Google Distributed Cloud (apenas software) para problemas conhecidos do VMware

Esta página apresenta todos os problemas conhecidos do Google Distributed Cloud no VMware. Esta página destina-se a administradores de TI e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são cumpridos ou as aplicações falham. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Se fizer parte do Google Developer Program, guarde esta página para receber notificações quando for publicada uma nota de lançamento relacionada com esta página. Para saber mais, consulte Páginas guardadas.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros pretendidos nos seguintes menus pendentes.

Selecione a sua versão do Google Distributed Cloud:

Selecione a categoria do problema:

Em alternativa, pesquise o seu problema:

Categoria Versões identificadas Problema e solução alternativa
Atualizações 1.30, 1.31

Os pods do Windows permanecem pendentes após a migração do ControlPlaneV2 devido a um certificado TLS inválido

Durante uma operação de atualização do Google Distributed Cloud que inclua uma migração do ControlPlaneV2 da versão 1.30.x para a 1.31.x, os pods do Windows podem não ser agendados e permanecer num estado Pending. Este problema manifesta-se como um erro de validação do certificado TLS para o webhook de admissão de mutação windows-webhook. O problema ocorre porque o nome alternativo de entidade (SAN) do certificado retém incorretamente um valor válido para a arquitetura Kubeception antiga, em vez de ser regenerado para o novo ponto final kube-system.svc.

Pode observar a seguinte mensagem de erro: failed calling webhook "windows.webhooks.gke.io": failed to call webhook: Post "https://windows-webhook.kube-system.svc:443/pod?timeout=10s": tls: failed to verify certificate: x509. Esta situação pode surgir do processo de migração do ControlPlaneV2 que copia o conteúdo do etcd, o que transfere o certificado antigo sem a regeneração adequada. É importante ter em atenção que os pools de nós do Windows são uma funcionalidade descontinuada e vão ficar indisponíveis no Google Distributed Cloud 1.33 e versões posteriores.

Solução alternativa:

  1. Faça uma cópia de segurança do segredo user-component-options no espaço de nomes do cluster do utilizador:

        kubectl get secret user-component-options -n USER_CLUSTER_NAME -oyaml > backup.yaml

  2. Elimine o segredo user-component-options:

        kubectl delete secret user-component-options -n USER_CLUSTER_NAME

  3. Edite o recurso onpremusercluster para acionar a conciliação adicionando a anotação onprem.cluster.gke.io/reconcile: "true":

        kubectl edit onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_MGMT_NAMESPACE

Substitua USER_CLUSTER_NAME pelo nome do seu cluster de utilizadores.
Atualizações 1.32.0-1.32.500, 1.33.0

A atualização para um cluster avançado falha se o stackdriver não estiver configurado

Quando atualiza um cluster não avançado para um cluster avançado, o processo pode deixar de responder se o stackdriver não estiver ativado.

Solução alternativa:

  • Se o cluster ainda não tiver sido atualizado, tem de seguir os passos para ativar stackdriver:
    1. Adicione a secção stackdriver ao ficheiro de configuração do cluster.
    2. Execute gkectl update para ativar a autorização stackdriver.
  • Se já estiver a decorrer uma atualização, siga estes passos:
    1. Edite o user-cluster-credssegredo no espaço de nomes USER_CLUSTER_NAME-gke-onprem-mgmt com o seguinte comando: 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
  patch secret user-cluster-creds \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  --type merge -p "{\"data\":{\"stackdriver-service-account-key\":\"$(cat STACKDRIVER_SERVICE_ACCOUNT_KEY_FILE | base64 | tr -d '\n')\"}}"
    2. Se atualizar o recurso personalizado OnPremUserCluster com o campo stackdriver, deve usar o mesmo projeto com a mesma localização do projeto e chave da conta de serviço que o cloudauditlogging se tiver ativado a funcionalidade. 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
    patch onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt --type merge -p '
    spec:
      stackdriver:
        clusterLocation: PROJECT_LOCATION
        providerID: PROJECT_ID
        serviceAccountKey:
          kubernetesSecret:
            keyName: stackdriver-service-account-key
            name: user-cluster-creds
'
    3. Adicione a secção stackdriver ao ficheiro de configuração do cluster para garantir a consistência.
Atualizações 1,29, 1,30, 1,31, 1,32+

Os pods não conseguem estabelecer ligação ao servidor da API Kubernetes com o plano de dados V2 e políticas de rede restritivas

Em clusters que usam a arquitetura do plano de controlo V2 (CPv2) (predefinição na versão 1.29 e posteriores) e o plano de dados V2, os pods podem não conseguir estabelecer ligação ao servidor da API Kubernetes (kubernetes.default.svc.cluster.local). Este problema é frequentemente acionado pela presença de políticas de rede, especialmente as que têm regras de saída de recusa predefinidas. Os sintomas incluem o seguinte:

  • As tentativas de ligação TCP ao endereço IP do cluster ou aos endereços IP do nó do servidor da API resultam numa mensagem Connection reset by peer.
  • Falhas de handshake TLS ao estabelecer ligação ao servidor da API.
  • A execução do comando cilium monitor -t drop no nó afetado pode mostrar pacotes destinados aos endereços IP do nó do plano de controlo e à porta do servidor da API (normalmente, 6443) a serem ignorados.

Causa

Este problema surge de uma interação entre o Dataplane V2 (com base no Cilium) e as políticas de rede do Kubernetes na arquitetura CPv2, em que os componentes do plano de controlo são executados em nós no cluster de utilizador. A configuração predefinida do Cilium não interpreta corretamente as regras ipBlock nas políticas de rede destinadas a permitir o tráfego para os IPs dos nós dos membros do plano de controlo. Este problema está relacionado com um problema do Cilium a montante (cilium#20550).

Solução alternativa:

Para as versões 1.29, 1.30 e 1.31, evite usar políticas de rede de saída restritivas que possam bloquear o tráfego para os nós do plano de controlo. Se precisar de uma política de recusa predefinida, pode ter de adicionar uma regra de permissão abrangente para todo o tráfego de saída, por exemplo, não especificando regras na secção de saída, o que permite efetivamente toda a saída. Esta solução é menos segura e pode não ser adequada para todos os ambientes.

Para todas as outras versões, ative uma configuração do Cilium para fazer corresponder corretamente os IPs dos nós nos campos ipBlock da política de rede. Para fazer corresponder os IPs dos nós nos campos ipBlock da política de rede, faça o seguinte:

  1. Edite o cilium-config ConfigMap: 
    kubectl edit configmap -n kube-system cilium-config
  2. Adicione ou modifique a secção de dados para incluir policy-cidr-match-mode: nodes: 
    data:
      policy-cidr-match-mode: nodes
  3. Para aplicar a alteração de configuração, reinicie o DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system
  4. Certifique-se de que tem uma política de rede que permite explicitamente o tráfego de saída dos seus pods para os IPs dos nós do plano de controlo na porta do servidor da API. Identifique os endereços IP dos nós do plano de controlo do cluster de utilizadores executando kubectl get svc kubernetes. O resultado é semelhante ao seguinte: 
        apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-egress-to-kube-apiserver
      namespace: NAMESPACE_NAME
    spec:
      podSelector: {} 
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: CP_NODE_IP_1/32
        - ipBlock:
            cidr: CP_NODE_IP_2/32
        ports:
        - protocol: TCP
          port: 6443 # Kubernetes API Server port on the node
Instalação 1.30.200-gke.101

O agente gke-connectPod está bloqueado no estado Pending durante a criação do cluster de utilizadores

Durante a criação do cluster de utilizadores, o pod do agente gke-connect pode ficar bloqueado num estado Pending, o que impede a criação completa do cluster. Este problema ocorre porque o pod do agente gke-connect tenta agendar antes de os nós de trabalho estarem disponíveis, o que leva a um impasse.

Este problema surge quando a criação inicial do cluster de utilizadores falha devido a erros de validação de pré-lançamento, e é feita uma tentativa subsequente de criar o cluster sem eliminar primeiro os recursos criados parcialmente. Na tentativa de criação do cluster subsequente, o pod do agente gke-connect fica bloqueado devido a taints não tolerados nos nós do plano de controlo, conforme indicado por um erro semelhante ao seguinte:

    0/3 nodes are available: 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }`.

Solução alternativa:

Se a criação do cluster de utilizadores falhar devido a erros de validação prévia, elimine os recursos do cluster criados parcialmente antes de tentar criar o cluster novamente com as configurações corrigidas. Isto garante que o fluxo de trabalho de criação prossegue corretamente, incluindo a criação de pools de nós, antes de o pod do agente gke-connect ser implementado.
Atualizar 1.16 e versões anteriores, 1.28.0-1.28.1100, 1.29.0-1.29.700, 1.30.0-1.30.200

Depois de desativar a encriptação de segredos sempre ativada com o gkectl update cluster, os segredos continuam a ser armazenados no etcd com encriptação. Este problema aplica-se apenas a clusters de utilizadores do kubeception. Se o seu cluster usar o Controlplane V2, não é afetado por este problema.

Para verificar se os segredos continuam encriptados, execute o seguinte comando, que obtém o segredo default/private-registry-creds armazenado em etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Se a chave secreta for armazenada com encriptação, o resultado tem o seguinte aspeto:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Se a chave secreta não estiver armazenada com encriptação, o resultado é semelhante ao seguinte:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Solução alternativa:

  1. Faça uma atualização contínua num DaemonSet específico da seguinte forma: 
        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      rollout restart statefulsets kube-apiserver \
      -n USER_CLUSTER_NAME
  2. Obtenha os manifestos de todos os segredos no cluster do utilizador, no formato YAML: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      get secrets -A -o yaml > SECRETS_MANIFEST.yaml
  3. Volte a aplicar todos os segredos no cluster de utilizadores para que todos os segredos sejam armazenados em etcd como texto simples: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      apply -f SECRETS_MANIFEST.yaml

Configuração 1,29, 1,30, 1,31

O ficheiro de configuração do cluster de utilizadores, user-cluster.yaml, gerado pelo comando gkectl get-config, não tem o campo hostgroups na secção nodePools. O comando gkectl get-config gera o ficheiro user-cluster.yaml com base no conteúdo do recurso personalizado OnPremUserCluster. No entanto, o campo nodePools[i].vsphere.hostgroups existe no recurso personalizado OnPremNodePool e não é copiado para o ficheiro user-cluster.yaml quando executa gkectl get-config.

Solução alternativa

Para resolver este problema, adicione manualmente o campo nodePools[i].vsphere.hostgroups ao ficheiro user-cluster.yaml. O ficheiro editado deve ter um aspeto semelhante ao seguinte exemplo:

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Pode usar o ficheiro de configuração do cluster de utilizadores editado para atualizar o cluster de utilizadores sem acionar erros e o campo hostgroups é mantido.
Redes 1.29.0-1.29.1000, 1.30.0-1.30.500, 1.31.0-1.31.100

Os pods do Istiod do acesso de entrada integrado não podem ficar prontos se os recursos gateway.networking.k8s.io estiverem instalados no cluster de utilizador. Pode encontrar a seguinte mensagem de erro de exemplo nos registos de pods:

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"

Solução alternativa:

Aplique o ClusterRole e o ClusterRoleBinding seguintes ao seu cluster de utilizadores: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
Instalação 1.29.0-1.29.1000, 1.30.0-1.30.500, 1.31.0-1.31.100

Se os nomes de anfitriões no campo ipblocks contiverem letras maiúsculas, os nós do plano de controlo do cluster de administrador podem ser reiniciados repetidamente.

Solução alternativa:

Use apenas nomes de anfitriões em minúsculas.
Instalação, atualizações 1.30.0-1.30.500, 1.31.0-1.31.100

Runtime: out of memory "erro" após executar gkeadm create ou upgrade

Quando cria ou atualiza estações de trabalho de administrador com comandos gkeadm, , pode receber um erro de falta de memória ao validar a imagem do SO transferida.

Por exemplo, 

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Solução alternativa:

  • Aumente o tamanho da memória do SO onde executa o comando gkeadm.
    		•
    Atualizações 1.30.0-1.30.400

    A atualização do cluster de administrador não de HA está bloqueada em Creating or updating cluster control plane workloads

    Quando atualiza um cluster de administrador não de HA, a atualização pode ficar bloqueada em Creating or updating cluster control plane workloads.

    Este problema ocorre se, na VM principal do administrador, ip a | grep cali devolver um resultado não vazio.

    Por exemplo, 

    ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

    Solução alternativa:

    1. Repare o administrador principal: 
      gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
    --config=ADMIN_CONFIG_FILE \
    --skip-validation
    2. Selecione o modelo de VM 1.30 se vir um comando como o do exemplo seguinte: 
      Please select the control plane VM template to be used for re-creating the
admin cluster's control plane VM.
    3. Retome a atualização: 
      gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG_FILE
    Configuração 1.31.0

    Campo isControlPlane redundante no ficheiro de configuração do cluster em network.controlPlaneIPBlock

    Os ficheiros de configuração do cluster gerados pelo gkectl create-config na versão 1.31.0 contêm um campo isControlPlane redundante em network.controlPlaneIPBlock:

        controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false

    Este campo não é necessário e pode ser removido em segurança do ficheiro de configuração.

    Migração 1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0

    Quando migra um cluster de administrador não de HA que usa o MetalLB para HA, os nós do suplemento de administrador podem ficar bloqueados num estado NotReady, o que impede a conclusão da migração.

    Este problema afeta apenas clusters de administrador configurados com o MetalLB, em que a reparação automática não está ativada.

    Este problema é causado por uma condição de concorrência durante a migração em que os altifalantes do MetalLB ainda estão a usar o segredo metallb-memberlist antigo. Como resultado da condição de concorrência, o VIP do plano de controlo antigo torna-se inacessível, o que faz com que a migração fique bloqueada.

    Solução alternativa:

    1. Elimine o segredo metallb-memberlist existente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    delete secret metallb-memberlist
    2. Reinicie a metallb-controllerimplementação para que possa gerar o novo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart deployment metallb-controller
    3. Certifique-se de que o novo metallb-memberlist é gerado: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    get secret metallb-memberlist
    4. Atualize updateStrategy.rollingUpdate.maxUnavailable no DaemonSet metallb-speaker de 1 para 100%.

      Este passo é obrigatório, porque determinados pods DaemonSet estão a ser executados nos nós NotReady.

      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    edit daemonset metallb-speaker
    5. Reinicie o metallb-speaker DaemonSet para que possa selecionar a nova lista de membros: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart daemonset metallb-speaker

      Após alguns minutos, os nós do suplemento de administração voltam a ficar Ready e a migração pode continuar.

    6. Se o comando gkectl inicial excedeu o tempo limite após mais de 3 horas, volte a executar gkectl update para retomar a migração com falha.
    Configuração, funcionamento 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

    A cópia de segurança do cluster para o cluster de administrador não de HA falha devido a nomes longos de datastore e datadisk

    Quando tenta fazer uma cópia de segurança de um cluster de administrador não de HA, a cópia de segurança falha porque o comprimento combinado dos nomes do arquivo de dados e do disco de dados excede o comprimento máximo de carateres.

    O comprimento máximo de carateres para um nome de arquivo de dados é 80.
    O caminho de cópia de segurança para um cluster de administrador não HA tem a sintaxe de nomenclatura "__". Assim, se o nome concatenado exceder o comprimento máximo, a criação da pasta de cópia de segurança falha

    Solução alternativa:

    Mude o nome do arquivo de dados ou do disco de dados para um nome mais curto.
    Certifique-se de que o comprimento combinado dos nomes do arquivo de dados e do disco de dados não excede o comprimento máximo de carateres.
    Atualizações 1.28, 1.29, 1.30

    Depois de executar o comando gkectl repair admin-master, um nó do plano de controlo do administrador pode apresentar uma versão mais antiga do que a versão esperada.

    Este problema ocorre porque o modelo de VM de cópia de segurança usado para a reparação do nó do plano de controlo do administrador de HA não é atualizado no vCenter após uma atualização, porque o modelo de VM de cópia de segurança não foi clonado durante a criação da máquina se o nome da máquina permanecer inalterado.

    Solução alternativa:

    1. Descubra o nome do computador que está a usar a versão mais antiga do Kubernetes: 
          kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
    2. Remova a anotação onprem.cluster.gke.io/prevented-deletion: 
          kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      Guarde a edição.

    3. Execute o seguinte comando para eliminar a máquina: 
          kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      É criada uma nova máquina com a versão correta.
    Configuração 1.30.0

    Quando atualiza um cluster de utilizadores ou um conjunto de nós através do Terraform, o Terraform pode tentar definir campos vCenter com valores vazios.

    Este problema pode ocorrer se o cluster não tiver sido originalmente criado com o Terraform.

    Solução alternativa:

    Para evitar a atualização inesperada, certifique-se de que a atualização é segura antes de executar terraform apply, conforme descrito no seguinte:

    1. Execução terraform plan
    2. Na saída, verifique se os campos vCenter estão definidos como nil.
    3. Se algum campo vCenter estiver definido como um valor vazio, na configuração do Terraform, adicione vcenter à lista ignore_changes após a documentação do Terraform. Isto impede as atualizações destes campos.
    4. Execute terraform plan novamente e verifique a saída para confirmar se a atualização está como esperado
    Atualizações 1.13, 1.14, 1.15 e 1.16

    Depois de os nós do plano de controlo dos clusters de utilizadores do kubeception serem criados, atualizados ou alvo de uma atualização, são reiniciados um a um, durante a primeira operação do cluster de administrador quando o cluster de administrador é criado ou atualizado para uma das versões afetadas. Para clusters kubeception com 3 nós do plano de controlo, isto não deve originar tempo de inatividade do plano de controlo, e o único impacto é que a operação do cluster de administrador demora mais tempo.

    Instalação, atualizações e atualizações 1.31

    Na versão 1.31 do Google Distributed Cloud, pode receber erros quando tenta criar recursos personalizados, como clusters (todos os tipos) e cargas de trabalho. O problema é causado por uma alteração interruptiva introduzida no Kubernetes 1.31 que impede que o campo caBundle numa definição de recurso personalizado passe de um estado válido para um estado inválido. Para mais informações sobre a alteração, consulte o registo de alterações do Kubernetes 1.31.

    Antes do Kubernetes 1.31, o campo caBundle era frequentemente definido para um valor improvisado de \n, porque nas versões anteriores do Kubernetes, o servidor da API não permitia conteúdo vazio do pacote de AC. A utilização de \n foi uma solução alternativa razoável para evitar confusões, uma vez que o cert-manager atualiza normalmente o caBundle mais tarde.

    Se o caBundle tiver sido corrigido uma vez de um estado inválido para um estado válido, não devem existir problemas. No entanto, se a definição do recurso personalizado for reconciliada de volta para \n (ou outro valor inválido), pode encontrar o seguinte erro:

    ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

    Solução alternativa

    Se tiver uma definição de recurso personalizada em que caBundle está definido como um valor inválido, pode remover o campo caBundle em segurança. Isto deve resolver o problema.
    SO 1.31

    Quando atualiza um cluster que usa a imagem do SO do SO otimizado para contentores (COS) para a versão 1.31, o comando cloud-init status falha, embora o cloud-init tenha terminado sem erros.

    Solução alternativa:

    Execute o seguinte comando para verificar o estado do cloud-init:

        systemctl show -p Result cloud-final.service

    Se o resultado for semelhante ao seguinte, significa que o cloud-init foi concluído com êxito:

        Result=success
    Atualizações 1,28

    Quando atualiza um cluster para a versão 1.28, o comando gkectl prepare falha durante a execução das verificações prévias da estação de trabalho de administração se o tamanho do disco da estação de trabalho de administração for inferior a 100 GB. Neste caso, o comando apresenta uma mensagem de erro semelhante à seguinte:

        Workstation Hardware: Workstation hardware requirements are not satisfied

    Na versão 1.28, o pré-requisito do tamanho do disco da estação de trabalho do administrador foi aumentado de 50 GB para 100 GB.

    Solução alternativa:

    1. Reverter a estação de trabalho do administrador.
    2. Atualize o ficheiro de configuração da estação de trabalho de administração para aumentar o espaço em disco para, pelo menos, 100 GB.
    3. Atualize a estação de trabalho de administrador.
    Atualizações 1,30

    O comando gkectl upgrade devolve um erro incorreto acerca da classe de armazenamento netapp. A mensagem de erro é semelhante à seguinte: 

        detected unsupported drivers:
      csi.trident.netapp.io

    Solução alternativa:

    Execute gkectl upgrade com a flag `--skip-pre-upgrade-checks`.
    Identidade todas as versões

    Depois de rodar os certificados da autoridade de certificação (AC) num cluster de utilizadores, o campo spec.certificateAuthorityData no ClientConfig contém um certificado da AC inválido, o que impede a autenticação no cluster.

    Solução alternativa:

    Antes da próxima autenticação da CLI gcloud, atualize manualmente o campo spec.certificateAuthorityData no ficheiro ClientConfig com o certificado da AC correto.

    1. Copie o certificado da AC do cluster do campo certificate-authority-data no kubeconfig do cluster de administrador.
    2. Edite o ClientConfig e cole o certificado da AC no campo spec.certificateAuthorityData. 
          kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
    Atualizações 1,28 ou mais

    Quando desativa a entrada agrupada removendo o campo loadBalancer.vips.ingressVIP no ficheiro de configuração do cluster, um erro na verificação prévia do MetalLB faz com que a atualização do cluster falhe com a mensagem de erro "invalid user ingress vip: invalid IP".

    Solução alternativa:

    Ignorar a mensagem de erro.
    Ignore a verificação prévia através de um dos seguintes métodos:

    • Adicione a flag --skip-validation-load-balancer ao comando gkectl update cluster.
    • Anotar o objeto onpremusercluster com onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer
      • .
    VMware, atualizações 1.16

    Durante uma atualização do cluster, os objetos de máquina podem ficar bloqueados na fase "Creating" (Criação) e não conseguem estabelecer ligação aos objetos de nó devido a uma regra de grupo antiafinidade (AAG) em falta no vCenter.

    Se descrever os objetos de máquina problemáticos, pode ver mensagens recorrentes como "Reconfigure DRS rule task "task-xxxx" complete" (Reconfigure DRS rule task "task-xxxx" complete)

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Solução alternativa:

    Desative a definição do grupo de anti-afinidade na configuração do cluster de administrador e na configuração do cluster de utilizador e acione o comando de atualização forçada para desbloquear a atualização do cluster:

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
        gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    Migração 1,29, 1,30

    Quando migra um cluster de utilizadores para o plano de controlo V2, se a encriptação de segredos sempre ativa tiver sido ativada, o processo de migração não processa corretamente a chave de encriptação de segredos. Devido a este problema, o novo cluster do plano de controlo V2 não consegue descifrar segredos. Se o resultado do seguinte comando não estiver vazio, a encriptação de segredos sempre ativada foi ativada em algum momento e o cluster é afetado por este problema:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}

    Se já tiver iniciado a migração e esta falhar, contacte a Google para receber apoio técnico. Caso contrário, antes da migração, desative a encriptação de segredos sempre ativa e desencripte os segredos.

    Migração 1.29.0-1.29.600, 1.30.0-1.30.100

    Se o cluster de administrador tiver ativado a encriptação de segredos sempre ativa na versão 1.14 ou anterior e tiver sido atualizado das versões antigas para as versões 1.29 e 1.30 afetadas, quando migrar o cluster de administrador de não HA para HA, o processo de migração não processa corretamente a chave de encriptação de segredos. Devido a este problema, o novo cluster de administrador de HA não consegue desencriptar segredos.

    Para verificar se o cluster pode estar a usar a chave formatada antiga:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

    Se o resultado mostrar a chave vazia da seguinte forma, significa que o cluster será afetado por este problema:

        "GeneratedKeys":[{"KeyVersion":"1","Key":""}]

    Se já tiver iniciado a migração e esta falhar, contacte a Google para receber apoio técnico.

    Caso contrário, antes de iniciar a migração, rode a chave de encriptação.
    Atualizações 1,16, 1,28, 1,29, 1,30

    Quando atualiza a estação de trabalho do administrador com o comando gkeadm upgrade admin-workstation, o ficheiro credential.yaml é regenerado incorretamente. Os campos de nome de utilizador e palavra-passe estão vazios. Além disso, a chave privateRegistry contém um erro ortográfico.

    A mesma gralha na tecla privateRegistry também está no ficheiro admin-cluster.yaml.
    Uma vez que o ficheiro credential.yaml é regenerado durante o processo de atualização do cluster de administração, o erro ortográfico está presente mesmo que o tenha corrigido anteriormente.

    Solução alternativa:

    • Atualize o nome da chave de registo privada em credential.yaml para corresponder ao privateRegistry.credentials.fileRef.entry no admin-cluster.yaml.
    • Atualize o nome de utilizador e a palavra-passe do registo privado no ficheiro credential.yaml.
    Atualizações 1.16+

    Quando atualiza um cluster de utilizadores, a operação de reconciliação pré-atualização pode demorar mais tempo do que o limite de tempo definido, o que resulta numa falha na atualização. A mensagem de erro tem o seguinte aspeto:

    Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

    O limite de tempo para a operação de conciliação pré-atualização é de 5 minutos mais 1 minuto por conjunto de nós no cluster de utilizador.

    Solução alternativa:

    Certifique-se de que o comando gkectl diagnose cluster é aprovado sem erros.
    Ignore a operação de conciliação pré-atualização adicionando a flag --skip-reconcile-before-preflight ao comando gkectl upgrade cluster. Por exemplo:

    gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
    Atualizações 1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0

    Quando atualiza o campo dataplaneV2.forwardMode do cluster de utilizadores através do gkectl update cluster, a alteração só é atualizada no ConfigMap. O DaemonSet anetd não deteta a alteração de configuração até ser reiniciado, e as suas alterações não são aplicadas.

    Solução alternativa:

    Quando o comando gkectl update cluster estiver concluído, é apresentada a saída Done updating the user cluster. Depois de ver a mensagem, execute o seguinte comando para reiniciar o anetdDaemonSet para aplicar a alteração de configuração:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

    Verifique a prontidão do DaemonSet após o reinício:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

    No resultado do comando anterior, verifique se o número na coluna DESIRED corresponde ao número na coluna READY.
    Atualizações 1.16

    Durante uma atualização do cluster de utilizadores de 1.16 para 1.28, é feita uma cópia de segurança do cluster de administrador. O processo de cópia de segurança do cluster de administrador apresenta a mensagem de erro "etcdctl: command not found". A atualização do cluster de utilizadores é bem-sucedida e o cluster de administrador permanece num estado saudável. O único problema é que o ficheiro de metadados no cluster de administrador não tem uma cópia de segurança.

    A causa do problema é que o ficheiro binário etcdctl foi adicionado na versão 1.28 e não está disponível em nós da versão 1.16.

    A cópia de segurança do cluster de administrador envolve vários passos, incluindo a criação de uma imagem instantânea do etcd e, em seguida, a gravação do ficheiro de metadados para o cluster de administrador. A cópia de segurança do etcd continua a ser bem-sucedida porque ainda é possível acionar etcdctl após uma execução no pod do etcd. No entanto, a escrita do ficheiro de metadados falha, uma vez que continua a depender do binário etcdctl para ser instalado no nó. No entanto, a cópia de segurança do ficheiro de metadados não impede a criação de uma cópia de segurança, pelo que o processo de cópia de segurança continua a ser bem-sucedido, tal como a atualização do cluster de utilizadores.

    Solução alternativa:

    Se quiser fazer uma cópia de segurança do ficheiro de metadados, siga os passos descritos no artigo Fazer uma cópia de segurança e restaurar um cluster de administrador com o gkectl para acionar uma cópia de segurança do cluster de administrador separada com a versão do gkectl que corresponde à versão do seu cluster de administrador.
    Instalação 1,16-1,29

    Quando cria um cluster de utilizadores configurado para o equilíbrio de carga manual, ocorre uma falha gkectl check-config a indicar que o valor ingressHTTPNodePort tem de ser, pelo menos, 30 000, mesmo quando a entrada agrupada está desativada.

    Este problema ocorre independentemente de os campos ingressHTTPNodePort e ingressHTTPSNodePort estarem definidos ou em branco.

    Solução alternativa:

    Para contornar este problema, ignore o resultado devolvido por gkectl check-config. Para desativar a entrada agrupada, consulte o artigo Desative a entrada agrupada.
    Atualizações 1.29.0

    O problema com o PodDisruptionBudget (PDB) ocorre quando usa clusters de administrador de alta disponibilidade (HA) e existem 0 ou 1 nó do cluster de administrador sem uma função após a migração. Para verificar se existem objetos node sem uma função, execute o seguinte comando:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

    Se existirem dois ou mais objetos de nós sem uma função após a migração, o PDB não está configurado incorretamente.

    Sintomas:

    O resultado de admin cluster diagnose inclui as seguintes informações

    Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

    Solução alternativa:

    Execute o seguinte comando para eliminar a PDB:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
    Instalação, atualizações e atualizações 1.28.0-1.28.600,1.29.0-1.29.100

    Em condições de concorrência raras, uma sequência de instalação incorreta do webhook de autorização binária e do pod gke-connect pode fazer com que a criação do cluster de utilizadores fique bloqueada devido a um nó que não consegue atingir um estado pronto. Nos cenários afetados, a criação de clusters de utilizadores pode ficar bloqueada devido a um nó que não consegue atingir um estado pronto. Se isto ocorrer, é apresentada a seguinte mensagem:

         Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

    Solução alternativa:

    1. Remova a configuração da Autorização binária do ficheiro de configuração. Para ver instruções de configuração, consulte o guia de instalação do dia 2 da Autorização binária para o GKE no VMware.
    2. Para desbloquear um nó não saudável durante o processo de criação do cluster atual, remova temporariamente a configuração do webhook da autorização binária no cluster de utilizador através do seguinte comando. 
              kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
      Assim que o processo de arranque estiver concluído, pode voltar a adicionar a seguinte configuração de webhook. 
      apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
  namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist
  objectSelector:
    matchExpressions:
    - key: "image-policy.k8s.io/break-glass"
      operator: NotIn
      values: ["true"]
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    - pods/ephemeralcontainers
  admissionReviewVersions:
  - "v1beta1"
  clientConfig:
    service:
      name: binauthz
      namespace: binauthz-system
      path: /binauthz
    # CA Bundle will be updated by the cert rotator.
    caBundle: Cg==
  timeoutSeconds: 10
  # Fail Open
  failurePolicy: "Ignore"
  sideEffects: None
    Atualizações 1.16, 1.28 e 1.29

    Durante uma atualização do cluster de utilizadores, a operação de atualização pode ficar bloqueada se o objeto de máquina espelhado no cluster de utilizadores contiver um deletionTimestamp. É apresentada a seguinte mensagem de erro se a atualização estiver bloqueada:

        machine is still in the process of being drained and subsequently removed

    Este problema pode ocorrer se tiver tentado anteriormente reparar o nó do plano de controlo do utilizador executando gkectl delete machine na máquina espelhada no cluster de utilizadores.

    Solução alternativa:

    1. Obtenha o objeto da máquina espelhada e guarde-o num ficheiro local para fins de cópia de segurança.
    2. Execute o seguinte comando para eliminar o finalizador da máquina duplicada e aguarde até que seja eliminado do cluster de utilizadores. 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
    3. Siga os passos em Nó do plano de controlo do cluster de utilizadores do plano de controlo V2 para acionar a reparação do nó nos nós do plano de controlo, para que a especificação da máquina de origem correta seja ressincronizada no cluster de utilizadores.
    4. Volte a executar o comando gkectl upgrade cluster para retomar a atualização
    Configuração e instalação 1.15, 1.16, 1.28 e 1.29

    Para o cluster de administrador de HA ou o cluster de utilizador do ControlPlane V2, o VIP do plano de controlo tem de estar na mesma sub-rede que os outros nós do cluster. Caso contrário, a criação do cluster falha porque o kubelet não consegue comunicar com o servidor da API através do VIP do plano de controlo.

    Solução alternativa:

    Antes da criação do cluster, certifique-se de que o VIP do plano de controlo está configurado na mesma sub-rede que os outros nós do cluster.
    Instalação, atualizações e atualizações 1.29.0 - 1.29.100

    A criação/atualização do cluster falha com um erro nos pods do CSI do vSphere a indicar que o nome de utilizador do vCenter é inválido. Isto ocorre porque o nome de utilizador usado não é um nome de domínio totalmente qualificado. Mensagem de erro no pod vsphere-csi-controller, conforme abaixo:

        GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username

    Este problema só ocorre na versão 1.29 e posteriores, uma vez que foi adicionada uma validação ao controlador CSI do vSphere para aplicar a utilização de nomes de utilizador de domínio totalmente qualificados.

    Solução alternativa:

    Use um nome do domínio totalmente qualificado para o nome de utilizador do vCenter no ficheiro de configuração das credenciais. Por exemplo, em vez de usar "username1", use "[email protected]".
    Atualizações 1.28.0 - 1.28.500

    Quando atualiza um cluster de administrador de 1.16 para 1.28, o arranque do novo computador principal de administrador pode não conseguir gerar o certificado do plano de controlo. O problema é causado por alterações na forma como os certificados são gerados para o servidor da API Kubernetes na versão 1.28 e posteriores. O problema reproduz-se para clusters criados nas versões 1.10 e anteriores que foram atualizados até à versão 1.16 e o certificado de folha não foi alterado antes da atualização.

    Para determinar se a falha na atualização do cluster de administrador é causada por este problema, siga os passos abaixo:

    1. Ligue-se à máquina principal de administrador com falhas através de SSH.
    2. Abra /var/log/startup.log e pesquise um erro como o seguinte:
    Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>

    Solução alternativa:

    1. Ligue-se à máquina principal de administração através de SSH. Para ver detalhes, consulte o artigo Usar SSH para estabelecer ligação a um nó do cluster de administrador.
    2. Crie uma cópia /etc/startup/pki-yaml.sh e atribua-lhe o nome /etc/startup/pki-yaml-copy.sh
    3. Edite o pacote /etc/startup/pki-yaml-copy.sh. Encontre authorityKeyIdentifier=keyidset e altere-o para authorityKeyIdentifier=keyid,issuer nas secções das seguintes extensões: apiserver_ext, client_ext, etcd_server_ext e kubelet_server_ext. Por exemplo: 
            [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
    4. Guarde as alterações a /etc/startup/pki-yaml-copy.sh.
    5. Com um editor de texto, abra o ficheiro /opt/bin/master.sh, localize e substitua todas as ocorrências de /etc/startup/pki-yaml.sh por /etc/startup/pki-yaml-copy.sh e, em seguida, guarde as alterações.
    6. Execute /opt/bin/master.sh para gerar o certificado e concluir o arranque da máquina.
    7. Execute o comando gkectl upgrade admin novamente para atualizar o cluster de administrador.
    8. Após a conclusão da atualização, rode o certificado de folha para os clusters de administrador e de utilizador, conforme descrito em Inicie a rotação.
    9. Após a conclusão da rotação dos certificados, faça as mesmas edições a /etc/startup/pki-yaml-copy.sh que fez anteriormente e execute /opt/bin/master.sh.
    Configuração 1.29.0

    A seguinte mensagem de aviso incorreta é emitida quando executa o comando gkectl para criar, atualizar ou fazer a atualização de um cluster que já tenha o Dataplane V2 ativado:

    WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.

    Existe um erro no gkectl que faz com que este aviso seja sempre apresentado enquanto o dataplaneV2.forwardMode não estiver a ser usado, mesmo que já tenha definido enableDataplaneV2: true no ficheiro de configuração do cluster.

    Solução alternativa:

    Pode ignorar este aviso com segurança.
    Configuração 1.28.0-1.28.400, 1.29.0

    Quando cria um cluster de administrador de HA, a verificação prévia apresenta a seguinte mensagem de erro incorreta:

    - Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

    O requisito está incorreto para clusters de administrador de HA 1.28 e superiores, porque já não têm nós suplementares. Além disso, uma vez que os IPs dos nós do plano de controlo do cluster de administração são especificados na secção network.controlPlaneIPBlock do ficheiro de configuração do cluster de administração, os IPs no ficheiro de bloco de IPs só são necessários para os nós do plano de controlo do cluster de utilizadores do kubeception.

    Solução alternativa:

    Para ignorar a verificação prévia incorreta numa versão não fixa, adicione --skip-validation-net-config ao comando gkectl.
    Operação 1.29.0-1.29.100

    Se migrou de um cluster de administrador não de HA para um cluster de administrador de HA, o agente Connect no cluster de administrador perde a ligação a gkeconnect.googleapis.com com o erro "Falha ao validar a assinatura JWT". Isto deve-se ao facto de, durante a migração, a chave de assinatura da KSA ser alterada. Por isso, é necessário um novo registo para atualizar os JWKs da OIDC.

    Solução alternativa:

    Para voltar a associar o cluster de administrador ao Google Cloud, siga os passos abaixo para acionar um novo registo:

    Primeiro, obtenha o gke-connectnome da implementação:

    kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

    Elimine a implementação gke-connect:

    kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

    Acione uma reconciliação forçada para o onprem-admin-cluster-controller adicionando uma anotação "force-reconcile" ao seu CR onpremadmincluster:

    kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

    A ideia é que o onprem-admin-cluster-controller vai sempre reimplementar a implementação gke-connect e voltar a registar o cluster se não encontrar nenhuma implementação gke-connect existente disponível.

    Após a solução alternativa (o comando pode demorar alguns minutos a concluir a conciliação), pode verificar se o erro 400 "Failed to verify JWT signature" desapareceu dos registos gke-connect-agent:

    kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
    Instalação, sistema operativo 1.28.0-1.28.500, 1.29.0

    O Google Distributed Cloud especifica uma sub-rede dedicada, --bip=169.254.123.1/24, para o IP da ponte Docker na configuração do Docker para evitar a reserva da sub-rede 172.17.0.1/16 predefinida. No entanto, nas versões 1.28.0 a 1.28.500 e 1.29.0, o serviço Docker não foi reiniciado depois de o Google Distributed Cloud personalizar a configuração do Docker devido a uma regressão na imagem do SO COS. Como resultado, o Docker escolhe 172.17.0.1/16 como a sub-rede do endereço IP da ponte. Isto pode causar um conflito de endereços IP se já tiver uma carga de trabalho em execução nesse intervalo de endereços IP.

    Solução alternativa:

    Para contornar este problema, tem de reiniciar o serviço Docker:

    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 persiste nas recriações de VMs. Tem de voltar a aplicar esta solução alternativa sempre que as VMs forem recriadas.
    Atualizar 1.28.0-1.28.400, 1.29.0-1.29.100

    Os binários CNI padrão bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap não estão incluídos nas imagens do SO nas versões afetadas. Estes ficheiros binários de CNI não são usados pelo plano de dados v2, mas podem ser usados para interfaces de rede adicionais na funcionalidade de várias interfaces de rede.

    A interface de rede múltipla com estes plug-ins CNI não funciona.

    Solução alternativa:

    Se estiver a usar esta funcionalidade, faça a atualização para a versão com a correção.
    Atualizar 1.15, 1.16 e 1.28

    A instalação do multipathd nos nós do cluster interfere com o controlador CSI do vSphere, o que impede o início das cargas de trabalho do utilizador.

    Solução alternativa:

    • Desativar multipathd
    Atualizações 1.15 e 1.16

    Se algumas configurações obrigatórias estiverem vazias no cluster de administrador porque as validações foram ignoradas, a respetiva adição pode ser bloqueada pelo webhook do cluster de administrador. Por exemplo, se o campo gkeConnect não tiver sido definido num cluster de administrador existente, adicioná-lo com o comando gkectl update admin pode gerar a seguinte mensagem de erro:

    admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters
    Ocasionalmente, pode haver um problema com a comunicação entre o servidor da API Kubernetes e o webhook. Quando isto acontece, pode ver a seguinte mensagem de erro: 
    failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

    Solução alternativa:

    Se encontrar um destes erros, use uma das seguintes soluções alternativas, consoante a sua versão:
    • Para clusters de administrador 1.15, execute o comando gkectl update admin com a flag --disable-admin-cluster-webhook. Por exemplo: 
              gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
    • Para clusters de administrador 1.16, execute comandos gkectl update admin com a flag --force. Por exemplo: 
              gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    Configuração 1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

    Se for usar um equilibrador de carga manual (loadBalancer.kind está definido como "ManualLB"), não deve ter de configurar a secção loadBalancer.manualLB no ficheiro de configuração para um cluster de administrador de alta disponibilidade (HA) nas versões 1.16 e superiores. No entanto, quando esta secção está vazia, o Google Distributed Cloud atribui valores predefinidos a todas as portas de nós, incluindo manualLB.controlPlaneNodePort, o que faz com que a criação do cluster falhe com a seguinte mensagem de erro:

    - Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

    Solução alternativa:

    Especifique manualLB.controlPlaneNodePort: 0 na configuração do cluster de administrador para o cluster de administrador de HA:

    loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
    Armazenamento 1.28.0-1.28.100

    O nfs-common está em falta na imagem do SO Ubuntu, o que pode causar problemas aos clientes que usam controladores dependentes do NFS, como o NetApp.

    Se o registo contiver uma entrada semelhante à seguinte após a atualização para a versão 1.28, significa que é afetado por este problema: 
    Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".

    Solução alternativa:

    Certifique-se de que os seus nós podem transferir pacotes da Canonical.

    Em seguida, aplique o seguinte DaemonSet ao seu cluster para instalar o nfs-common:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
    Armazenamento 1.28.0-1.28.100

    O SPBM em clusters de administrador é suportado na versão 1.28.0 e posteriores. No entanto, o campo vCenter.storagePolicyName está em falta no modelo do ficheiro de configuração.

    Solução alternativa:

    Adicione o campo `vCenter.storagePolicyName` no ficheiro de configuração do cluster de administrador se quiser configurar a política de armazenamento para o cluster de administrador. Consulte as instruções.
    Registo e monitorização 1.28.0-1.28.100

    A API kubernetesmetadata.googleapis.com adicionada recentemente não suporta o VPC-SC. Isto fará com que o agente de recolha de metadados não consiga alcançar esta API no VPC-SC. Posteriormente, as etiquetas de metadados de métricas vão estar em falta.

    Solução alternativa:

    No espaço de nomes `kube-system`, defina o campo `featureGates.disableExperimentalMetadataAgent` do CR `stackdriver` como `true` executando o comando

    `kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

    e, em seguida, execute

    `kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

    Atualizações 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

    Quando um cluster de administrador e qualquer cluster de utilizador com o ControlPlane V2 ativado usam credenciais do vSphere diferentes, por exemplo, após a atualização das credenciais do vSphere para o cluster de administrador, o clusterapi-controller pode não conseguir estabelecer ligação ao vCenter após o reinício. Veja o registo do clusterapi-controller em execução no espaço de nomes `kube-system` do cluster de administrador,

    kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG
     Se o registo contiver uma entrada semelhante à seguinte, significa que é afetado por este problema: 
    E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

    Solução alternativa:

    Atualize as credenciais do vSphere para que o cluster de administrador e todos os clusters de utilizador com o Controlplane V2 ativado estejam a usar as mesmas credenciais do vSphere.

    Registo e monitorização 1.14

    O Prometheus pode comunicar alertas semelhantes ao seguinte exemplo:

    Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

    Para verificar se este alerta é um falso positivo que pode ser ignorado, conclua os seguintes passos:

    1. Verifique a métrica grpc_server_handled_total não processada em comparação com a métrica grpc_method indicada na mensagem de alerta. Neste exemplo, verifique a etiqueta grpc_code para Watch.

      Pode verificar esta métrica através do Cloud Monitoring com a seguinte consulta MQL: 
      fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
    2. Pode ignorar com segurança um alerta em todos os códigos que não sejam OK se o código não for um dos seguintes: 
      Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

    Solução alternativa:

    Para configurar o Prometheus de modo a ignorar estes alertas de falsos positivos, reveja as seguintes opções:

    1. Silenciar o alerta na IU do Gestor de alertas.
    2. Se não tiver a opção de desativar o som do alerta, reveja os seguintes passos para suprimir os falsos positivos:
      1. Reduza o operador de monitorização para 0 réplicas para que as modificações possam persistir.
      2. Modifique o prometheus-config configmap e adicione grpc_method!="Watch" à configuração de alerta etcdHighNumberOfFailedGRPCRequests, conforme mostrado no exemplo seguinte:
        • Original: 
          rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
        • Modificado: 
          rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
           Substitua o seguinte CLUSTER_NAME pelo nome do seu cluster.
      3. Reinicie o Statefulset do Prometheus e do Alertmanager para aplicar a nova configuração.
    3. Se o código se enquadrar num dos casos problemáticos, verifique o registo etcd e o registo kube-apiserver para depurar mais.
    Redes 1.16.0-1.16.2, 1.28.0

    As ligações NAT de saída podem ser interrompidas após 5 a 10 minutos de uma ligação estabelecida se não houver tráfego.

    Como o conntrack só é importante na direção de entrada (ligações externas ao cluster), este problema só ocorre se a ligação não transmitir informações durante algum tempo e, em seguida, o lado de destino transmitir algo. Se o pod com NAT de saída instanciar sempre a mensagem, este problema não é apresentado.

    Este problema ocorre porque a recolha de lixo do anetd remove inadvertidamente as entradas de conntrack que o daemon considera não utilizadas. Uma correção a montante foi recentemente integrada no anetd para corrigir o comportamento.


    Solução alternativa:

    Não existe uma solução alternativa fácil e não detetámos problemas na versão 1.16 deste comportamento. Se notar que as ligações de longa duração foram interrompidas devido a este problema, as soluções alternativas consistem em usar uma carga de trabalho no mesmo nó que o endereço IP de saída ou enviar mensagens de forma consistente na ligação TCP.
    Operação 1.14, 1.15 e 1.16

    Se criar um CertificateSigningRequest (CSR) com expirationSeconds definido, o expirationSeconds é ignorado.

    Solução alternativa:

    Se for afetado por este problema, pode atualizar o cluster de utilizadores adicionando disableNodeIDVerificationCSRSigning: true no ficheiro de configuração do cluster de utilizadores e executar o comando gkectl update cluster para atualizar o cluster com esta configuração.
    Redes, atualizações 1.16.0-1.16.3

    Se tentar desativar a entrada agrupada para um cluster existente, o comando gkectl update cluster falha com um erro semelhante ao seguinte exemplo:

    [FAILURE] Config: ingress IP is required in user cluster spec

    Este erro ocorre porque gkectl procura um endereço IP de entrada do balanceador de carga durante as verificações prévias. Embora esta verificação não seja necessária quando desativa a entrada agrupada, a verificação prévia falha quando disableBundledIngress está definido como true.gkectl


    Solução alternativa:

    Use o parâmetro --skip-validation-load-balancer quando atualizar o cluster, conforme mostrado no exemplo seguinte:

    gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

    Para mais informações, veja como desativar a entrada agrupada para um cluster existente.
    Atualizações 1.13, 1.14, 1.15.0-1.15.6

    Se rodar os certificados da autoridade de certificação (AC) do cluster de administrador, as tentativas subsequentes de executar o comando gkectl update admin falham. O erro devolvido é semelhante ao seguinte:

    failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

    Solução alternativa:

    Se for afetado por este problema, pode atualizar o cluster de administrador usando o sinalizador --disable-update-from-checkpoint com o comando gkectl update admin:

    gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

    Quando usa a flag --disable-update-from-checkpoint, o comando de atualização não usa o ficheiro de ponto de verificação como fonte de informações fidedignas durante a atualização do cluster. O ficheiro de ponto de verificação continua a ser atualizado para utilização futura.
    Armazenamento 1.15.0-1.15.6, 1.16.0-1.16.2

    Durante as verificações prévias, a verificação de validação da carga de trabalho do CSI instala um pod no espaço de nomes default. O pod de carga de trabalho do CSI valida se o controlador CSI do vSphere está instalado e se pode fazer o aprovisionamento dinâmico de volumes. Se este Pod não for iniciado, a verificação de validação da carga de trabalho do CSI falha.

    Existem alguns problemas conhecidos que podem impedir o início deste Pod:

    • Se o Pod não tiver limites de recursos especificados, o que acontece para alguns clusters com webhooks de admissão instalados, o Pod não é iniciado.
    • Se o Cloud Service Mesh estiver instalado no cluster com a injeção automática de sidecar do Istio ativada no espaço de nomes default, o pod de carga de trabalho do CSI não é iniciado.

    Se o pod de carga de trabalho do CSI não for iniciado, é apresentado um erro de limite de tempo, como o seguinte, durante as validações prévias:

    - [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

    Para ver se a falha é causada pela falta de recursos do pod definidos, execute o seguinte comando para verificar o estado da tarefa anthos-csi-workload-writer-<run-id>:

    kubectl describe job anthos-csi-workload-writer-<run-id>

    Se os limites de recursos não estiverem definidos corretamente para o pod de carga de trabalho do CSI, o estado da tarefa contém uma mensagem de erro semelhante à seguinte:

    CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

    Se o pod de carga de trabalho do CSI não for iniciado devido à injeção de sidecar do Istio, pode desativar temporariamente a injeção de sidecar do Istio automática no espaço de nomes default. Verifique as etiquetas do espaço de nomes e use o seguinte comando para eliminar a etiqueta que começa com istio.io/rev:

    kubectl label namespace default istio.io/rev-

    Se o Pod estiver configurado incorretamente, verifique manualmente se o aprovisionamento de volumes dinâmicos com o controlador CSI do vSphere funciona:

    1. Crie um PVC que use a standard-rwo StorageClass.
    2. Crie um pod que use o PVC.
    3. Verifique se o pod consegue ler/escrever dados no volume.
    4. Remova o pod e o PVC depois de validar o funcionamento adequado.

    Se o aprovisionamento dinâmico de volumes com o controlador CSI do vSphere funcionar, execute gkectl diagnose ou gkectl upgrade com a flag --skip-validation-csi-workload para ignorar a verificação da carga de trabalho do CSI.

    Operação 1.16.0-1.16.2

    Quando tem sessão iniciada numa estação de trabalho de administrador gerida pelo utilizador, o comando gkectl update cluster pode exceder o tempo limite e não atualizar o cluster de utilizadores. Isto acontece se: a versão do cluster de administrador for 1.15 e executar gkectl update admin antes de executar o comando gkectl update cluster. Quando esta falha ocorre, é apresentado o seguinte erro ao tentar atualizar o cluster: 

          Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

    Durante a atualização de um cluster de administrador 1.15, o validation-controller que aciona as verificações prévias é removido do cluster. Se, em seguida, tentar atualizar o cluster de utilizadores, a verificação prévia fica suspensa até atingir o limite de tempo.

    Solução alternativa:

    1. Execute o seguinte comando para voltar a implementar o validation-controller: 
            gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
    2. Depois de a preparação estar concluída, execute o comando gkectl update cluster novamente para atualizar o cluster de utilizadores
    Operação 1.16.0-1.16.2

    Quando tem sessão iniciada numa estação de trabalho de administrador gerida pelo utilizador, o comando gkectl create cluster pode exceder o tempo limite e não criar o cluster de utilizadores. Isto acontece se: A versão do cluster de administrador for 1.15. Quando esta falha ocorre, é apresentado o seguinte erro ao tentar criar o cluster: 

          Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

    Uma vez que o validation-controller foi adicionado na versão 1.16, quando usa o cluster de administrador 1.15, o validation-controller responsável por acionar as verificações de pré-voo está em falta. Por conseguinte, quando tenta criar um cluster de utilizadores, as verificações prévias ficam pendentes até atingir o limite de tempo.

    Solução alternativa:

    1. Execute o seguinte comando para implementar o validation-controller: 
            gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
    2. Após a preparação, execute o comando gkectl create cluster novamente para criar o cluster de utilizadores
    Atualizações 1.16.0-1.16.2

    Quando atualiza um cluster de administrador da versão 1.15.x para a 1.16.x ou adiciona uma configuração connect, stackdriver, cloudAuditLogging ou gkeOnPremAPI quando atualiza um cluster de administrador, a operação pode ser rejeitada pelo webhook do cluster de administrador. Pode ser apresentada uma das seguintes mensagens de erro:

    • "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
    • "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
    • "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

    Uma atualização ou uma atualização para uma versão mais recente do cluster de administrador requer o comando onprem-admin-cluster-controller para conciliar o cluster de administrador num cluster do tipo. Quando o estado do cluster de administrador é restaurado no cluster do tipo, o webhook do cluster de administrador não consegue distinguir se o objeto OnPremAdminCluster é para a criação de um cluster de administrador ou para retomar as operações de uma atualização. Algumas validações de apenas criação são invocadas na atualização e na atualização inesperadamente.


    Solução alternativa:

    Adicione a anotação onprem.cluster.gke.io/skip-project-location-sameness-validation: true ao objeto OnPremAdminCluster:

    1. Edite o recurso de cluster onpremadminclusters: 
      kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
       Substitua o seguinte:
      • ADMIN_CLUSTER_NAME: o nome do cluster de administração.
      • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
    2. Adicione a anotação onprem.cluster.gke.io/skip-project-location-sameness-validation: true e guarde o recurso personalizado.
    3. Consoante o tipo de clusters de administrador, conclua um dos seguintes passos:
      • Para clusters de administrador não de HA com um ficheiro de ponto de verificação: adicione o parâmetro disable-update-from-checkpoint no comando de atualização ou adicione o parâmetro `disable-upgrade-from-checkpoint` no comando de atualização. Estes parâmetros só são necessários na próxima vez que executar o comando update ou upgrade: 
        • gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-update-from-checkpoint
        • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
      • Para clusters de administrador de HA ou se o ficheiro de ponto de verificação estiver desativado: atualize ou faça a atualização do cluster de administrador como habitualmente. Não são necessários parâmetros adicionais nos comandos de atualização.
    Operação 1.16.0-1.16.2

    Quando tem sessão iniciada numa estação de trabalho de administrador gerida pelo utilizador, o comando gkectl delete cluster pode exceder o tempo limite e não conseguir eliminar o cluster de utilizadores. Isto acontece se tiver executado primeiro o gkectl na estação de trabalho gerida pelo utilizador para criar, atualizar ou fazer a atualização do cluster de utilizadores. Quando esta falha ocorre, é apresentado o seguinte erro ao tentar eliminar o cluster: 

          failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition

    Durante a eliminação, um cluster elimina primeiro todos os respetivos objetos. A eliminação dos objetos de validação (criados durante a criação, a atualização ou a atualização) está bloqueada na fase de eliminação. Isto acontece porque um finalizador bloqueia a eliminação do objeto, o que faz com que a eliminação do cluster falhe.

    Solução alternativa:

    1. Obtenha os nomes de todos os objetos Validation: 
               kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
    2. Para cada objeto Validation, execute o seguinte comando para remover o finalizador do objeto Validation: 
            kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

      Depois de remover o finalizador de todos os objetos de validação, os objetos são removidos e a operação de eliminação do cluster de utilizador é concluída automaticamente. Não tem de fazer nada.

    Redes 1.15 e 1.16

    Se o pod de origem e o pod de gateway NAT de saída estiverem em dois nós de trabalho diferentes, o tráfego do pod de origem não consegue alcançar nenhum serviço externo. Se os pods estiverem localizados no mesmo anfitrião, a ligação ao serviço ou à aplicação externa é bem-sucedida.

    Este problema é causado pelo vSphere que elimina pacotes VXLAN quando a agregação de túneis está ativada. Existe um problema conhecido com o NSX e o VMware que envia apenas tráfego agregado em portas VXLAN conhecidas (4789).


    Solução alternativa:

    Altere a porta VXLAN usada pelo Cilium para 4789:

    1. Edite o cilium-config ConfigMap: 
      kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
    2. Adicione o seguinte ao cilium-config ConfigMap: 
      tunnel-port: 4789
    3. Reinicie o DaemonSet anetd: 
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Esta solução alternativa é revertida sempre que o cluster é atualizado. Tem de reconfigurar após cada atualização. A VMware tem de resolver o respetivo problema no vSphere para uma correção permanente.
    Atualizações 1.15.0-1.15.4

    A atualização do cluster de administrador de 1.14.x para 1.15.x com a encriptação de segredos sempre ativada falha devido a uma incompatibilidade entre a chave de encriptação gerada pelo controlador e a chave que persiste no disco de dados principal do administrador. A saída de gkectl upgrade admin contém a seguinte mensagem de erro: 

          E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane

    A execução de kubectl get secrets -A --kubeconfig KUBECONFIG` falha com o seguinte erro: 

          Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk

    Alternativa

    Se tiver uma cópia de segurança do cluster de administrador, siga estes passos para contornar a falha na atualização:

    1. Desative secretsEncryption no ficheiro de configuração do cluster de administração e atualize o cluster com o seguinte comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    2. Quando a nova VM principal de administração for criada, use SSH para aceder à VM principal de administração e substitua a nova chave no disco de dados pela antiga da cópia de segurança. A chave encontra-se em /opt/data/gke-k8s-kms-plugin/generatedkeys no administrador principal.
    3. Atualize o manifesto do pod estático kms-plugin.yaml em /etc/kubernetes/manifests para atualizar o --kek-id de modo a corresponder ao campo kid na chave de encriptação original.
    4. Reinicie o pod estático kms-plugin movendo o /etc/kubernetes/manifests/kms-plugin.yaml para outro diretório e, em seguida, movendo-o novamente.
    5. Retome a atualização de administrador executando gkectl upgrade admin novamente.

    Evitar a falha na atualização

    Se ainda não fez a atualização, recomendamos que não o faça para a versão 1.15.0 a 1.15.4. Se tiver de atualizar para uma versão afetada, siga os passos abaixo antes de atualizar o cluster de administrador:

    1. Faça uma cópia de segurança do cluster de administrador.
    2. Desative secretsEncryption no ficheiro de configuração do cluster de administração e atualize o cluster com o seguinte comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    3. Atualize o cluster de administrador.
    4. Reative a encriptação de segredos sempre ativada.
    Armazenamento 1,11-1,16

    O Google Distributed Cloud não suporta a funcionalidade Changed Block Tracking (CBT) em discos. Alguns softwares de cópia de segurança usam a funcionalidade CBT para monitorizar o estado do disco e fazer cópias de segurança, o que faz com que o disco não consiga estabelecer ligação a uma VM que execute o Google Distributed Cloud. Para mais informações, consulte o artigo da KB da VMware.


    Solução alternativa:

    Não faça uma cópia de segurança das VMs do Google Distributed Cloud, uma vez que o software de cópia de segurança de terceiros pode fazer com que a CBT seja ativada nos respetivos discos. Não é necessário fazer uma cópia de segurança destas VMs.

    Não ative o CBT no nó, uma vez que esta alteração não é mantida nas atualizações ou nas atualizações de versão.

    Se já tiver discos com a CBT ativada, siga os passos de resolução no artigo da VMware KBpara desativar a CBT no disco de primeira classe.
    Armazenamento 1.14, 1.15 e 1.16

    Se usar matrizes de armazenamento Nutanix para fornecer partilhas NFSv3 aos seus anfitriões, pode ocorrer corrupção de dados ou os pods podem não ser executados com êxito. Este problema é causado por um problema de compatibilidade conhecido entre determinadas versões do VMware e do Nutanix. Para mais informações, consulte o artigo da VMware KB associado.


    Solução alternativa:

    O artigo da base de conhecimentos da VMware está desatualizado ao indicar que não existe uma resolução atual. Para resolver este problema, atualize para a versão mais recente do ESXi nos seus anfitriões e para a versão mais recente do Nutanix nos seus conjuntos de armazenamento.
    Sistema operativo 1.13.10, 1.14.6 e 1.15.3

    Para determinadas versões do Google Distributed Cloud, o kubelet executado nos nós usa uma versão diferente da do plano de controlo do Kubernetes. Existe uma incompatibilidade porque o ficheiro binário kubelet pré-carregado na imagem do SO está a usar uma versão diferente.

    A tabela seguinte lista as incompatibilidades de versões identificadas:

    Versão do Google Distributed Cloud versão do kubelet Versão do Kubernetes
    1.13.10 v1.24.11-gke.1200 v1.24.14-gke.2100
    1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
    1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

    Solução alternativa:

    Não é necessária nenhuma ação. A inconsistência existe apenas entre as versões de patch do Kubernetes e não foram causados problemas por esta diferença de versões.

    Atualizações 1.15.0-1.15.4

    Quando um cluster de administrador tem uma versão da autoridade de certificação (AC) superior a 1, uma atualização ou uma atualização falha devido à validação da versão da AC no webhook. A saída da atualização de gkectl contém a seguinte mensagem de erro: 

        CAVersion must start from 1

    Solução alternativa:

    • Reduza a escala da implementação do auto-resize-controller no cluster de administração para desativar o redimensionamento automático de nós. Isto é necessário porque um novo campo introduzido no recurso personalizado do cluster de administrador na versão 1.15 pode causar um erro de ponteiro nulo no auto-resize-controller. 
       kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
    • Execute comandos gkectl com a flag --disable-admin-cluster-webhook.Por exemplo: 
              gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
    Operação 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

    Quando um cluster do plano de controlo V2 não HA é eliminado, fica bloqueado na eliminação de nós até atingir o limite de tempo.

    Solução alternativa:

    Se o cluster contiver um StatefulSet com dados críticos, contacte o apoio técnico do Google Cloud para resolver este problema.

    Caso contrário, siga estes passos:

    • Elimine todas as VMs do cluster do vSphere. Pode eliminar as VMs através da IU do vSphere ou executar o seguinte comando: 
            govc vm.destroy
      .
    • Forçar a eliminação do cluster novamente: 
           gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

    Armazenamento 1.15.0+, 1.16.0+

    Quando um cluster contém volumes persistentes do vSphere no interior da árvore (por exemplo, PVCs criados com a standard StorageClass), observa tarefas com.vmware.cns.tasks.attachvolume acionadas a cada minuto a partir do vCenter.


    Solução alternativa:

    Edite o configMap da funcionalidade CSI do vSphere e defina list-volumes como falso:

         kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG

    Reinicie os pods do controlador CSI do vSphere:

         kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    Armazenamento 1.16.0

    Quando um cluster contém volumes persistentes do vSphere intree, os comandos gkectl diagnose e gkectl upgrade podem gerar avisos falsos contra as respetivas reivindicações de volume persistente (PVCs) quando validam as definições de armazenamento do cluster. A mensagem de aviso tem o seguinte aspeto: 

        CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled

    Solução alternativa:

    Execute o seguinte comando para verificar as anotações de um PVC com o aviso acima:

        kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG

    Se o campo annotations na saída contiver o seguinte, pode ignorar o aviso com segurança:

          pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
    Atualizações 1.15.0+, 1.16.0+

    Se o cluster não estiver a usar um registo privado e as chaves da conta de serviço de acesso aos componentes e as chaves da conta de serviço de registo (ou de ligação) estiverem expiradas, quando alternar as chaves da conta de serviço, gkectl update credentials falha com um erro semelhante ao seguinte: 

    Error: reconciliation failed: failed to update platform: ...

    Solução alternativa:

    Primeiro, alterne a chave da conta de serviço de acesso aos componentes. Embora seja apresentada a mesma mensagem de erro, deve conseguir rodar as outras chaves após a rotação da chave da conta de serviço de acesso aos componentes.

    Se a atualização ainda não for bem-sucedida, contacte o apoio ao cliente do Google Cloud para resolver este problema.
    Atualizações 1.16.0-1.16.5

    Durante uma atualização do cluster de utilizadores, depois de o controlador do cluster de utilizadores ser atualizado para a versão 1.16, se tiver outros clusters de utilizadores 1.15 geridos pelo mesmo cluster de administrador, a respetiva máquina principal do utilizador pode ser recriada inesperadamente.

    Existe um erro no controlador do cluster de utilizadores 1.16 que pode acionar a recriação da máquina principal do utilizador 1.15.

    A solução alternativa que usa depende da forma como encontra este problema.

    Solução alternativa quando atualiza o cluster de utilizadores através da Google Cloud consola:

    Opção 1: use uma versão 1.16.6 ou superior do GKE on VMware com a correção.

    Opção 2: siga os passos seguintes:

    1. Adicione manualmente a anotação de nova execução com o seguinte comando: 
      kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

      A anotação de repetição é:

      onprem.cluster.gke.io/server-side-preflight-rerun: true
    2. Monitorize o progresso da atualização verificando o campo status do OnPremUserCluster.

    Solução alternativa quando atualiza o cluster de utilizadores através da sua própria estação de trabalho de administrador:

    Opção 1: use uma versão 1.16.6 ou superior do GKE on VMware com a correção.

    Opção 2: siga os passos seguintes:

    1. Adicione o ficheiro de informações de compilação /etc/cloud/build.info com o seguinte conteúdo. Isto faz com que as verificações prévias sejam executadas localmente na estação de trabalho do administrador e não no servidor. 
      gke_on_prem_version: GKE_ON_PREM_VERSION
       Por exemplo: 
      gke_on_prem_version: 1.16.0-gke.669
    2. Execute novamente o comando de atualização.
    3. Após a conclusão da atualização, elimine o ficheiro build.info.
    Criar 1.16.0-1.16.5, 1.28.0-1.28.100

    Durante a criação do cluster, se não especificar um nome de anfitrião para cada endereço IP no ficheiro de bloco de IP, a verificação prévia falha com a seguinte mensagem de erro: 

    multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`

    Existe um erro na verificação prévia que assume que o nome de anfitrião vazio é duplicado.

    Solução alternativa:

    Opção 1: use uma versão com a correção.

    Opção 2: ignore esta verificação prévia adicionando a flag --skip-validation-net-config.

    Opção 3: especifique um nome de anfitrião único para cada endereço IP no ficheiro de blocos de IP.
    Atualizações 1.16

    Para um cluster de administrador não de HA e um cluster de utilizador do plano de controlo v1, quando atualiza o cluster de administrador, a recriação da máquina principal do cluster de administrador pode ocorrer ao mesmo tempo que o reinício da máquina principal do cluster de utilizador, o que pode revelar uma condição de corrida. Isto faz com que os pods do plano de controlo do cluster de utilizadores não consigam comunicar com o plano de controlo do cluster de administrador, o que causa problemas de associação de volumes para o kube-etcd e o kube-apiserver no plano de controlo do cluster de utilizadores.

    Para validar o problema, execute os seguintes comandos para o pod afetado:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
     São apresentados eventos como: 
    Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

    Solução alternativa:

    1. SSH para o nó do plano de controlo do utilizador, uma vez que é um cluster de utilizadores do plano de controlo v1, o nó do plano de controlo do utilizador está no cluster de administrador.
    2. Reinicie o kubelet com o seguinte comando: 
          sudo systemctl restart kubelet
      Após o reinício, o kubelet pode reconstruir a montagem global de preparação corretamente.
    Atualizações 1.16.0

    Durante uma atualização de um cluster de administrador, pode ocorrer uma condição de corrida que faça com que o gestor do controlador de nuvem do vSphere elimine inesperadamente um novo nó do plano de controlo. Isto faz com que o clusterapi-controller fique bloqueado a aguardar a criação do nó e, eventualmente, o tempo limite da atualização/atualização expire. Neste caso, o resultado do comando gkectl upgrade/update é semelhante ao seguinte:

        controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...

    Para identificar o sintoma, execute o comando abaixo para iniciar sessão no gestor do controlador da nuvem do vSphere no cluster de administrador:

        kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system

    Segue-se uma mensagem de erro de exemplo do comando acima:

        node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.

    Solução alternativa:

    1. Reinicie o computador com falhas para recriar o objeto de nó eliminado.
    2. Use SSH em cada nó do plano de controlo e reinicie o pod estático do gestor do controlador de nuvem do vSphere: 
            sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
    3. Volte a executar o comando de atualização.
    Operação 1.16

    A atualização de um cluster 1.15 ou a criação de um cluster 1.16 com IPs estáticos falha se existirem nomes de anfitrião duplicados no mesmo centro de dados. Esta falha ocorre porque o gestor do controlador da nuvem do vSphere não consegue adicionar um IP externo nem um ID do fornecedor no objeto do nó. Isto faz com que a atualização/criação do cluster exceda o tempo limite.

    Para identificar o problema, obtenha os registos do pod do gestor do controlador de nuvem do vSphere para o cluster. O comando que usa depende do tipo de cluster, da seguinte forma:

    • Cluster de administrador: 
            kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
    • Cluster de utilizadores com enableControlplaneV2 false: 
            kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
    • Cluster de utilizadores com enableControlplaneV2 true: 
            kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

    Segue-se uma mensagem de erro de exemplo:

        I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2

    Verifique se o nome de anfitrião está duplicado no centro de dados:

    Pode usar a seguinte abordagem para verificar se o nome de anfitrião está duplicado e fazer uma solução alternativa, se necessário. 
              export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
    Exemplos de comandos e resultados: 
              export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

    A solução alternativa que usa depende da operação que falhou.

    Solução alternativa para atualizações:

    Aplique a solução alternativa para o tipo de cluster aplicável.

    • Cluster de utilizadores:
      1. Atualize o nome do anfitrião da máquina afetada no ficheiro user-ip-block.yaml para um nome único e acione uma atualização forçada:
                  gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
      2. Repetir gkectl upgrade cluster
    • Cluster de administrador:
      1. Atualize o nome do anfitrião da máquina afetada no ficheiro admin-ip-block.yaml para um nome único e acione uma atualização forçada:
                  gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
      2. Se for um cluster de administrador não de HA e verificar que a VM principal do administrador está a usar um nome de anfitrião duplicado, também tem de:
        Obter o nome da máquina principal do administrador 
                  kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
        Atualize o objeto da máquina principal do administrador
        Nota: o NEW_ADMIN_MASTER_HOSTNAME deve ser igual ao que definiu em admin-ip-block.yaml no passo 1.
                  kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
        Verifique se o nome do anfitrião está atualizado no objeto da máquina principal do administrador:
                  kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
      3. Volte a executar a atualização do cluster de administrador com o ponto de verificação desativado:
                  gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

    Solução alternativa para instalações:

    Aplique a solução alternativa para o tipo de cluster aplicável.
    Operação 1.16.0, 1.16.1, 1.16.2 e 1.16.3

    As seguintes operações falham quando o nome de utilizador ou a palavra-passe do vSphere contém $ ou `:

    • Atualizar um cluster de utilizador 1.15 com o Controlplane V2 ativado para 1.16
    • Atualizar um cluster de administrador de alta disponibilidade (HA) 1.15 para 1.16
    • Criar um cluster de utilizadores 1.16 com o Controlplane V2 ativado
    • Criar um cluster de administrador de HA 1.16

    Use uma versão 1.16.4 ou superior do Google Distributed Cloud com a correção ou execute a solução alternativa abaixo. A solução alternativa que usa depende da operação que falhou.

    Solução alternativa para atualizações:

    1. Altere o nome de utilizador ou a palavra-passe do vCenter no lado do vCenter para remover o $ e o `.
    2. Atualize o nome de utilizador ou a palavra-passe do vCenter no ficheiro de configuração de credenciais.
    3. Acionar uma atualização forçada do cluster.
      • Cluster de utilizadores: 
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
      • Cluster de administrador: 
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

    Solução alternativa para instalações:

    1. Altere o nome de utilizador ou a palavra-passe do vCenter no lado do vCenter para remover o $ e o `.
    2. Atualize o nome de utilizador ou a palavra-passe do vCenter no ficheiro de configuração de credenciais.
    3. Aplique a solução alternativa para o tipo de cluster aplicável.
    Armazenamento 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

    Depois de um nó ser eliminado e, em seguida, recriado com o mesmo nome do nó, existe uma ligeira probabilidade de que uma criação subsequente de PersistentVolumeClaim (PVC) falhe com um erro semelhante ao seguinte:

        The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

    Isto é causado por uma condição de corrida em que o controlador CSI do vSphere não elimina uma máquina removida da respetiva cache.


    Solução alternativa:

    Reinicie os pods do controlador CSI do vSphere:

        kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    Operação 1.16.0

    Quando executa o comando gkectl repair admin-master num cluster de administrador de HA, o gkectl devolve a seguinte mensagem de erro: 

      Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context

    Solução alternativa:

    Adicione a flag --admin-master-vm-template= ao comando e forneça o modelo de VM da máquina a reparar: 

      gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME

    Para encontrar o modelo de VM da máquina:

    1. Aceda à página Hosts and Clusters no cliente vSphere.
    2. Clique em Modelos de VMs e filtre pelo nome do cluster de administrador.

      Deve ver os três modelos de VMs para o cluster de administrador.

    3. Copie o nome do modelo de VM que corresponde ao nome da máquina que está a reparar e use o nome do modelo no comando de reparação.
      gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
    Redes 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

    Se usar o Seesaw como o tipo de equilibrador de carga para o seu cluster e vir que uma VM do Seesaw está inativa ou continua a falhar ao arrancar, pode ver a seguinte mensagem de erro na consola do vSphere:

        GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

    Este erro indica que o espaço em disco é baixo na VM porque o fluent-bit em execução na VM do Seesaw não está configurado com a rotação de registos correta.


    Solução alternativa:

    Localize os ficheiros de registo que consomem a maior parte do espaço em disco através de du -sh -- /var/lib/docker/containers/* | sort -rh. Limpe o ficheiro de registo com o maior tamanho e reinicie a VM.

    Nota: se a VM estiver completamente inacessível, anexe o disco a uma VM funcional (por exemplo, uma estação de trabalho de administrador), remova o ficheiro do disco anexado e, em seguida, volte a anexar o disco à VM do Seesaw original.

    Para evitar que o problema volte a ocorrer, estabeleça ligação à VM e modifique o ficheiro /etc/systemd/system/docker.fluent-bit.service. Adicione --log-opt max-size=10m --log-opt max-file=5 no comando Docker e, em seguida, execute systemctl restart docker.fluent-bit.service
    Operação 1.13, 1.14.0-1.14.6, 1.15

    Quando tenta atualizar (gkectl upgrade admin) ou atualizar (gkectl update admin) um cluster de administrador sem elevada disponibilidade com o ponto de verificação ativado, a atualização pode falhar com erros como os seguintes: 

    Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).
     
    failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)
     
    error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...


    Solução alternativa:

    Se não conseguir atualizar para uma versão de patch do Google Distributed Cloud com a correção, contacte o Apoio técnico da Google para receber assistência.
    Atualizações 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

    Quando um cluster de administrador está inscrito na API GKE On-Prem, a atualização do cluster de administrador para as versões afetadas pode falhar porque não foi possível atualizar a associação da frota. Quando esta falha ocorre, é apresentado o seguinte erro ao tentar atualizar o cluster:

        failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

    Um cluster de administrador é inscrito na API quando inscreve explicitamente o cluster ou quando atualiza um cluster de utilizador através de um cliente da API GKE On-Prem.


    Solução alternativa:

    Anule a inscrição do cluster de administrador: 
        gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    e retome a atualização do cluster de administrador. Pode ver temporariamente o erro obsoleto "failed to register cluster" (não foi possível registar o cluster). Após algum tempo, deve ser atualizado automaticamente.
    Atualizações 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

    Quando um cluster de administrador está inscrito na API GKE On-Prem, a respetiva anotação de link de recurso é aplicada ao recurso personalizado OnPremAdminCluster, que não é preservado durante as atualizações posteriores do cluster de administrador devido à utilização da chave de anotação incorreta. Isto pode fazer com que o cluster de administrador seja inscrito novamente na API GKE On-Prem por engano.

    Um cluster de administrador é inscrito na API quando inscreve explicitamente o cluster ou quando atualiza um cluster de utilizador através de um cliente da API GKE On-Prem.


    Solução alternativa:

    Anule a inscrição do cluster de administrador: 
        gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    e volte a inscrever o cluster de administrador.
    Redes 1.15.0-1.15.2

    OrderPolicy não é reconhecido como um parâmetro e não é usado. Em alternativa, o Google Distributed Cloud usa sempre Random.

    Este problema ocorre porque o modelo CoreDNS não foi atualizado, o que faz com que orderPolicy seja ignorado.


    Solução alternativa:

    Atualize o modelo CoreDNS e aplique a correção. Esta correção persiste até uma atualização.

    1. Edite o modelo existente: 
      kubectl edit cm -n kube-system coredns-template
       Substitua o conteúdo do modelo pelo seguinte: 
      coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
    Atualizações 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

    Determinadas condições de concorrência podem fazer com que o estado OnPremAdminCluster seja inconsistente entre o ponto de verificação e o CR real. Quando o problema ocorre, pode encontrar o seguinte erro ao atualizar o cluster de administrador depois de o ter atualizado:

    Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
     Para contornar este problema, tem de editar o ponto de verificação ou desativá-lo para a atualização. Contacte a nossa equipa de apoio técnico para continuar com a solução alternativa.
    Operação 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    O Google Distributed Cloud altera os certificados de administrador nos planos de controlo do cluster de administrador com cada processo de conciliação, como durante uma atualização do cluster. Este comportamento aumenta a possibilidade de obter certificados inválidos para o cluster de administrador, especialmente para clusters da versão 1.15.

    Se for afetado por este problema, pode deparar-se com problemas como os seguintes:

    • Os certificados inválidos podem fazer com que os seguintes comandos excedam o tempo limite e devolvam erros:
      • gkectl create admin
      • gkectl upgrade amdin
      • gkectl update admin

      Estes comandos podem devolver erros de autorização, como os seguintes:

      Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
    • Os registos kube-apiserver do cluster de administrador podem conter erros como os seguintes: 
      Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

    Solução alternativa:

    Atualize para uma versão do Google Distributed Cloud com a correção: 1.13.10+, 1.14.6+, 1.15.2+. Se a atualização não for viável para si, contacte o apoio ao cliente do Google Cloud para resolver este problema.
    Trabalhar em rede, operação 1.10, 1.11, 1.12, 1.13, 1.14

    Os pods de gateway de rede em kube-system podem apresentar um estado de Pending ou Evicted, conforme mostrado no seguinte exemplo de resultado condensado:

    $ 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

    Estes erros indicam eventos de despejo ou a impossibilidade de agendar pods devido a recursos de nós. Como os pods do Anthos Network Gateway não têm PriorityClass, têm a mesma prioridade predefinida que outras cargas de trabalho. Quando os nós têm restrições de recursos, os pods de gateway de rede podem ser despejados. Este comportamento é particularmente prejudicial para o ang-node DaemonSet, uma vez que esses pods têm de ser agendados num nó específico e não podem migrar.


    Solução alternativa:

    Atualize para a versão 1.15 ou posterior.

    Como solução a curto prazo, pode atribuir manualmente uma PriorityClass aos componentes do Anthos Network Gateway. O controlador do Google Distributed Cloud substitui estas alterações manuais durante um processo de conciliação, como durante uma atualização do cluster.

    • Atribua o system-cluster-critical PriorityClass ao cluster ang-controller-manager e às implementações do controlador autoscaler.
    • Atribua a system-node-critical PriorityClass ao DaemonSet do nó ang-daemon.
    Atualizações 1.12, 1.13, 1.14, 1.15.0-1.15.2

    Depois de usar gcloud para registar um cluster de administrador com a secção gkeConnect não vazia, pode ver o seguinte erro ao tentar atualizar o 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

    Elimine o espaço de nomes gke-connect: 

    kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
     Obtenha o nome do cluster de administrador: 
    kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
     Elimine a subscrição da frota: 
    gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
     e retome a atualização do cluster de administrador.
    Operação 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

    O gkectl diagnose snapshot --log-since não consegue limitar o período para os comandos journalctl executados nos nós do cluster

    Isto não afeta a funcionalidade de tirar uma captura instantânea do cluster, uma vez que a captura instantânea continua a incluir todos os registos recolhidos por predefinição através da execução de journalctl nos nós do cluster. Por conseguinte, não perde informações de depuração.
    Instalação, atualizações e atualizações 1.9+, 1.10+, 1.11+, 1.12+

    A instalação do Docker falha nas versões do Google Distributed Cloud anteriores à 1.13 porque MicrosoftDockerProvider está obsoleto.gkectl prepare windows


    Solução alternativa:

    A ideia geral para contornar este problema é atualizar para o Google Distributed Cloud 1.13 e usar a versão 1.13 gkectl para criar um modelo de VM do Windows e, em seguida, criar pools de nós do Windows. Existem duas opções para aceder ao Google Distributed Cloud 1.13 a partir da sua versão atual, conforme mostrado abaixo.

    Nota: temos opções para contornar este problema na sua versão atual sem ter de atualizar até à versão 1.13, mas são necessários mais passos manuais. Contacte a nossa equipa de apoio técnico se quiser considerar esta opção.


    Opção 1: atualização azul/verde

    Pode criar um novo cluster com a versão 1.13 ou superior do Google Distributed Cloud com pools de nós do Windows e migrar as suas cargas de trabalho para o novo cluster e, em seguida, desativar o cluster atual. Recomendamos que use a versão secundária mais recente do Google Distributed Cloud.

    Nota: isto requer recursos adicionais para aprovisionar o novo cluster, mas reduz o tempo de inatividade e a interrupção das cargas de trabalho existentes.


    Opção 2: elimine os node pools do Windows e volte a adicioná-los quando atualizar para o Google Distributed Cloud 1.13

    Nota: para esta opção, as cargas de trabalho do Windows não podem ser executadas até que o cluster seja atualizado para a versão 1.13 e os conjuntos de nós do Windows sejam adicionados novamente.

    1. Elimine os node pools do Windows existentes removendo a configuração dos node pools do Windows do ficheiro user-cluster.yaml e, em seguida, execute o comando: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    2. Atualize os clusters de administrador e utilizador apenas do Linux para a versão 1.12 seguindo o manual de atualização para a versão secundária de destino correspondente.
    3. (Certifique-se de que executa este passo antes de atualizar para a versão 1.13) Certifique-se de que o enableWindowsDataplaneV2: true está configurado no CR OnPremUserCluster. Caso contrário, o cluster vai continuar a usar o Docker para os conjuntos de nós do Windows, que não sã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 configurada ou estiver definida como falsa, atualize o cluster para a definir como verdadeira em user-cluster.yaml e, em seguida, execute: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    4. Atualize os clusters de administrador e utilizador apenas do Linux para a versão 1.13 seguindo o guia de atualização.
    5. Prepare o modelo de VM do Windows com o gkectl 1.13: 
      gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
    6. Adicione novamente a configuração do node pool do Windows ao user-cluster.yaml com o campo OSImage definido para o modelo de VM do Windows recém-criado.
    7. Atualize o cluster para adicionar node pools do Windows 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    Instalação, atualizações e atualizações 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    O valor predefinido de 5 segundos para RootDistanceMaxSec vai ser usado nos nós, em vez de 20 segundos, que deve ser a configuração esperada. Se verificar o registo de arranque do nó através de SSH na VM, que se encontra em `/var/log/startup.log`, pode encontrar o seguinte erro:

    + has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

    A utilização de 5 segundos RootDistanceMaxSec pode fazer com que o relógio do sistema fique dessincronizado com o servidor NTP quando o desvio do relógio for superior a 5 segundos.


    Solução alternativa:

    Aplique o seguinte DaemonSet ao seu cluster para configurar o RootDistanceMaxSec:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
    Atualizações 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Quando usa a versão 1.13 gkectl para atualizar um cluster de administrador da versão 1.12, pode 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"

    Quando usa gkectl update admin para clusters da versão 1.13 ou 1.14, pode 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 verificar o registo gkectl, pode ver que as várias alterações incluem a definição de osImageType de uma string vazia para ubuntu_containerd.

    Estes erros de atualização devem-se ao preenchimento incorreto do campo osImageType na configuração do cluster de administração, uma vez que foi introduzido na versão 1.9.


    Solução alternativa:

    Atualize para uma versão do Google Distributed Cloud com a correção. Se a atualização não for viável para si, contacte o apoio ao cliente do Google Cloud para resolver este problema.
    Instalação, segurança 1.13, 1.14, 1.15 e 1.16

    A capacidade de fornecer um certificado de publicação adicional para o servidor da API Kubernetes de um cluster de utilizador com authentication.sni não funciona quando o Controlplane V2 está ativado ( enableControlplaneV2: true).


    Solução alternativa:

    Até que esteja disponível um patch do Google Distributed Cloud com a correção, se precisar de usar o 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

    A máquina do plano de controlo do administrador não é iniciada quando o nome de utilizador do registo privado contém $. Quando verifica o /var/log/startup.log na máquina do plano de controlo do administrador, vê o seguinte erro: 

    ++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

    Solução alternativa:

    Use um nome de utilizador do registo privado sem $ ou use uma versão do Google Distributed Cloud com a correção.
    Atualizações 1.12.0-1.12.4

    Quando atualiza os clusters de administrador, vê os seguintes avisos de falsos positivos no registo, que pode ignorar. 

        console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      -         CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      +         CARotation:        nil,
      ...
    }
    Atualizações 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    Depois de rodar as chaves de assinatura da KSA e, posteriormente, atualizar um cluster de utilizadores, 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"


    Solução alternativa:

    Altere a versão da chave de assinatura da KSA novamente para 1, mas mantenha os dados da chave mais recentes:
    1. Verifique o segredo no cluster de administrador no espaço de nomes USER_CLUSTER_NAME e obtenha o nome do segredo ksa-signing-key: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
    2. Copie o segredo da chave de assinatura da KSA e atribua o nome service-account-cert ao segredo copiado: 
      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 -
    3. Elimine o segredo da chave de assinatura ksa anterior: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
    4. 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
    5. 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
'
    6. 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
    7. Aguarde até o cluster de utilizadores de destino estar pronto. Pode verificar o estado da seguinte forma: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
    8. Restaure o webhook de validação para o cluster de utilizadores: 
      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
'
    9. Evite outra rotação da chave de assinatura da KSA até o cluster ser atualizado para a versão com a correção.
    Operação 1.13.1+, 1.14, 1., 1.16

    Quando usa o Terraform para eliminar um cluster de utilizadores com um balanceador de carga F5 BIG-IP, os servidores virtuais F5 BIG-IP não são removidos após a eliminação do cluster.


    Solução alternativa:

    Para remover os recursos do F5, siga os passos para limpar uma partição do F5 de um cluster de utilizadores

    Instalação, atualizações e atualizações 1.13.8 e 1.14.4

    Se criar um cluster de administrador da versão 1.13.8 ou 1.14.4, ou atualizar um cluster de administrador para a versão 1.13.8 ou 1.14.4, o cluster kind extrai as seguintes imagens de contentores 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 a partir da sua estação de trabalho de administrador, a criação ou a atualização do cluster de administrador não consegue apresentar o cluster do tipo. A execução do seguinte comando na estação de trabalho de administração mostra os contentores pendentes correspondentes com ErrImagePull:

    docker exec gkectl-control-plane kubectl get pods -A

    A resposta contém entradas como as seguintes:

    ...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Estas imagens de contentores devem ser pré-carregadas na imagem do contentor do cluster do tipo. No entanto, o kind v0.18.0 tem um problema com as imagens de contentores pré-carregadas, o que faz com que sejam extraídas da Internet por engano.


    Solução alternativa:

    Execute os seguintes comandos na estação de trabalho do administrador enquanto o cluster de administrador estiver pendente de criação ou atualização:

    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

    Se as VMs do cluster estiverem ligadas a um comutador que filtra pedidos GARP (ARP gratuito) duplicados, a eleição do líder do keepalived pode encontrar uma condição de corrida, o que faz com que alguns nós tenham entradas incorretas na tabela ARP.

    Os nós afetados podem ping o VIP do plano de controlo, mas uma ligação TCP ao VIP do plano de controlo vai atingir o limite de tempo.


    Solução alternativa:

    Execute o seguinte comando em cada nó do plano de controlo do cluster afetado: 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Atualizações 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    vsphere-csi-controller deve atualizar o respetivo segredo do vCenter após a rotação do certificado do vCenter. No entanto, o sistema atual não reinicia corretamente os pods do vsphere-csi-controller, o que faz com que o vsphere-csi-controller falhe após a rotação.

    Solução alternativa:

    Para clusters criados na versão 1.13 e posteriores, siga as instruções abaixo para reiniciar o 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

    Mesmo quando o registo do cluster falha durante a criação do cluster de administrador, o comando gkectl create admin não falha no erro e pode ter êxito. Por outras palavras, a criação do cluster de administrador pode "ter êxito" sem estar registada numa frota.

    Para identificar o sintoma, pode procurar as seguintes mensagens de erro no registo de `gkectl create admin`: 
    Failed to register admin cluster

    Também pode verificar se consegue encontrar o cluster entre os clusters registados na consola da nuvem.

    Solução alternativa:

    Para clusters criados nas versões 1.12 e posteriores, siga as instruções para tentar novamente o registo do cluster de administrador após a criação do cluster. Para clusters criados em versões anteriores:

    1. Anexe um par de chave-valor falso, como "foo: bar", ao ficheiro de chave de SA connect-register
    2. Execute gkectl update admin para voltar a registar o cluster de administrador.

    Atualizações 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Durante a atualização do cluster de administrador, se a atualização dos nós do plano de controlo do utilizador exceder o tempo limite, o cluster de administrador não é registado novamente com a versão atualizada do agente Connect.


    Solução alternativa:

    Verifique se o cluster é apresentado entre os clusters registados. Como passo opcional, inicie sessão no cluster após configurar a autenticação. Se o cluster ainda estiver registado, pode ignorar as instruções seguintes para tentar novamente o registo. Para clusters atualizados para a versão 1.12 e posteriores, siga as instruções para tentar novamente o registo do cluster de administrador após a criação do cluster. Para clusters atualizados para versões anteriores,
    1. Anexe um par de chave-valor falso, como "foo: bar", ao ficheiro de chave de SA connect-register
    2. Execute gkectl update admin para voltar a registar o cluster de administrador.

    Configuração 1.15.0

    Para um cluster de administrador de alta disponibilidade, o comando gkectl prepare mostra esta mensagem de erro falsa:

    vCenter.dataDisk must be present in the AdminCluster spec

    Solução alternativa:

    Pode ignorar esta mensagem de erro com segurança.
    VMware 1.15.0

    Durante a criação de um conjunto de nós que usa a afinidade VM-anfitrião, pode ocorrer uma condição de concorrência que resulte na criação de várias regras de afinidade VM-anfitrião com o mesmo nome. Isto pode fazer com que a criação do node pool falhe.


    Solução alternativa:

    Remova as regras redundantes antigas para que a criação do node pool possa prosseguir. Estas regras têm o nome [USER_CLUSTER_NAME]-[HASH].
    Operação 1.15.0

    O comando gkectl repair admin-master pode falhar devido a uma condição de corrida com o seguinte erro. 

    Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Solução alternativa:

    Este comando é idempotente. Pode ser executado novamente em segurança até que o comando seja bem-sucedido.
    Atualizações 1.15.0

    Depois de recriar ou atualizar um nó do plano de controlo, determinados pods podem ficar no estado Failed devido a uma falha do predicado NodeAffinity. Estes pods com falhas não afetam o funcionamento normal nem o estado do cluster.


    Solução alternativa:

    Pode ignorar com segurança os pods com falhas ou eliminá-los manualmente.
    Segurança, configuração 1.15.0-1.15.1

    Se usar credenciais preparadas e um registo privado, mas não tiver configurado credenciais preparadas para o seu registo privado, o OnPremUserCluster pode não ficar pronto e pode ver a seguinte mensagem de erro: 

    failed to check secret reference for private registry …


    Solução alternativa:

    Prepare as credenciais do registo privado para o cluster de utilizadores de acordo com as instruções em Configure credenciais preparadas.

    Atualizações 1.15.0

    Durante a gkectl upgrade admin, a verificação prévia do armazenamento para a migração de CSI verifica se as StorageClasses não têm parâmetros que são ignorados após a migração de CSI. Por exemplo, se existir uma StorageClass com o parâmetro diskformat, então gkectl upgrade admin marca a StorageClass e comunica uma falha na validação prévia. Os clusters de administrador criados no Google Distributed Cloud 1.10 e versões anteriores têm uma StorageClass com diskformat: thin que falha esta validação. No entanto, esta StorageClass continua a funcionar bem após a migração do CSI. Em alternativa, estas falhas devem ser interpretadas como avisos.

    Para mais informações, consulte a secção de parâmetros StorageClass em Migrar volumes vSphere no kernel para o plug-in de armazenamento de contentores vSphere.


    Solução alternativa:

    Depois de confirmar que o cluster tem uma StorageClass com parâmetros ignorados após a migração do CSI, execute gkectl upgrade admin com a flag --skip-validation-cluster-health.
    Armazenamento 1.15 e 1.16

    Em determinadas condições, os discos podem ser anexados como só de leitura a nós do Windows. Isto resulta no volume correspondente ser apenas de leitura num pod. Este problema tem maior probabilidade de ocorrer quando um novo conjunto de nós substitui um conjunto de nós antigo (por exemplo, atualização do cluster ou atualização do node pool). As cargas de trabalho com estado que funcionavam bem anteriormente podem não conseguir escrever nos respetivos volumes no novo conjunto de nós.


    Solução alternativa:

    1. Obtenha o UID do pod que não consegue escrever no respetivo volume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Use o PersistentVolumeClaim para obter o nome do PersistentVolume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determine o nome do nó onde o pod está a ser executado: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Obtenha acesso ao Powershell no nó através de SSH ou da interface Web do vSphere.
    5. Defina variáveis de ambiente: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. 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
    7. Confirme se o disco está readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
       O resultado deve ser True.
    8. Defina readonly como false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Elimine o Pod para que seja reiniciado: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. O pod deve ser agendado para o mesmo nó. No entanto, caso o pod seja agendado para um novo nó, pode ter de repetir os passos anteriores no novo nó.

    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 atualizar as credenciais do vSphere para um cluster de administrador após atualizar as credenciais do cluster, pode verificar que vsphere-csi-secret no espaço de nomes kube-system no cluster de administrador continua a usar a credencial antiga.


    Solução alternativa:

    1. Obtenha o nome do Secret vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Atualize os dados da chave secreta vsphere-csi-secret que obteve no passo 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 \
    )\"}}"
    3. Reiniciar vsphere-csi-controller: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Pode acompanhar o estado da implementação com: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Após a implementação ser implementada com êxito, o controlador deve usar o vsphere-csi-secret atualizado.
    Atualizações 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    O audit-proxy pode entrar em ciclo de falhas devido a --cluster-name vazios. Este comportamento é causado por um erro na lógica de atualização, em que o nome do cluster não é propagado para o manifesto do pod / contentor audit-proxy.


    Solução alternativa:

    Para um cluster de utilizador do plano de controlo v2 com enableControlplaneV2: true, ligue-se à máquina do plano de controlo do utilizador através de SSH e atualize /etc/kubernetes/manifests/audit-proxy.yaml com --cluster_name=USER_CLUSTER_NAME.

    Para um cluster de utilizador do plano de controlo v1, edite o contentor audit-proxy no conjunto com estado kube-apiserver para adicionar --cluster_name=USER_CLUSTER_NAME:

    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Atualizações 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    Imediatamente após gkectl upgrade cluster, os pods do plano de controlo podem ser implementados novamente. O estado do cluster de gkectl list clusters foi alterado de RUNNING PARA RECONCILING. Os pedidos ao cluster de utilizadores podem exceder o limite de tempo.

    Este comportamento deve-se ao facto de a rotação do certificado do plano de controlo ocorrer automaticamente após gkectl upgrade cluster.

    Este problema só acontece com clusters de utilizadores que NÃO usam o plano de controlo v2.


    Solução alternativa:

    Aguarde que o estado do cluster volte a mudar para RUNNING em gkectl list clusters ou atualize para versões com a correção: 1.13.6+, 1.14.2+ ou 1.15+.
    Atualizações 1.12.7

    O Google Distributed Cloud 1.12.7-gke.19 é uma versão má e não deve usá-la. Os artefactos foram removidos do contentor do Cloud Storage.

    Solução alternativa:

    Em alternativa, use a versão 1.12.7-gke.20.
    Atualizações 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    Se atualizar a credencial de registo através de um dos seguintes métodos:

    • gkectl update credentials componentaccess se não usar o registo privado
    • gkectl update credentials privateregistry se usar o registo privado

    pode verificar que o gke-connect-agent continua a usar a imagem mais antiga ou que os pods do gke-connect-agent não podem ser apresentados devido a ImagePullBackOff.

    Este problema vai ser corrigido nas versões 1.13.8, 1.14.4 e subsequentes do Google Distributed Cloud.


    Solução alternativa:

    Opção 1: reimplemente o gke-connect-agent manualmente:

    1. Elimine o espaço de nomes gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Volte a implementar gke-connect-agent com a chave da conta de serviço de registo original (não é necessário atualizar a chave):

      Para o cluster de administração: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
       Para o cluster de utilizadores: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opção 2: pode alterar manualmente os dados do segredo de obtenção de imagens regcred que é usado pela implementação 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: pode adicionar o segredo de obtenção de imagens predefinido para o seu cluster na implementação gke-connect-agent da seguinte forma:

    1. Copie o segredo predefinido para o espaço de nomes 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 -
    2. Obtenha o gke-connect-agentnome da implementação: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Adicione o segredo predefinido à implementaçã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

    Quando valida a configuração antes de criar um cluster com o balanceador de carga manual executando gkectl check-config, o comando falha com as seguintes mensagens de erro.

     - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

    Solução alternativa:

    Opção 1: pode usar a versão de patch 1.13.7 e 1.14.4 que inclui a correção.

    Opção 2: também pode executar o mesmo comando para validar a configuração, mas ignorar a validação do equilibrador 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

    Os clusters que executam a versão 3.4.13 ou anterior do etcd podem sofrer de falta de recursos de observação e observações de recursos não operacionais, o que pode originar os seguintes problemas:

    • O agendamento de pods está interrompido
    • Os nós não conseguem registar-se
    • O kubelet não observa as alterações dos pods

    Estes problemas podem tornar o cluster não funcional.

    Este problema foi corrigido nas versões 1.12.7, 1.13.6, 1.14.3 e posteriores do Google Distributed Cloud. Estas versões mais recentes usam a versão 3.4.21 do etcd. Todas as versões anteriores do Google Distributed Cloud são afetadas por este problema.

    Solução alternativa

    Se não puder atualizar imediatamente, pode mitigar o risco de falha do cluster reduzindo o número de nós no cluster. Remova nós até que a métrica etcd_network_client_grpc_sent_bytes_total seja inferior a 300 MBps.

    Para ver esta métrica no Explorador de métricas:

    1. Aceda ao Explorador de métricas na Google Cloud consola:

      Aceda ao Metrics Explorer

    2. Selecione o separador Configuração.
    3. Expanda Selecionar uma métrica, introduza Kubernetes Container na barra de filtros e, de seguida, use os submenus para selecionar a métrica:
      1. No menu Recursos ativos, selecione Recipiente do Kubernetes.
      2. No menu Categorias de métricas ativas, selecione Anthos.
      3. No menu Métricas ativas, selecione etcd_network_client_grpc_sent_bytes_total.
      4. Clique em Aplicar.
    Atualizações 1.10, 1.11, 1.12, 1.13 e 1.14

    Em reinícios ou atualizações de clusters, o GKE Identity Service pode ficar sobrecarregado com tráfego composto por tokens JWT expirados encaminhados do kube-apiserver para o GKE Identity Service através do webhook de autenticação. Embora o GKE Identity Service não entre em crashloop, deixa de responder e deixa de processar pedidos adicionais. Este problema acaba por levar a latências mais elevadas do plano de controlo.

    Este problema está corrigido nas seguintes versões do Google Distributed Cloud:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Para determinar se é afetado por este problema, siga estes passos:

    1. Verifique se o ponto final do serviço de identidade do GKE é acessível 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 pelo VIP do painel de controlo e pela porta do equilibrador de carga do painel de controlo do seu cluster (por exemplo, 172.16.20.50:443).

      Se for afetado por este problema, o comando devolve um código de estado 400. Se o pedido expirar, reinicie o ais Pod e volte a executar o comando curl para ver se isso resolve o problema. Se receber um código de estado 000, o problema foi resolvido e não tem de fazer mais nada. Se continuar a receber um código de estado 400, o servidor HTTP do serviço de identidade do GKE não está a ser iniciado. Neste caso, continue.

    2. Verifique os registos do serviço de identidade do GKE e do kube-apiserver:
      1. Verifique o registo do GKE Identity Service: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Se o registo contiver uma entrada semelhante à seguinte, significa que é afetado por este problema:

        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:
      2. Verifique os registos kube-apiserver dos seus clusters:

        Nos comandos seguintes, KUBE_APISERVER_POD é o nome do kube-apiserver Pod no cluster indicado.

        Cluster de administrador:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Cluster de utilizadores:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Se os registos kube-apiserver contiverem entradas semelhantes às seguintes, significa que é afetado por este problema:

        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]"

    Solução alternativa

    Se não conseguir atualizar imediatamente os clusters para obter a correção, pode identificar e reiniciar os pods ofensivos como solução alternativa:

    1. Aumente o nível de detalhe do serviço de identidade do GKE 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
    2. Verifique o registo do serviço de identidade do GKE para ver o contexto do token inválido: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Para obter a carga útil do token associada a cada contexto de token inválido, analise cada segredo da conta de serviço relacionada com o seguinte comando: 
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Para descodificar o token e ver o nome e o espaço de nomes do pod de origem, copie o token para o depurador em jwt.io.
    5. Reinicie os pods identificados a partir dos tokens.
    Operação 1.8, 1.9 e 1.10

    Os pods de manutenção do etcd que usam a imagem etcddefrag:gke_master_etcddefrag_20210211.00_p0 são afetados. O contentor `etcddefrag` abre uma nova ligação ao servidor etcd durante cada ciclo de desfragmentação e as ligações antigas não são limpas.


    Solução alternativa:

    Opção 1: atualize para a versão de patch mais recente de 1.8 para 1.11, que contém a correção.

    Opção 2: se estiver a usar uma versão de patch anterior a 1.9.6 e 1.10.3, tem de reduzir o pod etcd-maintenance para o cluster de administrador e de utilizador:

    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 e 1.13

    O controlador de funcionamento do cluster e o comando gkectl diagnose cluster executam um conjunto de verificações de funcionamento, incluindo as verificações de funcionamento dos pods em todos os espaços de nomes. No entanto, começam a ignorar os pods do plano de controlo do utilizador por engano. Se usar o modo de plano de controlo v2, isto não afeta o seu cluster.


    Solução alternativa:

    Isto não afeta nenhuma gestão de carga de trabalho ou cluster. Se quiser verificar o estado dos pods do plano de controlo, pode executar os seguintes comandos:

    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Atualizações 1.6+, 1.7+

    As atualizações do cluster de administrador 1.6 e 1.7 podem ser afetadas pelo redirecionamento k8s.gcr.io -> registry.k8s.io

    O Kubernetes redirecionou o tráfego de k8s.gcr.io para registry.k8s.io a 20/03/2023. No Google Distributed Cloud 1.6.x e 1.7.x, as atualizações do cluster de administrador usam a imagem do contentor k8s.gcr.io/pause:3.2. Se usar um proxy para a sua estação de trabalho de administrador e o proxy não permitir registry.k8s.io e a imagem do contentor k8s.gcr.io/pause:3.2 não estiver em cache localmente, as atualizações do cluster de administrador falham ao extrair a imagem do contentor.


    Solução alternativa:

    Adicione registry.k8s.io à lista de autorizações do proxy para a sua estação de trabalho de administrador.
    Redes 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    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

    Isto deve-se ao facto de o ficheiro do grupo de gangorra já existir. E a verificação prévia tenta validar um equilibrador de carga do Seesaw inexistente.

    Solução alternativa:

    Remova o ficheiro do grupo de gangorra existente para este cluster. O nome do ficheiro é seesaw-for-gke-admin.yaml para o cluster de administrador e seesaw-for-{CLUSTER_NAME}.yaml para um cluster de utilizador.
    Redes 1.14

    A versão 1.14 do Google Distributed Cloud é suscetível a falhas de inserção na tabela de registo de ligações (conntrack) do netfilter quando usa imagens do sistema operativo Ubuntu ou COS. As falhas de inserção originam limites de tempo aleatórios da aplicação e podem ocorrer mesmo quando a tabela conntrack tem espaço para novas entradas. As falhas são causadas por alterações no kernel 5.15 e superior que restringem as inserções de tabelas com base no comprimento da cadeia.

    Para ver se é afetado por este problema, pode verificar as estatísticas do sistema de monitorização de ligações no kernel em cada nó com o seguinte comando:

    sudo conntrack -S

    A resposta tem o seguinte aspeto:

    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 um valor chaintoolong na resposta for um número diferente de zero, significa que é afetado por este problema.

    Solução alternativa

    A mitigação a curto prazo consiste em aumentar o tamanho da tabela de hash do netfilter (nf_conntrack_buckets) e da tabela de acompanhamento de ligações do netfilter (nf_conntrack_max). Use os seguintes comandos em cada nó do 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 predefinido do tamanho da tabela é 262144. Sugerimos que defina um valor igual a 65 536 vezes o número de núcleos no nó. Por exemplo, se o seu nó tiver oito núcleos, defina o tamanho da tabela como 524288.
    Redes 1.13.0-1.13.2

    Com o Controlplane V2 ativado, o calico-typha ou o anetd-operator podem ser agendados para nós do Windows e entrar num ciclo de falhas.

    O motivo é que as duas implementações toleram todas as falhas, incluindo a falha do nó do Windows.


    Solução alternativa:

    Atualize para a versão 1.13.3 ou superior, ou execute os seguintes comandos para editar a implementação de `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

    Pode não conseguir criar um cluster de utilizadores se especificar a secção privateRegistry com a credencial fileRef. O pré-voo pode falhar com a seguinte mensagem: 

    [FAILURE] Docker registry access: Failed to login.


    Solução alternativa:

    • Se não pretendia especificar o campo ou quer usar a mesma credencial do registo privado que o cluster de administrador, pode simplesmente remover ou comentar a secção privateRegistry no ficheiro de configuração do cluster de utilizador.
    • Se quiser usar uma credencial de registo privado específica para o seu cluster de utilizadores, pode especificar temporariamente a secção privateRegistry da seguinte forma: 
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
       (NOTE: esta é apenas uma correção temporária e estes campos já estão obsoletos. Considere usar o ficheiro de credenciais quando atualizar para a versão 1.14.3 ou superior.)

    Operações 1.10+

    O plano de dados V2 assume o equilíbrio de carga e cria um socket do kernel em vez de um DNAT baseado em pacotes. Isto significa que o Cloud Service Mesh não pode fazer a inspeção de pacotes, uma vez que o pod é ignorado e nunca usa o IPTables.

    Isto manifesta-se no modo gratuito do kube-proxy pela perda de conetividade ou encaminhamento incorreto do tráfego para serviços com a Cloud Service Mesh, uma vez que o sidecar não consegue fazer a inspeção de pacotes.

    Este problema está presente em todas as versões do Google Distributed Cloud 1.10. No entanto, algumas versões mais recentes do 1.10 (1.10.2 ou superior) têm uma solução alternativa.


    Solução alternativa:

    Atualize para a versão 1.11 para ter compatibilidade total ou, se estiver a executar a versão 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, em seguida, reinicie o daemonset anetd:

          kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Armazenamento 1.12 ou superior, 1.13.3

    kube-controller-manager pode atingir o limite de tempo ao separar PV/PVCs após 6 minutos e separar os PV/PVCs à força. Registos 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 validar o problema, inicie sessão no nó e execute os seguintes comandos:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    No registo do kubelet, são apresentados erros como os seguintes:

    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

    Solução alternativa:

    Estabeleça ligação ao nó afetado através de SSH e reinicie o nó.
    Atualizações 1.12+, 1.13+, 1.14+

    Pode não conseguir atualizar um cluster se usar um controlador CSI de terceiros. O comando gkectl cluster diagnose pode devolver 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"


    Solução alternativa:

    Faça a atualização através da opção --skip-validation-all.
    Operação 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    O nó principal de administrador criado através de gkectl repair admin-master pode usar uma versão de hardware da VM inferior à esperada. Quando o problema ocorre, é apresentado 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.


    Solução alternativa:

    Encerre o nó principal do administrador, siga as instruções em https://kb.vmware.com/s/article/1003746 para atualizar o nó para a versão esperada descrita na mensagem de erro e, em seguida, inicie o nó.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, , 1.28+, 1.29+, 1.30+, 1.31+, 1.32+

    No systemd v244, systemd-networkd tem uma alteração do comportamento predefinido na configuração KeepConfiguration. Antes desta alteração, as VMs não enviavam uma mensagem de libertação de alocação de DHCP para o servidor DHCP no encerramento ou reinício. Após esta alteração, as VMs enviam uma mensagem deste tipo e devolvem os IPs ao servidor DHCP. Como resultado, o IP libertado pode ser reatribuído a uma VM diferente e/ou pode ser atribuído um IP diferente à VM, o que resulta num conflito de IP (ao nível do Kubernetes, não ao nível do vSphere) e/ou numa alteração do IP nas VMs, o que pode danificar os clusters de várias formas.

    Por exemplo, pode ver os seguintes sintomas.

    • A IU do vCenter mostra que nenhuma MV usa o mesmo IP, mas kubectl get nodes -o wide devolve 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
    • Os novos nós não são iniciados devido ao 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


    Solução alternativa:

    Implemente o seguinte DaemonSet no cluster para reverter a alteração do comportamento predefinido.systemd-networkd As VMs que executam este DaemonSet não libertam os IPs para o servidor DHCP no encerramento/reinício. Os IPs são libertados automaticamente pelo servidor DHCP quando os arrendamentos expiram. 

          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

    Funcionamento, atualizações e atualizações 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    Este problema só afeta clusters de administrador atualizados a partir da versão 1.11.x e não afeta clusters de administrador criados recentemente após a versão 1.12.

    Após atualizar um cluster 1.11.x para 1.12.x, o campo component-access-sa-key no segredo admin-cluster-creds é limpo e fica vazio. Pode verificar isto executando o seguinte comando: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
     Se o resultado estiver vazio, significa que a chave foi limpa.

    Depois de a chave da conta de serviço de acesso aos componentes ter sido eliminada, a instalação de novos clusters de utilizadores ou a atualização dos clusters de utilizadores existentes falha. Seguem-se algumas mensagens de erro que pode encontrar:

    • Falha na pré-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."
    • A preparação por gkectl prepare falhou com a mensagem de erro: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Se estiver a atualizar um cluster de utilizadores 1.13 através da Google Cloud consola ou da CLI gcloud, quando executar o comando gkectl update admin --enable-preview-user-cluster-central-upgrade para implementar o controlador da plataforma de atualização, o comando falha com a mensagem: "failed to download bundle to disk: dialing: unexpected end of JSON input" (pode ver esta mensagem no campo status na saída de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Solução alternativa:

    Adicione novamente a chave da conta de serviço de acesso ao componente ao segredo 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+

    Para clusters de utilizadores criados com o Controlplane V2 ativado, os node pools com o dimensionamento automático ativado usam sempre o respetivo autoscaling.minReplicas no user-cluster.yaml. O registo do pod do redimensionador automático de cluster mostra um erro semelhante ao seguinte: 

      > 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
    Pode encontrar o pod do redimensionador automático de clusters executando os seguintes comandos. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Solução alternativa:

    Desative a escala automática em todos os node pools com `gkectl update cluster` até fazer a atualização 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

    Quando os utilizadores usam CIDR no ficheiro de blocos de IP, a validação da 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


    Solução alternativa:

    Inclua IPs individuais no ficheiro de bloqueio de IPs até atualizar para uma versão com a correção: 1.12.5, 1.13.4, 1.14.1 ou superior.
    Atualizações 1.14.0-1.14.1

    Quando atualiza o tipo de imagem do SO do plano de controlo no admin-cluster.yaml e, se o cluster de utilizadores correspondente tiver sido criado com enableControlplaneV2 definido como true, as máquinas do plano de controlo do utilizador podem não concluir a respetiva recriação quando o comando gkectl terminar.


    Solução alternativa:

    Após a conclusão da atualização, continue a aguardar que as máquinas do plano de controlo do utilizador também concluam a respetiva recriação monitorizando os tipos de imagens do SO dos respetivos nós através do comando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Por exemplo, se estiver a atualizar do Ubuntu para o COS, devemos aguardar que todas as máquinas do plano de controlo mudem completamente do Ubuntu para o COS, mesmo depois de o comando de atualização estar concluído.

    Operação 1.10, 1.11, 1.12, 1.13 e 1.14.0

    Um problema com o Calico no Google Distributed Cloud 1.14.0 faz com que a criação e a eliminação de pods falhem com a seguinte mensagem de erro no resultado de kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Este problema só é observado 24 horas após a criação ou a atualização do cluster para a versão 1.14 com o Calico.

    Os clusters de administrador usam sempre o Calico, enquanto para o cluster de utilizador existe um campo de configuração `enableDataPlaneV2` em user-cluster.yaml. Se esse campo estiver definido como `false` ou não estiver especificado, significa que está a usar o Calico no cluster de utilizador.

    O contentor install-cni dos nós cria um kubeconfig com um token válido durante 24 horas. Este token tem de ser renovado periodicamente pelo pod calico-node. O calico-node Pod não consegue renovar o token porque não tem acesso ao diretório que contém o ficheiro kubeconfig no nó.


    Solução alternativa:

    Este problema foi corrigido na versão 1.14.1 do Google Distributed Cloud. Atualize para esta ou uma versão posterior.

    Se não puder atualizar imediatamente, aplique a seguinte correção no calico-node DaemonSet no cluster de administrador e de utilizador:

      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 o seguinte:
    • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
    • USER_CLUSTER_CONFIG_FILE: o caminho do ficheiro de configuração do cluster de utilizadores.
    Instalação 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    A criação do cluster falha apesar de o utilizador ter a configuração adequada. O utilizador vê a criação a falhar porque o cluster não tem IPs suficientes.


    Solução alternativa:

    Divida os CIDRs em vários blocos CIDR mais pequenos, como 10.0.0.0/30, que se torna 10.0.0.0/31, 10.0.0.2/31. Desde que existam N+1 CIDRs, em que N é o número de nós no cluster, isto deve ser suficiente.

    Funcionamento, atualizações e atualizações 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Quando a funcionalidade de encriptação de segredos sempre ativada está ativada juntamente com a cópia de segurança do cluster, a cópia de segurança do cluster de administrador não inclui as chaves de encriptação e a configuração necessárias para a funcionalidade de encriptação de segredos sempre ativada. Como resultado, a reparação do mestre de administrador com esta cópia de segurança através do gkectl repair admin-master --restore-from-backup provoca 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

    Funcionamento, atualizações e atualizações 1.10+

    Se a funcionalidade de encriptação de segredos sempre ativa não estiver ativada na criação do cluster, mas for ativada mais tarde através da operação gkectl update, a operação gkectl repair admin-master não consegue reparar o nó do plano de controlo do cluster de administrador. Recomendamos que a funcionalidade de encriptação de segredos sempre ativada esteja ativada na criação do cluster. Não existe mitigação atual.

    Atualizações 1.10

    A atualização do primeiro cluster de utilizadores de 1.9 para 1.10 pode recriar nós noutros clusters de utilizadores no mesmo cluster de administrador. A recriação é realizada de forma contínua.

    O disk_label foi removido de MachineTemplate.spec.template.spec.providerSpec.machineVariables, o que acionou inesperadamente uma atualização em todos os MachineDeployments.


    Solução alternativa:
    Atualizações 1.10.0

    A atualização do cluster de utilizadores para a versão 1.10.0 pode fazer com que o Docker seja reiniciado com frequência.

    Pode detetar este problema executando kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Uma condição do nó mostra se o Docker é reiniciado com frequência. Segue-se um exemplo de resultado:

    Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Para compreender a causa principal, tem de usar o SSH no nó que tem o sintoma e executar comandos como sudo journalctl --utc -u docker ou sudo journalctl -x


    Solução alternativa:
    Atualizações 1.11 e 1.12

    Se estiver a usar uma versão do Google Distributed Cloud inferior a 1.12 e tiver configurado manualmente componentes do Prometheus gerido pela Google (GMP) no espaço de nomes gmp-system para o seu cluster, os componentes não são preservados quando atualiza para a versão 1.12.x.

    A partir da versão 1.12, os componentes da GMP no espaço de nomes gmp-system e os CRDs são geridos pelo stackdriver objeto, com a flag enableGMPForApplications definida como false por predefinição. Se implementar manualmente componentes da GMP no espaço de nomes antes da atualização para a versão 1.12, os recursos são eliminados pelo stackdriver.


    Solução alternativa:
    Operação 1.11, 1.12, 1.13.0 - 1.13.1

    No cenário system, a imagem instantânea do cluster não inclui recursos no espaço de nomes default.

    No entanto, alguns recursos do Kubernetes, como objetos da API Cluster, que estão sob este espaço de nomes contêm informações de depuração úteis. O resumo do cluster deve incluí-los.


    Solução alternativa:

    Pode executar manualmente os seguintes comandos para recolher 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 ficheiro kubeconfig do cluster de utilizadores.
    Atualizações 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Ao eliminar, atualizar ou fazer uma atualização de um cluster de utilizadores, a drenagem de nós pode ficar bloqueada nos seguintes cenários:

    • O cluster de administrador usa o controlador CSI do vSphere no vSAN desde a versão 1.12.x e
    • Não existem objetos PVC/PV criados por plug-ins vSphere na árvore no cluster de administrador e de utilizador.

    Para identificar o sintoma, execute o comando abaixo:

    kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Segue-se uma mensagem de erro de exemplo 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 predefinido para o controlador in-tree do vSphere. Quando não existem objetos PVC/PV criados, pode deparar-se com um erro em que a drenagem de nós fica bloqueada na procura de kubevols, uma vez que a implementação atual pressupõe que kubevols existe sempre.


    Solução alternativa:

    Crie o diretório kubevols no arquivo de dados onde o nó é criado. Isto é definido no campo vCenter.datastore nos ficheiros 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

    Quando elimina um cluster de utilizador, os objetos clusterrole e clusterrolebinding correspondentes para o escalador automático de clusters também são eliminados. Isto afeta todos os outros clusters de utilizadores no mesmo cluster de administrador com o escalador automático de clusters ativado. Isto deve-se ao facto de o clusterrole e o clusterrolebinding serem usados para todos os pods do escalador automático de clusters no mesmo cluster de administrador.

    Os sintomas são os seguintes:

    • cluster-autoscaler registos
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
       onde ADMIN_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de administrador. Segue-se um exemplo de mensagens de erro que pode ver: 
      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

    Solução alternativa:

    Configuração 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Quando o cluster de utilizadores é eliminado, o clusterrole correspondente também é eliminado, o que resulta na reparação automática e no exportador de métricas do vSphere a não funcionar

    Os sintomas são os seguintes:

    • cluster-health-controller registos
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
       onde ADMIN_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de administrador. Segue-se um exemplo de mensagens de erro que pode ver: 
      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
    • vsphere-metrics-exporter registos
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
       onde ADMIN_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de administrador. Segue-se um exemplo de mensagens de erro que pode ver: 
      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"

    Solução alternativa:

    Configuração 1.12.1-1.12.3, 1.13.0-1.13.2

    Um problema conhecido que pode fazer com que o gkectl check-config falhe sem executar o gkectl prepare. Isto é confuso porque sugerimos que execute 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:[]}

    Solução alternativa:

    Opção 1: execute gkectl prepare para carregar as imagens do SO em falta.

    Opção 2: use gkectl check-config --skip-validation-os-images para ignorar a validação das imagens do SO.
    Atualizações 1.11, 1.12 e 1.13

    Um problema conhecido que pode fazer com que a gkectl update admin/cluster falhe 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

    Solução alternativa:
    Instalação, atualizações e atualizações 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    O registo do nó falha durante a criação, a atualização, a atualização e a reparação automática do nó do cluster quando ipMode.type é static e o nome do anfitrião configurado no ficheiro de bloco de IP contém um ou mais pontos. Neste caso, os pedidos de assinatura de certificados (CSR) para um nó não são aprovados automaticamente.

    Para ver os CSRs pendentes de um nó, execute o seguinte comando:

    kubectl get csr -A -o wide

    Verifique se existem mensagens de erro nos seguintes registos:

    • Veja os registos no cluster de administração do contentor 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 ver os mesmos registos no cluster de utilizadores, execute o seguinte comando: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
       where:
      • ADMIN_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de administração.
      • USER_CLUSTER_NAME é o nome do cluster de utilizadores.
      Segue-se um exemplo de mensagens de erro que pode ver: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Veja os registos kubelet no nó problemático: 
      journalctl --u kubelet
       Segue-se um exemplo de mensagens de erro que pode ver: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Se especificar um nome do domínio no campo de nome de anfitrião de um ficheiro de bloqueio de IP, todos os carateres após o primeiro ponto são ignorados. Por exemplo, se especificar o nome do anfitrião como bob-vm-1.bank.plc, o nome do anfitrião da VM e o nome do nó são definidos como bob-vm-1.

    Quando a validação do ID do nó está ativada, o aprovador do CSR compara o nome do nó com o nome do anfitrião na especificação da máquina e não consegue conciliar o nome. O aprovador rejeita o CSR e o nó não é inicializado.


    Solução alternativa:

    Cluster de utilizadores

    Desative a validação do ID do nó concluindo os seguintes passos:

    1. Adicione os seguintes campos no ficheiro de configuração do cluster de utilizadores: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Guarde o ficheiro e atualize o cluster de utilizadores executando o seguinte comando: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
       Substitua o seguinte:
      • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
      • USER_CLUSTER_CONFIG_FILE: o caminho do ficheiro de configuração do cluster de utilizadores.

    Cluster de administração

    1. Abra o recurso personalizado OnPremAdminCluster para edição: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Adicione a seguinte anotação ao recurso personalizado: 
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Edite o manifesto kube-controller-manager no plano de controlo do cluster de administrador:
      1. SSH para o nó do plano de controlo do cluster de administrador.
      2. Abra o manifesto kube-controller-manager para edição: 
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Encontre a lista de controllers: 
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Atualize esta secção conforme mostrado abaixo: 
        --controllers=*,bootstrapsigner,tokencleaner
    4. Abra o controlador da API Deployment Cluster para edição: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Altere 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, atualizações e atualizações 1.11.0-1.11.4

    A criação/atualização do cluster de administrador fica bloqueada no seguinte registo para sempre e, eventualmente, atinge o limite de tempo:

    Waiting for Machine gke-admin-master-xxxx to become ready...

    Na versão 1.11 da documentação, o registo do controlador da API Cluster no instantâneo do cluster externo inclui o seguinte registo:

    Invalid value 'XXXX' specified for property startup-data

    Segue-se um exemplo do caminho do ficheiro para o registo 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.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    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 estado NotHealthy impede que o controlador atribua IPs flutuantes adicionais ao nó. Isto pode resultar num encargo mais elevado noutros nós ou numa falta de redundância para alta disponibilidade.

    Caso contrário, a atividade do plano de dados não é afetada.

    A contenção no objeto networkgatewaygroup faz com que algumas atualizações de estado falhem devido a uma falha no processamento de novas tentativas. Se falharem demasiadas atualizações de estado, o ang-controller-manager considera que o nó excedeu o limite de tempo de sinal de vida e marca o nó como NotHealthy.

    A falha no processamento de novas tentativas foi corrigida em versões posteriores.


    Solução alternativa:

    Atualize para uma versão corrigida, quando disponível.
    Atualizações 1.12.0-1.12.2, 1.13.0

    Um problema conhecido que pode fazer com que a atualização do cluster fique bloqueada à espera que o objeto da máquina antiga seja eliminado. Isto deve-se ao facto de não ser possível remover o finalizador do objeto da máquina. Isto afeta qualquer operação de atualização contínua para conjuntos de nós.

    O sintoma é que o comando gkectl excede o tempo limite 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 registos de pods clusterapi-controller, os erros são semelhantes aos seguintes:

    $ 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 repete-se para a mesma máquina durante vários minutos para execuções bem-sucedidas, mesmo sem este problema. Na maioria das vezes, o processo é rápido, mas, em alguns casos raros, pode ficar bloqueado nesta condição de concorrência durante várias horas.

    O problema é que a VM subjacente já foi eliminada no vCenter, mas o objeto de máquina correspondente não pode ser removido, ficando bloqueado na remoção do finalizador devido a atualizações muito frequentes de outros controladores. Isto pode fazer com que o comando gkectl expire, mas o controlador continua a reconciliar o cluster para que o processo de atualização seja concluído.


    Solução alternativa:

    Preparámos várias opções de mitigação diferentes para este problema, que dependem do seu ambiente e requisitos.

    • Opção 1: aguarde até que a atualização seja concluída automaticamente.

      Com base na análise e na reprodução no seu ambiente, a atualização pode eventualmente terminar sozinha sem intervenção manual. A ressalva desta opção é que não se sabe quanto tempo vai demorar a remoção do finalizador para cada objeto de máquina. Pode ser concluído imediatamente, se tiver sorte, ou pode demorar várias horas se a reconciliação do controlador do conjunto de máquinas for demasiado rápida e o controlador da máquina nunca tiver a oportunidade de remover o finalizador entre as reconciliações.

      A boa notícia é que esta opção não requer qualquer ação da sua parte e as cargas de trabalho não vão ser interrompidas. Só precisa de mais tempo para concluir a atualização.
    • Opção 2: aplique a anotação de reparação automática a todos os objetos de aprendizagem automática antigos.

      O controlador do conjunto de máquinas filtra as máquinas que têm a anotação de reparação automática e a data/hora de eliminação diferentes de zero, e não continua a emitir chamadas de eliminação nessas máquinas. Isto pode ajudar a evitar a condição de concorrência.

      A desvantagem é que os pods nas máquinas são eliminados diretamente em vez de serem removidos, o que significa que não respeitam a configuração do PDB. Isto pode causar potencialmente tempo de inatividade para as suas cargas de trabalho.

      O comando para obter todos os nomes de máquinas: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
       O comando para aplicar a anotação de reparação automática a cada máquina: 
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Se tiver este problema e a atualização ainda não for concluída após um longo período, contacte a nossa equipa de apoio técnico para obter mitigações.
    Instalação, atualizações e atualizações 1.10.2, 1.11, 1.12 e 1.13

    O comando gkectl prepare falhou 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 prévias de gkectl prepare incluíram uma validação incorreta.


    Solução 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

    A criação do cluster de administrador falhou 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 secreta que não suporta "/" nem ":".


    Solução alternativa:

    Remova o prefixo https:// ou http:// do campo vCenter.Address no YAML de configuração do cluster de administrador ou do cluster de utilizadores.
    Instalação, atualizações e atualizações 1.10, 1.11, 1.12 e 1.13

    gkectl prepare pode entrar em pânico com a seguinte stacktrace:

    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 criou o diretório do certificado do registo privado com uma autorização incorreta.


    Solução alternativa:

    Para corrigir este problema, execute os seguintes comandos 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
    Atualizações 1.10, 1.11, 1.12 e 1.13

    Após uma tentativa falhada de atualização do cluster de administrador, não execute gkectl repair admin-master. Se o fizer, as tentativas de atualização do administrador subsequentes podem falhar com problemas como a falha de ativação do administrador principal ou a inacessibilidade da VM.


    Solução alternativa:

    Se já se deparou com este cenário de falha, contacte o apoio técnico.
    Atualizações 1.10 e 1.11

    Se a máquina do painel de controlo do administrador não for recriada após uma tentativa de atualização do cluster de administrador retomada, o modelo de VM do painel de controlo do administrador é eliminado. O modelo de VM do plano de controlo do administrador é o modelo do mestre do administrador que é usado para recuperar a máquina do plano de controlo com gkectl repair admin-master.


    Solução alternativa:

    O modelo de VM do plano de controlo do administrador é regenerado durante a próxima atualização do cluster de administrador.
    Sistema operativo 1.12 e 1.13

    Na versão 1.12.0, o cgroup v2 (unificado) está ativado por predefinição para os nós do SO otimizado para contentores (COS). Isto pode causar potencialmente instabilidade para as suas cargas de trabalho num cluster do COS.


    Solução alternativa:

    Voltámos a usar o cgroup v1 (híbrido) na versão 1.12.1. Se estiver a usar nós do COS, recomendamos que faça a atualização para a versão 1.12.1 assim que for lançada.
    Identidade 1.10, 1.11, 1.12 e 1.13

    gkectl update reverte todas as alterações manuais que tenha feito ao recurso personalizado ClientConfig.


    Solução alternativa:

    Recomendamos vivamente que faça uma cópia de segurança do recurso ClientConfig após cada alteração manual.
    Instalação 1.10, 1.11, 1.12 e 1.13

    A validação falha porque não é possível encontrar partições do F5 BIG-IP, mesmo que existam.

    Um problema com a API F5 BIG-IP pode fazer com que a validação falhe.


    Solução alternativa:

    Experimente executar gkectl check-config novamente.
    Instalação 1.12

    Pode ver uma falha de instalação devido a cert-manager-cainjector em crashloop, 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"

    Solução alternativa:
    VMware 1.10, 1.11, 1.12 e 1.13

    Se o vCenter, para versões inferiores à 7.0U2, for reiniciado após uma atualização ou de outra forma, o nome da rede nas informações da VM do vCenter está incorreto e faz com que a máquina fique no estado Unavailable. Isto acaba por levar à reparação automática dos nós para criar novos.

    Erro relacionado com o govmomi.


    Solução alternativa:

    Esta solução alternativa é fornecida pelo apoio técnico da VMware:

    1. O problema foi corrigido nas versões 7.0U2 e superiores do vCenter.
    2. Para versões inferiores, clique com o botão direito do rato no anfitrião e, de seguida, selecione Ligação > Desligar. Em seguida, restabeleça a ligação, o que força uma atualização do grupo de portas da VM.
    Sistema operativo 1.10, 1.11, 1.12 e 1.13

    Para a versão 1.7.2 e superior do Google Distributed Cloud, as imagens do SO Ubuntu são reforçadas com a referência CIS L1 Server.

    Para cumprir a regra CIS "5.2.16 Ensure SSH Idle Timeout Interval is configured", /etc/ssh/sshd_config tem as seguintes definições:

    ClientAliveInterval 300
ClientAliveCountMax 0

    O objetivo destas definições é terminar uma sessão do cliente após 5 minutos de tempo de inatividade. No entanto, o valor ClientAliveCountMax 0 causa um comportamento inesperado. Quando usa a sessão SSH na estação de trabalho do administrador ou num nó do cluster, a ligação SSH pode ser terminada, mesmo que o cliente SSH não esteja inativo, como quando executa um comando demorado. O comando pode ser terminado com a seguinte mensagem:

    Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Solução alternativa:

    Pode:

    • Use nohup para impedir que o seu comando seja terminado na desligação SSH, 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Atualize o sshd_config para usar um valor ClientAliveCountMax diferente de zero. A regra do CIS recomenda a utilização de um valor inferior a 3: 
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Certifique-se de que volta a associar a sessão de SSH.
    Instalação 1.10, 1.11, 1.12 e 1.13

    Nas versões 1.13, o monitoring-operator vai instalar o cert-manager no espaço de nomes cert-manager. Se, por determinados motivos, precisar de instalar o seu próprio cert-manager, siga as instruções abaixo para evitar conflitos:

    Só tem de aplicar esta solução alternativa uma vez para cada cluster e as alterações são preservadas durante a atualização do cluster.

    Nota: um sintoma comum da instalação do seu próprio cert-manager é que a versão ou a imagem do cert-manager (por exemplo, v1.7.2) pode reverter para a versão mais antiga. Isto deve-se a monitoring-operator tentar conciliar o cert-manager e reverter a versão no processo.

    Solução alternativa:

    <pEvite conflitos durante a atualização

    1. Desinstale a sua versão da app cert-manager. Se definiu os seus próprios recursos, recomendamos que faça uma cópia de segurança dos mesmos.
    2. Faça a atualização.
    3. Siga as instruções abaixo para restaurar o seu próprio cert-manager.

    Restaure o seu próprio cert-manager em clusters de utilizadores

    • Reduza a escala da implementação monitoring-operator para 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Ajuste as implementações de cert-manager geridas 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 sua versão do cert-manager. Restaurar os seus recursos personalizados, se os tiver.
    • Pode ignorar este passo se estiver a usar a instalação predefinida do cert-manager a montante ou se tiver a certeza de que o cert-manager está instalado no espaço de nomes cert-manager. Caso contrário, copie o metrics-ca cert-manager.io/v1 Certificate e os recursos metrics-pki.cluster.local Issuer de cert-manager para o espaço de nomes de recursos do cluster do cert-manager 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

    Restaure o seu próprio cert-manager em clusters de administrador

    Em geral, não deve ter de reinstalar o cert-manager em clusters de administrador, uma vez que os clusters de administrador apenas executam cargas de trabalho do plano de controlo do Google Distributed Cloud. Nos raros casos em que também precisa de instalar o seu próprio cert-manager em clusters de administrador, siga as instruções abaixo para evitar conflitos. Tenha em atenção que, se for cliente do Apigee e só precisar do cert-manager para o Apigee, não precisa de executar os comandos do cluster de administrador.

    • Dimensione a implementação de monitoring-operator para 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Ajuste as implementações do cert-manager geridas 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 sua versão do cert-manager. Restaurar os seus recursos personalizados, se os tiver.
    • Pode ignorar este passo se estiver a usar a instalação predefinida do cert-manager a montante ou se tiver a certeza de que o cert-manager está instalado no espaço de nomes cert-manager. Caso contrário, copie o metrics-ca cert-manager.io/v1 Certificate e os recursos metrics-pki.cluster.local Issuer de cert-manager para o espaço de nomes de recursos do cluster do cert-manager 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
    </p
    Sistema operativo 1.10, 1.11, 1.12 e 1.13

    O Docker, o containerd e o runc nas imagens do SO Ubuntu enviadas com o Google Distributed Cloud estão associados a versões especiais através do Ubuntu PPA. Isto garante que quaisquer alterações ao tempo de execução do contentor são qualificadas pelo Google Distributed Cloud antes de cada lançamento.

    No entanto, as versões especiais são desconhecidas para o Ubuntu CVE Tracker, que é usado como feeds de vulnerabilidades por várias ferramentas de verificação de CVE. Como tal, vai ver falsos positivos nos resultados da análise de vulnerabilidades do Docker, containerd e runc.

    Por exemplo, pode ver os seguintes falsos positivos nos resultados da análise de CVEs. Estas CVEs já estão corrigidas nas versões de patches mais recentes do Google Distributed Cloud.

    Consulte as notas de lançamento] para ver as correções de CVEs.


    Solução alternativa:

    A Canonical tem conhecimento deste problema e a correção está a ser monitorizada em: https://github.com/canonical/sec-cvescan/issues/73.
    Atualizações 1.10, 1.11, 1.12 e 1.13

    Se estiver a atualizar clusters não de HA de 1.9 para 1.10, pode reparar que o kubectl exec, o kubectl log e o webhook relativos aos clusters de utilizadores podem estar indisponíveis durante um curto período. Este tempo de inatividade pode durar até um minuto. Isto acontece porque o pedido recebido (kubectl exec, kubectl log e webhook) é processado pelo kube-apiserver para o cluster de utilizadores. O kube-apiserver do utilizador é um Statefulset. Num cluster não de HA, existe apenas uma réplica para o Statefulset. Assim, durante a atualização, existe a possibilidade de o antigo kube-apiserver não estar disponível enquanto o novo kube-apiserver ainda não estiver pronto.


    Solução alternativa:

    Este tempo de inatividade só ocorre durante o processo de atualização. Se quiser um tempo de inatividade mais curto durante a atualização, recomendamos que mude para clusters de HA.
    Instalação, atualizações e atualizações 1.10, 1.11, 1.12 e 1.13

    Se estiver a criar ou a atualizar um cluster de HA e notar que a verificação de disponibilidade do konnectivity falhou no diagnóstico do cluster, na maioria dos casos, não afeta a funcionalidade do Google Distributed Cloud (kubectl exec, kubectl log e webhook). Isto acontece porque, por vezes, uma ou duas das réplicas de conetividade podem não estar prontas durante um determinado período devido a uma rede instável ou a outros problemas.


    Solução alternativa:

    A conetividade é recuperada automaticamente. Aguarde entre 30 minutos e 1 hora e volte a executar o diagnóstico do cluster.
    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11

    A partir da versão 1.7.2 do Google Distributed Cloud, as imagens do SO Ubuntu são reforçadas com o CIS L1 Server Benchmark.

    Como resultado, o script cron /etc/cron.daily/aide foi instalado para que seja agendada uma verificação aide para garantir que a regra do servidor CIS L1 "1.4.2 Ensure filesystem integrity is regularly checked" é seguida.

    A tarefa cron é executada diariamente às 06:25 UTC. Consoante o número de ficheiros no sistema de ficheiros, pode verificar picos de utilização da CPU e da memória nessa altura, causados por este processo aide.


    Solução alternativa:

    Se os picos estiverem a afetar a sua carga de trabalho, pode desativar a tarefa cron diária:

    sudo chmod -x /etc/cron.daily/aide
    Redes 1.10, 1.11, 1.12 e 1.13

    Quando implementa o Google Distributed Cloud versão 1.9 ou posterior, quando a implementação tem o equilibrador de carga agrupado do Seesaw num ambiente que usa regras de firewall distribuídas com estado do NSX-T, stackdriver-operatorpode não conseguir criargke-metrics-agent-conf o ConfigMap e fazer com que os gke-connect-agentpods fiquem num ciclo de falhas.

    O problema subjacente é que as regras da firewall distribuída do NSX-T com estado terminam a ligação de um cliente ao servidor da API do cluster de utilizadores através do equilibrador de carga do Seesaw, porque o Seesaw usa fluxos de ligação assimétricos. Os problemas de integração com as regras da firewall distribuída do NSX-T afetam todas as versões do Google Distributed Cloud que usam o Seesaw. Pode encontrar problemas de ligação semelhantes nas suas próprias aplicações quando criam objetos Kubernetes grandes cujos tamanhos são superiores a 32 KB.


    Solução alternativa:

    Na versão 1.13 da documentação, siga estas instruções para desativar as regras de firewall distribuídas do NSX-T ou para usar regras de firewall distribuídas sem estado para VMs do Seesaw.

    Se os seus clusters usarem um equilibrador de carga manual, siga estas instruções para configurar o equilibrador de carga de modo a repor as ligações dos clientes quando detetar uma falha no nó de back-end. Sem esta configuração, os clientes do servidor da API Kubernetes podem deixar de responder durante vários minutos quando uma instância do servidor fica inativa.
    Registo e monitorização 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Para as versões 1.10 a 1.15 do Google Distributed Cloud, alguns clientes encontraram uma faturação inesperadamente elevada para o Metrics volume na página Faturação. Este problema afeta-o apenas quando se aplicam todas as circunstâncias seguintes:

    • O registo e a monitorização de aplicações estão ativados (enableStackdriverForApplications=true)
    • Os pods de aplicações têm a anotação prometheus.io/scrap=true. (A instalação do Cloud Service Mesh também pode adicionar esta anotação.)

    Para confirmar se é afetado por este problema, liste as suas métricas definidas pelo utilizador. Se vir a faturação de métricas indesejadas com o prefixo de nome external.googleapis.com/prometheus e também vir enableStackdriverForApplications definido como verdadeiro na resposta de kubectl -n kube-system get stackdriver stackdriver -o yaml, então este problema aplica-se a si.


    Solução alternativa

    Se for afetado por este problema, recomendamos que atualize os seus clusters para a versão 1.12 ou superior, pare de usar a flag enableStackdriverForApplications e mude para a nova solução de monitorização de aplicações managed-service-for-prometheus que já não depende da anotação prometheus.io/scrap=true. Com a nova solução, também pode controlar a recolha de registos e métricas separadamente para as suas aplicações, com os indicadores enableCloudLoggingForApplications e enableGMPForApplications, respetivamente.

    Para deixar de usar a flag enableStackdriverForApplications, abra o objeto `stackdriver` para edição:

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

    Remova a linha enableStackdriverForApplications: true, guarde e feche o editor.

    Se não conseguir mudar da recolha de métricas baseada em anotações, siga estes passos:

    1. Encontre os pods e os serviços de origem que têm as métricas 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"'
    2. Remova a anotação prometheus.io/scrap=true do pod ou do serviço. Se a anotação for adicionada pelo Cloud Service Mesh, considere configurar o Cloud Service Mesh sem a opção Prometheus ou desativar a funcionalidade de união de métricas do Istio.
    Instalação 1.11, 1.12 e 1.13

    O instalador do Google Distributed Cloud pode falhar se as funções personalizadas estiverem associadas ao nível de autorizações errado.

    Quando a associação de funções está incorreta, a criação de um disco de dados do vSphere com govc fica suspensa e o disco é criado com um tamanho igual a 0. Para corrigir o problema, deve associar a função personalizada ao nível do vSphere vCenter (raiz).


    Solução alternativa:

    Se quiser associar a função personalizada ao nível do DC (ou inferior ao raiz), também tem de associar a função só de leitura ao utilizador ao nível do vCenter raiz.

    Para mais informações sobre a criação de funções, consulte o artigo Privilégios da conta de utilizador do vCenter.
    Registo e monitorização 1.9.0-1.9.4, 1.10.0-1.10.1

    Pode ver um tráfego de rede elevado para monitoring.googleapis.com, mesmo num novo cluster que não tenha cargas de trabalho do utilizador.

    Este problema afeta a versão 1.10.0-1.10.1 e a versão 1.9.0-1.9.4. Este problema foi corrigido nas versões 1.10.2 e 1.9.5.


    Solução alternativa:
    Registo e monitorização 1.10 e 1.11

    Para a versão 1.10 e superior do Google Distributed Cloud, o DaemonSet `gke-metrics-agent` tem erros CrashLoopBackOff frequentes quando `enableStackdriverForApplications` está definido como `true` no objeto `stackdriver`.


    Solução alternativa:

    Para mitigar este problema, desative a recolha de métricas de aplicações executando os seguintes comandos: Estes comandos não desativam a recolha de registos de aplicações.

    1. Para impedir a reversão das seguintes alterações, reduza a escala de stackdriver-operator: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
       Substitua USER_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster do utilizador.
    2. Abra o gke-metrics-agent-conf ConfigMap para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Em services.pipelines, comente toda a secção metrics/app-metrics: 
      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
    4. Feche a sessão de edição.
    5. Reinicie o gke-metrics-agent DaemonSet: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Registo e monitorização 1.11, 1.12 e 1.13

    Se forem usadas métricas descontinuadas nos seus painéis de controlo OOTB, vai ver alguns gráficos vazios. Para encontrar métricas descontinuadas nos painéis de controlo de monitorização, 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 seguintes métricas descontinuadas devem ser migradas para as respetivas substituições.

    DescontinuadoSubstituiçã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

    Solução alternativa:

    Para substituir as métricas descontinuadas

    1. Elimine "GKE on-prem node status" no painel de controlo do Google Cloud Monitoring. Reinstale o "Estado do nó do GKE on-prem" seguindo estas instruções.
    2. Elimine "Utilização de nós do GKE On-Prem" no painel de controlo do Google Cloud Monitoring. Reinstale a "Utilização de nós do GKE On-Prem" seguindo estas instruções.
    3. Elimine "GKE on-prem vSphere vm health" no painel de controlo do Google Cloud Monitoring. Reinstale "GKE on-prem vSphere vm health" seguindo estas instruções.

      4. Esta descontinuação deve-se à atualização do agente kube-state-metrics da versão 1.9 para a versão 2.4, que é necessária para o Kubernetes 1.22. Pode substituir todas as métricas descontinuadas kube-state-metrics que tenham o prefixo kube_ nos seus painéis de controlo personalizados ou políticas de alerta.
    Registo e monitorização 1.10, 1.11, 1.12 e 1.13

    Para a versão 1.10 e superior do Google Distributed Cloud, os dados dos clusters no Cloud Monitoring podem conter entradas de métricas de resumo irrelevantes, como as seguintes:

    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 estas métricas do tipo resumo estejam na lista de métricas, não são suportadas pelo gke-metrics-agent neste momento.
    Registo e monitorização 1.10, 1.11, 1.12 e 1.13

    Pode verificar que as seguintes métricas estão em falta em alguns, mas não em todos, os nós:

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

    Solução alternativa:

    Para corrigir este problema, siga estes passos como solução alternativa. Para [version 1.9.5+, 1.10.2+, 1.11.0]: aumente a CPU para gke-metrics-agent seguindo os passos 1 a 4

    1. Abra o recurso stackdriver para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar o pedido de CPU de gke-metrics-agent de 10m para 50m, o limite de CPU de 100m para 200m, adicione a seguinte secção resourceAttrOverride ao manifesto stackdriver : 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
       O recurso editado deve ser 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
    3. Guarde as alterações e feche o editor de texto.
    4. Para verificar se as alterações 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 encontra cpu: 50m se as suas edições tiverem entrado em vigor.
    Registo e monitorização 1.11.0-1.11.2, 1.12.0

    Se o cluster de administrador for afetado por este problema, as métricas do programador e do gestor de controladores estão em falta. Por exemplo, estas duas métricas estão em falta

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solução alternativa:

    Atualize para a versão v1.11.3 ou superior, v1.12.1 ou superior, ou v1.13 ou superior.
    1.11.0-1.11.2, 1.12.0

    Se o seu cluster de utilizadores for afetado por este problema, as métricas do programador e do gestor do controlador estão em falta. Por exemplo, estas duas métricas estão em falta:

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solução alternativa:

    Este problema foi corrigido na versão 1.13.0 e posteriores do Google Distributed Cloud. Atualize o cluster para uma versão com a correção.
    Instalação, atualizações e atualizações 1.10, 1.11, 1.12 e 1.13

    Se criar um cluster de administrador para a versão 1.9.x ou 1.10.0 e se o cluster de administrador não se registar com a especificação fornecida durante a respetiva criação, recebe o seguinte erro.gkeConnect

    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

    Continua a poder usar este cluster de administrador, mas recebe o seguinte erro se tentar atualizar o cluster de administrador para a versão 1.10.y mais tarde.

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

    Solução alternativa:
    Identidade 1.10, 1.11, 1.12 e 1.13

    Se estiver a usar a funcionalidade GKE Identity Service para gerir o GKE Identity Service ClientConfig, o agente Connect pode ser reiniciado inesperadamente.


    Solução alternativa:

    Se teve este problema com um cluster existente, pode fazer uma das seguintes ações:

    • Desative o serviço de identidade do GKE. Se desativar o serviço de identidade do GKE, não remove o binário do serviço de identidade do GKE implementado nem o ClientConfig do serviço de identidade do GKE. Para desativar o GKE Identity Service, execute este comando: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
       Substitua PROJECT_ID pelo ID do projeto anfitrião da frota.
    • Atualize o cluster para a versão 1.9.3 ou posterior, ou para a versão 1.10.1 ou posterior, de modo a atualizar a versão do agente Connect.
    Redes 1.10, 1.11, 1.12 e 1.13

    O Seesaw é executado no modo DSR e, por predefinição, não funciona no Cisco ACI devido à aprendizagem de IP do plano de dados.


    Solução alternativa:

    Uma possível solução alternativa é desativar a aprendizagem de IP adicionando o endereço IP do Seesaw como um IP virtual L4-L7 no Cisco Application Policy Infrastructure Controller (APIC).

    Pode configurar a opção de IP virtual L4-L7 acedendo a Inquilino > Perfis de aplicações > EPGs de aplicações ou EPGs uSeg. A falha na desativação da aprendizagem de IP resulta na oscilação do ponto final de IP entre diferentes localizações na estrutura da API Cisco.
    VMware 1.10, 1.11, 1.12 e 1.13

    Recentemente, a VMWare identificou problemas críticos com as seguintes versões do vSphere 7.0 Update 3:

    • vSphere ESXi 7.0 Update 3 (compilação 18644231)
    • vSphere ESXi 7.0 Update 3a (compilação 18825058)
    • vSphere ESXi 7.0 Update 3b (compilação 18905247)
    • vSphere vCenter 7.0 Update 3b (compilação 18901211)

    Solução alternativa:

    Entretanto, a VMWare removeu estes lançamentos. Deve atualizar os servidores ESXi e vCenter para uma versão mais recente.
    Sistema operativo 1.10, 1.11, 1.12 e 1.13

    Para agrupamentos em execução em nós que usam imagens do SO otimizado para contentores (COS), não pode montar o volume emptyDir como exec. É montado como noexec e recebe o seguinte erro: exec user process caused: permission denied. Por exemplo, vê esta mensagem de erro se implementar o seguinte pod de teste:

    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

    E no pod de teste, se executar mount | grep test-volume, é apresentada a opção noexec:

    /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Solução alternativa:
    Atualizações 1.10, 1.11, 1.12 e 1.13

    As réplicas do node pool não são atualizadas depois de a escalabilidade automática ter sido ativada e desativada num node pool.


    Solução alternativa:

    Remover as 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 implementação da máquina do node pool correspondente.
    Registo e monitorização 1.11, 1.12 e 1.13

    A partir da versão 1.11, nos painéis de controlo de monitorização predefinidos, o painel de controlo do estado do pod do Windows e o painel de controlo do estado do nó do Windows também mostram dados de clusters Linux. Isto deve-se ao facto de o nó do Windows e as métricas do pod também serem expostos em clusters Linux.
    Registo e monitorização 1.10, 1.11 e 1.12

    Para o Google Distributed Cloud versão 1.10, 1.11 e 1.12, o stackdriver-log-forwarder DaemonSet pode ter erros CrashLoopBackOff quando existem registos em buffer danificados no disco.


    Solução alternativa:

    Para mitigar este problema, temos de limpar os registos em buffer no nó.

    1. Para evitar o comportamento inesperado, reduza a escala 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 ficheiro kubeconfig do cluster do utilizador.
    2. Implemente o DaemonSet de limpeza para limpar blocos danificados: 
      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
    3. Para garantir que o DaemonSet de limpeza limpou todos os fragmentos, pode executar os seguintes comandos. O resultado dos dois comandos deve 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
    4. Elimine o DaemonSet de limpeza: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Retomar 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"}]'
    Registo e monitorização 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Se não vir registos no Cloud Logging dos seus clusters e notar o seguinte erro nos seus registos: 

    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 registos exceda o limite do agente de registo, o que faz com que o stackdriver-log-forwarder não envie registos. Este problema ocorre em todas as versões do Google Distributed Cloud.

    Alternativa:

    Para mitigar este problema, tem de aumentar o limite de recursos no agente de registo.

    1. Abra o recurso stackdriver para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar o pedido de CPU para stackdriver-log-forwarder , adicione a seguinte secçã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 deve ser 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
    3. Guarde as alterações e feche o editor de texto.
    4. Para verificar se as alterações 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 encontra cpu: 1200m se as suas edições tiverem entrado em vigor.
    Segurança 1.13

    Existe um curto período em que o nó está pronto, mas o certificado do servidor kubelet não está pronto. kubectl exec e kubectl logs estão indisponíveis durante estes dez segundos. Isto deve-se ao facto de o novo aprovador do certificado do servidor demorar algum tempo a ver os IPs válidos atualizados do nó.

    Este problema afeta apenas o certificado do servidor kubelet e não afeta o agendamento de pods.
    Atualizações 1.12

    Falha na atualização do cluster de utilizadores 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 está totalmente atualizado e a versão do estado ainda é 1.10. A atualização do cluster de utilizadores para a versão 1.12 não é bloqueada por nenhuma verificação prévia e falha devido a um problema de incompatibilidade de versões.


    Solução alternativa:

    Conclua a atualização do cluster de administrador para a versão 1.11 primeiro e, em seguida, atualize o cluster de utilizador para a versão 1.12.
    Armazenamento 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    O comando gkectl diagnose cluster falhou 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 armazenamento de dados não deve ser usada para pools de nós de cluster existentes e foi adicionada no gkectl diagnose cluster por engano.


    Solução alternativa:

    Pode ignorar a mensagem de erro ou ignorar a validação através de --skip-validation-infra.
    Operação, trabalho em rede 1.11, 1.12.0-1.12.1

    Pode não conseguir adicionar um novo cluster de utilizadores se o cluster de administrador estiver configurado com uma configuração do balanceador de carga do MetalLB.

    O processo de eliminação do cluster de utilizadores pode ficar bloqueado por algum motivo, o que resulta numa invalidação do ConfigMap do MetalLB. Não é possível adicionar um novo cluster de utilizadores neste estado.


    Solução alternativa:

    Pode forçar a eliminação do cluster de utilizadores.
    Instalação, sistema operativo 1.10, 1.11, 1.12 e 1.13

    Se osImageType estiver a usar cos para o cluster de administrador, e quando gkectl check-config for executado após a criação do cluster de administrador e antes da criação do cluster de utilizadores, falha em: 

    Failed to create the test VMs: VM failed to get IP addresses on the network.

    A VM de teste criada para o cluster de utilizadores check-config usa por predefinição o mesmo osImageType do cluster de administrador e, atualmente, a VM de teste ainda não é compatível com o COS.


    Solução alternativa:

    Para evitar a verificação prévia lenta que cria a VM de teste, use gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Registo e monitorização 1.12.0-1.12.1

    Este problema afeta os clientes que usam o Grafana no cluster de administração para monitorizar clusters de utilizadores nas versões 1.12.0 e 1.12.1 do Google Distributed Cloud. Resulta de uma incompatibilidade dos certificados pushprox-client nos clusters de utilizadores e da lista de autorizações no pushprox-server no cluster de administrador. O sintoma é o pushprox-client nos clusters de utilizadores a imprimir registos de erros como os seguintes:

    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Solução alternativa:
    Outro 1.11.3

    O comando gkectl repair admin-master falhou 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 consegue obter o modelo de VM a usar para reparar a VM do plano de controlo do administrador se o nome da VM do plano de controlo do administrador terminar com os carateres t, m, p ou l.


    Solução alternativa:

    Volte a executar o comando com --skip-validation.
    Registo e monitorização 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Os registos de auditoria na nuvem precisam de uma configuração de autorização especial que, atualmente, só é feita automaticamente para clusters de utilizadores através do GKE Hub. Recomendamos que tenha, pelo menos, um cluster de utilizadores que use o mesmo ID do projeto e conta de serviço que o cluster de administrador para os registos de auditoria do Google Cloud, para que o cluster de administrador tenha a autorização necessária.

    No entanto, nos casos em que o cluster de administrador usa um ID do projeto diferente ou uma conta de serviço diferente de qualquer cluster de utilizador, os registos de auditoria do cluster de administrador não seriam injetados no Google Cloud. O sintoma é uma série de erros Permission Denied no pod audit-proxy no cluster de administração.

    Solução alternativa:
    Operação, segurança 1.11

    Se a sua estação de trabalho não tiver acesso aos nós de trabalho do cluster de utilizadores, vai receber as seguintes falhas quando executar o comando 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 sua 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 administrador, recebe as seguintes falhas quando executa 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

    Solução alternativa:

    Se é seguro ignorar estas mensagens.
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ está preenchido com registos de auditoria. Pode verificar a utilização do disco executando sudo du -h -d 1 /var/log/audit.

    Determinados comandos gkectl na estação de trabalho do administrador, por exemplo, gkectl diagnose snapshot contribuem para a utilização do espaço em disco.

    Desde o Google Distributed Cloud v1.8, a imagem do Ubuntu está protegida com a referência CIS Level 2. Uma das regras de conformidade, "4.1.2.2 Ensure audit logs are not automatically deleted", garante a definição do auditd max_log_file_action = keep_logs. Isto resulta na manutenção de todas as regras de auditoria no disco.


    Solução alternativa:
    Redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    Os utilizadores não conseguem criar nem 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 associar-se erroneamente a um endereço IP flutuante atribuído ao nó e comunicá-lo como um endereço do nó em node.status.addresses. O webhook de validação verifica os NetworkGatewayGroup endereços IP flutuantes em relação a todos os node.status.addresses no cluster e considera isto um conflito.


    Solução alternativa:

    No mesmo cluster onde a criação ou a atualização de objetos NetworkGatewayGroup está a falhar, desative temporariamente o webhook de validação da ANG e envie a alteração:

    1. Guarde a configuração do webhook para que possa ser restaurada no final: 
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Edite a configuração do webhook: 
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Remova o item vnetworkgatewaygroup.kb.io da lista de configuração do webhook e feche para aplicar as alterações.
    4. Crie ou edite o seu objeto NetworkGatewayGroup.
    5. Volte a aplicar a configuração original do webhook: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Instalação, atualizações e atualizações 1.10.0-1.10.2

    Durante uma tentativa de atualização do cluster de administrador, a VM do plano de controlo de administrador pode ficar bloqueada durante a criação. A VM do plano de controlo do administrador entra num loop de espera infinito durante o arranque e é apresentado o seguinte erro de loop infinito no ficheiro /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

    Isto acontece porque, quando o Google Distributed Cloud tenta obter o endereço IP do nó no script de arranque, usa grep -v ADMIN_CONTROL_PLANE_VIP para ignorar o VIP do plano de controlo do cluster de administrador, que também pode ser atribuído à NIC. No entanto, o comando também ignora qualquer endereço IP que tenha um prefixo do VIP do plano de controlo, o que faz com que o script de arranque fique bloqueado.

    Por exemplo, suponha que o VIP do plano de controlo do cluster de administrador é 192.168.1.25. Se o endereço IP da VM do plano de controlo do cluster de administrador tiver o mesmo prefixo, por exemplo,192.168.1.254, a VM do plano de controlo fica bloqueada durante a criação. Este problema também pode ser acionado se o endereço de transmissão tiver o mesmo prefixo que o VIP do plano de controlo, por exemplo, 192.168.1.255.


    Solução alternativa:

    • Se o motivo do limite de tempo da criação do cluster de administrador for o endereço IP de transmissão, execute o seguinte comando na VM do plano de controlo do cluster de administrador: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
       Esta ação cria uma linha sem um endereço de transmissão e desbloqueia o processo de arranque. Depois de desbloquear o script de arranque, remova esta linha adicionada executando o seguinte comando: 
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • No entanto, se o motivo do limite de tempo da criação do cluster de administrador for o endereço IP da VM do plano de controlo, não pode desbloquear o script de arranque. Mude para um endereço IP diferente e recrie ou atualize para a versão 1.10.3 ou posterior.
    Sistema operativo, atualizações 1.10.0-1.10.2

    Não é possível montar corretamente o DataDisk no nó principal do cluster de administrador quando usa a imagem do COS e o estado do cluster de administrador que usa a imagem do COS é perdido após a atualização do cluster de administrador ou a reparação do nó principal do administrador. (O cluster de administrador que usa a imagem do COS é uma funcionalidade de pré-visualização)


    Solução alternativa:

    Recrie o cluster de administrador com osImageType definido como ubuntu_containerd

    Depois de criar o cluster de administrador com osImageType definido como cos, obtenha a chave SSH do cluster de administrador e use SSH no nó principal do administrador. O resultado df -h contém /dev/sdb1 98G 209M 93G 1% /opt/data. E o resultado lsblk contém -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1.10

    Na versão 1.10.0 do Google Distributed Cloud, as resoluções de nomes no Ubuntu são encaminhadas para o systemd-resolved local que escuta em 127.0.0.53 por predefinição. O motivo é que na imagem do Ubuntu 20.04 usada na versão 1.10.0, /etc/resolv.conf está associado simbolicamente a /run/systemd/resolve/stub-resolv.conf, que aponta para o stub DNS localhost 127.0.0.53.

    Como resultado, a resolução de nomes DNS do anfitrião local recusa-se 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.

    Isto faz com que todas as pesquisas de nomes .local falhem. Por exemplo, durante o arranque do nó, o kubelet falha ao extrair imagens de um registo privado com um sufixo .local. A especificação de um endereço vCenter com um sufixo .local não funciona numa estação de trabalho de administrador.


    Solução alternativa:

    Pode evitar este problema para nós de cluster se especificar o campo searchDomainsForDNS no ficheiro de configuração do cluster de administrador e no ficheiro de configuração do cluster de utilizador para incluir os domínios.

    Atualmente, o gkectl update não suporta a atualização do campo searchDomainsForDNS.

    Por conseguinte, se não tiver configurado este campo antes da criação do cluster, tem de usar SSH nos nós e ignorar o stub systemd-resolved local alterando o link simbólico de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contém o stub local 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

    Quanto à estação de trabalho do administrador, o gkeadm não suporta a especificação de domínios de pesquisa, pelo que tem de contornar este problema com este passo manual.

    Esta solução não persiste nas recriações de VMs. Tem de voltar a aplicar esta solução alternativa sempre que as VMs forem recriadas.
    Instalação, sistema operativo 1.10

    O Google Distributed Cloud especifica uma sub-rede dedicada para o endereço IP da ponte Docker que usa --bip=169.254.123.1/24, para que não reserve a sub-rede 172.17.0.1/16 predefinida. No entanto, na versão 1.10.0, existe um erro na imagem do SO Ubuntu que fez com que a configuração do Docker personalizada fosse ignorada.

    Como resultado, o Docker escolhe 172.17.0.1/16 como a sua sub-rede de endereço IP de ponte predefinida. Isto pode causar um conflito de endereços IP se já tiver uma carga de trabalho em execução nesse intervalo de endereços IP.


    Solução alternativa:

    Para contornar este problema, tem de mudar o nome do seguinte ficheiro de configuração do systemd para o dockerd e, em seguida, 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 persiste nas recriações de VMs. Tem de voltar a aplicar esta solução alternativa sempre que as VMs forem recriadas.
    Atualizações 1.11

    Na versão 1.11.0 do Google Distributed Cloud, existem alterações na definição de recursos personalizados relacionados com o registo e a monitorização:

    • 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 função do respetivo esquema. Em particular, a especificação resourceAttrOverride e storageSizeOverride no recurso personalizado stackdriver tem de ter o tipo de string nos valores dos pedidos e limites de tamanho de CPU, memória e armazenamento.

    As alterações de nomes de grupos são feitas em conformidade com as atualizações de CustomResourceDefinition no Kubernetes 1.22.

    Não é necessária nenhuma ação se não tiver lógica adicional que se aplique ou edite os recursos personalizados afetados. O processo de atualização do Google Distributed Cloud vai tratar da migração dos recursos afetados e manter as respetivas especificações existentes após a alteração do nome do grupo.

    No entanto, se executar alguma lógica que aplique ou edite os recursos afetados, é necessária especial atenção. Primeiro, têm de ser referenciados com o novo nome do grupo no ficheiro de manifesto. Por exemplo:

    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    Em segundo lugar, certifique-se de que os valores das especificações resourceAttrOverride e storageSizeOverride são do tipo string. Por 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 as edições não têm efeito e podem levar a um estado inesperado nos componentes de registo e monitorização. Os potenciais sintomas podem incluir:

    • Registos de erros de conciliaçã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 encontrar os erros acima, significa que já estava presente um tipo não suportado na especificação de CR do Stackdriver antes da atualização. Como solução alternativa, pode editar manualmente o CR do Stackdriver com o nome do grupo antigo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e fazer o seguinte:

    1. Altere os pedidos e os limites de recursos para o tipo de string;
    2. Remova qualquer anotação addons.gke.io/migrated-and-deprecated: true, se estiver presente.
    Em seguida, retome ou reinicie o processo de atualização.

    Sistema operativo 1.7 e posteriores

    Sempre que existe uma falha num servidor ESXi e a função vCenter HA foi ativada para o servidor, todas as VMs no servidor ESXi com falhas acionam o mecanismo vMotion e são movidas para outro servidor ESXi normal. As VMs do COS migradas perderiam os respetivos IPs.

    Solução alternativa:

    Reiniciar a VM
    Redes todas as versões anteriores a 1.14.7, 1.15.0-1.15.3 e 1.16.0

    O GARP (Gratuitous ARP) periódico enviado pelo Seesaw a cada 20 segundos não define o IP de destino no cabeçalho ARP. Algumas redes podem não aceitar estes pacotes (como o Cisco ACI). Pode causar um tempo de inatividade do serviço mais longo após a recuperação de um split brain (devido a quedas de pacotes VRRP).

    Solução alternativa:

    Acione uma comutação por falha do Seesaw executando sudo seesaw -c failover numa das VMs do Seesaw. Isto deve restaurar o tráfego.
    Sistema operativo 1.16, 1.28.0-1.28.200

    "staticPodPath" foi definido por engano para nós trabalhadores

    Solução alternativa:

    Crie manualmente a pasta "/etc/kubernetes/manifests"

    O que se segue?

    Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

    Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte: