| Instalação |
1.9.0
1.9.1
1.9.2 |
O iLO não consegue obter ocasionalmente a chave do HSM
Sintomas:
`server.status.conditions` tem uma entrada com o tipo `KeyManagerConfigured` e o estado `True`, mas nenhuma com o tipo `DiskEncryptionEnabled`. Existem pods com falhas com o nome `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 usar o SSH no pod devido a uma chave inválida.
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
Aceda à IU do iLO > Informações > Diagnósticos > Repor para repor o iLO. Se, durante a reposição, o iLO apresentar que o servidor está no autoteste de arranque (POST), reinicie o fluxo de aprovisionamento:
Se a instalação do cluster de administrador tiver sido concluída:
export KUBECONFIG=<root-admin-kubeconfig path>
Atualize a chave SSH:
Obtenha a chave SSH pública atual (tenha em atenção que esta pode ter sido alterada e, por isso, 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
Add IRONIC_RAMDISK_SSH_KEY: \ Reiniciar ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Reaprovisione a máquina para reinstalar o IPA:
Faça uma cópia de segurança do bmc-credential-$SERVER, uma vez que a eliminação do bmh também elimina o segredo
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Remova do ficheiro atributos não aplicáveis, como: last-applied, creationtimestamp, finalizer, ownerreference, resourceversion e uid.
Elimine o BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Obtenha o segredo bmc-credentials-$SERVER ou a cópia de segurança anterior de cellcfg e aplique-o.
Dizer ao servidor para fazer algo diferente.
Para remover o estado de BMH em cache:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Aguarde até o servidor ser aprovisionado. Veja como os objetos do BMH são criados. Pode ter de eliminar tarefas de encriptação para as 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.
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
Verifique se a VM STATUS apresenta Provisioning ou Starting:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG é o caminho do ficheiro kubeconfig do cluster do sistema.
PROJECT é o projeto da GDC no qual a VM reside.
Opcional: obtenha detalhes adicionais do estado:
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.
Elimine a VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME é o nome do seu espaço de nomes.
Verifique se a eliminação foi bem-sucedida:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Um resultado semelhante ao seguinte confirma o êxito:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Elimine 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 certifique-se de que todos os discos estão listados. Verifique se a eliminaçã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 êxito:
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 executar novamente o comando, este é executado durante diferentes períodos e falha em diferentes pontos do processo, como o envio ou a reetiquetagem, mas com erros semelhantes.
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
Exporte o KUBECONFIG para o kubeconfig do administrador raiz:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Emita este comando para reduzir a escala de
deployment/root-admin-tftp-manager-controller para 0 réplicas:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Realize as operações que estavam a falhar.
- Aumente a escala de
deployment/root-admin-tftp-manager-controller para 1 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 executar novamente o comando, este é executado durante diferentes períodos e falha em diferentes pontos do processo, como o envio ou a reetiquetagem, mas com erros semelhantes.
Solução alternativa:
Ignorar a mensagem com segurança. Desaparece após algum tempo.
|
| Operações |
1.9.2 |
Solução alternativa:
Para resolver o problema, reinicie o pod que tem o problema.
|
| Operações |
1.9.0
1.9.1
1.9.2 |
Sintomas:
O estado da condição Server's Ready é "Falso" e a mensagem contém "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...". Os registos da tarefa com falha contêm "Failed to connect to the host via ssh ... Permission denied (publickey)."
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
Obtenha a chave SSH pública atual do cluster de administrador principal:
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 E adicione ou substitua a chave IRONIC_RAMDISK_SSH_KEY existente:
<SSH public key>
Reinicie a implementaçã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 |
Solução alternativa:
Para evitar o problema de escassez de endereços IP, defina o tamanho do CIDR do pod como /21 ou superior quando criar um cluster de utilizadores de alta disponibilidade.
|
| Instalação |
1.9.2 |
Solução alternativa:
Para resolver o problema, reinicie os pods.
Consulte o runbook MON-R0001 para ver detalhes.
|
| Autenticação da plataforma |
1.9.13 |
Sintomas:
Todos os trabalhos de cplb-init e storage-ipsec-config-bm-XXXXX apresentam a seguinte mensagem: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Solução alternativa:
1. Verifique se o BGP VRF está inativo em aggswitch.
2. Verifique se existem alterações não comprometidas para a nova configuração de preparação na firewall.
3. Limpe todos os securitypolicyrules que tinham a organização eliminada no nome e reinicie o root-admin-controller.
|
| Atualizar |
1.9.1
1.9.2
1.9.11 |
Sintomas:
Server está .status.bareMetalHostStatus.provisionState preso(a) em deprovisioning há mais de 20 minutos.
O endereço IP de gestão do servidor que está a ser atualizado está incluído no resultado 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
Solução alternativa:
Para resolver o problema, execute o seguinte comando:
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Atualizar |
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 atualização em NodeUpgrade permanece por concluir durante mais de 2 horas.
Uma NodeUpgradeTask correspondente fica pendente na condição NodeResumeCompleted durante mais de 1 hora.
bm-system-x.x.x.x-machine-init tarefas permanecem por concluir durante muito tempo. x.x.x.x é a morada do nó.
Solução alternativa:
Para encontrar o endereço de um nó não saudável, consulte o x.x.x.x do trabalho bm-system-x.x.x.x-machine-init pendente.
Para encontrar um nó do plano de controlo em bom estado para o nó em mau estado, siga estes passos:
- Encontre o nodepool do nó não saudável.
Verifique o conjunto de nós do plano de controlo no mesmo cluster desse nó não saudável e selecione um endereço do .spec.address desse conjunto de nós do plano de controlo.
No bootstrapper ou no 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 controlo saudável, 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
|
| Atualizar |
1.9.1
1.9.2 |
Sintomas:
O pod do operador de frota do ODS está em ciclo de falhas.
Para verificar o estado do pod, execute o seguinte comando:
ko get pods -n ods-fleet-operator
É apresentado um erro de eleição de líder semelhante ao seguinte nos registos 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 registos do ODS Fleet Operator, execute:
ko logs deployment/fleet-controller-manager -n ods-fleet-system
É apresentada a seguinte mensagem:
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.
Solução alternativa:
Para editar a implementação, execute o seguinte comando:
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
Certifique-se de que edita o campo resources do contentor manager da seguinte forma:
Antes:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Depois:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Atualizar |
1.9.2
1.9.3 |
Sintomas:
É apresentada a seguinte mensagem de erro:
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
Solução alternativa:
Para corrigir o problema, siga estes passos:
Inicie sessão em todos os nós de GPU aprovisionados:
# 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) ...
Elimine o pod kubevm-gpu-driver-daemonset bloqueado. Esta ação reinicia a instalação:
# kug get pods -A | grep gpu | grep Init
(Opcional) Se a instalação do suplemento excedeu o tempo limite, reinicie a instalação do suplemento:
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Atualizar |
1.9.10
1.9.11 |
Sintomas:
O gpcbackup-agent-0 mostra failed to stage volume: iSCSI login failed e não consegue ajustar o volume.
Verifique se o pod não está a conseguir associar o volume. Os exemplos seguintes usam o kubeconfig do cluster do sistema:
-
Descreva o pod:
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Se o pod estiver a falhar, é apresentado um resultado semelhante ao seguinte exemplo:
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ó para o qual o pod está a falhar:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Obtém um resultado semelhante ao seguinte 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]
-
Obtenha o pod netapp-trident no mesmo nó para o qual o pod gpcbackup-agent-0 falhou:
kos get pod -o wide -n netapp-trident
Obtém um resultado semelhante ao seguinte exemplo:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Verifique os registos do pod netapp-trident no mesmo nó para o qual o pod gpcbackup-agent-0 falhou:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Obtém um resultado semelhante ao seguinte 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
Solução alternativa:
Para resolver o problema, siga estes passos:
-
Obtenha o nome do InventoryMachine:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Confirme que o emprego 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}"
Obtém um resultado semelhante ao seguinte:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Elimine a tarefa:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Obtém um resultado semelhante ao seguinte:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Confirme que o StorageEncryptionConnection existe:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Obtém um resultado semelhante ao seguinte:
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
-
Elimine o StorageEncryptionConnection:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Obtém um resultado semelhante ao seguinte:
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 que a nova tarefa foi recriada e executada com êxito:
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Obtém um resultado semelhante ao seguinte:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Atualizar |
1.9.10
1.9.11 |
Sintomas:
Um pod de registo do Harbor apresenta uma mensagem de erro semelhante à seguinte:
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
Solução alternativa:
Para resolver o problema, siga estes passos:
-
Verifique a reivindicação de volume persistente (PVC) do registo do Harbor e tome nota do nome do volume da PVC:
kubectl get pvc harbor-registry -n harbor-system
-
Para verificar se a associação de volume está no mesmo nó do pod de registo do Harbor, liste os volumeattachment e encontre o associado ao nome do volume:
kubectl get volumeattachment | grep [volume-name]
-
Se a associação de volume estiver num nó diferente do pod de registo do Harbor, remova o volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Reinicie o pod do registo do Harbor.
Agora, o registo do Harbor no cluster de administrador raiz tem de estar em bom estado e a atualização do nó é concluída com êxito.
|
| Instalação |
1.9.2
1.9.3
1.9.4
1.9.5
|
Sintomas:
É apresentada a seguinte mensagem de erro:
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Um registo de pod contém o seguinte:
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
A versão do CoreDNS é 1.8.6.
Solução alternativa:
Para resolver o problema, reinicie a implementação do coredns.
Assim que o KUBECONFIG estiver definido para o cluster correto, execute o seguinte comando:
kubectl rollout restart deployment coredns -n kube-system
O nome do cluster de utilizadores faz parte da mensagem de erro.
Para encontrar o ficheiro kubeconfig em /root/release/user/, encontre os kubeconfigs: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
Se faltarem ficheiros kubeconfig, gere-os da seguinte forma:
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
|
| Atualizar |
1.9.2
1.9.3 |
Sintomas:
É apresentada a seguinte mensagem de erro:
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]]
Normalmente, este problema é temporário e deve ficar resolvido.
|
| Instalação |
1.9.3 |
A instalação de um suplemento 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.
Solução alternativa:
A instalação do suplemento pode falhar devido ao facto de os nós estarem no estado NotReady. Verifique se os nós estão no estado NotReady através do seguinte comando:
kubectl get nodes
Obtenha detalhes do nó que se encontra no estado NotReady:
$ kubectl describe node | grep PodCIDRs
Para um cluster com este problema, um nó não tem PodCIDRs atribuídos, 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 implementação ipam-controller no cluster afetado:
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Atualizar |
1.9.3 |
Uma atualização 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.
Solução alternativa:
Atualize manualmente o campo abm-overrides's do AddOnSet <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> para o nome do AddOnSetTemplate da versão pretendida no mesmo espaço de nomes que o cluster a ser atualizado.</code.spec.addonsettemplateref<>
|
| Instalação |
1.9.3 |
Sintomas:
Um controlador de administrador da frota não fica pronto, o que faz com que o teste TestCreateFleetAdminCluster ou TestSimOverlayCreateFleetAdminCluster falhe. O controlador do administrador da frota está bloqueado num ciclo de falhas. O seguinte erro encontra-se nos registos do controlador de administração da frota: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Solução alternativa:
Implemente o LogmonCRD no cluster de administrador da organização. Reinicie o controlador de administração da frota.
|
| Instalação |
1.9.3 |
Sintomas:
É apresentada a seguinte mensagem de erro:
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] [...]
Solução alternativa:
Para resolver o problema, reinicie a implementaçã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
Nota: execute o seguinte comando antes de reiniciar a implementação e o daemonset para apontar para o cluster correto:
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Atualizar |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Sintomas:
Não é possível agendar um pod devido a CPU insuficiente.
Solução alternativa:
Para um cluster de utilizadores existente criado com n2-standard-4 nós de trabalho, adicione um novo NodePool n2-standard-8 com três nós a este cluster antes da atualização. Para novos clusters de utilizadores, crie-os com um n2-standard-8 NodePool com o mínimo de três nós. Consulte o artigo Crie um cluster de utilizadores para cargas de trabalho de contentores para ver 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. Isto
afeta dois tipos de máquinas, conforme indicado na solução alternativa. Os outros tipos de máquinas não são afetados e não precisam de uma solução alternativa.
Solução alternativa:
- Quando cria clusters de utilizadores que usam GPUs 40G A100, selecione sempre o tipo de máquina a2-highgpu-1g-gdc na IU.
- Quando criar clusters de utilizadores que usam GPUs A100 80G, selecione sempre o tipo de máquina a2-ultragpu-1g-gdc na IU.
|
| 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 superiores a 32 GB,
a instância de VM pode parecer estar em execução, parar e voltar a ser executada; possivelmente, repetindo
esta sequência. Eventualmente, é gerado um erro OOMKilled de falta de memória e a instância falha.
Seguem-se os três tipos de VMs 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
Solução alternativa:
- Valide 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 qualquer um dos três tipos indicados
edite o
configmap para incluir uma substituição de memória:
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Adicione uma secção
memory.guest e resources.overcommitGuestOverhead
, como pode ver no exemplo seguinte:
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, altere 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 este processo para todas as VMs afetadas.
|
| Atualizar |
1.9.4 |
Sintomas:
Uma tarefa bm-system-* fica bloqueada no passo Gathering Facts. Quando tenta executar o SSH manualmente no servidor, é apresentado o erro PTY allocation request failed on channel 0.
Solução alternativa:
Reinicie o servidor através de uma das seguintes 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
IU do iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Atualizar |
1.9.4
1.9.10 |
Sintomas:
Uma atualização falha devido à falha da tarefa backup-ipsec-*.
Solução alternativa:
Siga os passos seguintes:
Encontre as chaves pré-partilhadas no espaço de nomes gpc-system no cluster de administração da organização. As chaves têm o nome <node-name>-pre-shared-key.
Para obter o hash da chave do YAML da chave pré-partilhada 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 }'.
Tenha em atenção que tem de obter o hash da chave de um nó que não seja o nó onde a atualização do IPsec falhou. Aplique o hash desta chave pré-partilhada ao segredo da chave pré-partilhada do nó com falhas no gpc-system no cluster de administrador da organização. Elimine o objeto storageencryptionconnection que tem o mesmo nome que o nó com falhas no cluster de administrador raiz. Elimine a tarefa storage-ipsec-config-<node-name> associada no cluster de administrador da organização. Elimine a tarefa de atualização backup-ipsec-for-upgrade-<node-name> associada.
|
| Atualizar |
1.9.4 |
Sintomas:
A atualização dos clusters da organização demora muito tempo.
Solução alternativa:
Aguarde que o ClamAV seja encerrado naturalmente.
|
| Atualizar |
1.9.5 |
Sintomas:
São apresentados diferentes certificados:
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-----
Solução alternativa:
Nota: rode o certificado harbor-harbor-https antes de seguir os passos abaixo.
Siga os passos seguintes:
Existem cópias dos dados do certificado armazenadas em segredos no cluster. Após rodar o certificado harbor-harbor-https, também tem de atualizar as cópias secretas.
- Obtenha 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 do segredo do certificado do Artifact Registry em cada espaço de nomes.
Obtenha 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 segredo do certificado do Artifact Registry em cada espaço de nomes.
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 tem de atualizar uma cópia secreta do certificado com um nome fixo denominada
ca-cert-in-cluster-registry no espaço de nomes 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 espaço de nomes 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 estiver a rodar certificados para o cluster org-admin, também tem de atualizar as cópias secretas dos certificados existentes no cluster root-admin.
Obtenha todos os espaços de nomes 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 segredo do certificado do Artifact Registry em cada espaço de nomes.
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 .
|
| Atualizar |
1.10.0
1.10.1 |
Sintomas:
Depois de iniciar um OrganizationUpgrade, o pod kube-apiserver não está a ser executado num ou mais nós.
- Identifique o nó onde a atualização está bloqueada:
kubectl get po -n kube-system -l component=kube-apiserver
O resultado tem o seguinte aspeto:
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 ligação SSH ao nó que acabou de ser atualizado:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
O estado do contentor é apresentado 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 registos do pod
Exited:
crictl logs f1771b8aad929
O resultado tem o seguinte aspeto:
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
O sinalizador está configurado no ficheiro /etc/kubernetes/manifests/kube-apiserver.yaml:
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Solução alternativa:
Remova a flag do ficheiro /etc/kubernetes/manifests/kube-apiserver.yaml.
- Faça uma cópia de segurança do ficheiro:
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 que a linha é removida:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Indique o contentor
kube-apiserver:
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
O kubelet deteta automaticamente a alteração e inicia o
pod kube-apiserver:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Repita estes passos para todos os nós afetados.
|
| Atualizar |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Sintomas:
A implementação do kube-state-metrics entra em ciclos de falhas numa organização após a rotação de certificados. Este problema pode causar uma perda de
dados de monitorização.
|
| Atualizar |
1.9.6 |
Sintomas:
Após a atualização, o nó de trabalho está desequilibrado.
Solução alternativa:
Equilibre manualmente o nó trabalhador:
- Para uma carga de trabalho de pods, elimine os pods na implementação.
- Para uma carga de trabalho de VM, elimine o virt-launcher sem modificar o objeto GVM do plano de controlo.
|
| Atualizar |
1.9.6 |
Quando atualiza da versão 1.9.5 para a 1.9.6, existe a possibilidade de o plug-in do dispositivo GPU não poder ser iniciado.
Sintomas:
Pode ver o seguinte erro que bloqueia a disponibilidade do tempo de execução da VM
e o processo de atualização:
Failed to initialize NVML: could not load NVML library
Solução alternativa:
- Verifique se o
nvidia-container-runtime está corretamente
configurado no nó:
- Estabeleça uma ligação SSH ao nó que suspeita ter um problema.
- Obtenha a lista de pods:
crictl pods
- Inspeção dos pods:
crictl inspectp $pod_hash | grep runtimeOption -A1
Se o resultado for semelhante a este, o nó está configurado corretamente. Se o resultado não for semelhante ao seguinte, significa que o nvidia-container-runtime
não está 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
|
| Atualizar |
1.9.7 |
Quando atualiza para a versão 1.9.7, o firmware do node pool do cluster de administrador raiz permanece no estado in process.
Sintomas:
- Para o lado
NodeUpgrade, consulte a solução alternativa Tempo limite do servidor de artefactos:
NodeUpgrade está bloqueado no estado in process e a condição para NodeROMFirmwareUpgradeCompleted no estado Nodeupgradetask nunca é concluída.- O URL em
spec.firmware.firmwarePackages.url no objeto NodeUpgrade pode ficar bloqueado quando estiver a ser associado, 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 artefactos não autorizado:
- No registo do servidor de artefactos, pode ser apresentado um erro relacionado com o acesso não autorizado a um repositório:
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 tem de ter Spec.harborProjectConfig.accessLevel como private:
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Solução alternativa:
|
| Redes inferiores |
1.9.0 - 1.9.6 |
Sintomas:
As sessões de BGP estão inativas na rede interna de uma organização. Apenas um dos pontos finais de peering BGP internos da organização é adicionado aos objetos TORSwitchInternal.
Solução alternativa:
Altere explicitamente a sub-rede usada no {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim para não se sobrepor aos recursos AddressPoolClaim análogos de nenhuma outra organização.
- Investigue os sintomas:
- Para cada cluster do sistema de 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 utilização posterior.
- Determine se
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" é a causa principal:
- 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
- Pesquise o campo
ClusterIP do resultado (3.ª coluna) para encontrar o LocalIPs indicado no passo 1.b. Anote os LocalIPs que correspondem às entradas na 3.ª coluna do resultado para mais tarde. Se existirem vários clusters de administrador da organização distintos, em que o resultado do passo 2.a contém os LocalIPs indicados no passo 1.b, avance para o passo 3.
- Resolva IPs sobrepostos usados para clusters de sistemas da organização.
- Corrida:
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 devolvidos da consulta em 3.a. Este valor tem de ser igual ao número de organizações ativas.
- Para cada linha, anote o espaço de nomes (coluna 1) e o bloco CIDR (coluna 3). O bloco CIDR de cada linha deve ser igual ao bloco CIDR de todas as outras linhas.
- Para cada organização, siga estes passos:
- Navegue para o objeto
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim no cluster de administração da organização dessa organização.
- Calcular o
Start IP da reivindicação do conjunto de endereços de nós de trabalho dessa organização. Para o fazer, use o bloco CIDR de 3.c e o campo Size no AddressPoolClaim de 3.d.i. Começando no penúltimo IP no bloco CIDR, conte para baixo Size IPs. Este é o novo Start IP para a primeira organização (usado no passo 3.d.iii). Para cada organização adicional, a contagem regressiva é de Size IP segundos, começando no novo Start IP da organização anterior.
Por 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 do passo 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 tem de ter o seguinte aspeto se usar org-1 do ponto 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: ...
...
- Limpe para evitar sessões de BGP desnecessárias no hardware TORSwitch.
- Para apresentar uma lista de todos os recursos do
TORSwitchInternal que precisam de atualização, execute o seguinte comando:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Para cada um dos
TORSwitchInternals apresentados no resultado 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 tenham NeighborIPs iguais a qualquer um dos LocalIPs do passo 2.b. Por exemplo, LocalIP de 2.2.2.2 foi registado no passo 2.b. Segue-se um exemplo TORSwitchInternal antes e depois do passo 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. Tenha em atenção 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:
...
- Valide executando o passo 1 e confirmando que todos os
BGPSession objetos States regressaram a Established. A propagação de todas as modificações às configurações físicas do GDC TORSwitch pode demorar cerca de 10 minutos.
|
| Atualizar |
1.9.7 - 1.9.21 |
Durante uma atualização, existe a possibilidade de a atualização do nó e do sistema operativo não progredir.
Sintomas:
Pode ver um nó com o estado Ready, SchedulingDisabled durante 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
Solução alternativa:
- Siga o runbook PLATAUTH-SSH 0001 para obter a chave SSH do nó em questão. Depois de se ligar ao nó com SSH, execute o seguinte comando:
multipath -ll | grep fail
- Só avance para o passo seguinte se o resultado for semelhante ao seguinte:
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
|
| Atualizar |
1.9.8-1.9.21 |
Sintomas:
Se uma atualização do cluster ABM estiver bloqueada durante mais de 2 horas, a drenagem de nós pode estar bloqueada.
Solução alternativa:
As seguintes operações usam o cluster de administrador raiz como exemplo. ${TARGET_KUBECONFIG} refere-se ao `kubeconfig` do cluster do ABM de destino cuja drenagem de nós está bloqueada. ${KUBECONFIG} refere-se ao kubeconfig do cluster que gere o cluster do ABM de destino. Para o cluster de administrador raiz, ambos se referem ao kubeconfig de administrador raiz.
Conclua os passos seguintes para ver se a atualização do cluster do ABM está bloqueada:
- Verifique os nós bloqueados na drenagem:
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
O resultado é o seguinte:
{"10.200.0.2": 2}
Isto significa que, para o nó "10.200.0.2", estão a ser esvaziados dois pods.
- Verifique se os pods continuam a ser esvaziados do nó (referido como
${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 tem de ser igual ao número de pods que estão a ser esvaziados, comunicado no passo anterior.
Para cada agrupamento yetToDrain, conforme indicado no passo 1, verifique o estado do agrupamento:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Se o pod estiver no estado Running ou se o pod estiver audit-logs-loki-0 ou loki-0 no espaço de nomes obs-system e o pod não tiver nenhum evento a reclamar unable to unmount volume, elimine explicitamente o pod com um grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Para todos os outros casos em que um pod esteja bloqueado no processo de esgotamento, encaminhe o problema para os serviços de chamada.
- Monitorize se a drenagem do nó está concluída.
- Repita o passo um se outros nós estiverem bloqueados na drenagem.
|
| Atualizar |
1.9.6
1.9.7
1.9.8
|
Não é possível distribuir as versões 1.9 com artefactos assinados porque a flag Override em DistributionPolicy está definida como false, o que impede a distribuição quando existe um artefacto com o mesmo nome no registo de destino.
Sintomas:
Pode deparar-se com os seguintes problemas:
- O artefacto com assinatura é enviado. O registo pode ter o seguinte aspeto:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Falha ao enviar o artefacto. O registo pode ter o seguinte aspeto:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- O artefato 404 não foi encontrado. O registo pode ter o seguinte aspeto:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- A distribuição de artefactos falha.
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
- Atualize o recurso personalizado (CR)
DistributionPolicy para
definir o Spec.Override como true.
- Volte a acionar uma replicação seguindo o manual de procedimentos SAR-1005.
- Depois de a nova execução da replicação ser bem-sucedida, atualize o
ManualDistribution CR execution-ids em
Annotation com o ID de execução bem-sucedido.
|
| Módulo de segurança de hardware (HSM) |
1.9.9 |
Os HSMs podem comunicar intermitentemente ServicesNotStarted, o que pode fazer com que os servidores bare metal não fiquem em bom estado e comuniquem a seguinte mensagem:
"message": "failed to get master key name"
Sintomas:
Pode deparar-se com os seguintes problemas:
Solução alternativa:
Para resolver o problema, siga os passos abaixo para reiniciar os HSMs bloqueados:
- Instale a ferramenta
kstl a partir 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á a ter problemas ao reiniciar. Para cada HSM bloqueado
em
ServicesNotStarted, obtenha o
$HSM_MGMT_IP e verifique se o serviço está em baixo:
ksctl services status --url=https://$HSM_MGMT_IP
- Pause todos os HSMs, clusters de HSMs e inquilinos de HSMs:
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 ligação SSH ao HSM com o serviço inativo:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Certifique-se de que está no HSM correto. Verifique se estabeleceu uma ligação SSH com o
$HSM_MGMT_IP correto.
- Reinicie o primeiro HSM a partir do interior do HSM:
ksadmin@ciphertrust:~ sudo reboot
- Aguarde que o primeiro HSM fique em bom estado a partir do exterior do HSM:
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Este passo pode demorar cerca de cinco minutos para que os HSMs sejam reiniciados.
- Repita estes passos para os outros HSMs que têm serviços em baixo.
- Retome os HSMs, os clusters de HSMs e os inquilinos de HSMs:
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 é reconciliado. A reconciliação dos HSMs pode demorar entre cinco e dez minutos.
|
| Monitorização |
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 do 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 registos contêm a mensagem de erro read: connection reset by peer. Este problema deve-se a uma etiqueta em falta para ativar o tráfego de saída. Se o webhook precisar de comunicar entre organizações, tem de usar o NAT de saída.
Solução alternativa:
Tem de ativar o tráfego de saída para o alertmanager-servicenow-webhook em clusters de sistemas da organização. Para resolver o problema, siga os passos abaixo:
- Defina os pré-requisitos necessários:
- Instale a interface de linhas de comando (CLI) gdcloud.
- Obtenha os caminhos para os ficheiros kubeconfig dos clusters de administrador principal e administrador da organização. Guarde os caminhos nas variáveis de ambiente
ROOT_KUBECONFIG e ORG_SYSTEM_KUBECONFIG, respetivamente.
- Peça ao administrador de segurança para lhe conceder a função de administrador de observabilidade (
observability-admin) no espaço de nomes obs-system para os clusters de administrador principal e administrador da organização.
- Confirme se o problema existe no seu ambiente:
- Obtenha a implementação do
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Veja os registos da implementação
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Se os registos contiverem a mensagem de erro read: connection reset by peer, o problema existe e tem de continuar com os passos desta solução alternativa.
- Adicione a etiqueta de saída:
- Obtenha o ficheiro YAML de implementaçã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 a etiqueta de saída ao ficheiro YAML de implementaçã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 ficheiro YAML de implementaçã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 implementação tem de ser reiniciada automaticamente.
- Valide se o problema está corrigido executando novamente os passos Confirme se o problema existe no seu ambiente. A mensagem de erro dos registos não deve ser apresentada. Caso contrário, encaminhe a situação para a equipa de engenharia.
Estratégia de reversão:
Se os passos da solução alternativa falharem ou se verificar alguma perda nas métricas, devolva o ficheiro YAML de implementação alertmanager-servicenow-webhook ao estado original:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Atualizar |
1.9.10 |
Sintomas:
A atualização está bloqueada no passo 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 conjunto de nós em curso 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
Solução alternativa:
Siga os passos seguintes:
- Obtenha o nome da implementaçã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 de 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
|
| Atualizar |
1.9.10 |
Sintomas:
A atualização está bloqueada no passo 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
Solução alternativa:
Siga os passos seguintes:
Use o seguinte comando para ignorar 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
|
| Atualizar |
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.
Solução alternativa:
Para resolver o problema, reinicie a tarefa:
- Elimine a tarefa denominada
create-failover-registry-*** que tem "0/1" de conclusão.
- Elimine a anotação
failover-registry-creation-job-name do objeto Server que está a ser atualizado.
O controlador cria automaticamente a tarefa novamente.
|
| Atualizar |
1.9.20 |
Sintomas:
O nó falha na tarefa 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
"
Solução alternativa:
Elimine a tarefa `backup-ipsec-for-upgrade-bm` e aguarde que seja recriada.
|
| Google Distributed Cloud |
1.9.9 |
Sintomas:
Um conjunto de nós do plano de controlo não fica pronto devido à falha de início do cluster etcd. Pode deparar-se com 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
Solução alternativa:
Para resolver o problema, siga os passos abaixo:
- Verifique se a criação do cluster está bloqueada na tarefa de inicialização da máquina.
A tarefa kubeadm join falhou devido ao seguinte:
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 ao seguinte:
panic: runtime error: invalid memory address or nil pointer dereference
- Use SSH para estabelecer ligação a um nó do painel de controlo funcional.
- Execute o comando
etcdctl para limpar os dados obsoletos.
- Verifique a subscrição 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 subscrição 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
|
| Cópia de segurança e restauro de VMs |
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:
Os utilizadores não podem iniciar o processo de cópia de segurança e restauro de VMs devido a
definições de controlo de acesso baseado em funções (RBAC) e de esquema incorretas no gestor de VMs.
Os nomes dos planos de cópia de segurança de VMs não podem ter mais de 63 carateres.
Por exemplo, 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
Solução alternativa:
Os nomes dos planos de cópia de segurança de VMs são uma concatenação do nome VirtualMachineBackupPlanTemplate, do tipo de recurso (que é vm ou vm-disk) e do nome desse recurso. Esta string concatenada tem de ter menos de 63 carateres.
Para o fazer, mantenha os nomes destes recursos curtos quando os criar. Para ver detalhes sobre a criação destes recursos, consulte os artigos Crie e inicie uma instância de VM e Crie um plano de cópia de segurança para VMs.
|
| Atualizar |
1.9.9 |
Sintomas:
Uma atualização falha na tarefa de cópia de segurança 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
Solução alternativa:
Siga os passos seguintes:
Inicie sessão no nó em que a tarefa de atualização falha. Guarde o swanctl.conf como uma cópia de segurança. Remova a linha com chavetas no ficheiro /etc/swanctl/swanctl.conf. Elimine a tarefa com falhas backup-ipsec-for-upgrade e aguarde a sua recriação. Em seguida, a tarefa subsequente é concluída com êxito. Adicione novamente a linha removida no passo 3 a /etc/swanctl/swanctl.conf.
|
| Plataforma do nó |
1.9.6
1.9.7
1.9.8
1.9.9 |
Quando uma atualização de firmware é iniciada no cluster de administrador principal, depois de um dos nós concluir a atualização do nó, parece que fica bloqueado.
Sintomas:
- O
nodeupgradetask está bloqueado na fase NodeResumeCompleted.
- A tarefa
machine-init falha e o registo mostra que a tarefa kubeadm join falhou.
- Não pode estabelecer uma ligação SSH ao nó através do endereço IP do plano de dados.
O problema é causado pelo facto de o nó atualizado deixar de aceitar tráfego de rede de entrada.
Solução alternativa:
- Inspeccione os registos de
job/nodeupgradetask com falhas para anotar os
endereços IP e descobrir que nó tem o problema.
- Reinicie o pod do nó afetado.
anetd-client
- Valide a ligação SSH no IP do plano de dados ao nó afetado.
Passos opcionais para uma investigação mais detalhada:
- Aceda a um contentor de agente do Cilium de qualquer um dos pods anetd em funcionamento.
- Execute o comando cilium-bugtool e aguarde cerca de 10 segundos. A ferramenta guarda os registos no diretório
/var/log/network/policy_action.log.
- Procure
deny para ver se o tráfego está a ser recusado:
grep -r "deny" /var/log/network/ to
Tenha em atenção os servidores que estão a ser recusados, possivelmente os nós de metal puro do administrador principal.
|
| Atualizar |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomas:
- Uma atualização falha no suplemento
atat-webhooks.
- As etiquetas de suplementos da ATAT expiradas podem fazer com que as atualizações da organização falhem.
Por 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.
Solução alternativa:
Os utilizadores têm de atualizar as etiquetas do suplemento ATAT do portefólio. Siga o runbook ATAT-R0003 para resolver o problema.
|
| Atualizar |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomas:
- A atualização do SO do nó no metal em modo nativo da organização de inquilinos falha ao atualizar da versão 1.9.12 para a 1.9.13. É apresentada a seguinte mensagem:
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"
}
} ]
Solução alternativa:
- Remova a anotação
cluster.private.gdc.goog/ssh-trusted-ca-versions no CR do servidor de administrador de raiz e administrador da organização.
- Elimine as tarefas do Ansible com falhas. As novas tarefas são criadas automaticamente porque a anotação
cluster.private.gdc.goog/host-key-rotation-in-progress
está marcada como verdadeira no CR do servidor.
- Após a rotação, a anotação
cluster.private.gdc.goog/ssh-trusted-ca-versions é novamente adicionada ao CR do servidor.
|
| Nó, atualização |
1.9.* |
Sintomas:
Após a atualização, os pods em alguns nós bare metal ficam bloqueados no estado CrashLoopBackOff e
iptables -L -v -n | grep CILIUM no nó devolve um resultado vazio.
Solução alternativa:
Para resolver o problema, conclua os seguintes passos:
- Execute o seguinte 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 existe uma saída.
|
| Registo |
1.9.14
1.9.15 |
Sintomas:
O agrupamento audit-logs-loki-0 está no estado CrashLoopBackOff.
Valide o estado do pod:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Em que SYSTEM_KUBECONFIG é o caminho para o ficheiro kubeconfig.
O erro do Loki é apresentado no seguinte resultado, em que CrashLoopBackOff é o estado:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Solução alternativa:
Para resolver o problema, conclua os seguintes passos:
- Exporte o caminho para o ficheiro kubeconfig para uma variável de ambiente denominada
SYSTEM_KUBECONFIG.
- Reduza a escala do operador Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Reduza os recursos do Loki:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Elimine as reivindicações de volume persistente (PVC)
audit-logs-loki-storage-audit-logs-loki-0 e loki-storage-loki-0.
- Elimine os volumes persistentes (PV)
obs-system/loki-storage-loki-0 e obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Aumente a escala do operador Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Siga os passos para atualizar a configuração de registo a partir 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 estado Running tem de ser apresentado no resultado, como no exemplo seguinte:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infraestrutura como código |
1.9.16 |
Sintomas:
Quando atualiza para a versão 1.9.16, a instalação do suplemento do Gitlab falha. Pode
ver 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 postgres, como gpc-system/gitlab-postgresql-0,
está num estado de terminação.
Solução alternativa:
- Elimine à força o pod postgres que está bloqueado num estado de encerramento:
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Certifique-se de que o pod postgres é recriado após a eliminação.
|
| Gestão de identidade e de acesso |
1.9.19
1.9.20 |
Sintomas:
Quando atualiza a partir da versão 1.9.18 e tenta aceder à consola GDC, pode ver a seguinte mensagem:
Authentication failed, please contact your system administrator
Solução alternativa:
- Obtenha o CA necessário:
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Abra o ficheiro de configuração do cliente para edição:
kubectl edit clientconfig -n kube-public default
- Localize o elemento
certificateAuthorityData na configuração do cliente e atualize a AC necessária através do seguinte caminho: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
