El controlador de Ingress de Anthos administra los recursos de Compute Engine. Los recursos MultiClusterIngress (MCI) y MultiClusterService (MCS) se asignan a diferentes recursos de Compute Engine, por lo que comprender la relación entre estos recursos te ayuda a solucionar problemas. Por ejemplo, examina el siguiente recurso MCI:
apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
name: foo-ingress
spec:
rules:
- host: store.foo.com
http:
paths:
- backend:
serviceName: store-foo
servicePort: 80
- host: search.foo.com
http:
paths:
- backend:
serviceName: search-foo
servicePort: 80
Asignación de recursos de Compute Engine a Ingress for Anthos
En la siguiente tabla, se muestra el mapeo de los recursos de entorno a los recursos creados en los clústeres de Kubernetes y Google Cloud:
| Recurso de Kubernetes | Recurso de Google Cloud | Descripción |
|---|---|---|
| MultiClusterIngress | Regla de reenvío | VIP de balanceador de cargas de HTTP(S) |
| Proxy de destino | Configuración de las interrupciones de HTTP/S extraída de las anotaciones y del bloque de TLS | |
| Mapa de URL | Asignación de la ruta de host virtual desde la sección de reglas. | |
| MultiClusterService | Service de Kubernetes | Recurso derivado de la plantilla. |
| Servicio de backend | Se crea un servicio de backend para cada par (Service, ServicePort). | |
| Grupos de extremos de red | Conjunto de pods de backend que participan en el Service. |
En el siguiente diagrama, se muestra la relación entre MCI y MCS, y los recursos del balanceador de cargas de Compute Engine en dos clústeres miembros:
Inspecciona los recursos del balanceador de cargas de Compute Engine
Después de crear un balanceador de cargas, el estado de Ingress contendrá los nombres de cada recurso de Compute Engine que se creó para construir el balanceador de cargas. Por ejemplo:
Name: shopping-service
Namespace: prod
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1beta1
Kind: MultiClusterIngress
Metadata:
Creation Timestamp: 2019-07-16T17:23:14Z
Finalizers:
mci.finalizer.networking.gke.io
Spec:
Template:
Spec:
Backend:
Service Name: shopping-service
Service Port: 80
Status:
VIP: 34.102.212.68
CloudResources:
Firewalls: "mci-l7"
ForwardingRules: "mci-abcdef-myforwardingrule"
TargetProxies: "mci-abcdef-mytargetproxy"
UrlMap: "mci-abcdef-myurlmap"
HealthChecks: "mci-abcdef-80-myhealthcheck"
BackendServices: "mci-abcdef-80-mybackendservice"
NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"
No se creó la VIP
Si no ves una VIP, es posible que se haya producido un error durante su creación. Para descubrir si se produjo un error, ejecuta el siguiente comando:
kubectl describe mci shopping-service
Es posible que el resultado sea similar a este:
Name: shopping-service
Namespace: prod
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1beta1
Kind: MultiClusterIngress
Metadata:
Creation Timestamp: 2019-07-16T17:23:14Z
Finalizers:
mci.finalizer.networking.gke.io
Spec:
Template:
Spec:
Backend:
Service Name: shopping-service
Service Port: 80
Status:
VIP: 34.102.212.68
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning SYNC 29s multi-cluster-ingress-controller error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist
En este ejemplo, el error fue que el usuario no creó un recurso MultiClusterService con un recurso MultiClusterIngress que hiciera referencia a él.
En la mayoría de los casos, el mensaje de error indica el problema subyacente. Si no es así, comunícate con gke-mci-feedback@google.com para obtener ayuda.
Respuesta 502
Si tu balanceador de cargas adquirió una VIP, pero entrega de forma continua una respuesta 502, es posible que haya un error en las verificaciones de estado del balanceador de cargas. Las verificaciones de estado pueden fallar por dos motivos:
- Los pods de la aplicación no están en buen estado (consulta la depuración de Cloud Console para obtener un ejemplo).
- Un firewall mal configurado impide que los verificadores de estado de Google realicen verificaciones de estado.
En el caso n.º 1, asegúrate de que tu aplicación entregue una respuesta 200 en la ruta “/”.
En el caso n.º 2, asegúrate de que exista un firewall llamado “mci-default-l7” en tu VPC. El controlador de Ingress crea el firewall en tu VPC para garantizar que los verificadores de estado de Google puedan acceder a tus backends. Si el firewall no existe, asegúrate de que no haya automatización externa que lo borre cuando se cree.
No se agregó ni se quitó tráfico del clúster
Cuando se agrega una membresía nueva, el tráfico debe acceder a los backends en el clúster subyacente cuando corresponda. Del mismo modo, si se quita una membresía, el tráfico no debe acceder a los backends del clúster subyacente. Si no notas que este comportamiento no se produce, verifica si hay errores en los recursos MultiClusterIngress y MultiClusterService.
Dentro de los casos usuales en los que se produce este error, se incluyen los siguientes: cuando se agrega una membresía nueva en un clúster de GKE que no está en modo nativo de VPC o cuando se agrega una membresía nueva, pero no se implementa una aplicación en el clúster de GKE.
Describe el recurso
MultiClusterService:kubectl describe mcs zone-svcDescribe el recurso
MultiClusterIngress:kubectl describe mci zone-mci
Si los comandos anteriores no revelan el error, comunícate con gke-mci-feedback@google.com para obtener ayuda.
Migración del clúster de configuración
Para obtener más información sobre los casos prácticos de migración, consulta el concepto de diseño del clúster de configuración.
La migración de un clúster de configuración puede generar interrupciones si no se maneja de forma correcta. Sigue estos lineamientos cuando realices una migración de clúster de configuración:
- Asegúrate de usar la anotación static-ip en los recursos MCI. De lo contrario, el tráfico se interrumpirá durante la migración. Se volverán a crear IP efímeras cuando se migren los clústeres de configuración.
- Los recursos
MultiClusterIngressyMultiClusterServicedeben implementarse de forma idéntica en el clúster de configuración existente y en el nuevo. Si hay diferencias entre ambos, se conciliarán recursos MCS y MCI distintos en el clúster de configuración nuevo. - Solo hay un clúster de configuración activo a la vez. Los recursos MCI y MCS en el nuevo clúster de configuración no afectarán los recursos del balanceador de cargas hasta que se cambie el clúster de configuración.
Para migrar el clúster de configuración, ejecuta el siguiente comando:
gcloud alpha container hub ingress update \
--config-membership=projects/project_id/locations/global/memberships/new_config_cluster
Verifica que el comando funcionó. Para ello, asegúrate de que no haya errores visibles en el estado de la función:
gcloud alpha container hub ingress describe
Depuración de Console
En la mayoría de los casos, es útil verificar el estado exacto del balanceador de cargas cuando se depura un problema. Para encontrar el balanceador de cargas, dirígete a Balanceo de cargas en Google Cloud Console.
Códigos de error y advertencia
Ingress for Anthos emite códigos de error y advertencia en los recursos MCI y MCS y en el campo Descripción de multiclusteringress de gcloud para problemas conocidos.
Estos mensajes tienen códigos de error y advertencia documentados para que sea más fácil comprender lo que sucede cuando algo no funciona como se espera. Cada código consta de un ID de error en el formato AVMBR123, en el que 123 es un número único que corresponde a un error o una advertencia, junto con sugerencias sobre cómo se puede resolver.
AVMBR101: “No se reconoció la anotación [NAME]”
Este error aparece cuando se especifica una anotación en una especificación de MCI y MCS que no se reconoce. Existen dos razones por las que es posible que no se reconozca la anotación:
La anotación no es compatible con Ingress for Anthos. Esto puede suceder si se anotan recursos que no se prevee que use el controlador de Ingress de Anthos.
La anotación es compatible, pero está mal escrita y, por lo tanto, no se reconoce.
En ambos casos, consulta la documentación para descubrir las anotaciones compatibles y cómo se especifican.
AVMBR102: “No se encontró [RESOURCE_NAME]”
Este error aparece cuando se especifica un recurso complementario en un MCI, pero no se lo encuentra en el archivo de configuración de la membresía. Por ejemplo, este error se produce cuando un MCI hace referencia a un MCS que no se puede encontrar o cuando un MCS hace referencia a un BackendConfig que no se puede encontrar. Existen dos razones por las que no se pudo encontrar un recurso:
- No se encuentra en el espacio de nombres adecuado. Asegúrate de que los recursos que hacen referencia entre sí estén en el mismo espacio de nombres.
- El nombre del recurso está mal escrito.
- El recurso no existe con el espacio de nombres y el nombre adecuados. En este caso, créalo.
AVMBR103: “[CLUSTER_SELECTOR] no es válido”
Este error aparece cuando un selector de clúster especificado en un MCS no es válido. Existen dos razones por las que este selector puede no ser válido:
- La string que se proporcionó contiene un error tipográfico.
- La string que se proporcionó hace referencia a una membresía que ya no existe en el entorno.
AVMBR104: “No se pueden encontrar NEG para el puerto de servicio [SERVICE_PORT]”
Este error se produce cuando no se puede encontrar el NetworkEndpointGroup (NEG) para un servicio y par de puerto de MultiClusterService en particular. Los NEG son los recursos que contienen los extremos del pod en cada uno de tus clústeres de backend. El motivo principal por el que es posible que los NEG no existan es que se produjo un error durante la creación o actualización de los servicios derivados en tus clústeres de backend. Revisa los eventos en el recurso MultiClusterService para obtener más información.
AVMBR105: “Falta la licencia de Anthos”.
Este error se muestra en Estado de función y, además, indica que no está habilitada la API de Anthos (anthos.googleapis.com).
AVMBR106: “El servicio derivado no es válido: [REASON]”.
Este error se muestra en los eventos del recurso MultiClusterService. Una razón común para este error es que el recurso Service derivado de MultiClusterService tiene una especificación no válida.
Por ejemplo, esta MultiClusterService no tiene ninguna ServicePort definida en su especificación.
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: zone-mcs
namespace: zoneprinter
spec:
clusters:
- link: "us-central1-a/gke-us"
- link: "europe-west1-c/gke-eu"
AVMBR107: “Falta el vínculo del recurso del clúster de GKE en la membresía”.
Este error se muestra en Estado de función y se produce porque no hay un clúster de GKE subyacente en el recurso de la membresía. Para verificarlo, ejecuta el siguiente comando:
gcloud container hub memberships describe membership-name
Debes asegurarte de que no haya un vínculo de un recurso del clúster de GKE en el campo de extremo.
AVMBR108: “No se encontró el clúster de GKE [NAME]”.
Este error se muestra en Estado de función y se genera si la membresía no tiene un clúster de GKE subyacente.
AVMBR109: “[NAME] no es un clúster de GKE nativo de VPC”.
Este error se muestra en Estado de función. Se produce si el clúster de GKE especificado es un clúster basado en rutas. El controlador Ingress para Anthos crea un balanceador de cargas nativo del contenedor con NEG. Los clústeres deben ser nativos de VPC para usar un balanceador de cargas nativo del contenedor.
Para obtener más información, consulta Crea un clúster nativo de la VPC.
AVMBR110: “Falta el permiso [IAM_PERMISSION] para el clúster de GKE [NAME]”.
Este error se muestra en Estado de función. Existen dos motivos para este error:
- El clúster de GKE subyacente para la membresía se encuentra ubicado en un proyecto diferente al de la membresía.
- Se quitó el permiso de IAM especificado del agente de servicio de
MultiClusterIngress.
AVMBR111: “No se pudo obtener el archivo de configuración de la membresía: [REASON]”.
Este error se muestra en Estado de función. El motivo principal por el que se produce este error es que la membresía de configuración se borró mientras la función estaba habilitada.
Nunca deberías necesitar borrar el archivo de configuración de la membresía. Si deseas cambiarlo, sigue los pasos para configurar la migración del clúster.
AVMBR112: “El complemento HTTPLoadBalancing está inhabilitado en el clúster de GKE [NAME]”.
Este error se muestra en Estado de función y se produce cuando el complemento HTTPLoadBalancing está inhabilitado en un clúster de GKE. Puedes actualizar el clúster de GKE para habilitar el complemento HTTPLoadBalancing.
gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED
AVMBR113: “Este recurso está huérfano”.
En algunos casos, la utilidad de un recurso depende de que otro recurso haga referencia a él. Este error se produce cuando se crea un recurso de Kubernetes, pero otro recurso no hace referencia a él. Por ejemplo, aparecerá si creas un recurso BackendConfig al que no se hace referencia en MultiClusterService.