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ónexternal_ip_poolsespecifica en la sección[nsx_v3]dencp.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ónexternal_ip_pools_lbespecifica en la sección[nsx_v3]dencp.ini. Si la opciónexternal_ip_pools_lbno existe, se utiliza el grupo queexternal_ip_poolsespecifica. 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 clavetlsse 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 clavetlsse 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 mismohosty la mismapath; una entrada tiene especificación TLS y la otra no, ykubernetes.io/ingress.allow-httpse establece comofalse, las dos reglas se crearán en servidores virtuales diferentes y no entrarán en conflicto entre sí. Sin embargo, sitruese establece comokubernetes.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 conhostypathespecificados y sin coincidencia de expresión regular.
- Reglas conhostypathespecificados y con coincidencia de expresión regular (con lapathde entrada más larga en primer lugar).
- Reglas conhostopathespecificados y sin coincidencia de expresión regular.
- Reglas conhostopathespecificados y con coincidencia de expresión regular (con lapathde entrada más larga en primer lugar).
- (NCP 3.0.2 y versiones posteriores) Las reglas se aplican en el siguiente orden:
- Reglas conhostypathespecificado.
- Rules conExactpathType.
- Rules conPrefixpathType.
- Rules conRegexpathType.
- Reglas conhostopathespecificado.
- Rules conExactpathType.
- Rules conPrefixpathType.
- Rules conRegexpathType.
Nota: Si hay varias rutas que coinciden con una solicitud, se proporcionará la prioridad a la ruta más larga.Acerca depathType:- ImplementationSpecificse trata igual queExact.
- Dos rutas de acceso que coinciden conpathTypediferentes pueden coexistir.
- Para el tipoPrefix,/foocoincidirá con/foo/,/foo/barpero no con/fooni /foobar. Para buscar coincidencias de/foo, agregue la rutaExact/fooa 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 recursoIngressClass.
- (NCP 3.0.2 y versiones posteriores) Se admite el recursoIngressClass.
- (NCP 3.0.0 y 3.0.1) No se admite el atributopathType.
- (NCP 3.0.2 y versiones posteriores) Se admite el atributopathType.
- (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
en 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. |
| 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 anterioresEn 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/ay/coffee/b, pero no/coffee,/coffeecupni/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 posterioresPuede habilitar o deshabilitar la coincidencia de expresiones regulares del parámetropathde entrada (pero nohost) mediante la anotaciónncp/use-regex. Si se establece comofalse, la coincidencia exacta de la ruta se realiza mediante la coincidenciaequals. Si se establece comotrue, 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 operadorOR(|), 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 posteriorEste 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ónncp/use-regex: true.
- Para la coincidencia de todas las rutas secundarias, si tiene rutas como/coffee/*o/*, cámbielas a/coffee/.*y/.*./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 quepath: /.*.
- Ejemplo de anotacióningress.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: 80Las rutas de acceso/teay/coffeese 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, sipathse 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óningress.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ónkubernetes.io/ingress.allow-http:
- Si la anotación se establece comofalse, se crearán reglas para el servidor virtual HTTPS.
- Si se establece comotrueo 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ónncp/http-redirect:
- Si la anotación se establece comofalse, 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 comotrue, 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 sobrekubernetes.io/ingress.allow-http. Cuando se establece comotrue, dirigirá el tráfico HTTP que coincida hacia HTTPS con independencia del valor que establezca parakubernetes.io/ingress.allow-http. - Información sobre la anotaciónkubernetes.io/ingress.class:
- Si el valor esnsx, 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ónnsx/loadbalancer, consulte Objetos CRD LoadBalancer para ajustar la escala de entrada.
- Información sobre la anotaciónncp/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ónncp/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: Sincp/ssl-modeestá establecido enreencryptopassthrough,kubernetes.io/ingress.allow-httpdebe establecerse enFalse. Esta anotación no se puede establecer enpassthroughsi está establecida la anotacióningress.kubernetes.io/rewrite-target,ncp/use-regexoncp/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, tantoncp/jwt-algcomoncp/jwt-secretdeben 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 campojwt.key.
- Para los algoritmos asimétricos, el certificado público debe estar almacenado en el campotls.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_USEEste 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_FOUNDEste error indica que el secreto especificado en la especificación de entrada no existe, o sincp/jwt-algyncp/jwt-secretestá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_INGRESSEste 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ónncp/use-regex.
- La anotaciónkubernetes.io/ingress.allow-httpse establece comofalsey la entrada no tiene una sección TLS.
- La anotaciónncp/http-redirectse establece comotruey la entrada no tiene una sección TLS.
- Una regla de entrada no tienehostnipathespecificados. 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:
- Faltancp/jwt-algoncp/jwt-secret.
- ncp/jwt-algestá configurado con un algoritmo no admitido.
- ncp/jwt-algyncp/jwt-secretestán configurados con otras anotaciones de habilitación de HTTP, o con acceso directo a SSL.