【云原生之K8s】 Kubernetes原理
目录
引言
一、K8S的由来
1、公有云类型说明：IAAS，PAAS，SAAS
2、资源管理器的诞生
2.1 MESOS
2.2 Docker Swarm
2.3 Kubernetes
二、为什么需要Kubernetes，它能做什么
三、Kubernetes的特性
四、Kubernetes架构
1、K8S工作流程
2、K8S创建Pod流程
引言
Kubernetes是什么意思？为什么又称作K8S？
Kubernetes的名字来自希腊语，意思是“舵手” 或 “领航员”。K8s是将8个字母“ubernete”替换为“8”的缩写
Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用
一、K8S的由来
1、公有云类型说明：IAAS，PAAS，SAAS
在云计算的概念中，我们可以把公有云分为三个层面，IAAS（基础设施即服务）,PAAS（平台即服务）,SAAS（软件即服务）
-
IAAS：基础设施即服务。
Infrastructure-as-a-Service(IAAS)，国内做的最好的就是阿里云 -
Platform-as-a-Service(PAAS)，某些时候也叫做中间件， PAAS公司在网上提供各种开发和分发应用的解决方案，比如虚拟服务器和操作系统。
一些大的PAAS提供者有Google App Engine,Microsoft Azure，Force.com,Heroku，Engine Yard等
国内做的最好的就是新浪云 -
SAAS：软件即服务。
Software-as-a-Service(SAAS)，列举一些例子：如Google Apps、Dropbox、Salesforce、Cisco WebEx、Concur和GoToMeeting等
做的比较好的是Microsoft Office 365
2、资源管理器的诞生
有了以上这些公有云之后，我们需要对其进行资源管理，那么此时就诞生了资源管理器：MESOS–Docker Swarm–Kubernetes
2.1 MESOS
MESOS：Mesos是Apache旗下的开源分布式资源管理框架，它被称为是分布式系统的内核，后来在twitter得到广泛使用
Twitter也是mesos的最大客户，但是大概在2019年5月份，Twitter 宣布不再使用MESOS，而改用 Kubernetes，至此，Mesos已经是慢慢的被淘汰了
2.2 Docker Swarm
Docker Swarm，是一个非常轻量的群集管理工具，只有几十MB大小
Swarm 是 Docker官方提供的一款集群管理工具，其主要作用是把若干台 Docker 主机抽象为一个整体，并且通过一个入口统一管理这些 Docker 主机上的各种 Docker 资源。
但是Swarm 和 Kubernetes 比较类似，因为更加轻，所以具有的功能也较 kubernetes 更少一些。
大概在2019年7月份，阿里云宣布将Docker Swarm 从选择列表中剔除，这也意味着在不就得将来，Docker Swarm 也会像Mesos一样慢慢被淘汰掉
2.3 Kubernetes
Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用
用于自动部署、扩展和管理容器化（containerized）应用程序的开源系统。
可以理解成K8S是负责自动化运维管理多个容器化程序（比如docker）的集群，是一个生态机器丰富的容器编排框架工具
二、为什么需要Kubernetes，它能做什么
容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
这就是 Kubernetes 来解决这些问题的方法！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
K8S是Google开源的容器集群管理系统，在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 其主要功能如下：
- 使用 Docker 等容器技术对应用程序包装（package）、实例化（instantiate）、运行（run）。
- 以集群的方式运行、管理跨机器的容器。
- 解决 Docker 跨机器容器之间的通讯问题。
- K8S 的自我修复机制使得容器集群总是运行在用户期望的状态。
三、Kubernetes的特性
- 弹性伸缩：使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。
- 自我修复：在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。
- 服务发现和负载均衡：K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。
- 自动发布（默认滚动发布模式）和回滚：K8S采用滚动策略更新应用，一个更新一个Pod，而不是同时删除所有的Pod，如果更新过程中出现问题，将回滚更改，确保升级不收影响业务。
- 集中化配置管理和密钥管理：管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性，并可以将一些常用的配置存储在K8S中，方便应用程序使用。
- 存储编排：支持外挂存储并对外挂存储资源进行编排，挂载外部存储系统，无论是来自本地存储，公有云（如：AWS），还是网络存储（如：NFS、Glusterfs、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。
- 任务批量处理运行：提供一次性任务，定时任务，满足批量数据处理和分析的场景。
k8s解决了裸跑docker的若干痛点：
- 单机使用，无法有效集群
- 随着容器数量的上升，管理成本攀升
- 没有有效的容灾、自愈机制
- 没有预设编排模板，无法实现快速、大规模容器调度
- 没有统一的配置管理中心工具
- 没有容器生命周期的管理工具
- 没有图形化运维管理工具
四、Kubernetes架构
K8S 是属于主从设备模型（Master-Slave 架构），即由 Master 节点负责集群的调度、管理和运维，Slave 节点是集群中的运算工作负载节点。
在 K8S 中，主节点一般被称为 Master 节点，而从节点则被称为 Worker Node 节点，每个 Node 都会被 Master 分配一些工作负载。
Master 组件可以在群集中的任何计算机上运行，但建议 Master 节点占据一个独立的服务器。因为 Master 是整个集群的大脑，如果 Master 所在节点宕机或不可用，那么所有的控制命令都将失效。除了 Master，在 K8S 集群中的其他机器被称为 Worker Node 节点，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上去。
| 组件 | 作用 |
| master节点 | — |
| apiserver | 所有服务的访问入口 |
| controller-manager | 负责根据预设模板创建pod，维持pod等资源的副本期望数目 |
| scheduler | 负责调度pod，通过预选策略、优选策略选择最合适的node节点分配pod |
| etcd | 分布式键值对数据库，负责存储K8S集群的重要信息（持久化） |
| work node节点 | — |
| Kubelet | 跟apiserver通信汇报当前node节点上的资源使用情况和状态，接受apiserver的指令跟容器引擎交互实现容器的生命周期管理 |
| Kube-proxy | 在node节点上实现pod的网络代理，维护网络规则和四层负载均衡规则，负责写入规则到iptables或ipvs实现服务映射访问 |
| 容器运行时docker | 运行容器，负责本机的容器创建和管理工作 |
1、K8S工作流程
首先，运维人员使用kubectl命令行工具向API Server发送请求，API Server接收到请求后会写入到etcd中，API Server会让Controller-manager按照预设的模板去创建pod,Controller-manager通过API Server读取etcd中用户的预设信息，再通过API Server去找Scheduler可以为新创建的pod选择最合适的node节点。scheduler会通过API Server在etcd存储中心根据存储的node节点元信息、剩余资源等，用预选和优选策略选最优的node节点。
scheduler确定node节点后通过API Server交给这个node节点上的kubele进行pod资源的创建，kubele调用容器引擎交互创建pod,同时将pod监控信息通过API Server存储到etcd中。
用户访问时，通过kube-proxy负载、转发，访问相应的pod
决定创建pod清单的是Controller-manager控制器，而kubelet、容器引擎都是干活的
2、K8S创建Pod流程
kubectl创建一个Pod（在提交时，转化为json）
- 首先经过auth认证（鉴权），然后传递给API Server进行处理
- API Server将请求信息提交给etcd
- scheduler和controller-manager会watch（监听）API Server，监听请求
- 在scheduler和controller-manager监听到请求后，scheduler会提交给API Server一个list清单-----》包含的是获取node节点信息。
- 此时API Server就会向etcd获取后端node节点信息，获取到后，被scheduler监听到，然后scheduler进行预选优选进行打分，最后将结果给API Server。
- 此时API Server也会被controller-manager 监听，controller-manager会根据请求创建Pod的配置信息（需求什么控制器），然后把控制器资源给API Server。
- 此时API Server会提交清单给与对应节点的kubelet（代理）。
- kubelet代理通过K8S与容器的接口（例如containerd）进行交互，假设是docker容器，那么此时kubelet就会通过dockershim以及runc接口与docker的守护进程docker-server进行交互，来创建对应的容器，再生成对应的Pod。
- kubelet同时会借助于metric server收集本节点的所有状态信息，然后再提交给API Server。最后API Server会提交list清单给与etcd来存储（最后api-server会将数据维护在etcd中）。
简单版
1、首先kubectl 转化为json后，向api-server 提交创建Pod请求
2、api-server将请求信息记录在etcd中
3、scheduler 监听api-server处理的请求，然后向api-server申请后端节点信息
4、api-server 从etcd中获取后端节点信息后，给与scheduler
5、scheduler 进行预选优选、打分，然后提交结果给api-server
6、controller-manager 监听api-server处理的请求信息，并将所需的控制器资源给与api-server
7、api-server 对接node节点的kubelet
8、kubelet调用资源创建pod，并将统计信息返回给api-server
9、api-server将信息记录在etcd中