【技术中台干货】kubernetes in 5 mins

在第一章节我们熟悉了Docker的技术知识，那么需要考虑的是如何管理这些Docker容器呢？在众多容器编排管理平台中kubernetes无疑是最主流的。Kubernetes起源于谷歌的borg系统。Borg是谷歌内部的容器管理系统，它主要的目的是实现资源管理的自动化以及有效的利用平台资源。kubernetes的设计理念多源于borg系统，并且将borg中精华的部分提取出来。我们先来看一下kubernetes的基础架构，如下所示：

　　先从整体入手，具体的组件将在第三章节详细讲解。在kubernetes中服务器的角色可以分为controller plane和nodes两种。Controller plane也可以理解为kubernetes的master节点，最核心的组件就是kube-apiserver，它是kubernetes集群的大脑负责管理整个集群。而node节点是kubernetes中运行容器实例的部分，它上面跑的是真正运行的Docker容器和镜像。

　　首先需要提到的是kubernetes的设计理念，也是它的核心概念：声明式的API.声明式设计与命令式设计是不同的，命令式的设计强调的是怎么做，比如server端会发生命令叫client端执行哪项工作，然后收集执行结果。而声明式设计更强调的是一种“期望”，server发出一份“期望”，client端会根据这份“期望”自行进行执行任务工作。在理解声明式和命令式的区别时，大家可以想象命令式是基层领导，他在安排下属工作的时候都要清楚每个员工的工作内容，安排好每个员工的工作。而命令式更像高层领导，他关心是公司的发展方向，指定发展目标和期望。如果随着管理人数的越来越多，命令式的模式就会显得力不从心了，管理端的压力会越来越大，这也是声明式的优势。

　　在kubernetes中使用声明式的API去描述整个集群的状态，运行在集群中的实体称之为对象。Kubernetes集群的期望状态是指整个集群工作负载的状态描述，包括哪些容器运行状态、集群的资源使用情况、重启和回滚策略等。而这些状态的维护都是通过操作kubernetes API来实现的，API会将数据信息存储在etcd中做持久化。那么我们该怎么声明来告诉kubernetes API完成工作呢？可以通过yaml格式来写一段描述，如下：

　　这份yaml的主要字段有apiVersion是说明需要调用kubernetes API的版本、kind是说明这个资源类型是Deployment、replicas是指期望2个副本数、而spec字段中主要声明容器的镜像名称和开放端口等。我们通过这个yaml文件告诉kubernetes来“期望”创建这个类型的资源，kubernetes会通过各个组件的调用来实现我们的声明。

　　在kubernetes的API设计原则有以下几点：

　　API是遵循RESTful接口规则的并且应该是声明式的，对于大规模的集群环境这种设计可以保证集群的稳定性和减轻master节点的工作负载，同时隐藏技术细节将API对象以对应的名称暴露给使用者来描述一个集群期望的状态。

　　API的对象是从真正的实际工作场景中提炼出来的，满足集群建设的现实需求。比如Service、Ingress、Volume等，它解决了容器在集群中的服务发现、对外访问、存储挂载等，可以支撑各自复杂的业务场景，同时它们也是高内聚、松耦合的，符合云原生设计规范。

　　API的数据会被保存在etcd存储系统中，同时使用各种控制器来获取kubernetes API中的对象并实现相关的容器管理工作，控制逻辑应该只依赖当前状态，这是为了整个集群的稳定可靠，在设计控制逻辑时尽量避免复杂状态机制和逻辑。

　　Kubernetes 的基础组件介绍

　　在kubernetes中首先要说的是Pod，Pod是kubernetes中最小的单位，一个容器有时候并不能对应复杂的应用，所以kubernetes提出了Pod这个概念，它是把应用的容器、存储资源和独立的网络地址等资源打包在一起，作为集群中的最小单位，可以看到kubernetes从设计之初就是站着业务应用的视角上的，它能够在应用中的多个容器之间进行协调工作，构建一个高内聚的服务单元，方便集群中业务应用的发布和运行。

　　Pod在kubernetes集群中是如何运行的，都会经历那些基础组件呢？我们回个头来再来看kubernetes的基础架构图，如下所示：

　　kube-apiserver是整个kubernetes的控制入口，上一章节已经有比较详细的说明API的设计原则和特性，这里就不过多的赘述。

　　kubectl是客户端的命令行工具，我们编写的yaml声明文件会经过kubectl格式化发送给kube-apiserver，api会解释声明并存储到etcd中。

　　kube-controller-manager是负责kubernetes中的控制逻辑，维护集群中运行组件的整个生命周期，包括节点的状态、Pod的个数等。

　　kube-scheduler是负责节点的资源管理和分配，在kube-apiserver中创建的Pod，scheduler会根据集群的资源使用情况分配到对应的节点上，并且更新pod的最新状态。

　　以上三个组件是运行在kubernetes control plane上，也就是master节点上，它们是整个集群的核心组件。

　　etcd是集群中的API信息的持久化存储，它只会和kube-apiserver通信，API将接受的信息存储到etcd中，etcd在生产环境中建议使用多节点部署（N+1），它符合Raft一致性算法。

　　kube-porxy是运行在Node节点上的，它负责Pod的网络代理和负载均衡，通过它创建的访问规则可以允许集群内部或外部与Pod通信。

　　kubelet也是运行在Node节点上的，它会真正和容器进行关联，维护和操作容器同时接收容器的运行状态，将信息反馈给kube-apiserver.它作为每个Node节点的agent，接受节点上Pod任务和管理容器和维护整个生命周期。

　　整个Pod的创建流程大概如下：

　　1）我们先编写对应的yaml文件，通过kubectl提交Pod的创建任务，kube-apiserver与kubectl交互相应请求，通过认证和授权（rbac授权在以后的文章中可以详细讲解）完成Deployment资源的初始化，并将创建的信息存储在etcd中做持久化。

　　2）kube-controller-manager通过watch机制，检测kube-apiserver的状态变化，当发现有新的Deployment资源类型的时候，将任务加入到工作队列里，通过各个控制循环，发现新的Deployment资源没有关联表述的Pod和Replicaset，启用对应的replicaset controller创建Pod，同时更新kube-apiserver信息状态。

　　3）kube-scheduler也是通过watch监听最新的集群状态，当发现有新的Pod信息时，它会到整个集群的Node节点进行打分和过滤，通过binding的方式将Pod绑定到对应Node主机上，同时最新的状态也会同步到kube-apiserver上。

　　4）kubelet组件通过与kube-apiserver通信获取相关的信息，当发现有信息声明绑定关系时，会通过cni进行主机上的容器创建操作，新建Pod后也会将信息发送到kube-apiserver上，kube-apiserver接受的信息都会存储到etcd中。

　　5）kube-proxy也会和kubelet类似，在接收到kube-apiserver端有Service的创建任务会在Node节点上创建相关的网络规则和负载均衡策略。

　　以上就是Pod创建的大概流程，希望大家能够了解并能够在kubernetes的使用中有所体会。

　　如何在 Kubernetes 发布你的应用

　　最后的章节我们来完成在kubernetes集群中发布应用的工作，可以使用之前的创建nginx的yaml声明文件来完成我们的发布任务。

　　首先如何创建一个kubernetes集群，我们可以通过kubernetes官网上的交互式教程来完成，官网已经为我们创建好了一个集群，链接地址如下：

https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/

　　我们可以通过kubectl命令交互来操作kubernetes集群，比如kubectl get node来查看Node节点的信息，如下：

　　我们编写一份nignx的yaml声明文件，如下：

　　然后我们通过kubectl apply -f nginx.yaml来创建这个Deployment资源类型，kubernetes API会根据我们的声明完成相关的工作内容。

　　同时我们可以通过kubectl describe命令查看每个Pod的运行状态和信息。

　　这样一个应用已经在kubernetes中运行起来了，是不是很简单啊？kubernetes in 5 mins先暂时到这里，希望大家通过我的描述能了解Docker和kubernetes的全貌并对今后的kubernetes之旅有帮助。对于一个应用在kubernetes中是如何服务发现的、容器之前的网络架构、容器的对外访问、rbac授权等等内容如果大家也感兴趣，希望留言给我，我会整理好相关的内容和资料在后续的文章中发布出来，今天就到这里，谢谢大家。