问题1:我正在阅读文档，我对其中的措辞有点困惑。它说:
ClusterIP: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. This is the default ServiceType
NodePort: Exposes the service on each Node’s IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
LoadBalancer: Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.
NodePort服务类型是否仍然使用ClusterIP，但只是在一个不同的端口上，该端口对外部客户端开放?所以在这种情况下，<NodeIP>:<NodePort>与<ClusterIP>:<NodePort>?
或者NodeIP实际上是运行kubectl get节点时找到的IP，而不是用于ClusterIP服务类型的虚拟IP ?
问题2 -图表中也有下面的链接:
客户端在节点内部有什么特别的原因吗?我假设它需要在ClusterIP服务类型的情况下，ClusterIP服务类型?
如果为NodePort绘制相同的图，那么将客户端完全画在节点和集群之外是否有效?还是我完全错过了重点?
实际的理解。
我已经为NodePort和ClusterIP创建了2个服务
如果我想访问集群内的服务(从主节点或任何工作节点)，那么两者都是可访问的。
现在，如果我想从集群外部访问服务，那么只能访问Nodeport，不能访问ClusterIP。
在这里你可以看到localhost不会监听端口80，即使我的nginx容器监听端口80。
是的，这是唯一的区别。
ClusterIP。公开只能从集群内部访问的服务。
NodePort。通过每个节点IP上的静态端口公开服务。
loadbalance。通过云提供商的负载平衡器公开服务。
ExternalName。通过返回CNAME记录的值，将服务映射到预定义的externalName字段。
实际使用案例
假设您必须在集群中创建以下架构。我想这很常见。
现在，用户只会在某个端口上与前端通信。后端和DB服务始终对外部世界隐藏。
实际的理解。
我已经为NodePort和ClusterIP创建了2个服务
如果我想访问集群内的服务(从主节点或任何工作节点)，那么两者都是可访问的。
现在，如果我想从集群外部访问服务，那么只能访问Nodeport，不能访问ClusterIP。
在这里你可以看到localhost不会监听端口80，即使我的nginx容器监听端口80。
是的，这是唯一的区别。
ClusterIP。公开只能从集群内部访问的服务。
NodePort。通过每个节点IP上的静态端口公开服务。
loadbalance。通过云提供商的负载平衡器公开服务。
ExternalName。通过返回CNAME记录的值，将服务映射到预定义的externalName字段。
实际使用案例
假设您必须在集群中创建以下架构。我想这很常见。
现在，用户只会在某个端口上与前端通信。后端和DB服务始终对外部世界隐藏。
clusterIP:集群内可访问的IP(跨d集群内的节点)。
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.
pod3可以通过它们的clusterIP网络与pod1通信。
nodeport:为了让pod从集群外部通过nodeIP:nodeport访问，它将在上面创建/保留clusterIP作为它的clusterIP网络。
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX
您可以通过nodeIPA:nodeportX或nodeIPB:nodeportX访问pod1上的服务。任何一种方式都可以工作，因为kube-proxy(安装在每个节点上)将接收您的请求，并使用clusterIP网络在节点之间分发它[重定向它(iptables术语)]。
负载均衡器
基本上就是把LB放在前面，这样入站流量就被分配到nodeIPA:nodeportX和nodeIPB:nodeportX，然后继续执行上面的流程流2。
ClusterIP公开了以下内容:
spec.clusterIp: spec.ports [*] .port
您只能在集群内访问此服务。可以从它的spec.clusterIp端口访问它。如果使用spec.ports[*]. xml文件。targetPort被设置，它将从端口路由到targetPort。调用kubectl get services时得到的cluster -IP是在集群内部分配给该服务的IP。
NodePort公开了以下内容:
< NodeIP >: spec.ports [*] .nodePort
spec.clusterIp: spec.ports [*] .port
如果您从节点的外部IP访问nodePort上的这个服务，它将把请求路由到spec.clusterIp:spec.ports[*]。端口，这将反过来路由到您的spec.ports[*]。如果设置了targetPort。该服务的访问方式与ClusterIP相同。
nodeip是节点的外部IP地址。您无法从spec.clusterIp:spec.ports[*]. nodeport访问您的服务。
LoadBalancer公开以下内容:
spec.loadBalancerIp: spec.ports [*] .port
< NodeIP >: spec.ports [*] .nodePort
spec.clusterIp: spec.ports [*] .port
您可以从负载均衡器的IP地址访问此服务，该IP地址将请求路由到nodePort, nodePort又将请求路由到clusterIP端口。您可以像访问NodePort或ClusterIP服务一样访问这个服务。
