K8s速览 - 技术栈

k8s的核心能力

● 服务发现与负载均衡

● 服务恢复

● 服务伸缩

● 自动发布与回滚

● 批量执行

架构

server-client两层架构，Master作为中央管控节点，会和每一个Node进行一个连接；

所有UI层，client的操作，只会和Mater进行连接；

API Server ：处理API操作，k8s中的所有组件都会和其进行连接，组件之间不进行独立连接，依赖于API Server进行消息传递；
Controller ：控制器，负载集群状态的管理，譬如自动恢复，容器伸缩等都由controller完成；
Scheduler ：调度器，为容器找到合适的节点进行放置；
etcd：分布式存储系统，API Server需要的原信息都被放置到etcd中；etcd本身是有个高可用系统，通过etcd也保证了k8s master组件的高可用；

工作流程-交互示例：

创建pod的请求会交给API Server;API Server将数据存入etcd;

Scheduler通过watch机制知道有一个pod需要被调度；根据请求的资源等信息进行调度决策，选中调度节点；

Scheduler向 API Server报告调度信息

API Server通知相应节点进行pod的执行启动

节点kubelet 就会去调 Container runtime 来真正去启动配置这个容器和这个容器的运行环境，去调度 Storage Plugin 来去配置存储，network Plugin 去配置网络。

Pod和容器设计模式

容器的本质：

● 一个视图隔离、资源受限的进程

○ 容器内PID=1的进程就是应用本身

k8s->相当于云时代的操作系统；

● 类推容器镜像就是这个操作系统的软件安装包

那么pod相当于进程组；一个逻辑单位，k8s中的原子调度单位；

Pod需要解决的问题：

如何让pod内的多个容器搞笑共享资源和数据；

● 容器之间的是会通过Linux Namespace和cgroups隔离的

应用编排核心原理

应用编排与管理

思考直接管理pod的问题

● 如何保证集群中可用pod的数量

● 如何为所有pod更新镜像版本

● 更新过程中，如何为保证服务的可用性

● 更新过程中，发现问题如何及时回滚

● 声明式spec，声明期望的副本数，用控制器去保证status和spec预期一致

● 直接修改控制器中声明的image

● 设置更新策略，可滚动更新或者全量更新，还可以设置最大不可用pod数

● rollout undo一键回滚上一版或者指定版本

配置信息管理

● 可变配置信息

● 敏感信息存储

● pod自我身份认证

● 容器资源配置

● 容器安全管控

● 容器启动前前置条件校验-securityContext

configmap

● 管理环境变量，命令行参数等------解耦容器镜像和可变配置，保障pod的可移植性

● 限制

○ etcd限制大小1mb

○ pod只可以引用同命名空间下的cm

○ cm要在pod前创建，否则pod无法创建出来

○ cm中定义的key有问题时不会阻碍pod创建

secret

● 存储密码，token等敏感信息

● base-64编码保存

● 限制

○ 文件大小显示1mb

seviceAccount

pod身份认证

Qos：服务质量

根据request和limit隐式设置

securityContext

● 限制容器的行为

● 容器级别-对指定容器生效

● pod级别-对pod中的所有容器生效

● Pod Security Policies（PSP）：对集群内的所有pod生效

InitContainer

● Initcontainer会先于普通的container启动执行，所有InitContainer执行成功后，普通container才会执行

● pod中多个InitContainer是按定义次序一次启动执行，pod中多个普通container是并行启动

● 用途

○ 普通container启动前的初始化-如配置文件准备；前置条件检验-如网络联通检验

持久化信息存储

需要解决的问题

● 容器异常退出，保障之前的数据不丢失

● 同pod中的多个容器共享数据

Pod Volumes类型：

● 本地存储：emptydir、hostpath

● 网络存储

● project volume：secret、configmap、downwardAPI、serviceaccountToken

● PV&PVC

csi 是什么？

csi 的全称是 container storage interface，它是K8s社区后面对存储插件实现(out of tree)的官方推荐方式。csi 的实现大体可以分为两部分：

● 第一部分是由k8s社区驱动实现的通用的部分，像我们这张图中的 csi-provisioner和 csi-attacher controller；

● 另外一种是由云存储厂商实践的，对接云存储厂商的 OpenApi，主要是实现真正的 create/delete/mount/unmount 存储的相关操作，对应到上图中的csi-controller-server和csi-node-server。

接下来看一下，当用户提交 yaml 之后，k8s内部的处理流程。用户在提交 PVCyaml 的时候，首先会在集群中生成一个 PVC 对象，然后 PVC 对象会被 csi-provisioner controller watch到，csi-provisioner 会结合 PVC 对象以及 PVC 对象中声明的 storageClass，通过 GRPC 调用 csi-controller-server，然后，到云存储服务这边去创建真正的存储，并最终创建出来 PV 对象。最后，由集群中的 PV controller 将 PVC 和 PV 对象做 bound 之后，这个 PV 就可以被使用了。

用户在提交 pod 之后，首先会被调度器调度选中某一个合适的node，之后该 node 上面的 kubelet 在创建 pod 流程中会通过首先 csi-node-server 将我们之前创建的 PV 挂载到我们 pod 可以使用的路径，然后 kubelet 开始 create && start pod 中的所有 container

总的来说，有三个阶段：第一个 create 阶段，主要是创建存储；第二个 attach 阶段，就是将那块存储挂载到 node 上面(通常为将存储load到node的/dev下面)；第三个 mount 阶段，将对应的存储进一步挂载到 pod 可以使用的路径。这就是我们的 PVC、PV、已经通过CSI实现的卷从创建到使用的完整流程。