Problemas conhecidos do Google Distributed Cloud com isolamento físico 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 backup de volume usa o servidor DNS externo
em vez do encaminhador, o que impede que o backup de volume resolva os endpoints de armazenamento de objetos
no nível da organização. Na versão 1.12, o tráfego de backup exige novas rotas para cada organização.
Alternativa:
Os IOs precisam atualizar o cluster de armazenamento para ativar a resolução de DNS no nível da organização
e criar uma rota das interfaces lógicas de replicação (LIFs) para
endpoints de armazenamento de objetos em cada organização. Copie e cole os comandos a seguir do bootstrap.
O comando curl do gateway de entrada do administrador da organização dos nós do ONTAP falha porque
não há rota da sub-rede de backup para os planos de controle da organização.
Alternativa:
Os IOs precisam atualizar o cluster de armazenamento para ativar a resolução de DNS no nível da organização
e criar uma rota das interfaces lógicas de replicação (LIFs) para
endpoints de armazenamento de objetos em cada organização. Copie e cole os comandos a seguir do bootstrap.
Se o repositório de backup não tiver nenhum tipo de status de erro, mas
um alerta for gerado, a métrica de alerta do repositório poderá ser
gerada por engano. Esse é um problema conhecido na versão 1.12.0 e foi corrigido
na 1.12.4. A causa desse problema é que o repositório de backup
tenta periodicamente se conectar ao armazenamento de objetos como uma verificação de integridade
e entra em um estado não íntegro se a conexão falhar. No entanto, se o repositório de backup for recuperado, a métrica que indica a integridade dele não será revertida corretamente, fazendo com que o alerta fique preso em um estado de disparo indefinido.
Para resolver esse problema, exclua e recrie manualmente o repositório de backup para redefinir a métrica de integridade dele. Siga as etapas no
runbook BACK-R0003 para recriar o repositório de backup.
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 consegue reconciliar devido a jobs desatualizados. Os billing-storage-system-init-job-628 e billing-storage-system-init-job-629 permanecem após uma conclusão bem-sucedida.
Alternativa:
Siga estas etapas:
Faça backups dos jobs de faturamento desatualizados:
Os pods do Grafana nos namespaces anthos-identity-service-obs-system e platform-obs-obs-system estão travados no estado Init devido a erros de ativação de volume. A mensagem de erro nos registros do kubelet indica um problema de multiencadeamento. O problema decorre de um bug no Trident, que não consegue identificar e verificar corretamente o dispositivo subjacente para mapeamentos LUKS, resultando em um erro de multiencadeamento.
Alternativa:
Verifique se o PVC tem um "deletionTimestamp". Se não houver deletionTimestamp (migração de pod), siga estas etapas:
Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado no momento.
Isolar os Nodes no cluster que não correspondem a esse valor.
Exclua o Pod com falha. Isso vai fazer com que ele migre de volta para o Node original.
Depois de verificar, se houver um "deletionTimestamp" (exclusão de volume), siga estas etapas:
Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado no momento.
No Node, gere o conteúdo do arquivo de rastreamento:
cat/var/lib/trident/tracking/PVC_NAME.json
Valide se o dispositivo LUKS encontrado no campo devicePath da saída do arquivo de rastreamento está realmente fechado. Este caminho não pode existir neste momento:
statDEVICE_PATH
Valide se o número de série está mapeado para algum dispositivo multipath.
Copie o valor no campo iscsiLunSerial do arquivo de rastreamento.
Converta esse valor no valor hexadecimal esperado:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Com esse novo valor, verifique se a entrada de vários caminhos ainda existe:
multipath-ll|grepSERIAL_HEX
Se ele não existir, exclua o arquivo de rastreamento.
Se ele existir, você vai encontrar um valor hexadecimal serial um pouco mais longo do que o pesquisado, chamado de multipathSerial. Execute o comando a seguir e encontre os dispositivos de bloco:
multipath-llMULTIPATH_SERIAL
Em seguida, execute os comandos a seguir. O último é executado exclusivamente para cada dispositivo de transferência por 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.
Alternativa:
Alterne a permissão de /etc/kubernetes/pki/etcd/ca.crt. Essa é uma operação muito sensível ao tempo. A troca de permissão precisa acontecer depois da
execução anterior do job machine-init, mas antes da próxima execução
do job machine-init, já que machine-init substitui
a permissão de volta para a raiz.
Reinicie o etcd no segundo nó para recuperar o
etcd no primeiro nó de um loop de falhas.
Depois de concluir essas duas etapas, o kube-apiserver no primeiro nó começa
a ser executado, e o próximo job machine-init é concluído.
Depois de configurar a exportação para um sistema SIEM externo, a entrada do SIEM não será incluída no pipeline de processamento do Fluent Bit, e os registros do servidor da API do Kubernetes não estarão presentes nesse SIEM.
Ao fazer upgrade da versão 1.12.2 para a 1.12.4, se um nó for removido e depois adicionado novamente, o processo machine-init desse nó poderá falhar.
Essa falha ocorre porque o tráfego de rede do nó adicionado novamente para os serviços essenciais do plano de controle é negado pela política ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes.
Esse erro é destacado pelas mensagens de status neste exemplo de saída:
Receba CIDRs de CIDRClaim/org-external-cidr -n root (especificamente o campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Execute o comando a seguir no cluster de administrador raiz:
Adicione esses CIDRs ao ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, especificamente ao campo .spec.ingress.fromCIDR. Aplique essa mudança no cluster de administrador raiz com o comando:
Receba CIDRs para a organização (por exemplo, org-1) de CIDRClaim/org-external-cidr -n org-1 (especificamente o campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Esse comando é executado no cluster de administrador raiz para receber os CIDRs de "org-1":
Adicione esses CIDRs ao ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, especificamente ao campo .spec.ingress.fromCIDR. Aplique essa mudança no respectivo cluster de administrador da organização com o comando:
Em um nó bare metal do cluster do sistema, não é possível encerrar dois contêineres anetd. Depois de interromper o processo à força e reiniciar kubelet e containerd, o pod anetd é recriado, mas todos os contêineres ficam presos em podInit, e containerd informa a mensagem de erro:
Isso impede que a interface de rede de contêiner (CNI) seja iniciada e que outros pods sejam programados.
Alternativa:
Faça estas mitigações para evitar esse estado do nó:
Não programe mais de 10 PVCs por vez em um único nó. Aguarde a montagem antes de agendar mais. Isso era mais perceptível ao tentar criar VMs.
Atualize o arquivo /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 em um estado em que mostra tempos limite para anexos e montagens de volume ou não for possível excluir um volume, verifique o número de processos vgs pendentes no nó para identificar se ele está nesse estado particularmente ruim. A maneira mais confiável de corrigir um nó nesse estado é reiniciá-lo.
Há outro modo de falha que pode ocorrer. Esse modo de falha tem a seguinte assinatura na tentativa de montagem: mount(2) system call failed: No space left on device. Isso provavelmente é resultado da propagação de montagem no nó. Verifique isso executando cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Se algum deles mostrar um valor maior que um, exclua o pod que o usa. Isso vai acionar uma desmontagem. Se isso não funcionar, desmonte manualmente esse caminho. Se o problema persistir, reinicie o dispositivo.
Em alguns cenários, devido a condições de disputa, o Google Distributed Cloud (GDC) isolado
não cria os recursos personalizados do Kubernetes ACLs de switch necessários
durante a inicialização inicial do Distributed Cloud.
Ao provisionar Server durante a criação de um cluster,
há uma chance de o servidor ser marcado como provisionado, mas sem a condição
Provision-Ready. Como resultado, o
NodePool não pode consumir esse servidor. Uma mensagem de evento de erro de exemplo em NodePool pode ter esta aparência:
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 redefinição do iLO anterior pode não resolver
o problema completamente. Nesse caso, é necessário um novo provisionamento do servidor. Consulte os runbooks OS-P0002 e OS-P0003 para conferir os procedimentos detalhados.
Não é possível encontrar nxos.10.3.1.bin, mas algo semelhante, como nxos64-cs.10.3.1.F.bin, no diretório bootflash do switch.
Alternativa:
Na máquina de bootstrap, conclua as etapas a seguir. É necessário
concluir essas etapas quando o processo de pré-instalação estiver em andamento. Se houver
várias pastas /tmp/preinstall-bootstrap-, aplique as mudanças
à pasta atual que o processo de pré-instalação está usando. Para isso, verifique os
registros do processo de pré-instalação. Se você precisar reiniciar o comando de pré-instalação, essa ação também vai criar uma nova pasta /tmp/preinstall-bootstrap-.
Acesse a pasta /tmp/preinstall-bootstrap-RANDOM_NUMBER.
Dentro da pasta, encontre o arquivo poap.py.
Remova a linha com o checksum md5 completamente neste arquivo para que
head -n 4 poap.py fique assim:
Isso é um problema para servidores que não mantêm o tempo sincronizado. A
configuração não foi aplicada corretamente e precisa ser alterada para um namespace
diferente para ser aplicada corretamente.
Alternativa:
Siga estas etapas em todos os clusters:
Liste as políticas de SO atuais:
kubectlgetospolicies-nntp-system
A saída mostra admin-ntp-policy ou worker-ntp-policy.
Com base no nome da política, salve-a em um arquivo .yaml:
Edite o arquivo mudando metadata.namespace de
ntp-system para gpc-system e removendo o
status: line e tudo o que vem depois dele.
Aplique o arquivo editado ao cluster:
kubectlapply-fntp-ospolicy.yaml
Aguarde alguns minutos para que o controlador aplique a política do SO.
Estabeleça uma conexão SSH com um dos nós a que a OSPolicy
se aplica e execute cat /etc/chrony.conf. A saída mostra uma mensagem no início do arquivo informando que ele é gerenciado pelo Ansible e que os servidores nist.time.gov ou ntp.pool foram removidos da configuração.
O processo de backup e restauração de VMs não pode ser iniciado pelos usuários devido a
configurações inadequadas de controle de acesso baseado em papéis (RBAC) e de esquema no gerenciador de VMs.
Os nomes dos planos de backup de VM não podem ter mais de 63 caracteres.
Por exemplo, você pode ver esta mensagem de erro:
Os nomes dos planos de backup de VM são uma concatenação do nome VirtualMachineBackupPlanTemplate, do tipo de recurso (que é vm ou vm-disk) e do nome desse recurso. Essa string concatenada precisa ter menos de 63 caracteres.
Para isso, mantenha os nomes desses recursos curtos ao criá-los. Para detalhes sobre a criação desses recursos, consulte Criar e iniciar uma instância de VM e Criar um plano de backup para VMs.
As cargas de trabalho do serviço de banco de dados são provisionadas e configuradas em projetos separados no cluster do sistema Distributed Cloud. Embora os projetos sejam usados para impor limites administrativos no Distributed Cloud, eles não têm impacto em como e onde uma carga de trabalho é executada. Portanto, essas cargas de trabalho podem compartilhar a infraestrutura de computação subjacente com outras instâncias de banco de dados e vários sistemas de plano de controle.
Alternativa:
Para cargas de trabalho de banco de dados que exigem isolamento adicional, os usuários podem solicitar a criação de um pool de nós no cluster do sistema. Esse pool de nós, que precisa ser referenciado durante a criação do projeto, garante que as cargas de trabalho do banco de dados sejam provisionadas e executadas em uma infraestrutura de computação dedicada. A configuração do pool de nós isolado precisa ser concluída pelo operador de infraestrutura.
Na versão 15.2.1 do AlloyDB Omni, quando vários clusters do AlloyDB Omni são criados no mesmo nó, o último cluster criado fica preso em um estado de reconciliação. Receber registros do PostgreSQL com o comando
Durante a implantação do cliente, o nome de usuário do administrador do arquivo secret.yaml precisa ser admin. Em vez disso, o arquivo contém TO-BE-FILLED após a primeira criação. O nome de usuário admin precisa ser usado para inicializar a primeira configuração no firewall e no IP de loopback admin\admin.
Alternativa:
Verifique se TO-BE-FILLED não está presente nas seguintes credenciais de 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 do firewall têm o nome de usuário admin.
As políticas de firewall de IDPS padrão não são compatíveis com os IPs personalizados da organização para a interconexão Direct Connect (DX). Como resultado, a criação da organização com IPs personalizados falha porque eles não conseguem se conectar ao Harbor no administrador raiz.
Alternativa:
Para desbloquear o tráfego, crie manualmente um SecurityPolicyRule para os IPs personalizados da organização e implante nos firewalls do IDPS. Siga as etapas no runbook FW-G0002 para concluir as seguintes etapas:
1. Crie uma entrada SecurityPolicyRule no sistema virtual de firewall raiz para permitir que os IPs personalizados da organização acessem o Harbor raiz.
Devido a um problema conhecido no CipherTrust Manager, as licenças de teste desativadas ainda são detectáveis e podem acionar avisos falsos de expiração.
Alternativa:
Consulte HSM-R0003 para verificar as licenças normais ativas e excluir as licenças de teste desativadas.
O módulo de segurança de hardware (HSM) tem um comportamento inesperado ao excluir um CTMKey do KMS. Por exemplo, o serviço KMS pode não ser iniciado para a organização.
Alternativa:
Os usuários podem criptografar os dados excluindo as chaves do KMS em vez da chave raiz do KMS, o que se manifesta como um CTMKey.
Configurar o webhook do ServiceNow faz com que o gerenciamento do ciclo de vida (LCM) faça uma nova reconciliação e reverta as mudanças feitas no objeto ConfigMapmon-alertmanager-servicenow-webhook-backend e no objeto Secretmon-alertmanager-servicenow-webhook-backend no namespace mon-system.
Alternativa:
Pause o subcomponente do LCM para que as mudanças aconteçam sem serem revertidas:
Consiga os caminhos para os arquivos kubeconfig dos clusters de administrador raiz e de administrador da organização. Salve os caminhos nas variáveis de ambiente ROOT_ADMIN_KUBECONFIG e ORG_ADMIN_KUBECONFIG, respectivamente.
Pause o subcomponente do LCM em um dos seguintes clusters:
Pause o subcomponente do LCM no cluster de administrador raiz:
Algumas métricas dos clusters de usuários não são coletadas. Esse problema afeta os clusters de VM do usuário, mas não o cluster do sistema.
É possível conferir os seguintes registros do servidor do 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:"
É possível ver os seguintes registros do locatário 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"
Alternativa:
Siga estas etapas para resolver o problema:
Consiga o caminho para o arquivo kubeconfig do cluster. Salve o caminho na variável de ambiente KUBECONFIG.
Implante um serviço stub nos clusters de VM do usuário:
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 solicitações de balanceamento de carga do ASM em limites de cluster, que têm locatários padrão diferentes.
Alternativa:
A solução alternativa exige acesso à fonte private-cloud e a capacidade de lançar uma atualização de componente. É necessário mudar a configuração da malha para restringir o serviço cortex-tenant a receber tráfego apenas do cluster local e implantar o componente do ASM.
Abra o arquivo manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Apresente o campo serviceSettings no campo meshConfig.
O campo meshConfig originalmente tem a seguinte aparência:
Ao fazer upgrade da versão 1.11.0 para 1.11.3, o upgrade do nó falha para 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
}
Alternativa:
Faça login na máquina bare metal que está recebendo o upgrade. 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
Faça as verificações aqui. Execute os comandos a seguir:
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 arquivos forem idênticos, execute este comando na máquina e repita as verificações.
O upgrade do cluster está parado há mais de uma hora. O status e a especificação do modo de manutenção da máquina Bare Metal não correspondem. Por exemplo, o comando:
Uma tarefa de reinicialização da VM falha após a solução alternativa manual para o pod os-policy. A seguinte mensagem é exibida:
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
Durante um upgrade, o subcomponente do OPA Gatekeeper não é instalado no cluster do sistema. No entanto, as restrições e o webhook para aplicá-las são instalados.
Vários pods em um cluster do sistema podem ficar presos no estado TaintToleration:
O pod com o nome do contêiner istio-proxy não está pronto e tem o status ImagePullBackOff com o evento Back-off pulling image "auto".
Alternativa:
Verifique se o webhook mutante istio-revision-tag-default está presente no cluster. Se não, aguarde aproximadamente 10 minutos para ver se o sistema se recupera automaticamente. Se não for, encaminhe o problema.
Se o webhook de mutação estiver presente, exclua o pod problemático e verifique se ele volta a funcionar. O .spec.containers[].image não pode ser auto. Ele precisa ser uma imagem real semelhante a esta: gcr.io/gke-release/asm/proxyv2:<image version>.
Ao fazer upgrade da versão 1.11.1 para a 1.12.1, os ValidatingWebhookConfigurations, MutatingWebhookConfigurations e MonitoringRules implantados pelo componente de registro em log podem não ser atualizados.
Alternativa:
Verifique se você tem o kubectl e pode acessar o runbook IAM-R0004 para receber o KUBECONFIG do cluster de administrador raiz.
Exclua ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook do cluster de administrador raiz:
Exclua 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 de infra-obs namespace no cluster de administrador raiz:
Devido a um problema no job log-infra-backend-preinstall,
os registros de auditoria e operacionais do Loki não são instalados, e os registros não são
coletados.
Sintomas:
Talvez você veja um CrashLoopBackoff no cluster do sistema:
Aumente a memória em cada ingester, aumente o número de ingesters ou ambos. Para isso, implante um SubcomponentOverride no cluster de administrador da organização, como mostrado no exemplo a seguir:
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 status do Baremetalmachine mostra 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 integridade mostram o erro "netutil" ausente.
{"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"}
Alternativa:
Exclua o job do Kubernetes correspondente à verificação de integridade com falha.
Ao fazer upgrade da versão 1.11.x para a 1.12.x, uma VM pode não ficar pronta devido ao grande número de pods, o que bloqueia a drenagem de um nó bare metal.
Ao fazer upgrade da versão 1.11.x para a 1.12.1, NodeUpgrade contém várias versões para o mesmo modelo de hardware, bloqueando a verificação do upgrade de firmware.
Alternativa:
Siga estas etapas para modificar o CR specNodeUpgrade:
Se o upgrade for para servidores HPE Gen10 (GDC-4D), remova o firmware do modelo ilo6. Caso contrário, remova o firmware do modelo ilo5.
Seção para preservar a entrada com o redfishVersion mais recente para cada descrição.
Por exemplo, se as duas entradas a seguir existirem, mantenha apenas aquela com 2.98 Oct 10 2023:
Se a chave estiver ativada, a saída vai retornar "On".
Alternativa:
Remova o bloco image dos servidores problemáticos e aguarde até que eles voltem ao estado disponível. Depois que eles estiverem
disponíveis, adicione o bloco image novamente.
Esse problema ocorre quando os erros do iLO são ignorados e a resposta HTTP é
lida em vez de ser retornada imediatamente, resultando em uma dereferência de ponteiro nulo.
Espera-se que os nós estejam no modo de manutenção durante um upgrade. Se um nó estiver em manutenção, talvez você não tenha recursos suficientes para programar harbor-db.
O objeto StatefulSet do Prometheus está configurado incorretamente com a classe de armazenamento standard em vez de standard-rwo. Esse problema faz com que a inicialização do objeto StatefulSet do Anthos Prometheus do componente de monitoramento falhe.
O problema ocorre porque o reconciliador ObservabilityPipeline só define esse valor na primeira instalação, e o reconciliador ObsProjectInfra monitora recursos personalizados do cluster.
Alternativa:
Reinicie a implantação fleet-admin-controller no cluster de administrador da organização para resolver o problema.
O subcomponente mon-common precisa implantar um objeto de telemetria do Istio no cluster de administrador da organização para impedir o registro de auditoria de todas as solicitações do Cortex. No entanto, o arquivo de manifesto não está incluído no arquivo de build.
Alternativa:
Siga estas etapas para implantar o objeto de telemetria do Istio no cluster de administrador da organização:
Crie um arquivo YAML definindo o recurso personalizado (CR) de telemetria do Istio no namespace 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 arquivo de manifesto ao cluster de administrador da organização no namespace mon-system:
Ao fazer upgrade da versão 1.11.x para a 1.12.1, o firewall do host bloqueia o download da imagem de troca devido a uma incompatibilidade de interfaces usadas pelo firewall do host.
Alternativa:
Aplique a solução alternativa a seguir antes de fazer upgrade, apenas se você estiver fazendo upgrade
da versão 1.11.x para a 1.12.x.
Atualize os clusters de administrador raiz e de administrador da organização.
Receba o nome e o namespace do pool de nós para nós bare metal de administrador raiz e de administrador da organização. Para o cluster root-admin, use o kubeconfig root-admin. O comando a seguir lista um inventário
das máquinas e filtra a lista por máquinas bare metal:
Os campos NODEPOOL_NAME e NODEPOOL_NAMESPACE
são preenchidos com a lista de todos os pools de nós no cluster respectivo
quando o arquivo YAML anterior é implantado.
Um exemplo de arquivo YAML para o cluster de administrador raiz com os nomes reais do pool de nós do administrador raiz e do pool de nós do administrador da organização pode ser assim:
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, duas classes de armazenamento falharam: standard-rwo
e standard-block.
Alternativa:
Exclua o StorageClasses que o job 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 do cluster
(controlador root-admin para clusters de administrador raiz e da organização, controlador org-admin para clusters de sistema e de usuário).
Para a versão 1.12.4, confirme se as classes de armazenamento instaladas têm a anotação disk.gdc.goog/luks-encrypted: definida como "true" (excluindo as classes de armazenamento não LUKS). Se a anotação não estiver definida como "true", repita as etapas 1 e 2.
Reinicie a implantação do netapp-trident e o netapp-trident DaemonSet no cluster.
Verifique se o secret do LUKS foi criado para seus recursos PersistentVolumeClaim (PVC). Cada PVC precisa ter um secret no formato g-luks-$pvc_name.
Verifique se o subcomponente file-netapp-trident não tem erros no status.
Os pools de nós em clusters de usuários que executam a versão 1.27.x do Kubernetes podem não ser inicializados, o que impede que o cluster de usuário processe cargas de trabalho de contêineres.
Alternativa:
Não crie um cluster de usuários com a versão 1.27.x do Kubernetes.
O VMRuntime no cluster de destino (que pode ser de administrador ou de sistema) tem o status VMRuntime.ready = false e network-controller-manager no namespace kube-system está pendente.
A exclusão da implantação network-controller-manager deve recriar a implantação automaticamente com os certificados necessários pelo operador do VMM. A implantação vai entrar no estado Running e, em seguida, o status do VMRuntime vai mudar para ready=true.
Os pods do importador de VM entram em loop de falha, e o volume de dados fica preso no
status de importação por mais de 90 minutos. O status dos pods pode ser assim:
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
Alternativa:
Se a falha estiver na raiz, nas etapas a seguir, substitua KUBECONFIG pelo kubeconfig do administrador raiz.
Se a falha for na organização, nas etapas a seguir, substitua KUBECONFIG pelo kubeconfig do administrador da organização.
O arquivo pode ter a seguinte mensagem na seçã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'
Alternativa:
Verifique o namespace file-system para confirmar se ele não está sendo encerrado no org-admin cluster:
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 na etapa anterior:
Exemplo:
kubectledit-statushsmHSM_NAME-ngpc-system
Atualize o status da última condição de ctmclusterupgraderequest.status.conditions de False para True. Depois disso, o status da última condição hsmupgraderequest.status.conditions também se torna verdadeiro.
Durante um upgrade, o IP de gerenciamento de um servidor fica inacessível, principalmente após um upgrade do SO do switch.
Com o Rocky Linux, quando rotas estáticas são adicionadas, o IP de destino usado
para alcançar as rotas estáticas precisa estar acessível antes da adição delas. Se o switch estiver reiniciando após um upgrade do SO, esse IP de gerenciamento
poderá ficar temporariamente inacessível.
Alternativa:
Estabeleça uma conexão SSH com o servidor usando o endereço IP de dados
e reinicie o serviço de rede para recriar as rotas estáticas ausentes:
Ao implantar a organização gdchservices manualmente, o sistema de tíquetes não tem um upstream íntegro, não há VMs criadas e o pod midserver não está íntegro no cluster gdchservices-system no namespace support.
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, pule as verificações pós-voo. Quando o
upgrade for reiniciado, pule as verificações de simulação usando o
kubeconfig do administrador raiz:
O esquema Portfolio mudou na versão 1.12 do GDC. O campo portfolioName foi refatorado para portfolioID. Encontre o arquivo YAML que contém o recurso personalizado de portfólio mencionado na mensagem de erro. Renomeie o campo portfolioName como portfolioID.
O CR NodeUpgrade menciona version: rocky-86-xyz na especificação, mesmo que o nó em upgrade seja o Ubuntu.
Alternativa:
Não é necessário usar uma solução alternativa porque essas informações são benignas. O nó é atualizado corretamente para uma versão mais recente do Ubuntu.
Os jobs siem-*-preinstall no namespace raiz e org-1 no cluster de administrador raiz falham repetidamente.
Alternativa:
É esperado que os jobs falhem quando o flag de recurso SIEMComponent estiver desativado. As falhas não indicam que o componente está com defeito. A reconciliação do componente SIEM pode ser pausada se o ruído for prejudicial, mas geralmente é recomendável deixar o componente ativado, se possível. Se a reconciliação de componentes estiver pausada, ela precisará ser reativada manualmente quando a instalação do componente SIEM não for mais limitada em upgrades futuros.
Mantenha a saída separada. Corrija um cluster por vez. A saída pode ser semelhante a esta:
NAME
bm-2bca8e3f
bm-4caa4f4e
Crie um playbook e um arquivo de política:
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 seção de inventário anterior precisa ser preenchida como neste exemplo.
Adicione um parágrafo para cada nó encontrado na etapa 1. Você vai trabalhar com um cluster por vez. Portanto, preencha a seção de inventário com nós de um cluster.
Esse problema ocorre se o ambiente foi implantado anteriormente com a versão 1.11
e depois atualizado para a 1.12. Ao criar um cluster ou uma organização em
uma versão 1.12.x, o Rocky OS em vez do Ubuntu OS é selecionado para
provisionamento de nós de bare metal e máquina virtual devido à versão do Rocky OS
especificada nas CRs ReleaseMetadata e
Userclustermetadata.
Alternativa:
Aplique a solução alternativa a seguir antes de criar uma nova organização:
Verifique se há CRs OrganizationUpgrade 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 para a equipe de engenharia antes de seguir para as próximas etapas.
Remova todos os CRs OrganizationUpgrade para evitar upgrades acidentais do SO do nó:
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 de destino do GDC para a criação da nova organização. Deve haver um ReleaseMetadata correspondente para essa versão de destino:
TARGET_RELEASE=
Identifique a CR OSImageMetadata mais recente para o SO Ubuntu de destino no cluster de administrador raiz e defina a variável OS_VERSION:
Verifique se a variável usa a mesma versão principal.secundária.patch,
como 1.12.4, que o TARGET_RELEASE. Caso contrário, encaminhe para a equipe de engenharia antes de prosseguir.
Atualize o ReleaseMetadata de destino para usar o Ubuntu
OS_VERSION no cluster de administrador raiz:
Atualize o UserclusterMetadata de destino 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 VM locais são importadas usando a
CLI gdcloud compute images import, o status da importação fica
preso em WaitingForTranslationVM ou
ImportJobNotCreated. Isso acontece porque o disco temporário criado para tradução ou importação usa o mesmo tamanho da imagem qcow2 ou bruta, mas o LUKS adiciona uma sobrecarga de alguns MiBs que causa falha no provisionamento do disco.
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 VirtualMachineImageImport original criado automaticamente pela
CLI tiver minimumDiskSize como X Gi, crie um novo com
X+1 Gi. O valor é baseado no tamanho da imagem que está sendo importada. No
caso de qcow2, seria o tamanho virtual. Por exemplo, 20Gi deve ser
substituído por 21Gi.
Substitua os valores do marcador de posição com base em como a CLI foi chamada.
Se o objeto não estiver presente, acione o comando gdcloud compute images import ...
novamente. Depois que a saída do console passar de
Uploading image to ... para Image import has started for ...,
pressione CTRL + C para que a imagem local seja enviada por upload para o armazenamento de objetos e
o VirtualMachineImageImport seja preservado para referência ao
criar um novo.
Crie um novo VirtualMachineImageImport com um minimumDiskSize maior:
O pod importer-image-import-$VMII no namespace 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 status False e motivo TranslationInProgress após 2 horas do início da importação.
Alternativa:
Para melhorar a velocidade, modifique o tamanho mínimo do disco da imagem para 200Gi da seguinte maneira:
Para excluir e aplicar o ValidatingWebhookConfiguration, você precisa do kubeconfig de administrador do cluster para o cluster de administrador da organização. Você pode acessar o seguinte runbook IAM-R0004.
Se você usar gdcloud para iniciar a importação, não será possível fornecer o parâmetro minimumDiskSize. Você precisa criar um objeto VMII e modificá-lo conforme mostrado no comando anterior.
O processo de VirtualMachineImageImport continua, mas fica preso novamente em uma etapa posterior. No namespace do projeto no cluster do sistema, o job image-import-$VMII falha continuamente com o erro: error: stream error: stream ID x; NO_ERROR; received from peer. Nesse ponto, a importação da imagem é concluída. A imagem final é enviada para o armazenamento de objetos, mas o VirtualMachineImage está faltando. É possível criar um VirtualMachineImage manualmente da seguinte forma:
`$NAME` precisa corresponder a `VMII.ImageMetadata.Name`, e `$OS_NAME` pode ser um destes: [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`] e precisa corresponder ao tipo da imagem importada.
A implantação istio-eastwestgateway no namespace istio-system está travada, com eventos de pod mostrando um erro Back-off pulling image "auto" de kubelet.
Para diagnosticar o problema, verifique se o mutatingwebhookconfiguration chamado istio-revision-tag-default existe no mesmo cluster que
a implantação de gateway travada.
Modifique o configMap cortex-config no cluster do sistema
e defina o tempo limite do memcached no index_cache como dois segundos para
que a configuração do index_cache fique assim:
O local do instalador do fluent-bit mudou 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 encontra o instalador porque esse padrão não corresponde mais.
O local do instalador do Nessus mudou para operations_center\bin\NessusAgent-x64.msi.
O Copy-ConfigHostFiles.ps1 espera que o instalador do cliente
corresponda ao nome do arquivo /NessusAgent-10.4.1-x64.msi.
O instalador não encontra o instalador porque esse padrão não corresponde mais.
Extraia as credenciais de login da interface de gerenciamento do StorageGRID do secret gpc-system/objectstorage-breakglass-root-level1 no cluster root-admin.
Faça login na interface de gerenciamento do StorageGRID com as credenciais da etapa anterior. O URL está no status ObjectStorageSite:
Acesse a guia Configuração e clique em Grupos de alta disponibilidade.
Abra a visualização de detalhes de cada grupo de alta disponibilidade e anote o endereço IP virtual (VIPs).
Crie um novo grupo de alta disponibilidade:
Nome do grupo: o padrão de nome é ORGANIZATION_NAME-ha
. Nesse caso, é org-2-ha.
Descrição do grupo: use grupos de HA atuais para o padrão de descrição.
Interfaces: selecione todos os eth2.
Ordem de prioridade: a interface principal precisa ter a maior prioridade.
SubnetCIDR: esse campo é preenchido automaticamente pelo StorageGRID.
Verifique se a sub-rede corresponde ao status.ipv4SubnetStatus.cidrBlock
no SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtual: o próximo IP no intervalo de IP disponível. O IP não pode entrar em conflito com o IP reservado, o IP do cliente do nó de administrador e os VIPs dos grupos de alta disponibilidade atuais.
Alterne as credenciais de emergência do StorageGRID.
Ao fazer upgrade da organização raiz de 1.12.2 para 1.12.4, o subcomponente
iac-gitlab tem um status de reconciliação em andamento.
Para diagnosticar o problema, verifique os registros do Prometheus. Por exemplo:
Consulte a mensagem de erro anterior e anote o namespace e o nome da
implantação. Neste exemplo, o NAME é
iam-authzpdp-backend-server e o NAMESPACE é
iam-system.
Observe o pod que não tem todos os contêineres prontos. Nesse caso, o POD_NAME é iam-authzpdp-backend-server-6875654c4b-pvscg, que tem um dos dois contêineres não prontos, mostrado pelo status 1/2. Se houver mais de um pod assim, repita a próxima etapa para cada pod afetado.
Exclua o pod que não está totalmente íntegro:
kubectldeletepod-nNAMESPACEPOD_NAME>
Execute o comando da etapa 2 novamente. Todos os pods devem estar íntegros agora. Essa etapa pode levar alguns minutos.
Se o pod excluído não for substituído por um pod íntegro, abra um tíquete de suporte.
Durante o upgrade da organização do locatário da versão 1.12.2 para a 1.12.4, o upgrade do subcomponente opa gatekeeper falha com um ReconciliationError.
Alternativa:
Edite o objeto mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg do cluster de usuário afetado. Se houver mais de um cluster de usuário afetado, repita as etapas para cada um deles:
Edite a seção webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values para adicionar os dois valores a seguir:
Ao fazer upgrade da versão 1.12.2 para a 1.12.4, o ansibleplaybook não é atualizado como parte do upgrade do cluster. As correções atualizadas no ansibleplaybook não são aplicadas e bloqueiam a política do SO que executa a versão anterior do ansibleplaybook.
Alternativa:
Exclua o job do Kubernetes create-ansible-playbooks:
Ao criar uma organização, talvez o tempo limite do subcomponente core-dns seja atingido nos registros:
[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
Alternativa:
Atualize os serviços gpc-coredns-forwarder-udp e gpc-coredns-forwarder-tcp do cluster de administrador raiz e adicione os novos intervalos de IP aos intervalos de origem do balanceador de carga.
Se as mudanças de CR forem substituídas, pause o subcomponente dns-core
com a anotação lcm.private.gdc.goog/paused="true".
Ao fazer upgrade da versão 1.12.2 para a 1.12.4, o subcomponente file-netapp-trident fica preso na exclusão de StorageClasses. Ele mostra o seguinte status:
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
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
Exclua o StorageClasses que o job 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 do cluster
(controlador root-admin para clusters de administrador raiz e da organização, controlador org-admin para clusters de sistema e de usuário):
Os pods primary-prometheus-shardX-replicaX estão visíveis nos namespaces
obs-system e mon-system. Se o primary-prometheus-shardX-replicaX existir apenas no namespace obs-system após um upgrade para a versão 1.12, isso será um problema desconhecido diferente, e a solução alternativa não deverá ser realizada.
O comportamento esperado é que
primary-prometheus-shardX-replicaX exista apenas no
namespace mon-system depois que o upgrade para a versão 1.12 for concluído.
Alternativa:
Exclua manualmente os primary-prometheus-shardX-replicaX
StatefulSets no namespace obs-system.
Não exclua os StatefulSets primary-prometheus-shardX-replicaX
no namespace 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. Esse problema
acontece se um ClusterCIDRConfig for criado ao mesmo tempo
em que os pods ipam-controller estão fazendo bootstrap. A criação do cluster está travada no estado de reconciliação:
Verifique se o objeto ClusterCIDRConfig foi criado no
cluster:
Execute "describe" em um dos objetos de nó do cluster que está
preso na reconciliação e verifique se um evento CIDRNotAvailable está
presente no objeto de nó:
O MonitoringTarget mostra um status Not Ready quando os clusters de usuários estão sendo criados, fazendo com que as APIs pré-treinadas mostrem continuamente um estado Enabling na interface do usuário.
Alternativa:
Abra o menu no navegador Chrome (ícone de três pontos).
Clique em Mais ferramentas > Ferramentas para desenvolvedores para abrir o console.
Clique na guia Rede no console.
Encontre as solicitações ai-service-status.
Clique na guia Resposta em uma solicitação ai-service-status para mostrar o conteúdo dela.
Verifique se tudo parece pronto, exceto os componentes MonitoringTarget e LoggingTarget.
Ao fazer upgrade do armazenamento de objetos, talvez você veja 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
Alternativa:
Verifique se cada nó tem as credenciais de SSH correspondentes armazenadas em um secret.
Durante os upgrades, o cluster do banco de dados de tradução é recriado, o que faz com que o segredo secret-store do cluster do sistema ODS fique desatualizado e dessincronizado. Por isso, o pod e o serviço de front-end de tradução não são inicializados.
O servidor não consegue se conectar ao gerenciador de chaves, o que impede que o estado do servidor fique disponível. Esse problema faz com que o job server-encrypt-and-create-logical-drive falhe e o cluster de administrador não fique pronto. Talvez você veja um erro nos registros do job como este:
O Loki tem apenas um volume permanente (PV) para registros de gravação antecipada (WAL) e índices. O WAL pode preencher o PV se um pod do Loki não conseguir se conectar ao bucket de armazenamento por horas. Se o PV não tiver mais espaço, o Loki não poderá ser recuperado, a menos que você exclua o PV e reinicie o StatefulSet.
Alternativa:
Para recuperar um pod do Loki desse estado, reduza o escalonamento do StatefulSet correspondente e exclua o PV sem espaço restante.
Siga estas etapas para recuperar o pod do Loki:
Verifique se o contêiner da ferramenta de E/S está instalado na estação de trabalho. Para mais detalhes, consulte o manual de operações OOPS-P0065.
Para receber as permissões necessárias para editar recursos, peça ao administrador de segurança para conceder a você os seguintes papéis:
observability-viewer
observability-admin
Defina a variável de ambiente KUBECONFIG com o caminho para o arquivo kubeconfig no cluster de administrador raiz. Para mais detalhes, consulte o runbook IAM-R0004.
Defina a variável de ambiente ORG_NAME com o nome da organização afetada.
Salve o conteúdo a seguir em um arquivo YAML chamado log-admin-overrides.yaml:
Defina a variável de ambiente KUBECONFIG com o caminho para o arquivo kubeconfig no cluster em que o pod do Loki afetado está sendo executado. Para mais detalhes, consulte o runbook 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 arquivo kubeconfig no cluster de administrador da organização afetada. Para mais detalhes, consulte o runbook IAM-R0004.
Edite o conteúdo no arquivo YAML log-admin-overrides.yaml da seguinte maneira:
Os jobs são programados continuamente. Assim que um job é encerrado, um novo é programado. Os jobs que estão sendo programados 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
Alternativa:
Pause os seguintes subcomponentes:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Retome os subcomponentes sempre que houver uma mudança no secret fleet-info no cluster de administrador raiz. Esse problema ocorre quando há uma mudança nas chaves de gerenciamento da instância, como kr get managementswitches -A, ou uma mudança em qualquer cidrclaim no namespace da organização.
Retome os subcomponentes sempre que houver uma mudança em qualquer recurso NodePool no cluster de administrador da organização. Cancele a pausa dos subcomponentes antes de começar.
Ao fazer upgrade da versão 1.12.2 para a 1.12.4, um upstream íntegro para o ServiceNow não está disponível. Talvez você veja 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. A vinculação de volume indica que o PVC está ativado para LUKS.
O reconciliador procura um secret com as senhas do LUKS. Como a vinculação de volume diz que o LUKS está ativado e a classe de armazenamento não está, a senha secreta não é criada.
Alternativa:
Receba o Kubeconfig do cluster raiz ou de administrador da organização em que o problema aparece:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Exclua e recrie a classe de armazenamento system-performance-rwo:
Ao fazer upgrade da versão 1.12.2 para a 1.12.4, o upgrade da organização fica preso em uma etapa NodeUpgrade, e a tarefa de upgrade do nó mostra o seguinte erro:
O kubelet continua imprimindo o seguinte registro 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 é congelado, impedindo que kubelet exclua o pod cgroup.
Alternativa:
Use o script a seguir para encontrar o processo que está bloqueando a exclusã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 do congelador usando cat freezer.state. O estado precisa ser FROZEN.
Echo "THAWED" > freezer.state
O cgroup foi excluído. Kubelet para de enviar spam para o registro.
Inspecione as anotações e os rótulos do projeto gdch-perftest e do bucket perftest-bucket-reports do PTaaS no namespace perftest gdch-perftest. O bucket pode não ter o rótulo 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 estes rótulos 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.
Mude 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."],[],[]]
