clústeres de Anthos alojados en VMware

10

Selecciona tus clústeres de Anthos alojados en VMware:

Selecciona la categoría del problema:

O busca tu problema:

Categoría Versiones identificadas Problema y solución alternativa
Herramientas de redes 1.13.0-1.13.2

Ciclo de fallas de calico-typha o de anetd-operator en nodos de Windows con Controlplane v2

Con Controlplane v2 o un nuevo modelo de instalación, calico-typha o anetd-operator pueden programarse en nodos de Windows y pueden entrar en un bucle de fallas.

El motivo es que las dos implementaciones toleran todos los taints, incluido el taint de nodo de Windows.


Solución alternativa:

Actualiza a la versión 1.13.3+ o ejecuta los siguientes comandos para editar la implementación `calico-typha` o `anetd-operator`:


    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

Quita los siguientes spec.template.spec.tolerations:


    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

Agregue la siguiente tolerancia:


    - key: node-role.kubernetes.io/master
      operator: Exists
Configuración 1.14.0-1.14.2

No se puede cargar el archivo de credenciales de registro privado del clúster de usuario

Es posible que no puedas crear un clúster de usuario si especificas la sección privateRegistry con la credencial fileRef. La comprobación previa podría fallar con el siguiente mensaje: 


[FAILURE] Docker registry access: Failed to login.


Solución alternativa:

  • Si no tenías la intención de especificar el campo o quieres usar la misma credencial de registro privado que el clúster de administrador, puedes quitar o comentar la sección privateRegistry del archivo de configuración del clúster de usuario.
  • Si deseas usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar de forma temporal la sección privateRegistry de esta manera: 
    
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
    (NOTA: Esta es solo una corrección temporal y estos campos ya dejaron de estar disponibles; considera usar el archivo de credenciales cuando actualices a la versión 1.14.3+).

Operations 1.10+

Anthos Service Mesh y otras mallas de servicio no son compatibles con Dataplane v2

Dataplane V2 se encarga del balanceo de cargas y crea un socket de kernel en lugar de una DNAT basada en paquetes. Esto significa que Anthos Service Mesh no puede realizar la inspección de paquetes, ya que el pod se omite y nunca usa IPTables.

Esto se manifiesta en el modo gratuito de kube-proxy por pérdida de conectividad o enrutamiento de tráfico incorrecto para los servicios con Anthos Service Mesh, ya que el archivo adicional no puede realizar la inspección de paquetes.

Este problema está presente en todas las versiones de clústeres de Anthos en Bare Metal 1.10; sin embargo, algunas versiones más recientes de 1.10 (1.10.2+) tienen una solución alternativa.


Solución alternativa:

Actualiza a la versión 1.11 para obtener compatibilidad total o, si ejecutas la versión 1.10.2 o posterior, ejecuta lo siguiente:


    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

Agrega bpf-lb-sock-hostns-only: true al ConfigMap y, luego, reinicia el daemon anetd:


      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Almacenamiento 1.12 + 1.13.3

kube-controller-manager podría desconectar volúmenes persistentes de manera forzada después de 6 minutos

kube-controller-manager puede agotar el tiempo de espera cuando se desconectan los PV/PVC después de 6 minutos y desconectarlo de manera forzada. En los registros detallados de kube-controller-manager, se muestran eventos similares a los siguientes:


$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

Para verificar el problema, accede al nodo y ejecuta los siguientes comandos:


# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

En el registro de kubelet, se muestran errores como los siguientes:


Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

Solución alternativa:

Conéctate al nodo afectado mediante SSH y reinícialo.
Revisiones y actualizaciones 1,12+, 1,13+, 1,14+

La actualización del clúster se detiene si se usa el controlador de CSI de terceros

Es posible que no puedas actualizar un clúster si usas un controlador de CSI de terceros. El comando gkectl cluster diagnose puede mostrar el siguiente error: 


"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


Solución alternativa:

Realiza la actualización mediante la opción --skip-validation-all.
Operación 1.10+, 1.11+, 1.12+, 1.13+ y 1.14+

gkectl repair admin-master crea la VM de administrador principal sin actualizar la versión de hardware de la VM.

El nodo principal del administrador creado a través de gkectl repair admin-master puede usar una versión de hardware de VM inferior a la esperada. Cuando ocurra el problema, verás el error en el informe gkectl diagnose cluster. 


CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


Solución alternativa:

Cierra el nodo principal del administrador, sigue https://kb.vmware.com/s/article/1003746 para actualizar el nodo a la versión esperada descrita en el mensaje de error y, luego, inicia el nodo.
Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+ y 1.14+

La VM libera la asignación de tiempo de DHCP al momento del apagado o el reinicio de forma inesperada, lo que puede generar cambios en la IP.

En systemv v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración de KeepConfiguration. Antes de este cambio, las VM no enviaban un mensaje de liberación de asignación de DHCP al servidor de DHCP durante el apagado o el reinicio. Después de este cambio, las VM envían un mensaje como este y muestran las IP al servidor de DHCP. Como resultado, la IP liberada se puede reasignar a una VM diferente o se puede asignar una IP diferente a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no a nivel de vSphere) o cambio de IP en las VM, lo que puede interrumpir los clústeres de varias maneras.

Por ejemplo, es posible que veas los siguientes síntomas.

  • La IU de vCenter muestra que ninguna VM usa la misma IP, pero kubectl get nodes -o wide muestra nodos con IP duplicadas. 
    
NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
  • No se pueden iniciar los nodos nuevos debido a un error calico-node 
    
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


Solución alternativa:

Implementa el siguiente DaemonSet en el clúster para revertir el cambio de comportamiento predeterminado de systemd-networkd. Las VM que ejecutan este DaemonSet no liberarán las IP del servidor DHCP durante el apagado o el reinicio. El servidor DHCP liberará automáticamente las IP cuando venzan las asignaciones. 


      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

Operación, actualizaciones y actualizaciones 1.12.0+, 1.13.0+ y 1.14.0+

La clave de la cuenta de servicio de acceso a los componentes se limpia después de que el clúster de administrador se actualiza de 1.11.x

Este problema solo afectará a los clústeres de administrador que se actualicen desde la versión 1.11.x y no afectará a los clústeres de administrador que se crearon después de 1.12.

Después de actualizar un clúster 1.11.x a 1.12.x, el campo component-access-sa-key del secreto admin-cluster-creds se limpiará para vaciarlo. Esto se puede verificar si ejecutas el siguiente comando: 


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds | grep 'component-access-sa-key'
Si el resultado está vacío, significa que la clave se está borrando.

Después de borrar la clave de la cuenta de servicio de acceso a los componentes, la instalación de clústeres de usuario nuevos o la actualización de clústeres de usuario existentes fallarán. A continuación, se enumeran algunos mensajes de error que puedes encontrar:

  • Error de verificación previa de validación lenta con el mensaje de error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
  • La preparación por gkectl prepare falló con el mensaje de error: "Failed to prepare OS images: dialing: unexpected end of JSON input"


Solución:

Vuelve a agregar la clave de cuenta de servicio de acceso a los componentes al secreto de forma manual. Para ello, ejecuta el siguiente comando: 


kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
Operación 1.13.0+, 1.14.0+

El escalador automático del clúster no funciona cuando está habilitado Controlplane V2

Para los clústeres de usuario creados con Controlplane V2 o un nuevo modelo de instalación, los grupos de nodos con el ajuste de escala automático habilitado siempre usan su autoscaling.minReplicas en user-cluster.yaml. El registro del pod del escalador automático del clúster también muestra que están en mal estado. 


  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
Puedes encontrar el pod del escalador automático de clústeres si ejecutas los siguientes comandos. 

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


Solución:

Inhabilita el ajuste de escala automático en todos los grupos de nodos con “gkectl update cluster” hasta actualizar a una versión con la corrección
Instalación 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

No se permite CIDR en el archivo de bloque de IP

Cuando los usuarios usen CIDR en el archivo de bloque de IP, la validación de configuración fallará con el siguiente error: 


- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


Solución:

Incluye las IP individuales en el archivo de bloque de IP hasta que actualices a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1+.
Revisiones y actualizaciones 1.14.0-1.14.1

La actualización del tipo de imagen de SO en admin-cluster.yaml no espera a que se vuelvan a crear las máquinas del plano de control del usuario

Cuando actualiza el tipo de imagen de SO del plano de control en admin-cluster.yaml y si el clúster de usuario correspondiente se creó a través de Controlplane V2, es posible que las máquinas del plano de control de usuario no vuelvan a crear una vez que finalice el comando gkectl.


Solución:

Una vez que finalice la actualización, supervisa los tipos de imágenes de SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide y continúa esperando que las máquinas del plano de control de usuario terminen la recreación. P.ej., si actualizas de Ubuntu a COS, debes esperar a que todas las máquinas del plano de control cambien por completo de Ubuntu a COS, incluso después de que se complete el comando de actualización.

Operación 1.14.0

Errores en la creación o eliminación del Pod debido a un problema de token de autenticación de la cuenta de servicio de la CNI Calico

Un problema con Calico en clústeres de Anthos alojados en VMware 1.14.0 hace que la creación y la eliminación de pods falle con el siguiente mensaje de error en el resultado de kubectl describe pods:


  error getting ClusterInformation: connection is unauthorized: Unauthorized

Este problema solo se observa 24 horas después de que se crea el clúster o se actualiza a la versión 1.14 mediante Calico.

Los clústeres de administrador siempre usan Calico, mientras que para los clústeres de usuario hay un campo de configuración `enableDataPlaneV2` en user-cluster.yaml. Si ese campo se establece en `false`, o no se especifica, significa que estás usando Calico en el clúster de usuario.

El contenedor install-cni de los nodos crea un kubeconfig con un token que es válido durante 24 horas. El pod calico-node debe renovar este token de forma periódica. El pod calico-node no puede renovar el token, ya que no tiene acceso al directorio que contiene el archivo kubeconfig en el nodo.


Solución alternativa:

Para mitigar el problema, aplica el siguiente parche en el DaemonSet de calico-node en tu clúster de administrador y de usuario:


  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Reemplaza lo siguiente:
  • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
  • USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.
Instalación 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

La validación del bloque de IP falla cuando se usa CIDR

La creación del clúster falla a pesar de que el usuario tenga la configuración adecuada. El usuario ve que la creación falla debido a que el clúster no tiene suficientes IP.


Solución:

Divide los CIDR en varios bloques más pequeños, como 10.0.0.0/30, que se convierte en 10.0.0.0/31, 10.0.0.2/31. Siempre que haya N+1 CIDR, donde N es la cantidad de nodos en el clúster, esto debería ser suficiente.

Operación, actualizaciones y actualizaciones 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

La copia de seguridad del clúster de administrador no incluye la configuración de las claves de encriptación de secretos siempre activas

Cuando la función de encriptación de secretos siempre activa está habilitada junto con la copia de seguridad de los clústeres, la copia de seguridad de los clústeres de administrador no puede incluir las claves ni la configuración que requiere la encriptación de secretos siempre activa. Como resultado, reparar la instancia principal del administrador con esta copia de seguridad mediante gkectl repair admin-master --restore-from-backup genera el siguiente error: 


Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

Operación, actualizaciones y actualizaciones 1.10+

Volver a crear la VM de administrador principal con un disco de arranque nuevo (p.ej., gkectl repair admin-master) fallará si la función de encriptación de secretos siempre activa está habilitada con el comando “gkectl update”.

Si la función de encriptación de secretos siempre activa no está habilitada en la creación del clúster, pero se habilita más tarde mediante la operación gkectl update, gkectl repair admin-master no podrá reparar el nodo del plano de control del clúster de administrador. Se recomienda que la función de encriptación de secretos siempre activa esté habilitada en la creación del clúster. Por el momento, no existe una mitigación.

Revisiones y actualizaciones 1.10

La actualización del primer clúster de usuario de 1.9 a 1.10 recrea los nodos en otros clústeres de usuario

Si actualizas el primer clúster de usuario de 1.9 a 1.10, es posible que los nodos de otros clústeres de usuario se vuelvan a crear en el mismo clúster de administrador. La recreación se realiza de manera progresiva.

Se quitó disk_label de MachineTemplate.spec.template.spec.providerSpec.machineVariables, lo que activó una actualización en todos los MachineDeployment de forma inesperada.


Solución alternativa:
Revisiones y actualizaciones 1.10.0

Docker se reinicia con frecuencia después de la actualización del clúster

Actualizar el clúster de usuario a 1.10.0 podría provocar que Docker se reinicie con frecuencia.

Para detectar este problema, ejecuta kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

Una condición de nodo mostrará si el Docker se reinicia con frecuencia. A continuación, se muestra un ejemplo de resultado:


Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

Para comprender la causa raíz, debes establecer una conexión SSH al nodo que tenga el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x


Solución alternativa:
Revisiones y actualizaciones 1.11 a 1.12

Los componentes de GMP implementados automáticamente no se conservan después de actualizar a la versión 1.12

Si usas clústeres de Anthos alojados en la versión de VMware 1.12 y configuraste de forma manual los componentes de Prometheus administrados por Google (GMP) en el espacio de nombres de gmp-system para el clúster, los componentes no se conservarán cuando actualices a la versión 1.12.x.

A partir de la versión 1.12, los componentes de GMP en el espacio de nombres gmp-system y las CRD se administran mediante el objeto stackdriver, con la marca enableGMPForApplications establecida en false de forma predeterminada. Si implementas de forma manual los componentes de GMP en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver borrará los recursos.


Solución alternativa:
Operación 1.11, 1.12, 1.13.0 - 1.13.1

Faltan objetos ClusterAPI en la situación de instantánea de clúster system

En la situación system, la instantánea del clúster no incluye ningún recurso en el espacio de nombres default.

Sin embargo, algunos recursos de Kubernetes, como los objetos de la API de clúster que se encuentran en este espacio de nombres, contienen información de depuración útil. La instantánea del clúster debe incluirlas.


Solución alternativa:

Puedes ejecutar de forma manual los siguientes comandos para recopilar la información de depuración.


export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
Donde:

USER_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de usuario.
Revisiones y actualizaciones 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

La eliminación del clúster de usuario se detuvo en el vaciado de nodos para la configuración de vSAN

Cuando se borra, actualiza o actualiza un clúster de usuario, el desvío de nodos puede detenerse en las siguientes situaciones:

  • El clúster de administrador usa el controlador de CSI de vSphere en vSAN desde la versión 1.12.x.
  • No hay objetos PVC/PV creados por complementos de vSphere en el árbol de clústeres de administrador y de usuario.

Para identificar el síntoma, ejecuta el siguiente comando:


kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

Aquí hay un mensaje de error de muestra del comando anterior:


E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

kubevols es el directorio predeterminado para el controlador en árbol de vSphere. Cuando no se crean objetos PVC/PV, es posible que se produzca un error que impedirá que el nodo se bloquee en la búsqueda de kubevols, ya que la implementación actual supone que kubevols siempre existe.


Solución alternativa:

Crea el directorio kubevols en el almacén de datos en el que se crea el nodo. Esto se define en el campo vCenter.datastore en los archivos user-cluster.yaml o admin-cluster.yaml.
Configuración 1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

Los clústeres de administrador cluster-health-controller y vsphere-metrics-exporter no funcionan después de borrar el clúster de usuario

En la eliminación del clúster de usuario, también se borra el clusterrole correspondiente, lo que provoca que el exportador de métricas de vSphere y la reparación automática no funcionen.

Los síntomas son los siguientes:

  • Registros cluster-health-controller
    • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
    En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de mensajes de error que pueden aparecer: 
    
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
  • Registros vsphere-metrics-exporter
    • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
    En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de mensajes de error que pueden aparecer: 
    
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

Solución alternativa:

Configuración 1.12.1-1.12.3, 1.13.0-1.13.2

gkectl check-config falla en la validación de imagen de SO

Un problema conocido que podría fallar en gkectl check-config sin ejecutar gkectl prepare. Esto es confuso porque sugerimos ejecutar el comando antes de ejecutar gkectl prepare

El síntoma es que el comando gkectl check-config fallará con el siguiente mensaje de error:


Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

Solución alternativa:

Opción 1: Ejecuta gkectl prepare para subir las imágenes de SO faltantes.

Opción 2: usa gkectl check-config --skip-validation-os-images para omitir la validación de imágenes de SO.
Revisiones y actualizaciones 1.11, 1.12, 1.13

gkectl update admin/cluster no pudo actualizar los grupos antiafinidad

Un problema conocido que podría fallar en gkectl update admin/cluster cuando se actualice anti affinity groups.

El síntoma es que el comando gkectl update fallará con el siguiente mensaje de error:


Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

Solución alternativa:
Instalación, actualizaciones y actualizaciones 1.13.0

Los nodos no se registran si el nombre de host configurado contiene un punto.

El registro de nodos falla durante la creación, la actualización, la actualización y la reparación automática de nodos cuando ipMode.type es static y el nombre de host configurado en el archivo de bloqueo de IP contiene uno o más puntos. En este caso, las solicitudes de firma de certificado (CSR) de un nodo no se aprueban de forma automática.

Para ver las CSR pendientes para un nodo, ejecuta el comando siguiente:


kubectl get csr -A -o wide

Revisa los siguientes registros para ver si hay mensajes de error:

  • Visualiza los registros en el clúster de administrador del contenedor clusterapi-controller-manager en el Pod clusterapi-controllers: 
    
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Para ver los mismos registros en el clúster de usuario, ejecuta el siguiente comando: 
    
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    En el ejemplo anterior, se ilustra lo siguiente:
    • ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
    • USER_CLUSTER_NAME es el nombre del clúster de usuario.
    Este es un ejemplo de mensajes de error que pueden aparecer: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
  • Visualiza los registros kubelet en el nodo problemático: 
    
journalctl --u kubelet
    A continuación, se muestra un ejemplo de mensajes de error que puedes ver: "Error getting node" err="node \"node-worker-vm-1\" not found"

Si especificas un nombre de dominio en el campo de nombre de host de un archivo de bloque de IP, se ignorarán los caracteres posteriores al primer período. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host de VM y el nombre de nodo se establecerán en bob-vm-1.

Cuando la verificación de ID de nodo está habilitada, el responsable de aprobación de CSR compara el nombre del nodo con el nombre de host en la especificación de la máquina y no concilia el nombre. El responsable de aprobación rechaza la CSR y el nodo no se inicia.


Solución alternativa:

Clúster de usuario

Para inhabilitar la verificación de ID del nodo, completa los siguientes pasos:

  1. Agrega los siguientes campos a tu archivo de configuración de clúster de usuario: 
    
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
  2. Guarda el archivo y actualiza el clúster de usuario mediante la ejecución del siguiente comando: 
    
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
    Reemplaza lo siguiente:
    • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
    • USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.

Clúster de administrador

  1. Abre el recurso personalizado OnPremAdminCluster para editarlo: 
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
  2. Agrega la siguiente anotación al recurso personalizado: 
    
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
  3. Edita el manifiesto kube-controller-manager en el plano de control del clúster de administrador:
    1. Establece una conexión SSH al nodo del plano de control del clúster de administrador.
    2. Abre el manifiesto kube-controller-manager para editarlo: 
      
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
    3. Busca la lista de controllers: 
      
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
    4. Actualiza esta sección como se muestra a continuación: 
      
--controllers=*,bootstrapsigner,tokencleaner
  4. Abre el controlador de la API de clúster de implementación para editarlo: 
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
  5. Cambia los valores de node-id-verification-enabled y node-id-verification-csr-signing-enabled a false: 
    
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
Instalación, actualizaciones y actualizaciones 1.11.0-1.11.4

Falla de inicio de la máquina del plano de control del administrador causada por el paquete de certificados del registro privado

La creación o actualización del clúster de administrador se bloquea en el siguiente registro de forma permanente y, con el tiempo, se agota el tiempo de espera:


Waiting for Machine gke-admin-master-xxxx to become ready...

El registro del controlador de la API de clúster en la instantánea del clúster externo incluye el siguiente registro:


Invalid value 'XXXX' specified for property startup-data

A continuación, se muestra un ejemplo de una ruta de acceso de archivo para el registro del controlador de la API de clúster:


kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.

    
Workaround:

    
Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.

    
Or upgrade to a version with the fix when available.
Herramientas de redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

Se marcó NetworkGatewayNodes como en mal estado debido a un conflicto de actualización de estado concurrente

En networkgatewaygroups.status.nodes, algunos nodos cambian entre NotHealthy y Up.

Los registros del pod ang-daemon que se ejecutan en ese nodo revelan errores repetidos: 


2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

El estado NotHealthy evita que el controlador asigne IP flotantes adicionales al nodo. Esto puede generar una carga mayor en otros nodos o una falta de redundancia para la alta disponibilidad.

De lo contrario, la actividad del plano de datos no se ve afectada.

La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a un error en el control de los reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager verá que el nodo superó el límite de tiempo de monitoreo de funcionamiento y marca el nodo NotHealthy.

El error en el control de reintentos se corrigió en versiones posteriores.


Solución alternativa:

Actualiza a una versión corregida, cuando esté disponible.
Revisiones y actualizaciones 1.12.0-1.12.2, 1.13.0

La condición de carrera bloquea la eliminación de los objetos de la máquina durante las actualizaciones y las actualizaciones

Un problema conocido que podría provocar que la actualización o la actualización del clúster se detenga mientras esperas que se borre el objeto de máquina anterior. Esto se debe a que no se puede quitar el finalizador del objeto de máquina. Esto afecta a cualquier operación de actualización progresiva de los grupos de nodos.

El síntoma es que el comando gkectl agota el tiempo de espera con el siguiente mensaje de error:


E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

En los registros del pod clusterapi-controller, los errores son los siguientes:


$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

El error se repite para la misma máquina durante varios minutos en ejecuciones exitosas, incluso sin este error, durante la mayor parte del tiempo puede ejecutarse con rapidez, pero en algunos casos excepcionales puede quedarse en esta condición de carrera durante varias horas.

El problema es que la VM subyacente ya se borró en vCenter, pero no se puede quitar el objeto de máquina correspondiente, que se detiene en la eliminación del finalizador debido a las actualizaciones muy frecuentes de otros controladores. Esto puede causar que se agote el tiempo de espera del comando gkectl, pero el controlador sigue conciliando el clúster para que se complete el proceso de actualización o actualización.


Solución alternativa:

Preparamos varias opciones de mitigación diferentes para este problema, que dependen de tu entorno y tus requisitos.

  • Opción 1: Espera a que la actualización se complete por sí sola.

    Según el análisis y la reproducción en tu entorno, la actualización puede finalizar por sí sola sin ninguna intervención manual. La advertencia de esta opción es que no se sabe cuánto tiempo tardará la eliminación del finalizador en cada objeto de máquina. Puede pasar de inmediato si tiene suerte, o podría durar varias horas si la conciliación del controlador del conjunto de máquinas es demasiado rápida y el controlador de la máquina nunca tiene la oportunidad de quitar el finalizador entre las conciliaciones.

    Lo bueno es que esta opción no requiere ninguna acción de tu parte, y las cargas de trabajo no se interrumpirán. Solo falta un tiempo más para que finalice la actualización.
  • Opción 2: Aplica la anotación de reparación automática a todos los objetos de máquina antiguos.

    El controlador del conjunto de máquinas filtrará las máquinas que tengan marcas de tiempo de eliminación y anotación de reparación automática que no sean cero, y no seguirán emitiendo llamadas de eliminación en esas máquinas, lo que puede ayudar a evitar la condición de carrera.

    La desventaja es que los pods en las máquinas se borrarán directamente en lugar de expulsarse, lo que significa que no respetará la configuración de PDB, lo que podría causar un tiempo de inactividad para las cargas de trabajo.

    El comando para obtener todos los nombres de máquina: 
    
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
    El comando para aplicar la anotación de reparación automática en cada máquina: 
    
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

Si encuentras este problema y la actualización o actualización aún no se puede completar después de un tiempo prolongado, comunícate con nuestro equipo de asistencia para obtener las mitigaciones.
Instalación, actualizaciones y actualizaciones 1.10.2, 1.11, 1.12, 1.13

gkectl prepara la falla de verificación previa de la validación de imagen de SO

El comando gkectl prepare falló con lo siguiente:


- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

Las comprobaciones previas de gkectl prepare incluían una validación incorrecta.


Solución alternativa:

Ejecuta el mismo comando con una marca adicional --skip-validation-os-images.
Instalación 1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

La URL de vCenter con el prefijo https:// o http:// puede causar un error de inicio del clúster

No se pudo crear el clúster de administrador con el siguiente comando:


Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

La URL se usa como parte de una clave secreta, que no es compatible con "/" o ":".


Solución alternativa:

Quita el prefijo https:// o http:// del campo vCenter.Address en el clúster de administrador o el archivo yaml de configuración del clúster de usuario.
Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

gkectl prepare en pánico el util.CheckFileExists

gkectl prepare puede entrar en pánico con el siguiente seguimiento de pila:


panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

El problema es que gkectl prepare creó el directorio del certificado de registro privado con un permiso incorrecto.


Solución alternativa:

Para solucionar este problema, ejecuta los siguientes comandos en la estación de trabajo de administrador:


sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

gkectl repair admin-master y la actualización reanudable del administrador no funcionan en conjunto.

Después de un intento de actualización del clúster de administrador con errores, no ejecutes gkectl repair admin-master. Si lo haces, es posible que los intentos posteriores de actualización del administrador fallen debido a problemas como la falla de la instancia principal del administrador en caso de falla o el acceso a la VM.


Solución alternativa:

Si ya encontraste esta situación de falla, comunícate con el equipo de asistencia.
Revisiones y actualizaciones 1.10, 1.11

La actualización reanudada del clúster de administrador puede generar una falta en la plantilla de VM del plano de control de administrador

Si la máquina del plano de control de administrador no se vuelve a crear después de un intento de actualización del clúster de administrador reanudada, la plantilla de VM del plano de control de administrador se borra. La plantilla de VM del plano de control de administrador es la plantilla de la instancia principal de administrador que se usa para recuperar la máquina del plano de control con gkectl repair admin-master.


Solución alternativa:

La plantilla de VM del plano de control de administrador se volverá a generar durante la próxima actualización del clúster de administrador.
Sistema operativo 1.12 a 1.13

cgroup v2 podría afectar las cargas de trabajo

En la versión 1.12.0, cgroup v2 (unificado) está habilitado de forma predeterminada para nodos de Container Optimized OS (COS). Esto podría causar inestabilidad en las cargas de trabajo en un clúster de COS.


Solución alternativa:

Cambiamos a cgroup v1 (híbrido) en la versión 1.12.1. Si usas nodos COS, te recomendamos actualizar a la versión 1.12.1 en cuanto se lance.
Identidad 1.10, 1.11, 1.12, 1.13

Recurso personalizado de ClientConfig

gkectl update revierte los cambios manuales que realizaste en el recurso personalizado ClientConfig.


Solución alternativa:

Te recomendamos crear una copia de seguridad del recurso ClientConfig después de cada cambio manual.
Instalación 1.10, 1.11, 1.12, 1.13

La validación de gkectl check-config falla y no encuentra las particiones de BIG-IP de F5

La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.

Un problema con la API de BIG-IP de F5 puede causar que la validación falle.


Solución alternativa:

Vuelve a ejecutar gkectl check-config.
Instalación 1.12

No se pudo instalar el clúster de usuario debido al problema de elección de líder de cert-manager/ca-injector

Es posible que veas una falla de instalación debido a cert-manager-cainjector en el bucle de fallas, cuando apiserver/etcd es lento:


# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

Solución alternativa:
Seguridad, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

Es posible que sea necesario renovar los certificados antes de actualizar el clúster de administrador

Antes de comenzar el proceso de actualización del clúster de administrador, debes asegurarte de que tus certificados de clúster de administrador sean válidos y renovarlos si no lo son.

Si iniciaste el proceso de actualización y encontraste un error con el vencimiento del certificado, comunícate con Atención al cliente de Google para obtener ayuda.

Nota: Esta guía es estrictamente para la renovación de los certificados del clúster de administrador.

Solución alternativa:
VMware 1.10, 1.11, 1.12, 1.13

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Si vCenter, en las versiones anteriores a la 7.0U2, se reinicia, después de una actualización o de otra manera, el nombre de la red en la información de la VM de vCenter es incorrecto y cambia el estado de la máquina a Unavailable. Con el tiempo, esto hace que los nodos se repare automáticamente para crear nuevos.

Error relacionado con govmomi.


Solución alternativa:

La solución alternativa la proporciona la asistencia de VMware:

  1. El problema se solucionó en vCenter 7.0U2 y versiones posteriores.
  2. Para versiones anteriores, haz clic con el botón derecho en el host y selecciona Conexión > Desconectar. A continuación, vuelve a conectarte, lo que fuerza una actualización del grupo de puertos de la VM.
Sistema operativo 1.10, 1.11, 1.12, 1.13

Conexión SSH cerrada por host remoto

Para los clústeres de Anthos alojados en VMware 1.7.2 y versiones posteriores, las imágenes del SO Ubuntu se endurecen con las comparativas del servidor CIS L1.

Para cumplir con la regla CIS “5.2.16 Asegúrate de que el intervalo de tiempo de espera de inactividad de SSH esté configurado”, /etc/ssh/sshd_config tiene la siguiente configuración:


ClientAliveInterval 300
ClientAliveCountMax 0

El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0 provoca un comportamiento inesperado. Cuando usas la sesión SSH en la estación de trabajo de administrador o en un nodo del clúster, la conexión SSH puede desconectarse, incluso si el cliente SSH no está inactivo, por ejemplo, si ejecutas un comando lento, que podría terminar con el siguiente mensaje:


Connection to [IP] closed by remote host.
Connection to [IP] closed.

Solución alternativa:

Tienes varias opciones:

  • Usa nohup para evitar que el comando finalice en la desconexión SSH. 
    
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
  • Actualiza sshd_config para usar un valor ClientAliveCountMax distinto de cero. La regla de CIS recomienda usar un valor inferior a 3: 
    
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

Asegúrate de volver a conectar tu sesión SSH.
Instalación 1.10, 1.11, 1.12, 1.13

Instalación de cert-manager en conflicto

En las versiones 1.13, monitoring-operator instalará cert-manager en el espacio de nombres cert-manager. Si, por ciertos motivos, necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:

Solo debes aplicar este trabajo una vez por cada clúster, y los cambios se conservarán durante la actualización del clúster.

Nota: Un síntoma común de instalación de tu propio cert-manager es que la versión cert-manager o la imagen (por ejemplo, v1.7.2) pueden volver a su versión anterior. Esto se debe a que monitoring-operator intenta conciliar el cert-manager y revertir la versión en el proceso.

Solución alternativa:

Evite los conflictos durante la actualización

  1. Desinstala tu versión de cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos.
  2. Realiza la actualización.
  3. Sigue las siguientes instrucciones para restablecer tu propio cert-manager.

Restablece tu propio cert-manager en clústeres de usuario

  • Escala la implementación monitoring-operator a 0: 
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
  • Escala las implementaciones de cert-manager administradas por monitoring-operator a 0: 
    
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
  • Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si tienes uno.
  • Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que tu cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos emisores metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado. 
    
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

Restablece tu propio cert-manager en clústeres de administrador

Por lo general, no es necesario volver a instalar cert-manager en los clústeres de administrador, porque los clústeres de administrador solo ejecutan clústeres de Anthos en las cargas de trabajo del plano de control de VMware. En los casos poco frecuentes en los que también necesites instalar tu propio cert-manager en clústeres de administrador, sigue estas instrucciones para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y que solo necesitas cert-manager para Apigee, no necesitas ejecutar los comandos del clúster de administrador.

  • Escala la implementación de monitoring-operator a 0. 
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
  • Escala las implementaciones de cert-manager administradas por monitoring-operator a 0. 
    
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
  • Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si tienes uno.
  • Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que tu cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos emisores metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado. 
    
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
Sistema operativo 1.10, 1.11, 1.12, 1.13

Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc

Las imágenes de Docker, containerd y runc de las imágenes del SO Ubuntu que se envían con los clústeres de Anthos alojados en VMware se fijan a versiones especiales con el PPA de Ubuntu. Esto garantiza que los cambios en el entorno de ejecución de los contenedores se califiquen mediante los clústeres de Anthos alojados en VMware antes de cada lanzamiento.

Sin embargo, el Seguimiento de CVE de Ubuntu, que varias herramientas de análisis de CVE usan, considera las versiones especiales. Por lo tanto, verás falsos positivos en los resultados de análisis de vulnerabilidades de Docker, containerd y runc.

Por ejemplo, es posible que veas los siguientes falsos positivos de los resultados del análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de los clústeres de Anthos alojados en VMware.

Consulta las notas de la versión para conocer las correcciones de CVE.


Solución alternativa:

Canonical está al tanto de este problema y se realiza un seguimiento de la corrección en https://github.com/canonical/sec-cvescan/issues/73.
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

Es posible que la conexión de red entre el clúster de administrador y el del usuario no esté disponible por un período breve durante la actualización del clúster que no es de alta disponibilidad

Si actualizas clústeres que no tienen alta disponibilidad de 1.9 a 1.10, es posible que notes que kubectl exec, kubectl log y el webhook de los clústeres de usuario no están disponibles por un período breve. Este tiempo de inactividad puede ser de hasta un minuto. Esto sucede porque kube-apiserver administra el pedido entrante (kubectl exec, kubectl log and webhook). El usuario kube-apiserver es un estado con estado. En un clúster que no tiene alta disponibilidad, solo hay una réplica para el objeto Statefulset. Por lo tanto, durante la actualización, es posible que el kube-apiserver anterior no esté disponible mientras el nuevo kube-apiserver aún no esté listo.


Solución alternativa:

Este tiempo de inactividad solo ocurre durante el proceso de actualización. Si deseas obtener un tiempo de inactividad menor durante la actualización, te recomendamos que cambies a clústeres con alta disponibilidad.
Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

No se pudo comprobar la preparación de Konnectivity en el diagnóstico del clúster con alta disponibilidad después de la creación o actualización del clúster

Si creas o actualizas un clúster de HA y observas que la verificación de preparación de la conectividad falló en el diagnóstico del clúster, en la mayoría de los casos, no afectará la funcionalidad de los clústeres de Anthos alojados en VMware (kubectl exec, kubectl log y webhook). Esto sucede porque, en ocasiones, una o dos de las réplicas de Konnectivity pueden no estar listas por un período debido a la inestabilidad de las herramientas de redes o a otros problemas.


Solución alternativa:

La conectividad se recuperará sola. Espera entre 30 minutos y 1 hora y vuelve a ejecutar el diagnóstico del clúster.
Sistema operativo 1.7, 1.8, 1.9, 1.10 y 1.11

/etc/cron.daily/aide Problema de aumento de memoria y CPU

A partir de la versión 1.7.2 de los clústeres de Anthos alojados en VMware, las imágenes del SO Ubuntu se endurecen mediante las comparativas del servidor CIS L1.

Como resultado, la secuencia de comandos cron /etc/cron.daily/aide se instaló para que se programe una verificación de aide a fin de garantizar que se siga de forma regular la regla 1.4.2 del servidor CIS L1.

El trabajo cron se ejecuta todos los días a las 6:25 a.m. UTC. Según la cantidad de archivos en el sistema de archivos, es posible que experimentes picos de uso de memoria y CPU en ese momento debido a este proceso de aide.


Solución alternativa:

Si los aumentos afectan tu carga de trabajo, puedes inhabilitar el trabajo cron diario:


sudo chmod -x /etc/cron.daily/aide
Herramientas de redes 1.10, 1.11, 1.12, 1.13

Los balanceadores de cargas y las reglas de firewall distribuidas con estado de NSX-T interactúan de manera impredecible

Cuando implementas clústeres de Anthos alojados en VMware versión 1.9 o posterior, cuando la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall distribuido con estado de NSX-T, stackdriver-operator podría no crear gke-metrics-agent-conf de ConfigMap y causar que los pods gke-connect-agent estén en un bucle de fallas.

El problema subyacente es que las reglas de firewall distribuidas con estado de NSX-T finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw, ya que este usa flujos de conexión asimétricas. Los problemas de integración con las reglas de firewall distribuido de NSX-T afectan a todos los clústeres de Anthos alojados en VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando crean objetos de Kubernetes grandes, cuyo tamaño es superior a 32,000.


Solución alternativa:

Sigue estas instrucciones a fin de inhabilitar las reglas de firewall distribuidas de NSX-T o usar reglas de firewall distribuidas sin estado para las VM de Seesaw.

Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas y restablecer las conexiones de los clientes cuando detecte una falla de nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes pueden dejar de responder durante varios minutos cuando una instancia del servidor falla.
Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14

Facturación inesperada de Monitoring

Para los clústeres de Anthos alojados en VMware 1.10 a la versión más reciente, algunos clientes descubrieron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo afecta a las siguientes circunstancias:

  • Se habilitó la supervisión de la aplicación (enableStackdriverForApplications=true)
  • Servicio administrado para Prometheus no está habilitado (enableGMPForApplications)
  • Los pods de la aplicación tienen la anotación prometheus.io/scrap=true.

Para confirmar si te afecta este problema, enumera las métricas definidas por el usuario. Si ves la facturación de métricas no deseadas, este problema se aplica a ti.


Solución alternativa

Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 y cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que abordan este problema:

  • Marcas separadas para controlar la recopilación de registros de la aplicación en comparación con las métricas de la aplicación
  • Paquete de Google Cloud Managed Service para Prometheus

    • Si no puedes actualizar a la versión 1.12, sigue estos pasos:

    1. Encuentra los servicios y los pods de origen que tienen la facturación no deseada 
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del Pod o del Service.
    Instalación 1.11, 1.12, 1.13

    El instalador falla cuando se crea el disco de datos de vSphere

    El instalador de las clústeres de Anthos alojados en VMware puede fallar si las funciones personalizadas están vinculadas en el nivel de permisos incorrecto.

    Cuando la vinculación de función es incorrecta, la creación de un disco de datos de vSphere con govc se bloquea y el disco se crea con un tamaño igual a 0. Para solucionar el problema, debes vincular la función personalizada a nivel de vCenter de vSphere (raíz).


    Solución alternativa:

    Si deseas vincular la función personalizada en el nivel de DC (o un nivel inferior a la raíz), también debes vincular la función de solo lectura al usuario en el nivel raíz de vCenter.

    Para obtener más información sobre la creación de funciones, consulta Privilegios de cuenta de usuario de vCenter.
    Registro y supervisión 1.9.0-1.9.4, 1.10.0-1.10.1

    Tráfico de red alto a monitoring.googleapis.com

    Es posible que veas un tráfico de red alto en monitoring.googleapis.com, incluso en un clúster nuevo que no tenga cargas de trabajo de usuarios.

    Este problema afecta a las versiones 1.10.0-1.10.1 y 1.9.0-1.9.4. Este problema se solucionó en las versiones 1.10.2 y 1.9.5.


    Solución alternativa:
    Registro y supervisión 1.10, 1.11

    gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff

    Para los clústeres de Anthos alojados en VMware 1.10 y versiones posteriores, el DaemonSet “gke-metrics-agent” tiene errores frecuentes de CrashLoopBackOff cuando “enableStackdriverForApplications” se establece como “true” en el objeto “stackdriver”.


    Solución alternativa:

    Para mitigar este problema, inhabilita la recopilación de métricas de la aplicación mediante la ejecución de los siguientes comandos. Estos comandos no inhabilitarán la recopilación de registros de la aplicación.

    1. Para evitar que se reviertan los siguientes cambios, reduce la escala de stackdriver-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Abre el ConfigMap gke-metrics-agent-conf para editar: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. En services.pipelines, marca como comentario la sección metrics/app-metrics completa: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Cierra la sesión de edición.
    5. Reinicia el DaemonSet gke-metrics-agent: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Registro y supervisión 1.11, 1.12, 1.13

    Reemplaza métricas obsoletas en el panel

    Si se usan métricas obsoletas en tus paneles de OOTB, verás algunos gráficos vacíos. Para encontrar métricas obsoletas en los paneles de Monitoring, ejecuta los siguientes comandos:

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Las siguientes métricas obsoletas deberían migrarse a sus reemplazos.

    Funciones obsoletasReemplazo
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Solución alternativa:

    Para reemplazar las métricas obsoletas, haz lo siguiente:

    1. Borra “Estado del nodo de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Estado del nodo de GKE On-Prem” según estas instrucciones.
    2. Borra “Uso de nodos de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Uso de nodos de GKE On-Prem” según estas instrucciones.
    3. Borra “GKE On-Prem vSphere vm health” en el panel de Google Cloud Monitoring. Vuelve a instalar “Estado de vSphere VM de GKE On-Prem” según estas instrucciones.

      4. Esta baja se debe a la actualización del agente kube-state-metrics de v1.9 a v2.4, que es necesario para Kubernetes 1.22. Puedes reemplazar todas las métricas obsoletas de kube-state-metrics, que tienen el prefijo kube_, en tus paneles personalizados o políticas de alertas.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13

    Datos de métricas desconocidos en Cloud Monitoring

    Para los clústeres de Anthos alojados en VMware 1.10 y versiones posteriores, los datos de los clústeres en Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Estos son otros tipos de métricas que pueden tener métricas de resumen irrelevantes:

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen están en la lista de métricas, gke-metrics-agent no las admite en este momento.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13

    Faltan métricas en algunos nodos

    Es posible que falten las siguientes métricas en algunos nodos, pero no en todos:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solución alternativa:

    Para solucionar este problema, sigue estos pasos como solución alternativa. Para [versión 1.9.5+, 1.10.2+, 1.11.0], sigue los pasos 1 a 4 para aumentar la CPU de gke-metrics-agent.

    1. Abre tu recurso stackdriver para editarlo: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, el límite de CPU de 100m a 200m agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      El recurso editado debe ser similar al siguiente: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que los cambios se aplicaron, ejecuta el siguiente comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      El comando encuentra cpu: 50m si tus ediciones se aplicaron.
    Registro y supervisión 1.11.0-1.11.2, 1.12.0

    Faltan métricas de programador y de administrador-administrador en el clúster de administrador

    Si tu clúster de administrador se ve afectado por este problema, faltan las métricas del programador y del controlador-administrador. Por ejemplo, faltan estas dos métricas.

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solución alternativa:

    Actualizar a v1.11.3+, v1.12.1+, o v1.13+
    1.11.0-1.11.2, 1.12.0

    Faltan métricas de programador y de administrador-administrador en el clúster de usuario

    Si tu clúster de usuario se ve afectado por este problema, faltan las métricas del programador y del administrador-administrador. Por ejemplo, faltan estas dos métricas:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solución alternativa:
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    No se pudo registrar el clúster de administrador durante la creación

    Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si el clúster de administrador no puede registrarse con la especificación gkeConnect proporcionada durante su creación, verás el siguiente error.

    
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Podrás seguir usando este clúster de administrador, pero verás el siguiente error si luego intentas actualizar el clúster de administrador a la versión 1.10.y.

    
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Solución alternativa:
    Identidad 1.10, 1.11, 1.12, 1.13

    El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible

    Si usas la función Anthos Identity Service para administrar Anthos Identity Service ClientConfig, es posible que el agente de Connect se reinicie de forma inesperada.


    Solución alternativa:

    Si experimentaste este problema con un clúster existente, puedes realizar una de las siguientes acciones:

    • Inhabilita Anthos Identity Service (AIS). Si inhabilitas AIS, no se quitará el objeto binario AIS implementado ni se quitará AIS ClientConfig. Para inhabilitar AIS, ejecuta este comando: 
      
gcloud beta container hub identity-service disable \
    --project PROJECT_NAME
      Reemplaza PROJECT_NAME por el nombre del proyecto host de la flota del clúster.
    • Actualiza el clúster a la versión 1.9.3 o posterior, o a la versión 1.10.1 o posterior a fin de actualizar la versión del agente de Connect.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13

    Cisco ACI no funciona con el retorno directo del servidor (DSR)

    Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP de plano de datos.


    Solución alternativa:

    Una solución alternativa es inhabilitar el aprendizaje de IP si agregas la dirección IP de Seesaw como una IP virtual L4-L7 en el controlador de infraestructura de la política de aplicaciones (APIC) de Cisco.

    Para configurar la opción de IP virtual L4-L7, ve a Usuarios > Perfiles de aplicación > EPG de la aplicación o EPG de Seu. Si no se inhabilita el aprendizaje de IP, se producirá una oscilación de IP entre las diferentes ubicaciones en la estructura de la API de Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    Problemas de actualización 3 de vSphere 7.0

    Recientemente, VMWare identificó problemas críticos con las siguientes actualizaciones de vSphere 7.0 de actualización 3:

    • vSphere ESXi 7.0 actualización 3 (compilación 18644231)
    • vSphere ESXi 7.0 actualización 3a (compilación 18825058)
    • vSphere ESXi 7.0 actualización 3b (compilación 18905247)
    • vSphere vCenter 7.0 actualización 3b (compilación 18901211)

    Solución alternativa:

    Desde entonces, VMWare quitó estas actualizaciones. Debes actualizar ESXi y vCenter Servers a una versión más reciente.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    No se pudo activar el volumen emptyDir como exec en el pod que se ejecuta en nodos COS

    Para los pods que se ejecutan en nodos que usan imágenes de Container-Optimized OS (COS), no puedes activar el volumen emptyDir como exec. Se activa como noexec y obtendrás el siguiente error: exec user process caused: permission denied. Por ejemplo, verás este mensaje de error si implementas el siguiente pod de prueba:

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Y, en el pod de prueba, si ejecutas mount | grep test-volume, se mostrará la opción noexec:

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Solución alternativa:
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

    La actualización de la réplica del grupo de nodos del clúster no funciona después de inhabilitar el ajuste de escala automático en el grupo de nodos.

    Las réplicas del grupo de nodos no se actualizan una vez que el ajuste de escala automático está habilitado o inhabilitado en un grupo de nodos.


    Solución alternativa:

    Quita las anotaciones cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size y cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size de la implementación de la máquina del grupo de nodos correspondiente.
    Registro y supervisión 1.11, 1.12, 1.13

    Los paneles de supervisión de Windows muestran datos de clústeres de Linux

    A partir de la versión 1.11, en los paneles de supervisión listos para usar, el panel de estado del pod de Windows y el panel del estado del nodo de Windows también muestran datos de los clústeres de Linux. Esto se debe a que las métricas del nodo y del pod de Windows también se exponen en clústeres de Linux.
    Registro y supervisión 1.10, 1.11

    stackdriver-log-forwarder en CrashLoopBackOff constante

    Para los clústeres de Anthos alojados en VMware 1.10 y 1.11, stackdriver-log-forwarderel DaemonSet puede tener errores CrashLoopBackOff cuando hay registros dañados en el búfer en el disco.


    Solución alternativa:

    Para mitigar este problema, necesitaremos limpiar los registros almacenados en búfer en el nodo.

    1. Para evitar un comportamiento inesperado, reduce la escala de stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Implementa el DaemonSet de limpieza para limpiar fragmentos dañados: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Para asegurarte de que el DaemonSet de limpieza limpió todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual al número de nodo en el clúster: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Borra el DaemonSet de limpieza: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Reanudar stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Seguridad 1.13

    El servicio de Kubelet no estará disponible temporalmente después de NodeReady

    Hay un período corto en el que el nodo está listo, pero el certificado del servidor de kubelet no está listo. kubectl exec y kubectl logs no están disponibles durante estas decenas de segundos. Esto se debe a que el nuevo aprobador de certificados del servidor tarda en ver las IP válidas actualizadas del nodo.

    Este problema solo afecta al certificado del servidor de kubelet y no a la programación de pods.
    Revisiones y actualizaciones 1.12

    La actualización parcial del clúster de administrador no bloquea la actualización posterior del clúster de usuario

    No se pudo actualizar el clúster de usuario con lo siguiente:

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    El clúster de administrador no está completamente actualizado y la versión de estado aún es 1.10. Ninguna verificación previa bloqueará la actualización del clúster de usuario a la 1.12, que fallará con un problema de sesgo de la versión.


    Solución alternativa:

    Completa el proceso para actualizar el clúster de administrador a la versión 1.11 y, luego, actualizar el clúster de usuario a 1.12.
    Almacenamiento 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore informa incorrectamente espacio libre insuficiente

    El comando gkectl diagnose cluster falló con lo siguiente: 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    La validación del espacio libre del almacén de datos no se debe usar para los grupos de nodos del clúster existentes y se agregó por error por gkectl diagnose cluster.


    Solución alternativa:

    Puedes ignorar el mensaje de error, o bien omitir la validación mediante --skip-validation-infra.
    Operación, Herramientas de redes 1.11, 1.12.0-1.12.1

    No se pudo agregar un clúster de usuario nuevo cuando el clúster de administrador usa el balanceador de cargas de MetalLB

    Es posible que no puedas agregar un clúster de usuario nuevo si el clúster de administrador está configurado con una configuración de balanceador de cargas de MetalLB.

    El proceso de eliminación del clúster de usuario puede atascarse por algún motivo, lo que genera una invalidación del ConfigMap de MatalLB. No es posible agregar un clúster de usuario nuevo en este estado.


    Solución alternativa:

    Puedes forzar la eliminación de tu clúster de usuario.
    Instalación, sistema operativo 1.10, 1.11, 1.12, 1.13

    Falla cuando se usa Container-Optimized OS (COS) para el clúster de usuario

    Si osImageType usa cos para el clúster de administrador, y cuando gkectl check-config se ejecuta después de la creación del clúster de administrador y antes de la creación del clúster de usuario, fallará en: 

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    La VM de prueba que se crea para el clúster de usuario check-config usa de forma predeterminada la misma osImageType del clúster de administrador. Por el momento, la VM de prueba aún no es compatible con COS.


    Solución alternativa:

    Para evitar la comprobación previa lenta que crea la VM de prueba, usa gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Registro y supervisión 1.12.0-1.12.1

    Grafana en el clúster de administrador no puede llegar a los clústeres de usuario

    Este problema afecta a los clientes que usan Grafana en el clúster de administrador para supervisar los clústeres de usuario en los clústeres de Anthos alojados en VMware 1.12.0 y 1.12.1. Proviene de una discrepancia de certificados pushprox-client en clústeres de usuario y en la lista de anunciantes permitidos del pushprox-server en el clúster de administrador. El síntoma es pushprox-client en clústeres de usuario que imprimen registros de errores como los siguientes:

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Solución alternativa:
    Otro 1.11.3

    gkectl repair admin-master no proporciona la plantilla de VM que se usará para la recuperación.

    El comando gkectl repair admin-master falló con lo siguiente: 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master no puede recuperar la plantilla de VM que se usará para reparar la VM del plano de control de administrador si el nombre de la VM termina en los caracteres t, m, p o l.


    Solución alternativa:

    Vuelve a ejecutar el comando con --skip-validation.
    Registro y supervisión 1.11

    Error de Cloud Audit Logging debido al permiso denegado

    Anthos Cloud Audit Logging necesita una configuración de permisos especial que, por el momento, solo se realiza de forma automática para los clústeres de usuario a través de GKE Hub. Se recomienda tener al menos un clúster de usuario que use el mismo ID de proyecto y la misma cuenta de servicio que el clúster de administrador para los registros de auditoría en la nube, de modo que el clúster de administrador tenga el permiso adecuado necesario en el registro de auditoría en la nube.

    Sin embargo, en los casos en que el clúster de administrador use un ID de proyecto o una cuenta de servicio diferentes con cualquier clúster de usuario, los registros de auditoría del clúster de administrador no se podrían insertar en la nube. El síntoma es una serie de errores Permission Denied en el pod audit-proxy en el clúster de administrador.


    Solución alternativa:
    Operación, seguridad 1.11

    Falló la verificación de gkectl diagnose certificados

    Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, obtendrá las siguientes fallas cuando ejecute gkectl diagnose:

    
Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Si la estación de trabajo no tiene acceso a los nodos trabajadores del clúster de administrador o a los nodos trabajadores del clúster de administrador, se generarán las siguientes fallas cuando se ejecute gkectl diagnose:

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Solución alternativa:

    Si es seguro ignorar estos mensajes.
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

    /var/log/audit/ llena el espacio en el disco en la estación de trabajo de administrador

    /var/log/audit/ está lleno de registros de auditoría. Para verificar el uso del disco, ejecuta sudo du -h -d 1 /var/log/audit.

    Algunos comandos gkectl en la estación de trabajo de administrador, por ejemplo, gkectl diagnose snapshot, contribuyen al uso del espacio en disco.

    A partir de Anthos v1.8, la imagen de Ubuntu está endurecida con la comparativa de CIS de nivel 2. Y una de las reglas de cumplimiento, “4.1.2.2 Asegúrate de que los registros de auditoría no se borren de forma automática”, garantiza la configuración auditada max_log_file_action = keep_logs. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.


    Solución alternativa:
    Herramientas de redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup conflictos de IP flotantes con dirección de nodo

    Los usuarios no pueden crear ni actualizar objetos NetworkGatewayGroup debido al siguiente error de webhook de validación:

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    En las versiones afectadas, kubelet puede vincularse por error a una dirección IP flotante asignada al nodo y, luego, informarlo como una dirección de nodo en node.status.addresses. La webhook de validación compara las direcciones IP flotantes de NetworkGatewayGroup con todas las node.status.addresses del clúster y considera que esto es un conflicto.


    Solución alternativa:

    En el mismo clúster en el que falla la creación o la actualización de los objetos NetworkGatewayGroup, inhabilita de forma temporal el webhook de validación de ANG y envía el cambio:

    1. Guarda la configuración del webhook para que se pueda restablecer al final: 
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Edita la configuración del webhook: 
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Quita el elemento vnetworkgatewaygroup.kb.io de la lista de configuración de webhook y ciérralo para aplicar los cambios.
    4. Crea o edita tu objeto NetworkGatewayGroup.
    5. Vuelva a aplicar la configuración original del webhook: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Instalación, actualizaciones y actualizaciones 1.10.0-1.10.2

    Crea o actualiza el tiempo de espera del clúster de administrador

    Durante un intento de actualización del clúster de administrador, la VM del plano de control del administrador podría detenerse durante la creación. La VM del plano de control del administrador pasa a un bucle de espera infinito durante el inicio, y verás el siguiente error de bucle infinito en el archivo /var/log/cloud-init-output.log:

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Esto se debe a que, cuando las clústeres de Anthos alojados en VMware intentan obtener la dirección IP del nodo en la secuencia de comandos de inicio, usan grep -v ADMIN_CONTROL_PLANE_VIP para omitir la VIP del plano de control del clúster de administrador que también se puede asignar a la NIC. Sin embargo, el comando también omite cualquier dirección IP que tenga un prefijo de la VIP del plano de control, lo que hace que la secuencia de comandos de inicio se bloquee.

    Por ejemplo, supongamos que la VIP del plano de control del clúster de administrador es 192.168.1.25. Si la dirección IP de la VM del plano de control del clúster de administrador tiene el mismo prefijo, por ejemplo,192.168.1.254, entonces la VM del plano de control se detendrá durante la creación. Este problema también se puede activar si la dirección de emisión tiene el mismo prefijo que la VIP del plano de control, por ejemplo, 192.168.1.255.


    Solución alternativa:

    • Si el motivo del tiempo de espera para la creación del clúster de administrador se debe a la dirección IP de emisión, ejecuta el siguiente comando en la VM del plano de control del clúster de administrador: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Esto creará una línea sin una dirección de emisión y desbloqueará el proceso de inicio. Después de desbloquear la secuencia de comandos de inicio, ejecuta el siguiente comando para quitar esta línea agregada: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Sin embargo, si el motivo del tiempo de espera de creación del clúster de administrador se debe a la dirección IP de la VM del plano de control, no puedes desbloquear la secuencia de comandos de inicio. Cambia a una dirección IP diferente y vuelve a crearla o actualízala a la versión 1.10.3 o una posterior.
    Sistema operativo, actualizaciones y actualizaciones 1.10.0-1.10.2

    El estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster o en la reparación de la instancia principal del administrador

    DataDisk no se puede activar de forma correcta en el nodo principal del clúster de administrador cuando se usa la imagen de COS. Además, el estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster de administrador o en la reparación de la instancia principal del administrador. (el clúster de administrador que usa una imagen de COS es una función de vista previa)


    Solución alternativa:

    Vuelve a crear el clúster de administrador con osImageType configurado como ubuntu_containerd

    Después de crear el clúster de administrador con osImageType configurado como cos, toma la llave SSH del clúster de administrador y establece una conexión SSH en el nodo principal del administrador. El resultado de df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Y el resultado de lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1.10

    Búsqueda de DNS con error resuelto por el sistema en dominios .local

    En la versión 1.10.0 de los clústeres de Anthos alojados en VMware, las resoluciones de nombre en Ubuntu se enrutan a la escucha local resuelta por el sistema en 127.0.0.53 de forma predeterminada. Esto se debe a que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado de manera simbólica a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS del host local 127.0.0.53.

    Como resultado, la resolución de nombres de DNS del host local se niega a revisar los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) en busca de nombres con un sufijo .local, a menos que los nombres se especifiquen como dominios de búsqueda.

    Esto hace que las búsquedas de nombres de .local fallen. Por ejemplo, durante el inicio del nodo, kubelet no puede extraer imágenes de un registro privado con un sufijo .local. Especificar una dirección de vCenter con un sufijo .local no funcionará en una estación de trabajo de administrador.


    Solución alternativa:

    Puedes evitar este problema para los nodos del clúster si especificas el campo searchDomainsForDNS en el archivo de configuración del clúster de administrador y en el archivo de configuración del clúster de usuario a fin de incluir los dominios.

    Por el momento, gkectl update aún no admite la actualización del campo searchDomainsForDNS.

    Por lo tanto, si no configuraste este campo antes de la creación del clúster, debes establecer una conexión SSH en los nodos y evitar el stub de resolución del sistema local. Para ello, cambia el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local de 127.0.0.53) a /run/systemd/resolve/resolv.conf (que apunta al DNS ascendente real): 

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    En cuanto a la estación de trabajo de administrador, gkeadm no admite la especificación de dominios de búsqueda, por lo que debes solucionar este problema con este paso manual.

    Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
    Instalación, sistema operativo 1.10

    La IP del puente de Docker usa 172.17.0.1/16 en lugar de 169.254.123.1/24.

    Los clústeres de Anthos alojados en VMware especifican una subred dedicada para la dirección IP del puente de Docker que usa --bip=169.254.123.1/24, de modo que no reserve la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen de SO Ubuntu que hizo que se ignorara la configuración personalizada de Docker.

    Como resultado, Docker elige la 172.17.0.1/16 predeterminada como su subred de dirección IP de puente. Esto podría causar un conflicto de direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese rango de direcciones IP.


    Solución alternativa:

    Para solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración de systemd por Docker y, luego, reiniciar el servicio:

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Verifica que Docker elija la dirección IP del puente correcta:

    
ip a | grep docker0

    Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
    Revisiones y actualizaciones 1.11

    Actualización a 1.11 bloqueada por Stackdriver Readyiness

    En la versión 1.11.0 de los clústeres de Anthos alojados en VMware, hay cambios en la definición de recursos personalizados relacionados con el registro y la supervisión:

    • El nombre del grupo del recurso personalizado stackdriver cambió de addons.sigs.k8s.io a addons.gke.io.
    • El nombre del grupo de los recursos personalizados monitoring y metricsserver cambió de addons.k8s.io a addons.gke.io.
    • Las especificaciones de los recursos anteriores se comienzan a evaluar según su esquema. En particular, las especificaciones resourceAttrOverride y storageSizeOverride en el recurso personalizado stackdriver deben tener un tipo de string en los valores de las solicitudes y los límites de tamaño de CPU, memoria y almacenamiento.

    Los cambios en el nombre del grupo se realizan para cumplir con las actualizaciones de CustomResourceDefinition en Kubernetes 1.22.

    No se requiere ninguna acción si no tiene una lógica adicional que aplique o edite los recursos personalizados afectados. El proceso de actualización de los clústeres de Anthos alojados en VMware se encargará de la migración de los recursos afectados y sus especificaciones existentes después del cambio de nombre del grupo.

    Sin embargo, si ejecutas cualquier lógica que aplique o edite los recursos afectados, se requiere especial atención. En primer lugar, se les debe hacer referencia con el nuevo nombre del grupo en su archivo de manifiesto. Por ejemplo:

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    En segundo lugar, asegúrate de que los valores de las especificaciones resourceAttrOverride y storageSizeOverride sean del tipo string. Por ejemplo:

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    De lo contrario, las modificaciones y las modificaciones no tendrán efecto y pueden provocar un estado inesperado en los componentes de registro y supervisión. Estos son algunos de los posibles síntomas:

    • Registros de errores de conciliación en onprem-user-cluster-controller, por ejemplo: 
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Falla en kubectl edit stackdriver stackdriver, por ejemplo: 
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Si ves los errores anteriores, significa que ya había un tipo no compatible con la especificación de CR de Stackdriver antes de la actualización. Como solución alternativa, puedes editar de forma manual la CR de Stackdriver con el nombre de grupo anterior kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver y hacer lo siguiente:

    1. Cambia las solicitudes de recursos y los límites al tipo de string.
    2. Quita cualquier anotación addons.gke.io/migrated-and-deprecated: true si está presente.
    Luego, reanuda o reinicia el proceso de actualización.

    Si necesitas asistencia adicional, comunícate con la Atención al cliente de Google.