En esta página, se enumeran todos los problemas conocidos de Google Distributed Cloud Virtual for Bare Metal. Para filtrar los problemas conocidos por versión o categoría del producto, selecciona los filtros en los siguientes menús desplegables.
Selecciona tu GDCV para la versión de Bare Metal:
Selecciona la categoría del problema:
También puedes buscar tu problema de la siguiente manera:
Categoría
Versiones identificadas
Problema y solución alternativa
Revisiones y actualizaciones
1.28.0, 1.28.100, 1.28.200, 1.28.300
Se produjo un error cuando se actualizaba un clúster a 1.28.0-1.28.300
Actualizar los clústeres creados antes de la versión 1.11.0 a las versiones 1.28.0 a 1.28.300
puede hacer que el Pod del implementador del controlador de ciclo de vida entre en un estado de error
durante la actualización. Cuando esto sucede, los registros del Pod del implementador del controlador de ciclo de vida tienen un mensaje de error similar al siguiente:
"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions
Solución alternativa:
Este problema se solucionó en la versión 1.28.400. Actualiza a la versión 1.28.400 o
una versión posterior para resolver el problema.
Si no puedes actualizar, ejecuta los siguientes comandos para resolver el problema:
Se muestra un ID del proyecto incorrecto en el Explorador de registros
A veces, los registros de clústeres o contenedores se etiquetan con un ID del proyecto diferente en resource.labels.project_id en el Explorador de registros.
Esto puede ocurrir cuando el clúster está configurado para usar la observabilidad
PROJECT_ONE, que se establece en el campo
clusterOperations.projectID de la configuración del clúster.
Sin embargo, el cloudOperationsServiceAccountKeyPath en la
configuración tiene una clave de cuenta de servicio del proyecto
PROJECT_TWO.
En esos casos, todos los registros se enrutan a PROJECT_ONE, pero resource.labels.project_id está etiquetado como PROJECT_TWO.
Solución alternativa:
Usa una de las siguientes opciones para resolver el problema:
Usa una cuenta de servicio del mismo proyecto de destino.
Cambia project_id en el archivo JSON de claves de la cuenta de servicio por el proyecto actual.
Cambia project_id directamente en el filtro de registros del Explorador de registros.
Instalación, actualizaciones, copias de seguridad y restablecimiento
1.28.0, 1.28.100
Los problemas de conectividad del extremo gcr.io de Container Registry pueden bloquear las operaciones del clúster
Varias operaciones de clúster para clústeres de administrador crean un clúster de
arranque. Antes de crear un clúster de arranque, bmctl
realiza una verificación de accesibilidad de Google Cloud desde la estación de trabajo de administrador.
Esta verificación puede fallar debido a problemas de conectividad con el extremo de Container Registry, gcr.io, y es posible que veas un mensaje de error como el siguiente:
system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Solución alternativa
Para solucionar este problema, vuelve a intentar la operación con la marca --ignore-validation-errors.
Herramientas de redes
1.15, 1.16
GKE Dataplane V2 no es compatible con algunos controladores de almacenamiento
Los clústeres de GKE alojados en Bare Metal usan GKE Dataplane V2, que
no es compatible con algunos proveedores de almacenamiento. Es posible que tengas
problemas con Pods o volúmenes NFS atascados. Esto es muy probable si tienes cargas de trabajo que usan volúmenes ReadWriteMany respaldados por controladores de almacenamiento que son susceptibles a este problema:
Robin.io
Portworx (sharedv4 volúmenes de servicio)
csi-nfs
Esta lista no es exhaustiva.
Solución alternativa
Hay una solución a este problema disponible para las siguientes versiones de Ubuntu:
20.04 LTS: Usa una imagen de kernel 5.4.0 posterior a linux-image-5.4.0-166-generic
22.04 LTS: Usa una imagen de kernel 5.15.0 posterior a linux-image-5.15.0-88-generic o el kernel HWE 6.5.
Es posible que notes que kube-state-metrics o el Pod gke-metrics-agent que existe en el mismo nodo que kube-state-metrics no tienen memoria (OOM).
Esto puede ocurrir en clústeres con más de 50 nodos o con muchos
objetos de Kubernetes.
Solución alternativa
A fin de resolver este problema, actualiza la definición de recurso personalizado stackdriver para usar la puerta de funciones ksmNodePodMetricsOnly. Esta puerta de funciones garantiza que solo se exponga una pequeña cantidad de
métricas críticas.
Para utilizar esta solución alternativa, completa los siguientes pasos:
Verifica la definición de recurso personalizado stackdriver para las puertas de funciones disponibles:
La verificación previa falla en RHEL 9.2 debido a que faltan iptables
Cuando instalas un clúster en el sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, es posible que experimentes una falla debido a que falta el paquete iptables. El error se produce durante las comprobaciones preliminares y activa un mensaje de error similar al siguiente:
'check_package_availability_pass': "The following packages are not available: ['iptables']"
RHEL 9.2 está en vista previa para GKE en la versión 1.28 de Bare Metal.
Solución alternativa
Para omitir el error de comprobación previa, configura
spec.bypassPreflightCheck como true en el
recurso del clúster.
Operación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16
Conmutación por error lenta de MetalLB a gran escala
Cuando MetalLB controla una gran cantidad de servicios (más de 10,000), la conmutación por error puede tardar más de una hora. Esto sucede porque MetalLB usa una cola limitada por frecuencia que, cuando se encuentra en escala alta, puede tardar un poco en llegar al servicio que debe conmutarse por error.
Solución alternativa
Actualiza tu clúster a la versión 1.28 o posterior. Si no puedes hacerlo, editar el servicio de forma manual (por ejemplo, agregar una anotación) hará que la conmutación por error se realice con mayor rapidez.
Operación
1.16.0-1.16.6, 1.28.0-1/28.200
Si el proxy está habilitado, se deben configurar las variables de entorno en la estación de trabajo de administrador
bmctl check cluster puede fallar debido a fallas del proxy si no tienes definidas las variables de entorno HTTPS_PROXY y NO_PROXY en la estación de trabajo de administrador. El comando bmctl informa un mensaje de error que indica que no se pudieron llamar a algunos servicios de Google, como en el siguiente ejemplo:
Configura HTTPS_PROXY y NO_PROXY de forma manual en la estación de trabajo de administrador.
Revisiones y actualizaciones
1.28.0-gke.435
Las actualizaciones a la versión 1.28.0-gke.435 pueden fallar si audit.log tiene la propiedad incorrecta
En algunos casos, el archivo /var/log/apiserver/audit.log en los nodos del plano de control tiene la propiedad del grupo y el usuario establecida en root.
Esta configuración de propiedad de archivos provoca fallas de actualización para los nodos del plano
de control cuando se actualiza un clúster de la versión 1.16.x a la versión 1.28.0-gke.435.
Este problema solo se aplica a los clústeres creados antes de la versión 1.11 y que tenían inhabilitados los Registros de auditoría de Cloud. Los Registros de auditoría de Cloud están habilitados de forma predeterminada para los clústeres de la versión 1.9 y posteriores.
Solución alternativa
Si no puedes actualizar tu clúster a la versión 1.28.100-gke.146, sigue estos pasos como solución alternativa para completar la actualización del clúster a la versión 1.28.0-gke.435:
Si los registros de auditoría de Cloud están habilitados, quita el archivo /var/log/apiserver/audit.log.
Si los Registros de auditoría de Cloud están inhabilitados, cambia la propiedad de /var/log/apiserver/audit.log a la misma que la del directorio superior, /var/log/apiserver.
Herramientas de redes, actualizaciones y actualizaciones
1.28.0-gke.435
MetalLB no asigna direcciones IP a servicios VIP
GKE en Bare Metal usa MetalLB para el balanceo de cargas en paquetes. En la versión 1.28.0-gke.435 de GKE en Bare Metal, el paquete de MetalLB se actualiza a la versión 0.13, que incluye compatibilidad con CRD para IPAddressPools. Sin embargo, debido a que ConfigMaps permite cualquier nombre para una IPAddressPool, los nombres del grupo tenían que convertirse en un nombre que cumpliera con Kubernetes. Para ello, agrega un hash al final del nombre de IPAddressPool.
Por ejemplo, un IPAddressPool con el nombre default se convierte en un nombre como default-qpvpd cuando actualizas tu clúster a la versión 1.28.0-gke.435.
Dado que MetalLB requiere un nombre específico de IPPool para la selección, la conversión de nombres evita que MetalLB seleccione un grupo y asigne direcciones IP. Por lo tanto, los servicios que usan metallb.universe.tf/address-pool como anotación para seleccionar el grupo de direcciones para una dirección IP ya no recibirán una dirección IP del controlador de MetalLB.
Este problema se corrigió en la versión 1.28.100-gke.146 de GKE en Bare Metal.
Solución alternativa
Si no puedes actualizar tu clúster a la versión 1.28.100-gke.146, sigue estos pasos como solución alternativa:
Obtén el nombre convertido de IPAddressPool:
kubectl get IPAddressPools -n kube-system
Actualiza el servicio afectado para establecer la anotación metallb.universe.tf/address-pool en el nombre convertido con el hash.
Por ejemplo, si el nombre IPAddressPool se convirtió de default a un nombre como default-qpvpd, cambia la anotación metallb.universe.tf/address-pool: default del Service a metallb.universe.tf/address-pool: default-qpvpd.
El hash que se usa en la conversión de nombres es determinista, por lo que la solución alternativa es persistente.
Revisiones y actualizaciones
1.14
Pods huérfanos después de actualizar a la versión 1.14.x
Cuando actualizas GKE en clústeres de Bare Metal a la versión 1.14.x, algunos
recursos de la versión anterior no se borran. En particular, es posible que veas un conjunto de Pods huérfanos como el siguiente:
Este problema se corrigió en la versión 1.15.0 y posteriores de GKE en Bare Metal.
Instalación
1.14
La creación del clúster se detuvo en el trabajo machine-init
Si intentas instalar la versión 1.14.x de Google Distributed Cloud Virtual for Bare Metal, es posible que experimentes una falla debido a los trabajos machine-init, similar al siguiente resultado de ejemplo:
"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference
Solución alternativa:
Quita el miembro obsoleto de etcd que hace que el trabajo machine-init falle. Completa los siguientes pasos en un nodo del plano de control en funcionamiento:
Enumera los miembros de etcd existentes:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member list
Busca miembros con un estado de unstarted, como se muestra en
el siguiente resultado de ejemplo:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member remove MEMBER_ID
Reemplaza MEMBER_ID por el ID del miembro de etcd con errores. En el resultado de ejemplo anterior, este ID es bd1949bcb70e2cb5.
En el siguiente resultado de ejemplo, se muestra que se quitó el miembro:
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
.
Herramientas de redes
1.28.0
A Cilium-operator le faltan los permisos list y watch del nodo
En Cilium 1.13, los permisos de ClusterRole cilium-operator son incorrectos. Faltan los permisos list y
watch del nodo. cilium-operator no inicia los recolectores de elementos no utilizados, lo que genera los siguientes problemas:
Fuga de recursos de cilio.
Las identidades inactivas no se quitan de los mapas de políticas de BFP.
Los mapas de políticas podrían alcanzar el límite de 16,000.
No se pueden agregar entradas nuevas.
La aplicación de NetworkPolicy es incorrecta.
Es posible que las identidades alcancen el límite de 64,000.
No se pueden crear nuevos Pods.
Un operador al que le faltan los permisos de nodo informa el siguiente mensaje de registro de ejemplo:
2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s
El agente de Cilium informa un mensaje de error cuando no puede insertar una entrada en un mapa de políticas, como en el siguiente ejemplo:
level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint
Solución alternativa:
Quita las identidades de Cilium y, luego, agrega los permisos de ClusterRole que faltan al operador:
Quita los objetos CiliumIdentity existentes:
kubectl delete ciliumid –-all
Edita el objeto ClusterRole cilium-operator:
kubectl edit clusterrole cilium-operator
Agrega una sección para nodes que incluya los permisos faltantes, como se muestra en el siguiente ejemplo:
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
Guarda el editor y ciérralo. El operador detecta de forma dinámica el cambio de permiso. No necesitas reiniciar el operador de forma manual.
Revisiones y actualizaciones
1.15.0-1.15.7, 1.16.0-1.16.3
Se detectó un problema transitorio durante la comprobación preliminar
Es posible que una de las tareas de verificación de estado de kubeadm que se ejecuta durante la verificación previa
de la actualización falle y muestre el siguiente mensaje de error:
[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found
Este error se puede ignorar de forma segura. Si encuentras este error que bloquea la actualización, vuelve a ejecutar el comando de actualización.
Si observas este error cuando ejecutas la comprobación preliminar con el comando bmctl preflightcheck, esta falla no bloquea nada. Puedes volver a ejecutar la comprobación preliminar para obtener la información precisa.
Solución alternativa:
Vuelve a ejecutar el comando de actualización o, si se encuentra durante
bmctl preflightcheck, vuelve a ejecutar el comando preflightcheck.
Operación
1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0
La verificación de estado periódica de la red falla cuando se reemplaza o quita un nodo.
Este problema afecta a los clústeres que realizan verificaciones periódicas de estado de la red
después de que se reemplaza o quita un nodo. Si tu clúster se somete a verificaciones de estado
periódicas, estas últimas generarán errores después del
reemplazo o eliminación de un nodo, ya que el ConfigMap del inventario de red no
se actualiza una vez creado.
Solución alternativa:
La solución recomendada es borrar el ConfigMap del inventario y la verificación periódica de estado de la red. El operador del clúster los vuelve a crear de forma automática con la información más actualizada.
Para los clústeres 1.14.x, ejecuta los siguientes comandos:
La puerta de enlace de red para GDC no puede aplicar tu configuración cuando el nombre del dispositivo contiene un punto.
Si tienes un dispositivo de red que incluye un carácter de punto (.) en el nombre, como bond0.2, la puerta de enlace de red para GDC trata el punto como una ruta de acceso en el directorio cuando ejecuta sysctl para hacer cambios. Cuando la puerta de enlace de red para GDC comprueba si la detección de direcciones duplicadas (DAD) está habilitada, la verificación puede fallar y, por lo tanto, no se conciliará.
El comportamiento es diferente entre las versiones del clúster:
1.14 y 1.15: Este error solo existe cuando usas direcciones IP flotantes IPv6. Si no usas direcciones IP flotantes IPv6, no notarás este problema cuando los nombres de tus dispositivos contengan un punto.
1.16.0 - 1.16.2: Este error siempre existe cuando los nombres de los dispositivos contienen un punto.
Solución alternativa:
Actualiza tu clúster a la versión 1.16.3 o posterior.
Como solución alternativa hasta que puedas actualizar los clústeres, quita el punto (.) del nombre del dispositivo.
Actualizaciones, herramientas de redes, seguridad
1.16.0
Las actualizaciones a la versión 1.16.0 fallan cuando seccomp está inhabilitado
Si seccomp está inhabilitado para tu clúster (spec.clusterSecurity.enableSeccomp establecido en false), fallará la actualización a la versión 1.16.0.
La versión 1.16 de GKE en Bare Metal usa la versión 1.27 de Kubernetes.
En Kubernetes 1.27.0 y versiones posteriores, la función para configurar perfiles de seccomp tiene disponibilidad general y ya no usa una puerta de funciones.
Este cambio de Kubernetes hace que las actualizaciones a la versión 1.16.0 fallen cuando
seccomp está inhabilitado en la configuración del clúster. Este problema se solucionó en los clústeres de la versión 1.16.1 y de versiones posteriores. Si el campo cluster.spec.clusterSecurity.enableSeccomp está configurado como false, puedes actualizar a la versión 1.16.1 o una posterior.
Los clústeres con spec.clusterSecurity.enableSeccomp sin establecer o
establecido como true no se ven afectados.
Los metadatos de containerd pueden dañarse después del reinicio cuando
se activa /var/lib/containerd.
Si activaste de forma opcional /var/lib/containerd, los metadatos de containerd pueden dañarse después de un reinicio. Los metadatos dañados pueden hacer que los Pods fallen, incluidos los Pods críticos para el sistema.
Para verificar si este problema te afecta, comprueba si se definió una activación opcional en /etc/fstab para /var/lib/containerd/ y si tiene nofail en las opciones de activación.
Solución alternativa:
Quita la opción de activación nofail en /etc/fstab o actualiza tu clúster a la versión 1.15.6 o posterior.
Operación
1.13, 1.14, 1.15, 1.16, 1.28
Limpia los Pods inactivos del clúster
Es posible que veas Pods administrados por un Deployment (ReplicaSet) en un estado Failed y con el estado TaintToleration. Estos Pods no usan recursos del clúster, pero
deben borrarse.
Puedes usar el siguiente comando de kubectl para enumerar los Pods que puedes limpiar:
kubectl get pods –A | grep TaintToleration
En el siguiente resultado de ejemplo, se muestra un Pod con el estado TaintToleration:
En cada Pod con los síntomas descritos, verifica el ReplicaSet al que pertenece el Pod. Si el ReplicaSet está satisfecho, puedes borrar los Pods:
Obtén el ReplicaSet que administra el Pod y busca el valor ownerRef.Kind:
kubectl get pod POD_NAME -n NAMESPACE -o yaml
Obtén el ReplicaSet y verifica que el status.replicas sea el mismo que spec.replicas:
kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
Si los nombres coinciden, borra el Pod:
kubectl delete pod POD_NAME -n NAMESPACE.
Actualizaciones
1.16.0
etcd-events puede bloquearse cuando se actualiza a la versión 1.16.0
Cuando actualizas un clúster existente a la versión 1.16.0, las fallas de Pods relacionadas con etcd-events pueden detener la operación. En particular, el trabajo del nodo de actualización falla para el paso TASK [etcd_events_install : Run etcdevents].
Si te afecta este problema, verás fallas de Pods como las siguientes:
El Pod kube-apiserver no se inicia con el
siguiente error:
El pod etcd-events no se inicia con el siguiente error:
Error: error syncing endpoints with etcd: context deadline exceeded
Solución alternativa:
Si no puedes actualizar tu clúster a una versión que incluya la corrección, usa la siguiente solución temporal para abordar los errores:
Usa SSH para acceder al nodo del plano de control con los errores informados.
Edita el archivo de manifiesto etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, y quita la marca initial-cluster-state=existing.
Aplica el manifiesto.
La actualización debería continuar.
Herramientas de redes
1.15.0-1.15.2
No se reconoce orderPolicy de CoreDNS
OrderPolicy no se reconoce como un parámetro y no se usa. En cambio, GKE en Bare Metal siempre usa Random.
Este problema ocurre porque no se actualizó la plantilla de CoreDNS, lo que hace que se ignore orderPolicy.
Solución alternativa:
Actualiza la plantilla de CoreDNS y aplica la corrección. Esta solución persiste hasta que se actualiza.
Edita la plantilla existente:
kubectl edit cm -n kube-system coredns-template
Reemplaza el contenido de la plantilla por lo siguiente:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
Herramientas de redes, operación
1.10, 1.11, 1.12, 1.13, 1.14
Puerta de enlace de red para componentes de GDC expulsados o pendientes debido a la falta de
clase de prioridad
Los Pods de puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted, como se muestra en el siguiente resultado de ejemplo abreviado:
Estos errores indican eventos de expulsión o una imposibilidad de programar Pods
debido a los recursos del nodo. Como la puerta de enlace de red para los Pods de GDC no tiene PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo.
Cuando los nodos tienen recursos limitados, los Pods de la puerta de enlace de red pueden expulsarse. Este comportamiento es particularmente malo para el DaemonSet ang-node, ya que esos Pods deben programarse en un nodo específico y no se pueden migrar.
Solución alternativa:
Actualiza a la versión 1.15 o posterior.
Como solución a corto plazo, puedes asignar una PriorityClass a la puerta de enlace de red para los componentes de GDC de forma manual. El controlador de GKE en Bare Metal reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.
Asigna la PriorityClass system-cluster-critical a las implementaciones del controlador de clúster ang-controller-manager y autoscaler.
Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
Instalación, actualizaciones y actualizaciones
1.15.0, 1.15.1, 1.15.2
La creación y las actualizaciones del clúster fallan debido a la longitud del nombre del clúster
La creación de clústeres de la versión 1.15.0, 1.15.1 o 1.15.2 o la actualización
de clústeres a la versión 1.15.0, 1.15.1 o 1.15.2 falla cuando el nombre del clúster
tiene más de 48 caracteres (versión 1.15.0) o 45 caracteres (versión
1.15.1 o 1.15.2). Durante las operaciones de creación y actualización de clústeres, GKE en Bare Metal crea un recurso de verificación de estado con un nombre que incorpora el nombre y la versión del clúster:
Para los clústeres de la versión 1.15.0, el nombre del recurso de verificación de estado es CLUSTER_NAME-add-ons-CLUSTER_VER.
Para los clústeres de las versiones 1.15.1 o 1.15.2, el nombre del recurso de verificación de estado es CLUSTER_NAME-kubernetes-CLUSTER_VER.
En el caso de los nombres largos de clústeres, el nombre del recurso de verificación de estado supera la restricción de 63 caracteres de Kubernetes para nombres de etiquetas, lo que impide la creación del recurso de verificación de estado.
Sin una verificación de estado correcta, la operación del clúster falla.
Para ver si te afecta este problema, usa kubectl describe a fin de verificar el recurso con errores:
Si este problema te afecta, la respuesta contendrá una advertencia para una ReconcileError como la siguiente:
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred:
* failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]
Solución alternativa
Para desbloquear la actualización o creación del clúster, puedes omitir la
verificación de estado. Usa el siguiente comando para aplicar un parche al recurso personalizado de verificación de estado con el estado de aprobación: (status: {pass: true})
Los clústeres de las versiones 1.14.0 y 1.14.1 con funciones de vista previa no se pueden actualizar a la versión 1.15.x.
Si los clústeres de las versiones 1.14.0 y 1.14.1 tienen habilitada una función de vista previa,
no se les permitirá actualizar correctamente a la versión 1.15.x. Esto se aplica a las funciones de versión preliminar, como la capacidad de crear un clúster sin kube-proxy, que se habilita con la siguiente anotación en el archivo de configuración del clúster:
Si te
afecta este problema, verás un error como el siguiente durante la
actualización del clúster:
[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version
Este problema se solucionó en los clústeres de la versión 1.14.2 y superiores.
Solución alternativa:
Si no puedes actualizar tus clústeres a la versión 1.14.2 o superior antes de actualizar a la versión 1.15.x, puedes actualizar a la versión 1.15.x directamente mediante un clúster de arranque:
bmctl upgrade cluster --use-bootstrap=true
Operación
1.15
Los clústeres de la versión 1.15 no aceptan direcciones IP flotantes duplicadas.
La puerta de enlace de red para GDC no te permite crear nuevos recursos personalizados NetworkGatewayGroup que contengan direcciones IP en spec.floatingIPs que ya se usen en recursos personalizados NetworkGatewayGroup existentes. Esta regla se aplica mediante un webhook en GKE en los clústeres de Bare Metal versión 1.15.0 y posteriores. Las direcciones IP flotantes duplicadas preexistentes no causan errores. El webhook solo evita la creación de nuevos
recursos personalizados NetworkGatewayGroups que contienen direcciones
IP duplicadas.
El mensaje de error de webhook identifica la dirección IP en conflicto y el recurso personalizado existente que ya la usa:
IP address exists in other gateway with name default
En la documentación inicial para las funciones de red avanzadas, como la puerta de enlace NAT de salida, no se previenen las direcciones IP duplicadas.
Inicialmente, el conciliador reconoció solo el recurso NetworkGatewayGroup llamado default. La puerta de enlace de red para GDC ahora reconoce todos los recursos personalizados NetworkGatewayGroup en el espacio de nombres del sistema. Los recursos personalizados NetworkGatewayGroup existentes se respetan sin modificaciones.
Solución alternativa:
Los errores ocurren solo cuando se crea un nuevo recurso personalizado NetworkGatewayGroup.
Para solucionar el error, haz lo siguiente:
Usa el siguiente comando para enumerar NetworkGatewayGroups
recursos personalizados:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Abre los recursos personalizados NetworkGatewayGroup existentes y quita las direcciones IP flotantes en conflicto (spec.floatingIPs):
Para aplicar los cambios, cierra y guarda los recursos personalizados editados.
Entorno de ejecución de VM en GDC
1.13.7
Es posible que las VMs no se inicien en los clústeres 1.13.7 que usan un registro privado
Cuando habilitas el entorno de ejecución de VM en GDC en un clúster nuevo o actualizado de la versión 1.13.7 que usa un registro privado, es posible que las VMs que se conectan a la red del nodo o usen una GPU no se inicien de forma correcta. Este problema se debe a que algunos Pods del sistema en el espacio de nombres vm-system obtienen errores de extracción de imágenes. Por ejemplo, si la VM usa la red de nodos, algunos Pods podrían informar errores de extracción de imágenes como los siguientes:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Este problema se corrigió en la versión 1.14.0 y posteriores de GKE en clústeres de Bare Metal.
Solución alternativa
Si no puedes actualizar tus clústeres de inmediato, puedes extraer imágenes de forma manual. Los siguientes comandos extraen la imagen del complemento de la CNI macvtap para la VM y la envían al registro privado:
Reemplaza REG_HOST por el nombre de dominio de un host que duplicas de forma local.
Instalación
1.11, 1.12
Durante la creación del clúster en el clúster de tipo, el pod gke-metric-agent no se inicia
Durante la creación de clústeres en el clúster de similares, el Pod gke-metrics-agent no se inicia debido a un error de extracción de imágenes, como se indica a continuación:
error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Además, en el registro containerd del clúster de arranque, verás la siguiente entrada:
Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
En el Pod, verás el siguiente error “failing to pull”:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Solución alternativa
A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de tipo es facilitar la tasa de éxito de creación de clústeres y realizar seguimientos y supervisión internos.
Por lo tanto, puedes ignorar este error.
Solución alternativa
A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de tipo es facilitar la tasa de éxito de creación de clústeres y realizar seguimientos y supervisión internos.
Por lo tanto, puedes ignorar este error.
Operación, Herramientas de redes
1.12, 1.13, 1.14, 1.15, 1.16, 1.28
El acceso a un extremo de Service IPv6 hace que falle el nodo LoadBalancer en CentOS o RHEL
Cuando accedes a un Service de pila doble (un Service que tiene extremos IPv4 e IPv6) y usas el extremo IPv6, el nodo LoadBalancer que entrega el Service puede fallar. Este problema afecta a los clientes que usan servicios de pila doble con CentOS o RHEL y una versión de kernel anterior a kernel-4.18.0-372.46.1.el8_6.
Si crees que este problema te afecta, verifica la versión de kernel en el nodo LoadBalancer con el comando uname -a.
Solución alternativa:
Actualiza el nodo LoadBalancer a la versión de kernel kernel-4.18.0-372.46.1.el8_6 o a una versión posterior. Esta versión de kernel está disponible de forma predeterminada en CentOS y RHEL versión 8.6 y posteriores.
Herramientas de redes
1.11, 1.12, 1.13, 1.14.0
Problemas de conectividad intermitentes después de reiniciar el nodo
Después de reiniciar un nodo, es posible que veas problemas de conectividad intermitentes en un servicio NodePort o LoadBalancer. Por ejemplo, es posible que tengas errores intermitentes de protocolo de enlace TLS o de restablecimiento de conexión. Este problema se solucionó para las versiones de clúster 1.14.1 y posteriores.
Para verificar si este problema te afecta, consulta las reglas de reenvío de iptables en los nodos en los que se ejecuta el Pod de backend del Service afectado:
sudo iptables -L FORWARD
Si ves la regla KUBE-FORWARD antes de la regla CILIUM_FORWARD en iptables, es posible que este problema te afecte. En el siguiente resultado de ejemplo, se muestra un nodo en el que existe el problema:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Solución alternativa:
Reinicia el Pod anetd en el nodo mal configurado. Después de reiniciar el Pod anetd, la regla de reenvío en iptables debería configurarse de forma correcta.
En el siguiente resultado de ejemplo, se muestra que la regla CILIUM_FORWARD ahora está configurada de forma correcta antes que la regla KUBE-FORWARD:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Revisiones y actualizaciones
1.9, 1.10
La función de versión preliminar no conserva el permiso original ni la información del propietario
La función de vista previa del clúster 1.9.x con bmctl 1.9.x no conserva el permiso original ni la información del propietario. Para verificar si esta función te afecta, extrae el archivo del que creaste una copia de seguridad mediante el siguiente comando:
tar -xzvf BACKUP_FILE
Solución alternativa
Verifica si metadata.json está presente y si bmctlVersion es 1.9.x. Si metadata.json no está presente, actualiza al clúster 1.10.x y usa bmctl 1.10.x para crear una copia de seguridad y restablecer.
Actualizaciones y creaciones
1.14.2
clientconfig-operator quedó en estado pendiente con CreateContainerConfigError
Si actualizaste a un clúster de versión 1.14.2 o creaste uno con una configuración
OIDC/LDAP, es posible que veas que el Pod clientconfig-operator se atascó
en un estado pendiente. Con este problema, hay dos Pods clientconfig-operator, uno en estado de ejecución y el otro en estado pendiente.
Este problema solo se aplica a los clústeres de la versión 1.14.2. Las versiones anteriores del clúster, como 1.14.0 y 1.14.1, no se ven afectadas. Este problema se solucionó en la versión 1.14.3 y en todas las versiones posteriores, incluidas la 1.15.0 y las posteriores.
Solución alternativa:
Como solución alternativa, puedes aplicar parches a la implementación de clientconfig-operator para agregar contexto de seguridad adicional y asegurarte de que la implementación esté lista.
Usa el siguiente comando para aplicar un parche a clientconfig-operator en el clúster de destino:
CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig para el clúster de destino.
Operación
1.11, 1.12, 1.13, 1.14, 1.15
La rotación de la autoridad certificadora falla para los clústeres sin balanceo de cargas en paquetes
Para los clústeres sin balanceo de cargas en paquetes (spec.loadBalancer.mode configurado como manual), el comando bmctl update credentials certificate-authorities rotate puede dejar de responder y fallar con el siguiente error: x509: certificate signed by unknown authority.
Si te afecta este problema, es posible que el comando bmctl genere el siguiente mensaje antes de dejar de responder:
Signing CA completed in 3/0 control-plane nodes
En este caso, el comando falla en algún momento. El registro de rotación de la autoridad certificadora de un clúster con tres planos de control puede incluir entradas como las siguientes:
[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")
ipam-controller-manager de bucles de falla en clústeres de pila doble
Cuando implementas un clúster de pila doble (un clúster con direcciones IPv4 e IPv6), los Pods ipam-controller-manager pueden generar un bucle de fallas. Este comportamiento hace que los nodos fluyan entre los estados Ready y NotReady, y puede hacer que la instalación del clúster falle. Este problema puede ocurrir cuando el servidor de la API se encuentra bajo una carga alta.
Para ver si este problema te afecta, verifica si los Pods ipam-controller-manager fallan con errores CrashLoopBackOff:
kubectl -n kube-system get pods | grep ipam-controller-manager
En el siguiente resultado de ejemplo, se muestran los Pods en un estado CrashLoopBackOff:
Los clústeres que ejecutan la versión de etcd 3.4.13 o versiones anteriores pueden experimentar limitaciones de reloj y supervisión de recursos no operativos, lo que puede generar los siguientes problemas:
Se interrumpe la programación del Pod
No se pueden registrar los nodos
kubelet no observa cambios en el Pod
Estos problemas pueden hacer que el clúster no funcione.
Este problema se solucionó en GDCV para las versiones 1.12.9, 1.13.6, 1.14.3 y posteriores de Bare Metal. Estas versiones más recientes usan la versión de etcd 3.4.21. Este problema afecta a todas las versiones anteriores de GDCV para Bare Metal.
Solución alternativa
Si no puedes actualizar de inmediato, puedes mitigar el riesgo de
falla del clúster si reduces la cantidad de nodos en tu clúster. Quita
los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total
sea inferior a 300 MBps.
Para ver esta métrica en el Explorador de métricas, sigue estos pasos:
Ve al Explorador de métricas en la consola de Google Cloud:
Expande Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, utiliza los submenús para seleccionar la métrica:
En el menú Recursos activos, selecciona Contenedor de Kubernetes.
En el menú Categorías de métricas activas, selecciona Anthos.
En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
Haz clic en Aplicar.
Herramientas de redes
1.11.6, 1.12.3
Estado "Fallido" del operador vfio-pci del SR-IOV
El syncStatus del objeto SriovNetworkNodeState
puede informar el valor "Fallido" para un nodo configurado. Para ver el estado de un nodo y determinar si el problema te afecta, ejecuta el siguiente comando:
kubectl -n gke-operators get \
sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
-o jsonpath='{.status.syncStatus}'
Reemplaza NODE_NAME por el nombre del nodo que deseas verificar.
Solución alternativa:
Si el estado del objeto SriovNetworkNodeState es “Fallido”,
actualiza el clúster a la versión 1.11.7 o posterior, o a la versión 1.12.4 o
posterior.
Revisiones y actualizaciones
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
Algunos nodos trabajadores no están en estado Listo después de la actualización
Una vez finalizada la actualización, es posible que la condición Listo de algunos nodos trabajadores se establezca en false. En el recurso Node, verás un error junto a la condición Listo similar al siguiente ejemplo:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Cuando accedes a la máquina detenida, la configuración de la CNI en la máquina está vacía:
sudo ls /etc/cni/net.d/
Solución alternativa
Borra el Pod anetd del nodo para reiniciarlo.
Actualizaciones y actualizaciones, Seguridad
1.10
Varias rotaciones de certificados de cert-manager generan incoherencias.
Después de varias rotaciones de certificados manuales o automáticas, el pod de webhook, como anthos-cluster-operator, no se actualiza con los certificados nuevos emitidos por cert-manager. Cualquier actualización del recurso personalizado del clúster falla y genera un error similar al siguiente:
Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Este problema puede ocurrir en las siguientes circunstancias:
Si realizaste dos rotaciones manuales de certificados emitidos por el administrador de certificados en un clúster con más de 180 días o más, y nunca reiniciaste el anthos-cluster-operator.
Si realizaste rotaciones manuales de certificados emitidos por cert-manager en un clúster con más de 90 días de antigüedad y nunca reiniciaste el anthos-cluster-operator.
Solución alternativa
Reinicia el Pod mediante la finalización del anthos-cluster-operator.
Revisiones y actualizaciones
1.14.0
Pods del controlador del ciclo de vida desactualizados que se crearon durante la actualización del clúster de usuario
En los clústeres de administrador de la versión 1.14.0, se pueden crear uno o más Pods de implementador del controlador de ciclo de vida
desactualizados durante las actualizaciones del clúster de usuario.
Este problema se aplica a los clústeres de usuario que se crearon en un principio en versiones anteriores a la 1.12. Los Pods creados de forma involuntaria no impiden las operaciones de actualización, pero pueden encontrarse en un estado inesperado. Te
recomendamos que quites los Pods desactualizados.
Este problema se corrigió en la versión 1.14.1.
Solución alternativa:
Para quitar los Pods del implementador del controlador del ciclo de vida desactualizados, haz lo siguiente:
Enumera recursos de comprobación preliminar:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
El resultado se verá así:
NAMESPACE NAME PASS AGE
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d
en el que ci-87a021b9dcbb31c es el nombre del clúster.
Borra los recursos cuyo valor en la columna PASS sea true o false.
Por ejemplo, para borrar los recursos en el resultado de muestra anterior, usa los siguientes comandos:
El estado BGPSession cambia constantemente debido a una gran cantidad de rutas entrantes
Las herramientas de redes avanzadas de GKE en Bare Metal no pueden administrar las sesiones de BGP de forma correcta cuando los pares externos anuncian una gran cantidad de rutas (alrededor de 100 o más). Con una gran cantidad de rutas entrantes, el controlador de BGP local del nodo tarda demasiado en conciliar las sesiones de BGP y no actualiza el estado. La falta de actualizaciones de estado, o una verificación de estado, provoca que la sesión se borre por estar inactiva.
Entre los comportamientos no deseados en las sesiones de BGP que puedes observar y que indican un problema, se incluyen los siguientes:
Eliminación y recreación continuas de bgpsession.
bgpsession.status.state nunca se convierte en Established
Rutas que no publican anuncios o que se anuncian y
se retiran repetidamente
Los problemas de balanceo de cargas de BGP pueden notarse debido a problemas de conectividad a los servicios de LoadBalancer.
El problema FlatIP de BGP puede notarse debido a problemas de conectividad a los Pods.
Para determinar si los problemas de BGP se deben a los pares remotos que anuncian demasiadas rutas, usa los siguientes comandos a fin de revisar los estados y el resultado asociados:
Usa kubectl get bgpsessions en el clúster afectado.
El resultado muestra bgpsessions con el estado "Sin establecer" y la hora del último informe cuenta de forma continua de 10 a 12 segundos antes de que parezca restablecerse a cero.
El resultado de kubectl get bgpsessions muestra que las sesiones afectadas se recrean de forma repetida:
kubectl get bgpsessions \
-o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
Los mensajes de registro indican que se están borrando las sesiones de BGP inactivas:
kubectl logs ang-controller-manager-POD_NUMBER
Reemplaza POD_NUMBER por el Pod líder de tu clúster.
Solución alternativa:
Reduce o elimina la cantidad de rutas anunciadas desde el intercambio de tráfico remoto al clúster con una política de exportación.
En la versión 1.14.2 y posteriores del clúster de GKE en Bare Metal, también puedes inhabilitar la función que procesa las rutas recibidas mediante un AddOnConfiguration. Agrega el argumento --disable-received-routes al contenedor bgpd del daemonset ang-daemon.
Herramientas de redes
1.14, 1.15, 1.16, 1.28
Tiempos de espera de la aplicación causados por fallas de inserción de tablas
de conntrack
Los clústeres que se ejecutan en un SO Ubuntu que usa el kernel 5.15 o superior son susceptibles a fallas de inserción de tablas de seguimiento de conexión de netfilter (conntrack). Las fallas de inserción pueden ocurrir incluso cuando la tabla
de conntrack tiene espacio para entradas nuevas. Las fallas se producen por cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas en función de la longitud de la cadena.
Para ver si te afecta este problema, puedes comprobar las estadísticas del sistema de seguimiento de conexiones del kernel con el siguiente comando:
sudo conntrack -S
La respuesta es similar a la que se muestra a continuación:
Si un valor chaintoolong en la respuesta es un número distinto de cero, este problema te afectará.
Solución alternativa
La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets) y la tabla de seguimiento de conexión de netfilter (nf_conntrack_max). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas:
Reemplaza TABLE_SIZE por un tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos del nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.
No se pueden restablecer las copias de seguridad de los clústeres con bmctl para algunas versiones
Te recomendamos que crees una copia de seguridad de los clústeres antes de la actualización para que
puedas restablecer la versión anterior si la actualización no se realiza de forma correcta.
Un problema con el comando bmctl restore cluster hace que no pueda restablecer las copias de seguridad de los clústeres con las versiones identificadas. Este problema es específico de las actualizaciones, en las que restableces una copia de seguridad de una versión anterior.
Si tu clúster se ve afectado, el registro bmctl restore cluster contiene el siguiente error:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Solución alternativa:
Hasta que se solucione este problema, te recomendamos que sigas las instrucciones en
Crea una copia de seguridad y restablece clústeres
para hacer una copia de seguridad de tus clústeres y restablecerlos de forma manual, si es necesario.
Herramientas de redes
1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2
NetworkGatewayGroup falla si no hay una dirección IP en la interfaz.
NetworkGatewayGroup no crea daemons para los nodos que no tienen interfaces IPv4 y también IPv6. Esto hace que funciones como
el balanceador de cargas de BGP y la NAT de salida fallen. Si verificas los registros del Pod ang-node con errores en el espacio de nombres kube-system, se muestran errores similares al siguiente ejemplo cuando falta una dirección IPv6:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
En el ejemplo anterior, no hay una dirección IPv6 en la interfaz ens192. Se muestran errores de ARP similares si al nodo le falta una dirección IPv4.
NetworkGatewayGroup intenta establecer una conexión ARP y una conexión NDP a la dirección IP local del vínculo. Si la dirección IP no existe (IPv4 para ARP o IPv6 para NDP), la conexión falla y el daemon no continúa.
Este problema se corrigió en la versión 1.14.3.
Solución alternativa:
Conéctate al nodo con SSH y agrega una dirección IPv4 o IPv6 al
vínculo que contiene la IP del nodo. En la entrada de registro del ejemplo anterior, esta interfaz era ens192:
ip address add dev INTERFACE scope link ADDRESS
Reemplaza lo siguiente:
INTERFACE: La interfaz para tu nodo, como ens192.
ADDRESS: La dirección IP y la máscara de subred que se aplicará a la interfaz.
Restablecimiento/eliminación
1.10, 1.11, 1.12, 1.13.0 a 1.13.2
Bucle de falla anthos-cluster-operator cuando se quita un nodo del plano de control
Cuando intentas quitar un nodo del plano de control mediante la eliminación de la dirección IP de Cluster.Spec, anthos-cluster-operator entra en un estado de bucle de falla que bloquea cualquier otra operación.
Solución alternativa:
El problema se corrigió en las versiones 1.13.3, 1.14.0 y posteriores. Todas las demás versiones se ven afectadas. Actualiza a una de las versiones corregidas
Como solución alternativa, ejecuta el siguiente comando:
IP_ADDRESS: Es la dirección IP del nodo en estado de bucle de falla.
CLUSTER_NAMESPACE: Es el espacio de nombres del clúster.
Instalación
1.13.1, 1.13.2 y 1.13.3
kubeadm join falla en clústeres grandes debido a una discrepancia
de tokens
Cuando instalas GKE en clústeres de Bare Metal con una gran cantidad de nodos, es posible que veas un mensaje de error kubeadmin join similar al siguiente ejemplo:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Solución alternativa:
Este problema se resolvió en el GDCV para Bare Metal versión 1.13.4 y posteriores.
Si necesitas usar una versión afectada, primero crea un clúster con menos de 20 nodos y, luego, cambia el tamaño del clúster para agregar nodos adicionales una vez que se complete la instalación.
Registro y supervisión
1.10, 1.11, 1.12, 1.13.0
Límite de CPU bajo para metrics-server en clústeres de Edge
En GKE en clústeres de Bare Metal Edge, los límites bajos de CPU para
metrics-server pueden causar reinicios frecuentes de
metrics-server. El ajuste de escala automático horizontal de Pods (HPA) no funciona porque metrics-server no está en buen estado.
Si el límite de CPU de metrics-server es inferior a 40m,
tus clústeres pueden verse afectados. Para verificar los límites de CPU de metrics-server, revisa uno de los siguientes archivos:
Versión 1.x-1.12 de GKE en clústeres de Bare Metal:
Este problema se resuelve en los clústeres de GKE en Bare Metal versión 1.13.1 o posterior. Para
solucionar este problema, actualiza tus clústeres.
Una solución alternativa a corto plazo hasta que puedas actualizar los clústeres es aumentar de forma manual los límites de CPU para metrics-server de la siguiente manera:
Quita la línea --config-dir=/etc/config y aumenta los límites de CPU, como se muestra en el siguiente ejemplo:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
Guarda el metrics-server y ciérralo para aplicar los cambios.
Herramientas de redes
1.14, 1.15, 1.16
La conexión directa de NodePort al Pod de hostNetwork no funciona
La conexión a un Pod habilitado con hostNetwork mediante el servicio NodePort falla cuando el Pod de backend está en el mismo nodo que el NodePort de destino. Este problema afecta a los servicios de LoadBalancer cuando se usa con
Pods de hostNetwork. Con varios backends, puede haber una falla de conexión esporádica.
Este problema se debe a un error en el programa eBPF.
Solución alternativa:
Cuando uses un servicio de Nodeport, no te orientes al nodo en el que se ejecuta ninguno de
los Pods de backend. Cuando uses el servicio LoadBalancer, asegúrate de que los Pods alojados en hostNetwork no se ejecuten en nodos LoadBalancer.
Revisiones y actualizaciones
1.12.3, 1.13.0
Los clústeres de administrador 1.13.0 no pueden administrar los clústeres de usuario 1.12.3
Los clústeres de administrador que ejecutan la versión 1.13.0 no pueden administrar los clústeres de usuario que ejecutan la versión 1.12.3. Las operaciones en un clúster de usuario de la versión 1.12.3 fallan.
Solución alternativa:
Actualiza el clúster de administrador a la versión 1.13.1 o actualiza el clúster de
usuario a la misma versión que el clúster de administrador.
Revisiones y actualizaciones
1.12
Se bloqueó la actualización a la versión 1.13.x para los clústeres de administrador con grupos de nodo trabajador
Los clústeres de administrador de la versión 1.13.0 y posteriores no pueden contener grupos de nodo trabajador.
Se bloquean las actualizaciones a la versión 1.13.0 o posteriores para los clústeres de administrador con grupos de
nodo trabajador. Si la actualización del clúster de administrador está detenida, puedes confirmar
si los grupos de nodo trabajador son la causa. Para ello, verifica el siguiente error en el
archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Solución alternativa:
Antes de actualizar, mueve todos los grupos de nodo trabajador a los clústeres de usuario. Si deseas obtener instrucciones para agregar y quitar grupos de nodos, consulta Administra grupos de nodos en un clúster.
Revisiones y actualizaciones
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Errores cuando se actualizan recursos con kubectl apply
Si actualizas recursos existentes como los recursos personalizados ClientConfig o Stackdriver con kubectl apply, el controlador puede mostrar un error o revertir la entrada y los cambios planificados.
Por ejemplo, puedes intentar editar el recurso personalizado Stackdriver de la siguiente manera. Para ello, primero obtén el recurso y, luego, aplica una versión actualizada:
Habilita funciones o actualiza la configuración en el archivo YAML.
Vuelve a aplicar el archivo YAML actualizado:
kubectl apply -f stackdriver.yaml
En el último paso de kubectl apply, es posible que tengas problemas.
Solución alternativa:
No uses kubectl apply para realizar cambios en los recursos existentes. En su lugar, usa kubectl edit o kubectl patch como se muestra en los siguientes ejemplos:
Los fragmentos de trabajo pendientes dañados causan
un bucle de fallas stackdriver-log-forwarder
El bucle de fallas stackdriver-log-forwarder falla si intenta procesar un fragmento de trabajo pendiente dañado. Los siguientes errores de ejemplo se muestran en los registros de contenedores:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Cuando ocurre este bucle de fallas, no puedes ver los registros en Cloud Logging.
Solución alternativa:
Para resolverlos, sigue estos pasos:
Identificar los fragmentos de trabajo pendientes dañados. Revisa los siguientes ejemplos
de mensajes de error:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
En este ejemplo, el archivo tail.1/1-1659339894.252926599.flb que se almacenó en var/log/fluent-bit-buffers/tail.1/ fue el
error. Se deben quitar todos los archivos *.flb en los que haya fallado una verificación de formato.
Finaliza los Pods en ejecución para stackdriver-log-forwarder:
Reemplaza KUBECONFIG por la ruta de acceso al
archivo kubeconfig del clúster de usuario.
Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso.
Conéctate al nodo mediante SSH en el que se ejecuta stackdriver-log-forwarder.
En el nodo, borra todos los archivos *.flb dañados en var/log/fluent-bit-buffers/tail.1/.
Si hay demasiados archivos dañados y quieres aplicar una secuencia de comandos para limpiar todos los fragmentos de tareas pendientes, usa las siguientes secuencias de comandos:
Implementa un DaemonSet para limpiar todos los datos sucios en búferes en fluent-bit:
Herramientas de redes, entorno de ejecución de VM en GDC
1.14.0
Si reinicias Dataplane V2 (anetd) en los clústeres, es posible que las VMs existentes no se puedan conectar a una red que no sea del Pod.
En clústeres de varios NIC, reiniciar Dataplane V2 (anetd) puede provocar que las máquinas virtuales no se puedan conectar a las redes. Se puede observar un error similar al siguiente en los registros del Pod anetd:
could not find an allocator to allocate the IP of the multi-nic endpoint
Solución alternativa:
Puedes reiniciar la VM como solución rápida. Para evitar que el problema vuelva a ocurrir, actualiza el clúster a la versión 1.14.1 o una posterior.
Operación
1.13, 1.14.0, 1.14.1
gke-metrics-agent no tiene límite de memoria en clústeres de perfiles de Edge.
Según la carga de trabajo del clúster, el gke-metrics-agent puede usar más de 4,608 MiB de memoria. Este problema solo afecta a
GKE en los clústeres de perfil de Bare Metal Edge. Los clústeres de perfiles predeterminados no
se ven afectados.
Solución alternativa:
Actualiza tu clúster a la versión 1.14.2 o posterior.
Instalación
1.12, 1.13
La creación del clúster puede fallar debido a condiciones de carrera
Cuando creas clústeres con kubectl, es posible que la verificación preliminar nunca finalice debido a las condiciones de carrera. Como resultado, la creación del clúster puede fallar en ciertos casos.
El conciliador de verificación previa crea un SecretForwarder
para copiar el secreto ssh-key predeterminado en el espacio de nombres de destino.
Por lo general, la comprobación preliminar aprovecha las referencias de propietario y
se concilia una vez que se completa el SecretForwarder. Sin embargo, en
casos excepcionales, las referencias del propietario de SecretForwarder pueden
perder la referencia a la comprobación preliminar, lo que provoca que la comprobación preliminar se detenga. Como resultado, la creación del clúster falla. Para continuar con la
conciliación de la verificación preliminar controlada por el controlador, borra el
Pod del operador del clúster o el recurso de verificación previa. Cuando
borras el recurso de comprobación previa, se crea otro y continúa
la conciliación. Como alternativa, puedes actualizar tus clústeres existentes
(que se crearon con una versión anterior) a una versión fija.
Herramientas de redes
1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Las direcciones IP reservadas no se liberan cuando se usa el complemento ubicación con la función de varias NIC.
En la función de varios Nic, si usas el complemento de ubicación de CNI y usas la operación CNI DEL para borrar una interfaz de red para un Pod, es posible que algunas direcciones IP reservadas no se liberen correctamente. Esto sucede cuando se interrumpe la operación CNI DEL.
Para verificar las reservas de direcciones IP sin usar de los Pods, ejecuta el siguiente comando:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Solución alternativa:
Borra de forma manual las direcciones IP (ippools) que no se usan.
Instalación
1.10, 1.11.0, 1.11.1, 1.11.2
El detector de problemas de nodos falla en el clúster de usuario 1.10.4
El detector de problemas de nodos puede fallar en los clústeres de usuario de la versión 1.10.x, cuando los clústeres de administrador de las versiones 1.11.0, 1.11.1 o 1.11.2 administran los clústeres de usuario 1.10.x. Cuando falla el detector de problemas de nodos, el registro se actualiza con el siguiente mensaje de error:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Solución alternativa
Actualiza el clúster de administrador a la versión 1.11.3 para resolver el problema.
Operación
1.14
Los nodos del clúster IPv4 de modo isla 1.14 tienen un tamaño de máscara CIDR
de Pod de 24.
En la versión 1.14, no se tiene en cuenta la configuración maxPodsPerNode para los clústeres de modo isla, por lo que a los nodos se les asigna un tamaño de máscara CIDR de Pod de 24 (256 direcciones IP).Esto podría provocar que el clúster se quede sin direcciones IP del Pod antes de lo esperado. Por ejemplo, si tu clúster tiene un tamaño de máscara de CIDR de Pod de 22, a cada nodo se le asignará una máscara de CIDR de Pod de 24 y el clúster solo podrá admitir hasta 4 nodos. Es posible que tu clúster
también experimente inestabilidad de la red en un período de alta deserción de Pods cuando maxPodsPerNode se establezca en 129 o un valor superior y no haya suficiente
sobrecarga en el CIDR del Pod para cada nodo.
Si tu clúster se ve afectado, el Pod anetd informa el
siguiente error cuando agregas un nodo nuevo al clúster y no hay
podCIDR disponible:
error="required IPv4 PodCIDR not available"
Solución alternativa
Sigue estos pasos para resolver el problema:
Actualiza a 1.14.1 o una versión posterior.
Quita los nodos trabajadores y vuelve a agregarlos.
Quita los nodos del plano de control y vuelve a agregarlos, preferentemente uno por uno para evitar el tiempo de inactividad del clúster.
Revisiones y actualizaciones
1.14.0, 1.14.1
Falla en la reversión de la actualización del clúster
Una reversión de actualización puede fallar para los clústeres de la versión 1.14.0 o 1.14.1.
Si actualizas un clúster de 1.14.0 a 1.14.1 y, luego, intentas revertirla a 1.14.0 mediante el comando bmctl restore cluster, es posible que se muestre un error como el del siguiente ejemplo:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Solución alternativa:
Borra todos los recursos healthchecks.baremetal.cluster.gke.io del espacio de nombres del clúster y, luego, vuelve a ejecutar el comando bmctl restore
cluster:
Enumera los healthchecks.baremetal.cluster.gke.io
recursos:
kubectl get healthchecks.baremetal.cluster.gke.io \
--namespace=CLUSTER_NAMESPACE \
--kubeconfig=ADMIN_KUBECONFIG
Reemplaza lo siguiente:
CLUSTER_NAMESPACE: Es el espacio de nombres del clúster.
ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
Borra todos los healthchecks.baremetal.cluster.gke.io recursos enumerados en el paso anterior:
Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de verificación de estado.
Vuelve a ejecutar el comando bmctl restore cluster.
Herramientas de redes
1.12.0
La dirección IP externa del servicio no
funciona en modo plano
En un clúster que tiene flatIPv4 configurado como true, no se puede acceder a los servicios de tipo LoadBalancer mediante sus direcciones IP externas.
Este problema se solucionó en la versión 1.12.1.
Solución alternativa:
En el ConfigMap cilium-config, configura enable-415 como "true" y, luego, reinicia los Pods anetd.
Revisiones y actualizaciones
1.13.0 y 1.14
Las actualizaciones in situ de la versión 1.13.0 a la 1.14.x nunca finalizan.
Cuando intentas realizar una actualización in situ de 1.13.0 a 1.14.x con bmctl 1.14.0 y la marca --use-bootstrap=false, la actualización nunca finaliza.
Un error con el operador preflight-check hace que el
clúster nunca programe las verificaciones requeridas, lo que significa que la verificación
preliminar nunca finaliza.
Solución alternativa:
Actualiza a la versión 1.13.1 antes de actualizar a la versión 1.14.x. Debería funcionar una actualización in situ de 1.13.0 a 1.13.1. También puedes actualizar de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.
Actualizaciones y actualizaciones, Seguridad
1.13 y 1.14
Los clústeres actualizados a la versión 1.14.0 pierden los taints de instancia principal.
Los nodos del plano de control requieren uno de dos taints específicos para evitar
que se programen Pods de carga de trabajo en ellos. Cuando actualizas los clústeres de GKE de la versión 1.13
a la versión 1.14.0, los nodos del plano de control pierden los
siguientes taints obligatorios:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Este problema no causa fallas de actualización, pero los Pods que no deben
ejecutarse en los nodos del plano de control pueden comenzar a hacerlo. Estos
Pods de cargas de trabajo pueden sobrecargar los nodos del plano de control y provocar inestabilidad
en el clúster.
Determina si te afecta esto
Busca los nodos del plano de control, usa el siguiente comando:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Para verificar la lista de taints en un nodo, usa el siguiente comando:
Si no se enumera ninguno de los taints necesarios, se verá afectado.
Solución alternativa
Usa los siguientes pasos para cada nodo del plano de control del clúster de la versión 1.14.0 afectado a fin de restablecer la función adecuada. Estos pasos son para el taint node-role.kubernetes.io/master:NoSchedule y los pods relacionados. Si deseas que los nodos del plano de control usen el taint PreferNoSchedule, ajusta los pasos según corresponda.
Busca pods sin la tolerancia node-role.kubernetes.io/master:NoSchedule:
kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
-o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
--kubeconfig KUBECONFIG_PATH | \
grep -v "node-role.kubernetes.io/master" | uniq
Borra los Pods que no tienen la tolerancia node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Operación, entorno de ejecución de VM en GDC
1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
La creación de la VM falla de forma intermitente con errores de carga
La creación de una máquina virtual (VM) nueva con el comando kubectl virt create vm falla con poca frecuencia durante la carga de imágenes. Este problema se aplica a las VMs de Linux y Windows. El error se parece al siguiente ejemplo:
PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51
2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s
fail to upload image: unexpected return value 500, ...
Solución alternativa
Vuelve a ejecutar el comando kubectl virt create vm para crear tu VM.
Actualizaciones y actualizaciones, registro y supervisión
1.11
Los componentes de la colección administrada en los clústeres 1.11 no se conservan en las actualizaciones a la versión 1.12.
Los componentes de la colección administrada forman parte de Managed Service para Prometheus.
Si implementaste manualmente los componentes de la recopilación administrada en el espacio de nombres gmp-system de los clústeres de la versión 1.11, los recursos asociados no se conservan cuando actualizas a la versión 1.12.
A partir de los clústeres de la versión 1.12.0, stackdriver-operator administra los componentes de Managed Service para Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionadas con el campo enableGMPForApplications. El campo enableGMPForApplications se establece de forma predeterminada como true, por lo que, si implementas de forma manual los componentes de Managed Service para Prometheus en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver-operator borrará los recursos.
Solución alternativa
Para conservar los recursos de recopilación administrada de forma manual, haz lo siguiente:
Crea una copia de seguridad de todos los recursos personalizados de PodMonitoring existentes.
Vuelve a implementar los recursos personalizados de PodMonitoring en tu clúster actualizado.
Revisiones y actualizaciones
1.13
Algunos clústeres de la versión 1.12 con el entorno de ejecución de contenedores de Docker no se pueden actualizar a la versión 1.13
Si a un clúster de la versión 1.12 que usa el entorno de ejecución del contenedor de Docker le falta la siguiente anotación, no se puede actualizar a la versión 1.13:
Si te afecta este problema, bmctl escribe el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.
Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.
Es más probable que esto ocurra con los clústeres de Docker de la versión 1.12 que se actualizaron desde la versión 1.11, ya que esa actualización no requiere la anotación para mantener el entorno de ejecución del contenedor de Docker. En este caso, los clústeres no tienen la anotación cuando se actualizan a la versión 1.13. Ten en cuenta que, a partir de la versión 1.13, containerd es el único entorno de ejecución de contenedores permitido.
Solución alternativa:
Si te afecta este problema, actualiza el recurso del clúster con
la anotación faltante. Puedes agregar la anotación mientras se ejecuta la actualización o después de cancelarla, y antes de reintentar la actualización.
Instalación
1.11
bmctl sale antes de que se complete la creación del clúster
La creación del clúster puede fallar en GDCV para la versión 1.11.0 de Bare Metal (este problema se solucionó en GDCV para la versión 1.11.1 de Bare Metal). En algunos casos, el comando bmctl create cluster se cierra antes de tiempo y escribe errores como los siguientes en los registros:
Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster
Solución alternativa
La operación con errores produce artefactos, pero el clúster no está
operativo. Si este problema te afecta, sigue estos pasos para limpiar los artefactos y crear un clúster:
Ver los pasos de la solución alternativa
Para borrar los artefactos del clúster y restablecer la máquina de nodos, ejecuta el siguiente comando:
bmctl reset -c USER_CLUSTER_NAME
Para iniciar la operación de creación del clúster, ejecuta el siguiente comando:
La marca --keep-bootstrap-cluster es importante si este comando falla.
Si el comando de creación del clúster se ejecuta correctamente, puedes omitir los pasos restantes. De lo contrario, continúa.
Ejecuta el siguiente comando para obtener la versión del clúster de arranque:
La creación del clúster falla cuando se usan varias NIC, containerd
y proxy HTTPS
La creación del clúster falla cuando tienes la siguiente combinación de
condiciones:
El clúster está configurado para usar containerd como el entorno de ejecución del contenedor (nodeConfig.containerRuntime establecido en containerd en el archivo de configuración del clúster, el valor predeterminado de GDCV para Bare Metal versión 1.13 y superior).
El clúster está configurado con el fin de proporcionar varias interfaces de red,
varias NIC, para Pods (clusterNetwork.multipleNetworkInterfaces
configurado como true en el archivo de configuración del clúster).
El clúster está configurado para usar un proxy (se especifica spec.proxy.url en el archivo de configuración del clúster). Aunque la creación del clúster falle, esta configuración se propaga cuando intentas crear uno. Puedes ver esta configuración del proxy como una variable de entorno HTTPS_PROXY o en tu configuración containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).
Solución alternativa
Agrega CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodo.
Instalación
1.10, 1.11, 1.12
Errores en sistemas con configuración restrictiva de umask
GDCV para Bare Metal versión 1.10.0 introdujo una función de plano de control sin raíz que ejecuta todos los componentes del plano de control como un usuario no raíz. Ejecutar todos los componentes como un usuario no raíz puede causar fallas de instalación o actualización en sistemas con una configuración de umask más restrictiva de 0077.
Solución alternativa
Restablece los nodos del plano de control y cambia la configuración de umask a 0022 en todas las máquinas del plano de control. Después de actualizar las máquinas, vuelve a intentar la instalación.
Como alternativa, puedes cambiar los permisos de directorio y archivo de /etc/kubernetes en las máquinas del plano de control para que la instalación o actualización continúe.
Haz que /etc/kubernetes y todos sus subdirectorios sean legibles en todo el mundo: chmod o+rx.
Permite que todos los archivos que pertenecen al usuario root del directorio /etc/kubernetes (de manera recurrente) sean legibles para todo el mundo (chmod o+r). Excluye los archivos de claves privadas (.key) de estos cambios, ya que se crearon con la propiedad y los permisos correctos.
Haz que /usr/local/etc/haproxy/haproxy.cfg sea legible en todo el mundo.
Haz que /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml sea legible en todo el mundo.
Instalación
1.10, 1.11, 1.12, 1.13
Incompatibilidad del grupo de control v2
El
grupo de control v2 (cgroup v2) no es compatible con GKE en las versiones 1.13 y anteriores de los clústeres de Bare Metal de GDCV para Bare Metal. Sin embargo, la versión 1.14 admite cgroup v2 como función de Versión preliminar
. La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.
Solución alternativa
Si tu sistema usa cgroup v2, actualiza tu clúster a la versión 1.14.
Instalación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Verificaciones de comprobación previa y credenciales de cuentas de servicio
En el caso de las instalaciones activadas por clústeres híbridos o de administrador (en otras
palabras, clústeres que no se crearon con bmctl, como los clústeres de usuario),
la verificación previa no verifica las credenciales de la cuenta de servicio de
Google Cloud ni sus permisos asociados.
Instalación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Realiza la instalación en vSphere
Cuando instalas GKE en clústeres Bare Metal en VMs de vSphere, debes desactivar las marcas
tx-udp_tnl-segmentation y
tx-udp_tnl-csum-segmentation. Estas marcas están
relacionadas con la descarga de segmentación de hardware realizada por el controlador de vSphere VMXNET3
y no funcionan con el túnel GENEVE de
GKE en los clústeres de Bare Metal.
Solución alternativa
Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de estas marcas:
ethtool -k NET_INTFC | grep segm
Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.
La respuesta debe tener entradas como las siguientes:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas, pero no lo están. Para desactivar de forma explícita estas marcas, actívalas y, luego, desactívalas con los siguientes comandos:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
tx-udp_tnl-csum-segmentation off
Este cambio de marca no persiste en los reinicios. Configura las secuencias de comandos de inicio para establecer de forma explícita estas marcas cuando se inicie el sistema.
Revisiones y actualizaciones
1.10
bmctl no puede crear, actualizar ni restablecer clústeres de usuario de versiones anteriores
La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria anterior, sin importar la versión del clúster de
administrador. Por ejemplo, no puedes usar bmctl con una versión de 1.N.X para restablecer un clúster de usuario de la versión 1.N-1.Y, incluso si el clúster de administrador también está en la versión 1.N.X.
Si te afecta este problema, deberías ver registros similares a los siguientes cuando uses bmctl:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
* cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Solución alternativa:
Usa kubectl para crear, editar o borrar el recurso personalizado del clúster de usuario dentro del clúster de administrador.
La capacidad de actualizar los clústeres de usuario no se ve afectada.
Revisiones y actualizaciones
1.12
Es posible que se detengan las actualizaciones del clúster a la versión 1.12.1
La actualización de los clústeres a la versión 1.12.1 a veces se detiene debido a que el servidor de la API no está disponible. Este problema afecta a todos los tipos de clústeres y a todos los
sistemas operativos compatibles. Cuando ocurre este problema, el comando bmctl
upgrade cluster puede fallar en varios puntos, incluso durante la segunda fase de las comprobaciones preliminares.
Solución alternativa
Puedes verificar tus registros de actualización para determinar si este problema te afecta. Los registros de actualización se encuentran en
/baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP de forma predeterminada.
upgrade-cluster.log puede contener errores como los siguientes:
Failed to upgrade cluster: preflight checks failed: preflight check failed
El registro de la máquina puede contener errores como los siguientes (las fallas reiteradas indican que te afecta este problema):
WorkManager y Keepalived deben ejecutarse en cada nodo del plano de control antes de que vuelvas a intentar actualizar tu clúster a la versión 1.12.1. Usa la
interfaz de línea de comandos de crictl en cada nodo para verificar si los contenedores haproxy y keepalived se están ejecutando:
Si MediaStore o Keepalived no se ejecutan en un nodo, reinicia kubelet en el nodo:
systemctl restart kubelet
Actualizaciones, entorno de ejecución de VM en GDC
1.11, 1.12
La actualización de clústeres a la versión 1.12.0 o posterior falla cuando
el entorno de ejecución de VM en GDC está habilitado.
En la versión 1.12.0 de GKE en clústeres de Bare Metal, todos los recursos relacionados con el entorno de ejecución de VM en GDC se migran al espacio de nombres vm-system para admitir mejor el entorno de ejecución de VM en la versión de DG de GDC. Si tienes habilitado el entorno de ejecución de VM en GDC en un clúster de la versión 1.11.x o anterior, la actualización a la versión 1.12.0 o posterior fallará, a menos que primero inhabilites el entorno de ejecución de VM en GDC. Cuando te ves afectado por este problema, la operación de actualización informa el siguiente error:
Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version
Solución alternativa
Para inhabilitar el entorno de ejecución de la VM en GDC, sigue estos pasos:
Edita el recurso personalizado VMRuntime:
kubectl edit vmruntime
Establece enabled como false en la especificación:
La actualización se detuvo en error during manifests operations
En algunas situaciones, las actualizaciones del clúster no se completan y la
CLI de bmctl deja de responder. Este problema puede deberse a que un recurso se actualizó de forma incorrecta. Para determinar si te afecta este problema y corregirlo, consulta los registros anthos-cluster-operator y busca errores similares a las siguientes entradas:
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Estas entradas son un síntoma de un recurso actualizado de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso que causa problemas.
Solución alternativa
Si encuentras estos errores en tus registros, completa los siguientes pasos:
Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso contenido en el mensaje de registro.
Guarda los cambios y aplícalos al recurso.
Vuelve a intentar la actualización del clúster.
Revisiones y actualizaciones
1.10, 1.11, 1.12
Las actualizaciones están bloqueadas para los clústeres con funciones que usan la puerta de enlace de red para GDC
Las actualizaciones de los clústeres de la versión 1.10.x a la 1.11.x fallan para los clústeres que usan
puerta de enlace NAT de salida o
balanceo de cargas agrupado con
BGP. Ambas funciones usan la puerta de enlace de red para GDC. Las actualizaciones del clúster
se detienen en el mensaje de línea de comandos
Waiting for upgrade to complete... y anthos-cluster-operator registra errores
como los siguientes:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Solución alternativa
Para desbloquear la actualización, ejecuta los siguientes comandos en el clúster que estás actualizando:
bmctl update no quita los bloques de mantenimiento
El comando bmctl update no puede quitar ni modificar la sección maintenanceBlocks de la configuración de recursos del clúster.
Solución alternativa
Si deseas obtener más información, incluidas las instrucciones para quitar nodos del modo de mantenimiento, consulta Coloca nodos en modo de mantenimiento.
Operación
1.10, 1.11, 1.12
Nodos desacordonados si no usas el procedimiento del modo de mantenimiento
Si ejecutas clústeres de la versión 1.12.0 (anthosBareMetalVersion: 1.12.0) o anteriores y usas kubectl cordon de forma manual en un nodo, GKE en Bare Metal podría desacordonar el nodo antes de que estés listo en un esfuerzo por conciliar el estado esperado.
Solución alternativa
Para los clústeres de la versión 1.12.0 y anteriores, usa el
modo de mantenimiento a fin de
acordonar y vaciar los nodos de forma segura.
En la versión 1.12.1 (anthosBareMetalVersion: 1.12.1) o
posterior, GKE en Bare Metal no desacordonará los nodos de forma inesperada cuando
uses kubectl cordon.
Operación
1.11
Los clústeres de administrador de la versión 11 que usan una duplicación del registro no pueden administrar los clústeres de la versión
1.10
Si el clúster de administrador está en la versión 1.11 y usa una duplicación del registro, no puede administrar los clústeres de usuario que se encuentren en una versión secundaria inferior. Este problema
afecta las operaciones de restablecimiento, actualización y actualización del clúster de usuario.
Para determinar si este problema te afecta, revisa tus registros en busca de
operaciones de clúster, como crear, actualizar o restablecer. Estos registros se encuentran en la carpeta bmctl-workspace/CLUSTER_NAME/ de forma predeterminada. Si te afecta el problema, tus registros contienen el siguiente mensaje de error:
flag provided but not defined: -registry-mirror-host-to-endpoints
Operación
1.10, 1.11
El secreto de kubeconfig reemplazó
Cuando se ejecuta en clústeres de usuario, el comando bmctl check cluster reemplaza el Secreto de kubeconfig del clúster de usuario por el kubeconfig del clúster de administrador. Reemplazar el archivo provoca que las operaciones de clúster estándar, como la actualización y la actualización, fallen para los clústeres de usuario afectados. Este problema se aplica a las versiones 1.11.1 y anteriores del clúster de GKE en Bare Metal.
Para determinar si este problema afecta a un clúster de usuario, ejecuta el siguiente comando:
ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
USER_CLUSTER_NAMESPACE: Es el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres del clúster para
los clústeres de GKE en Bare Metal son el nombre del clúster precedido por
cluster-. Por ejemplo, si le asignas el nombre test a tu clúster, el espacio de nombres predeterminado es cluster-test.
USER_CLUSTER_NAME: Es el nombre del clúster de usuario que se verificará.
Si el nombre del clúster en el resultado (consulta contexts.context.cluster en el siguiente resultado de muestra) es el nombre del clúster de administrador, el clúster de usuario especificado se ve afectado.
Sigue estos pasos para restablecer la función en un clúster de usuario afectado
(USER_CLUSTER_NAME):
Ubica el archivo kubeconfig del clúster de usuario. GKE en Bare Metal genera el archivo kubeconfig en la estación de trabajo de administrador cuando creas un clúster. De forma predeterminada, el archivo se encuentra en el directorio bmctl-workspace/USER_CLUSTER_NAME.
Verifica que el kubeconfig sea el kubeconfig del clúster de usuario correcto:
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Reemplaza PATH_TO_GENERATED_FILE por la ruta de acceso al archivo kubeconfig del clúster de usuario. La respuesta muestra detalles sobre los nodos del clúster de usuario. Confirma que los nombres de las máquinas sean
correctos para tu clúster.
Ejecuta el siguiente comando para borrar el archivo kubeconfig dañado en el clúster de administrador:
Captura una instantánea como usuario no raíz de acceso
Si usas containerd como entorno de ejecución del contenedor, ejecutar la instantánea como usuario no raíz requiere que /usr/local/bin esté en la ruta de acceso del usuario.
De lo contrario, fallará con el error crictl: command not found.
Cuando no accedes como usuario raíz, sudo se usa para ejecutar los comandos de la instantánea. La ruta de acceso sudo puede diferir del perfil raíz y no puede contener /usr/local/bin.
Solución alternativa
Actualiza secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.
Registro y supervisión
1.10
stackdriver-log-forwarder tiene [parser:cri] invalid
time format registros de advertencia
[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'
Solución alternativa:
Ver los pasos de la solución alternativa
Actualiza tu clúster a la versión 1.11.0 o posterior.
Si no puedes actualizar tus clústeres de inmediato, sigue estos pasos para actualizar la regex de análisis de CRI:
Para evitar que se reviertan los siguientes cambios, reduce verticalmente la escala de stackdriver-operator:
[PARSER]
# https://rubular.com/r/Vn30bO78GlkvyB
Name cri
Format regex
# The timestamp is described in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
{2}:[0-9]{2})) (?<stream>stdout|stderr)
(?<logtag>[^ ]*) (?<log>.*)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Reinicia los Pods del servidor de reenvío de registros:
Para las versiones de 1.10 a 1.15 del clúster de GKE en Bare Metal, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema te afecta solo cuando se cumplen todas las siguientes circunstancias:
La supervisión de aplicaciones está habilitada (enableStackdriverForApplications=true)
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 solucione el problema:
Marcas separadas para controlar la recopilación de los registros de la aplicación y las métricas de la aplicación
Google Cloud Managed Service para Prometheus
Si no puedes actualizar a la versión 1.12, sigue estos pasos:
Busca los Pods y Services 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 Service.
Registro y supervisión
1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Los cambios en metrics-server-config no se conservan
En casos extremos, una densidad alta de Pods puede crear una sobrecarga excesiva de registro y supervisión, lo que puede hacer que el servidor de métricas se detenga y se reinicie. Puedes editar el ConfigMap metrics-server-config para asignar más recursos y mantener en ejecución el servidor de métricas. Sin embargo, debido a la conciliación,
las ediciones realizadas en metrics-server-config pueden
revertirse al valor predeterminado durante una operación de actualización o actualización del clúster.
El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, recoge el ConfigMap revertido y vuelve a ser vulnerable a una sobrecarga excesiva.
Solución alternativa
Para la versión 1.11.x, puedes crear una secuencia de comandos de edición del ConfigMap y realizarla junto con
actualizaciones del clúster. Para la versión 1.12 y posteriores, comunícate con el equipo de asistencia.
Registro y supervisión
1.11, 1.12
Las métricas obsoletas afectan el panel de Cloud Monitoring
Varias métricas de GKE en Bare Metal dejaron de estar disponibles y, a partir de GDCV para Bare Metal versión 1.11, ya no se recopilan datos para estas métricas obsoletas. Si usas estas métricas en alguna de tus políticas de alertas, no habrá ningún dato para activar la condición de alerta.
En la siguiente tabla, se enumeran las métricas individuales que dejaron de estar disponibles y la métrica que las reemplaza.
En las versiones anteriores a 1.11 del clúster de GKE en Bare Metal, el archivo de definición de la política para la alerta de Anthos on baremetal node cpu usage exceeds
80 percent (critical) recomendada usa las métricas obsoletas. El archivo de definición JSON node-cpu-usage-high.json se actualiza para las versiones 1.11.0 y posteriores.
Solución alternativa
Sigue estos pasos para migrar a las métricas de reemplazo:
En la consola de Google Cloud, selecciona Monitoring o haz clic en el
siguiente botón: Ir a Monitoring
En el panel de navegación, selecciona Paneles y borra el panel Estado del nodo del clúster de Anthos (Anthos cluster node status).
Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel Estado del nodo del clúster de Anthos.
stackdriver-log-forwarder tiene errores CrashloopBackOff
En algunas situaciones, el agente de registro fluent-bit puede atascarse procesando fragmentos dañados. Cuando el agente de Logging no puede omitir los fragmentos dañados, es posible que observes que stackdriver-log-forwarder sigue fallando con un error CrashloopBackOff. Si tienes este problema, tus
registros tienen entradas como las siguientes
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5
in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0
Solución alternativa:
Limpia los fragmentos del búfer del servidor de reenvío de registros de Stackdriver.
Nota: En los siguientes comandos, reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.
Finaliza todos los Pods stackdriver-log-forwarder:
Estos registros de errores se pueden ignorar de forma segura, ya que las métricas a las que hacen referencia no son
compatibles y no son fundamentales para la supervisión.
Registro y supervisión
1.10, 1.11
Interrupciones intermitentes en la exportación de métricas
Es posible que los clústeres de GKE en Bare Metal experimenten interrupciones en la exportación continua
y normal de métricas, o bien métricas faltantes en algunos nodos. Si este problema afecta a los clústeres, es posible que veas brechas en los datos de las siguientes métricas (como mínimo):
El comando encuentra cpu: 50m si tus ediciones se aplicaron.
Herramientas de redes
1.10
Múltiples puertas de enlace predeterminadas interrumpen la conectividad a extremos externos
Tener varias puertas de enlace predeterminadas en un nodo puede causar una conectividad interrumpida desde un Pod hasta extremos externos, como google.com.
Para determinar si te afecta este problema, ejecuta el siguiente comando en el nodo:
ip route show
Varias instancias de default en la respuesta indican que te ves afectado.
Herramientas de redes
1.12
Se reemplazan las ediciones de recursos personalizados de las Herramientas de redes en los clústeres de usuario
La versión 1.12.x de GKE en clústeres de Bare Metal no te impide editar manualmente los recursos personalizados de las redes en tu clúster de usuario. GKE en Bare Metal concilia los recursos personalizados
en los clústeres de usuario con los recursos personalizados en el clúster de administrador
durante las actualizaciones del clúster. Esta conciliación reemplaza cualquier edición realizada directamente en los recursos personalizados de red en el clúster de usuario. Los
recursos personalizados de herramientas de redes se deben modificar solo en el clúster de administrador,
pero los clústeres de la versión 1.12.x no aplican este requisito.
Edita estos recursos personalizados en el clúster de administrador y el
paso de conciliación aplica los cambios a los clústeres de usuario.
Solución alternativa
Si modificaste alguno de los recursos personalizados mencionados anteriormente en
un clúster de usuario, modifica los recursos personalizados correspondientes en tu clúster de
administrador para que coincidan antes de la actualización. Este paso garantiza que se conserven los cambios de configuración. Las versiones 1.13.0 y posteriores de los clústeres de GKE en Bare Metal evitan que modifiques los recursos personalizados de red en los clústeres de usuario directamente.
Herramientas de redes
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Fallas de conectividad del Pod y filtrado de la ruta de acceso inversa
GKE en Bare Metal configura el filtrado de ruta inversa en los nodos para inhabilitar la validación de la fuente (net.ipv4.conf.all.rp_filter=0). Si la configuración rp_filter se cambia a 1 o 2, los Pods fallarán debido a los tiempos de espera de la comunicación fuera del nodo.
El filtrado de rutas de acceso inversas se establece con los archivos rp_filter en la carpeta de configuración IPv4 (net/ipv4/conf/all). sysctl también puede anular este valor, ya que almacena los ajustes del filtrado de rutas de acceso inversas en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.
Solución alternativa
La conectividad del Pod se puede restablecer mediante una de las siguientes soluciones alternativas:
Vuelve a establecer el valor de net.ipv4.conf.all.rp_filter en 0 de forma manual y, luego, ejecuta sudo sysctl -p para aplicar el cambio.
O
Reinicia el Pod anetd para volver a establecer net.ipv4.conf.all.rp_filter como 0. Para reiniciar el Pod anetd, usa los siguientes comandos a fin de ubicar y borrar el Pod anetd, y se iniciará un Pod anetd nuevo en su lugar:
Después de implementar cualquiera de las soluciones alternativas, verifica que el valor net.ipv4.conf.all.rp_filter se establezca en 0 mediante la ejecución de sysctl net.ipv4.conf.all.rp_filter en cada nodo.
Herramientas de redes
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Las direcciones IP del clúster de arranque (tipo) y las direcciones IP del nodo del clúster
se superponen
192.168.122.0/24 y 10.96.0.0/27 son los CIDR predeterminados del Pod y del servicio que usa el clúster de arranque (tipo).
Las comprobaciones preliminares fallarán si se superponen con las direcciones IP de la máquina del nodo del clúster.
Solución alternativa
Para evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl para especificar valores diferentes.
Sistema operativo
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
La creación o actualización del clúster falla en CentOS
En diciembre de 2020, la comunidad de CentOS y Red Hat anunciaron la baja de CentOS. El 31 de enero de 2022, CentOS 8 alcanzó su final del ciclo de vida (EOL). Como resultado del EOL, los repositorios de yum dejaron de funcionar para CentOS, lo que provoca que las operaciones de creación y actualización de clústeres fallen. Esto se aplica a todas las versiones compatibles de CentOS y
afecta a todas las versiones de GKE en clústeres de Bare Metal.
Solución alternativa
Ver los pasos de la solución alternativa
Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivo:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
El contenedor no puede escribir en VOLUME definido en Dockerfile con containerd y SELinux
Si usas containerd como entorno de ejecución del contenedor y tu sistema operativo tiene SELinux habilitado, es posible que el VOLUME definido en el Dockerfile de la aplicación no se pueda escribir. Por ejemplo, los contenedores compilados con el siguiente Dockerfile no pueden escribir en la carpeta /tmp.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
Para verificar si te afecta este problema, ejecuta el siguiente comando en el nodo que aloja el contenedor problemático:
ausearch -m avc
Si te afecta este problema, verás un error denied como el siguiente:
Para solucionar el problema, realiza uno de los siguientes cambios:
Desactiva SELinux.
No uses la función VOLUME dentro del Dockerfile.
Revisiones y actualizaciones
1.10, 1.11, 1.12
El detector de problemas de nodos no está habilitado de forma predeterminada después de las actualizaciones del clúster.
Cuando actualizas GKE en clústeres de Bare Metal, el detector de problemas de nodos no está habilitado de forma predeterminada. Este problema se aplica a las actualizaciones de la versión 1.10 a la 1.12.1 y se corrigió en la versión 1.12.2.
Solución alternativa:
Para habilitar el detector de problemas de nodos, sigue estos pasos:
Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
Usa el comando SSH y conéctate al nodo.
Verifica si se está ejecutando el servicio node-problem-detector systemd en el nodo:
systemctl is-active node-problem-detector
Si el resultado del comando muestra inactive, significa que el detector de problemas del nodo no se está ejecutando en el nodo.
Para habilitar el detector de problemas de nodos, usa el comando kubectl edit y edita el ConfigMap de node-problem-detector-config. Para obtener más información, consulta Detector de problemas de nodos.
Operación
1.9, 1.10
La copia de seguridad del clúster falla cuando se usa un acceso que no es raíz
El comando bmctl backup cluster falla si nodeAccess.loginUser se configura como un nombre de usuario que no es raíz].
Solución alternativa:
Este problema se aplica a las versiones 1.9.x, 1.10.0 y 1.10.1, y se corrige en las versiones 1.10.2 y posteriores.
Herramientas de redes
1.10, 1.11, 1.12
Los servicios del balanceador de cargas no funcionan con contenedores en la red del host del
plano de control
Hay un error en anetd en el que los paquetes se descartan para los servicios de LoadBalancer si los Pods de backend se ejecutan en el nodo del plano de control y usan el campo hostNetwork: true en las especificaciones del contenedor.
El error no está presente en la versión 1.13 ni en versiones posteriores.
Solución alternativa:
Las siguientes soluciones alternativas pueden ser útiles si usas un servicio LoadBalancer respaldado por Pods hostNetwork:
Ejecútalas en nodos trabajadores (no en nodos del plano de control).
El Pod de anthos-version-$version$ huérfano no pudo extraer la imagen
El clúster que se actualiza de 1.12.x a 1.13.x puede observar un Pod anthos-version-$version$ con errores con el error ImagePullBackOff.
Esto sucede debido a que se actualiza la condición de carrera de anthos-cluster-operator y no debería afectar ninguna capacidad normal del clúster.
El error no está presente después de la versión 1.13 o posterior.
Solución alternativa:
Borra el trabajo de dynamic-version-installer mediante kubectl delete job anthos-version-$version$ -n kube-system
.
Revisiones y actualizaciones
1.13
Los clústeres 1.12 actualizados de la versión 1.11 no se pueden actualizar a la versión 1.13.0
Los clústeres de la versión 1.12 que se actualizaron desde la versión 1.11 no se pueden
actualizar a la versión 1.13.0. Este problema de actualización no se aplica a los clústeres
que se crearon en la versión 1.12.
Para determinar si te ves afectado, verifica los registros del trabajo de actualización que contiene la cadena upgrade-first-no* en el clúster de administrador.
Si ves el siguiente mensaje de error, esto te afecta.
Hay un problema en stackdriver-operator que hace que consuma más tiempo de CPU de lo normal. El uso normal de CPU es inferior a 50 millicores de CPU (50m) para stackdriver-operator en estado inactivo. La causa es una discrepancia de los recursos de certificado que stackdriver-operator aplica con las expectativas de cert-manager. Esta discrepancia genera una condición de carrera entre cert-manager y stackdriver-operator en la actualización de esos recursos.
Este problema puede reducir el rendimiento en los clústeres con disponibilidad
de CPU limitada.
Solución alternativa:
Hasta que puedas actualizar a una versión que haya corregido este error, usa la siguiente solución alternativa:
Para reducir temporalmente la escala de stackdriver-operator a 0
réplicas, aplica un recurso personalizado AddonConfiguration:
El scraping de métricas basadas en anotaciones no funciona
En el GDCV para la versión secundaria de Bare Metal 1.16, el campo enableStackdriverForApplications en la especificación de recursos personalizados stackdriver dejó de estar disponible. Este campo se reemplazó por dos campos, enableCloudLoggingForApplications y enableGMPForApplications, en el recurso personalizado de Stackdriver.
Te recomendamos que uses Google Cloud Managed Service para Prometheus a fin de supervisar
tus cargas de trabajo. Usa el campo enableGMPForApplications para habilitar esta función.
Si dependes de la recopilación de métricas activada por anotaciones prometheus.io/scrape en tus cargas de trabajo, puedes usar la marca de puerta de atributos annotationBasedApplicationMetrics para mantener el comportamiento anterior. Sin embargo, hay un problema que impide que annotationBasedApplicationMetrics funcione correctamente, lo que impide la recopilación de métricas de tus aplicaciones en Cloud Monitoring.
Solución alternativa:
Para resolver este problema, actualiza tu clúster a la versión 1.16.2 o superior.
La recopilación de métricas de carga de trabajo basadas en anotaciones que permite la puerta de funciones annotationBasedApplicationMetrics recopila métricas de los objetos que tienen la anotación prometheus.io/scrape. Muchos sistemas de software con origen de código abierto pueden usar esta anotación. Si continúas usando este método de recopilación de métricas, ten en cuenta esta dependencia para que no te sorprendan los cargos de métricas en Cloud Monitoring.
Paneles y borra el panel Estado del nodo del clúster de Anthos (Anthos cluster node status).