Trabalhando com o complemento 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.

O complemento kube-proxy é implantado em cada nó do Amazon EC2 em seu cluster do Amazon EKS. Ele mantém as regras de rede em seus nós e permite a comunicação de rede com seus Pods. O complemento não é implantado em nós do Fargate em seu cluster. Para obter mais informações, consulte a kube-proxy documentação do Kubernetes.

A tabela a seguir lista a versão mais recente do tipo de complemento do Amazon EKS para cada versão do Kubernetes.

Versão do Kubernetes	1.30	1.29	1.28	1.27	1.26	1.25	1.24	1.23
	v1.30.0-eksbuild.3	v1.29.3-eksbuild.5	v1.28.8-eksbuild.5	v1.27.12-eksbuild.5	v1.26.15-eksbuild.5	v1.25.16-eksbuild.8	v1.24.17-eksbuild.8	v1.23.17-eksbuild.9

Importante

Uma versão anterior da documentação estava incorreta. As versões v1.28.5, v1.27.9 e v1.26.12 do kube-proxy não estão disponíveis.

Se você estiver gerenciando esse complemento automaticamente, as versões na tabela podem não ser as mesmas que as versões autogerenciadas disponíveis.

Há dois tipos de imagem de contêiner kube-proxy disponíveis para cada versão do cluster do Amazon EKS:

• Padrão: esse tipo de imagem é baseado em uma imagem do Docker baseado em Debian que é mantida pela comunidade do Kubernetes upstream.

• Mínima: esse tipo de imagem é baseado em uma imagem de base mínima mantida pelo Amazon EKS Distro, que contém pacotes mínimos e não tem shells. Para obter mais informações, consulte Amazon EKS Distro.

Versão mais recente da imagem do contêiner kube-proxy autogerenciado disponível para cada versão de cluster do Amazon EKS
Tipo de imagem	1.30	1.29	1.28	1.27	1.26	1.25	1.24	1.23
kube-proxy (tipo padrão)	Somente o tipo mínimo está disponível	Somente o tipo mínimo está disponível	Somente o tipo mínimo está disponível	Somente o tipo mínimo está disponível	Somente o tipo mínimo está disponível	Somente o tipo mínimo está disponível	v1.24.10-eksbuild.2	v1.23.16-eksbuild.2
kube-proxy (tipo mínimo)	v1.30.0-minimal-eksbuild.3	v1.29.3-minimal-eksbuild.5	v1.28.8-minimal-eksbuild.5	v1.27.12-minimal-eksbuild.5	v1.26.15-minimal-eksbuild.5	v1.25.16-minimal-eksbuild.8	v1.24.17-minimal-eksbuild.4	v1.23.17-minimal-eksbuild.5

Importante

• O tipo de imagem padrão não está disponível para a Kubernetes versão 1.25 e versões posteriores. Você deve usar o tipo mínimo de imagem.

• Ao atualizar um tipo de complemento do Amazon EKS, você especifica uma versão válida do complemento do Amazon EKS, que pode não ser uma versão listada nesta tabela. Isso ocorre porque as versões complementares do Amazon EKS nem sempre correspondem às versões de imagem de contêiner especificadas ao atualizar o tipo autogerenciado desse complemento. Ao atualizar o tipo autogerenciado desse complemento, você especifica uma versão de imagem de contêiner válida listada nesta tabela.

Pré-requisitos

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

Considerações

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

Para atualizar o complemento autogerenciado kube-proxy

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 Atualizar um complemento do Amazon EKS, em vez de usar o procedimento neste 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 dos resultados na etapa anterior. Substitua v1.30.0-eksbuild.3 pela versão do kube-proxy listada na tabela Versão da imagem mais recente do contêiner kube-proxy disponível para cada versão de cluster do Amazon EKS. É possível especificar um número de versão para o tipo de imagem default (padrão) minimal (mínimo).

   kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.0-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 esse texto no editor, consulte o arquivo CNI manifest (Manifesto de 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 tiver sido originalmente criado com o Kubernetes versão 1.14 ou posterior, você pode pular esta etapa, pois o kube-proxy já inclui essa Affinity Rule. Se você criou originalmente um cluster do Amazon EKS com o Kubernetes versão 1.13 ou anterior e pretender usar nós do Fargate no cluster, edite o manifesto do kube-proxy para incluir uma regra de NodeAffinity para evitar o agendamento de Pods do kube-proxy 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. Editar seu kube-proxy DaemonSet.

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

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

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