K8S，盘他！之Pod概念与网络通讯方式详解！

蔚落 2023-07-04 12:53 9阅读 0赞

### 文章目录 ###

*  前言
 *  一：pod概念
 *   *   *  1.1：pod的种类
         *  1.2：pod网络
         *  1.3：pod存储
         *  1.4：使用pod
         *  1.5：pod控制器类型
         *  1.6：服务发现
 *  二：网络通讯方式
 *   *   *  2.1：网络通讯模式
         *  2.2：K8S中网络层次说明
         *  2.3：网络解决方案，通过Flannel访问
         *  2.4：网络通讯方式总结

# 前言 #

# 一：pod概念 #

*  Pod是kubernetes中你可以创建和部署的最小也是最简的单位。Pod代表着集群中运行的进程。
 *  Pod中封装着应用的容器（数量大于等于1，docker最常用，也可使用其他的），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

### 1.1：pod的种类 ###

*  自主式pod
 *  控制器管理的pod

### 1.2：pod网络 ###

*  每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。

### 1.3：pod存储 ###

*  可以为一个Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

### 1.4：使用pod ###

*  你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
 *  Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。

### 1.5：pod控制器类型 ###

*  Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为
 *  有如下几种类型：RC（ReplicationController），RS（ReplicaSet），Deployment，HPA（HorizontalPodAutoScale）,StatefullSet，DaemonSet，Job，Cronjob
 *  RC：
    
     *  ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
     *  在新版本的 Kubernetes中建议使用 ReplicaSet来取代 ReplicationControlle
 *  RS：
    
     *  ReplicaSet跟 ReplicationController没有本质的不同，只是名字不一样，但是ReplicaSet支持集合式的selector
 *  Deployment：
    
     *  虽然 ReplicaSet可以独立使用，但一般还是建议使用 Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet不支持rolling-update（回滚更新）但 Deployment支持）
     *  Deployment为Pod和 ReplicaSet提供了一个声明式定义（ declarative）方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括
     *  定义 Deployment来创建Pod和 ReplicaSet
     *  滚动升级和回滚应用
     *  扩容和缩容
     *  暂停和继续 Deployment
 *  HPA
    
     *  Horizontal Pod Autoscaling仅适用于 Deployment和 ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩所容，在 V1alpha版本中，支持根据内存和用户自定义的 metric扩缩容
 *  StatefullSet
    
     *  StatefulSet是为了解决有状态服务的问题（对应 Deployments和 ReplicaSets是为无状态服务而设计），其应用场景包括
     *  稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
     *  稳定的网络标志，即Pod重新调度后其 PodName和 HostName不变，基于 Headless Service（即没有 Cluster IP的 Service）来实现
     *  有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N1，在下一个Pod运行之前所有之前的Pod必须都是 Running和 Ready状态），基于 init containers来实现
     *  有序收缩，有序删除（即从N-1到0）
 *  DaemonSet
    
     *  DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod
     *  使用 DaemonSet的一些典型用法：
        
         *  运行集群存储 daemon，例如在每个Node上运行 glusterd、ceph
         *  在每个Node上运行日志收集 daemon，例如 fluentd、 logstash
         *  在每个Node上运行监控 daemon，例如 Prometheus Node Exporter
 *  Job,Cronjob
    
     *  Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
     *  CronJob管理基于时间的Job，即：
        
         *  在给定时间点只运行一次
         *  周期性地在给定时间点运行

### 1.6：服务发现 ###

*  Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。
 *  ![mark][]
 *  Kubernetes `Service` 定义了这样一种抽象：一个 `Pod` 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。（通过一些标签与pod建立联系，且service有自己的IP地址和端口）
 *  client客户端通过访问service的IP地址和端口和RR（轮询算法）来访问到下面的pod。

# 二：网络通讯方式 #

*  Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（ Google Compute Engine）里面是现成的网络模型， Kubernetes假定这个网络已经存在。
 *  而在私有云里搭建 Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker容器之间的互相访问先打通，然后运行 Kubernetes

### 2.1：网络通讯模式 ###

*  同一个Pod内的多个容器之间：lo（通过localhost回环地址）
 *  各Pod之间的通讯：overlay Network （覆盖网络）
 *  Pod与 Service之间的通讯：各节点的 Iptables规则

### 2.2：K8S中网络层次说明 ###

*  ![mark][mark 1]

### 2.3：网络解决方案，通过Flannel访问 ###

*  Flannel是CoreOS团队针对 Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内
 *  ![mark][mark 2]
 *  ETCD在这里的作用：为Flannel提供说明
    
     *  存储管理 Flannel可分配的IP地址段资源
     *  监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

### 2.4：网络通讯方式总结 ###

*  同一个Pod内部通讯
    
     *  同一个Pod共享同一个网络命名空间，共享同一个 Linux协议栈
 *  pod1和pod2通讯–在同一台机器：
    
     *  Pod1与Pod2不在同一台主机，Pod的地址是与 docker0在同一个网段的，但doke0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问
 *  pod1和pod2通讯–不在同一台机器：
    
     *  Pod1与Pod2在同一台机器，由 Docker0网桥直接转发请求至Pod2，不需要经过 Flanne1
 *  Pod至 Service的网络
    
     *  目前基于性能考虑，全部为 iptables（现在版本都是通过LVS）维护和转发
 *  Pod到外网
    
     *  Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后， iptables执行 Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求
 *  外网访问Pod
    
     *  外网访问Pod通过Service

[mark]: https://imgconvert.csdnimg.cn/aHR0cDovL3Rhbmd6aGVuZy1waWNnby5vc3MtY24taGFuZ3pob3UuYWxpeXVuY3MuY29tL2ltZy8yMDIwMDIxMS8xMjA1MDI4MjkucG5n?x-oss-process=image/format,png
[mark 1]: https://imgconvert.csdnimg.cn/aHR0cDovL3Rhbmd6aGVuZy1waWNnby5vc3MtY24taGFuZ3pob3UuYWxpeXVuY3MuY29tL2ltZy8yMDIwMDIxMS8xMjM2MzM1NzQucG5n?x-oss-process=image/format,png
[mark 2]: https://imgconvert.csdnimg.cn/aHR0cDovL3Rhbmd6aGVuZy1waWNnby5vc3MtY24taGFuZ3pob3UuYWxpeXVuY3MuY29tL2ltZy8yMDIwMDIxMS8xMjI1Mzk1NzkucG5n?x-oss-process=image/format,png