k8s架构基础介绍

kubernetes架构

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。
Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。
每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。
Kubernetes主要由以下几个核心组件组成：

kubectl：k8s是命令行端，用来发送客户的操作指令。

master节点

1. API server[资源操作入口]：是k8s集群的前端接口，各种各样客户端工具以及k8s的其他组件可以通过它管理k8s集群的各种资源。它提供了HTTP/HTTPS RESTful API,即K8S API。

• 提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，只有API Server与存储通信，其他模块通过API Server访问集群状态。

第一，是为了保证集群状态访问的安全。

第二，是为了隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。

• 作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。对相关的资源数据“全量查询”+“变化监听”，实时完成相关的业务功能。

2. Scheduler[集群分发调度器]：负责决定将Pod放在哪个Node上运行。在调度时，会充分考虑集群的拓扑结构，当前各个节点的负载情况，以及应对高可用、性能、数据亲和性和需求。

1.Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。

2.实时监测Kubernetes集群中未分发和已分发的所有运行的Pod。

3.Scheduler也监测Minion节点信息，由于会频繁查找Minion节点，Scheduler会缓存一份最新的信息在本地。

4.最后，Scheduler在分发Pod到指定的Minion节点后，会把Pod相关的信息Binding写回API Server。

4. Controller Manager[内部管理控制中心]：负责管理集群的各种资源，保证资源处于预期的状态。它由多种Controller组成，包括Replication Controller、Endpoints Controller、Namespace Controller、Serviceaccounts Controller等。

实现集群故障检测和恢复的自动化工作，负责执行各种控制器，主要有：

1.endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。

2.replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

5. Etcd：负责保存k8s集群的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速的通知k8s相关组件。[（第三方组件）它有可替换方案。Consul、zookeeper]()

6. Pod: k8s集群的最小组成单位。一个Pod内，可以运行一个或多个容器。大多数情况下，一个Pod内只有一个Container容器。

7. Flanner：是k8s集群网络，可以保证Pod的跨主机通信。也有替换方案。

[root@master ~]# kubectl get pod --all-namespaces
//查看pod信息

[root@master ~]# kubectl get pod --all-namespaces -o wide
//显示pod的节点信息

Node节点

Kubelet[节点上的Pod管家]：它是Node的agent(代理)，当Scheduler确定某 个Node上运行Pod之后，会将Pod的具体配置信息发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器，并向Master报告运行状态。

• 负责Node节点上pod的创建、修改、监控、删除等全生命周期的管理
• 定时上报本Node的状态信息给API Server。
• kubelet是Master API Server和Minion之间的桥梁，接收Master API Server分配给它的commands和work，与持久性键值存储etcd、file、server和http进行交互，读取配置信息。
• 具体的工作如下：

设置容器的环境变量、给容器绑定Volume、给容器绑定Port、根据指定的Pod运行一个单一容器、给指定的Pod创建network 容器。

同步Pod的状态、同步Pod的状态、从cAdvisor获取Container info、 pod info、 root info、 machine info。

在容器中运行命令、杀死容器、删除Pod的所有容器。

kube-proxy[负载均衡、路由转发]:负责将访问service的TCP/UDP数据流转发到后端的容器。如果有多个
副本，kube-proxy会实现负载均衡。

• Proxy是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，运行在每个Node上。Proxy提供TCP/UDP sockets的proxy，每创建一种Service，Proxy主要从etcd获取Services和Endpoints的配置信息（也可以从file获取），然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务端口，当外部请求发生时，Proxy会根据Load Balancer将请求分发到后端正确的容器处理。
• Proxy不但解决了同一主宿机相同服务端口冲突的问题，还提供了Service转发服务端口对外提供服务的能力，Proxy后端使用了随机、轮循负载均衡算法。

除了核心组件，还有一些推荐的Add-ons：

kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询

一. 分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示。

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口层：kubectl命令行工具、客户端SDK以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

二. 在K8s中运行一个容器应用

​ 下面通过运行一个容器应用的过程，来一起理解一下K8s组件是如何协作的。

开发者开发一个应用后，打包Docker镜像，上传到Docker registry；然后编写一个yaml部署描述文件，以描述应用的结构和资源需求。开发者通过kubectl（或其它应用），将部署描述文件提交到API server，API server将部署需求更新到etcd。etcd在K8s管理结点中的作用相当于数据库，其它组件提交到API server的数据都存储于etcd。API server非常轻量，并不会直接去创建或管理Pod等资源，在多数场景下甚至不会去主动调用其它的K8s组件发出指令。其它组件通过建立和API server的长连接，监视关心的对象，监视到变化后，执行所负责的操作。

继续我们的启动应用之旅，如图所示，Controller Manager中的控制器监视到新的部署描述后，根据部署描述，创建ReplicaSet、Pod等资源。Scheduler监视到新的Pod资源后，结合集群的资源情况，选定一或多个工作结点运行Pod。工作结点上的Kubelet监视到有Pod被计划在自己的结点后，向Docker等Container runtime发出启动容器的指令，Docker engineer将按照指令从Docker registy拉取镜像，然后启动并运行容器。

三. K8s集群的高可用部署

​ 通过之前的介绍，我们看到K8s可以在多个工作结点上启动并管理容器，下面来学习一下，如何实现管理结点的高可用部署。

上图的K8s高可用部署中有3个管理结点。etcd自身是一个分布式数据存储系统，按照其多实例部署方案，结点只需在启动时知道其它结点的IP和端口号即可组成高可用环境。和通常的应用服务器一样，API Server是无状态的，可以运行任意多个实例，且彼此之间无需互相知道。为了能使kubectl等客户端和Kubelet等组件连接到健康的API Server、减轻单台API Server的压力，需使用基础架构提供的负载均衡器作为多个API Server实例的入口。如上图的部署方法，每个主结点上都运行了一个etcd实例，这样API Server只需连接本地的etcd实例即可，无需再使用负载均衡器作为etcd的入口。

Controller Manager和Scheduler需要修改K8s集群，同时修改时可能引发并发问题。假设两个ReplicaSet Controller同时监视到需创建一个Pod，然后同时进行创建操作，就会创建出两个Pod。K8s为了避免这个问题，一组此类组件的实例将选举出一个leader，仅有leader处于活动状态，其它实例处于待命状态。Controller Manager和Scheduler也可以独立于API server部署，通过负载均衡器连接到多个API server实例。

范例

分析各个组件的作用以及架构工作流程:

1) kubectl发送部署 请求到API server
2) APIserver通知Controller Manager创建一个Deployment资源。
3) Scheduler执行调度任务,将两个副本Pod分发到node01和node02. 上。
4) node01和node02, 上的kubelet在各自节点上创建并运行Pod。

补充

1.应用的配置和当前的状态信息保存在etcd中，执行kubectl get pod时API server会从etcd中读取这些数据。

2.flannel会为每个Pod分配一个IP。 但此时没有创建Service资源，目前kube-proxy还没有参与进来。

运行一个例子（创建一个deployment资源对象<pod控制器>）

[root@master ~]# kubectl run test-web --image=httpd --replicas=2
//创建一个deployment资源对象。

运行完成之后，如果有镜像可直接开启，没有的话需要等待一会儿，node节点要在docker hup上下载

查看一下

[root@master ~]# kubectl get  deployments.或 kubectl get  deploy

[root@master ~]# kubectl get pod

[root@master ~]# kubectl get pod  -o wide
//显示pod的节点信息

如果，node节点没有运行test-web服务，需要在节点上重启一下<systemctl restart kubelet>

如果删除一个pod

[root@master ~]# kubectl delete pod test-web-5b56bdff65-2njqf 

查看一下

[root@master ~]# kubectl get pod -o wide

现在发现容器还存在，因为控制器会自动发现，一旦与之前执行的命令有误差，他会自动补全。

参考：
https://blog.csdn.net/gongxsh00/article/details/79932136
https://www.jianshu.com/p/18edac81c718