kubernetes-总体概述和架构详解

1、Kubernetes是什么

Kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。经过Kubernetes可以进行应用的自动化部署和扩缩容。在Kubernetes中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。Kubernetes积累了做为Google生产环境运行工做负载15年的经验，并吸取了来自于社区的最佳想法和实践。Kubernetes通过这几年的快速发展，造成了一个大的生态环境，Google在2014年将Kubernetes做为开源项目。Kubernetes的关键特性包括：

自动化装箱：在不牺牲可用性的条件下，基于容器对资源的要求和约束自动部署容器。同时，为了提升利用率和节省更多资源，将关键和最佳工做量结合在一块儿。

自愈能力：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行从新部署和从新调度；当容器未经过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。

水平扩容：经过简单的命令、用户界面或基于CPU的使用状况，可以对应用进行扩容和缩容。

服务发现和负载均衡：开发者不须要使用额外的服务发现机制，就可以基于Kubernetes进行服务发现和负载均衡。

自动发布和回滚：Kubernetes可以程序化的发布应用和相关的配置。若是发布有问题，Kubernetes将可以回归发生的变动。

保密和配置管理：在不须要从新构建镜像的状况下，能够部署和更新保密和应用配置。

存储编排：自动挂接存储系统，这些存储系统能够来自于本地、公共云提供商（例如：GCP和AWS）、网络存储(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)。

2、Kubernetes的总体架构 

 

Kubernetes属于主从分布式架构，主要由Master Node和Worker Node组成，以及包括客户端命令行工具kubectl和其它附加项。

Master Node：做为控制节点，对集群进行调度管理；Master Node由API Server、Scheduler、Cluster State Store（etcd）和Controller Manger Server所组成；

Worker Node：做为真正的工做节点，运行业务应用的容器；Worker Node包含kubelet、kube proxy和Container Runtime；

kubectl：用于经过命令行与API Server进行交互，而对Kubernetes进行操做，实如今集群中进行各类资源的增删改查等操做；

Add-on：是对Kubernetes核心功能的扩展，例如增长网络和网络策略等能力。

1 Master Node（主节点）

1.1 API Server（API服务器）

API Server主要用来处理REST的操做，确保它们生效，并执行相关业务逻辑，以及更新etcd（或者其余存储）中的相关对象。API Server是全部REST命令的入口，它的相关结果状态将被保存在etcd（或其余存储）中。API Server的基本功能包括：

REST语义，监控，持久化和一致性保证，API 版本控制，放弃和生效
内置准入控制语义，同步准入控制钩子，以及异步资源初始化
API注册和发现
另外，API Server也做为集群的网关。默认状况，客户端经过API Server对集群进行访问，客户端须要经过认证，并使用API Server做为访问Node和Pod（以及service）的堡垒和代理/通道。

1.2 Cluster state store（集群状态存储）

Kubernetes默认使用etcd做为集群总体存储，固然也可使用其它的技术。etcd是一个简单的、分布式的、一致的key-value存储，主要被用来共享配置和服务发现。etcd提供了一个CRUD操做的REST API，以及提供了做为注册的接口，以监控指定的Node。集群的全部状态都存储在etcd实例中，并具备监控的能力，所以当etcd中的信息发生变化时，就可以快速的通知集群中相关的组件。

1.3 Controller-Manager Server（控制管理服务器）

Controller-Manager Serve用于执行大部分的集群层次的功能，它既执行生命周期功能(例如：命名空间建立和生命周期、事件垃圾收集、已终止垃圾收集、级联删除垃圾收集、node垃圾收集)，也执行API业务逻辑（例如：pod的弹性扩容）。控制管理提供自愈能力、扩容、应用生命周期管理、服务发现、路由、服务绑定和提供。Kubernetes默认提供Replication Controller、Node Controller、Namespace Controller、Service Controller、Endpoints Controller、Persistent Controller、DaemonSet Controller等控制器。

1.4 Scheduler（调度器）

scheduler组件为容器自动选择运行的主机。依据请求资源的可用性，服务请求的质量等约束条件，scheduler监控未绑定的pod，并将其绑定至特定的node节点。Kubernetes也支持用户本身提供的调度器，Scheduler负责根据调度策略自动将Pod部署到合适Node中，调度策略分为预选策略和优选策略，Pod的整个调度过程分为两步：

1）预选Node：遍历集群中全部的Node，按照具体的预选策略筛选出符合要求的Node列表。如没有Node符合预选策略规则，该Pod就会被挂起，直到集群中出现符合要求的Node。

2）优选Node：预选Node列表的基础上，按照优选策略为待选的Node进行打分和排序，从中获取最优Node。

2 Worker Node（从节点）

2.1 Kubelet

Kubelet是Kubernetes中最主要的控制器，维护容器的生命周期，并管理CSI（Container Storage Interface）和CNI（Conteinre Network Interface）。它是Pod和Node API的主要实现者，Kubelet负责驱动容器执行层。在Kubernetes中，应用容器彼此是隔离的，而且与运行其的主机也是隔离的，这是对应用进行独立解耦管理的关键点。

在Kubernets中，Pod做为基本的执行单元，它能够拥有多个容器和存储数据卷，可以方便在每一个容器中打包一个单一的应用，从而解耦了应用构建时和部署时的所关心的事项，已经可以方便在物理机/虚拟机之间进行迁移。API准入控制能够拒绝或者Pod，或者为Pod添加额外的调度约束，可是Kubelet才是Pod是否可以运行在特定Node上的最终裁决者，而不是scheduler或者DaemonSet。kubelet默认状况使用cAdvisor进行资源监控。负责管理Pod、容器、镜像、数据卷等，实现集群对节点的管理，并将容器的运行状态汇报给Kubernetes API Server。

2.2 Container Runtime（容器运行时）

每个Node都会运行一个Container Runtime，其负责下载镜像和运行容器。Kubernetes自己并不停容器运行时环境，但提供了接口，能够插入所选择的容器运行时环境。kubelet使用Unix socket之上的gRPC框架与容器运行时进行通讯，kubelet做为客户端，而CRI shim做为服务器。

protocol buffers API提供两个gRPC服务，ImageService和RuntimeService。ImageService提供拉取、查看、和移除镜像的RPC。RuntimeSerivce则提供管理Pods和容器生命周期管理的RPC，以及与容器进行交互(exec/attach/port-forward)。容器运行时可以同时管理镜像和容器（例如：Docker和Rkt），而且能够经过同一个套接字提供这两种服务。在Kubelet中，这个套接字经过–container-runtime-endpoint和–image-service-endpoint字段进行设置。Kubernetes CRI支持的容器运行时包括docker、rkt、cri-o、frankti、kata-containers和clear-containers等。

2.3 kube proxy

基于一种公共访问策略（例如：负载均衡），服务提供了一种访问一群pod的途径。此方式经过建立一个虚拟的IP来实现，客户端可以访问此IP，并可以将服务透明的代理至Pod。每个Node都会运行一个kube-proxy，kube proxy经过iptables规则引导访问至服务IP，并将重定向至正确的后端应用，经过这种方式kube-proxy提供了一个高可用的负载均衡解决方案。服务发现主要经过DNS实现。

在Kubernetes中，kube proxy负责为Pod建立代理服务；引到访问至服务；并实现服务到Pod的路由和转发，以及经过应用的负载均衡。

3 kubectl

kubectl是Kubernetes集群的命令行接口。运行kubectl命令的语法以下所示

$ kubectl [command] [TYPE] [NAME] [flags]
这里的command，TYPE、NAME和flags为：

comand：指定要对资源执行的操做，例如create、get、describe和delete
TYPE：指定资源类型，资源类型是大小写敏感的，开发者可以以单数、复数和缩略的形式。例如：

$ kubectl get pod pod1
$ kubectl get pods pod1
$ kubectl get po pod1
NAME：指定资源的名称，名称也大小写敏感的。若是省略名称，则会显示全部的资源，例如:

$kubectl get pods
flags：指定可选的参数。例如，可使用-s或者–server参数指定Kubernetes API server的地址和端口。
另外，能够经过运行kubectl help命令获取更多的信息。

4 add-one(附加项和其余依赖)

在Kunbernetes中能够以附加项的方式扩展Kubernetes的功能，目前主要有网络、服务发现和可视化这三大类的附加项，下面是可用的一些附加项：

4.1 网络和网络策略

ACI 经过与Cisco ACI集成的容器网络和网络安全。
Calico 是一个安全的3层网络和网络策略提供者。
Canal 联合Fannel和Calico，经过网络和网络侧。
Cilium 是一个3层网络和网络侧插件，它可以透明的增强HTTP/API/L7 策略。其即支持路由，也支持overlay/encapsultion模式。
Flannel 是一个overlay的网络提供者。

4.2 服务发现

CoreDNS 是一个灵活的，可扩展的DNS服务器，它可以做为Pod集群内的DNS进行安装。

Ingress 提供基于Http协议的路由转发机制。

4.3 可视化&控制

Dashboard 是Kubernetes的web用户界面。

3、kubenetes工做原理

1 工做原理

1 准备包含应用程序的Deployment的yml文件，而后经过kubectl客户端工具发送给ApiServer。

2 ApiServer接收到客户端的请求并将资源内容存储到数据库(etcd)中。

3 Controller组件(包括scheduler、replication、endpoint)监控资源变化并做出反应。

4 ReplicaSet检查数据库变化，建立指望数量的pod实例。

5 Scheduler再次检查数据库变化，发现还没有被分配到具体执行节点(node)的Pod，而后根据一组相关规则将pod分配到能够运行它们的节点上，并更新数据库，记录pod分配状况。

6 Kubelete监控数据库变化，管理后续pod的生命周期，发现被分配到它所在的节点上运行的那些pod。若是找到新pod，则会在该节点上运行这个新pod。

另：kuberproxy运行在集群各个主机上，管理网络通讯，如服务发现、负载均衡。当有数据发送到主机时，将其路由到正确的pod或容器。对于从主机上发出的数据，它能够基于请求地址发现远程服务器，并将数据正确路由，在某些状况下会使用轮循调度算法(Round-robin)将请求发送到集群中的多个实例。

2 pod建立的时序图

如下是pod建立的时序图，此典型的建立过程以帮助理解k8s的工做原理：

pod建立的时序图，此典型的建立过程以帮助理解k8s的工做原理：

1 用户提交建立Pod的请求，能够经过API Server的REST API ，也可用Kubectl命令行工具，支持Json和Yaml两种格式；

2 API Server 处理用户请求，存储Pod数据到Etcd；

3 Schedule经过和 API Server的watch机制，查看到新的pod，尝试为Pod绑定Node；

4 过滤主机：调度器用一组规则过滤掉不符合要求的主机，好比Pod指定了所须要的资源，那么就要过滤掉资源不够的主机；

5 主机打分：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些总体优化策略，好比把一个Replication Controller的副本分布到不一样的主机上，使用最低负载的主机等；

6 选择主机：选择打分最高的主机，进行binding操做，结果存储到Etcd中；

7 kubelet根据调度结果执行Pod建立操做： 绑定成功后，会启动container, docker run, scheduler会调用API Server的API在etcd中建立一个bound pod对象，描述在一个工做节点上绑定运行的全部pod信息。运行在每一个工做节点上的kubelet也会按期与etcd同步bound pod信息，一旦发现应该在该工做节点上运行的bound pod对象没有更新，则调用Docker API建立并启动pod内的容器。

 

————————————————版权声明：本文为CSDN博主「星光001」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。原文连接：https://blog.csdn.net/u014042372/article/details/80573213