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

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

【技术中台干货】kubernetes in 5 mins_第1张图片

  先从整体入手,具体的组件将在第三章节详细讲解。在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 in 5 mins_第2张图片

  在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的基础架构图,如下所示:

【技术中台干货】kubernetes in 5 mins_第3张图片

  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/

【技术中台干货】kubernetes in 5 mins_第4张图片

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

【技术中台干货】kubernetes in 5 mins_第5张图片

  我们编写一份nignx的yaml声明文件,如下:

【技术中台干货】kubernetes in 5 mins_第6张图片

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

【技术中台干货】kubernetes in 5 mins_第7张图片

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

【技术中台干货】kubernetes in 5 mins_第8张图片

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

 

 

你可能感兴趣的:(技术中台,kubernetes,运维)