Problemas de instalación del modo privado de Anthos

En esta página, se describe cómo solucionar problemas que podrían surgir durante la instalación o actualización del modo privado de Anthos.

Requisitos previos para la solución de problemas

El modo privado de Anthos requiere un acceso a una estación de trabajo de administrador para que puedas comenzar a solucionar problemas. Para acceder a la estación de trabajo de administrador, ejecuta el siguiente comando:

ssh <USERNAME>@<WORKSTATION>
cd ./anthos-baremetal-private-mode
export PATH=$PWD/bin:$PATH

Nota: El comando SSH exacto puede variar según el entorno.

Crear clúster

En esta sección, se explica cómo solucionar problemas relacionados con la creación de clústeres del modo privado de Anthos.

Error en la creación del clúster de administrador

En esta sección, se enumeran los errores comunes de configuración del clúster de administrador y las comprobaciones previas, y se sugiere cómo solucionarlos.

Errores de configuración

Los problemas comunes de configuración del clúster de administrador incluyen una anotación faltante en la configuración, ninguna configuración de autenticación para el registro y un error en la creación del clúster de arranque.

Anotación faltante en el archivo de configuración

Si durante la creación de los recursos del grupo de nodos, tu archivo de configuración no incluye una anotación, es posible que veas el siguiente error:

Cluster.baremetal.cluster.gke.io "admin" is invalid: [Spec.LoadBalancer.AddressPools: Forbidden: Field not allowed for admin clusters, Spec.GKEConnect: Required value: Field is required].

Para solucionar este problema, agrega una anotación al archivo de configuración del clúster de administrador y establece la anotación en true:

annotations:
    baremetal.cluster.gke.io/private-mode: "true"

Consulta Clúster de administrador y grupo de nodos para ver un ejemplo de una anotación aplicada en un archivo de configuración del clúster de administrador.

Configuración de autenticación faltante para el registro

Si falta la configuración de autenticación, es posible que veas el error no auth config found for the registry.

Asegúrate de que el pullCredentialConfigPath que se especifica en el archivo admin.yaml contenga la configuración de autenticación para el extremo. Por ejemplo, si el extremo es https://10.200.0.2 y pullCredentialConfigPath es /root/.docker/config.json, el archivo config.json tiene la siguiente entrada de autenticación:

{
        "auths": {
                "10.200.0.2": {
                        "auth": "<base64 encoded auth>"
                }
        }
}

Si la entrada de autenticación para el registro no está presente, actualiza el archivo config.json mediante el acceso al registro:

docker login <registry> -u <username> -p <password>

Crea un error de clúster de arranque

Puedes encontrar el siguiente error mientras creas tu clúster:

failed: error creating bootstrap cluster: failed to pull kind image kindest/node:v0.11.1-gke.7-v1.20.9-gke.101 from registry mirror(s)

Si ves el error cuando se crea el clúster de arranque, asegúrate de que todas las imágenes se suban al registro privado:

actl images push --private-registry=<registry>

Un comando de muestra se ve de la siguiente manera:

actl images push --private-registry=10.200.0.2/library

Fallas en la comprobación previa

Cuando creas el clúster de administrador en modo privado de Anthos, es posible que debas corregir una falla en la creación del clúster mediante errores de comprobación previa, creación de clústeres estancada o realizar alguna solución de problemas generales.

Falla de creación de clúster con errores de comprobación previa

Si la comprobación previa falló, es posible que veas el siguiente mensaje de error:

unable to create cluster: unable to create cluster: preflight check failed

El modo privado de Anthos recopila los registros de errores correspondientes en el directorio actl-workspace/admin/log/preflight-<timestamp>/, por ejemplo, actl-workspace/admin/log/preflight-20210907-205726/.

Para resolver el problema, verifica lo siguiente:

• Cada registro de nodo con errores en el archivo, llamado dirección IP del nodo
• Registros relacionados con la red en el archivo node-network

Según los datos de los registros, asegúrate de si hay errores evidentes, como los requisitos mínimos de la máquina no se cumplen o puertos en conflicto. Actualiza las máquinas y vuelve a intentarlo.

Creación de clústeres estancados

Si la creación de clústeres le lleva mucho tiempo, por ejemplo, más de 30 minutos a un clúster de tres nodos, revise el clúster de arranque local para ver si hay errores al extraer la imagen:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -A

Si los Pods tienen el estado ImagePullErr, asegúrate de que esas imágenes se suban al registro:

actl images push --private-registry=<registry>

Un comando de muestra se ve de la siguiente manera:

actl images push --private-registry=10.200.0.2/library

Si un trabajo de creación de clúster específico tiene un estado Error, verifica los registros del Pod correspondiente:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -n cluster-admin
kubectl --kubeconfig actl-workspace/.kindkubeconfig logs <pod-name> -n cluster-admin

Revisa los registros para ver si se pueden rectificar de forma manual algún error en la máquina. Puedes obtener errores adicionales de la máquina mediante el SSH para acceder a la máquina y la ejecución de journalctl --no-pager -l. Para asegurarte de que los servicios importantes funcionen, ejecuta el siguiente comando:

service containerd status
service kubelet status

journalctl -u containerd
journalctl -u kubelet

# If needed sudo systemctl restart <service> to fix issues.
# sudo service <service> restart
# e.g.,
# sudo service containerd restart

Problemas generales

A fin de solucionar problemas de un nodo en general, usa SSH para conectarte a un nodo y ejecuta el siguiente comando:

journalctl --no-pager -l

Revisa los registros en busca de errores.

Error en la creación del clúster

Usa SSH para conectarte a la máquina del plano de control y ver los Pods en el clúster:

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get po -A

Problemas de red

En esta sección, se explican los problemas más comunes relacionados con la red en el modo privado de Anthos y se enumeran los pasos para resolverlos.

• Para ver la conexión entre cada nodo y verificar los errores relacionados con la red, usa ip route.

• Cuando no se pueda acceder a la VIP del plano de control, usa SSH para conectarte a un nodo del plano de control y ejecuta lo siguiente:

  journalctl -u containerd --no-pager -l
  # Check the logs of those pods as well.
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf -n kube-system get po | grep -E "haproxy|keepalived"
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-haproxy | awk '{print $1}'`
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-keepalived | awk '{print $1}'`
  

  Este problema puede ocurrir si las imágenes keepalived y haproxy no se cargan en un registro privado.

• Solo úsalo después de una creación exitosa del clúster de administrador. Si no se puede acceder a las IP de servicio, verifica los registros de los Pods metallb:

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=controller -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=speaker -n kube-system
  

• Si todos los pods están estancados en la creación del contenedor, realiza una de las siguientes acciones:

  • Verifica la implementación de anetd-operator y los registros de anetd daemonset.

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l k8s-app=cilium -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l k8s-app=cilium -n kube-system
  

  • Si no se define una puerta de enlace predeterminada, es posible que iptables no funcione correctamente, por lo que el operador anetd puede no alcanzar el servidor kube-api.

  ip route add default via <some-ip>
  iptables-save -t nat
  iptables-save -t filter
  

• Intenta reiniciar el nodo para ver si se solucionó el problema.

Errores comunes

Los comandos kubectl no funcionan

Si no configuraste la herramienta de línea de comandos de kubectl para que se conecte a un servidor remoto de la API de Kubernetes, verás el siguiente mensaje de error:

$ kubectl ...
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Asegúrate de tener un kubeconfig configurado. Para ello, configura la variable de entorno KUBECONFIG o ejecuta los comandos con la marca --kubeconfig.
Por ejemplo, para configurar el kubeconfig del administrador, haz lo siguiente:

• Configura la variable de entorno en el kubeconfig del administrador:

export KUBECONFIG=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

• Usa la opción de línea de comandos kubeconfig:

kubectl --kubeconfig=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

Para obtener más detalles, consulta Organiza el acceso de clúster mediante archivos kubeconfig.

Error de creación del clúster de usuario

En tu estación de trabajo, para acceder al clúster de administrador y ver los Pods relacionados con el clúster de usuario, usa el siguiente comando:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get po -n cluster-CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre del clúster.

Si el clúster de usuario aún falla, intenta borrar un clúster de usuario y vuelve a aplicar la siguiente configuración:

# Delete user cluster
export ADMIN_KUBECONFIG=$(pwd)/actl-workspace/admin/admin-kubeconfig
export USER_CLUSTER_NAME=user-1
kubectl -n cluster-${USER_CLUSTER_NAME} delete Cluster $USER_CLUSTER_NAME --kubeconfig=${ADMIN_KUBECONFIG}

# Re-apply the user cluster YAML file
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f user.yaml

# Wait until client config ready and stored in the path "$(pwd)/${USER_CLUSTER_NAME}-kubeconfig"
export USER_KUBECONFIG=$(pwd)/${USER_CLUSTER_NAME}-kubeconfig
waittime="5 minutes"
endtime=$(date -ud "$waittime" +%s)
while ! KUBECONFIG=${ADMIN_KUBECONFIG} actl clusters baremetal get-credentials -c "${USER_CLUSTER_NAME}" -o "${USER_KUBECONFIG}"; do
  if [[ $endtime -le $(date -u +%s) ]]; then
    echo "Client config not ready in $waittime, terminating"
    exit 1
  fi
  echo "client config not ready, sleeping 30s"
  sleep 30
done

# Check the user cluster status until all nodes are ready
KUBECONFIG=${USER_KUBECONFIG} kubectl get nodes

Crea Centro de administración de Anthos

Recursos insuficientes en el clúster de administrador

El recurso personalizado AdminOperator configura la instalación de Centro de administración de Anthos. Para ver si el controlador tiene problemas para instalar el Centro de administración, consulta los eventos y registros de Google Kubernetes Engine de este recurso y controlador personalizados:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe adminoperator admin-operator
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -n anthos-management-center-operator -l control-plane=admin-operator

Errores de extracción de imágenes

Iniciar Pods en el clúster puede ocasionar problemas que impidan que AdminOperator informe de forma correcta.

# Get all pods that aren't in a Running state or have succeeded.
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods --field-selector=status.phase!=Running,status.phase!=Succeeded -A

# Examine the pods of interest that are failing...
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe pod --namespace [NAMESPACE] [POD_OF_INTEREST]

Actualizar

Anthos en equipos físicos

Para obtener detalles sobre cómo solucionar problemas relacionados con una actualización de Anthos en equipos físicos, consulta Recupera una actualización con errores en Anthos en equipos físicos.

Nota: En el caso de los clústeres de modo privado de Anthos, debes reemplazar el comando bmctl por actl cuando apliques correcciones para Anthos en el equipo físico. Por ejemplo, usa actl clusters baremetal upgrade en lugar de bmctl upgrade cluster.

Centro de administración de Anthos

Para comprobar la versión del componente instalado, usa lo siguiente:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get adminoperator admin-operator -o yaml

Este es un ejemplo del resultado:

apiVersion: managementcenter.anthos.cloud.google.com/v1
kind: AdminOperator
spec:
  updateConfigOverride:
    policies:
    - name: anthos-config-management
      versionConstraint: <=1.8.0-gke.0
status:
  components:
  - name: anthos-bare-metal
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-config-management
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-service-mesh
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  version: 1.8.0-gke.0

En un entorno de modo privado de Anthos implementado, el status.version en el objeto AdminOperator indica la versión de la versión del modo privado de Anthos.

Por ejemplo, 1.8.0-gke.0. status.components muestra el estado de la versión de cada componente. Enumera la versión observada y la restricción de versión para cada componente implementado.

status.version y status.components deben estar siempre disponibles; de lo contrario, la instalación se daña. spec.updateConfigOverride es opcional. Solo está presente si los operadores de infraestructura configuran el campo de forma manual para actualizar un componente específico. Cuando se omite el campo, todos los componentes se ejecutan en la misma versión que AdminOperator.

Verifica los paquetes en el centro de actualización

Solo los paquetes que se ofrecen en el centro de actualizaciones se implementan en el Centro de administración.

Por ejemplo, si primero instalas el clúster de administrador con la versión 1.8.0-gke.0 y, luego, actualizas a 1.8.1-gke.0, el centro de actualización contiene dos conjuntos de paquetes. Borrar el recurso UpdateItem de un componente de uso activo podría dañar la instalación del modo privado de Anthos.

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get updateitems -n anthos-management-center

Este es un ejemplo del resultado:

NAME                                  AGE
anthos-config-management-1.8.0-gke.0  13d
anthos-service-mesh-1.8.0-gke.0       13d

¿Qué sigue?

• Obtén más información sobre los problemas conocidos del modo privado de Anthos.