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
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.
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: /
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
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
eclient-key-data
no kubeconfig porclient-certificate-data
eclient-key-data
no arquivonew_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 valorClientAliveCountMax
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.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 pormonitoring-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 emissormetrics-pki.cluster.local
dekube-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 pormonitoring-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 emissormetrics-pki.cluster.local
dekube-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
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.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 pormonitoring-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 Certificadometrics-ca
cert-manager.io/v1 e os Recursos do emissormetrics-pki.cluster.local
decert-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
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 pormonitoring-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.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 Certificadometrics-ca
cert-manager.io/v1 e os Recursos do emissormetrics-pki.cluster.local
decert-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 } ' 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.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
de10m
para50m
, adicione a seguinte seçãoresourceAttrOverride
ao manifestostackdriver
: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
paraprobe_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