Dirección del tráfico de TCP y UDP con Network Load Balancers - Amazon EKS
Crear un equilibrador de carga de red(Opcional) Implementación de una aplicación de muestra

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Dirección del tráfico de TCP y UDP con Network Load Balancers

Se equilibra la carga del tráfico de red en L4 del modelo OSI. Para equilibrar la carga del tráfico de aplicaciones en L7, implemente una ingress de Kubernetes, que aprovisiona un equilibrador de carga de aplicación de AWS. Para obtener más información, consulte Dirección de la aplicación y el tráfico de HTTP con Application Load Balancers. Para obtener más información sobre las diferencias entre los dos tipos de equilibrio de carga, consulte Características de Elastic Load Balancing en el sitio web de AWS.

Cuando crea un Service de Kubernetes de tipo LoadBalancer, el controlador del equilibrador de carga del proveedor de nube de AWS crea equilibradores de carga clásicos de AWS de forma predeterminada, pero también puede crear equilibradores de carga de red de AWS. Este controlador solo recibirá correcciones de errores críticos en el futuro. Para obtener más información acerca del uso del equilibrador de carga del proveedor de nube de AWS, consulte controlador del equilibrador de carga del proveedor de nube de AWS en la documentación de Kubernetes. Su uso no se aborda en este tema.

Le recomendamos usar la versión 2.7.2 o una posterior del AWS Load Balancer Controller en lugar del controlador del equilibrador de carga del proveedor de la nube de AWS. El AWS Load Balancer Controller crea equilibradores de carga de red de AWS, pero no crea equilibradores de carga clásica de AWS. El resto de este tema trata sobre el uso del Controlador del equilibrador de carga de AWS.

Un equilibrador de carga de red de AWS puede equilibrar la carga del tráfico de red hacia los Pods implementados en destinos IP e instancias de Amazon EC2 o hacia destinos IP de AWS Fargate. Para obtener más información, consulte Controlador del equilibrador de carga de AWS en GitHub.

Requisitos previos

Antes de poder equilibrar la carga del tráfico de red con el AWS Load Balancer Controller, debe cumplir los siguientes requisitos.

  • Tener un clúster existente. Si no tiene un clúster existente, consulte Introducción a Amazon EKS. Si necesita actualizar la versión de un clúster existente, consulte Actualización del clúster existente a la nueva versión de Kubernetes.

  • Implemente AWS Load Balancer Controller en su clúster. Para obtener más información, consulte Enrutamiento del tráfico de internet con el controlador del equilibrador de carga de AWS. Recomendamos la versión 2.7.2 o posterior.

  • Tener al menos una subred. Si varias subredes etiquetadas se encuentran en una zona de disponibilidad, el controlador elige la primera subred cuyo ID de subred va primero lexicográficamente. La subred debe tener al menos ocho direcciones IP disponibles.

  • Si utiliza la versión 2.1.1 del AWS Load Balancer Controller o anteriores, las subredes deben etiquetarse de la siguiente manera. Si utiliza la versión 2.1.2 o posterior, esta etiqueta es opcional. Es posible que desee etiquetar una subred si tiene varios clústeres que se ejecutan en la misma VPC o varios servicios de AWS que comparten subredes en una VPC y desea tener más control sobre dónde se aprovisionan los equilibradores de carga para cada clúster. Si especifica de manera explícita los ID de subred como una anotación en un objeto de servicio, Kubernetes y el AWS Load Balancer Controller utilizarán esas subredes directamente para crear el equilibrador de carga. El etiquetado de subred no es necesario si elige utilizar este método para aprovisionar los equilibradores de carga y puede omitir los siguientes requisitos de etiquetado de subred privada y pública. Sustituya my-cluster con el nombre del clúster.

    • Clave: kubernetes.io/cluster/my-cluster

    • Valor: shared o owned

  • Las subredes públicas y privadas deben cumplir los siguientes requisitos, a menos que especifique de manera explícita los ID de subred como una anotación en un objeto de servicio o entrada. Si aprovisiona equilibradores de carga mediante la especificación explícita de los ID de subred como una anotación en un objeto de servicio o entrada, Kubernetes y el AWS Load Balancer Controller utilizarán esas subredes directamente para crear el equilibrador de carga, y las siguientes etiquetas no serán necesarias.

    • Subredes privadas: deben etiquetarse con el siguiente formato. De esta manera Kubernetes y el controlador del equilibrador de carga de AWS saben que las subredes se pueden utilizar para equilibradores de carga internos. Si utiliza eksctl o una plantilla de AWS AWS CloudFormation de Amazon EKS para crear la VPC después del 26 de marzo de 2020, las subredes se etiquetan correctamente cuando se crean. Para obtener más información sobre las plantillas de VPC de AWS AWS CloudFormation de Amazon EKS, consulte Creación de una Amazon VPC para su clúster de Amazon EKS.

      • Clave: kubernetes.io/role/internal-elb

      • Valor: 1

    • Subredes públicas: deben etiquetarse con el siguiente formato. Es así para que Kubernetes sepa que debe utilizar solo esas subredes para los equilibradores de carga externos, en lugar de elegir una subred pública en cada zona de disponibilidad (en orden lexicográfico por ID de subred). Si utiliza eksctl o una plantilla de AWS CloudFormation de Amazon EKS para crear la VPC después del 26 de marzo de 2020, las subredes se etiquetan correctamente cuando se crean. Para obtener más información sobre las plantillas de VPC de AWS CloudFormation de Amazon EKS, consulte Creación de una Amazon VPC para su clúster de Amazon EKS.

      • Clave: kubernetes.io/role/elb

      • Valor: 1

    Si las etiquetas del rol de subred no se agregan de manera explícita, el controlador de servicio de Kubernetes examinará la tabla de enrutamiento de las subredes de la VPC del clúster para determinar si la subred es privada o pública. Recomendamos que no dependa de este comportamiento y que, en su lugar, agregue de manera explícita las etiquetas de rol públicas o privadas. El AWS Load Balancer Controller no examina las tablas de enrutamiento y requiere que las etiquetas privadas y públicas estén presentes para la detección automática correcta.

Consideraciones

  • La configuración del equilibradores de carga se controla mediante anotaciones que se agregan al manifiesto del servicio. Las anotaciones de servicio son diferentes cuando se utiliza el AWS Load Balancer Controller en comparación a cuando se utiliza el controlador del equilibrador de carga del proveedor de nube de AWS. Asegúrese de revisar las anotaciones para el AWS Load Balancer Controller antes de implementar los servicios.

  • Cuando se utiliza el Amazon VPC CNI plugin for Kubernetes, el AWS Load Balancer Controller puede equilibrar la carga hacia destinos IP o de instancia de Amazon EC2 y destinos IP de Fargate. Al utilizar complementos de CNI compatibles alternativos, el controlador solo puede equilibrar la carga en los destinos de instancia. Para obtener más información acerca de los tipos de destinos de Network Load Balancer, consulte Tipo de destino en la Guía del usuario para Network Load Balancer.

  • Si desea agregar etiquetas al equilibrador de carga durante su creación o después de ella, agregue la siguiente anotación en la especificación del servicio. Para obtener más información, consulte Etiquetas de recursos de AWS en la documentación del AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags

  • Para asignar direcciones IP elásticas al Network Load Balancer, agregue la siguiente anotación. Sustituya los example values con los Allocation IDs de las direcciones IP elásticas. El número de Allocation IDs debe coincidir con el número de subredes utilizadas para el equilibrador de carga. Para obtener más información, consulte la documentación de AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy

  • Amazon EKS agrega una regla de entrada al grupo de seguridad del nodo para el tráfico del cliente y una regla para cada subred del equilibrador de carga de la VPC a fin de realizar comprobaciones de estado para cada equilibrador de carga de red que cree. La implementación de un servicio de tipo LoadBalancer puede fallar si Amazon EKS intenta crear reglas que superen la cuota del número máximo de reglas permitidas para un grupo de seguridad. Para obtener más información, consulte Grupos de seguridad en las cuotas de Amazon VPC en la Guía del usuario de Amazon VPC. Considere las siguientes opciones a fin de minimizar las posibilidades de exceder el número máximo de reglas para un grupo de seguridad:

    • Solicite un aumento de las reglas por cuota de grupo de seguridad. Para obtener más información, consulte Solicitar un aumento de cuota en la Guía del usuario de Service Quotas.

    • Utilice destinos de IP, en lugar de destinos de instancia. Con los destinos de IP, puede compartir reglas para los mismos puertos de destino. Puede especificar manualmente las subredes del equilibrador de carga con una anotación. Para obtener más información, consulte Anotaciones en GitHub.

    • Utilice una entrada en lugar de un servicio de tipo LoadBalancer para enviar tráfico al servicio. El AWS Application Load Balancer requiere menos reglas que los Network Load Balancers. Puede compartir un ALB entre varias entradas. Para obtener más información, consulte Dirección de la aplicación y el tráfico de HTTP con Application Load Balancers. No puede compartir un Network Load Balancer entre varios servicios.

    • Implemente sus clústeres en varias cuentas.

  • Si los Pods se ejecutan en Windows en un clúster de Amazon EKS, un único servicio con un equilibrador de carga puede admitir hasta 1024 Pods de backend. Cada Pod tiene su propia dirección IP única.

  • Recomendamos crear solo equilibradores de carga de red nuevos con el AWS Load Balancer Controller. Intentar sustituir los Network Load Balancers existentes creados con el Controlador del equilibrador de carga del proveedor de nube de AWS puede dar lugar a varios Network Load Balancers que podrían causar tiempo de inactividad en la aplicación.

Crear un equilibrador de carga de red

Puede crear un equilibrador de carga de red con IP o destinos de instancia.

IP targets

Puede utilizar destinos de IP con Pods implementados en nodos de Amazon EC2 o Fargate. El servicio de Kubernetes debe crearse como tipo LoadBalancer. Para obtener más información, consulte Tipo de equilibradores de carga en la documentación de Kubernetes.

Para crear un equilibrador de carga que utilice destinos IP, agregue las siguientes anotaciones a un manifiesto de servicio e implemente el servicio. El valor external para aws-load-balancer-type es lo que lleva al AWS Load Balancer Controller, en lugar del controlador del equilibrador de carga del proveedor de nube de AWS, a crear el equilibrador de carga de red. Puede ver un manifiesto de servicio de ejemplo con los comentarios.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
nota

Si equilibra la carga en Pods de IPv6, agregue la siguiente anotación. Solo puede equilibrar la carga a través de IPv6 a destinos IP, no a destinos de instancias. Sin esta anotación, la tarea de equilibrar la carga se realiza a través de IPv4.

service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

Los Network Load Balancers se crean con el internal aws-load-balancer-scheme de forma predeterminada. Puede lanzar equilibradores de carga de red en cualquier subred de la VPC del clúster, incluidas las subredes sin especificar cuando creó el clúster.

Kubernetes examina la tabla de enrutamiento de las subredes con el fin de identificar si son públicas o privadas. Las subredes públicas tienen una ruta directa a Internet mediante una puerta de enlace de Internet, pero no así las subredes privadas.

Si desea crear un Network Load Balancer en una subred pública para equilibrar la carga en nodos de Amazon EC2 (Fargate solo puede ser privado), especifique internet-facing con la siguiente anotación:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
nota

La anotación service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" todavía se admite para la compatibilidad con versiones anteriores. Sin embargo, le recomendamos que utilice las anotaciones anteriores para nuevos equilibradores de carga en lugar de service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

importante

No edite los comentarios después de crear el servicio. Si necesita modificarlo, elimine el objeto de servicio y vuelva a crearlo con el valor deseado para este comentario.

Instance targets

El Controlador del equilibrador de carga del proveedor de nube de AWS crea Network Load Balancers solo con destinos de instancia. La versión 2.2.0 y posteriores del Controlador del equilibrador de carga de AWS también crean equilibradores de carga de red con destinos de instancia. Recomendamos utilizarlo, en lugar de utilizar el Controlador del equilibrador de carga del proveedor de nube de AWS, para crear nuevos Network Load Balancers. Puede utilizar destinos de instancia del equilibrador de carga de red con Pods implementados en nodos de Amazon EC2, pero no en Fargate. Para equilibrar la carga del tráfico de red a través de los Pods implementados en Fargate, debe utilizar destinos de IP.

Para implementar un Network Load Balancer en una subred privada, la especificación del servicio debe tener las siguientes anotaciones. Puede ver un manifiesto de servicio de ejemplo con los comentarios. El valor external para aws-load-balancer-type es lo que lleva al Controlador del equilibrador de carga de AWS, en lugar del controlador del equilibrador de carga del proveedor de nube de AWS, a crear el Network Load Balancer.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

Los Network Load Balancers se crean con el internal aws-load-balancer-scheme de forma predeterminada. Para los equilibradores de carga de red internos, el clúster de Amazon EKS debe estar configurado para utilizar al menos una subred privada en la VPC. Kubernetes examina la tabla de enrutamiento de las subredes con el fin de identificar si son públicas o privadas. Las subredes públicas tienen una ruta directa a Internet mediante una puerta de enlace de Internet, pero no así las subredes privadas.

Si desea crear un Network Load Balancer en una subred pública para equilibrar la carga en nodos de Amazon EC2, especifique internet-facing con la siguiente anotación:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
importante

No edite los comentarios después de crear el servicio. Si necesita modificarlo, elimine el objeto de servicio y vuelva a crearlo con el valor deseado para este comentario.

(Opcional) Implementación de una aplicación de muestra

Requisitos previos
Para implementar una aplicación de muestra

  1. Si va a implementar en Fargate, asegúrese de tener una subred privada disponible en la VPC y cree un perfil de Fargate. Si no implementa en Fargate, omita este paso. Puede crear el perfil con la ejecución del siguiente comando o en la AWS Management Console con los mismos valores para name y namespace que los del comando. Reemplace los example values por los de su propiedad.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name nlb-sample-app \
    --namespace nlb-sample-app

  2. Implemente una aplicación de muestra.

    1. Cree un espacio de nombres para la aplicación.

      kubectl create namespace nlb-sample-app

    2. Guarde el siguiente contenido en un archivo denominado sample-deployment.yaml en el equipo.

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nlb-sample-app
  namespace: nlb-sample-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/nginx/nginx:1.23
          ports:
            - name: tcp
              containerPort: 80

    3. Aplique el manifiesto al clúster.

      kubectl apply -f sample-deployment.yaml

  3. Cree un servicio con un equilibrador de carga de red interno que equilibre la carga en destinos IP.

    1. Guarde el siguiente contenido en un archivo denominado sample-service.yaml en el equipo. Si va a implementar en nodos Fargate, elimine la línea service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing.

      apiVersion: v1
kind: Service
metadata:
  name: nlb-sample-service
  namespace: nlb-sample-app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx

    2. Aplique el manifiesto al clúster.

      kubectl apply -f sample-service.yaml

  4. Compruebe que el servicio se haya implementado.

    kubectl get svc nlb-sample-service -n nlb-sample-app

    Un ejemplo de salida sería el siguiente.

    NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com  80:32400/TCP   16h
    nota

    Los valores de 10.100.240.137 y xxxxxxxxxx-xxxxxxxxxxxxxxxx serán diferentes a la salida de ejemplo (serán exclusivos de su equilibrador de carga) y us-west-2 puede ser diferente según la Región de AWS en la que se encuentre el clúster.

  5. Abra la AWS Management Console de Amazon EC2. Seleccione Target Groups (Grupos de destino) (en Load Balancing (Equilibrador de carga) en el panel de navegación izquierdo. En la columna Name (Nombre), seleccione el nombre del grupo de destino donde el valor de la columna Load balancer (Equilibrador de carga) coincida con el nombre de la columna EXTERNAL-IP de la salida en el paso anterior. Por ejemplo, debe seleccionar el grupo de destino denominado k8s-default-samplese-xxxxxxxxxx si la salida es la misma que la salida anterior. El Target type (Tipo de destino) es IP porque así se especificó en el manifiesto del servicio de muestra.

  6. Seleccione el Grupo de destino y elija la pestaña Targets (Destinos). En Registered targets (Destinos registrados), debería ver tres direcciones IP de las tres réplicas implementadas en un paso anterior. Espere hasta que el estado de todos los destinos sea healthy (bueno) antes de continuar. Pueden pasar varios minutos hasta que todos los destinos sean healthy. Los destinos pueden estar en estado unhealthy antes de cambiar al estado healthy.

  7. Envíe tráfico al servicio mediante el reemplazo de xxxxxxxxxx-xxxxxxxxxxxxxxxx y us-west-2 por los valores devueltos en la salida de un paso anterior para EXTERNAL-IP. Si ha realizado la implementación en una subred privada, tendrá que ver la página desde un dispositivo dentro de la VPC, como un host bastión. Para obtener más información, consulte Host bastión de Linux en AWS.

    curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

    Un ejemplo de salida sería el siguiente.

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

  8. Cuando haya terminado de utilizar la implementación, el servicio y el espacio de nombres de muestra, elimínelos.

    kubectl delete namespace nlb-sample-app