AWS Builder Center: Learn, Build and Connect with builders in the AWS community

AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.

¿Cómo puedo automatizar la configuración del proxy HTTP para los nodos de containerd de Amazon EKS?

13 minutos de lectura

Quiero automatizar la configuración del proxy HTTP para los nodos de Amazon Elastic Kubernetes Service (Amazon EKS) con una versión ejecutable de containerd.

Descripción corta

Puedes automatizar la configuración del proxy HTTP para los nodos de Amazon EKS con una plantilla de lanzamiento personalizada que incluya la configuración del proxy en los datos de usuario. El enfoque de configuración varía en función de la familia de AMI: Amazon Linux 2, Amazon Linux 2023 o Bottlerocket.

Nota: Para los clústeres de Amazon EKS versión 1.24 y posteriores, containerd es el tiempo de ejecución de contenedor predeterminado.

Resolución

Para configurar tu grupo de nodos gestionado con ajustes de proxy HTTP, crea una plantilla de lanzamiento personalizada con tu ID de imagen de máquina de Amazon (AMI). A continuación, configura los ajustes apropiados del proxy HTTP y los valores del entorno del clúster.

Elige el enfoque de configuración en función de tu familia de AMI:

Configuración del proxy HTTP para los nodos de Amazon Linux 2

Creación de la plantilla de lanzamiento

Abre la consola de Amazon Elastic Compute Cloud (Amazon EC2).
En el panel de navegación, selecciona Plantillas de lanzamiento.
Elige Crear plantilla de lanzamiento.
En Nombre de la plantilla de lanzamiento, introduce un nombre para la plantilla.
En las imágenes de aplicaciones y sistemas operativos (imagen de máquina de Amazon), elige tu ID de AMI de Amazon Linux 2.
Configura las siguientes opciones:
En Tipo de instancia, elige el tipo de instancia requerido.
En Nombre del par de claves, elige tu par de claves SSH de Amazon EC2.
En Grupos de seguridad, elige tu grupo de seguridad.
Amplía los detalles avanzados.

En Datos de usuario, introduce la siguiente configuración:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==BOUNDARY=="

--==BOUNDARY==
Content-Type: text/cloud-boothook; charset="us-ascii"

#Set the proxy hostname and port
PROXY=XXXXXXX:3128
TOKEN=`curl -X PUT "http://[IP_ADDRESS]/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
MAC=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/mac/)
VPC_CIDR=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/network/interfaces/macs/$MAC/vpc-ipv4-cidr-blocks | xargs | tr ' ' ',')

#Create the containerd and sandbox-image systemd directory
mkdir -p /etc/systemd/system/containerd.service.d
mkdir -p /etc/systemd/system/sandbox-image.service.d

#[Optional] Configure yum to use the proxy
cloud-init-per instance yum_proxy_config cat << EOF >> /etc/yum.conf
proxy=http://$PROXY
EOF

#Set the proxy for future processes, and use as an include file
cloud-init-per instance proxy_config cat << EOF >> /etc/environment
http_proxy=http://$PROXY
https_proxy=http://$PROXY
HTTP_PROXY=http://$PROXY
HTTPS_PROXY=http://$PROXY
no_proxy=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com
NO_PROXY=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com
EOF

#Configure Containerd with the proxy
cloud-init-per instance containerd_proxy_config tee <<EOF /etc/systemd/system/containerd.service.d/http-proxy.conf >/dev/null
[Service]
EnvironmentFile=/etc/environment
EOF

#Configure sandbox-image with the proxy
cloud-init-per instance sandbox-image_proxy_config tee <<EOF /etc/systemd/system/sandbox-image.service.d/http-proxy.conf >/dev/null
[Service]
EnvironmentFile=/etc/environment
EOF

#Configure the kubelet with the proxy
cloud-init-per instance kubelet_proxy_config tee <<EOF /etc/systemd/system/kubelet.service.d/proxy.conf >/dev/null
[Service]
EnvironmentFile=/etc/environment
EOF

cloud-init-per instance reload_daemon systemctl daemon-reload

--==BOUNDARY==
Content-Type:text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -o xtrace

#Set the proxy variables before running the bootstrap.sh script
set -a
source /etc/environment

#Run the bootstrap.sh script
B64_CLUSTER_CA=YOUR_CLUSTER_CA
API_SERVER_URL=API_SERVER_ENDPOINT

/etc/eks/bootstrap.sh EKS_CLUSTER_NAME --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL

--==BOUNDARY==--

Elige Crear plantilla de lanzamiento.

Verificación de la configuración

Después de crear tu grupo de nodos gestionado con la plantilla de lanzamiento, verifica la configuración del proxy:

Para comprobar el estado de los nodos, ejecuta el siguiente comando:

kubectl get nodes -o wide

Para comprobar que las variables de entorno del proxy están configuradas, conéctate a un nodo y ejecuta el siguiente comando:

systemctl show containerd | grep Environment

El resultado muestra las variables de entorno del proxy configuradas para containerd.

Configuración del proxy HTTP para los nodos de Amazon Linux 2023

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

Amazon Linux 2023 presenta un nuevo proceso de inicialización de nodos, denominado nodeadm, que usa un esquema de configuración YAML. Para este proceso, nodeadm se ejecuta en dos fases: configurar y ejecutar. La fase nodeadm-config se ejecuta antes de cloud-init, mientras que nodeadm-run se ejecuta después de cloud-init.

Durante la fase nodeadm-config, el sistema llama al servicio Amazon EC2 para recuperar los detalles de la instancia. Para evitar la llamada de Amazon EC2 antes de configurar los ajustes del proxy, usa la puerta de funciones InstanceIdNodeName en nodeadm.

**Creación de un rol de IAM en un nodo de trabajo **

Crea un nuevo rol de AWS Identity and Access Management (IAM) en un nodo de trabajo con las políticas necesarias.
Usa una de las siguientes opciones para proporcionar al rol de IAM del nodo de trabajo el acceso adecuado:

Opción 1: Crear una entrada de acceso a EKS
Para crear una entrada de acceso de tipo EC2, ejecuta el siguiente comando de la AWS CLI create-access-entry:
```
aws eks create-access-entry --cluster-name EKS_CLUSTER_NAME --principal-arn WORKER_NODE_IAM_ROLE_ARN --type EC2
```
Nota: Sustituye EKS_CLUSTER_NAME por el nombre de tu clúster. Sustituye WORKER_NODE_IAM_ROLE_ARN por el ARN del rol de IAM del nodo de trabajo.

Opción 2: Actualización de ConfigMap de aws-auth
Agrega la siguiente configuración a tu ConfigMap de aws-auth en formato YAML:
```
- groups:
  - system:bootstrappers
  - system:nodes
  rolearn: ROLE_ARN
  username: system:node:{{SessionName}}
```
Nota: Sustituye ROLE_ARN por el ARN del rol de IAM de tu nodo de trabajo. Esta configuración otorga los permisos de RBAC de Kubernetes necesarios para el rol de IAM del nodo de trabajo.

Creación de la plantilla de lanzamiento

Abre la consola de Amazon EC2.
En el panel de navegación, selecciona Plantillas de lanzamiento.
Elige Crear plantilla de lanzamiento.
En Nombre de la plantilla de lanzamiento, introduce un nombre para la plantilla.
En las imágenes de aplicaciones y sistemas operativos (imagen de máquina de Amazon), elige tu ID de AMI de Amazon Linux 2023.
Configura las siguientes opciones:
En Tipo de instancia, elige el tipo de instancia requerido.
En Nombre del par de claves, elige tu par de claves SSH de Amazon EC2.
En Grupos de seguridad, elige tu grupo de seguridad.
Amplía los detalles avanzados.

En Datos de usuario, introduce la siguiente configuración:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==BOUNDARY=="

--==BOUNDARY==
Content-Type: text/cloud-boothook; charset="us-ascii"

#!/bin/bash

#Set the proxy hostname and port
PROXY=XXXXXXX:3128
TOKEN=`curl -X PUT "http://[IP_ADDRESS]/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
MAC=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/mac/)
VPC_CIDR=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v -s http://[IP_ADDRESS]/latest/meta-data/network/interfaces/macs/$MAC/vpc-ipv4-cidr-blocks | xargs | tr ' ' ',')

#[Optional] Configure yum to use the proxy
cloud-init-per instance yum_proxy_config cat << EOF >> /etc/yum.conf
proxy=http://$PROXY
EOF

#Set the proxy for future processes, and use as an include file
cloud-init-per instance proxy_config cat << EOF >> /etc/environment
http_proxy=http://$PROXY
https_proxy=http://$PROXY
HTTP_PROXY=http://$PROXY
HTTPS_PROXY=http://$PROXY
no_proxy=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com
NO_PROXY=$VPC_CIDR,[IP_ADDRESS],[IP_ADDRESS],[IP_ADDRESS],.internal,.eks.amazonaws.com
EOF

#Configure Containerd with the proxy
cloud-init-per instance containerd_proxy_config tee <<EOF /etc/systemd/system/containerd.service.d/http-proxy.conf >/dev/null
[Service]
EnvironmentFile=/etc/environment
EOF

#Configure the kubelet with the proxy
cloud-init-per instance kubelet_proxy_config tee <<EOF /etc/systemd/system/kubelet.service.d/proxy.conf >/dev/null
[Service]
EnvironmentFile=/etc/environment
EOF

cloud-init-per instance reload_daemon systemctl daemon-reload

--==BOUNDARY==
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  featureGates:
    InstanceIdNodeName: true
  cluster:
    name: EKS_CLUSTER_NAME
    apiServerEndpoint: API_SERVER_ENDPOINT
    certificateAuthority: YOUR_CLUSTER_CA
    cidr: KUBERNETES_SERVICE_CIDR_RANGE

--==BOUNDARY==--

Nota: Sustituye XXXXXXX:3128 por el puerto y el nombre de host del proxy. Sustituye YOUR_CLUSTER_CA por la autoridad de certificación (CA) de tu clúster. Sustituye API_SERVER_ENDPOINT por el punto de enlace de tu servidor. Sustituye EKS_CLUSTER_NAME por el nombre de tu clúster. Sustituye WORKER_NODE_IAM_ROLE_ARN por el rango de CIDR de servicio de tu clúster. Si el CIDR del servicio no se proporciona en los datos del usuario, se produce un error en la fase nodeadm-config.

Elige Crear plantilla de lanzamiento.

Verificación de la configuración

Después de crear tu grupo de nodos gestionado con la plantilla de lanzamiento, verifica la configuración del proxy:

Para comprobar el estado de los nodos, ejecuta el siguiente comando:

kubectl get nodes -o wide

Para comprobar que las variables de entorno del proxy están configuradas, conéctate a un nodo y ejecuta el siguiente comando:

systemctl show containerd | grep Environment

El resultado muestra las variables de entorno del proxy configuradas para containerd.

Configuración del proxy HTTP para los nodos de Bottlerocket

Creación de la plantilla de lanzamiento

Abre la consola de Amazon EC2.
En el panel de navegación, selecciona Plantillas de lanzamiento.
Elige Crear plantilla de lanzamiento.
En Nombre de la plantilla de lanzamiento, introduce un nombre para la plantilla.
En las imágenes de aplicaciones y sistemas operativos (imagen de máquina de Amazon), elige tu ID de AMI de Bottlerocket.
Configura las siguientes opciones:
En Tipo de instancia, elige el tipo de instancia requerido.
En Nombre del par de claves, elige tu par de claves SSH de Amazon EC2.
En Grupos de seguridad, elige tu grupo de seguridad.
Amplía los detalles avanzados.

En Datos de usuario, introduce la siguiente configuración:

[settings.kubernetes]
"cluster-name" = "EKS_CLUSTER_NAME"
"api-server" = "API_SERVER_ENDPOINT"
"cluster-certificate" = "YOUR_CLUSTER_CA"

[settings.network]
no-proxy = ["VPC_CIDR_RANGE","[IP_ADDRESS]","[IP_ADDRESS]","[IP_ADDRESS]",".internal",".eks.amazonaws.com"]
https-proxy = "XXXXXXX:3128"

Nota: Sustituye XXXXXXX:3128 por el puerto y el nombre de host del proxy. Sustituye YOUR_CLUSTER_CA por la autoridad de certificación (CA) de tu clúster. Sustituye API_SERVER_ENDPOINT por el punto de enlace de tu servidor. Sustituye EKS_CLUSTER_NAME por el nombre de tu clúster. Sustituye VPC_CIDR_RANGE por tu CIDR de VPC. Bottlerocket configura automáticamente los ajustes de proxy para los servicios containerd y kubelet.

Para agregar certificados autofirmados a tus instancias de Bottlerocket, usa la siguiente configuración en la sección de datos de usuario:

[settings.pki.proxy-bundle]
data="ENCODED_CA_DATA"
trusted=true

Nota: Sustituye ENCODED_CA_DATA por los datos del certificado codificados en base64.

Para codificar el archivo de certificado, ejecuta el siguiente comando:

base64 -i FILE -w0

Elige Crear plantilla de lanzamiento.

Verificación de la configuración

Después de crear tu grupo de nodos gestionado con la plantilla de lanzamiento, verifica la configuración del proxy:

Para comprobar el estado de los nodos, ejecuta el siguiente comando:

kubectl get nodes -o wide

Para verificar la configuración del proxy, conéctate a un nodo de Bottlerocket mediante el administrador de sesiones de AWS Systems Manager y ejecuta el siguiente comando:
```
apiclient get settings.network
```

El resultado muestra la configuración de proxy configurada para el nodo.

Creación de un grupo de nodos administrados

Después de crear la plantilla de lanzamiento, crea un nuevo grupo de nodos administrados que utilice la plantilla de lanzamiento personalizada.

Para obtener más información sobre la creación de grupos de nodos administrados con plantillas de lanzamiento, consulta Personalización de nodos administrados con plantillas de lanzamiento.

Configuración del proxy para clústeres totalmente privados

Importante: Al usar asociaciones de EKS Pod Identity con una configuración de proxy, también debes incluir [IP_ADDRESS] (IPv4) o [[IP_ADDRESS]] (IPv6) en las variables de entorno no_proxy/NO_PROXY.

Los clústeres de Amazon EKS con acceso a un punto de conexión de servidor de API privada, subredes privadas y sin acceso a Internet requieren puntos de conexión adicionales. Si usas la configuración anterior para crear un clúster, debes crear y agregar puntos de enlace para los siguientes servicios:

Amazon EC2
Amazon Elastic Container Registry para extraer imágenes de contenedores
Amazon Elastic Load Balancing para equilibradores de carga de aplicación y equilibradores de carga de red
Registros de Amazon CloudWatch
AWS Security Token Service cuando utilizas roles de IAM para cuentas de servicio
Autenticación de Amazon EKS al usar asociaciones de Pod Identity
Amazon EKS

Tras crear estos puntos de enlace, configura las variables NO_PROXY y no_proxy en los datos de usuario de la plantilla de lanzamiento de instancias de Amazon EC2. Incluye los subdominios de punto de enlace públicos específicos de tu región y servicios de AWS.

Por ejemplo:

Para Amazon Simple Storage Service (Amazon S3):

Si tu bucket está en us-east-1, agrega: .s3.us-east-1.amazonaws.com
Si tu bucket está en eu-west-1, agrega: .s3.eu-west-1.amazonaws.com

En el caso de Amazon EKS, cuando utilizas el acceso privado a un punto de enlace:

Si tu clúster está en us-east-1, agrega: .us-east-1.eks.amazonaws.com
Si tu clúster está en eu-west-1, agrega: .eu-west-1.eks.amazonaws.com

Nota: Sustituye los identificadores de región por la región de AWS en la que hayas implementado tus recursos y añade estos puntos de enlace a las variables NO_PROXY y no_proxy. En función de la carga de trabajo y los complementos del clúster, añade otros servicios a la configuración de proxy.

Configuración del proxy para clústeres públicos

Nota: Si tienes una configuración diferente, estos pasos son opcionales.

Si diriges el tráfico del clúster a Internet a través de un proxy HTTP y tu punto de enlace de Amazon EKS es público, debes completar esta tarea.

Crea un ConfigMap para configurar los valores del entorno:

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-environment-variables
  namespace: kube-system

data:
  HTTP_PROXY: http://XXXXXXX:3128
  HTTPS_PROXY: http://XXXXXXX:3128
  NO_PROXY: KUBERNETES_SERVICE_CIDR_RANGE,[IP_ADDRESS],[IP_ADDRESS],VPC_CIDR_RANGE,[IP_ADDRESS],.internal,.eks.amazonaws.com,ec2.us-east-1.amazonaws.com
  no_proxy: KUBERNETES_SERVICE_CIDR_RANGE,[IP_ADDRESS],[IP_ADDRESS],VPC_CIDR_RANGE,[IP_ADDRESS],.internal,.eks.amazonaws.com,ec2.us-east-1.amazonaws.com

Nota: Sustituye KUBERNETES_SERVICE_CIDR_RANGE y VPC_CIDR_RANGE por los valores de sus rangos CIDR. Tras crear los puntos de enlace de VPC (Amazon EKS y Amazon EC2), añade los puntos de enlace del servicio de AWS a NO_PROXY y no_proxy.

Aplica el archivo ConfigMap:

kubectl apply -f proxy-configmap.yaml

Configuración de aws-node y kube-proxy

Para configurar tu proxy HTTP en aws-node y kube-proxy, ejecuta los siguientes comandos:

kubectl patch -n kube-system -p '{ "spec": {"template":{ "spec": { "containers": [ { "name": "aws-node", "envFrom": [ { "configMapRef": {"name": "proxy-environment-variables"} } ] } ] } } } }' daemonset aws-node

kubectl patch -n kube-system -p '{ "spec": {"template":{ "spec": { "containers": [ { "name": "kube-proxy", "envFrom": [ { "configMapRef": {"name": "proxy-environment-variables"} } ] } ] } } } }' daemonset kube-proxy

Verificación de la configuración del proxy

Para comprobar que la configuración del proxy funciona correctamente, sigue estos pasos:

Para comprobar el estado de los nodos, ejecuta el siguiente comando:

kubectl get nodes -o wide

Para probar la conectividad del pod a través del proxy, ejecuta los siguientes comandos:

kubectl run test-pod --image=amazonlinux:2 --restart=Never -- sleep 300
kubectl get pods -A

Consulta el registro de tu proxy para obtener información adicional sobre la conectividad de tus nodos. Los registros deben mostrar las conexiones correctas (TCP_TUNNEL/200) a los puntos de enlace del registro de contenedores.
Resultado de ejemplo:

192.168.100.114 TCP_TUNNEL/200 6230 CONNECT registry-1.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -
192.168.100.114 TCP_TUNNEL/200 10359 CONNECT auth.docker.io:443 - HIER_DIRECT/XX.XX.XX.XX -

Información relacionada

Actualización de Amazon Linux 2 a Amazon Linux 2023

Creación de nodos de Bottlerocket autoadministrados

Concesión de acceso a los usuarios de IAM a las entradas de acceso de Kubernetes con EKS

Temas: Containers
Etiquetas: Amazon Elastic Kubernetes Service
Idioma: Español

OFICIAL DE AWSActualizada hace 9 meses

Sin comentarios

Contenido relevante

Consulta sobre la migración de EKS Optimized AL2 AMIs
User-9823829
preguntada hace 10 meses
Lambda HTTP Authorizer y función no generan logs en CloudWatch cuando están en warm start
EstebanRojasBarrera
preguntada hace un año
Validación del uso de CloudFront en un entorno multi-tenant con behaviors + Lambda@Edge y recomendaciones para obtener un comportamiento predecible.
F_Ruben
preguntada hace 10 meses
No puedo conectarme por RDP a mis instancias en Windows
Leo
preguntada hace 5 meses
Error en MFA, al solicitar la llamada de reestablecer
roberto
preguntada hace 10 meses
¿Cómo automatizo la configuración del proxy HTTP para los nodos de trabajo de Amazon EKS con Docker?
OFICIAL DE AWSActualizada hace 2 años
¿Cómo automatizo la configuración del proxy HTTP para Amazon EKS con los nodos de trabajo de Amazon Linux 2023?
OFICIAL DE AWSActualizada hace 6 meses
¿Cómo configuro los nodos de trabajo de Amazon EKS para limpiar la caché de imágenes en un porcentaje específico de uso del disco?
OFICIAL DE AWSActualizada hace un año
¿Cómo utilizo Automatización de AWS Systems Manager para actualizar y aplicar parches de seguridad a las AMI de mis nodos de trabajo de Amazon EKS?
OFICIAL DE AWSActualizada hace 8 meses
¿Cómo puedo cobrar a los bots y agentes de IA por el acceso a mi contenido usando la monetización de tráfico de IA de AWS WAF?
INGENIERO DE SOPORTE
Rodrigo Reyes
publicado hace 2 meses