k8s 框架及历史简介

k8s 框架简介

IAAS：基础设施级服务
PAAS：平台级服务
SAAS：软件级服务

学习k8s的思维导图

链接：https://pan.baidu.com/s/154StovBmSXj4-ZzGUVbeVA
提取码：q34m

发展史

Docker Swarm: 面向对象是中小型企业
Apache Mesos： Twitter marathon 把硬件资源虚拟成一个整体给别人分配使用，逐步没落，调度资源没有k8s灵活
k8s: CNCF(云计算基金会) Borg google内部使用borg，后来发现dockerswarm使用广泛，所以让go开发工程师重写brog，成了k8s，1.0版本的时候捐给了CNCF

这里注意的是，docker和另外一家coreos公司的ceo是好哥们，技术基本是共享的，docker火起来后，coreos也研发了一个类似docker的技术，但是最后结果可想而知，最后他加入k8s生态构建，etcd就是coreos提供的捐赠给CNCF的

除了k8s外还有一些容器管理引擎：

• podman 红帽RedHat开发的容器管理引擎
• docker docker公司研发的docker，另外他还研发了container捐给CNCF
• CNCF container，docker公司研发捐给CNCF的

docker和contaniner的关系：

• docker用到的运行接口是CRI，CRI是一种容器运行时的标准，可以把CRI想象成一个数据线接口，Python等调用docker是需要调用这个接口，遵循这个规范，这个规范就是CRI
• container用到的接口是O-CRI，他是CRI做了些改动，O即OPEN，

有趣的是，k8s加入CNCF后，kubectl用的是O-CRI接口，无法直接调用docker的CRI接口，CNCF是国际公司，不可能直接去迁就docker，所以在中间加了个垫片，类似于螺丝与螺母之间的垫片，后来k8s壮大超过docker后，不再迁就docker，在1.19版本中，移除了垫片。k8s调用docker的O-CRI接口，如果没有就不调了，docker忍气吞声发了声明，说支持O_CRI，反过来支持k8s。

k8s的优势：

• 开源
• 轻量级
• 弹性伸缩
• 负载均衡

1.1 简介

• Kubernetes 是用来管理容器集群的平台。既然是管理集群，那么就存在被管理节点，针对每个 Kubernetes 集群都由一个 Master 负责管理和控制集群节点。

• 我们通过 Master 对每个节点 Node 发送命令。简单来说，Master 就是管理者，Node 就是被管理者。

• Node 可以是一台机器或者一台虚拟机。在 Node 上面可以运行多个 Pod，Pod 是 Kubernetes 管理的最小单位，同时每个 Pod 可以包含多个容器（Docker）。

• 通常我们都是通过 kubectl 对 Kubernetes 下命令的，它通过 APIServer 去调用各个进程来完成对 Node 的部署和控制

• APIServer 的核心功能是对核心对象（例如：Pod，Service，RC）的增删改查操作，同时也是集群内模块之间数据交换的枢纽。

• 它包括了常用的 API，访问（权限）控制，注册，信息存储（etcd）等功能。在它的下面我们可以看到 Scheduler，它将待调度的 Pod 绑定到 Node 上，并将绑定信息写入 etcd 中。

• etcd 包含在 APIServer 中，用来存储资源信息。接下来就是 Controller Manager 了，如果说 Kubernetes 是一个自动化运行的系统，那么就需要有一套管理规则来控制这套系统。

• Controller Manager 就是这个管理者，或者说是控制者。它包括 多 个 Controller，分别对应着副本，节点，资源，命名空间，服务等等

• 紧接着，Scheduler 会把 Pod 调度到 Node 上，调度完以后就由 kubelet 来管理 Node 了。

• kubelet 监听apiserver，apiserver下发任务后，kubectl调用docker的接口创建容器。

• kube-proxy 上面监听apiserver，拿到请求后，到node上调用linux内核接口netlink,通过netlink实现对ipvs和network网络的管控，实现数据转发，和kubectl各司其职

• 在完成资源调度以后，kubelet 进程也会在 APIServer 上注册 Node 信息，定期向 Master 汇报 Node 信息，并通过 cAdvisor 监控容器和节点资源。

• 由于，微服务的部署都是分布式的，所以对应的 Pod 以及容器的部署也是。为了能够方便地找到这些 Pod 或者容器，引入了 Service（kube-proxy）进程，它来负责反向代理和负载均衡的实施。

上面是k8s的一些组件，另外还有一些插件。组件和插件的区别：

组件： 类似人的手，胳膊，有了这些才完整
插件： 手里的锤子，有了插件有更多的功能，没有也是正常的

2.1 组件

2.1.1 Controller Manager

• Replication Controller：保证Replication Controller中定义的副本数量与实际运行的pod数量一致。

• Node Controller：管理维护Node，定期检查Node节点的健康状态，标识出失效和未失效的Node节点。

• Namespace Controller：管理维护Namespace，定期清理无效的Namespace，包括Namespace下的API对象，例如pod和service等

• Service Controller：管理维护Service，提供负载以及服务代理。

• Endpoints Controller：管理维护Endpoints，即维护关联service和pod的对应关系，其对应关系通过Label来进行关联的

• Service Account Controller：管理维护Service Account，为每个Namespace创建默认的Service Account，同时为Service Account创建Service Account Secret。

• Persistent Volume Controller：持久化数据控制器，用来部署有状态服务

• Deamon Set Controller：让每一个Node节点都运行相同的服务

• Deployment Controller：无状态服务部署控制器

• Job Controller：管理维护Job，为Job创建一次性任务Pod，保证完成Job指定完成的任务数目。

• Pod Autoscaler Controller：实现pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行pod的伸缩动作。

k8s其实就是两套cs架构组成

apiserver是server的时候，kubectl,kubproxy等都是client
etcd是server的时候，apiserver是client