Descripción general

Acceso directo a un pod

Después de crear un pod, pueden producirse los siguientes problemas si accede directamente al pod:

• El pod puede ser borrado y recreado en cualquier momento por un controlador tal como un Deployment, y el resultado de acceder al pod se vuelve impredecible.
• La dirección IP del pod se asigna solo después de iniciar el pod. Antes de iniciar el pod, se desconoce la dirección IP del pod.
• Una aplicación suele estar compuesta por varios pods que ejecutan la misma imagen. Acceder a los pods uno por uno no es eficiente.

Por ejemplo, una aplicación utiliza Deployments para crear el frontend y el backend. El frontend llama al backend para el cómputo, como se muestra en Figura 1. Tres pods están funcionando en el backend, que son independientes y reemplazables. Cuando se vuelve a crear un pod de backend, se asigna al nuevo pod una nueva dirección IP, de la cual el pod de frontend no está al tanto.

Figura 1 Acceso dentro de pod

Uso de Services para el acceso a pods

Los Services de Kubernetes se utilizan para resolver los problemas de acceso a pods anteriores. Un Service tiene una dirección IP fija. (Cuando se crea un clúster de CCE, se establece un bloque CIDR de Service, que se utiliza para asignar direcciones IP a Services.) Un Service reenvía las solicitudes de acceso al Service a los pods basados en etiquetas y, al mismo tiempo, realiza el equilibrio de carga para estos pods.

En el ejemplo anterior, se agrega un Service para que el pod frontend acceda a los pods de backend. De esta manera, el pod frontend no necesita estar al tanto de los cambios en los pods backend, como se muestra en Figura 2.

Figura 2 Acceso a pods con un Service

Tipos de servicio

Kubernetes le permite especificar un servicio de un tipo requerido. Los valores y acciones de los diferentes tipos de Servicios son los siguientes:

• ClusterIP

  Un Service de ClusterIP permite que las cargas de trabajo del mismo clúster utilicen sus nombres de dominio internos del clúster para tener acceso entre sí.

• NodePort

  Un Service de NodePort está expuesto en la IP de cada nodo en un puerto estático. Un Service de ClusterIP, al que se enruta el Service de NodePort, se crea automáticamente. Al solicitar <NodeIP>:<NodePort>, puede acceder a un Service de NodePort desde fuera del clúster.

• LoadBalancer

  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.

• DNAT

  Un gateway de DNAT traduce direcciones para los nodos de clúster y permite que varios nodos de clúster compartan una EIP. Los servicios de DNAT ofrecen una mayor confiabilidad que los servicios de NodePort basados en EIP. No es necesario vincular una EIP a un solo nodo y las solicitudes se pueden distribuir a la carga de trabajo incluso cualquiera de los nodos internos está inactivo.

externalTrafficPolicy (afinidad del Service)

Para un Service de NodePort y de LoadBalancer las solicitudes se envían primero al puerto del nodo, luego al Service y, finalmente, al pod que respalda el Service. El pod de respaldo puede no estar ubicado en el nodo que recibe las solicitudes. De forma predeterminada, se puede acceder a la carga de trabajo de backend desde cualquier dirección IP de nodo y puerto de servicio. Si el pod no está en el nodo que recibe la solicitud, la solicitud se redirigirá al nodo donde se encuentra el pod, lo que puede causar pérdida de rendimiento.

externalTrafficPolicy es un parámetro de configuración del Service.

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
spec:
  externalTrafficPolicy: local
  ports:
  - name: service
    nodePort: 30000
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: NodePort

Si el valor de externalTrafficPolicy es local, las solicitudes enviadas desde Node IP address:Service port se reenviarán solo al pod en el nodo local. Si el nodo no tiene un pod, las solicitudes se suspenden.

Si el valor de externalTrafficPolicy es cluster, las solicitudes se reenvían dentro del clúster y se puede acceder a la carga de trabajo de backend desde cualquier dirección IP de nodo y puerto de servicio.

Si externalTrafficPolicy no está definido, se utiliza el valor predeterminado cluster.

Puede establecer este parámetro al crear un Service del tipo NodePort en la consola de CCE.

Los valores de externalTrafficPolicy son los siguientes:

• cluster: Las direcciones IP y los puertos de acceso de todos los nodos de un clúster pueden 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.
• local: 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.