Versão 1.7. 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 não é a versão mais recente.

Versões disponíveis

Problemas conhecidos

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

Falha no upgrade do cluster de usuário devido a "falha no registro no GCP"

Categoria

Fazer upgrade

Versões identificadas

1.7.0+, 1.8.0+

Sintomas

Ao fazer upgrade dos clusters de usuário para as versões 1.7, o comando gkectl upgrade cluster falha com mensagens de erro semelhantes às seguintes:

$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:

failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00  --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...

Os erros indicam que o upgrade do cluster de usuário foi na maior parte concluído, exceto pelo Connect Agent, que não recebeu upgrade. No entanto, a funcionalidade do GKE Connect não será afetada.

Causa

A versão 20210129-01-00 do Connect Agent usada nas versões 1.7 não é compatível.

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

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.

## `kubectl describe CSINode` and `gkectl diagnose snapshot`

`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.

## OIDC and the CA certificate

The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.

Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).

To work around this issue, run the following script:

<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>

IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"
</pre></section>

Replace the following:

* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:

* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
  kubeconfig file.

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

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

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

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

## Nodes fail to complete their upgrade process

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

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

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

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

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 [CLUSTER_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 [CLUSTER_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 [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

Etapa 3: reiniciar o encaminhador de registro

kubectl --kubeconfig [CLUSTER_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

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

Consiga o endereço IP e as chaves SSH do nó mestre 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')

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

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 .

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

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

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.

É 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 [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

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.

Prevemos uma correção em uma versão futura. Enquanto isso, você pode resolver esse problema com uma das duas alternativas a seguir:

Remova periodicamente os arquivos de registro em /run/aide/cron.daily.old* (recomendado).
Siga as etapas mencionadas no link externo acima. Observação: essa solução alternativa pode afetar o estado de conformidade do nó.

Como usar clusters do Anthos no VMware com o Anthos Service Mesh versão 1.7 ou posterior

Se você usa clusters do Anthos no VMware com o Anthos Service Mesh versão 1.7 ou posterior e quer fazer upgrade para clusters do Anthos no VMware versão 1.6.0-1.6.3 ou clusters do Anthos no VMware versão 1.7.0-1.7.2, remova os rótulos bundle.gke.io/component-name e bundle.gke.io/component-version das seguintes definições de recursos personalizados (CRDs, na sigla em inglês):

destinationrules.networking.istio.io
envoyfilters.networking.istio.io
serviceentries.networking.istio.io
virtualservices.networking.istio.io

Execute este comando para atualizar o CRD destinationrules.networking.istio.io no cluster de usuário:
```
kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
```
Remova os rótulos bundle.gke.io/component-version e bundle.gke.io/component-name do CRD.

Como alternativa, você pode aguardar a versão 1.6.4 e 1.7.3 e fazer upgrade diretamente para 1.6.4 ou 1.7.3.

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

Verifique se a VM temporária e a estação de trabalho do administrador estão em um estado de desligamento.
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".
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
```
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
```
Encerre a VM temporária.
Ligue a estação de trabalho de administrador. Agora você já pode usar o SSH como de costume.
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, no caso de versões anteriores à 7.0U2, for reiniciado, após o upgrade ou de outra forma, o nome da rede nas informações da VM do vCenter estará incorreto e resultará no estado Unavailable da máquina. 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 solução 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.

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.

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.

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

Problemas conhecidos

Falha no upgrade do cluster de usuário devido a "falha no registro no GCP"

Categoria

Versões identificadas

Sintomas

Causa

Alternativa

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

Categoria

Versões identificadas

Sintomas

Causa

Alternativa

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

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

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

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

Etapa 3: reiniciar o encaminhador de registro

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

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

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

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

Como usar clusters do Anthos no VMware com o Anthos Service Mesh versão 1.7 ou posterior

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

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

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

Estação de trabalho do administrador

VM de plano de controle do cluster do administrador

VMs de complemento de cluster de administrador

VMs do plano de controle do cluster do usuário

VMs de worker do cluster de usuário

VMs do Seesaw

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

Conexão SSH fechada pelo host remoto

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

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

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

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