Equilibrio de carga de aplicaciones en Amazon EKS - Amazon EKS

Equilibrio de carga de aplicaciones en Amazon EKS

Cuando crea una ingress de Kubernetes, se aprovisiona un equilibrador de carga de aplicación (ALB) de AWS que equilibra la carga del tráfico de aplicaciones. Para obtener más información, consulte ¿Qué es un equilibrador de carga de aplicación? en la Guía del usuario de equilibradores de carga de aplicación 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 Equilibrio de carga de red en Amazon EKS . 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 de una versión de Kubernetes de clúster de Amazon EKS.

  • Implemente AWS Load Balancer Controller en su clúster. Para obtener más información, consulte Instalación del complemento AWS Load Balancer Controller . Recomendamos la versión 2.4.4 o posterior.

  • Al menos dos subredes en diferentes zonas de disponibilidad. El AWS Load Balancer Controller 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 con el nombre del clúster.

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

    • Valor: shared o owned

  • Si utiliza la versión AWS Load Balancer Controller 2.1.1 o anterior, las subredes deben etiquetarse con el siguiente formato. 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 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. 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 equilibradores 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 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 equilibradores 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 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 AWS Load Balancer Controller 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.

Consideraciones

  • El AWS Load Balancer Controller 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 AWS Load Balancer Controller, 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 de los 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 AWS Load Balancer Controller 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 redirige a NodePort para su servicio y, luego, se envía 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” (Equilibrador 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 redirige 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.

  • 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 AWS Load Balancer Controller, consulte Anotaciones 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.

Para compartir un Application Load Balancer 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

Requisitos previos

Para implementar 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 implementa 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. Reemplace los example values por los de su propiedad.

    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 AWS Load Balancer Controller 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.

      • Public

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

        1. Descargue el manifiesto.

          curl -o 2048_full.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/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 a 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 2048_full.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/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

    El ejemplo de resultado es 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 AWS Load Balancer Controller. Estos registros pueden contener mensajes de error que pueden ayudarlo a diagnosticar cualquier problema con la implementación.

    kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller
  4. 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 Host bastión de Linux en AWS.

    
                        Aplicación de muestra 2048
  5. 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.4.4/docs/examples/2048/2048_full.yaml
    • Si descargó y editó el manifiesto, utilice el siguiente comando.

      kubectl delete -f 2048_full.yaml