k8s集群中的每一个Pod(最小调度单位)都有自己的IP地址，即ip-per-pod模型。
在ip-per-pod每个模型pod为了保持集群中的独特性，我们不需要在每个集群中都显式 Pod 之间创建链接， 从容器端口到主机端口的映射不需要处理。从端口分配、命名、服务发现、 从负载平衡、应用配置和迁移的角度来看，Pod 可视为独立虚拟机或物理主机。
如下图所示，两个容器从表面上看docker网络与k8s网络中与client通信形式。

k8s为了保持核心功能的简化(模块化)和适应不同业务用户的网络环境，是一个庞大的分布式系统，k8s通过CNI(Container Network Interface)即集成各种网络方案的容器网络接口。这些网络方案必须符合要求k8s网络模型要求：

节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
节点代理(如系统保护过程)kubelet）节点上的一切都可以和Pod通信

注:只针对那些支持: Pods 运行在主机网络中的平台(如:Linux）：

在节点主机网络中运行的主机 Pod可以不通过 NAT 在所有节点上 Pod 通信

这有点像美团吗？外包配送业务（CNI）对于三方公司（实现计划），我不在乎骑手通过哪种飞机炮（网络）送餐，只要符合及时、不泄漏（模型要求）等相关规则，这是一个合格的分销。

Pod内容器很简单，在同一个 Pod 内部，所有容器共享存储，网络使用相同 IP 地址和端口空间可以通过localhost发现对方。Pod 使用中间容器 Infra，Infra 在 Pod 首先创建，其他容器通过 Join Network Namespace 的方式与 Infra 容器相连。

我们有一个pod包含busybox、nginx这两个容器

kubectl get pod -n training NAME                                  READY    STATUS     RESTARTS    AGE pod-localhost-765b965cfc-8sh76   2/2       Running    0             2m56s 

在busybox中使用telnet连接nginx容器的 80端口看看。

kubectl exec -it  pod-localhost-765b965cfc-8sh76 -c container-si1nrb -n training -- /bin/sh  # telnet localhost 80 Connected to localhost 

一个pod有多个容器可以通过-c指定进入的容器名(通过describe通过容器名称)，显然是通过localhost可以轻松访问同一个pod中的nginx容器80端口。这通常部署在许多密切相关的应用程序中pod中。

我们通过node两个选择器pod调度到同一个node中

 ...  nodeSelector:         kubernetes.io/hostname: node2  ... 

两个容器分别获得一个IP地址，也通过IP双方网络地址正常交换。

# kubectl get pod -o wide -n training  NAME                                  READY   STATUS    RESTARTS   AGE     IP              NODE                    NOMINATED NODE   READINESS GATES  pod-to-pod-64444686ff-w7c4g           1/1     Running   0          6m53s   100.82.98.206   node2                    pod-to-pod-busybox-7b9db67bc6-tl27c   1/1     Running   0          5m3s    100.82.98.250   node2                    # kubectl exec -it  pod-to-pod-busybox-7b9db67bc6-tl27c  -n training -- /bin/sh /# telnet 100.82.98.206 80 Connected to 100.82.98.206 

同一主机网络的pod以及我们以前学到的东西docker bridge相似，通过linux在网桥上添加虚拟设备 veth pair 连接容器和主机命名空间。
在k8s只是用灰色部分代替CNI方案实现。

此时pod分布如下

kubectl get pod -o wide -n training  NAME                                               ` READY     STATUS     RESTARTS   AGE    IP                 NODE                    NOMINATED NODE   READINESS GATES  pod-to-pod-64444686ff-w7c4g                     1/1        Running    0            104m   100.82.98.206    node2                        pod-to-pod-busybox-node2-6476f7b7f9-mqcw9    1/1        Running     0            42s    100.91.48.208    node3                 # kubectl exec -it  pod-to-pod-busybox-node2-6476f7b7f9-mqcw9  -n training -- /bin/sh / # telnet 100.82.98.206 80 Connected to 100.82.98.206 

pod不同主机的通信依赖于不同主机的通信CNI插件，这里我们以Calico为例的做简单了解，从Calico架构图中可以看到每个node节点的自身依然采用容器网络模式，Calico在每个节点都利用Linux 内核实现了一个高效的虚拟路由器vRouter来负责数据转发。每个虚拟路由器将路由信息广播到网络中，并添加路由转发规则。同时基于iptables还提供了丰富的网络策略，实现k8s的Network Policy策略，提供容器间网络可达性限制的功能。