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 Diagnosticando e Solucionando Problemas de Nó para Clusters do Kubernetes Usando o Script do Node Doctor.

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.

Quando o Kubernetes Engine provisiona um balanceador de carga do OCI para um serviço Kubernetes do tipo LoadBalancer, o balanceador de carga não tem proteção de exclusão ativada.

Se você usar subsequentemente a Console, a CLI ou a API para ativar a proteção de exclusão para o balanceador de carga, o cloud-controller-manager não só será impedido de excluir o balanceador de carga, como também não poderá atualizar nenhuma das propriedades do balanceador de carga.

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

Enquanto isso, não use a Console, a CLI ou a API para ativar a proteção de exclusão para um balanceador de carga.

Observe que o uso da Console, da CLI ou da API para modificar balanceadores de carga do OCI provisionados pelo Kubernetes Engine não é recomendado (para obter mais informações, consulte Definindo Serviços do Kubernetes do Tipo LoadBalancer).

As novas versões do plug-in CNI de Rede de Pod Nativa da VCN do OCI são normalmente lançadas nos realms OC1, OC2 e OC3.

No entanto, em 3 de setembro de 2024, a versão 2.2.0 do plug-in CNI do OCI VCN-Native Pod Networking, que contém aprimoramentos de segurança e desempenho, foi lançada apenas no realm OC1.

Em 4 de outubro de 2024, o plug-in CNI versão 2.2.2 do OCI VCN-Native Pod Networking foi lançado nos realms OC1, OC2 e OC3, contendo outros aprimoramentos.

Portanto, entre 3 de setembro de 2024 e 4 de outubro de 2024:

• Os novos clusters criados nos realms OC2 e OC3 usaram a versão anterior do plug-in CNI do OCI VCN-Native Pod Networking, ou seja, a versão 2.1.0.
• No caso de clusters existentes nos realms OC2 e OC3, mesmo que você tenha especificado que queria que a Oracle implantasse atualizações no plug-in CNI do OCI VCN-Native Pod Networking em um cluster automaticamente, a versão 2.2.0 não foi implantada nesses clusters.

Independentemente de você ou a Oracle ser responsável por implantar atualizações no plug-in CNI do OCI VCN-Native Pod Networking, as atualizações só serão aplicadas quando os nós de trabalho forem reinicializados pela próxima vez.

Como resultado, você pode ter clusters nos realms OC2 e OC3 que ainda estão executando a versão 2.1.0 do plug-in CNI do OCI VCN-Native Pod Networking.

Para se beneficiar dos aprimoramentos nas versões 2.2.0 e 2.2.2 do plug-in CNI do OCI VCN-Native Pod Networking, recomendamos que você atualize qualquer cluster em OC2 ou OC3 para usar a versão 2.2.2.

O plug-in CNI da VCN-Native Pod Networking versão 2.2.0 não será liberado nos realms OC2 e OC3, mesmo que você possa selecionar a versão 2.2.0 na Console.

Se você ativar o plug-in CNI do OCI VCN-Native Pod Networking para um cluster aprimorado no realm OC2 ou OC3 e especificar que deseja escolher a versão do complemento a ser implantado, não selecione a versão 2.2.0. Em vez disso, selecione a versão 2.2.2 (ou posterior). Se você selecionar a versão 2.2.0 para um cluster aprimorado nos realms OC2 e OC3, lembre-se de que os nós de trabalho não aparecerão e o cluster não funcionará.

Para obter mais informações, consulte Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods.

Quando você trabalha com um cluster do Kubernetes criado pelo Kubernetes Engine, pode notar atrasos inesperados quando o cluster interage com o servidor de API do Kubernetes (como respostas lentas aos comandos do kubectl).

Se você estiver usando uma máquina cliente com uma versão mais antiga da CLI do OCI e/ou do Python instalada, esses picos intermitentes na latência do kube-apiserver podem ser devido a um problema conhecido de desempenho da CLI do OCI. Este problema de desempenho foi observado com o Python versão 3.6 especificamente.

Por padrão, o arquivo kubeconfig que o Kubernetes Engine cria para um cluster contém um comando da CLI do OCI para gerar um token (o comando OCI ce cluster generate-token). O token é usado para autenticar solicitações para o kube-apiserver. No momento, cada solicitação de kube-apiserver aciona uma chamada da CLI do OCI para executar o comando para gerar o token. É essa chamada da CLI do OCI que pode ser afetada pelo problema conhecido de desempenho da CLI do OCI.

Para confirmar se a latência do kube-apiserver é causada pelo problema conhecido de desempenho da CLI do OCI, localize e exiba o arquivo kubeconfig que está sendo usado pelo cliente. Na seção users do arquivo kubeconfig, localize o usuário associado ao cluster em questão. Supondo que nenhuma modificação tenha sido feita no arquivo kubeconfig para usar uma conta de serviço (consulte Adicionando um Token de Autenticação da Conta de Serviço a um Arquivo Kubeconfig), a seção user contém o comando de geração de token da CLI do OCI no seguinte formato yaml:

- name: <user-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - ce
      - cluster
      - generate-token
      - --cluster-id
      - <your-cluster-ocid>
      - --region
      - <your-region>
      command: oci
      env: []

Para confirmar se a latência do kube-apiserver é causada pelo problema de desempenho conhecido, use o seguinte comando para retornar o tempo que a CLI do OCI leva para executar o comando de geração de token:

time oci ce cluster generate-token --cluster-id <your-cluster-ocid> --region <your-region>

Se o tempo gasto para executar o comando estiver próximo da latência do kube-apiserver que você observou, talvez você esteja enfrentando o problema de desempenho conhecido.

Certifique-se de que você esteja usando a versão estável mais recente da CLI do OCI, juntamente com uma versão suportada do Python (consulte Instalação Manual na documentação da CLI do OCI).

Se você estiver usando o Python versão 3.6, recomendamos que faça upgrade para uma versão mais recente do Python.

Se você não puder fazer upgrade para uma versão mais recente do Python, desative a importação de todos os serviços (o comportamento padrão) e, em vez disso, importe seletivamente apenas os serviços e módulos individuais necessários. Sabe-se que a importação seletiva de serviços melhora o desempenho do Python versão 3.6. Para obter mais informações, consulte Ativar Importações de Serviços Seletivos para Python 3.6.

Quando você faz upgrade de um pool de nós existente para o Kubernetes versão 1.33.1 em um cluster que você criou usando o Kubernetes Engine, pode notar que as cargas de trabalho que foram executadas com sucesso agora encontram problemas e retornam mensagens de erro como Too many open files.

Uma possível causa é que, nos pools de nós que executam o Kubernetes versão 1.33.1, o limite de software padrão para arquivos abertos (ulimit nofile) nos contêineres foi reduzido para 1024. As cargas de trabalho que dependiam implicitamente de um limite padrão anteriormente maior podem, portanto, encontrar problemas.

O limite de software padrão para arquivos abertos (ulimit nofile) em contêineres foi reduzido para 1024 devido a uma alteração no runtime do contêiner CRI-O. O Kubernetes versão 1.33.1 usa o CRI-O versão 1.33. No CRI-O versão 1.33, o parâmetro LimitNOFILE não é mais definido explicitamente no arquivo de serviço systemd do CRI-O. Como resultado, o limite de software padrão systemd (normalmente 1024) agora se aplica a arquivos abertos dentro de contêineres. Para obter mais informações, consulte https://github.com/cri-o/cri-o/pull/8962.

Estamos cientes do problema e trabalhando em uma resolução. Enquanto isso, há duas soluções alternativas possíveis:

• Solução alternativa 1: crie um script cloud-init personalizado para aumentar o ulimit nofile. Por exemplo:

  #!/bin/bash
  mkdir -p /etc/crio/crio.conf.d
  echo "[crio]" > /etc/crio/crio.conf.d/11-default.conf
  echo "  [crio.runtime]" >> /etc/crio/crio.conf.d/11-default.conf
  echo "    default_ulimits=[\"nofile=262144:262144\"]" >> /etc/crio/crio.conf.d/11-default.conf
  curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
  sudo bash /var/run/oke-init.sh

  Observe que nofile=262144:262144 é um exemplo. Defina nofile como um valor apropriado para a carga de trabalho. Para obter mais informações sobre como criar scripts personalizados do cloud-init, consulte Usando Scripts Personalizados de Inicialização do Cloud-init para Configurar nós gerenciados.

• Solução alternativa 2: Faça downgrade temporário da versão do Kubernetes em execução no pool de nós para o Kubernetes versão 1.32, até que uma resolução permanente esteja disponível.