View a markdown version of this page

Introducción a la puerta de enlace de nodos híbridos de EKS - Amazon EKS

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Introducción a la puerta de enlace de nodos híbridos de EKS

Esta página explica los requisitos previos, la preparación del entorno, la instalación, la verificación y la eliminación de la puerta de enlace de Nodos híbridos de Amazon EKS. Para obtener una introducción a la puerta de enlace y su arquitectura, consulte Puerta de enlace de Nodos híbridos de Amazon EKS.

Requisitos previos

Antes de instalar la puerta de enlace de nodos híbridos, asegúrese de que el entorno cumple los siguientes requisitos:

  • Clúster de EKS compatible con el CNI y el VTEP de Cilium : su clúster de EKS debe usar la versión de EKS de Cilium como CNI en los nodos híbridos y el VTEP de Cilium debe estar activado. Para obtener más información, consulte Configuración de la CNI para la puerta de enlace de nodos híbridos.

  • CNI de VPC de AWS en nodos de nube: los nodos de puerta de enlace y otros nodos de nube del clúster deben usar la CNI de VPC de AWS. La puerta de enlace se basa en el enrutamiento nativo de la VPC para reenviar el tráfico entre la VPC y el túnel de VXLAN.

  • Conectividad híbrida: es necesaria una conexión privada entre la VPC y el entorno en las instalaciones. Puede utilizar AWS Direct Connect, AWS Site-to-Site VPN o la solución de VPN propia. Para obtener más información, consulte Cómo preparar las redes para los nodos híbridos.

  • Tráfico VXLAN permitido: los grupos de seguridad conectados a las instancias de EC2 de la puerta de enlace deben permitir el tráfico UDP entrante y saliente en el puerto 8472. En el lado del nodo híbrido, las reglas del firewall en las instalaciones también deben permitir el tráfico del puerto UDP 8472 hacia y desde las direcciones IP del nodo de puerta de enlace.

  • Permisos de IAM para la administración de tablas de enrutamiento: la puerta de enlace requiere las siguientes acciones de EC2 para administrar las tablas de enrutamiento de la VPC:

    • ec2:DescribeRouteTables

    • ec2:CreateRoute

    • ec2:ReplaceRoute

    • ec2:DescribeInstances

      Puede conceder estos permisos mediante alguna de los siguientes opciones:

      EKS Pod Identity (recommended)

      Utilice EKS Pod Identity para conceder permisos únicamente a la cuenta de servicio del pod de puerta de enlace.

      1. Instale el complemento del agente de EKS Pod Identity en el clúster si aún no lo ha hecho:

        aws eks create-addon \ --cluster-name CLUSTER_NAME \ --addon-name eks-pod-identity-agent
      2. Cree un rol de IAM con los permisos de EC2 necesarios y una política de confianza para EKS Pod Identity:

        cat > gateway-trust-policy.json << 'EOF' { "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"] } ] } EOF aws iam create-role \ --role-name EKSHybridNodesGatewayRole \ --assume-role-policy-document file://gateway-trust-policy.json aws iam put-role-policy \ --role-name EKSHybridNodesGatewayRole \ --policy-name HybridNodesGatewayRouteTable \ --policy-document '{ "Version": "2012-10-17" , "Statement": [{ "Effect": "Allow", "Action": [ "ec2:DescribeRouteTables", "ec2:CreateRoute", "ec2:ReplaceRoute", "ec2:DescribeInstances" ], "Resource": "*" }] }'
      3. Cree una asociación de Pod Identity que vincule el rol de IAM a la cuenta de servicio de puerta de enlace:

        aws eks create-pod-identity-association \ --cluster-name CLUSTER_NAME \ --namespace eks-hybrid-nodes-gateway \ --service-account eks-hybrid-nodes-gateway \ --role-arn arn:aws:iam::ACCOUNT_ID:role/EKSHybridNodesGatewayRole
      Node IAM role

      Adjunte una política administrada o integrada con los permisos necesarios al rol de IAM asociado al perfil de instancia de los nodos de la puerta de enlace:

      aws iam put-role-policy \ --role-name NODE_ROLE_NAME \ --policy-name HybridNodesGatewayRouteTable \ --policy-document '{ "Version": "2012-10-17" , "Statement": [{ "Effect": "Allow", "Action": [ "ec2:DescribeRouteTables", "ec2:CreateRoute", "ec2:ReplaceRoute", "ec2:DescribeInstances" ], "Resource": "*" }] }'

      Todos los pods de los nodos de la puerta de enlace tendrán estos permisos.

  • Modo automático de EKS (si usa el modo automático para los nodos de puerta de enlace): si planea usar el modo automático de EKS para aprovisionar los nodos de la puerta de enlace, el modo automático debe estar activado en su clúster de EKS. Para obtener más información, consulte Activación del modo automático de EKS.

Preparación de los nodos de puerta de enlace

La puerta de enlace requiere al menos dos nodos de EC2 para una alta disponibilidad. Hay dos opciones de configuración de nodos compatibles para la puerta de enlace:

  • Modo automático de EKS (recomendado): los nodos se aprovisionan automáticamente mediante NodePool y NodeClass. La comprobación de origen/destino, las etiquetas y los taints se configuran de forma declarativa.

  • Grupos de nodos administrados: los nodos se aprovisionan mediante un grupo de nodos administrados o nodos autoadministrados. Las etiquetas se pueden configurar a través de la API del grupo de nodos administrados y la comprobación de origen y destino se puede desactivar mediante una plantilla de lanzamiento personalizada con datos de usuario.

Modo automático de EKS (recomendado)

Cuando utilice el modo automático de EKS, debe crear un NodePool y un NodeClass antes de instalar el gráfico de Helm. El NodePool aprovisiona las instancias de EC2 con las etiquetas, los taints y la configuración de comprobación de origen y destino correctas. No es necesario aprovisionar ni configurar los nodos de forma manual.

Aplique los siguientes recursos a su clúster y sustituya los valores de los marcadores de posición:

  • YOUR_NODE_ROLE: el nombre del rol de IAM de nodo utilizado por el modo automático de EKS para aprovisionar nodos. Este es el rol que configuró (o que creó EKS) al activar el modo automático en el clúster. Para obtener más información, consulte Creación de un rol de IAM de nodo para el modo automático de EKS.

  • YOUR_CLUSTER_NAME: el nombre de su clúster de EKS.

  • SUBNET_ID_1, SUBNET_ID_2: ID de subred en diferentes zonas de disponibilidad donde se aprovisionarán los nodos de puerta de enlace.

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: hybrid-gateway spec: advancedNetworking: sourceDestCheck: DisabledPrimaryENI role: YOUR_NODE_ROLE securityGroupSelectorTerms: - tags: aws:eks:cluster-name: YOUR_CLUSTER_NAME subnetSelectorTerms: - id: SUBNET_ID_1 - id: SUBNET_ID_2 --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: hybrid-gateway spec: template: metadata: labels: hybrid-gateway-node: "true" spec: expireAfter: 336h nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: hybrid-gateway requirements: - key: karpenter.sh/capacity-type operator: In values: - on-demand - key: eks.amazonaws.com/instance-category operator: In values: - c - m - r - key: eks.amazonaws.com/instance-generation operator: Gt values: - "4" - key: kubernetes.io/arch operator: In values: - amd64 - key: kubernetes.io/os operator: In values: - linux taints: - key: hybrid-gateway-node effect: NoSchedule terminationGracePeriod: 24h0m0s disruption: budgets: - nodes: 10% consolidateAfter: 30s consolidationPolicy: WhenEmptyOrUnderutilized

Campos clave de esta configuración:

  • advancedNetworking.sourceDestCheck: DisabledPrimaryENI: desactiva la comprobación de origen y destino de EC2 en el ENI principal del nodo para que la puerta de enlace pueda reenviar el tráfico que no está dirigido a sí misma.

  • taints: el taint hybrid-gateway-node: NoSchedule garantiza que solo estén en estos nodos los pods de puerta de enlace con una programación de tolerancia coincidente.

  • labels: el selector de nodos del diagrama de Helm utiliza la etiqueta hybrid-gateway-node: "true" para dirigir los pods de puerta de enlace a estos nodos.

  • nodeClassRef: vincula el NodePool al NodeClass con la configuración de comprobación de origen/destino.

Grupos de nodos administrados

Cuando utilice grupos de nodos administrados, cree un grupo de nodos dedicado para la puerta de enlace con las etiquetas y los taints necesarios y una plantilla de lanzamiento personalizada que desactive la comprobación de origen y destino en el momento del lanzamiento.

Paso 1: crear una plantilla de inicialización

Cree una plantilla de lanzamiento con datos de usuario que desactive la comprobación de origen y destino en el ENI principal al arrancar la instancia:

# Create the launch template with user data to disable source/dest check USERDATA=$(cat <<'SCRIPT' | base64 -w 0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==BOUNDARY==" --==BOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 60") MAC=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/mac) ENI_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \ "http://169.254.169.254/latest/meta-data/network/interfaces/macs/${MAC}/interface-id") REGION=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/placement/region) aws ec2 modify-network-interface-attribute \ --network-interface-id "$ENI_ID" \ --no-source-dest-check \ --region "$REGION" --==BOUNDARY==-- SCRIPT ) aws ec2 create-launch-template \ --launch-template-name YOUR_CLUSTER_NAME-gateway-lt \ --launch-template-data "{\"UserData\":\"${USERDATA}\",\"MetadataOptions\":{\"HttpTokens\":\"required\",\"HttpPutResponseHopLimit\":2}}"
nota

El rol de IAM del nodo debe tener el permiso ec2:ModifyNetworkInterfaceAttribute para que el script de datos de usuario se ejecute correctamente. El formato MIME multiparte garantiza que los datos del usuario se ejecuten junto con el script de arranque de EKS.

Paso 2: crear el grupo de nodos administrados

Cree un grupo de nodos administrados dedicado con la etiqueta de puerta de enlace, el taint y la plantilla de lanzamiento del paso 1:

aws eks create-nodegroup \ --cluster-name YOUR_CLUSTER_NAME \ --nodegroup-name YOUR_CLUSTER_NAME-gateway-nodes \ --subnets SUBNET_ID_1 SUBNET_ID_2 \ --node-role YOUR_NODE_ROLE_ARN \ --instance-types INSTANCE_TYPE \ --ami-type AL2023_x86_64_STANDARD \ --scaling-config desiredSize=2,maxSize=2,minSize=2 \ --labels hybrid-gateway-node=true \ --taints "key=hybrid-gateway-node,effect=NO_SCHEDULE" \ --launch-template "name=YOUR_CLUSTER_NAME-gateway-lt,version=1"

Esto crea un grupo de nodos administrados de 2 nodos en el que:

  • --labels se establece en hybrid-gateway-node=true de manera que el selector de nodos del gráfico de Helm se dirija a estos nodos.

  • --taints agrega un taint NoSchedule para que solo estén en estos nodos los pods de puerta de enlace con una programación de tolerancia coincidente.

  • --launch-template adjunta la plantilla de lanzamiento que desactiva la comprobación de origen y destino durante el arranque.

Utilice subredes en diferentes zonas de disponibilidad para lograr una alta disponibilidad.

Instalación con Helm

Modo automático de EKS

Ejecute el siguiente comando para instalar la puerta de enlace con el modo automático de EKS:

helm install eks-hybrid-nodes-gateway \ oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \ --version 1.0.0 \ --namespace eks-hybrid-nodes-gateway \ --create-namespace \ --set vpcCIDR=VPC_CIDR \ --set podCIDRs=POD_CIDRS \ --set routeTableIDs=ROUTE_TABLE_IDS

Grupos de nodos administrados o nodos autoadministrados

En el caso de los grupos de nodos administrados o nodos autoadministrados, establezca autoMode.enabled=false:

helm install eks-hybrid-nodes-gateway \ oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \ --version 1.0.0 \ --namespace eks-hybrid-nodes-gateway \ --create-namespace \ --set autoMode.enabled=false \ --set vpcCIDR=VPC_CIDR \ --set podCIDRs=POD_CIDRS \ --set routeTableIDs=ROUTE_TABLE_IDS

Valores de Helm necesarios

Los siguientes valores son necesarios para todas las instalaciones:

Valor Descripción

vpcCIDR

El bloque de CIDR de la VPC del clúster de EKS (por ejemplo, 10.0.0.0/16). Se utiliza para la configuración VTEP de Cilium, de modo que los nodos híbridos enruten el tráfico vinculado a VPC a través de la puerta de enlace.

podCIDRs

Lista separada por comas de los CIDR del pod utilizados por Cilium en nodos híbridos (por ejemplo, 10.100.0.0/16,10.101.0.0/16). La puerta de enlace crea entradas en la tabla de enrutamiento de la VPC y rutas de VXLAN para estos CIDR.

routeTableIDs

Lista separada por comas de los ID de las tablas de enrutamiento de la VPC para programar (por ejemplo, rtb-0abc1234def567890,rtb-0fed9876cba543210). La puerta de enlace crea rutas en estas tablas que dirigen los CIDR del pod híbrido a la instancia de puerta de enlace activa.

Para obtener una lista completa de los valores configurables, consulte Referencia de configuración de la puerta de enlace de Nodos híbridos de Amazon EKS.

Verificar la instalación

Tras instalar la puerta de enlace, compruebe que esté funcionando y en buen estado.

Comprobación del estado del pod

Confirme que los dos pods de la puerta de enlace estén en ejecución:

kubectl get pods -n eks-hybrid-nodes-gateway

Debería ver una salida similar a esta:

NAME READY STATUS RESTARTS AGE eks-hybrid-nodes-gateway-5d4f6a7b8c-abc12 1/1 Running 0 2m eks-hybrid-nodes-gateway-5d4f6a7b8c-def34 1/1 Running 0 2m

Comprobación de la elección de líder

Compruebe que un grupo haya adquirido la concesión elegida como líder:

kubectl get lease -n eks-hybrid-nodes-gateway

La salida muestra el líder actual en la columna HOLDER:

NAME HOLDER AGE hybrid-gateway-leader eks-hybrid-nodes-gateway-5d4f6a7b8c-abc12 2m

Comprobación del punto de conexión de estado

Compruebe que el punto de conexión de estado responde en el pod líder mediante el reenvío de puertos:

kubectl port-forward -n eks-hybrid-nodes-gateway LEADER_POD_NAME 8088:8088 & curl -s http://localhost:8088/healthz

Una puerta de enlace en buen estado devuelve una respuesta HTTP 200.

Comprobación de las entradas de la tabla de enrutamiento de la VPC

En la consola de Amazon VPC o mediante la AWS CLI, confirme que las tablas de enrutamiento de la VPC contengan entradas para los CIDR de los pods híbridos que apuntan al ENI de la instancia de puerta de enlace líder:

aws ec2 describe-route-tables \ --route-table-ids ROUTE_TABLE_ID \ --query "RouteTables[].Routes[?DestinationCidrBlock=='[.replaceable]`POD_CIDR`']"

Cada CIDR de pod híbrido debe tener una ruta con el NetworkInterfaceId configurado en el ENI principal de la instancia líder.

Desinstalación

Para eliminar la puerta de enlace de nodos híbridos, ejecute:

helm uninstall eks-hybrid-nodes-gateway --namespace eks-hybrid-nodes-gateway
nota

La desinstalación del gráfico de Helm no elimina automáticamente las entradas de la tabla de enrutamiento de la VPC creadas por la puerta de enlace. Tras la desinstalación, elimine manualmente las rutas de los CIDR de los pods híbridos de las tablas de enrutamiento de la VPC para evitar enrutar el tráfico a instancias que ya no ejecutan la puerta de enlace. Puede eliminar rutas mediante la AWS CLI:

aws ec2 delete-route \ --route-table-id ROUTE_TABLE_ID \ --destination-cidr-block POD_CIDR

Siguientes pasos