Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Versiones disponibles

Soluciona problemas de creación y actualización de clústeres

En esta página, se muestra cómo investigar problemas relacionados con la creación, actualización y cambio de tamaño de clústeres en clústeres de Anthos alojados en VMware (GKE On-Prem).

Comportamiento de registro predeterminado de `gkectl` y `gkeadm`

Para gkectl y gkeadm, basta con usar la configuración de registro predeterminada:

Para gkectl, el archivo de registro predeterminado es /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log y el archivo está vinculado con un symlink con el archivo logs/gkectl-$(date).log en el directorio local en el que ejecutas gkectl.
Para gkeadm, el archivo de registro predeterminado es logs/gkeadm-$(date).log en el directorio local en el que ejecutas gkeadm.
El nivel de verbosidad -v5 predeterminado cubre todas las entradas de registro que necesita el equipo de asistencia al cliente.

El archivo de registro incluye el comando que se ejecutó y el mensaje de error.

Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.

Especifica ubicaciones no predeterminadas para archivos de registro

A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl, usa la marca --log_file. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.

A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm, usa la marca --log_file.

Ubica los registros de la API de clúster en el clúster de administrador

Si una VM no se inicia después de que comienza el plano de control del administrador, puedes investigar el problema mediante la inspección de los registros del Pod de controladores de la API de clúster en el clúster de administrador.

Busca el nombre del Pod de controladores de la API de clúster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

Ver registros de vsphere-controller-manager. Comienza por especificar el Pod, pero no el contenedor:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

El resultado te indica que debes especificar un contenedor y que proporciona los nombres de los contenedores en el Pod. Por ejemplo:

... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

Elige un contenedor y consulta sus registros:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Usa `govc` para resolver problemas con vSphere

Puedes usar govc para investigar problemas con vSphere. Por ejemplo, puedes confirmar los permisos y el acceso de tus cuentas de usuario de vCenter y recopilar registros de vSphere.

Depura mediante los registros del clúster de arranque

Durante la instalación, los clústeres de Anthos alojados en VMware crean un clúster de arranque temporal. Después de una instalación correcta, los clústeres de Anthos alojados en VMware borran el clúster de arranque, por lo que solo tienes el clúster de administrador y el de usuario. Por lo general, no deberías tener motivos para interactuar con el clúster de arranque.

Si pasas --cleanup-external-cliuster=false a gkectl create cluster, el clúster de arranque no se borrará y podrás usar sus registros para depurar problemas de instalación.

Busca los nombres de Pods que se ejecutan en el espacio de nombres kube-system:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Visualiza los registros de un Pod:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

Cambia el certificado de vCenter

Si ejecutas vCenter Server en modo de evaluación o de configuración predeterminado y tiene un certificado TLS generado, este certificado puede cambiar con el tiempo. Si cambió, debes informar a tus clústeres en ejecución sobre el certificado nuevo:

Recupera el nuevo certificado de vCenter y descomprímelo:
```
curl -k -o certs.zip https://VCENTER_IP_ADDRESS/certs/download.zip
unzip certs.zip
```
La marca -k admite certificados desconocidos. Esto sirve para evitar cualquier problema de certificado que tengas cuando accedas a vCenter.
Guarda el certificado de Linux en un archivo llamado vcenter-ca.pem:
```
cat certs/lin/*.0 > vcenter-ca.pem
```
En el archivo de configuración del clúster de administrador, establece vCenter.caCertPath en la ruta de acceso de tu archivo vcenter-ca.pem nuevo.
Usa SSH para conectarte al nodo de plano de control de tu clúster de administrador.

En el nodo, reemplaza el contenido de /etc/vsphere/certificate/ca.crt por el contenido de vcenter.pem.

Sal de tu conexión SSH.

Borra los ConfigMaps de vcenter-ca-certificate. Hay uno en el espacio de nombres kube-system y otro en cada espacio de nombres del clúster del usuario. Por ejemplo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace kube-system
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace user-cluster1

Crea ConfigMaps nuevos con el certificado nuevo. Por ejemplo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -

Para reiniciar el contenedor que contiene los Pods estáticos en el plano de control del administrador, haz lo siguiente:
- Establece una conexión SSH a la VM principal del administrador.
- Ejecuta docker restart.
A continuación, actualiza los datos del certificado de CA en el secreto create-config de administración.
- Obtén el secreto y decodifica el valor data.cfg del resultado:
```
kubectl get secret create-config -n kube-system -o jsonpath={.data.cfg} | base64 -d > admin-create-config.yaml
```
  `
- Compara el valor de admincluster.spec.cluster.vsphere.cacertdata con el nuevo certificado de CA de vCenter.
- Si los dos valores son diferentes, debes editar el secreto create-config de administración para agregar el nuevo certificado de CA. En el archivo admin-create-config.yaml, copia el resultado de la decodificación de base-64 y reemplaza el valor de admincluster.spec.cluster.vsphere.cacertdata por el certificado de CA de vCenter nuevo.
- Codifica el valor del paso anterior: cat admin-create-config.yaml | base64 -w0 > admin-create-config.b64
- Edita el secreto create-config y reemplaza el valor data.cfg por el valor codificado:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n kube-system create-config
```
Ahora, actualiza los datos del certificado de CA en los secretos de create-config para los clústeres de usuario.

Edita el secreto de create-config y reemplaza el valor data.cfg por el valor codificado en base64 que creaste en el paso anterior. Por ejemplo:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n user-cluster-1 create-config
```

Borra los siguientes Pods en los clústeres de usuario.

clusterapi-controllers
kube-controller-manager
kube-apiserver
vsphere-csi-controller
vsphere-metrics-exporter

Para obtener los nombres de los Pods, ejecuta este código:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep clusterapi
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-controller-manager
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-apiserver
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-csi-controller
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-metrics-exporter

Borra los Pods que encontraste en el paso anterior:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace NAMESPACE \
    delete pod POD_NAME

Cuando los Pods se reinicien, usarán el certificado nuevo.

Depura problemas de BIG-IP de F5 mediante el archivo kubeconfig interno

Después de una instalación, los clústeres de Anthos alojados en VMware generan un archivo kubeconfig en el directorio principal de la estación de trabajo de administrador, llamado internal-cluster-kubeconfig-debug. Este archivo kubeconfig es idéntico a tu archivo kubeconfig del clúster de administrador, excepto que apunta directamente al nodo del plano de control del clúster de administrador, en el que se ejecuta el servidor de API de Kubernetes. Puedes usar el archivo internal-cluster-kubeconfig-debug para depurar los problemas de BIG-IP de F5.

El cambio de tamaño de un clúster de usuario falla

Si un cambio de tamaño de un clúster de usuario falla, haz lo siguiente:

Busca los nombres de las MachineDeployments y las máquinas:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Describe una MachineDeployment para ver sus registros:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

Verifica si hay errores en máquinas recién creadas:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

No se pueden asignar direcciones para cambiar el tamaño de un clúster

Este problema ocurre si no hay suficientes direcciones IP disponibles para cambiar el tamaño de un clúster de usuarios.

kubectl describe machine muestra el siguiente error:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Para resolver este problema, asigna más direcciones IP para el clúster. Luego, borra la máquina afectada:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

Los clústeres de Anthos alojados en VMware crean una máquina nueva y le asignan una de las direcciones IP recién disponibles.

Hay una cantidad suficiente de direcciones IP asignadas, pero la máquina no se registra con el clúster

Este problema puede ocurrir si hay un conflicto de direcciones IP. Por ejemplo, se usa una dirección IP que especificaste para una máquina en un balanceador de cargas.

Para resolver este problema, actualiza tu archivo de bloque de IP del clúster a fin de que las direcciones de la máquina no entren en conflicto con las direcciones especificadas en el archivo de configuración del clúster o con tu archivo de bloque de IP de Seesaw.

La instantánea se crea automáticamente cuando falla la creación o actualización del clúster de administrador

Si intentas crear o actualizar un clúster de administrador y esa operación falla, los clústeres de Anthos alojados en VMware toman una instantánea externa del clúster de arranque, que es un clúster transitorio que se usa para crear o actualizar el clúster de administrador. Aunque esta instantánea del clúster de arranque es similar a la instantánea tomada mediante la ejecución del comando gkectl diagnose snapshot en el clúster de administrador, en su lugar se activa de forma automática. Esta instantánea del clúster de arranque contiene información importante de depuración para el proceso de creación y actualización del clúster de administrador. Puedes proporcionar esta instantánea a la Asistencia de Google Cloud, si es necesario.

El proceso de actualización se atasca

Los clústeres de Anthos alojados en VMware, en segundo plano, usan el comando drain de Kubernetes durante una actualización. Un Deployment puede bloquear este procedimiento drain con una sola réplica que tenga un PodDisruptionBudget (PDB) creado para él con minAvailable: 1.

En ese caso, guarda el PDB y quítalo del clúster antes de intentar la actualización. Luego, puedes volver a agregar el PDB después de que se complete la actualización.