k8s系统架构图（二）

一个K8S集群由两部分构成 master节点和node节点。

master节点主要负责集群的控制，对pod进行调度，已经令牌管理等等功能。

node节点主要是负责干活，启动容器、管理容器。

master节点和node节点一般不要部署在一台机器上。

上面这个架构图，举例是一个master节点和2个node节点。但实际生产上，从高可用考虑，是需要部署多个master节点的。

将这张图抽象一下，大约是这个样子

master节点中又有很多组件

主要的是：

Api Server：对外暴露K8S的api接口，是外界进行资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；就是监视新创建的 Pod，如果没有分配节点，就选择一个节点供他们运行，这就是pod的调度

controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等，它们是处理集群中常规任务的后台线程

etcd：kubernetes的后端数据库，k/v方式存储，所有的k8s集群数据都存放在此处。保存了整个集群的状态

其中有kube-scheduler和kube-controller-manager两个组件是有leader选举的，这个选举机制是k8s对于这两个组件的高可用保障。

apiserver是可以水平扩展的。

Node节点的组件：

 

kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；

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

fluentd 是一个守护进程，它有助于提供集群层面日志 集群层面的日志

再来一张综合起来的图：

解释图中的几个词：

CNI、CRI和CSI都是K8S的开放接口

Kubernetes作为云原生应用的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下接口，可以分别对接不同的后端，来实现自己的业务逻辑：

CRI（Container Runtime Interface）：容器运行时接口，提供计算资源CNI（Container Network Interface）：容器网络接口，提供网络资源CSI（Container Storage Interface）：容器存储接口，提供存储资源

这几个属于进阶内容，新手先不用管。

另外附一个参考高可用部署架构：

在每台node节点上安装nginx，nginx通过内部的负载均衡将node节点上需要通过访问master，kube-apiserver组件的请求，反代到两台k8s-master节点上，这样就可以实现master节点的高可用，当任意一台master节点宕机后，也可以通过nginx负载均衡放文档另一个master节点上

---

//来自百家号：IT有意思