| Instalación |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
No se permite CIDR en el archivo de bloque de IP
Cuando los usuarios usen CIDR en el archivo de bloque de IP, la validación de configuración fallará con el siguiente error:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Solución:
Incluye las IP individuales en el archivo de bloque de IP hasta que actualices a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1+.
|
| Revisiones y actualizaciones |
1.14.0-1.14.1 |
La actualización del tipo de imagen de SO en admin-cluster.yaml no espera a que se vuelvan a crear las máquinas del plano de control del usuario
Cuando actualiza el tipo de imagen de SO del plano de control en admin-cluster.yaml y si el clúster de usuario correspondiente se creó a través de Controlplane V2, es posible que las máquinas del plano de control de usuario no vuelvan a crear una vez que finalice el comando gkectl.
Solución:
Una vez que finalice la actualización, supervisa los tipos de imágenes de SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide y continúa esperando que las máquinas del plano de control de usuario terminen la recreación. P.ej., si actualizas de Ubuntu a COS, debes esperar a que todas las máquinas del plano de control cambien por completo de Ubuntu a COS, incluso después de que se complete el comando de actualización.
|
| Operación |
1.14.0 |
Errores en la creación o eliminación del Pod debido a un problema de token de autenticación de la cuenta de servicio de la CNI Calico
Un problema con Calico en clústeres de Anthos alojados en VMware 1.14.0 hace que la creación y la eliminación de pods falle con el siguiente mensaje de error en el resultado de kubectl describe pods:
error getting ClusterInformation: connection is unauthorized: Unauthorized
Este problema solo se observa 24 horas después de que se crea el clúster o se actualiza a la versión 1.14 mediante Calico.
Los clústeres de administrador siempre usan Calico, mientras que para los clústeres de usuario hay un campo de configuración `enableDataPlaneV2` en user-cluster.yaml. Si ese campo se establece en `false`, o no se especifica, significa que estás usando Calico en el clúster de usuario.
El contenedor install-cni de los nodos crea un kubeconfig con un token que es válido durante 24 horas. El pod calico-node debe renovar este token de forma periódica. El pod calico-node no puede renovar el token, ya que no tiene acceso al directorio que contiene el archivo kubeconfig en el nodo.
Solución alternativa:
Para mitigar el problema, aplica el siguiente parche en el DaemonSet de calico-node en tu clúster de administrador y de usuario:
kubectl -n kube-system get daemonset calico-node \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
kubectl -n kube-system get daemonset calico-node \
--kubeconfig USER_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Reemplaza lo siguiente:
ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.
|
| Instalación |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
La validación del bloque de IP falla cuando se usa CIDR
La creación del clúster falla a pesar de que el usuario tenga la configuración adecuada. El usuario ve que la creación falla debido a que el clúster no tiene suficientes IP.
Solución:
Divide los CIDR en varios bloques más pequeños, como 10.0.0.0/30, que se convierte en 10.0.0.0/31, 10.0.0.2/31. Siempre que haya N+1 CIDR, donde N es la cantidad de nodos en el clúster, esto debería ser suficiente.
|
| Operación, actualizaciones y actualizaciones |
1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6 |
La copia de seguridad del clúster de administrador no incluye la configuración de las claves de encriptación de secretos siempre activas
Cuando la función de encriptación de secretos siempre activa está habilitada junto con la copia de seguridad de los clústeres, la copia de seguridad de los clústeres de administrador no puede incluir las claves ni la configuración que requiere la encriptación de secretos siempre activa. Como resultado, reparar la instancia principal del administrador con esta copia de seguridad mediante gkectl repair admin-master --restore-from-backup genera el siguiente error:
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Solución alternativa:
- Usa el objeto binario de gkectl de la versión de parche más reciente disponible para la versión secundaria correspondiente a fin de realizar la copia de seguridad del clúster de administrador después de las operaciones críticas del clúster. Por ejemplo, si el clúster ejecuta una versión 1.10.2, usa el objeto binario gke.1.10.5 para realizar una copia de seguridad del clúster de administrador manual como se describe en Cómo crear una copia de seguridad y restablecer un clúster de administrador con gkectl.
|
| Operación, actualizaciones y actualizaciones |
1.10+ |
Volver a crear la VM de administrador principal con un disco de arranque nuevo (p.ej., gkectl repair admin-master) fallará si la función de encriptación de secretos siempre activa está habilitada con el comando “gkectl update”.
Si la función de encriptación de secretos siempre activa no está habilitada en la creación del clúster, pero se habilita más tarde mediante la operación gkectl update, gkectl repair admin-master no podrá reparar el nodo del plano de control del clúster de administrador. Se recomienda que la función de encriptación de secretos siempre activa esté habilitada en la creación del clúster. Por el momento, no existe una mitigación.
|
| Revisiones y actualizaciones |
1.10 |
La actualización del primer clúster de usuario de 1.9 a 1.10 recrea los nodos en otros clústeres de usuario
Si actualizas el primer clúster de usuario de 1.9 a 1.10, es posible que los nodos de otros clústeres de usuario se vuelvan a crear en el mismo clúster de administrador. La recreación se realiza de manera progresiva.
Se quitó disk_label de MachineTemplate.spec.template.spec.providerSpec.machineVariables, lo que activó una actualización en todos los MachineDeployment de forma inesperada.
Solución alternativa:
Ver pasos para solucionarlos
- Reduce la réplica de
clusterapi-controllers a 0 para todos los clústeres de usuario.
kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Actualiza cada clúster de usuario uno por uno.
|
| Revisiones y actualizaciones |
1.10.0 |
Docker se reinicia con frecuencia después de la actualización del clúster
Actualizar el clúster de usuario a 1.10.0 podría provocar que Docker se reinicie con frecuencia.
Para detectar este problema, ejecuta kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG
Una condición de nodo mostrará si el Docker se reinicia con frecuencia. A continuación, se muestra un ejemplo de resultado:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Para comprender la causa raíz, debes establecer una conexión SSH al nodo que tenga el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x
Solución alternativa:
|
| Revisiones y actualizaciones |
1.11 a 1.12 |
Los componentes de GMP implementados automáticamente no se conservan después de actualizar a la versión 1.12
Si usas clústeres de Anthos alojados en la versión de VMware 1.12 y configuraste de forma manual los componentes de Prometheus administrados por Google (GMP) en el espacio de nombres de gmp-system para el clúster, los componentes no se conservarán cuando actualices a la versión 1.12.x.
A partir de la versión 1.12, los componentes de GMP en el espacio de nombres gmp-system y las CRD se administran mediante el objeto stackdriver, con la marca enableGMPForApplications establecida en false de forma predeterminada. Si implementas de forma manual los componentes de GMP en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver borrará los recursos.
Solución alternativa:
|
| Operación |
1.11, 1.12, 1.13.0 - 1.13.1 |
Faltan objetos ClusterAPI en la situación de instantánea de clúster system
En la situación system, la instantánea del clúster no incluye ningún recurso en el espacio de nombres default.
Sin embargo, algunos recursos de Kubernetes, como los objetos de la API de clúster que se encuentran en este espacio de nombres, contienen información de depuración útil. La instantánea del clúster debe incluirlas.
Solución alternativa:
Puedes ejecutar de forma manual los siguientes comandos para recopilar la información de depuración.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
Donde:
USER_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de usuario.
|
| Revisiones y actualizaciones |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
La eliminación del clúster de usuario se detuvo en el vaciado de nodos para la configuración de vSAN
Cuando se borra, actualiza o actualiza un clúster de usuario, el desvío de nodos puede detenerse en las siguientes situaciones:
- El clúster de administrador usa el controlador de CSI de vSphere en vSAN desde la versión 1.12.x.
- No hay objetos PVC/PV creados por complementos de vSphere en el árbol de clústeres de administrador y de usuario.
Para identificar el síntoma, ejecuta el siguiente comando:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Aquí hay un mensaje de error de muestra del comando anterior:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols es el directorio predeterminado para el controlador en árbol de vSphere. Cuando no se crean objetos PVC/PV, es posible que se produzca un error que impedirá que el nodo se bloquee en la búsqueda de kubevols, ya que la implementación actual supone que kubevols siempre existe.
Solución alternativa:
Crea el directorio kubevols en el almacén de datos en el que se crea el nodo. Esto se define en el campo vCenter.datastore en los archivos user-cluster.yaml o admin-cluster.yaml.
|
| Configuración |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13 |
Los clústeres de administrador cluster-health-controller y vsphere-metrics-exporter no funcionan después de borrar el clúster de usuario
En la eliminación del clúster de usuario, también se borra el clusterrole correspondiente, lo que provoca que el exportador de métricas de vSphere y la reparación automática no funcionen.
Los síntomas son los siguientes:
- Registros
cluster-health-controller
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
Este es un ejemplo de mensajes de error que pueden aparecer:
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
Registros vsphere-metrics-exporter
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
Este es un ejemplo de mensajes de error que pueden aparecer:
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
Solución alternativa:
Ver pasos para solucionarlos
Aplica el siguiente yaml al clúster de administrador
- Para vsphere-metrics-Exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
Para cluster-health-controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
| Configuración |
1.12.1-1.12.3, 1.13.0-1.13.2 |
gkectl check-config falla en la validación de imagen de SO
Un problema conocido que podría fallar en gkectl check-config sin ejecutar gkectl prepare. Esto es confuso porque sugerimos ejecutar el comando antes de ejecutar gkectl prepare
El síntoma es que el comando gkectl check-config fallará con el siguiente mensaje de error:
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
Solución alternativa:
Opción 1: Ejecuta gkectl prepare para subir las imágenes de SO faltantes.
Opción 2: usa gkectl check-config --skip-validation-os-images para omitir la validación de imágenes de SO.
|
| Revisiones y actualizaciones |
1.11, 1.12, 1.13 |
gkectl update admin/cluster no pudo actualizar los grupos antiafinidad
Un problema conocido que podría fallar en gkectl update admin/cluster cuando se actualice anti affinity groups.
El síntoma es que el comando gkectl update fallará con el siguiente mensaje de error:
Waiting for machines to be re-deployed... ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition
Solución alternativa:
Ver pasos para solucionarlos
Para que la actualización surta efecto, las máquinas deben volver a crearse after con la actualización con errores.
Para la actualización del clúster de administrador, es necesario volver a crear los nodos de administrador principal y del usuario.
Para la actualización del clúster de usuario, es necesario volver a crear los nodos trabajadores del usuario
Para volver a crear los nodos trabajadores del usuario
Opción 1
Sigue cómo actualizar un grupo de nodos y cambia la CPU o la memoria para activar una recreación progresiva de los nodos.
Opción 2
Use kubectl delete para volver a crear las máquinas de a una
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
Para volver a crear los nodos principales del usuario
Opción 1
Sigue el plano de control de cambio de tamaño y cambia la CPU o la memoria para activar una recreación progresiva de los nodos.
Opción 2
Use kubectl delete para volver a crear las máquinas de a una
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Para volver a crear los nodos del complemento de administrador
Use kubectl delete para volver a crear las máquinas una a la vez.
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
| Instalación, actualizaciones y actualizaciones |
1.13.0 |
El registro de nodos falla durante la creación, la actualización, la actualización y la reparación automática de nodos cuando ipMode.type es static y el nombre de host configurado en el archivo de bloqueo de IP contiene uno o más puntos. En este caso, las solicitudes de firma de certificado (CSR) de un nodo no se aprueban de forma automática.
Para ver las CSR pendientes para un nodo, ejecuta el comando siguiente:
kubectl get csr -A -o wide
Revisa los siguientes registros para ver si hay mensajes de error:
- Visualiza los registros en el clúster de administrador del contenedor
clusterapi-controller-manager en el Pod clusterapi-controllers:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n kube-system \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
- Para ver los mismos registros en el clúster de usuario, ejecuta el siguiente comando:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
En el ejemplo anterior, se ilustra lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
- USER_CLUSTER_NAME es el nombre del clúster de usuario.
Este es un ejemplo de mensajes de error que pueden aparecer: "msg"="failed
to validate token id" "error"="failed to find machine for node
node-worker-vm-1" "validate"="csr-5jpx9"
- Visualiza los registros
kubelet en el nodo problemático:
journalctl --u kubelet
A continuación, se muestra un ejemplo de mensajes de error que puedes ver: "Error getting
node" err="node \"node-worker-vm-1\" not found"
Si especificas un nombre de dominio en el campo de nombre de host de un archivo de bloque de IP, se ignorarán los caracteres posteriores al primer período. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host de VM y el nombre de nodo se establecerán en bob-vm-1.
Cuando la verificación de ID de nodo está habilitada, el responsable de aprobación de CSR compara el nombre del nodo con el nombre de host en la especificación de la máquina y no concilia el nombre. El responsable de aprobación rechaza la CSR y el nodo no se inicia.
Solución alternativa:
Clúster de usuario
Para inhabilitar la verificación de ID del nodo, completa los siguientes pasos:
- Agrega los siguientes campos a tu archivo de configuración de clúster de usuario:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Guarda el archivo y actualiza el clúster de usuario mediante la ejecución del siguiente comando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Reemplaza lo siguiente:
ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.
Clúster de administrador
- Abre el recurso personalizado
OnPremAdminCluster para editarlo:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Agrega la siguiente anotación al recurso personalizado:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Edita el manifiesto
kube-controller-manager en el plano de control del clúster de administrador:
- Establece una conexión SSH al nodo del plano de control del clúster de administrador.
- Abre el manifiesto
kube-controller-manager para editarlo:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Busca la lista de
controllers:
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Actualiza esta sección como se muestra a continuación:
--controllers=*,bootstrapsigner,tokencleaner
- Abre el controlador de la API de clúster de implementación para editarlo:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Cambia los valores de
node-id-verification-enabled y node-id-verification-csr-signing-enabled a false:
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
|
| Instalación, actualizaciones y actualizaciones |
1.11.0-1.11.4 |
Falla de inicio de la máquina del plano de control del administrador causada por el paquete de certificados del registro privado
La creación o actualización del clúster de administrador se bloquea en el siguiente registro de forma permanente y, con el tiempo, se agota el tiempo de espera:
Waiting for Machine gke-admin-master-xxxx to become ready...
El registro del controlador de la API de clúster en la instantánea del clúster externo incluye el siguiente registro:
Invalid value 'XXXX' specified for property startup-data
A continuación, se muestra un ejemplo de una ruta de acceso de archivo para el registro del controlador de la API de clúster:
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
VMware has a 64k vApp property size limit. In the identified versions,
the data passed via vApp property is close to the limit. When the private
registry certificate contains a certificate bundle, it may cause the final
data to exceed the 64k limit.
Workaround:
Only include the required certificates in the private registry
certificate file configured in privateRegistry.caCertPath in
the admin cluster config file.
Or upgrade to a version with the fix when available.
|
| Herramientas de redes |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
Se marcó NetworkGatewayNodes como en mal estado debido a un conflicto de actualización de estado concurrente
En networkgatewaygroups.status.nodes, algunos nodos cambian entre NotHealthy y Up.
Los registros del pod ang-daemon que se ejecutan en ese nodo revelan errores repetidos:
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
El estado NotHealthy evita que el controlador asigne IP flotantes adicionales al nodo. Esto puede generar una carga mayor en otros nodos o una falta de redundancia para la alta disponibilidad.
De lo contrario, la actividad del plano de datos no se ve afectada.
La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a un error en el control de los reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager verá que el nodo superó el límite de tiempo de monitoreo de funcionamiento y marca el nodo NotHealthy.
El error en el control de reintentos se corrigió en versiones posteriores.
Solución alternativa:
Actualiza a una versión corregida, cuando esté disponible.
|
| Revisiones y actualizaciones |
1.12.0-1.12.2, 1.13.0 |
La condición de carrera bloquea la eliminación de los objetos de la máquina durante las actualizaciones y las actualizaciones
Un problema conocido que podría provocar que la actualización o la actualización del clúster se detenga mientras esperas que se borre el objeto de máquina anterior. Esto se debe a que no se puede quitar el finalizador del objeto de máquina. Esto afecta a cualquier operación de actualización progresiva de los grupos de nodos.
El síntoma es que el comando gkectl agota el tiempo de espera con el siguiente mensaje de error:
E0821 18:28:02.546121 61942 console.go:87] Exit with error:
E0821 18:28:02.546184 61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
En los registros del pod clusterapi-controller, los errores son los siguientes:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
El error se repite para la misma máquina durante varios minutos en ejecuciones exitosas, incluso sin este error, durante la mayor parte del tiempo puede ejecutarse con rapidez, pero en algunos casos excepcionales puede quedarse en esta condición de carrera durante varias horas.
El problema es que la VM subyacente ya se borró en vCenter, pero no se puede quitar el objeto de máquina correspondiente, que se detiene en la eliminación del finalizador debido a las actualizaciones muy frecuentes de otros controladores.
Esto puede causar que se agote el tiempo de espera del comando gkectl, pero el controlador sigue conciliando el clúster para que se complete el proceso de actualización o actualización.
Solución alternativa:
Preparamos varias opciones de mitigación diferentes para este problema, que dependen de tu entorno y tus requisitos.
Si encuentras este problema y la actualización o actualización aún no se puede completar después de un tiempo prolongado, comunícate con nuestro equipo de asistencia para obtener las mitigaciones.
|
| Instalación, actualizaciones y actualizaciones |
1.10.2, 1.11, 1.12, 1.13 |
gkectl prepara la falla de verificación previa de la validación de imagen de SO
El comando gkectl prepare falló con lo siguiente:
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
Las comprobaciones previas de gkectl prepare incluían una validación incorrecta.
Solución alternativa:
Ejecuta el mismo comando con una marca adicional --skip-validation-os-images.
|
| Instalación |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13 |
La URL de vCenter con el prefijo https:// o http:// puede causar un error de inicio del clúster
No se pudo crear el clúster de administrador con el siguiente comando:
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
La URL se usa como parte de una clave secreta, que no es compatible con "/" o ":".
Solución alternativa:
Quita el prefijo https:// o http:// del campo vCenter.Address en el clúster de administrador o el archivo yaml de configuración del clúster de usuario.
|
| Instalación, actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
gkectl prepare en pánico el util.CheckFileExists
gkectl prepare puede entrar en pánico con el siguiente seguimiento de pila:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...
El problema es que gkectl prepare creó el directorio del certificado de registro privado con un permiso incorrecto.
Solución alternativa:
Para solucionar este problema, ejecuta los siguientes comandos en la estación de trabajo de administrador:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
| Revisiones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
gkectl repair admin-master y la actualización reanudable del administrador no funcionan en conjunto.
Después de un intento de actualización del clúster de administrador con errores, no ejecutes gkectl
repair admin-master. Si lo haces, es posible que los intentos posteriores de actualización del administrador fallen debido a problemas como la falla de la instancia principal del administrador en caso de falla o el acceso a la VM.
Solución alternativa:
Si ya encontraste esta situación de falla, comunícate con el equipo de asistencia.
|
| Revisiones y actualizaciones |
1.10, 1.11 |
La actualización reanudada del clúster de administrador puede generar una falta en la plantilla de VM del plano de control de administrador
Si la máquina del plano de control de administrador no se vuelve a crear después de un intento de actualización del clúster de administrador reanudada, la plantilla de VM del plano de control de administrador se borra. La plantilla de VM del plano de control de administrador es la plantilla de la instancia principal de administrador que se usa para recuperar la máquina del plano de control con gkectl
repair admin-master.
Solución alternativa:
La plantilla de VM del plano de control de administrador se volverá a generar durante la próxima
actualización del clúster de administrador.
|
| Sistema operativo |
1.12 a 1.13 |
cgroup v2 podría afectar las cargas de trabajo
En la versión 1.12.0, cgroup v2 (unificado) está habilitado de forma predeterminada para nodos de Container Optimized OS (COS). Esto podría causar inestabilidad en las cargas de trabajo en un clúster de COS.
Solución alternativa:
Cambiamos a cgroup v1 (híbrido) en la versión 1.12.1. Si usas nodos COS, te recomendamos actualizar a la versión 1.12.1 en cuanto se lance.
|
| Identidad |
1.10, 1.11, 1.12, 1.13 |
Recurso personalizado de ClientConfig
gkectl update revierte los cambios manuales que realizaste en el recurso personalizado ClientConfig.
Solución alternativa:
Te recomendamos crear una copia de seguridad del recurso ClientConfig después de cada cambio manual.
|
| Instalación |
1.10, 1.11, 1.12, 1.13 |
La validación de gkectl check-config falla y no encuentra las particiones de BIG-IP de F5
La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
Solución alternativa:
Vuelve a ejecutar gkectl check-config.
|
| Instalación |
1.12 |
No se pudo instalar el clúster de usuario debido al problema de elección de líder de cert-manager/ca-injector
Es posible que veas una falla de instalación debido a cert-manager-cainjector en el bucle de fallas, cuando apiserver/etcd es lento:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Solución alternativa:
Ver pasos para solucionarlos
Ejecuta los siguientes comandos para mitigar el problema.
Primero, reduce la escala de monitoring-operator para que no revierta los cambios a la implementación cert-manager:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Edita la implementación de cert-manager-cainjector para inhabilitar la elección de líder, ya que solo tenemos una réplica en ejecución. No es necesaria para una sola réplica:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
El fragmento YAML relevante para la implementación de cert-manager-cainjector debería verse como el siguiente ejemplo:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Mantén las réplicas monitoring-operator en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio.
Una vez que finalice la instalación y el clúster esté en funcionamiento, activa monitoring-operator para las operaciones del día 2:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Después de cada actualización, se revierten los cambios. Vuelve a realizar los mismos pasos para mitigar el problema hasta que se solucione en una versión futura.
|
| Seguridad, actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
Es posible que sea necesario renovar los certificados antes de actualizar el clúster de administrador
Antes de comenzar el proceso de actualización del clúster de administrador, debes asegurarte de que tus certificados de clúster de administrador sean válidos y renovarlos si no lo son.
Si iniciaste el proceso de actualización y encontraste un error con el vencimiento del certificado, comunícate con Atención al cliente de Google para obtener ayuda.
Nota: Esta guía es estrictamente para la renovación de los certificados del clúster de administrador.
Solución alternativa:
Ver pasos para solucionarlos
Asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador antes de comenzar.
- Configura la variable
KUBECONFIG:
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Reemplaza ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG por la ruta absoluta al archivo kubeconfig del clúster de administrador.
- Obtén la dirección IP y las claves SSH del nodo principal de administrador:
kubectl --kubeconfig "${KUBECONFIG}" get secrets \
-n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \
get nodes -o \
jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
--selector='node-role.kubernetes.io/master')
- Verifica si los certificados vencieron:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
Si los certificados caducan, debes renovarlos antes de actualizar el clúster de administrador.
- Crea copias de seguridad de certificados anteriores. Este es un paso opcional, pero recomendado:
# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout
# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
- Renueva los certificados con kubeadm:
# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo kubeadm alpha certs renew all
- Reinicia los pods estáticos que se ejecutan en el nodo principal del administrador:
# on admin master
cd /etc/kubernetes
sudo mkdir tempdir
sudo mv manifests/*.yaml tempdir/
sleep 5
echo "remove pods"
# ensure kubelet detect those change remove those pods
# wait until the result of this command is empty
sudo docker ps | grep kube-apiserver
# ensure kubelet start those pods again
echo "start pods again"
sudo mv tempdir/*.yaml manifests/
sleep 30
# ensure kubelet start those pods again
# should show some results
sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \
-e kube-scheduler -e etcd
# clean up
sudo rm -rf tempdir
logout
- Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes del vencimiento.
- Crea una copia de seguridad del archivo kubeconfig del clúster de administrador:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
- Reemplaza
client-certificate-data y client-key-data en kubeconfig con client-certificate-data y client-key-data en el archivo new_admin.conf que creaste.
- Debes validar los certificados renovados y el certificado de kube-apiserver. Verifica el vencimiento de los certificados:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
- Verifica el certificado de kube-apiserver:
# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server
# Get the current kube-apiserver certificate
openssl s_client -showcerts -connect : \
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
> current-kube-apiserver.crt
# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate
|
| VMware |
1.10, 1.11, 1.12, 1.13 |
Reinicia o actualiza vCenter para versiones anteriores a 7.0U2
Si vCenter, en las versiones anteriores a la 7.0U2, se reinicia, después de una actualización o de otra manera, el nombre de la red en la información de la VM de vCenter es incorrecto y cambia el estado de la máquina a Unavailable. Con el tiempo, esto hace que los nodos se repare automáticamente para crear nuevos.
Error relacionado con govmomi.
Solución alternativa:
La solución alternativa la proporciona la asistencia de VMware:
- El problema se solucionó en vCenter 7.0U2 y versiones posteriores.
- Para versiones anteriores, haz clic con el botón derecho en el host y selecciona Conexión > Desconectar. A continuación, vuelve a conectarte, lo que fuerza una actualización del grupo de puertos de la VM.
|
| Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Conexión SSH cerrada por host remoto
Para los clústeres de Anthos alojados en VMware 1.7.2 y versiones posteriores, las imágenes del SO Ubuntu se endurecen con las comparativas del servidor CIS L1.
Para cumplir con la regla CIS “5.2.16 Asegúrate de que el intervalo de tiempo de espera de inactividad de SSH esté configurado”, /etc/ssh/sshd_config tiene la siguiente configuración:
ClientAliveInterval 300
ClientAliveCountMax 0
El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0 provoca un comportamiento inesperado. Cuando usas la sesión SSH en la estación de trabajo de administrador o en un nodo del clúster, la conexión SSH puede desconectarse, incluso si el cliente SSH no está inactivo, por ejemplo, si ejecutas un comando lento, que podría terminar con el siguiente mensaje:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solución alternativa:
Tienes varias opciones:
Asegúrate de volver a conectar tu sesión SSH.
|
| Instalación |
1.10, 1.11, 1.12, 1.13 |
Instalación de cert-manager en conflicto
En las versiones 1.13, monitoring-operator instalará cert-manager en el espacio de nombres cert-manager. Si, por ciertos motivos, necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:
Solo debes aplicar este trabajo una vez por cada clúster, y los cambios se conservarán durante la actualización del clúster.
Nota: Un síntoma común de instalación de tu propio cert-manager es que la versión cert-manager o la imagen (por ejemplo, v1.7.2) pueden volver a su versión anterior. Esto se debe a que monitoring-operator intenta conciliar el cert-manager y revertir la versión en el proceso.
Solución alternativa:
Evite los conflictos durante la actualización
- Desinstala tu versión de
cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos.
- Realiza la actualización.
- Sigue las siguientes instrucciones para restablecer tu propio
cert-manager.
Restablece tu propio cert-manager en clústeres de usuario
- Escala la implementación
monitoring-operator a 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Escala las implementaciones de
cert-manager administradas por monitoring-operator a 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector\
--replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook --replicas=0
- Vuelve a instalar tu versión de
cert-manager.
Restablece tus recursos personalizados si tienes uno.
- Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que tu cert-manager está instalado en el espacio de nombres
cert-manager.
De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos emisores metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
Restablece tu propio cert-manager en clústeres de administrador
Por lo general, no es necesario volver a instalar cert-manager en los clústeres de administrador, porque los clústeres de administrador solo ejecutan clústeres de Anthos en las cargas de trabajo del plano de control de VMware. En los casos poco frecuentes en los que también necesites instalar tu propio cert-manager en clústeres de administrador, sigue estas instrucciones para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y que solo necesitas cert-manager para Apigee, no necesitas ejecutar los comandos del clúster de administrador.
- Escala la implementación de
monitoring-operator a 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n kube-system scale deployment monitoring-operator --replicas=0
- Escala las implementaciones de
cert-manager administradas por monitoring-operator a 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook \
--replicas=0
- Vuelve a instalar tu versión de
cert-manager.
Restablece tus recursos personalizados si tienes uno.
- Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que tu cert-manager está instalado en el espacio de nombres
cert-manager.
De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos emisores metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
|
| Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc
Las imágenes de Docker, containerd y runc de las imágenes del SO Ubuntu que se envían con los clústeres de Anthos alojados en VMware se fijan a versiones especiales con el PPA de Ubuntu. Esto garantiza que los cambios en el entorno de ejecución de los contenedores se califiquen mediante los clústeres de Anthos alojados en VMware antes de cada lanzamiento.
Sin embargo, el Seguimiento de CVE de Ubuntu, que varias herramientas de análisis de CVE usan, considera las versiones especiales. Por lo tanto, verás falsos positivos en los resultados de análisis de vulnerabilidades de Docker, containerd y runc.
Por ejemplo, es posible que veas los siguientes falsos positivos de los resultados del análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de los clústeres de Anthos alojados en VMware.
Consulta las notas de la versión para conocer las correcciones de CVE.
Solución alternativa:
Canonical está al tanto de este problema y se realiza un seguimiento de la corrección en https://github.com/canonical/sec-cvescan/issues/73.
|
| Revisiones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
Es posible que la conexión de red entre el clúster de administrador y el del usuario no esté disponible
por un período breve durante la actualización del clúster que no es de alta disponibilidad
Si actualizas clústeres que no tienen alta disponibilidad de 1.9 a 1.10, es posible que notes que kubectl exec, kubectl log y el webhook de los clústeres de usuario no están disponibles por un período breve. Este tiempo de inactividad puede ser de hasta un minuto. Esto sucede porque kube-apiserver administra el pedido entrante (kubectl exec, kubectl log and webhook). El usuario kube-apiserver es un estado con estado. En un clúster que no tiene alta disponibilidad, solo hay una réplica para el objeto Statefulset. Por lo tanto, durante la actualización, es posible que el kube-apiserver anterior no esté disponible mientras el nuevo kube-apiserver aún no esté listo.
Solución alternativa:
Este tiempo de inactividad solo ocurre durante el proceso de actualización. Si deseas obtener un tiempo de inactividad menor durante la actualización, te recomendamos que cambies a clústeres con alta disponibilidad.
|
| Instalación, actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
No se pudo comprobar la preparación de Konnectivity en el diagnóstico del clúster con alta disponibilidad después de la creación o actualización del clúster
Si creas o actualizas un clúster de HA y observas que la verificación de preparación de la conectividad falló en el diagnóstico del clúster, en la mayoría de los casos, no afectará la funcionalidad de los clústeres de Anthos alojados en VMware (kubectl exec, kubectl log y webhook). Esto sucede porque, en ocasiones, una o dos de las réplicas de Konnectivity pueden no estar listas por un período debido a la inestabilidad de las herramientas de redes o a otros problemas.
Solución alternativa:
La conectividad se recuperará sola. Espera entre 30 minutos y 1 hora y vuelve a ejecutar el diagnóstico del clúster.
|
| Sistema operativo |
1.7, 1.8, 1.9, 1.10 y 1.11 |
/etc/cron.daily/aide Problema de aumento de memoria y CPU
A partir de la versión 1.7.2 de los clústeres de Anthos alojados en VMware, las imágenes del SO Ubuntu se endurecen mediante las comparativas del servidor CIS L1.
Como resultado, la secuencia de comandos cron /etc/cron.daily/aide se instaló para que se programe una verificación de aide a fin de garantizar que se siga de forma regular la regla 1.4.2 del servidor CIS L1.
El trabajo cron se ejecuta todos los días a las 6:25 a.m. UTC. Según la cantidad de archivos en el sistema de archivos, es posible que experimentes picos de uso de memoria y CPU en ese momento debido a este proceso de aide.
Solución alternativa:
Si los aumentos afectan tu carga de trabajo, puedes inhabilitar el trabajo cron diario:
sudo chmod -x /etc/cron.daily/aide
|
| Herramientas de redes |
1.10, 1.11, 1.12, 1.13 |
Los balanceadores de cargas y las reglas de firewall distribuidas con estado de NSX-T interactúan de manera impredecible
Cuando implementas clústeres de Anthos alojados en VMware versión 1.9 o posterior, cuando la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall distribuido con estado de NSX-T, stackdriver-operator podría no crear gke-metrics-agent-conf de ConfigMap y causar que los pods gke-connect-agent estén en un bucle de fallas.
El problema subyacente es que las reglas de firewall distribuidas con estado de NSX-T finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw, ya que este usa flujos de conexión asimétricas. Los problemas de integración con las reglas de firewall distribuido de NSX-T afectan a todos los clústeres de Anthos alojados en VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando crean objetos de Kubernetes grandes, cuyo tamaño es superior a 32,000.
Solución alternativa:
Sigue estas instrucciones a fin de inhabilitar las reglas de firewall distribuidas de NSX-T o usar reglas de firewall distribuidas sin estado para las VM de Seesaw.
Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas y restablecer las conexiones de los clientes cuando detecte una falla de nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes pueden dejar de responder durante varios minutos cuando una instancia del servidor falla.
|
| Registro y supervisión |
1.10, 1.11, 1.12, 1.13, 1.14 |
Facturación inesperada de Monitoring
Para los clústeres de Anthos alojados en VMware 1.10 a la versión más reciente, algunos clientes descubrieron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo afecta a las siguientes circunstancias:
- Se habilitó la supervisión de la aplicación (
enableStackdriverForApplications=true)
- Servicio administrado para Prometheus no está habilitado (
enableGMPForApplications)
- Los pods de la aplicación tienen la anotación
prometheus.io/scrap=true.
Para confirmar si te afecta este problema, enumera las métricas definidas por el usuario. Si ves la facturación de métricas no deseadas, este problema se aplica a ti.
Solución alternativa
Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 y cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que abordan este problema:
Marcas separadas para controlar la recopilación de registros de la aplicación en comparación con las métricas de la aplicación
Paquete de Google Cloud Managed Service para Prometheus
Si no puedes actualizar a la versión 1.12, sigue estos pasos:
- Encuentra los servicios y los pods de origen que tienen la facturación no deseada
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
- Quita la anotación
prometheus.io/scrap=true del Pod o del Service.
|
| Instalación |
1.11, 1.12, 1.13 |
El instalador falla cuando se crea el disco de datos de vSphere
El instalador de las clústeres de Anthos alojados en VMware puede fallar si las funciones personalizadas están vinculadas en el nivel de permisos incorrecto.
Cuando la vinculación de función es incorrecta, la creación de un disco de datos de vSphere con govc se bloquea y el disco se crea con un tamaño igual a 0. Para solucionar el problema, debes vincular la función personalizada a nivel de vCenter de vSphere (raíz).
Solución alternativa:
Si deseas vincular la función personalizada en el nivel de DC (o un nivel inferior a la raíz), también debes vincular la función de solo lectura al usuario en el nivel raíz de vCenter.
Para obtener más información sobre la creación de funciones, consulta Privilegios de cuenta de usuario de vCenter.
|
| Registro y supervisión |
1.9.0-1.9.4, 1.10.0-1.10.1 |
Tráfico de red alto a monitoring.googleapis.com
Es posible que veas un tráfico de red alto en monitoring.googleapis.com, incluso en un clúster nuevo que no tenga cargas de trabajo de usuarios.
Este problema afecta a las versiones 1.10.0-1.10.1 y 1.9.0-1.9.4. Este problema se solucionó en las versiones 1.10.2 y 1.9.5.
Solución alternativa:
Ver pasos para solucionarlos
Actualiza a la versión 1.10.2/1.9.5 o posterior.
Para mitigar este problema en una versión anterior, haz lo siguiente:
- Reduce la escala de “stackdriver-operator”:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
- Abre el ConfigMap
gke-metrics-agent-conf para editar:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
edit configmap gke-metrics-agent-conf
- Aumenta el intervalo del sondeo de 0.1 segundos a 13 segundos:
processors:
disk_buffer/metrics:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-metrics
probe_interval: 13s
retention_size_mib: 6144
disk_buffer/self:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-self
probe_interval: 13s
retention_size_mib: 200
disk_buffer/uptime:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-uptime
probe_interval: 13s
retention_size_mib: 200
- Cierra la sesión de edición.
- Cambia la versión de DaemonSet de
gke-metrics-agent a 1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
| Registro y supervisión |
1.10, 1.11 |
gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff
Para los clústeres de Anthos alojados en VMware 1.10 y versiones posteriores, el DaemonSet “gke-metrics-agent” tiene errores frecuentes de CrashLoopBackOff cuando “enableStackdriverForApplications” se establece como “true” en el objeto “stackdriver”.
Solución alternativa:
Para mitigar este problema, inhabilita la recopilación de métricas de la aplicación mediante la ejecución de los siguientes comandos. Estos comandos no inhabilitarán la recopilación de registros de la aplicación.
- Para evitar que se reviertan los siguientes cambios, reduce la escala de
stackdriver-operator:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
- Abre el ConfigMap
gke-metrics-agent-conf para editar:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- En
services.pipelines, marca como comentario la sección metrics/app-metrics completa:
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Cierra la sesión de edición.
- Reinicia el DaemonSet
gke-metrics-agent:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
| Registro y supervisión |
1.11, 1.12, 1.13 |
Reemplaza métricas obsoletas en el panel
Si se usan métricas obsoletas en tus paneles de OOTB, verás algunos gráficos vacíos. Para encontrar métricas obsoletas en los paneles de Monitoring, ejecuta los siguientes comandos:
gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E \
'kube_daemonset_updated_number_scheduled\
|kube_node_status_allocatable_cpu_cores\
|kube_node_status_allocatable_pods\
|kube_node_status_capacity_cpu_cores'
Las siguientes métricas obsoletas deberían migrarse a sus reemplazos.
| Funciones obsoletas | Reemplazo |
|---|
kube_daemonset_updated_number_scheduled |
kube_daemonset_status_updated_number_scheduled |
kube_node_status_allocatable_cpu_cores
kube_node_status_allocatable_memory_bytes
kube_node_status_allocatable_pods |
kube_node_status_allocatable |
kube_node_status_capacity_cpu_cores
kube_node_status_capacity_memory_bytes
kube_node_status_capacity_pods |
kube_node_status_capacity |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Solución alternativa:
Para reemplazar las métricas obsoletas, haz lo siguiente:
- Borra “Estado del nodo de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Estado del nodo de GKE On-Prem” según estas instrucciones.
- Borra “Uso de nodos de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Uso de nodos de GKE On-Prem” según estas instrucciones.
- Borra “GKE On-Prem vSphere vm health” en el panel de Google Cloud Monitoring. Vuelve a instalar “Estado de vSphere VM de GKE On-Prem” según estas instrucciones.
Esta baja se debe a la actualización del agente kube-state-metrics de v1.9 a v2.4, que es necesario para Kubernetes 1.22. Puedes reemplazar todas las métricas obsoletas de kube-state-metrics, que tienen el prefijo kube_, en tus paneles personalizados o políticas de alertas.
|
| Registro y supervisión |
1.10, 1.11, 1.12, 1.13 |
Datos de métricas desconocidos en Cloud Monitoring
Para los clústeres de Anthos alojados en VMware 1.10 y versiones posteriores, los datos de los clústeres en Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Estos son otros tipos de métricas que pueden tener métricas de resumen irrelevantes:
apiserver_admission_step_admission_duration_seconds_summarygo_gc_duration_secondsscheduler_scheduling_duration_secondsgkeconnect_http_request_duration_seconds_summaryalertmanager_nflog_snapshot_duration_seconds_summary
Si bien estas métricas de tipo de resumen están en la lista de métricas, gke-metrics-agent no las admite en este momento.
|
| Registro y supervisión |
1.10, 1.11, 1.12, 1.13 |
Faltan métricas en algunos nodos
Es posible que falten las siguientes métricas en algunos nodos, pero no en todos:
kubernetes.io/anthos/container_memory_working_set_byteskubernetes.io/anthos/container_cpu_usage_seconds_totalkubernetes.io/anthos/container_network_receive_bytes_total
Solución alternativa:
Para solucionar este problema, sigue estos pasos como solución alternativa. Para [versión 1.9.5+, 1.10.2+, 1.11.0], sigue los pasos 1 a 4 para aumentar la CPU de gke-metrics-agent.
- Abre tu recurso
stackdriver para editarlo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Para aumentar la solicitud de CPU de
gke-metrics-agent de 10m a 50m, el límite de CPU de 100m a 200m agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver :
spec:
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 100m
memory: 4608Mi
requests:
cpu: 10m
memory: 200Mi
El recurso editado debe ser similar al siguiente:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 200m
memory: 4608Mi
requests:
cpu: 50m
memory: 200Mi
- Guarda los cambios y cierra el editor de texto.
- Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
El comando encuentra cpu: 50m si tus ediciones se aplicaron.
|
| Registro y supervisión |
1.11.0-1.11.2, 1.12.0 |
Faltan métricas de programador y de administrador-administrador en el clúster de administrador
Si tu clúster de administrador se ve afectado por este problema, faltan las métricas del programador y del controlador-administrador. Por ejemplo, faltan estas dos métricas.
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solución alternativa:
Actualizar a v1.11.3+, v1.12.1+, o v1.13+
|
|
1.11.0-1.11.2, 1.12.0 |
Faltan métricas de programador y de administrador-administrador en el clúster de usuario
Si tu clúster de usuario se ve afectado por este problema, faltan las métricas del programador y del administrador-administrador. Por ejemplo, faltan estas dos métricas:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solución alternativa:
|
| Instalación, actualizaciones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
No se pudo registrar el clúster de administrador durante la creación
Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si el clúster de administrador no puede registrarse con la especificación gkeConnect proporcionada durante su creación, verás el siguiente error.
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
Podrás seguir usando este clúster de administrador, pero verás el siguiente error si luego intentas actualizar el clúster de administrador a la versión 1.10.y.
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""
Solución alternativa:
Ver pasos para solucionarlos
Si se produce este error, sigue estos pasos para solucionar el problema de registro del clúster. Después de realizar esta corrección, puedes actualizar el clúster de administrador.
- Ejecuta
gkectl update admin para registrar el clúster de administrador con la clave de cuenta de servicio correcta.
- Crea una cuenta de servicio dedicada para aplicar un parche en el recurso personalizado
OnPremAdminCluster.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.
- Ejecuta estos comandos para actualizar el recurso personalizado
OnPremAdminCluster.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Intenta actualizar el clúster de administrador de nuevo con la marca
--disable-upgrade-from-checkpoint.
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador.
|
| Identidad |
1.10, 1.11, 1.12, 1.13 |
El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible
Si usas la función Anthos Identity Service para administrar Anthos Identity Service ClientConfig, es posible que el agente de Connect se reinicie de forma inesperada.
Solución alternativa:
Si experimentaste este problema con un clúster existente, puedes realizar una de las siguientes acciones:
|
| Herramientas de redes |
1.10, 1.11, 1.12, 1.13 |
Cisco ACI no funciona con el retorno directo del servidor (DSR)
Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP de plano de datos.
Solución alternativa:
Una solución alternativa es inhabilitar el aprendizaje de IP si agregas la dirección IP de Seesaw como una IP virtual L4-L7 en el controlador de infraestructura de la política de aplicaciones (APIC) de Cisco.
Para configurar la opción de IP virtual L4-L7, ve a Usuarios > Perfiles de aplicación > EPG de la aplicación o EPG de Seu. Si no se inhabilita el aprendizaje de IP, se producirá una oscilación de IP entre las diferentes ubicaciones en la estructura de la API de Cisco.
|
| VMware |
1.10, 1.11, 1.12, 1.13 |
Problemas de actualización 3 de vSphere 7.0
Recientemente, VMWare identificó problemas críticos con las siguientes actualizaciones de vSphere 7.0 de actualización 3:
- vSphere ESXi 7.0 actualización 3 (compilación 18644231)
- vSphere ESXi 7.0 actualización 3a (compilación 18825058)
- vSphere ESXi 7.0 actualización 3b (compilación 18905247)
- vSphere vCenter 7.0 actualización 3b (compilación 18901211)
Solución alternativa:
Desde entonces, VMWare quitó estas actualizaciones. Debes actualizar ESXi y vCenter Servers a una versión más reciente.
|
| Sistema operativo |
1.10, 1.11, 1.12, 1.13 |
No se pudo activar el volumen emptyDir como exec en el pod que se ejecuta en nodos COS
Para los pods que se ejecutan en nodos que usan imágenes de Container-Optimized OS (COS), no puedes activar el volumen emptyDir como exec. Se activa como noexec y obtendrás el siguiente error: exec user
process caused: permission denied. Por ejemplo, verás este mensaje de error si implementas el siguiente pod de prueba:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: test
name: test
spec:
containers:
- args:
- sleep
- "5000"
image: gcr.io/google-containers/busybox:latest
name: test
volumeMounts:
- name: test-volume
mountPath: /test-volume
resources:
limits:
cpu: 200m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- emptyDir: {}
name: test-volume
Y, en el pod de prueba, si ejecutas mount | grep test-volume, se mostrará la opción noexec:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Solución alternativa:
Ver pasos para solucionarlos
Aplica un recurso DaemonSet, por ejemplo:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
| Revisiones y actualizaciones |
1.10, 1.11, 1.12, 1.13 |
La actualización de la réplica del grupo de nodos del clúster no funciona después de inhabilitar el ajuste de escala automático en el grupo de nodos.
Las réplicas del grupo de nodos no se actualizan una vez que el ajuste de escala automático está habilitado o
inhabilitado en un grupo de nodos.
Solución alternativa:
Quita las anotaciones cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size y cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size de la implementación de la máquina del grupo de nodos correspondiente.
|
| Registro y supervisión |
1.11, 1.12, 1.13 |
Los paneles de supervisión de Windows muestran datos de clústeres de Linux
A partir de la versión 1.11, en los paneles de supervisión listos para usar, el panel de estado del pod de Windows y el panel del estado del nodo de Windows también muestran datos de los clústeres de Linux. Esto se debe a que las métricas del nodo y del pod de Windows también se exponen en clústeres de Linux.
|
| Registro y supervisión |
1.10, 1.11 |
stackdriver-log-forwarder en CrashLoopBackOff constante
Para los clústeres de Anthos alojados en VMware 1.10 y 1.11, stackdriver-log-forwarderel DaemonSet puede tener errores CrashLoopBackOff cuando hay registros dañados en el búfer en el disco.
Solución alternativa:
Para mitigar este problema, necesitaremos limpiar los registros almacenados en búfer en el nodo.
- Para evitar un comportamiento inesperado, reduce la escala de
stackdriver-log-forwarder:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
- Implementa el DaemonSet de limpieza para limpiar fragmentos dañados:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit-cleanup
namespace: kube-system
spec:
selector:
matchLabels:
app: fluent-bit-cleanup
template:
metadata:
labels:
app: fluent-bit-cleanup
spec:
containers:
- name: fluent-bit-cleanup
image: debian:10-slim
command: ["bash", "-c"]
args:
- |
rm -rf /var/log/fluent-bit-buffers/
echo "Fluent Bit local buffer is cleaned up."
sleep 3600
volumeMounts:
- name: varlog
mountPath: /var/log
securityContext:
privileged: true
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
- key: node-role.kubernetes.io/master
effect: NoSchedule
- key: node-role.gke.io/observability
effect: NoSchedule
volumes:
- name: varlog
hostPath:
path: /var/log
EOF
- Para asegurarte de que el DaemonSet de limpieza limpió todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual al número de nodo en el clúster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Borra el DaemonSet de limpieza:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Reanudar
stackdriver-log-forwarder:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
|
| Seguridad |
1.13 |
El servicio de Kubelet no estará disponible temporalmente después de NodeReady
Hay un período corto en el que el nodo está listo, pero el certificado del servidor de kubelet no está listo. kubectl exec y kubectl logs no están disponibles durante estas decenas de segundos.
Esto se debe a que el nuevo aprobador de certificados del servidor tarda en ver las IP válidas actualizadas del nodo.
Este problema solo afecta al certificado del servidor de kubelet y no a la programación de pods.
|
| Revisiones y actualizaciones |
1.12 |
La actualización parcial del clúster de administrador no bloquea la actualización posterior
del clúster de usuario
No se pudo actualizar el clúster de usuario con lo siguiente:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
El clúster de administrador no está completamente actualizado y la versión de estado aún es 1.10. Ninguna verificación previa bloqueará la actualización del clúster de usuario a la 1.12, que fallará con un problema de sesgo de la versión.
Solución alternativa:
Completa el proceso para actualizar el clúster de administrador a la versión 1.11 y, luego, actualizar el clúster de usuario a 1.12.
|
| Almacenamiento |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
Datastore informa incorrectamente espacio libre insuficiente
El comando gkectl diagnose cluster falló con lo siguiente:
Checking VSphere Datastore FreeSpace...FAILURE
Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
La validación del espacio libre del almacén de datos no se debe usar para los grupos de nodos del clúster existentes y se agregó por error por gkectl diagnose cluster.
Solución alternativa:
Puedes ignorar el mensaje de error, o bien omitir la validación mediante --skip-validation-infra.
|
| Operación, Herramientas de redes |
1.11, 1.12.0-1.12.1 |
Es posible que no puedas agregar un clúster de usuario nuevo si el clúster de administrador está configurado con una configuración de balanceador de cargas de MetalLB.
El proceso de eliminación del clúster de usuario puede atascarse por algún motivo, lo que genera una invalidación del ConfigMap de MatalLB. No es posible agregar un clúster de usuario nuevo en este estado.
Solución alternativa:
Puedes forzar la eliminación de tu clúster de usuario.
|
| Instalación, sistema operativo |
1.10, 1.11, 1.12, 1.13 |
Falla cuando se usa Container-Optimized OS (COS) para el clúster de usuario
Si osImageType usa cos para el clúster de administrador, y cuando gkectl check-config se ejecuta después de la creación del clúster de administrador y antes de la creación del clúster de usuario, fallará en:
Failed to create the test VMs: VM failed to get IP addresses on the network.
La VM de prueba que se crea para el clúster de usuario check-config usa de forma predeterminada la misma osImageType del clúster de administrador. Por el momento, la VM de prueba aún no es compatible con COS.
Solución alternativa:
Para evitar la comprobación previa lenta que crea la VM de prueba, usa gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast.
|
| Registro y supervisión |
1.12.0-1.12.1 |
Grafana en el clúster de administrador no puede llegar a los clústeres de usuario
Este problema afecta a los clientes que usan Grafana en el clúster de administrador para supervisar los clústeres de usuario en los clústeres de Anthos alojados en VMware 1.12.0 y 1.12.1. Proviene de una discrepancia de certificados pushprox-client en clústeres de usuario y en la lista de anunciantes permitidos del pushprox-server en el clúster de administrador.
El síntoma es pushprox-client en clústeres de usuario que imprimen registros de errores como los siguientes:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Solución alternativa:
Ver pasos para solucionarlos
realiza los siguientes pasos:
- Reduce la escala de la implementación del operador de supervisión en el espacio de nombres kube-system del clúster de administrador.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Edita el ConfigMap
pushprox-server-rbac-proxy-config en el espacio de nombres del sistema de kube-system del clúster de administrador.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Localiza la línea principals del objeto de escucha external-pushprox-server-auth-proxy y corrige la principal_name de todos los clústeres de usuario. Para ello, quita la substring kube-system de pushprox-client.metrics-consumers.kube-system.cluster.. La configuración nueva debería verse de la siguiente manera:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Reinicia la implementación
pushprox-server en el clúster de administrador y la implementación pushprox-client en los clústeres de usuario afectados:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- Los pasos anteriores deberían resolver el problema. Una vez que el clúster se actualice a la versión 1.12.2 y, luego, en la que se soluciona el problema, escala verticalmente el operador de supervisión kube-system del clúster de administrador para que pueda volver a administrar la canalización.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
| Otro |
1.11.3 |
gkectl repair admin-master no proporciona la plantilla de VM que se usará para la recuperación.
El comando gkectl repair admin-master falló con lo siguiente:
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
gkectl repair admin-master no puede recuperar la plantilla de VM que se usará para reparar la VM del plano de control de administrador si el nombre de la VM termina en los caracteres t, m, p o l.
Solución alternativa:
Vuelve a ejecutar el comando con --skip-validation.
|
| Registro y supervisión |
1.11 |
Error de Cloud Audit Logging debido al permiso denegado
Anthos Cloud Audit Logging necesita una configuración de permisos especial que, por el momento, solo se realiza de forma automática para los clústeres de usuario a través de GKE Hub.
Se recomienda tener al menos un clúster de usuario que use el mismo ID de proyecto y la misma cuenta de servicio que el clúster de administrador para los registros de auditoría en la nube, de modo que el clúster de administrador tenga el permiso adecuado necesario en el registro de auditoría en la nube.
Sin embargo, en los casos en que el clúster de administrador use un ID de proyecto o una cuenta de servicio diferentes con cualquier clúster de usuario, los registros de auditoría del clúster de administrador no se podrían insertar en la nube. El síntoma es una serie de errores Permission Denied en el pod audit-proxy en el clúster de administrador.
Solución alternativa:
Ver pasos para solucionarlos
Para resolver este problema, se puede configurar el permiso mediante la interacción con la función cloudauditlogging de Hub:
- Primero, verifica las cuentas de servicio existentes incluidas en la lista de anunciantes permitidos de Anthos Cloud Audit Logging para tu proyecto:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- Según la respuesta, realiza una de las siguientes acciones:
- Si recibes un error
404 Not_found, significa que no hay ninguna cuenta de servicio incluida en la lista de anunciantes permitidos para este ID del proyecto. Para incluir una cuenta de servicio en la lista de entidades permitidas, habilita la función cloudauditlogging de Hub:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Si recibiste una especificación de función que contiene
"lifecycleState": "ENABLED" con "code":
"OK" y una lista de cuentas de servicio en allowlistedServiceAccounts, significa que hay cuentas de servicio existentes permitidas para este proyecto. Puedes usar una cuenta de servicio de esta lista en tu clúster o agregar una cuenta de servicio nueva a la lista de entidades permitidas:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Si recibiste una especificación de función que contiene
"lifecycleState": "ENABLED" con "code":
"FAILED", significa que la configuración de permisos no se realizó correctamente.
Intenta solucionar los problemas en el campo description de la respuesta o crea una copia de seguridad de la lista de entidades permitidas actual, borra la función concentrador de Cloudauditlogging y vuelve a habilitarla mediante el paso 1 de esta sección nuevamente. Puedes borrar la función cloudauditlogging de Hub de las siguientes maneras:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
En los comandos anteriores:
|
| Operación, seguridad |
1.11 |
Falló la verificación de gkectl diagnose certificados
Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, obtendrá las siguientes fallas cuando ejecute gkectl diagnose:
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Si la estación de trabajo no tiene acceso a los nodos trabajadores del clúster de administrador o a los nodos trabajadores del clúster de administrador, se generarán las siguientes fallas cuando se ejecute gkectl diagnose:
Checking admin cluster certificates...FAILURE
Reason: 3 admin cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Solución alternativa:
Si es seguro ignorar estos mensajes.
|
| Sistema operativo |
1.8, 1.9, 1.10, 1.11, 1.12 y 1.13 |
/var/log/audit/ llena el espacio en el disco en la estación de trabajo de administrador
/var/log/audit/ está lleno de registros de auditoría. Para verificar el uso del disco, ejecuta sudo du -h -d 1 /var/log/audit.
Algunos comandos gkectl en la estación de trabajo de administrador, por ejemplo, gkectl diagnose snapshot, contribuyen al uso del espacio en disco.
A partir de Anthos v1.8, la imagen de Ubuntu está endurecida con la comparativa de CIS de nivel 2. Y una de las reglas de cumplimiento, “4.1.2.2 Asegúrate de que los registros de auditoría no se borren de forma automática”, garantiza la configuración auditada max_log_file_action = keep_logs. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.
Solución alternativa:
Ver pasos para solucionarlos
Estación de trabajo de administrador
En la estación de trabajo de administrador, puedes cambiar de forma manual la configuración de auditoría para rotar los registros de forma automática y, luego, reiniciar el servicio auditado:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
La configuración anterior provocaría que las auditorías roten sus registros de manera automática una vez que hayan generado más de 250 archivos (cada uno con un tamaño de 8 millones).
Nodos de clúster
En el caso de los nodos del clúster, actualiza a la versión 1.11.5+, 1.12.4+, 1.13.2+ o 1.14+. Si aún no puedes actualizarlas a esas versiones, aplica el siguiente DaemonSet a tu clúster:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Ten en cuenta que, si realizar este cambio de configuración auditado, se infringiría la regla de nivel 2 de CIS "4.1.2.2, asegúrate de que los registros de auditoría no se borren de forma automática".
|
| Herramientas de redes |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayGroup conflictos de IP flotantes con dirección de nodo
Los usuarios no pueden crear ni actualizar objetos NetworkGatewayGroup debido al siguiente error de webhook de validación:
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
En las versiones afectadas, kubelet puede vincularse por error a una dirección IP flotante asignada al nodo y, luego, informarlo como una dirección de nodo en node.status.addresses. La webhook de validación compara las direcciones IP flotantes de NetworkGatewayGroup con todas las node.status.addresses del clúster y considera que esto es un conflicto.
Solución alternativa:
En el mismo clúster en el que falla la creación o la actualización de los objetos NetworkGatewayGroup, inhabilita de forma temporal el webhook de validación de ANG y envía el cambio:
- Guarda la configuración del webhook para que se pueda restablecer al final:
kubectl -n kube-system get validatingwebhookconfiguration \
ang-validating-webhook-configuration -o yaml > webhook-config.yaml
- Edita la configuración del webhook:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Quita el elemento
vnetworkgatewaygroup.kb.io de la lista de configuración de webhook y ciérralo para aplicar los cambios.
- Crea o edita tu objeto
NetworkGatewayGroup.
- Vuelva a aplicar la configuración original del webhook:
kubectl -n kube-system apply -f webhook-config.yaml
|
| Instalación, actualizaciones y actualizaciones |
1.10.0-1.10.2 |
Crea o actualiza el tiempo de espera del clúster de administrador
Durante un intento de actualización del clúster de administrador, la VM del plano de control del administrador podría detenerse durante la creación. La VM del plano de control del administrador pasa a un bucle de espera infinito durante el inicio, y verás el siguiente error de bucle infinito en el archivo /var/log/cloud-init-output.log:
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1
Esto se debe a que, cuando las clústeres de Anthos alojados en VMware intentan obtener la dirección IP del nodo en la secuencia de comandos de inicio, usan grep -v
ADMIN_CONTROL_PLANE_VIP para omitir la VIP del plano de control del clúster de administrador que también se puede asignar a la NIC. Sin embargo, el comando también omite cualquier dirección IP que tenga un prefijo de la VIP del plano de control, lo que hace que la secuencia de comandos de inicio se bloquee.
Por ejemplo, supongamos que la VIP del plano de control del clúster de administrador es 192.168.1.25. Si la dirección IP de la VM del plano de control del clúster de administrador tiene el mismo prefijo, por ejemplo,192.168.1.254, entonces la VM del plano de control se detendrá durante la creación. Este problema también se puede activar si la dirección de emisión tiene el mismo prefijo que la VIP del plano de control, por ejemplo, 192.168.1.255.
Solución alternativa:
|
| Sistema operativo, actualizaciones y actualizaciones |
1.10.0-1.10.2 |
El estado del clúster de administrador que usa la imagen de COS se perderá cuando
se actualice el clúster o en la reparación de la instancia principal del administrador
DataDisk no se puede activar de forma correcta en el nodo principal del clúster de administrador cuando se usa la imagen de COS. Además, el estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster de administrador o en la reparación de la instancia principal del administrador. (el clúster de administrador que usa una imagen de COS es una función de vista previa)
Solución alternativa:
Vuelve a crear el clúster de administrador con osImageType configurado como ubuntu_containerd
Después de crear el clúster de administrador con osImageType configurado como cos, toma la llave SSH del clúster de administrador y establece una conexión SSH en el nodo principal del administrador.
El resultado de df -h contiene /dev/sdb1 98G 209M 93G
1% /opt/data. Y el resultado de lsblk contiene -sdb1
8:17 0 100G 0 part /opt/data
|
| Sistema operativo |
1.10 |
Búsqueda de DNS con error resuelto por el sistema en dominios .local
En la versión 1.10.0 de los clústeres de Anthos alojados en VMware, las resoluciones de nombre en Ubuntu se enrutan a la escucha local resuelta por el sistema en 127.0.0.53 de forma predeterminada. Esto se debe a que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado de manera simbólica a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS del host local 127.0.0.53.
Como resultado, la resolución de nombres de DNS del host local se niega a revisar los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) en busca de nombres con un sufijo .local, a menos que los nombres se especifiquen como dominios de búsqueda.
Esto hace que las búsquedas de nombres de .local fallen. Por ejemplo, durante el inicio del nodo, kubelet no puede extraer imágenes de un registro privado con un sufijo .local. Especificar una dirección de vCenter con un sufijo .local no funcionará en una estación de trabajo de administrador.
Solución alternativa:
Puedes evitar este problema para los nodos del clúster si especificas el campo searchDomainsForDNS en el archivo de configuración del clúster de administrador y en el archivo de configuración del clúster de usuario a fin de incluir los dominios.
Por el momento, gkectl update aún no admite la actualización del campo searchDomainsForDNS.
Por lo tanto, si no configuraste este campo antes de la creación del clúster, debes establecer una conexión SSH en los nodos y evitar el stub de resolución del sistema local. Para ello, cambia el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local de 127.0.0.53) a /run/systemd/resolve/resolv.conf (que apunta al DNS ascendente real):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
En cuanto a la estación de trabajo de administrador, gkeadm no admite la especificación de dominios de búsqueda, por lo que debes solucionar este problema con este paso manual.
Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
|
| Instalación, sistema operativo |
1.10 |
La IP del puente de Docker usa 172.17.0.1/16 en lugar de 169.254.123.1/24.
Los clústeres de Anthos alojados en VMware especifican una subred dedicada para la dirección IP del puente de Docker que usa --bip=169.254.123.1/24, de modo que no reserve la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen de SO Ubuntu que hizo que se ignorara la configuración personalizada de Docker.
Como resultado, Docker elige la 172.17.0.1/16 predeterminada como su subred de dirección IP de puente. Esto podría causar un conflicto de direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese rango de direcciones IP.
Solución alternativa:
Para solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración de systemd por Docker y, luego, reiniciar el servicio:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Verifica que Docker elija la dirección IP del puente correcta:
ip a | grep docker0
Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
|
