Problemas Conhecidos do Kubernetes Engine (OKE)

As propriedades dos novos nós de trabalho que iniciam em um pool de nós não refletem as últimas alterações nas propriedades do pool de nós. A causa provável é o uso dos atributos obsoletos quantityPerSubnet e subnetIds ao usar a operação da API UpdateNodePoolDetails para atualizar as propriedades do pool de nós.

Execute um dos seguintes procedimentos:

• Comece usando o atributo nodeConfigDetails ao usar a operação da API UpdateNodePoolDetails. Primeiramente, dimensione o pool de nós para 0 usando o atributo quantityPerSubnet. Em seguida, pare de usar os atributos subnetIds e quantityPerSubnet e use o atributo nodeConfigDetails em seu lugar.
• Entre em contato com o Suporte Técnico da Oracle para reiniciar o componente de back-end responsável pela sincronização (o componente tenant-agent).

Quando você inicia o Painel de Controle do Kubernetes, em algumas situações você pode encontrar mensagens de erro "net/http: TLS handshake timeout" e "connection reset by peer" no Web browser. Este problema foi observado apenas em clusters recém-criados que executam o Kubernetes versão 1.11. Para obter detalhes sobre um problema relacionado ao Kubernetes, consulte https://github.com/kubernetes/dashboard/issues/3038.

1. Em uma janela de terminal, digite:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. No seu web browser, vá para https://localhost:8443

Quando você usa um token Kubeconfig versão 2.0.0 para acessar as versões do Helm/Tiller anteriores à versão 2.11, recebe uma das seguintes mensagens de erro:

• Error: Unauthorized
• Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Atualize o Helm/Tiller da seguinte maneira:

1. Em uma janela de terminal, faça download da versão 1.0.0 do token Kubeconfig digitando o seguinte comando:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. Identifique a chave de região a ser usada para especificar o registro do Oracle Cloud Infrastructure Registry na região do cluster (consulte Disponibilidade por Região). Por exemplo, se o cluster estiver na região Leste dos EUA (Ashburn), iad será o código da região a ser usado para especificar o registro nessa região.

3. Faça upgrade do Tiller digitando o seguinte comando:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   em que <region-key> é o código identificado na etapa anterior.

4. Em um browser, navegue até https://helm.sh/docs/using_helm/#installing-the-helm-client e siga as instruções para fazer download e instalar o arquivo binário do cliente Helm.

5. Após o upgrade do Helm/Tiller, faça download da versão 2.0.0 do token Kubeconfig digitando o seguinte comando:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

A versão do Kubernetes Engine 1.8.0 incluiu uma melhoria de segurança para melhorar a força de cifragem no kubelet em execução nos nós de trabalho do cliente. Os novos nós de trabalho criados entre 20 de agosto de 2019 e 16 de setembro de 2019 incluem essa configuração. O novo conjunto de cifras não permite conexões com o kubelet via http/2. Essa restrição afeta o Servidor de Métricas e também o Horizontal Pod Autoscaler, que depende do Servidor de Métricas.

Por sua vez, para cada nó de trabalho existente:

1. Impeça que novos pods iniciem e excluam pods existentes no nó de trabalho, digitando kubectl drain <node_name>. Para obter mais informações:

   • sobre o uso do kubectl, consulte Acessando um Cluster com o Kubectl
   • sobre o comando drain, consulte drain na documentação do Kubernetes

   Recomendado: Utilize orçamentos de interrupção, conforme apropriado, para o seu aplicativo, para garantir que haja um número suficiente de pods de réplica em execução durante a operação de drenagem.

2. Exclua o nó de trabalho (por exemplo, encerrando-o na Console ).
3. Aguarde a inicialização do nó de trabalho substituto.

Os nós de trabalho substitutos incluem novas definições para permitir a comunicação com o kubelet.

Quando um novo pod é iniciado em um nó de trabalho de um cluster, em algumas situações, o pod falha ao montar todos os volumes anexados ao nó por causa de timeouts e você vê uma mensagem semelhante a esta:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

Uma possível causa identificada para esse problema é se a especificação do pod inclui um campo fsGroup no campo securityContext. Se o contêiner estiver sendo executado em um nó de trabalho como usuário não raiz, a definição do campo fsGroup no campo securityContext poderá causar timeouts por causa do número de arquivos nos quais o Kubernetes deve fazer alterações de propriedade (consulte https://github.com/kubernetes/kubernetes/issues/67014).

Se a especificação do pod não inclui um campo fsgroup no campo securityContext, a causa é desconhecida.

Se a especificação do pod incluir o campo fsgroup no campo securityContext e o container estiver executando um usuário não raiz, considere as seguintes soluções alternativas:

• Remova o campo fsgroup do campo securityContext.
• Use o campo supplementalGroups no campo securityContext (em vez de fsgroup) e defina supplementalGroups como identificador de volume.
• Altere a especificação do pod para que o container seja executado como raiz.

Se a especificação do pod não incluir o campo fsgroup no campo securityContext ou se o contêiner já estiver sendo executado como raiz, será necessário reiniciar ou substituir o nó de trabalho. Por exemplo, interrompendo e iniciando a instância, reinicializando-a ou encerrando-a para que uma nova instância seja iniciada. Siga as instruções em Interrompendo, Iniciando ou Reiniciando uma Instância ou Finalizando uma Instância, conforme apropriado, para usar a Console ou a API. Se preferir, você poderá usar comandos da CLI, como o exemplo a seguir, para encerrar uma instância:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

em que <name> é o nome do nó de trabalho, derivado da propriedade Endereço IP Privado da instância (por exemplo, 10.0.10.5).

Ao usar o serviço OS Management para gerenciar atualizações e patches do sistema operacional em instâncias do Oracle Cloud Infrastructure, há algumas situações em que OS pools de nós de cluster criados pelo serviço Kubernetes Engine não podem ficar on-line.

Existem duas soluções alternativas possíveis:

• Solução alternativa 1: Se você quiser usar o serviço OS Management para gerenciar instâncias do Oracle Cloud Infrastructure, ative o Oracle Enterprise Linux no OS Management. Consulte Gerenciando Origens de Software
• Solução alternativa 2: se você não quiser usar o serviço OS Management para gerenciar instâncias do Oracle Cloud Infrastructure, certifique-se de que não haja políticas que permitam a execução do OS Management. Especificamente, remova a política que concede a um grupo dinâmico de instâncias acesso ao serviço OS Management. Consulte Configurando Políticas para o Serviço OS Management.

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

Para verificar esse problema, abra uma janela de terminal na instância e execute o seguinte comando:

sudo /usr/sbin/lsmod | grep br_netfilter 

Se nenhum resultado for retornado, é porque o módulo de kernel do Bridge Netfilter não está ativado. O módulo de kernel Bridge Netfilter é necessário para mascarar o tráfego VxLAN dos pods do Kubernetes.

Ative o módulo de kernel Bridge Netfilter. Abra uma janela de terminal na instância e execute os seguintes comandos:

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

Ao usar a rede nativa de pods da VCN, o endereço IP do cliente de origem das solicitações de entrada para um pod pode não ser preservado conforme esperado. Em vez disso, as solicitações de entrada recebidas por meio de um serviço Kubernetes do tipo LoadBalancer que tem externalTrafficPolicy: Local definido no arquivo de manifesto podem ser mostradas como originárias do endereço IP do nó de trabalho.

Para solicitações TCP de entrada recebidas por meio de um serviço Kubernetes do tipo LoadBalancer que tem a anotação oci.oraclecloud.com/load-balancer-type: "lb" no arquivo de manifesto, obtenha o endereço IP do cliente de origem do cabeçalho X-Forwarded-For ou X-Real-IP.

Ao usar a rede nativa de pods da VCN, os pods talvez não possam se comunicar pela rede se você tiver especificado uma forma bare metal para nós de trabalho em um ou mais pools de nós no cluster.

Especifique uma forma de VM para nós de trabalho em cada pool de nós no cluster ao usar a rede nativa de pods da VCN.

Ao usar uma rede nativa de pods da VCN, o número máximo de pods por nó de trabalho em um pool de nós pode ser limitado a 31, independentemente do número de OCPUs especificadas para a forma flexível selecionada para o pool de nós.

Se você quiser mais de 31 pods por nó de trabalho em um pool de nós, selecione outra forma para nós de trabalho no pool de nós.

Ao usar a rede nativa de pods da VCN, os pods em execução em nós de trabalho conectados a uma sub-rede de pods com um bloco CIDR fora do primeiro bloco CIDR especificado para a VCN podem não conseguir se comunicar com os serviços Kubernetes.

Crie sub-redes de pods com blocos CIDR dentro do primeiro bloco CIDR especificado para a VCN.

Ao usar o script do Node Doctor para solucionar problemas de nó, o script pode exibir uma mensagem de erro de exceção semelhante à seguinte:

FileNotFoundError: [Errno 2] No such file or directory: '/home/opc/vendor/pip…

O script do Node Doctor provavelmente continuará a ser executado e, tendo exibido a mensagem Generating node doctor bundle, produzirá o resultado da solução de problemas.

Estamos cientes do problema e trabalhando em uma solução. Entretanto, se o script do Node Doctor exibir a mensagem Generating node doctor bundle, observe que o resultado da solução de problemas ainda será válido.

Se você não quiser que o script do Node Doctor exiba a mensagem de erro de exceção FileNotFoundError: [Errno 2]..., atualize o script digitando:

node-doctor.sh --update

Para obter mais informações sobre o script do Node Doctor e como atualizá-lo, consulte Solução de Problemas de Nó para Clusters do Kubernetes Usando o Node Doctor Script.

Se um cluster usar a rede de pod nativa da VCN e tiver um pod de carga de trabalho e o pod CoreDNS em execução no mesmo nó de trabalho, a resolução de DNS às vezes falhará porque o tráfego é NATed incorreto.

Em 2023-03-21, foi lançada uma atualização para o plug-in CNI de Rede de Pod Nativo da VCN do OCI que resolveu esse problema. Siga as instruções em Atualizando o plug-in CNI da Rede de pods nativos da VCN do OCI para implantar a atualização.

Se um cluster usar a rede de pods nativos da VCN e tiver nós de trabalho executando o Oracle Linux 8 (OL8), os pods às vezes não serão iniciados em um dos nós de trabalho. O problema tem as seguintes características:

• O nó de trabalho está executando uma imagem OL8.
• Os pods relacionados à rede de host são executados conforme esperado no nó de trabalho, mas todos os outros pods não são iniciados.
• Os logs crictl contêm a mensagem Adding address to IPVLAN parent device (indicando que um endereço IP está sendo anexado à VNIC secundária do nó de trabalho), seguida pela mensagem de erro Error adding secondary VNIC IP.
• A execução do comando ip address do Linux no nó de trabalho mostra que uma (ou mais) VNICs secundárias não têm um endereço IP anexado.
• Todos os outros nós de trabalho (ou a maioria deles) estão operando conforme esperado.

Uma causa provável identificada por esse problema está relacionada ao NetworkManager, que gerencia dispositivos de rede e conexões. Em alguns casos, o NetworkManager desanexa o endereço IP anexado a uma ou mais VNICs secundárias do nó de trabalho, fazendo com que o plug-in CNI da Rede de pods nativos da VCN do OCI falhe.

Em 2023-03-21, foi lançada uma atualização para o plug-in CNI de Rede de Pod Nativo da VCN do OCI que resolveu esse problema. Siga as instruções em Atualizando o plug-in CNI da Rede de pods nativos da VCN do OCI para implantar a atualização.

Se você tiver especificado o Oracle Linux 8.7 ou o Oracle Linux 8.8 para um pool de nós ( selecionando uma imagem da plataforma Oracle Linux 8.7 ou Oracle Linux 8.8 ou uma imagem de nó de trabalho do OKE criada com base no Oracle Linux 8.7 ou Oracle Linux 8.8), o status dos nós de trabalho do pool de nós poderá mudar inesperadamente para NotReady. O problema tem as seguintes características:

• Os nós de trabalho estão executando o Oracle Linux 8.7 ou o Oracle Linux 8.8.
• Os nós de trabalho estão executando o Kubernetes versão 1.24.1, 1.25.4 ou 1.26.2. (Os nós de trabalho que executam o Kubernetes versão 1.25.12, 1.26.7 e 1.27 não são afetados.)
• Os pods de curta duração são frequentemente implantados nos nós de trabalho.
• Os pods implantados nos nós de trabalho no pool de nós também podem permanecer no status ContainerCreating por mais tempo do que o esperado.

Estamos cientes do problema e trabalhando em uma solução.

Enquanto isso, se você encontrar esse problema, use qualquer uma das soluções alternativas a seguir que melhor atenda aos seus requisitos:

• Especifique uma imagem do Oracle Linux 7 para o pool de nós.
• Especifique uma imagem do Oracle Linux 8.6 (ou uma imagem anterior do Oracle Linux 8) para o pool de nós.
• Especifique uma versão mais recente do Kubernetes para o pool de nós. (Os nós de trabalho que executam o Kubernetes versão 1.25.12, 1.26.7 e 1.27 não são afetados.)

Para obter os OCIDs de imagens que não aparecem mais na Console:

• Imagens da plataforma: Consulte Todas as Imagens do Oracle Linux 7.x e Todas as Imagens do Oracle Linux 8.x
• Imagens do nó de trabalho do OKE: Consulte Todas as Imagens do Nó de Trabalho do OKE Oracle Linux 7.x e Todas as Imagens do Nó de Trabalho do OKE Oracle Linux 8.x

Em clusters criados antes de 26 de junho de 2023 que usam rede de pods nativa da VCN, talvez você veja um atraso no provisionamento de novos nós de trabalho.

Ao fazer bootstrap dos nós de trabalho com o plug-in CNI do OCI VCN-Native Pod Networking, o Kubernetes Engine implanta um recurso personalizado do Kubernetes (o recurso NativePodNetwork ou NPN) em cada instância de computação. Quando um nó de trabalho é inicializado com sucesso, o Kubernetes Engine fornece um status de SUCESSO ao recurso NPN associado à instância de computação.

Em alguns casos, se uma instância de computação for encerrada antes que o Kubernetes Engine dê um status de SUCESSO ao recurso NPN associado, o recurso NPN permanecerá em um status BACKOFF ou IN_PROGRESS indefinidamente. A existência desses recursos 'desatualizados' pode atrasar o provisionamento de novos nós de trabalho.

O problema é corrigido em clusters criados após 2023-06-26. Para resolver o problema em clusters criados antes de 2023-06-26, execute uma ação única para excluir os recursos obsoletos seguindo as instruções desta seção.

Antes de começar, verifique se o sistema atende aos seguintes pré-requisitos:

• a CLI do OCI está instalada (consulte Instalando a CLI)
• a CLI do OCI está configurada (consulte Configurando a CLI)
• jq foi baixado e instalado (consulte https://jqlang.github.io/jq/download/)
• existe uma política do serviço IAM que concede pelo menos a permissão INSTANCE_READ, como Allow group <group-name> to manage instance-family in <location> (consulte Criar Política Obrigatória para Grupos)
• os arquivos kubeconfig apropriados estão acessíveis para permitir que você use o kubectl para gerenciar clusters que usam o plug-in CNI de Rede de Pod Nativa da VCN do OCI (consulte Acessando um Cluster Usando o Kubectl)

Identifique e exclua os recursos desatualizados da seguinte forma:

1. Verifique se o sistema atende a todos os pré-requisitos:
   1. Salve o seguinte script em um arquivo chamado pre-req-check.sh:

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. Execute o script pre-req-check.sh digitando:

      sh pre-req-check.sh

2. Identifique os recursos NPN possíveis candidatos à exclusão porque eles não têm um status de SUCESSO:
   1. Envie uma lista de recursos NPN que não têm um status de SUCESSO para um arquivo de texto chamado potential_stale_resources.txt digitando:

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. Opcionalmente, exiba a lista de recursos NPN candidatos em potential_stale_resources.txt informando:

      cat potential_stale_resources.txt

      Por exemplo, potential_stale_resources.txt pode conter:

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. Identifique os recursos NPN obsoletos a serem excluídos determinando quais recursos NPN candidatos estão associados a instâncias de computação que não estão disponíveis ou foram encerrados:
   1. Salve o seguinte script em um arquivo chamado get_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. Execute o script get_stale_resources.sh digitando:

      sh get_stale_resources.sh potential_stale_resources.txt

      O script get_stale_resources.sh identifica os recursos NPN desatualizados a serem excluídos, envia mensagens de processamento para a tela e grava os nomes dos recursos NPN desatualizados em um arquivo chamado stale_resources.txt. Por exemplo:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. Opcionalmente, exiba a lista de recursos NPN desatualizados em stale_resources.txt informando:

      cat stale_resources.txt

      Por exemplo, stale_resources.txt pode conter:

      anyhqljth4...snq
      anyhqljth4...qhq

4. Exclua os recursos NPN desatualizados listados no arquivo stale_resources.txt:
   1. Salve o seguinte script em um arquivo chamado delete_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. Execute o script delete_stale_resources.sh digitando:

      sh delete_stale_resources.sh stale_resources.txt

      O script delete_stale_resources.sh exclui os recursos NPN desatualizados listados no arquivo stale_resources.txt e envia mensagens de processamento para a tela. Por exemplo:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. Como boa prática de governança, exclua os arquivos stale_resources.txt e potential_stale_resources.txt criados anteriormente.

Quando você especifica uma forma Arm para um nó virtual, os pods programados no nó são executados nos processadores Arm, conforme pretendido. No entanto, se você examinar o nó virtual usando o comando kubectl describe node ou a API do Kubernetes, a propriedade Arquitetura do nó indicará AMD64, mesmo que os pods programados no nó sejam executados nos processadores Arm.

Estamos cientes do problema e trabalhando em uma solução.

Enquanto isso, se você encontrar esse problema, ignore o valor da propriedade Arquitetura do nó virtual.