ingress - ¿Cuál es la diferencia entre los tipos de servicio ClusterIP, NodePort y LoadBalancer en Kubernetes?
kubernetes service load balancer (5)
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, solicitando
<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
ClusterIP
pero solo en un puerto diferente, que está abierto a clientes externos?
Entonces, en este caso, ¿es
<NodeIP>:<NodePort>
lo mismo que
<ClusterIP>:<NodePort>
?
¿O es el
NodeIP
realmente la IP encontrada cuando ejecuta
kubectl get nodes
y 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 particular por la cual el
Client
está dentro del
Node
?
Supuse que tendría que estar dentro de un
Cluster
en 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 del
Node
y del
Cluster
o me estoy perdiendo completamente el punto?
- 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.
- 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 forma 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.
- 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.
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 de k8s clusteR) 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).
ClusterIp exposure < NodePort exposure < LoadBalancer exposure
ClusterIp -> Expose service through **k8s cluster** with ip/name:port
NodePort -> Expose service through **Internal network VM''s** also external to k8s ip/name:port
LoadBalancer -> Expose service through **External world** or whatever you defined in your LB.
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 una 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:
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:
En mi tablero aparecen como:
A continuación se muestra un diagrama que muestra la relación básica.
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 puerto
spec.clusterIp
.
Si se establece un
spec.ports[*].targetPort
se
spec.ports[*].targetPort
desde el puerto al targetPort.
La IP del CLUSTER que obtiene cuando llama
kubectl get services
es la IP asignada a este servicio dentro del cluster 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,
spec.clusterIp:spec.ports[*].port
la solicitud a
spec.clusterIp:spec.ports[*].port
, que a su vez lo
spec.ports[*].targetPort
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 con un servicio NodePort o ClusterIP también.
ClusterIP: los pods / servicios pueden acceder a los servicios en el Cluster
Si realizo 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 pueda llegar a este servicio)
Si realizo un servicio llamado mynodeportservice en el espacio de nombres de tipo mynamespace de tipo: NodePort en un clúster de Kubernetes de 3 nodos.
Luego se creará un Servicio de tipo: ClusterIP y los clientes podrán acceder a él 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 puede 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 de 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 de host k8 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 es el NodeIP realmente la IP encontrada cuando ejecuta kubectl get nodos?
También sí *
Vamos a dibujar un paralelismo entre Fundamentos:
Un contenedor está dentro de una vaina.
una cápsula está dentro de un conjunto de réplicas.
un conjunto de réplicas está dentro de una implementación.
Bien 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.