| Instalação |
1.9.0
1.9.1
1.9.2 |
Às vezes, o iLO não consegue recuperar a chave do HSM.
Sintomas:
`server.status.conditions` tem uma entrada com o tipo `KeyManagerConfigured` e o status `True`, mas nenhuma com o tipo `DiskEncryptionEnabled`. Há pods com falha chamados `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` com o erro `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0`. Falha ao fazer ssh no pod devido a uma chave inválida.
Alternativa:
Para resolver o problema, siga estas etapas:
Acesse a UI do iLO > Informações > Diagnóstico > Redefinir para redefinir o iLO. Se, durante a redefinição, o iLO mostrar que o servidor está no teste automático de inicialização (POST), reinicie o fluxo de provisionamento:
Se a instalação do admin-cluster foi concluída:
export KUBECONFIG=<root-admin-kubeconfig path>
Atualize a chave SSH:
Pegue a chave SSH pública atual. Ela pode ter sido alterada e, portanto, ser diferente de /root/.ssh/id_rsa.pub.
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
Coloque a chave pública no configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars
Adicione IRONIC_RAMDISK_SSH_KEY: \ Reinicie o ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Faça o reprovisionamento da máquina para reinstalar o IPA:
Faça backup de bmc-credential-$SERVER, porque a exclusão de bmh também exclui o secret.
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Remova do arquivo atributos não aplicáveis, como: last-applied, creationtimestamp, finalizer, ownerreference, resourceversion, uid.
Exclua o BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Pegue o Secret bmc-credentials-$SERVER ou o backup anterior de cellcfg e aplique-o.
Diga ao servidor para fazer algo diferente.
Para remover o status em cache do BMH:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Aguarde o provisionamento do servidor. Assista como os objetos BMH são criados. Talvez seja necessário excluir os jobs de criptografia para acionar novamente.
|
| Operações |
1.9.0
1.9.1
1.9.2 |
Sintomas:
O estado da VM persiste com STATUS de Provisioning ou Starting quando storageClassName é standard-block.
Alternativa:
Para resolver o problema, siga estas etapas:
Verifique se a VM STATUS mostra Provisioning ou Starting:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG é o caminho do arquivo kubeconfig do cluster do sistema.
PROJECT é o projeto do GDC em que a VM reside.
Opcional: confira mais detalhes do status:
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME é o nome da VM que não responde.
Exclua a VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME é o nome do namespace.
Verifique se a exclusão foi bem-sucedida:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Um resultado semelhante ao seguinte confirma o sucesso:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Exclua todos os discos dessa VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Substitua o nome de cada um dos seus discos por DISK_NAME_1 e DISK_NAME_2 até DISK_NAME_N e verifique se todos os discos estão listados. Verifique se a exclusão foi bem-sucedida:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Um resultado semelhante ao seguinte confirma o sucesso:
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
Recrie a VM e os discos.
Reinicie a VM.
|
| Operações |
1.9.2 |
Sintomas:
gdcloud system container-registry load-oci falha com erros. Se você executar o comando novamente, ele será executado por períodos diferentes e falhará em pontos diferentes do processo, como push ou retag, mas com erros semelhantes.
Alternativa:
Para resolver o problema, siga estas etapas:
Exporte KUBECONFIG para o kubeconfig do administrador raiz:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Execute este comando para reduzir o escalonamento de
deployment/root-admin-tftp-manager-controller para zero réplicas:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Execute as operações que estavam falhando.
- Aumente os recursos do
deployment/root-admin-tftp-manager-controller para uma réplica:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| Operações |
1.9.1
1.9.2
1.9.3 |
Sintomas:
gdcloud system container-registry load-oci falha com erros. Se você executar o comando novamente, ele será executado por períodos diferentes e falhará em pontos diferentes do processo, como push ou retag, mas com erros semelhantes.
Alternativa:
Ignore a mensagem com segurança. Ele desaparece depois de um tempo.
|
| Operações |
1.9.2 |
Alternativa:
Para resolver o problema, reinicie o pod afetado.
|
| Operações |
1.9.0
1.9.1
1.9.2 |
Sintomas:
O status da condição "Servidor pronto" é "False", e a mensagem contém "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...". Os registros do job com falha contêm "Failed to connect to the host via ssh ... Permission denied (publickey)."
Alternativa:
Para resolver o problema, siga estas etapas:
Extraia a chave pública SSH atual do cluster de administrador raiz:
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dColoque a chave no configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars Adicione ou substitua a IRONIC_RAMDISK_SSH_KEY:
<SSH public key>
Reinicie a implantação do ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Para cada servidor afetado:
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Operações |
1.9.2 |
Alternativa:
Para evitar o problema de falta de endereços IP, defina o tamanho do CIDR do pod como /21 ou maior ao criar um cluster de usuários de alta disponibilidade.
|
| Instalação |
1.9.2 |
Alternativa:
Para resolver o problema, reinicie os pods.
Consulte o runbook MON-R0001 para mais detalhes.
|
| Autenticação da plataforma |
1.9.13 |
Sintomas:
Todos os jobs cplb-init e storage-ipsec-config-bm-XXXXX mostram a seguinte mensagem: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Alternativa:
1. Verifique se a VRF do BGP está inativa em aggswitch.
2. Verifique se há mudanças não confirmadas na nova configuração de preparação no firewall.
3. Limpe todos os securitypolicyrules que tinham a organização excluída no nome e reinicie o root-admin-controller.
|
| Fazer upgrade |
1.9.1
1.9.2
1.9.11 |
Sintomas:
Server está com .status.bareMetalHostStatus.provisionState preso em deprovisioning há mais de 20 minutos.
O endereço IP de gerenciamento do servidor que está sendo atualizado está incluído na saída de qualquer um destes comandos:
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
Alternativa:
Para resolver o problema, execute:
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Fazer upgrade |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
Sintomas:
Uma tarefa de upgrade em NodeUpgrade permanece inacabada por mais de duas horas.
Um NodeUpgradeTask correspondente fica na condição NodeResumeCompleted por mais de uma hora.
bm-system-x.x.x.x-machine-init jobs permanecem inacabados por muito tempo. x.x.x.x é o endereço do nó.
Alternativa:
Para encontrar o endereço de um nó não íntegro, consulte o x.x.x.x do job bm-system-x.x.x.x-machine-init pendente.
Para encontrar um nó de plano de controle íntegro para o nó não íntegro, siga estas etapas:
- Encontre o pool de nós do nó não íntegro.
Verifique o pool de nós do plano de controle no mesmo cluster do nó não íntegro e selecione um endereço do .spec.address desse pool de nós do plano de controle.
No bootstrapper ou OC IT, execute:
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
No nó do plano de controle íntegro, execute:
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| Fazer upgrade |
1.9.1
1.9.2 |
Sintomas:
O pod do operador de frota do ODS está em loop de falha.
Para verificar o status do pod, execute:
ko get pods -n ods-fleet-operator
Um erro de eleição de líder semelhante ao seguinte aparece nos registros do operador da frota do ODS:
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
Para verificar os registros do operador da frota do ODS, execute:
ko logs deployment/fleet-controller-manager -n ods-fleet-system
A seguinte mensagem é exibida:
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition
Alternativa:
Para editar a implantação, execute:
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
Edite o campo resources do contêiner manager da seguinte maneira:
Antes:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Depois:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Fazer upgrade |
1.9.2
1.9.3 |
Sintomas:
A seguinte mensagem de erro é exibida:
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
Alternativa:
Para corrigir o problema, siga estas etapas:
Faça login em todos os nós de GPU provisionados:
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Remova pacotes antigos:
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
Exclua o pod kubevm-gpu-driver-daemonset preso. Isso reinicia a instalação:
# kug get pods -A | grep gpu | grep Init
(Opcional) Se a instalação do complemento tiver expirado, reinicie o processo:
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Fazer upgrade |
1.9.10
1.9.11 |
Sintomas:
O gpcbackup-agent-0 mostra failed to stage volume: iSCSI login failed e não consegue preparar o volume.
Verifique se o pod não está conseguindo anexar o volume. Os exemplos a seguir usam o kubeconfig do cluster do sistema:
-
Descreva o pod:
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Se o pod estiver falhando, uma saída semelhante ao exemplo a seguir será mostrada:
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
Verifique o nó em que o pod está falhando:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Você vai receber uma saída semelhante a este exemplo:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
Consiga o pod netapp-trident no mesmo nó em que o pod gpcbackup-agent-0 falhou:
kos get pod -o wide -n netapp-trident
Você vai receber uma saída semelhante a este exemplo:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Verifique os registros do pod netapp-trident no mesmo nó em que o pod gpcbackup-agent-0 falhou:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Você vai receber uma saída semelhante a este exemplo:
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
Alternativa:
Para resolver o problema, siga estas etapas:
-
Consiga o nome do InventoryMachine:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Confirme se o job anterior existe:
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
Você vai receber uma saída semelhante a esta:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Exclua o job:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Você vai receber uma saída semelhante a esta:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Confirme se o StorageEncryptionConnection existe:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Você vai receber uma saída semelhante a esta:
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
Exclua o StorageEncryptionConnection:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Você vai receber uma saída semelhante a esta:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Reinicie o pod root-admin-controller:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
Confirme se o novo job foi recriado e executado com sucesso:
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Você vai receber uma saída semelhante a esta:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Fazer upgrade |
1.9.10
1.9.11 |
Sintomas:
Um pod do registro do Harbor mostra uma mensagem de erro semelhante a esta:
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
Alternativa:
Para solucionar o problema, siga estas etapas:
-
Verifique a declaração de volume persistente (PVC) do registro do Harbor e anote o nome do volume da PVC:
kubectl get pvc harbor-registry -n harbor-system
-
Para verificar se a vinculação de volume está no mesmo nó do pod do registro do Harbor, liste os volumeattachment e encontre o associado ao nome do volume:
kubectl get volumeattachment | grep [volume-name]
-
Se o anexo de volume estiver em um nó diferente do pod do registro do Harbor, remova o volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Reinicie o pod do registro do Harbor.
Agora, o registro do Harbor no cluster de administrador raiz precisa estar íntegro, e o upgrade do nó será concluído.
|
| Instalação |
1.9.2
1.9.3
1.9.4
1.9.5
|
Sintomas:
A seguinte mensagem de erro é exibida:
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Um registro de pod contém o seguinte:
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
A versão do CoreDNS é 1.8.6.
Alternativa:
Para resolver o problema, reinicie a implantação do coredns.
Depois que KUBECONFIG for definido para o cluster correto, execute:
kubectl rollout restart deployment coredns -n kube-system
O nome do cluster de usuário faz parte da mensagem de erro.
Para encontrar o arquivo kubeconfig em /root/release/user/, procure os kubeconfigs: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
Se os arquivos kubeconfig estiverem faltando, gere-os da seguinte maneira:
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| Fazer upgrade |
1.9.2
1.9.3 |
Sintomas:
A seguinte mensagem de erro é exibida:
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
Esse problema geralmente é temporário e deve ser resolvido.
|
| Instalação |
1.9.3 |
A instalação de um complemento falha com o seguinte erro:
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition
Alternativa:
A instalação do complemento pode falhar porque os nós estão no estado NotReady. Verifique se os nós estão no estado NotReady usando:
kubectl get nodes
Saiba detalhes sobre o nó que está no estado NotReady:
$ kubectl describe node | grep PodCIDRs
Em um cluster com esse problema, um nó não tem PodCIDRs atribuídos a ele, por exemplo:
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
Para corrigir o problema, reinicie a implantação ipam-controller no cluster afetado:
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Fazer upgrade |
1.9.3 |
Um upgrade falha com o seguinte erro:
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded
Alternativa:
Atualize manualmente o campo <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> do AddOnSet abm-overrides para o nome do AddOnSetTemplate da versão desejada no mesmo namespace do cluster que está sendo atualizado.</code.spec.addonsettemplateref<>
|
| Instalação |
1.9.3 |
Sintomas:
Um controlador de administrador da frota não fica pronto, falhando no teste TestCreateFleetAdminCluster ou TestSimOverlayCreateFleetAdminCluster. O controlador de administrador da frota está preso em um loop de falhas. O seguinte erro está nos registros do controlador de administrador da frota: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Alternativa:
Implante o CRD Logmon no cluster de administrador da organização. Reinicie o controlador de administrador da frota.
|
| Instalação |
1.9.3 |
Sintomas:
A seguinte mensagem de erro é exibida:
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
Alternativa:
Para resolver o problema, reinicie a implantação e o daemonset no cluster:
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
Observação:execute o comando a seguir antes de reiniciar o deployment e o daemonset para apontar para o cluster correto:
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Fazer upgrade |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Sintomas:
Um pod não pode ser programado devido à falta de CPU.
Alternativa:
Para um cluster de usuário criado com nós de trabalho n2-standard-4, adicione um novo NodePool n2-standard-8 com três nós a esse cluster antes de fazer upgrade. Para novos clusters de usuário, crie um NodePool n2-standard-8 com o mínimo de três nós. Consulte Criar um cluster de usuário para cargas de trabalho de contêineres para mais detalhes.
|
| Operações |
1.9.0
1.9.2
1.9.3
1.9.4 |
Sintomas:
A instância de VM PHASE mostra Scheduling e READY
permanece False, nunca atingindo o estado True. Isso afeta dois tipos de máquina, conforme listado na solução alternativa. Outros tipos de máquinas não são afetados e não precisam de uma solução alternativa.
Alternativa:
- Ao criar clusters de usuários que usam GPUs A100 de 40 GB, sempre selecione o tipo de máquina a2-highgpu-1g-gdc na UI.
- Ao criar clusters de usuários que usam GPUs A100 80G, sempre selecione o tipo de máquina a2-ultragpu-1g-gdc na UI.
|
| Operações |
1.9.0
1.9.2
1.9.3
1.9.4 |
Sintomas:
Para pools de nós com instâncias de VM com tamanhos de memória maiores que 32 GB,
a instância de VM pode parecer ser executada, parar e ser executada novamente, possivelmente repetindo
essa sequência. Com o tempo, um erro de falta de memória OOMKilled é
gerado e a instância falha.
Estes são os três tipos de VM afetados:
- n2-highmem-8-gdc: 64 GB de memória
- a2-highgpu-1g-gdc: 85 GB de memória
- a2-ultragpu-1g-gdc: 170 GB de memória
Alternativa:
- Verifique o tipo de máquina:
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- Procure o tipo de VM em
spec.compute.virtualMachineTypeName na sua saída.
- Se o tipo de VM for um dos três tipos listados,
edite o
configmap para incluir uma substituição de memória:
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Adicione uma seção
memory.guest e resources.overcommitGuestOverhead, como no exemplo a seguir:
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- Em
memory, mude guest para ter os seguintes valores:
- Para n2-highmem-8-gdc, faça MEMORY_SIZE
63.6G.
- Para a2-highgpu-1g-gdc, faça MEMORY_SIZE
84G.
- Para a2-ultragpu-1g-gdc, faça MEMORY_SIZE
168G.
- Repita isso para todas as VMs afetadas.
|
| Fazer upgrade |
1.9.4 |
Sintomas:
Um job bm-system-* fica parado na etapa Gathering Facts. Ao tentar fazer SSH manualmente no servidor, PTY allocation request failed on channel 0 é exibido.
Alternativa:
Reinicie o servidor usando uma destas opções:
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
UI do iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Fazer upgrade |
1.9.4
1.9.10 |
Sintomas:
Um upgrade falha porque o job backup-ipsec-* falhou.
Alternativa:
Siga estas etapas:
Encontre as chaves pré-compartilhadas no namespace gpc-system no cluster de administrador da organização. As chaves são chamadas de <node-name>-pre-shared-key.
Para receber o hash de chave de um arquivo YAML de chave pré-compartilhada de um nó em funcionamento, use kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'.
É necessário extrair o hash de chave de um nó diferente daquele em que o upgrade do ipsec falhou. Aplique o hash dessa chave pré-compartilhada ao segredo pre-shared-key do nó com falha no gpc-system no cluster de administrador da organização. Exclua o objeto storageencryptionconnection que tem o mesmo nome do nó com falha no cluster de administrador raiz. Exclua o job storage-ipsec-config-<node-name> associado no cluster de administrador da organização. Exclua o job de upgrade backup-ipsec-for-upgrade-<node-name> associado.
|
| Fazer upgrade |
1.9.4 |
Sintomas:
A atualização de clusters da organização leva muito tempo.
Alternativa:
Aguarde o encerramento natural do clamav.
|
| Fazer upgrade |
1.9.5 |
Sintomas:
Diferentes certificados são exibidos:
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
Alternativa:
Observação: faça a rotação do certificado harbor-harbor-https antes das etapas a seguir.
Siga estas etapas:
Há cópias dos dados do certificado armazenadas em secrets no cluster. Depois de fazer a rotação do certificado harbor-harbor-https, atualize também as cópias do secret.
- Recupere o URL do Artifact Registry.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- Atualize as cópias secretas do certificado do Artifact Registry em cada namespace.
Receba todos os namespaces que armazenam uma cópia secreta do certificado do Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Atualize a cópia do secret do certificado do Artifact Registry em cada namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- Para o cluster root-admin, também é necessário atualizar uma correção chamada
ca-cert-in-cluster-registry no namespace anthos-creds.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- Atualize o
registry-cert armazenado no namespace kube-system.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- Se você estiver rotacionando certificados para o cluster org-admin, também precisará atualizar as cópias secretas de certificados que existem no cluster root-admin.
Receba todos os namespaces que armazenam uma cópia secreta do certificado do Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Atualize a cópia do secret do certificado do Artifact Registry em cada namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done .
|
| Fazer upgrade |
1.10.0
1.10.1 |
Sintomas:
Depois de iniciar um OrganizationUpgrade, o pod
kube-apiserver não está sendo executado em um ou mais nós.
- Identifique o nó em que o upgrade está bloqueado:
kubectl get po -n kube-system -l component=kube-apiserver
A saída será semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- Estabeleça uma conexão SSH com o nó que acabou de ser atualizado:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
O status do contêiner vai aparecer como Exited:
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- Verifique os registros do pod
Exited:
crictl logs f1771b8aad929
A saída será semelhante ao seguinte:
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
A flag é configurada no arquivo /etc/kubernetes/manifests/kube-apiserver.yaml:
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Alternativa:
Remova a flag do arquivo /etc/kubernetes/manifests/kube-apiserver.yaml.
- Faça backup do arquivo:
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- Remova a linha:
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- Confirme se a linha foi removida:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Liste o contêiner
kube-apiserver:
O root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet detecta automaticamente a mudança e inicia o pod
kube-apiserver:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Repita essas etapas para todos os nós afetados.
|
| Fazer upgrade |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Sintomas:
Os loops de falha de implantação do kube-state-metrics em uma
organização após a rotação de certificado. Esse problema pode causar a perda de dados de monitoramento.
|
| Fazer upgrade |
1.9.6 |
Sintomas:
Após o upgrade, o nó de trabalho fica desequilibrado.
Alternativa:
Faça o balanceamento manual do nó de trabalho:
- Para uma carga de trabalho de pod, exclua os pods na implantação.
- Para uma carga de trabalho de VM, exclua o virt-launcher sem modificar o objeto GVM do plano de controle.
|
| Fazer upgrade |
1.9.6 |
Ao fazer upgrade da versão 1.9.5 para a 1.9.6, é possível que o plug-in do dispositivo
de GPU não seja iniciado.
Sintomas:
O seguinte erro pode aparecer, bloqueando a preparação do ambiente de execução da VM
e o processo de upgrade:
Failed to initialize NVML: could not load NVML library
Alternativa:
- Verifique se o
nvidia-container-runtime está configurado corretamente no nó:
- Estabeleça uma conexão SSH com o nó que você suspeita ter um problema.
- Confira a lista de pods:
crictl pods
- Inspecione os pods:
crictl inspectp $pod_hash | grep runtimeOption -A1
Se a saída for semelhante a esta, o nó estará configurado corretamente. Se a saída não for assim, o nvidia-container-runtime não estará configurado no nó:
binary_name": "/usr/bin/nvidia-container-runtime"
- Se o
nvidia-container-runtime não estiver configurado corretamente, reinicie o containerd para resolver o problema:
systemctl restart containerd
|
| Fazer upgrade |
1.9.7 |
Ao fazer upgrade para a versão 1.9.7, o firmware do pool de nós do cluster de administrador raiz permanece no status in process.
Sintomas:
- Para o lado
NodeUpgrade, consulte a solução alternativa Tempo limite do servidor de artefatos:
NodeUpgrade está preso no status in process, e a condição para NodeROMFirmwareUpgradeCompleted no status Nodeupgradetask nunca é concluída.- O URL em
spec.firmware.firmwarePackages.url no objeto NodeUpgrade pode ficar travado quando conectado a, por exemplo:
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Para o lado
Harbor, consulte a solução alternativa Servidor de artefatos não autorizado:
- No registro do servidor de artefatos, um erro relacionado ao acesso não autorizado a um repositório pode mostrar:
gdch-hpe-firmware/ilo, por exemplo:
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- No projeto do Harbor,
gdch-hpe-firmware precisa ter Spec.harborProjectConfig.accessLevel como private:
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Alternativa:
|
| Rede de nível inferior |
1.9.0 - 1.9.6 |
Sintomas:
As sessões do BGP estão inativas na rede interna de uma organização. Apenas um dos endpoints de peering BGP internos da organização é adicionado aos objetos TORSwitchInternal.
Alternativa:
Mude explicitamente a sub-rede usada em {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim para não se sobrepor a nenhum outro recurso AddressPoolClaim análogo de outra organização.
- Investigue os sintomas:
- Para cada cluster do sistema da organização, execute:
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Verifique o campo
State de cada objeto BGPSession para State de NotEstablished. Anote o LocalIP de cada NotEstablished BGPSession associado para usar mais tarde.
- Determine se
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" é a causa raiz:
- Para cada organização ativa, execute:
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- Procure o campo
ClusterIP da saída (terceira coluna) para o LocalIPs observado na etapa 1.b. Anote os LocalIPs que correspondem às entradas na terceira coluna da saída para mais tarde. Se houver vários clusters de administrador da organização distintos, em que a saída de 2.a contenha os LocalIPs observados na etapa 1.b, siga para a etapa 3.
- Resolver IPs sobrepostos usados para clusters de sistemas organizacionais.
- Execute:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- Anote o número de objetos
SubnetClaim retornados da consulta em 3.a. Isso precisa ser igual ao número de organizações ativas.
- Para cada linha, anote o namespace (coluna 1) e o bloco CIDR (coluna 3). O bloco CIDR de cada linha precisa ser igual ao de todas as outras linhas.
- Para cada organização, faça o seguinte:
- Navegue até o objeto
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim no cluster de administrador da organização.
- Calcule o
Start IP da reivindicação do pool de endereços do nó de trabalho dessa organização. Para fazer isso, pegue o bloco CIDR de 3.c e o campo Size no AddressPoolClaim de 3.d.i. Começando no penúltimo IP do bloco CIDR, conte Size IPs para baixo. Esse é o novo Start IP da primeira organização (usado na etapa 3.d.iii). Para cada organização adicional, faça a contagem regressiva de Size IPs, começando pelo novo Start IP da organização anterior.
Exemplo:
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- No
AddressPoolClaim da etapa 3.c.i, adicione o seguinte campo no campo Spec:
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
Use o seguinte comando:
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
O resultado precisa ser parecido com este se você usar org-1 de 3.d.ii, por exemplo:
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- Faça uma limpeza para evitar sessões do BGP desnecessárias no hardware TORSwitch.
- Para listar todos os recursos
TORSwitchInternal que precisam ser atualizados, execute:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Para cada um dos
TORSwitchInternals listados na saída do comando anterior, execute o seguinte comando:
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Para todos os objetos
TORSwitchInternal, remova todas as entradas da lista .spec.ebgpNeighbors que têm NeighborIPs iguais a qualquer um dos LocalIPs da etapa 2.b. Por exemplo, LocalIP de 2.2.2.2 foi observado na etapa 2.b. Confira abaixo um exemplo de TORSwitchInternal antes e depois da etapa de limpeza.
Antes da limpeza:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
Após a limpeza. Observe a entrada ebgpNeighbor removida:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- Para validar, siga a etapa 1 e confirme se todos os objetos
States BGPSession voltaram para Established. Pode levar cerca de 10 minutos para que todas as modificações sejam propagadas para as configurações físicas do GDC TORSwitch.
|
| Fazer upgrade |
1.9.7 - 1.9.21 |
Durante um upgrade, é possível que o upgrade do nó e do sistema operacional não avance.
Sintomas:
Talvez você veja um nó com o status Ready, SchedulingDisabled por algumas horas.
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
Alternativa:
- Siga o runbook PLATAUTH-SSH 0001 para receber a chave SSH do nó em questão. Depois de se conectar ao nó com SSH, execute o seguinte comando:
multipath -ll | grep fail
- Só prossiga para a próxima etapa se a saída for semelhante a esta:
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- Execute o seguinte para corrigir o problema:
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Fazer upgrade |
1.9.8-1.9.21 |
Sintomas:
Se um upgrade de cluster do ABM ficar parado por mais de duas horas, a drenagem de nós poderá ser bloqueada.
Alternativa:
As operações a seguir usam o cluster de administrador raiz como exemplo. ${TARGET_KUBECONFIG} se refere ao "kubeconfig" do cluster de destino do ABM cujo esgotamento de nós está bloqueado. ${KUBECONFIG} se refere ao kubeconfig do cluster que gerencia o cluster de destino do ABM. Para o cluster de administrador raiz, ambos se referem ao kubeconfig do administrador raiz.
Siga estas etapas para verificar se o upgrade do cluster da ABM está travado:
- Verifique os nós presos na drenagem:
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
O resultado será assim:
{"10.200.0.2": 2}
Isso significa que, para o nó "10.200.0.2", dois pods estão sendo drenados.
- Verifique se os pods ainda estão sendo drenados do nó (chamado de
${NODE_BEING_DRAINED}):
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
O número de pods de saída precisa ser igual ao número de pods sendo esgotados informado na etapa anterior.
Para cada pod yetToDrain listado na etapa 1, verifique o status dele:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Se o pod estiver no estado Running ou se ele for audit-logs-loki-0 ou loki-0 no namespace obs-system e não tiver nenhum evento reclamando unable to unmount volume, exclua explicitamente o pod com um grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Em todos os outros casos em que um pod fica preso no processo de remoção, encaminhe para os serviços de plantão.
- Monitore se a redução do nó foi concluída.
- Repita a etapa 1 se outros nós estiverem presos no processo de remoção.
|
| Fazer upgrade |
1.9.6
1.9.7
1.9.8
|
As versões 1.9 com artefatos assinados não podem ser distribuídas porque a flag Override em DistributionPolicy está definida como "false", o que impede a distribuição quando há um artefato com o mesmo nome no registro de destino.
Sintomas:
Você pode encontrar os seguintes problemas:
- O artefato com assinatura é enviado. O registro pode ter esta aparência:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Falha ao enviar o artefato. O registro pode ter esta aparência:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- O artefato 404 não foi encontrado. O registro pode ter esta aparência:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- Falha na distribuição de artefatos.
Alternativa:
Para resolver o problema, siga estas etapas:
- Atualize o recurso personalizado (CR)
DistributionPolicy para
definir Spec.Override como true.
- Para acionar uma replicação novamente, siga o runbook SAR-1005.
- Depois que a nova execução de replicação for concluída, atualize o
CR
ManualDistribution execution-ids em
Annotation com o ID de execução bem-sucedida.
|
| Hardware Security Module (HSM) |
1.9.9 |
Os HSMs podem informar intermitentemente ServicesNotStarted, o que pode fazer com que os servidores bare metal não fiquem íntegros e mostrem a seguinte mensagem:
"message": "failed to get master key name"
Sintomas:
Você pode encontrar os seguintes problemas:
Alternativa:
Para resolver o problema, siga estas etapas para reiniciar os HSMs travados:
- Instale a ferramenta
kstl do primeiro HSM executando os seguintes comandos:
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- Confirme se algum HSM está com problemas para reiniciar. Para cada HSM preso
em
ServicesNotStarted, receba o
$HSM_MGMT_IP e verifique se o serviço está inativo:
ksctl services status --url=https://$HSM_MGMT_IP
- Pause todos os HSMs, clusters de HSM e locatários de HSM:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- Estabeleça uma conexão SSH com o HSM com o serviço inativo:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Confira se você está no HSM correto. Verifique se você estabeleceu uma conexão SSH com o
$HSM_MGMT_IP correto.
- Reinicialize o primeiro HSM de dentro dele:
ksadmin@ciphertrust:~ sudo reboot
- Aguarde o primeiro HSM ficar íntegro fora do HSM:
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Essa etapa pode levar cerca de cinco minutos para que os HSMs sejam reiniciados.
- Repita essas etapas para os outros HSMs com serviços inativos.
- Retome os HSMs, clusters de HSM e locatários de HSM:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- Verifique se tudo está conciliado. Pode levar de cinco a dez minutos
para que os HSMs sejam reconciliados.
|
| Monitoramento |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
Sintomas:
Os alertas alertmanager-servicenow-webhook não chegam ao ServiceNow no cluster do sistema da organização para versões do GDC anteriores à 1.11.3. Os registros contêm a mensagem de erro read: connection reset by peer. Esse problema ocorre devido à falta de um rótulo para ativar o tráfego de saída. Se o webhook precisar se comunicar entre organizações, ele terá que usar o NAT de saída.
Alternativa:
É necessário ativar o tráfego de saída para alertmanager-servicenow-webhook em clusters do sistema da organização. Para resolver o problema, siga estas etapas:
- Defina os pré-requisitos necessários:
- Instale a interface de linha de comando (CLI) gdcloud.
- Consiga os caminhos para os arquivos kubeconfig dos clusters de administrador raiz e de administrador da organização. Salve os caminhos nas variáveis de ambiente
ROOT_KUBECONFIG e ORG_SYSTEM_KUBECONFIG, respectivamente.
- Peça ao administrador de segurança para conceder a você o papel de administrador de observabilidade (
observability-admin) no namespace obs-system para os clusters de administrador raiz e administrador da organização.
- Confirme se o problema existe no seu ambiente:
- Receba a implantação do
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Confira os registros da implantação
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Se os registros contiverem a mensagem de erro read: connection reset by peer, o problema existe e você precisa continuar com as etapas desta solução alternativa.
- Adicione o rótulo de saída:
- Extraia o arquivo YAML de implantação
alertmanager-servicenow-webhook atual:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Adicione o rótulo de saída ao arquivo YAML de implantação
alertmanager-servicenow-webhook:
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Substitua o arquivo YAML de implantação
alertmanager-servicenow-webhook pelas atualizações:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
A implantação precisa ser reiniciada automaticamente.
- Para verificar se o problema foi corrigido, execute novamente as etapas em Confirmar se o problema existe no seu ambiente. A mensagem de erro dos registros não pode ser exibida. Caso contrário, encaminhe para a engenharia.
Estratégia de reversão:
Se as etapas da solução alternativa falharem ou se você notar alguma perda nas métricas, retorne o arquivo YAML de implantação alertmanager-servicenow-webhook ao estado original:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Fazer upgrade |
1.9.10 |
Sintomas:
O upgrade está parado na etapa NodeMaintain.
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
O nodeupgradetask do pool de nós em andamento mostra:
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
Alternativa:
Siga estas etapas:
- Consiga o nome da implantação do cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- Especifique o nome do cap-controller-manager (por exemplo: cap-controller-manager-1.28.0-gke.435):
export CAP_DEPLOYMENT_NAME=
- Reinicie o cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| Fazer upgrade |
1.9.10 |
Sintomas:
O upgrade está travado na etapa de verificação pós-voo AdminClusterHealth.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
O objeto da organização mostra:
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
Alternativa:
Siga estas etapas:
Use o comando a seguir para pular as verificações prévias:
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| Fazer upgrade |
1.9.9 |
Sintomas:
O NodeUpgradeTask pode ter a condição failed to monitor failover registry recreation: failed to monitor job: job not complete que impede a conclusão de uma tarefa.
Alternativa:
Para resolver o problema, reinicie o job:
- Exclua o job chamado
create-failover-registry-*** com conclusão "0/1".
- Exclua a anotação
failover-registry-creation-job-name do objeto do servidor que está sendo atualizado.
O controlador cria o job automaticamente de novo.
|
| Fazer upgrade |
1.9.20 |
Sintomas:
O nó falha no job backup-ipsec-for-upgrade-bm.
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
Alternativa:
Exclua o job `backup-ipsec-for-upgrade-bm` e aguarde a recriação dele.
|
| Google Distributed Cloud |
1.9.9 |
Sintomas:
Um pool de nós do plano de controle não fica pronto devido à falha na inicialização do cluster etcd. Você pode encontrar o seguinte problema:
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
Alternativa:
Para resolver o problema, siga estas etapas:
- Verifique se a criação do cluster está travada no job de inicialização da máquina.
A tarefa kubeadm join falhou devido a:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
A tarefa kubeadm reset falhou devido a:
panic: runtime error: invalid memory address or nil pointer dereference
- Use SSH para se conectar a um nó do painel de controle em funcionamento.
- Execute o comando
etcdctl para limpar os dados obsoletos.
- Verifique a assinatura do
etcd:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- Remova a assinatura obsoleta:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| Backup e restauração de VM |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
Sintomas:
O processo de backup e restauração de VMs não pode ser iniciado pelos usuários devido a
configurações inadequadas de controle de acesso baseado em papéis (RBAC) e de esquema no gerenciador de VMs.
Os nomes dos planos de backup de VM não podem ter mais de 63 caracteres.
Por exemplo, você pode ver esta mensagem de erro:
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
Alternativa:
Os nomes dos planos de backup de VM são uma concatenação do nome VirtualMachineBackupPlanTemplate, do tipo de recurso (que é vm ou vm-disk) e do nome desse recurso. Essa string concatenada precisa ter menos de 63 caracteres.
Para isso, mantenha os nomes desses recursos curtos ao criá-los. Para detalhes sobre a criação desses recursos, consulte Criar e iniciar uma instância de VM e Criar um plano de backup para VMs.
|
| Fazer upgrade |
1.9.9 |
Sintomas:
Um upgrade falha no job de backup ipsec com o seguinte erro de modelo:
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
Alternativa:
Siga estas etapas:
Faça login no nó em que a tarefa de upgrade falha. Salve o swanctl.conf como backup. Remova a linha com chaves no arquivo /etc/swanctl/swanctl.conf. Exclua o job backup-ipsec-for-upgrade com falha e aguarde a recriação. Depois, o job subsequente será concluído. Adicione a linha removida na etapa 3 de volta a /etc/swanctl/swanctl.conf.
|
| Plataforma do nó |
1.9.6
1.9.7
1.9.8
1.9.9 |
Quando um upgrade de firmware é iniciado no cluster de administrador raiz, depois que um dos
nós conclui o upgrade, ele parece estar travado.
Sintomas:
- O
nodeupgradetask está travado na
etapa NodeResumeCompleted.
- O job
machine-init falha, e o registro mostra que o
kubeadm join falhou.
- Não é possível estabelecer uma conexão SSH com o nó usando o endereço IP do plano de dados.
O problema é causado porque o nó atualizado não aceita mais o tráfego de rede de entrada.
Alternativa:
- Inspecione os registros de
job/nodeupgradetask com falha para anotar os
endereços IP e descobrir qual nó tem o problema.
- Reinicie o pod
anetd-client do nó afetado.
- Verifique a conexão SSH no IP do plano de dados com o nó afetado.
Etapas opcionais para investigação mais detalhada:
- Coloque um shell em um contêiner de agente do cilium de qualquer um dos pods anetd em funcionamento.
- Execute o cilium-bugtool e aguarde cerca de 10 segundos. A ferramenta salva
registros no diretório
/var/log/network/policy_action.log.
- Procure
deny para saber se o tráfego está sendo negado:
grep -r "deny" /var/log/network/ to
Observe quais servidores estão sendo negados, possivelmente os nós bare metal
do administrador raiz.
|
| Fazer upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomas:
- Um upgrade falha no complemento
atat-webhooks.
- Os rótulos expirados do complemento ATAT podem causar falhas nos upgrades da organização.
Exemplo:
Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16.
Alternativa:
Os usuários precisam atualizar os rótulos de complemento de ATAT do portfólio. Siga o runbook ATAT-R0003 para resolver o problema.
|
| Fazer upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomas:
- O upgrade do SO do nó em bare metal da organização do locatário falha ao fazer upgrade da versão 1.9.12 para a 1.9.13. A seguinte mensagem aparecerá:
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
Alternativa:
- Remova a anotação
cluster.private.gdc.goog/ssh-trusted-ca-versions no CR do administrador raiz e do administrador da organização.
- Exclua os jobs do Ansible com falha. Novos jobs são criados automaticamente porque a anotação
cluster.private.gdc.goog/host-key-rotation-in-progress
está marcada como "true" no CR do servidor.
- Após a rotação, a anotação
cluster.private.gdc.goog/ssh-trusted-ca-versions é adicionada de volta ao CR do servidor.
|
| Nó, upgrade |
1.9.* |
Sintomas:
Após o upgrade, os pods em alguns nós bare metal ficam travados no estado CrashLoopBackOff, e
iptables -L -v -n | grep CILIUM no nó retorna um resultado vazio.
Alternativa:
Para resolver o problema, siga estas etapas:
- Execute este comando:
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force.
- Execute
iptables -L -v -n | grep CILIUM novamente e verifique se há saída.
|
| Logging |
1.9.14
1.9.15 |
Sintomas:
O pod audit-logs-loki-0 está no estado CrashLoopBackOff.
Verifique o status do pod:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
em que SYSTEM_KUBECONFIG é o caminho para o arquivo kubeconfig.
O erro do Loki aparece na saída a seguir, em que CrashLoopBackOff é o status:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Alternativa:
Para resolver o problema, siga estas etapas:
- Exporte o caminho para o arquivo kubeconfig para uma variável de ambiente chamada
SYSTEM_KUBECONFIG.
- Reduza o operador Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Reduza a escala vertical dos recursos do Loki:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Exclua as reivindicações de volume permanente (PVCs)
audit-logs-loki-storage-audit-logs-loki-0 e loki-storage-loki-0.
- Exclua os volumes permanentes (PVs)
obs-system/loki-storage-loki-0 e obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Faça o escalonamento vertical do operador Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Siga as etapas para atualizar a configuração de geração de registros da versão 1.9.
- Verifique se o pod
audit-logs-loki-0 está em execução:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
O status Running precisa aparecer na saída, como no exemplo a seguir:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infraestrutura como código |
1.9.16 |
Sintomas:
Ao fazer upgrade para a versão 1.9.16, a instalação do complemento do GitLab falha. Você
pode encontrar um erro como este:
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
O pod do postgres, como gpc-system/gitlab-postgresql-0,
está em um estado de encerramento.
Alternativa:
- Exclua à força o pod do postgres que está travado em um estado de encerramento:
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Verifique se o pod do postgres é recriado após a exclusão.
|
| Gerenciamento de identidade e acesso |
1.9.19
1.9.20 |
Sintomas:
Ao fazer upgrade da versão 1.9.18 e tentar acessar o
console do GDC, talvez você veja a seguinte mensagem:
Authentication failed, please contact your system administrator
Alternativa:
- Acesse a CA necessária:
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Abra o arquivo de configuração do cliente para edição:
kubectl edit clientconfig -n kube-public default
- Localize o
certificateAuthorityData na configuração do cliente e atualize a CA necessária usando o seguinte caminho: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
