Entrada

NCP creará un equilibrador de carga de Capa 7 para las entradas con especificación TLS y otro equilibrador de carga de Capa 7 para las entradas sin especificación TLS. También puede crear objetos CRD (CustomResourceDefinitions) para controlar el ajuste de escala de la entrada.

Tenga en cuenta lo siguiente:

Todas las entradas obtendrán una sola dirección IP.

Al recurso de entrada se le asigna una dirección IP del grupo de direcciones IP externas que la opción

external_ip_pools

especifica en la sección

[nsx_v3]

ncp.ini

. El equilibrador de carga se expone en esta dirección IP y los puertos HTTP y HTTPS (80 y 443).

Al recurso de entrada se le asigna una dirección IP del grupo de direcciones IP externas que la opción

external_ip_pools_lb

especifica en la sección

[nsx_v3]

ncp.ini

. Si la opción

external_ip_pools_lb

no existe, se utiliza el grupo que

external_ip_pools

especifica. El equilibrador de carga se expone en esta dirección IP y los puertos HTTP y HTTPS (80 y 443).

Puede utilizar otro grupo de direcciones IP cambiando la configuración y reiniciando NCP.

Puede especificar un certificado predeterminado para TLS. A continuación podrá obtener información sobre la generación de un certificado y el montaje de este en el pod de NCP.

Las entradas sin especificación TLS se alojarán en el servidor virtual HTTP (puerto 80).

Las entradas con especificación TLS se alojarán en el servidor virtual HTTPS (puerto 443). El equilibrador de carga actuará como servidor SSL y finalizará la conexión SSL de cliente.

Se admite la modificación de una entrada agregando o quitando la sección TLS. Cuando la clave

tls

se quita de la especificación de entrada, las reglas de entrada se transferirán del servidor virtual HTTPS (puerto 443) al servidor virtual HTTP (puerto 80). De igual modo, cuando la clave

tls

se agrega a la especificación de entrada, las reglas de entrada se transferirán del servidor virtual HTTP (puerto 80) al servidor virtual HTTPS (puerto 443).

Si hay reglas duplicadas en las definiciones de entrada de un solo clúster, solo se aplicará la primera regla. El resto de entradas con reglas duplicadas se anotarán con un error. Por ejemplo, si crea dos entradas con el mismo

host

y la misma

path

; una entrada tiene especificación TLS y la otra no, y

kubernetes.io/ingress.allow-http

se establece como

false

, las dos reglas se crearán en servidores virtuales diferentes y no entrarán en conflicto entre sí. Sin embargo, si

true

se establece como

kubernetes.io/ingress.allow-http

, la entrada que se aplique posteriormente se anotará con un error. Consulte la sección "Errores" que se incluye más abajo para obtener más información.

Solo se admite una entrada con un back-end predeterminado en cada clúster. El tráfico que no coincida con ninguna regla de entrada se reenviará al back-end predeterminado.

Si hay varias entradas con back-end predeterminados, solo se configurará la primera. Las demás se anotarán con un error. Consulte la sección "Errores" que se incluye más abajo para obtener más información.

(NCP 3.0.0 y 3.0.1) Las reglas se aplican en el siguiente orden:

Reglas con

host

path

especificados y sin coincidencia de expresión regular.

Reglas con

host

path

especificados y con coincidencia de expresión regular (con la

path

de entrada más larga en primer lugar).

Reglas con

host

path

especificados y sin coincidencia de expresión regular.

Reglas con

host

path

especificados y con coincidencia de expresión regular (con la

path

de entrada más larga en primer lugar).

(NCP 3.0.2 y versiones posteriores) Las reglas se aplican en el siguiente orden:

Reglas con

host

path

especificado.

Rules con

Exact

pathType

Rules con

Prefix

pathType

Rules con

Regex

pathType

Reglas con

host

path

especificado.

Rules con

Exact

pathType

Rules con

Prefix

pathType

Rules con

Regex

pathType

Nota: Si hay varias rutas que coinciden con una solicitud, se proporcionará la prioridad a la ruta más larga.

Acerca de

pathType

ImplementationSpecific

se trata igual que

Exact

Dos rutas de acceso que coinciden con

pathType

diferentes pueden coexistir.

Para el tipo

Prefix

/foo

coincidirá con

/foo/

/foo/bar

pero no con

/foo

ni /

foobar

. Para buscar coincidencias de

/foo

, agregue la ruta

Exact

/foo

a la regla de entrada.

(Esto es aplicable si utiliza el modo Directiva). Si se crea una entrada TLS con un back-end predeterminado, se recomienda configurar el back-end predeterminado para responder a las solicitudes HTTP y HTTPS debido a lo siguiente:

El equilibrador de carga finalizará TLS y enviará solicitudes HTTP al servidor back-end predeterminado si hay una entrada TLS (en el clúster para el caso práctico de Kubernetes/PKS o en el mismo espacio de nombres para el caso práctico de Project Pacific) con el host que coincida con el host de la solicitud.

El equilibrador de carga volverá a cifrar y a enviar solicitudes HTTPS al servidor back-end si no hay ninguna entrada TLS (en el clúster para el caso práctico de Kubernetes/PKS o en el mismo espacio de nombres para el caso práctico de Project Pacific) con el host que coincida con el host de la solicitud.

(NCP 3.0.0 y 3.0.1) No se admite el recurso

IngressClass

(NCP 3.0.2 y versiones posteriores) Se admite el recurso

IngressClass

(NCP 3.0.0 y 3.0.1) No se admite el atributo

pathType

(NCP 3.0.2 y versiones posteriores) Se admite el atributo

pathType

(NCP 3.0.2 y versiones posteriores) Se admite la autenticación de cliente JWT (token web JSON). Esta función requiere NSX-T Data Center 3.0.0 o versiones posteriores.

A partir de Kubernetes 1.18, la anotación

kubernetes.io/ingress.class

de entrada queda obsoleta y se reemplaza por el recurso IngressClass. Para especificar NSX-T como el controlador de entrada en el recurso IngressClass, establezca el parámetro del controlador en

k8s.io/nsx

. Por ejemplo:

kind: IngressClass
metadata:
  name: nsx-lb
  annotations:
    ingressclass.kubernetes.io/is-default-class: true
spec:
  controller: k8s.io/nsx

Para especificar un controlador de entrada de terceros, establezca el parámetro del controlador en

k8s.io/<controller name>

. Por ejemplo:

kind: IngressClass
metadata:
  name: nginx-lb
  annotations:
    ingressclass.kubernetes.io/is-default-class: false
spec:
  controller: k8s.io/ingress-nginx

Para establecer IngressClass como el valor predeterminado para el clúster, establezca la anotación

ingressclass.kubernetes.io/is-default-class

true

. Consulte el ejemplo anterior.

No debe utilizar ni la anotación

kubernetes.io/ingress.class

ni el recurso IngressClass.

Anotaciones de funciones

En la siguiente tabla, se incluyen las anotaciones compatibles con NCP:

Anotación	Descripción	Valores compatibles	Valor predeterminado	Versión de NCP
kubernetes.io/ingress.allow-http	Habilita las solicitudes HTTP además de HTTPS.	true, false	true	2.5 y versiones posteriores
ncp/use-regex	Habilita la coincidencia de patrones de ruta.	true, false	false	2.5.1 y posteriores
ingress.kubernetes.io/rewrite-target	Vuelve a escribir la ruta de la solicitud entrante.	(NCP 2.5 y versiones posteriores) Rutas que empiezan por ‘/’ (NCP 2.5.1 y versiones posteriores, y NSX-T 2.5.1 y versiones posteriores) Rutas con un marcador de posición numerado para un grupo capturado en una expresión regular, por ejemplo, /$1	Sin valor predeterminado	Consulte la columna Valores compatibles.
ncp/http-redirect	Redirecciona las solicitudes HTTP a HTTPS.	true, false	false	2.5.1 y posteriores
kubernetes.io/ingress.class	Indica qué controlador de entrada es responsable de una entrada determinada.	nsx, nginx, etc.	nsx	2.5 y versiones posteriores
nsx/loadbalancer	Coloca una entrada en un equilibrador de carga específico.	Nombre de un objeto CRD de equilibrador de carga	Sin valor predeterminado	2.5.1 y posteriores
ncp/whitelist-source-range	Limita el acceso de entrada por la IP de origen de la solicitud	Lista separada por comas de CIDR, direcciones IP o rangos de IP.	Sin valor predeterminado	3.0.0 y posteriores
ncp/ssl-mode	Selecciona el modo SSL para todas las reglas de una entrada.	offload, reencrypt, passthrough	offload	3.0.1 y posteriores
ncp/jwt-alg	Determina el algoritmo que se utilizará para validar la firma de JWT. Habilita la autenticación del cliente de JWT cuando se establece con ncp/jwt-secret.	HS256, RS256	Sin valor predeterminado	3.0.2 y posteriores
ncp/jwt-secret	Especifica el nombre del secreto de Kubernetes que contiene el secreto de JWT o la clave pública que se utiliza para la validación de la firma. Habilita la autenticación del cliente de JWT cuando se establece con ncp/jwt-alg.	Nombre de un secreto de Kubernetes	Sin valor predeterminado	3.0.2 y posteriores
ncp/jwt-token	Ubicación adicional para buscar JWT en la solicitud HTTP.	_arg_<nombre_parámetro>, _cookie_<nombre_cookie>	Sin valor predeterminado	3.0.2 y posteriores
ncp/jwt-realm	Especifica el encabezado de territorio devuelto con 401 cuando falla la autenticación.	Cadena que indica el dominio Kerberos	Nombre de host de la regla de entrada	3.0.2 y posteriores
ncp/jwt-preserve	Opción para mantener JWT y pasar al back-end después de una autenticación correcta.	true, false	true	3.0.2 y posteriores

Información sobre las anotaciones:

Coincidencia REGEX (expresión regular) de la ruta

Para NCP 2.5.0 y versiones anteriores

En NCP 2.5.0 y versiones anteriores, la coincidencia de todas las rutas secundarias se habilita automáticamente mediante los caracteres de expresión regular "." y "*". Por ejemplo, la ruta

/coffee/.*

coincide con

/coffee/

seguido de uno, ninguno o varios caracteres como, por ejemplo,

/coffee/

/coffee/a

/coffee/b

, pero no

/coffee

/coffeecup

/coffeecup/a

Un ejemplo de especificación de entrada:

kind: Ingress
metadata:
  name: cafe-ingress
spec:
  rules:
  - http:
      paths:
      - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
        backend:
          serviceName: coffee-svc
          servicePort: 80

Para NCP 2.5.1 y versiones posteriores

Puede habilitar o deshabilitar la coincidencia de expresiones regulares del parámetro

path

de entrada (pero no

host

) mediante la anotación

ncp/use-regex

. Si se establece como

false

, la coincidencia exacta de la ruta se realiza mediante la coincidencia

equals

. Si se establece como

true

, la coincidencia de expresión regular se realiza agregando el inicio del carácter de cadena (^) y el final del carácter de cadena ($) a la ruta para que todo el URI de solicitud coincida con el patrón. Tenga en cuenta que cuando se utiliza el operador

(|), siempre se debe especificar el ámbito con paréntesis para que ^ y $ se apliquen a todos los operandos. Por ejemplo,

path: /(tea|coffee|milk)

. Un ejemplo de especificación de entrada:

kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    ncp/use-regex: "true"
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea/.*
        backend:
          serviceName: tea-svc
          servicePort: 80

Cómo actualizar las entradas antes de actualizar NCP a la versión 2.5.1 u otra posterior

Este proceso solo es necesario en caso de que haya entradas que requieran la coincidencia de todas las rutas secundarias mediante el uso de los caracteres "." y "*".

Actualice las entradas para que incluyan la anotación

ncp/use-regex: true

Para la coincidencia de todas las rutas secundarias, si tiene rutas como

/coffee/*

, cámbielas a

/coffee/.*

/.*

/coffee/.*

coincidirá con

/coffee/

/coffee/a

/coffee/b

/coffee/a/b

, etc.

/.*

coincidirá con

/coffee

/tea

/coffee/a

, etc. Si omite la ruta, el comportamiento será igual que

path: /.*

Ejemplo de anotación

ingress.kubernetes.io/rewrite-target

kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

Las rutas de acceso

/tea

/coffee

se reescribirán como

antes de enviar la URL al servicio back-end.

A partir de las versiones 2.5.1 de NCP y NSX-T, si

path

se especifica mediante una expresión regular, los grupos capturados se guardarán en marcadores de posición numerados con el formato $1, $2, etc. Estos marcadores de posición se pueden utilizar como parámetros en la anotación

ingress.kubernetes.io/rewrite-target

. No se admiten marcadores de posición con nombre ni grupos capturados con nombre. Por ejemplo,

kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    ncp/use-regex: "true"
    #/tea/cup will be rewritten to /cup before sending request to endpoint
    ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea/(.*)
        backend:
          serviceName: tea-svc
          servicePort: 80

Información sobre la anotación

kubernetes.io/ingress.allow-http

Si la anotación se establece como

false

, se crearán reglas para el servidor virtual HTTPS.

Si se establece como

true

o no se incluye, se crearán reglas para los servidores virtuales HTTP y HTTPS. Tenga en cuenta que se crearán reglas HTTPS si la sección TLS está presente en la especificación de entrada.

Información sobre la anotación

ncp/http-redirect

Si la anotación se establece como

false

, el tráfico HTTP que entra (puerto 80) hacia el servidor virtual HTTP no se redirigirá al servidor virtual HTTPS.

Si la anotación se establece como

true

, el tráfico HTTP que entra (puerto 80) hacia el servidor virtual HTTP se redirigirá al servidor virtual HTTPS (puerto 443).

Esta anotación solo es válida si está presente la sección TLS. Esta anotación tiene prioridad sobre

kubernetes.io/ingress.allow-http

. Cuando se establece como

true

, dirigirá el tráfico HTTP que coincida hacia HTTPS con independencia del valor que establezca para

kubernetes.io/ingress.allow-http

Información sobre la anotación

kubernetes.io/ingress.class

Si el valor es

nsx

, NCP gestionará la entrada. Si se especifica otro valor, NCP ignorará la entrada. Para obtener más información, consulte Controladores de entrada de terceros.

Para obtener más información sobre la anotación

nsx/loadbalancer

, consulte Objetos CRD LoadBalancer para ajustar la escala de entrada.

Información sobre la anotación

ncp/whitelist-source-range

Cuando se establece, solo se aceptará una solicitud entrante si su IP de origen se incluye en esta anotación. De lo contrario, se descartará el tráfico.

Puede especificar una combinación de CIDR, direcciones IP y rangos de IP. Por ejemplo, 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.

YAML de ejemplo:

kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    ncp/whitelist-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"
spec:
  tls:
  - hosts:
    - cafe.example.com
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80

Información sobre la anotación

ncp/ssl-mode

Esta anotación se aplica a todas las reglas de una entrada y el equilibrador de carga funcionará en el modo SSL seleccionado para estas reglas.

Nota: Si

ncp/ssl-mode

está establecido en

reencrypt

passthrough

kubernetes.io/ingress.allow-http

debe establecerse en

False

. Esta anotación no se puede establecer en

passthrough

si está establecida la anotación

ingress.kubernetes.io/rewrite-target

ncp/use-regex

ncp/whitelist-source-range

Acerca de la autenticación de cliente de JWT:

Para habilitar la autenticación del cliente de JWT para todas las reglas bajo una entrada, tanto

ncp/jwt-alg

como

ncp/jwt-secret

deben tener un valor válido. Cuando se habilita, el tráfico HTTP entrante, solo se transfiere al back-end si se proporciona un token web JSON válido. De lo contrario, el tráfico se rechazará con el estado 401.

Esta función no es compatible con las siguientes anotaciones:

kubernetes.io/ingress.allow-http: true

ncp/http-redirect: true

ncp/ssl-mode: passthrough

ncp/jwt-alg

Algoritmos simétricos compatibles: HS256

Algoritmos asimétricos compatibles: RS256

ncp/jwt-secret

Debe configurarse una clave simétrica o un certificado público en un secreto de Kubernetes con el nombre especificado en esta anotación en el mismo espacio de nombres que la entrada.

Para los algoritmos simétricos, el secreto debe estar almacenado en el campo

jwt.key

Para los algoritmos asimétricos, el certificado público debe estar almacenado en el campo

tls.crt

La autenticación del cliente de JWT se deshabilitará si el secreto simétrico o el certificado público no se almacenan en las ubicaciones mencionadas anteriormente, o si los datos almacenados en el secreto no son válidos.

ncp/jwt-token

Solo se puede configurar un elemento en esta anotación.

_arg_<param_name>

: para los JWT pasados como un parámetro de URI. Especifique el nombre del parámetro que contiene JWT.

_cookie_<cookie_name>

: para los JWT pasados como una cookie. Especifique el nombre de la cookie que contiene JWT.

Errores

Los errores se anotan en el recurso de entrada. La clave de error es

ncp/error.loadbalancer

y la clave de advertencia es

ncp/warning.loadbalancer

. El error y la advertencia posibles son:

ncp/error.loadbalancer

DEFAULT_BACKEND_IN_USE

Este error indica que ya existe una entrada con un back-end predeterminado. La entrada estará inactiva. Este error se produce si 1) la entrada es para HTTP y existe otra entrada para HTTP con un back-end predeterminado; 2) la entrada es para HTTPS y existe otra entrada para HTTPS con un back-end predeterminado, o 3) la entrada es para HTTP y HTTPS y existe otra entrada para HTTP y HTTPS con un back-end predeterminado. Para solucionar el error, elimine y vuelva a crear la entrada con una especificación correcta.

ncp/warning.loadbalancer

SECRET_NOT_FOUND

Este error indica que el secreto especificado en la especificación de entrada no existe, o si

ncp/jwt-alg

ncp/jwt-secret

están anotados, pero el secreto no se puede encontrar en el mismo espacio de nombres que la entrada. La entrada se activará parcialmente. Para solucionar el error, cree el secreto que falta. Tenga en cuenta que las advertencias incluidas en la anotación no se borrarán durante el ciclo de vida del recurso de entrada.

ncp/warning.loadbalancer

INVALID_INGRESS

Este error indica que se cumple una de las siguientes condiciones. La entrada estará inactiva. Para solucionar el error, elimine y vuelva a crear la entrada con una especificación correcta.

Una regla de entrada entra en conflicto con otra regla de entrada en el mismo clúster de Kubernetes. Solo se producen conflictos entre entradas que tengan la misma estrategia de coincidencia, es decir, con el mismo valor de la anotación

ncp/use-regex

La anotación

kubernetes.io/ingress.allow-http

se establece como

false

y la entrada no tiene una sección TLS.

La anotación

ncp/http-redirect

se establece como

true

y la entrada no tiene una sección TLS.

Una regla de entrada no tiene

host

path

especificados. Una regla de entrada de este tipo tiene la misma funcionalidad que el back-end predeterminado de entrada. Utilice el back-end predeterminado de entrada en su lugar.

La entrada tiene anotaciones de JWL que no se pueden procesar correctamente. Por ejemplo:

Falta

ncp/jwt-alg

ncp/jwt-secret

ncp/jwt-alg

está configurado con un algoritmo no admitido.

ncp/jwt-alg

ncp/jwt-secret

están configurados con otras anotaciones de habilitación de HTTP, o con acceso directo a SSL.

Equilibrio de carga

Content feedback and comments

VMware NSX Container Plugin 3.2

Entrada

Anotaciones de funciones

Errores