Atualizar o complemento autogerenciado kube-proxy do Kubernetes

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.

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.

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.

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

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

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

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