Node

申请了一台服务器，服务器所作的工作被称之为（Work），Node 可以是一台物理机，也可以是虚拟机，取决于所在的集群配置。在 K8S 中一台服务器就是一个 Node。Node 的组件运行在每一个节点上（包括 master 节点和 worker 节点），负责维护运行中的 Pod 并提供 Kubernetes 运行时环境。

Node 的 IP 地址

在一个节点服务器中，IP 地址包括内网 IP 和外网 IP。对应于 K8S 集群来讲，内部 IP 可以在集群内访问，外部 IP 可以在集群外访问。在服务器上执行hostname命令，得到主机名字。在集群中，Node 的主机名也会被记录。

Node 的基本信息和组件

使用 cat /etc/issue 或者 cat /etc/os-release等方法可以查看 Node 的基本信息。集群会记录每个 Node 的基础信息。
Kubernetes 通过将容器放入在节点（Node）上运行的Pod 中来执行你的工作负载。
每个节点包含运行Pods所需的服务，可以理解为Pod是最小的调度单元； 这些节点由控制面负责管理。通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可只有一个节点。
节点上的组件包括kubelet、container-runtimes以及kube-proxy。

kubelet

此组件是运行在每一个集群节点上的代理程序。它确保 Pod 中的容器处于运行状态。Kubelet 通过多种途径获得 PodSpec 定义，并确保 PodSpec 定义中所描述的容器处于运行和健康的状态。Kubelet 实现了集群中最重要的关于 Node 和 Pod 的控制功能，如果没有 Kubelet 的存在，那 Kubernetes 很可能就只是一个纯粹的通过 API Server CRUD 的应用程序。K8S 原生的执行模式是操作应用程序的容器，而不像传统模式那样，直接操作某个包或者是操作某个进程。基于这种模式，可以让应用程序之间相互隔离，互不影响。此外，由于是操作容器，所以应用程序可以说和主机也是相互隔离的，毕竟它不依赖于主机，在任何的容器运行时（比如 Docker）上都可以部署和运行。

kube-proxy

我们都知道，想要访问某个服务，那要么通过域名，要么通过 IP。而每个 Pod 在创建后都会有一个虚拟 IP，K8S 中有一个抽象的概念，叫做 Service ，kube-proxy 便是提供一种代理的服务，让你可以通过 Service 访问到 Pod。实际的工作原理是在每个 Node 上启动一个 kube-proxy 的进程，通过编排 iptables 规则来达到此效果。kube-proxy 在节点上维护网络规则。这些网络规则使得您可以在集群内、集群外正确地与 Pod 进行网络通信。如果操作系统中存在 packet filtering layer，kube-proxy 将使用这一特性（iptables 代理模式），否则，kube-proxy 将自行转发网络请求（User space 代理模式）。

容器引擎 Container runtime

容器运行时最主要的功能是下载镜像和运行容器，K8S 提供了一套通用的容器运行时接口 CRI (Container Runtime Interface), 凡是符合这套标准的容器运行时实现，均可在 K8S 上使用。容器引擎负责运行容器。我们最常见的实现可能是 Docker , 目前还有其他的一些实现，比如 rkt, cri-o。 :::info Kubernetes支持多种容器引擎：Docker(opens new window)、containerd(opens new window)、cri-o(opens new window)、rktlet(opens new window)以及任何实现了 Kubernetes容器引擎接口(opens new window)的容器引擎。 :::

Master

Master ，是管理集群的相关组件。
Master 是整个 K8S 集群的“大脑”，与大脑类似，它有几个重要的功能：

  • 接收：外部的请求和集群内部的通知反馈
  • 发布：对集群整体的调度和管理
  • 存储：存储

这些功能，也通过一些组件来共同完成，通常情况下，我们将 Master 称为 control plane 控制平面 。 :::info Master 组件是集群的控制平台（control plane）：

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

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

kube-api server

此 master 组件提供 Kubernetes API。这是 Kubernetes 控制平台的前端（front-end），可以水平扩展（通过部署更多的实例以达到性能要求）。kubectl / kubernetes dashboard / kuboard 等 Kubernetes 管理工具就是通过 kubernetes API 实现对 Kubernetes 集群的管理。
这是整个集群的入口，类似于人体的感官，接收外部的信号和请求，并将一些信息写入到 etcd 中。
实际处理逻辑比三次握手简单的多：

  • 请求 API Server ：“嗨，我有些东西要放到 etcd 里面”
  • API Server 收到请求：“你是谁？我为啥要听你的”
  • 从请求中，拿出自己的身份凭证（一般是证书）：“是我啊，你的master，给我把这些东西放进去”
  • 这时候就要看是些什么内容了，如果这些内容 API Server 能理解，那就放入 etcd 中 “好的 master 我放进去了”；如果不能理解，“抱歉 master 我理解不了”

可以看到，它提供了认证相关的功能，用于判断是否有权限进行操作。当然 API Server 支持多种认证方法，不过一般情况下，我们都使用 x509 证书进行认证。
API Server 的目标是成为一个极简的 server，只提供 REST 操作，更新 etcd ，并充当着集群的网关。

etcd

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

kube-scheduler

顾名思义，Scheduler 是集群的调度器，它会持续的关注集群中未被调度的 Pod ，并根据各种条件，比如资源的可用性，节点的亲和性或者其他的一些限制条件，通过绑定的 API 将 Pod 调度/绑定到 Node 上。
在这个过程中，调度程序一般只考虑调度开始时， Node 的状态，而不考虑在调度过程中 Node 的状态变化
此 master 组件监控所有新创建尚未分配到节点上的 Pod，并且自动选择为 Pod 选择一个合适的节点去运行。
影响调度的因素有：

  • 单个或多个 Pod 的资源需求
  • 硬件、软件、策略的限制
  • 亲和与反亲和（affinity and anti-affinity）的约定
  • 数据本地化要求

  • 工作负载间的相互作用

    kube-controller-manager

    Controller Manager 大概是 K8S 集群中最繁忙的部分，它在后台运行着许多不同的控制器进程，用来调节集群的状态。当集群的配置发生变更，控制器就会朝着预期的状态开始工作。
    此 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的存储类、存储卷、数据卷等与之关联