Rede, operação |
1.10, 1.11, 1.12, 1.13, 1.14 |
Componentes do gateway de rede do Anthos removidos ou pendentes devido à
classe de prioridade ausente
Os pods do gateway de rede em kube-system podem mostrar um status
Pending ou Evicted , conforme o exemplo de saída
condensada a seguir:
$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc 2/2 Running 0 5d2h
ang-node-mw8cq 0/2 Evicted 0 6m5s
ang-node-zsmq7 0/2 Pending 0 7h
Esses erros indicam eventos de remoção ou impossibilidade de programar pods
devido a recursos de nó. Como os pods do gateway de rede do Anthos não têm
PriorityClass, eles têm a mesma prioridade padrão que outras cargas de trabalho.
Quando os nós têm recursos restritos, os pods do gateway de rede podem ser
removidos. Esse comportamento é especialmente ruim para o DaemonSet ang-node ,
porque esses pods precisam ser programados em um nó específico e não podem ser
migrados.
Alternativa:
Faça upgrade para a versão 1.15 ou posterior.
Como correção de curto prazo, é possível atribuir manualmente uma
PriorityClass
aos componentes do gateway de rede do Anthos. O controlador de clusters do Anthos no VMware substitui essas alterações manuais durante um processo de reconciliação, por exemplo, durante um upgrade de cluster.
- Atribua a PriorityClass
system-cluster-critical às
implantações do controlador de
cluster ang-controller-manager e autoscaler .
- Atribua a PriorityClass
system-node-critical ao
DaemonSet do nó ang-daemon .
|
Upgrades e atualizações |
1.12, 1.13, 1.14, 1.15 |
falha no upgrade do cluster de administrador após o registro do cluster no gcloud
Depois de usar gcloud para registrar um cluster de administrador com a seção gkeConnect não vazia, talvez você encontre o seguinte erro ao tentar fazer upgrade do cluster:
failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated
É possível excluir o namespace gke-connect
kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
e retomar o upgrade do cluster de administrador.
|
Operação |
1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1 |
gkectl diagnose snapshot --log-since falha ao limitar a janela de tempo para comandos journalctl em execução nos nós do cluster
Isso não afeta a funcionalidade de tirar um snapshot do cluster, já que o snapshot ainda inclui todos os registros coletados por padrão ao executar journalctl nos nós do cluster. Portanto, nenhuma informação de depuração é perdida.
|
Instalação, upgrades e atualizações |
1.9+, 1.10+, 1.11+, 1.12+ |
gkectl prepare windows falha
gkectl prepare windows falha ao instalar o Docker nos clusters do Anthos no VMware versões anteriores à 1.13 porque o uso do MicrosoftDockerProvider foi suspenso.
Alternativa:
A ideia geral para resolver esse problema é fazer upgrade para clusters do Anthos no VMware 1.13 e usar o gkectl 1.13 para criar um modelo de VM do Windows e, em seguida, criar pools de nós do Windows. Há duas opções para acessar os clusters do Anthos no VMware 1.13 da
versão atual, conforme mostrado abaixo.
Observação: temos opções para resolver esse problema na sua versão atual sem precisar fazer upgrade para a versão 1.13, mas serão necessárias mais etapas manuais. Entre em contato com nossa equipe de suporte se quiser considerar essa opção.
Opção 1: upgrade azul/verde
É possível criar um novo cluster usando os clusters do Anthos no VMware versão 1.13+ com pools de nós do Windows, migrar suas cargas de trabalho para o novo cluster e, em seguida, desativar o cluster atual. É recomendável usar a versão secundária mais recente do Anthos.
Observação: isso exigirá recursos extras para provisionar o novo cluster, mas menos inatividade e interrupção para as cargas de trabalho.
Opção 2: excluir pools de nós do Windows e adicioná-los novamente ao fazer upgrade para clusters do Anthos no VMware 1.13
Observação: para essa opção, as cargas de trabalho do Windows não poderão ser executadas até que o cluster seja atualizado para a versão 1.13 e os pools de nós do Windows sejam adicionados novamente.
- Exclua os pools de nós do Windows removendo a configuração desses pools no arquivo user-cluster.yaml e, em seguida, execute o comando:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Faça upgrade dos clusters de administrador+usuário exclusivos do Linux para a versão 1.12 seguindo o guia do usuário para upgrade para a versão secundária de destino correspondente.
- (Siga esta etapa antes de fazer upgrade para a 1.13) Verifique se
enableWindowsDataplaneV2: true está configurado na resposta automática OnPremUserCluster . Caso contrário, o cluster continuará usando o Docker para pools de nós do Windows, que não serão compatíveis com o modelo de VM do Windows 1.13 recém-criado que não tem o Docker instalado. Se não estiver configurado ou estiver definido como falso, atualize o cluster definindo-o como verdadeiro em user-cluster.yaml e, em seguida, execute:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Faça upgrade dos clusters de administrador+usuário exclusivos do Linux para a versão 1.13 seguindo o guia do usuário para upgrade.
- Prepare o modelo de VM do Windows usando o gkectl 1.13:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Adicione novamente a configuração do pool de nós do Windows ao user-cluster.yaml com o campo
OSImage definido como o modelo de VM recém-criado do Windows.
- Atualizar o cluster para adicionar pools de nós do Windows
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
|
Instalação, upgrades e atualizações |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
A configuração RootDistanceMaxSec não está em vigor para
ubuntu nós
O valor padrão de 5 segundos para RootDistanceMaxSec será usado nos nós, em vez de 20 segundos, que seria a configuração esperada. Se você verificar o registro de inicialização do nó usando SSH na VM, localizada em `/var/log/startup.log`, poderá encontrar o seguinte erro:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
O uso de um RootDistanceMaxSec de cinco segundos pode fazer com que o relógio do sistema fique fora de sincronia com o servidor NTP quando o deslocamento do relógio for maior que cinco segundos.
Alternativa:
Conecte-se por SSH aos nós e configure RootDistanceMaxSec :
mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
|
Upgrades e atualizações |
1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
gkectl update admin falha devido a um campo osImageType vazio
Quando você usa a versão 1.13 gkectl para atualizar um cluster de administrador da versão 1.12, é possível ver o seguinte erro:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Ao usar gkectl update admin para clusters da versão 1.13 ou 1.14, você verá a seguinte mensagem na resposta:
Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time
Se você verificar o registro gkectl , verá que as várias alterações incluem a configuração de osImageType de uma string vazia como ubuntu_containerd .
Esses erros de atualização ocorrem devido ao preenchimento incorreto do campo osImageType na configuração do cluster de administrador desde que ele foi introduzido na versão 1.9.
Alternativa:
Faça upgrade para uma versão dos clusters do Anthos no VMware com a correção. Se o upgrade não for possível, entre em contato com o Cloud Customer Care para resolver esse problema.
|
Instalação, segurança |
1.13, 1.14, 1.15 |
SNI não funciona em clusters de usuário com o Controlplane V2
A capacidade de fornecer um certificado de atendimento extra para o servidor da API Kubernetes de um cluster de usuário com authentication.sni não funciona quando o Controlplane V2 está ativado (enableControlplaneV2: true ).
Alternativa:
Até que um patch do Anthos no VMware esteja disponível com a correção, se você
precisar usar a SNI, desative o Controlplane V2 (enableControlplaneV2: false ).
|
Instalação |
1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
$ no nome de usuário do registro particular causa falha na inicialização da máquina do plano de controle de administrador
A máquina do plano de controle de administrador não é iniciada quando o nome de usuário do registro particular contém $ .
Ao verificar o /var/log/startup.log na máquina do plano de controle de administrador, você verá o seguinte erro:
++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable
Alternativa:
Use um nome de usuário de registro particular sem $ ou uma versão dos clusters do Anthos no VMware com a correção.
|
Upgrades e atualizações |
1.12.0-1.12.4 |
Avisos de falso positivo sobre alterações não compatíveis durante a atualização do cluster de administrador
Ao atualizar clusters de administrador, você verá os seguintes avisos de falso positivo no registro e poderá ignorá-los.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
Upgrades e atualizações |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Falha ao atualizar cluster de usuário após rotação de chaves de assinatura KSA
Depois que você alterna as chaves de assinatura KSA e, depois,
atualiza um cluster de usuário, o gkectl update pode falhar com a seguinte mensagem de erro:
Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"
Alternativa:
Altere a versão da chave de assinatura KSA novamente para 1, mas retenha os dados mais recentes da chave:
- Verifique o secret no cluster de administrador no namespace
USER_CLUSTER_NAME e encontre o nome do secret ksa-signing-key:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
- Copie o secret ksa-signing-key e nomeie essa cópia como service-account-cert:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
- Exclua o secret ksa-signing-key anterior:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Atualize o campo
data.data no ConfigMap ksa-signing-key-rotation-stage para '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
- Desative o webhook de validação para editar as informações da versão no recurso personalizado OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremuserclusters
'
- Atualize o campo
spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation para 1 no recurso personalizado OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
- Aguarde até que o cluster de usuário de destino esteja pronto. Verifique o status:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
- Restaure o webhook de validação do cluster de usuário:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremuserclusters
'
- Evite fazer outra rotação de chaves de assinatura KSA até o cluster fazer upgrade para a versão com a correção.
|
Operação |
1.13.1+, 1.14, 1.15 |
Quando você usa o Terraform para excluir um cluster de usuário com um balanceador de carga F5 BIG-IP, os servidores virtuais F5 BIG-IP não são removidos após a exclusão do cluster.
Alternativa:
Para remover os recursos F5, siga as etapas para limpar uma partição F5 do cluster de usuário
|
Instalação, upgrades e atualizações |
1.13.8, 1.14.4 |
Cluster kind extrai imagens de contêiner de docker.io
Se você criar um cluster de administrador com a versão 1.13.8 ou 1.14.4 ou fizer upgrade dele para a versão 1.13.8 ou 1.14.4, o cluster kind extrairá as seguintes imagens de contêiner de docker.io :
docker.io/kindest/kindnetd
docker.io/kindest/local-path-provisioner
docker.io/kindest/local-path-helper
Se docker.io não estiver acessível na estação de trabalho de administrador, a criação ou o upgrade do cluster de administrador não conseguirá trazer o cluster kind.
A execução do comando a seguir na estação de trabalho de administrador mostra os contêineres correspondentes pendentes com ErrImagePull :
docker exec gkectl-control-plane kubectl get pods -A
A resposta contém entradas como estas:
...
kube-system kindnet-xlhmr 0/1
ErrImagePull 0 3m12s
...
local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1
Pending 0 3m12s
...
Essas imagens de contêiner precisam ser pré-carregadas na imagem de contêiner do cluster kind. No entanto, o kind v0.18.0 tem um problema com as imagens de contêiner pré-carregadas, que faz com que elas sejam extraídas da Internet por engano.
Alternativa:
Execute os seguintes comandos na estação de trabalho de administrador enquanto o cluster de administrador está com a criação ou o upgrade pendente:
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
|
Operação |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
Falha de failover em clusters de usuário e administrador do Controlplane V2 de alta disponibilidade quando a rede filtra solicitações GARP duplicadas
Se as VMs do cluster estiverem conectadas a um switch que filtra solicitações GARP (ARP gratuitas) duplicadas, a eleição de líder de atividade pode encontrar uma disputa, o que faz com que alguns nós tenham entradas de tabela ARP incorretas.
Os nós afetados podem dar um ping no VIP do plano de controle, mas uma conexão TCP com o VIP do plano de controle expira.
Alternativa:
Execute o seguinte comando em cada nó do plano de controle do cluster afetado:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
Upgrades e atualizações |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
O vsphere-csi-controller precisa ser reiniciado após a rotação do certificado do vCenter
vsphere-csi-controller precisa atualizar a chave secreta do vCenter após a rotação do certificado. No entanto, o sistema atual não reinicia corretamente os pods do vsphere-csi-controller , fazendo com que vsphere-csi-controller falhe após a rotação.
Alternativa:
Para clusters criados nas versões 1.13 e posteriores, siga as instruções abaixo para reiniciar vsphere-csi-controller .
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
|
Instalação |
1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1 |
A criação do cluster de administrador não falha em erros de registro do cluster
Mesmo quando o registro de cluster falha durante a criação do cluster de administrador, o comando gkectl create admin não falha no erro e pode ser bem-sucedido. Em outras palavras, a criação do cluster de administrador pode ter "êxito" sem o registro em uma frota.
Para identificar o sintoma, procure as mensagens de erro a seguir no registro de "gkectl create admin".
Failed to register admin cluster
Verifique também se encontra o cluster entre os clusters registrados no console do Cloud.
Alternativa:
Em clusters criados nas versões 1.12 e posteriores, siga as instruções para tentar novamente o registro do cluster de administrador após a criação do cluster. Para clusters criados em versões anteriores:
-
anexe um par de chave-valor falso, como "foo: bar", ao seu arquivo de chave SA do connect-register;
-
Execute
gkectl update admin para registrar novamente o cluster de administrador.
|
Upgrades e atualizações |
1.10, 1.11, 1.12, 1.13.0-1.13.1 |
A ação de registrar novamente o cluster de administrador pode ser ignorada durante o upgrade do cluster de administrador
Durante o upgrade do cluster de administrador, se o upgrade dos nós do plano de controle do usuário expirar, o cluster de administrador não será registrado novamente com a versão atualizada do agente de conexão.
Alternativa:
Verifique se o cluster é exibido entre os clusters registrados.
Como etapa opcional, faça login no cluster após configurar a autenticação. Se o cluster ainda estiver registrado, pule as instruções a seguir sobre tentar novamente o registro.
Em clusters que fizeram upgrade para as versões 1.12 e posteriores, siga as instruções para tentar novamente o registro do cluster de administrador após a criação do cluster. Em clusters que fizeram upgrade para versões anteriores:
-
anexe um par de chave-valor falso, como "foo: bar", ao seu arquivo de chave SA do connect-register;
-
Execute
gkectl update admin para registrar novamente o cluster de administrador.
|
Configuração |
1.15.0 |
Mensagem de erro falsa sobre vCenter.dataDisk
Para um cluster de administrador de alta disponibilidade, gkectl prepare mostra esta mensagem de erro falsa:
vCenter.dataDisk must be present in the AdminCluster spec
Alternativa:
Você pode ignorar esse erro com segurança.
|
VMware |
1.15.0 |
A criação do pool de nós falha devido a regras de afinidade redundantes de VM para host
Durante a criação de um pool de nós que usa Afinidade de VM para host, uma disputa pode resultar na criação de várias Regras de afinidade de VM para host com o mesmo nome. Isso pode causar falha na criação do pool de nós.
Alternativa:
Remova as regras redundantes antigas para poder continuar a criação do pool de nós.
Essas regras são chamadas [USER_CLUSTER_NAME]-[HASH].
|
Operação |
1.15.0 |
gkectl repair admin-master pode falhar devido a failed
to delete the admin master node object and reboot the admin master VM
O comando gkectl repair admin-master pode falhar devido a uma disputa com o seguinte erro.
Failed to repair: failed to delete the admin master node object and reboot the admin master VM
Alternativa:
Esse comando é idempotente. O comando pode ser executado com segurança novamente até ter êxito.
|
Upgrades e atualizações |
1.15.0 |
Os pods permanecem no estado "Falha" ao recriar ou atualizar um nó do plano de controle
Depois de recriar ou atualizar um nó do plano de controle, alguns pods podem permanecer no estado Failed devido a uma falha no predicado NodeAffinity. Esses pods com falha não afetam a integridade ou as operações normais do cluster.
Alternativa:
É possível ignorar com segurança os pods com falha ou excluí-los manualmente.
|
Segurança, configuração |
1.15 |
O OnPremUserCluster não está pronto devido a credenciais de registro particulares
Se você usa credenciais preparadas e um registro particular, mas não configurou credenciais preparadas para seu registro particular, o OnPremUserCluster pode não ficar pronto e você verá a seguinte mensagem de erro:
failed to check secret reference for private registry …
Alternativa:
Prepare as credenciais do registro particular para o cluster de usuário de acordo com as instruções em Configurar credenciais preparadas.
|
Upgrades e atualizações |
1.15.0 |
Durante gkectl upgrade admin , a verificação de simulação de armazenamento para a CSI Migration verifica se o StorageClasses não tem parâmetros que são ignorados após a CSI Migration.
Por exemplo, se houver um StorageClass com o parâmetro diskformat , gkectl upgrade admin sinalizará o StorageClass e reportará uma falha na validação de simulação.
Os clusters de administrador criados no Anthos 1.10 e anteriores têm um StorageClass com diskformat: thin ,
que falhará nessa validação. No entanto, esse StorageClass ainda funciona
bem após a migração do CSI. Essas falhas precisam ser interpretadas como alertas.
Para mais informações, consulte a seção do parâmetro StorageClass em Como migrar volumes do vSphere em árvore para o plug-in vSphere Container Storage.
Alternativa:
Depois de confirmar que seu cluster tem um StorageClass com parâmetros ignorados depois da migração da CSI, execute gkectl upgrade admin com a flag --skip-validation-cluster-health .
|
Armazenamento |
1.15 |
Os volumes do vSphere em árvore migrados usando o sistema de arquivos do Windows não podem ser usados com o driver vSphere CSI
Em determinadas condições, os discos podem ser anexados como somente leitura aos nós do Windows. Isso faz com que o volume correspondente seja somente leitura dentro de um pod.
É mais provável que esse problema ocorra quando um novo conjunto de nós substitui um conjunto antigo (por exemplo, upgrade de cluster ou atualização de pool de nós). As cargas de trabalho com estado que anteriormente funcionavam bem podem não conseguir gravar nos respectivos volumes no novo conjunto de nós.
Alternativa:
-
Encontre o UID do pod que não consegue gravar no respectivo volume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Use o PersistentVolumeClaim para encontrar o nome do PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Determine o nome do nó em que o pod está em execução:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
--namespace POD_NAMESPACE \
-o jsonpath='{.spec.nodeName}{"\n"}'
-
Consiga acesso ao nó via PowerShell, seja por SSH ou pela interface da Web do vSphere.
-
Defina as variáveis de ambiente:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifique o número do disco associado ao PersistentVolume:
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
-
Verifique se o disco é
readonly :
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly O resultado será True .
- Defina
readonly como false .
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Exclua o pod para que ele seja reiniciado:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
O pod precisa ser programado no mesmo nó. No entanto, se o pod for programado em um novo nó, talvez seja necessário repetir as etapas anteriores nesse nó.
|
Upgrades e atualizações |
1.12, 1.13.0-1.13.7, 1.14.0-1.14.4 |
vsphere-csi-secret não é atualizado após gkectl update credentials vsphere --admin-cluster
Se você atualizar as credenciais do vSphere de um cluster de administrador após a atualização das credenciais do cluster, talvez encontre o vsphere-csi-secret no namespace kube-system no cluster de administrador ainda usando a credencial antiga.
Alternativa:
- Consiga o nome do secret
vsphere-csi-secret :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- Atualize os dados do secret
vsphere-csi-secret que você recebeu na etapa acima:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
"{\"data\":{\"config\":\"$( \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
| base64 -d \
| sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
| sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
| base64 -w 0 \
)\"}}"
- Restart
vsphere-csi-controller :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- É possível acompanhar o status de lançamento com:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Depois que a implantação for concluída, o vsphere-csi-secret atualizado deverá ser usado pelo controlador.
|
Upgrades e atualizações |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
audit-proxy com loop de falhas ao ativar os Registros de auditoria do Cloud com gkectl update cluster
audit-proxy pode falhar em loop devido a uma --cluster-name vazia.
Esse comportamento é causado por um bug na lógica de atualização, em que o nome do cluster não é propagado para o manifesto do pod/contêiner do proxy de auditoria.
Alternativa:
Em um cluster de usuário do plano de controle v2 com enableControlplaneV2: true , conecte-se à máquina do plano de controle do usuário usando SSH e atualize /etc/kubernetes/manifests/audit-proxy.yaml com --cluster_name=USER_CLUSTER_NAME .
Em um cluster de usuário do plano de controle v1, edite o contêiner audit-proxy no kube-apiserver com estado definido para adicionar --cluster_name=USER_CLUSTER_NAME :
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
|
Upgrades e atualizações |
1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Uma reimplantação do plano de controle adicional logo após gkectl upgrade cluster
Logo após gkectl upgrade cluster , os pods do plano de controle podem ser reimplantados novamente.
O estado do cluster de gkectl list clusters muda de RUNNING PARA RECONCILING .
As solicitações para o cluster de usuário podem expirar.
Esse comportamento ocorre devido à rotação automática de certificados do plano de controle após gkectl upgrade cluster .
Esse problema só acontece com clusters de usuário que NÃO usam o plano de controle v2.
Alternativa:
Aguarde o estado do cluster voltar para RUNNING novamente em gkectl list clusters ou faça upgrade para versões com a correção: 1.13.6+, 1.14.2+ ou 1.15+.
|
Upgrades e atualizações |
1.12.7 |
A versão incorreta 1.12.7-gke.19 foi removida
Os clusters do Anthos no VMware 1.12.7-gke.19 são uma versão incorreta, e você não deve usá-la. Os artefatos foram removidos do bucket do Cloud Storage.
Alternativa:
Use a versão 1.12.7-gke.20.
|
Upgrades e atualizações |
1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent continuará usando a imagem mais antiga após a atualização da credencial do registro.
Se você atualizar a credencial do registro usando um dos métodos a seguir:
gkectl update credentials componentaccess se não estiver usando o registro particular
gkectl update credentials privateregistry se estiver usando o registro particular
Você pode descobrir que gke-connect-agent continua usando a imagem mais antiga ou que os pods gke-connect-agent não podem ser abertos devido a ImagePullBackOff .
Esse problema será corrigido nas versões 1.13.8, 1.14.4 e posteriores dos clusters do Anthos no VMware.
Alternativa:
Opção 1: reimplantar gke-connect-agent manualmente:
- Exclua o namespace
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Reimplante o
gke-connect-agent com a chave da conta de serviço de registro original (não é necessário atualizar a chave):
Para o cluster de administrador:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
Para o cluster de usuário:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Opção 2: é possível alterar manualmente os dados do secret de pull de imagem regcred que é usado pela implantação do gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"
Opção 3: é possível adicionar a chave secreta de pull de imagem padrão ao cluster na implantação do gke-connect-agent :
- Copie o secret padrão para o namespace
gke-connect :
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
- Consiga o nome da implantação do
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- Adicione o secret padrão à implantação do
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
|
Instalação |
1.13, 1.14 |
Falha na verificação de configuração do balanceador de carga manual
Quando você valida a configuração antes de criar um cluster com o balanceador de carga manual executando gkectl check-config , o comando falha com as mensagens de erro a seguir.
- Validation Category: Manual LB Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference
Alternativa:
Opção 1: é possível usar as versões de patch 1.13.7 e 1.14.4, que incluem a correção.
Opção 2: também é possível executar o mesmo comando para validar a configuração, mas pular a validação do balanceador de carga.
gkectl check-config --skip-validation-load-balancer
|
Operação |
1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 e 1.14 |
privação do relógio no etcd
Os clusters que executam o etcd versão 3.4.13 ou anterior podem apresentar privação do relógio e relógios de recursos não operacionais, que podem causar os seguintes problemas:
- A programação do pod é interrompida
- Não é possível registrar nós
- O kubelet não observa mudanças no pod
Esses problemas podem tornar o cluster não funcional.
Esse problema foi corrigido nas versões 1.12.7, 1.13.6, 1.14.3 e posteriores dos clusters do Anthos no VMware. Essas versões mais recentes usam o etcd versão 3.4.21. Todas as versões anteriores dos clusters do Anthos no VMware foram afetadas por esse problema.
Alternativa
Se não for possível fazer upgrade imediatamente, reduza o risco de falha do cluster diminuindo seu número de nós. Remova os nós até que a métrica etcd_network_client_grpc_sent_bytes_total seja inferior a 300 MBps.
Para visualizar essa métrica no Metrics Explorer:
- Acesse o Metrics Explorer no Console do Google Cloud:
Acesse o Metrics Explorer
- Selecione a guia Configuração.
- Expanda Selecionar uma métrica, insira
Kubernetes Container na barra de filtros e use os submenus para selecionar a métrica:
- No menu Recursos ativos, selecione Contêiner do Kubernetes.
- No menu Categorias de métricas ativas, selecione Anthos.
- No menu Métricas ativas, selecione
etcd_network_client_grpc_sent_bytes_total .
- Clique em Aplicar.
|
Upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 e 1.14 |
O Anthos Identity Service pode causar latências no plano de controle
Nas reinicializações ou upgrades de cluster, o Anthos Identity Service pode ficar sobrecarregado com o tráfego composto por tokens JWT expirados encaminhados do kube-apiserver para o Anthos Identity Service através do webhook de autenticação. Embora o Anthos Identity Service não apresente loop de falhas, ele para de responder e cessa o atendimento de novas solicitações.
Esse problema acaba gerando latências maiores no plano de controle.
Esse problema foi corrigido nas seguintes versões dos clusters do Anthos no VMware:
Para determinar se esse problema está afetando você, execute as seguintes etapas:
- Verifique se o endpoint do Anthos Identity Service pode ser acessado externamente:
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Substitua CLUSTER_ENDPOINT pela porta do balanceador de carga e VIP do plano de controle para o cluster (por exemplo, 172.16.20.50:443 ).
Se esse problema estiver afetando você, o comando retornará um código de status 400 . Se a solicitação expirar, reinicie o pod ais e execute novamente o comando curl para ver se isso resolve o problema. Se você receber um código de status 000 , o problema foi resolvido e está tudo pronto. Se você ainda receber um código de status 400 , o servidor HTTP do Anthos Identity Service não iniciará. Nesse caso, continue.
- Verifique os registros do Anthos Identity Service e kube-apiserver:
- Verifique o registro do Anthos Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Quando esse problema está afetando você, o registro contém uma entrada como esta:
I0811 22:32:03.583448 32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
- Verifique os registros
kube-apiserver dos clusters:
Nos comandos a seguir, KUBE_APISERVER_POD é o nome do pod kube-apiserver no cluster especificado.
Cluster de administrador:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n kube-system KUBE_APISERVER_POD kube-apiserver
Cluster de usuário:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver
Quando esse problema está afetando você, os registros kube-apiserver contêm entradas como estas:
E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
Alternativa
Se não for possível fazer upgrade dos clusters imediatamente para efetuar a correção, identifique e reinicie os pods ofensivos como uma solução alternativa:
- Aumente o nível de detalhes do Anthos Identity Service para 9:
kubectl patch deployment ais -n anthos-identity-service --type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
"value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
--kubeconfig KUBECONFIG
- Verifique se o registro do Anthos Identity Service apresenta o contexto de token inválido:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
- Para saber o payload do token associado a cada contexto de token inválido, analise cada secret da conta de serviço relacionada usando o comando a seguir:
kubectl -n kube-system get secret SA_SECRET \
--kubeconfig KUBECONFIG \
-o jsonpath='{.data.token}' | base64 --decode
- Para decodificar o token e ver o nome e o namespace do pod de origem, copie o token para o depurador em jwt.io.
- Reinicie os pods identificados nos tokens.
|
Operação |
1.8, 1.9, 1.10 |
Problema de aumento no uso de memória dos pods de manutenção do etcd
Os pods de manutenção do etcd que usam a imagem etcddefrag:gke_master_etcddefrag_20210211.00_p0 são afetados. O contêiner "etcddefrag" abre uma nova conexão com o servidor etcd durante cada ciclo de infraestrutura e as conexões antigas não são limpas.
Alternativa:
Opção 1: fazer upgrade para a versão mais recente do patch da versão 1.8 para a 1.11 com a correção
Opção 2: se você estiver usando uma versão de patch anterior à 1.9.6 e 1.10.3, será preciso reduzir a escala vertical do pod de manutenção do etcd para o cluster de administrador e de usuário:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Operação |
1.9, 1.10, 1.11, 1.12, 1.13 |
Perda das verificações de integridade dos pods do plano de controle do cluster de usuário
O controlador de integridade do cluster e o comando gkectl diagnose cluster executam um conjunto de verificações de integridade, incluindo as verificações de integridade dos pods nos namespaces. No entanto, elas começam a pular os pods do plano de controle do usuário por engano. Se você usar o modo de plano de controle v2, isso não afetará seu cluster.
Alternativa:
Isso não afeta o gerenciamento de clusters ou cargas de trabalho. Se você quiser verificar a integridade dos pods do plano de controle, execute os seguintes comandos:
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Upgrades e atualizações |
1.6+, 1.7+ |
Os upgrades do cluster de administrador 1.6 e 1.7 podem ser afetados pelo redirecionamento k8s.gcr.io -> registry.k8s.io .
O Kubernetes redirecionou o tráfego de k8s.gcr.io para registry.k8s.io em 20/03/2023. Nos clusters do Anthos no VMware 1.6.x e 1.7.x, os upgrades de cluster de administrador usam a imagem de contêiner k8s.gcr.io/pause:3.2 . Se você usar um proxy na estação de trabalho do administrador e o proxy não permitir registry.k8s.io , e a imagem do contêiner k8s.gcr.io/pause:3.2 não estiver armazenada em cache localmente, os upgrades do cluster de administrador falharão ao extrair a imagem do contêiner.
Alternativa:
Adicione registry.k8s.io à lista de permissões do proxy para sua estação de trabalho do administrador.
|
Rede |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Falha na validação do Seesaw na criação do balanceador de carga
gkectl create loadbalancer falha com a seguinte mensagem de erro:
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
Isso ocorreu devido ao arquivo do grupo do Seesaw. E a verificação de simulação
tenta validar um balanceador de carga de gangorra inexistente.
Alternativa:
Remova o arquivo do grupo do Seesaw atual do cluster. O nome do arquivo
é seesaw-for-gke-admin.yaml para o cluster de administrador e
seesaw-for-{CLUSTER_NAME}.yaml para um cluster de usuário.
|
Rede |
1.14 |
Tempos limite do aplicativo causados por falhas de inserção da tabela de conexão
Os clusters do Anthos na VMware versão 1.14 são suscetíveis a
falhas de inserção de tabela no rastreamento de conexão (conntrack) do netfilter ao usar
imagens de sistema operacional Ubuntu ou COS. As falhas de inserção levam a um tempo limite
aleatório do aplicativo e podem ocorrer mesmo quando a tabela de conntrack tiver espaço
para novas entradas. As falhas são causadas por alterações no
kernel 5.15 e mais recentes que restringem as inserções de tabelas com base no comprimento
da cadeia.
Para saber se esse problema te afeta, verifique as estatísticas do sistema de rastreamento de conexão no kernel em cada nó com o seguinte comando:
sudo conntrack -S
A resposta será assim:
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...
Se o valor chaintoolong na resposta for um número diferente de zero, esse problema afeta você.
Alternativa
A mitigação de curto prazo aumenta o tamanho da tabela de hash
netfiler (nf_conntrack_buckets ) e da tabela de
rastreamento de conexão do netfilter (nf_conntrack_max ). Use os
seguintes comandos em cada nó de cluster para aumentar o tamanho das
tabelas:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Substitua TABLE_SIZE pelo novo tamanho em bytes. O
valor padrão de tamanho da tabela é 262144 . Sugerimos definir um valor igual a 65.536 vezes o número de núcleos no nó. Por exemplo,
se o nó tiver oito núcleos, defina o tamanho da tabela como 524288 .
|
Rede |
1.13.0-1.13.2 |
loop de falha calico-typha ou anetd-operator nos nós do Windows com o Controlplane v2
Com o Controlplane v2 ou um novo modelo de instalação, é possível programar calico-typha ou anetd-operator para nós do Windows e entrar em loop de falhas.
O motivo é que as duas implantações toleram todos os taints, incluindo o taint de nó do Windows.
Alternativa:
Faça upgrade para a versão 1.13.3 ou posterior ou execute os seguintes comandos para editar a implantação "calico-typha" ou "anetd-operator":
# If dataplane v2 is not used.
kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
# If dataplane v2 is used.
kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
Remova os seguintes spec.template.spec.tolerations :
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
E adicione a seguinte tolerância:
- key: node-role.kubernetes.io/master
operator: Exists
|
Configuração |
1.14.0-1.14.2 |
Não é possível carregar o arquivo da credencial de registro particular do cluster de usuário
Talvez não seja possível criar um cluster de usuário se você especificar a
seção privateRegistry com a credencial fileRef .
A simulação pode falhar com a seguinte mensagem:
[FAILURE] Docker registry access: Failed to login.
Alternativa:
|
Operações |
1.10+ |
O Anthos Service Mesh e outras malhas de serviço não são compatíveis com o Dataplane v2
O Dataplane V2 assume o balanceamento de carga e cria um soquete kernel em vez de um DNAT baseado em pacote. Isso significa que o Anthos Service Mesh
não pode fazer a inspeção de pacotes porque o pod é ignorado e nunca usa IPTables.
Isso se manifesta no modo gratuito do kube-proxy pela perda de conectividade ou pelo roteamento de tráfego incorreto para serviços com o Anthos Service Mesh, porque o arquivo secundário não pode inspecionar pacotes.
Esse problema está presente em todas as versões dos clusters do Anthos em bare metal 1.10, mas algumas versões 1.10 mais recentes (1.10.2+) têm uma solução alternativa.
Alternativa:
Faça upgrade para a versão 1.11 para ter compatibilidade total ou, se a versão for 1.10.2 ou posterior, execute:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
Adicione bpf-lb-sock-hostns-only: true ao configmap e reinicie o daemonset anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Armazenamento |
1.12+, 1.13.3 |
kube-controller-manager pode remover os volumes permanentes
à força após seis minutos
kube-controller-manager pode expirar ao remover
PV/PVCs após seis minutos e remover à força esses PV/PVCs. Os registros detalhados
de kube-controller-manager mostram eventos semelhantes aos
seguintes:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Para verificar o problema, faça login no nó e execute os seguintes comandos:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
No registro do kubelet, são exibidos erros como estes:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Alternativa:
Conecte-se ao nó afetado usando SSH e reinicie o nó.
|
Upgrades e atualizações |
1.12+, 1.13+, 1.14+ |
O upgrade do cluster ficará travado se um driver CSI de terceiros for usado
Talvez não seja possível fazer upgrade de um cluster se você usar um driver CSI de
terceiros. O comando gkectl cluster diagnose pode retornar o
seguinte erro:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Alternativa:
Faça o upgrade usando a opção --skip-validation-all .
|
Operação |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ |
gkectl repair admin-master cria a VM mestre do administrador
sem fazer upgrade da versão do hardware da vm
O nó mestre do administrador criado via gkectl repair admin-master
pode usar uma versão de hardware de VM inferior à esperada. Quando o problema acontecer, você verá o erro do relatório gkectl diagnose cluster .
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Alternativa:
Encerre o nó mestre do administrador. Siga
https://kb.vmware.com/s/article/1003746
para fazer upgrade do nó para a versão esperada descrita no erro
e inicie o nó.
|
Sistema operacional |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+ |
A VM libera o lease de DHCP no encerramento/reinicialização inesperado, o que pode
resultar em alterações no IP
No systemd v244, o systemd-networkd tem uma
mudança de comportamento padrão
na configuração do KeepConfiguration . Antes dessa mudança,
as VMs não enviavam uma mensagem de lançamento da lease de DHCP para o servidor DHCP no
encerramento ou reinicialização. Após essa alteração, as VMs enviam essa mensagem e
retornam os IPs ao servidor DHCP. Como resultado, o IP liberado pode ser
realocado para uma VM diferente e/ou outro IP pode ser atribuído à
VM, resultando em conflito de IP (no nível do Kubernetes, não no vSphere)
/ou alteração de IP nas VMs, o que pode interromper os clusters de várias maneiras.
Por exemplo, você pode ver os sintomas a seguir.
- A IU do vCenter mostra que nenhuma VM usa o mesmo IP, mas
kubectl get
nodes -o wide retorna nós com IPs duplicados.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- Novos nós não iniciam devido a erro
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Alternativa:
Implante o DaemonSet a seguir no cluster para reverter a
mudança de comportamento padrão systemd-networkd . As VMs que executam esse DaemonSet não liberarão os IPs ao servidor DHCP no encerramento/reinicialização. Os IPs serão liberados automaticamente pelo servidor DHCP
quando as leases expirarem.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Operação, upgrades e atualizações |
1.12.0+, 1.13.0+, 1.14.0+ |
A chave da conta de serviço de acesso ao componente foi excluída após o upgrade do cluster de administrador
da versão 1.11.x
Esse problema afetará somente os clusters de administrador atualizados
a partir da versão 1.11.x, mas não os clusters criados após a
versão 1.12.
Depois de fazer upgrade de um cluster 1.11.x para 1.12.x, o
campo component-access-sa-key no
secret admin-cluster-creds será excluído permanentemente para esvaziar.
Para verificar isso, execute o seguinte comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
Se você encontrar a saída vazia, significa que a chave foi excluída permanentemente.
Depois que a chave da conta de serviço de acesso ao componente for excluída,
a instalação de novos clusters de usuário ou o upgrade de clusters de usuário atuais
falhará. Confira a seguir algumas mensagens de erro que você pode encontrar:
- Falha de simulação da validação lenta com a mensagem de erro
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- Falha na preparação de
gkectl prepare com a mensagem de erro:
"Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Se você estiver fazendo upgrade de um cluster de usuário 1.13 usando o Console do Google Cloud
ou a CLI gcloud, quando você executar
gkectl update admin --enable-preview-user-cluster-central-upgrade
para implantar o controlador da plataforma de upgrade, o comando falhará
com a mensagem: "failed to download bundle to disk: dialing:
unexpected end of JSON input" . É possível ver essa mensagem
no campo status na
saída de kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml .
Alternativa:
Adicione a chave da conta de serviço de acesso ao componente de volta ao secret
manualmente executando o seguinte comando:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
|
Operação |
1.13.0+, 1.14.0+ |
O escalonador automático de clusters não funciona quando o Controlplane V2 está ativado
Para clusters de usuários criados com o Controlplane V2 ouum novo modelo de instalação, pools de nós comescalonamento automático sempre usam oescalonamento automático.minReplicas no arquivo user-cluster.yaml. O registro do pod de escalonador automático de clusters também mostra que eles não estão íntegros.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
TIMESTAMP 1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
Para encontrar o pod do escalonador automático de clusters, execute os comandos a seguir.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c 4648017n 48076Ki 30s
Alternativa:
Desative o escalonamento automático em todos os pools de nós com "gkectl update cluster" até fazer upgrade para uma versão com a correção.
|
Instalação |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
CIDR não é permitido no arquivo de bloco de IP
Quando os usuários usam o CIDR no arquivo de bloco de IP, a validação de configuração falha com o seguinte erro:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Alternativa:
Inclua IPs individuais no arquivo de bloco de IPs até fazer upgrade para uma versão com a correção: 1.12.5, 1.13.4, 1.14.1+.
|
Upgrades e atualizações |
1.14.0-1.14.1 |
A atualização do tipo de imagem do SO no admin-cluster.yaml não aguarda a recriação das máquinas do plano de controle do usuário
Ao atualizar o tipo de imagem do SO do plano de controle em admin-cluster.yaml e se o cluster de usuário correspondente tiver sido criado pelo Controlplane V2, as máquinas do plano de controle do usuário não poderão concluir a recriação quando o comando gkectl for concluído.
Alternativa:
Depois que a atualização for concluída, aguarde até que as máquinas do plano de controle do usuário também concluam a recriação ao monitorar os tipos de imagem do SO do nó usando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide . Por exemplo, se atualizar do Ubuntu para o COS, devemos esperar que todas as máquinas do plano de controle mudem completamente do Ubuntu para o COS mesmo após a conclusão do comando de atualização.
|
Operação |
1.14.0 |
Erros de criação ou exclusão de pods devido a um problema no token de autenticação da conta de serviço
da CNI do Calico
Um problema com o Calico nos clusters do Anthos no VMware 1.14.0
faz com que a criação e a exclusão de pods falhem com a seguinte mensagem de erro
na saída de kubectl describe pods :
error getting ClusterInformation: connection is unauthorized: Unauthorized
Esse problema só é observado 24 horas após a criação ou
o upgrade do cluster para a versão 1.14 usando o Calico.
Os clusters de administrador estão sempre usando o Calico. Já para o cluster de usuário, há
um campo de configuração "enableDataPlaneV2" em user-cluster.yaml. Se esse campo estiver
definido como "falso" ou não for especificado, você estará usando o Calico no cluster de
usuário.
O contêiner install-cni dos nós cria um kubeconfig com um
token válido por 24 horas. Esse token precisa ser renovado
periodicamente pelo pod calico-node . O pod
calico-node não pode renovar o token porque não tem acesso ao diretório
que contém o arquivo kubeconfig no nó.
Alternativa:
Para atenuar o problema, aplique o seguinte patch no
DaemonSet calico-node no cluster de administrador e usuário:
kubectl -n kube-system get daemonset calico-node \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
kubectl -n kube-system get daemonset calico-node \
--kubeconfig USER_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Substitua:
ADMIN_CLUSTER_KUBECONFIG : o caminho
do arquivo kubeconfig do cluster de administrador.
USER_CLUSTER_CONFIG_FILE : o caminho
do arquivo de configuração do cluster de usuário.
|
Instalação |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
A validação do bloco de IP falha ao usar CIDR
A criação do cluster falha, mesmo quando o usuário tem a configuração correta. O usuário recebe uma falha na criação porque o cluster não tem IPs suficientes.
Alternativa:
Dividir CIDRs em vários blocos CIDR menores, como 10.0.0.0/30 , se torna 10.0.0.0/31, 10.0.0.2/31 . Desde que haja CIDRs N+1, em que N é o número de nós no cluster, isso vai ser suficiente.
|
Operação, upgrades e atualizações |
1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6 |
O backup do cluster de administrador não inclui as chaves de criptografia de secrets e a configuração sempre ativadas
Quando o atributo de criptografia de secrets sempre ativado for ativado com o backup de cluster, o backup do cluster de administrador não incluirá as chaves de criptografia e a configuração exigidas pelo atributo de criptografia de secrets sempre ativado. Como resultado, reparar o mestre do administrador com esse backup usando gkectl repair admin-master --restore-from-backup causa o seguinte erro:
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Alternativa:
- Use o binário gkectl da versão de patch mais recente disponível para a versão secundária correspondente a fim de fazer o backup do cluster de administrador após operações críticas do cluster. Por exemplo, se o cluster estiver executando uma versão 1.10.2, use o binário gkectl 1.10.5 para fazer um backup manual do cluster de administrador, conforme descrito em Fazer backup e restaurar um cluster de administrador com gkectl.
|
Operação, upgrades e atualizações |
1.10+ |
Recriar a VM mestre do administrador com um novo disco de inicialização (por exemplo, gkectl repair admin-master ) falhará se o atributo de criptografia de secrets sempre ativado estiver ativado usando o comando "gkectl update".
Se o atributo de criptografia de secrets sempre ativado não estiver ativado na criação do cluster, mas for ativado depois usando a operação gkectl update , o gkectl repair admin-master não vai reparar o nó do plano de controle do cluster de administrador. É recomendável ativar o atributo de criptografia de secrets sempre ativado durante a criação do cluster. Não há mitigação atual.
|
Upgrades e atualizações |
1.10 |
Fazer upgrade do primeiro cluster de usuário de 1.9 para 1.10 recria nós em outros clusters de usuário
O upgrade do primeiro cluster de usuário de 1.9 para 1.10 pode recriar nós em outros clusters de usuário no mesmo cluster de administrador. A recriação é feita de modo contínuo.
O disk_label foi removido de MachineTemplate.spec.template.spec.providerSpec.machineVariables , o que acionou uma atualização em todos os MachineDeployment s inesperadamente.
Alternativa:
Ver etapas de solução alternativa
- Reduza a réplica de
clusterapi-controllers para 0 em todos os clusters de usuários.
kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Faça upgrade de cada cluster de usuário um por um.
|
Upgrades e atualizações |
1.10.0 |
O Docker é reiniciado com frequência após o upgrade do cluster
Fazer upgrade do cluster de usuário para 1.10.0 pode causar a reinicialização do Docker com frequência.
Execute kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG para detectar esse problema
Uma condição de nó mostrará se o Docker é reiniciado com frequência. Este um exemplo de saída:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Para entender a causa raiz, é preciso executar o SSH no nó que tem o sintoma e executar comandos como sudo journalctl --utc -u docker ou sudo journalctl -x .
Alternativa:
|
Upgrades e atualizações |
1.11, 1.12 |
Os componentes do GMP autoimplantados não são preservados após o upgrade para a versão 1.12
Se você estiver usando uma versão dos clusters do Anthos no VMware anterior à 1.12 e tiver configurado manualmente os componentes do Prometheus gerenciados pelo Google (GMP) no namespace gmp-system
do seu cluster, os componentes não são preservados quando você
faz upgrade para a versão 1.12.x.
A partir da versão 1.12, os componentes do GMP no namespace gmp-system e nos CRDs são gerenciados pelo objeto
stackdriver , com a flag enableGMPForApplications definida como false por padrão. Se você implantar manualmente os componentes do GMP no namespace antes do upgrade para a versão 1.12, os recursos serão excluídos por stackdriver .
Alternativa:
|
Operação |
1.11, 1.12, 1.13.0 - 1.13.1 |
Objetos ClusterAPI ausentes no snapshot do cluster cenário system
No cenário system , o snapshot do cluster não inclui recursos no namespace default .
No entanto, alguns recursos do Kubernetes, como objetos da API Cluster que estão nesse namespace, contêm informações úteis de depuração. O snapshot do cluster precisa incluí-las.
Alternativa:
Execute os comandos a seguir para coletar as informações de depuração.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
onde:
USER_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de
usuário.
|
Upgrades e atualizações |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
Exclusão de cluster de usuário travada na drenagem do nó para configuração do vSAN
Ao excluir, atualizar ou fazer upgrade de um cluster de usuário, a drenagem do nó pode ficar travada nos seguintes cenários:
- O cluster de administrador usa o driver CSI do vSphere na vSAN desde a versão 1.12.x e
- Não há objetos PVC/PV criados por plug-ins vSphere em árvore no cluster de administrador e de usuário.
Para identificar o sintoma, execute o comando abaixo:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Confira um exemplo de mensagem de erro do comando acima:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols é o diretório padrão para o driver em árvore do vSphere. Quando não houver objetos PVC/PV criados, pode ocorrer um bug em que a drenagem de nós vai ficar travada ao encontrar kubevols , já que a implementação atual supõe que kubevols sempre existe.
Alternativa:
Crie o diretório kubevols no repositório de dados em que o nó foi criado. Isso é definido no campo vCenter.datastore nos arquivos user-cluster.yaml ou admin-cluster.yaml .
|
Configuração |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 |
O clusterrolebinding e o clusterrole do Cluster Autoscaler são excluídos após a exclusão de um cluster de usuário.
Na exclusão do cluster de usuário, os clusterrole e clusterrolebinding correspondentes do escalonador automático de cluster também são excluídos. Isso afeta todos os outros clusters de usuário no mesmo cluster de administrador com o escalonador automático de cluster ativado. Isso ocorre porque os mesmos clusterrole e clusterrolebinding são usados para todos os pods do escalonador automático de cluster no mesmo cluster de administrador.
Os sintomas são os seguintes:
- Registros
cluster-autoscaler
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de
administrador.
Confira um exemplo de mensagens de erro:
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
Alternativa:
Ver etapas de solução alternativa
Verificar se o clusterrole e o clusterrolebinding estão ausentes no cluster de administrador
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Se estiverem ausentes, aplique o clusterrole e o clusterrolebinding a seguir ao cluster de administrador. Adicione os assuntos da conta de serviço ao clusterrolebinding para cada cluster de usuário.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
Configuração |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
O cluster de administrador cluster-health-controller e vsphere-metrics-exporter não funcionam depois de excluir o cluster de usuário
Na exclusão do cluster de usuário, o clusterrole correspondente também é excluído, o que faz com que o reparo automático e o exportador de métricas do vsphere não funcionem
Os sintomas são os seguintes:
- Registros
cluster-health-controller
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de
administrador.
Confira um exemplo de mensagens de erro:
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
Registros vsphere-metrics-exporter
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de
administrador.
Confira um exemplo de mensagens de erro:
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
Alternativa:
Ver etapas de solução alternativa
Aplique o seguinte yaml ao cluster de administrador
- Para vsphere-metrics-exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
Para cluster-health-controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
Configuração |
1.12.1-1.12.3, 1.13.0-1.13.2 |
gkectl check-config falha na validação da imagem do SO
Um problema conhecido que poderia falhar o gkectl check-config sem executar gkectl prepare . Isso é confuso porque sugerimos executar o comando antes de executar gkectl prepare .
O sintoma é que o comando gkectl check-config falha com a
seguinte mensagem de erro:
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
Alternativa:
Opção 1: execute gkectl prepare para fazer upload das imagens ausentes do SO.
Opção 2: use gkectl check-config --skip-validation-os-images para pular a validação de imagens do SO.
|
Upgrades e atualizações |
1.11, 1.12, 1.13 |
gkectl update admin/cluster não consegue atualizar grupos antiafinidade
Um problema conhecido que poderia falhar o gkectl update admin/cluster ao atualizar o anti affinity groups .
O sintoma é que o comando gkectl update falha com a
seguinte mensagem de erro:
Waiting for machines to be re-deployed... ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition
Alternativa:
Ver etapas de solução alternativa
Para que a atualização entre em vigor, as máquinas precisam ser recriadas after a atualização com falha.
Para a atualização do cluster de administrador, os nós mestres e de complementos do administrador precisam ser recriados
Para a atualização do cluster de usuário, os nós de trabalho do usuário precisam ser recriados
Para recriar nós de trabalho do usuário
Opção 1 Siga atualizar um pool de nós e altere a CPU ou a memória para acionar uma recriação contínua dos nós.
Opção 2 Usar kubectl delete para recriar uma máquina de cada vez
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
Para recriar nós mestres de usuários
Opção 1 Siga o plano de controle de redimensionamento e altere a CPU ou a memória para acionar uma recriação contínua dos nós.
Opção 2 Usar kubectl delete para recriar uma máquina de cada vez
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Para recriar nós de complementos do administrador
Usar o kubectl delete para recriar uma máquina de cada vez
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
Instalação, upgrades e atualizações |
1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0 |
O registro do nó falha durante a criação, o upgrade, a atualização do cluster e
o reparo automático do nó, quando ipMode.type é static e
o nome do host configurado no
arquivo de bloco de IP contém um
ou mais pontos finais. Nesse caso, as solicitações de assinatura de certificado (CSR, na sigla em inglês) de um nó não serão aprovadas automaticamente.
Para acessar CSRs pendentes de um nó, execute o comando a seguir:
kubectl get csr -A -o wide
Verifique se há mensagens de erro nos seguintes registros:
- Confira os registros no cluster de administrador do
contêiner
clusterapi-controller-manager no
pod clusterapi-controllers :
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n kube-system \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
- Para acessar os mesmos registros no cluster de usuário, execute o seguinte
comando:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
em que:
- ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster
de administrador.
- USER_CLUSTER_NAME é o nome do cluster de usuário.
Confira um exemplo de mensagens de erro: "msg"="failed
to validate token id" "error"="failed to find machine for node
node-worker-vm-1" "validate"="csr-5jpx9"
- Confira os registros
kubelet no nó problemático:
journalctl --u kubelet
Confira um exemplo de mensagens de erro: "Error getting
node" err="node \"node-worker-vm-1\" not found"
Se você especificar um nome de domínio no campo do nome do host de um arquivo de bloco de IP,
todos os caracteres após o primeiro ponto final serão ignorados. Por exemplo, se
você especificar o nome do host como bob-vm-1.bank.plc , o nome do host
da VM e o nome do nó serão definidos como bob-vm-1 .
Quando a verificação do ID do nó está ativada, o aprovador da CSR compara o
nome do nó com o nome do host na especificação da máquina e não reconcilia
o nome. O aprovador rejeita a CSR, e o nó falha ao
inicializar.
Alternativa:
Cluster de usuário
Para desativar a verificação do ID do nó, siga estas etapas:
- Adicione os seguintes campos ao arquivo de configuração do cluster de usuário:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Salve o arquivo e atualize o cluster de usuário executando o seguinte
comando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Substitua:
ADMIN_CLUSTER_KUBECONFIG : o caminho
do arquivo kubeconfig do cluster de administrador
USER_CLUSTER_CONFIG_FILE : o caminho
do arquivo de configuração do cluster de usuário.
Cluster de administrador
- Abra o recurso personalizado
OnPremAdminCluster para
editar:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Adicione a seguinte anotação ao recurso personalizado:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Edite o manifesto
kube-controller-manager no plano de controle
do cluster de administrador:
- Estabeleça uma conexão SSH com o
nó do plano de controle do cluster de administrador.
- Abra o manifesto
kube-controller-manager para
edição:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Encontre a lista de
controllers :
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Atualize esta seção conforme mostrado abaixo:
--controllers=*,bootstrapsigner,tokencleaner
- Abra o controlador da API Deployment Cluster para edição:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Mude os valores de
node-id-verification-enabled e
node-id-verification-csr-signing-enabled para
false :
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
|
Instalação, upgrades e atualizações |
1.11.0-1.11.4 |
Falha de inicialização da máquina do plano de controle do administrador causada pelo pacote de certificado
de registro particular
A criação/upgrade do cluster de administrador é interrompida no registro a seguir
para sempre e, por fim, expira:
Waiting for Machine gke-admin-master-xxxx to become ready...
O registro do controlador da API Cluster no
snapshot de cluster externo inclui o seguinte registro:
Invalid value 'XXXX' specified for property startup-data
Confira um exemplo de caminho de arquivo para o registro do controlador da API Cluster:
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
VMware has a 64k vApp property size limit. In the identified versions,
the data passed via vApp property is close to the limit. When the private
registry certificate contains a certificate bundle, it may cause the final
data to exceed the 64k limit.
Workaround:
Only include the required certificates in the private registry
certificate file configured in privateRegistry.caCertPath in
the admin cluster config file.
Or upgrade to a version with the fix when available.
|
Rede |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayNodes marcado como não íntegro devido a um
conflito de atualização de status simultâneo
Em networkgatewaygroups.status.nodes , alguns nós alternam entre
NotHealthy e Up .
Os registros do pod ang-daemon em execução nesse nó revelam
erros repetidos:
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
O status NotHealthy impede que o controlador
atribua outros IPs flutuantes ao nó. Isso pode resultar em mais
carga para outros nós ou falta de redundância para alta disponibilidade.
A atividade do plano de dados não será afetada.
A contenção no objeto networkgatewaygroup faz algumas
atualizações de status falharem devido a um erro no processamento de novas tentativas. Se muitas
atualizações de status falharem, ang-controller-manager vê o nó como
tendo passado do limite de tempo do sinal de funcionamento e marca esse nó como NotHealthy .
O erro no processamento de novas tentativas foi corrigido em versões mais recentes.
Alternativa:
Fazer upgrade para uma versão fixa, quando disponível.
|
Upgrades e atualizações |
1.12.0-1.12.2, 1.13.0 |
A disputa bloqueia a exclusão de objetos da máquina durante uma atualização ou
upgrade
Um problema conhecido que poderia fazer com que o upgrade ou a atualização do cluster ficassem
esperando para que o objeto da máquina antigo fosse excluído. Isso acontece porque
não é possível remover o finalizador do objeto da máquina. Isso afeta qualquer
operação de atualização gradual para pools de nós.
O sintoma é que o comando gkectl expira com a
seguinte mensagem de erro:
E0821 18:28:02.546121 61942 console.go:87] Exit with error:
E0821 18:28:02.546184 61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Nos registros de pod clusterapi-controller , os erros são
assim:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
O erro se repetirá na mesma máquina por vários minutos para
execuções bem-sucedidas, mesmo sem esse bug. Na maioria dos casos, ele pode passar
rapidamente, mas em alguns casos raros, ele poderá ficar preso nessa disputa por várias horas.
O problema é que a VM já foi excluída no vCenter, mas
o objeto da máquina correspondente não pode ser removido e fica preso na
remoção do finalizador devido a atualizações muito frequentes de outros controladores.
Isso pode fazer com que o comando gkectl atinja o tempo limite, mas o
controlador continua reconciliando o cluster para que o processo de upgrade ou atualização
seja concluído.
Alternativa:
Preparamos várias opções diferentes de mitigação para esse problema,
que depende do seu ambiente e dos seus requisitos.
Se você encontrar esse problema e o upgrade ou a atualização ainda não
forem concluídos após um longo período,
entre em contato
com nossa equipe de suporte para mitigação.
|
Instalação, upgrades e atualizações |
1.10.2, 1.11, 1.12, 1.13 |
Falha na simulação da validação da imagem do SO gkectl prepare
Falha no comando gkectl prepare com:
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
As verificações de simulação de gkectl prepare incluíram uma
validação incorreta.
Alternativa:
Execute o mesmo comando com uma flag adicional
--skip-validation-os-images .
|
Instalação |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
O URL do vCenter com prefixo https:// ou http://
pode causar falha na inicialização do cluster
Falha na criação do cluster de administrador com:
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
O URL é usado como parte de uma chave de Secret, que não
é compatível com "/" ou ":".
Alternativa:
Remova o prefixo https:// ou http:// do
campo vCenter.Address no yaml de configuração do cluster de
usuário ou no cluster de administrador.
|
Instalação, upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
gkectl prepare com falha em util.CheckFileExists
gkectl prepare pode gerar falhas com o stacktrace
a seguir:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...
O problema é que gkectl prepare criava o diretório de certificado de
registro particular com uma permissão incorreta.
Alternativa:
Para corrigir esse problema, execute os comandos a seguir na estação de trabalho
do administrador:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
Upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
gkectl repair admin-master e o upgrade de administrador retomável não
funcionam juntos
Após uma falha na tentativa de upgrade do cluster de administrador, não execute gkectl
repair admin-master . Isso pode causar falhas nas próximas tentativas de upgrade do administrador
com problemas como falha da alimentação mestre do administrador ou a
VM inacessível.
Alternativa:
Se você já encontrou esse cenário de falha,
entre em contato com o suporte.
|
Upgrades e atualizações |
1.10, 1.11 |
O upgrade do cluster de administrador retomado pode levar à ausência do modelo de VM do plano de controle do
administrador
Se a máquina do plano de controle do administrador não for recriada após uma tentativa de upgrade do cluster
de administrador retomado, o modelo de VM do plano de controle do administrador vai ser
excluído. O modelo de VM do plano de controle do administrador é o modelo mestre de
administração usado para recuperar a máquina do plano de controle com
gkectl
repair admin-master .
Alternativa:
O modelo de VM do plano de controle do administrador vai ser gerado novamente durante o próximo
upgrade de cluster de administrador.
|
Sistema operacional |
1.12, 1.13 |
O cgroup v2 pode afetar as cargas de trabalho
Na versão 1.12.0, o cgroup v2 (unificado) é ativado por padrão para
nós do Container Optimized OS (COS). Isso pode causar
instabilidade nas cargas de trabalho em um cluster do COS.
Alternativa:
Voltamos ao cgroup v1 (híbrido) na versão 1.12.1. Se você estiver
usando nós do COS, recomendamos fazer upgrade para a versão 1.12.1
assim que ela for lançada.
|
Identidade |
1.10, 1.11, 1.12, 1.13 |
Recurso personalizado ClientConfig
gkectl update reverte todas as alterações manuais
feitas para o recurso personalizado ClientConfig.
Alternativa:
É altamente recomendável que você faça backup do recurso ClientConfig após
cada alteração manual.
|
Instalação |
1.10, 1.11, 1.12, 1.13 |
Falha na validação de gkectl check-config : não é possível encontrar
partições de F5 BIG-IP
A validação falha porque não são encontradas partições de F5 BIG-IP, embora
elas existam.
Um problema com a API F5 BIG-IP pode causar falha na validação.
Alternativa:
Tente executar gkectl check-config novamente.
|
Instalação |
1.12 |
Falha na instalação do cluster de usuário devido ao problema de eleição do líder do
cert-manager/ca-injector
Pode haver uma falha na instalação devido a
cert-manager-cainjector no loop de falhas, quando o apiserver/etcd
está lento:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
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"
Alternativa:
Ver etapas de solução alternativa
Execute os comandos a seguir para atenuar o problema.
Primeiro reduza a escala vertical no monitoring-operator para não
reverter as alterações na implantação do cert-manager :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Edite a implantação cert-manager-cainjector para desativar
a eleição do líder, porque temos apenas uma réplica em execução. Ela não
é necessária para uma única réplica:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
O snippet YAML relevante para a implantação
cert-manager-cainjector será semelhante ao exemplo a seguir:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --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 USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Após cada upgrade, as alterações são revertidas. Siga as mesmas
etapas novamente para atenuar o problema até que isso seja corrigido em uma
versão futura.
|
Segurança, upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
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.
Se você iniciou o processo de upgrade e encontrou um erro com o
vencimento do certificado, entre em contato com o Suporte do Google para receber ajuda.
Observação: esta orientação é apenas para a renovação de certificados do cluster de administrador.
Alternativa:
Ver etapas de solução alternativa
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
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Como reiniciar ou fazer upgrade do vCenter em versões anteriores à 7.0U2
Se o vCenter, para versões anteriores à 7.0U2, for reiniciado, após um
upgrade ou de outra forma, o nome da rede nas informações da VM do vCenter estará
incorreto e resultará na máquina em um estado
Unavailable . Isso leva os nós a serem reparados automaticamente para criar
outros.
Bug govmomi
relacionado.
Alternativa:
Esta solução alternativa é fornecida pelo suporte da VMware:
- O problema foi corrigido na versão 7.0U2 e mais recentes do vCenter.
- Para versões anteriores, clique com o botão direito do mouse no host e selecione
Conexão > Desconectar. Em seguida, reconecte-se, o que força uma atualização
do grupo de portas da VM.
|
Sistema operacional |
1.10, 1.11, 1.12, 1.13 |
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 SO Ubuntu são reforçadas com o
CIS L1 Server Benchmark.
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.
Alternativa:
Você tem as seguintes opções:
Reconecte sua sessão SSH.
|
Instalação |
1.10, 1.11, 1.12, 1.13 |
Instalação conflitante do cert-manager
Nas versões 1.13, o monitoring-operator vai 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:
Basta aplicar essa solução uma vez para cada cluster, e as
alterações serão preservadas no upgrade do cluster.
Observação: um sintoma comum de instalação do gerenciador de certificados
é que a versão cert-manager ou a imagem (por exemplo,
v1.7.2) pode reverter para a versão anterior. Isso é causado por
monitoring-operator ao tentar reconciliar o
cert-manager e reverter a versão no processo.
Alternativa:
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 a versão do
cert-manager .
Restaure
os recursos personalizados se você os tiver.
- Pule esta etapa se você estiver usando a instalação do gerenciador de certificados padrão upstream 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
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 gerenciador de certificados para a 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 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 a versão do
cert-manager .
Restaure
os recursos personalizados se você os tiver.
- Pule esta etapa se você estiver usando a instalação do gerenciador de certificados padrão upstream 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
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
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
|
Sistema operacional |
1.10, 1.11, 1.12, 1.13 |
Falsos positivos na verificação de vulnerabilidades do Docker, containerd e runc
O Docker, o containerd e o runc nas imagens do SO 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ê terá falsos positivos nos resultados do Docker,
do containerd e de verificação de vulnerabilidade do runc.
Por exemplo, os falsos positivos a seguir podem ser exibidos nos resultados da verificação
da CVE. Essas CVEs já foram corrigidas nas versões mais recentes dos
patches dos clusters do Anthos no VMware.
Consulte as notas da versão
para conferir correções da CVE.
Alternativa:
A Canonical está ciente desse problema, e a correção é
rastreada em
https://github.com/canonical/sec-cvescan/issues/73.
|
Upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
A conexão de rede entre o cluster de administrador e de usuário pode ficar indisponível
por um curto período durante o upgrade de um cluster que não seja de alta disponibilidade
Se você estiver fazendo upgrade dos clusters que não são de alta disponibilidade da versão 1.9 para a 1.10, talvez
perceba que kubectl exec , kubectl log e o webhook
nos clusters de usuários podem ficar indisponíveis por um curto período. Essa inatividade
pode ser de até um minuto. Isso acontece porque a solicitação de entrada
(kubectl exec, kubectl log e webhook) é processada pelo kube-apiserver para o
cluster de usuário. O usuário kube-apiserver é um
Statefulset. Em um cluster que não seja de alta disponibilidade, há apenas
uma réplica para o Statefulset. Portanto, durante o upgrade, é possível que o kube-apiserver
antigo fique indisponível enquanto o novo kube-apiserver ainda não estiver
pronto.
Alternativa:
Esse tempo de inatividade ocorre apenas durante o processo de upgrade. Se você quiser uma
inatividade mais curta durante o upgrade, recomendamos que mude para
clusters de
alta disponibilidade.
|
Instalação, upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
Falha na verificação de prontidão conectividade no diagnóstico do cluster de alta disponibilidade após
a criação ou upgrade do cluster
Se você estiver criando ou fazendo upgrade de um cluster de alta disponibilidade e perceber que a verificação de prontidão
konnectivity falhou no diagnóstico do cluster, na maioria dos casos isso não
afetará a funcionalidade de clusters do Anthos no VMware (kubectl exec, kubectl
log e webhook). Isso acontece porque, às vezes, uma ou duas
réplicas de konnectivity podem ficar inativas por um período devido a
instabilidade da rede ou outros problemas.
Alternativa:
O konnectivity será recuperada por conta própria. Aguarde 30 minutos a uma hora
e execute novamente o diagnóstico do cluster.
|
Sistema operacional |
1.7, 1.8, 1.9, 1.10, 1.11 |
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 SO Ubuntu têm maior proteção com o
CIS L1 Server
Benchmark.
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 .
Alternativa:
Se os picos estiverem afetando sua carga de trabalho, desative o cron job diário:
sudo chmod -x /etc/cron.daily/aide
|
Rede |
1.10, 1.11, 1.12, 1.13 |
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 é 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.
Alternativa:
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.
|
Geração de registros e monitoramento |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
Faturamento inesperado de monitoramento
Para clusters do Anthos no VMware em versões 1.10 e mais recentes, alguns clientes encontraram
um faturamento alto inesperado para Metrics volume na
página Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:
- O monitoramento de aplicativos está ativado (
enableStackdriverForApplications=true )
- O serviço gerenciado para o Prometheus não está ativado (
enableGMPForApplications )
- Os pods do aplicativo têm a anotação
prometheus.io/scrap=true . A instalação do Anthos Service Mesh também pode adicionar essa anotação.
Para confirmar se você foi afetado por esse problema,
liste as métricas definidas pelo usuário. Se você vir faturamento para métricas indesejadas, esse problema se aplica a você.
Alternativa
Se você for afetado por esse problema, recomendamos que faça upgrade dos
clusters para a versão 1.12 e mude para a nova solução de monitoramento de aplicativos managed-service-for-prometheus que resolve esse problema:
Sinalizações separadas para controlar a coleta de registros do aplicativo em comparação com as métricas do aplicativo
Pacote de serviço gerenciado do Google Cloud Managed Service para Prometheus
Se não for possível fazer upgrade para a versão 1.12, siga estas etapas:
- Encontre os pods e os serviços de origem que têm as faturadas indesejadas.
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
- Remova a anotação
prometheus.io/scrap=true do pod ou do serviço. Se a anotação for adicionada pelo Anthos Service Mesh, considere configurar o Anthos Service Mesh sem a opção Prometheus ou desativar o recurso de mesclagem de métricas do Istio.
|
Instalação |
1.11, 1.12, 1.13 |
O instalador falha ao criar um disco de dados do vSphere
Os clusters do Anthos no instalador do VMware podem falhar se os papéis personalizados estiverem
vinculados no nível errado de permissões.
Quando a vinculação de papel está incorreta, a criação de um disco de dados do vSphere com
govc trava e o disco é criado com um tamanho igual a 0. Para
corrigir o problema, você precisa vincular o papel personalizado no
nível do vSphere vCenter (raiz).
Alternativa:
Se você quiser vincular o papel personalizado no nível do DC
(ou inferior à raiz), também é necessário vincular o papel
somente leitura ao usuário no nível raiz do vCenter.
Para mais informações sobre a criação de papéis, consulte
Privilégios de conta de usuário do vCenter.
|
Geração de registros e monitoramento |
1.9.0-1.9.4, 1.10.0-1.10.1 |
Tráfego de rede alto para monitoring.googleapis.com
É possível que você veja um tráfego de rede alto para
monitoring.googleapis.com , mesmo em um novo cluster que não tenha
cargas de trabalho de usuários.
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.
Alternativa:
Ver etapas de solução alternativa
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 a escala 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 set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
Geração de registros e monitoramento |
1.10, 1.11 |
gke-metrics-agent tem erros CrashLoopBackOff frequentes
Para clusters do Anthos no VMware versão 1.10 e mais recentes, o DaemonSet "gke-metrics-agent"
tem erros CrashLoopBackOff frequentes quando
"enableStackdriverForApplications" é definido como "true" no objeto
"stackdriver".
Alternativa:
Para minimizar esse problema, desative a coleta de métricas do aplicativo executando os comandos a seguir. Esses comandos não desativam a coleta de registros de aplicativos.
- 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
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
- Em
services.pipelines , comente a seção metrics/app-metrics inteira:
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Fechar a sessão de edição.
- Reinicie o
gke-metrics-agent DaemonSet:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
Geração de registros e monitoramento |
1.11, 1.12, 1.13 |
Substituir métricas com uso suspenso no painel
Se as métricas descontinuadas forem usadas nos painéis de OOTB, alguns gráficos vazios serão exibidos. Para encontrar métricas descontinuadas nos painéis do Monitoring, execute os seguintes comandos:
gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E \
'kube_daemonset_updated_number_scheduled\
|kube_node_status_allocatable_cpu_cores\
|kube_node_status_allocatable_pods\
|kube_node_status_capacity_cpu_cores'
As métricas descontinuadas a seguir precisam ser migradas para as substituições.
Suspenso | Substituição |
kube_daemonset_updated_number_scheduled |
kube_daemonset_status_updated_number_scheduled |
kube_node_status_allocatable_cpu_cores
kube_node_status_allocatable_memory_bytes
kube_node_status_allocatable_pods |
kube_node_status_allocatable |
kube_node_status_capacity_cpu_cores
kube_node_status_capacity_memory_bytes
kube_node_status_capacity_pods |
kube_node_status_capacity |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Alternativa:
Para substituir as métricas descontinuadas:
- Exclua o "Status do nó do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale o "Status do nó do GKE On-Prem" seguindo estas instruções.
- Exclua "Utilização do nó do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale a "Utilização de nós do GKE On-Prem" seguindo estas instruções.
- Exclua "Integridade de VM do vSphere do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale "Integridade de VM do vSphere do GKE On-Prem" seguindo estas instruções.
Essa descontinuação ocorre devido ao upgrade do agente kube-state-metrics da v1.9 para a v2.4, que é necessário para o Kubernetes 1.22. É possível substituir todas as métricas kube-state-metrics descontinuadas, que têm o prefixo kube_ , nos painéis personalizados ou nas políticas de alertas.
|
Geração de registros e monitoramento |
1.10, 1.11, 1.12, 1.13 |
Dados de métrica desconhecidos no Cloud Monitoring
Para clusters do Anthos no VMware versão 1.10 e posterior, os dados de clusters no Cloud Monitoring podem conter
entradas de métricas de resumo irrelevantes, como o seguinte:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Outros tipos de métricas que podem ter métricas de resumo irrelevantes incluem: :
apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary
Embora essas métricas de tipo de resumo estejam na lista de métricas, elas não são compatíveis com gke-metrics-agent no momento.
|
Geração de registros e monitoramento |
1.10, 1.11, 1.12, 1.13 |
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
Alternativa:
Para corrigir esse problema, siga as seguintes etapas como uma solução alternativa. Para
[versão 1.9.5+, 1.10.2+, 1.11.0]: aumente a CPU do gke-metrics-agent seguindo as etapas de 1 a 4
- 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 , o limite de CPU de 100m
para 200m adiciona a seção resourceAttrOverride
a seguir ao manifesto stackdriver :
spec:
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 100m
memory: 4608Mi
requests:
cpu: 10m
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: 200m
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.
|
Geração de registros e monitoramento |
1.11.0-1.11.2, 1.12.0 |
Não há métricas do programador e do gerenciador de controladores no cluster de administrador
Se o cluster de administrador for afetado por esse problema, as métricas do programador e do gerenciador de controladores estão ausentes. Por exemplo, essas duas métricas estão ausentes
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Alternativa:
Faça upgrade para a v1.11.3+, v1.12.1+ ou v1.13+.
|
|
1.11.0-1.11.2, 1.12.0 |
Não há métricas do programador e do gerenciador de controladores no cluster de usuário
Se o cluster de usuário for afetado por esse problema, as métricas do programador e do gerenciador de controladores estão ausentes. Por exemplo, essas duas métricas estão ausentes:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Alternativa:
Esse problema foi corrigido nos clusters do Anthos no VMware versão 1.13.0 e posteriores.
Faça upgrade do cluster para uma versão com a correção.
|
Instalação, upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
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: ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
Você ainda vai poder usar esse cluster de administrador, mas receberá 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: ""
Alternativa:
Ver etapas de solução alternativa
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.
- Execute
gkectl update admin para registrar o cluster de administrador com a chave de conta de serviço correta.
- Crie uma conta de serviço dedicada para corrigir o recurso personalizado
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig
do cluster de administrador.
- Execute estes comandos para atualizar o recurso personalizado
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
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}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Tente fazer upgrade do cluster de administrador novamente com a flag
--disable-upgrade-from-checkpoint .
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Substitua ADMIN_CLUSTER_CONFIG pelo caminho do arquivo de configuração do
cluster de administrador.
|
Identidade |
1.10, 1.11, 1.12, 1.13 |
Usar o Anthos Identity Service pode fazer com que o agente do Connect seja reiniciado de maneira imprevisível
Se você estiver usando o atributo
Anthos Identity Service
para gerenciar o
ClientConfig do Anthos Identity Service, o
agente do Connect poderá ser reiniciado inesperadamente.
Alternativa:
Se você tiver esse problema com um cluster existente, siga um destes procedimentos:
|
Rede |
1.10, 1.11, 1.12, 1.13 |
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.
Alternativa:
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.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Problemas da atualização 3 do vSphere 7.0
A VMWare identificou recentemente problemas críticos nas seguintes versões da atualização 3 do vSphere 7.0:
- Atualização 3 do vSphere ESXi 7.0 (versão 18644231)
- Atualização 3a do vSphere ESXi 7.0 (versão 18825058)
- Atualização 3b do vSphere ESXi 7.0 (versão 18905247)
- Atualização 3b do vSphere vCenter 7.0 (versão 18901211)
Alternativa:
A VMWare removeu essas versões. Faça upgrade dos servidores de ESXi e vCenter para uma versão mais recente.
|
Sistema operacional |
1.10, 1.11, 1.12, 1.13 |
Falha ao montar o volume emptyDir como exec no pod em execução nos nós do COS
Para pods em execução em nós que usam imagens do Container-Optimized OS (COS), não é possível montar o volume emptyDir como exec . Ele é montado como noexec , e você receberá este erro: exec user
process caused: permission denied . Por exemplo, você receberá essa mensagem de erro se implantar o pod de teste a seguir:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: test
name: test
spec:
containers:
- args:
- sleep
- "5000"
image: gcr.io/google-containers/busybox:latest
name: test
volumeMounts:
- name: test-volume
mountPath: /test-volume
resources:
limits:
cpu: 200m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- emptyDir: {}
name: test-volume
No pod de teste, se você executar mount | grep test-volume , ele vai mostrar a opção noexec:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Alternativa:
Ver etapas de solução alternativa
Aplique um recurso de DaemonSet, por exemplo:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Upgrades e atualizações |
1.10, 1.11, 1.12, 1.13 |
A atualização da réplica do pool de nós de clusters não funciona depois que o escalonamento automático é desativado no pool de nós
As réplicas do pool de nós não são atualizadas depois que o escalonamento automático é ativado e desativado em um pool de nós.
Alternativa:
Remoção das anotações cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size da implantação da máquina do pool de nós correspondente.
|
Geração de registros e monitoramento |
1.11, 1.12, 1.13 |
Os painéis de monitoramento do Windows mostram dados de clusters do Linux
A partir da versão 1.11, nos painéis de monitoramento prontos para uso, o
painel de status do pod do Windows e o painel de status do nó do Windows também mostram
dados de clusters do Linux. Isso porque as métricas de nós e pods do Windows também
são expostas nos clusters do Linux.
|
Geração de registros e monitoramento |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder na constante CrashLoopBackOff
Para clusters do Anthos na VMware versão 1.10, 1.11 e 1.12, stackdriver-log-forwarder
o DaemonSet pode ter erros CrashLoopBackOff quando há
registros armazenados em buffer corrompidos no disco.
Alternativa:
Para atenuar esse problema, precisaremos limpar os registros armazenados em buffer
no nó.
- Para evitar esse comportamento inesperado, reduza a escala vertical de
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.
- Implante o DaemonSet de limpeza para limpar os blocos corrompidos:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -f - << EOF
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
EOF
- Para garantir que o DaemonSet de limpeza limpou todos os blocos,
execute os seguintes comandos. A saída dos dois comandos precisa ser igual ao número do nó no cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Exclua o DaemonSet de limpeza:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Retome
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
|
Geração de registros e monitoramento |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
stackdriver-log-forwarder não envia registros para o Cloud Logging
Se você não vir registros no Cloud Logging dos seus clusters e notar o seguinte erro nos registros:
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
É provável que a taxa de entrada de registros exceda o limite do agente do Logging, fazendo com que stackdriver-log-forwarder não envie registros.
Esse problema ocorre em todos os clusters do Anthos nas versões do VMware.
Alternativa:
Para atenuar esse problema, é preciso aumentar o limite de recursos no agente do Logging.
- 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 para
stackdriver-log-forwarder , adicione a seguinte seção resourceAttrOverride ao manifesto stackdriver :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
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:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
- 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 stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
O comando encontrará cpu: 1200m se as edições tiverem entrado em vigor.
|
Segurança |
1.13 |
O serviço do Kubelet ficará temporariamente indisponível após o NodeReady
há um curto período em que o nó está pronto, mas o certificado do servidor do kubelet não está. kubectl exec e kubectl logs ficam indisponíveis durante esse período.
Isso ocorre porque leva tempo para o novo aprovador de certificado do servidor ver os IPs válidos atualizados do nó.
Esse problema afeta apenas o certificado do servidor kubelet. Ele não afeta a
programação do pod.
|
Upgrades e atualizações |
1.12 |
O upgrade parcial do cluster de administrador não bloqueia o upgrade posterior do cluster de usuário
Falha no upgrade do cluster de usuário com:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
O cluster de administrador não recebeu upgrade completo, e a versão do status ainda é 1.10. O upgrade do cluster de usuário para 1.12 não será bloqueado por nenhuma verificação de simulação e falha com o problema de desvio de versão.
Alternativa:
Conclua o upgrade do cluster de administrador para a versão 1.11 e depois atualize o cluster de usuário para a 1.12.
|
Armazenamento |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
O Datastore informa incorretamente que há espaço livre insuficiente
Falha no comando gkectl diagnose cluster com:
Checking VSphere Datastore FreeSpace...FAILURE
Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
A validação do espaço livre do repositório de dados não pode ser usada para pools de nós de clusters atuais e foi adicionada em gkectl diagnose cluster por engano.
Alternativa:
É possível ignorar a mensagem de erro ou pular a validação usando --skip-validation-infra .
|
Operação, rede |
1.11, 1.12.0-1.12.1 |
Talvez não seja possível adicionar um novo cluster de usuário se o cluster de administrador estiver definido com uma configuração do balanceador de carga MetalLB.
O processo de exclusão do cluster de usuário pode ficar travado por algum motivo, o que resulta em uma invalidação do ConfigMap MetalLB. Não será possível adicionar um novo cluster de usuário nesse estado.
Alternativa:
É possível forçar a exclusão do cluster de usuário.
|
Instalação, sistema operacional |
1.10, 1.11, 1.12, 1.13 |
Falha ao usar o Container-Optimized OS (COS) no cluster de usuário
Se osImageType estiver usando cos para o cluster de administrador, quando gkectl check-config for executado após a criação do cluster de administrador e antes da criação do cluster de usuário, ocorrerá uma falha:
Failed to create the test VMs: VM failed to get IP addresses on the network.
Por padrão, a VM de teste criada para o cluster de usuário check-config usa o mesmo osImageType do cluster de administrador. No momento, a VM de teste ainda não é compatível com o COS.
Alternativa:
Para evitar a verificação lenta de simulação, que cria a VM de teste, usando gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast .
|
Geração de registros e monitoramento |
1.12.0-1.12.1 |
O Grafana no cluster de administrador não consegue alcançar os clusters de usuário
Esse problema afeta os clientes que usam o Grafana no cluster de administrador para monitorar os clusters de usuário nos clusters do Anthos no VMware 1.12.0 e 1.12.1. Ele é originado de uma incompatibilidade de certificados pushprox-client em clusters de usuário e a lista de permissões no pushprox-server no cluster de administrador.
O sintoma é o pushprox-client em registros de erro de impressão de clusters de usuários, como o seguinte:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Alternativa:
Ver etapas de solução alternativa
Siga as etapas abaixo:
- Reduza a implantação do monitoring-operator no namespace kube-system do cluster de administrador.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Edite o ConfigMap
pushprox-server-rbac-proxy-config no namespace kube-system do cluster de administrador.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Localize a linha principals para o listener external-pushprox-server-auth-proxy e corrija a principal_name para todos os clusters de usuário removendo a substring kube-system de pushprox-client.metrics-consumers.kube-system.cluster. .
A nova configuração terá esta aparência:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Reinicie a implantação
pushprox-server no cluster de administrador e a implantação pushprox-client nos clusters de usuário afetados:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- As etapas anteriores devem resolver o problema. Depois que o cluster for atualizado para a versão 1.12.2 e posteriores, quando o problema for corrigido, escalone verticalmente o monitoring-operator do kube-system de cluster de administrador para que ele possa gerenciar o pipeline novamente.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
Outro |
1.11.3 |
gkectl repair admin-master não fornece o modelo de VM a ser usado para recuperação
Falha no comando gkectl repair admin-master com:
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
gkectl repair admin-master não poderá buscar o modelo de VM a ser usado para
reparar a VM do plano de controle do administrador se o nome da VM do plano de controle do administrador
terminar com os caracteres t , m , p ou l .
Alternativa:
Execute o comando novamente com --skip-validation .
|
Geração de registros e monitoramento |
1.11, 1.12, 1.13, 1.14, 1.15 |
Falha nos Registros de auditoria do Cloud devido à permissão negada
Os Registros de auditoria do Cloud do Anthos precisam de uma configuração de permissão especial que,
no momento, é executada automaticamente apenas para clusters de usuários pelo GKE Hub.
Recomendamos que haja pelo menos um cluster de usuário que use o mesmo
ID do projeto e conta de serviço com o cluster de administrador para os Registros de auditoria do Cloud, assim o cluster de administrador terá a permissão necessária para os
Registros de auditoria do Cloud.
No entanto, nos casos em que o cluster de administrador usa IDs de projeto ou
contas de serviço diferentes com qualquer cluster de usuário, os registros de auditoria do cluster de administrador
não seriam injetados na nuvem. O sintoma é uma série
de erros Permission Denied no pod audit-proxy
no cluster de administrador.
Alternativa:
Ver etapas de solução alternativa
Para resolver esse problema, interaja com o atributo do cloudauditlogging Hub para configurar
a permissão:
- Primeiro, verifique as contas de serviço incluídas na lista de permissões dos Registros de auditoria do Cloud
do Anthos para seu projeto:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- Dependendo da resposta, escolha uma das seguintes opções:
- Se você recebeu um erro
404 Not_found , isso significa que
não há uma conta de serviço na lista de permissões para esse ID de projeto. É possível
colocar uma conta de serviço na lista de permissões ativando o
atributo do cloudauditlogging Hub:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Se você recebeu uma especificação de atributos que contém
"lifecycleState": "ENABLED" com "code":
"OK" e uma lista de contas de serviço em
allowlistedServiceAccounts , isso significa que já existem
contas de serviço permitidas para este projeto. É possível usar uma
conta de serviço desta lista no seu cluster ou adicionar uma nova conta de serviço à lista de permissões:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Se você recebeu uma especificação de atributos que contém
"lifecycleState": "ENABLED" com "code":
"FAILED" , a configuração de permissão não foi bem-sucedida.
Resolva os problemas no campo description
da resposta ou faça backup da lista de permissões atual, exclua o
atributo do hub cloudauditlogging e reative-o seguindo a etapa 1
desta seção. Para excluir o atributo do Hub cloudauditlogging ,
faça o seguinte:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
Nos comandos acima:
|
Operação, segurança |
1.11 |
Falha de certificados de verificação de gkectl diagnose
Se a estação de trabalho não tiver acesso aos nós de trabalho do cluster de usuário,
ela vai receber as seguintes falhas ao executar
gkectl diagnose :
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
Se a estação de trabalho não tiver acesso aos nós de trabalho do cluster de administrador
ou aos nós de trabalho do cluster de usuário, ela receberá as seguintes falhas ao
executar gkectl diagnose :
Checking admin cluster certificates...FAILURE
Reason: 3 admin 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
Alternativa:
Se for seguro ignorar essas mensagens.
|
Sistema operacional |
1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
/var/log/audit/ ocupando espaço em disco na estação de trabalho
do administrador
O /var/log/audit/ está repleto de registros de auditoria. Verifique
o uso do disco executando sudo du -h -d 1 /var/log/audit .
Certos comandos gkectl na estação de trabalho do administrador, por exemplo, gkectl diagnose snapshot contribuem para o uso
do espaço em disco.
Desde o Anthos v1.8, a imagem do Ubuntu é reforçada com o CIS Level 2
Benchmark. E uma das regras de compliance, "4.1.2.2 Garanta que os registros de auditoria não sejam
excluídos automaticamente", garante a configuração auditada
max_log_file_action = keep_logs . Isso resulta em todas as
regras de auditoria mantidas no disco.
Alternativa:
Ver etapas de solução 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 de cluster
Para nós de cluster, faça upgrade para 1.11.5+, 1.12.4+, 1.13.2+ ou 1.14+. Se
ainda não for possível fazer upgrade para essas versões, aplique o DaemonSet a seguir ao cluster:
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: /
Esta alteração da configuração auditada viola a regra do nível 2
do CIS "4.1.2.2. Garanta que os registros de auditoria não sejam excluídos automaticamente".
|
Rede |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
O IP flutuante do NetworkGatewayGroup entra em conflito com o endereço do
nó
Os usuários não podem criar ou atualizar objetos NetworkGatewayGroup
devido ao seguinte erro de webhook de validação:
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
Nas versões afetadas, o kubelet pode se vincular por engano a um endereço IP flutuante atribuído ao nó e informá-lo como um endereço de nó em
node.status.addresses . O webhook de validação verifica
endereços IP flutuantes NetworkGatewayGroup em todos os
node.status.addresses no cluster e vê isso como um
conflito.
Alternativa:
No mesmo cluster em que a criação ou a atualização de
objetos NetworkGatewayGroup está falhando, desative temporariamente
o webhook de validação do ANG e envie sua alteração:
- Salve a configuração do webhook para que ela possa ser restaurada no final:
kubectl -n kube-system get validatingwebhookconfiguration \
ang-validating-webhook-configuration -o yaml > webhook-config.yaml
- Edite a configuração do webhook:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Remova o item
vnetworkgatewaygroup.kb.io da
lista de configuração do webhook e feche para aplicar as alterações.
- Crie ou edite o objeto
NetworkGatewayGroup .
- Aplique novamente a configuração original do webhook:
kubectl -n kube-system apply -f webhook-config.yaml
|
Instalação, upgrades e atualizações |
1.10.0-1.10.2 |
Como criar ou fazer upgrade do tempo limite do cluster de administrador
Durante uma tentativa de upgrade do cluster de administrador, a VM do plano de controle do administrador
pode ficar travada durante a criação. A VM do plano de controle do administrador entra em um
loop de espera infinita durante a inicialização, e você receberá o seguinte
erro de loop infinito no arquivo
/var/log/cloud-init-output.log :
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1
Isso ocorre porque, quando os clusters do Anthos no VMware tentam acessar o endereço IP do nó no script de inicialização, ele usa grep -v
ADMIN_CONTROL_PLANE_VIP para pular o VIP do plano de controle do
cluster de administrador que também pode ser atribuído à NIC. Porém, o comando também pula
qualquer endereço IP que tenha um prefixo do VIP do plano de controle, o que faz com que
o script de inicialização trave.
Por exemplo, suponha que o VIP do plano de controle do cluster de administrador seja
192.168.1.25. Se o endereço IP da VM do plano de controle do cluster de administrador tiver
o mesmo prefixo, por exemplo,192.168.1.254, a VM do plano de controle vai
ficar travada durante a criação. Esse problema também pode ocorrer se o
endereço de transmissão tiver o mesmo prefixo que o VIP do plano de controle, por
exemplo, 192.168.1.255 .
Alternativa:
|
Sistema operacional, upgrades e atualizações |
1.10.0-1.10.2 |
O estado do cluster de administrador que usa a imagem do COS será perdido após
o upgrade do cluster de administrador ou o reparo mestre do administrador
Não é possível montar o DataDisk corretamente no nó mestre do cluster de administrador ao
usar a imagem do COS. Além disso, o estado do cluster de administrador que usa a imagem do COS será
perdido após o upgrade do cluster de administrador ou reparo mestre do administrador. O cluster de administrador
que usa a imagem do COS é um recurso em fase de pré-lançamento.
Alternativa:
Recriar cluster de administrador com osImageTypeType definido como ubuntu_containerd
Depois de criar o cluster de administrador com osImageType definido como cos, use
a chave SSH do cluster de administrador e o SSH no nó mestre do administrador.
O resultado de df -h contém /dev/sdb1 98G 209M 93G
1% /opt/data . E o resultado de lsblk contém -sdb1
8:17 0 100G 0 part /opt/data .
|
Sistema operacional |
1.10 |
Busca de DNS com falha resolvida pelo systemd em domínios .local
Nos clusters do Anthos na versão 1.10.0 do VMware, as resoluções de nome no Ubuntu
são roteadas para detecção local resolvida pelo systemd em 127.0.0.53
por padrão. O motivo é que, na imagem do Ubuntu 20.04 usada na versão
1.10.0, /etc/resolv.conf tem um link simbólico para
/run/systemd/resolve/stub-resolv.conf , que aponta para o
stub de DNS 127.0.0.53 do localhost.
Como resultado, a resolução de nome DNS do localhost se recusa a verificar os
servidores DNS upstream (especificados em
/run/systemd/resolve/resolv.conf ) para nomes com um
sufixo .local , a menos que os nomes sejam especificados como
domínios de pesquisa.
Isso causa falhas nas pesquisas de nomes de .local . Por
exemplo, durante a inicialização do nó, o kubelet falha ao extrair imagens
de um registro particular com um sufixo .local . A especificação de um
endereço do vCenter com um sufixo .local não funcionará em uma
estação de trabalho de administrador.
Alternativa:
Para evitar esse problema em nós de cluster, especifique o
campo searchDomainsForDNS no arquivo de configuração do cluster de administrador e o arquivo de configuração do cluster de usuário para incluir os domínios.
No momento, o gkectl update ainda não é compatível com a
atualização do campo searchDomainsForDNS .
Portanto, se você não tiver configurado esse campo antes da criação do cluster,
precisará usar o SSH nos nós e ignorar o stub local resolvido pelo systemd
alterando o link simbólico de /etc/resolv.conf de
/run/systemd/resolve/stub-resolv.conf (que contém o
stub local de 127.0.0.53 ) para
/run/systemd/resolve/resolv.conf (que aponta para o DNS
upstream real):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Como na estação de trabalho de administrador, o gkeadm não é compatível
com a especificação de domínios de pesquisa. Por isso, é necessário contornar esse problema nesta etapa manual.
Esta solução não permanece nas recriações de VM. Aplique
a solução novamente sempre que as VMs forem recriadas.
|
Instalação, sistema operacional |
1.10 |
O IP da ponte do Docker usa 172.17.0.1/16 em vez de
169.254.123.1/24
Os clusters do Anthos no VMware especificam uma sub-rede dedicada para o endereço IP
da ponte do Docker que usa --bip=169.254.123.1/24 , para que
ela não reserve a sub-rede 172.17.0.1/16 padrão. No entanto,
na versão 1.10.0, um bug na imagem do SO Ubuntu fez com que a
configuração personalizada do Docker fosse ignorada.
Como resultado, o Docker escolhe o 172.17.0.1/16 padrão como a
sub-rede de endereço IP da ponte. Isso poderá causar um conflito de endereços IP se a
carga de trabalho já estiver em execução nesse intervalo de endereços IP.
Alternativa:
Para contornar esse problema, você precisa renomear o seguinte arquivo de configuração systemd do dockerd e reiniciar o serviço:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Verifique se o Docker escolhe o endereço IP da ponte correto:
ip a | grep docker0
Esta solução não permanece nas recriações de VM. Aplique
a solução novamente sempre que as VMs forem recriadas.
|
Upgrades e atualizações |
1.11 |
Upgrade para a versão 1.11 bloqueada pela prontidão do Stackdriver
Nos clusters do Anthos na VMware versão 1.11.0, há alterações na definição de recursos personalizados relacionados a geração de registros e monitoramento:
- O nome do grupo do recurso personalizado
stackdriver foi alterado de addons.sigs.k8s.io para addons.gke.io .
- O nome do grupo dos recursos personalizados
monitoring e metricsserver foi alterado de addons.k8s.io para addons.gke.io .
- As especificações dos recursos acima começam a ser validadas em relação ao esquema. Em particular, as especificações resourceAttrOverride e storageSizeOverride no recurso personalizado
stackdriver precisam ter um tipo de string nos valores das solicitações e limites de CPU, memória e tamanho de armazenamento.
As mudanças no nome do grupo foram feitas para obedecer às atualizações da CustomResourceDefinition no Kubernetes 1.22.
Nenhuma ação será necessária caso você não tenha outra lógica que aplique ou edite os recursos personalizados afetados. O processo de upgrade dos clusters do Anthos no VMware cuida da migração dos recursos afetados e mantém as especificações atuais após a mudança do nome do grupo.
No entanto, se você executar qualquer lógica que aplique ou edite os recursos afetados, será necessário atenção especial. Primeiro, eles precisam estar referenciados com o novo nome de grupo no arquivo de manifesto. Exemplo:
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
Depois, verifique se os valores de especificação resourceAttrOverride e storageSizeOverride são do tipo string. Exemplo:
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder
limits:
cpu: 1000m # or "1"
# cpu: 1 # integer value like this would not work
memory: 3000Mi
Caso contrário, as aplicações e edições não terão efeito e poderão levar a um status inesperado nos componentes de registro e monitoramento. Os possíveis sintomas podem incluir:
- Registros de erros de reconciliação em
onprem-user-cluster-controller , por exemplo:
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
- Falha em
kubectl edit stackdriver stackdriver , por exemplo:
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Se você encontrar os erros acima, isso significa que um tipo incompatível na especificação da CR do Stackdriver já estava presente antes do upgrade. Como solução alternativa, é possível editar manualmente a resposta automática do Stackdriver com o nome antigo do grupo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e fazer o seguinte:
- Alterar as solicitações e os limites dos recursos para o tipo de string;
- Remova qualquer anotação
addons.gke.io/migrated-and-deprecated: true , se houver.
Em seguida, retome ou reinicie o processo de upgrade.
|
Sistema operacional |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
As VMs do COS não mostram IPs quando são movidas por desligamento irregular do host
Sempre que houver uma falha em um servidor ESXi e a função de alta disponibilidade do vCenter estiver ativada no servidor, todas as VMs no servidor ESXi com falha acionarão o mecanismo vMotion e serão movidas para outro servidor ESXi normal. As VMs do COS migradas perderiam os IPs.
Alternativa:
Reinicialize a VM
|