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

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

1.1&＃xff1a;pod的种类

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

1.2&＃xff1a;pod网络

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

1.3&＃xff1a;pod存储

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

1.4&＃xff1a;使用pod

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

1.5&＃xff1a;pod控制器类型

• Kubernetes中内建了很多controller&＃xff08;控制器&＃xff09;&＃xff0c;这些相当于一个状态机&＃xff0c;用来控制Pod的具体状态和行为

• 有如下几种类型&＃xff1a;RC&＃xff08;ReplicationController&＃xff09;&＃xff0c;RS&＃xff08;ReplicaSet&＃xff09;&＃xff0c;Deployment&＃xff0c;HPA&＃xff08;HorizontalPodAutoScale&＃xff09;,StatefullSet&＃xff0c;DaemonSet&＃xff0c;Job&＃xff0c;Cronjob

• RC&＃xff1a;

  • ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数&＃xff0c;即如果有容器异常退出&＃xff0c;会自动创建新的Pod来替代&＃xff1b;而如果异常多出来的容器也会自动回收。
  • 在新版本的 Kubernetes中建议使用 ReplicaSet来取代 ReplicationControlle

• RS&＃xff1a;

  • ReplicaSet跟 ReplicationController没有本质的不同&＃xff0c;只是名字不一样&＃xff0c;但是ReplicaSet支持集合式的selector

• Deployment&＃xff1a;

  • 虽然 ReplicaSet可以独立使用&＃xff0c;但一般还是建议使用 Deployment来自动管理ReplicaSet&＃xff0c;这样就无需担心跟其他机制的不兼容问题&＃xff08;比如 ReplicaSet不支持rolling-update&＃xff08;回滚更新&＃xff09;但 Deployment支持&＃xff09;
  • Deployment为Pod和 ReplicaSet提供了一个声明式定义&＃xff08; declarative&＃xff09;方法&＃xff0c;用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括
  • 定义 Deployment来创建Pod和 ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续 Deployment

• HPA

  • Horizontal Pod Autoscaling仅适用于 Deployment和 ReplicaSet&＃xff0c;在V1版本中仅支持根据Pod的CPU利用率扩所容&＃xff0c;在 V1alpha版本中&＃xff0c;支持根据内存和用户自定义的 metric扩缩容

• StatefullSet

  • StatefulSet是为了解决有状态服务的问题&＃xff08;对应 Deployments和 ReplicaSets是为无状态服务而设计&＃xff09;&＃xff0c;其应用场景包括
  • 稳定的持久化存储&＃xff0c;即Pod重新调度后还是能访问到相同的持久化数据&＃xff0c;基于PVC来实现
  • 稳定的网络标志&＃xff0c;即Pod重新调度后其 PodName和 HostName不变&＃xff0c;基于 Headless Service&＃xff08;即没有 Cluster IP的 Service&＃xff09;来实现
  • 有序部署&＃xff0c;有序扩展&＃xff0c;即Pod是有顺序的&＃xff0c;在部署或者扩展的时候要依据定义的顺序依次依次进行&＃xff08;即从0到N1&＃xff0c;在下一个Pod运行之前所有之前的Pod必须都是 Running和 Ready状态&＃xff09;&＃xff0c;基于 init containers来实现
  • 有序收缩&＃xff0c;有序删除&＃xff08;即从N-1到0&＃xff09;

• DaemonSet

  • DaemonSet确保全部&＃xff08;或者一些&＃xff09;Node上运行一个Pod的副本。当有Node加入集群时&＃xff0c;也会为他们新增一个Pod。当有Node从集群移除时&＃xff0c;这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod
  • 使用 DaemonSet的一些典型用法&＃xff1a;
    • 运行集群存储 daemon&＃xff0c;例如在每个Node上运行 glusterd、ceph
    • 在每个Node上运行日志收集 daemon&＃xff0c;例如 fluentd、 logstash
    • 在每个Node上运行监控 daemon&＃xff0c;例如 Prometheus Node Exporter

• Job,Cronjob

  • Job负责批处理任务&＃xff0c;即仅执行一次的任务&＃xff0c;它保证批处理任务的一个或多个Pod成功结束
  • CronJob管理基于时间的Job&＃xff0c;即&＃xff1a;
    • 在给定时间点只运行一次
    • 周期性地在给定时间点运行

1.6&＃xff1a;服务发现

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

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

2.1&＃xff1a;网络通讯模式

• 同一个Pod内的多个容器之间&＃xff1a;lo&＃xff08;通过localhost回环地址&＃xff09;
• 各Pod之间的通讯&＃xff1a;overlay Network &＃xff08;覆盖网络&＃xff09;
• Pod与 Service之间的通讯&＃xff1a;各节点的 Iptables规则

2.2&＃xff1a;K8S中网络层次说明

2.3&＃xff1a;网络解决方案&＃xff0c;通过Flannel访问

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

2.4&＃xff1a;网络通讯方式总结

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