K8S中的网络

pod与pod通信

 pod在同一主机

同一主机网络的pod互通和我们之前学习的docker bridge相似，通过linux网桥添加虚拟设备对 veth pair 连接容器和主机主机命名空间。
我们把之前的图拿过来，在k8s中只不过把灰色部分替换成CNI方案实现。

pod 在不同主机下

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

简单理解就是通过在主机上启动虚拟路由器(calico node)，将每个主机作为路由器使用实现互联互通的网络拓扑。

Calico节点组网时可以直接利用数据中心的网络结构(L2或者L3)，不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。

pod 与service通信

我们知道在k8s中容器随时可能被摧毁，pod的IP显然不是持久的，会随着扩展或缩小应用规模、或者应用程序崩溃以及节点重启等而消失和出现。service 设计就是来处理这个问题。service可以管理一组 Pod 的状态，允许我们跟踪一组随时间动态变化的 Pod IP 地址。而客户端只需要知道service这个不变的虚拟IP就可以了。

我们先来看看典型的service与pod使用，我们创建了一个service，标签选择器为app:nginx，将会路由到app=nginx标签的Pod上。
其实大多数时候在自动化部署服务时并不知道service ip，所以另一种常见方式通过DNS进行域名解析后，可以使用 “ServiceName:Port” 访问Service，可以自己尝试一下。

 

 

外网与service通信

其实所谓外网通信也是service的表现形式。
service几种类型和不同用途。

ClusterIP： 用于在集群内部互相访问的场景，通过ClusterIP访问Service，即我们上面所说的pod与service。
NodePort： 用于从集群外部访问的场景，通过节点上的端口访问Service。
LoadBalancer： 用于从集群外部访问的场景，其实是NodePort的扩展，通过一个特定的LoadBalancer访问Service，这个LoadBalancer将请求转发到节点的NodePort，而外部只需要访问LoadBalancer。
None： 用于Pod间的互相发现，这种类型的Service又叫Headless Service。

LoadBalancer本身不是属于Kubernetes的组件，如果使用云厂商的容器服务。通常会提供一套他们的负载均衡服务比如阿里云ACK的SLB、华为云的ELB等等。

Service是基于四层TCP和UDP协议转发的，而k8s 另外一种资源对象Ingress可以基于七层的HTTP和HTTPS协议转发，可通过域名和路径做到更细粒度的划分，这是后话。