kube-proxy 支持 ipvs iptables两种模式

Cluster IP

Service的IP地址，此为虚拟IP地址。外部网络无法ping通，只有kubernetes集群内部访问使用。

在kubernetes查询Cluster IP
kubectl -n 命名空间 get Service即可看到ClusterIP

Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，原因有以下几点

Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址
Cluster IP无法被ping，他没有一个“实体网络对象”来响应
Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。
在不同Service下的pod节点在集群间相互访问可以通过Cluster IP

ClusterIP： 默认方式。根据是否生成ClusterIP又可分为普通Service和Headless Service两类：
普通Service：通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最常见的方式。
Headless Service：该服务不会分配Cluster IP，也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为podIP列表。主要供StatefulSet使用。

kafka0-kafka.svc.XX ====> pod ip列表 （ 客户端获得这个列表，自行处理)
service ip => cluster ip =>kube proxy 负载均衡(RR) => pod ip

cluster-ip 是虚拟ip 只能curl 不能ping
[root@cs2-k8s1 k8s]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-test NodePort 10.68.126.157 80:30002/TCP 79s

[root@cs2-k8s1 k8s]# kubectl exec -it post-zdjkl /bin/bash
[root@post-zdjkl snake]# ping 10.68.126.157
PING 10.68.126.157 (10.68.126.157) 56(84) bytes of data.
— 10.68.126.157 ping statistics —
15 packets transmitted, 0 received, 100% packet loss, time 14006ms

[root@post-zdjkl snake]# curl 10.68.126.157

......(省略)

ClusterIP
此类型会提供一个集群内部的虚拟IP（与Pod不在同一网段)，以供集群内部的pod之间通信使用。ClusterIP也是Kubernetes service的默认类型。
!

为了实现图上的功能主要需要以下几个组件的协同工作：
apiserver：在创建service时，apiserver接收到请求以后将数据存储到etcd中。
kube-proxy：k8s的每个节点中都有该进程，负责实现service功能，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables中。
iptables：使用NAT等技术将virtualIP的流量转至endpoint中。