Atualizar o complemento autogerenciado kube-proxy do Kubernetes

Importante

Recomendamos adicionar o tipo Amazon EKS do complemento ao seu cluster em vez de usar o tipo autogerenciado do complemento. Se você não estiver familiarizado com a diferença entre os tipos, consulte Complementos do Amazon EKS. Para obter mais informações sobre como adicionar um complemento do Amazon EKS ao cluster, consulte Criar um complemento do Amazon EKS. Se você não conseguir usar o complemento do Amazon EKS, recomendamos que você envie um problema sobre o motivo pelo qual não pode usar o repositório GitHub para roteiro de contêineres.

Pré-requisitos

• Um cluster existente do Amazon EKS. Para implantar, consulte Começar a usar o Amazon EKS.

Considerações

• Kube-proxy em um cluster do Amazon EKS tem a mesma política de compatibilidade e inclinação do Kubernetes. Saiba como Verificar a compatibilidade da versão do complemento do Amazon EKS com um cluster.

  1. Confirme que tem o tipo autogerenciado de complemento instalado em seu cluster. Substitua my-cluster pelo nome do cluster.

     aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text

     Se receber uma mensagem de erro, você tem o tipo autogerenciado do complemento instalado no cluster. As etapas restantes desse tópico servem para atualizar o tipo autogerenciado do complemento. Se receber um número de versão, você tem o tipo de complemento do Amazon EKS instalado no cluster. Para atualizá-lo, use o procedimento em Atualização de um complemento do Amazon EKS, em vez de usar o procedimento deste tópico. Se não estiver familiarizado com a diferença entre os tipos de complemento, consulte Complementos do Amazon EKS.

  2. Veja qual versão da imagem do contêiner está atualmente instalada em seu cluster.

     kubectl describe daemonset kube-proxy -n kube-system | grep Image

     Veja um exemplo de saída abaixo.

     Image:    602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.29.1-eksbuild.2

     No resultado de exemplo, v1.29.1-eksbuild.2 é a versão instalada no cluster.

  3. Atualize o complemento kube-proxy substituindo 602401143452 e region-code pelos valores da sua saída retornada na etapa anterior. Substitua v1.30.6-eksbuild.3 pela versão do kube-proxy listada na tabela Versão de imagem mais recente do contêiner autogerenciado para cada versão de cluster do Amazon EKS.

     Importante

     Os manifestos para cada tipo de imagem são diferentes e não compatíveis entre os tipos de imagem padrão ou mínimo. Você deve usar o mesmo tipo de imagem da imagem anterior, para que o ponto de entrada e os argumentos correspondam.

     kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.6-eksbuild.3

     Veja um exemplo de saída abaixo.

     daemonset.apps/kube-proxy image updated

  4. Confirme se agora a nova versão está instalada em seu cluster.

     kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3

     Veja um exemplo de saída abaixo.

     v1.30.0-eksbuild.3

  5. Se você estiver usando os nós x86 e Arm no mesmo cluster e o cluster tiver sido implantado antes de 17 de agosto de 2020. Em seguida, edite seu manifesto kube-proxy para incluir um seletor de nó para várias arquiteturas de hardware com o seguinte comando. É uma operação única. Depois que você adicionar o seletor ao manifesto, não precisará fazer isso toda vez que atualizar o complemento. Se o cluster foi implantado em ou após 17 de agosto de 2020, kube-proxy já é capaz de multiarquitetura.

     kubectl edit -n kube-system daemonset/kube-proxy

     Adicione o seletor de nós a seguir ao arquivo no editor e, em seguida, salve o arquivo. Para obter um exemplo de onde incluir este texto no editor, consulte o arquivo CNI manifest (Manifesto do CNI) no GitHub Isso permite que o Kubernetes extraia a imagem de hardware correta com base na arquitetura de hardware do nó.

     - key: "kubernetes.io/arch"
       operator: In
       values:
       - amd64
       - arm64

  6. Se o cluster foi originalmente criado com a versão 1.14 ou mais recente do Kubernetes, você pode ignorar esta etapa porque o kube-proxy já inclui essa Affinity Rule. Se você criou originalmente um cluster do Amazon EKS com a versão 1.13 ou anterior do Kubernetes e quiser usar nós do Fargate no cluster, edite o manifesto do kube-proxy para incluir uma regra de NodeAffinity para impedir que os pods do kube-proxy façam agendamentos em nós do Fargate. Esta é uma edição ocasional. Depois que você adicionar o Affinity Rule ao manifesto, não precisará fazer isso toda vez que atualizar o complemento. Edite o DaemonSet do kube-proxy.

     kubectl edit -n kube-system daemonset/kube-proxy

     Adicione a Affinity Rule a seguir à seção spec do DaemonSet do arquivo no editor e, em seguida, salve o arquivo. Para obter um exemplo de onde incluir este texto no editor, consulte o arquivo CNI manifest (Manifesto do CNI) no GitHub

     - key: eks.amazonaws.com/compute-type
       operator: NotIn
       values:
       - fargate