Version 1.8. Essa versão é compatível com a política de suporte da versão do Anthos, que oferece os patches e atualizações mais recentes para vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem). Consulte as notas da versão para saber mais detalhes. Esta é a versão mais recente.

Problemas conhecidos

Neste documento, descrevemos problemas conhecidos da versão 1.8 dos clusters do Anthos no VMware (GKE On-Prem).

Recurso personalizado ClientConfig

gkectl update reverte todas as alterações manuais feitas para o recurso personalizado ClientConfig. É altamente recomendável que você faça backup do recurso ClientConfig após cada alteração manual.

kubectl describe CSINode e gkectl diagnose snapshot

kubectl describe CSINode e gkectl diagnose snapshot às vezes falham devido ao problema de OSS Kubernetes ao desreferenciar campos de ponteiro nulo.

OIDC e certificado de CA

Por padrão, o provedor OIDC não usa a CA comum. É necessário fornecer explicitamente o certificado da CA.

O upgrade do cluster de administrador de 1.5 para 1.6.0 divide os clusters de usuário da versão 1.5 que usam um provedor OIDC e não têm valor para authentication.oidc.capath no arquivo de configuração do cluster de usuário.

Para contornar esse problema, execute o script a seguir:

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

Substitua:

  • YOUR_OIDC_IDENTITY_PROVICER: o endereço do seu provedor OIDC:

  • YOUR_YOUR_USER_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de usuário.

Falha na validação do gkectl check-config: não é possível encontrar partições F5 BIG-IP

Sintomas

A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.

Causas possíveis

Um problema com a API F5 BIG-IP pode causar falha na validação.

Resolução

Tente executar gkectl check-config novamente.

Interrupção de cargas de trabalho com PodDisruptionBudgets

O upgrade de clusters pode causar interrupção ou inatividade das cargas de trabalho que usam PodDisruptionBudgets (PDBs).

Falha no processo de upgrade dos nós

Se você tiver o Anthos Service Mesh ou o OSS Istio instalado no cluster, dependendo das configurações do PodDisruptionBudget para os componentes do Istio, talvez os nós do usuário não façam upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você aumente a configuração minReplicas de escalonamento horizontal e automático do pod para os componentes no namespace istio-system antes de fazer upgrade. Isso garantirá que você sempre tenha uma instância do plano de controle ASM em execução.

Se você tiver o Anthos Service Mesh 1.5+ ou o OSS Istio 1.5+:

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

Se você tiver o Anthos Service Mesh 1.4.x ou o OSS Istio 1.4.x:

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

O encaminhador de registro faz um número excessivo de solicitações OAuth 2.0

Com os clusters do Anthos no VMware versão 1.7.1, há chances de que você enfrente problemas com o encaminhador de registro que consome memória fazendo solicitações excessivas do OAuth 2.0. Aqui está uma solução alternativa, em que você faz downgrade da versão stackdriver-operator, limpa o disco e reinicia o encaminhador de registros.

Etapa 0: fazer o download das imagens para um registro particular, se apropriado

Se você usa um registro particular, siga estas etapas para fazer o download dessas imagens no seu registro particular antes de continuar. Pule esta etapa se você não usa um registro particular.

Substitua PRIVATE_REGISTRY_HOST pelo nome do host ou endereço IP do seu registro particular do 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

Etapa 1: fazer downgrade da versão stackdriver-operator

Execute o comando a seguir para fazer downgrade da versão do stackdriver-operator.

kubectl  --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"}]}}}}'

Etapa 2: limpar o buffer de disco do encaminhador de registros

  • Implante o DaemonSet no cluster para limpar o buffer.
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
  • Verifique se o buffer do disco está limpo.
kubectl --kubeconfig  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

A saída mostra o número de nós no cluster.

kubectl --kubeconfig  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

A saída mostra o número de nós no cluster.

  • Exclua o DaemonSet de limpeza.
kubectl --kubeconfig  -n kube-system delete ds fluent-bit-cleanup

Etapa 3: reiniciar o encaminhador de registro

kubectl --kubeconfig  -n kube-system rollout restart ds/stackdriver-log-forwarder

Registros e métricas não são enviados ao projeto especificado por stackdriver.projectID

Nos clusters do Anthos no VMware 1.7, os registros são enviados para o projeto pai da conta de serviço especificada no campo stackdriver.serviceAccountKeyPath do arquivo de configuração do cluster. O valor de stackdriver.projectID é ignorado. Esse problema será corrigido em uma versão futura.

Como solução alternativa, veja os registros no projeto pai da conta de serviço de monitoramento de registros.

A renovação dos certificados pode ser necessária antes de um upgrade do cluster de administrador

Antes de iniciar o processo de upgrade do cluster de administrador, verifique se os certificados do cluster de administrador são válidos atualmente e, se não forem, renove-os.

Processo de renovação do certificado do cluster de administrador

  1. Verifique se o OpenSSL está instalado na estação de trabalho do administrador antes de começar.

  2. Defina a variável KUBECONFIG:

    KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
    

    Substitua ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG pelo caminho absoluto para o arquivo kubeconfig do cluster de administrador.

  3. Consiga o endereço IP e as chaves SSH do nó mestre 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')
    
  4. Verifique se os certificados expiraram:

    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
    

    Se os certificados tiverem expirado, você precisará renová-los antes de fazer upgrade do cluster de administrador.

  5. Faça backup dos certificados antigos:

    Esta é uma etapa opcional, mas recomendada.

    # 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 .
    
  6. Renove os certificados com o kubeadm:

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

  7. Reinicie o nó mestre do 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
     
  8. Como o arquivo kubeconfig do cluster de administrador também expirará se os certificados de administrador expirarem, você precisará fazer backup desse arquivo antes que ele expire.

    • Faça backup do arquivo kubeconfig do cluster de administrador:

      ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
      "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"

    • Substitua client-certificate-data e client-key-data no kubeconfig por client-certificate-data e client-key-data no arquivo new_admin.conf que você criou.

  9. É preciso validar os certificados renovados e o certificado do kube-apiserver.

    • Verifique a validade dos certificados:

      ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
      "sudo kubeadm alpha certs check-expiration"

    • Verifique o certificado do 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

O script /etc/cron.daily/aide usa todo o espaço em /run, causando um loop de falhas nos pods

A partir dos clusters do Anthos no VMware 1.7.2, as imagens do Ubuntu OS têm maior proteção com o comparativo de mercado CIS L1 Server. . Como resultado, o script cron /etc/cron.daily/aide foi instalado para que uma verificação de ajuda seja programada para garantir que a regra "1.4.2 do servidor CIS L1 seja verificada regularmente".

O script usa /run/aide como um diretório temporário para salvar os registros cron. Ao longo do tempo, ele pode usar todo o espaço em /run. Consulte /etc/cron.daily/aide script usa todo o espaço em /run para ver uma solução alternativa.

Se você encontrar um ou mais pods travando em um nó, execute df -h /run no nó. Se a saída do comando mostrar 100% de uso do espaço, é provável que você esteja enfrentando esse problema.

Esse problema foi corrigido na versão 1.8.1. Para as versões 1.7.2 e 1.8.0, é possível resolver esse problema manualmente com uma das duas soluções alternativas a seguir:

  1. Remova periodicamente os arquivos de registro em /run/aide/cron.daily.old* (recomendado).
  2. Siga as etapas mencionadas em /etc/cron.daily/aide script usa todo o espaço em /run. Observação: essa solução alternativa pode afetar o estado de conformidade do nó.

Como fazer upgrade do balanceador de carga da Seesaw com a versão 1.8.0

Se você usar o gkectl upgrade loadbalancer para tentar atualizar alguns parâmetros do balanceador de carga da Seesaw na versão 1.8.0, isso não funcionará no modo DHCP ou IPAM. Se sua configuração incluir essa configuração, não faça upgrade para a versão 1.8.0, mas para a versão 1.8.1 ou posterior.

Não é possível fazer login na estação de trabalho de administrador devido a um problema de expiração da senha

Esse problema pode ocorrer se você estiver usando uma das seguintes versões de clusters do Anthos no 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

Você pode receber o seguinte erro ao tentar executar SSH nas VMs do Anthos, incluindo a estação de trabalho do administrador, os nós do cluster e os nós do Seesaw:

WARNING: Your password has expired.

Esse erro ocorre porque a senha de usuário do Ubuntu nas VMs expirou. Redefina manualmente o tempo de expiração da senha do usuário para um valor grande antes de fazer login nas VMs.

Prevenção de erros de expiração de senha

Se você estiver executando as versões afetadas listadas acima e a senha do usuário ainda não tiver expirado, estenda o prazo de validade antes de ver o erro SSH.

Execute o seguinte comando em cada VM do Anthos:

sudo change -M 99999 ubuntu

Mitigação do erro de expiração da senha

Se a senha já tiver expirado e você não conseguir fazer login nas VMs para estender o prazo de validade, execute as seguintes etapas para cada componente.

Estação de trabalho do administrador

Use uma VM temporária para realizar as etapas a seguir. É possível criar uma estação de trabalho de administrador usando a versão 1.7.1-gke.4 para usar como VM temporária.

  1. Verifique se a VM temporária e a estação de trabalho do administrador estão em um estado de desligamento.

  2. Anexe o disco de inicialização da estação de trabalho do administrador à VM temporária. O disco de inicialização é aquele com o rótulo "Disco rígido 1".

  3. Monte o disco de inicialização dentro da VM executando estes comandos. Substitua seu próprio identificador de disco de inicialização por dev/sdc1.

    sudo mkdir -p /mnt/boot-disk
    sudo mount /dev/sdc1 /mnt/boot-disk
    
  4. Defina a data de validade do usuário do Ubuntu com um valor alto, como 99999 dias.

    sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
    
  5. Encerre a VM temporária.

  6. Ligue a estação de trabalho de administrador. Agora você já pode usar o SSH como de costume.

  7. Como limpeza, exclua a VM temporária.

VM de plano de controle do cluster do administrador

Siga as instruções para recriar a VM do plano de controle do cluster de administrador.

VMs de complemento de cluster de administrador

Execute o comando a seguir na estação de trabalho do administrador para recriar a 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"}}]"
  

Depois de executar esse comando, aguarde até que as VMs de complemento do cluster de administrador concluam a recriação e estejam prontas antes de continuar com as próximas etapas.

VMs do plano de controle do cluster do usuário

Execute o seguinte comando na estação de trabalho de administrador para recriar as VMs:

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

Depois de executar esse comando, aguarde até que as VMs do plano de controle do cluster de usuário concluam a recriação e estejam prontas antes de continuar com as próximas etapas.

VMs de worker do cluster de usuário

Execute o comando a seguir na estação de trabalho de administrador para recriar as VMs.

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

VMs do Seesaw

Execute os comandos a seguir na estação de trabalho de administrador para recriar as VMs do Seesaw. Haverá um tempo de inatividade. Se a alta disponibilidade estiver ativada no balanceador de carga, o tempo máximo de inatividade será de dois 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