Versión 1.9. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Versiones disponibles

Problemas conocidos

En este documento, se describen los problemas conocidos de la versión 1.9 de los clústeres de Anthos alojados en VMware (GKE On-Prem).

Recurso personalizado de ClientConfig

gkectl update revierte los cambios manuales que realizaste al recurso personalizado ClientConfig. Te recomendamos crear una copia de seguridad del recurso ClientConfig después de cada cambio manual.

La validación check-config de gkectl falla: no se pueden encontrar las particiones de BIG-IP de F5

Síntomas: La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
Causas posibles: Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
Solución: Vuelve a ejecutar gkectl check-config.

Interrupción de las cargas de trabajo con PodDisruptionBudgets

La actualización de los clústeres puede causar interrupciones o tiempo de inactividad para las cargas de trabajo que usan PodDisruptionBudgets (PDB).

El proceso de actualización de los nodos falla

Si tienes objetos PodDisruptionBudget configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment o la HorizontalPodAutoscaler a fin de permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten ninguna interrupción, haz lo siguiente:

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 a un problema de elección de líder de cert-manager/ca-injector

Es posible que veas un error de instalación debido a cert-manager-cainjector en bloqueo, cuando apiserver/etcd es lento:

# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

Ejecuta los siguientes comandos para mitigar el problema.

Primero reduce verticalmente la escala de monitoring-operator para que no revierta los cambios en la implementación de cert-manager.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

En segundo lugar, edita la implementación de cert-manager-cainjector para inhabilitar la elección de líder, ya que solo tenemos una réplica en ejecución. No es necesario si hay una sola réplica.

# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit -n kube-system deployment cert-manager-cainjector

El fragmento yaml relevante para la implementación de cert-manager-cainjector debe verse de la siguiente manera: ... apiVersion: apps/v1 kind: Deployment metadata: name: cert-manager-cainjector namespace: kube-system ... spec: ... template: ... spec: ... containers: - name: cert-manager image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0" args: ... - --leader-elect=false ...

Mantén las réplicas 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 USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=1

Los cambios se revertirán después de cada actualización. Realiza los mismos pasos una vez más para mitigar el problema hasta que se solucione en una versión futura.

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.

Crea una copia de seguridad de los certificados anteriores:

Este es un paso opcional, pero recomendado.

# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"

# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout

# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .

Renueva los certificados con kubeadm:

 # ssh into admin master
 ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
 # on admin master
 sudo kubeadm alpha certs renew all

Reinicia el nodo principal del administrador:

  # on admin master
  cd /etc/kubernetes
  sudo mkdir tempdir
  sudo mv manifests/*.yaml tempdir/
  sleep 5
  echo "remove pods"
  # ensure kubelet detect those change remove those pods
  # wait until the result of this command is empty
  sudo docker ps | grep kube-apiserver

  # ensure kubelet start those pods again
  echo "start pods again"
  sudo mv tempdir/*.yaml manifests/
  sleep 30
  # ensure kubelet start those pods again
  # should show some results
  sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd

  # clean up
  sudo rm -rf tempdir

  logout

Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes 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 y client-key-data en la kubeconfig por client-certificate-data y client-key-data en el archivo new_admin.conf que creaste.

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

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 valor ClientAliveCountMax 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 una versión superior a 1.8.2

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:

Desinstala tu versión de cert-manager.
Realiza la actualización.

Si deseas restablecer tu propia instalación de cert-manager, sigue estos pasos:

Escala la implementación de monitoring-operator a 0. Para el clúster de administrador, ejecuta este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

Para un clúster de usuario, ejecuta este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

Escala las implementaciones de cert-manager administradas por monitoring-operator a 0.

Para el clúster de administrador, ejecuta este comando:

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

Para un clúster de usuario, ejecuta este comando:

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

Vuelve a instalar tu cert-manager.
Copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de kube-system al espacio de nombres del recurso del clúster de tu cert-manager instalado. Este espacio de nombres podría ser cert-manager si se usa la versión ascendente del administrador de certificados, como v1.0.3, pero eso depende de tu instalación.

Administra un `cert-manager` de terceros cuando actualices a la versión 1.9.2 o superior

Si experimentaste un error de instalación, sigue estos pasos para actualizar correctamente a la versión 1.9.2 o posterior:

Desinstala tu versión de cert-manager.
Realiza la actualización.

Si deseas restablecer tu propia instalación de cert-manager, sigue estos pasos:

Escala la implementación de monitoring-operator a 0. Para el clúster de administrador, ejecuta este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

Para un clúster de usuario, ejecuta este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

Escala las implementaciones de cert-manager administradas por monitoring-operator a 0.

Para el clúster de administrador, ejecuta este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

Para un clúster de usuario, ejecuta este comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

Vuelve a instalar tu cert-manager.
Copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso del clúster de tu administrador de certificados instalado. Este espacio de nombres podría ser cert-manager si se usa la versión ascendente del administrador de certificados, como v1.5.4, pero eso depende de tu instalación.

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.

Pods de mal estado de los servidores cuando se usa el balanceador de cargas de Seesaw o de modo manual

Si usas Seesaw o el balanceador de cargas en modo manual, es posible que notes que los Pods del servidor de konnectivity están en mal estado. Esto sucede porque Seesaw no admite la reutilización de una dirección IP en un servicio. Para el modo manual, la creación de un servicio de balanceador de cargas no aprovisiona de forma automática el servicio en el balanceador de cargas.

Los túneles SSH están habilitados en los clústeres de la versión 1.9. Por lo tanto, incluso si el servidor de konnectivity no está en buen estado, puedes usar el túnel SSH para que la conectividad hacia el clúster y dentro de él no se vea afectada. Por lo tanto, no debes preocuparte por estos Pods en mal estado.

Si planeas actualizar de la versión 1.9.0 a 1.9.x, te recomendamos que borres las implementaciones del servidor de konnectivity en mal estado antes de realizar la actualización. Ejecute este comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

`/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:00 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`.

Los balanceadores de cargas y las reglas de firewall distribuido con estado de NSX-T interactúan de forma impredecible

Cuando implementas clústeres de Anthos en la versión 1.9 o posterior de VMware, cuando la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall con estado de NSX-T, stackdriver-operator podría no crear un ConfigMap gke-metrics-agent-conf y provocar que los Pods gke-connect-agent entren en un bucle de fallas.

El problema subyacente es que las reglas de firewall distribuido con estado de NSX-T finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw porque Seesaw usa flujos de conexión asimétricos. Los problemas de integración con las reglas de firewall distribuido de NSX-T afectan a todas las versiones de los clústeres de Anthos alojados en VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando creen objetos grandes de Kubernetes con tamaños de más de 32,000. Sigue estas instrucciones a fin de inhabilitar las reglas de firewall distribuido de NSX-T o usar reglas de firewall distribuido sin estado en las VM de Seesaw.

Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas a fin de restablecer las conexiones de clientes cuando detecte una falla del nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes podrían dejar de responder durante varios minutos cuando falla una instancia del servidor.

No se pudo registrar el clúster de administrador durante la creación

Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si el clúster de administrador no se registra con la especificación gkeConnect proporcionada durante su creación, recibirás el siguiente error.

  Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

Aún podrás usar este clúster de administrador, pero recibirás el siguiente error si luego intentas actualizarlo a la versión 1.10.y.

  failed to migrate to first admin trust chain: failed to parse current version "":
  invalid version: "" failed to migrate to first admin trust chain: failed to parse
  current version "": invalid version: ""

Si se produce este error, sigue estos pasos para solucionar el problema de registro del clúster. Después de realizar esta corrección, puedes actualizar tu clúster de administrador.

Proporciona govc, la interfaz de línea de comandos a vSphere, algunas variables que declaran elementos de vCenter Server y el entorno de vSphere.

Nota: Puedes encontrar muchos de estos valores en el archivo de configuración del clúster de administrador o mediante el acceso al servidor de vCenter
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
Reemplaza lo siguiente:
- VCENTER_SERVER_ADDRESS es la dirección IP o el nombre de host de vCenter Server.
- VCENTER_SERVER_USERNAME es el nombre de usuario de una cuenta que contiene el rol Administrator o privilegios equivalentes en vCenter Server.
- VCENTER_SERVER_PASSWORD es la contraseña de la cuenta de vCenter Server.
- VSPHERE_DATASTORE es el nombre del almacén de datos que configuraste en el entorno de vSphere.
- VSPHERE_DATACENTER es el nombre del centro de datos que configuraste en el entorno de vSphere.
- DATA_DISK_NAME es el nombre del disco de datos.

Descarga el archivo DATA_DISK_NAME‑checkpoint.yaml.

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

Edita los campos de punto de control.

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster -n kube-system $ADMIN_CLUSTER_NAME -o=jsonpath='{.spec.gkeOnPremVersion}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

Genera una suma de verificación nueva.
- Cambia la última línea del archivo de punto de control a
```
checksum:$NEW_CHECKSUM
```
  Reemplaza NEW_CHECKSUM por el resultado del siguiente comando:
```
sha256sum temp-checkpoint.yaml
```

Sube el archivo de punto de control nuevo.

govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml

El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible.

Si usas la función Anthos Identity Service para administrar Clientconfig de Anthos Identity Service, es posible que el agente de Connect se reinicie de forma inesperada.

Si tienes este problema con un clúster existente, puedes realizar una de las siguientes acciones:

Inhabilita Anthos Identity Service (AIS). Si inhabilitas AIS, no se quitará el objeto binario de AIS implementado ni Clientconfig de AIS. Para inhabilitar AIS, ejecuta este comando:
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
Reemplaza PROJECT_NAME por el nombre del proyecto host de la flota del clúster.
Actualiza el clúster a la versión 1.9.3, 1.10.1 o posterior, para actualizar la versión del agente de Connect.

Alto tráfico de red a monitoring.googleapis.com

Es posible que veas un tráfico de red alto a monitoring.googleapis.com, incluso en un clúster nuevo que no tiene cargas de trabajo de usuarios.

Este problema afecta a las versiones 1.10.0-1.10.1 y 1.9.0-1.9.4. Este problema se solucionó en las versiones 1.10.2 y 1.9.5.

Para solucionar este problema, actualiza a la versión 1.10.2/1.9.5 o a una posterior.

Para mitigar este problema en una versión anterior, haz lo siguiente:

Reduce verticalmente la escala de stackdriver-operator:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

Abre el ConfigMap gke-metrics-agent-conf para editar:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit configmap gke-metrics-agent-conf

Aumenta el intervalo del sondeo de 0.1 segundos a 13 segundos:

processors:
  disk_buffer/metrics:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-metrics
    probe_interval: 13s
    retention_size_mib: 6144
 disk_buffer/self:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-self
    probe_interval: 13s
    retention_size_mib: 200
  disk_buffer/uptime:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-uptime
    probe_interval: 13s
    retention_size_mib: 200

Cierra la sesión de edición.

Cambia la versión de DaemonSet de gke-metrics-agent a 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

Faltan métricas en algunos nodos

Es posible que te falten las siguientes métricas en algunos nodos, pero no en todos:

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

Para solucionar este problema, haz lo siguiente:

[versión 1.9.5+]: Para aumentar la CPU de gke-metrics-agent, sigue los pasos 1 a 4
[versión 1.9.0-1.9.4]: Sigue los pasos 1 a 9.

Abre tu recurso stackdriver para editarlo:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

Para aumentar el límite de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver:

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

El recurso editado debe ser similar al siguiente:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Guarda los cambios y cierra el editor de texto.
Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
El comando encuentra cpu: 50m si tus ediciones se aplicaron.

Para evitar que los cambios se reviertan, reduce verticalmente la escala de stackdriver-operator:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0

Abre gke-metrics-agent-conf para editarla:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

Edita la configuración para cambiar todas las instancias de probe_interval: 0.1s a probe_interval: 13s:

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Guarda los cambios y cierra el editor de texto.

Cambia la versión de DaemonSet de gke-metrics-agent a 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

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.

Problemas conocidos

Recurso personalizado de ClientConfig

La validación check-config de gkectl falla: no se pueden encontrar las particiones de BIG-IP de F5

Interrupción de las cargas de trabajo con PodDisruptionBudgets

El proceso de actualización de los nodos falla

No se pudo instalar el clúster de usuario debido a un problema de elección de líder de cert-manager/ca-injector

Puede que sea necesario renovar los certificados antes de que se actualice el clúster de administrador

Proceso de renovación del certificado del clúster de administrador

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Conexión SSH cerrada por host remoto

Conflicto con cert-manager cuando se actualiza a una versión superior a 1.8.2

Administra un cert-manager de terceros cuando actualices a la versión 1.9.2 o superior

Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc

Pods de mal estado de los servidores cuando se usa el balanceador de cargas de Seesaw o de modo manual

/etc/cron.daily/aide Problema de aumento de memoria y CPU

Los balanceadores de cargas y las reglas de firewall distribuido con estado de NSX-T interactúan de forma impredecible

No se pudo registrar el clúster de administrador durante la creación

El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible.

Alto tráfico de red a monitoring.googleapis.com

Faltan métricas en algunos nodos

Cisco ACI no funciona con el retorno directo del servidor (DSR)

Conflicto con `cert-manager` cuando se actualiza a una versión superior a 1.8.2

Administra un `cert-manager` de terceros cuando actualices a la versión 1.9.2 o superior

`/etc/cron.daily/aide` Problema de aumento de memoria y CPU