### node 节点 node: node 上有两个 IP, 一个是主机本身的 IP, 一个是主机在集群内的 IP 集群内的 IP 就好比路由器的网关地址, 给节点内的 Pod 分配 IP 时, 都与这个"网关地址"有关 ``` node12: 主机IP:192.168.20.12, 在集群内的IP: 10.224.1.0 node13: 主机IP:192.168.20.13, 在集群内的IP: 10.224.2.0 node14: 主机IP:192.168.20.14, 在集群内的IP: 10.224.3.0 node15: 主机IP:192.168.20.15, 在集群内的IP: 10.224.4.0 ``` ### PodIP 给 Pod 分配 IP 时, 根据 Pod 所在的主机在集群内的 IP 进行分配 ``` node12: 主机IP:192.168.20.12, 在集群内的IP: 10.224.1.0 pod1: 10.224.1.44 pod2: 10.224.1.30 node13: 主机IP:192.168.20.13, 在集群内的IP: 10.224.2.0 pod1: 10.224.2.15 pod2: 10.224.2.20 node14: 主机IP:192.168.20.14, 在集群内的IP: 10.224.3.0 pod1: 10.224.3.40 pod2: 10.224.3.100 node15: 主机IP:192.168.20.15, 在集群内的IP: 10.224.4.0 pod1: 10.224.4.21 pod2: 10.224.4.19 ``` ### ClusterIP 与 ServiceIP ServiceIP 与端口配合只是对一组 pod 中指定应用程序的代理, 它与 ClusterIP 相同都是由 k8s 统一管理的, 大部分情况下, ClusterIP 与 ServiceIP 都是以 10 开头 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echo-service-cluster ClusterIP 10.103.139.141 80/TCP 34m echo-service-node NodePort 10.96.139.86 80:30227/TCP 34m kubernetes ClusterIP 10.96.0.1 443/TCP 30d ``` ## client_address 流量到达 pod 后, pod 获取到的客户端地址会根据 service 的类型而变化 ### PodIP 假设一个 Pod 部署在 10.224.2.0 主机上, PodIP 为:10.244.2.16, 应用程序端口号为 80: Pod 创建成功后, 可以通过`kubectl exec pod-name`的方式进入 pod 内访问应用程序, 在 Pod 内访问应用程序, 不同访问地址, client_address 的值是这样的: ```shell kubectl exec echoserver-8585bfb456-2d48s -- curl -s 10.244.2.16 # client_address: 10.244.2.16 kubectl exec echoserver-8585bfb456-2d48s -- curl -s localhost # client_address: ::1 kubectl exec echoserver-8585bfb456-2d48s -- curl -s 127.0.0.1 # client_address: ::ffff:127.0.0.1 ``` 还可以在集群内的任何主机上通过`PodIP:AppPort`访问到应用程序, 基本上可以看出规律, 在非 Pod 所在节点上访问, client_address 获取到的是执行 curl 命令节点的 IP 地址, 在 Pod 所在节点上访问, client_address 获取到的是节点本身的`x.1`地址 ```shell # 在10.244.0.0节点上执行: curl 10.244.2.16 # client_address: 10.244.0.0 # 在10.244.1.0节点上执行: curl 10.244.2.16 # client_address: 10.244.1.0 # 在10.244.2.0节点上执行: curl 10.244.2.16 # client_address: 10.244.2.1 # 在10.244.3.0节点上执行: curl 10.244.2.16 # client_address: 10.244.3.0 ``` 关于为什么在 10.224.2.0 节点上访问, 显示的 client_address 却是 10.224.2.1, 这和系统的路由规则有关, 简单看一下: 在 node14 上执行以下命令, 里面有这么几行内容, 可以看到如果在 10.224.2.0 主机上访问 PodIP 为 10.224.2.x 的应用程序,最终会被路由到 10.224.2.1 上,再转给 10.224.2.x ```shell [root@node14 ~]# ip route 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink # 发往10.224.0.x的数据, 全部都由flannel.1设备处理, 流向下个地址10.244.0.0 10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink # 发往10.224.1.x的数据, 全部都由flannel.1设备处理, 流向下个地址10.244.2.0 10.244.2.0/24 dev cni0 proto kernel scope link src 10.244.2.1 # 发往10.224.2.x的数据, 全部都由cni0设备处理, 且指定了cni0的网卡地址为10.224.2.1 10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink # 发往10.224.3.x的数据, 全部都由flannel.1设备处理, 流向下个地址10.244.3.0 ``` ### ClusterIP Service, 相当于是为单个 pod 或者 pod 组,创建了一个代理, Service 本身的一个端口会与 Pod 内应用程序的端口做一层映射关系 ClusterIP-Service 长得像这样: ```shell [root@node12 ~]# k describe svc echo-service-cluster Name: echo-service-cluster Namespace: default Labels: app=echoserver Annotations: Selector: app=echoserver Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.102.238.26 # 这是Service的IP地址 IPs: 10.102.238.26 Port: 80/TCP # 这是Service本身的端口 TargetPort: 80/TCP # 这是应用程序的端口 Endpoints: 10.244.1.51:80,10.244.2.17:80,10.244.3.32:80 Session Affinity: None Events: ``` 所以 ClusterIP 类型的 Service 创建好之后, 可以在集群内的任意主机上通过`ServiceIP:ServicePort`访问到应用程序, 集群外访问不到需要注意的是, 当 deployment 在多个节点上都有副本 Pod 时, 在集群内的任意主机上访问 Service, 应用程序获取到的 client_address 是会动态变化的, 因为 Service 代理的是一组 Pod,Service 有一套自己的负载均衡体系, 可能会路由到任何一台 Pod 副本所在的主机上在 Pod 内也可以通过`ServiceIP:ServicePort`访问到应用程序, 像下面这样, 如果被路由到 Pod 所在的主机节点上, client_address 获取的是 ip route 指定的地址, 如果被路由到其他节点上, client_address 获取的是执行 curl 命令的 Pod 本身的 IP 地址 ```shell kubectl exec pod-name -- curl ServiceIP:ServicePort ``` ### NodePort NodePort 类型的 Service 是 ClusterIP 的超集, 所以 ClusterIP 可以用的访问方式, NodePort 同样适用 NodePort-Service 的内容长得像这样: ```shell [root@node12 ~]# k describe svc echo-service-node Name: echo-service-node Namespace: default Labels: app=echoserver Annotations: Selector: app=echoserver Type: NodePort IP Family Policy: SingleStack IP Families: IPv4 IP: 10.99.66.47 # 这是Service的IP地址 IPs: 10.99.66.47 Port: 80/TCP # 这是Service本身的端口 TargetPort: 80/TCP # 这是应用程序的端口 NodePort: 31706/TCP # 这是为Service分配的可访问端口NodePort Endpoints: 10.244.1.51:80,10.244.2.17:80,10.244.3.32:80 Session Affinity: None External Traffic Policy: Cluster Events: ``` NodePort-Service 创建好之后, 最大的功能在于, 它可以在集群外的主机上通过`集群内任意NodeIP:NodePort`访问到应用程序与 ClusterIP-Service 一样, Service 代理的是一组 Pod, 所以在访问时, 应用程序获取到的 client_address 也是会根据 NodeIP 的变化而变化 ## CNAME Service 在创建的时候, 一般都会有一个 service-name 字段, 集群内的任意 Pod 都可以通过这个字段访问到 Service ```shell [root@node12 ~]# k get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echo-service-cluster ClusterIP 10.102.238.26 80/TCP 26m echo-service-node NodePort 10.99.66.47 80:31706/TCP 10m kubernetes ClusterIP 10.96.0.1 443/TCP 30d ``` 比如上面的案例, 在集群内的任意 Pod 内执行`curl 10.102.238.26`与`curl echo-service-cluster`的结果是一样的在实际运用中, 微服务架构之间的 RCP 调用, 在不知道 ServiceIP 的情况下, 就可以通过 CNAME 来访问对应的服务

K8S备忘录--IP地址分配及不同Service类型可支持的访问方式