K8S集群学习记录03

Pod概念

只要有pod，pod中的pause容器就会被创建启动；pause容器是pod的根容器，1.初始化网络栈、挂载网络卷，即pod内部的其他容器共用pause容器的网络栈和存储卷。2.启动一系列的应用容器，应用容器数量在一个以上，即需要启动一个主容器

在同一个pod中，容器之间的端口不能冲突

服务的分类：

• 有状态服务：例如：mysql、数据库类型
• 无状态服务：例如：http、web服务器、ftp服务器
• 中心化服务:
• 去中心化服务：

pod类型

创建模式

• 自主式pod（自己管理自己，出现问题自生自灭）
• 控制器管理pod（控制器管理，pod出问题控制器会处理）

控制器类型：

为无状态服务设计的控制器：

• 通用型：（目标：要求持续运行）

  • ReplicationController（RC）：用来确保容器应用的副本数始终保持在用户定义的副本数（期望），即如果有容器异常退出，会自动创建新的pod来代替；而如果异常多出来的容器也会被回收。需要注意副本数（期望）的值只是一个范围，具体能够达到多少副本的数量与资源相挂钩。 （在新版本K8S中建议使用RS来代替RC）

  • ReplicaSet（RS）：与RC没有本质的不同，并且RS支持集合式的selector。RS虽好，但不支持滚动更新和回滚。

    虽然RS可以单独使用，但一般还是建议使用Deployment来管理RS，这样就无需担心跟其他机制的不兼容问题。

  • Deployment（Deploy）：支持滚动更新以及回滚。

    • deployment的底层原理：

      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q50Eygps-1645975384183)(/Users/carry/Desktop/deployment的底层原理 .png)]

• 特殊场景：

  批处理任务：（目标：成功退出，返回码为0）

  • Job Cron Job:

    • Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。

    • Corn Job：管理基于时间，即 在给定时间点只运行一次；周期性的在给定时间点运行。

    job 与 Corn job 主要区别：job保障任务一次或多次的成功；cron job在轮巡计划下定期执行job，实现批处理任务的运行。

  每个节点有且只有一个任务：

  • daemonset：确保全部(或者一些）Node上运行一个pod的副本。当有Node加入集群时，也会为其增加一个pod；当有Node从集群移除，这些pod也会被回收。删除daemonSet将会删除他创建的所有pod。

    使用daemonSet的典型用法：

    • 运行集群存储daemon，例如在每个Node上运行glusterd、ceph
    • 在每个Node上运行日志收集daemon，例如fluentd、logstash
    • 在每个Node上运行监控daemon，例如：prometheus Node Exporter

  自动扩容缩

  • HPA：仅适用于deployment和RS之上，在V1版本中仅支持根据pod的CPU利用率扩容，在V1 alpha版本中支持根据内存和用户自定义的metric扩容。

    说人话就是：根据pod资源使用情况，调整副本数量，依赖于RC、RS、Deployment之上。

有状态服务的控制器

• StatefulSet：解决有状态服务的问题（对应RS、Deployment是为无状态服务而设计），应用场景包括：

  • 稳定的持久化存储：即pod重新调度后还是能访问到相同的持久化数据，基于PVC实现；

    （每一个Pod都有自己稳定的存储）

  • 稳定的网络标志：即pod重新调度后，其podName和HostName不变，基于Headless Server来实现；

    （ 每一个控件启动的pod都有唯一的访问地址，访问地址是不变的）

  • 有序部署、有序扩容：即pod是有顺序的 ，在部署或扩容的时候要依据定义的顺序依次进行（即从0到N-1，在下一个pod运行之前的所有之前pod必须都是running或ready状态），基于init containers实现

    （控制器的启动顺序有顺序，第一个不启动成功、第二个不会启动。）

  • 有序收缩、有序删除（从N-1到0）

自定义控制器

通用型控制器无法满足时，需要自行通过官方的开发工具包进行kubernetes开发。

网络通讯方式

k8s的网络模型假定了所有pod都在一个可以直接连通的扁平的网络空间中，这在GCE(google computer Engine)里面是现成的网络模型，k8s已经假定这个网络存在了。

而在私有云里搭建k8s集群，需要自行实现这个网络假设，将不同节点上的Docker容器之间互相访问先打通，然后运行k8s。

即：没有扁平化的网络，k8s部署好后是未就绪的。

Flannel

Flannel是CoreOS团队针对k8s设计的一个网络规划服务，简单来书，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟网络IP地址（flannel与etcd的联动实现）。而且它还能在这些IP地址之间建立一个覆盖网络，通过覆盖网络将数据包原封不动的传递到目标容器内。

---

flannel底层原理：

简单来说，10.1.15.2想要发送数据包到10.1.20.3，

1. 发送源（15.2）的数据包(包含源地址、目标地址)通过docker查询目标地址是否处于同一网段，不处于同一网段，则需要网关进行传递，而所有通过doker网关向外界通讯的报文都会被flannel0捕获；
2. Flannel0管理Flanneld（flanneld实现了flannel0的接口），flanneld进程获取到数据包后，有且只有通过物理网络将报文进行传输，所以Flanneld通过查询etcd，匹配目标地址（10.1.20.3）所在网段对应的物理IP(192.169.66.12);
3. Flanneld获取到目标地址所在网段的物理IP(192.169.66.12)后，将数据包进行二次封装，设定源地址为当前物理ip(192.168.66.11)、目标地址为通过查询得到的物理ip(192.169.66.12)、内容是需要传递的数据包，就如同一个快递被另一个快递包裹进行传递一样。通过物理网络将二次封装的数据包进行UDP传递（UDP网络通讯io有保障，但是在网络设施不佳、传输路径较长时UDP的传输并不稳定，但在当前环境下，缺点被掩盖(同机房)）；
4. 二次封装的数据包到达物理目标地址(192.169.66.12)后，flanneld将二次封装的数据包拆封、将内部数据包传输到docker环境中广播，目标地址(10.1.20.3)进行接收。