K8s-k8s架构

本文章属个人学习整理的对应笔记，学习内容来尚硅谷的培训课，有兴趣的同学可以跳转下方链接

【云原生Java架构师的第一课K8s+Docker+KubeSphere+DevOps】https://www.bilibili.com/video/BV13Q4y1C7hS?p=71&vd_source=08192e8d3b82bf20dfe6807a2901dd9e

---

1工作方式

kubernetes cluster = N master node + N worker node

master node是管理节点，worker node是工作节点

2.构架图

1.Master节点

Master节点包含API Server，Scheduler，Controller manager，etcd几个组件

1.AP Server（秘书部）：

提供其他模块之江的数据交互通信的枢纽，其他模块通过API Server查询或修改数据，只有API Server才直接和etcd进行交互

kubernetes集群中，API Server扮演着通信枢纽的位置。API Server不仅负责和etc交互，并对外提供统一的API调用入口，所有的交互都是以API Server为核心的。API Server 提供了以下的功能：

a.整个集群管理的API接口：

所有对集群进行的查询和管理都要通过API来进行。集群内部的组件也是通过API Server更新和同步数据到etcd中

b.集群内部各个模块之间通信的枢纽：

所有模块之前并不会之间相互调用，而是通过和API Server打交道来完成自己那部分工作

c.集群安全控制：

API Server提供的验证和授权保证了整个集群的安全

d.数据中心枢纽：

API Server负责和etcd交互存放集群用到的运行数据

2.scheduler（调度者）

scheduler负责节点资源管理，接收来自kube-apiserver创建pod的任务，收到任务后它会检索出所有符合该pod要求的node节点（通过预选策略和优选策略），喀什执行pod调度逻辑，调度成功后将pod绑定到目标节点上。

3.controller manager（决策者）

controller-manager作为k8s集群的管理控制中心，负责集群内node，namespace，service，token，replication等资源对象的管理，使集群内的资源对象维持在预期的工作状态。

每一个controller通过api-server提供的restful接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复为预期的工作状态，常见的controller有namespace controller，node controller，service controller，service controller，service account controller，token

4.etcd（资料库）

etcd在kubernetes集群是用来存放数据并通知变动的。

kubernetes中没有用到数据库，它把关键数据都存放在etc中，这使kubernetes的整体结构变得非常简单。在kubernetes中，数据是随时发生变化的，比如说用户提交了新任务，增加了新的node，node宕机了，容器死掉了等等，都会出啊发状态数据的变更。状态数据变更之后，master上的kube-scheduler和kube-controller-manager，就会重新安排工作，他们的工作安排结果也是数据。这些变化，都需要即使通知给每个组将。etcd有一个特别昊的特性，可以调用它的api监听其中的数据，一旦数据发送变化了，就会收到通知。有了这个特征之后，kubernetes中的每个组件只需要监听etcd中数据，就可以直到自己应该做啥了

2.Node节点

Node节点包括kubelet，kube-proxy模块和pod对象

1.pod:

pod是kubernetes是基本的操作单元。一个pod代表着集群中运行的一个进程，它内部封装了一个或多个精密相关的容器

2.kubelet（厂长）：

运行在每个计算节点上

a.kubelet组件通过api-server提供的接口监测到kube-scheduler产生的pod绑定事件，然后从etcd获取pod清单，下载镜像并启动容器

b.同时监控分配给Node节点的pods，周期性获取容器状态，再通过api-server通知各个组件

3.kube-proxy（门卫大爷）

 首先k8s里所有资源都存在etcd中，各个组件通过API Server的接口进行访问etcd来获取资源信息，kube-proxy会作为daemon（守护经常）跑在每个节点上通过watch的方式监控着etcd中关于pod的最新状态信息，它一旦检查到一个pod资源被删除了或新建或ip变化等一系列变化，它就理解将这些变动，反应在iptables或ipvs规则长，以便之后，再有请求发送到API  Server时，Service可以通过ipvs罪行的规则将请求的分发到pod上。

kube-proxy负责制定数据包的转发策略，并以守护进程的模式对各个节点的pod信息实时监控并更新转发规则，service收到请求后会根据kube-proxy制定好的策略来进行情趣的转发，从而实现负载均衡

3.总结

1.etcd保存了整个集群的状态；

2.API Server提供了资源操作的唯一入口，并提供认证，授权，访问控制，API注册和发现等机制；

3.controller manager负责维护集群的状态，比如故障检测，自动扩展，滚动更新等

4.scheduler负责资源的调度，按照预定的调度策略将pod调度到相应的机器上

5.kubelet负责维护容器的生命周期，同时也负责volume（VI）和网络（CNI）的管理

6.kube-proxy负责为service提供cluster内部的服务发现和负载均衡

---

 我们今天的内容到这就结束了，今天的内容到这里就结束了，如果有啥不会的朋友记得论坛里面提问哈~

如果朋友你感觉文章的内容对你有帮助，可以点赞，关注文章和专栏以及关注我哈，嘿嘿嘿我会定期更新文章的，谢谢朋友你的支持哈