En este documento, se describen los problemas conocidos de la versión 1.8 de los clústeres de Anthos alojados en VMware (GKE On-Prem).
/var/log/audit/ llenando espacio en disco
Categoría
SO
Versiones identificadas
1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+ y 1.12.0+, 1.13.0+
Síntomas
/var/log/audit/
está lleno de registros de auditoría. Para verificar el uso del disco, ejecuta sudo du -h -d 1 /var/log/audit
.
Causa
A partir de Anthos v1.8, la imagen de Ubuntu se endurece con la comparativa de CIS de nivel 2. Además, una de las reglas de cumplimiento, 4.1.2.2 Ensure audit logs are not automatically deleted
, garantiza la configuración auditada max_log_file_action = keep_logs
. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.
Solución alternativa
Estación de trabajo de administrador
En la estación de trabajo de administrador, puedes cambiar de forma manual la configuración auditd para rotar los registros de forma automática y, luego, reiniciar el servicio auditd:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
La configuración anterior haría que la auditoría rote automáticamente sus registros una vez que haya generado más de 250 archivos (cada uno con un tamaño de 8 millones).
Nodos del clúster
Para los nodos del clúster, aplica el siguiente DaemonSet a tu clúster a fin de evitar posibles problemas:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Ten en cuenta que realizar este cambio de configuración auditado infringiría la regla de nivel 2 de CIS 4.1.2.2 Ensure audit logs are not automatically deleted
.
La actualización o actualización del clúster de usuario falla debido a que “no se pudo registrar el clúster de usuario”
Categoría
Actualizar
Versiones identificadas
1.7.0+, 1.8.0 o superior
Síntomas
Ejecuta gkectl diagnose cluster
cuando se agote el tiempo de espera de un comando gkectl
anterior en los siguientes casos.
- La actualización de clústeres de usuario con GKE Connect se habilitó en versiones 1.8.
- Ejecutar
gkectl update cluster
en clústeres de usuario 1.8 con GKE Connect habilitado - Ejecutar
gkectl update cluster
para habilitar GKE Connect en clústeres de usuarios 1.8
$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
Unhealthy Resources:
OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...
Ten en cuenta que la funcionalidad de GKE Connect no se verá afectada. En otras palabras, si GKE Connect funcionaba antes del comando, debería seguir funcionando.
Causa
La versión 20210514-00-00
del agente de Connect que se usa en las versiones 1.8 es incompatible.
Solución alternativa
Comunícate con Atención al cliente de Google para mitigar el problema.
No se ejecuta systemd-timesyncd después del reinicio en el nodo de Ubuntu
Categoría
SO
Versiones identificadas
1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+
Síntomas
systemctl status systemd-timesyncd
debe mostrar que el servicio no funciona:
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Esto podría causar problemas de tiempo de inactividad.
Causa
chrony
se instaló de forma incorrecta en la imagen de Ubuntu. Además, hay un conflicto entre chrony
y systemd-timesyncd
, en la que systemd-timesyncd
se vuelve inactivo y chrony
se activa cada vez que se reinicia la VM de Ubuntu. Sin embargo, systemd-timesyncd
debe ser el cliente ntp predeterminado para la VM.
Solución alternativa
Opción 1: Ejecuta restart systemd-timesyncd
de forma manual cada vez que se reinicie la VM.
Opción 2: Implementa el siguiente Daemonset para que systemd-timesyncd
siempre se reinicie si no funciona.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ensure-systemd-timesyncd
spec:
selector:
matchLabels:
name: ensure-systemd-timesyncd
template:
metadata:
labels:
name: ensure-systemd-timesyncd
spec:
hostIPC: true
hostPID: true
containers:
- name: ensure-systemd-timesyncd
# Use your preferred image.
image: ubuntu
command:
- /bin/bash
- -c
- |
while true; do
echo $(date -u)
echo "Checking systemd-timesyncd status..."
chroot /host systemctl status systemd-timesyncd
if (( $? != 0 )) ; then
echo "Restarting systemd-timesyncd..."
chroot /host systemctl start systemd-timesyncd
else
echo "systemd-timesyncd is running."
fi;
sleep 60
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "10m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
````
## ClientConfig custom resource
`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.
## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions
<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>
## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}
Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).
## Nodes fail to complete their upgrade process
If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.
To see all `PodDisruptionBudget` objects that do not allow any disruptions:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}' ``
No se pudo instalar el clúster de usuario debido al problema de elección de líder de cert-manager/ca-injector en Anthos 1.8.2 y 1.8.3
Es posible que veas una falla de instalación debido a cert-manager-cainjector
en el bucle de fallas, cuando apiserver/etcd es lento. El siguiente comando:
kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Ejecuta los siguientes comandos para mitigar el problema.
Primero, reduce la escala de monitoring-operator
para que no revierta los cambios a la Deployment cert-manager-cainjector
.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0
Segundo, aplique un parche a la Deployment cert-manager-cainjector
para inhabilitar la elección de líder, lo cual es seguro porque solo tenemos una réplica en ejecución. No es necesario si hay una sola réplica.
# Ensure that we run only 1 cainjector replica, even during rolling updates. kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch ' spec: strategy: rollingUpdate: maxSurge: 0 ' # Add a command line flag for cainjector: `--leader-elect=false` kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[ { "op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--leader-elect=false" } ]'
Mantén las réplicas de monitoring-operator
en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio.
Una vez que finalice la instalación y el clúster esté en funcionamiento, activa monitoring-operator
para las operaciones del día 2:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=1
Ten en cuenta que, después de actualizar a la versión 1.8.4 y superior (o 1.9.1 y superior, si actualizas a la versión 1.9), estos pasos ya no serán necesarios, ya que Anthos inhabilitará la elección de líder para Cainjector. Hasta entonces, si tienes este problema durante cada actualización, deberás volver a realizar los mismos pasos.
Puede que sea necesario renovar los certificados antes de que se actualice el clúster de administrador
Antes de comenzar el proceso de actualización de clústeres de administrador, debes asegurarte de que tus certificados de clúster de administrador sean actualmente válidos y renovarlos si no lo son.
Proceso de renovación del certificado del clúster de administrador
Antes de comenzar, asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador.
Configura la variable
KUBECONFIG
.KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Reemplaza ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG por la ruta absoluta al archivo kubeconfig del clúster de administrador.
Obtén la dirección IP y las claves SSH del nodo principal de administrador:
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Verifica si los certificados vencieron:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Si los certificados vencieron, debes renovarlos antes de actualizar el clúster de administrador.
Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes de la fecha de vencimiento.
Crea una copia de seguridad del archivo kubeconfig del clúster de administrador:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Reemplaza
client-certificate-data
yclient-key-data
en la kubeconfig porclient-certificate-data
yclient-key-data
en el archivonew_admin.conf
que creaste.
Crea una copia de seguridad de los certificados anteriores:
Este es un paso opcional, pero recomendado.
# ssh into admin master if you didn't in the previous step ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
Renueva los certificados con kubeadm:
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
Reinicia los Pods estáticos que se ejecutan en el nodo principal del administrador:
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
Renueva los certificados de los nodos trabajadores del clúster de administrador
Verifica la fecha de vencimiento de los certificados de nodos
kubectl get nodes -o wide # find the oldest node, fill NODE_IP with the internal ip of that node ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}" openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem logout
Si el certificado está a punto de vencer, renueva los certificados de nodo mediante la reparación manual de nodos.
Debes validar los certificados renuevas y el certificado de kube-apiserver.
Verifica el vencimiento de los certificados:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Verifica el certificado de kube-apiserver:
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
La secuencia de comandos /etc/cron.daily/aide usa todo el espacio en /run, lo que provoca un bloqueo en los Pods.
A partir de los clústeres de Anthos alojados en VMware 1.7.2, las imágenes del SO Ubuntu se endurecen con la comparativa del servidor L1 de CIS.
.
Como resultado, se instaló la secuencia de comandos cron /etc/cron.daily/aide
para que se programe una verificación de ayuda a fin de garantizar la regla del servidor L1 de CIS “1.4.2 Asegurarse de que la integridad del sistema de archivos se verifique con regularidad”.
La secuencia de comandos usa /run/aide
como directorio temporal para guardar sus registros cron y, con el tiempo, podría usar todo el espacio en /run
. Consulta la secuencia de comandos /etc/cron.daily/aide usa todo el espacio en /run para obtener una solución alternativa.
Si ves que uno o más Pods se encuentran en un bucle de fallas en un nodo, ejecuta df -h /run
en el nodo. Si el resultado del comando muestra un uso del 100% del espacio, es probable que estés experimentando este problema.
Este problema se corrigió en la versión 1.8.1. Para las versiones 1.7.2 y 1.8.0, puedes resolver este problema de forma manual con cualquiera de las siguientes dos soluciones:
- Quita los archivos de registro de forma periódica en
/run/aide/cron.daily.old*
(recomendado). - Sigue los pasos mencionados en la secuencia de comandos /etc/cron.Daily/aide para usar todo el espacio de /run. (Nota: Esta solución alternativa podría afectar el estado de cumplimiento del nodo).
Actualiza el balanceador de cargas de Seesaw con la versión 1.8.0
Si usas gkectl upgrade loadbalancer
para intentar actualizar algunos parámetros del balanceador de cargas de Seesaw en la versión 1.8.0, esto no funcionará en modo DHCP o IPAM. Si su configuración incluye esta configuración, no actualice a la versión 1.8.0, sino a la versión 1.8.1 o posterior.
No se puede acceder a la estación de trabajo de administrador debido a un problema de vencimiento de la contraseña
Es posible que experimentes este problema si usas una de las siguientes versiones de clústeres de Anthos alojados en VMware.
- 1.7.2-gke.2
- 1.7.3-gke.2
- 1.8.0-gke.21
- 1.8.0-gke.24
- 1.8.0-gke.25
- 1.8.1-gke.7
- 1.8.2-gke.8
Es posible que recibas el siguiente error cuando intentes establecer una conexión SSH a tus VM de Anthos, incluida la estación de trabajo de administrador, los nodos del clúster y los nodos de Seesaw:
WARNING: Your password has expired.
Este error se produce porque la contraseña del usuario de ubuntu en las VM está vencida. Debes restablecer de forma manual el tiempo de vencimiento de la contraseña de usuario a un valor grande antes de acceder a las VM.
Prevención de error de vencimiento de contraseña
Si ejecutas las versiones afectadas que se mencionaron antes y la contraseña del usuario aún no venció, debes extender el tiempo de vencimiento antes de ver el error de SSH.
Ejecuta el siguiente comando en cada VM de Anthos:
sudo chage -M 99999 ubuntu
Mitigación del error de vencimiento de contraseña
Si la contraseña de usuario ya venció y no puedes acceder a las VM para extender el tiempo de vencimiento, realiza los siguientes pasos de mitigación para cada componente.
Estación de trabajo de administrador
Usa una VM temporal para realizar los siguientes pasos. Puedes crear una estación de trabajo de administrador con la versión 1.7.1-gke.4 para usarla como VM temporal.
Asegúrate de que la VM temporal y la estación de trabajo de administrador estén en estado de apagado.
Adjunta el disco de arranque de la estación de trabajo de administrador a la VM temporal. El disco de arranque es el que tiene la etiqueta “Hard disk 1”.
Activa el disco de arranque dentro de la VM mediante la ejecución de estos comandos. Sustituye tu propio identificador de disco de arranque por
dev/sdc1
.sudo mkdir -p /mnt/boot-disk sudo mount /dev/sdc1 /mnt/boot-disk
Configura la fecha de vencimiento del usuario de ubuntu en un valor grande, como
99999
días.sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
Apaga la VM temporal.
Enciende la estación de trabajo de administrador Ahora, deberías tener acceso SSH como de costumbre.
Como limpieza, borra la VM temporal.
VM del plano de control del clúster de administrador
Sigue las instrucciones para volver a crear la VM del plano de control del clúster de administrador.
VM del complemento del clúster de administrador
Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear la VM:
kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
Después de ejecutar este comando, espera a que las VM del complemento de clúster de administrador terminen de crear y estén listas antes de continuar con los pasos siguientes.
VM del plano de control del clúster de usuario
Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear las VM:
usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
Después de ejecutar este comando, espera a que las VM del plano de control del clúster de usuario terminen de crear y estén listas antes de continuar con los siguientes pasos.
VM de trabajador del clúster de usuario
Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear las VM.
for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done
VM de Seesaw
Ejecuta los siguientes comandos desde la estación de trabajo de administrador para volver a crear las VM de Seesaw. Habrá un tiempo de inactividad. Si la alta disponibilidad está habilitada en el balanceador de cargas, el tiempo de inactividad máximo es de dos segundos.
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff
Reinicia o actualiza vCenter para versiones anteriores a 7.0U2
Si vCenter, en versiones anteriores a 7.0U2, se reinicia después de una actualización o de otra manera, el nombre de red en la información de VM de vCenter es incorrecto y hace que la máquina esté en un estado Unavailable
. Finalmente, esto hace que los nodos se reparen automáticamente para crear otros nuevos.
Error relacionado de govmomi: https://github.com/vmware/govmomi/issues/2552
La solución alternativa la proporciona la asistencia de VMware:
1. The issue is fixed in vCenter versions 7.0U2 and above. 2. For lower versions: Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the VM's portgroup.
Error irrecuperable gkectl create-config admin
y gkectl create-config cluster
En las versiones 1.8.0-1.8.3, el comando gkectl create-config admin/cluster
entra en conflicto con el mensaje panic: invalid version: "latest"
.
Como solución alternativa, usa gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION
. Reemplaza DESIRED_CLUSTER_VERSION
por la versión deseada, como 1.8.2-gke.8.
Crea o actualiza el tiempo de espera del clúster de administrador
Este problema afecta a las versiones 1.8.0-1.8.3.
Es posible que se agote el tiempo de espera de la creación o actualización del clúster de administrador con el siguiente error:
Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory
Además, el registro en nodes/ADMIN_MASTER_NODE/files/var/log/startup.log
de la instantánea del clúster externo termina con este mensaje:
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
Este error ocurre cuando la red es lenta entre la VM del plano de control del administrador y el registro de contenedores. Asegúrate de inspeccionar la configuración de tu red o proxy para reducir la latencia y aumentar el ancho de banda.
Conexión SSH cerrada por host remoto
Para los clústeres de Anthos alojados en VMware versión 1.7.2 y posteriores, las imágenes del SO de Ubuntu se endurecen con la comparativa del servidor L1 de CIS.
Para cumplir con la regla de CIS “5.2.16 Asegúrate de que el intervalo de tiempo de espera de inactividad de SSH esté configurado”, /etc/ssh/sshd_config
tiene la siguiente configuración:
ClientAliveInterval 300 ClientAliveCountMax 0
El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0
genera un comportamiento inesperado. Cuando uses la sesión SSH en la estación de trabajo de administrador o un nodo del clúster, la conexión SSH podría desconectarse, incluso si tu cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y tu comando podría finalizar con el siguiente mensaje:
Connection to [IP] closed by remote host. Connection to [IP] closed.
Como solución alternativa, puedes hacer lo siguiente:
Usa
nohup
para evitar que el comando se finalice cuando te desconectes de SSH.nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
Actualiza
sshd_config
para usar un valorClientAliveCountMax
distinto de cero. La regla de CIS recomienda usar un valor inferior a 3.sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config sudo systemctl restart sshd
Asegúrate de volver a conectar tu sesión SSH.
Conflicto con cert-manager
cuando se actualiza a la versión 1.8.2 o superior
Si tienes tu propia instalación de cert-manager
con clústeres de Anthos alojados en VMware, es posible que experimentes una falla cuando intentes actualizar a las versiones 1.8.2 o posteriores. Esto es el resultado de un conflicto entre tu versión de cert-manager
, que probablemente esté instalada en el espacio de nombres cert-manager
, y la versión monitoring-operator
.
Si intentas instalar otra copia de cert-manager
después de actualizar a los clústeres de Anthos alojados en VMware 1.8.2 o versiones posteriores, es posible que la instalación falle debido a un conflicto con el existente que administra monitoring-operator
.
La entidad emisora del clúster metrics-ca
, en el que se basan los componentes del plano de control y la observabilidad para la creación y rotación de los secretos de certificado, requiere que un secreto de certificado metrics-ca
se almacene en el espacio de nombres del recurso del clúster. Este espacio de nombres es kube-system
para la instalación del operador de supervisión, y es probable que sea cert-manager
para la instalación.
Si experimentaste un error de instalación, sigue estos pasos para actualizar correctamente a la versión 1.8.2 o posterior:
Evita conflictos durante la actualización
Desinstala tu versión de
cert-manager
. Si definiste tus propios recursos, es posible que quieras crear una copia de seguridad.Realiza la actualización.
Sigue estas instrucciones para restablecer tu propio
cert-manager
.
Restablece tu propio cert-manager en los clústeres de usuario
Escala la implementación de
monitoring-operator
a 0.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0
Escala las implementaciones de
cert-manager
administradas pormonitoring-operator
a 0.kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
Reinstala el
cert-manager
del cliente. Restablecer los recursos personalizados si los tienesCopia el certificado
metrics-ca
cert-manager.io/v1 y los recursos de la entidad emisora demetrics-pki.cluster.local
dekube-system
al espacio de nombres del recurso del clúster de tu cert-manager instalado. El espacio de nombres cert-manager instalado escert-manager
si se usa la instalación cert-manager predeterminada ascendente, pero eso depende de la instalación.relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
Restablece tu propio cert-manager en los clústeres de administrador
En general, no es necesario volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan clústeres de Anthos en cargas de trabajo del plano de control de VMware. En los casos excepcionales en los que también necesite instalar su propio cert-manager en clústeres de administrador, siga las instrucciones que se indican a continuación para evitar conflictos. Tenga en cuenta que, si es cliente de Apigee y solo necesita cert-manager para Apigee, no necesita ejecutar los comandos del clúster de administrador.
Escala la implementación de
monitoring-operator
a 0.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0
Escala las implementaciones de
cert-manager
administradas pormonitoring-operator
a 0.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
Reinstala el
cert-manager
del cliente. Restablecer los recursos personalizados si los tienesCopia el certificado
metrics-ca
cert-manager.io/v1 y los recursos de la entidad emisora demetrics-pki.cluster.local
dekube-system
al espacio de nombres del recurso del clúster de tu cert-manager instalado. El espacio de nombres cert-manager instalado escert-manager
si se usa la instalación cert-manager predeterminada ascendente, pero eso depende de la instalación.relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f3=$(mktemp) f4=$(mktemp) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc
Docker, containerd y runc en las imágenes del SO de Ubuntu enviadas con clústeres de Anthos alojados en VMware se fijan a versiones especiales mediante PPA de Ubuntu. Esto garantiza que los clústeres de Anthos en VMware califiquen los cambios en el entorno de ejecución del contenedor antes de cada actualización.
Sin embargo, las versiones especiales no son conocidas para la Herramienta de seguimiento de CVE de Ubuntu, que se usa como feed de vulnerabilidad en varias herramientas de análisis de CVE. Por lo tanto, verás falsos positivos en los resultados del análisis de vulnerabilidades de Docker, containerd y runc.
Por ejemplo, es posible que veas los siguientes falsos positivos en los resultados del análisis de CVE. Estas CVE ya se corrigen en las últimas versiones de parche de los clústeres de Anthos en VMware.
Consulta las notas de la versión para conocer las correcciones de CVE.
La canonicalización está al tanto de este problema, y la corrección se rastrea en https://github.com/Canonical/sec-cvescan/issues/73.
/etc/cron.daily/aide
Problema de aumento de memoria y CPU
A partir de los clústeres de Anthos alojados en VMware versión 1.7.2, las imágenes del SO Ubuntu se endurecen con la comparativa del servidor L1 de CIS.
Como resultado, se instaló la secuencia de comandos cron /etc/cron.daily/aide
para que se programe una verificación aide
a fin de garantizar que se siga la regla de CIS L1 “1.4.2 Asegúrate de que se verifique con regularidad la integridad del sistema de archivos”.
El trabajo cron se ejecuta todos los días a las 6:25 a.m. UTC. Según la cantidad de archivos del sistema de archivos, es posible que experimentes aumentos repentinos del uso de memoria y CPU durante ese período debido a este proceso aide
.
Si los aumentos afectan tu carga de trabajo, puedes inhabilitar el trabajo cron diario:
`sudo chmod -x /etc/cron.daily/aide`.
Cisco ACI no funciona con el retorno directo del servidor (DSR)
Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP del plano de datos. Una posible solución es inhabilitar el aprendizaje de IP agregando la dirección IP de Seesaw como una IP virtual de L4-L7 en el controlador de infraestructura de política de aplicación (APIC) de Cisco.
Para configurar la opción de IP virtual de L4-L7, ve a Usuario > Perfiles de aplicaciones > EPG de aplicación o EPG de uSeg. Si no se inhabilita el aprendizaje de IP, el extremo de IP oscilará entre diferentes ubicaciones en la estructura de la API de Cisco.
Un token del portador de una cuenta de servicio que es demasiado largo puede romper los registros del balanceador de cargas de Seesaw.
Si el token del portador de la cuenta de servicio de supervisión de registros es superior a 512 KB, puede romper los registros del balanceador de cargas de Seesaw. Para solucionar este problema, actualiza a la versión 1.9 o a una posterior.
Problemas de conectividad entre Pods debido a daemons anetd
en un interbloqueo de software
Los clústeres con enableDataplaneV2
configurado como true
pueden experimentar problemas de conectividad entre Pods debido a daemons anetd
(que se ejecutan como un Daemonset) que ingresan a un interbloqueo del software. En este estado, los daemons anetd
verán que los nodos inactivos (que antes se borraron) son pares y no detectarán nodos recientemente agregados como pares nuevos.
Si experimentaste este problema, completa los siguientes pasos para reiniciar los daemons anetd
a fin de actualizar los nodos de intercambio de tráfico, y se debe restablecer la conectividad.
Busca todos los daemons
anetd
en el clúster:kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
Verifica si los daemons
anetd
ven pares inactivos:kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
Reemplaza ANETD_XYZ por el nombre de un Pod
anetd
.Reinicia todos los Pods afectados:
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ
Falla de los certificados de verificación gkectl diagnose
Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, recibirá las siguientes fallas cuando se ejecute gkectl diagnose
. Es seguro ignorarlas.
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out