Herramientas de redes, operación |
1.10, 1.11, 1.12, 1.13, 1.14 |
Componentes de la puerta de enlace de red de Anthos expulsados o pendientes debido a que falta una clase de prioridad
Los Pods de la puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted , como se muestra en el siguiente resultado condensado de ejemplo:
$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc 2/2 Running 0 5d2h
ang-node-mw8cq 0/2 Evicted 0 6m5s
ang-node-zsmq7 0/2 Pending 0 7h
Estos errores indican eventos de expulsión o una incapacidad para programar Pods debido a los recursos de nodos. Dado que los Pods de la puerta de enlace de red de Anthos no tienen
PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo.
Cuando los nodos tienen restricciones de recursos, los Pods de la puerta de enlace de la red pueden expulsarse. Este comportamiento es especialmente inadecuado para el DaemonSet de ang-node , ya que esos Pods deben estar programados en un nodo específico y no se pueden migrar.
Solución alternativa:
Actualiza a la versión 1.15 o posterior.
Como solución a corto plazo, puedes asignar una PriorityClass de forma manual a los componentes de la puerta de enlace de Anthos Network. El controlador de clústeres de Anthos alojados en VMware reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.
- Asigna la clase
system-cluster-critical PriorityClass a los objetos Deployment del controlador de clústeres ang-controller-manager y autoscaler .
- Asigna la Prioridad
system-node-critical al DaemonSet de nodo ang-daemon .
|
Revisiones y actualizaciones |
1.12, 1.13, 1.14, 1.15 |
La actualización del clúster de administrador falla después de registrar el clúster con gcloud
Después de usar gcloud para registrar un clúster de administrador con una sección gkeConnect no vacía, es posible que veas el siguiente error cuando intentes actualizar el clúster:
failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated
Puedes borrar el espacio de nombres gke-connect
kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
y reanuda la actualización del clúster de administrador.
|
Operación |
1.13.0-1.13.8, 1.14.0-1.14.5 y 1.15.0-1.15.1 |
gkectl diagnose snapshot --log-since no limita el período para los comandos de journalctl que se ejecutan en los nodos del clúster.
Esto no afecta la funcionalidad de tomar una instantánea del clúster, ya que la instantánea aún incluye todos los registros que se recopilan de forma predeterminada mediante la ejecución de journalctl en los nodos del clúster. Por lo tanto, no se pierde la información de depuración.
|
Instalación, actualizaciones y actualizaciones |
1.9+, 1.10+, 1.11+ y 1.12+ |
gkectl prepare windows falla
gkectl prepare windows no puede instalar Docker en clústeres de Anthos alojados en versiones de VMware anteriores a 1.13 porque MicrosoftDockerProvider está obsoleto.
Solución alternativa:
La idea general para solucionar este problema es actualizar a clústeres de Anthos alojados en VMware 1.13 y usar el gkectl 1.13 a fin de crear una plantilla de VM de Windows y, luego, crear grupos de nodos de Windows. Hay dos opciones para acceder a los clústeres de Anthos alojados en VMware 1.13 desde tu versión actual, como se muestra a continuación.
Nota: Tenemos opciones para solucionar este problema en tu versión actual sin necesidad de actualizar a la versión 1.13, pero necesitarás más pasos manuales. Comunícate con nuestro equipo de asistencia al cliente si deseas usar esta opción.
Opción 1: Actualización azul-verde
Puedes crear un clúster nuevo con la versión 1.13 o superior de clústeres de Anthos alojados en VMware con grupos de nodos de Windows y migrar tus cargas de trabajo al clúster nuevo para, luego, eliminar el clúster actual. Se recomienda usar la versión secundaria más reciente de Anthos.
Nota: Esto requerirá recursos adicionales para aprovisionar el clúster nuevo, pero
menos tiempo de inactividad y alteraciones para las cargas de trabajo existentes.
Opción 2: Borra los grupos de nodos de Windows y vuelve a agregarlos cuando
actualices a clústeres de Anthos alojados en VMware 1.13.
Nota: Para esta opción, las cargas de trabajo de Windows no podrán ejecutarse hasta que el clúster se actualice a la versión 1.13 y se vuelvan a agregar los grupos de nodos de Windows.
- Para borrar los grupos de nodos de Windows existentes, quita la configuración
de los grupos de nodos de Windows del archivo user-cluster.yaml y, luego, ejecuta el siguiente comando:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Actualiza los clústeres de administrador+usuario solo de Linux a la versión 1.12 según la
guía del usuario de actualización para la versión secundaria de destino correspondiente.
- (Asegúrate de realizar este paso antes de actualizar a 1.13) Asegúrate de que
enableWindowsDataplaneV2: true esté configurado en la CR de OnPremUserCluster ; de lo contrario, el clúster seguirá usando Docker para los grupos de nodos de Windows, que no serán compatibles con la plantilla de VM de Windows 1.13 recién creada que no tenga instalado Docker. Si no está configurado o configurado como falso, actualice su clúster para que sea verdadero en user-cluster.yaml y luego ejecute lo siguiente:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Actualiza los clústeres de administrador+usuario solo de Linux a 1.13 según la
guía del usuario de actualización.
- Prepara la plantilla de VM de Windows con la gkectl 1.13:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Vuelve a agregar la configuración del grupo de nodos de Windows a user-cluster.yaml con el campo
OSImage establecido en la plantilla de VM de Windows recién creada.
- Actualiza el clúster para agregar grupos de nodos de Windows
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
|
Instalación, actualizaciones y actualizaciones |
1.13.0-1.13.9, 1.14.0-1.14.5 y 1.15.0-1.15.1 |
La configuración de RootDistanceMaxSec no tiene efecto para
los nodos ubuntu
El valor predeterminado de 5 segundos para RootDistanceMaxSec se usará en los nodos, en lugar de 20 segundos, que debería ser la configuración esperada. Si verificas el registro de inicio del nodo mediante una conexión SSH a la VM, que se encuentra en “/var/log/startup.log”, puedes encontrar el siguiente error:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
Si usas RootDistanceMaxSec de 5 segundos, es posible que el reloj del sistema no esté sincronizado con el servidor NTP cuando el desvío del reloj sea mayor de 5 segundos.
Solución alternativa:
Establece una conexión SSH a los nodos y configura RootDistanceMaxSec :
mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
|
Revisiones y actualizaciones |
1.12.0-1.12.6, 1.13.0-1.13.6 y 1.14.0-1.14.2 |
gkectl update admin falla debido a que el campo osImageType está vacío
Cuando usas la versión 1.13 gkectl para actualizar un clúster de administrador de la versión 1.12, es posible que veas el siguiente error:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Cuando usas gkectl update admin para los clústeres de las versiones 1.13 o 1.14, es posible que veas el siguiente mensaje en la respuesta:
Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time
Si revisas el registro gkectl , es posible que veas que los diversos cambios incluyen la configuración de osImageType de una string vacía a ubuntu_containerd .
Estos errores de actualización se deben a un reabastecimiento incorrecto del
campo osImageType en la configuración del clúster de administrador, ya que se
introdujo en la versión 1.9.
Solución alternativa:
Actualiza a una versión de los clústeres de Anthos alojados en VMware con la solución. Si la actualización
no es posible para ti, comunícate con el servicio de Atención al cliente de Cloud para resolver este problema.
|
Instalación, seguridad |
1.13, 1.14, 1.15 |
La SNI no funciona en clústeres de usuario con Controlplane V2
La capacidad de proporcionar un certificado de entrega adicional para el servidor de la API de Kubernetes de un clúster de usuario con
authentication.sni no funciona cuando se habilita Controlplane V2 (
enableControlplaneV2: true ).
Solución alternativa:
Hasta que un parche de clústeres de Anthos alojados en VMware esté disponible con la corrección, si necesitas
usar SNI, inhabilita Controlplane V2 (enableControlplaneV2: false ).
|
Instalación |
1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
$ en el nombre de usuario del registro privado causa fallas en el inicio de la máquina del plano de control del administrador
La máquina del plano de control del administrador no se inicia cuando el nombre de usuario del registro privado contiene $ .
Cuando verifiques /var/log/startup.log en la máquina del plano de control del administrador, verás el
siguiente error:
++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable
Solución alternativa:
Usa un nombre de usuario de registro privado sin $ o una versión de clústeres de Anthos alojados en VMware con la solución.
|
Revisiones y actualizaciones |
1.12.0 a 1.12.4 |
Advertencias de falsos positivos sobre los cambios no admitidos durante la actualización del clúster de administrador
Cuando
actualices los clústeres de administrador, verás las siguientes advertencias de falsos positivos en el registro y podrás ignorarlas.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
Revisiones y actualizaciones |
1.13.0-1.13.9, 1.14.0-1.14.5 y 1.15.0-1.15.1 |
No se pudo actualizar el clúster de usuario después de la rotación de claves de firma de KSA
Después de rotar las claves de firma de KSA y, luego,
actualizar un clúster de usuario, es posible que gkectl update falle y muestre el siguiente mensaje de error:
Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"
Solución alternativa:
Cambia la versión de tu clave de firma de KSA a 1, pero conserva los datos de clave más recientes:
- Verifica el secreto del clúster de administrador en el espacio de nombres
USER_CLUSTER_NAME y obtén el nombre del secreto de ksa-signing-key:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
- Copia el secreto ksa-signing-key y asígnale el nombre como service-account-cert:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
- Borra el secreto de clave ksa anterior:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Actualiza el campo
data.data en el mapa de configuración de ksa-signing-key-rotation-stage a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
- Inhabilita el webhook de validación para editar la información de la versión en el recurso personalizado OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremuserclusters
'
- Actualiza el campo
spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation a 1 en tu recurso personalizado OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
- Espera a que el clúster de usuario de destino esté listo: Para verificar el estado, haz lo siguiente:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
- Restablece el webhook de validación para el clúster de usuario:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremuserclusters
'
- Evita otra rotación de claves de firma de KSA hasta que el clúster se
actualice a la versión con la corrección.
|
Operación |
1.13.1+, 1.14, 1.15 |
Cuando usas Terraform para borrar un clúster de usuario con un balanceador de cargas de BIG-IP de
F5, los servidores virtuales de BIG-IP de F5 no se quitan después de
borrar el clúster.
Solución alternativa:
A fin de quitar los recursos de F5, sigue los pasos para limpiar una partición de F5 de un clúster de usuario
|
Instalación, actualizaciones y actualizaciones |
1.13.8, 1.14.4 |
el tipo de clúster extrae imágenes de contenedor de docker.io
Si creas un clúster de administrador de la versión 1.13.8 o la versión 1.14.4, o actualizas un clúster de administrador a la versión 1.13.8 o 1.14.4, el tipo de clúster extrae las siguientes imágenes de contenedor de docker.io :
docker.io/kindest/kindnetd
docker.io/kindest/local-path-provisioner
docker.io/kindest/local-path-helper
Si no se puede acceder a docker.io desde la estación de trabajo de administrador, la creación o la actualización del clúster de administrador no mostrará el tipo de clúster.
Si ejecutas el siguiente comando en la estación de trabajo de administrador, se muestran los
contenedores correspondientes pendientes con ErrImagePull :
docker exec gkectl-control-plane kubectl get pods -A
La respuesta contiene entradas como las siguientes:
...
kube-system kindnet-xlhmr 0/1
ErrImagePull 0 3m12s
...
local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1
Pending 0 3m12s
...
Estas imágenes de contenedor se deben precargar en la imagen del contenedor del clúster de tipo. Sin embargo, la categoría v0.18.0 tiene un problema con las imágenes de contenedor precargadas, lo que hace que se extraigan de Internet por error.
Solución alternativa:
Ejecuta los siguientes comandos en la estación de trabajo de administrador, mientras el clúster de administrador
está pendiente de creación o actualización:
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
|
Operación |
1.13.0-1.13.7, 1.14.0-1.14.4 y 1.15.0 |
No se pudo realizar la conmutación por error en el clúster de usuario y de administrador de HA Controlplane V2 cuando la red filtró solicitudes de GARP duplicadas
Si las VM de tu clúster están conectadas con un interruptor que filtra las solicitudes GARP duplicadas (ARP injustificada), la elección de líder de keepalife puede encontrar una condición de carrera, lo que hace que algunos nodos tengan entradas de tabla ARP incorrectas.
Los nodos afectados pueden ping la VIP del plano de control, pero se agotará el tiempo de espera de la conexión TCP a la VIP del plano de control.
Solución alternativa:
Ejecuta el siguiente comando en cada nodo del plano de control del clúster afectado:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
Actualizaciones y actualizaciones |
1.13.0-1.13.7, 1.14.0-1.14.4 y 1.15.0 |
vsphere-csi-controller debe reiniciarse después de la rotación del certificado de vCenter
vsphere-csi-controller debe actualizar su secreto de vCenter después de la rotación del certificado de vCenter. Sin embargo, el sistema actual no reinicia correctamente los Pods de vsphere-csi-controller , lo que hace que vsphere-csi-controller falle después de la rotación.
Solución alternativa:
Para los clústeres creados en 1.13 y versiones posteriores, sigue las instrucciones a continuación a fin de reiniciar vsphere-csi-controller .
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
|
Instalación |
1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1 |
La creación del clúster de administrador no falla en los errores de registro del clúster.
Incluso cuando el registro del clúster falla durante la creación del clúster de administrador, el comando gkectl create admin no falla con el error y puede tener éxito. En otras palabras, la creación del clúster de administrador podría tener éxito sin estar registrada en una flota.
Para identificar el síntoma, puede buscar los siguientes mensajes de error en el registro de “gkectl create admin”,
Failed to register admin cluster
También puede verificar si puede encontrar el clúster entre los clústeres registrados en la consola de Cloud.
Solución alternativa:
Para los clústeres creados en 1.12 y versiones posteriores, sigue las instrucciones a fin de volver a intentar el registro del clúster de administrador después de su creación. Para los clústeres creados en versiones anteriores,
-
Agregar un par clave-valor falso como “foo: bar” al archivo de claves de SA del registro de conexión
-
Ejecuta
gkectl update admin para volver a registrar el clúster de administrador.
|
Actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13.0-1.13.1 |
Es posible que se omita el registro nuevo del clúster de administrador durante la actualización
Durante la actualización del clúster de administrador, si se agota el tiempo de espera de la actualización de los nodos del plano de control de usuario, el clúster de administrador no se volverá a registrar con la versión actualizada del agente de conexión.
Solución alternativa:
Comprueba si el clúster se muestra entre los clústeres registrados.
Como paso opcional, accede al clúster después de configurar la autenticación. Si el clúster aún está registrado, puedes omitir las siguientes instrucciones para volver a intentarlo.
Para los clústeres actualizados a la versión 1.12 y posteriores, sigue las instrucciones a fin de volver a intentar el registro del clúster de administrador después de su creación. Para los clústeres actualizados a versiones anteriores, haz lo siguiente:
-
Agregar un par clave-valor falso como “foo: bar” al archivo de claves de SA del registro de conexión
-
Ejecuta
gkectl update admin para volver a registrar el clúster de administrador.
|
Configuración |
1.15.0 |
Mensaje de error falso sobre vCenter.dataDisk
Para un clúster de administrador de alta disponibilidad, gkectl prepare muestra este mensaje de error falso:
vCenter.dataDisk must be present in the AdminCluster spec
Solución alternativa:
Puedes ignorar este mensaje.
|
VMware |
1.15.0 |
La creación del grupo de nodos falla debido a reglas de afinidad de host de VM redundantes
Durante la creación de un grupo de nodos que usa la afinidad de VM-Host, una condición de carrera puede generar que se creen varias reglas de afinidad de VM-Host con el mismo nombre. Esto puede provocar que la creación del grupo de nodos falle.
Solución alternativa:
Quita las reglas redundantes anteriores para que pueda continuar la creación del grupo de nodos.
Estas reglas se denominan [USER_CLUSTER_NAME]-[HASH].
|
Operación |
1.15.0 |
Es posible que gkectl repair admin-master falle debido a failed
to delete the admin master node object and reboot the admin master VM
El comando gkectl repair admin-master puede fallar debido a una condición de carrera con el siguiente error.
Failed to repair: failed to delete the admin master node object and reboot the admin master VM
Solución alternativa:
Este comando es idempotente. Puede volver a ejecutarse de forma segura hasta que el comando funcione correctamente.
|
Revisiones y actualizaciones |
1.15.0 |
Los Pods permanecen en estado de error durante la recreación o la actualización de un
nodo del plano de control
Después de volver a crear o actualizar un nodo del plano de control, es posible que algunos Pods queden en estado Failed debido a una falla del predicado de NodeAffinity. Estos Pods con errores no afectan el estado ni las operaciones normales del clúster.
Solución alternativa:
Puede ignorar de forma segura los Pods con errores o borrarlos de forma manual.
|
Seguridad, configuración |
1.15 |
OnPremUserCluster no está listo debido a las credenciales del registro privado
Si usas credenciales preparadas y un registro privado, pero no configuraste credenciales preparadas para tu registro privado, es posible que OnPremUserCluster no esté listo y es posible que veas el siguiente mensaje de error:
failed to check secret reference for private registry …
Solución alternativa:
Prepara las credenciales de registro privado para el clúster de usuario de acuerdo con las instrucciones en Configura credenciales preparadas.
|
Revisiones y actualizaciones |
1.15.0 |
Durante gkectl upgrade admin , la verificación previa del almacenamiento para la migración de CSI verifica que las StorageClass no tengan parámetros que se ignoren después de la migración de CSI.
Por ejemplo, si hay una StorageClass con el parámetro diskformat , gkectl upgrade admin marca la StorageClass y, luego, informa un error en la validación previa.
Los clústeres de administrador creados en Anthos 1.10 y versiones anteriores tienen una StorageClass con diskformat: thin , que fallará esta validación. Sin embargo, esta aún funciona bien después de la migración de CSI. En su lugar, estas fallas deben interpretarse como advertencias.
Para obtener más información, consulta la sección del parámetro StorageClass en Migra volúmenes de vSphere en árbol al complemento de almacenamiento para contenedores de vSphere.
Solución alternativa:
Después de confirmar que tu clúster tiene una StorageClass con parámetros ignorados después de que la migración de CSI
ejecute gkectl upgrade admin con la marca --skip-validation-cluster-health .
|
Almacenamiento |
1.15 |
No se pueden usar los volúmenes de vSphere de árbol migrado mediante el sistema de archivos de Windows con el controlador de CSI de vSphere
En ciertas condiciones, los discos se pueden conectar como de solo lectura a los nodos de Windows. Esto hace que el volumen correspondiente sea de solo lectura dentro de un Pod.
Es más probable que este problema ocurra cuando un nuevo conjunto de nodos reemplaza un conjunto
antiguo de nodos (por ejemplo, la actualización del clúster o la actualización del grupo de nodos). Es posible que las cargas de trabajo con estado que funcionaron bien antes no puedan escribir en sus volúmenes en el nuevo conjunto de nodos.
Solución alternativa:
-
Obtenga el UID del Pod que no puede escribir en su volumen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Usa PersistentVolumeClaim para obtener el nombre del PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Determine el nombre del nodo en el que se ejecuta el Pod:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
--namespace POD_NAMESPACE \
-o jsonpath='{.spec.nodeName}{"\n"}'
-
Obtén acceso de PowerShell al nodo, ya sea a través de SSH o de la interfaz web de vSphere.
-
Establece las variables de entorno:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifica el número del disco asociado con el PersistentVolume:
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
-
Verifica que el disco sea
readonly :
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
El resultado debe ser True .
- Establece
readonly en false .
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Borra el Pod para que se reinicie:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
El Pod debe programarse para el mismo nodo. Sin embargo, en caso de que el Pod se programe en un nodo nuevo, es posible que debas repetir los pasos anteriores en el nodo nuevo.
|
Revisiones y actualizaciones |
1.12, 1.13.0-1.13.7, 1.14.0-1.14.4 |
vsphere-csi-secret no se actualizará después del gkectl update credentials vsphere --admin-cluster
Si actualizas las credenciales de vSphere para un clúster de administrador después de actualizar las credenciales del clúster, es posible que encuentres vsphere-csi-secret en el espacio de nombres kube-system en el clúster de administrador que aún usa la credencial anterior.
Solución alternativa:
- Obtén el nombre secreto
vsphere-csi-secret :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- Actualiza los datos del secreto
vsphere-csi-secret que obtuviste en el paso anterior:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
"{\"data\":{\"config\":\"$( \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
| base64 -d \
| sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
| sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
| base64 -w 0 \
)\"}}"
- Reinicia
vsphere-csi-controller :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- Puedes realizar un seguimiento del estado del lanzamiento con los siguientes elementos:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Después de que se implementa correctamente la implementación, el controlador debe usar el vsphere-csi-secret actualizado.
|
Revisiones y actualizaciones |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
audit-proxy un bucle de falla cuando se habilitan los registros de auditoría de Cloud con gkectl update cluster
Es posible que audit-proxy falle debido a un --cluster-name vacío.
Este comportamiento se debe a un error en la lógica de actualización, en el que el nombre del clúster no se propaga al manifiesto del contenedor o del proxy de auditoría.
Solución alternativa:
Para un clúster de usuario de plano de control v2 con enableControlplaneV2: true , conéctate a la máquina del plano de control de usuario mediante SSH y actualiza /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME .
En un clúster de usuario del plano de control v1, edita el contenedor audit-proxy en el
set con estado kube-apiserver para agregar --cluster_name=USER_CLUSTER_NAME :
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
|
Revisiones y actualizaciones |
1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Una reimplementación adicional del plano de control justo después de gkectl upgrade cluster
Justo después de gkectl upgrade cluster , es posible que los Pods del plano de control se vuelvan a implementar.
El estado del clúster de gkectl list clusters cambia de RUNNING a RECONCILING .
Es posible que se agote el tiempo de espera de las solicitudes al clúster de usuario.
Este comportamiento se debe a la rotación del certificado del plano de control que ocurre automáticamente después de gkectl upgrade cluster .
Este problema solo sucede con los clústeres de usuario que NO usan el plano de control v2.
Solución alternativa:
Espera a que el estado del clúster vuelva a cambiar a RUNNING en gkectl list clusters o actualiza a versiones con la corrección: 1.13.6+, 1.14.2+ o 1.15+.
|
Revisiones y actualizaciones |
1.12.7 |
Se quitó la versión 1.12.7-gke.19 incorrecta.
Los clústeres de Anthos alojados en VMware 1.12.7-gke.19 son una versión incorrecta y no debes usarlo. Se quitaron los artefactos
del bucket de Cloud Storage.
Solución alternativa:
En su lugar, usa la versión 1.12.7-gke.20.
|
Revisiones y actualizaciones |
1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent continúa usando la imagen anterior después de que se actualiza la credencial de registro.
Si actualizas la credencial de registro mediante uno de los siguientes métodos:
gkectl update credentials componentaccess si no usas un registro privado
gkectl update credentials privateregistry si usas el registro privado.
es posible que gke-connect-agent siga usando la imagen anterior o que los pods gke-connect-agent no se puedan extraer debido a ImagePullBackOff .
Este problema se solucionará en las versiones 1.13.8, 1.14.4 y posteriores de clústeres de Anthos alojados en VMware.
Solución alternativa:
Opción 1: Vuelve a implementar gke-connect-agent de forma manual:
- Borra el espacio de nombres
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Vuelve a implementar
gke-connect-agent con la clave de cuenta de servicio de registro original (no es necesario actualizar la clave):
Para el clúster de administrador:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
Para el clúster de usuario:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Opción 2: Puedes cambiar de forma manual los datos del secreto de extracción de imagen regcred que usa la implementación de gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"
Opción 3: Puedes agregar el secreto de extracción de imagen predeterminado para tu clúster en la implementación gke-connect-agent de la siguiente manera:
- Copia el secreto predeterminado en el espacio de nombres
gke-connect :
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
- Obtén el nombre de implementación de
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- Agrega el secreto predeterminado a la implementación de
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
|
Instalación |
1.13, 1.14 |
Error de verificación manual de la configuración del balanceador de cargas
Cuando validas la configuración antes de crear un clúster con un balanceador de cargas manual mediante la ejecución de gkectl check-config , el comando fallará con los siguientes mensajes de error.
- Validation Category: Manual LB Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference
Solución alternativa:
Opción 1: Puedes usar las versiones de parche 1.13.7 y 1.14.4, que incluirán la corrección.
Opción 2: También puedes ejecutar el mismo comando para validar la configuración, pero omitir la validación del balanceador de cargas.
gkectl check-config --skip-validation-load-balancer
|
Operación |
1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14 |
escasez de reloj etcd
Los clústeres que ejecutan la versión 3.4.13 de etcd o una versión anterior pueden experimentar escasez de relojes y relojes de recursos no operativos, lo que puede generar los siguientes problemas:
- Se interrumpió la programación del Pod
- No se pueden registrar los nodos
- kubelet no observa cambios en el Pod
Estos problemas pueden hacer que el clúster no funcione.
Este problema se solucionó en las versiones 1.12.7, 1.13.6, 1.14.3 y posteriores de clústeres de Anthos alojados en VMware. Estas versiones más recientes utilizan la versión 3.4.21 de etcd. Todas las versiones anteriores de clústeres de Anthos alojados en VMware se ven afectadas por
este problema.
Solución alternativa
Si no puedes actualizar de inmediato, puedes mitigar el riesgo de que el clúster falle mediante la reducción de la cantidad de nodos en el clúster. Quita los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MBps.
Para ver esta métrica en el Explorador de métricas, sigue estos pasos:
- Ve al Explorador de métricas en la consola de Google Cloud:
Ir al Explorador de métricas
- Selecciona la pestaña Configuración.
- Expande la opción Seleccionar una métrica, ingresa
Kubernetes Container en la barra de filtros y, luego, usa los submenús para seleccionarla:
- En el menú Recursos activos, selecciona Contenedor de Kubernetes.
- En el menú Categorías de métricas activas, selecciona Anthos.
- En el menú Métricas activas, selecciona
etcd_network_client_grpc_sent_bytes_total .
- Haga clic en Aplicar.
|
Revisiones y actualizaciones |
1.10, 1.11, 1.12, 1.13 y 1.14 |
Anthos Identity Service puede causar latencias del plano de control
Cuando se reinician los clústeres o se realizan actualizaciones, Anthos Identity Service puede verse abrumado por el tráfico que consta de tokens JWT vencidos que se reenvían de kube-apiserver a Anthos Identity Service a través del webhook de autenticación. Aunque Anthos Identity Service no
falla, deja de responder y deja de entregar más solicitudes.
Este problema, en última instancia, genera latencias de plano de control más altas.
Este problema se solucionó en las siguientes versiones de clústeres de Anthos alojados en VMware:
- 1.12.6 y posteriores
- 1.13.6 o superior
- 1.14.2 o posterior
Para determinar si este problema te afecta, sigue estos pasos:
- Verifica si se puede acceder al extremo de Anthos Identity Service de forma externa:
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Reemplaza CLUSTER_ENDPOINT
por la VIP del plano de control y el puerto del balanceador de cargas del clúster de control (por ejemplo, 172.16.20.50:443 ).
Si este problema te afecta, el comando muestra un código de estado 400 . Si se agota el tiempo de espera de la solicitud, reinicia el Pod ais y vuelve a ejecutar el comando curl para ver si se resuelve el problema. Si recibes un código de estado de 000 , significa que el problema se resolvió y ya terminaste. Si aún recibes un código de estado 400 , no se inicia el servidor HTTP de Anthos Identity Service. En este caso, continúa.
- Verifica los registros de Anthos Identity Service y kube-apiserver:
- Verifica el registro de Anthos Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Si el registro contiene una entrada como la siguiente, este problema te afecta:
I0811 22:32:03.583448 32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
- Verifica los registros
kube-apiserver de los clústeres:
En los siguientes comandos, KUBE_APISERVER_POD es el nombre del Pod kube-apiserver en el clúster determinado.
Clúster de administrador:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n kube-system KUBE_APISERVER_POD kube-apiserver
Clúster de usuario:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver
Si los registros kube-apiserver contienen entradas como las siguientes, entonces este problema te afecta:
E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
Solución alternativa
Si no puedes actualizar los clústeres de inmediato para obtener la solución, puedes identificar y reiniciar los Pods infractores como solución alternativa.
- Aumenta el nivel de verbosidad de Anthos Identity a 9:
kubectl patch deployment ais -n anthos-identity-service --type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
"value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
--kubeconfig KUBECONFIG
- Verifica el registro de Anthos Identity Service para ver el contexto del token no válido:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
- Para obtener la carga útil del token asociada con el contexto de cada token no válido,
analiza cada secreto de la cuenta de servicio relacionado con el siguiente comando:
kubectl -n kube-system get secret SA_SECRET \
--kubeconfig KUBECONFIG \
-o jsonpath='{.data.token}' | base64 --decode
- Para decodificar el token y ver el nombre y el espacio de nombres del Pod de origen, copia el token en el depurador en jwt.io.
- Reinicie los Pods identificados a partir de los tokens.
|
Operación |
1.8, 1.9, 1.10 |
El problema de aumento de uso de memoria de los Pods de mantenimiento de etcd
Los Pods de mantenimiento de etcd que usan la imagen etcddefrag:gke_master_etcddefrag_20210211.00_p0 se ven afectados. El contenedor `etcddefrag` abre una nueva conexión al servidor etcd durante cada ciclo de descongelación y las conexiones antiguas no se borran.
Solución alternativa:
Opción 1: Actualiza a la versión de parche más reciente de 1.8 a 1.11 que contenga la corrección.
Opción 2: Si usas la versión del parche anterior a las 1.9.6 y 1.10.3, debes reducir verticalmente la escala del Pod de mantenimiento de etcd para el clúster de administrador y de usuario:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Operación |
1.9, 1.10, 1.11, 1.12, 1.13 |
Perderá las verificaciones de estado de los Pods del plano de control del clúster de usuario
Tanto el controlador de estado del clúster como el comando gkectl diagnose cluster realizan un conjunto de verificaciones de estado, incluidas las verificaciones de estado de los Pods en los espacios de nombres. Sin embargo, comienzan a omitir los Pods del plano de control del usuario por error. Si usas el modo de plano de control v2, esto no afectará tu clúster.
Solución alternativa:
Esto no afectará la administración de las cargas de trabajo ni de los clústeres. Si desea verificar el estado de los Pods del plano de control, puede ejecutar los siguientes comandos:
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Revisiones y actualizaciones |
1.6+, 1.7 o superior |
Las actualizaciones del clúster de administrador 1.6 y 1.7 pueden verse afectadas por el redireccionamiento k8s.gcr.io -> registry.k8s.io .
Kubernetes redireccionó el tráfico de k8s.gcr.io a registry.k8s.io el 20/3/2023. En los clústeres de Anthos alojados en VMware 1.6.x y 1.7.x, las actualizaciones del clúster de administrador usan la imagen de contenedor k8s.gcr.io/pause:3.2 . Si usas un proxy para la estación de trabajo de administrador y el proxy no permite registry.k8s.io , y la imagen de contenedor k8s.gcr.io/pause:3.2 no se almacena en caché de forma local, las actualizaciones del clúster de administrador fallarán cuando se extraiga la imagen de contenedor.
Solución alternativa:
Agrega registry.k8s.io a la lista de entidades permitidas del proxy para tu estación de trabajo de administrador.
|
Herramientas de redes |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Error de validación de Seesaw en la creación del balanceador de cargas
gkectl create loadbalancer falla con el siguiente mensaje de error:
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
Esto se debe a que el archivo del grupo de Seesaw ya existe. Además, la comprobación previa intenta validar un balanceador de cargas de sube y baja inexistente.
Solución alternativa:
Quita el archivo del grupo de Seesaw existente de este clúster. El nombre de archivo
es seesaw-for-gke-admin.yaml para el clúster de administrador y
seesaw-for-{CLUSTER_NAME}.yaml para un clúster de usuario.
|
Herramientas de redes |
1.14 |
Tiempos de espera de la aplicación causados por errores de inserción de la tabla de conntrack
La versión 1.14 de las clústeres de Anthos alojados en VMware es susceptible a fallas de inserción de la tabla de seguimiento de conexión (conntrack) de netfilter cuando se usan imágenes del sistema operativo Ubuntu o COS. Las fallas de inserción generan tiempos de espera aleatorios de la aplicación y pueden ocurrir incluso cuando la tabla de conntrack tiene espacio para entradas nuevas. Las fallas se producen por cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas en función de la longitud de la cadena.
Para ver si este problema te afecta, puedes verificar las estadísticas del sistema de seguimiento de conexiones en el kernel en cada nodo con el siguiente comando:
sudo conntrack -S
La respuesta es similar a la que se muestra a continuación:
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...
Si un valor de chaintoolong en la respuesta es un número distinto de cero, este problema te afecta.
Solución alternativa
La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets ) y la tabla de seguimiento de conexión de netfilter (nf_conntrack_max ). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Reemplaza TABLE_SIZE por el tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144 . Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos en el nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288 .
|
Herramientas de redes |
1.13.0-1.13.2 |
Calic-typha o bucle de falla de anetd-operator en nodos de Windows con Controlplane v2
Con Controlplane v2 o un nuevo modelo de instalación, calico-typha o anetd-operator pueden programarse en nodos de Windows y entrar en un bucle de fallas.
El motivo es que las dos implementaciones toleran todos los taints, incluido el taint de nodo de Windows.
Solución alternativa:
Actualiza a la versión 1.13.3+ o ejecuta los siguientes comandos para editar la implementación “calico-typha” o “anetd-operator”:
# If dataplane v2 is not used.
kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
# If dataplane v2 is used.
kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
Quita los siguientes spec.template.spec.tolerations :
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
Agrega la siguiente tolerancia:
- key: node-role.kubernetes.io/master
operator: Exists
|
Configuración |
1.14.0-1.14.2 |
No se puede cargar el archivo de credenciales del registro privado del clúster de usuario
Es posible que no puedas crear un clúster de usuario si especificas la
sección privateRegistry con la credencial fileRef .
La comprobación previa podría fallar con el siguiente mensaje:
[FAILURE] Docker registry access: Failed to login.
Solución alternativa:
|
Operaciones |
1.10+ |
Anthos Service Mesh y otras mallas de servicios no son compatibles con Dataplane v2
Dataplane V2 se encarga del balanceo de cargas y crea un socket de kernel en lugar de una DNAT basada en paquetes. Esto significa que Anthos Service Mesh no puede realizar la inspección de paquetes, ya que el Pod se omite y nunca usa IPTables.
Esto se manifiesta en el modo gratuito de kube-proxy por pérdida de conectividad o enrutamiento de tráfico incorrecto para servicios con Anthos Service Mesh, ya que el archivo adicional no puede realizar la inspección de paquetes.
Este problema está presente en todas las versiones de clústeres de Anthos alojados en Bare Metal 1.10; sin embargo, algunas versiones más recientes de la versión 1.10 (1.10.2+) tienen una solución alternativa.
Solución alternativa:
Actualiza a la versión 1.11 para obtener compatibilidad total o, si ejecutas 1.10.2 o posterior, ejecuta lo siguiente:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
Agrega bpf-lb-sock-hostns-only: true al ConfigMap y, luego, reinicia el daemonset anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Almacenamiento |
1.12 + 1.13.3 |
kube-controller-manager podría desconectar los volúmenes persistentes con fuerza después de 6 minutos.
Es posible que se agote el tiempo de espera de kube-controller-manager cuando se desconecta el PV/PVC después de 6 minutos y que se desconecta de forma forzada. En los registros detallados de kube-controller-manager , se muestran eventos similares a los siguientes:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Para verificar el problema, accede al nodo y ejecuta los siguientes comandos:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
En el registro de kubelet, se muestran los siguientes errores:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Solución alternativa:
Conéctate al nodo afectado mediante SSH y reinicia el nodo.
|
Revisiones y actualizaciones |
1.12+, 1.13+ y 1.14+ |
La actualización del clúster se detiene si se usa el controlador de CSI de terceros
Es posible que no puedas actualizar un clúster si usas un controlador de CSI de terceros. El comando gkectl cluster diagnose puede mostrar el siguiente error:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Solución alternativa:
Realiza la actualización mediante la opción --skip-validation-all .
|
Operación |
1.10+, 1.11+, 1.12+, 1.13+ y 1.14+ |
gkectl repair admin-master crea la VM principal del administrador sin actualizar su versión de hardware.
Es posible que el nodo principal del administrador que se creó mediante gkectl repair admin-master use una versión de hardware de VM inferior a la esperada. Cuando ocurra el problema, verás el error en el informe gkectl diagnose cluster .
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Solución alternativa:
Cierra el nodo principal del administrador, sigue https://kb.vmware.com/s/article/1003746 para actualizarlo a la versión esperada que se describe en el mensaje de error y, luego, inícialo.
|
Sistema operativo |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ y 1.15+ |
La VM libera la asignación de tiempo de DHCP al apagar o reiniciar de forma inesperada, lo que puede
provocar cambios en la IP.
En systemd v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración KeepConfiguration . Antes de este cambio, las VM no enviaban un mensaje de liberación de asignación de tiempo de DHCP al servidor de DHCP cuando se cerraba o se reiniciaba. Después de este cambio, las VMs envían ese mensaje y muestran las IP al servidor DHCP. Como resultado, la IP liberada se puede reasignar a una VM diferente o se puede asignar una IP diferente a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no a nivel de vSphere) o cambio de IP en las VM, lo que puede interrumpir los clústeres de varias maneras.
Por ejemplo, es posible que veas los siguientes síntomas.
- La IU de vCenter muestra que ninguna VM usa la misma IP, pero
kubectl get
nodes -o wide muestra nodos con IP duplicadas.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- No se pueden iniciar los nodos nuevos debido a un error
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Solución alternativa:
Implementa el siguiente DaemonSet en el clúster para revertir el cambio de comportamiento predeterminado systemd-networkd . Las VM que ejecuten este DaemonSet no liberarán las IP al servidor DHCP durante el apagado o el reinicio. El servidor DHCP liberará las IP automáticamente cuando venzan las asignaciones.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Operación, actualizaciones y actualizaciones |
1.12.0+, 1.13.0+ y 1.14.0+ |
La clave de la cuenta de servicio de acceso a los componentes se limpia después de que el clúster de administrador se actualiza de la versión 1.11.x
Este problema solo afectará a los clústeres de administrador que se actualicen desde la versión 1.11.x y no afectará a los clústeres de administrador que se creen después de 1.12.
Después de actualizar un clúster 1.11.x a 1.12.x, el campo component-access-sa-key del secreto admin-cluster-creds se limpiará para vaciarlo.
Para ello, ejecute el siguiente comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
Si el resultado está vacío, significa que la clave se borró.
Una vez que se haya borrado la clave de la cuenta de servicio de acceso a los componentes,
fallará la instalación de clústeres de usuarios nuevos o la actualización de clústeres
de usuarios existentes. A continuación, se enumeran algunos mensajes de error que puedes encontrar:
- Error de validación previa de validación lenta con el mensaje de error
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- La preparación de
gkectl prepare falló con el mensaje de error "Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Si actualizas un clúster de usuario 1.13 mediante Google Cloud Console o gcloud CLI, cuando ejecutes
gkectl update admin --enable-preview-user-cluster-central-upgrade para implementar el controlador de la plataforma de actualización, el comando fallará y mostrará el mensaje "failed to download bundle to disk: dialing:
unexpected end of JSON input" (puedes ver este mensaje en el campo status en el resultado de kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml ).
Solución:
Agrega la clave de la cuenta de servicio de acceso a los componentes de forma manual en el Secret mediante el siguiente comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
|
Operación |
1.13.0 o superior y 1.14.0 o superior |
El escalador automático del clúster no funciona cuando Controlplane V2 está habilitado
En el caso de los clústeres de usuario creados con Controlplane V2 o un modelo de instalación nuevo, los grupos de nodos que tienen habilitado el ajuste de escala automático siempre usan sus ajuste de escala automático.minReplicas en user-cluster.yaml. El registro del Pod del escalador automático del clúster también muestra que están en mal estado.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
TIMESTAMP 1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
El Pod del escalador automático del clúster se puede encontrar ejecutando los siguientes comandos.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c 4648017n 48076Ki 30s
Solución:
Inhabilitar el ajuste de escala automático en todos los grupos de nodos con “gkectl update cluster” hasta actualizar a una versión con la corrección
|
Instalación |
1.12.0-1.12.4, 1.13.0-1.13.3 y 1.14.0 |
No se permite el CIDR en el archivo de bloque de IP
Cuando los usuarios usan CIDR en el archivo de bloqueo de IP, la validación de la configuración falla 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 del 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 máquinas del plano de control de 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 terminen la recreación cuando finalice el comando gkectl.
Solución:
Una vez que finalice la actualización, siga esperando que las máquinas del plano de control de usuario también vuelvan a crear mediante la supervisión de sus tipos de imagen de SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide . P.ej., si se actualiza de Ubuntu a COS, deberíamos 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 |
Error al crear o borrar el Pod debido a un problema de token de autenticación de la cuenta de servicio de CNI de Calico
Un problema con Calico en clústeres de Anthos alojados en VMware 1.14.0 hace que la creación y eliminación de Pods falle y muestre 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 o actualiza el clúster 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 está configurado como “false” o no se especifica, lo que 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 por 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 el 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 y 1.14.0 |
La validación del bloqueo 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 porque el clúster no tiene suficientes IP.
Solución:
Divide los CIDR en varios bloques CIDR más pequeños, como 10.0.0.0/30 se convierte en 10.0.0.0/31, 10.0.0.2/31 . Siempre que haya CIDR de N+1, en los que N es la cantidad de nodos del 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 las claves de encriptación de secretos siempre activas y la configuración
Cuando la función de encriptación de secretos siempre activada está habilitada junto con la copia de seguridad del clúster, esta no puede incluir las claves de encriptación y la configuración que requiere la función de 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 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 1.10.5 gkectl para realizar una copia de seguridad manual del clúster de administrador, como se describe en Crea una copia de seguridad y restablece un clúster de administrador con gkectl.
|
Operación, actualizaciones y actualizaciones |
1.10+ |
Volver a crear la VM de la instancia principal de administrador con un disco de arranque nuevo (p.ej., gkectl repair admin-master ) fallará si la función de encriptación de secretos siempre activa usa el comando “gkectl update”.
Si la función de encriptación de secretos siempre activada no está habilitada en la creación del clúster, pero se habilita más adelante mediante la operación gkectl update , gkectl repair admin-master no puede reparar el nodo del plano de control del clúster de administrador. Se recomienda habilitar la función de encriptación de secretos siempre activa durante la creación del clúster. No existe una mitigación actual.
|
Revisiones y actualizaciones |
1.10 |
Si se actualiza el primer clúster de usuario de 1.9 a 1.10, se vuelven a crear los nodos en otros clústeres de usuario.
Si actualizas el primer clúster de usuario de 1.9 a 1.10, se pueden recrear nodos en otros clústeres de usuario bajo el mismo clúster de administrador. La recreación se realiza de manera continua.
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 alternativos
- 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
Si actualizas el clúster de usuario a la versión 1.10.0, es posible que Docker se reinicie con frecuencia.
Ejecuta kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG para detectar este problema
Una condición de nodo mostrará si el Docker se reinicia con frecuencia. Este es un resultado de ejemplo:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Para comprender la causa raíz, debes establecer una conexión SSH al nodo que tenga el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x
Solución alternativa:
|
Revisiones y actualizaciones |
1.11, 1.12 |
No se conservan los componentes de GMP de implementación automática después de la actualización a la versión 1.12
Si usas una versión de clústeres de Anthos alojados en VMware anterior a la 1.12 y configuraste de forma manual los componentes de Prometheus administrados por Google (GMP) en el espacio de nombres gmp-system de tu 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 configurada en false de forma predeterminada. Si implementas de forma manual los componentes de GMP en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver borrará los recursos.
Solución alternativa:
|
Operación |
1.11, 1.12, 1.13.0 - 1.13.1 |
Faltan objetos de ClusterAPI en la situación system de la instantánea del clúster
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 incluirlos.
Solución alternativa:
Puedes ejecutar los siguientes comandos de forma manual 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 y 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 borras, actualizas o actualizas 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 de árbol en el clúster 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
Este es 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 detectes un error que asegura que el desvío de nodo se detenga 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 donde 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, 1.13, 1.14 |
Se borrarán Cluster Autoscaler clusterrolebinding y clusterrole después de borrar un clúster de usuario.
Cuando se borra el clúster de usuario, también se borran los clusterrole y clusterrolebinding correspondientes para el escalador automático del clúster. Esto afecta a todos los demás clústeres de usuario en el mismo clúster de administrador con el escalador automático habilitado. Esto se debe a que se usan el mismo clúster de funciones y atributos Clusterrolebinding para todos los Pods del escalador automático de clústeres dentro del mismo clúster de administrador.
Los síntomas son los siguientes:
- Registros
cluster-autoscaler
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
En el comando anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
A continuación, se muestra un ejemplo de mensajes de error que puedes ver:
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
Solución alternativa:
Ver pasos alternativos
Verifica si faltan la función Clusterrole y Clusterrolebinding en el clúster de administrador
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Aplica el siguiente clúster o función de vinculación de clústeres al clúster de administrador si faltan. Agrega los asuntos de la cuenta de servicio a la vinculación de clúster para cada clúster de usuario.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
Configuración |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
El clúster de administrador cluster-health-controller y vsphere-metrics-exporter no funcionan después de borrar el clúster de usuario
Cuando se borra el clúster de usuario, también se borra el clusterrole correspondiente, lo que hace que el exportador de métricas de reparación automática y de vSphere no funcione.
Los síntomas son los siguientes:
- Registros
cluster-health-controller
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
En el comando anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
A continuación, se muestra un ejemplo de mensajes de error que puedes ver:
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 comando anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
A continuación, se muestra un ejemplo de mensajes de error que puedes ver:
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 alternativos
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 el controlador del estado del clúster
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 la imagen de SO
Es un problema conocido que puede generar un error 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á y se mostrará 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 puede actualizar los grupos antiafinidad
Se produjo un error conocido que podía fallar el gkectl update admin/cluster cuando se actualizaba anti affinity groups .
El síntoma es que el comando gkectl update fallará y se mostrará 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 alternativos
Para que se aplique la actualización, 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 del administrador y del usuario principal
Para la actualización del clúster de usuario, se deben volver a crear los nodos trabajadores del usuario.
Volver a crear los nodos trabajadores del usuario
Opción 1 Sigue actualiza 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 recrear 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 recrear 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 recrear las máquinas, una a la vez
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
Instalación, actualizaciones y actualizaciones |
1.13.0-1.13.8, 1.14.0-1.14.4 y 1.15.0 |
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 CSRs pendientes de un nodo, ejecute el siguiente comando:
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.
A continuación, se muestra un ejemplo de mensajes de error que puedes ver: "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 bloqueo 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 y el nombre de nodo de la VM 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 puede iniciarse.
Solución alternativa:
Clúster de usuario
Para inhabilitar la verificación del ID del nodo, completa los siguientes pasos:
- Agrega los siguientes campos al archivo de configuración del 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 editar:
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 en el inicio de la máquina del plano de control del administrador causada por el paquete de certificado del registro privado
La creación o actualización del clúster de administrador se bloquea en el siguiente registro para siempre 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
Esta es una ruta de archivo de ejemplo 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 simultáneo
En networkgatewaygroups.status.nodes , algunos nodos cambian entre NotHealthy y Up .
Los registros del Pod ang-daemon que se ejecuta en ese nodo muestran 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 mayor carga en otros nodos o una falta de redundancia para la alta disponibilidad.
De lo contrario, la actividad del plano de datos no se verá afectada.
La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a un error en el control de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager verá que el nodo supera su límite de tiempo de funcionamiento y lo marca como NotHealthy .
El error en el manejo de reintentos se corrigió en versiones posteriores.
Solución alternativa:
Actualiza a una versión fija, cuando esté disponible.
|
Revisiones y actualizaciones |
1.12.0 a 1.12.2, 1.13.0 |
La condición de carrera bloquea la eliminación del objeto de la máquina durante la actualización o
la actualización.
Un problema conocido que puede hacer que la actualización o actualización del clúster se detenga en espera de la eliminación del objeto de máquina anterior. Esto se debe a que el finalizador no se puede quitar del objeto de máquina. Esto afecta a cualquier operación de actualización progresiva para 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 , se muestran los siguientes errores:
$ 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 rápidamente, pero en algunos casos poco frecuentes puede quedarse en esta condición de carrera durante varias horas.
El problema es que la VM subyacente ya se borra en vCenter, pero el objeto de máquina correspondiente no se puede quitar, que se detiene en la eliminación del finalizador debido a las actualizaciones muy frecuentes de otros controladores.
Esto puede provocar 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, según tu entorno y tus requisitos.
Si encuentras este problema y la actualización o actualización no se puede completar después de mucho tiempo, comunícate con nuestro equipo de asistencia al cliente para obtener mitigaciones.
|
Instalación, actualizaciones y actualizaciones |
1.10.2, 1.11, 1.12, 1.13 |
gkectl prepara la falla de comprobació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, 1.13 |
La URL de vCenter con el prefijo https:// o http://
puede provocar fallas en el 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 admite "/" ni ":".
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 |
Pánico en gkectl prepare 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 del administrador reanudable no funcionan en conjunto
Después de un intento de actualización con errores del clúster de administrador, no ejecutes gkectl
repair admin-master . Si lo haces, es posible que los intentos de actualización posteriores del administrador
fallen con problemas como la falla de la instancia principal del administrador en caso de falla o la
VM a la que no se puede acceder.
Solución alternativa:
Si ya encontraste esta situación de error, comunícate con el equipo de asistencia.
|
Revisiones y actualizaciones |
1.10 a 1.11 |
La actualización reanudada del clúster de administrador puede provocar que falte una plantilla de VM
del plano de control del administrador
Si la máquina del plano de control del administrador no se vuelve a crear después de un intento de actualización
del clúster de administrador reanudada, se borra la
plantilla de la VM del plano de control de administrador. La plantilla de VM del plano de control del administrador es la plantilla de la instancia principal
del 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, el cgroup v2 (unificado) está habilitado de forma predeterminada para los nodos de Container Optimized OS (COS). Esto podría causar inestabilidad en las cargas de trabajo de un clúster de COS.
Solución alternativa:
En la versión 1.12.1, cambiamos a cgroup v1 (híbrido). Si usas
nodos de COS, te recomendamos que actualices 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 cualquier cambio manual que hayas realizado al recurso personalizado ClientConfig.
Solución alternativa:
Te recomendamos que crees 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 gkectl check-config falla: no se pueden encontrar las particiones de BIG-IP de
F5.
La validación falla porque no se pueden encontrar las particiones de BIG-IP de F5, aunque existan.
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 a causa de
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 alternativos
Ejecuta los siguientes comandos para mitigar el problema.
Primero, reduce la escala de monitoring-operator para que no revierta los cambios a la Deployment cert-manager :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Edita la Deployment 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 cert-manager-cainjector debe 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 monitoring-operator réplicas en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio.
Una vez finalizada la instalación y de que 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 del
administrador
Antes de comenzar el proceso de actualización del clúster de administrador, debes asegurarte de que
los certificados del clúster de administrador sean válidos y renovarlos
si no lo son.
Si comenzaste el proceso de actualización y encontraste un error relacionado con el vencimiento del certificado, comunícate con Atención al cliente de Google para obtener asistencia.
Nota: Esta guía es solo para la renovación de los certificados del clúster de administrador.
Solución alternativa:
Ver pasos alternativos
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 vencieron, debes renovarlos antes de actualizar
el clúster de administrador.
- 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 por client-certificate-data y client-key-data en el archivo new_admin.conf que creaste.
- Crea copias de seguridad de certificados anteriores. Este es un paso opcional, pero recomendado:
# ssh into admin master if you didn't in the previous step
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
- 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, para las versiones anteriores a la 7.0U2, se reinicia después de una actualización, de lo contrario, el nombre de red en la información de VM de vCenter es incorrecto y la máquina tiene el estado Unavailable . De esta manera, con el tiempo, los nodos se repararán automáticamente para crear otros nuevos.
Error de govmomi.
Solución alternativa:
La solución alternativa la proporciona la asistencia de VMware:
- El problema se corrigió 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 versión 1.7.2 y posteriores, las imágenes del SO Ubuntu se endurecen con la
comparativa de servidores CIS L1.
Para cumplir con la regla de 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 tu cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y es posible que el comando finalice con el siguiente mensaje:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solución alternativa:
Tienes varias opciones:
Asegúrate de volver a conectar tu sesión SSH.
|
Instalación |
1.10, 1.11, 1.12, 1.13 |
Instalación cert-manager en conflicto
En las versiones 1.13, monitoring-operator instalará cert-manager en el espacio de nombres cert-manager . Si por algún motivo necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:
Solo debes aplicar este trabajo alrededor de una vez para cada clúster, y los
cambios se conservarán en 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) puede 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:
Evita conflictos durante la actualización
- Desinstala tu versión de
cert-manager . Si definiste
tus propios recursos, te recomendamos
crear una copia de seguridad
.
- Realiza la actualización.
- Sigue estas instrucciones para restablecer tu propio
cert-manager .
Restablece tu propio cert-manager en los clústeres de usuario
- Escala la Deployment
monitoring-operator a 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Escala las implementaciones
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 los recursos personalizados, si los tienes.
- Puedes omitir este paso si usas la
instalación predeterminada de cert-manager ascendente o si estás seguro de que 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 del emisor de metrics-pki.cluster.local de cert-manager en el 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 los clústeres de administrador
En general, no es necesario volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan clústeres de Anthos en cargas de trabajo del plano de control de VMware. En los casos excepcionales en los que también necesites instalar tu propio cert-manager en los clústeres de administrador, sigue las siguientes instrucciones para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y 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
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 los recursos personalizados, si los tienes.
- Puedes omitir este paso si usas la
instalación predeterminada de cert-manager ascendente o si estás seguro de que 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 del emisor de metrics-pki.cluster.local de cert-manager en el 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 de Ubuntu OS 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 de entorno de ejecución de contenedores califiquen
los clústeres de Anthos alojados en VMware antes de cada lanzamiento.
Sin embargo, el rastreador de CVE de Ubuntu no conoce las versiones especiales, las cuales se usan como feeds de vulnerabilidades por parte de varias herramientas de análisis de CVE. 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 tus resultados de análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de los clústeres de Anthos alojados en VMware.
Consulta las notas de la versión para conocer las correcciones de CVE.
Solución alternativa:
Canonical está al tanto de este problema y se realiza un seguimiento de la solució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 webhook no están disponibles por poco tiempo. Este tiempo de inactividad puede ser de hasta un minuto. Esto sucede porque kube-apiserver controla la solicitud entrante (kubectl exec, kubectl log and webhook). El usuario kube-apiserver es un
Statefulset. En un clúster que no tiene alta disponibilidad, solo hay una réplica para
Statefulset. Por lo tanto, durante la actualización, existe la posibilidad de que el antiguo kube-apiserver 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 más breve durante la actualización, te recomendamos que cambies a clústeres de alta disponibilidad.
|
Instalación, actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
No se pudo verificar la preparación de Konnectivity en el diagnóstico del clúster con alta disponibilidad después de
crearlo o actualizarlo
Si estás creando o actualizando un clúster con alta disponibilidad y observas que la verificación de preparación de Konectivity 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, a veces, una o dos de las réplicas de contención pueden no estar listas para un período de tiempo debido a problemas de red inestables 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, 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 con la
comparativa del servidor
CIS L1.
Como resultado, se instaló la secuencia de comandos cron /etc/cron.daily/aide para programar una verificación de aide a fin de garantizar que se siga 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 aumentos repentinos de uso de CPU y memoria en ese momento.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 distribuidas con estado de NSX-T, stackdriver-operator puede que no cree gke-metrics-agent-conf de ConfigMap y cause que los Pods gke-connect-agent estén en un bucle de fallas.
El problema subyacente es que las reglas de firewall distribuidas con NSX-T con estado 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 porque Seesaw usa flujos de conexión asimétricas. Los problemas de integración con las reglas de firewall distribuidas 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 creen objetos grandes de Kubernetes con tamaños superiores 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 el balanceador de cargas a fin de restablecer las conexiones de los
clientes cuando detecte una falla en el nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes podrían 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, 1.15 |
Facturación inesperada de supervisión
En el caso de los clústeres de Anthos alojados en VMware 1.10 a la versión más reciente, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo te afecta cuando se aplican todas las siguientes circunstancias:
- La supervisión de aplicaciones está habilitada (
enableStackdriverForApplications=true )
- El servicio administrado para Prometheus no está habilitado (
enableGMPForApplications ).
- Los Pods de la aplicación tienen la anotación
prometheus.io/scrap=true . Instalar Anthos Service Mesh también puede agregar esta anotación.
Para confirmar si este problema te afecta, enumera las métricas definidas por el usuario. Si ves la facturación por métricas no deseadas, este problema se aplica a tu caso.
Solución alternativa
Si este problema te afecta, te recomendamos que actualices los clústeres a la versión 1.12 y cambie a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que resuelve este problema:
Marcas independientes para controlar la recopilación de registros de aplicaciones frente a las métricas de aplicaciones
Google Cloud Managed Service para Prometheus
Si no puedes actualizar a la versión 1.12, sigue estos pasos:
- Busca los Pods y servicios de origen que tienen el no deseado facturado.
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. Si se agrega la anotación mediante Anthos Service Mesh, considera
configurar Anthos Service Mesh sin la opción Prometheus
o desactivar la función de combinación de métricas de Istio.
|
Instalación |
1.11, 1.12, 1.13 |
El instalador falla cuando se crea el disco de datos de vSphere
El instalador de 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, se crea un disco de datos de vSphere con govc que 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 vSphere vCenter (raíz).
Solución alternativa:
Si deseas vincular la función personalizada a nivel de DC (o un valor 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 tráfico de red alto en
monitoring.googleapis.com , incluso en un clúster nuevo que no tiene
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 alternativos
Actualiza a la versión 1.10.2/1.9.5 o una 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 a 1.11 |
gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff
Para los clústeres de Anthos alojados en VMware versión 1.10 y posteriores, “gke-metrics-agent” DaemonSet tiene errores frecuentes de CrashLoopBackOff cuando “enableStackdriverForApplications” se configura como “true” en el objeto “stackdriver”.
Solución alternativa:
Para mitigar este problema, inhabilita la recopilación de métricas de la aplicación ejecutando 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 , comenta toda la sección metrics/app-metrics :
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 que dejaron de estar disponibles
- Borra “Estado del nodo de GKE On-Prem” en el panel de
Google Cloud Monitoring. Vuelve a instalar el estado del nodo de GKE On-Prem. Para ello, sigue
estas instrucciones.
- Borra “Uso de nodos de GKE On-Prem” en el panel de
Google Cloud Monitoring. Vuelve a instalar el “uso de nodos de GKE On-Prem” según
estas instrucciones.
- Borra “Estado de la VM de vSphere de GKE On-Prem” en el panel de
Google Cloud Monitoring. Vuelve a instalar “GKE On-Prem vSphere VM health”
siguiendo
estas instrucciones.
Esta baja se debe a la actualización del agente
kube-state-metrics de la versión 1.9 a la 2.4, que es necesaria para
Kubernetes 1.22. Puedes reemplazar todas las métricas
kube-state-metrics obsoletas, 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 versión 1.10 y superior, 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
Otros tipos de métricas que pueden tener métricas de resumen irrelevantes incluyen los siguientes:
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, no son compatibles con gke-metrics-agent 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+ y 1.11.0], sigue los pasos 1 a 4 a fin de 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 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 del programador y del administrador en el clúster de administrador
Si tu clúster se ve afectado por este problema, faltan las métricas
del programador y del administrador-controlador. 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:
Actualiza a la versión 1.11.3 o posterior, o a la versión 1.12.1 o posterior.
|
|
1.11.0-1.11.2, 1.12.0 |
Faltan métricas del programador y del administrador-controlador en el clúster de usuario
Si este problema afecta a tu clúster de usuario, faltan las métricas del programador y del administrador-controlador. 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:
Este problema se solucionó en los clústeres de Anthos alojados en VMware versión 1.13.0 y posteriores.
Actualiza el clúster a una versión con la solución.
|
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 se registra 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 actualizarlo 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 alternativos
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 la cuenta de servicio correcta.
- Crea una cuenta de servicio dedicada para aplicar un parche al 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:
|
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 del 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 (APIC) de Cisco.
Para configurar la opción de IP virtual L4-L7, ve a Tenant > Application Profiles > Application EPGs o uSeg EPGs. Si no se inhabilita el aprendizaje de IP, se moverá el extremo de IP entre diferentes ubicaciones de la estructura de la API de Cisco.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Problemas de vSphere 7.0 con la actualización 3
Recientemente, VMWare identificó problemas críticos con las siguientes versiones de Actualización 3 de vSphere 7.0:
- vSphere ESXi 7.0 Update 3 (compilación 18644231)
- vSphere ESXi 7.0 Update 3a (compilación 18825058)
- vSphere ESXi 7.0 Update 3b (compilación 18905247)
- vSphere vCenter 7.0 Update 3b (compilación 18901211)
Solución alternativa:
Desde entonces, VMWare quitó estas versiones. Debes actualizar ESXi y los servidores de vCenter 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 los nodos de 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 ,
verás la opción noexec:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Solución alternativa:
Ver pasos alternativos
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 que se inhabilita el
ajuste de escala automático en el grupo de nodos.
Las réplicas del grupo de nodos no se actualizan una vez que se habilita o se inhabilita el ajuste de escala automático en un grupo de nodos.
Solución alternativa:
Se quitaron 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 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 de estado del nodo de Windows también muestran datos de clústeres de Linux. Esto se debe a que las métricas del Pod y del nodo de Windows también se exponen en clústeres de Linux.
|
Registro y supervisión |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder en CrashLoopBackOff constante
Para los clústeres de Anthos alojados en VMware versión 1.10, 1.11 y 1.12, stackdriver-log-forwarder
Es posible que DaemonSet tenga errores CrashLoopBackOff cuando haya registros
almacenados en búfer en el disco.
Solución alternativa:
Para mitigar este problema, debemos 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 del 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"}]'
|
Registro y supervisión |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
stackdriver-log-forwarder no envía registros a Cloud Logging
Si no ves registros en Cloud Logging de tus clústeres y observas el siguiente error en tus registros:
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
Es probable que la tasa de entrada de registros supere el límite del agente de Logging, lo que hace que stackdriver-log-forwarder no envíe registros.
Este problema ocurre en todas las versiones de clústeres de Anthos alojados en VMware.
Solución alternativa:
Para mitigar este problema, debes aumentar el límite de recursos del agente de Logging.
- Abre tu recurso
stackdriver para editarlo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Para aumentar la solicitud de CPU de
stackdriver-log-forwarder , agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
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:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
- 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 stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
El comando encuentra cpu: 1200m si tus ediciones se aplicaron.
|
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 responsable de aprobación 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 se actualizó por completo y la versión de estado aún
es 1.10. Ninguna verificación previa verificará la actualización del clúster de usuario a la versión 1.12 y fallará con un problema de sesgo de versión.
Solución alternativa:
Completa el paso para actualizar el clúster de administrador a la versión 1.11 y, luego,
actualiza a 1.12.
|
Almacenamiento |
1.10.0-1.10.5, 1.11.0-1.11.2 y 1.12.0 |
Datastore informa de manera incorrecta espacio 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 existente y se agregó por error por gkectl diagnose cluster .
Solución alternativa:
Puedes ignorar el mensaje de error o, también, omitir la validación mediante --skip-validation-infra .
|
Operación, Herramientas de redes |
1.11, 1.12.0-1.12.1 |
Es posible que no puedas agregar un clúster de usuario nuevo si el de administrador tiene
una configuración de balanceador de cargas de MetalLB.
El proceso de eliminación del clúster de usuario puede bloquearse por algún motivo, lo que genera una invalidación del ConfigMap de MatalLB. No será posible agregar un clúster de usuario nuevo en este estado.
Solución alternativa:
Puedes
forzar la eliminación del 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 se ejecuta gkectl check-config después de la creación del clúster
de administrador y antes de la creación de un clúster de usuario, fallará:
Failed to create the test VMs: VM failed to get IP addresses on the network.
La VM de prueba creada para el clúster de usuario check-config usa
de forma predeterminada el mismo osImageType del clúster de administrador, y
la VM de prueba aún no es compatible con COS.
Solución alternativa:
Para evitar la verificació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 a 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 las versiones 1.12.0 y 1.12.1 de VMware. Proviene de una discrepancia entre los certificados del cliente de pushprox en los clústeres
de usuarios y la lista de entidades permitidas en el servidor pushprox del clúster de administrador.
El síntoma es pushprox-client en clústeres de usuario que imprimen registros de error como el siguiente:
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 alternativos
realiza los siguientes pasos:
- Reduce la implementación de supervisión-operador en el espacio de nombres de 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 de kube-system del clúster de administrador.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Ubica 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 solucionó 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 del plano de control de administrador termina con los caracteres t ,
m , p o l .
Solución alternativa:
Vuelve a ejecutar el comando con --skip-validation .
|
Registro y supervisión |
1.11, 1.12, 1.13, 1.14, 1.15 |
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 del 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 tenga el permiso adecuado que necesita.
Sin embargo, en los casos en que el clúster de administrador use un ID del 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 insertarían en la nube. El síntoma es una serie de errores Permission Denied en el Pod audit-proxy del clúster de administrador.
Solución alternativa:
Ver pasos alternativos
Para resolver este problema, el permiso se puede configurar interactuando con la función de concentrador cloudauditlogging :
- Primero, verifica las cuentas de servicio existentes incluidas en la lista de entidades permitidas de Cloud Audit Logging de Anthos 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 recibiste un error
404 Not_found , significa que no hay una cuenta de servicio incluida en la lista de entidades permitidas para este ID del proyecto. Para incluir una cuenta de servicio en la lista de entidades permitidas, habilita la función de concentrador cloudauditlogging :
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
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 del centro de Cloudauditlogging y vuelve a habilitarla después del paso 1 de esta sección. Puedes borrar la función cloudauditlogging de Hub de la siguiente manera:
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:
|
Operación, seguridad |
1.11 |
gkectl diagnose reprobando errores en los certificados
Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, se producirán 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 tu 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 mostrará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, 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 de gkectl en la estación de trabajo de administrador, como gkectl diagnose snapshot , contribuyen al uso del espacio en el disco.
A partir de Anthos v1.8, la imagen de Ubuntu se endurece con la comparativa de CIS de nivel 2. Además, una de las reglas de cumplimiento, “4.1.2.2, Garantiza que los registros de auditoría no se borren automáticamente”, garantiza la configuración auditada de 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 alternativos
Estación de trabajo de administrador
En la estación de trabajo de administrador, puedes cambiar de forma manual la configuración auditada para rotar los registros de forma automática y, luego, reiniciar el servicio auditd:
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 la auditoría rote automáticamente sus registros una vez que se generen más de 250 archivos (cada uno con un tamaño de 8 millones).
Nodos del clúster
Para 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, 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 la realización de este cambio de configuración auditado infringiría la regla 4.1.2.2 de CIS de nivel 2 para garantizar que no se borren automáticamente los registros de auditoría.
|
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 . El webhook de validación compara las direcciones IP flotantes de NetworkGatewayGroup con todas las node.status.addresses del clúster y lo ve como 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 temporalmente el webhook de validación de ANG y envía el cambio:
- Guarda la configuración del webhook para que pueda restablecerse 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 |
Crear o actualizar el tiempo de espera del clúster de administrador
Durante un intento de actualización del clúster de administrador, es posible que la VM del plano de control del administrador se detenga 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 los clústeres de Anthos alojados en VMware intentan obtener la dirección IP del nodo en la secuencia de comandos de inicio, usa 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, la VM del plano de control se detendrá durante la creación. Este problema también se puede priorizar 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:
|
Sistema operativo, actualizaciones y actualizaciones |
1.10.0-1.10.2 |
El estado del clúster de administrador que use la imagen COS se perderá cuando
se actualice el clúster o se realice la reparación de la instancia principal del administrador
DataDisk no se puede activar de forma correcta en el nodo instancia principal del clúster de administrador cuando
se usa la imagen de COS, y el estado del clúster de administrador que usa la imagen de COS
se perderá cuando se actualice el clúster del administrador o se repare la instancia principal. (el clúster de administrador que usa la 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 SSH en el nodo de la instancia principal de 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. El motivo es que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado con un archivo sym a /run/systemd/resolve/stub-resolv.conf , que apunta al stub de DNS de 127.0.0.53 .
Como resultado, la resolución de nombres de DNS de localhost se niega a verificar 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 para 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 omitir el stub que resuelve el sistema local. Para ello, cambia el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local 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 resolver este problema con este paso manual.
Esta solución no se conserva durante 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 de Ubuntu con el que se ignoraba la configuración personalizada de Docker.
Como resultado, Docker elige el 172.17.0.1/16 predeterminado 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:
A fin de solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración de systemd para 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 durante las recreaciones de VM. Debes volver a aplicar
esta solución alternativa cada vez que se vuelvan a crear las VM.
|
Revisiones y actualizaciones |
1.11 |
La preparación está bloqueada y se actualizó a la versión 1.11.
En la versión 1.11.0 de los clústeres de Anthos alojados en VMware, hay cambios en la definición de recursos personalizados relacionados con el registro y la supervisión:
- El nombre del grupo del recurso personalizado
stackdriver cambió de addons.sigs.k8s.io a addons.gke.io .
- El nombre del grupo de los recursos personalizados
monitoring y metricsserver cambió de addons.k8s.io a addons.gke.io ;
- Las especificaciones de los recursos anteriores se comienzan a medir según su esquema. En especial, las especificaciones resourceAttrOverride y storageSizeOverride en el recurso personalizado
stackdriver deben tener un tipo de string en los valores de las solicitudes y los límites de tamaño de CPU, memoria y almacenamiento.
Los cambios en los nombres de los grupos se realizan para cumplir con las actualizaciones de CustomResourceDefinition en Kubernetes 1.22.
No es necesario que realice ninguna acción si no tiene una lógica adicional que aplique o edite los recursos personalizados afectados. El proceso de actualización de los clústeres de Anthos alojados en VMware se encargará de la migración de los recursos afectados y mantendrá sus especificaciones existentes después del cambio de nombre del grupo.
Sin embargo, si ejecutas alguna lógica que aplique o edite los recursos afectados, se debe prestar especial atención. Primero, se debe hacer referencia a ella con el nuevo nombre del grupo en tu archivo de manifiesto. Por ejemplo:
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
En segundo lugar, asegúrate de que los valores de especificación resourceAttrOverride y storageSizeOverride sean del tipo string. Por ejemplo:
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder
limits:
cpu: 1000m # or "1"
# cpu: 1 # integer value like this would not work
memory: 3000Mi
De lo contrario, las aplicaciones y las modificaciones no surtirán efecto y es posible que generen un estado inesperado en los componentes de registro y supervisión. Estos son algunos de los posibles síntomas:
- Registros de errores de conciliación en
onprem-user-cluster-controller , por ejemplo:
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
- Error en
kubectl edit stackdriver stackdriver , por ejemplo:
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Si ves los errores anteriores, significa que ya había un tipo no compatible con la especificación de CR de Stackdriver antes de la actualización. Como solución alternativa, puedes editar manualmente la CR de Stackdriver con el nombre anterior del grupo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver y hacer lo siguiente:
- Cambiar las solicitudes y los límites de recursos al tipo de string
- Quita cualquier anotación
addons.gke.io/migrated-and-deprecated: true si está presente.
Luego, reanuda o reinicia el proceso de actualización.
|
Sistema operativo |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
Las VM de COS no muestran IP cuando las VM se mueven a través del cierre incorrecto del host
Cuando hay un error en un servidor ESXi y la función de alta disponibilidad de vCenter se habilita para el servidor, todas las VMs del servidor ESXi con errores activan el mecanismo de vMotion y se mueven a otro servidor ESXi normal. Las VMs migradas de COS perderán sus IP.
Solución alternativa:
Reiniciar la VM
|