Kubernetes从零到精通（02-组件架构）

 

目录

一、master节点服务器的组件

kube-apiserver

etcd

kube-controller-manager

kube-scheduler

二、node节点服务器的组件

kubelet

kube-proxy（可选）

容器运行时（Container runtime）

三、插件

dns

cni网络插件

---

       今天我们对Kubernetes的架构做进一步的了解，就像office分成了excel，word等组件一样，Kubernetes也拆分为多个组件，office可以选择自己需要的组件安装，而Kubernetes的这些组件大多都是必须的，每个组件有自己的功能，各个组件之间协作完成任务。我们看下各组件的功能介绍：

一、master节点服务器的组件

kube-apiserver

        公开 Kubernetes HTTP API 的核心组件。提供对Kubernetes各类资源对象的增删改查和watch（资源变更回调通知）等http rest接口，这些接口是集群其他组件之间数据交互和通信的入口，各个组件通过它来知道互相的状态，下一步需要的操作（具体的代码实现，感兴趣可以看源码）。同时，它也是集群管理的api入口，像kubectl，python/go等开发语言的sdk调用，或者自开发的管理工具，都通过和它通信来实现。

etcd

        具备一致性和高可用性的键值存储，用于所有 API 的数据存储，这是一个数据库集群，用来保存数据用的。

kube-controller-manager

        运行控制器来实现 Kubernetes API 的行为。每个controller组件通过定时的调用apiserver提供的list和watch接口，来实时的监控集群中资源的变化，当系统发生故障等，会尝试自动将其状态调整为正常状态，实现故障自愈等功能。

        控制器有许多不同类型。以下是一些例子：

• Node 控制器：负责在节点出现故障时进行通知和响应
• Job 控制器：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
• EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）
• ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount

kube-scheduler

        查找尚未绑定到节点的 Pod，并将每个 Pod 分配给合适的节点。这个组件的侧重点是调度，用户需要创建的pod会在哪些node节点服务器上创建运行，就是它来通过一些调度算法计算出的。简单说，scheduler组件接收controller-manager创建新pod的需求，然后把pod安排到合适的node服务器上，目标node服务器上的kubelet服务会接管后续的工作，进行实际的容器创建管理等。

二、node节点服务器的组件

kubelet

        确保 Pod 及其容器正常运行。如上面所提到的，与scheduler配合，管理pod和pod中的容器。另外，每个kubelet进程会定时向apiserver汇报本node节点资源使用情况，并通过cAdvisor监控容器和node资源。而apiserver接收到信息后，会把数据写入etcd数据库。

kube-proxy（可选）

        维护节点上的网络规则以实现 Service 的功能。类似于一个service的透明代理和负载均衡器，核心功能就是把对service的访问请求转发到对应的多个pod上。这个组件采用的代理机制从最开始的类似haproxy，改为基于iptables的委托代理，到最新的linux专用ipvs代理，性能和稳定性得到了极大提升。

        如果我们使用网络插件为 Service 实现本身的数据包转发， 并提供与 kube-proxy 等效的行为，那么我们不需要在集群中的节点上运行 kube-proxy。

容器运行时（Container runtime）

        负责运行容器的软件，这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

        就像运行docker镜像要先安装docker软件一样，容器运行时是Kubernetes最基本的软件。

三、插件

        插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能（就是说插件可以通过Kubernetes命令行等方式安装）。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

dns

        几乎所有 Kubernetes 集群都应该有集群 DNS，它为 Kubernetes 服务提供 DNS 记录。这里简单理解下：单纯的ip+端口方式，给应用服务（尤其是微服务）之间的互相调用带来了麻烦，而且因为Kubernetes的动态扩缩容和故障自愈等功能，以及服务迁移的需要，不能保证ip+端口一直保持不变。所以dns服务几乎是Kubernetes的必选插件，目前流行的dns插件如CoreDNS。

cni网络插件

        网络插件 是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信，目前流行的如Calico网络插件。

        以上是Kubernetes架构的介绍，其中提到了一些还没有接触过的名词，如Pod，Service，DaemonSet，Deployment，Job，ServiceAccount等，这些都是Kubernetes为了实现自动化调度等功能定义的资源类型，用户使用配置文件或者kubectl工具命令行自定义这些资源（简单说就是给apiserver可以接受的、预制的一系列参数和接口赋值），Kubernetes就能实现我们的需求。下一章节我们开始介绍这些资源对象。