Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones - Amazon EKS
Requisitos previosReutilice los ALB con grupos de entrada(Opcional) Implementación de una aplicación de muestra

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.

Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones

nota

Nuevo: el modo automático de Amazon EKS automatiza las tareas rutinarias para el equilibrio de carga. Para obtener más información, consulte:

Cuando crea una ingress de Kubernetes, se aprovisiona un Application Load Balancer (ALB) de AWS que equilibra la carga del tráfico de aplicaciones. Para obtener más información, consulte ¿Qué es un Application Load Balancer? en la Guía del usuario deApplication Load Balancers y Entrada en la documentación de Kubernetes. Los ALB se pueden utilizar con pods que se implementan en nodos o en AWS Fargate. Puede implementar un ALB en subredes públicas o privadas.

El tráfico de aplicaciones se equilibra en L7 del modelo OSI. Para equilibrar la carga del tráfico de red en L4, implemente un service de Kubernetes del tipo LoadBalancer. Este tipo aprovisiona un Network Load Balancer de AWS. Para obtener más información, consulte Dirija el tráfico de TCP y UDP con equilibradores de carga de red. 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.

Requisitos previos

Para poder equilibrar la carga del tráfico de aplicaciones a una aplicación, 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.

  • Tenga el Controlador del equilibrador de carga de AWS implementado en el 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.

  • Al menos dos subredes en diferentes zonas de disponibilidad. El Controlador del equilibrador de carga de AWS elige una subred de cada zona de disponibilidad. Cuando varias subredes etiquetadas se encuentran en una zona de disponibilidad, el controlador elige la subred cuyo ID de subred vaya primero lexicográficamente. Cada subred debe tener al menos ocho direcciones IP disponibles.

    Si utiliza varios grupos de seguridad adjuntos al nodo de trabajo, debe etiquetarse exactamente un grupo de seguridad de la siguiente manera. Sustituya my-cluster por el nombre del clúster.

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

    • Valor: shared o owned

  • Si utiliza la versión 2.1.1 o anterior del Controlador del equilibrador de carga de AWS, las subredes deben etiquetarse con el formato siguiente. Si utiliza la versión 2.1.2 o posterior, el etiquetado es opcional. No obstante, recomendamos que etiquete una subred si se da cualquiera de las siguientes situaciones. Tiene varios clústeres que se ejecutan en la misma VPC o que tienen varios servicios de AWS que comparten subredes en una VPC. O bien, desea tener más control sobre dónde se aprovisionan los equilibradores de carga para cada clúster. Sustituya my-cluster por 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. Esto es así a menos que especifique de manera explícita los ID de subred como una anotación en un objeto de entrada o servicio. Supongamos que aprovisiona equilibradores de carga mediante la especificación explícita de los ID de subred como una anotación en un objeto de entrada o servicio. En esta situación, Kubernetes y el Controlador del equilibrador de carga de AWS utilizan esas subredes directamente para crear el equilibrador de carga y no se requieren las siguientes etiquetas.

    • 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 balanceadores de carga internos. 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/internal-elb

      • Valor: 1

    • Subredes públicas: deben etiquetarse con el siguiente formato. Esto es para que Kubernetes sepa que debe utilizar solo las subredes que se especificaron para los balanceadores de carga externos. De esta forma, Kubernetes no elige una subred pública en cada zona de disponibilidad (lexicográficamente en función de su 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 de rol de subred no se agregan de manera explícita, el controlador de servicio de Kubernetes examina la tabla de enrutamiento de las subredes de la VPC del clúster. Esto sirve para determinar si la subred es privada o pública. Recomendamos que no dependa de este comportamiento. En su lugar, agregue de manera explícita las etiquetas de rol públicas o privadas. El Controlador del equilibrador de carga de AWS no examina las tablas de enrutamiento. También requiere que las etiquetas privadas y públicas estén presentes para la detección automática correcta.

  • El Controlador del equilibrador de carga de AWS crea los ALB y los recursos de apoyo de AWS necesarios cada vez que se crea un recurso de entrada de Kubernetes en el clúster con la anotación kubernetes.io/ingress.class: alb. El recurso de entrada configura el ALB para dirigir el tráfico HTTP o HTTPS a diferentes pods dentro del clúster. Para asegurarse de que los objetos de entrada utilizan el Controlador del equilibrador de carga de AWS, agregue la siguiente anotación a su especificación de entrada de Kubernetes. Para obtener más información, consulte Especificación de entrada en GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    nota

    Si equilibra la carga en pods IPv6, agregue la siguiente anotación a su especificación de entrada. 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.

alb.ingress.kubernetes.io/ip-address-type: dualstack

  • El Controlador del equilibrador de carga de AWS admite los siguientes modos de tráfico:

    • Instancia: registra los nodos dentro del clúster como destinos para el ALB. El tráfico que llega al ALB se dirige a NodePort para su servicio y, a continuación, se transfiere por proxy a sus pods. Este es el modo de tráfico predeterminado. También puede especificarlo de manera explícita con la anotación alb.ingress.kubernetes.io/target-type: instance.

      nota

      Su servicio de Kubernetes debe especificar el NodePort o el tipo de “LoadBalancer” (Balanceador de carga) necesario para utilizar este modo de tráfico.

    • IP: registra los pods como destinos para el ALB. El tráfico que llega al ALB se dirige directamente a los pods para su servicio. Debe especificar la anotación alb.ingress.kubernetes.io/target-type: ip necesaria para utilizar este modo de tráfico. El tipo de destino de IP es necesario cuando los pods de destino se ejecutan en Fargate o en los Nodos híbridos de Amazon EKS.

  • Para etiquetar ALB creados por el controlador, agregue el siguiente comentario al controlador: alb.ingress.kubernetes.io/tags. Para ver una lista de todos los comentarios disponibles compatibles con el Controlador del equilibrador de carga de AWS, consulte Comentarios de entrada en GitHub.

  • La actualización o degradación de la versión del controlador de ALB puede presentar cambios importantes en las características que dependen de él. Para obtener más información sobre los cambios importantes que se presentan en cada versión, consulte las Notas de la versión del controlador de ALB en GitHub.

Reutilice los ALB con grupos de entrada

Puede compartir un equilibrador de carga de aplicación entre varios recursos de servicio mediante IngressGroups.

Para unir una entrada a un grupo, agregue la siguiente anotación a la especificación de un recurso de entrada de Kubernetes.

alb.ingress.kubernetes.io/group.name: my-group

El nombre del grupo debe:

  • Tener 63 caracteres o menos de longitud.

  • Constar de letras minúsculas, números, - y .

  • Comenzar y terminar por un número o una letra.

El controlador fusiona de manera automática las reglas de entrada para todas las entradas del mismo grupo de entradas. Las soporta con un solo ALB. La mayoría de las anotaciones definidas en una entrada solo se aplican a las rutas definidas por esa entrada. De forma predeterminada, los recursos de entrada no pertenecen a ningún grupo de entradas.

aviso

Riesgo potencial de seguridad

Especifique un grupo de entradas para una entrada solo cuando todos los usuarios de Kubernetes que tienen el permiso RBAC para crear o modificar recursos de entrada tienen el mismo límite de confianza. Si agrega la anotación con un nombre de grupo, otros usuarios de Kubernetes podrán crear o modificar sus entradas para que pertenezcan al mismo grupo de entradas. Si lo hace, puede provocar comportamientos indeseables, como sobrescribir reglas existentes con reglas de mayor prioridad.

Puede agregar un número de orden para el recurso de entrada.

alb.ingress.kubernetes.io/group.order: '10'

El número puede ser entre 1 y 1000. El número más bajo para todas las entradas del mismo grupo de entradas se evalúa primero. Todas las entradas sin esta anotación se evalúan con un valor de cero. Las reglas duplicadas con un número superior pueden sobrescribir reglas con un número inferior. De forma predeterminada, el orden de las reglas entre entradas dentro del mismo grupo de entradas se determina lexicográficamente en función del espacio de nombres y del nombre.

importante

Asegúrese de que cada entrada del mismo grupo de entradas tenga un número de prioridad único. No puede tener números de orden duplicados entre entradas.

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

Puede ejecutar la aplicación de muestra en un clúster que tenga nodos de Amazon EC2, pods de Fargate o ambos.

  1. Si no va a implementar en Fargate, omita este paso. Si va a implementar en Fargate, cree un perfil de Fargate. 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. Sustituya los valores de ejemplo por sus propios valores.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048

  2. Implemente el videojuego 2048 como una aplicación de muestra para comprobar que el Controlador del equilibrador de carga de AWS crea un ALB de AWS como resultado del objeto de entrada. Complete los pasos del tipo de subred en la que va a realizar la implementación.

    1. Si va a implementar en pods de un clúster que creó con la familia IPv6, vaya al siguiente paso.

      • Público:

      kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml

      • Privado:

        1. Descargue el manifiesto.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml

        2. Edite el archivo y busque la línea que indica alb.ingress.kubernetes.io/scheme: internet-facing.

        3. Cambie internet-facing por internal y guarde el archivo.

        4. Aplique el manifiesto al clúster.

          kubectl apply -f 2048_full.yaml

    2. Si va a implementar en pods de un clúster que creó con la familia IPv6, lleve a cabo los pasos siguientes.

      1. Descargue el manifiesto.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml

      2. Abra el archivo en un editor y agregue la siguiente línea a las anotaciones de la especificación de entrada.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Si equilibra la carga en pods internos, en lugar de en pods orientados a Internet, cambie la línea que dice alb.ingress.kubernetes.io/scheme: internet-facing por alb.ingress.kubernetes.io/scheme: internal.

      4. Guarde el archivo.

      5. Aplique el manifiesto al clúster.

        kubectl apply -f 2048_full.yaml

  3. Al cabo de unos minutos, verifique que el recurso de entrada se haya creado con el comando siguiente.

    kubectl get ingress/ingress-2048 -n game-2048

    Un ejemplo de salida sería el siguiente.

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    nota

    Si ha creado el equilibrador de carga en una subred privada, el valor de ADDRESS en la salida anterior aparece precedido por internal-.

Si la entrada no se creó correctamente después de varios minutos, ejecute el siguiente comando para ver los registros del Controlador del equilibrador de carga de AWS. Estos registros pueden contener mensajes de error que pueden ayudarlo a diagnosticar cualquier problema con la implementación.

kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  1. Si ha realizado la implementación en una subred pública, abra un navegador y navegue hasta la URL ADDRESS de la salida del comando anterior para ver la aplicación de muestra. Si no ve nada, actualice el navegador e inténtelo de nuevo. 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 Hosts bastión de Linux en AWS.

    Aplicación de muestra 2048

  2. Cuando termine de experimentar con la aplicación de muestra, elimínela ejecutando alguno de los siguientes comandos.

    • Si aplicó el manifiesto, en lugar de aplicar una copia que haya descargado, utilice el siguiente comando.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml

    • Si descargó y editó el manifiesto, utilice el siguiente comando.

      kubectl delete -f 2048_full.yaml