1 - 我正在阅读文档,并且我对措辞略有不满。它说:
ClusterIP :在群集内部IP上公开服务。选择此值使服务只能从群集中访问。这是默认的ServiceType
NodePort :在静态端口(NodePort)上的每个节点的IP上公开服务。将自动创建NodePort服务将路由到的ClusterIP服务。您可以通过请求
<NodeIP>:<NodePort>
从群集外部联系NodePort服务。LoadBalancer :使用云提供商的负载均衡器在外部公开服务。将自动创建外部负载均衡器将路由到的NodePort和ClusterIP服务。
NodePort服务类型是否仍使用ClusterIP
,但只是在不同的端口,该端口对外部客户端开放?因此,在这种情况下<NodeIP>:<NodePort>
与<ClusterIP>:<NodePort>
相同?
或者NodeIP
实际上是在运行kubectl get nodes
时找到的IP而不是用于ClusterIP服务类型的虚拟IP?
2 - 同样在以下链接的图表中:
http://kubernetes.io/images/docs/services-iptables-overview.svg
Client
内有Node
有什么特别的原因吗?我认为在ClusterIP服务类型的情况下它需要在Cluster
内。
如果为NodePort绘制了相同的图表,那么在Node
和Cluster
之外完全绘制客户端是否有效,或者我完全忽略了这一点?
答案 0 :(得分:117)
ClusterIP公开以下内容:
spec.clusterIp:spec.ports[*].port
您只能在群集内访问此服务。它可以从spec.clusterIp
端口访问。如果设置了spec.ports[*].targetPort
,它将从端口路由到targetPort。调用kubectl get services
时获得的CLUSTER-IP是内部在集群内分配给此服务的IP。
NodePort公开以下内容:
<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].port
如果您从节点的外部IP在nodePort上访问此服务,它会将请求路由到spec.clusterIp:spec.ports[*].port
,spec.ports[*].targetPort
会将请求路由到<ClusterIP>:spec.ports[*].nodePort
(如果已设置)。也可以使用与ClusterIP相同的方式访问此服务。
您的NodeIP是节点的外部IP地址。您无法从spec.loadBalancerIp:spec.ports[*].port
访问您的服务。
LoadBalancer公开以下内容:
<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].port
slugurl
您可以从负载均衡器的IP地址访问此服务,该IP地址将您的请求路由到nodePort,nodePort又将请求路由到clusterIP端口。您可以像访问NodePort或ClusterIP服务一样访问此服务。
答案 1 :(得分:55)
澄清任何正在寻找更简单级别3之间差异的人。您可以使用最小的ClusterIp(在k8s clusteR内)或使用NodePort(在k8s群集外部的群集内)或LoadBalancer(外部世界或您在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.
答案 2 :(得分:18)
ClusterIP:群集中的pod /服务可访问服务
如果我在默认名称空间类型“ ClusterIP”中创建名为myservice的服务,则将为该服务创建以下可预测的静态DNS地址:
myservice.default.svc.cluster.local(或仅是myservice.default,或者通过默认名称空间中的Pod可以使用“ myservice”)
该DNS名称只能由群集中的pod和服务来解析。
NodePort:同一LAN上的客户端可以访问服务,而这些客户端可以ping K8s主机节点(以及集群中的Pod /服务)(为安全起见,k8s主机节点应位于专用子网中,因此互联网上的客户将无法使用此服务)
如果我在mynamespace名称空间中创建了一个名为mynodeportservice的服务,其类型为:3节点Kubernetes群集上的NodePort。然后将创建一个类型为Service的服务:ClusterIP,群集内的客户端可以通过以下可预测的静态DNS地址访问该服务:
mynodeportservice.mynamespace.svc.cluster.local(或仅是mynodeportservice.mynamespace)
对于mynodeportservice在节点端口上侦听的每个端口,其范围为30000-32767。这样,群集外部的外部客户端可以访问群集内部存在的该ClusterIP服务。
假设我们的3个K8s主机节点具有IP 10.10.10.1、10.10.10.2、10.10.10.3,Kubernetes服务正在侦听端口80,随机选择的Nodeport是31852。
集群外部的客户端可以访问10.10.10.1:31852、10.10.10.2:31852或10.10.10.3:31852(因为每个Kubernetes主机节点都在监听NodePort),Kubeproxy将将请求转发到mynodeportservice的端口80。
LoadBalancer:连接到Internet的每个人都可以访问服务*(通用架构为L4 LB,可以通过将其放置在DMZ中或为其提供私有IP和公共IP来公开访问Internet,并且k8s主机节点是在专用子网中)
(注意:这是唯一不能在100%的Kubernetes实现中使用的服务类型,例如裸机Kubernetes,它在Kubernetes具有云提供程序集成时才起作用。)
如果使用mylbservice,则将生成L4 LB VM(群集IP服务和NodePort服务也将被隐式生成)。这次,我们的NodePort为30222。我们的想法是L4 LB将具有1.2.3.4的公共IP,它将负载均衡并将流量转发到具有私有IP地址的3个K8s主机节点。 (10.10.10.1:30222、10.10.10.2:30222、10.10.10.3:30222),然后Kube Proxy会将其转发到群集中存在的ClusterIP类型的服务。
您还问:
NodePort服务类型是否仍使用ClusterIP?是*
还是运行kubectl get节点时找到的NodeIP实际上是IP?还可以*
让我们在基本原理之间画一个平行线:
容器位于豆荚内。吊舱位于副本集中。副本集位于部署内部。
好吧,
ClusterIP服务是NodePort服务的一部分。 NodePort服务是负载均衡器服务的一部分。
在您显示的该图中,客户端将是群集内的一个pod。
答案 3 :(得分:11)
让我们假设您在本地计算机上创建了Ubuntu VM。 IP地址为 192.168.1.104 。
您登录到VM,并安装了Kubernetes。然后,您在其中运行了nginx图像的地方创建了一个Pod。
1-如果要访问VM中的此nginx容器,则将创建绑定到该容器的 ClusterIP ,例如:
$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080
然后,在浏览器中,您可以使用端口80输入nginxclusterip的IP地址,例如:
2-如果要从主机访问此nginx pod,则需要使用 NodePort 公开部署。例如:
$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort
现在,您可以从主机上访问nginx了,
在我的信息中心中,它们显示为:
下面是显示基本关系的图。
答案 4 :(得分:2)
我为 NodePort 创建了 2 个服务,1 个为 ClusterIP
如果我想访问集群内的服务(从主节点或任何工作节点),那么两者都可以访问。
现在,如果我想从集群外部访问服务,那么 Nodeport 只能访问而不能访问 ClusterIP。
在这里你可以看到 localhost 不会监听端口 80,即使我的 nginx 容器正在监听端口 80。
是的,这是唯一的区别。
假设您必须在集群中创建以下架构。我想它很常见。
现在,用户只会在某个端口上与前端通信。后端和数据库服务始终对外部世界隐藏。
答案 5 :(得分:1)
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.
pod3可以通过其clusterIP网络与pod1对话。
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX
您可以通过nodeIPA:nodeportX或nodeIPB:nodeportX访问pod1上的服务。两种方法都行得通,因为kube-proxy(安装在每个节点中)将接收您的请求,并使用clusterIP网络在节点之间分发[重定向(iptables术语)]。
基本上只是将LB放在前面,以便将入站流量分配到nodeIPA:nodeportX和nodeIPB:nodeportX,然后继续上面的流程2。
答案 6 :(得分:1)
Feature |
ClusterIP |
NodePort |
LoadBalancer |
---|---|---|---|
展示 | 在集群的内部 IP 上公开服务。 | 向外部客户端公开服务 | 向外部客户端公开服务 |
簇 | 这种类型使得服务只能从集群内部访问 | NodePort 服务,每个集群节点在节点本身上打开一个端口(因此得名),并将在该端口上接收到的流量重定向到底层服务。 | 可通过专用负载均衡器访问的 LoadBalancer 服务,由运行 Kubernetes 的云基础架构提供 |
辅助功能 | 这是默认服务,内部客户端将请求发送到稳定的内部 IP 地址。 | 该服务不仅可以通过内部集群IP和端口访问,还可以通过所有节点上的专用端口访问。 | 客户端通过负载均衡器的 IP 连接到服务。 |
Yaml 配置 | type: ClusterIP |
type: NodePort |
type: LoadBalancer |
IP 范围 | 任意公网ip形式Cluster | 30000 - 32767 | 任意公网ip形式的Cluster |
答案 7 :(得分:0)
请不要忘记“新”服务类型(from the k8s docu):
ExternalName :通过返回带有其值的CNAME记录,将服务映射到externalName字段的内容(例如foo.bar.example.com)。没有设置任何代理。
注意:您需要使用kube-dns版本1.7或CoreDNS版本0.0.8或更高版本才能使用ExternalName类型。