En esta página, se describen las capacidades principales y la arquitectura de redes de GKE Ingress, específicamente la protección de las conexiones desde el cliente hasta el balanceador de cargas y hasta los Pods de la aplicación, la administración del enrutamiento complejo en varios servicios de backend y la comprensión de cómo se organizan las verificaciones de estado del balanceador de cargas dentro de un clúster.
En esta página, se desarrollan los conceptos fundamentales que se describen en la descripción general de Ingress de GKE. Si deseas obtener instrucciones paso a paso y ejemplos de implementación con recursos personalizados, como FrontendConfig y BackendConfig, consulta Configura las funciones de Ingress para las aplicaciones de GKE.
Esta página está dirigida a especialistas en redes que diseñan la red para su organización y que instalan, configuran y brindan asistencia técnica para el equipo de redes. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes del usuario de GKE.
Protege Ingress con HTTPS
El Ingress de GKE protege el tráfico entre el cliente y el balanceador de cargas de aplicaciones, y desde el balanceador de cargas hasta los Pods de la aplicación.
Configura TLS entre el cliente y el balanceador de cargas
Un balanceador de cargas HTTP(S) actúa como un proxy entre tus clientes y tu aplicación. Si deseas aceptar solicitudes HTTPS de tus clientes, el balanceador de cargas debe contar con un certificado para que pueda demostrar su identidad a los clientes. También debe tener una clave privada para completar el protocolo de enlace HTTPS.
Cuando el balanceador de cargas acepta una solicitud HTTP(S) de un cliente, el tráfico entre el cliente y el balanceador de cargas se encripta mediante TLS. Sin embargo, el balanceador de cargas finaliza el cifrado TLS y reenvía la solicitud sin encriptación a la aplicación. Para obtener más información, consulta Cómo configurar la encriptación entre el balanceador de cargas y tu aplicación.
Métodos para proporcionar certificados SSL
Puedes proporcionar certificados SSL a un balanceador de cargas de HTTP(S) a través de los siguientes métodos:
Certificados administrados por Google: Son certificados de validación de dominio (DV) que Google aprovisiona, renueva y administra para tus nombres de dominio. Estos certificados no demuestran tu identidad ni la de tu organización. Los certificados administrados por Google admiten hasta 100 dominios sin comodines. Para obtener más información, consulta Usa certificados administrados por Google.
Certificados autoadministrados compartidos con Google Cloud: Puedes aprovisionar tu propio certificado SSL y crear un recurso de certificado en tu proyecto de Google Cloud . Luego, puedes enumerar el recurso de certificado en una anotación en un Ingress para crear un balanceador de cargas de HTTP(S) que use el certificado. Para obtener más información, consulta Usa certificados ya compartidos.
Certificados autoadministrados que usan Secrets de Kubernetes: Puedes aprovisionar tu propio certificado SSL y crear un Secret para retenerlo. Luego, puedes hacer referencia al secreto en el campo
tlsde un manifiesto de Ingress para crear un balanceador de cargas HTTP(S). Para obtener más información, consulta Usa Secrets de Kubernetes.
Entrega tráfico HTTPS con varios certificados
Puedes configurar el balanceador de cargas de aplicaciones para que presente hasta 15 certificados TLS a un cliente. Usar varios certificados es fundamental cuando necesitas entregar contenido desde varios nombres de host, cada uno de los cuales requiere un certificado diferente (por ejemplo, certificados separados para your-store.example y your-experimental-store.example). Puedes especificar estos múltiples certificados en el manifiesto de Ingress.
Selección y prioridad de certificados
Para determinar qué certificado presentar al cliente, el balanceador de cargas usa la indicación de nombre del servidor (SNI).
Si el cliente usa SNI o un nombre de dominio que coincide con el nombre común (CN) en uno de los certificados disponibles, el balanceador de cargas usa el certificado cuyo CN coincide más con el nombre de host solicitado por el cliente.
Si el cliente no admite SNI o el nombre de dominio solicitado no coincide con el CN de ningún certificado disponible, el balanceador de cargas usa el primer certificado que aparece en el manifiesto de Ingress como el predeterminado. El balanceador de cargas elige este certificado según las siguientes reglas:
- Para los Secretos enumerados en el bloque
tls, el certificado principal es el primer Secreto en el bloquetls. - Para los certificados ya compartidos en la anotación
pre-shared-cert, el certificado principal es el primer certificado que se indica en la anotación. - Para los certificados administrados por Google en la anotación
managed-certificates, todos los certificados administrados se ordenan alfabéticamente por nombre. El certificado principal es el primero de esta lista alfabética. Para establecer un certificado específico como principal, debes nombrar tus objetosManagedCertificatede manera adecuada para controlar el orden de clasificación. Por ejemplo, para quemy-default-certsea el principal en lugar deanother-cert, puedes llamarlos0-my-default-certy1-another-cert.
- Para los Secretos enumerados en el bloque
Cuando el balanceador de cargas presenta varios certificados a través de diferentes métodos de GKE, los certificados ya compartidos tienen prioridad sobre los Secretos que se enumeran en el bloque tls de Ingress.
En el siguiente diagrama, se muestra un balanceador de cargas que envía tráfico a backends diferentes, según el nombre de dominio que se usa en la solicitud:
Prácticas recomendadas para la rotación de certificados
Si deseas rotar el contenido de tu Secret o un certificado ya compartido, sigue estas prácticas recomendadas:
- Crea un nuevo Secreto o certificado ya compartido con un nombre diferente que contenga los datos del certificado nuevo. Actualiza tu Ingress para usar el nuevo recurso de certificado.
- Si no te molesta interrumpir el tráfico, puedes quitar el recurso anterior del Ingress, aprovisionar un recurso nuevo con el mismo nombre, pero de contenido diferente y, luego, volver a conectarlo al Ingress.
Para evitar llevar a cabo la administración de la rotación de certificados, usa certificados SSL administrados por Google.
Aplicar el tráfico solo HTTPS
Si deseas que todo el tráfico entre el cliente y el balanceador de cargas HTTP(S) use HTTPS, puedes inhabilitar HTTP con la inclusión de la anotación kubernetes.io/ingress.allow-http en el manifiesto de Ingress y establecer el valor en "false". Para obtener más información, consulta Inhabilita HTTP.
Configura la encriptación entre el balanceador de cargas y tu aplicación
En esta sección, se explica cómo proteger la conexión desde el balanceador de cargas hasta los Pods de la aplicación.
Habilita el protocolo de backend HTTPS o HTTP/2
El balanceador de cargas de aplicaciones externo actúa como un proxy entre tus clientes y tu aplicación de GKE. Si bien los clientes pueden conectarse al balanceador de cargas a través de HTTPS (para el encriptado) y varios protocolos (HTTP/1.1 o HTTP/2), la conexión del balanceador de cargas a tus Pods de backend se establece de forma predeterminada en HTTP/1.1 sin encriptar.
Si tu aplicación puede controlar configuraciones más avanzadas, puedes actualizar manualmente el balanceador de cargas de aplicaciones externo para que use lo siguiente:
- HTTP/2: Para optimizar el rendimiento si tus Pods lo admiten.
- HTTPS (TLS): Para aplicar la encriptación de extremo a extremo del tráfico entre el proxy del balanceador de cargas y tus Pods.
Puedes controlar tanto el protocolo (HTTP o HTTPS) como la versión de HTTP (HTTP/1.1 o HTTP/2) que se usan para la conexión de backend con la anotación cloud.google.com/app-protocols en tu manifiesto de servicio de Kubernetes.
Este manifiesto de Service debe incluir type: NodePort, a menos que uses el balanceo de cargas nativo del contenedor. Si usas el balanceo de cargas nativo del contenedor, usa type: ClusterIP.
Direcciones IP estáticas para balanceadores de cargas de HTTPS
Cuando creas un objeto Ingress para un balanceador de cargas de aplicaciones externo, obtienes una dirección IP externa estable que los clientes pueden usar para acceder a tus Services y, a su vez, a tus contenedores en ejecución. La dirección IP es estable en el sentido de que dura toda la vida útil del objeto Ingress. Si borras tu Ingress y creas uno nuevo a partir del mismo archivo de manifiesto, no se garantiza que obtengas la misma dirección IP externa.
Si deseas que una dirección IP permanente permanezca igual cuando borres el Ingress y crees uno nuevo, debes reservar una dirección IP externa y estática global. Luego, en el manifiesto del Ingress, incluye una anotación que indique el nombre de tu dirección IP estática reservada. Si modificas un Ingress existente para que use una dirección IP estática en lugar de una dirección IP efímera, GKE podría cambiar la dirección IP del balanceador de cargas cuando GKE vuelva a crear la regla de reenvío del balanceador de cargas.
Enrutamiento del tráfico
GKE Ingress usa mapas de URL para definir cómo se enrutan las solicitudes entrantes a servicios de backend específicos. Puedes configurar reglas de enrutamiento basadas en nombres de host, rutas de acceso de URL o una combinación de ambos para administrar el tráfico de varias aplicaciones a través de un solo balanceador de cargas.
Servicios de backend múltiples
Cada balanceador de cargas de aplicaciones externo o balanceador de cargas de aplicaciones interno usa un solo mapa de URL, que hace referencia a uno o más servicios de backend. Un servicio de backend corresponde a cada servicio al que se hace referencia en el Ingress.
Por ejemplo, puedes configurar el balanceador de cargas para enrutar solicitudes a diferentes servicios de backend según la ruta de URL. Las solicitudes enviadas a your-store.example se pueden enrutar a un servicio de backend que muestra artículos a precio completo; las solicitudes enviadas a your-store.example/discounted se pueden enrutar a un servicio de backend que muestra artículos con descuento.
También puedes configurar el balanceador de cargas para enrutar solicitudes según el nombre de host. Las solicitudes enviadas a your-store.example pueden ir a un servicio de backend y las solicitudes enviadas a your-experimental-store.example pueden ir a otro.
En un clúster de GKE, puedes crear un objeto Ingress de Kubernetes para crear y configurar un balanceador de cargas HTTP(S). Un objeto Ingress debe estar asociado con uno o más objetos Service, cada uno de los cuales está asociado con un conjunto de pods.
Si deseas configurar GKE Ingress con varios backends para el mismo host, debes tener una sola regla con un solo host y varias rutas. De lo contrario, el controlador de Ingress de GKE aprovisiona solo un servicio de backend.
A continuación, se detalla un manifiesto para un Ingress llamado my-ingress:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: your-store.example http: paths: - path: /products pathType: ImplementationSpecific backend: service: name: my-products port: number: 60000 - path: /discounted pathType: ImplementationSpecific backend: service: name: my-discounted-products port: number: 80
Cuando creas el Ingress, el controlador de Ingress de GKE crea y configura un balanceador de cargas de aplicaciones externo o un balanceador de cargas de aplicaciones interno según la información en el Ingress y los servicios asociados. Además, se le asigna una dirección IP estable al balanceador de cargas que puedes asociar con un nombre de dominio.
En el ejemplo anterior, supón que asociaste la dirección IP del balanceador de cargas con el nombre de dominio your-store.example. Cuando un cliente envía una solicitud a your-store.example/products, la solicitud se enruta a un Service de Kubernetes llamado my-products en el puerto 60000. Cuando un cliente envía una solicitud a your-store.example/discounted, la solicitud se enruta a un Service de Kubernetes llamado my-discounted-products en el puerto 80.
El único carácter comodín admitido para el campo path de un Ingress es el carácter *. El carácter * debe estar después de una barra diagonal (/) y debe ser el último carácter del patrón. Por ejemplo, /*, /foo/* y /foo/bar/* son patrones válidos, pero *, /foo/bar* y /foo/*/bar no lo son.
Un patrón más específico tiene prioridad sobre uno menos específico. Si tienes /foo/* y /foo/bar/*, entonces se considera que /foo/bar/bat coincide con /foo/bar/*.
Para obtener más información sobre las limitaciones de ruta y la coincidencia de patrones, consulta la documentación de mapas de URL.
El manifiesto para el servicio my-products podría verse así:
apiVersion: v1 kind: Service metadata: name: my-products spec: type: NodePort selector: app: products department: sales ports: - protocol: TCP port: 60000 targetPort: 50000
Ten en cuenta lo siguiente en el manifiesto anterior:
El campo
spec.typedepende del método de balanceo de cargas que uses:- Si usas el balanceo de cargas nativo del contenedor, usa
type: ClusterIP. - Si usas grupos de instancias, usa
type: NodePort.
- Si usas el balanceo de cargas nativo del contenedor, usa
El campo
selectorindica que cualquier pod que tenga las etiquetasapp: productsydepartment: saleses miembro de este servicio.Cuando llega una solicitud al Service en el puerto 60000, se enruta a uno de los pods miembros en el puerto TCP 50000.
Cada pod miembro debe tener un contenedor que escuche en el puerto TCP 50000.
El manifiesto para el servicio my-discounted-products podría verse así:
apiVersion: v1 kind: Service metadata: name: my-discounted-products spec: type: NodePort selector: app: discounted-products department: sales ports: - protocol: TCP port: 80 targetPort: 8080
Ten en cuenta lo siguiente en el manifiesto anterior:
El campo
selectorindica que cualquier Pod que tenga las etiquetasapp: discounted-productsydepartment: saleses miembro de este Servicio.Cuando llega una solicitud al servicio del puerto 80, se enruta a uno de los pods miembros en el puerto TCP 8080.
Cada pod miembro debe tener un contenedor que escuche en el puerto TCP 8080.
Backend predeterminado
Puedes especificar un backend predeterminado para tu Ingress proporcionando un campo spec.defaultBackend
en tu manifiesto de Ingress. Esto controlará cualquier solicitud que no coincida
con las rutas definidas en el campo rules. Por ejemplo, en el siguiente Ingress, toda
solicitud que no coincida con /discounted se enviará a un servicio llamado my-products en
el puerto 60001.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
defaultBackend:
service:
name: my-products
port:
number: 60001
rules:
- http:
paths:
- path: /discounted
pathType: ImplementationSpecific
backend:
service:
name: my-discounted-products
port:
number: 80
Si no especificas un backend predeterminado, GKE proporciona uno que muestra 404. Esto se crea como un servicio NodePort default-http-backend en el clúster en el espacio de nombres kube-system.
La respuesta HTTP 404 es similar a la siguiente:
response 404 (backend NotFound), service rules for the path non-existent
Para configurar Ingress de GKE con un backend predeterminado personalizado, consulta Ingress de GKE con backend predeterminado personalizado.
Verificaciones de estado
Cuando expones uno o más objetos de servicio a través de un Ingress mediante el controlador de Ingress predeterminado, GKE crea un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno. Ambos balanceadores de cargas admiten varios servicios de backend en un solo mapa de URL. Cada uno de los servicios de backend corresponde a un servicio de Kubernetes, y cada servicio de backend debe hacer referencia a una Google Cloud verificación de estado. Esta verificación de estado es diferente de una prueba de funcionamiento o disponibilidad de Kubernetes porque la verificación de estado se implementa fuera del clúster.
Las verificaciones de estado del balanceador de cargas se especifican por servicio de backend. Si bien es posible usar la misma verificación de estado para todos los servicios de backend del balanceador de cargas, la referencia de verificación de estado no se especifica para todo el balanceador de cargas (en el objeto Ingress).
GKE crea verificaciones de estado según uno de los siguientes métodos:
- CRD de
BackendConfig: Es una definición de recurso personalizado (CRD) que te brinda un control preciso sobre la forma en que tus servicios interactúan con el balanceador de cargas. Las CRD deBackendConfigte permiten especificar parámetros personalizados para la verificación de estado asociada al servicio de backend correspondiente. Estos parámetros de configuración personalizados brindan mayor flexibilidad y control sobre las verificaciones de estado tanto para el balanceador de cargas de aplicaciones clásico como para el balanceador de cargas de aplicaciones interno creado por un Ingress. - Sondeo de preparación: Es una verificación de diagnóstico que determina si un contenedor dentro de un Pod está listo para entregar tráfico. El controlador de Ingress de GKE crea la verificación de estado para el servicio de backend del Service según el sondeo de preparación que usan los Pods de entrega de ese Service. Puedes derivar los parámetros de verificación de estado, como la ruta de acceso, el puerto y el protocolo, de la definición de la sonda de disponibilidad.
- Valores predeterminados: Son los parámetros que se usan cuando no configuras un CRD de
BackendConfigo no defines atributos para el sondeo de preparación.
Usa un CRD de BackendConfig para tener el mayor control sobre la configuración de la verificación de estado del balanceador de cargas.
GKE usa el siguiente procedimiento a fin de crear una verificación de estado para cada servicio de backend que corresponda a un Service de Kubernetes:
Si el Service hace referencia a una CRD de
BackendConfigcon informaciónhealthCheck, GKE usa esa información para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE admiten la creación de verificaciones de estado de esta manera.Si el Service no hace referencia a una CRD de
BackendConfig, haz lo siguiente:GKE puede inferir algunos o todos los parámetros para una verificación de estado si los Pod de entrega usan una plantilla de Pod con un contenedor cuya prueba de disponibilidad tiene atributos que se pueden interpretar como parámetros de verificación de estado. Consulta Parámetros de una prueba de disponibilidad para obtener detalles sobre la implementación y Parámetros inferidos y predeterminados a fin de obtener una lista de atributos que se pueden usar con el fin de crear una verificación de estado. Solo el controlador de Ingress de GKE admite la inferencia de parámetros de una prueba de disponibilidad.
Si la plantilla de pod para los pods de entrega del Service no tiene un contenedor con un sondeo de preparación cuyos atributos se pueden interpretar como parámetros de una verificación de estado, se usan los valores predeterminados para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE pueden crear una verificación de estado solo con los valores predeterminados.
Parámetros inferidos y predeterminados
Los siguientes parámetros se usan cuando no especificas parámetros de verificación de estado para el Service correspondiente con una CRD de BackendConfig.
| Parámetro de verificación de estado | Valor predeterminado | Valor inferible |
|---|---|---|
| Protocol | HTTP | si está presente en la anotación del servicio cloud.google.com/app-protocols
|
| Ruta de la solicitud | / |
si está presente en el spec del pod de entrega:containers[].readinessProbe.httpGet.path
|
| Encabezado de Host de solicitud | Host: backend-ip-address |
si está presente en el spec del pod de entrega:containers[].readinessProbe.httpGet.httpHeaders
|
| Respuesta esperada | HTTP 200 (OK) | No se puede cambiar HTTP 200 (OK) |
| Intervalo de verificación |
|
si está presente en el spec del pod de entrega:
|
| Tiempo de espera de verificación | 5 segundos | si está presente en el spec del pod de entrega:containers[].readinessProbe.timeoutSeconds |
| Umbral de buen estado | 1 | 1 No se puede modificar. |
| Umbral de mal estado |
|
Igual que la configuración predeterminada:
|
| Especificación de puerto |
|
Los sondeos de verificación de estado se envían al número de puerto especificado por spec.containers[].readinessProbe.httpGet.port, siempre que se cumplan todas las siguientes condiciones:
|
| Dirección IP de destino |
|
Igual que la configuración predeterminada:
|
Parámetros de una prueba de disponibilidad
Cuando GKE crea la verificación de estado para el servicio de backend del servicio, GKE puede copiar ciertos parámetros de prueba de disponibilidad de un contenedor que usan los Pod de entrega del servicio. Esta opción solo es compatible con el controlador de Ingress de GKE.
Los atributos de sondeo de preparación admitidos que se pueden interpretar como parámetros de verificación de estado se enumeran junto con los valores predeterminados en Parámetros predeterminados e inferidos. Los valores predeterminados se usan para los atributos no especificados en el sondeo de preparación o si no especificas ninguno.
Si los pods de entrega para tu Service contienen varios contenedores, o si usas el controlador de Ingress de GKE Enterprise, debes usar una CRD de BackendConfig para definir los parámetros de verificación de estado. Para obtener más información, consulta Cuándo usar un CRD de BackendConfig en su lugar.
Cuándo usar CRD de BackendConfig en su lugar
En lugar de depender de parámetros de sondeos de preparación de pods, debes definir explícitamente los parámetros de verificación de estado para un servicio de backend mediante la creación de una CRD de BackendConfig para el Service en estas situaciones:
Si usas GKE Enterprise: El controlador de Ingress de GKE Enterprise no admite la obtención de parámetros de verificación de estado de los sondeos de preparación de los pods de entrega. Solo puede crear verificaciones de estado con parámetros implícitos o como se define en una CRD de
BackendConfig.Si tienes más de un contenedor en los Pods de entrega: GKE no tiene una forma de seleccionar el sondeo de preparación de un contenedor específico desde el cual inferir los parámetros de verificación de estado. Debido a que cada contenedor puede tener su propio sondeo de preparación, y debido a que un sondeo de preparación no es un parámetro obligatorio para un contenedor, debes definir la verificación de estado del servicio de backend correspondiente mediante una referencia a
BackendConfigen el Service correspondiente.Si necesitas control sobre el puerto usado para las verificaciones de estado del balanceador de cargas: GKE solo usa la
containers[].readinessProbe.httpGet.portdel sondeo de preparación para la verificación de estado del servicio de backend cuando ese puerto coincide con el puerto de servicio para el Service al que se hace referencia en elspec.rules[].http.paths[].backend.servicePortde Ingress.
Parámetros de una CRD de BackendConfig
Puedes especificar los parámetros de verificación de estado del servicio de backend con el parámetro healthCheck de una BackendConfig CRD al que hace referencia el Service correspondiente. Esto te brinda más flexibilidad y control sobre
las verificaciones de estado para un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno
creado por un Ingress. Consulta Configuración de Ingress para conocer la compatibilidad con la versión de GKE.
Este CRD de BackendConfig de ejemplo define el protocolo de verificación de estado (tipo), una ruta de solicitud, un puerto y un intervalo de verificación en su atributo spec.healthCheck:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 15
port: 15020
type: HTTPS
requestPath: /healthz
Para configurar todos los campos disponibles cuando configuras una verificación de estado BackendConfig, usa el ejemplo de configuración de verificación de estado personalizada.
Para configurar Ingress de GKE con una verificación de estado HTTP personalizada, consulta Ingress de GKE con verificación de estado HTTP personalizada.
Preparación del pod
Después de configurar las verificaciones de estado del balanceador de cargas con uno de los métodos anteriores, el controlador de Ingress de GKE usa el estado de los extremos de backend para determinar la preparación de los Pods, lo que es fundamental para administrar las actualizaciones progresivas y la estabilidad general del tráfico.
Para los pod relevantes, el controlador Ingress correspondiente administra una puerta de preparación de tipo cloud.google.com/load-balancer-neg-ready. El controlador Ingress sondea la condición de la verificación de estado del balanceador de cargas, que incluye el estado de todos los extremos en el NEG. Cuando la condición de la verificación de estado del balanceador de cargas indica que el extremo correspondiente a un pod en particular está en buen estado, el controlador Ingress establece el valor de puerta de preparación del pod en True.
El kubelet que se ejecuta en cada nodo calcula la preparación efectiva del Pod, y considera el valor de esta puerta de preparación y el sondeo de preparación del Pod, si está definido.
Las puertasde embarque de preparación de Pods se habilitan de forma automática cuando se usa el balanceo de cargas nativo del contenedor a través de Ingress.
Las puertas de preparación controlan la velocidad de una actualización progresiva. Cuando inicias una actualización progresiva, a medida que GKE crea pods nuevos, se agrega un extremo para cada pod nuevo a un NEG. Cuando el extremo está en buen estado desde la perspectiva del balanceador de cargas, el controlador de Ingress establece la puerta de preparación en True. Un pod recién creado debe pasar al menos su puerta de preparación antes de que GKE quite un pod anterior. Esto garantiza que el extremo correspondiente para el pod ya pasó la verificación de estado del balanceador de cargas y se mantiene la capacidad del backend.
Si la puerta de preparación de un pod nunca indica que el pod está listo, debido a una mala imagen del contenedor o una verificación de estado del balanceador de cargas mal configurado, el balanceador de cargas no dirigirá el tráfico al nuevo pod. Si se produce un error de este tipo cuando se lanza una implementación actualizada, el lanzamiento se detiene después de intentar crear un pod nuevo porque la puerta de preparación del pod nunca se establece en Verdadero. Consulta la sección de solución de problemas para obtener información sobre cómo detectar y solucionar esta situación.
Sin el balanceo de cargas nativo del contenedor y las puertas de preparación, GKE no puede detectar si los extremos de un balanceador de cargas están en buen estado antes de marcar pods como listos. En versiones anteriores de Kubernetes, tú controlas la velocidad con la que se quitan y reemplazan los pods si especificas un período de retraso (minReadySeconds en la especificación de implementación).
GKE establece el valor de cloud.google.com/load-balancer-neg-ready para un Pod en True si se cumple alguna de las siguientes condiciones:
- Ninguna de las direcciones IP del Pod son extremos en un NEG
GCE_VM_IP_PORTadministrado por el plano de control de GKE. - Una o más de las direcciones IP del pod son extremos en un NEG
GCE_VM_IP_PORTadministrado por el plano de control de GKE. El NEG se conecta a un servicio de backend. El servicio de backend tiene una verificación de estado del balanceador de cargas correcta. - Una o más de las direcciones IP del pod son extremos en un NEG
GCE_VM_IP_PORTadministrado por el plano de control de GKE. El NEG se conecta a un servicio de backend. Se agota el tiempo de espera de la verificación de estado del balanceador de cargas para el servicio de backend . - Una o más de las direcciones IP del Pod son extremos en uno o más NEG de
GCE_VM_IP_PORT. Ninguno de los NEG está vinculado a un servicio de backend. No hay datos disponibles sobre la verificación de estado del balanceador de cargas.
Compatibilidad con WebSocket
Con los balanceadores de cargas de aplicaciones externos, el protocolo WebSocket funciona sin que tengas que configurarlo.
Si planeas usar el protocolo WebSocket, es posible que quieras usar un valor de tiempo de espera mayor que los 30 segundos predeterminados. Para el tráfico de WebSocket enviado a través de un balanceador de cargas de aplicaciones externoGoogle Cloud , el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión de WebSocket puede permanecer abierta, ya sea que esté activa o no.
Para establecer el valor de tiempo de espera de un servicio de backend, consulta Tiempo de espera de la respuesta del backend.
Situaciones avanzadas de redes
Ingress de GKE admite configuraciones de redes avanzadas, como compartir recursos de red entre proyectos y usar controladores de Ingress personalizados.
VPC compartida
Los recursos de Ingress y MultiClusterIngress son compatibles con la VPC compartida, pero requieren una preparación adicional.
El controlador de Ingress se ejecuta en el plano de control de GKE y realiza llamadas a la API a Google Cloud con la cuenta de servicio de GKE del proyecto del clúster. De forma predeterminada, cuando un clúster ubicado en un proyecto de servicio de VPC compartida usa una red de VPC compartida, el controlador de Ingress no puede usar la cuenta de servicio de GKE del proyecto de servicio para crear y actualizar las reglas de firewall de permiso de entrada en el proyecto host.
Puedes otorgar los permisos de la cuenta de servicio de GKE del proyecto de servicio para crear y administrar las reglas de firewall de VPC en el proyecto host. Si otorgas estos permisos, GKE crea reglas de firewall de permiso de entrada para lo siguiente:
Proxies de Google Front End (GFE) y sistemas de verificación de estado que usan los balanceadores de cargas de aplicaciones externos para Ingress externo. Para obtener más información, consulta la descripción general del balanceador de cargas de aplicaciones externo.
Sistemas de verificación de estado para balanceadores de cargas de aplicaciones internos que usa Ingress interno.
Aprovisiona de forma manual las reglas de firewall del proyecto host
Si tus políticas de seguridad solo permiten la administración de firewall del proyecto host, puedes aprovisionar estas reglas de firewall de forma manual. Cuando implementas Ingress en una VPC compartida, el evento de recursos de Ingress proporciona la regla de firewall específica que es necesaria para brindar acceso.
Para aprovisionar una regla de forma manual, haz lo siguiente:
Ve el evento de recursos Ingress:
kubectl describe ingress INGRESS_NAMEReemplaza INGRESS_NAME por el nombre de tu Ingress.
Deberías ver un resultado similar al siguiente:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 9m34s (x237 over 38h) loadbalancer-controller Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`La regla de firewall requerida y sugerida aparece en la columna
Message.Copia y aplica las reglas de firewall sugeridas desde el proyecto host. La aplicación de la regla proporciona acceso a los Pods desde el balanceador de cargas y los verificadores de estado deGoogle Cloud .
Otorga permiso al controlador de Ingress para administrar las reglas de firewall del proyecto host
Si deseas que un clúster de GKE en un proyecto de servicio cree y administre los recursos de firewall en tu proyecto host, a la cuenta de servicio de GKE del proyecto de servicio se le debe otorgar los permisos de IAM adecuados mediante una de las siguientes estrategias:
Otorga a la cuenta de servicio de GKE del proyecto de servicio el rol de administrador de seguridad de Compute al proyecto host. En el siguiente ejemplo, se muestra esta estrategia.
Para un enfoque más detallado, crea un rol de IAM personalizado que incluya solo los siguientes permisos:
compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.deleteycompute.subnetworks.list. Otorga a la cuenta de servicio de GKE del proyecto de servicio esa función personalizada para el proyecto host.
Si tienes clústeres en más de un proyecto de servicio, debes elegir una de las estrategias y repetirla para la cuenta de servicio de GKE del proyecto de servicio.
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
Reemplaza lo siguiente:
HOST_PROJECT_ID: El ID del proyecto del proyecto host de VPC compartidaSERVICE_PROJECT_NUMBER: El número de proyecto del proyecto de servicio que contiene el clúster.
Usar un controlador de Ingress personalizado
Puedes ejecutar un controlador de Ingress personalizado si inhabilitas el complemento HttpLoadBalancing. Esto evita que el controlador de Ingress de GKE procese los recursos de Ingress.
Si deseas ejecutar un controlador de Ingress personalizado con el complemento HttpLoadBalancing habilitado, por ejemplo, para usar funciones como la subconfiguración y Private Service Connect, puedes usar uno de los siguientes enfoques:
- En el manifiesto de Ingress, configura la anotación
kubernetes.io/ingress.class. Esta configuración es compatible con clústeres que ejecutan todas las versiones de GKE. - Configura el campo
ingressClassName. - Configura una clase de Ingress predeterminada.
Debes asegurarte de que spec.ingressClassName no reemplace accidentalmente a ningún proceso. Una operación de actualización que cambia spec.IngressClassName de un valor válido a una string vacía ("") hace que el controlador de Ingress de GKE procese el Ingress.
Configura el campo ingressClassName
Puedes usar un controlador de Ingress personalizado si configuras el campo ingressClassName en el manifiesto de Ingress. En el siguiente manifiesto, se describe un Ingress que especifica el controlador de Ingress cilium:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
spec:
ingressClassName: cilium
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
Configura una clase de Ingress predeterminada
Puedes configurar una clase de Ingress predeterminada para todos los recursos Ingress en un clúster si creas un recurso IngressClass con la anotación ingressclass.kubernetes.io/is-default-class configurada como true:
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: gce
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: k8s.io/ingress-gce
Resumen del comportamiento del controlador de Ingress de GKE
Para los clústeres que ejecutan versiones 1.18 y posteriores de GKE, sin importar si el controlador de Ingress de GKE procesa un Ingress depende del valor de la anotación kubernetes.io/ingress.class y del campo ingressClassName en el manifiesto de Ingress. Para obtener más información, consulta Comportamiento del controlador de Ingress de GKE.
Plantillas para la configuración de Ingress
- En Recetas de herramientas de redes de GKE, puedes encontrar plantillas que proporciona GKE que son utilizadas bastante en Ingress en la sección Ingress.