Problemas conhecidos do Google Distributed Cloud (somente software) para VMware

Nesta página, listamos todos os problemas conhecidos do Google Distributed Cloud no VMware. Esta página é destinada a administradores e operadores de TI que gerenciam o ciclo de vida da infraestrutura tecnológica e responder a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são atendidos ou os aplicativos falham. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

Se você faz parte do Programa para desenvolvedores do Google, salve esta página para receber notificações quando uma nota da versão relacionada a ela for publicada. Para saber mais, consulte Páginas salvas.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros desejados nos menus suspensos a seguir.

Selecione sua versão do Google Distributed Cloud:

Selecione a categoria do seu problema:

Ou procure seu problema:

Categoria Versões identificadas Problema e solução alternativa
Atualizações 1.32.0-1.32.600, 1.33.0-1.33.100

O uso de gkectl update para atualizar um cluster de usuário que não é de alta disponibilidade (não HA) para um cluster avançado com um plano de controle de HA falha e gera a seguinte mensagem de erro:

Failed to generate diff summary: failed to get desired onprem user cluster and node pools from seed config with dry-run webhooks:
failed to apply validating webhook to OnPremUserCluster:
masterNode.replcias: Forbidden: the field must not be mutated, diff (-before, +after): int64(- 1,+ 3)

Alternativa:

Use o comando gkectl upgrade para fazer upgrade do cluster de usuário sem HA para um cluster avançado de HA.
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 inclui uma migração do ControlPlaneV2 da versão 1.30.x para a 1.31.x, os pods do Windows podem não ser programados e permanecer em um estado Pending. Esse problema se manifesta como um erro de validação do certificado TLS para o webhook de admissão mutante windows-webhook. O problema ocorre porque o nome alternativo do titular (SAN) do certificado retém incorretamente um valor válido para a arquitetura antiga do Kubeception, em vez de ser regenerado para o novo endpoint kube-system.svc.

Talvez você veja 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. Essa situação pode surgir do processo de migração do ControlPlaneV2, que copia o conteúdo do etcd e transfere o certificado antigo sem a regeneração adequada. É importante observar que os pools de nós do Windows são um recurso descontinuado e não estarão disponíveis no Google Distributed Cloud 1.33 e versões mais recentes.

Alternativa:

  1. Faça backup do secret user-component-options no namespace do cluster de usuário:

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

  2. Exclua o secret user-component-options:

        kubectl delete secret user-component-options -n USER_CLUSTER_NAME

  3. Edite o recurso onpremusercluster para acionar a reconciliaçã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 cluster de usuário.
Upgrades, atualizações 1.32.0-1.32.500, 1.33.0

O upgrade/atualização para um cluster avançado falha se o stackdriver não estiver configurado.

Ao fazer upgrade/atualizar um cluster não avançado para um avançado, o processo pode parar de responder se o stackdriver não estiver ativado.

Alternativa:

  • Se o cluster ainda não tiver sido atualizado, siga as etapas para ativar stackdriver:
    1. Adicione a seção stackdriver ao arquivo de configuração do cluster.
    2. Execute gkectl update para ativar stackdriver.
  • Se um upgrade já estiver em andamento, siga estas etapas:
    1. Edite o secret user-cluster-creds no namespace 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. Atualize o recurso personalizado OnPremUserCluster com o campo stackdriver. Use o mesmo projeto com o mesmo local do projeto e a chave da conta de serviço do cloudauditlogging se você tiver ativado o recurso. 
      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 seção stackdriver ao arquivo de configuração do cluster para manter a consistência.
Upgrades 1.29, 1.30, 1.31, 1.32+

Pods não conseguem se conectar ao servidor da API Kubernetes com o Dataplane V2 e políticas de rede restritivas

Em clusters que usam a arquitetura do plano de controle V2 (CPv2, padrão na versão 1.29 e mais recentes) e o Dataplane V2, os pods podem não se conectar ao servidor da API Kubernetes (kubernetes.default.svc.cluster.local). Esse problema geralmente é causado pela presença de políticas de rede, especialmente aquelas com regras de negação de saída padrão. Os sintomas incluem:

  • As tentativas de conexão TCP com o endereço IP do cluster ou os endereços IP do nó do servidor da API resultam em uma mensagem Connection reset by peer.
  • Falhas de handshake de TLS ao se conectar ao servidor da API.
  • Executar o comando cilium monitor -t drop no nó afetado pode mostrar pacotes destinados aos endereços IP do nó do plano de controle e à porta do servidor da API (normalmente 6443) sendo descartados.

Causa

Esse problema surge de uma interação entre o Dataplane V2 (baseado no Cilium) e as políticas de rede do Kubernetes na arquitetura CPv2, em que os componentes do plano de controle são executados em nós dentro do cluster de usuário. A configuração padrão do Cilium não interpreta corretamente as regras ipBlock em políticas de rede destinadas a permitir o tráfego para os IPs de nó dos membros do plano de controle. Esse problema está relacionado a um problema upstream do Cilium (cilium#20550).

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 controle. Se você precisar de uma política de negação padrão, adicione uma regra de permissão ampla para todo o tráfego de saída. Por exemplo, não especifique nenhuma regra na seção de saída, permitindo efetivamente toda a saída. Essa 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 corresponder corretamente aos IPs de nó nos campos ipBlock da política de rede. Para corresponder aos IPs de nós nos campos ipBlock da política de rede, faça o seguinte:

  1. Editar o ConfigMap cilium-config: 
    kubectl edit configmap -n kube-system cilium-config
  2. Adicione ou modifique a seção de dados para incluir policy-cidr-match-mode: nodes: 
    data:
      policy-cidr-match-mode: nodes
  3. Para aplicar a mudança de configuração, reinicie o DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system
  4. Verifique se você tem uma política de rede que permite explicitamente o tráfego de saída dos pods para os IPs dos nós do plano de controle na porta do servidor da API. Identifique os endereços IP dos nós do plano de controle do cluster de usuário executando kubectl get svc kubernetes. A saída será semelhante a esta: 
        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 pod do agente gke-connect travou no estado Pending durante a criação do cluster de usuário

Durante a criação do cluster de usuário, o pod do agente gke-connect pode ficar preso em um estado Pending, impedindo que o cluster seja totalmente criado. Esse problema ocorre porque o pod do agente gke-connect tenta fazer o agendamento antes que os nós de trabalho estejam disponíveis, o que causa um impasse.

Esse problema ocorre quando a criação inicial do cluster de usuário falha devido a erros de validação de simulação, e uma tentativa subsequente de criar o cluster é feita sem excluir primeiro os recursos parcialmente criados. Na tentativa subsequente de criação do cluster, o pod do agente gke-connect fica preso devido a taints não tolerados nos nós do plano de controle, conforme indicado por um erro semelhante a este:

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

Alternativa:

Se a criação do cluster de usuário falhar devido a erros de validação de simulação, exclua os recursos do cluster parcialmente criados antes de tentar criar o cluster novamente com configurações corrigidas. Isso garante que o fluxo de trabalho de criação prossiga corretamente, incluindo a criação de pools de nós antes da implantação do pod do agente gke-connect.
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 criptografia de secrets sempre ativada com gkectl update cluster, os secrets ainda serão armazenados em etcd com criptografia. Esse problema se aplica apenas a clusters de usuário do kubeception. Se o cluster usar o Controlplane V2, você não será afetado por esse problema.

Para verificar se as chaves secretas ainda estão criptografadas, execute o seguinte comando, que recupera a chave secreta default/private-registry-creds armazenada 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 o secret for armazenado com criptografia, a saída será semelhante a esta:

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 o secret não estiver armazenado com criptografia, a saída será semelhante a esta:

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

Alternativa:

  1. Faça uma atualização gradual em um DaemonSet específico, da seguinte maneira: 
        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      rollout restart statefulsets kube-apiserver \
      -n USER_CLUSTER_NAME
  2. Receba os manifestos de todos os segredos no cluster de usuários no formato YAML: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      get secrets -A -o yaml > SECRETS_MANIFEST.yaml
  3. Reaplique todos os secrets no cluster de usuários para que todos 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 arquivo de configuração do cluster de usuário, user-cluster.yaml, gerado pelo comando gkectl get-config, não tem o campo hostgroups na seção nodePools. O comando gkectl get-config gera o arquivo 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 arquivo user-cluster.yaml quando você executa gkectl get-config.

Alternativa

Para resolver esse problema, adicione manualmente o campo nodePools[i].vsphere.hostgroups ao arquivo user-cluster.yaml. O arquivo editado deve ficar semelhante ao exemplo a seguir:

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

É possível usar o arquivo de configuração do cluster de usuário editado para atualizar o cluster de usuário sem acionar erros, e o campo hostgroups será mantido.
Rede 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Os pods do Istiod da entrada agrupada não podem ficar prontos se os recursos gateway.networking.k8s.io forem instalados no cluster de usuário. A seguinte mensagem de erro de exemplo pode ser encontrada nos registros do pod:

    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"

Alternativa:

Aplique o ClusterRole e o ClusterRoleBinding a seguir ao seu cluster de usuário: 

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 host no campo ipblocks contiverem letras maiúsculas, os nós do plano de controle do cluster de administrador poderão ser reinicializados várias vezes.

Alternativa:

Use apenas nomes de host em letras minúsculas.
Instalação, upgrades 1.30.0-1.30.500, 1.31.0-1.31.100

Runtime: out of memory "error" depois de executar gkeadm create ou upgrade

Ao criar ou fazer upgrade de estações de trabalho de administrador com comandos gkeadm, você pode receber um erro de falta de memória ao verificar a imagem do SO baixada.

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

Alternativa:

  • Aumente o tamanho da memória do SO em que você executa o comando gkeadm.
    		•
    Upgrades 1.30.0-1.30.400

    Upgrade do cluster de administrador sem HA travado em Creating or updating cluster control plane workloads

    Ao fazer upgrade de um cluster de administrador não HA, o upgrade pode ficar travado em Creating or updating cluster control plane workloads.

    Esse problema ocorre se, na VM mestre do administrador, ip a | grep cali retornar 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

    Alternativa:

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

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

    Os arquivos 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

    Esse campo não é necessário e pode ser removido com segurança do arquivo de configuração.

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

    Ao migrar um cluster de administrador não HA que usa o MetalLB para HA, os nós de complemento de administrador podem ficar presos em um status NotReady, impedindo a conclusão da migração.

    Esse problema afeta apenas clusters de administrador configurados com MetalLB em que o reparo automático não está ativado.

    Esse problema é causado por uma condição de disputa durante a migração, em que os speakers do MetalLB ainda estão usando o antigo secret metallb-memberlist. Como resultado da condição de disputa, o VIP antigo do plano de controle fica inacessível, o que causa a interrupção da migração.

    Alternativa:

    1. Exclua o secret metallb-memberlist atual: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    delete secret metallb-memberlist
    2. Reinicie a implantação metallb-controller para que ela possa gerar o novo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart deployment metallb-controller
    3. Verifique se o novo metallb-memberlist foi 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%.

      Essa etapa é necessária porque alguns pods do DaemonSet estão sendo executados nos nós NotReady.

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

      Depois de alguns minutos, os nós do complemento de administrador voltam a ficar Ready e a migração pode continuar.

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

    O backup do cluster para um cluster de administrador que não é de alta disponibilidade falha devido a nomes longos de repositório de dados e disco de dados

    Ao tentar fazer backup de um cluster de administrador que não é de alta disponibilidade, o backup falha porque o tamanho combinado dos nomes do repositório de dados e do disco de dados excede o tamanho máximo de caracteres.

    O comprimento máximo de um nome de repositório de dados é de 80 caracteres.
    O caminho de backup para um cluster de administrador que não é de alta disponibilidade tem a sintaxe de nomenclatura "__". Portanto, se o nome concatenado exceder o tamanho máximo, a criação da pasta de backup vai falhar.

    Alternativa:

    Renomeie o datastore ou o datadisk com um nome mais curto.
    Verifique se o comprimento combinado dos nomes do datastore e do datadisk não excede o comprimento máximo de caracteres.
    Upgrades 1.28, 1.29, 1.30

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

    Esse problema ocorre porque o modelo de VM de backup usado para o reparo do nó do plano de controle do administrador de alta disponibilidade não é atualizado no vCenter após um upgrade, já que o modelo de VM de backup não foi clonado durante a criação da máquina se o nome dela permanecer inalterado.

    Alternativa:

    1. Descubra o nome da máquina que está usando 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

      Salve a edição.

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

      Uma nova máquina será criada com a versão correta.
    Configuração 1.30.0

    Ao atualizar um cluster de usuário ou um pool de nós usando o Terraform, o Terraform pode tentar definir campos vCenter como valores vazios.

    Esse problema pode ocorrer se o cluster não foi criado originalmente usando o Terraform.

    Alternativa:

    Para evitar a atualização inesperada, verifique se ela é segura antes de executar terraform apply, conforme descrito abaixo:

    1. Executar 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 seguindo a documentação do Terraform. Isso impede atualizações nesses campos.
    4. Execute terraform plan novamente e verifique a saída para confirmar se a atualização está conforme o esperado.
    Atualizações 1.13, 1.14, 1.15, 1.16

    Depois que os nós do plano de controle dos clusters de usuário do kubeception forem criados, atualizados ou fizerem upgrade, eles serão reinicializados um por um durante a primeira operação do cluster de administrador, quando ele for criado ou atualizado para uma das versões afetadas. Para clusters de kubeception com três nós do plano de controle, isso não deve causar inatividade do plano de controle, e o único impacto é que a operação do cluster de administrador leva mais tempo.

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

    Na versão 1.31 do Google Distributed Cloud, você pode receber erros ao tentar criar recursos personalizados, como clusters (todos os tipos) e cargas de trabalho. O problema é causado por uma mudança incompatível introduzida no Kubernetes 1.31 que impede que o campo caBundle em uma definição de recurso personalizada faça a transição de um estado válido para um inválido. Para mais informações sobre a mudança, consulte o registro de alterações do Kubernetes 1.31.

    Antes do Kubernetes 1.31, o campo caBundle era geralmente definido com um valor improvisado de \n, porque em versões anteriores do Kubernetes o servidor da API não permitia conteúdo vazio do pacote de CA. Usar \n era uma solução alternativa razoável para evitar confusão, já que o cert-manager geralmente atualiza o caBundle depois.

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

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

    Alternativa

    Se você tiver uma definição de recurso personalizada em que caBundle está definido como um valor inválido, remova o campo caBundle por completo. Isso deve resolver o problema.
    SO 1.31

    Ao fazer upgrade de um cluster que usa a imagem do SO Container Optimized OS (COS) para a versão 1.31, o comando cloud-init status falha, embora o cloud-init tenha sido concluído sem erros.

    Alternativa:

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

        systemctl show -p Result cloud-final.service

    Se a saída for semelhante a esta, o cloud-init foi concluído com sucesso:

        Result=success
    Upgrades 1.28

    Ao fazer upgrade de um cluster para a versão 1.28, o comando gkectl prepare falha ao executar as verificações de simulação da estação de trabalho de administrador se o tamanho do disco da estação de trabalho de administrador for menor que 100 GB. Nesse caso, o comando mostra uma mensagem de erro semelhante a esta:

        Workstation Hardware: Workstation hardware requirements are not satisfied

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

    Alternativa:

    1. Reverta a estação de trabalho de administrador.
    2. Atualize o arquivo de configuração da estação de trabalho de administrador para aumentar o tamanho do disco para pelo menos 100 GB.
    3. Faça upgrade da estação de trabalho de administrador.
    Upgrades 1,30

    O comando gkectl upgrade retorna um erro incorreto sobre a classe de armazenamento do netapp. A mensagem de erro é semelhante a esta: 

        detected unsupported drivers:
      csi.trident.netapp.io

    Alternativa:

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

    Depois de alternar os certificados da autoridade de certificação (CA) em um cluster de usuário, o campo spec.certificateAuthorityData no ClientConfig contém um certificado de CA inválido, o que impede a autenticação no cluster.

    Alternativa:

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

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

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

    Alternativa:

    Ignore a mensagem de erro.
    Pule a verificação prévia usando um dos seguintes métodos:

    • Adicione a flag --skip-validation-load-balancer ao comando gkectl update cluster.
    • Adicione a anotação onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer ao objeto onpremusercluster.
      • .
    VMware, upgrades 1.16

    Durante um upgrade do cluster, os objetos de máquina podem ficar presos na fase "Criando" e não serem vinculados aos objetos de nó devido à ausência de uma regra de grupo antiafinidade (AAG) no vCenter.

    Se você descrever os objetos de máquina problemáticos, poderá ver mensagens recorrentes como "Reconfigure DRS rule task "task-xxxx" complete"

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Alternativa:

    Desative a configuração do grupo antiafinidade na configuração do cluster de administrador e na configuração do cluster de usuário e acione o comando de atualização forçada para desbloquear o upgrade 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

    Ao migrar um cluster de usuário para o Controlplane V2, se a criptografia de secrets sempre ativada tiver sido ativada, o processo de migração não vai processar corretamente a chave de criptografia de secrets. Devido a esse problema, o novo cluster do Controlplane V2 não consegue descriptografar secrets. Se a saída do comando a seguir não estiver vazia, a criptografia de secrets sempre ativada foi ativada em algum momento, e o cluster é afetado por esse problema:

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

    Se você já tiver iniciado a migração e ela falhar, entre em contato com o Google para receber suporte. Caso contrário, antes da migração, desative a criptografia de secrets sempre ativada e descriptografe os secrets.

    Migração 1.29.0-1.29.600, 1.30.0-1.30.100

    Se o cluster de administrador tiver ativado a criptografia de segredos ativa na versão 1.14 ou anterior e tiver feito upgrade de versões antigas para as versões 1.29 e 1.30 afetadas, ao migrar o cluster de administrador de não HA para HA, o processo de migração não vai processar corretamente a chave de criptografia de segredos. Devido a esse problema, o novo cluster de administrador de HA não vai conseguir descriptografar segredos.

    Para verificar se o cluster está usando 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 a saída mostrar a chave vazia, como no exemplo a seguir, significa que o cluster será afetado por esse problema:

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

    Se você já tiver iniciado a migração e ela falhar, entre em contato com o Google para receber suporte.

    Caso contrário, antes de iniciar a migração, faça a rotação da chave de criptografia.
    Upgrades 1.16, 1.28, 1.29, 1.30

    Ao fazer upgrade da estação de trabalho de administrador usando o comando gkeadm upgrade admin-workstation, o arquivo credential.yaml é regenerado incorretamente. Os campos de nome de usuário e senha estão vazios. Além disso, a chave privateRegistry contém um erro de digitação.

    O mesmo erro de ortografia da chave privateRegistry também está no arquivo admin-cluster.yaml.
    Como o arquivo credential.yaml é regenerado durante o processo de upgrade do cluster de administrador, o erro de digitação vai aparecer mesmo que você tenha corrigido antes.

    Alternativa:

    • Atualize o nome da chave de registro particular em credential.yaml para corresponder ao privateRegistry.credentials.fileRef.entry no admin-cluster.yaml.
    • Atualize o nome de usuário e a senha do registro particular no credential.yaml.
    Upgrades 1.16+

    Ao fazer upgrade de um cluster de usuário, a operação de reconciliação antes do upgrade pode levar mais tempo do que o tempo limite definido, resultando em uma falha de upgrade. A mensagem de erro é semelhante a esta:

    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 tempo limite para a operação de reconciliação antes do upgrade é de 5 minutos mais 1 minuto por pool de nós no cluster de usuário.

    Alternativa:

    Verifique se o comando gkectl diagnose cluster é executado sem erros.
    Pule a operação de reconciliação pré-upgrade 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

    Ao atualizar o campo dataplaneV2.forwardMode do cluster de usuário usando gkectl update cluster, a mudança só é atualizada no ConfigMap. O DaemonSet anetd não vai detectar a mudança de configuração até ser reiniciado, e suas alterações não serão aplicadas.

    Alternativa:

    Quando o comando gkectl update cluster for concluído, você verá a saída de Done updating the user cluster. Depois de ver essa mensagem, execute o seguinte comando para reiniciar o anetd DaemonSet e aplicar a mudança de configuração:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

    Verifique a prontidão do DaemonSet após a reinicialização:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

    Na saída do comando anterior, verifique se o número na coluna DESIRED corresponde ao número na coluna READY.
    Upgrades 1.16

    Durante um upgrade do cluster de usuário da versão 1.16 para a 1.28, o cluster de administrador é armazenado em backup. O processo de backup do cluster de administrador mostra a mensagem de erro "etcdctl: command not found". O upgrade do cluster de usuário é concluído, e o cluster de administrador permanece em um estado íntegro. O único problema é que o arquivo de metadados no cluster de administrador não é armazenado em backup.

    O problema é que o binário etcdctl foi adicionado na versão 1.28 e não está disponível nos nós 1.16.

    O backup do cluster de administrador envolve várias etapas, incluindo a criação de um snapshot do etcd e a gravação do arquivo de metadados do cluster de administrador. O backup do etcd ainda é bem-sucedido porque etcdctl ainda pode ser acionado após uma execução no pod do etcd. Mas a gravação do arquivo de metadados falha porque ainda depende do binário etcdctl para ser instalado no nó. No entanto, o backup do arquivo de metadados não impede a criação de um backup. Portanto, o processo de backup e o upgrade do cluster de usuário ainda são concluídos.

    Alternativa:

    Se quiser fazer um backup do arquivo de metadados, siga Fazer backup e restaurar um cluster de administrador com gkectl para acionar um backup separado do cluster de administrador usando a versão do gkectl que corresponde à versão do seu cluster de administrador.
    Instalação 1.16-1.29

    Ao criar um cluster de usuário configurado para balanceamento de carga manual, ocorre uma falha de gkectl check-config, indicando que o valor de ingressHTTPNodePort precisa ser pelo menos 30000, mesmo quando a entrada agrupada está desativada.

    Esse problema ocorre independente de os campos ingressHTTPNodePort e ingressHTTPSNodePort estarem definidos ou em branco.

    Alternativa:

    Para contornar esse problema, ignore o resultado retornado por gkectl check-config. Para desativar a entrada em pacote, consulte Desativar a entrada em pacote.
    Atualizações 1.29.0

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

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

    Se houver dois ou mais objetos de nó sem uma função após a migração, o PDB não estará mal configurado.

    Sintomas:

    A saída 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).

    Alternativa:

    Execute o comando a seguir para excluir o PDB:

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

    Em condições de disputa raras, uma sequência de instalação incorreta do webhook da autorização binária e do pod gke-connect pode fazer com que a criação do cluster de usuário seja interrompida devido a um nó que não consegue atingir um estado pronto. Em cenários afetados, a criação do cluster de usuário pode ser interrompida porque um nó não consegue atingir um estado pronto. Se isso acontecer, a seguinte mensagem será exibida:

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

    Alternativa:

    1. Remova a configuração da Autorização binária do arquivo de configuração. Para instruções de configuração, consulte o guia de instalação do segundo dia da autorização binária para o GKE no VMware.
    2. Para desbloquear um nó não íntegro durante o processo atual de criação do cluster, remova temporariamente a configuração do webhook da autorização binária no cluster de usuário usando o comando a seguir. 
              kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
      Depois que o processo de bootstrap for concluído, você poderá adicionar novamente 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
    Upgrades 1.16, 1.28, 1.29

    Durante um upgrade de cluster de usuário, a operação pode ficar travada se o objeto de máquina espelhada no cluster de usuário contiver um deletionTimestamp. A seguinte mensagem de erro será exibida se o upgrade estiver travado:

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

    Esse problema pode ocorrer se você tentou corrigir o nó do plano de controle do usuário executando gkectl delete machine na máquina espelhada no cluster de usuário.

    Alternativa:

    1. Receba o objeto da máquina espelhada e salve-o em um arquivo local para fins de backup.
    2. Execute o comando a seguir para excluir o finalizador da máquina espelhada e aguarde a exclusão do cluster de usuário. 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
    3. Siga as etapas em Nó do plano de controle do cluster de usuário do plano de controle V2 para acionar o reparo do nó nos nós do plano de controle. Assim, a especificação correta da máquina de origem será ressincronizada no cluster de usuário.
    4. Execute o gkectl upgrade cluster novamente para retomar o upgrade
    Configuração, instalação 1.15, 1.16, 1.28, 1.29

    Para um cluster de administrador de alta disponibilidade ou um cluster de usuário do ControlPlane V2, o VIP do plano de controle precisa estar na mesma sub-rede que os outros nós do cluster. Caso contrário, a criação do cluster vai falhar porque o kubelet não consegue se comunicar com o servidor da API usando o VIP do plano de controle.

    Alternativa:

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

    A criação/upgrade do cluster falha com um erro nos pods CSI do vSphere indicando que o nome de usuário do vCenter é inválido. Isso ocorre porque o nome de usuário 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

    Esse problema só ocorre na versão 1.29 e mais recentes, porque uma validação foi adicionada ao driver CSI do vSphere para exigir o uso de nomes de usuário de domínio totalmente qualificados.

    Alternativa:

    Use um nome de domínio totalmente qualificado para o nome de usuário do vCenter no arquivo de configuração de credenciais. Por exemplo, em vez de usar "username1", use "username1@example.com".
    Upgrades, atualizações 1.28.0 - 1.28.500

    Ao fazer upgrade de um cluster de administrador da versão 1.16 para 1.28, o bootstrap da nova máquina mestre de administrador pode não gerar o certificado do plano de controle. O problema é causado por mudanças na forma como os certificados são gerados para o servidor da API Kubernetes na versão 1.28 e mais recentes. O problema se reproduz em clusters criados nas versões 1.10 e anteriores que foram atualizados até a 1.16 e o certificado folha não foi girado antes da atualização.

    Para determinar se a falha no upgrade do cluster de administrador é causada por esse problema, siga estas etapas:

    1. Conecte-se à máquina mestre de administrador com falha usando SSH.
    2. Abra /var/log/startup.log e procure um erro como este:
    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>

    Alternativa:

    1. Conecte-se à máquina mestre de administrador usando SSH. Para mais detalhes, consulte Como usar o SSH para se conectar a um nó de cluster de administrador.
    2. Faça uma cópia de /etc/startup/pki-yaml.sh e nomeie como /etc/startup/pki-yaml-copy.sh
    3. Editar /etc/startup/pki-yaml-copy.sh. Encontre authorityKeyIdentifier=keyidset e mude para authorityKeyIdentifier=keyid,issuer nas seçõ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. Salve as mudanças em /etc/startup/pki-yaml-copy.sh.
    5. Usando um editor de texto, abra /opt/bin/master.sh, encontre e substitua todas as ocorrências de /etc/startup/pki-yaml.sh por /etc/startup/pki-yaml-copy.sh e salve as mudanças.
    6. Execute /opt/bin/master.sh para gerar o certificado e concluir a inicialização da máquina.
    7. Execute o gkectl upgrade admin novamente para fazer upgrade do cluster de administrador.
    8. Depois que o upgrade for concluído, alterne o certificado folha para os clusters de administrador e de usuário, conforme descrito em Iniciar a rotação.
    9. Depois que a rotação do certificado for concluída, faça as mesmas edições em /etc/startup/pki-yaml-copy.sh que você fez antes e execute /opt/bin/master.sh.
    Configuração 1.29.0

    A seguinte mensagem de aviso incorreta é exibida quando você executa gkectl para criar, atualizar ou fazer upgrade de um cluster que já tem 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.

    Há um bug no gkectl que faz com que ele sempre mostre esse aviso enquanto o dataplaneV2.forwardMode não estiver sendo usado, mesmo que você já tenha definido enableDataplaneV2: true no arquivo de configuração do cluster.

    Alternativa:

    Você pode ignorar esse aviso com segurança.
    Configuração 1.28.0-1.28.400, 1.29.0

    Ao criar um cluster de administrador de alta disponibilidade, a verificação de simulação mostra 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 alta disponibilidade 1.28 e mais recentes porque eles não têm mais nós de complemento. Além disso, como os 3 IPs do nó do plano de controle do cluster de administrador são especificados na seção network.controlPlaneIPBlock do arquivo de configuração do cluster de administrador, os IPs no arquivo de bloco de IP são necessários apenas para nós do plano de controle do cluster de usuário do kubeception.

    Alternativa:

    Para pular a verificação de simulação incorreta em uma versão não corrigida, adicione --skip-validation-net-config ao comando gkectl.
    Operação 1.29.0-1.29.100

    Se você migrou de um cluster de administrador não HA para um cluster de administrador HA, o agente do Connect no cluster de administrador perde a conexão com gkeconnect.googleapis.com com o erro "Falha ao verificar a assinatura JWT". Isso acontece porque, durante a migração, a chave de assinatura do KSA é alterada. Portanto, é necessário fazer um novo registro para atualizar os JWKs do OIDC.

    Alternativa:

    Para reconectar o cluster de administrador ao Google Cloud, siga estas etapas para acionar um novo registro:

    Primeiro, consiga o nome da implantação do gke-connect:

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

    Exclua a implantaçã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 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 sempre vai implantar novamente a implantação do gke-connect e registrar o cluster se não encontrar uma implantação do gke-connect disponível.

    Depois da solução alternativa (pode levar alguns minutos para que o controlador conclua a reconciliação), verifique se o erro 400 "Falha ao verificar a assinatura JWT" desapareceu dos registros gke-connect-agent:

    kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
    Instalação, sistema operacional 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 do Docker na configuração do Docker para evitar a reserva da sub-rede 172.17.0.1/16 padrão. No entanto, nas versões 1.28.0 a 1.28.500 e 1.29.0, o serviço do Docker não era reiniciado depois que o Google Distributed Cloud personalizava a configuração do Docker devido a uma regressão na imagem do SO COS. Como resultado, o Docker escolhe o 172.17.0.1/16 padrão como a sub-rede de endereço IP da ponte. Isso poderá causar um conflito de endereços IP se a carga de trabalho já estiver em execução nesse intervalo de endereços IP.

    Alternativa:

    Para contornar esse problema, reinicie o serviço do 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 permanece nas recriações de VM. Aplique a solução novamente sempre que as VMs forem recriadas.
    update 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 são incluídos nas imagens do SO nas versões afetadas. Esses binários do CNI não são usados pelo plano de dados v2, mas podem ser usados para outras interfaces de rede no recurso de várias interfaces de rede.

    Várias interfaces de rede com esses plug-ins CNI não vão funcionar.

    Alternativa:

    Faça upgrade para a versão com a correção se você estiver usando esse recurso.
    update 1.15, 1.16, 1.28

    A instalação de multipathd em nós de cluster interfere no driver CSI do vSphere, o que impede o início das cargas de trabalho do usuário.

    Alternativa:

    • Desativar multipathd
    Atualizações 1.15, 1.16

    Se algumas configurações obrigatórias estiverem vazias no cluster de administrador porque as validações foram ignoradas, a adição delas poderá ser bloqueada pelo webhook do cluster de administrador. Por exemplo, se o campo gkeConnect não foi definido em um cluster de administrador, 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
    Às vezes, pode haver um problema na comunicação entre o servidor da API Kubernetes e o webhook. Quando isso acontecer, você poderá 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

    Alternativa:

    Se você encontrar um desses erros, use uma das seguintes soluções alternativas, dependendo da 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 você usar um balanceador de carga manual (loadBalancer.kind definido como "ManualLB"), não será necessário configurar a seção loadBalancer.manualLB no arquivo de configuração de um cluster de administrador de alta disponibilidade (HA) nas versões 1.16 e mais recentes. No entanto, quando essa seção está vazia, o Google Distributed Cloud atribui valores padrão a todos os NodePorts, 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

    Alternativa:

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

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

    nfs-common está faltando na imagem do SO Ubuntu, o que pode causar problemas para clientes que usam drivers dependentes do NFS, como o NetApp.

    Se o log contiver uma entrada como a seguinte após a atualização para a versão 1.28, você será 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".

    Alternativa:

    Verifique se os nós podem fazer o download de pacotes da Canonical.

    Em seguida, aplique o seguinte DaemonSet ao 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 é compatível com a versão 1.28.0 e mais recentes. Mas o campo vCenter.storagePolicyName está ausente no modelo de arquivo de configuração.

    Alternativa:

    Adicione o campo `vCenter.storagePolicyName` no arquivo de configuração do cluster de administrador se você quiser configurar a política de armazenamento para o cluster de administrador. Consulte as instruções.
    Geração de registros e monitoramento 1.28.0-1.28.100

    A API kubernetesmetadata.googleapis.com, adicionada recentemente, não é compatível com o VPC-SC. Isso fará com que o agente de coleta de metadados não consiga acessar essa API no VPC-SC. Consequentemente, os rótulos de metadados de métricas vão ficar faltando.

    Alternativa:

    No namespace "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}}}'`

    depois 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"}]}]}}}}'`

    Upgrades, atualizações 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

    Quando um cluster de administrador e um cluster de usuário com o ControlPlane V2 ativado usam credenciais diferentes do vSphere, por exemplo, depois de atualizar as credenciais do vSphere para o cluster de administrador, o clusterapi-controller pode não se conectar ao vCenter após a reinicialização. Confira o registro do clusterapi-controller em execução no namespace `kube-system` do cluster de administrador.

    kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG
     Quando esse problema está afetando você, o registro contém uma entrada como esta: 
    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

    Alternativa:

    Atualize as credenciais do vSphere para que o cluster de administrador e todos os clusters de usuário com o Controlplane V2 ativado usem as mesmas credenciais do vSphere.

    Geração de registros e monitoramento 1.14

    O Prometheus pode gerar alertas semelhantes ao exemplo a seguir:

    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 esse alerta é um falso positivo que pode ser ignorado, siga estas etapas:

    1. Compare a métrica grpc_server_handled_total bruta com o grpc_method informado na mensagem de alerta. Neste exemplo, verifique o rótulo grpc_code para Watch.

      É possível verificar essa métrica usando o Cloud Monitoring com a seguinte consulta em MQL: 
      fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
    2. Um alerta em todos os códigos diferentes de OK pode ser ignorado com segurança se o código não for um dos seguintes: 
      Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

    Alternativa:

    Para configurar o Prometheus e ignorar esses alertas de falso positivo, analise as seguintes opções:

    1. Silencie o alerta na interface do Alert Manager.
    2. Se não for possível silenciar o alerta, siga estas etapas para suprimir os falsos positivos:
      1. Reduza a escala vertical do operador de monitoramento para réplicas 0 para que as modificações possam persistir.
      2. Modifique o configmap prometheus-config e adicione grpc_method!="Watch" à configuração de alerta etcdHighNumberOfFailedGRPCRequests, conforme mostrado no exemplo a seguir:
        • 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 cluster.
      3. Reinicie o Statefulset do Prometheus e do Alertmanager para escolher a nova configuração.
    3. Se o código se enquadrar em um dos casos problemáticos, verifique os registros do etcd e do kube-apiserver para depurar mais.
    Rede 1.16.0-1.16.2, 1.28.0

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

    Como o conntrack só importa na direção de entrada (conexões externas com o cluster), esse problema só acontece se a conexão não transmitir nenhuma informação por um tempo e, em seguida, o lado de destino transmitir algo. Se o pod com NAT de saída sempre instanciar a mensageria, esse problema não vai aparecer.

    Esse problema ocorre porque a coleta de lixo do anetd remove inadvertidamente entradas conntrack que o daemon considera não utilizadas. Uma correção upstream foi integrada recentemente ao anetd para corrigir o comportamento.


    Alternativa:

    Não há uma solução alternativa fácil, e não encontramos problemas na versão 1.16 com esse comportamento. Se você notar que conexões de longa duração foram descartadas devido a esse problema, use uma carga de trabalho no mesmo nó do endereço IP de saída ou envie mensagens de forma consistente na conexão TCP.
    Operação 1.14, 1.15, 1.16

    Se você criar um CertificateSigningRequest (CSR) com expirationSeconds definido, o expirationSeconds será ignorado.

    Alternativa:

    Se você for afetado por esse problema, atualize o cluster de usuário adicionando disableNodeIDVerificationCSRSigning: true no arquivo de configuração do cluster de usuário e execute o comando gkectl update cluster para atualizar o cluster com essa configuração.
    Rede, upgrades e atualizações 1.16.0-1.16.3

    Se você tentar desativar a entrada agrupada para um cluster atual, o comando gkectl update cluster vai falhar com um erro semelhante ao exemplo a seguir:

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

    Esse erro ocorre porque gkectl verifica um endereço IP de entrada do balanceador de carga durante as verificações de simulação. Embora essa verificação não seja necessária ao desativar a entrada agrupada, a verificação de simulação gkectl falha quando disableBundledIngress é definido como true.


    Alternativa:

    Use o parâmetro --skip-validation-load-balancer ao atualizar o cluster, conforme mostrado no exemplo a seguir:

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

    Para mais informações, consulte como desativar a entrada agrupada em um cluster atual.
    Upgrades, atualizações 1.13, 1.14, 1.15.0-1.15.6

    Se você rotacionar os certificados da autoridade certificadora (CA) do cluster de administrador, as tentativas subsequentes de executar o comando gkectl update admin vão falhar. O erro retornado é semelhante a este:

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

    Alternativa:

    Se você for afetado por esse problema, atualize o cluster de administrador usando a flag --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 você usa a flag --disable-update-from-checkpoint, o comando de atualização não usa o arquivo de checkpoint como a fonte de verdade durante a atualização do cluster. O arquivo de checkpoint ainda é atualizado para uso futuro.
    Armazenamento 1.15.0-1.15.6, 1.16.0-1.16.2

    Durante as verificações de simulação, a verificação de validação da carga de trabalho da CSI instala um pod no namespace default. O pod de carga de trabalho do CSI valida se o driver CSI do vSphere está instalado e pode fazer o provisionamento dinâmico de volume. Se esse pod não for iniciado, a verificação de validação da carga de trabalho do CSI vai falhar.

    Há alguns problemas conhecidos que podem impedir a inicialização desse pod:

    • Se o pod não tiver limites de recursos especificados, o que acontece em alguns clusters com webhooks de admissão instalados, o pod não será iniciado.
    • Se o Cloud Service Mesh estiver instalado no cluster com a injeção automática de arquivo secundário do Istio ativada no namespace default, o pod de carga de trabalho do CSI não será iniciado.

    Se o pod de carga de trabalho do CSI não for iniciado, você vai receber um erro de tempo limite como o seguinte durante as validações de simulação:

    - [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 verificar se a falha é causada pela falta de recursos de pod definidos, execute o comando a seguir para verificar o status do job 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 status do job vai conter uma mensagem de erro como esta:

    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, desative temporariamente a injeção automática de sidecar do Istio no namespace default. Verifique os rótulos do namespace e use o seguinte comando para excluir o rótulo que começa com istio.io/rev:

    kubectl label namespace default istio.io/rev-

    Se o pod estiver mal configurado, verifique manualmente se o provisionamento dinâmico de volume com o driver CSI do vSphere funciona:

    1. Crie um PVC que use o StorageClass standard-rwo.
    2. Crie um pod que use o PVC.
    3. Verifique se o pod pode ler/gravar dados no volume.
    4. Remova o pod e o PVC depois de verificar se a operação está correta.

    Se o provisionamento dinâmico de volume com o driver CSI do vSphere funcionar, execute gkectl diagnose ou gkectl upgrade com a flag --skip-validation-csi-workload para pular a verificação de carga de trabalho do CSI.

    Operação 1.16.0-1.16.2

    Quando você faz login em uma estação de trabalho de administrador gerenciada pelo usuário, o comando gkectl update cluster pode atingir o tempo limite e não atualizar o cluster de usuário. Isso acontece se a versão do cluster de administrador for 1.15 e você executar gkectl update admin antes de executar gkectl update cluster. Quando essa falha acontece, você vê o seguinte erro ao tentar fazer upgrade do 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 de simulação é removido do cluster. Se você tentar atualizar o cluster de usuário, a verificação de simulação vai ficar pendente até atingir o tempo limite.

    Alternativa:

    1. Execute o comando a seguir para reimplantar o validation-controller: 
            gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
    2. Depois que a preparação for concluída, execute o gkectl update cluster novamente para atualizar o cluster de usuário.
    Operação 1.16.0-1.16.2

    Quando você faz login em uma estação de trabalho de administrador gerenciada pelo usuário, o comando gkectl create cluster pode atingir o tempo limite e não criar o cluster de usuário. Isso acontece se a versão do cluster de administrador for 1.15. Quando essa falha acontece, você vê 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

    Como o validation-controller foi adicionado na versão 1.16, ao usar o cluster de administrador 1.15, o validation-controller responsável por acionar as verificações de simulação está ausente. Portanto, ao tentar criar um cluster de usuário, as verificações de simulação ficam pendentes até que o tempo limite seja atingido.

    Alternativa:

    1. Execute o comando a seguir para implantar o validation-controller: 
            gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
    2. Depois que a preparação for concluída, execute o comando gkectl create cluster novamente para criar o cluster de usuário.
    Upgrades, atualizações 1.16.0-1.16.2

    Ao fazer upgrade de um cluster de administrador da versão 1.15.x para 1.16.x ou adicionar uma configuração connect, stackdriver, cloudAuditLogging ou gkeOnPremAPI ao atualizar um cluster de administrador, a operação poderá ser rejeitada pelo webhook do cluster de administrador. Uma das seguintes mensagens de erro pode aparecer:

    • "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 upgrade do cluster de administrador exige que o onprem-admin-cluster-controller reconcilie o cluster de administrador em um cluster do tipo. Quando o estado do cluster de administrador é restaurado no cluster kind, 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 operações de uma atualização ou upgrade. Algumas validações de criação exclusiva são invocadas ao atualizar e fazer upgrade inesperadamente.


    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:
      • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.
      • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
    2. Adicione a anotação onprem.cluster.gke.io/skip-project-location-sameness-validation: true e salve o recurso personalizado.
    3. Dependendo do tipo de clusters de administrador, siga uma destas etapas:
      • Para clusters de administrador que não são de alta disponibilidade com um arquivo de ponto de controle:adicione o parâmetro disable-update-from-checkpoint ao comando de atualização ou adicione o parâmetro `disable-upgrade-from-checkpoint` ao comando de upgrade. Esses parâmetros só são necessários na próxima vez que você 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 alta disponibilidade ou se o arquivo de checkpoint estiver desativado:atualize ou faça upgrade do cluster de administrador normalmente. Nenhum parâmetro adicional é necessário nos comandos de atualização ou upgrade.
    Operação 1.16.0-1.16.2

    Quando você faz login em uma estação de trabalho de administrador gerenciada pelo usuário, o comando gkectl delete cluster pode atingir o tempo limite e não excluir o cluster de usuário. Isso acontece se você primeiro executar gkectl na estação de trabalho gerenciada pelo usuário para criar, atualizar ou fazer upgrade do cluster de usuário. Quando essa falha acontece, você vê o seguinte erro ao tentar excluir 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 exclusão, um cluster primeiro exclui todos os objetos dele. A exclusão dos objetos de validação (criados durante a criação, atualização ou upgrade) fica travada na fase de exclusão. Isso acontece porque um finalizador bloqueia a exclusão do objeto, o que faz com que a exclusão do cluster falhe.

    Alternativa:

    1. Consiga os nomes de todos os objetos de validação: 
               kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
    2. Para cada objeto de validação, execute o comando a seguir para remover o finalizador do objeto: 
            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 serão removidos e a operação de exclusão do cluster de usuário será concluída automaticamente. Você não precisa fazer nada.

    Rede 1.15, 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 poderá alcançar nenhum serviço externo. Se os pods estiverem no mesmo host, a conexão com o serviço ou aplicativo externo será bem-sucedida.

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


    Alternativa:

    Mude a porta VXLAN usada pelo Cilium para 4789:

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

    Essa solução alternativa é revertida sempre que o cluster é atualizado. É necessário reconfigurar após cada upgrade. A VMware precisa resolver o problema no vSphere para uma correção permanente.
    Upgrades 1.15.0-1.15.4

    O upgrade do cluster de administrador da versão 1.14.x para a 1.15.x com a criptografia de secrets sempre ativada falha devido a uma incompatibilidade entre a chave de criptografia gerada pelo controlador e a chave que persiste no disco de dados mestre 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 você tiver um backup do cluster de administrador, siga estas etapas para evitar a falha de upgrade:

    1. Desative secretsEncryption no arquivo de configuração do cluster de administrador e atualize o cluster usando o seguinte comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    2. Quando a nova VM mestre do administrador for criada, faça login nela por SSH e substitua a nova chave no disco de dados pela antiga do backup. A chave está localizada em /opt/data/gke-k8s-kms-plugin/generatedkeys no mestre administrador.
    3. Atualize o manifesto do pod estático kms-plugin.yaml em /etc/kubernetes/manifests para atualizar o --kek-id e corresponder ao campo kid na chave de criptografia original.
    4. Reinicie o pod estático kms-plugin movendo o /etc/kubernetes/manifests/kms-plugin.yaml para outro diretório e depois movendo-o de volta.
    5. Retome o upgrade do administrador executando gkectl upgrade admin novamente.

    Como evitar a falha do upgrade

    Se você ainda não fez upgrade, recomendamos que não faça para as versões 1.15.0 a 1.15.4. Se você precisar fazer upgrade para uma versão afetada, siga as etapas abaixo antes de fazer upgrade do cluster de administrador:

    1. Faça backup do cluster de administrador.
    2. Desative secretsEncryption no arquivo de configuração do cluster de administrador e atualize o cluster usando o seguinte comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    3. Fazer upgrade do cluster de administrador
    4. Reative a criptografia de secrets sempre ativada.
    Armazenamento 1.11-1.16

    O Google Distributed Cloud não oferece suporte ao acompanhamento de bloco alterado (CBT) em discos. Alguns softwares de backup usam o recurso CBT para rastrear o estado do disco e fazer backups, o que impede que o disco se conecte a uma VM que executa o Google Distributed Cloud. Para mais informações, consulte o artigo da base de conhecimento da VMware.


    Alternativa:

    Não faça backup das VMs do Google Distributed Cloud, porque um software de backup de terceiros pode ativar o CBT nos discos delas. Não é necessário fazer backup dessas VMs.

    Não ative a CBT no nó, porque essa mudança não vai persistir em atualizações ou upgrades.

    Se você já tiver discos com o CBT ativado, siga as etapas de Resolução no artigo da base de conhecimento do VMware para desativar o CBT no disco de primeira classe.
    Armazenamento 1.14, 1.15, 1.16

    Se você usa arrays de armazenamento Nutanix para fornecer compartilhamentos NFSv3 aos seus hosts, pode ocorrer corrupção de dados ou incapacidade de execução dos pods com êxito. Esse 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 base de conhecimento da VMware associado.


    Alternativa:

    O artigo da base de conhecimento da VMware está desatualizado, porque não há uma resolução atual. Para resolver esse problema, atualize para a versão mais recente do ESXi nos hosts e para a versão mais recente do Nutanix nas matrizes de armazenamento.
    Sistema operacional 1.13.10, 1.14.6, 1.15.3

    Em algumas versões do Google Distributed Cloud, o kubelet em execução nos nós usa uma versão diferente do plano de controle do Kubernetes. Há uma incompatibilidade porque o binário kubelet pré-carregado na imagem do SO está usando uma versão diferente.

    A tabela a seguir lista as incompatibilidades de versão 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

    Alternativa:

    Nenhuma ação é necessária. A inconsistência é apenas entre as versões de patch do Kubernetes, e não houve problemas causados por essa distorção de versão.

    Upgrades, atualizações 1.15.0-1.15.4

    Quando um cluster de administrador tem uma versão de autoridade certificadora (CA) maior que 1, uma atualização ou upgrade falha devido à validação da versão da CA no webhook. A saída de gkectl upgrade/update contém a seguinte mensagem de erro: 

        CAVersion must start from 1

    Alternativa:

    • Reduza a escala vertical da implantação de auto-resize-controller no cluster de administrador para desativar o redimensionamento automático de nós. Isso é necessário porque um novo campo introduzido no recurso personalizado do cluster de administrador na 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 Controlplane V2 não HA é excluído, ele fica preso na exclusão de nós até atingir o tempo limite.

    Alternativa:

    Se o cluster tiver um StatefulSet com dados críticos, entre em contato com o Cloud Customer Care para resolver esse problema.

    Caso contrário, siga estas etapas:

    • Exclua todas as VMs do cluster do vSphere. É possível excluir as VMs pela UI do vSphere ou executar o seguinte comando: 
            govc vm.destroy
      .
    • Force a exclusã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 permanentes do vSphere em árvore (por exemplo, PVCs criados com a StorageClass standard), você observa tarefas com.vmware.cns.tasks.attachvolume acionadas a cada minuto no vCenter.


    Alternativa:

    Edite o ConfigMap de recursos do CSI do vSphere e defina "list-volumes" como "false":

         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 permanentes do vSphere no kernel, os comandos gkectl diagnose e gkectl upgrade podem gerar avisos falsos contra as declarações de volume permanente (PVCs) ao validar as configurações de armazenamento do cluster. A mensagem de aviso é semelhante a esta: 

        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

    Alternativa:

    Execute o comando a seguir 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, ignore o aviso:

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

    Se o cluster não estiver usando um registro particular e as chaves da conta de serviço de acesso a componentes e da conta de serviço de geração de registros e monitoramento (ou registro do Connect) estiverem expiradas, quando você fizer a rotação das chaves da conta de serviço, o gkectl update credentials vai falhar com um erro semelhante a este: 

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

    Alternativa:

    Primeiro, alterne a chave da conta de serviço de acesso a componentes. Embora a mesma mensagem de erro seja exibida, você poderá girar as outras chaves após a rotação de chaves da conta de serviço de acesso do componente.

    Se a atualização ainda não for concluída, entre em contato com o Cloud Customer Care para resolver esse problema.
    Upgrades 1.16.0-1.16.5

    Durante um upgrade do cluster de usuário, depois que o controlador do cluster de usuário for atualizado para a versão 1.16, se você tiver outros clusters de usuário 1.15 gerenciados pelo mesmo cluster de administrador, a máquina mestre do usuário poderá ser recriada inesperadamente.

    Há um bug no controlador de cluster de usuário 1.16 que pode acionar a recriação da máquina mestre do usuário 1.15.

    A solução alternativa depende de como você encontra esse problema.

    Solução alternativa ao fazer upgrade do cluster de usuário usando o console Google Cloud :

    Opção 1: use uma versão 1.16.6 ou mais recente do GKE no VMware com a correção.

    Opção 2: siga estas etapas:

    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 nova execução é:

      onprem.cluster.gke.io/server-side-preflight-rerun: true
    2. Monitore o progresso do upgrade verificando o campo status do OnPremUserCluster.

    Solução alternativa ao fazer upgrade do cluster de usuário usando sua própria estação de trabalho do administrador:

    Opção 1: use uma versão 1.16.6 ou mais recente do GKE no VMware com a correção.

    Opção 2: siga estas etapas:

    1. Adicione o arquivo de informações de build /etc/cloud/build.info com o seguinte conteúdo. Isso faz com que as verificações de simulação sejam executadas localmente na estação de trabalho do administrador em vez de no servidor. 
      gke_on_prem_version: GKE_ON_PREM_VERSION
       Por exemplo: 
      gke_on_prem_version: 1.16.0-gke.669
    2. Execute o comando de upgrade novamente.
    3. Depois que o upgrade for concluído, exclua o arquivo build.info.
    Criar 1.16.0-1.16.5, 1.28.0-1.28.100

    Durante a criação do cluster, se você não especificar um nome do host para cada endereço IP no arquivo de bloco de IP, a verificação de simulação vai falhar 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.`

    Há um bug na verificação de simulação que considera o nome do host vazio como duplicado.

    Alternativa:

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

    Opção 2: ignore essa verificação de simulação adicionando a flag --skip-validation-net-config.

    Opção 3: especificar um nome do host exclusivo para cada endereço IP no arquivo de bloco de IPs.
    Upgrades, atualizações 1.16

    Para um cluster de administrador que não seja HA e um cluster de usuário do plano de controle v1, quando você faz upgrade ou atualização do cluster de administrador, a recriação da máquina mestre do cluster de administrador pode acontecer ao mesmo tempo que a reinicialização da máquina mestre do cluster de usuário, o que pode causar uma disputa. Isso faz com que os pods do plano de controle do cluster de usuário não consigam se comunicar com o plano de controle do cluster de administrador, o que causa problemas de anexação de volume para kube-etcd e kube-apiserver no plano de controle do cluster de usuário.

    Para verificar o problema, execute os seguintes comandos no pod afetado:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
     Você vai ver 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"

    Alternativa:

    1. Estabeleça uma conexão SSH com o nó do plano de controle do usuário. Como é um cluster de usuário do plano de controle v1, o nó do plano de controle do usuário está no cluster de administrador.
    2. Reinicie o kubelet usando o seguinte comando: 
          sudo systemctl restart kubelet
      Após a reinicialização, o kubelet pode reconstruir a montagem global de estágio corretamente.
    Upgrades, atualizações 1.16.0

    Durante um upgrade ou atualização de um cluster de administrador, uma disputa pode fazer com que o gerenciador de controladores de nuvem do vSphere exclua inesperadamente um novo nó do plano de controle. Isso faz com que o clusterapi-controller fique preso aguardando a criação do nó e, finalmente, o upgrade/atualização expira. Nesse caso, a saída do comando de upgrade/atualização gkectl é semelhante a esta:

        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 fazer login no gerenciador de controladores de 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

    Confira um exemplo de mensagem de erro do comando acima:

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

    Alternativa:

    1. Reinicie a máquina com falha para recriar o objeto de nó excluído.
    2. Estabeleça uma conexão SSH com cada nó do plano de controle e reinicie o pod estático do gerenciador de controladores de nuvem do vSphere: 
            sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
    3. Execute novamente o comando de upgrade/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 houver nomes de host duplicados no mesmo data center. Isso acontece porque o gerenciador de controladores de nuvem do vSphere não adiciona um IP externo e um ID de provedor ao objeto do nó. Isso causa o tempo limite do upgrade/criação do cluster.

    Para identificar o problema, extraia os registros do pod do gerenciador de controladores de nuvem do vSphere para o cluster. O comando usado depende do tipo de cluster, da seguinte maneira:

    • 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 usuário 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 usuário 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

    Confira um exemplo de mensagem de erro:

        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 do host está duplicado no data center:

    Use a abordagem a seguir para verificar se o nome do host está duplicado e faça 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 saída: 
              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 depende da operação que falhou.

    Solução alternativa para upgrades:

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

    • Cluster de usuário:
      1. Atualize o nome do host da máquina afetada em user-ip-block.yaml para um nome exclusivo e acione uma atualização forçada:
                  gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
      2. Executar gkectl upgrade cluster novamente
    • Cluster de administrador:
      1. Atualize o nome do host da máquina afetada em admin-ip-block.yaml para um nome exclusivo 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 que não é HA e você descobrir que a VM mestre de administrador está usando um nome do host duplicado, também será necessário:
        Conferir o nome da máquina mestre de administrador 
                  kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
        Atualizar o objeto da máquina principal de administrador
        Observação:o NEW_ADMIN_MASTER_HOSTNAME precisa ser igual ao que você definiu em admin-ip-block.yaml na etapa 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 host foi 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. Execute novamente o upgrade do cluster de administrador com o checkpoint desativado:
                  gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

    Solução alternativa para instalações:

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

    As operações a seguir falham quando o nome de usuário ou a senha do vSphere contém $ ou `:

    • Fazer upgrade de um cluster de usuário 1.15 com o Controlplane V2 ativado para a versão 1.16
    • Fazer upgrade de um cluster de administrador de alta disponibilidade (HA) da versão 1.15 para a 1.16
    • Como criar um cluster de usuário 1.16 com o Controlplane V2 ativado
    • Como criar um cluster de administrador de alta disponibilidade 1.16

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

    Solução alternativa para upgrades:

    1. Mude o nome de usuário ou a senha do vCenter no lado do vCenter para remover o $ e o `.
    2. Atualize o nome de usuário ou a senha do vCenter no arquivo de configuração de credenciais.
    3. Aciona uma atualização forçada do cluster.
      • Cluster de usuário: 
                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. Mude o nome de usuário ou a senha do vCenter no lado do vCenter para remover o $ e o `.
    2. Atualize o nome de usuário ou a senha do vCenter no arquivo de configuração de credenciais.
    3. Faça 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 que um nó é excluído e recriado com o mesmo nome, há uma pequena chance de que uma criação subsequente de PersistentVolumeClaim (PVC) falhe com um erro como este:

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

    Isso é causado por uma condição de disputa em que o controlador CSI do vSphere não exclui uma máquina removida do cache.


    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 você executa o comando gkectl repair admin-master em um cluster de administrador de alta disponibilidade, o gkectl retorna 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

    Alternativa:

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

      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. Acesse a página Hosts and Clusters no cliente vSphere.
    2. Clique em Modelos de VM e filtre pelo nome do cluster de administrador.

      Os três modelos de VM do cluster de administrador vão aparecer.

    3. Copie o nome do modelo de VM que corresponde ao nome da máquina que você está corrigindo e use o nome do modelo no comando de correçã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
    Rede 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 você usa o Seesaw como o tipo de balanceador de carga para seu cluster e percebe que uma VM do Seesaw está inativa ou não consegue inicializar, a seguinte mensagem de erro pode aparecer no console do vSphere:

        GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

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


    Alternativa:

    Localize os arquivos de registro que consomem a maior parte do espaço em disco usando du -sh -- /var/lib/docker/containers/* | sort -rh. Limpe o arquivo de registro com o maior tamanho e reinicie a VM.

    Observação:se a VM estiver completamente inacessível, anexe o disco a uma VM em funcionamento (por exemplo, uma estação de trabalho de administrador), remova o arquivo do disco anexado e anexe o disco novamente à VM original do Seesaw.

    Para evitar que o problema aconteça novamente, conecte-se à VM e modifique o arquivo /etc/systemd/system/docker.fluent-bit.service. Adicione --log-opt max-size=10m --log-opt max-file=5 no comando do Docker e execute systemctl restart docker.fluent-bit.service
    Operação 1.13, 1.14.0-1.14.6, 1.15

    Quando você tenta fazer upgrade (gkectl upgrade admin) ou atualizar (gkectl update admin) um cluster de administrador que não é de alta disponibilidade com o checkpoint ativado, o upgrade ou 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]...


    Alternativa:

    Se não for possível fazer upgrade para uma versão de patch do Google Distributed Cloud com a correção, entre em contato com o suporte do Google para receber ajuda.
    Upgrades 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, o upgrade do cluster de administrador para as versões afetadas pode falhar porque a associação da frota não pôde ser atualizada. Quando essa falha acontece, você vê o seguinte erro ao tentar fazer upgrade do 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 você inscreve explicitamente o cluster ou quando você Faz upgrade de um cluster de usuário usando um cliente da API GKE On-Prem.


    Alternativa:

    Cancele 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 o upgrade do cluster de administrador. Talvez você veja o erro "Falha ao registrar o cluster" desatualizado temporariamente. Depois de um tempo, ele é atualizado automaticamente.
    Upgrades, atualizações 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

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

    Um cluster de administrador é inscrito na API quando você inscreve explicitamente o cluster ou quando você Faz upgrade de um cluster de usuário usando um cliente da API GKE On-Prem.


    Alternativa:

    Cancele 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 reinscreva o cluster de administrador.
    Rede 1.15.0-1.15.2

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

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


    Alternativa:

    Atualize o modelo CoreDNS e aplique a correção. Essa correção persiste até um upgrade.

    1. Edite o modelo: 
      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 }}
    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

    Certas disputas podem fazer com que o status OnPremAdminCluster seja inconsistente entre o checkpoint e a resposta automática real. Quando o problema acontece, é possível encontrar o seguinte erro ao atualizar o cluster de administrador após o upgrade:

    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 resolver esse problema, será necessário editar o checkpoint ou desativá-lo para upgrade/atualização. Entre em contato com nossa equipe de suporte para continuar com a solução.
    Operação 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    O Google Distributed Cloud muda os certificados de administrador nos planos de controle do cluster de administrador a cada processo de reconciliação, como durante um upgrade de cluster. Esse comportamento aumenta a possibilidade de receber certificados inválidos para o cluster de administrador, especialmente para clusters da versão 1.15.

    Se você for afetado por esse problema, poderá encontrar problemas como os seguintes:

    • Certificados inválidos podem fazer com que os seguintes comandos atinjam o tempo limite e retornem erros:
      • gkectl create admin
      • gkectl upgrade amdin
      • gkectl update admin

      Esses comandos podem retornar erros de autorização, como:

      Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
    • Os registros 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...

    Alternativa:

    Faça upgrade para uma versão do Google Distributed Cloud com a correção: 1.13.10+, 1.14.6+, 1.15.2+. Se o upgrade não for possível, entre em contato com o Cloud Customer Care para resolver esse problema.
    Rede, operação 1.10, 1.11, 1.12, 1.13, 1.14

    Os pods do gateway de rede em kube-system podem mostrar um status Pending ou Evicted, conforme o exemplo de saída condensada a seguir:

    $ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

    Esses erros indicam eventos de remoção ou impossibilidade de programar pods devido a recursos de nó. Como os pods do gateway de rede do Anthos não têm PriorityClass, eles têm a mesma prioridade padrão que outras cargas de trabalho. Quando os nós têm recursos restritos, os pods do gateway de rede podem ser removidos. Esse comportamento é especialmente ruim para o DaemonSet ang-node, porque esses pods precisam ser programados em um nó específico e não podem ser migrados.


    Alternativa:

    Faça upgrade para a versão 1.15 ou posterior.

    Como correção de curto prazo, é possível atribuir manualmente uma PriorityClass aos componentes do gateway de rede do Anthos. O controlador do Google Distributed Cloud substitui essas alterações manuais durante um processo de reconciliação, como durante um upgrade de cluster.

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

    Depois de usar gcloud para registrar um cluster de administrador com a seção gkeConnect não vazia, talvez você encontre o seguinte erro ao tentar fazer upgrade do cluster:

    failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

    Exclua o namespace gke-connect: 

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

    gkectl diagnose snapshot --log-since falha ao limitar a janela de tempo para comandos journalctl em execução nos nós do cluster

    Isso não afeta a funcionalidade de tirar um snapshot do cluster, já que o snapshot ainda inclui todos os registros coletados por padrão ao executar journalctl nos nós do cluster. Portanto, nenhuma informação de depuração é perdida.
    Instalação, upgrades e atualizações 1.9+, 1.10+, 1.11+, 1.12+

    gkectl prepare windows falha ao instalar o Docker nas versões do Google Distributed Cloud anteriores à 1.13 porque o MicrosoftDockerProvider foi descontinuado.


    Alternativa:

    A ideia geral de resolver esse problema é fazer upgrade para o Google Distributed Cloud 1.13 e usar o gkectl 1.13 para criar um modelo de VM do Windows e, em seguida, criar pools de nós do Windows. Há duas opções para acessar o Google Distributed Cloud 1.13 da versão atual, conforme mostrado abaixo.

    Observação: temos opções para resolver esse problema na sua versão atual sem precisar fazer upgrade para a versão 1.13, mas serão necessárias mais etapas manuais. Entre em contato com nossa equipe de suporte se quiser considerar essa opção.


    Opção 1: upgrade azul/verde

    É possível criar um novo cluster usando o Google Distributed Cloud versão 1.13+ com pools de nós do Windows, migrar suas cargas de trabalho para o novo cluster e, em seguida, desativar o cluster atual. Recomendamos usar a versão secundária mais recente do Google Distributed Cloud.

    Observação: isso exigirá recursos extras para provisionar o novo cluster, mas menos inatividade e interrupção para as cargas de trabalho existentes.


    Opção 2:excluir pools de nós do Windows e adicioná-los novamente ao fazer upgrade para o Google Distributed Cloud 1.13

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

    1. Exclua os pools de nós do Windows existentes removendo a configuração de pools de nós do Windows do arquivo user-cluster.yaml e, em seguida, execute o comando: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    2. Faça upgrade dos clusters de administrador+usuário exclusivos do Linux para a versão 1.12 seguindo o guia do usuário para upgrade para a versão secundária de destino correspondente.
    3. (Siga esta etapa antes de fazer upgrade para a versão 1.13) Verifique se o enableWindowsDataplaneV2: true está configurado na resposta automática OnPremUserCluster.Caso contrário, o cluster continuará usando o Docker para pools de nós do Windows, que não serão compatíveis com o Modelo de VM 1.13 recém-criado que não tem o Docker instalado. Se não estiver configurado ou estiver definido como falso, atualize o cluster definindo-o como verdadeiro em user-cluster.yaml e, em seguida, execute: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    4. Faça upgrade dos clusters de administrador+usuário exclusivos do Linux para a versão 1.13 seguindo o guia do usuário para upgrade.
    5. Prepare o modelo de VM do Windows usando o gkectl 1.13: 
      gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
    6. Adicione novamente a configuração do pool de nós do Windows ao user-cluster.yaml com o campo OSImage definido como o modelo de VM recém-criado do Windows.
    7. Atualizar o cluster para adicionar pools de nós do Windows 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    Instalação, upgrades e atualizações 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    O valor padrão de 5 segundos para RootDistanceMaxSec será usado nos nós, em vez de 20 segundos, que seria a configuração esperada. Se você verificar o registro de inicialização do nó usando SSH na VM, localizada em `/var/log/startup.log`, poderá encontrar o seguinte erro:

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

    O uso de um RootDistanceMaxSec de cinco segundos pode fazer com que o relógio do sistema fique fora de sincronia com o servidor NTP quando o deslocamento do relógio for maior que cinco segundos.


    Alternativa:

    Aplique o seguinte DaemonSet ao 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: /
    Upgrades, atualizações 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Quando você usa a versão 1.13 gkectl para atualizar um cluster de administrador da versão 1.12, é possível ver o seguinte erro:

    Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

    Ao usar gkectl update admin para clusters da versão 1.13 ou 1.14, você verá a seguinte mensagem na resposta:

    Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

    Se você verificar o registro gkectl, verá que as várias alterações incluem a configuração de osImageType de uma string vazia para ubuntu_containerd.

    Esses erros de atualização ocorrem devido ao preenchimento incorreto do campo osImageType na configuração do cluster de administrador desde que ele foi introduzido na versão 1.9.


    Alternativa:

    Faça upgrade para uma versão do Google Distributed Cloud com a correção. Se o upgrade não for possível, entre em contato com o Cloud Customer Care para resolver esse problema.
    Instalação, segurança 1.13, 1.14, 1.15, 1.16

    A capacidade de fornecer um certificado de atendimento extra para o servidor da API Kubernetes de um cluster de usuário com authentication.sni não funciona quando o Controlplane V2 está ativado (enableControlplaneV2: true).


    Alternativa:

    Até que um patch do Google Distributed Cloud esteja disponível com a correção, se você precisar usar a SNI, desative o Controlplane V2 (enableControlplaneV2: false).
    Instalação 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    A máquina do plano de controle de administrador não é iniciada quando o nome de usuário do registro particular contém $. Ao verificar o /var/log/startup.log na máquina do plano de controle de administrador, você verá o seguinte erro: 

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

    Alternativa:

    Use um nome de usuário de registro particular sem $ ou uma versão do Google Distributed Cloud com a correção.
    Upgrades, atualizações 1.12.0-1.12.4

    Ao atualizar clusters de administrador, você verá os seguintes avisos de falso positivo no registro e poderá ignorá-los. 

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

    Depois que você alterna as chaves de assinatura KSA e, depois, atualiza um cluster de usuário, o gkectl update pode falhar com a seguinte mensagem de erro: 

    Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


    Alternativa:

    Altere a versão da chave de assinatura KSA novamente para 1, mas retenha os dados mais recentes da chave:
    1. Verifique o secret no cluster de administrador no namespace USER_CLUSTER_NAME e encontre o nome do secret ksa-signing-key: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
    2. Copie o secret ksa-signing-key e nomeie essa cópia como service-account-cert: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
    3. Exclua o secret ksa-signing-key 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é que o cluster de usuário de destino esteja pronto. Verifique o status: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
    8. Restaure o webhook de validação do cluster de usuário: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
    9. Evite fazer outra rotação de chaves de assinatura KSA até o cluster fazer upgrade para a versão com a correção.
    Operação 1.13.1+, 1.14, 1., 1.16

    Quando você usa o Terraform para excluir um cluster de usuário com um balanceador de carga F5 BIG-IP, os servidores virtuais F5 BIG-IP não são removidos após a exclusão do cluster.


    Alternativa:

    Para remover os recursos F5, siga as etapas para limpar uma partição F5 do cluster de usuário
    Instalação, upgrades e atualizações 1.13.8, 1.14.4

    Se você criar um cluster de administrador com a versão 1.13.8 ou 1.14.4 ou fizer upgrade dele para a versão 1.13.8 ou 1.14.4, o cluster kind extrairá as seguintes imagens de contêiner de docker.io:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Se docker.io não estiver acessível na estação de trabalho de administrador, a criação ou o upgrade do cluster de administrador não conseguirá trazer o cluster kind. A execução do comando a seguir na estação de trabalho de administrador mostra os contêineres correspondentes pendentes com ErrImagePull:

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

    A resposta contém entradas como estas:

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

    Essas imagens de contêiner precisam ser pré-carregadas na imagem de contêiner do cluster kind. No entanto, o kind v0.18.0 tem um problema com as imagens de contêiner pré-carregadas, que faz com que elas sejam extraídas da Internet por engano.


    Alternativa:

    Execute os seguintes comandos na estação de trabalho de administrador enquanto o cluster de administrador está com a criação ou o upgrade pendente:

    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Operação 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    Se as VMs do cluster estiverem conectadas a um switch que filtra solicitações GARP (ARP gratuitas) duplicadas, a eleição de líder de sinal de atividade pode encontrar uma disputa, o que faz com que alguns nós tenham entradas de tabela ARP incorretas.

    Os nós afetados podem dar um ping no VIP do plano de controle, mas uma conexão TCP com o VIP do plano de controle expira.


    Alternativa:

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

    vsphere-csi-controller precisa atualizar o secret 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, fazendo com que vsphere-csi-controller falhe após a rotação.

    Alternativa:

    Para clusters criados nas versões 1.13 e posteriores, siga as instruções abaixo para reiniciar vsphere-csi-controller 

    kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Instalação 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    Mesmo quando o registro de cluster falha durante a criação do cluster de administrador, o comando gkectl create admin não falha no erro e pode ser bem-sucedido. Em outras palavras, a criação do cluster de administrador pode ter "êxito" sem o registro em uma frota.

    Para identificar o sintoma, procure as mensagens de erro a seguir no registro de "gkectl create admin". 
    Failed to register admin cluster

    Verifique também se encontra o cluster entre os clusters registrados no console do Cloud.

    Alternativa:

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

    1. Anexe um par de chave-valor falso, como "foo: bar", ao seu arquivo de chave SA do connect-register
    2. Execute gkectl update admin para registrar novamente o cluster de administrador.

    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Durante o upgrade do cluster de administrador, se o upgrade dos nós do plano de controle do usuário expirar, o cluster de administrador não será registrado novamente com a versão atualizada do agente de conexão.


    Alternativa:

    Verifique se o cluster é exibido entre os clusters registrados. Como etapa opcional, faça login no cluster após configurar a autenticação. Se o cluster ainda estiver registrado, pule as instruções a seguir sobre tentar novamente o registro. Em clusters que fizeram upgrade para as versões 1.12 e posteriores, siga as instruções para tentar novamente o registro do cluster de administrador após a criação do cluster. Em clusters que fizeram upgrade para versões anteriores:
    1. anexe um par de chave-valor falso, como "foo: bar", ao seu arquivo de chave SA do connect-register;
    2. execute gkectl update admin para registrar novamente o cluster de administrador.

    Configuração 1.15.0

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Alternativa:

    Você pode ignorar esse erro com segurança.
    VMware 1.15.0

    Durante a criação de um pool de nós que usa Afinidade de VM-host , uma disputa pode resultar em várias Regras de afinidade de VM-host sendo criadas com o mesmo nome. Isso pode causar falha na criação do pool de nós.


    Alternativa:

    Remova as regras redundantes antigas para que a criação do pool de nós possa continuar. Essas regras se chamam [USER_CLUSTER_NAME]-[HASH].
    Operação 1.15.0

    O comando gkectl repair admin-master pode falhar devido a uma disputa com o seguinte erro. 

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


    Alternativa:

    Esse comando é idempotente. Ele pode ser executado com segurança novamente até o comando ser bem-sucedido.
    Upgrades, atualizações 1.15.0

    Depois de recriar ou atualizar um nó do plano de controle, alguns pods podem ser deixados no estado Failed devido a uma falha no predicado do NodeAffinity. Esses pods com falha não afetam a integridade ou as operações normais do cluster.


    Alternativa:

    É possível ignorar com segurança os pods com falha ou excluí-los manualmente.
    Segurança, configuração 1.15.0-1.15.1

    Se você usa credenciais preparadas e um registro particular, mas não configurou credenciais preparadas para seu registro particular, o OnPremUserCluster pode não ficar pronto e você verá a seguinte mensagem de erro: 

    failed to check secret reference for private registry …


    Alternativa:

    Prepare as credenciais do registro particular para o cluster de usuário de acordo com as instruções em Configurar credenciais preparadas.

    Upgrades, atualizações 1.15.0

    Durante gkectl upgrade admin, a verificação de simulação de armazenamento para a CSI Migration verifica se o StorageClasses não tem parâmetros que são ignorados após a CSI Migration. Por exemplo, se houver um StorageClass com o parâmetro diskformat, gkectl upgrade admin sinalizará o StorageClass e relatará uma falha na validação de simulação. Os clusters de administrador criados no Google Distributed Cloud 1.10 e anteriores têm um StorageClass com diskformat: thin, que falhará nessa validação. No entanto, esse StorageClass ainda funciona bem após a CSI Migration. Essas falhas precisam ser interpretadas como alertas.

    Para mais informações, consulte a seção do parâmetro StorageClass em Como migrar volumes do vSphere em árvore para o plug-in vSphere Container Storage.


    Alternativa:

    Depois de confirmar que seu cluster tem um StorageClass com parâmetros ignorados depois da CSI Migration, execute gkectl upgrade admin com a flag --skip-validation-cluster-health.
    Armazenamento 1.15, 1.16

    Em determinadas condições, os discos podem ser anexados como somente leitura aos nós do Windows. Isso faz com que o volume correspondente seja somente leitura dentro de um pod. É mais provável que esse problema ocorra quando um novo conjunto de nós substitui um conjunto antigo (por exemplo, upgrade de cluster ou atualização de pool de nós). As cargas de trabalho com estado que anteriormente funcionavam bem podem não conseguir gravar nos respectivos volumes no novo conjunto de nós.


    Alternativa:

    1. Encontre o UID do pod que não consegue gravar no respectivo volume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Use o PersistentVolumeClaim para encontrar o nome do PersistentVolume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determine o nome do nó em que o pod está em execução: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Consiga acesso ao nó via PowerShell, seja por SSH ou pela interface da Web do vSphere.
    5. Defina as 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. Verifique se o disco está readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
       O resultado 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. Exclua o pod para que ele seja reiniciado: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. O pod precisa ser programado no mesmo nó. No entanto, se o pod for programado em um novo nó, talvez seja necessário repetir as etapas anteriores nesse novo nó.

    Upgrades, atualizações 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secret não é atualizado após gkectl update credentials vsphere --admin-cluster

    Se você atualizar as credenciais do vSphere de um cluster de administrador após a atualização das credenciais do cluster, talvez encontre o vsphere-csi-secret no namespace kube-system no cluster de administrador ainda usando a credencial antiga.


    Alternativa:

    1. Consiga o nome do secret vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Atualize os dados do secret vsphere-csi-secret que você recebeu na etapa acima: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. Restart vsphere-csi-controller: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. É possível acompanhar o status do lançamento com: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Depois que a implantação for concluída, o vsphere-csi-secret atualizado deverá ser usado pelo controlador.
    Upgrades, atualizações 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    audit-proxy pode falhar em loop devido a um --cluster-name vazio. Esse comportamento é causado por um bug na lógica de atualização, em que o nome do cluster não é propagado para o manifesto do pod/contêiner do proxy de auditoria.


    Alternativa:

    Em um cluster de usuário do plano de controle v2 com enableControlplaneV2: true, conecte-se à máquina do plano de controle do usuário usando SSH e atualize /etc/kubernetes/manifests/audit-proxy.yaml com --cluster_name=USER_CLUSTER_NAME.

    Em um cluster de usuário do plano de controle v1, edite o contêiner audit-proxy no kube-apiserver com estado definido para adicionar --cluster_name=USER_CLUSTER_NAME:

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

    Logo após gkectl upgrade cluster, os pods do plano de controle podem ser reimplantados novamente. O estado do cluster de gkectl list clusters muda de RUNNING PARA RECONCILING. As solicitações para o cluster de usuário podem expirar.

    Esse comportamento ocorre devido à rotação automática de certificados do plano de controle após gkectl upgrade cluster.

    Esse problema só acontece com clusters de usuário que NÃO usam o plano de controle v2.


    Alternativa:

    Aguarde o estado do cluster voltar para RUNNING novamente em gkectl list clusters ou faça upgrade para versões com a correção: 1.13.6+, 1.14.2+ ou 1.15+.
    Upgrades, atualizações 1.12.7

    O Google Distributed Cloud 1.12.7-gke.19 é uma versão incorreta, e você não deve usá-la. Os artefatos foram removidos do bucket do Cloud Storage.

    Alternativa:

    Use a versão 1.12.7-gke.20.
    Upgrades, atualizações 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    Se você atualizar a credencial do registro usando um dos métodos a seguir:

    • gkectl update credentials componentaccess se não estiver usando o registro particular
    • gkectl update credentials privateregistry se estiver usando o registro particular

    Você pode descobrir que gke-connect-agent continua usando a imagem mais antiga ou que os pods gke-connect-agent não podem ser abertos devido a ImagePullBackOff.

    Esse problema será corrigido nas versões 1.13.8, 1.14.4 e posteriores do Google Distributed Cloud.


    Alternativa:

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

    1. Exclua o namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Reimplante o gke-connect-agent com a chave da conta de serviço de registro original (não é necessário atualizar a chave):

      Para o cluster de administrador: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
       Para o cluster de usuário: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opção 2: é possível alterar manualmente os dados do secret de pull de imagem regcred que é usado pela implantação do gke-connect-agent:

    kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Opção 3: é possível adicionar a chave secreta de pull de imagem padrão ao cluster na implantação do gke-connect-agent:

    1. Copie o secret padrão para o namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Consiga o nome da implantação do gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Adicione o secret padrão à implantação do gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Instalação 1.13, 1.14

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

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

    Alternativa:

    Opção 1: é possível usar as versões de patch 1.13.7 e 1.14.4, que incluem a correção.

    Opção 2: também é possível executar o mesmo comando para validar a configuração, mas pular a validação do balanceador de carga.

    gkectl check-config --skip-validation-load-balancer
    Operação 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 e 1.14

    Os clusters que executam o etcd versão 3.4.13 ou anterior podem apresentar privação do relógio e relógios de recursos não operacionais, que podem causar os seguintes problemas:

    • A programação do pod é interrompida
    • Não é possível registrar nós
    • O kubelet não observa mudanças no pod

    Esses problemas podem tornar o cluster não funcional.

    Esse problema foi corrigido nas versões 1.12.7 e 1.13.6 do Google Distributed Cloud. 1.14.3 e versões subsequentes. Essas versões mais recentes usam o etcd versão 3.4.21. Todas as versões anteriores do Google Distributed Cloud são afetadas pela problema.

    Alternativa

    Se não for possível fazer upgrade imediatamente, reduza o risco de falha do cluster diminuindo seu número de nós. Remova os nós até que a métrica etcd_network_client_grpc_sent_bytes_total seja inferior a 300 MBps.

    Para visualizar essa métrica no Metrics Explorer:

    1. Acesse o Metrics Explorer no console Google Cloud :

      Acessar o Metrics Explorer

    2. Selecione a guia Configuração.
    3. Expanda Selecionar uma métrica, insira Kubernetes Container na barra de filtros e use os submenus para selecionar a métrica:
      1. No menu Recursos ativos, selecione Contêiner 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.
    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13 e 1.14

    Nas reinicializações ou upgrades de cluster, o GKE Identity Service pode ficar sobrecarregado com o 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 apresente loop de falhas, ele para de responder e cessa o atendimento de novas solicitações. Esse problema acaba gerando latências maiores no plano de controle.

    Esse problema foi corrigido nas seguintes versões do Google Distributed Cloud:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Para determinar se esse problema está afetando você, execute as seguintes etapas:

    1. Verifique se o endpoint do GKE Identity Service pode ser acessado externamente: 
      curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Substitua CLUSTER_ENDPOINT pela porta do balanceador de carga e VIP do plano de controle para o cluster (por exemplo, 172.16.20.50:443).

      Se esse problema estiver afetando você, o comando retornará um código de status 400. Se a solicitação expirar, reinicie o pod ais e execute novamente o comando curl para ver se isso resolve o problema. Se você receber um código de status 000, o problema foi resolvido e está tudo pronto. Se você ainda receber um código de status 400, o servidor HTTP do GKE Identity Service não iniciará. Nesse caso, continue.

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

        Quando esse problema está afetando você, o registro contém uma entrada como esta:

        I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Verifique os registros kube-apiserver dos clusters:

        Nos comandos a seguir, KUBE_APISERVER_POD é o nome do pod kube-apiserver no cluster especificado.

        Cluster de administrador:

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

        Cluster de usuário:

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

        Quando esse problema está afetando você, os registros kube-apiserver contêm entradas como estas:

        E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Alternativa

    Se não for possível fazer upgrade dos clusters imediatamente para efetuar a correção, identifique e reinicie os pods ofensivos como uma solução alternativa:

    1. Aumente o nível de detalhes do GKE Identity Service para 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Verifique se o registro do GKE Identity Service apresenta o contexto de token inválido: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Para saber o payload do token associado a cada contexto de token inválido, analise cada secret da conta de serviço relacionada usando o comando a seguir: 
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Para decodificar o token e ver o nome e o namespace do pod de origem, copie o token para o depurador em jwt.io.
    5. Reinicie os pods identificados nos tokens.
    Operação 1.8, 1.9, 1.10

    Os pods de manutenção do etcd que usam a imagem etcddefrag:gke_master_etcddefrag_20210211.00_p0 são afetados. O contêiner "etcddefrag" abre uma nova conexão com o servidor etcd durante cada ciclo de infraestrutura e as conexões antigas não são limpas.


    Alternativa:

    Opção 1: fazer upgrade para a versão mais recente do patch da versão 1.8 para a 1.11 com a correção

    Opção 2: se você estiver usando uma versão de patch anterior à 1.9.6 e 1.10.3, será preciso reduzir a escala vertical do pod de manutenção do etcd para o cluster de administrador e de usuário:

    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Operação 1.9, 1.10, 1.11, 1.12, 1.13

    O controlador de integridade do cluster e o comando gkectl diagnose cluster executam um conjunto de verificações de integridade, incluindo as verificações de integridade dos pods nos namespaces. No entanto, elas começam a pular os pods do plano de controle do usuário por engano. Se você usar o modo de plano de controle v2, isso não afetará seu cluster.


    Alternativa:

    Isso não afeta o gerenciamento de clusters ou cargas de trabalho. Se você quiser verificar a integridade dos pods do plano de controle, execute os seguintes comandos:

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

    Os upgrades do cluster de administrador 1.6 e 1.7 podem ser afetados pelo redirecionamento k8s.gcr.io -> registry.k8s.io.

    O Kubernetes redirecionou o tráfego de k8s.gcr.io para registry.k8s.io em 20/03/2023. No Google Distributed Cloud 1.6.x e 1.7.x, os upgrades de cluster de administrador usam a imagem de contêiner k8s.gcr.io/pause:3.2. Se você usar um proxy na estação de trabalho do administrador e o proxy não permitir registry.k8s.io, e a imagem do contêiner k8s.gcr.io/pause:3.2 não estiver armazenada em cache localmente, os upgrades do cluster de administrador falharão ao extrair a imagem do contêiner.


    Alternativa:

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

    gkectl create loadbalancer falha com a seguinte mensagem de erro:

    - Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Isso ocorreu devido ao arquivo do grupo do Seesaw. E a verificação de simulação tenta validar um balanceador de carga de gangorra inexistente.

    Alternativa:

    Remova o arquivo do grupo do Seesaw atual do cluster. O nome do arquivo é seesaw-for-gke-admin.yaml para o cluster de administrador e seesaw-for-{CLUSTER_NAME}.yaml para um cluster de usuário.
    Rede 1.14

    A versão 1.14 do Google Distributed Cloud é suscetível a falhas de inserção de tabela no rastreamento de conexão (conntrack) do netfilter ao usar imagens de sistema operacional Ubuntu ou COS. As falhas de inserção levam a um tempo limite aleatório do aplicativo e podem ocorrer mesmo quando a tabela de conntrack tiver espaço para novas entradas. As falhas são causadas por alterações no kernel 5.15 e mais recentes que restringem as inserções de tabelas com base no comprimento da cadeia.

    Para saber se esse problema te afeta, verifique as estatísticas do sistema de rastreamento de conexão no kernel em cada nó com o seguinte comando:

    sudo conntrack -S

    A resposta será assim:

    cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

    Se o valor chaintoolong na resposta for um número diferente de zero, esse problema afeta você.

    Alternativa

    A mitigação de curto prazo aumenta o tamanho da tabela de hash netfiler (nf_conntrack_buckets) e da tabela de rastreamento de conexão do netfilter (nf_conntrack_max). Use os seguintes comandos em cada nó de cluster para aumentar o tamanho das tabelas:

    sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    Substitua TABLE_SIZE pelo novo tamanho em bytes. O valor padrão de tamanho da tabela é 262144. Sugerimos definir um valor igual a 65.536 vezes o número de núcleos no nó. Por exemplo, se o nó tiver oito núcleos, defina o tamanho da tabela como 524288.
    Rede 1.13.0-1.13.2

    Com o Controlplane V2 ativado, é possível programar calico-typha ou anetd-operator para nós do Windows e entrar em loop de falhas.

    O motivo é que as duas implantações toleram todos os taints, incluindo o taint de nó do Windows.


    Alternativa:

    Faça upgrade para a versão 1.13.3 ou posterior ou execute os seguintes comandos para editar a implantação "calico-typha" ou "anetd-operator":

        # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Remova os seguintes spec.template.spec.tolerations:

        - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    E adicione a seguinte tolerância:

        - key: node-role.kubernetes.io/master
      operator: Exists
    Configuração 1.14.0-1.14.2

    Talvez não seja possível criar um cluster de usuário se você especificar a seção privateRegistry com a credencial fileRef. A simulação pode falhar com a seguinte mensagem: 

    [FAILURE] Docker registry access: Failed to login.


    Alternativa:

    • Se você não pretendia especificar o campo ou quer usar a mesma credencial de registro particular que o cluster de administrador, basta remover ou comentar a seção privateRegistry no arquivo de configuração do cluster de usuário.
    • Se você quiser usar uma credencial de registro particular específica para seu cluster de usuário, especifique temporariamente a seção privateRegistry desta maneira: 
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
       (NOTE: isso é apenas uma correção temporária, e esses campos já estão descontinuados. Considere usar o arquivo de credencial ao fazer upgrade para a versão 1.14.3 ou posterior.)

    Operações 1.10+

    O Dataplane V2 assume o balanceamento de carga e cria um soquete kernel em vez de um DNAT baseado em pacote. Isso significa que o Cloud Service Mesh não pode fazer a inspeção de pacotes porque o pod é ignorado e nunca usa IPTables.

    Isso se manifesta no modo gratuito do kube-proxy pela perda de conectividade ou pelo roteamento de tráfego incorreto para serviços com o Cloud Service Mesh, porque o arquivo secundário não pode inspecionar pacotes.

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


    Alternativa:

    Faça upgrade para a versão 1.11 para ter compatibilidade total ou, se a versão for 1.10.2 ou posterior, execute:

        kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Adicione bpf-lb-sock-hostns-only: true ao configmap e reinicie o daemonset anetd:

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

    Armazenamento 1.12+, 1.13.3

    kube-controller-manager pode expirar ao remover PV/PVCs após seis minutos e remover à força esses PV/PVCs. Os registros detalhados de kube-controller-manager mostram eventos semelhantes aos seguintes:

    $ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Para verificar o problema, faça login no nó e execute os seguintes comandos:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    No registro do kubelet, são exibidos erros como estes:

    Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Alternativa:

    Conecte-se ao nó afetado usando SSH e reinicie o nó.
    Upgrades, atualizações 1.12+, 1.13+, 1.14+

    Talvez não seja possível fazer upgrade de um cluster se você usar um driver CSI de terceiros. O comando gkectl cluster diagnose pode retornar o seguinte erro: 

    "virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Alternativa:

    Faça o upgrade usando a opção --skip-validation-all.
    Operação 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    O nó mestre do administrador criado via gkectl repair admin-master pode usar uma versão de hardware de VM inferior à esperada. Quando o problema acontecer, você verá o erro do relatório gkectl diagnose cluster. 

    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Alternativa:

    Encerre o nó mestre do administrador. Siga https://kb.vmware.com/s/article/1003746 para fazer upgrade do nó para a versão esperada descrita no erro e inicie o nó.
    Sistema operacional 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, , 1.28+, 1.29+, 1.30+, 1.31+, 1.32+

    No systemd v244, o systemd-networkd tem uma mudança de comportamento padrão na configuração do KeepConfiguration. Antes dessa mudança, as VMs não enviavam uma mensagem de lançamento da lease de DHCP para o servidor DHCP no encerramento ou reinicialização. Após essa alteração, as VMs enviam essa mensagem e retornam os IPs ao servidor DHCP. Como resultado, o IP liberado pode ser realocado para uma VM diferente e/ou outro IP pode ser atribuído à VM, resultando em conflito de IP (no nível do Kubernetes, não no vSphere) /ou alteração de IP nas VMs, o que pode interromper os clusters de várias maneiras.

    Por exemplo, você pode ver os sintomas a seguir.

    • A IU do vCenter mostra que nenhuma VM usa o mesmo IP, mas kubectl get nodes -o wide retorna nós com IPs duplicados. 
      NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • Novos nós não iniciam devido a erro calico-node 
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Alternativa:

    Implante o DaemonSet a seguir no cluster para reverter a mudança de comportamento padrão systemd-networkd. As VMs que executam esse DaemonSet não liberarão os IPs ao servidor DHCP no encerramento/reinicialização. Os IPs serão liberados automaticamente pelo servidor DHCP quando as leases expirarem. 

          apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Operação, upgrades e atualizações 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    Esse problema afetará somente os clusters de administrador atualizados a partir da versão 1.11.x, mas não os clusters criados após a versão 1.12.

    Depois de fazer upgrade de um cluster 1.11.x para 1.12.x, o campo component-access-sa-key no secret admin-cluster-creds será excluído permanentemente para esvaziar. Para verificar isso, execute o seguinte comando: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
     Se você encontrar a saída vazia, significa que a chave foi excluída permanentemente.

    Depois que a chave da conta de serviço de acesso ao componente for excluída, a instalação de novos clusters de usuário ou o upgrade de clusters de usuário atuais falhará. Confira a seguir algumas mensagens de erro que você pode encontrar:

    • Falha de simulação da validação lenta com a mensagem de erro "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Falha na preparação de gkectl prepare com a mensagem de erro: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Se você estiver fazendo upgrade de um cluster de usuário 1.13 usando o console Google Cloud ou a CLI gcloud, quando você executar gkectl update admin --enable-preview-user-cluster-central-upgrade para implantar o controlador da plataforma de upgrade, o comando falhará com a mensagem: "failed to download bundle to disk: dialing: unexpected end of JSON input". É possível ver essa mensagem no campo status na saída de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml.


    Alternativa:

    Adicione a chave da conta de serviço de acesso ao componente de volta ao secret manualmente executando o seguinte comando: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

    Operação 1.13.0+, 1.14.0+

    Para clusters de usuários criados com o Controlplane V2 ativado, os pools de nós com o escalonamento automático ativado sempre usam o autoscaling.minReplicas no user-cluster.yaml. O registro do pod de escalonador automático de cluster mostra um erro semelhante a este: 

      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Para encontrar o pod do escalonador automático de clusters, execute os comandos a seguir. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Alternativa:

    Desative o escalonamento automático em todos os pools de nós com "gkectl update cluster" até fazer upgrade para uma versão com a correção.
    Instalação 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Quando os usuários usam o CIDR no arquivo de bloco de IP, a validação de configuração falha com o seguinte erro: 

    - Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Alternativa:

    Inclua IPs individuais no arquivo de bloco de IPs até fazer upgrade para uma versão com a correção: 1.12.5, 1.13.4, 1.14.1+.
    Upgrades, atualizações 1.14.0-1.14.1

    Ao atualizar o tipo de imagem do SO do plano de controle em admin-cluster.yaml e se o cluster de usuário correspondente tiver sido criado com enableControlplaneV2 definido como true, as máquinas do plano de controle do usuário não poderão concluir a recriação quando o comando gkectl for concluído.


    Alternativa:

    Depois que a atualização for concluída, aguarde até que as máquinas do plano de controle do usuário também concluam a recriação ao monitorar os tipos de imagem do SO do nó usando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Por exemplo, se atualizar do Ubuntu para o COS, devemos esperar que todas as máquinas do plano de controle mudem completamente do Ubuntu para o COS mesmo após a conclusão do comando de atualização.

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

    Um problema com o Calico no Google Distributed Cloud 1.14.0 faz com que a criação e a exclusão de pods falhem com a seguinte mensagem de erro na saída de kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Esse problema só é observado 24 horas após a criação ou o upgrade do cluster para a versão 1.14 usando o Calico.

    Os clusters de administrador estão sempre usando o Calico. Já para o cluster de usuário, há um campo de configuração "enableDataPlaneV2" em user-cluster.yaml. Se esse campo estiver definido como "falso" ou não for especificado, você estará usando o Calico no cluster de usuário.

    O contêiner install-cni dos nós cria um kubeconfig com um token válido por 24 horas. Esse token precisa ser renovado periodicamente pelo pod calico-node. O pod calico-node não pode renovar o token porque não tem acesso ao diretório que contém o arquivo kubeconfig no nó.


    Alternativa:

    Esse problema foi corrigido na versão 1.14.1 do Google Distributed Cloud. Faça upgrade para esta versão ou uma mais recente.

    Se não for possível fazer upgrade imediatamente, aplique o seguinte patch no DaemonSet calico-node no cluster de administrador e usuário:

      kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Substitua:
    • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
    • USER_CLUSTER_CONFIG_FILE: o caminho do arquivo de configuração do cluster de usuário.
    Instalação 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    A criação do cluster falha, mesmo quando o usuário tem a configuração correta. O usuário recebe uma falha na criação porque o cluster não tem IPs suficientes.


    Alternativa:

    Dividir CIDRs em vários blocos CIDR menores, como 10.0.0.0/30, se torna 10.0.0.0/31, 10.0.0.2/31. Desde que haja CIDRs N+1, em que N é o número de nós no cluster, isso vai ser suficiente.

    Operação, upgrades e atualizações 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Quando o atributo de criptografia de secrets sempre ativado for ativado com o backup de cluster, o backup do cluster de administrador não incluirá as chaves de criptografia e a configuração exigidas pelo atributo de criptografia de secrets sempre ativado. Como resultado, reparar o mestre do administrador com esse backup usando gkectl repair admin-master --restore-from-backup causa o seguinte erro: 

    Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Operação, upgrades e atualizações 1.10+

    Se o atributo de criptografia de secrets sempre ativado não estiver ativado na criação do cluster, mas for ativado depois usando a operação gkectl update, o gkectl repair admin-master não vai reparar o nó do plano de controle do cluster de administrador. É recomendável ativar o atributo de criptografia de secrets sempre ativado durante a criação do cluster. Não há mitigação atual.

    Upgrades, atualizações 1.10

    O upgrade do primeiro cluster de usuário de 1.9 para 1.10 pode recriar nós em outros clusters de usuário no mesmo cluster de administrador. A recriação é feita de modo contínuo.

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


    Alternativa:
    Upgrades, atualizações 1.10.0

    Fazer upgrade do cluster de usuário para 1.10.0 pode causar a reinicialização do Docker com frequência.

    Execute kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG para detectar esse problema

    Uma condição de nó mostrará se o Docker é reiniciado com frequência. Este um exemplo de saída:

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

    Para entender a causa raiz, é preciso executar o SSH no nó que tem o sintoma e executar comandos como sudo journalctl --utc -u docker ou sudo journalctl -x.


    Alternativa:
    Upgrades, atualizações 1.11, 1.12

    Se você estiver usando uma versão do Google Distributed Cloud anterior à 1.12 e tiver configurado manualmente os componentes do Prometheus gerenciados pelo Google (GMP) no namespace gmp-system do seu cluster, os componentes não serão preservados quando você fizer upgrade para a versão 1.12.x.

    A partir da versão 1.12, os componentes do GMP no namespace gmp-system e nos CRDs são gerenciados pelo objeto stackdriver, com a flag enableGMPForApplications definida como false por padrão. Se você implantar manualmente os componentes do GMP no namespace antes do upgrade para a versão 1.12, os recursos serão excluídos por stackdriver.


    Alternativa:
    Operação 1.11, 1.12, 1.13.0 - 1.13.1

    No cenário system, o snapshot do cluster não inclui recursos no namespace default.

    No entanto, alguns recursos do Kubernetes, como objetos da API Cluster que estão nesse namespace, contêm informações úteis de depuração. O snapshot do cluster precisa incluí-las.


    Alternativa:

    Execute os comandos a seguir para coletar as informações de depuração.

    export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
     em que:

    USER_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de usuário.
    Upgrades, atualizações 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Ao excluir, atualizar ou fazer upgrade de um cluster de usuário, a drenagem do nó pode ficar travada nos seguintes cenários:

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

    Para identificar o sintoma, execute o comando abaixo:

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

    Confira um exemplo de mensagem de erro do comando acima:

    E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols é o diretório padrão para o driver em árvore do vSphere. Quando não houver objetos PVC/PV criados, pode ocorrer um bug em que a drenagem de nós vai ficar travada ao encontrar kubevols, já que a implementação atual supõe que kubevols sempre existe.


    Alternativa:

    Crie o diretório kubevols no repositório de dados em que o nó foi criado. Isso é definido no campo vCenter.datastore nos arquivos user-cluster.yaml ou admin-cluster.yaml.
    Configuração 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    Na exclusão do cluster de usuário, os clusterrole e clusterrolebinding correspondentes do escalonador automático de cluster também são excluídos. Isso afeta todos os outros clusters de usuário no mesmo cluster de administrador com o escalonador automático de cluster ativado. Isso ocorre porque os mesmos clusterrole e clusterrolebinding são usados para todos os pods do escalonador automático de cluster no mesmo cluster de administrador.

    Os sintomas são os seguintes:

    • Registros cluster-autoscaler
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
       em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador. Confira um exemplo de mensagens de erro: 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Alternativa:

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

    Na exclusão do cluster de usuário, o clusterrole correspondente também é excluído, o que faz com que o reparo automático e o exportador de métricas do vsphere não funcionem

    Os sintomas são os seguintes:

    • Registros cluster-health-controller
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
       em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador. Confira um exemplo de mensagens de erro: 
      error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • Registros vsphere-metrics-exporter
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
       em que ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador. Confira um exemplo de mensagens de erro: 
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Alternativa:

    Configuração 1.12.1-1.12.3, 1.13.0-1.13.2

    Um problema conhecido que poderia falhar o gkectl check-config sem executar gkectl prepare. Isso é confuso porque sugerimos executar o comando antes de executar gkectl prepare.

    O sintoma é que o comando gkectl check-config falha com a seguinte mensagem de erro:

    Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Alternativa:

    Opção 1: execute gkectl prepare para fazer upload das imagens ausentes do SO.

    Opção 2: use gkectl check-config --skip-validation-os-images para pular a validação de imagens do SO.
    Upgrades, atualizações 1.11, 1.12, 1.13

    Um problema conhecido que poderia falhar o gkectl update admin/cluster ao atualizar o anti affinity groups.

    O sintoma é que o comando gkectl update falha com a seguinte mensagem de erro:

    Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

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

    O registro do nó falha durante a criação, o upgrade, a atualização do cluster e o reparo automático do nó, quando ipMode.type é static e o nome do host configurado no arquivo de bloco de IP contém um ou mais pontos finais. Nesse caso, as solicitações de assinatura de certificado (CSR, na sigla em inglês) de um nó não serão aprovadas automaticamente.

    Para acessar CSRs pendentes de um nó, execute o comando a seguir:

    kubectl get csr -A -o wide

    Verifique se há mensagens de erro nos seguintes registros:

    • Confira os registros no cluster de administrador do contêiner clusterapi-controller-manager no pod clusterapi-controllers: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Para acessar os mesmos registros no cluster de usuário, execute o seguinte comando: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
       onde:
      • ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador.
      • USER_CLUSTER_NAME é o nome do cluster de usuário.
      Confira um exemplo de mensagens de erro: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Confira os registros kubelet no nó problemático: 
      journalctl --u kubelet
       Confira um exemplo de mensagens de erro: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Se você especificar um nome de domínio no campo do nome do host de um arquivo de bloco de IP, todos os caracteres após o primeiro ponto final serão ignorados. Por exemplo, se você especificar o nome do host como bob-vm-1.bank.plc, o nome do host da VM e o nome do nó serão definidos como bob-vm-1.

    Quando a verificação do ID do nó está ativada, o aprovador da CSR compara o nome do nó com o nome do host na especificação da máquina e não reconcilia o nome. O aprovador rejeita a CSR, e o nó falha ao inicializar.


    Alternativa:

    Cluster de usuário

    Para desativar a verificação do ID do nó, siga estas etapas:

    1. Adicione os seguintes campos ao arquivo de configuração do cluster de usuário: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Salve o arquivo e atualize o cluster de usuário executando o seguinte comando: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
       Substitua:
      • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador
      • USER_CLUSTER_CONFIG_FILE: o caminho do arquivo de configuração do cluster de usuário.

    Cluster de administrador

    1. Abra o recurso personalizado OnPremAdminCluster para editar: 
      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 controle do cluster de administrador:
      1. Estabeleça uma conexão SSH com o nó do plano de controle 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 seçã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. Mude os valores de node-id-verification-enabled e node-id-verification-csr-signing-enabled para false: 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Instalação, upgrades e atualizações 1.11.0-1.11.4

    A criação/upgrade do cluster de administrador é interrompida no registro a seguir para sempre e, por fim, expira:

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

    Na versão 1.11 da documentação, o registro do controlador da API Cluster no snapshot de cluster externo inclui o seguinte registro:

    Invalid value 'XXXX' specified for property startup-data

    Confira um exemplo de caminho de arquivo para o registro do controlador da API Cluster:

    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    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 status NotHealthy impede que o controlador atribua outros IPs flutuantes ao nó. Isso pode resultar em mais carga para outros nós ou falta de redundância para alta disponibilidade.

    A atividade do plano de dados não será afetada.

    A contenção no objeto networkgatewaygroup faz algumas atualizações de status falharem devido a um erro no processamento de novas tentativas. Se muitas atualizações de status falharem, ang-controller-manager vê o nó como tendo passado do limite de tempo do sinal de funcionamento e marca esse nó como NotHealthy.

    O erro no processamento de novas tentativas foi corrigido em versões mais recentes.


    Alternativa:

    Fazer upgrade para uma versão fixa, quando disponível.
    Upgrades, atualizações 1.12.0-1.12.2, 1.13.0

    Um problema conhecido que poderia fazer com que o upgrade ou a atualização do cluster ficassem esperando para que o objeto da máquina antigo fosse excluído. Isso acontece porque não é possível remover o finalizador do objeto da máquina. Isso afeta qualquer operação de atualização gradual para pools de nós.

    O sintoma é que o comando gkectl expira com a seguinte mensagem de erro:

    E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Nos registros de pod clusterapi-controller, os erros são assim:

    $ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    O erro se repetirá na mesma máquina por vários minutos para execuções bem-sucedidas, mesmo sem esta questão. Na maioria dos casos, ele pode passar rapidamente, mas em alguns casos raros, ele poderá ficar preso nessa disputa por várias horas.

    O problema é que a VM já foi excluída no vCenter, mas o objeto da máquina correspondente não pode ser removido e fica preso na remoção do finalizador devido a atualizações muito frequentes de outros controladores. Isso pode fazer com que o comando gkectl atinja o tempo limite, mas o controlador continua reconciliando o cluster para que o processo de upgrade ou atualização seja concluído.


    Alternativa:

    Preparamos várias opções diferentes de mitigação para esse problema, que depende do seu ambiente e dos seus requisitos.

    • Opção 1: aguardar a conclusão do upgrade por conta própria.

      Com base na análise e na reprodução no seu ambiente, o upgrade pode terminar sozinho sem nenhuma intervenção manual. A orientação dessa opção é que não há certeza de quanto tempo levará para a remoção do finalizador de cada objeto de máquina. Ela poderá ser concluída imediatamente se você tiver sorte suficiente ou durar várias horas se o reconciliador do controlador de máquina for muito rápido e o controlador de máquina nunca tiver a chance de remover o finalizador entre as reconciliações.

      O bom é que essa opção não requer nenhuma ação da sua parte, e as cargas de trabalho não serão interrompidas. Ela só precisa de mais tempo para concluir o upgrade.
    • Opção 2: aplicar a anotação de reparo automático a todos os objetos de máquina antigos.

      O controlador do conjunto de máquinas filtrará as máquinas que têm a anotação de reparo automático e o carimbo de data/hora de exclusão diferentes de zero e não continuará a emitir chamadas de exclusão nessas máquinas. Isso pode ajudar a evitar a disputa.

      A desvantagem é que os pods nas máquinas serão excluídos diretamente em vez de removidos, o que significa que não respeitarão a configuração do PDB. Isso poderá causar inatividade nas cargas de trabalho.

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

    Se você encontrar esse problema e o upgrade ou a atualização ainda não forem concluídos após um longo período, entre em contato com nossa equipe de suporte para mitigação.
    Instalação, upgrades e atualizações 1.10.2, 1.11, 1.12, 1.13

    Falha no comando gkectl prepare com:

    - Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    As verificações de simulação de gkectl prepare incluíram uma validação incorreta.


    Alternativa:

    Execute o mesmo comando com uma flag adicional --skip-validation-os-images.
    Instalação 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Falha na criação do cluster de administrador com:

    Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    O URL é usado como parte de uma chave de Secret, que não é compatível com "/" ou ":".


    Alternativa:

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

    gkectl prepare pode gerar falhas com o stacktrace a seguir:

    panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    O problema é que gkectl prepare criava o diretório de certificado de registro particular com uma permissão incorreta.


    Alternativa:

    Para corrigir esse problema, execute os comandos a seguir na estação de trabalho do administrador:

    sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13

    Após uma falha na tentativa de upgrade do cluster de administrador, não execute gkectl repair admin-master. Isso pode causar falhas nas próximas tentativas de upgrade do administrador com problemas como falha da alimentação mestre do administrador ou a VM inacessível.


    Alternativa:

    Se você já encontrou esse cenário de falha, entre em contato com o suporte.
    Upgrades, atualizações 1.10, 1.11

    Se a máquina do plano de controle do administrador não for recriada após uma tentativa de upgrade do cluster de administrador retomado, o modelo de VM do plano de controle do administrador vai ser excluído. O modelo de VM do plano de controle do administrador é o modelo mestre de administração usado para recuperar a máquina do plano de controle com gkectl repair admin-master.


    Alternativa:

    O modelo de VM do plano de controle do administrador vai ser gerado novamente durante o próximo upgrade de cluster de administrador.
    Sistema operacional 1.12, 1.13

    Na versão 1.12.0, o cgroup v2 (unificado) é ativado por padrão para nós do Container Optimized OS (COS). Isso pode causar instabilidade nas cargas de trabalho em um cluster do COS.


    Alternativa:

    Voltamos ao cgroup v1 (híbrido) na versão 1.12.1. Se você estiver usando nós do COS, recomendamos fazer upgrade para a versão 1.12.1 assim que ela for lançada.
    Identidade 1.10, 1.11, 1.12, 1.13

    gkectl update reverte todas as alterações manuais feitas para o recurso personalizado ClientConfig.


    Alternativa:

    É altamente recomendável que você faça backup do recurso ClientConfig após cada alteração manual.
    Instalação 1.10, 1.11, 1.12, 1.13

    A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.

    Um problema com a API F5 BIG-IP pode causar falha na validação.


    Alternativa:

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

    Pode haver uma falha na instalação devido a cert-manager-cainjector no loop de falhas, quando o apiserver/etcd está lento:

    # These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

    Alternativa:
    VMware 1.10, 1.11, 1.12, 1.13

    Se o vCenter, para versões anteriores à 7.0U2, for reiniciado, após um upgrade ou de outra forma, o nome da rede nas informações da VM do vCenter estará incorreto e resultará na máquina em um estado Unavailable. Isso leva os nós a serem reparados automaticamente para criar outros.

    Bug govmomi relacionado.


    Alternativa:

    Esta solução alternativa é fornecida pelo suporte da VMware:

    1. O problema foi corrigido na versão 7.0U2 e mais recentes do vCenter.
    2. Para versões anteriores, clique com o botão direito do mouse no host e selecione Conexão > Desconectar. Em seguida, reconecte-se, o que força uma atualização do grupo de portas da VM.
    Sistema operacional 1.10, 1.11, 1.12, 1.13

    Para o Google Distributed Cloud versão 1.7.2 e mais recentes, as imagens do SO Ubuntu são reforçadas com o CIS L1 Server Benchmark.

    Para atender à regra do CIS "5.2.16 Verificar se o intervalo de tempo limite de inatividade SSH está configurado", o /etc/ssh/sshd_config tem as seguintes configurações:

    ClientAliveInterval 300
ClientAliveCountMax 0

    O objetivo dessas configurações é encerrar a sessão de um cliente após cinco minutos de inatividade. No entanto, o valor ClientAliveCountMax 0 causa um comportamento inesperado. Quando você usa a sessão SSH na estação de trabalho de administrador ou em um nó de cluster, a conexão SSH pode ser desconectada mesmo que o cliente SSH não esteja inativo, como ao executar um comando demorado e seu comando pode ser encerrado com a seguinte mensagem:

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

    Alternativa:

    Você tem as seguintes opções:

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

    Reconecte sua sessão SSH.
    Instalação 1.10, 1.11, 1.12, 1.13

    Nas versões 1.13, o monitoring-operator vai instalar o gerenciador de certificados no namespace cert-manager. Se por algum motivo você precisar instalar seu próprio gerenciador de certificados, siga as instruções a seguir para evitar conflitos:

    Basta aplicar essa solução uma vez para cada cluster, e as alterações serão preservadas no upgrade do cluster.

    Observação: um sintoma comum de instalação do gerenciador de certificados é que a versão cert-manager ou a imagem (por exemplo, v1.7.2) pode reverter para a versão anterior. Isso é causado por monitoring-operator ao tentar reconciliar o cert-manager e reverter a versão no processo.

    Alternativa:

    <pEvitar conflitos durante o upgrade

    1. Desinstale sua versão de cert-manager. Se você definiu seus próprios recursos, recomendamos fazer backup deles.
    2. Faça upgrade.
    3. Siga as instruções a seguir para restaurar seu próprio cert-manager.

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

    • Escalone a implantação monitoring-operator para 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Escalone as implantações cert-manager gerenciadas por monitoring-operator para 0: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Reinstale a versão do cert-manager. Restaure os recursos personalizados se você os tiver.
    • Pule esta etapa se você estiver usando a instalação do gerenciador de certificados padrão upstream ou se tiver certeza de que o gerenciador de certificados está instalado no namespace cert-manager. Caso contrário, copie o Certificado metrics-ca cert-manager.io/v1 e os recursos do Emissor metrics-pki.cluster.local de cert-manager para o namespace do recurso do cluster do gerenciador de certificados instalado. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

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

    De modo geral, não é necessário reinstalar o gerenciador de certificados nos clusters de administrador porque os clusters de administrador só executam cargas de trabalho do plano de controle do Google Distributed Cloud. Nos raros casos em que você também precisa instalar seu próprio gerenciador de certificados em clusters de administrador, siga as instruções a seguir para evitar conflitos. Se você é cliente da Apigee e precisa apenas de um gerenciador de certificados para a Apigee, não é necessário executar os comandos de cluster de administrador.

    • Escalone a implantação monitoring-operator para 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Escalone as implantações cert-manager gerenciadas por monitoring-operator para 0.
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Reinstale a versão do cert-manager. Restaure os recursos personalizados se você os tiver.
    • Pule esta etapa se você estiver usando a instalação do gerenciador de certificados padrão upstream ou se tiver certeza de que o gerenciador de certificados está instalado no namespace cert-manager. Caso contrário, copie o Certificado metrics-ca cert-manager.io/v1 e os recursos do Emissor metrics-pki.cluster.local de cert-manager para o namespace do recurso do cluster do gerenciador de certificados instalado. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    </p
    Sistema operacional 1.10, 1.11, 1.12, 1.13

    O Docker, o containerd e o runc nas imagens do SO Ubuntu fornecidos com o Google Distributed Cloud são fixados nas versões especiais usando o Ubuntu PPA. Isso garante que todas as mudanças no ambiente de execução do contêiner sejam 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 os feeds de vulnerabilidade por várias ferramentas de verificação da CVE. Portanto, você terá falsos positivos nos resultados do Docker, do containerd e de verificação de vulnerabilidade do runc.

    Por exemplo, os falsos positivos a seguir podem ser exibidos nos resultados da verificação da CVE. Essas CVEs já foram corrigidas nas versões mais recentes dos patches do Google Distributed Cloud.

    Consulte as notas da versão para conferir correções da CVE.


    Alternativa:

    A Canonical está ciente desse problema, e a correção é rastreada em https://github.com/canonical/sec-cvescan/issues/73.
    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13

    Se você estiver fazendo upgrade dos clusters que não são de alta disponibilidade da versão 1.9 para a 1.10, talvez perceba que kubectl exec, kubectl log e o webhook nos clusters de usuários podem ficar indisponíveis por um curto período. Essa inatividade pode ser de até um minuto. Isso acontece porque a solicitação de entrada (kubectl exec, kubectl log e webhook) é processada pelo kube-apiserver para o cluster de usuário. O usuário kube-apiserver é um Statefulset. Em um cluster que não seja de alta disponibilidade, há apenas uma réplica para o Statefulset. Portanto, durante o upgrade, é possível que o kube-apiserver antigo fique indisponível enquanto o novo kube-apiserver ainda não estiver pronto.


    Alternativa:

    Esse tempo de inatividade ocorre apenas durante o processo de upgrade. Se você quiser uma inatividade mais curta durante o upgrade, recomendamos que mude para clusters de alta disponibilidade.
    Instalação, upgrades e atualizações 1.10, 1.11, 1.12, 1.13

    Se você estiver criando ou fazendo upgrade de um cluster de alta disponibilidade e perceber que a verificação de prontidão konnectivity falhou no diagnóstico do cluster, na maioria dos casos isso não afetará a funcionalidade do Google Distributed Cloud (kubectl exec, kubectl log e webhook). Isso acontece porque, às vezes, uma ou duas réplicas de konnectivity podem ficar inativas por um período devido a instabilidade da rede ou outros problemas.


    Alternativa:

    O konnectivity será recuperada por conta própria. Aguarde 30 minutos a uma hora e execute novamente o diagnóstico do cluster.
    Sistema operacional 1.7, 1.8, 1.9, 1.10, 1.11

    A partir da versão 1.7.2 do Google Distributed Cloud, as imagens do SO Ubuntu têm maior proteção com o CIS L1 Server Benchmark.

    Como resultado, o script cron /etc/cron.daily/aide foi instalado para que uma verificação aide seja programada para garantir que a regra do CIS L1 Server "1.4.2 Garanta que a integridade do sistema de arquivos seja verificada regularmente" seja seguida.

    O cron job é executado diariamente às 6h 25m UTC. Dependendo do número de arquivos no sistema de arquivos, você talvez tenha picos de uso de CPU e memória em torno desse horário, causados por esse processo aide.


    Alternativa:

    Se os picos estiverem afetando sua carga de trabalho, desative o cron job diário:

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

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

    O problema é que as regras de firewall distribuídas com estado NSX-T encerram a conexão de um cliente com o servidor da API do cluster de usuário pelo balanceador de carga Seesaw porque o Seesaw usa fluxos de conexão assimétricos. Os problemas de integração com as regras de firewall distribuídas NSX-T afetam todas as versões do Google Distributed Cloud que usam o Seesaw. Você pode encontrar problemas de conexão semelhantes nos seus aplicativos ao criar objetos grandes do Kubernetes com tamanhos maiores que 32 K.


    Alternativa:

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

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

    Para as versões 1.10 a 1.15 do Google Distributed Cloud, alguns clientes têm encontrado uma cobrança alta inesperada para Metrics volume no Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:

    • A geração de registros e o monitoramento de aplicativos estão ativados (enableStackdriverForApplications=true)
    • Os pods do aplicativo têm a anotação prometheus.io/scrap=true. (A instalação do Cloud Service Mesh também pode adicionar essa anotação.)

    Para confirmar se você foi afetado por esse problema, liste as métricas definidas pelo usuário. Se você vir faturamento para métricas indesejadas com o prefixo de nome external.googleapis.com/prometheus e também vir enableStackdriverForApplications definido como "true" na resposta de kubectl -n kube-system get stackdriver stackdriver -o yaml, esse problema se aplica a você.


    Alternativa

    Se você for afetado por esse problema, recomendamos que faça upgrade dos clusters para a versão 1.12 ou mais recente, pare de usar a flag enableStackdriverForApplications e mude para a nova solução de monitoramento de aplicativos managed-service-for-prometheus, que não depende mais da anotação prometheus.io/scrap=true. Com a nova solução, também é possível controlar a coleta de registros e métricas separadamente para seus aplicativos, com as flags enableCloudLoggingForApplications e enableGMPForApplications, respectivamente.

    Para parar 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, salve e feche o editor.

    Se não for possível mudar da coleta de métricas baseada em anotações, siga estas etapas:

    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 o recurso de mesclagem de métricas do Istio.
    Instalação 1.11, 1.12, 1.13

    O instalador do Google Distributed Cloud pode falhar se os papéis personalizados estiverem vinculados no nível errado de permissões.

    Quando a vinculação de papel está incorreta, a criação de um disco de dados do vSphere com govc trava e o disco é criado com um tamanho igual a 0. Para corrigir o problema, você precisa vincular o papel personalizado no nível do vSphere vCenter (raiz).


    Alternativa:

    Se você quiser vincular o papel personalizado no nível do DC (ou inferior à raiz), também é necessário vincular o papel somente leitura ao usuário no nível raiz do vCenter.

    Para mais informações sobre a criação de papéis, consulte Privilégios de conta de usuário do vCenter.
    Geração de registros e monitoramento 1.9.0-1.9.4, 1.10.0-1.10.1

    É possível que você veja um tráfego de rede alto para monitoring.googleapis.com, mesmo em um novo cluster que não tenha cargas de trabalho de usuários.

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


    Alternativa:
    Geração de registros e monitoramento 1.10, 1.11

    Para o Google Distributed Cloud versão 1.10 e mais recentes, o DaemonSet "gke-metrics-agent" tem erros CrashLoopBackOff frequentes quando "enableStackdriverForApplications" é definido como "true" no objeto "stackdriver".


    Alternativa:

    Para minimizar esse problema, desative a coleta de métricas do aplicativo executando os comandos a seguir. Esses comandos não desativam a coleta de registros de aplicativos.

    1. Para evitar que as mudanças a seguir sejam revertidas, reduza a escala vertical de stackdriver-operator: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
       Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.
    2. Abra o ConfigMap gke-metrics-agent-conf para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Em services.pipelines, comente a seção metrics/app-metrics inteira:
      services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Fechar 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
    Geração de registros e monitoramento 1.11, 1.12, 1.13

    Se as métricas descontinuadas forem usadas nos painéis de OOTB, alguns gráficos vazios serão exibidos. Para encontrar métricas descontinuadas nos painéis do Monitoring, execute os seguintes comandos:

    gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    As métricas descontinuadas a seguir precisam ser migradas para as substituições.

    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

    Alternativa:

    Para substituir as métricas descontinuadas:

    1. Exclua o "Status do nó do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale o "Status do nó do GKE On-Prem" seguindo estas instruções.
    2. Exclua "Utilização do nó do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale a "Utilização de nós do GKE On-Prem" seguindo estas instruções.
    3. Exclua "Integridade de VM do vSphere do GKE On-Prem" no painel do Google Cloud Monitoring. Reinstale "Integridade de VM do vSphere do GKE On-Prem" seguindo estas instruções.

      4. Essa descontinuação ocorre devido ao upgrade do agente kube-state-metrics da v1.9 para a v2.4, que é necessário para o Kubernetes 1.22. É possível substituir todas as métricas kube-state-metrics descontinuadas, que têm o prefixo kube_, nos painéis personalizados ou nas políticas de alertas.
    Geração de registros e monitoramento 1.10, 1.11, 1.12, 1.13

    Para o Google Distributed Cloud versão 1.10 e posterior, os dados de clusters no Cloud Monitoring podem conter entradas de métricas de resumo irrelevantes, como o seguinte:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Outros tipos de métricas que podem ter métricas de resumo irrelevantes incluem:

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Embora essas métricas de tipo de resumo estejam na lista de métricas, elas não são compatíveis com gke-metrics-agent no momento.
    Geração de registros e monitoramento 1.10, 1.11, 1.12, 1.13

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

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

    Alternativa:

    Para corrigir esse problema, siga as seguintes etapas como uma solução alternativa. Para [versão 1.9.5+, 1.10.2+, 1.11.0]: aumente a CPU do gke-metrics-agent seguindo as etapas de 1 a 4

    1. Abra o recurso stackdriver para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar a solicitação de CPU de gke-metrics-agent de 10m para 50m, o limite de CPU de 100m para 200m adiciona a seção resourceAttrOverride a seguir ao manifesto stackdriver: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
       O recurso editado ficará semelhante ao seguinte: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Salve as alterações e feche o editor de texto.
    4. Para verificar se as mudanças entraram em vigor, execute o seguinte comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
       O comando encontrará cpu: 50m se as edições tiverem entrado em vigor.
    Geração de registros e monitoramento 1.11.0-1.11.2, 1.12.0

    Se o cluster de administrador for afetado por esse problema, as métricas do programador e do gerenciador de controladores estão ausentes. Por exemplo, essas duas métricas estão ausentes

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

    Alternativa:

    Faça upgrade para a v1.11.3+, v1.12.1+ ou v1.13+.
    1.11.0-1.11.2, 1.12.0

    Se o cluster de usuário for afetado por esse problema, as métricas do programador e do gerenciador de controladores estão ausentes. Por exemplo, essas duas métricas estão ausentes:

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

    Alternativa:

    Esse problema foi corrigido na versão 1.13.0 e mais recentes do Google Distributed Cloud. Faça upgrade do cluster para uma versão com a correção.
    Instalação, upgrades e atualizações 1.10, 1.11, 1.12, 1.13

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

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

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

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

    Alternativa:
    Identidade 1.10, 1.11, 1.12, 1.13

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


    Alternativa:

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

    • Desativar o serviço de identidade do GKE. Se você desativar o serviço de identidade do GKE, isso não vai remover o binário implantado 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 host da frota do cluster.
    • Atualize o cluster para a versão 1.9.3, 1.10.1 ou mais recente e faça upgrade da versão do agente do Connect.
    Rede 1.10, 1.11, 1.12, 1.13

    O Seesaw é executado no modo DSR. Por padrão, ele não funciona na Cisco ACI devido ao aprendizado de IP de plano de dados.


    Alternativa:

    Uma possível solução alternativa é desativar o aprendizado de IP adicionando o endereço IP Seesaw como um IP virtual L4-L7 no Controlador de infraestrutura de política de aplicativo (APIC) da Cisco.

    Para configurar a opção de IP virtual L4-L7, acesse Locatário > Perfis de aplicativo > EPGs de aplicativo ou EPGs uSeg. Se o aprendizado de IP não for desativado, o endpoint de IP vai oscilar entre diferentes locais na estrutura da API Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    A VMWare identificou recentemente problemas críticos nas seguintes versões da atualização 3 do vSphere 7.0:

    • Atualização 3 do vSphere ESXi 7.0 (versão 18644231)
    • Atualização 3a do vSphere ESXi 7.0 (versão 18825058)
    • Atualização 3b do vSphere ESXi 7.0 (versão 18905247)
    • Atualização 3b do vSphere vCenter 7.0 (versão 18901211)

    Alternativa:

    A VMWare removeu essas versões. Faça upgrade dos servidores de ESXi e vCenter para uma versão mais recente.
    Sistema operacional 1.10, 1.11, 1.12, 1.13

    Para pods em execução em nós que usam imagens do Container-Optimized OS (COS), não é possível montar o volume emptyDir como exec. Ele é montado como noexec, e você receberá este erro: exec user process caused: permission denied. Por exemplo, você receberá essa mensagem de erro se implantar o pod de teste a seguir:

    apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    No pod de teste, se você executar mount | grep test-volume, ele vai mostrar a opção noexec:

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

    Alternativa:
    Upgrades, atualizações 1.10, 1.11, 1.12, 1.13

    As réplicas do pool de nós não são atualizadas depois que o escalonamento automático é ativado e desativado em um pool de nós.


    Alternativa:

    Remoção das anotações cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size da implantação da máquina do pool de nós correspondente.
    Geração de registros e monitoramento 1.11, 1.12, 1.13

    A partir da versão 1.11, nos painéis de monitoramento prontos para uso, o painel de status do pod do Windows e o painel de status do nó do Windows também mostram dados de clusters do Linux. Isso porque as métricas de nós e pods do Windows também são expostas nos clusters do Linux.
    Geração de registros e monitoramento 1.10, 1.11, 1.12

    Para as versões 1.10, 1.11 e 1.12 do Google Distributed Cloud, o DaemonSet stackdriver-log-forwarder pode ter erros CrashLoopBackOff quando há registros armazenados em buffer corrompidos no disco.


    Alternativa:

    Para atenuar esse problema, precisaremos limpar os registros armazenados em buffer no nó.

    1. Para evitar esse comportamento inesperado, reduza a escala vertical de stackdriver-log-forwarder: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
       Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.
    2. Implante o DaemonSet de limpeza para limpar os blocos corrompidos: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Para garantir que o DaemonSet de limpeza limpou todos os blocos, execute os seguintes comandos. A saída dos dois comandos precisa ser igual ao número do nó no cluster: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Exclua o DaemonSet de limpeza:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Retome stackdriver-log-forwarder: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Geração de registros e monitoramento 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Se você não vir registros dos seus clusters no Cloud Logging e perceber o seguinte erro nos registros: 

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    É provável que a taxa de entrada de registros exceda o limite do agente de geração de registros, o que faz com que stackdriver-log-forwarder não envie registros. Esse problema ocorre em todas as versões do Google Distributed Cloud.

    Alternativa:

    Para atenuar esse problema, é preciso aumentar o limite de recursos no agente de geração de registros.

    1. Abra o recurso stackdriver para edição: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar a solicitação de CPU para stackdriver-log-forwarder, adicione a seguinte seção resourceAttrOverride ao manifesto stackdriver: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
       O recurso editado ficará semelhante ao seguinte: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Salve as alterações e feche o editor de texto.
    4. Para verificar se as mudanças entraram em vigor, execute o seguinte comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       O comando encontrará cpu: 1200m se as edições tiverem entrado em vigor.
    Segurança 1.13

    há um curto período em que o nó está pronto, mas o certificado do servidor do kubelet não está. kubectl exec e kubectl logs ficam indisponíveis durante esse período. Isso ocorre porque leva tempo para o novo aprovador de certificado do servidor ver os IPs válidos atualizados do nó.

    Esse problema afeta apenas o certificado do servidor kubelet. Ele não afeta a programação do pod.
    Upgrades, atualizações 1.12

    Falha no upgrade do cluster de usuário com:

    .LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    O cluster de administrador não recebeu upgrade completo, e a versão do status ainda é 1.10. O upgrade do cluster de usuário para 1.12 não será bloqueado por nenhuma verificação de simulação e falha com o problema de desvio de versão.


    Alternativa:

    Conclua o upgrade do cluster de administrador para a versão 1.11 e depois atualize o cluster de usuário para a 1.12.
    Armazenamento 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Falha no comando gkectl diagnose cluster com: 

    Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    A validação do espaço livre do repositório de dados não pode ser usada para pools de nós de clusters atuais e foi adicionada em gkectl diagnose cluster por engano.


    Alternativa:

    É possível ignorar a mensagem de erro ou pular a validação usando --skip-validation-infra.
    Operação, rede 1.11, 1.12.0-1.12.1

    Talvez não seja possível adicionar um novo cluster de usuário se o cluster de administrador estiver definido com uma configuração do balanceador de carga MetalLB.

    O processo de exclusão do cluster de usuário pode ficar travado por algum motivo, o que resulta em uma invalidação do ConfigMap MetalLB. Não será possível adicionar um novo cluster de usuário nesse estado.


    Alternativa:

    É possível forçar a exclusão do cluster de usuário.
    Instalação, sistema operacional 1.10, 1.11, 1.12, 1.13

    Se osImageType estiver usando cos para o cluster de administrador, quando gkectl check-config for executado após a criação do cluster de administrador e antes da criação do cluster de usuário, ocorrerá uma falha: 

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

    Por padrão, a VM de teste criada para o cluster de usuário check-config usa o mesmo osImageType do cluster de administrador. No momento, a VM de teste ainda não é compatível com o COS.


    Alternativa:

    Para evitar a verificação lenta de simulação, que cria a VM de teste, usando gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Geração de registros e monitoramento 1.12.0-1.12.1

    Esse problema afeta os clientes que usam o Grafana no cluster de administrador para monitorar os clusters de usuário nas versões 1.12.0 e 1.12.1 do Google Distributed Cloud. Ele é originado de uma incompatibilidade de certificados pushprox-client em clusters de usuário e a lista de permissões no pushprox-server no cluster de administrador. O sintoma é o pushprox-client em registros de erro de impressão de clusters de usuários, como o seguinte:

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

    Alternativa:
    Outro 1.11.3

    Falha no comando gkectl repair admin-master com: 

    Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master não poderá buscar o modelo de VM a ser usado para reparar a VM do plano de controle do administrador se o nome da VM do plano de controle do administrador terminar com os caracteres t, m, p ou l.


    Alternativa:

    Execute o comando novamente com --skip-validation.
    Geração de registros e monitoramento 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Os Registros de auditoria do Cloud precisam de uma configuração de permissão especial que, no momento, é executada automaticamente apenas para clusters de usuários pelo GKE Hub. Recomendamos que haja pelo menos um cluster de usuário que use o mesmo ID do projeto e conta de serviço com o cluster de administrador para os registros de auditoria do Cloud, assim o cluster de administrador terá a permissão necessária.

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

    Alternativa:
    Operação, segurança 1.11

    Se a estação de trabalho não tiver acesso aos nós de trabalho do cluster de usuário, ela vai receber as seguintes falhas ao executar gkectl diagnose:

    Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Se a estação de trabalho não tiver acesso aos nós de trabalho do cluster de administrador ou aos nós de trabalho do cluster de usuário, ela receberá as seguintes falhas ao executar gkectl diagnose:

    Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Alternativa:

    Se for seguro ignorar essas mensagens.
    Sistema operacional 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    O /var/log/audit/ está repleto de registros de auditoria. Verifique o uso do disco executando sudo du -h -d 1 /var/log/audit.

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

    Desde o Google Distributed Cloud v1.8, a imagem do Ubuntu é reforçada com o comparativo de mercado CIS de nível 2. E uma das regras de compliance, "4.1.2.2 Garanta que os registros de auditoria não sejam excluídos automaticamente", garante a configuração auditada max_log_file_action = keep_logs. Isso resulta em todas as regras de auditoria mantidas no disco.


    Alternativa:
    Rede 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    Os usuários não podem criar ou atualizar objetos NetworkGatewayGroup devido ao seguinte erro de webhook de validação:

    [1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    Nas versões afetadas, o kubelet pode se vincular por engano a um endereço IP flutuante atribuído ao nó e informá-lo como um endereço de nó em node.status.addresses. O webhook de validação verifica endereços IP flutuantes NetworkGatewayGroup em todos os node.status.addresses no cluster e vê isso como um conflito.


    Alternativa:

    No mesmo cluster em que a criação ou a atualização de objetos NetworkGatewayGroup está falhando, desative temporariamente o webhook de validação do ANG e envie sua alteração:

    1. Salve a configuração do webhook para que ela possa ser restaurada no final: 
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    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 objeto NetworkGatewayGroup.
    5. Aplique novamente a configuração original do webhook: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Instalação, upgrades e atualizações 1.10.0-1.10.2

    Durante uma tentativa de upgrade do cluster de administrador, a VM do plano de controle do administrador pode ficar travada durante a criação. A VM do plano de controle do administrador entra em um loop de espera infinita durante a inicialização, e você receberá o seguinte erro de loop infinito no arquivo /var/log/cloud-init-output.log:

    + echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Isso ocorre porque, quando o Google Distributed Cloud tenta acessar o endereço IP do nó no script de inicialização, ele usa grep -v ADMIN_CONTROL_PLANE_VIP para pular o VIP do plano de controle do cluster de administrador que também pode ser atribuído à NIC. Porém, o comando também pula qualquer endereço IP que tenha um prefixo do VIP do plano de controle, o que faz com que o script de inicialização trave.

    Por exemplo, suponha que o VIP do plano de controle do cluster de administrador seja 192.168.1.25. Se o endereço IP da VM do plano de controle do cluster de administrador tiver o mesmo prefixo, por exemplo,192.168.1.254, a VM do plano de controle vai ficar travada durante a criação. Esse problema também pode acionado se o endereço de transmissão tiver o mesmo prefixo que o VIP do plano de controle, por exemplo, 192.168.1.255.


    Alternativa:

    • Se o motivo do tempo limite da criação do cluster de administrador for devido ao endereço IP da transmissão, execute o seguinte comando na VM do plano de controle do cluster de administrador: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
       Isso vai criar uma linha sem um endereço de transmissão e desbloquear o processo de inicialização. Depois que o script de inicialização for desbloqueado, remova essa linha adicionada executando o seguinte comando: 
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • No entanto, se o motivo do tempo limite da criação do cluster de administrador for devido ao endereço IP da VM do plano de controle, não será possível desbloquear o script de inicialização. Alterne para um endereço IP diferente e recrie ou faça upgrade para a versão 1.10.3 ou mais recente.
    Sistema operacional, upgrades e atualizações 1.10.0-1.10.2

    Não é possível montar o DataDisk corretamente no nó mestre do cluster de administrador ao usar a imagem do COS. Além disso, o estado do cluster de administrador que usa a imagem do COS será perdido após o upgrade do cluster de administrador ou reparo mestre do administrador. O cluster de administrador que usa a imagem do COS é um recurso em fase de pré-lançamento.


    Alternativa:

    Recriar cluster de administrador com osImageTypeType definido como ubuntu_containerd

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

    No Google Distributed Cloud versão 1.10.0, as resoluções de nome no Ubuntu são roteadas para detecção local resolvida pelo systemd em 127.0.0.53 por padrão. O motivo é que, na imagem do Ubuntu 20.04 usada na versão 1.10.0, /etc/resolv.conf tem um link simbólico para /run/systemd/resolve/stub-resolv.conf, que aponta para o stub de DNS 127.0.0.53 do localhost.

    Como resultado, a resolução de nome DNS do localhost se recusa a verificar os servidores DNS upstream (especificados em /run/systemd/resolve/resolv.conf) para nomes com um sufixo .local, a menos que os nomes sejam especificados como domínios de pesquisa.

    Isso causa falhas nas pesquisas de nomes de .local. Por exemplo, durante a inicialização do nó, o kubelet falha ao extrair imagens de um registro particular com um sufixo .local. A especificação de um endereço do vCenter com um sufixo .local não funcionará em uma estação de trabalho de administrador.


    Alternativa:

    Para evitar esse problema em nós de cluster, especifique o campo searchDomainsForDNS no arquivo de configuração do cluster de administrador e o arquivo de configuração do cluster de usuário para incluir os domínios.

    No momento, o gkectl update ainda não é compatível com a atualização do campo searchDomainsForDNS.

    Portanto, se você não tiver configurado esse campo antes da criação do cluster, precisará usar o SSH nos nós e ignorar o stub local resolvido pelo systemd alterando o link simbólico de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contém o stub local de 127.0.0.53) para /run/systemd/resolve/resolv.conf (que aponta para o DNS upstream real):

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Como na estação de trabalho de administrador, o gkeadm não é compatível com a especificação de domínios de pesquisa. Por isso, é necessário contornar esse problema nesta etapa manual.

    Esta solução não permanece nas recriações de VM. Aplique a solução novamente sempre que as VMs forem recriadas.
    Instalação, sistema operacional 1.10

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

    Como resultado, o Docker escolhe o 172.17.0.1/16 padrão como a sub-rede de endereço IP da ponte. Isso poderá causar um conflito de endereços IP se a carga de trabalho já estiver em execução nesse intervalo de endereços IP.


    Alternativa:

    Para contornar esse problema, você precisa renomear o seguinte arquivo de configuração systemd do dockerd e reiniciar o serviço:

    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Verifique se o Docker escolhe o endereço IP da ponte correto:

    ip a | grep docker0

    Esta solução não permanece nas recriações de VM. Aplique a solução novamente sempre que as VMs forem recriadas.
    Upgrades, atualizações 1.11

    No Google Distributed Cloud versão 1.11.0, há mudanças na definição de recursos personalizados relacionados a geração de registros e monitoramento:

    • O nome do grupo do recurso personalizado stackdriver foi alterado de addons.sigs.k8s.io para addons.gke.io.
    • O nome do grupo dos recursos personalizados monitoring e metricsserver foi alterado de addons.k8s.io para addons.gke.io.
    • As especificações dos recursos acima começam a ser validadas em relação ao esquema. Em particular, as especificações resourceAttrOverride e storageSizeOverride no recurso personalizado stackdriver precisam ter um tipo de string nos valores das solicitações e limites de CPU, memória e tamanho de armazenamento.

    As mudanças no nome do grupo foram feitas para obedecer às atualizações da CustomResourceDefinition no Kubernetes 1.22.

    Nenhuma ação será necessária caso você não tenha outra lógica que aplique ou edite os recursos personalizados afetados. O processo de upgrade do Google Distributed Cloud cuida da migração dos recursos afetados e mantém as especificações atuais após a mudança do nome do grupo.

    No entanto, se você executar qualquer lógica que aplique ou edite os recursos afetados, será necessário atenção especial. Primeiro, eles precisam estar referenciados com o novo nome de grupo no arquivo de manifesto. Por exemplo:

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

    Depois, verifique se os valores de especificação resourceAttrOverride e storageSizeOverride são do tipo string. 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 edições não terão efeito e poderão levar a um status inesperado nos componentes de registro e monitoramento. Os possíveis sintomas podem incluir:

    • Registros de erros de reconciliação em onprem-user-cluster-controller, por exemplo: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Falha em kubectl edit stackdriver stackdriver, por exemplo: 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Se você encontrar os erros acima, isso significa que um tipo incompatível na especificação da CR do Stackdriver já estava presente antes do upgrade. Como solução alternativa, é possível editar manualmente a resposta automática do Stackdriver com o nome antigo do grupo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e fazer o seguinte:

    1. Alterar as solicitações e os limites dos recursos para o tipo de string;
    2. Remova qualquer anotação addons.gke.io/migrated-and-deprecated: true, se houver.
    Em seguida, retome ou reinicie o processo de upgrade.

    Sistema operacional 1.7 e superior

    Sempre que houver uma falha em um servidor ESXi e a função de alta disponibilidade do vCenter estiver ativada no servidor, todas as VMs no servidor ESXi com falha acionarão o mecanismo vMotion e serão movidas para outro servidor ESXi normal. As VMs do COS migradas perderiam os IPs.

    Alternativa:

    Reinicialize a VM
    Rede todas as versões anteriores a 1.14.7, 1.15.0-1.15.3, 1.16.0

    O ARP periódico (ARRP gratuito) enviado pelo Seesaw a cada 20 segundos não define o IP de destino no cabeçalho ARP. Algumas redes podem não aceitar esses pacotes (como Cisco ACI). Eles podem causar um tempo de inatividade mais longo após a recuperação de um cérebro dividido (devido à queda do pacote VRRP).

    Alternativa:

    Acione um failover do Seeaw com a execução de sudo seesaw -c failover em qualquer uma das VMs do Seesaw. Isso deve restaurar o tráfego.
    Sistema operacional 1.16, 1.28.0-1.28.200

    "staticPodPath" foi definido por engano para nós de trabalho

    Alternativa:

    Crie manualmente a pasta "/etc/kubernetes/manifests"

    A seguir

    Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

    Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo: