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.
externalIPscambia la ecuación aquí? Específicamente, ¿es posible asignar unaexternalIPsmatriz a unClusterIPservicio de tipo, y luego el servicio también se vuelve accesible en la IP externa? ¿Cuándo elegirías esto sobre un NodePort?