Kubernetes架构

Kubernetes的架构图如下图所示：

Kubernetes架构 - 图1

一个Kubernetes集群由一组被称作节点的机器组成，这些节点上运行Kubernetes所管理的容器化应用程序，一个Kubernetes集群至少应该有一个工作节点

集群中需要有一台服务器作为Master，负责管理整个集群，Master是集群的网关和中枢

负责诸如为用户和客户端暴露API、跟踪其他服务器的健康状态、以最优方式调度工作负载，以及编排其他组件之间的通信任务，是客户端与集群之间的核心联络点，并负载着Kubernetes系统的大多数集中式管控逻辑

单个Master节点就可以完成所有的功能，但是出于冗余及负载均衡等目的，生产环境中通常需要协同部署多个Master节点

Node是Kubernetes集群的工作节点，负责接收来自Master的工作指令从而响应地创建或销毁Pod对象，以及完成调整网络规则以合理地路由和转发流量等工作

理论上讲，Node可以是任何形式的计算设备，不过Master会统一将其抽象为Node对象进行管理

Kubernetes将所有Node资源集结于一处形成一台更加强大的服务器，在用户将应用部署于其上时，Master会使用调度算法将其自动指派至某个特定的Node运行
在Node加入集群或从集群中移除时，Master也会按需重新编排影响到的Pod，于是用户无须关心其应用究竟运行在何处

控制平面组件

Kubernetes的Master包含四个主要的组件：kube-apiserver、kube-controller-manager、kube-scheduler 以及 etcd我们一般也将Master节点称为控制平面

kube-apiserver是用来处理API操作的，Kubernetes中所有的组件都会和API Server进行连接，组件与组件之间一般不进行独立的连接，都依赖于API Server进行消息的传送

kube-apiserver相当于是集群的网关，是通信中枢

kube-controller-manager是控制器管理器，用来完成对集群状态的管理，它通过apiserver监控整个集群的状态来确保每个资源都处于期望的状态

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行

例如如下几个控制器的工作：

自Kubernetes1.6版本后又出现了一个新的控制器，即云控制器管理器，其中运行着与基础云提供商交互的控制器

Kubernetes架构 - 图2

是k8s的调度器，该组件监视那些新创建的未指定运行节点的Pod，并分配Pod在某个节点上运行

调度策略考虑的因素包括单个Pod和Pod集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰等

当kube-apiserver确认Pod对象的创建请求之后，便需要由kube-scheduler根据集群内各节点的可用资源状态、以及要运行的容器的资源需求来做出调度决策

是k8s的后台数据库，是一个兼具一致性和高可用的键值数据库，持久存储着整个集群所有资源状态信息

Kubernetes的Node包含三个主要的组件：kubelet、kube-proxy、Container Runtime我们一般也将Node节点称为工作平面

kubelet是运行在每个工作节点上最重要的组件，它负责管理节点上的pod，当在Master上执行创建、删除对象时，kubelet就会执行从kube-apiserver下达的指令，并会定期想Master汇报节点资源的使用情况

kube-proxy维护节点上的网络规则，实现了Kubernetes Service概念的一部分

它的作用是为Service资源对象生成iptables或者ipvs规则，使发往Service的流量负载均衡到正确的后端Pod

kube-proxy其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service

Kubernetes架构 - 图3

简而言之就是容器，，Kubernetes 支持多种容器: Docker、containerd、cri-o、 rktlet以及任何实现Kubernetes CRI的容器，需要在Node节点安装runtime作为k8s部署容器的运行环境，目前主流的就是Docker

是一个命令行工具，它会调用API Server发送请求写入状态到etcd，或者在etcd中进行查询操作

通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署

kubectl命令的详细介绍参照文章《Kubernetes资源管理》