Problemas conocidos de los clústeres de Anthos alojados en VMware

Version 1.14 

• Versión más reciente
• Versión 1.16
• Versiones anteriores (no admitidas)

Selecciona tus clústeres de Anthos alojados en VMware: 1.14 1.13 1.12 1.11 1.10

Selecciona la categoría del problema: Configuración Instalación Revisiones y actualizaciones Operación Registro y supervisión Herramientas de redes Seguridad Almacenamiento Sistema operativo VMware Identidad Otro

O busca tu problema:

Categoría	Versiones identificadas	Problema y solución alternativa
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 Solución alternativa: Usa el objeto binario de gkectl de la versión de parche más reciente disponible para la versión secundaria correspondiente a fin de realizar la copia de seguridad del clúster de administrador después de las operaciones críticas del clúster. Por ejemplo, si el clúster ejecuta una versión 1.10.2, usa el objeto binario gke.1.10.5 para realizar una copia de seguridad del clúster de administrador manual como se describe en Cómo crear una copia de seguridad y restablecer un clúster de administrador con gkectl.
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: Ver pasos para solucionarlos Reduce la réplica de clusterapi-controllers a 0 para todos los clústeres de usuario. kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG Actualiza cada clúster de usuario uno por uno.
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: Usar containerd para el entorno de ejecución del contenedor Actualiza el clúster a la versión más reciente de 1.10
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: Crear una copia de seguridad de todos los recursos personalizados (CR) existentes de PodMonitoring Actualiza todos los clústeres a la versión 1.12 y habilita el servicio administrado para Prometheus. Volver a implementar las CR de PodMonitoring
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: Ver pasos para solucionarlos Aplica el siguiente yaml al clúster de administrador Para vsphere-metrics-Exporter kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: vsphere-metrics-exporter rules: - apiGroups: - cluster.k8s.io resources: - clusters verbs: [get, list, watch] - apiGroups: - "" resources: - nodes verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: k8s-app: vsphere-metrics-exporter name: vsphere-metrics-exporter namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: vsphere-metrics-exporter subjects: - kind: ServiceAccount name: vsphere-metrics-exporter namespace: kube-system Para cluster-health-controller apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-health-controller-role rules: - apiGroups: - "*" resources: - "*" verbs: - "*"
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: Ver pasos para solucionarlos Para que la actualización surta efecto, las máquinas deben volver a crearse after con la actualización con errores. Para la actualización del clúster de administrador, es necesario volver a crear los nodos de administrador principal y del usuario. Para la actualización del clúster de usuario, es necesario volver a crear los nodos trabajadores del usuario Para volver a crear los nodos trabajadores del usuario Opción 1 Sigue cómo actualizar un grupo de nodos y cambia la CPU o la memoria para activar una recreación progresiva de los nodos. Opción 2 Use kubectl delete para volver a crear las máquinas de a una kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG Para volver a crear los nodos principales del usuario Opción 1 Sigue el plano de control de cambio de tamaño y cambia la CPU o la memoria para activar una recreación progresiva de los nodos. Opción 2 Use kubectl delete para volver a crear las máquinas de a una kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG Para volver a crear los nodos del complemento de administrador Use kubectl delete para volver a crear las máquinas una a la vez. kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
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: Agrega los siguientes campos a tu archivo de configuración de clúster de usuario: disableNodeIDVerification: true disableNodeIDVerificationCSRSigning: true 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 Abre el recurso personalizado OnPremAdminCluster para editarlo: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ edit onpremadmincluster -n kube-system Agrega la siguiente anotación al recurso personalizado: features.onprem.cluster.gke.io/disable-node-id-verification: enabled Edita el manifiesto kube-controller-manager en el plano de control del clúster de administrador: Establece una conexión SSH al nodo del plano de control del clúster de administrador. Abre el manifiesto kube-controller-manager para editarlo: sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml Busca la lista de controllers: --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning Actualiza esta sección como se muestra a continuación: --controllers=*,bootstrapsigner,tokencleaner 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 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: Ver pasos para solucionarlos Ejecuta los siguientes comandos para mitigar el problema. Primero, reduce la escala de monitoring-operator para que no revierta los cambios a la implementación cert-manager: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \ scale deployment monitoring-operator --replicas=0 Edita la implementación de cert-manager-cainjector para inhabilitar la elección de líder, ya que solo tenemos una réplica en ejecución. No es necesaria para una sola réplica: # Add a command line flag for cainjector: `--leader-elect=false` kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \ -n kube-system deployment cert-manager-cainjector El fragmento YAML relevante para la implementación de cert-manager-cainjector debería verse como el siguiente ejemplo: ... apiVersion: apps/v1 kind: Deployment metadata: name: cert-manager-cainjector namespace: kube-system ... spec: ... template: ... spec: ... containers: - name: cert-manager image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0" args: ... - --leader-elect=false ... Mantén las réplicas monitoring-operator en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio. Una vez que finalice la instalación y el clúster esté en funcionamiento, activa monitoring-operator para las operaciones del día 2: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \ scale deployment monitoring-operator --replicas=1 Después de cada actualización, se revierten los cambios. Vuelve a realizar los mismos pasos para mitigar el problema hasta que se solucione en una versión futura.
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: Ver pasos para solucionarlos Asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador antes de comenzar. Configura la variable KUBECONFIG: KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG Reemplaza ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG por la ruta absoluta al archivo kubeconfig del clúster de administrador. Obtén la dirección IP y las claves SSH del nodo principal de administrador: kubectl --kubeconfig "${KUBECONFIG}" get secrets \ -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \ get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master') Verifica si los certificados vencieron: ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration" Si los certificados caducan, debes renovarlos antes de actualizar el clúster de administrador. Crea copias de seguridad de certificados anteriores. Este es un paso opcional, pero recomendado: # ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz . Renueva los certificados con kubeadm: # ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all Reinicia los pods estáticos que se ejecutan en el nodo principal del administrador: # on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \ -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes del vencimiento. Crea una copia de seguridad del archivo kubeconfig del clúster de administrador: ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}" Reemplaza client-certificate-data y client-key-data en kubeconfig con client-certificate-data y client-key-data en el archivo new_admin.conf que creaste. Debes validar los certificados renovados y el certificado de kube-apiserver. Verifica el vencimiento de los certificados: ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration" Verifica el certificado de kube-apiserver: # Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect : \ | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \ > current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
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: El problema se solucionó en vCenter 7.0U2 y versiones posteriores. 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 Desinstala tu versión de cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos. Realiza la actualización. 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. CVE-2019-16884 CVE-2019-19921 CVE-2020-15157 CVE-2020-15257 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: 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"' 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: Ver pasos para solucionarlos Actualiza a la versión 1.10.2/1.9.5 o posterior. Para mitigar este problema en una versión anterior, haz lo siguiente: Reduce la escala de “stackdriver-operator”: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system \ scale deployment stackdriver-operator --replicas=0 Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario. Abre el ConfigMap gke-metrics-agent-conf para editar: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system \ edit configmap gke-metrics-agent-conf Aumenta el intervalo del sondeo de 0.1 segundos a 13 segundos: processors: disk_buffer/metrics: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-metrics probe_interval: 13s retention_size_mib: 6144 disk_buffer/self: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-self probe_interval: 13s retention_size_mib: 200 disk_buffer/uptime: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-uptime probe_interval: 13s retention_size_mib: 200 Cierra la sesión de edición. Cambia la versión de DaemonSet de gke-metrics-agent a 1.1.0-anthos.8: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system set image daemonset/gke-metrics-agent \ gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
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. 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. Abre el ConfigMap gke-metrics-agent-conf para editar: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit configmap gke-metrics-agent-conf 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 Cierra la sesión de edición. 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 obsoletas Reemplazo 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: 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. 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. 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. 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. Abre tu recurso stackdriver para editarlo: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit stackdriver stackdriver 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 Guarda los cambios y cierra el editor de texto. 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: Ver pasos para solucionarlos Si se produce este error, sigue estos pasos para solucionar el problema de registro del clúster. Después de realizar esta corrección, puedes actualizar el clúster de administrador. Ejecuta gkectl update admin para registrar el clúster de administrador con la clave de cuenta de servicio correcta. Crea una cuenta de servicio dedicada para aplicar un parche en el recurso personalizado OnPremAdminCluster. export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG # Create Service Account modify-admin kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: modify-admin namespace: kube-system EOF # Create ClusterRole kubectl apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: modify-admin-role rules: - apiGroups: - "onprem.cluster.gke.io" resources: - "onpremadminclusters/status" verbs: - "patch" EOF # Create ClusterRoleBinding for binding the permissions to the modify-admin SA kubectl apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: creationTimestamp: null name: modify-admin-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: modify-admin-role subjects: - kind: ServiceAccount name: modify-admin namespace: kube-system EOF Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador. Ejecuta estos comandos para actualizar el recurso personalizado OnPremAdminCluster. export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG SERVICE_ACCOUNT=modify-admin SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \ -n kube-system -o json \ | jq -Mr '.secrets[].name | select(contains("token"))') TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \ | jq -Mr '.data.token' | base64 -d) kubectl get secret ${SECRET} -n kube-system -o json \ | jq -Mr '.data["ca.crt"]' \ | base64 -d > /tmp/ca.crt APISERVER=https://$(kubectl -n default get endpoints kubernetes \ --no-headers | awk '{ print $2 }') # Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \ --no-headers | awk '{ print $1 }') GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \ -n kube-system $ADMIN_CLUSTER_NAME \ -o=jsonpath='{.spec.gkeOnPremVersion}') # Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR curl -H "Accept: application/json" \ --header "Authorization: Bearer $TOKEN" -XPATCH \ -H "Content-Type: application/merge-patch+json" \ --cacert /tmp/ca.crt \ --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \ $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status Intenta actualizar el clúster de administrador de nuevo con la marca --disable-upgrade-from-checkpoint. gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --disable-upgrade-from-checkpoint Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador.
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: Ver pasos para solucionarlos Aplica un recurso DaemonSet, por ejemplo: apiVersion: apps/v1 kind: DaemonSet metadata: name: fix-cos-noexec namespace: kube-system spec: selector: matchLabels: app: fix-cos-noexec template: metadata: labels: app: fix-cos-noexec spec: hostIPC: true hostPID: true containers: - name: fix-cos-noexec image: ubuntu command: ["chroot", "/host", "bash", "-c"] args: - | set -ex while true; do if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then echo "remounting /var/lib/kubelet with exec" nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet fi sleep 3600 done volumeMounts: - name: host mountPath: /host securityContext: privileged: true volumes: - name: host hostPath: path: /
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. 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. 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 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 Borra el DaemonSet de limpieza: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system delete ds fluent-bit-cleanup 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: Ver pasos para solucionarlos realiza los siguientes pasos: Reduce la escala de la implementación del operador de supervisión en el espacio de nombres kube-system del clúster de administrador. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --namespace kube-system scale deploy monitoring-operator \ --replicas=0 Edita el ConfigMap pushprox-server-rbac-proxy-config en el espacio de nombres del sistema de kube-system del clúster de administrador. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --namespace kube-system edit cm pushprox-server-rbac-proxy-config Localiza la línea principals del objeto de escucha external-pushprox-server-auth-proxy y corrige la principal_name de todos los clústeres de usuario. Para ello, quita la substring kube-system de pushprox-client.metrics-consumers.kube-system.cluster.. La configuración nueva debería verse de la siguiente manera: permissions: - or_rules: rules: - header: { name: ":path", exact_match: "/poll" } - header: { name: ":path", exact_match: "/push" } principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}] Reinicia la implementación pushprox-server en el clúster de administrador y la implementación pushprox-client en los clústeres de usuario afectados: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client Los pasos anteriores deberían resolver el problema. Una vez que el clúster se actualice a la versión 1.12.2 y, luego, en la que se soluciona el problema, escala verticalmente el operador de supervisión kube-system del clúster de administrador para que pueda volver a administrar la canalización. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
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: Ver pasos para solucionarlos Para resolver este problema, se puede configurar el permiso mediante la interacción con la función cloudauditlogging de Hub: Primero, verifica las cuentas de servicio existentes incluidas en la lista de anunciantes permitidos de Anthos Cloud Audit Logging para tu proyecto: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging Según la respuesta, realiza una de las siguientes acciones: Si recibes un error 404 Not_found, significa que no hay ninguna cuenta de servicio incluida en la lista de anunciantes permitidos para este ID del proyecto. Para incluir una cuenta de servicio en la lista de entidades permitidas, habilita la función cloudauditlogging de Hub: curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' Si recibiste una especificación de función que contiene "lifecycleState": "ENABLED" con "code": "OK" y una lista de cuentas de servicio en allowlistedServiceAccounts, significa que hay cuentas de servicio existentes permitidas para este proyecto. Puedes usar una cuenta de servicio de esta lista en tu clúster o agregar una cuenta de servicio nueva a la lista de entidades permitidas: curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' Si recibiste una especificación de función que contiene "lifecycleState": "ENABLED" con "code": "FAILED", significa que la configuración de permisos no se realizó correctamente. Intenta solucionar los problemas en el campo description de la respuesta o crea una copia de seguridad de la lista de entidades permitidas actual, borra la función concentrador de Cloudauditlogging y vuelve a habilitarla mediante el paso 1 de esta sección nuevamente. Puedes borrar la función cloudauditlogging de Hub de las siguientes maneras: curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging En los comandos anteriores: Reemplaza PROJECT_ID por el proyecto de registro de auditoría del clúster. Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de la cuenta de servicio de registro de auditoría del clúster.
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: Ver pasos para solucionarlos Estación de trabajo de administrador En la estación de trabajo de administrador, puedes cambiar de forma manual la configuración de auditoría para rotar los registros de forma automática y, luego, reiniciar el servicio auditado: sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf systemctl restart auditd La configuración anterior provocaría que las auditorías roten sus registros de manera automática una vez que hayan generado más de 250 archivos (cada uno con un tamaño de 8 millones). Nodos de clúster En el caso de los nodos del clúster, actualiza a la versión 1.11.5+, 1.12.4+, 1.13.2+ o 1.14+. Si aún no puedes actualizarlas a esas versiones, aplica el siguiente DaemonSet a tu clúster: apiVersion: apps/v1 kind: DaemonSet metadata: name: change-auditd-log-action namespace: kube-system spec: selector: matchLabels: app: change-auditd-log-action template: metadata: labels: app: change-auditd-log-action spec: hostIPC: true hostPID: true containers: - name: update-audit-rule image: ubuntu command: ["chroot", "/host", "bash", "-c"] args: - | while true; do if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then echo "updating auditd max_log_file_action to rotate with a max of 250 files" sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf echo "restarting auditd" systemctl restart auditd else echo "auditd setting is expected, skip update" fi sleep 600 done volumeMounts: - name: host mountPath: /host securityContext: privileged: true volumes: - name: host hostPath: path: / Ten en cuenta que, si realizar este cambio de configuración auditado, se infringiría la regla de nivel 2 de CIS "4.1.2.2, asegúrate de que los registros de auditoría no se borren de forma automática".
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: 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 Edita la configuración del webhook: kubectl -n kube-system edit validatingwebhookconfiguration \ ang-validating-webhook-configuration Quita el elemento vnetworkgatewaygroup.kb.io de la lista de configuración de webhook y ciérralo para aplicar los cambios. Crea o edita tu objeto NetworkGatewayGroup. 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.

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