¿Cuál es la diferencia entre los tipos de servicio ClusterIP, NodePort y LoadBalancer en Kubernetes?

1 - Estoy leyendo la documentación y estoy un poco confundido con la redacción. Dice:

ClusterIP : expone el servicio en una IP interna del clúster. Al elegir este valor, solo se puede acceder al servicio desde el clúster. Este es el tipo de servicio predeterminado

NodePort : expone el servicio en cada IP de Node en un puerto estático (NodePort). Se crea automáticamente un servicio ClusterIP, al que se enrutará el servicio NodePort. Podrá ponerse en contacto con el servicio NodePort, desde fuera del clúster, mediante una solicitud <NodeIP>:<NodePort>.

LoadBalancer : expone el servicio externamente utilizando el equilibrador de carga de un proveedor de la nube. Los servicios NodePort y ClusterIP, a los que se enrutará el equilibrador de carga externo, se crean automáticamente.

¿El tipo de servicio NodePort todavía usa ClusterIPpero solo en un puerto diferente, que está abierto a clientes externos? Entonces, en este caso es <NodeIP>:<NodePort>lo mismo que <ClusterIP>:<NodePort>?

¿O se encuentra NodeIPrealmente la IP cuando se ejecuta kubectl get nodesy no la IP virtual utilizada para el tipo de servicio ClusterIP?

2 - También en el diagrama del siguiente enlace:

http://kubernetes.io/images/docs/services-iptables-overview.svg

¿Hay alguna razón en particular por la cual Clientestá dentro del Node? Supuse que tendría que estar dentro de a Clusteren el caso de un tipo de servicio ClusterIP.

Si se dibujara el mismo diagrama para NodePort, ¿sería válido dibujar el cliente completamente fuera de ambos Nodey Clusterme estoy perdiendo completamente el punto?

Un ClusterIP expone lo siguiente:

• spec.clusterIp:spec.ports[*].port

Solo puede acceder a este servicio mientras está dentro del clúster. Es accesible desde su spec.clusterIppuerto. Si spec.ports[*].targetPortse establece a, se enrutará desde el puerto al puerto de destino. La CLUSTER-IP que obtiene cuando llama kubectl get serviceses la IP asignada a este servicio dentro del clúster internamente.

Un NodePort expone lo siguiente:

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Si accede a este servicio en un nodePort desde la IP externa del nodo, enrutará la solicitud spec.clusterIp:spec.ports[*].port, que a su vez lo enrutará a su spec.ports[*].targetPort, si está configurado. También se puede acceder a este servicio de la misma manera que ClusterIP.

Sus NodeIP son las direcciones IP externas de los nodos. No puede acceder a su servicio desde <ClusterIP>:spec.ports[*].nodePort.

Un LoadBalancer expone lo siguiente:

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Puede acceder a este servicio desde la dirección IP de su equilibrador de carga, que enruta su solicitud a un nodoPort, que a su vez enruta la solicitud al puerto clusterIP. Puede acceder a este servicio como lo haría también con un servicio NodePort o ClusterIP.

Para aclarar a cualquiera que esté buscando cuál es la diferencia entre los 3 en un nivel más simple. Puede exponer su servicio con ClusterIp mínimo (dentro del clúster k8s) o mayor exposición con NodePort (dentro del clúster externo al clúster k8s) o LoadBalancer (mundo externo o lo que haya definido en su LB).

Exposición ClusterIp <Exposición NodePort <Exposición LoadBalancer

• 
  Servicio de exposición ClusterIp a través del clúster k8s conip/name:port
• El
  servicio NodePort Expose a través de VM de red interna también externo a k8sip/name:port
• LoadBalancer
  Exponga el servicio a través del mundo externo o lo que haya definido en su LB.

ClusterIP: los servicios son accesibles por pods / services en el Cluster
Si hago un servicio llamado myservice en el espacio de nombres predeterminado de tipo: ClusterIP, se creará la siguiente dirección DNS estática predecible para el servicio:

myservice.default.svc.cluster.local (o solo myservice.default, o por pods en el espacio de nombres predeterminado, solo "myservice" funcionará)

Y ese nombre DNS solo puede resolverse mediante pods y servicios dentro del clúster.

NodePort: los clientes pueden acceder a los servicios en la misma LAN / clientes que pueden hacer ping a los nodos de host K8s (y pods / servicios en el clúster) (tenga en cuenta la seguridad de que sus nodos de host k8s deben estar en una subred privada, por lo tanto, los clientes en Internet ganaron no puedo llegar a este servicio)
Si hago un servicio llamado mynodeportservice en el espacio de nombres de mi espacio de nombres de tipo: NodePort en un clúster de Kubernetes de 3 nodos. Luego se creará un Servicio de tipo: ClusterIP y será accesible para los clientes dentro del clúster en la siguiente dirección de DNS estática predecible:

mynodeportservice.mynamespace.svc.cluster.local (o simplemente mynodeportservice.mynamespace)

Para cada puerto que mynodeportservice escucha en un puerto de nodo en el rango de 30000 a 32767, se elegirá al azar. Para que los clientes externos que están fuera del clúster puedan acceder al servicio ClusterIP que existe dentro del clúster. Digamos que nuestros 3 nodos host K8 tienen IP 10.10.10.1, 10.10.10.2, 10.10.10.3, el servicio Kubernetes está escuchando en el puerto 80, y el Nodeport seleccionado al azar fue 31852.

Un cliente que existe fuera del clúster podría visitar 10.10.10.1:31852, 10.10.10.2:31852 o 10.10.10.3:31852 (ya que NodePort es escuchado por cada nodo host de Kubernetes) Kubeproxy reenviará la solicitud al puerto 80 de mynodeportservice.

LoadBalancer: todos los usuarios conectados a Internet pueden acceder a los servicios * (la arquitectura común es L4 LB es accesible públicamente en Internet al colocarlo en una DMZ o al proporcionarle una IP privada y pública, y los nodos host k8s están en una subred privada)
( Nota: este es el único tipo de servicio que no funciona en el 100% de las implementaciones de Kubernetes, como Kubernetes, funciona cuando Kubernetes tiene integraciones de proveedores en la nube).

Si realiza mylbservice, se generará una máquina virtual L4 LB (un servicio IP de clúster y un servicio NodePort también se generará implícitamente). Esta vez nuestro NodePort es 30222. La idea es que el L4 LB tendrá una IP pública de 1.2.3.4 y cargará el equilibrio y reenviará el tráfico a los 3 nodos host K8 que tienen direcciones IP privadas. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) y luego Kube Proxy lo reenviará al servicio de tipo ClusterIP que existe dentro del clúster.

También preguntó: ¿El tipo de servicio NodePort todavía utiliza ClusterIP? Sí * ¿
O el NodeIP es realmente la IP encontrada cuando ejecuta kubectl get nodos? También Sí *

Vamos a dibujar un paralelo entre Fundamentos:
un contenedor está dentro de una cápsula. una cápsula está dentro de un conjunto de réplicas. un conjunto de réplicas está dentro de una implementación.
De manera similar:
un servicio ClusterIP es parte de un servicio NodePort. Un servicio NodePort es parte de un servicio de equilibrador de carga.

En ese diagrama que mostró, el Cliente sería un pod dentro del clúster.

Supongamos que creó una VM de Ubuntu en su máquina local. Su dirección IP es 192.168.1.104 .

Inicie sesión en VM e instaló Kubernetes. Luego creaste un pod donde se ejecutaba la imagen nginx en él.

1- Si desea acceder a este pod nginx dentro de su VM, creará un ClusterIP vinculado a ese pod, por ejemplo:

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

Luego, en su navegador, puede escribir la dirección IP de nginxclusterip con el puerto 80, como:

http://10.152.183.2:80

2- Si desea acceder a este pod nginx desde su máquina host, deberá exponer su implementación con NodePort . Por ejemplo:

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

Ahora desde su máquina host puede acceder a nginx como:

http://192.168.1.104:31865/

En mi tablero aparecen como:

A continuación se muestra un diagrama que muestra la relación básica.

Incluso si esta pregunta ya tiene una respuesta, proporcionaré otra, tal vez con algunas fotos más para tener una mejor comprensión.

1. ClusterIP es el tipo de servicio predeterminado en Kubernetes y este tipo le brinda un servicio dentro del clúster. Al usar esto, otras aplicaciones del clúster pueden acceder al servicio a través del proxy Kubernetes.

Debo mencionar que este tipo de servicio no debe usarse para exponer servicios de producción. Sin embargo, se puede usar para

• integración de depuración entre servicios;
• acceder a servicios internos que exponen datos no relacionados con el negocio (paneles de monitoreo).

La forma en que va la solicitud es la siguiente: tráfico -> proxy K8s -> servicio K8s (ClusterIP) -> pods y se muestra en la siguiente imagen.

2. NodePort es la forma más primitiva de aceptar tráfico externo y reenviarlo a los servicios de kubernetes. Como su nombre lo indica, el tipo de servicio NodePort abre un puerto específico en todas las máquinas virtuales, que de hecho son los nodos de Kubernetes, para permitir que el tráfico que se envía a ese puerto específico se reenvíe al servicio.

El tipo de servicio NodePort tiene algunas desventajas:

• es necesario tener solo un servicio por puerto;
• si se cambiará la ip de la máquina virtual, algunos cambios deben hacerse en el clúster;
• solo se puede usar el puerto entre 3000-32767.

La forma en que se realiza la solicitud es la siguiente: tráfico -> puerto expuesto en la máquina virtual -> servicio K8s (NodePort) -> pods y se muestra en la siguiente imagen:

3. LoadBalancer es la forma estándar de exponer un servicio a Internet. Si su deseo es exponer directamente un servicio y todo el tráfico en un puerto específico para ser reenviado al servicio, entonces esta es la manera de hacerlo. Además, el tipo de servicio LoadBalancer no implica ningún filtrado o enrutamiento. Además, puede enviarle tráfico TCP, UDP, HTTP gRPC.

Desventaja: cada servicio expuesto a través de un LoadBalancer tendrá su propia dirección IP y cada servicio estará expuesto a través de un solo LoadBalancer que puede ser costoso.

La solicitud tiene la siguiente ruta: tráfico -> LoadBalancer -> Servicio K8s -> pods y se muestra en la siguiente imagen.

1. clusterIP: IP accesible dentro del cluster (a través de nodos dentro del d cluster).

nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3 puede hablar con pod1 a través de su red clusterIP.

2. nodeport: para hacer que los pods sean accesibles desde fuera del clúster a través de nodeIP: nodeport, creará / mantendrá clusterIP arriba como su red clusterIP.

nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

puede acceder al servicio en el pod1 a través de nodeIPA: nodeportX O nodeIPB: nodeportX. De cualquier manera funcionará porque kube-proxy (que está instalado en cada nodo) recibirá su solicitud y la distribuirá [redirigirla (término de iptables)] entre los nodos que utilizan la red clusterIP.

3. Balanceador de carga

básicamente, colocando LB al frente, para que el tráfico entrante se distribuya a nodeIPA: nodeportX y nodeIPB: nodeportX y luego continúe con el flujo de proceso número 2 anterior.