☰

Los servicios de Kubernetes agotan el tiempo de acceso a pods de diferentes trabajadores

tag-icon • tag-icon amazon-web-services kubernetes kubeadm
Los servicios de Kubernetes agotan el tiempo de acceso a pods de diferentes trabajadores

Estoy tratando de poner en pie a un par de trabajadores de Kubernetes en instancias EC2 y me encuentro con un problema en el que el servicio no parece "ver" todos los pods que debería poder ver.

Mi entorno exacto es un par de AWS Snowballs, rojo y azul, y mi clúster se parece a control, worker-redy worker-blue[1]. Estoy implementando un servidor Python ficticio que espera un GET en el puerto 8080 y responde con el nombre de host local. Lo configuré con suficientes réplicas para que ambas worker-redtengan worker-blueal menos una cápsula cada una. Finalmente, creé un servicio, cuyas especificaciones se ven así

spec:
    type: NodePort
    selector:
        app: hello-server
    ports:
        - port: 8080
          targetPort: 8080
          nodePort: 30080

Ahora puedo comprobar que mis pods están activos.

kubectl get pods -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP              NODE          NOMINATED NODE   READINESS GATES
hello-world-deployment-587468bdb7-hf4dq   1/1     Running   0          27m   192.168.1.116   worker.red    <none>           <none>
hello-world-deployment-587468bdb7-mclhm   1/1     Running   0          27m   192.168.1.126   worker.blue   <none>           <none>

Ahora puedo intentar rizarlos.

curl worker-red:30080
greetings from hello-world-deployment-587468bdb7-hf4dq

curl worker-blue:30080
greetings from hello-world-deployment-587468bdb7-mclhm

Eso es lo que sucede aproximadamente la mitad de las veces. La otra mitad de las veces, el rizo falla con un error de tiempo de espera. Específicamente, rizar el rojo trabajador SÓLO producirá una respuesta de hf4dq, y rizar el azul trabajador SÓLO producirá una respuesta de mclhm. Si acordono y drenando el azul trabajador para que mis dos pods funcionen en rojo, nunca habrá un tiempo de espera y ambos pods responderán.

Parece que el servicio NodePort no llega a los pods que no están en el host que estoy rizando. Según tengo entendido, no es así como se supone que funcionan los servicios. ¿Qué me estoy perdiendo?

[1] Si configuro de modo que tenga dos trabajadores en Red, ocurre el mismo problema que estoy describiendo, pero este es mi caso de uso principal, por lo que me concentraré en él.

Respuesta1

Es difícil decir simplemente qué podría estar mal aquí, pero hay algunos pasos que puedes seguir para solucionar tu problema:

  1. Pods de depuración, especialmente verifique si hay algo sospechoso en los registros:

  • kubectl logs ${POD_NAME} ${CONTAINER_NAME}

  • kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

  1. Servicios de depuración, por ejemplo marcando:

  • ¿Existe el Servicio?

  • ¿El Servicio funciona por nombre DNS?

  • ¿El Servicio funciona por IP?

  • ¿Está el Servicio definido correctamente?

  • ¿El Servicio tiene algún punto final?

  • ¿Está funcionando el proxy kube?

Seguir esos pasos le ayudará a encontrar la causa de su problema y también a comprender mejor los mecanismos detrás de los servicios.

Respuesta2

Está utilizando NodePortun servicio de tipo, en cuyo caso lo que está observando es muy esperado.

Su servicio hace coincidir 2 pods que se ejecutan en dos nodos diferentes. Dado que el servicio es de tipo NodePort, existe una asociación inherente entre un pod de su servicio y el nodo en el que se ejecuta. Si curva el worker-redpunto final, obtendráSOLOobtener la respuesta del worker-redpod, esto se debe a que el otro pod está vinculado a otro punto final worker-blue:<node-port>y no se puede acceder a él desde el worker-redpunto final. Sí, es el mismo servicio, pero está respaldado por 2 puntos finales, cada uno con diferentes nombres de host.

Básicamente así es como NodePortfuncionan los servicios.

Cuando los agrupa a ambos en el mismo nodo, se puede acceder a ambos pods desde el mismo nombre de host del nodo, por lo que rizar ambos funcionará. Desde ahora, ambos puntos finales se asignan a puertos diferentes, pero elmismo nombre de host.

Como una forma de mejorar su comprensión de esto. Puede intentar cambiar su tipo de servicio a LoadBalancer. Y notará que podrá acceder a ambos pods utilizando el mismo nombre de host, independientemente de dónde se programen. Y este nombre de host/dirección IP será la dirección que LoadBalancertodos los pods del servicio tendrán en común.

¡Espero que esto aclare tu confusión!

información relacionada