En este documento, se describen los problemas conocidos de la versión 1.7 de los clústeres de Anthos alojados en VMware (GKE On-Prem).
La actualización del clúster de usuario falla debido a que “no se pudo registrar en GCP”.
Categoría
Actualizar
Versiones identificadas
1.7.0+, 1.8.0 o superior
Síntomas
Cuando actualizas los clústeres de usuario a las versiones 1.7, el comando gkectl upgrade cluster
falla con mensajes de error similares a
$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:
failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00 --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...
Los errores indican que la actualización del clúster de usuario se completó en gran medida, excepto que no se actualizó el agente de Connect. Sin embargo, la funcionalidad de GKE Connect no debería verse afectada.
Causa
La versión 20210129-01-00
del agente de Connect que se usa en las versiones 1.7 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.
## `kubectl describe CSINode` and `gkectl diagnose snapshot`
`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.
## OIDC and the CA certificate
The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.
Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).
To work around this issue, run the following script:
<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>
IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>
openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'
ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)
ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"
cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem
kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"
</pre></section>
Replace the following:
* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:
* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
kubeconfig file.
## 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}' ``
El reenvío de registros realiza una cantidad excesiva de solicitudes de OAuth 2.0
Con los clústeres de Anthos alojados en VMware, versión 1.7.1, es posible que tengas problemas para consumir memoria del servidor de reenvío si realizas solicitudes excesivas de OAuth 2.0. Esta es una solución alternativa, en la que puedes cambiar a una versión inferior de la versión de stackdriver-operator
, limpiar el disco y reiniciar el servidor de reenvío.
Paso 0: Descarga las imágenes a tu registro privado, si corresponde
Si usas un registro privado, sigue estos pasos para descargar esas imágenes en tu registro privado antes de continuar. Omite este paso si no usas un registro privado.
Reemplaza PRIVATE_REGISTRY_HOST por el nombre de host o la dirección IP de tu registro privado de Docker.
stackdriver-operator
docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \ PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440 docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440
fluent-bit
docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \ PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3 docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3
Prometheus
docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \ PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0 docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0
Paso 1: Cambia a una versión inferior del operador de Stackdriver
- Ejecuta el siguiente comando para cambiar a una versión anterior del operador de Stackdriver.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \ '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'
Paso 2: Limpia el búfer de discos para el reenvío de registros
- Implementa el DaemonSet en el clúster para limpiar el búfer.
apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log
- Verifica que se haya limpiado el búfer del disco.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
El resultado muestra la cantidad de nodos del clúster.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
El resultado muestra la cantidad de nodos del clúster.
- Borra el DaemonSet de limpieza.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup
Paso 3: Reinicia el reenvío de registros
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder
Los registros y las métricas no se envían al proyecto especificado por stackdriver.projectID
.
En los clústeres de Anthos alojados en VMware 1.7, los registros se envían al proyecto superior de la cuenta de servicio especificada en el campo stackdriver.serviceAccountKeyPath
del archivo de configuración del clúster. Se ignora el valor de stackdriver.projectID
. Se solucionará este problema en una próxima versión.
Como solución alternativa, visualiza los registros en el proyecto superior de tu cuenta de servicio de supervisión y registro.
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.
Obtén la dirección IP y las claves SSH del nodo principal de administrador:
kubectl --kubeconfig [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_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.
Anticipamos una corrección en una versión futura. Mientras tanto, puedes resolver este problema con cualquiera de las siguientes soluciones alternativas:
- Quita los archivos de registro de forma periódica en
/run/aide/cron.daily.old*
(recomendado). - Sigue los pasos mencionados en el vínculo externo anterior. (Nota: Esta solución alternativa podría afectar el estado de cumplimiento del nodo).
Usa los clústeres de Anthos alojados en VMware con Anthos Service Mesh versión 1.7 o posterior
Si usas clústeres de Anthos alojados en VMware con la versión 1.7 o posterior de Anthos Service Mesh y deseas actualizar a la versión 1.6.0-1.6.3 o 1.7.0-1.7.2, debes quitar las etiquetas bundle.gke.io/component-name
y bundle.gke.io/component-version
de las siguientes definiciones de recursos personalizados (CRD):
destinationrules.networking.istio.io
envoyfilters.networking.istio.io
serviceentries.networking.istio.io
virtualservices.networking.istio.io
Ejecuta este comando para actualizar la CRD
destinationrules.networking.istio.io
en tu clúster de usuario:kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
Quita las etiquetas
bundle.gke.io/component-version
ybundle.gke.io/component-name
de la CRD.
Otra opción es esperar la versión 1.6.4 y 1.7.3 y, luego, actualizar a 1.6.4 o 1.7.3 directamente.
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.
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.
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`.