# Kubernetes组件

参考文档: Kubernetes Components (opens new window)

本文档描述了 Kubernetes 的主要组件。

# Master组件

Master组件是集群的控制平台(control plane):

  • master 组件负责集群中的全局决策(例如,调度)
  • master 组件探测并响应集群事件(例如,当 Deployment 的实际 Pod 副本数未达到 replicas 字段的规定时,启动一个新的 Pod)

Master组件可以运行于集群中的任何机器上。但是,为了简洁性,通常在同一台机器上运行所有的 master 组件,且不在此机器上运行用户的容器。参考 安装Kubernetes高可用

# kube-apiserver

此 master 组件提供 Kubernetes API。这是Kubernetes控制平台的前端(front-end),可以水平扩展(通过部署更多的实例以达到性能要求)。kubectl / kubernetes dashboard / kuboard 等Kubernetes管理工具就是通过 kubernetes API 实现对 Kubernetes 集群的管理。

# etcd

支持一致性和高可用的名值对存储组件,Kubernetes集群的所有配置信息都存储在 etcd 中。请确保您 备份 (opens new window) 了 etcd 的数据。关于 etcd 的更多信息,可参考 etcd 官方文档 (opens new window)

# kube-scheduler

此 master 组件监控所有新创建尚未分配到节点上的 Pod,并且自动选择为 Pod 选择一个合适的节点去运行。

影响调度的因素有:

  • 单个或多个 Pod 的资源需求
  • 硬件、软件、策略的限制
  • 亲和与反亲和(affinity and anti-affinity)的约定
  • 数据本地化要求
  • 工作负载间的相互作用

# kube-controller-manager

此 master 组件运行了所有的控制器

逻辑上来说,每一个控制器是一个独立的进程,但是为了降低复杂度,这些控制器都被合并运行在一个进程里。

kube-controller-manager 中包含的控制器有:

  • 节点控制器: 负责监听节点停机的事件并作出对应响应
  • 副本控制器: 负责为集群中每一个 副本控制器对象(Replication Controller Object)维护期望的 Pod 副本数
  • 端点(Endpoints)控制器:负责为端点对象(Endpoints Object,连接 Service 和 Pod)赋值
  • Service Account & Token控制器: 负责为新的名称空间创建 default Service Account 以及 API Access Token

# cloud-controller-manager

cloud-controller-manager 中运行了与具体云基础设施供应商互动的控制器。这是 Kubernetes 1.6 版本中引入的特性,尚处在 alpha 阶段。

cloud-controller-manager 只运行特定于云基础设施供应商的控制器。如果您参考 www.kuboard.cn 上提供的文档安装 Kubernetes 集群,默认不安装 cloud-controller-manager。

cloud-controller-manager 使得云供应商的代码和 Kubernetes 的代码可以各自独立的演化。在此之前的版本中,Kubernetes的核心代码是依赖于云供应商的代码的。在后续的版本中,特定于云供应商的代码将由云供应商自行维护,并在运行Kubernetes时链接到 cloud-controller-manager。

以下控制器中包含与云供应商相关的依赖:

  • 节点控制器:当某一个节点停止响应时,调用云供应商的接口,以检查该节点的虚拟机是否已经被云供应商删除

    译者注:私有化部署Kubernetes时,我们不知道节点的操作系统是否删除,所以在移除节点后,要自行通过 kubectl delete node 将节点对象从 Kubernetes 中删除

  • 路由控制器:在云供应商的基础设施中设定网络路由

    译者注:私有化部署Kubernetes时,需要自行规划Kubernetes的拓扑结构,并做好路由配置,例如 离线安装高可用的Kubernetes集群 中所作的

  • 服务(Service)控制器:创建、更新、删除云供应商提供的负载均衡器

    译者注:私有化部署Kubernetes时,不支持 LoadBalancer 类型的 Service,如需要此特性,需要创建 NodePort 类型的 Service,并自行配置负载均衡器

  • 数据卷(Volume)控制器:创建、绑定、挂载数据卷,并协调云供应商编排数据卷

    译者注:私有化部署Kubernetes时,需要自行创建和管理存储资源,并通过Kubernetes的存储类存储卷数据卷等与之关联

译者注:通过 cloud-controller-manager,Kubernetes可以更好地与云供应商结合,例如,在阿里云的 Kubernetes 服务里,您可以在云控制台界面上轻松点击鼠标,即可完成 Kubernetes 集群的创建和管理。在私有化部署环境时,您必须自行处理更多的内容。幸运的是,通过合适的教程指引,这些任务的达成并不困难。

# Node 组件

Node 组件运行在每一个节点上(包括 master 节点和 worker 节点),负责维护运行中的 Pod 并提供 Kubernetes 运行时环境。

# kubelet

此组件是运行在每一个集群节点上的代理程序。它确保 Pod 中的容器处于运行状态。Kubelet 通过多种途径获得 PodSpec 定义,并确保 PodSpec 定义中所描述的容器处于运行和健康的状态。Kubelet不管理不是通过 Kubernetes 创建的容器。

# kube-proxy

kube-proxy 是一个网络代理程序,运行在集群中的每一个节点上,是实现 Kubernetes Service 概念的重要部分。

kube-proxy 在节点上维护网络规则。这些网络规则使得您可以在集群内、集群外正确地与 Pod 进行网络通信。如果操作系统中存在 packet filtering layer,kube-proxy 将使用这一特性(iptables代理模式),否则,kube-proxy将自行转发网络请求(User space代理模式

# 容器引擎

容器引擎负责运行容器。Kubernetes支持多种容器引擎:Docker (opens new window)containerd (opens new window)cri-o (opens new window)rktlet (opens new window) 以及任何实现了 Kubernetes容器引擎接口 (opens new window) 的容器引擎

# Addons

Addons 使用 Kubernetes 资源(DaemonSet、Deployment等)实现集群的功能特性。由于他们提供集群级别的功能特性,addons使用到的Kubernetes资源都放置在 kube-system 名称空间下。

下面描述了一些经常用到的 addons,参考 Addons (opens new window) 查看更多列表。

# DNS

除了 DNS Addon 以外,其他的 addon 都不是必须的,所有 Kubernetes 集群都应该有 Cluster DNS

Cluster DNS 是一个 DNS 服务器,是对您已有环境中其他 DNS 服务器的一个补充,存放了 Kubernetes Service 的 DNS 记录。

Kubernetes 启动容器时,自动将该 DNS 服务器加入到容器的 DNS 搜索列表中。

如果您参考 www.kuboard.cn 上提供的文档安装 Kubernetes,默认已经安装了 Core DNS (opens new window)

# Web UI(Dashboard)

Dashboard (opens new window) 是一个Kubernetes集群的 Web 管理界面。用户可以通过该界面管理集群。

# Kuboard

Kuboard 是一款基于Kubernetes的微服务管理界面,相较于 Dashboard,Kuboard 强调:

  • 无需手工编写 YAML 文件
  • 微服务参考架构
  • 上下文相关的监控
  • 场景化的设计
    • 导出配置
    • 导入配置

# ContainerResource Monitoring

Container Resource Monitoring (opens new window) 将容器的度量指标(metrics)记录在时间序列数据库中,并提供了 UI 界面查看这些数据

# Cluster-level Logging

Cluster-level logging (opens new window) 机制负责将容器的日志存储到一个统一存储中,并提供搜索浏览的界面

更新时间: 2022-01-03 18:32:47