前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

---

Kubernetes 使用共享网络将多个物理机或虚拟机汇集到一个集群中，在各服务器之间进行通信，该集群是配置 Kubernetes 的所有组件、功能和工作负载的物理平台。

集群中一台服务器(或高可用部署中的一组服务器)用作 Master ，负责管理整个集群，余下的其他机器用作 Worker Node (早期版本中也称为 Minion )，它们是使用本地和外部资源接收和运行工。

Master

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

单个 Master 节点即可完成其所有的功能，但出于冗余及负载均衡等目的,生产环境中通常需要协同部署多个此类主机。

Master节点类似于蜂群中的蜂王。

Node

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

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

Node 类似于蜂群中的工蜂，生产环境中，它们通常数量众多。

Kubernetes 将所有 Node 的资源集结于一处形成一台更加强大的“服务器”，在用户将应用部署于其上时， Master 会使用调度算法将其自动指派至某个特定的 Node 运行。

在 Node 加入集群或从集群中移除时， Master 也会按需重新编排影响到的 Pod (容器)。

于是，用户无须关心其应用究竟运行于何处。

---

Pod

Kubernetes 并不直接运行容器，而是使用一个抽象的资源对象来封装一个或者多个容器，这个抽象即为 Pod ，它也是 Kubernetes 的最小调度单元。

同一 Pod 中的容器共享网络名称空间和存储资源，这些容器可经由本地回环节口 IO 直接通信，但彼此之间又在 Mount 、 User 及 PID 等名称空间上保持了隔离。

尽管 Pod 中可以包含多个容器，但是作为最小调度单元，它应该尽可能地保持“小”，即通常只应该包含一个主容器，以及必要的辅助型容器( sidecar )。

Controller

尽管 Pod 是 Kubernetes 的最小调度单元，但用户通常并不会直接部署及管理 Pod 对象，而是要借助于另一类抽象一一控制器( Controller )对其进行管理。

用于工作负载的控制器是一种管理 Pod 生命周期的资源抽象，它们是 Kubernetes 上的一类对象，而非单个资源对象，包括 ReplicationController 、 Replicaset 、 Deployment 、 Statefulset 、 Job 等。

以 Deployment 控制器为例，它负责确保指定的 Pod 对象的副本数量精确符合定义，否则“多退少补”。

使用控制器之后就不再需要手动管理 Pod 对象了，用户只需要声明应用的期望状态，控制器就会自动对其进行进程管理。

---

Label

标签( Label )是将资源进行分类的标识符，资源标签其实就是一个键值型( key / values ) 数据。

标签旨在指定对象(如 Pod 等)辨识性的属性，这些属性仅对用户存在特定的意义对 Kubernetes 集群来说并不直接表达核心系统语义。

标签可以在对象创建时附加其上，并能够在创建后的任意时间进行添加和修改。

一个对象可以拥有多个标签，一个标签也可以附加于多个对象(通常是同一类对象)之上。

Selector

标签选择器( Selector )全称为“ Label Selector '"，它是一种根据 Label 来过滤符合条件的资源对象的机制。

用户通常使用标签对资源对象进行分类，而后使用标签选择器挑选出它们，例如将其创建为某 Service 的端点。

---

Service

Service 是建立在一组 Pod 对象之上的资源抽象，它通过标签选择器选定一组 Pod 对象，并为这组 Pod 对象定义一个统一的固定访问入口(通常是一个 IP 地址)，若 Kubernetes 集群存在 DNS 附件，它就会在 Service 创建时为其自动配置一个 DNS 名称以便客户端进行服务发现。

到达 ServiceIP 的请求将被负载均衡至其后的端点一一各个 Pod 对象之上，因此 Service 从本质上来讲是一个四层代理服务。

另外， Service 还可以将集群外部流量引入到集群中来。

Ingress

Kubernetes 将 Pod 对象和外部网络环境进行了隔离， Pod 和 Service 等对象间的通信都使用其内部专用地址进行，如若需要开放某些 Pod 对象提供给外部用户访问，则需要为其请求流量打开一个通往 Kubernetes 集群内部的通道，除了 Service 之外， Ingress 也是这类通道的实现方式之一。

---

Volume

存储卷( Volume )是独立于容器文件系统之外的存储空间，常用于扩展容器的存储空间并为它提供持久存储能力。

Kubernetes 集群上的存储卷大体可分为临时卷、本地卷和网络卷。

临时卷和本地卷都位于 Node 本地，一旦 Pod 被调度至其他 Node ，此种类型的存储卷将无法访问到，因此临时卷和本地卷通常用于数据缓存，持久化的数据则需要放置于持久卷 ( Persistent Volume 通常简称 PV)之上。

Name / Namespace

名称( Name )是 Kubernetes 集群中资源对象的标识符，它们的作用域通常是名称空间( Namespace )，因此名称空间是名称的额外的限定机制。

在同一个名称空间中，同一类型资源对象的名称必须具有唯一性。

名称空间通常用于实现租户或项目的资源隔离，从而形成逻辑分组。

创建的 Pod 和 Service 等资源对象都属于名称空间级别，未指定时，它们都属于默认的名称空间"default" 。

Annotation

Annotation (注解)是另一种附加在对象之上的键值类型的数据，但它拥有更大的数据容量。

Annotation 常用于将各种非标识型元数据( metadata )附加到对象上，但它不能用于标识和选择对象，通常也不会被 Kubernetes 直接使用，其主要目的是方便工具或用户的阅读及査找等。