Creación de un LoadBalancer Service

Escenario

Los LoadBalancer Service pueden acceder a cargas de trabajo desde la red pública con ELB, que es más fiable que el acceso basado en EIP. La dirección de acceso de LoadBalancer tiene el formato de Dirección IP del balanceador de carga de red pública:Puerto de acceso, por ejemplo, 10.117.117.117:80.

En este modo de acceso, las solicitudes se transmiten a través de un balanceador de carga de ELB a un nodo y luego se reenvían al pod de destino a través del Servicio.

Figura 1 LoadBalancer

Cuando se utilizan clúster de CCE Turbo y balanceador de carga dedicados, se admite la red de paso a través para reducir la latencia del servicio y garantizar cero pérdidas de rendimiento.

Las solicitudes de acceso externo se reenvían directamente desde un balanceador de carga a los pods. Las solicitudes de acceso interno se pueden reenviar a un pod con un Service.

Figura 2 Redes passthrough

Restricciones

• LoadBalancer Services permiten acceder a cargas de trabajo desde las redes públicas con ELB. Este modo de acceso tiene las siguientes restricciones:
  • Los balanceadores de carga creados automáticamente no deben ser utilizados por otros recursos. De lo contrario, estos balanceadores de carga no se pueden eliminar por completo.
  • No cambie el nombre de oyente para el balanceador de carga en clústeres de v1.15 y anteriores. De lo contrario, no se puede acceder al balanceador de carga.
• Después de crear un Service, si la configuración de afinidad se cambia del nivel de clúster al nivel de nodo, la tabla de seguimiento de conexiones no se borrará. Se recomienda no modificar la configuración de afinidad del Service después de que se haya creado el Servicio. Si necesita modificarlo, vuelva a crear un Service.
• Si la afinidad de servicio se establece en el nivel de nodo (es decir, se establece externalTrafficPolicy en Local), el clúster puede no tener acceso al Service mediante la dirección de ELB. Para obtener más información, véase Por qué un clúster no puede acceder a los servicios mediante el uso de la dirección de ELB.
• Los clústeres de Turbo de CCE solo admiten la afinidad de servicio a nivel de clúster.
• Los balanceadores de carga de ELB dedicados solo se pueden usar en clústeres de v1.17 y posteriores.
• Los balanceadores de carga dedicados deben ser del tipo de red (TCP/UDP) que admita las redes privadas (con una IP privada). Si Service necesita soportar HTTP, las especificaciones de los balanceadores de carga dedicados deben usar HTTP/HTTPS (balanceo de carga de aplicación) además de TCP/UDP (balanceo de carga de red).
• Si crea un LoadBalancer Service en la consola de CCE, se genera automáticamente un puerto de nodo aleatorio. Si utiliza kubectl para crear un LoadBalancer Service, se genera un puerto de nodo aleatorio a menos que especifique uno.
• En un clúster de CCE, si la afinidad a nivel de clúster está configurada para un LoadBalancer Service, las solicitudes se distribuyen a los puertos de nodo de cada nodo mediante SNAT al ingresar al clúster. El número de puertos de nodo no puede exceder el número de puertos de nodo disponibles en el nodo. Si la afinidad de servicio está en el nivel de nodo (local), no existe tal restricción. En un clúster de CCE Turbo, esta restricción se aplica a los balanceadores de carga ELB compartidos, pero no a los dedicados. Se recomienda utilizar balanceadores de carga ELB dedicados en clústeres de CCE Turbo.
• Cuando el modo de reenvío (proxy) del servicio de clúster es IPVS, la IP del nodo no se puede configurar como la IP externa del Service. De lo contrario, el nodo no está disponible.
• En un clúster que usa el modo proxy IPVS, si el ingreso y el Service usan el mismo balanceador de carga de ELB, no se puede acceder a la entrada desde los nodos y contenedores en el clúster porque kube-proxy monta la dirección de LoadBalancer Service en el puente ipvs-0. Este puente intercepta el tráfico del balanceador de carga conectado a la entrada. Se recomienda utilizar diferentes balanceadores de carga de ELB para la entrada y el Service.

Creación de un LoadBalancer Service

1. Inicie sesión en la consola de CCE y acceda a la consola del clúster.
2. Elija Networking en el panel de navegación y haga clic en Create Service en la esquina superior derecha.
3. Configure los parámetros.
   • Service Name: Especifique un nombre de Service, que puede ser el mismo que el nombre de la carga de trabajo.
   • Access Type: Seleccione LoadBalancer.
   • Namespace: Espacio de nombres al que pertenece la carga de trabajo.
   • Service Affinity: Para más información, véase externalTrafficPolicy (afinidad del Service).
     • Cluster level: Las direcciones IP y los puertos de acceso de todos los nodos de un clúster se pueden utilizar para acceder a la carga de trabajo asociada con el Service. El acceso al Service causará una pérdida de rendimiento debido a la redirección de la ruta y no se puede obtener la dirección IP de origen del cliente.
     • Node level: Solo la dirección IP y el puerto de acceso del nodo donde se encuentra la carga de trabajo pueden acceder a la carga de trabajo asociada con el Service. El acceso al Service no causará pérdida de rendimiento debido a la redirección de la ruta, y se puede obtener la dirección IP de origen del cliente.
   • Selector: Agregue una etiqueta y haga clic en Add. Un Service selecciona un pod basado en la etiqueta agregada. También puede hacer clic en Reference Workload Label para hacer referencia a la etiqueta de una carga de trabajo existente. En el cuadro de diálogo que se muestra, seleccione una carga de trabajo y haga clic en OK.
   • IPv6: Esta función está deshabilitada por defecto. Una vez habilitada esta función, la dirección IP del clúster del Service cambia a una dirección IPv6. Para obtener más información, consulte Creación de un clúster de doble pila IPv4/IPv6 en CCE. Este parámetro solo está disponible en clústeres de v1.15 o posterior con IPv6 habilitado (establecido durante la creación del clúster).
   • Load Balancer

     Seleccione el balanceador de carga que desea interconectar. Solo se admiten balanceadores de carga en la misma VPC que el clúster. Si no hay ningún balanceador de carga disponible, haga clic en Create Load Balancer para crear uno en la consola de ELB.

     La consola de CCE admite la creación automática de balanceadores de carga. Seleccione Auto create en el cuadro de lista desplegable y establezca los siguientes parámetros:

     • Instance Name: Ingrese un nombre de balanceador de carga.
     • Public Access: Si está habilitado, se creará una EIP con ancho de banda de 5 Mbit/s. De forma predeterminada, se cobra por el tráfico.
     • AZ, Subnet y Specifications (disponible solo para balanceadores de carga dedicados): Establezca la AZ, la subred y las especificaciones. Actualmente, solo se pueden crear automáticamente los balanceadores de carga dedicados del tipo de red (TCP/UDP).

     Puede hacer clic en Edit y configurar los parámetros del balanceador de carga en el cuadro de diálogo Load Balancer.

     • Distribution Policy: Hay tres algoritmos disponibles: Round robin ponderado, algoritmo de conexiones mínimas ponderadas o hash de IP de origen.
       

       • Round robin ponderado: las solicitudes se reenvían a diferentes servidores en función de sus pesos, lo que indica el rendimiento del procesamiento del servidor. Los servidores backend con mayores pesos reciben proporcionalmente más solicitudes, mientras que los servidores con igual peso reciben el mismo número de solicitudes. Este algoritmo se utiliza a menudo para las conexiones cortas, como los servicios de HTTP.
       • Conexiones mínimas ponderadas: Además del peso asignado a cada servidor, también se considera el número de conexiones procesadas por cada servidor backend. Las solicitudes se reenvían al servidor con la relación de conexiones/peso más baja. Basado en las conexiones mínimas, el algoritmo conexiones mínimas ponderadas asigna un peso a cada servidor basado en su capacidad de procesamiento. Este algoritmo se utiliza a menudo para las conexiones persistentes, tales como las conexiones de base de datos.
       • Hash de IP de origen: La dirección IP de origen de cada solicitud se calcula usando el algoritmo hash para obtener una clave hash única, y todos los servidores backend están numerados. La clave generada asigna el cliente a un servidor determinado. Esto permite que las solicitudes de diferentes clientes se distribuyan en modo de equilibrio de carga y garantiza que las solicitudes del mismo cliente se reenvíen al mismo servidor. Este algoritmo se aplica a las conexiones de TCP sin cookies.
     • Type: Esta función está deshabilitada por defecto. Puede seleccionar Source IP address. La sesión adhesiva basada en la dirección IP de origen significa que las solicitudes de acceso desde la misma dirección IP se reenvían al mismo servidor backend.
       

       Cuando la política de distribución utiliza el algoritmo de dirección IP de origen, no se puede establecer la sesión adhesiva.

   • Health Check: Establezca la configuración de comprobación de estado del balanceador de carga. De forma predeterminada, la comprobación de estado se realiza globalmente.

     Parámetro	Descripción
     Protocol	Cuando el protocolo de Puerto se establece en TCP, se admiten TCP y HTTP. Cuando el protocolo del Puerto se establece en UDP, se admite el UDP. Check Path (soportado solo por HTTP): especifica el URL de comprobación de estado. La ruta de comprobación debe comenzar con un (/) de barra diagonal y contener entre 1 y 80 caracteres.
     Port	De forma predeterminada, el puerto de Service (Puerto de nodo y puerto contenedor del Service) se utiliza para la comprobación de estado. También puede especificar otro puerto para la comprobación de estado. Después de especificar el puerto, se agregará un puerto de servicio llamado cce-healthz para el Service. Node Port: si se utiliza un balanceador de carga compartido o no se asocia ninguna instancia ENI, el puerto de nodo se utiliza como puerto de comprobación de estado. Si no se especifica este parámetro, se utiliza un puerto aleatorio. El valor oscila entre 30000 y 32767. Container Port: Cuando un balanceador de carga dedicado está asociado a una instancia ENI, el puerto contenedor se utiliza para la comprobación de estado. El valor varía de 1 a 65535.
     Check Period (s)	Especifica el intervalo máximo entre las comprobaciones de estado. El valor varía de 1 a 50.
     Timeout (s)	Especifica la duración máxima del tiempo de espera para cada comprobación de estado. El valor varía de 1 a 50.
     Max. Retries	Especifica el número máximo de reintentos de comprobación de estado. El valor varía de 1 a 10.

   • Port
     • Protocol: protocolo utilizado por el Service.
     • Service Port: puerto utilizado por el Service. El número de puerto se encuentra dentro del rango de 1 a 65535.
     • Container Port: puerto en el que escucha la carga de trabajo. Por ejemplo, Nginx utiliza el puerto 80 de forma predeterminada.
   • Annotation: El LoadBalancer Service tiene algunas funciones avanzadas de CCE, que se implementan mediante anotaciones. Para obtener más información, véase Uso de anotaciones para configurar el balanceo de carga.

4. Haga clic en OK.

Uso de kubectl para crear un Service (Uso de un balanceador de carga existente)

Puede establecer el Service al crear una carga de trabajo con kubectl. En esta sección se utiliza una carga de trabajo Nginx como ejemplo para describir cómo agregar un LoadBalancer Service usando kubectl.

1. Utilice kubectl para conectarse al clúster. Para obtener más información, véase Conexión a un clúster con kubectl.
2. Cree los archivos llamados nginx-deployment.yaml y nginx-elb-svc.yaml y edítelos.

   Los nombres de archivo están definidos por el usuario. nginx-despliegue.yaml y nginx-elb-svc.yaml son simplemente los nombres de archivo de ejemplo.

   vi nginx-deployment.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - image: nginx 
           name: nginx
         imagePullSecrets:
         - name: default-secret

   vi nginx-elb-svc.yaml

   

   Antes de habilitar la sesión adhesiva, asegúrese de que se cumplen las siguientes condiciones:

   • El protocolo de carga de trabajo es TCP.
   • La antiafinidad se ha configurado entre los pods de la carga de trabajo. Es decir, todos los pods de la carga de trabajo se despliegan en los nodos diferentes. Para obtener más información, véase Política de programación (afinidad/antiafinidad).

   apiVersion: v1 
   kind: Service 
   metadata: 
     name: nginx
     annotations:
       kubernetes.io/elb.id: <your_elb_id>                         # ELB ID. Replace it with the actual value.
       kubernetes.io/elb.class: performance                   # Load balancer type
       kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
       kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
       kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
       kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
       kubernetes.io/elb.health-check-option: '{
         "protocol":"TCP",
         "delay":"5",
         "timeout":"10",
         "max_retries":"3"
       }'
   spec:
     selector: 
        app: nginx
     ports: 
     - name: service0 
       port: 80     # Port for accessing the Service, which is also the listener port on the load balancer.
       protocol: TCP 
       targetPort: 80  # Port used by a Service to access the target container. This port is closely related to the applications running in a container.
     type: LoadBalancer

   El ejemplo anterior utiliza anotaciones para implementar algunas funciones avanzadas de balanceo de carga, como la sesión adhesiva y la comprobación de estado. Para obtener más información, véase Tabla 1.

   Además de las funciones de este ejemplo, para más anotaciones y ejemplos relacionados con funciones avanzadas, consulte Uso de anotaciones para configurar el balanceo de carga.

   Tabla 1 parámetros de anotaciones

   Parámetro	Obligatorio	Tipo	Descripción
   kubernetes.io/elb.id	Sí	String	ID de un balanceador de carga mejorado. Obligatorio cuando se va a asociar un balanceador de carga existente. Cómo obtenerlo: En la consola de gestión, haga clic en Service List y elija Networking > Elastic Load Balance. Haga clic en el nombre del balanceador de carga de destino. En la página de ficha Summary, encuentre y copie el ID. NOTA: El sistema se conecta preferentemente al balanceador de carga basándose en el campo kubernetes.io/elb.id. Si no se especifica este campo, se utiliza el campo spec.loadBalancerIP (opcional y disponible solo en 1.23 y versiones anteriores). No utilice el campo spec.loadBalancerIP para conectarse al balanceador de carga. Este campo será descartado por Kubernetes. Para obtener más información, consulte Deprecation.
   kubernetes.io/elb.class	Sí	String	Seleccione un tipo de balanceador de carga adecuado. El valor puede ser: union: balanceador de carga compartido performance: balanceador de carga dedicado, que solo se puede utilizar en clústeres de v1.17 y posteriores. Para obtener más información, consulte Diferencias entre los balanceadores de carga compartidos y los dedicados.
   kubernetes.io/elb.lb-algorithm	No	String	Especifica el algoritmo de equilibrio de carga del grupo de servidores backend. El valor predeterminado es ROUND_ROBIN. Opciones: ROUND_ROBIN: algoritmo de round robin ponderado LEAST_CONNECTIONS: algoritmo de conexiones mínimas ponderadas SOURCE_IP: algoritmo de hash IP de origen NOTA: Si este parámetro se establece en SOURCE_IP, la configuración de ponderación (campo weight) de los servidores backend vinculados al grupo de servidores backend no es válida y no se puede habilitar la sesión adhesiva.
   kubernetes.io/elb.session-affinity-mode	No	String	Se admite la sesión adhesiva basada en la dirección IP de origen. Es decir, las solicitudes de acceso desde la misma dirección IP se reenvían al mismo servidor backend. Deshabilitar sesión adhesiva: No configure este parámetro. Activar la sesión adhesiva: Establezca este parámetro en SOURCE_IP para indicar que la sesión adhesiva se basa en la dirección IP de origen. NOTA: Cuando kubernetes.io/elb.lb-algorithm se establece en SOURCE_IP (algoritmo de dirección IP de origen), no se puede activar la sesión adhesiva.
   kubernetes.io/elb.session-affinity-option	No	Tabla 2 object	Tiempo de espera de sesión adhesiva.
   kubernetes.io/elb.health-check-flag	No	String	Si se debe habilitar la comprobación de estado del ELB. Habilitar la comprobación de estado: Deje en blanco este parámetro o configúrelo en on. Deshabilitar la comprobación de estado: Establezca este parámetro en off. Si este parámetro está habilitado, el campo kubernetes.io/elb.health-check-option también debe especificarse al mismo tiempo.
   kubernetes.io/elb.health-check-option	No	Tabla 3 object	Elementos de configuración de comprobación de estado de ELB.

   Tabla 2 Estructura de datos del campo elb.session-affinity-option

   Parámetro	Obligatorio	Tipo	Descripción
   persistence_timeout	Sí	String	Tiempo de espera de sesión adhesiva, en minutos. Este parámetro solo es válido cuando elb.session-affinity-mode está establecido en SOURCE_IP. Rango de valores: 1 a 60. Valor predeterminado: 60

   Tabla 3 Descripción de la estructura de datos del campo elb.health-check-option

   Parámetro	Obligatorio	Tipo	Descripción
   delay	No	String	Tiempo de espera inicial (en segundos) para iniciar la comprobación de estado. Rango de valores: 1 a 50. Valor predeterminado: 5
   timeout	No	String	Tiempo de espera de la comprobación de estado, en segundos. Rango de valores: 1 a 50. Valor predeterminado: 10
   max_retries	No	String	Número máximo de reintentos de comprobación de estado. Rango de valores: 1 a 10. Valor predeterminado: 3
   protocol	No	String	Protocolo de comprobación de estado. Opciones de valor: TCP o HTTP
   path	No	String	URL de comprobación de estado. Este parámetro debe configurarse cuando el protocolo es HTTP. Valor predeterminado: / El valor puede contener de 1 a 10,000 caracteres.

3. Cree una carga de trabajo.

   kubectl create -f nginx-deployment.yaml

   Si se muestra información similar a la siguiente, se ha creado la carga de trabajo.

   deployment/nginx created

   kubectl get pod

   Si se muestra la información similar a la siguiente, la carga de trabajo se está ejecutando.

   NAME                     READY     STATUS             RESTARTS   AGE
   nginx-2601814895-c1xhw   1/1       Running            0          6s

4. Crear un Service.

   kubectl create -f nginx-elb-svc.yaml

   Si se muestra la información similar a la siguiente, se ha creado el Service.

   service/nginx created

   kubectl get svc

   Si se muestra la información similar a la siguiente, se ha definido el tipo de acceso y se puede acceder a la carga de trabajo.

   NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
   kubernetes   ClusterIP      10.247.0.1       <none>        443/TCP        3d
   nginx        LoadBalancer   10.247.130.196   10.78.42.242   80:31540/TCP   51s

5. Ingrese el URL en el cuadro de dirección del navegador, por ejemplo, 10.78.42.242:80. 10.78.42.242 indica la dirección IP del balanceador de carga y 80 indica el puerto de acceso que se muestra en la consola de CCE.

   El Nginx es accesible.

   Figura 3 Acceso a Nginx a través del LoadBalancer Service
   

Uso de kubectl para crear un Service (creación automática de un balanceador de carga)

Puede establecer el Service al crear una carga de trabajo con kubectl. En esta sección se utiliza una carga de trabajo Nginx como ejemplo para describir cómo agregar un LoadBalancer Service usando kubectl.

1. Utilice kubectl para conectarse al clúster. Para obtener más información, véase Conexión a un clúster con kubectl.
2. Cree los archivos llamados nginx-deployment.yaml y nginx-elb-svc.yaml y edítelos.

   Los nombres de archivo están definidos por el usuario. nginx-despliegue.yaml y nginx-elb-svc.yaml son simplemente los nombres de archivo de ejemplo.

   vi nginx-deployment.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - image: nginx 
           name: nginx
         imagePullSecrets:
         - name: default-secret

   vi nginx-elb-svc.yaml

   

   Antes de habilitar la sesión adhesiva, asegúrese de que se cumplen las siguientes condiciones:

   • El protocolo de carga de trabajo es TCP.
   • La antiafinidad se ha configurado entre los pods de la carga de trabajo. Es decir, todos los pods de la carga de trabajo se despliegan en diferentes nodos. Para obtener más información, véase Política de programación (afinidad/antiafinidad).
   Ejemplo de un Service que utiliza un balanceador de carga compartido de red pública:

   apiVersion: v1 
   kind: Service 
   metadata: 
     annotations:   
       kubernetes.io/elb.class: union
       kubernetes.io/elb.autocreate: '{
         "type": "public",
         "bandwidth_name": "cce-bandwidth-1551163379627",
         "bandwidth_chargemode": "bandwidth",
         "bandwidth_size": 5,
         "bandwidth_sharetype": "PER",
         "eip_type": "5_bgp"
       }'
       kubernetes.io/elb.enterpriseID: 0       # ID of the enterprise project to which the load balancer belongs
       kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
       kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
       kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
       kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
       kubernetes.io/elb.health-check-option: '{
         "protocol":"TCP",
         "delay":"5",
         "timeout":"10",
         "max_retries":"3"
       }'
     labels: 
       app: nginx 
     name: nginx 
   spec: 
     ports: 
     - name: service0 
       port: 80
       protocol: TCP 
       targetPort: 80
     selector: 
       app: nginx 
     type: LoadBalancer

   Ejemplo de Service que utiliza un balanceador de carga dedicado de red pública (solo para clústeres de v1.17 y versiones posteriores):

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
     namespace: default
     annotations:
       kubernetes.io/elb.class: performance
       kubernetes.io/elb.autocreate: '{
         "type": "public",
         "bandwidth_name": "cce-bandwidth-1626694478577",
         "bandwidth_chargemode": "bandwidth",
         "bandwidth_size": 5,
         "bandwidth_sharetype": "PER",
         "eip_type": "5_bgp",
         "available_zone": [
            ""
         ],
         "l4_flavor_name": "L4_flavor.elb.s1.small"
       }'
       kubernetes.io/elb.enterpriseID: 0       # ID of the enterprise project to which the load balancer belongs
       kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
       kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
       kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
       kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
       kubernetes.io/elb.health-check-option: '{
         "protocol":"TCP",
         "delay":"5",
         "timeout":"10",
         "max_retries":"3"
       }'
   spec:
     selector:
       app: nginx
     ports:
     - name: cce-service-0
       targetPort: 80
       nodePort: 0
       port: 80
       protocol: TCP
     type: LoadBalancer

   El ejemplo anterior utiliza anotaciones para implementar algunas funciones avanzadas de balanceo de carga, como la sesión adhesiva y la comprobación de estado. Para obtener más información, véase Tabla 4.

   Además de las funciones de este ejemplo, para más anotaciones y ejemplos relacionados con funciones avanzadas, consulte Uso de anotaciones para configurar el balanceo de carga.

   Tabla 4 Parámetros de anotaciones

   Parámetro	Obligatorio	Tipo	Descripción
   kubernetes.io/elb.class	Sí	String	Seleccione un tipo de balanceador de carga adecuado. El valor puede ser: union: balanceador de carga compartido performance: balanceador de carga dedicado, que solo se puede utilizar en clústeres de v1.17 y posteriores. Para obtener más información, consulte Diferencias entre los balanceadores de carga compartidos y los dedicados.
   kubernetes.io/elb.autocreate	Sí	elb.autocreate object	Si se debe crear automáticamente un balanceador de carga asociado con el Service. Ejemplo Si se creará automáticamente un balanceador de carga de red pública, establezca este parámetro en el siguiente valor: {"type":"public","bandwidth_name":"cce-bandwidth-1551163379627","bandwidth_chargemode":"bandwidth","bandwidth_size":5,"bandwidth_sharetype":"PER","eip_type":"5_bgp","name":"james"} Si se creará automáticamente un balanceador de carga de red privada, establezca este parámetro en el siguiente valor: {"type":"inner","name":"A-location-d-test"}
   kubernetes.io/elb.subnet-id	-	String	ID de la subred donde se encuentra el clúster. El valor puede contener de 1 a 100 caracteres. Obligatorio cuando se va a crear automáticamente un clúster de v1.11.7-r0 o anterior. Opcional para los clústeres posteriores a v1.11.7-r0. Para obtener más detalles sobre cómo obtener el valor, consulte ¿Cuál es la diferencia entre la API de subred de VPC y la API de subred de OpenStack Neutron?
   kubernetes.io/elb.enterpriseID	No	String	Los clústeres de v1.15 y versiones posteriores admiten este campo. En clústeres anteriores a v1.15, los balanceadores de carga se crean en el proyecto predeterminado de forma predeterminada. Este parámetro indica el ID del proyecto de empresa en el que se creará el balanceador de carga de ELB. Si este parámetro no se especifica o se establece en 0, los recursos estarán enlazados al proyecto de empresa predeterminado. Cómo obtenerlo: Inicie sesión en la consola de gestión y seleccione Enterprise > Project Management en la barra de menú superior. En la lista que se muestra, haga clic en el nombre del proyecto de empresa de destino y copie el ID en la página de detalles del proyecto de empresa.
   kubernetes.io/elb.lb-algorithm	No	String	Especifica el algoritmo de equilibrio de carga del grupo de servidores backend. El valor predeterminado es ROUND_ROBIN. Opciones: ROUND_ROBIN: algoritmo de round robin ponderado LEAST_CONNECTIONS: algoritmo de conexiones mínimas ponderadas SOURCE_IP: algoritmo de hash IP de origen NOTA: Si este parámetro se establece en SOURCE_IP, la configuración de ponderación (campo weight) de los servidores backend vinculados al grupo de servidores backend no es válida y no se puede habilitar la sesión adhesiva.
   kubernetes.io/elb.session-affinity-mode	No	String	Se admite la sesión adhesiva basada en la dirección IP de origen. Es decir, las solicitudes de acceso desde la misma dirección IP se reenvían al mismo servidor backend. Deshabilitar sesión adhesiva: No configure este parámetro. Activar la sesión adhesiva: Establezca este parámetro en SOURCE_IP para indicar que la sesión adhesiva se basa en la dirección IP de origen. NOTA: Cuando kubernetes.io/elb.lb-algorithm se establece en SOURCE_IP (algoritmo de dirección IP de origen), no se puede activar la sesión adhesiva.
   kubernetes.io/elb.session-affinity-option	No	Tabla 2 object	Tiempo de espera de sesión adhesiva.
   kubernetes.io/elb.health-check-flag	No	String	Si se debe habilitar la comprobación de estado del ELB. Habilitar la comprobación de estado: Deje en blanco este parámetro o configúrelo en on. Deshabilitar la comprobación de estado: Establezca este parámetro en off. Si este parámetro está habilitado, el campo kubernetes.io/elb.health-check-option también debe especificarse al mismo tiempo.
   kubernetes.io/elb.health-check-option	No	Tabla 3 object	Elementos de configuración de comprobación de estado de ELB.

   Tabla 5 Estructura de datos del campo elb.autocreate

   Parámetro	Obligatorio	Tipo	Descripción
   name	No	String	Nombre del balanceador de carga creado automáticamente. Rango de valores: de 1 a 64 caracteres, incluidas las letras minúsculas, los dígitos y los guiones bajos (_). El valor debe comenzar con una letra minúscula y terminar con una letra minúscula o un dígito. Predeterminado: cce-lb+service.UID
   type	No	String	Tipo de red del balanceador de carga. public: balanceador de carga de red pública inner: balanceador de carga de red privada Predeterminado: inner
   bandwidth_name	Sí para los balanceadores de carga de red pública	String	Nombre del ancho de banda. El valor predeterminado es cce-bandwidth-******. Rango de valores: de 1 a 64 caracteres, incluidas las letras minúsculas, los dígitos y los guiones bajos (_). El valor debe comenzar con una letra minúscula y terminar con una letra minúscula o un dígito.
   bandwidth_chargemode	No	String	Modo de facturación de ancho de banda. bandwidth: facturado por ancho de banda traffic: facturado por tráfico Predeterminado: bandwidth
   bandwidth_size	Sí para los balanceadores de carga de red pública	Integer	Tamaño del ancho de banda. El valor predeterminado es de 1 a 2000 Mbit/s. Configure este parámetro en función del rango de ancho de banda permitido en su región.
   bandwidth_sharetype	Sí para los balanceadores de carga de red pública	String	Modo de uso compartido de ancho de banda. PER: Ancho de banda dedicado
   eip_type	Sí para los balanceadores de carga de red pública	String	Tipo de la EIP. 5_telcom: China Telecom 5_union: China Unicom 5_bgp: BGP dinámico 5_sbgp: BGP estático
   vip_subnet_cidr_id	No	String	Subred donde se encuentra el balanceador de carga. Este campo es compatible con clústeres de v1.21 o posterior. Si no se especifica este parámetro, el balanceador de carga de ELB y el clúster están en la misma subred.
   available_zone	Sí	Array of strings	AZ donde se encuentra el balanceador de carga. Puede obtener todas las AZ soportadas por consultar la lista de AZ. Este parámetro solo está disponible para los balanceadores de carga dedicados.
   l4_flavor_name	Sí	String	Nombre de la variante del balanceador de carga de capa 4. Puede obtener todos los tipos admitidos consultando la lista de variantes. Este parámetro solo está disponible para los balanceadores de carga dedicados.
   l7_flavor_name	No	String	Nombre de la variante del balanceador de carga de capa 7. Puede obtener todos los tipos admitidos consultando la lista de variantes. Este parámetro solo está disponible para los balanceadores de carga dedicados. El valor de este parámetro debe ser el mismo que el de l4_flavor_name, es decir, ambas son especificaciones elásticas o especificaciones fijas.
   elb_virsubnet_ids	No	Array of strings	Subred donde se encuentra el servidor de backend del balanceador de carga. Si este parámetro se deja en blanco, se utiliza la subred de clúster predeterminada. Los balanceadores de carga ocupan un número diferente de direcciones IP de subred según sus especificaciones. Por lo tanto, no se recomienda utilizar los bloques CIDR de subred de otros recursos (como clústeres y nodos) como el bloque CIDR del balanceador de carga. Este parámetro solo está disponible para los balanceadores de carga dedicados. Por ejemplo: "elb_virsubnet_ids": [ "14567f27-8ae4-42b8-ae47-9f847a4690dd" ]

3. Cree una carga de trabajo.

   kubectl create -f nginx-deployment.yaml

   Si se muestra la información similar a la siguiente, se está creando la carga de trabajo.

   deployment/nginx created

   kubectl get pod

   Si se muestra la información similar a la siguiente, la carga de trabajo se está ejecutando.

   NAME                     READY     STATUS             RESTARTS   AGE
   nginx-2601814895-c1xhw   1/1       Running            0          6s

4. Crear un Service.

   kubectl create -f nginx-elb-svc.yaml

   Si se muestra la información similar a la siguiente, se ha creado el Service.

   service/nginx created

   kubectl get svc

   Si se muestra la información similar a la siguiente, se ha definido el tipo de acceso y se puede acceder a la carga de trabajo.

   NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
   kubernetes   ClusterIP      10.247.0.1       <none>        443/TCP        3d
   nginx        LoadBalancer   10.247.130.196   10.78.42.242   80:31540/TCP   51s

5. Ingrese el URL en el cuadro de dirección del navegador, por ejemplo, 10.78.42.242:80. 10.78.42.242 indica la dirección IP del balanceador de carga y 80 indica el puerto de acceso que se muestra en la consola de CCE.

   El Nginx es accesible.

   Figura 4 Acceso a Nginx a través del LoadBalancer Service
   

Por qué un clúster no puede acceder a los servicios mediante el uso de la dirección de ELB

upstream connect error or disconnect/reset before headers. reset reason: connection failure

Esto se debe a que cuando se crea el LoadBalancer Service, kube-proxy agrega la dirección de acceso de ELB como IP externa a iptables o IPVS. Si un cliente inicia una solicitud para acceder a la dirección de ELB desde dentro del clúster, la dirección se considera la dirección IP externa del Service y se reenvía directamente por kube-proxy sin pasar a través del ELB fuera del clúster.

Se pueden utilizar los siguientes métodos para resolver este problema:

• (Recomendado) En el clúster, utilice el nombre de dominio de servicio o servicio de ClusterIP para el acceso.
• Establezca externalTrafficPolicy del servicio en Cluster es decir, la afinidad de servicio a nivel de clúster. Tenga en cuenta que esto afecta a la persistencia de la dirección de origen.

  apiVersion: v1 
  kind: Service
  metadata: 
    annotations:   
      kubernetes.io/elb.class: union
      kubernetes.io/elb.autocreate: '{"type":"public","bandwidth_name":"cce-bandwidth","bandwidth_chargemode":"bandwidth","bandwidth_size":5,"bandwidth_sharetype":"PER","eip_type":"5_bgp","name":"james"}'
    labels: 
      app: nginx 
    name: nginx 
  spec: 
    externalTrafficPolicy: Cluster
    ports: 
    - name: service0 
      port: 80
      protocol: TCP 
      targetPort: 80
    selector: 
      app: nginx 
    type: LoadBalancer

• Aprovechando la función de pass-through del Service, kube-proxy se omite cuando se utiliza la dirección de ELB para acceder. Primero se accede al balanceador de carga de ELB y, a continuación, a la carga de trabajo. Para obtener más información, véase Habilitación de redes de paso a través para los servicios de LoadBalancer.
  

  • Después de configurar las redes de paso a través para un balanceador de carga dedicado, no se puede acceder a contenedores en el nodo donde se ejecuta la carga de trabajo a través del Service.
  • Las redes de paso a través no son compatibles con clústeres de v1.15 o anteriores.
  • En el modo de red IPVS, la configuración de paso a través del Service conectado al mismo ELB debe ser la misma.

  apiVersion: v1 
  kind: Service 
  metadata: 
    annotations:   
      kubernetes.io/elb.pass-through: "true"
      kubernetes.io/elb.class: union
      kubernetes.io/elb.autocreate: '{"type":"public","bandwidth_name":"cce-bandwidth","bandwidth_chargemode":"bandwidth","bandwidth_size":5,"bandwidth_sharetype":"PER","eip_type":"5_bgp","name":"james"}'
    labels: 
      app: nginx 
    name: nginx 
  spec: 
    externalTrafficPolicy: Local
    ports: 
    - name: service0 
      port: 80
      protocol: TCP 
      targetPort: 80
    selector: 
      app: nginx 
    type: LoadBalancer