问题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绘制相同的图,那么将客户端完全画在节点和集群之外是否有效?还是我完全错过了重点?


当前回答

不要忘记“new”服务类型(来自k8s文档):

ExternalName:通过返回带有值的CNAME记录,将服务映射到ExternalName字段的内容(例如,foo.bar.example.com)。没有设置任何类型的代理。

注意:使用ExternalName类型需要kube-dns版本1.7或CoreDNS版本0.0.8或更高版本。

其他回答

假设你在本地机器上创建了一个Ubuntu虚拟机。IP地址是192.168.1.104。

登录VM,安装Kubernetes。然后你创建了一个运行nginx图像的pod。

1-如果你想在你的虚拟机中访问这个nginx pod,你将创建一个绑定到该pod的ClusterIP,例如:

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

然后在浏览器上输入nginxclusterip的ip地址,端口为80,如下所示:

http://10.152.183.2:80

2-如果你想从你的主机上访问这个nginx pod,你需要用NodePort公开你的部署。例如:

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

现在你可以从你的主机上访问nginx,像这样:

http://192.168.1.104:31865/

在我的仪表板上,它们显示为:

下图显示了基本关系。

为了在更简单的层面上为那些正在寻找这三者之间的区别的人澄清。您可以使用最小的ClusterIp(在k8s集群内)公开您的服务,也可以使用NodePort(在k8s集群外部的集群内)或LoadBalancer(外部世界或您在LB中定义的任何东西)公开您的服务。

ClusterIp暴露< NodePort暴露< LoadBalancer暴露

ClusterIp 通过ip/name:port的k8s集群公开服务 NodePort 通过内部网络虚拟机的外部k8s ip/name:port公开服务 loadbalance 通过外部世界或您在LB中定义的任何方式公开服务。

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服务一样访问这个服务。

实际的理解。

我已经为NodePort和ClusterIP创建了2个服务

如果我想访问集群内的服务(从主节点或任何工作节点),那么两者都是可访问的。

现在,如果我想从集群外部访问服务,那么只能访问Nodeport,不能访问ClusterIP。

在这里你可以看到localhost不会监听端口80,即使我的nginx容器监听端口80。


是的,这是唯一的区别。

ClusterIP。公开只能从集群内部访问的服务。 NodePort。通过每个节点IP上的静态端口公开服务。 loadbalance。通过云提供商的负载平衡器公开服务。 ExternalName。通过返回CNAME记录的值,将服务映射到预定义的externalName字段。


实际使用案例

假设您必须在集群中创建以下架构。我想这很常见。

现在,用户只会在某个端口上与前端通信。后端和DB服务始终对外部世界隐藏。

Feature ClusterIP NodePort LoadBalancer
Exposition Exposes the Service on an internal IP in the cluster. Exposing services to external clients Exposing services to external clients
Cluster This type makes the Service only reachable from within the cluster A NodePort service, each cluster node opens a port on the node itself (hence the name) and redirects traffic received on that port to the underlying service. A LoadBalancer service accessible through a dedicated load balancer, provisioned from the cloud infrastructure Kubernetes is running on
Accessibility It is default service and Internal clients send requests to a stable internal IP address. The service is accessible at the internal cluster IP-port, and also through a dedicated port on all nodes. Clients connect to the service through the load balancer’s IP.
Yaml Config type: ClusterIP type: NodePort type: LoadBalancer
Port Range Any public ip form Cluster 30000 - 32767 Any public ip form Cluster
User Cases For internal communication Best for testing public or private access or providing access for a small amount of time. widely used For External communication

来源:

Kubernetes在行动 Kubernetes。io服务 Kubernetes Services简单直观地解释了