Problemas conhecidos do Google Distributed Cloud air-gapped 1.12.x
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O cluster de armazenamento para a cópia de segurança do volume usa o servidor DNS externo
em vez do encaminhador, o que impede que a cópia de segurança do volume resolva os pontos finais de armazenamento de objetos ao nível da organização. Na versão 1.12, o tráfego de cópia de segurança requer
novos trajetos para cada organização.
Solução alternativa:
Os IOs têm de atualizar o cluster de armazenamento para ativar a resolução DNS ao nível da organização e criar uma rota a partir das interfaces lógicas (LIFs) de replicação para os pontos finais de armazenamento de objetos em cada organização. Copie e cole os seguintes comandos do programa de arranque.
A obtenção do gateway de entrada do administrador da organização a partir de nós do ONTAP falha porque não existe um caminho da sub-rede de cópia de segurança para os planos de controlo da organização.
Solução alternativa:
Os IOs têm de atualizar o cluster de armazenamento para ativar a resolução DNS ao nível da organização e criar uma rota a partir das interfaces lógicas (LIFs) de replicação para os pontos finais de armazenamento de objetos em cada organização. Copie e cole os seguintes comandos do programa de arranque.
Se o repositório de cópias de segurança não tiver nenhum tipo de estado de erro, mas for gerado um alerta para o mesmo, a métrica de alerta para o repositório pode ser gerada por engano. Este é um problema conhecido na versão 1.12.0 e foi corrigido na versão 1.12.4. A causa deste problema é que o repositório de cópias de segurança
tenta periodicamente estabelecer ligação ao armazenamento de objetos como uma verificação do estado,
e entra num estado não saudável se não conseguir estabelecer ligação. No entanto, se o repositório de cópia de segurança for recuperado, a métrica que indica o respetivo estado não é revertida corretamente, o que faz com que o alerta permaneça num estado de acionamento indefinido.
Para resolver este problema, pode eliminar e recriar manualmente o repositório de cópias de segurança para repor a respetiva métrica de estado. Siga os passos no runbook
BACK-R0003 para recriar o repositório de cópias de segurança.
Mensagem de erro: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
O subcomponente bil-storage-system-cluster não é reconciliado devido a tarefas desatualizadas. Os billing-storage-system-init-job-628 e billing-storage-system-init-job-629 permanecem após a conclusão com êxito.
Solução alternativa:
Conclua os seguintes passos:
Faça cópias de segurança das tarefas de faturação desatualizadas:
Os pods do Grafana nos espaços de nomes anthos-identity-service-obs-system e platform-obs-obs-system estão bloqueados no estado Init devido a erros de montagem de volume. A mensagem de erro nos registos do kubelet indica um problema de multi-attach. O problema tem origem num erro no Trident, em que não identifica nem valida corretamente o dispositivo subjacente para mapeamentos LUKS, o que leva a um erro de ligação múltipla.
Solução alternativa:
Verifique se o PVC tem um deletionTimestamp. Se não existir deletionTimestamp (migração de pods), siga estes passos:
Verifique o VolumeAttachment do PVC para identificar onde o volume está atualmente associado.
Isolar os Nodes no cluster que não correspondem a este valor.
Elimine o Pod com falhas. Isto deve fazer com que seja migrado novamente para o Node original.
Após a verificação, se existir um deletionTimestamp (eliminação de volume), siga estes passos:
Verifique o VolumeAttachment do PVC para identificar onde o volume está atualmente associado.
No Node, apresente o conteúdo do respetivo ficheiro de acompanhamento:
cat/var/lib/trident/tracking/PVC_NAME.json
Valide se o dispositivo LUKS encontrado no campo devicePath do resultado do ficheiro de acompanhamento está efetivamente fechado. Este caminho não deve existir neste ponto:
statDEVICE_PATH
Valide se o número de série está atualmente mapeado para algum dispositivo de vários caminhos.
Copie o valor no campo iscsiLunSerial do ficheiro de acompanhamento.
Converta este valor no valor hexadecimal esperado:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Com este novo valor, verifique se a entrada de vários caminhos ainda existe:
multipath-ll|grepSERIAL_HEX
Se não existir, elimine o ficheiro de acompanhamento.
Se existir, é apresentado um valor hexadecimal ligeiramente mais longo do que o pesquisado, denominado multipathSerial. Execute o seguinte e encontre os dispositivos de bloqueio:
multipath-llMULTIPATH_SERIAL
Em seguida, execute os seguintes comandos, sendo que o último é executado exclusivamente para cada dispositivo de blocos:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
A saída mostra um resultado não vazio.
Solução alternativa:
Ative ou desative a autorização de /etc/kubernetes/pki/etcd/ca.crt. Esta é uma operação muito
sensível ao tempo. A mudança de autorização tem de ocorrer após a execução anterior da tarefa machine-init, mas antes da execução seguinte da tarefa machine-init, uma vez que machine-init substitui a autorização de volta para a raiz.
Reinicie o etcd no segundo nó para recuperar o etcd no primeiro nó do ciclo de falhas.
Depois de concluir estes dois passos, o kube-apiserver no primeiro nó começa a ser executado e a tarefa machine-init seguinte é bem-sucedida.
Depois de concluir a configuração da exportação para um sistema SIEM externo, a entrada SIEM não é incluída no pipeline de processamento do Fluent Bit e os registos do servidor da API Kubernetes não estão presentes neste SIEM.
Quando atualiza da versão 1.12.2 para a 1.12.4, se um nó for removido e, posteriormente, adicionado novamente, o processo machine-init desse nó pode falhar.
Esta falha ocorre porque o tráfego de rede do nó adicionado novamente para os serviços essenciais do plano de controlo é recusado pela política ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes.
Este erro é realçado pelas mensagens de estado neste exemplo de resultado:
Obtenha CIDRs de CIDRClaim/org-external-cidr -n root (especificamente o campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Execute o seguinte comando no cluster de administrador raiz:
Adicione estes CIDRs ao ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, especificamente ao campo .spec.ingress.fromCIDR. Aplique esta alteração no cluster de administrador raiz com o comando:
Obtenha CIDRs para a organização (por exemplo, org-1) de CIDRClaim/org-external-cidr -n org-1 (especificamente, o campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Este comando é executado no cluster de administrador raiz para obter os CIDRs de "org-1":
Adicione estes CIDRs ao ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, especificamente ao campo .spec.ingress.fromCIDR. Aplique esta alteração no cluster de administração da organização respetivo com o comando:
Num nó bare metal do cluster do sistema, não é possível terminar dois contentores anetd. Depois de parar o processo à força, reiniciar o kubelet e o containerd, o pod anetd é recriado, mas todos os contentores ficam bloqueados em podInit e o containerd apresenta a mensagem de erro:
Isto impede o início da interface de rede de contentores (CNI) e impede o agendamento de outros pods.
Solução alternativa:
Realize estas mitigações para evitar este estado do nó:
Não agende mais de 10 PVCs de cada vez num único nó. Aguarde que sejam montados antes de agendar mais. Isto era mais percetível quando tentava criar VMs.
Atualize o ficheiro /etc/lvm/lvm.conf em todos os nós para incluir a linha: filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] no bloco devices{}
Se o nó entrar num estado em que apresenta tempos limite para anexos e montagens de volumes, ou não conseguir eliminar um volume, verifique o número de processos vgs pendentes no nó para identificar se o nó se encontra neste estado particularmente mau. A forma mais fiável de corrigir um nó neste estado é reiniciá-lo.
Existe outro modo de falha que pode ser experimentado. Esse modo de falha tem a seguinte assinatura na tentativa de montagem: mount(2) system call failed: No space left on device. Isto deve-se provavelmente à propagação da montagem no nó. Verifique isto executando cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Se algum destes mostrar um valor superior a um, elimine o pod que o está a usar. Isto deve acionar a desmontagem. Se não tiver êxito, desmonte manualmente esse caminho. Se continuar a ter problemas, reinicie o dispositivo.
Em determinados cenários, devido a condições de concorrência, o Google Distributed Cloud (GDC) isolado
não cria os recursos personalizados do Kubernetes ACLs do comutador necessários
durante a inicialização inicial do Distributed Cloud.
Quando o aprovisionamento Server ocorre durante a criação de qualquer cluster,
existe a possibilidade de o servidor ser marcado como aprovisionado, mas não ter
a condição Provision-Ready. Como resultado, o
NodePool não pode consumir este servidor. Uma mensagem de evento de erro de exemplo no NodePool pode ter o seguinte aspeto:
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
Em casos raros, o procedimento de reposição do iLO anterior pode não resolver totalmente o problema. Nesse caso, é necessário voltar a aprovisionar o servidor. Consulte os runbooks OS-P0002
e OS-P0003 para ver os procedimentos detalhados.
Não consegue encontrar nxos.10.3.1.bin, mas encontra algo semelhante, como nxos64-cs.10.3.1.F.bin, no diretório bootflash do comutador.
Solução alternativa:
Na máquina de arranque autónomo, conclua os seguintes passos. Tem de
concluir estes passos quando o processo de pré-instalação estiver em curso. Se existirem
várias pastas /tmp/preinstall-bootstrap-, aplique as alterações
à pasta atual que o processo de pré-instalação está a usar. Para tal, verifique os
registos do processo de pré-instalação. Se precisar de reiniciar o comando de pré-instalação, esta ação também cria uma nova pasta /tmp/preinstall-bootstrap-.
Aceda à pasta /tmp/preinstall-bootstrap-RANDOM_NUMBER.
Dentro da pasta, encontre o ficheiro poap.py.
Remova completamente a linha com a soma de verificação MD5 neste ficheiro para que
head -n 4 poap.py tenha este aspeto:
Este problema é causado pela limpeza inadequada da tarefa de atualização. Não
é necessária nenhuma ação, e a tarefa pode ser deixada no estado de ciclo de falhas.
Este é um problema para servidores que não mantêm a hora sincronizada. A configuração não está corretamente aplicada e tem de ser alterada para um espaço de nomes diferente para ser aplicada corretamente.
Solução alternativa:
Aplique os seguintes passos a todos os clusters:
Apresente as políticas de SO existentes:
kubectlgetospolicies-nntp-system
O resultado mostra admin-ntp-policy ou worker-ntp-policy.
Com base no nome da política, guarde-a num ficheiro .yaml:
Edite o ficheiro alterando metadata.namespace de
ntp-system para gpc-system e removendo
status: line e tudo o que se segue.
Aplique o ficheiro editado ao cluster:
kubectlapply-fntp-ospolicy.yaml
Aguarde alguns minutos para que o controlador aplique a política do SO.
Estabeleça uma ligação SSH a um dos nós aos quais a OSPolicy se aplica e execute cat /etc/chrony.conf. O resultado mostra
uma mensagem no início do ficheiro que indica que é gerido pelo ansible e
tem os servidores nist.time.gov ou ntp.pool removidos
da configuração.
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:
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.
As cargas de trabalho do serviço de base de dados são aprovisionadas e configuradas em projetos separados no cluster do sistema da nuvem distribuída. Embora os projetos sejam usados para aplicar limites administrativos na Distributed Cloud, não têm impacto na forma como e onde uma carga de trabalho é executada. Por conseguinte, estas cargas de trabalho podem partilhar a infraestrutura de computação subjacente com outras instâncias de base de dados e vários sistemas do plano de controlo.
Solução alternativa:
Para cargas de trabalho de base de dados que requerem isolamento adicional, os utilizadores podem pedir a criação de um conjunto de nós no cluster do sistema. Este conjunto de nós, que tem de ser referenciado durante a criação do projeto, garante que as cargas de trabalho da base de dados são aprovisionadas e executadas numa infraestrutura de computação dedicada. A configuração do conjunto de nós isolado tem de ser concluída pelo operador de infraestrutura.
Para a versão 15.2.1 do AlloyDB Omni, quando são criados vários clusters do AlloyDB Omni no mesmo nó, o último cluster criado fica bloqueado num estado de conciliação. Obtenha registos do PostgreSQL com o comando
Durante a implementação do cliente, o nome de utilizador do administrador de ficheiros secret.yaml tem de ser admin. Em vez disso, o ficheiro contém TO-BE-FILLED após a primeira criação. O nome de utilizador admin tem de ser usado para inicializar a primeira configuração na firewall e através do IP de loopback admin\admin
Solução alternativa:
Verifique se TO-BE-FILLED não está presente nas seguintes credenciais da firewall:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Verifique se todas as contas de administrador da firewall têm o nome de utilizador admin.
As políticas de firewall do IDPS predefinidas não suportam os IPs personalizados da organização para o Direct Connect (DX) Interconnect. Como resultado, a criação de organizações com IPs personalizados falha porque os IPs personalizados não conseguem estabelecer ligação ao Harbor no administrador principal.
Solução alternativa:
Para desbloquear o tráfego, crie manualmente um SecurityPolicyRule para os IPs personalizados da organização e implemente-o nas firewalls do IDPS. Siga os passos no runbook FW-G0002 para concluir os seguintes passos:
1. Crie uma entrada SecurityPolicyRule no sistema virtual de firewall raiz para permitir que os IPs personalizados da organização acedam ao Harbor raiz
Devido a um problema conhecido existente no CipherTrust Manager, as licenças de avaliação desativadas continuam a ser detetáveis e podem acionar avisos de expiração falsos.
Solução alternativa:
Consulte HSM-R0003 para verificar as licenças normais ativas e eliminar as licenças de avaliação desativadas.
O módulo de segurança de hardware (HSM) tem um comportamento inesperado quando elimina um KMS CTMKey. Por exemplo, o serviço KMS pode não ser iniciado para a organização.
Solução alternativa:
Os utilizadores podem destruir criptograficamente os dados eliminando as chaves do KMS em vez da chave raiz do KMS, o que se manifesta como um CTMKey.
Siga os passos no manual de procedimentos HSM T0016 para renovar os certificados do servidor, se a data Not After estiver no prazo de 30 dias a partir de hoje.
Configurar o webhook do ServiceNow faz com que a gestão do ciclo de vida (LCM) reconcilie novamente e reverta as alterações feitas ao objeto ConfigMapmon-alertmanager-servicenow-webhook-backend e ao objeto Secretmon-alertmanager-servicenow-webhook-backend no espaço de nomes mon-system.
Solução alternativa:
Pause o subcomponente da LCM para permitir que as alterações ocorram sem serem revertidas:
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_ADMIN_KUBECONFIG e ORG_ADMIN_KUBECONFIG, respetivamente.
Pause o subcomponente LCM num dos seguintes clusters:
Pause o subcomponente LCM no cluster de administrador raiz:
Algumas métricas dos clusters de utilizadores não são recolhidas. Este problema afeta os clusters de VMs de utilizador, mas não o cluster do sistema.
Pode ver os seguintes registos do servidor Prometheus:
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Pode ver os seguintes registos do inquilino do Cortex:
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Solução alternativa:
Siga estes passos para resolver o problema:
Obtenha o caminho para o ficheiro kubeconfig do cluster. Guarde o caminho na variável de ambiente KUBECONFIG.
Implemente um serviço de teste nos clusters de VMs de utilizador:
As métricas destinadas à instância do Grafana do operador de infraestrutura podem estar na instância do Grafana do administrador da plataforma e vice-versa. O problema é causado por pedidos de equilíbrio de carga do ASM em limites de clusters, que têm inquilinos predefinidos diferentes.
Solução alternativa:
A solução alternativa requer acesso à origem private-cloud e a capacidade de implementar uma atualização de componentes. Tem de alterar a configuração da malha para restringir o serviço cortex-tenant de modo a receber apenas tráfego do cluster local e implementar o componente ASM.
Abra o ficheiro manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Apresente o campo serviceSettings no campo meshConfig.
O campo meshConfig tem originalmente o seguinte aspeto:
Durante a atualização da versão 1.11.0 para a 1.11.3, a atualização do nó falha para o NodeOSInPlaceUpgradeCompleted.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Solução alternativa:
Inicie sessão na máquina de hardware simples que está a ser atualizada. Verifique se o fstab tem /boot/efi e se o diretório está montado:
Execute mount -a e verifique se o diretório está montado:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Continue com as verificações aqui. Execute os seguintes comandos:
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Se nem todos os ficheiros forem idênticos, execute este comando no computador e repita as verificações.
A atualização do cluster está suspensa há mais de uma hora. O estado e a especificação do modo de manutenção da máquina de metal exposto não correspondem. Por exemplo, o comando:
Uma tarefa de reinício de VM falha após a solução alternativa manual para o pod os-policy. É apresentada a seguinte mensagem:
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Solução alternativa:
Parar e iniciar a VM resolve o problema. Siga as instruções para iniciar e parar uma VM.
Durante uma atualização, o subcomponente do Gatekeeper da OPA não é instalado no cluster do sistema. No entanto, as restrições são instaladas e o webhook para as aplicar também.
Vários pods num cluster do sistema podem ficar bloqueados no estado TaintToleration:
O pod com o nome do contentor istio-proxy não está pronto e tem o estado ImagePullBackOff com o evento Back-off pulling image "auto".
Solução alternativa:
Verifique se o webhook de mutação istio-revision-tag-default está presente no cluster. Caso contrário, aguarde aproximadamente 10 minutos para ver se o sistema é recuperado automaticamente. Se não for o caso, encaminhe o problema.
Se o webhook de mutação estiver presente, elimine o pod problemático e verifique se volta a ficar disponível. O elemento .spec.containers[].image não pode ser auto. Tem de ter o aspeto de uma imagem real semelhante à seguinte: gcr.io/gke-release/asm/proxyv2:<image version>.
Quando atualizar da versão 1.11.1 para a 1.12.1, a atualização de ValidatingWebhookConfigurations, MutatingWebhookConfigurations e MonitoringRules implementados pelo componente de registo pode falhar.
Solução alternativa:
Certifique-se de que tem o kubectl e consegue aceder ao manual de procedimentos IAM-R0004 para obter o KUBECONFIG para o cluster de administrador raiz.
Elimine ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook do cluster de administrador raiz:
Elimine os MonitoringRules audit-logs-alerts, audit-logs-sli-syslog-prober, audit-logs-sli-filelog-prober, audit-logs-sli-fluentbit-to-loki, audit-logs-sli-fluentbit-to-splunk, audit-logs-sli-fluentbit-backlog, audit-logs-sli-loki-ingester-failed-rate, audit-logs-sli-loki-io-up e audit-logs-sli-loki-pa-up do infra-obs namespace no cluster de administrador raiz:
Devido a um problema na tarefa log-infra-backend-preinstall, os registos de auditoria e os registos operacionais do Loki não estão instalados e os registos não são recolhidos.
Sintomas:
Pode ver um CrashLoopBackoff no cluster do sistema:
Aumente a memória em cada carregador, aumente o número de carregadores ou ambos. Pode fazê-lo implementando um SubcomponentOverride no cluster de administração da organização, conforme mostrado no exemplo seguinte:
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. O estado da máquina bare metal mostra uma falha na verificação check_registry_mirror_reachability_pass.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. As verificações de saúde mostram o erro "netutil" em falta.
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Solução alternativa:
Elimine a tarefa do Kubernetes correspondente à verificação de funcionamento com falha
Quando atualiza de 1.11.x para 1.12.x, uma VM pode não estar pronta devido a um número excessivo de pods, o que bloqueia a drenagem de um nó de metal exposto.
Quando atualiza da versão 1.11.x para a 1.12.1, o ficheiro NodeUpgrade contém várias versões para o mesmo modelo de hardware, o que bloqueia a validação da atualização de firmware.
Solução alternativa:
Siga os passos abaixo para modificar a NodeUpgrade CR spec:
Se a atualização for para servidores HPE Gen10 (GDC-4D), remova o firmware do modelo ilo6. Caso contrário, remova o firmware do modelo ilo5.
Secção para preservar a entrada com o redfishVersion mais recente para cada descrição.
Por exemplo, se existirem ambas as entradas seguintes, mantenha apenas a que tem 2.98 Oct 10 2023:
O Ironic atingiu um limite de tempo enquanto aguardava que um servidor fosse ativado. O estado muda de cleaning para clean failed e, em seguida, para available:
Se o comutador estiver ativado, a saída devolve "On".
Solução alternativa:
Remova o bloco image dos servidores problemáticos e aguarde até que os servidores voltem ao estado disponível. Depois de estarem
disponíveis, volte a adicionar o bloco image.
Este problema ocorre quando os erros do iLO são ignorados e a resposta HTTP é lida em vez de ser devolvida imediatamente, o que resulta numa desreferenciação de ponteiro nulo.
Espera-se que os nós estejam no modo de manutenção durante uma atualização. Se um nó estiver em manutenção, pode não ter recursos suficientes para agendar harbor-db.
O objeto StatefulSet do Prometheus está configurado incorretamente com a classe de armazenamento standard em vez de standard-rwo. Este problema faz com que o arranque do objeto StatefulSet do Anthos Prometheus do componente de monitorização falhe.
O problema ocorre porque o reconciliador ObservabilityPipeline só define este valor na primeira instalação e o reconciliador ObsProjectInfra monitoriza os recursos personalizados do cluster.
Solução alternativa:
Reinicie a implementação do fleet-admin-controller no cluster de administrador da organização para resolver o problema.
O subcomponente mon-common tem de implementar um objeto de telemetria do Istio no cluster de administrador da organização para impedir o registo de auditoria de todos os pedidos do Cortex. No entanto, o ficheiro de manifesto não está incluído no ficheiro de compilação.
Solução alternativa:
Siga os passos abaixo para implementar o objeto de telemetria do Istio no cluster de administrador da organização:
Crie um ficheiro YAML que defina o recurso personalizado (CR) de telemetria do Istio no espaço de nomes mon-system do cluster de administrador da organização:
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Aplique o ficheiro de manifesto ao cluster de administrador da organização no espaço de nomes mon-system:
O Prober ConfigMap é preenchido à medida que cada teste é registado.
Siga o manual de procedimentos MON-R2009 para silenciar o alerta MON-A0001, Blackbox monitoring metrics pipeline down, porque este alerta vai continuar a ser acionado.
Quando atualiza de 1.11.x para 1.12.x, um pod de transferência de imagens de comutação pode ficar bloqueado no estado ErrImagePull com o seguinte aviso:
Quando atualiza da versão 1.11.x para a 1.12.1, a firewall do anfitrião bloqueia a transferência da imagem do comutador devido a uma incompatibilidade das interfaces usadas pela firewall do anfitrião.
Solução alternativa:
Aplique a seguinte solução alternativa antes de fazer a atualização, apenas se estiver a atualizar
da versão 1.11.x para a 1.12.x.
Atualize os clusters de administrador principal e de administrador da organização.
Obtenha o nome e o espaço de nomes do conjunto de nós para os nós bare metal do administrador raiz
e os nós bare metal do administrador da organização. Para o cluster root-admin, use o
kubeconfig root-admin. O comando seguinte apresenta um inventário
das máquinas e filtra a lista por máquinas de metal nu:
Os campos NODEPOOL_NAME e NODEPOOL_NAMESPACE são preenchidos com a lista de todos os nodepools no cluster respetivo quando o ficheiro YAML anterior é implementado.
Um exemplo de um ficheiro YAML para o cluster de administrador raiz com os nomes reais do grupo de nós do administrador raiz e do grupo de nós do administrador da organização pode ter o seguinte aspeto:
O subcomponente de configuração de chaves unificada do Linux (LUKS) não é reimplementado durante a atualização. Para verificar o subcomponente file-netapp-trident:
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
Neste exemplo, falharam duas classes de armazenamento: standard-rwo
e standard-block.
Solução alternativa:
Elimine o StorageClasses que a tarefa não conseguiu criar, como standard-rwo, standard-block, standard-rwo-non-luks e standard-block-non-luks.
Acione a recriação do StorageClasses reiniciando o oclcm-backend-controller para o seu cluster
(controlador de administrador principal para clusters de administrador principal e de organização, controlador de administrador de organização para clusters de sistema e de utilizador).
Para a versão 1.12.4, confirme que as classes de armazenamento instaladas têm a anotação disk.gdc.goog/luks-encrypted: definida como verdadeira (excluindo as classes de armazenamento não LUKS). Se a anotação não estiver definida como verdadeira, repita os passos 1 e 2.
Reinicie a implementação do netapp-trident e o netapp-trident DaemonSet no cluster.
Verifique se o segredo LUKS foi criado para os seus recursos PersistentVolumeClaim (PVC). Cada PVC tem de ter um segredo no formato g-luks-$pvc_name.
Verifique se o subcomponente file-netapp-trident não tem nenhum erro no estado.
Os conjuntos de nós nos clusters de utilizadores executados na versão 1.27.x do Kubernetes podem não ser inicializados, o que faz com que o cluster de utilizadores não processe cargas de trabalho de contentores.
Solução alternativa:
Não crie um cluster de utilizador com a versão 1.27.x do Kubernetes.
A importação de imagens de VMs falha no passo de tradução de imagens se uma imagem de origem do Ubuntu contiver origens de APT predefinidas em sources.list.
Solução alternativa:
Certifique-se de que o diretório /var/lib/apt/lists/ está vazio na imagem de origem.
O VMRuntime no cluster de destino (pode ser um cluster de administrador ou de sistema) tem o estado VMRuntime.ready = false e network-controller-manager no espaço de nomes kube-system está pendente
A eliminação da implementação network-controller-manager deve recriar automaticamente a implementação com os certificados necessários pelo operador da VMM. A implementação deve entrar no estado Running e, posteriormente, o estado do VMRuntime deve mudar para ready=true.
Os pods do importador de VMs entram num ciclo de falhas e o volume de dados fica bloqueado no estado de
importação durante mais de 90 minutos. O estado dos pods pode ter o seguinte aspeto:
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Solução alternativa:
Se a falha estiver na raiz, nos passos seguintes, substitua KUBECONFIG pela configuração kubeconfig do administrador raiz.
Se a falha for na organização, nos passos seguintes, substitua KUBECONFIG pela configuração kubeconfig do administrador da organização.
O ficheiro pode ter a seguinte mensagem na secção backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Solução alternativa:
Verifique o espaço de nomes file-system para confirmar que não termina em org-admin cluster:
Pause o subcomponente file-observability até que o subcomponente mon-admin esteja disponível, adicionando as seguintes anotações ao subcomponente file-observability:
Execute ksctl system info get --url=https://HSM_MANAGEMENT_IP para verificar se todas as versões do HSM foram atualizadas para .Spec.TargetVersion de ctmclusterupgraderequest:
Atualize o campo Status.FirmwareVersion de cada HSM para a versão atualizada, conforme obtido no passo anterior:
Por exemplo:
kubectledit-statushsmHSM_NAME-ngpc-system
Atualize o estado da última condição de ctmclusterupgraderequest.status.conditions de False para True. Depois disso, o estado da última condição hsmupgraderequest.status.conditions também passa a ser verdadeiro.
Durante uma atualização
o IP de gestão de um servidor fica inacessível, especificamente após uma atualização
do SO do comutador.
Com o Rocky Linux, quando são adicionadas rotas estáticas, o IP de destino usado para alcançar as rotas estáticas tem de estar acessível antes de adicionar as rotas estáticas. Se o comutador estiver a ser reiniciado após uma atualização do SO, esse IP de gestão pode estar temporariamente inacessível.
Solução alternativa:
Estabeleça uma ligação SSH ao servidor através do endereço IP de dados
e reinicie o serviço de rede para recriar as rotas estáticas em falta:
Quando implementa a organização gdchservices manualmente, o sistema de
pedidos não tem upstream saudável, não são criadas VMs e o pod do servidor intermédio
não está saudável no cluster gdchservices-system no espaço de nomes support.
Solução alternativa:
Crie um novo recurso personalizado TicketingSystem com a imagem de VM correta no cluster gdchservices-admin:
Se o erro ocorrer durante as verificações pós-voo e todas as outras verificações forem concluídas sem erros, ignore as verificações pós-voo. Quando a atualização for reiniciada, também tem de ignorar as verificações prévias com o kubeconfig de administrador raiz:
O esquema Portfolio foi alterado na versão 1.12 do GDC. O campo portfolioName foi refatorado para portfolioID. Encontre o ficheiro YAML que contém o recurso personalizado de portefólio mencionado na mensagem de erro. Mude o nome do campo portfolioName para portfolioID.
Seguem-se os potenciais motivos pelos quais não é criada uma tarefa em execução para uma tarefa de aplicação de patches que concluiu apenas tarefas de pré-teste:
A falha do NTP impede a execução de todas as outras tarefas de aplicação de patches.
O nó está num estado não saudável.
O agente de configuração do SO não está em execução.
O agente de configuração do SO não consegue comunicar com o serviço de configuração do SO.
Existe um problema com o serviço OS Config.
Solução alternativa:
Verifique o CR `NodeTargetPolicy` do nó.
Pesquise `.spec.osPolicies` do CR `NodeTargetPolicy` que tem `ref.name=admin-ntp-policy` e `type: Ready` com o estado falso:
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
As tarefas siem-*-preinstall no espaço de nomes root e org-1 falham repetidamente.
Solução alternativa:
Espera-se que as tarefas falhem quando o feature gate SIEMComponent estiver desativado. As falhas não indicam que o componente está avariado. A conciliação do componente SIEM pode ser pausada se o ruído for disruptivo, mas, geralmente, recomenda-se que deixe o componente ativado, se possível. Se a conciliação de componentes estiver pausada, tem de ser reativada manualmente quando a instalação do componente SIEM deixar de estar restrita em atualizações futuras.
Podem existir problemas com vgs, blkid e o gather_facts do Ansible não está a responder. Este problema afeta os sistemas operativos Rocky e Ubuntu.
Execute estes passos se os nós já tiverem sido atualizados. O processo para
atualizar o ficheiro lvm.conf consiste nos seguintes passos:
Obter uma lista de todos os nós para que esta correção possa ser aplicada a todos eles.
Crie um ficheiro de política do SO e um guia interativo do Ansible.
Aplique a correção aos nós.
Verifique se a correção foi aplicada.
Pré-requisitos:
Siga os passos no manual de procedimentos IAM-R0004 para gerar o ROOTCONFIG para o cluster de administrador raiz e o ORGCONFIG para o cluster de administrador da organização.
Siga os passos no manual de procedimentos IAM-R0005 para obter as seguintes funções da organização.
Solução alternativa:
Identifique os InventoryMachines que correspondem aos
clusters:
Manter a saída separada. Corrija um cluster de cada vez. O resultado pode ter o seguinte aspeto:
NAME
bm-2bca8e3f
bm-4caa4f4e
Crie um ficheiro de política e um guia:
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
A secção de inventário anterior tem de ser preenchida como neste exemplo.
Adicione um parágrafo por nó encontrado no passo 1. Vai fazer um cluster de cada vez, por isso, preencha a secção de inventário com nós para um cluster.
Este problema ocorre se o ambiente tiver sido implementado anteriormente com a versão 1.11 e, em seguida, atualizado para a versão 1.12. Quando cria um novo cluster ou organização numa versão 1.12.x, o Rocky OS em vez do Ubuntu OS é selecionado para o aprovisionamento de nós de metal puro e de máquinas virtuais devido à versão do Rocky OS especificada nos CRs ReleaseMetadata e Userclustermetadata.
Solução alternativa:
Aplique a seguinte solução alternativa antes de criar uma nova organização:
Verifique se existem OrganizationUpgrade CRs que não estão no estado Succeeded: true:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
Se for esse o caso, encaminhe o problema para a equipa de engenharia antes de avançar
para os passos seguintes.
Remova todos os CRs existentes para evitar
atualizações acidentais do SO dos nós:OrganizationUpgrade
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Defina a versão do GDC de destino para a criação da nova organização. Deve existir um ReleaseMetadata correspondente para esta versão de destino:
TARGET_RELEASE=
Identifique o CR mais recente para o SO Ubuntu de destino no cluster de administrador principal e defina a variável OS_VERSION:OSImageMetadata
Certifique-se de que a variável usa a mesma versão principal.secundária.patch, como 1.12.4, que a TARGET_RELEASE. Caso contrário, encaminhe o problema para a equipa de engenharia antes de avançar para os passos seguintes.
Atualize o destino ReleaseMetadata para usar o Ubuntu
OS_VERSION no cluster de administrador raiz:
Atualize o destino UserclusterMetadata para usar o Ubuntu
OS_VERSION no cluster de administrador raiz e no cluster de administrador da organização
para cada organização. Execute o seguinte comando para cada cluster:
Quando as imagens de VMs locais são importadas através da CLI gdcloud compute images import, o estado de importação fica bloqueado em WaitingForTranslationVM ou ImportJobNotCreated. Isto deve-se ao facto de o disco temporário
criado para traduzir ou importar usar o tamanho exato da imagem qcow2 ou raw, mas o LUKS adiciona uma sobrecarga de alguns MiBs que faz com que o aprovisionamento do disco falhe.
Solução alternativa:
Crie um novo VirtualMachineImageImport manualmente com o mesmo nome de imagem, mas com um spec.minimumDiskSize maior. Por
exemplo, se este foi o comando usado para importar a imagem:
Se o original VirtualMachineImageImport criado automaticamente pela
CLI tiver minimumDiskSize como X Gi, crie um novo com
X+1 Gi. O valor baseia-se no tamanho da imagem que está a ser importada. No caso de qcow2, seria o tamanho virtual. Por exemplo, 20 Gi devem ser substituídos por 21 Gi.
Substitua os valores dos marcadores de posição com base na forma como a CLI foi chamada.
Se o objeto não estiver presente, acione novamente o comando gdcloud compute images import .... Depois de a saída da consola passar de
Uploading image to ... para Image import has started for ...,
prima CTRL + C para que a imagem local seja carregada para o armazenamento de objetos e
o VirtualMachineImageImport seja preservado para referência para
criar um novo.
Crie um novo VirtualMachineImageImport com um
minimumDiskSize maior:
O pod importer-image-import-$VMII no espaço de nomes do projeto do cluster do sistema falha com o seguinte erro: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). O objeto VirtualMachineImageImport VMII tem o tipo de condição Ready com o estado False e o motivo TranslationInProgress após 2 horas do início da importação.
Solução alternativa:
Para melhorar a velocidade, modifique o tamanho mínimo do disco da imagem para 200 Gi da seguinte forma:
Tenha em atenção que, para eliminar e aplicar o ValidatingWebhookConfiguration, precisa do kubeconfig do administrador do cluster para o cluster do administrador da organização. Pode obter o seguinte manual de procedimentos IAM-R0004.
Se usar gdcloud para iniciar a importação, tenha em atenção que não existe forma de fornecer o parâmetro minimumDiskSize. Tem de criar um objeto VMII e modificá-lo conforme mostrado no comando anterior.
O processo de VirtualMachineImageImport continua, mas volta a ficar bloqueado num passo subsequente. No espaço de nomes do projeto no cluster do sistema, vê que a tarefa image-import-$VMII falha continuamente com o erro: error: stream error: stream ID x; NO_ERROR; received from peer. Neste ponto, a importação de imagens é concluída. A imagem final é carregada para o armazenamento de objetos, mas o ícone VirtualMachineImage está em falta. Pode criar manualmente um VirtualMachineImage da seguinte forma:
`$NAME` deve corresponder a `VMII.ImageMetadata.Name`, e `$OS_NAME` pode ser um de [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`] e deve corresponder ao tipo de imagem importada.
A implementação do istio-eastwestgateway no espaço de nomes istio-system está bloqueada, com eventos de pods a apresentar um erro Back-off pulling image "auto" de kubelet.
Para diagnosticar o problema, verifique se o mutatingwebhookconfiguration com o nome istio-revision-tag-default existe no mesmo cluster que a implementação do gateway bloqueada.
Modifique o cortex-configconfigMap no cluster do sistema
e defina o limite de tempo para o memcached na index_cache para dois segundos, de modo
que a configuração da index_cache tenha o seguinte aspeto:
O nó de metal exposto é apresentado como NotReady e o servidor fica
bloqueado no ecrã de arranque com a última mensagem a indicar
Retrieving encryption keys.
Solução alternativa:
Reinicie o iLO.
Depois de o iLO estar novamente em funcionamento, reinicie o servidor.
A localização do instalador do fluent-bit foi alterada para operations_center\bin\fluent-bit-win64.msi.
O Copy-ConfigHostFiles.ps1 espera que o instalador do cliente fluent-bit
corresponda ao padrão fluent-bit-*-win64.*.
O instalador não consegue encontrar o instalador porque esse padrão já não corresponde.
A localização do instalador do Nessus foi alterada para operations_center\bin\NessusAgent-x64.msi.
O Copy-ConfigHostFiles.ps1 espera que o instalador do cliente corresponda ao nome do ficheiro /NessusAgent-10.4.1-x64.msi.
O instalador não consegue encontrar o instalador porque esse padrão já não corresponde.
Este problema é causado por uma configuração de ponto final do S3 em falta para a nova organização.
Solução alternativa:
Crie manualmente um grupo de HA para a nova organização.
Através do procedimento de acesso de emergência, adquira um kubeconfig do cluster de administrador raiz que tenha acesso de leitura aos seguintes recursos:
Obtenha as credenciais de início de sessão da IU de gestão do StorageGRID a partir do segredo gpc-system/objectstorage-breakglass-root-level1 no cluster root-admin.
Inicie sessão na IU de gestão do StorageGRID com as credenciais do
passo anterior. O URL está no estado ObjectStorageSite:
Aceda ao separador Configuração e clique em Grupos de alta disponibilidade.
Abra a vista de detalhes de cada grupo de HA e anote o respetivo endereço IP virtual (VIPs).
Crie um novo grupo de HA:
Nome do grupo: o padrão de nome é ORGANIZATION_NAME-ha
. Neste caso, é org-2-ha.
Descrição do grupo: use grupos de HA existentes para o padrão de descrição.
Interfaces: selecione todas as eth2.
A ordem de prioridade: a interface principal deve ter a prioridade mais elevada.
SubnetCIDR: este campo é preenchido automaticamente pelo StorageGRID.
Confirme se a sub-rede corresponde ao status.ipv4SubnetStatus.cidrBlock
no SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtual: o próximo IP no intervalo de IPs disponíveis. O IP não pode entrar em conflito com o IP reservado, o IP do cliente do nó de administração e os VIPs dos grupos de HA existentes.
Rode as credenciais de acesso de emergência do StorageGRID.
Quando atualiza a organização raiz de 1.12.2 para 1.12.4, o subcomponente iac-gitlab tem um estado de conciliação em curso.
Para diagnosticar o problema, verifique os registos do Prometheus, por exemplo:
Se este problema ocorrer durante a atualização, elimine a tarefa de migração, uma vez que tem um limite de tempo de 3600 segundos, e, em seguida, avance com a atualização:
Consulte a mensagem de erro anterior e tome nota do espaço de nomes e do nome da implementação. Neste exemplo, NAME é
iam-authzpdp-backend-server e NAMESPACE é
iam-system.
Tenha em atenção o pod que não tem todos os contentores prontos. Neste caso
o POD_NAME é iam-authzpdp-backend-server-6875654c4b-pvscg
que tem um dos dois contentores não pronto, indicado pelo estado 1/2. Se existir mais do que um pod como este, repita o passo seguinte
para cada pod afetado.
Elimine o pod que não está totalmente em bom estado:
kubectldeletepod-nNAMESPACEPOD_NAME>
Execute novamente o comando do passo 2. Repare que todos os pods devem estar
agora em bom estado. Este passo pode demorar alguns minutos.
Se o pod eliminado não for substituído por um pod em bom estado, abra um pedido de apoio técnico.
Durante a atualização da organização de inquilinos de 1.12.2 para 1.12.4, a atualização do subcomponente opa gatekeeper falha com um ReconciliationError.
Solução alternativa:
Edite o mutatingwebhookconfiguration objeto edr-sidecar-injector-webhook-cfg do cluster de utilizadores afetado. Se existirem mais do que um cluster de utilizadores afetados, repita os passos para cada cluster de utilizadores afetados:
Edite a secção webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values para lhe adicionar os seguintes dois valores:
Quando atualiza de 1.12.2 para 1.12.4, o ansibleplaybook não é atualizado como parte da atualização do cluster. As correções atualizadas no ansibleplaybook não são aplicadas e bloqueiam a política de SO que executa a versão anterior do ansibleplaybook.
Solução alternativa:
Elimine a tarefa do Kubernetes create-ansible-playbooks:
Quando cria uma nova organização, pode ver o subcomponente core-dns a expirar nos registos:
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Solução alternativa:
Atualize o serviço gpc-coredns-forwarder-udp do cluster de administrador principal e o serviço gpc-coredns-forwarder-tcp, e adicione os novos intervalos de IP aos intervalos de origem do equilibrador de carga.
Se as alterações do CR forem substituídas, pause o dns-core
subcomponente com a anotação lcm.private.gdc.goog/paused="true".
Quando atualiza de 1.12.2 para 1.12.4, o subcomponente file-netapp-trident fica bloqueado na eliminação de StorageClasses. Apresenta o seguinte estado:
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Solução alternativa:
Pause o subcomponente file-netapp-trident:
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Elimine o StorageClasses que a tarefa não conseguiu criar, como standard-rwo, standard-block, standard-rwo-non-luks e standard-block-non-luks:
Acione a recriação do StorageClasses reiniciando o oclcm-backend-controller para o seu cluster
(controlador de administrador principal para clusters de administrador principal e de organização, controlador de administrador de organização para clusters de sistema e de utilizador):
Os pods primary-prometheus-shardX-replicaX são visíveis no espaço de nomes obs-system e no espaço de nomes mon-system. Se o primary-prometheus-shardX-replicaX só
existir no espaço de nomes obs-system após uma atualização para a versão 1.12, então
trata-se de um problema desconhecido diferente e a solução alternativa não deve ser realizada.
O comportamento pretendido é que
primary-prometheus-shardX-replicaX só exista no espaço de nomes
mon-system após a conclusão da atualização 1.12.
Solução alternativa:
Elimine manualmente os primary-prometheus-shardX-replicaXStatefulSetsobs-system no espaço de nomes obs-system.
Não elimine os primary-prometheus-shardX-replicaX
StatefulSets no espaço de nomes mon-system.
Um ClusterCIDRConfig é um objeto obrigatório para atribuir
PodCIDRs. Apesar de o ClusterCIDRConfig ter sido criado, o PodCIDRs não foi atribuído. Este problema ocorre se for criado um ClusterCIDRConfig ao mesmo tempo que os pods ipam-controller estão a ser iniciados. A criação do cluster está bloqueada no estado de reconciliação:
Verifique se o objeto ClusterCIDRConfig foi criado no cluster:
Execute o comando describe para um dos objetos de nó do cluster que está
bloqueado na reconciliação e verifique se existe um evento CIDRNotAvailable no objeto de nó:
O MonitoringTarget mostra um estado Not Ready quando estão a ser criados clusters de utilizadores, o que faz com que as APIs pré-preparadas mostrem continuamente um estado Enabling na interface do utilizador.
Solução alternativa:
Abra o menu no navegador Chrome (ícone de três pontos).
Clique em Mais ferramentas > Ferramentas para programadores para abrir a consola.
Clique no separador Rede na consola.
Encontre os ai-service-status pedidos.
Clique no separador Resposta num pedido ai-service-status para mostrar o conteúdo desse pedido.
Verifique se tudo parece pronto, exceto os componentes MonitoringTarget e LoggingTarget.
Quando atualiza o armazenamento de objetos, pode ver um aviso como este:
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError:ErrorMessage:{"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked
Solução alternativa:
Verifique se cada nó tem credenciais SSH correspondentes armazenadas num segredo.
Durante as atualizações, o cluster da base de dados de tradução é recriado, o que faz com que o segredo do cluster do sistema ODS secret-store fique desatualizado e dessincronizado. Por este motivo, o pod e o serviço de frontend de tradução falham a inicialização.
O servidor não consegue estabelecer ligação ao gestor de chaves, o que impede que o estado do servidor fique disponível. Este problema faz com que a tarefa falhe e o cluster de administrador não fique pronto.server-encrypt-and-create-logical-drive Pode ver um erro nos registos de tarefas como este:
O Loki tem apenas um volume persistente (PV) para os registos de gravação antecipada (WAL) e os índices. O WAL pode preencher o PV se um pod do Loki não conseguir estabelecer ligação ao contentor de armazenamento durante horas. Se o PV não tiver espaço disponível, o Loki não pode ser recuperado, a menos que elimine o PV e reinicie o StatefulSet.
Solução alternativa:
Para recuperar um pod Loki deste estado, tem de reduzir a escala do StatefulSet correspondente e eliminar o PV sem espaço restante.
Siga estes passos para recuperar o pod Loki:
Certifique-se de que o contentor da ferramenta de E/S está instalado na estação de trabalho. Para obter detalhes, consulte o manual de operações OOPS-P0065.
Para receber as autorizações necessárias para editar recursos, peça ao administrador de segurança que lhe conceda as seguintes funções:
observability-viewer
observability-admin
Defina a variável de ambiente KUBECONFIG com o caminho para o ficheiro kubeconfig no cluster de administrador raiz. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.
Defina a variável de ambiente ORG_NAME com o nome da organização afetada.
Guarde o seguinte conteúdo num ficheiro YAML com o nome log-admin-overrides.yaml:
Defina a variável de ambiente KUBECONFIG com o caminho para o ficheiro kubeconfig no cluster onde o pod Loki afetado está em execução. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.
Defina a variável de ambiente LOKI_POD_NAME com o nome do pod do Loki afetado.
Defina a variável de ambiente KUBECONFIG com o caminho para o ficheiro kubeconfig no cluster de administrador da organização afetada. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.
Edite o conteúdo no ficheiro YAML log-admin-overrides.yaml da seguinte forma:
As tarefas são agendadas continuamente. Assim que uma tarefa é terminada, é agendada uma nova tarefa. As tarefas que estão a ser agendadas continuamente são:
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Solução alternativa:
Pause os seguintes subcomponentes:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Desativar a pausa dos subcomponentes sempre que houver uma alteração ao segredo fleet-info no cluster de administrador raiz. Este problema ocorre quando existe uma alteração nos comutadores de gestão da instância, como kr get managementswitches -A, ou uma alteração a qualquer cidrclaim no espaço de nomes da organização.
Desative a pausa dos subcomponentes sempre que houver uma alteração a qualquer recurso NodePool no cluster de administrador da organização. Despause os subcomponentes antes de começar.
Quando atualiza da versão 1.12.2 para a 1.12.4, não está disponível um upstream saudável para o ServiceNow. Pode ver a seguinte mensagem: failed to stage volume: LUKS passphrase cannot be empty.
A classe de armazenamento system-performance-rwo não está ativada para LUKS. O anexo de volume indica que o PVC tem o LUKS ativado.
O reconciliador procura um segredo com as frases secretas do LUKS. Uma vez que o anexo de volume indica que tem o LUKS ativado e a classe de armazenamento não tem o LUKS ativado, a palavra-passe secreta não é criada.
Solução alternativa:
Obtenha o Kubeconfig para o cluster raiz ou de administrador da organização onde o problema aparece:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Elimine a classe de armazenamento system-performance-rwo e volte a criá-la:
Quando atualiza de 1.12.2 para 1.12.4, a atualização da organização fica bloqueada na fase NodeUpgrade e a tarefa de atualização do nó apresenta o seguinte erro:
Obtenha o Kubeconfig para o cluster de raiz ou de administrador da organização onde a atualização do nó está a falhar e verifique se o nodeupgradetask falhou:
O kubelet continua a imprimir o seguinte registo de spam:
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
O processo runc init está bloqueado, o que impede que o kubelet elimine o pod cgroup.
Solução alternativa:
Use o seguinte script para encontrar o processo que está a bloquear a eliminação de cgroup:
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Verifique o estado de congelamento através de cat freezer.state. O estado deve ser FROZEN.
Echo "THAWED" > freezer.state
O grupo cgroup foi eliminado com êxito. Kubelet para de enviar spam para o registo.
O PTaaS está implementado na organização gdchservices.
Inspeccione as anotações e as etiquetas do projeto gdch-perftest e do contentor perftest-bucket-reports do PTaaS no espaço de nomes perftest gdch-perftest. O contentor pode não ter a etiqueta: app.kubernetes.io/managed-by=Helm, e as anotações: meta.helm.sh/release-name=perf-ptaas-assets e meta.helm.sh/release-namespace=gdch-perftest.
Adicione estas etiquetas e anotações manualmente:
Inspecione as anotações do projeto PTaaS gdch-perftest. O projeto pode estar configurado incorretamente com a anotação: meta.helm.sh/release-name=perf-ptaas-assets.
Altere esta anotação para meta.helm.sh/release-name=perf-ptaas-backend:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-23 UTC."],[],[]]
