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 archivologs/gkectl-$(date).log
en el directorio local en el que ejecutasgkectl
.Para
gkeadm
, el archivo de registro predeterminado eslogs/gkeadm-$(date).log
en el directorio local en el que ejecutasgkeadm
.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 archivovcenter-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 devcenter.pem
.Sal de tu conexión SSH.
Borra los ConfigMaps de
vcenter-ca-certificate
. Hay uno en el espacio de nombreskube-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
- Obtén el secreto y decodifica el valor data.cfg del resultado:
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.