Problemas conhecidos

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

/var/log/audit/ preenchendo espaço em disco

Categoria

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.

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: /

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.

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 objetos PodDisruptionBudget configurados que não podem permitir outras interrupções, o upgrade dos nós poderá falhar no upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você escalone verticalmente Deployment ou HorizontalPodAutoscaler para permitir que o nó seja drenado enquanto respeita a configuração PodDisruptionBudget.

Para ver todos os objetos PodDisruptionBudget que não permitem interrupções:

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 ao problema de eleição do líder do cert-manager/ca-injector no Anthos 1.9.0

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.9.1 ou mais recente, essas etapas não vão ser mais necessárias, já que o Anthos vai desativar a eleição de líder para o cainjector.

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

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

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 "${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

É 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

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

Nas versões mais antigas que a 7.0U2, se o vCenter for reiniciado após um upgrade ou por outro motivo, o nome da rede nas informações da VM do vCenter vai 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 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.

Conflito com o `cert-manager` ao fazer upgrade para a versão 1.9.0 ou 1.9.1

Se você tiver seu próprio cert-manager instalado com clusters do Anthos no VMware, poderá ocorrer uma falha ao tentar fazer upgrade para as versões 1.9.0 ou 1.9.1. 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 do cert-manager após fazer upgrade para os clusters do Anthos no VMware versão 1.9.0 ou 1.9.1, a instalação poderá falhar devido a um conflito com o atual gerenciado pelo 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 as versões 1.9.0 e 1.9.1:

Evitar conflitos durante o upgrade

Desinstale sua versão de cert-manager. Se você definiu seus próprios recursos, recomendamos fazer backup deles.
Faça upgrade.
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.

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

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

Na versão 1.9.2 ou mais recente, o monitoring-operator instalará o gerenciador de certificados no namespace cert-manager. Se por algum motivo você precisar instalar seu próprio gerenciador de certificados, siga as instruções a seguir para evitar conflitos:

Evitar conflitos durante o upgrade

Desinstale sua versão de cert-manager. Se você definiu seus próprios recursos, recomendamos fazer backup deles.
Faça upgrade.
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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

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

Pule esta etapa se você estiver usando a instalação padrão do gerenciador de certificados padrão ou se tiver certeza de que o gerenciador de certificados está instalado no namespace cert-manager. Caso contrário, copie o Certificado metrics-ca cert-manager.io/v1 e os Recursos do emissor metrics-pki.cluster.local de cert-manager para o namespace do recurso do cluster do gerenciador de certificados instalado.

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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n cert-manager 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

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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

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

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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n cert-manager 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.

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.

Pods de servidor Kotlin não íntegros ao usar o Seesaw ou o balanceador de carga modo manual

Se você estiver usando o Seesaw ou o balanceador de carga no modo manual, talvez perceba que os pods do servidor do konnectivity não estão íntegros. Isso acontece porque o Seesaw não é compatível com a reutilização de um endereço IP em um serviço. No modo manual, a criação de um serviço do balanceador de carga não provisiona o serviço automaticamente no balanceador de carga.

O encapsulamento SSH está ativado nos clusters da versão 1.9. Assim, mesmo que o servidor correspondente não esteja íntegro, você ainda poderá usar o túnel SSH para que a conectividade com o cluster e dentro dele não seja afetada. Portanto, você não precisa se preocupar com esses pods não íntegros.

Se você planeja fazer upgrade da versão 1.9.0 para a versão 1.9.x, é recomendável excluir as implantações de servidores não íntegros do servidor antes do upgrade. Execute este comando:

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

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

Os balanceadores de carga e as regras de firewall distribuídas de estado NSX-T interagem de maneira imprevisível

Ao implantar clusters do Anthos no VMware na versão 1.9 ou mais recente, quando a implantação tem o balanceador de carga em pacote Seesaw em um ambiente que usa regras de firewall distribuídas com estado NSX-T, stackdriver-operator pode falhar ao criar ConfigMap gke-metrics-agent-conf e fazer os pods gke-connect-agent entrar em loop de falha.

O problema subjacente é que as regras de firewall distribuídas com estado NSX-T encerram a conexão de um cliente com o servidor da API do cluster de usuário pelo balanceador de carga Seesaw porque o Seesaw usa fluxos de conexão assimétricos. Os problemas de integração com as regras de firewall distribuídas NSX-T afetam todas as versões dos clusters do Anthos no VMware que usam o Seesaw. Você pode encontrar problemas de conexão semelhantes nos seus aplicativos ao criar objetos grandes do Kubernetes com tamanhos maiores que 32 K. Siga estas instruções para desativar as regras de firewall distribuídas NSX-T ou para usar regras de firewall distribuídas sem estado para VMs do Seesaw.

Se os clusters usarem um balanceador de carga manual, siga estas instruções para configurar o balanceador de carga para redefinir as conexões do cliente quando detectar uma falha no nó de back-end. Sem essa configuração, os clientes do servidor da API Kubernetes poderão ficar minutos sem responder quando uma instância do servidor ficar inativa.

Falha ao registrar o cluster de administrador durante a criação

Se você criar um cluster de administrador para a versão 1.9.x ou 1.10.0 e se o cluster de administrador não for registrado com a especificação gkeConnect fornecida durante a criação, você vai receber o seguinte erro.

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

Você ainda vai poder esse cluster de administrador, mas verá o seguinte erro se tentar fazer upgrade do cluster de administrador para a versão 1.10.y.

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

Se esse erro ocorrer, siga estas etapas para corrigir o problema de registro do cluster. Depois de fazer essa correção, você pode fazer upgrade do cluster de administrador.

Forneça ao govc, a interface de linha de comando para o vSphere, algumas variáveis que declarem elementos do servidor e do ambiente do vSphere.

Observação: muitos desses valores podem ser encontrados no arquivo de configuração do cluster de administrador ou fazendo login no servidor do vCenter
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
Substitua:
- VCENTER_SERVER_ADDRESS é o endereço IP ou nome do host do servidor vCenter.
- VCENTER_SERVER_USERNAME é o nome de usuário de uma conta que tem o papel Administrador ou privilégios equivalentes no servidor do vCenter.
- VCENTER_SERVER_PASSWORD é a senha da conta do servidor vCenter.
- VSPHERE_DATASTORE é o nome do repositório de dados configurado no ambiente do vSphere.
- VSPHERE_DATACENTER é o nome do data center configurado no ambiente do vSphere.
- DATA_DISK_NAME é o nome do disco de dados.

Faça o download do arquivo DATA_DISK_NAME‑checkpoint.yaml.

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

Edite os campos do checkpoint.

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

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

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

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

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

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo de configuração do cluster de administrador.

Gere uma nova soma de verificação.
- Altere a última linha do arquivo de checkpoint para
```
checksum:$NEW_CHECKSUM
```
  Substitua NEW_CHECKSUM pela saída do comando a seguir:
```
sha256sum temp-checkpoint.yaml
```

Faça upload do novo arquivo de checkpoint.

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

Usar o Anthos Identity Service pode fazer com que o agente do Connect seja reiniciado de maneira imprevisível

Se você estiver usando o recurso Anthos Identity Service para gerenciar o ClientConfig do Anthos Identity Service, o agente do Connect poderá ser reiniciado inesperadamente.

Se você tiver esse problema com um cluster existente, siga um destes procedimentos:

Desative o Anthos Identity Service (AIS). Se você desativar o AIS, isso não vai remover o binário do AIS implantado nem o ClientConfig do AIS. Para desativar o AIS, execute este comando:
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
Substitua PROJECT_NAME pelo nome do projeto host da frota do cluster.
Atualize o cluster para a versão 1.9.3, 1.10.1 ou posterior e faça upgrade da versão do agente do Connect.

Tráfego de rede alto para monitoring.googleapis.com

Talvez você veja um tráfego de rede alto para monitoring.gooleapis.com, mesmo em um novo cluster sem cargas de trabalho de usuário.

Esse problema afeta as versões 1.10.0-1.10.1 e 1.9.0-1.9.4. Esse problema foi corrigido nas versões 1.10.2 e 1.9.5.

Para corrigir esse problema, faça upgrade para a versão 1.10.2/1.9.5 ou posterior.

Para atenuar esse problema em uma versão anterior, siga estas etapas:

Reduza o escalonamento vertical de stackdriver-operator:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0
```
Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

Abra o ConfigMap gke-metrics-agent-conf para edição:

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

Aumente o intervalo da sondagem de 0,1 segundo para 13 segundos:

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

Fechar a sessão de edição.

Altere a versão do DaemonSet gke-metrics-agent para 1.1.0-anthos.8:

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

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

Métricas ausentes em alguns nós

Talvez você se depare com as seguintes métricas ausentes em alguns nós, mas não em todos:

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

Para corrigir esse problema:

[versão 1.9.5+]: aumente a CPU do gke-metrics-agent seguindo as etapas de 1 a 4
[versão 1.9.0-1.9.4]: siga as etapas 1 a 9

Abra o recurso stackdriver para edição:

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

Para aumentar a solicitação de CPU de gke-metrics-agent de 10m para 50m, adicione a seguinte seção resourceAttrOverride ao manifesto stackdriver:

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

O recurso editado ficará semelhante ao seguinte:

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

Salve as alterações e feche o editor de texto.
Para verificar se as mudanças entraram em vigor, execute o seguinte comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
O comando encontrará cpu: 50m se as edições tiverem entrado em vigor.

Para evitar que as mudanças a seguir sejam revertidas, reduza a escala vertical de stackdriver-operator:

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

Abra gke-metrics-agent-conf para edição:

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

Edite a configuração para alterar todas as instâncias de probe_interval: 0.1s para probe_interval: 13s:

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

Salve as alterações e feche o editor de texto.

Altere a versão do DaemonSet gke-metrics-agent para 1.1.0-anthos.8:

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

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

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

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

Problemas conhecidos

/var/log/audit/ preenchendo espaço em disco

Categoria

Versões identificadas

Sintomas

Causa

Alternativa

Estação de trabalho do administrador

Nós do cluster

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

Categoria

Versões identificadas

Sintomas

Causa

Alternativa

Recurso personalizado ClientConfig

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

Interrupção de cargas de trabalho com PodDisruptionBudgets

Falha no processo de upgrade dos nós

Falha na instalação do cluster de usuário devido ao problema de eleição do líder do cert-manager/ca-injector no Anthos 1.9.0

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

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

Conexão SSH fechada pelo host remoto

Conflito com o cert-manager ao fazer upgrade para a versão 1.9.0 ou 1.9.1

Evitar conflitos durante o upgrade

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

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

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

Evitar conflitos durante o upgrade

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

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

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

Pods de servidor Kotlin não íntegros ao usar o Seesaw ou o balanceador de carga modo manual

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

Os balanceadores de carga e as regras de firewall distribuídas de estado NSX-T interagem de maneira imprevisível

Falha ao registrar o cluster de administrador durante a criação

Usar o Anthos Identity Service pode fazer com que o agente do Connect seja reiniciado de maneira imprevisível

Tráfego de rede alto para monitoring.googleapis.com

Métricas ausentes em alguns nós

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

Falha na verificação de certificados com gkectl diagnose

Conflito com o `cert-manager` ao fazer upgrade para a versão 1.9.0 ou 1.9.1

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

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