Problemas conhecidos dos clusters do Anthos em bare metal

Version 1.11 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Configuração

Especificações do plano de controle e do balanceador de carga

As especificações do plano de controle e do pool de nós do balanceador de carga são especiais. Essas especificações declaram e controlam os recursos essenciais do cluster. A fonte canônica desses recursos é as respectivas seções no arquivo de configuração do cluster.

• spec.controlPlane.nodePoolSpec
• spec.loadBalancer.nodePoolSpec

Consequentemente, não modifique o plano de controle de nível superior e os recursos do pool de nós do balanceador de carga diretamente. Modifique as seções associadas no arquivo de configuração do cluster.

Instalação

bmctl sai antes de a criação do cluster ser concluída

A criação do cluster pode falhar para clusters do Anthos na versão bare metal 1.11.0. Esse problema está corrigido nos clusters do Anthos na versão bare metal 1.11.1. Em alguns casos, o comando bmctl create cluster sai antecipadamente e grava erros como este nos registros:

Error creating cluster: error waiting for applied resources: provider cluster-api
watching namespace USER_CLUSTER_NAME not found in the target cluster

A operação com falha produz artefatos, mas o cluster não está operacional. Se esse problema afetar você, use as etapas a seguir para limpar os artefatos e criar um cluster:

1. Para excluir os artefatos do cluster e redefinir a máquina do nó, execute o seguinte comando:

   bmctl reset -c USER_CLUSTER_NAME
   

2. Para iniciar a operação de criação do cluster, execute o seguinte comando:

   bmctl create cluster -c USER_CLUSTER_NAME --keep-bootstrap-cluster
   

   A sinalização --keep-bootstrap-cluster será importante se esse comando falhar.

   Se o comando de criação do cluster for bem-sucedido, pule para as etapas restantes. Caso contrário, continue.

3. Execute o seguinte comando para descobrir a versão do cluster de inicialização:

   kubectl get cluster USER_CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \
       --kubeconfig bmctl-workspace/.kindkubeconfig \
       -o=jsonpath='{.status.anthosBareMetalVersion}
   

   A saída precisa ser 1.11.0. Se a saída não for 1.11.0, aguarde um ou dois minutos e tente novamente.

4. Para mover recursos manualmente do cluster de inicialização para o cluster de destino, execute o seguinte comando:

   bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig --to-kubeconfig \
       bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \
       -n USER_CLUSTER_NAMESPACE
   

5. Para excluir o cluster de inicialização, execute este comando:

   bmctl reset bootstrap
   

A instalação informa erro de reconciliação do ambiente de execução da VM

A operação de criação do cluster pode informar um erro semelhante a este:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:"
"message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\":
failed to call webhook: Post \"https://vmruntime-webhook-service.kube-
system.svc:443/validate-vm-cluster-gke-io-v1-vmruntime?timeout=10s\": dial tcp
10.95.5.151:443: connect: connection refused" "name"="xxx"
"reason"="ReconciliationError"

Esse erro é benigno e pode ser ignorado com segurança.

A criação de cluster falha ao usar proxy multi-NIC, containerd e HTTPS

A criação de cluster falha quando você tem a seguinte combinação de condições:

• O cluster é configurado para usar containerd como ambiente de execução do contêiner. nodeConfig.containerRuntime é definido como containerd no arquivo de configuração do cluster, o padrão para clusters do Anthos em bare metal na versão 1.11.

• O cluster é configurado para fornecer várias interfaces de rede, multi-NIC, para pods (clusterNetwork.multipleNetworkInterfaces definido como true no arquivo de configuração do cluster).

• O cluster é configurado para usar um proxy, em que spec.proxy.url é especificado no arquivo de configuração do cluster. Mesmo que a criação do cluster falhe, essa configuração é propagada quando você tenta criar um cluster. É possível ver essa configuração de proxy como uma variável de ambiente HTTPS_PROXY ou na configuração containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Como solução alternativa para esse problema, anexe CIDRs de serviço (clusterNetwork.services.cidrBlocks) à variável de ambiente NO_PROXY em todas as máquinas de nó.

Falha nos sistemas com a configuração umask restritiva

Os clusters do Anthos na versão bare metal 1.10.0 apresentaram um recurso de plano de controle sem raiz que executa todos os componentes do plano de controle como um usuário não raiz. A execução dos componentes como um usuário não raiz pode causar falhas de instalação ou de upgrade em sistemas com uma configuração umask mais restritiva de 0077.

A solução alternativa a falhas de criação de cluster é redefinir os nós do plano de controle e alterar a configuração umask para 0022 em todas as máquinas do plano de controle. Após a atualização das máquinas, tente instalar novamente.

Também é possível alterar as permissões de diretório e de arquivo de /etc/kubernetes nas máquinas do plano de controle para que a instalação ou upgrade continue.

• Torne /etc/kubernetes e todos os subdiretórios globalmente legíveis: chmod o+rx.
• Transfira todos os arquivos do usuário root no diretório (recursivamente) /etc/kubernetes legível (chmod o+r). Exclua os arquivos de chave privada (.key) dessas alterações, porque eles já foram criados com as permissões e a propriedade corretas.
• Torne o /usr/local/etc/haproxy/haproxy.cfg legível.
• Torne o /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml legível.

Incompatibilidade com o grupo de controle v2

O grupo de controle v2 (cgroup v2) não é compatível com clusters do Anthos em bare metal. A presença de /sys/fs/cgroup/cgroup.controllers indica que seu sistema usa o cgroup v2.

As verificações de simulação verificam se o cgroup v2 não está em uso na máquina de cluster.

Mensagens de erro benignas durante a instalação

Ao examinar os registros de criação de cluster, talvez você note falhas temporárias sobre o registro de clusters ou a chamada de webhooks. Esses erros podem ser ignorados com segurança, porque a instalação tentará novamente até que as operações sejam concluídas.

Verificações de simulação e credenciais da conta de serviço

Para instalações acionadas por clusters administrativos ou de clusters híbridos (em outras palavras, clusters não criados com bmctl, como clusters de usuários), a verificação de simulação não verifica as credenciais da conta de serviço do Google Cloud Platform ou suas permissões associadas.

Application Default Credentials e bmctl

bmctl usa Application Default Credentials (ADC, na sigla em inglês) para validar o valor de local da operação do cluster no cluster spec quando não está definido como global.

Para que as ADC funcionem, você precisa apontar a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para um arquivo de credencial de conta de serviço ou executar gcloud auth application-default login.

Serviço do Docker

Em máquinas de nó de cluster, se o executável do Docker estiver presente na variável de ambiente do PATH, mas o serviço do Docker não estiver ativo, a verificação de simulação falhará e informará que o Docker service is not active. Para corrigir esse erro, remova o Docker ou ative o serviço do Docker.

Como instalar no vSphere

Ao instalar clusters do Anthos em Bare Metal em VMs do vSphere, é preciso desativar as sinalizações tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation. Essas sinalizações são relacionadas à descarga de segmentação de hardware feita pelo vSphere driver VMXNET3 e não funcionam com o túnel GENEVE de clusters Anthos no ambiente Bare Metal.

Execute o comando a seguir em cada nó para verificar os valores atuais dessas sinalizações. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Substitua NET_INTFC pela interface de rede associada ao endereço IP do nó.

No RHEL 8.4, ethtool às vezes mostra que essas sinalizações estão desativadas, mas na realidade não estão. Para ter certeza de que estão desativadas, ative-as e depois desative-as com os comandos a seguir.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Essa alteração de sinalização não permanece nas reinicializações. Configure os scripts de inicialização para definir explicitamente esses sinalizadores quando o sistema for inicializado.

Upgrades e atualizações

O detector de problemas de nós não é ativado por padrão após upgrades de clusters

Ao fazer upgrade de clusters do Anthos em bare metal, o detector de problemas de nós não é ativado por padrão. O problema é relevante para upgrades das versões 1.10 à 1.12.1 e foi corrigido na versão 1.12.2.

Para ativar o detector de problemas de nós:

1. Verifique se o serviço node-problem-detector systemd está em execução no nó.

   1. Use o comando ssh e conecte-se ao nó.

   2. Verifique se o serviço node-problem-detector systemd está em execução no nó.

   systemctl is-active node-problem-detector
   

   Se o resultado do comando mostrar inactive, o detector não está sendo executado no nó.

2. Para ativar o detector de problemas de nós, use o comando kubectl edit e edite o ConfigMap node-problem-detector-config. Para saber mais, consulte Detector de problemas de nós.

O upgrade de clusters para a versão 1.11.2 ou superior falha quando o Anthos VM Runtime está ativado

Nos clusters do Anthos na versão bare metal 1.11.2, todos os recursos relacionados ao ambiente de execução da VM do Anthos são migrados para o namespace vm-system. Se você tiver o Anthos VM Runtime ativado em um cluster da versão 1.11.1 ou anterior, o upgrade para a versão 1.11.2 ou mais recente falhará a menos que você desative o Anthos VM Runtime. Quando você é afetado por esse problema, a operação de upgrade informa o seguinte erro:

Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from
version 1.11.0 to version 1.11.2: please disable VMruntime before upgrade to
1.11.2 and higher version

Para desativar o Anthos VM Runtime:

1. Edite o recurso personalizado VMRuntime:

   kubectl edit vmruntime
   

2. Defina enabled como false na especificação:

   apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
   spec:
     enabled: false
   ...
   

3. Salve o recurso personalizado no seu editor.

4. Depois que o upgrade do cluster for concluído, reative o ambiente de execução da VM do Anthos.

Para mais informações, consulte Como trabalhar com cargas de trabalho baseadas em VM.

O upgrade parou em error during manifests operations

Em algumas situações, os upgrades de cluster não são concluídos e a CLI bmctl não responde. Esse problema pode ser causado por um recurso atualizado incorretamente. Para saber se você foi afetado por esse problema e corrigi-lo, siga estas etapas:

1. Verifique os registros anthos-cluster-operator e procure erros semelhantes às seguintes entradas:

   controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
   ...
   {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
   

   Essas entradas são um sintoma de um recurso atualizado incorretamente, em que {RESOURCE_NAME} é o nome do recurso com problema.

2. Se você encontrar esses erros nos registros, use kubectl edit para remover a anotação kubectl.kubernetes.io/last-applied-configuration do recurso contido na mensagem do registro.

3. Salve e aplique as alterações no recurso.

4. Tente fazer o upgrade do cluster novamente.

Os upgrades são bloqueados para clusters com recursos que usam o Anthos Network Gateway

Os upgrades de cluster da 1.10.x para 1.11.x falham para clusters que usam o gateway NAT de saída ou o balanceamento de carga em pacote com o BGP. Esses recursos usam o Anthos Network Gateway. Os upgrades de cluster ficam travados na mensagem de linha de comando Waiting for upgrade to complete... e os erros anthos-cluster-operator registram o seguinte:

apply run failed ...
MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable...

Cuidado: a solução alternativa a seguir exclui manifestos e causa um breve período de inatividade de 30 a 60 segundos para balanceamento de carga em pacote com o BGP. As sessões do BGP são descartadas e restabelecidas, e os serviços do LoadBalancer ficam indisponíveis durante esse período. A função é restaurada quando o anthos-cluster-operator reinstala os manifestos.

Para desbloquear o upgrade, execute os seguintes comandos no cluster que você está fazendo upgrade:

kubectl -n kube-system delete deployment ang-controller-manager-autoscaler

kubectl -n kube-system delete deployment ang-controller-manager

kubectl -n kube-system delete ds ang-node

bmctl update não remove bloqueios de manutenção

O comando bmctl update não pode remover nem modificar a seção maintenanceBlocks da configuração de recursos do cluster. Veja mais informações, incluindo instruções sobre a remoção de nós do modo de manutenção em Colocar nós no modo de manutenção.

Não é possível iniciar a diminuição do nó quando ele está fora de alcance

O processo de drenagem para nós não será iniciado se o nó estiver fora de alcance dos clusters do Anthos em bare metal. Por exemplo, se um nó ficar off-line durante um processo de upgrade de cluster, ele poderá fazer com que o upgrade pare de responder. Isso é raro. Para minimizar a probabilidade de encontrar esse problema, verifique se os nós estão funcionando corretamente antes de iniciar um upgrade.

Operação

Os nós não são restritos se você não usar o procedimento do modo de manutenção

Se você usar manualmente kubectl cordon em um nó, os Clusters do Anthos em bare metal podem desassociar o nó antes de estar tudo pronto para reconciliar o estado esperado. Para Clusters do Anthos em bare metal versão 1.12.0 e anterior, use o modo de manutenção para restringir e drenar nós com segurança. Na versão 1.12.1 (anthosBareMetalVersion: 1.12.1) ou mais recente, os Clusters do Anthos em bare metal não cancelam os nós inesperadamente quando você usa kubectl cordon.

Os clusters de administrador da versão 11 que usam um espelho de registro não podem gerenciar os clusters da versão 1.10

Se o cluster de administrador estiver na versão 1.11 e usar um espelho de registro, não será possível gerenciar clusters de usuário que estão em uma versão secundária menor. Esse problema afeta as operações de redefinição, atualização e upgrade no cluster de usuários.

Para determinar se esse problema afeta você, verifique se há operações de cluster nos registros, como criar, fazer upgrade ou redefinir. Por padrão, esses registros ficam localizados na pasta bmctl-workspace/CLUSTER_NAME/. Se você for afetado pelo problema, os registros contêm a seguinte mensagem de erro:

flag provided but not defined: -registry-mirror-host-to-endpoints

Secret do kubeconfig substituído

O comando bmctl check cluster, quando executado em clusters de usuários, substitui o secret do kubeconfig do cluster de usuário pelo kubeconfig do cluster de administrador. A substituição do arquivo causa falhas nas operações padrão do cluster, como atualização e upgrade, para os clusters de usuário afetados. Esse problema se aplica aos clusters do Anthos na versão bare metal 1.11.1 e anteriores.

Para determinar se esse problema afeta um cluster de usuário, execute o seguinte comando:

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

Substitua:

• ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
• USER_CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster para os clusters do Anthos em bare metal são o nome do cluster precedido por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.
• USER_CLUSTER_NAME: o nome do cluster de usuário a ser verificado.

Se o nome do cluster na saída (consulte contexts.context.cluster no exemplo de saída a seguir) for o nome do cluster de administrador, o cluster de usuário especificado será afetado.

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

As etapas a seguir restauram a função em um cluster de usuário afetado (USER_CLUSTER_NAME):

1. Localizar o arquivo kubeconfig do cluster de usuário.

   Os clusters do Anthos em bare metal geram o arquivo kubeconfig na estação de trabalho de administrador quando você cria um cluster. Por padrão, o arquivo está no diretório bmctl-workspace/USER_CLUSTER_NAME.

2. Verifique se o kubeconfig está correto no cluster de usuário kubeconfig:

   kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE
   

   Substitua PATH_TO_GENERATED_FILE pelo caminho para o arquivo Kubeconfig do cluster de usuário. A resposta retorna detalhes sobre os nós do cluster de usuário. Confirme se os nomes de máquina estão corretos para o cluster.

3. Execute o seguinte comando para excluir o arquivo kubeconfig corrompido no cluster de administrador:

   kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
   

4. Execute o seguinte comando para salvar o secret kubeconfig correto de volta no cluster de administrador:

   kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
       --from-file=value=PATH_TO_GENERATED_FILE
   

Como tirar um snapshot como um usuário de login não raiz

Se você usar o containerd como ambiente de execução de contêiner, a execução do snapshot como usuário não raiz exigirá que /usr/local/bin esteja no PATH do usuário. Caso contrário, ocorrerá uma falha com crictl: command not found.

Quando você não estiver conectado como o usuário raiz, sudo será usado para executar os comandos de snapshot. O PATH sudo pode ser diferente do perfil raiz e pode não conter /usr/local/bin.

É possível corrigir esse erro atualizando secure_path em /etc/sudoers para incluir /usr/local/bin. Como alternativa, crie um link simbólico para crictl em outro diretório /bin.

Ambiente de execução de VM do Anthos

• Reiniciar um pod faz com que as VMs nele alterem os endereços IP ou percam os endereços IP completamente. Se o endereço IP de uma VM for alterado, isso não afetará a acessibilidade dos aplicativos de VM expostos como um serviço do Kubernetes. Se o endereço IP for perdido, execute dhclient a partir da VM para adquirir um endereço IP para a VM.

Geração de registros e monitoramento

Faturamento inesperado de monitoramento

Para os clusters do Anthos nas versões bare metal 1.10 e 1.11, alguns clientes encontraram um faturamento alto inesperado para Metrics volume na página Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:

• A geração de registros e o monitoramento de aplicativos estão ativados (enableStackdriverForApplications=true)

• Os pods do aplicativo têm a anotação prometheus.io/scrap=true

Para confirmar se você foi afetado por esse problema, liste as métricas definidas pelo usuário. Se você vir faturamento para métricas indesejadas, esse problema se aplica a você.

Para garantir que você não receba cobranças adicionais pelo Metrics volume ao usar a geração de registros e o monitoramento de aplicativos, siga estas etapas:

1. Encontre os pods e os serviços de origem que têm as métricas faturadas indesejadas.

   kubectl --kubeconfig KUBECONFIG get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
   kubectl --kubeconfig KUBECONFIG get services -A -o yaml | grep 'prometheus.io/scrape: "true"'
   

2. Remova a anotação prometheus.io/scrap=true do pod ou do serviço.

As edições em metrics-server-config não são mantidas.

Uma alta densidade de pods pode, em casos extremos, criar uma sobrecarga excessiva de geração de registros e monitoramento, o que pode fazer com que o servidor de métricas seja interrompido e reiniciado. É possível editar o ConfigMap metrics-server-config para alocar mais recursos para manter o Metrics Server em execução. No entanto, devido à reconciliação, as edições feitas em metrics-server- config poderão ser revertidas para o valor padrão durante uma atualização de cluster ou operação de upgrade. O Metrics Server não é afetado imediatamente, mas na próxima vez que for reiniciado, ele capta o ConfigMap revertido e está vulnerável a sobrecargas excessivas.

Como solução alternativa, é possível criar um script para a edição do ConfigMap e executá-lo com atualizações ou upgrades do cluster.

Métricas com uso suspenso afetam o painel do Cloud Monitoring

Várias métricas do Anthos estão obsoletas. A partir dos clusters do Anthos na versão Bare Metal 1.11, os dados não são mais coletados para essas métricas obsoletas. Se você usar essas métricas em qualquer uma das políticas de alertas, não haverá dados para acionar a condição de alerta.

A tabela a seguir lista as métricas individuais que estão obsoletas e as métricas que as substituem.

Métricas descontinuadas	Métrica de substituição
kube_daemonset_updated_number_scheduled	kube_daemonset_status_updated_number_scheduled
kube_node_status_allocatable_cpu_cores kube_node_status_allocatable_memory_bytes kube_node_status_allocatable_pods	kube_node_status_allocatable
kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_node_status_capacity_pods	kube_node_status_capacity

Nos clusters do Anthos em versões bare metal anteriores à 1.11, o arquivo de definição de política para o alerta Anthos on baremetal node cpu usage exceeds 80 percent (critical) recomendado usa as métricas obsoletas. O arquivo de definição JSON node-cpu-usage-high.json foi atualizado para as versões 1.11.0 e posteriores.

Siga as etapas abaixo para migrar para as métricas de substituição:

1. No console do Google Cloud, selecione Monitoramento ou clique no botão a seguir:

   Acessar Monitoring

2. No painel de navegação, selecione Painéis e exclua o painel Status do nó do cluster do Anthos.

3. Clique na guia Biblioteca de amostra e reinstale o painel Status do nó do cluster do Anthos.

4. Siga as instruções em Como criar políticas de alerta para criar uma política usando o arquivo de definição de política node-cpu-usage-high.json atualizado.

Dados de métrica desconhecidos no Cloud Monitoring

Os dados nos clusters da versão 1.10.x do Cloud Monitoring podem conter entradas de métricas de resumo irrelevantes, como:

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

• apiserver_admission_step_admission_duration_seconds_summary
• go_gc_duration_seconds
• scheduler_scheduling_duration_seconds
• gkeconnect_http_request_duration_seconds_summary
• alertmanager_nflog_snapshot_duration_seconds_summary

Embora essas métricas de tipo de resumo estejam na lista de métricas, elas não são compatíveis com gke-metrics-agent no momento.

Interrupções intermitentes da exportação de métricas

Os clusters do Anthos na versão bare metal 1.11.0 podem sofrer interrupções na exportação normal e contínua de métricas ou falta de métricas em alguns nós. Se esse problema afetar os clusters, você poderá ver lacunas nos dados das seguintes métricas (no mínimo):

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

Para corrigir esse problema, faça upgrade dos clusters para a versão 1.11.1 ou mais recente.

Se não for possível fazer upgrade, execute as seguintes etapas como uma solução alternativa:

1. Abra o recurso stackdriver para edição:

   kubectl -n kube-system edit stackdriver stackdriver
   

2. Para aumentar a solicitação de CPU de gke-metrics-agent de 10m para 50m, adicione a seguinte seção resourceAttrOverride ao manifesto stackdriver:

   spec:
     resourceAttrOverride:
       gke-metrics-agent/gke-metrics-agent:
         limits:
           cpu: 100m
           memory: 4608Mi
         requests:
           cpu: 50m
           memory: 200Mi
   

   O recurso editado ficará semelhante ao seguinte:

   spec:
     anthosDistribution: baremetal
     clusterLocation: us-west1-a
     clusterName: my-cluster
     enableStackdriverForApplications: true
     gcpServiceAccountSecretName: ...
     optimizedMetrics: true
     portable: true
     projectID: my-project-191923
     proxyConfigSecretName: ...
     resourceAttrOverride:
       gke-metrics-agent/gke-metrics-agent:
         limits:
           cpu: 100m
           memory: 4608Mi
         requests:
           cpu: 50m
           memory: 200Mi
   

3. Salve as alterações e feche o editor de texto.

4. Para verificar se as mudanças entraram em vigor, execute o seguinte comando:

   kubectl -n kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
   

   O comando encontrará cpu: 50m se as edições tiverem entrado em vigor.

Rede

Os serviços do balanceador de carga não funcionam com contêineres na rede do host do plano de controle

Há um bug em anetd em que os pacotes são descartados para os serviços LoadBalancer se os pods de back-end estão em execução no nó do plano de controle e usando o campo hostNetwork: true na especificação do contêiner.

O bug não está presente na versão 1.13 ou mais recente.

As soluções alternativas a seguir podem ajudar se você usar um serviço LoadBalancer com suporte de pods hostNetwork:

1. Executar em nós de trabalho (não em nós do plano de controle)

2. Use externalTrafficPolicy: local na especificação do serviço e verifique se as cargas de trabalho são executadas nos nós do balanceador de carga

Falha NAT com muitas conexões paralelas

Para um determinado nó no cluster, o endereço IP do nó fornece conversão de endereços de rede (NAT, na sigla em inglês) para pacotes roteados para um endereço fora do cluster. Da mesma forma, quando pacotes de entrada inserem um nó de balanceamento de carga configurado para usar o balanceamento de carga em pacote (spec.loadBalancer.mode: bundled), a conversão de endereços de rede de origem (SNAT, na sigla em inglês) encaminha os pacotes para o endereço IP do nó antes de são encaminhados para um pod de back-end.

O intervalo de portas para NAT usado por clusters do Anthos em bare metal é 32768–65535. Esse intervalo limita o número de conexões paralelas a 32.767 por protocolo nesse nó. Cada conexão precisa de uma entrada na tabela conntrack. Se você tiver muitas conexões de curta duração, a tabela conntrack ficará sem portas para NAT. Um coletor de lixo limpa as entradas desatualizadas, mas a limpeza não é imediata.

Quando o número de conexões no nó se aproximar de 32.767, você começará a notar quedas de pacotes em conexões que precisam de NAT. A solução para esse problema é redistribuir o tráfego para outros nós.

Para identificar esse problema, execute o seguinte comando no pod anetd do nó problemático:

kubectl -n kube-system anetd-XXX -- hubble observe --from-ip $IP --to-ip $IP -f

Você verá erros no seguinte formato:

No mapping for NAT masquerade DROPPED

IP de origem do cliente com balanceamento de carga em pacote de camada 2

Definir a política de tráfego externo como Local pode causar erros de roteamento, como No route to host, para balanceamento de carga em pacote de camada 2. A política de tráfego externo é definida como Cluster (externalTrafficPolicy: Cluster), por padrão. Com essa configuração, o Kubernetes processa o tráfego em todo o cluster. Serviços do tipo LoadBalancer ou NodePort podem usar externalTrafficPolicy: Local para preservar o endereço IP da origem do cliente. No entanto, com essa configuração, o Kubernetes processa apenas o tráfego local do nó.

Se você quiser preservar o endereço IP da origem do cliente, será necessário fazer outras configurações para garantir que os IPs de serviço estejam acessíveis. Para detalhes de configuração, consulte Como preservar o endereço IP da origem do cliente em Configurar o balanceamento de carga em pacote.

Modificar o firewall apagará as cadeias de políticas do Cilium iptable

Ao executar clusters do Anthos em Bare Metal com firewalld ativado no CentOS ou no Red Had Enterprise Linux (RHEL), as alterações em firewalld podem remover as cadeias iptables do Cilium na rede do host. As cadeias iptables são adicionadas pelo pod anetd quando ele é iniciado. A perda das cadeias do iptables do Cilium faz com que o pod no nó perca a conectividade de rede fora do nó.

As alterações em firewalld que removerão as cadeias de iptables incluem, mas não estão limitadas a:

• Reiniciando firewalld, usando systemctl
• Como atualizar o firewalld com o cliente da linha de comando (firewall-cmd --reload)

Para corrigir esse problema de conectividade, reinicie o anetd. Localize e exclua o pod anetd com os seguintes comandos para reiniciar anetd:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Substitua ANETD_XYZ pelo nome do pod anetd.

Endereços egressSourceIP duplicados

Ao usar a visualização do recurso Gateway NAT de saída, é possível definir regras de seleção de tráfego que especificam um endereço egressSourceIP que já está sendo usado por outro objeto EgressNATPolicy. Isso pode causar conflitos de roteamento do tráfego de saída. Coordene com sua equipe de desenvolvimento para determinar quais endereços IP flutuantes estão disponíveis para uso antes de especificar o endereço egressSourceIP no recurso EgressNATPolicy personalizado.

Falhas de conectividade dos pods e filtragem de caminho reverso

Os clusters do Anthos no bare metal configura o filtro de caminho reverso nos nós para desativar a validação de origem (net.ipv4.conf.all.rp_filter=0). Se a configuração rp_filter for alterada para 1 ou 2, os pods falharão devido a tempos limite de comunicação fora do nó.

A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração IPv4 (net/ipv4/conf/all). Este valor também pode ser modificado por sysctl, que armazena as configurações de filtragem de caminho reverso em um arquivo de configuração de segurança de rede, como /etc/sysctl.d/60-gce-network-security.conf.

Para restaurar a conectividade do pod, defina net.ipv4.conf.all.rp_filter de volta para 0 manualmente ou reinicie o pod de anetd para definir net.ipv4.conf.all.rp_filter novamente para 0. Para reiniciar o pod anetd, use os seguintes comandos para localizar e excluir o pod anetd, e um novo pod anetd será iniciado no lugar:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Substitua ANETD_XYZ pelo nome do pod anetd.

Endereços IP do cluster de inicialização (tipo) e endereços IP dos nós do cluster sobrepostos

192.168.122.0/24 e 10.96.0.0/27 são as CIDRs padrão do pod e do serviço usadas pelo cluster de inicialização (tipo). As verificações de simulação falharão se houver sobreposição com os endereços IP da máquina do nó do cluster. Para evitar o conflito, passe as sinalizações --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr para bmctl para especificar valores diferentes.

Sistema operacional

Incompatibilidade com o Ubuntu 18.04.6 no kernel do GA

Os clusters do Anthos nas versões bare metal 1.11.0 e 1.11.1 não são compatíveis com o Ubuntu 18.04.6 no kernel do GA (de 4.15.0-144-generic para 4.15.0-176-generic). A incompatibilidade faz com que o agente não configure a rede do cluster com um erro "O programa BPF é muito grande" nos registros anetd. É possível ver pods travados no status ContainerCreating com um erro networkPlugin cni failed to set up pod no log de eventos dos pods. Esse problema não se aplica aos kernels de ativação de hardware do Ubuntu (HWE).

Recomendamos que você instale o kernel do HWE e faça upgrade para a última versão do HWE compatível com o Ubuntu 18.04.

Falha na criação ou atualização do cluster no CentOS

Em dezembro de 2020, a comunidade do CentOS e a Red Hat anunciaram o fim do CentOS. Em 31 de janeiro de 2022, o CentOS 8 chegou ao fim da vida útil (EOL). Como resultado do EOL, os repositórios yum pararam de funcionar com o CentOS, o que causa falha nas operações de criação e atualização dos clusters. Isso se aplica a todas as versões compatíveis do CentOS e afeta todas as versões dos clusters do Anthos em bare metal.

Como solução alternativa, execute os seguintes comandos para que seu CentOS use um feed de arquivo:

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*

sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

Como solução de longo prazo, considere migrar para outro sistema operacional compatível.

Limitações do endpoint do sistema operacional

No RHEL e no CentOS, há uma limitação no nível do cluster de 100.000 endpoints. Serviço do Kubernetes. Se dois serviços fizerem referência ao mesmo conjunto de pods, isso conta como dois conjuntos separados de endpoints. A implementação nftable subjacente no RHEL e no CentOS causa essa limitação. A limitação não é intrínseca dos clusters do Anthos em bare metal.

Segurança

O contêiner não pode gravar em VOLUME definido no Dockerfile com containerd e SELinux

Se você usa o containerd como o ambiente de execução do contêiner e o sistema operacional está com o SELinux ativado, o VOLUME definido no Dockerfile do aplicativo pode não ser gravável. Por exemplo, os contêineres criados com o Dockerfile a seguir não podem gravar na pasta /tmp.

FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp

Para verificar se você será afetado por esse problema, execute o seguinte comando no nó que hospeda o contêiner problemático:

ausearch -m avc

Se você for afetado por esse problema, verá um erro denied como este:

time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979):
proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6
items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC
msg=audit(1649106092.768:10979): avc:  denied {
write } for  pid=76042 comm="bash"
name="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:container_t:s0:c701,c935
tcontext=system_u:object_r:container_ro_file_t:s0 tclass=dir permissive=0

Para contornar esse problema, faça uma das seguintes alterações:

• Desative o SELinux.
• Não use o recurso VOLUME dentro do Dockerfile.

Erros do SELinux durante a criação do pod

A criação do pod às vezes falha quando o SELinux impede o ambiente de execução do contêiner de configurar rótulos em montagens tmpfs. Essa falha é rara, mas pode acontecer quando o SELinux está no modo Enforcing e em alguns kernels.

Para verificar se o SELinux é a causa das falhas na criação de pods, use o seguinte comando para verificar se há erros nos registros kubelet:

journalctl -u kubelet

Se o SELinux estiver causando falha na criação do pod, a resposta do comando conterá um erro semelhante ao seguinte:

error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied

Para verificar se esse problema está relacionado à aplicação do SELinux, execute o seguinte comando:

ausearch -m avc

Esse comando pesquisa nos registros de auditoria erros de permissão de cache de vetor de acesso (AVC). O avc: denied no exemplo de resposta a seguir confirma que as falhas de criação do pod estão relacionadas à aplicação do SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

A causa raiz desse problema de criação de pods com o SELinux é um bug do kernel encontrado nas seguintes imagens do Linux:

• Red Hat Enterprise Linux (RHEL) versões anteriores à 8.3
• Versões do CentOS anteriores à 8.3

A reinicialização da máquina ajuda a recuperar o problema.

Para evitar erros de criação de pods, use o RHEL 8.3 ou posterior ou o CentOS 8.3 ou posterior, porque essas versões corrigiram o bug do kernel.

Redefinir/excluir

Exclusão de namespaces

A exclusão de um namespace impedirá a criação de novos recursos nesse namespace, incluindo jobs para redefinir máquinas. Ao excluir um cluster de usuário, você precisa excluir o objeto de cluster antes de excluir o namespace dele. Caso contrário, os jobs para redefinir as máquinas não poderão ser criados, e o processo de exclusão ignorará a etapa de limpeza da máquina.

serviço containerd

O comando bmctl reset não exclui arquivos de configuração containerd ou binários. O serviço containerd systemd está ativo e em execução. O comando exclui os contêineres que estão executando pods programados para o nó.