Nas seções a seguir, descrevemos os problemas que podem ser encontrados ao usar o GKE On-Prem e como resolvê-los.
Antes de começar
Verifique as seções a seguir antes de começar a resolver um problema.
Como diagnosticar problemas de cluster usando gkectl
Use os comandos gkectl diagnose
para identificar problemas de cluster
e compartilhar informações do cluster com o Google. Consulte
Como diagnosticar problemas de cluster.
Comportamento de geração de registros padrão
Para gkectl
e gkeadm
, basta usar as configurações de
geração de registros padrão:
-
Por padrão, as entradas de registro são salvas da seguinte maneira:
-
Para
gkectl
, o arquivo de registros padrão é/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
e está vinculado ao arquivologs/gkectl-$(date).log
no diretório local em que você executagkectl
. -
Para
gkeadm
, o arquivo de registros padrão élogs/gkeadm-$(date).log
no diretório local em que você executagkeadm
.
-
Para
- Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam
impressas no terminal (quando
--alsologtostderr
éfalse
). - O nível de detalhamento
-v5
(padrão) abrange todas as entradas de registro exigidas pela equipe de suporte. - O arquivo de registros também contém o comando executado e a mensagem de erro.
Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.
Como especificar um local não padrão para o arquivo de registros
Se quiser especificar um local não padrão para o arquivo de registros gkectl
, use
a sinalização --log_file
. O arquivo de registro que você especificar não
será vinculado ao diretório local.
Se quiser especificar um local não padrão para o arquivo de registros gkeadm
, use
a sinalização --log_file
.
Como localizar registros da API Cluster no cluster de administrador
Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:
Encontre o nome do pod de controladores da API Cluster no namespace
kube-system
, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use
grep
ou uma ferramenta semelhante para pesquisar erros:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Instalação
Como depurar problemas de F5 BIG-IP com o kubeconfig do nó do plano de controle do cluster de administrador
Após uma instalação, o GKE On-Prem gera um arquivo kubeconfig no diretório inicial da estação de trabalho do administrador denominado internal-cluster-kubeconfig-debug
. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, com a diferença de que ele aponta diretamente para o nó do plano de controle do cluster de administrador, em que o plano de controle de administrador é executado. É possível usar o arquivo internal-cluster-kubeconfig-debug
para depurar problemas de F5 BIG-IP.
Falha na validação de gkectl check-config
: não é possível encontrar partições de F5 BIG-IP
- Sintomas
A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.
- Causas possíveis
Um problema com a API F5 BIG-IP pode causar falha na validação.
- Resolução
Tente executar
gkectl check-config
novamente.
Falha em gkectl prepare --validate-attestations
: não foi possível validar o atestado de versão
- Sintomas
Executar
gkectl prepare
com a sinalização--validate-attestations
opcional retorna o seguinte erro:could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causas possíveis
Um atestado pode não existir para as imagens afetadas.
- Resolução
Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme instruído em Como criar uma estação de trabalho de administrador. Se o problema persistir, entre em contato com o Google para receber ajuda.
Como depurar usando os registros do cluster de inicialização
Durante a instalação, o GKE On-Prem cria um cluster temporário de inicialização. Após uma instalação bem-sucedida, o GKE On-Prem exclui o cluster de inicialização, deixando você com o cluster de administrador e de usuário. Geralmente, não há motivo para interagir com esse cluster.
Se algo der errado durante uma instalação e você tiver transmitido
--cleanup-external-cluster=false
para gkectl create cluster
,
talvez seja útil realizar a depuração usando os registros do cluster de inicialização. Encontre
o pod e receba os registros dele:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Plug-in de autenticação para Anthos
Como manter a CLI gcloud anthos auth
atualizada
Muitos problemas comuns podem ser evitados verificando se os componentes da instalação do gcloud anthos auth
estão atualizados com as correções da versão mais recente.
Há duas partes que precisam ser verificadas, porque o comando gcloud anthos auth
tem lógica no componente principal gcloud
e um componente anthos-auth
empacotado separadamente.
-
O componente principal
gcloud
.-
Para atualizar o componente principal
gcloud
, faça o seguinte:gcloud components update
-
Verifique se a instalação do
gcloud
está desatualizada executando o seguinte comando e verificando se a data impressa nos últimos 12 dias.gcloud version
-
-
anthos-auth
O componente .-
Para atualizar o componente
anthos-auth
, execute:gcloud components install anthos-auth
-
Verifique se a instalação do
anthos-auth
não está desatualizada executando o seguinte comando e verificando se a versão é v1.1.3 ou posterior.gcloud anthos auth version
-
apt-get
Instalações de gcloud
Para verificar se a instalação do gcloud
é gerenciada por apt-get
, execute o comando gcloud
components update
e verifique o seguinte erro:
$ gcloud components update ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: ...
Problema: não é possível realizar esta ação porque o gerenciador de componentes da CLI gcloud está desativado para esta instalação:
No caso de instalações gerenciadas por meio do apt-get
, a execução dos comandos gcloud components
acima não funcionará diretamente e resultará em uma mensagem de erro semelhante à reproduzida acima. No entanto, a execução dos comandos gcloud components update
e gcloud components install anthos-auth
imprimirá os comandos apt-get
específicos que podem ser executados para atualizar a instalação.
Falha ao executar gkectl create-login-config
Problema 1:
- Sintomas
Ao executar
gkectl create-login-config
, você encontra o seguinte erro:Error getting clientconfig using [user_cluster_kubeconfig]
- Causas possíveis
Esse erro significa que o arquivo kubeconfig transmitido para
gkectl create-login-config
não serve para um cluster de usuário ou que o CRD ClientConfig não foi acionado durante a criação do cluster.- Resolução
Execute o seguinte comando para ver se o CRD ClientConfig está no cluster:
kubectl --kubeconfig [user_cluster_kubeconfig] get clientconfig default -n kube-public
Problema 2:
- Sintomas
Ao executar
gkectl create-login-config
, você encontra o seguinte erro:error merging with file [merge_file] because [merge_file] contains a cluster with the same name as the one read from [kubeconfig]. Please write to a new output file
- Causas possíveis
Cada arquivo de configuração de login precisa conter nomes exclusivos de cluster. Se você vir esse erro, o arquivo em que estiver gravando os dados de configuração de login conterá um nome de cluster que já existe no arquivo de destino.
- Resolução
Grave em um novo arquivo
--output
. Observe o seguinte:- Se
--output
não for fornecido, os dados de configuração de login serão gravados em um arquivo chamadokubectl-anthos-config.yaml
no diretório atual por padrão. - Se
--output
já existir, o comando tentará mesclar a nova configuração de login com o--output
.
- Se
Falha ao executar gcloud anthos auth
login
Problema 1:
- Sintomas
Falha ao executar
login
usando o plug-in de autenticação e o arquivo YAML gerado de configuração de login.- Causas possíveis
Pode haver um erro nos detalhes de configuração do OIDC.
- Resolução
Verifique o registro do cliente OIDC com o administrador.
Problema 2:
- Sintomas
Quando um proxy é configurado para tráfego HTTPS, a execução do comando
gcloud anthos auth login
falha comproxyconnect tcp
na mensagem de erro. Um exemplo do tipo de mensagem que pode ser exibida éproxyconnect tcp: tls: first record does not look like a TLS handshake
.- Causas possíveis
Pode haver um erro nas configurações da variável de ambiente
https_proxy
ouHTTPS_PROXY
. Se houver umhttps://
especificado nas variáveis de ambiente, as bibliotecas de cliente HTTP do GoLang poderão falhar se o proxy estiver configurado para processar conexões HTTPS usando outros protocolos, como SOCK5.- Resolução
Modifique as variáveis de ambiente
https_proxy
eHTTPS_PROXY
para omitir o prefixohttps://
. No Windows, modifique as variáveis de ambiente do sistema. Por exemplo, altere o valor da variável de ambientehttps_proxy
dehttps://webproxy.example.com:8000
parawebproxy.example.com:8000
.
Falha ao usar o kubeconfig gerado por
gcloud anthos auth login
para acessar o cluster
- Sintomas
Erro "Não autorizado"
Se houver um erro "Não autorizado" ao usar o kubeconfig gerado por
gcloud anthos auth login
para acessar o cluster, isso significa que o apiserver não pode autorizar o usuário.- Causas possíveis
- Os RBACs apropriados estão ausentes ou incorretos ou há um erro na configuração do OIDC para o cluster.
- Resolução
- Siga estas etapas para tentar resolver o problema:
Analise o
id-token
do kubeconfig.No arquivo kubeconfig que foi gerado pelo comando de login, copie o
id-token
:kind: Config … users: - name: … user: auth-provider: config: id-token: [id-token] …
Siga as etapas para instalar o jwt-cli e executar:
jwt [id-token]
Verifique a configuração do OIDC.
A seção
oidc
preenchida emconfig.yaml
, que foi usado para criar o cluster, contém os camposgroup
eusername
, que são usados para definir as sinalizações--oidc-group-claim
e--oidc-username-claim
no apiserver. Quando o analisador é apresentado com o token, ele procura essa reivindicação de grupo e de nome de usuário e verifica se o grupo ou usuário correspondente tem as permissões corretas.Verifique se as reivindicações definidas para
group
euser
na seçãooidc
deconfig.yaml
estão presentes noid-token
.Verifique os RBACs que foram aplicados.
Verifique se há um RBAC com as permissões corretas para o usuário especificado pela reivindicação de nome de usuário ou para um dos grupos listados na reivindicação de grupo da etapa anterior. O nome do usuário ou grupo no RBAC precisa ter o prefixo
usernameprefix
ougroupprefix
fornecido na seçãooidc
deconfig.yaml
.Se
usernameprefix
for deixado em branco eusername
for um valor diferente deemail
, o prefixo será padronizado comoissuerurl#
. Para desativar os prefixos de nome de usuário,usernameprefix
deve ser definido como-
.Para mais informações sobre prefixos de usuários e grupos, consulte Como preencher a especificação oidc.
Observe que o servidor da API Kubernetes atualmente trata uma barra invertida como um caractere de escape. Portanto, se o nome do usuário ou do grupo contiver
\\
, o servidor da API o lerá como um único\
ao analisar oid_token
. Portanto, o RBAC aplicado a esse usuário ou grupo deve conter somente uma única barra invertida. Caso contrário, você verá um erroUnauthorized
.Exemplo:
config.yaml:
oidc: issuerurl: … username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:" ...
id_token:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
Os seguintes RBACs concederiam a esse usuário permissões de administrador de cluster (observe a barra única no campo de nome em vez de uma barra dupla):
Group RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
User RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Verifique os registros do servidor da API.
Se o plug-in OIDC configurado no kube apiserver não for iniciado corretamente, o servidor da API retornará um erro "Não autorizado" quando apresentado com o
id-token
. Para ver se houve algum problema com o plug-in OIDC no servidor da API, execute:kubectl --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n [user_cluster_name]
- Sintomas
Não é possível se conectar ao servidor: recebe {DISCOVERY_ENDPOINT}: x509: certificado assinado por autoridade desconhecida
- Causas possíveis
O token de atualização no kubeconfig expirou.
- Resolução
Execute o comando
login
novamente.
Login no Console do Google Cloud
Veja a seguir erros comuns que podem ocorrer ao usar o Console do Cloud para tentar fazer login:
O login redireciona para a página com o erro "URL não encontrado"
- Sintomas
O Console do Cloud não consegue alcançar o provedor de identidade do GKE On-Prem.
- Causas possíveis
O Console do Cloud não consegue alcançar o provedor de identidade do GKE On-Prem.
- Resolução
Siga estas etapas para tentar resolver o problema:
-
Defina
useHTTPProxy
comotrue
Se o IDP não estiver acessível pela Internet pública, você precisará ativar o proxy OIDC HTTP para fazer login por meio do Console do Cloud. Na seção
oidc
deconfig.yaml
,usehttpproxy
deve ser definido comotrue
. Se você já tiver criado um cluster e quiser ativar o proxy, será possível editar o CRD ClientConfig diretamente. Execute$ kubectl edit clientconfig default -n kube-public
e altereuseHTTPProxy
paratrue
. useHTTPProxy
já está definido comotrue
Se o proxy HTTP estiver ativado e você ainda estiver vendo esse erro, pode ter ocorrido um problema na inicialização do proxy. Para acessar os registros do proxy, execute
$ kubectl logs deployment/clientconfig-operator -n kube-system
. Mesmo que seu IDP tenha uma CA conhecida, para que o proxy http seja iniciado, o campocapath
na seçãooidc
deconfig.yaml
precisa ser fornecido.Prompts de IDP para consentimento
Se o servidor de autorização solicitar consentimento e você não tiver incluído o extraparam
prompt=consent
, talvez esse erro apareça. Execute$ kubectl edit clientconfig default -n kube-public
, adicioneprompt=consent
aextraparams
e tente fazer login novamente.Os RBACs estão configurados incorretamente
Se você ainda não tiver feito isso, tente fazer a autenticação usando o Plug-in de autenticação para Anthos. Se você também estiver vendo um erro de autorização ao fazer login com o plug-in, siga as etapas de solução de problemas para resolver o problema com o plug-in e tente fazer login novamente pelo Console do Cloud.
Tente sair e fazer login novamente
Em alguns casos, se algumas configurações forem alteradas no serviço de armazenamento, talvez seja necessário sair explicitamente. Acesse a página de detalhes do cluster, clique em Sair e tente fazer login novamente.
Estação de trabalho do administrador
openssl
não pode validar o OVA da estação de trabalho de administrador- Sintomas
Executar
openssl dgst
no arquivo OVA da estação de trabalho de administrador não retornaVerified OK
- Causas possíveis
Há um problema no arquivo OVA que impede a validação bem-sucedida.
- Resolução
Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme descrito em Fazer o download do OVA da estação de trabalho de administrador . Se o problema persistir, entre em contato com o Google para receber ajuda.
Conectar
Não é possível registrar um cluster de usuário
Se você encontrar problemas com o registro de clusters de usuário, entre em contato com o Google para receber ajuda.
O registro do cluster criado durante a versão Alfa foi cancelado
Consulte Como registrar um cluster de usuário na documentação do Connect.
Também é possível excluir e recriar o cluster.
Armazenamento
Falha ao anexar o volume
Sintomas
A saída de
gkectl diagnose cluster
é semelhante a esta:Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status 1 storage errors
Um ou mais pods estão parados no estado
ContainerCreating
com um aviso como este:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
Causas possíveis
Se um disco virtual estiver anexado à máquina virtual errada, pode ser devido ao problema nº 32727 no Kubernetes 1.12.
Resolução
Se um disco virtual estiver anexado à máquina virtual errada, talvez seja necessário desanexá-lo manualmente:
- Drene o nó.
Consulte Drenar um nó com segurança. Convém incluir as
sinalizações
--ignore-daemonsets
e--delete-local-data
no comandokubectl drain
. - Desligue a VM.
- Edite a configuração de hardware da VM no vCenter para remover o volume.
- Ligue a VM
- Desfaça o nó.
O volume foi perdido
Sintomas
A saída de
gkectl diagnose cluster
é semelhante a esta:Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found 1 storage errors
Um ou mais pods estão parados no estado
ContainerCreating
com um aviso como este:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/ kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
Causas possíveis
Se você vir um erro "não encontrado" relacionado ao arquivo VMDK, é provável que o disco virtual tenha sido excluído permanentemente. Isso pode acontecer se um operador excluir manualmente um disco virtual ou a máquina virtual ao qual estiver anexado. Para evitar isso, gerencie suas máquinas virtuais conforme descrito em Como redimensionar um cluster de usuário e Como fazer upgrade de clusters
Resolução
Se um disco virtual foi excluído permanentemente, talvez seja necessário limpar manualmente os recursos relacionados do Kubernetes:
- Execute
kubectl delete pvc [PVC_NAME].
para excluir o PVC que faz referência ao PV - Execute
kubectl delete pod [POD_NAME].
para excluir o pod que faz referência ao PVC - Repita a etapa 2. (Sim, na verdade. Consulte o problema 74374 do Kubernetes.)
Não é possível remover o volume do CSI do vSphere
Sintomas
Se você encontrar pods presos na fase
ContainerCreating
com avisos deFailedAttachVolume
, pode ser devido a uma falha na remoção em um nó diferente.Execute o seguinte comando para encontrar erros de remoção de CSI:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
A saída será semelhante a esta:
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 Causas possíveis
O privilégio
CNS > Searchable
não foi concedido ao usuário vSphere.Resolução
Adicione o privilégio
CNS > Searchable
à sua conta de usuário do vCenter. Essa operação é repetida automaticamente até ser bem-sucedida.Upgrades
Sobre a inatividade durante upgrades
Recurso Descrição Cluster de administrador Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuário e as cargas de trabalho em clusters de usuário continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade.
Plano de controle do cluster de usuário Normalmente, não há inatividade perceptível nos planos de controle do cluster de usuário. No entanto, conexões de longa duração com o servidor da API Kubernetes podem falhar e precisam ser restabelecidas. Nesses casos, o autor da chamada da API precisa tentar novamente até estabelecer uma conexão. No pior dos casos, pode haver até um minuto de inatividade durante um upgrade.
Nós do cluster de usuário Se um upgrade exigir uma alteração nos nós do cluster de usuário, o GKE On-Prem recriará os nós de maneira contínua e reagendará os pods em execução nesses nós. É possível evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets e regras antiafinidade apropriados.
A renovação dos certificados pode ser necessária antes de um upgrade do cluster de administrador
Antes de iniciar o processo de upgrade do cluster de administrador, verifique se os certificados do cluster de administrador são válidos atualmente e, se não forem, renove-os.
Processo de renovação do certificado do cluster de administrador
Verifique se o OpenSSL está instalado na estação de trabalho do administrador antes de começar.
Defina a variável
KUBECONFIG
:KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Substitua ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG pelo caminho absoluto para o arquivo kubeconfig do cluster de administrador.
Consiga o endereço IP e as chaves SSH do nó mestre de administrador:
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Verifique se os certificados expiraram:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Se os certificados tiverem expirado, você precisará renová-los antes de fazer upgrade do cluster de administrador.
Faça backup dos certificados antigos:
Esta é uma etapa opcional, mas recomendada.
# ssh into admin master 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 o 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
Como o arquivo kubeconfig do cluster de administrador também expirará se os certificados de administrador expirarem, você precisará fazer backup desse arquivo antes que ele expire.
Faça backup do arquivo kubeconfig do cluster de administrador:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Substitua
client-certificate-data
eclient-key-data
no kubeconfig porclient-certificate-data
eclient-key-data
no arquivonew_admin.conf
que você criou.
É preciso validar os certificados renovados e o certificado do kube-apiserver.
Verifique a validade dos certificados:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Verifique o certificado do kube-apiserver:
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
Como redimensionar clusters de usuário
Falha no redimensionamento de um cluster de usuário
- Sintomas
Falha na operação de redimensionamento em um cluster de usuário.
- Causas possíveis
Vários fatores podem causar falhas nas operações de redimensionamento.
- Resolução
Se um redimensionamento falhar, siga estas etapas:
Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
Verifique se há erros nas máquinas recém-criadas:
kubectl describe machine [MACHINE_NAME]
Erro: "nenhum endereço pode ser alocado"
- Sintomas
Depois de redimensionar um cluster de usuário,
kubectl describe machine [MACHINE_NAME]
exibe o seguinte erro:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- Causas possíveis
Não há endereços IP suficientes disponíveis para o cluster de usuário.
- Resolução
Aloque mais endereços IP para o cluster. Em seguida, exclua a máquina afetada:
kubectl delete machine [MACHINE_NAME]
Se o cluster estiver configurado corretamente, uma máquina de substituição será criada com um endereço IP.
Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster
- Sintomas
A rede tem endereços suficientes alocados, mas ainda assim a máquina não é registrada no cluster de usuário.
- Causas possíveis
Pode haver um conflito de IP. O IP pode ser usado por outra máquina ou pelo balanceador de carga.
- Resolução
Verifique se o endereço IP da máquina afetada não foi usado. Se houver um conflito, você precisará resolvê-lo no seu ambiente.
vSphere
Depuração com
govc
Se você encontrar problemas específicos ao vSphere, use o
govc
para solucionar problemas. Por exemplo, é possível confirmar facilmente as permissões e o acesso das suas contas de usuário do vCenter e coletar registros do vSphere.Como alterar o certificado do vCenter
Se você estiver executando um servidor vCenter no modo de configuração padrão ou de avaliação e tiver um certificado TLS gerado, esse certificado poderá mudar ao longo do tempo. Se o certificado tiver sido alterado, você precisará informar seus clusters em execução sobre o novo certificado:
Recupere o novo certificado do vCenter e salve-o em um arquivo:
true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Agora, para cada cluster, exclua o ConfigMap que contém o certificado do vSphere e do vCenter de cada cluster e crie um novo ConfigMap com o novo certificado. Exemplo:
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
Exclua o pod clusterapi-controllers de cada cluster. Quando o pod é reiniciado, ele começa a usar o novo certificado. Exemplo:
kubectl --kubeconfig kubeconfig -n kube-system get pods
kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...
Diversos
Limite de sessão no provedor do vSphere do Terraform
O GKE On-Prem usa o provedor do vSphere do Terraform para abrir VMs no ambiente vSphere. O limite de sessões no provedor é de 1.000 sessões. A implementação atual não fecha as sessões ativas após o uso. Podem ocorrer erros 503 se você tiver muitas sessões em execução.
As sessões são fechadas automaticamente após 300 segundos.
- Sintomas
Se você tiver muitas sessões em execução, talvez você encontre o seguinte erro:
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable
- Causas possíveis
Há muitas sessões de provedor do Terraform em execução no seu ambiente.
- Resolução
No momento, isso está funcionando conforme o esperado. As sessões são fechadas automaticamente após 300 segundos. Para mais informações, consulte o problema nº 618 no GitHub.
Como usar um proxy para o Docker:
oauth2: cannot fetch token
- Sintomas
Ao usar um proxy, você encontra o seguinte erro:
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- Causas possíveis
É possível que você tenha fornecido um proxy HTTPS em vez de HTTP.
- Resolução
Na configuração do Docker, altere o endereço do proxy para
http://
em vez dehttps://
.
Como verificar se as licenças são válidas
Lembre-se de verificar se as licenças são válidas, especialmente se você estiver usando licenças de teste. Pode haver falhas inesperadas se as licenças F5, host ESXi ou vCenter tiverem expirado.
-