[*]Esta es el arreglo más exacta que te podemos compartir, pero primero obsérvala detenidamente y valora si es compatible a tu trabajo.
Solución:
[*]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.clusterIp Puerto. Si un spec.ports[*].targetPort está configurado, se enrutará desde el puerto al targetPort. El CLUSTER-IP que obtienes al llamar kubectl get services es la IP asignada a este servicio dentro del clúster internamente.
[*]Un NodePort expone lo siguiente:
: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 a 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 forma que ClusterIP.
[*]Sus NodeIPs son las direcciones IP externas de los nodos. No puede acceder a su servicio desde spec.clusterIp:spec.ports[*].nodePort.
[*]Un LoadBalancer expone lo siguiente:
spec.loadBalancerIp:spec.ports[*].port:spec.ports[*].nodePort spec.clusterIp:spec.ports[*].port
[*]Puede acceder a este servicio desde la dirección IP de su balanceador de carga, que enruta su solicitud a un nodePort, 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.
[*]Aclarar para quien esté buscando cuál es la diferencia entre los 3 en un nivel más simple. Puede exponer su servicio con un ClusterIp mínimo (dentro del clúster k8s) o una exposición mayor 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
- ClusterIp
Exponer el servicio a través clúster k8s con
ip/name:port - NodePort
Exponer el servicio a través VM de la red interna también externo a k8s
ip/name:port - LoadBalancer
Exponer el servicio a través Mundo externo o lo que hayas definido en tu LB.
[*]ClusterIP: los servicios son accesibles por pods / servicios en el Cluster
Si hago un servicio llamado myservice en el espacio de nombres predeterminado de tipo: ClusterIP, entonces lo siguiente predecible static Se creará la dirección DNS para el servicio:
[*]myservice.default.svc.cluster.local (o simplemente myservice.default, o por pods en el espacio de nombres predeterminado, simplemente funcionará “myservice”)
[*]Y ese nombre de 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 host de K8s (y pods / servicios en el clúster) (tenga en cuenta por seguridad que sus nodos host k8s deben estar en una subred privada, por lo que los clientes en Internet ganaron no poder acceder a este servicio)
Si realizo un servicio llamado mynodeportservice en el espacio de nombres mynamespace de tipo: NodePort en un clúster de Kubernetes de 3 nodos. Luego, se creará un servicio de tipo: ClusterIP y los clientes dentro del clúster podrán acceder a él en el siguiente punto predecible static Dirección DNS:
[*]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-32767 se elegirá al azar. Para que los clientes externos que están fuera del clúster puedan acceder a ese servicio ClusterIP que existe dentro del clúster. Digamos que nuestros 3 nodos de host K8 tienen IPs 10.10.10.1, 10.10.10.2, 10.10.10.3, el servicio de Kubernetes está escuchando en el puerto 80 y el Nodeport elegido 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 todos los nodos de host de Kubernetes escuchan NodePort) Kubeproxy reenviará la solicitud al puerto 80 de mynodeportservice.
[*]LoadBalancer: los servicios son accesibles para todos los que estén conectados a Internet * (la arquitectura común es L4 LB es de acceso público en Internet colocándolo en una DMZ o dándole una IP pública y privada y los nodos de 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 sin sistema operativo, funciona cuando Kubernetes tiene integraciones de proveedores en la nube).
Si realiza mylbservice, se generará una máquina virtual L4 LB (también se generará implícitamente un servicio IP de clúster y un servicio NodePort). Esta vez nuestro NodePort es 30222. La idea es que el L4 LB tenga una IP pública de 1.2.3.4 y equilibrará la carga y reenviará el tráfico a los 3 nodos host de 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 usa ClusterIP? Sí*
¿O es el NodeIP en realidad la IP que se encuentra cuando ejecuta kubectl get nodos? También si *
Dibujemos un paralelo entre Fundamentos:
Un contenedor está dentro de una vaina. una vaina está dentro de un conjunto de réplicas. un conjunto de réplicas está dentro de una implementación.
Bueno, 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.
Te mostramos reseñas y valoraciones
[*]