Versión 1.7. 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 es la versión más reciente.

Problemas conocidos

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).

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.

kubectl describe CSINode y gkectl diagnose snapshot

A veces, kubectl describe CSINode y gkectl diagnose snapshot fallan debido al problema de Kubernetes de OSS en la desreferencia de campos de puntero nulo.

OIDC y el certificado de CA

El proveedor de OIDC no usa la CA común de forma predeterminada. Debes proporcionar el certificado de CA de forma explícita.

La actualización del clúster de administrador de 1.5 a 1.6.0 interrumpe los clústeres de usuario 1.5 que usan un proveedor de OIDC y no tienen valor para authentication.oidc.capath en el archivo de configuración del clúster de usuario.

Para solucionar este problema, ejecuta la siguiente secuencia de comandos:

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

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}\"}]"

Reemplaza lo siguiente:

  • YOUR_OIDC_IDENTITY_PROVICER: Es la dirección de tu proveedor de OIDC:

  • YOUR_YOUR_USER_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo de configuración del clúster de usuario.

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 OSS Istio o Anthos Service Mesh instalado en tu clúster, según la configuración de PodDisruptionBudget para los componentes de Istio, es posible que los nodos del usuario no se actualicen a la versión del plano de control después de varios intentos. A fin de evitar este error, te recomendamos que aumentes la configuración del ajuste de escala automático horizontal de Pods minReplicas de 1 a 2 para los componentes del espacio de nombres istio-system antes de la actualización. Esto garantizará que siempre tengas una instancia del plano de control de ASM en ejecución.

Si tienes Anthos Service Mesh 1.5+ o OSS Istio 1.5+, ejecuta lo siguiente:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Si tienes OSS Istio 1.4.x o Anthos Service Mesh 1.4.x, ejecuta lo siguiente:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

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

  1. Antes de comenzar, asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador.

  2. 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')
    
  3. 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.

  4. 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 .
    
  5. 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
     

  6. 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
     
  7. 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 y client-key-data en la kubeconfig por client-certificate-data y client-key-data en el archivo new_admin.conf que creaste.

  8. 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 dos soluciones:

  1. Quita los archivos de registro de forma periódica en /run/aide/cron.daily.old* (recomendado).
  2. 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
  1. 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
  2. Quita las etiquetas bundle.gke.io/component-version y bundle.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.