Problemas conhecidos

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

/var/log/audit/ como preencher o espaço em disco

Categoria

SO

Versões identificadas

1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+

Sintomas

O /var/log/audit/ está repleto de registros de auditoria. Verifique o uso do disco executando sudo du -h -d 1 /var/log/audit.

Causa

Desde o Anthos v1.8, a imagem do Ubuntu é reforçada com o Comparativo de mercado CIS de nível 2. E uma das regras de conformidade, 4.1.2.2 Ensure audit logs are not automatically deleted, garante que a configuração auditada max_log_file_action = keep_logs. Isso resulta em todas as regras de auditoria mantidas no disco.

Alternativa

Estação de trabalho do administrador

Na estação de trabalho do administrador, é possível alterar manualmente as configurações auditadas para alternar os registros automaticamente e reiniciar o serviço auditado:

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

Com a configuração acima, os registros auditados poderiam alternar automaticamente os registros depois de gerar mais de 250 arquivos (cada um com um tamanho de 8 milhões).

Nós do cluster

Nos nós do cluster, aplique o seguinte DaemonSet ao cluster para evitar possíveis problemas:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

Essa mudança na configuração auditada violaria a regra 4.1.2.2 Ensure audit logs are not automatically deleted do CIS de nível 2.

Falha no upgrade/atualização do cluster do usuário devido a "falha ao registrar o cluster de usuário"

Categoria

Fazer upgrade, atualizar

Versões identificadas

1.7.0+, 1.8.0+

Sintomas

Execute gkectl diagnose cluster quando um comando gkectl anterior expirar nos casos a seguir.

1. O upgrade dos clusters de usuário com o GKE Connect foi ativado para as versões 1.8.
2. Executar gkectl update cluster em clusters de usuário 1.8 com a conexão do GKE ativada.
3. Executar gkectl update cluster para ativar o GKE Connect em clusters de usuário 1.8.

$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
    Unhealthy Resources:
      OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...

Observe que a funcionalidade do GKE Connect não será afetada. Em outras palavras, se o GKE Connect estava funcionando antes do comando, deve permanecer funcional.

Causa

A versão Connect Agent20210514-00-00 usada nas versões 1.8 não recebe mais suporte.

Alternativa

Entre em contato com o Suporte do Google para resolver o problema.

systemd-timesyncd não está em execução após a reinicialização no nó do Ubuntu

Categoria

SO

Versões identificadas

1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+

Sintomas

systemctl status systemd-timesyncd vai mostrar que o serviço está desativado:

● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)

Isso pode causar problemas de tempo fora de sincronia.

Causa

O chrony foi instalado incorretamente na imagem do SO do Ubuntu, e há um conflito entre chrony e systemd-timesyncd, em que systemd-timesyncd ficava inativo e chrony ficava ativo toda vez que a VM do Ubuntu foi reinicializada. No entanto, systemd-timesyncd precisa ser o cliente ntp padrão da VM.

Alternativa

Opção 1: execute manualmente o restart systemd-timesyncd sempre que a VM for reinicializada.

Opção 2: implantar o Daemonset a seguir para que systemd-timesyncd seja sempre reiniciado se estiver inativo.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ensure-systemd-timesyncd
spec:
  selector:
    matchLabels:
      name: ensure-systemd-timesyncd
  template:
    metadata:
      labels:
        name: ensure-systemd-timesyncd
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: ensure-systemd-timesyncd
        # Use your preferred image.
        image: ubuntu
        command:
        - /bin/bash
        - -c
        - |
          while true; do
            echo $(date -u)
            echo "Checking systemd-timesyncd status..."
            chroot /host systemctl status systemd-timesyncd
            if (( $? != 0 )) ; then
              echo "Restarting systemd-timesyncd..."
              chroot /host systemctl start systemd-timesyncd
            else
              echo "systemd-timesyncd is running."
            fi;
            sleep 60
          done
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: "10Mi"
            cpu: "10m"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
````

## ClientConfig custom resource

`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.

## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions

<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>

## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}

Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).

## Nodes fail to complete their upgrade process

If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.

To see all `PodDisruptionBudget` objects that do not allow any disruptions:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}' ```

Falha na instalação do cluster de usuário devido a um problema de eleição do líder cert-manager/ca-injector no Anthos 1.8.2 e 1.8.3

Pode haver uma falha na instalação devido a cert-manager-cainjector no loop de falhas, quando o apiserver/etcd está lento. O comando a seguir,

  kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector

pode produzir algo como os seguintes registros:

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"

Execute os comandos a seguir para atenuar o problema.

Primeiro reduza verticalmente o monitoring-operator para não reverter as alterações na implantação cert-manager-cainjector.

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

Depois, faça o patch da implantação cert-manager-cainjector para desativar a eleição de líder, o que é seguro porque temos apenas uma réplica em execução. Ela não é necessária para uma única réplica.

# Ensure that we run only 1 cainjector replica, even during rolling updates.
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch '
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
'
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[
    {
        "op": "add",
        "path": "/spec/template/spec/containers/0/args/-",
        "value": "--leader-elect=false"
    }
]'

Mantenha as réplicas de monitoring-operator em 0 como uma mitigação até que a instalação seja concluída. Caso contrário, a alteração será revertida.

Depois que a instalação for concluída e o cluster estiver em execução, ative o monitoring-operator para as operações do segundo dia:

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

Após o upgrade para a versão 1.8.4 ou mais recentes (ou 1.9.1 e mais recentes, se você fizer upgrade para a versão 1.9), essas etapas não serão mais necessárias, porque o Anthos vai desativar a eleição de líder para o cainjector. Até lá, se você enfrentar esse problema durante cada upgrade, é necessário executar as mesmas etapas de mitigação novamente.

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.

Observação: se você iniciou o processo de upgrade e encontrou um erro com expiração do certificado, entre em contato com o Suporte do Google para receber assistência.

Observação: essa orientação é estritamente para a renovação dos certificados do cluster de administrador.

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

6. Faça backup dos certificados antigos:

   Esta é uma etapa opcional, mas recomendada.

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

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

8. Reinicie os pods estáticos em execução no 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
    

9. Renovar os certificados dos nós de trabalho do cluster de administrador

   Verificar a data de validade dos certificados dos nós

       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
      

   Se o certificado estiver prestes a expirar, renove-o com o reparo manual de nós.

10. É 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.

Observação: a prevenção e a mitigação recomendadas aqui violam a regra do comparativo de mercado CIS 5.4.1.1, "Garantir que a expiração da senha seja de 365 dias ou menos", no nó.

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 chage -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

Como reiniciar ou fazer upgrade do vCenter em versões anteriores à 7.0U2

Se o vCenter, para versões anteriores à 7.0U2, for reiniciado, após um upgrade ou de outra forma, o nome da rede nas informações da VM do vCenter estará incorreto e resultará na máquina em um estado Unavailable. Isso leva os nós a serem reparados automaticamente para criar outros.

Bug relacionado do govmomi: https://github.com/vmware/govmomi/issues/2552 (em inglês)

Esta alternativa é fornecida pelo suporte da 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.

Pânico gkectl create-config admin e gkectl create-config cluster

Nas versões 1.8.0-1.8.3, o comando gkectl create-config admin/cluster entra em conflito com a mensagem panic: invalid version: "latest".

Como solução alternativa, use gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION. Substitua DESIRED_CLUSTER_VERSION pela versão pretendida, como 1.8.2-gke.8.

Como criar/fazer upgrade do tempo limite do cluster de administrador

Este problema afeta a versão 1.8.0-1.8.3.

A criação do cluster de administrador ou o upgrade do cluster de administrador pode expirar com o seguinte erro:

Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory

Além disso, o registro em nodes/ADMIN_MASTER_NODE/files/var/log/startup.log no snapshot do cluster externo termina com esta mensagem:

[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

Esse erro ocorre quando a rede está lenta entre a VM do plano de controle de administrador e o Container Registry. Revise sua configuração de rede ou proxy para reduzir a latência e aumentar a largura de banda.

Conexão SSH fechada pelo host remoto

Para clusters do Anthos na versão 1.7.2 e mais recentes do VMware, as imagens do sistema operacional Ubuntu são reforçadas com o CIS Benchmark do servidor L1. Para atender à regra do CIS "5.2.16 Verificar se o intervalo de tempo limite de inatividade SSH está configurado", o /etc/ssh/sshd_config tem as seguintes configurações:

ClientAliveInterval 300
ClientAliveCountMax 0

O objetivo dessas configurações é encerrar a sessão de um cliente após cinco minutos de inatividade. No entanto, o valor ClientAliveCountMax 0 causa um comportamento inesperado. Quando você usa a sessão SSH na estação de trabalho de administrador ou em um nó de cluster, a conexão SSH pode ser desconectada mesmo que o cliente SSH não esteja inativo, como ao executar um comando demorado e seu comando pode ser encerrado com a seguinte mensagem:

Connection to [IP] closed by remote host.
Connection to [IP] closed.

Como alternativa, você pode:

• Use nohup para evitar que o comando seja encerrado na desconexão SSH:

  nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
  

• Atualize o sshd_config para usar um valor ClientAliveCountMax diferente de zero. A regra do CIS recomenda usar um valor inferior a 3.

  sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  

  Reconecte sua sessão SSH.

Conflito com cert-manager ao fazer upgrade para a versão 1.8.2 ou mais recente.

Se você tiver sua própria instalação cert-manager com clusters do Anthos no VMware, poderá ocorrer uma falha ao tentar fazer upgrade para as versões 1.8.2 ou posteriores. Isso é resultado de um conflito entre sua versão do cert-manager, que provavelmente está instalada no namespace cert-manager, e a versão monitoring-operator.

Se você tentar instalar outra cópia de cert-manager após o upgrade para clusters do Anthos no VMware na versão 1.8.2 ou mais recente, a instalação poderá falhar devido a um conflito com a cópia atual gerenciada por monitoring-operator.

O emissor do cluster metrics-ca, que os componentes do plano de controle e de observabilidade dependem para a criação e rotação de secrets do certificado, exige que um secret metrics-ca do certificado seja armazenado no namespace do recurso do cluster. Esse namespace é kube-system para a instalação do monitoring-operator e provavelmente será cert-manager para a instalação.

Se ocorrer uma falha na instalação, siga estas etapas para fazer upgrade para a versão 1.8.2 ou mais recente:

Observação: basta aplicar essa solução uma vez para cada cluster, e as alterações serão preservadas no upgrade do cluster.

Evitar conflitos durante o upgrade

1. Desinstale sua versão de cert-manager. Se você definiu seus próprios recursos, recomendamos fazer backup deles.

2. Faça upgrade.

3. Siga as instruções a seguir para restaurar seu próprio cert-manager.

Restaurar o próprio gerenciador de certificados em clusters de usuário

• Escalone a implantação monitoring-operator para 0.

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

• Escalone as implantações cert-manager gerenciadas por monitoring-operator para 0.

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

• Reinstale o cert-manager do cliente. Restaure os recursos personalizados se você tiver os recursos.

• Copie o certificado metrics-ca cert-manager.io/v1 e os recursos do emissor metrics-pki.cluster.local de kube-system para o namespace do recurso do cluster cert-manager instalado. O namespace do gerenciador de certificados instalado será cert-manager se você estiver usando a instalação do gerenciador de certificados padrão de upstream, mas isso dependerá da instalação.

  relevant_fields='
  {
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
  name: .metadata.name,
  namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
  }
  '
  f1=$(mktemp)
  f2=$(mktemp)
  kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
  kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f2
  kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
  kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
   

Restaurar o próprio gerenciador de certificados em clusters de administrador

De modo geral, não é necessário reinstalar o gerenciador de certificados nos clusters de administrador porque os clusters de administrador só executam cargas de trabalho do plano de controle dos clusters do Anthos no VMware. Nos raros casos em que você também precisa instalar seu próprio gerenciador de certificados em clusters de administrador, siga as instruções a seguir para evitar conflitos. Se você é cliente da Apigee e precisa apenas de um certificado da Apigee, não é necessário executar os comandos de cluster de administrador.

• Escalone a implantação monitoring-operator para 0.

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

• Escalone as implantações cert-manager gerenciadas por monitoring-operator para 0.

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

• Reinstale o cert-manager do cliente. Restaure os recursos personalizados se você tiver os recursos.

• Copie o certificado metrics-ca cert-manager.io/v1 e os recursos do emissor metrics-pki.cluster.local de kube-system para o namespace do recurso do cluster cert-manager instalado. O namespace do gerenciador de certificados instalado será cert-manager se você estiver usando a instalação do gerenciador de certificados padrão de upstream, mas isso dependerá da instalação.

  relevant_fields='
  {
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
  name: .metadata.name,
  namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
  }
  '
  f3=$(mktemp)
  f4=$(mktemp)
  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4
  kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
  kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
   

Falsos positivos na verificação de vulnerabilidades do Docker, containerd e runc

O docker, o containerd e o runc nas imagens do sistema operacional Ubuntu fornecidos com clusters do Anthos no VMware são fixados nas versões especiais usando o Ubuntu PPA. Isso garante que todas as alterações no ambiente de execução do contêiner sejam qualificadas por clusters do Anthos no VMware antes de cada lançamento.

No entanto, as versões especiais são desconhecidas para o Ubuntu CVE Tracker, que é usado como os feeds de vulnerabilidade por várias ferramentas de verificação da CVE. Portanto, você verá falsos positivos nos resultados do Docker, containerd e verificação de vulnerabilidades do runc.

Por exemplo, os falsos positivos a seguir podem ser vistos nos resultados da verificação da CVE. Essas CVEs já foram corrigidas nas versões mais recentes dos patches do Anthos no VMware.

• CVE-2019-16884
• CVE-2019-19921
• CVE-2020-15157
• CVE-2020-15257

Consulte as notas da versão para ver correções da CVE.

A Canonical está ciente desse problema, e a correção é rastreada em https://github.com/canonical/sec-cvescan/issues/73.

Problema de CPU e pico de memória /etc/cron.daily/aide

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 aide seja programada para garantir que a regra do CIS L1 Server "1.4.2 garanta que a integridade do sistema de arquivos seja verificada regularmente" seja seguida.

O cron job é executado diariamente às 6h 25m UTC. Dependendo do número de arquivos no sistema de arquivos, você talvez tenha picos de uso de CPU e memória em torno desse horário, causados por esse processo aide.

Se os picos estiverem afetando sua carga de trabalho, desative o cron job diário:

`sudo chmod -x /etc/cron.daily/aide`.

Cisco ACI não funciona com o retorno direto de servidor (DSR, na sigla em inglês)

O Seesaw é executado no modo DSR. Por padrão, ele não funciona na Cisco ACI devido ao aprendizado de IP de plano de dados. Uma possível solução alternativa é desativar o aprendizado de IP adicionando o endereço IP Seesaw como um IP virtual L4-L7 no controlador de infraestrutura de política de aplicativo (APIC) da Cisco.

Para configurar a opção de IP virtual L4-L7, acesse Locatário > Perfis de aplicativo > EPGs de aplicativo ou EPGs uSeg. Se o aprendizado de IP não for desativado, o endpoint de IP vai oscilar entre diferentes locais na estrutura da API Cisco.

Um token do portador da conta de serviço muito longo pode interromper os registros do balanceador de carga do Seesaw

Se o token do portador da conta de serviço do logging-monitoring for maior que 512 KB, ele poderá interromper os registros do balanceador de carga do Seesaw. Para corrigir esse problema, faça upgrade para a versão 1.9 ou posterior.

Problemas de conectividade entre pods devido a daemons anetd no impasse do software

Clusters com enableDataplaneV2 definido como true podem enfrentar problemas de conectividade entre pods devido a daemons anetd (em execução como um Daemonset) que entram em um impasse de software. Enquanto estiver nesse estado, os daemons anetd verão nós desatualizados (nós excluídos anteriormente) como pares e perderão os nós recém-adicionados como novos pares.

Se você tiver esse problema, conclua as etapas a seguir para reiniciar os daemons anetd para atualizar os nós de mesmo nível e a conectividade vai ser restaurada.

1. Encontre todos os daemons anetd no cluster:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
   

2. Verifique se os daemons anetd veem pares desatualizados:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
   

   Substitua ANETD_XYZ pelo nome de um pod anetd.

3. Reinicie todos os pods afetados:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ
   

Falha na verificação de certificados com gkectl diagnose

Se a estação de trabalho não tiver acesso aos nós de trabalho do cluster do usuário, ela apresentará as seguintes falhas ao executar gkectl diagnose. É seguro ignorá-las.

Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out