【k8s】K8S中的IP地址(Node IP、Pod IP、Cluster IP、External IP、Internal-IP)

关联文章：
《k8s 核心概念 2 service》service 概述
第五章 服务service 一 ( dns、ENDPOINTS) service 作用
第五章 服务service 二

【k8s】Service种类、类型(ClusterIP、NodePort、LoadBalancer、ExternalName) service的几种类型
K8S中的IP地址(Node IP、Pod IP、Cluster IP、External IP) 和service有关联的一些ip概念

1. 概述

通过《k8s 核心概念 2 service》我们知道service 的作用是提供另一种方式去访问pod，与直接访问pod相比，此时，service 可以避免pod发生变化后ip变化的问题。

此外，service存在不同的类型，例如Cluster IP类型仅能在集群内部访问，而External IP类型可以在服务外访问。不同的类型，会产生不同的ip字段，在不同场景下会有不同的字段出现。

kubernetes里有三张不同的网络，每种IP地址，就代表一个不同的寻址空间：

• Node IP：Node节点的IP地址
• Pod IP：Pod的IP地址
• Cluster IP：内部或集群内访问Service的IP地址
• External IP是 为了解决如何从外部访问 service 服务的问题。

Node IP包含内部IP和外部IP2个概念，内部IP让集群节点互相访问，外部IP提供了外部访问功能。

Pod IP提供访问pod功能，但仅限于集群内访问，不能从外部访问。但是存在缺点，pod如果挂掉再重启，IP会变。

Cluster IP是service Cluster IP，是服务中的一种，该类型的服务仅能从内部访问，间接访问pod。该服务提供了通过标签管理一组pod，即使Pod IP变化，重启后，他的标签不会变，仍受其管理，因此，解决了之前提到的Pod IP会变的问题。并且由于这一组pod通常是完成相同功能的，例如都是通过8080端口提供天气查询服务，因此servie可以采用随机或其他负载均衡策略，转发至相应的pod。

External IP是 为了解决如何从外部访问 service 服务的问题。

1.1 service种类

【k8s】Service种类、类型(ClusterIP、NodePort、LoadBalancer、ExternalName) service的几种类型

2. Node IP

Node IP分内部和外部，内部IP仅限集群内访问，外部IP可以从外部访问。

首先，Node IP是kubernetes集群中每个节点的物理网卡的IP地址（包括虚拟机的网卡），这是一个真实存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络进行通信，不管他们中是否有部分节点不属于这个kebernetes集群。这也表明了Kubenetes集群之外的节点访问Kubernetes之内的某个节点或者TCP/IP服务时，必须要通过Node IP进行通信。

内部的node IP是指k8s 管理集群内的节点，自然需要给每个节点分配IP。此时是最最原始的状态。这个ip有什么用？很有用，例如像查看某个pod运行在哪个节点上，例如图3；有时候需要指定pod安装至指定的node上，此时，就需要指定node IP。

外部的Node IP通常是指每个节点在局域网内或公开的IP，可以让不在集群内的主机或客户端可以访问的IP。


可以把外部Node IP理解成护照，国际通用，而内部Node IP理解成身份证，仅限国内使用

nodeIP一般不会单独使用，例如你要访问Node1的pod1，因为Node1还存在Pod2等很多其他Pod，无法仅通过ip，还得借助其他参数，例如一个端口来映射某个pod，例如在NodePort类型的Service，每个Service都会在Node节点上开通一个端口，外部可以通过NodeIP:NodePort即可访问Service里的Pod,和我们访问服务器部署的项目一样，IP:端口/项目名

在kubernetes查询内部Node IP：
1.kubectl get nodes
2.kubectl describe node nodeName

显示出来的Internal-IP字段就是NodeIP

或者直接查询 kubectl get nodes -o wide：

3. Pod IP

其次，Pod IP是每个Pod的IP地址，它是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络，前面我们说过，Kubernetes要求位于不同Node上的Pod能够彼此直接通信，所以Kuberntes里一个Pod里的容器访问另外一个Pod里的容器，就是通过Pod IP所在的虚拟二层网络进行通信的，而真实的TCP/IP流量则是通过Node IP所在的物理网卡流出的。

在kubernetes查询Pod IP：
1.kubectl get pods
2.kubectl describe pod podName

该方法的截图省略。

或者直接查询 kubectl get pod -o wide：

其中IP字段指pod的IP，node字段指运行在哪个节点上，也就是Node IP(这里对应node IP的内部IP概念，对应前面提到的Internal-IP字段)

4. Service Cluster IP

Service是Kubernetes最核心的概念，通过创建Service，可以为一组具有相同功能的容器用用提供一个统一的入口地址，并且将请求进行负载分发到后端的各个容器应用上。

最后，我们说说Service的Cluster IP，翻译过来是集群IP，它也是一个虚拟的IP，但更像一个“伪造”的IP网络，原因有一下几点：

• Cluster IP仅仅作用于kubernetes Service这个对象，并由Kubernetes管理和分配IP地址（来源于Cluster IP地址池）
• Cluster IP无法被ping **注意，很重要**，因为没有一个“实体网络对象”来响应
• Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备TCP/IP通信的基础，并且它们属于Kubernetes集群这样一个封闭的空间，集群之外的节点如果要访问这个通信端口，则需要做一些额外的工作。
• 在Kubernetes集群之内，Node IP网，Pod IP网与Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程方式的特殊的路由规则，与我们所熟知的IP路由有很大的不同。

根据上面的分析和总结，我们基本明白了：Service的Cluster IP属于Kubernetes集群内部的地址，无法在集群外部直接使用这个地址。那么矛盾来了：实际上我们开发的业务系统中肯定多少有一部分要提供给Kubernetes集群外部的应用或者用户来使用的，NodePort是解决上述问题最直接、最有效、最常用的做法，这个主题以后再说。

4.1 Cluster IP原理

Cluster IP是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的。这个地址从我们启动API的service-cluster-ip-range参数(旧版本为portal_net参数)指定的地址池中分配，比如–service-cluster-ip-range=10.0.0.0/16。假设这个Service的端口是1234。集群内的所有kube-proxy都会注意到这个Service。当proxy发现一个新的service后，它会在本地节点打开一个任意端口，建相应的iptables规则，重定向服务的IP和port到这个新建的端口，开始接受到达这个服务的连接。

当一个客户端访问这个service时，这些iptable规则就开始起作用，客户端的流量被重定向到kube-proxy为这个service打开的端口上，kube-proxy随机选择一个后端pod来服务客户。这个流程如下图所示：

5. External IP

External IP是 为了解决如何从外部访问 service 服务的问题。

外部访问Service的方式有两种：

1）通过设置nodePort映射到物理机，同时设置Service的类型为NodePort。

2）通过设置LoadBalancer映射到云服务上提供的LoadBalancer地址。这种用法仅用于公有云服务提供商的云平台设置Service的场景。对该Service的请求将会通过LoadBalancer转发到后端Pod上，负载分发的实现方式则依赖于云服务商提供的LoadBalancer的实现机制。

以NodePort类型的服务:为例：

看看EXTERNAL -IP列。它显示nodes, 表明服务可通过任何集群节点的IP地址访问。PORT (S)列显示集群IP (8 0) 的内部端口和节点端口(30123), 可以通过以下地址访问该服务：
• 10.11.254.223:80
• <节点1 node’sIP>:30123
• <节点2 node’sIP>:30123, 等等

loadbalancer类型的服务：

负载均衡器的对外 IP地址为130.211.53.173, 因此现在可以通过该IP 地址访问该服务：

参考

K8S中的IP地址
k8s之PodIP、ClusterIP和ExternalIP