Container Service for Kubernetes:Service FAQ

¿Qué instancias de CLB crea un clúster de ACK de forma predeterminada?

Si se instala el complemento Nginx Ingress Controller durante la creación del clúster, este genera dos instancias de CLB:

• CLB del servidor de API: Es el endpoint del servidor de API. Todas las solicitudes del clúster pasan por esta instancia a través del puerto TCP 6443. Los backends son pods del servidor de API o instancias ECS maestras.

• CLB de Nginx Ingress Controller: Está asociado al Service nginx-ingress-controller en kube-system. Se vincula dinámicamente a los pods del Ingress Controller para balancear las solicitudes externas. Escucha en los puertos TCP 80 y 443.

¿Cómo elijo entre las directivas de tráfico externo Local y Cluster?

Las directivas de tráfico externo Local y Cluster varían según el plugin de red. Consulte External traffic policies: Local and Cluster.

¿Por qué se modificó mi configuración de CLB?

CCM utiliza una API declarativa y actualiza automáticamente la configuración de CLB basándose en la definición del Service. Los cambios realizados directamente en la consola de CLB pueden sobrescribirse.

¿Cómo se calculan las ponderaciones de los nodos en modo Local?

El siguiente ejemplo utiliza un pod de aplicación (app=nginx) desplegado en tres instancias ECS y expuesto mediante un Service.

¿Cómo habilito el drenado de conexiones para un Service de tipo LoadBalancer?

Agregue las siguientes anotaciones al Service. Cuando se elimina un servidor backend, la instancia de CLB continúa procesando las conexiones existentes durante la duración del tiempo de espera de drenado.

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout

Consulte Enable connection draining for a listener.

¿Cómo listo todas las instancias de CLB en un clúster?

1. Connect to the cluster using kubectl.

2. Obtenga el nombre, namespace, dirección IP y tipo de dirección de cada Service de tipo LoadBalancer. Ejemplo de salida:

      kubectl get services -A -ojson | jq '.items[] | select(.spec.type == "LoadBalancer") | {name: .metadata.name, namespace: .metadata.namespace, ip: .status.loadBalancer.ingress[0].ip, lb_type: .metadata.annotations."service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type"}'

      {
        "name": "test",
        "namespace": "default",
        "ip": "192.168.*.*",
        "lb_type": "intranet"
      }
      {
        "name": "nginx-ingress-lb",
        "namespace": "kube-system",
        "ip": "47.97.*.*",
        "lb_type": "null"
      }

¿Cómo habilito el renombrado de CLB para versiones anteriores de CCM?

CCM v1.9.3.10 y posteriores etiquetan automáticamente las instancias de CLB para permitir el renombrado. Para las instancias de CLB creadas por versiones anteriores de CCM, agregue la etiqueta manualmente.

Este procedimiento aplica únicamente a instancias de CLB creadas por CCM v1.9.3.10 o anterior. El tipo de Service debe ser LoadBalancer.

1. Conéctese al nodo maestro del clúster. Consulte Connect to an ACK cluster using kubectl.

2. Consulte el tipo de Service y la dirección IP. Reemplace ${namespace} y ${service} con el namespace y el nombre del Service correspondientes.

      kubectl get svc -n ${namespace} ${service}

   # kubectl get svc -n ${namespace} ${service}
   nginx-local   LoadBalancer   172.19.xxx.xxx   47.111.xxx.xxx   8900:31598/TCP   33d

3. Genere la etiqueta para la instancia de CLB:

      kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'

   # kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "ku
   kubernetes.do.not.delete: xxx

4. Inicie sesión en la consola de CLB. Con la dirección IP obtenida en el paso 2, busque la instancia de CLB en la región correspondiente.

5. Agregue una etiqueta a la instancia de CLB utilizando la clave y el valor del paso 3 (elementos 1 y 2 en la figura anterior). Consulte Create and manage a CLB instance.

¿Por qué no se puede acceder a una dirección IP de CLB desde dentro del clúster?

Dos escenarios pueden causar esto.

Escenario 1: CLB privado no creado por un Service

Cuando un pod accede a una instancia de CLB privada que no fue creada por un Service, el acceso falla si el pod y un servidor backend están en el mismo nodo. Esta es una limitación de capa 4: una instancia ECS no puede ser simultáneamente servidor backend y cliente para la misma instancia de CLB.

Para resolverlo:

• Cambie la dirección IP del CLB a una dirección IP pública.

• Cree la instancia de CLB a través de un Service y establezca la directiva de tráfico externo en Cluster. Kube-proxy interceptará entonces el tráfico dirigido al CLB desde dentro del clúster, evitando la limitación.

**Escenario 2: externalTrafficPolicy: Local bloquea el acceso interno**

Cuando un Service usa externalTrafficPolicy: Local, el acceso interno a la IP del CLB falla desde los nodos que no tienen un pod backend. La dirección del CLB está destinada al uso externo. El tráfico interno es interceptado por kube-proxy y enrutado localmente (iptables o IPVS). Si el nodo no tiene un pod backend local, la conexión falla.

Consulte kube-proxy adds external-lb address to local node iptables rules.

Soluciones (listadas por recomendación):

1. Acceda internamente a los Services mediante ClusterIP o nombre del Service. Por ejemplo, el nombre del Service de Ingress es nginx-ingress-lb.kube-system. Este es el enfoque recomendado.

2. **Cambie externalTrafficPolicy a Cluster.** Esto reenvía el tráfico a todos los nodos pero habilita SNAT, por lo que el backend no puede obtener la IP real del cliente.

      kubectl edit svc nginx-ingress-lb -n kube-system

3. Utilice passthrough de interfaz de red elástica (ENI) en clústeres Terway. Establezca externalTrafficPolicy en Cluster y agregue la anotación service.beta.kubernetes.io/backend-type: "eni". Esto conserva la IP de origen mientras permite el acceso interno. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          service.beta.kubernetes.io/backend-type: eni
        labels:
          app: nginx-ingress-lb
        name: nginx-ingress-lb
        namespace: kube-system
      spec:
        externalTrafficPolicy: Cluster

¿Cuándo se eliminan las instancias de CLB?

El comportamiento de eliminación depende de si CCM creó la instancia de CLB y de cómo se asoció con el Service.

Si el Service reutiliza una instancia de CLB existente (anotada con service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id}), eliminar el Service no elimina la instancia de CLB. De lo contrario, eliminar el Service también elimina la instancia de CLB.

¿Qué hago si elimino accidentalmente una instancia de CLB?

Escenario 1: CLB de Ingress eliminado

Los siguientes pasos utilizan Nginx Ingress como ejemplo.

1. Inicie sesión en ACK console. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, busque el clúster objetivo y haga clic en su nombre. En el panel de navegación izquierdo, seleccione Network > Services.

3. Seleccione kube-system en la lista desplegable Namespace.

   • Si nginx-ingress-lb aparece en la lista, haga clic en Edit YAML en la columna Actions. Elimine el campo status.loadBalancer y su contenido, luego haga clic en OK. CCM reconstruirá la instancia de CLB.

   • Si nginx-ingress-lb no aparece, haga clic en Create from YAML y utilice la siguiente plantilla: ``yaml apiVersion: v1 kind: Service metadata: labels: app: nginx-ingress-lb name: nginx-ingress-lb namespace: kube-system spec: externalTrafficPolicy: Local ports: selector: app: ingress-nginx type: LoadBalancer ``

     • name: http port: 80 protocol: TCP targetPort: 80

     • name: https port: 443 protocol: TCP targetPort: 443

Escenario 2: CLB específico de aplicación eliminado

• Si ya no necesita el Service, elimínelo.

• Si el Service aún está en uso:

  1. Inicie sesión en ACK console. En el panel de navegación izquierdo, haga clic en Clusters.

  2. En la página Clusters, busque el clúster objetivo y haga clic en su nombre. En el panel de navegación izquierdo, seleccione Network > Services.

  3. En la lista desplegable Namespace, haga clic en All Namespaces y luego busque el Service objetivo.

  4. En la columna Actions, haga clic en Edit YAML. Elimine el contenido de status.loadBalancer y haga clic en OK. CCM reconstruirá la instancia de CLB.

¿Por qué falla la reutilización de una instancia de CLB existente?

Compruebe lo siguiente en orden:

1. Versión de CCM: Las versiones anteriores a v1.9.3.105-gfd4e547-aliyun no admiten la reutilización de instancias de CLB. Para obtener instrucciones de actualización, consulte Upgrade the CCM component.

2. Origen de la instancia: No se pueden reutilizar las instancias de CLB creadas por el clúster.

3. CLB del servidor de API: La instancia de CLB del servidor de API no se puede reutilizar.

4. Desajuste de VPC: Una instancia de CLB privada debe estar en la misma virtual private cloud (VPC) que el clúster. No se admite la reutilización entre distintas VPC.

¿Por qué no se crean listeners al reutilizar una instancia de CLB existente?

Verifique que la anotación service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners sea "true". Sin ella, no se crean los listeners.

CCM no sobrescribe los listeners en instancias de CLB existentes de forma predeterminada:

Sobrescribir listeners activos puede causar interrupciones del servicio.

CCM admite configuraciones de backend limitadas. Para configuraciones complejas, cree los listeners en la consola de CLB. Fuerce la sobrescritura de listeners únicamente cuando sus puertos ya no estén en uso.

¿Qué hago si una instancia de CLB permanece en estado Pending?

1. Ejecute kubectl -n {your-namespace} describe svc {your-svc-name} para revisar los mensajes de eventos.

2. Resuelva los errores reportados en los eventos. Consulte Service error messages and solutions para obtener orientación.

Si no aparecen eventos, consulte Why are no events displayed for Service and LoadBalancer synchronization?

¿Qué hago si no se actualiza un grupo vServer?

1. Ejecute kubectl -n {your-namespace} describe svc {your-svc-name} para revisar los mensajes de eventos.

2. Resuelva los errores reportados en los eventos. Consulte Service error messages and solutions para obtener orientación.

Si no aparecen eventos, consulte Why are no events displayed for Service and LoadBalancer synchronization?

¿Qué hago si una anotación de Service no surte efecto?

1. Ejecute kubectl -n {your-namespace} describe svc {your-svc-name} para buscar eventos de error. Si existen errores, consulte Service error messages and solutions.

2. Si no aparecen errores, compruebe lo siguiente:

   • Versión de CCM: Verifique que la versión de CCM admita la anotación. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

   • Presencia de la anotación: Inicie sesión en la consola de ACK. En la página Services, haga clic en el nombre del Service y confirme que la anotación existe. Si falta, agréguela. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

   • Sintaxis de la anotación: Verifique que la clave y el valor de la anotación sean correctos.

Para ver la lista de Services, consulte Manage services.

¿Por qué no se muestran eventos de sincronización de Service y LoadBalancer?

Si kubectl -n {your-namespace} describe svc {your-svc-name} no muestra eventos, revise la versión de CCM:

• Anterior a v1.9.3.276-g372aa98-aliyun: No se admiten eventos. Actualice CCM. Para obtener instrucciones de actualización, consulte Upgrade the CCM component.

• v1.9.3.276-g372aa98-aliyun y posteriores: Envíe un ticket para una investigación más detallada.

Errores de cuota y recursos

Errores de configuración

Errores de red

Errores de reutilización de CLB

Errores de facturación

¿Cómo accedo a un Service de tipo NodePort?

• Desde dentro del clúster (en un nodo del clúster): Utilice la ClusterIP y el puerto, o bien la IP del nodo y el NodePort del Service. El valor predeterminado de NodePort es mayor que 30000.

• Desde fuera del clúster (dentro de la misma VPC): Utilice la dirección IP del nodo y el NodePort del Service.

• Desde fuera de la VPC (desde otra VPC o desde Internet): Exponga el Service como tipo LoadBalancer y acceda a él mediante su endpoint externo.

Si la directiva de tráfico externo es Local, compruebe que el nodo al que accede aloja un pod backend del Service. Consulte External traffic policies: Local and Cluster .

¿Cómo configuro un listener para un Service de tipo NodePort?

CCM solo admite la configuración de listeners para Services de tipo LoadBalancer. Cambie el tipo de Service de NodePort a LoadBalancer.

¿Cómo configuro el rango de NodePort?

El parámetro --service-node-port-range del servidor de API (ServiceNodePortRange) controla el rango de puertos para los Services de tipo NodePort y LoadBalancer. El rango predeterminado abarca del 30000 al 32767. En los clústeres ACK Pro, personalice los parámetros del plano de control para ajustar este rango. Consulte Customize the parameters of the control plane for an ACK Pro cluster.

Tenga en cuenta lo siguiente:

• Evite conflictos de rangos de puertos. El rango de NodePort no debe superponerse con el parámetro del kernel net.ipv4.ip_local_port_range, que controla los números de puerto locales disponibles para las aplicaciones en el nodo. El valor predeterminado de ip_local_port_range va del 32768 al 60999.

• Los rangos predeterminados son seguros. Con la configuración predeterminada de ACK, ServiceNodePortRange (30000-32767) y ip_local_port_range (32768-60999) no se superponen. Si alguno de los rangos se ha ampliado y ahora se superponen, pueden producirse excepciones de red esporádicas. En casos graves, las comprobaciones de estado fallan y los nodos quedan fuera de línea. Restaure los valores predeterminados o ajuste ambos rangos para eliminar la superposición.

• Reconfigure los Services existentes después de realizar cambios. Tras ajustar el rango de puertos, algunos Services de tipo NodePort o LoadBalancer podrían seguir utilizando puertos dentro del rango ip_local_port_range. Ejecute kubectl edit <service-name> y modifique el campo spec.ports.nodePort por un NodePort que no esté en uso.

¿Qué hago si falla una actualización de CCM?

Consulte Cloud Controller Manager (CCM) upgrade check fails.

¿Cómo agrego los permisos necesarios para una actualización de CCM en un clúster dedicado de ACK?

Las versiones más recientes de CCM introducen API de Alibaba Cloud que requieren permisos adicionales de Resource Access Management (RAM). Por ejemplo, la versión v2.11.2 agrega la gestión de rutas para redes Flannel, y la v2.12.1 incorpora la gestión por lotes para Network Load Balancer (NLB).

Antes de actualizar a la versión v2.11.2 o posterior en un clúster dedicado de ACK, otorgue los permisos necesarios al rol RAM del clúster:

1. Inicie sesión en la ACK console. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, localice el clúster objetivo y haga clic en su nombre. En el panel de navegación izquierdo, haga clic en Cluster Information.

3. Haga clic en la pestaña Basic Information y luego haga clic en el nombre del rol correspondiente a Master RAM Role.

4. En la consola de RAM, haga clic en Permissions > Policies en el panel de navegación izquierdo. Localice la directiva personalizada que comienza con k8sMasterRolePolicy-Ccm- y haga clic en su nombre.

   En clústeres más antiguos, es posible que esta directiva no exista. Seleccione en su lugar una directiva personalizada cuyo nombre comience con k8sMasterRolePolicy- .

5. Haga clic en Edit Policy Document y agregue el permiso nlb:ListAsynJobs a los permisos de NLB. Para clústeres Flannel, agregue también los permisos vpc:CreateRouteEntries y vpc:DeleteRouteEntries a los permisos de VPC.

   "nlb:ListServerGroupServers",
           "nlb:GetJobStatus",
           "nlb:LoadBalancerLeaveSecurityGroup",
           "nlb:LoadBalancerJoinSecurityGroup",
           "nlb:ListAsynJobs"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },

   },
   {
     "Action": [
       "vpc:Describe*",
       "vpc:DeleteRouteEntry",
       "vpc:CreateRouteEntry",
       "vpc:CreateRouteEntries",
       "vpc:DeleteRouteEntries"
     ],
     "Resource": "*",
     "Effect": "Allow"
   }
   ]
   }

6. Envíe los cambios y continúe con la actualización de CCM.