说明
本本内容从 https://www.vmware.com/topics/glossary 获取、翻译，网站内容政策请参考 https://www.vmware.com/community_terms.html，内容复制、翻译请参考版权协议http://creativecommons.org/licenses/by-nc/3.0/。
本文内容从 vmware 网站的术语词汇知识库收集、翻译、整理，文章主要介绍 Kubernetes 各组成部件中的一些术语，以及概念。
Kubernetes集群的组成
我们谈起 Kubernetes 和应用部署时，往往会涉及到容器、节点、Pods 等概念，还有各种术语，令人眼花缭乱。为了更好地摸清 Kubernetes，下面我们将介绍 Kubernetes 中与应用程序部署(deployment)和执行(execution)相关的知识。
Kubernetes 集群由多个组件(components)、硬件(hardware)、软件(software)组成，它们共同工作来管理容器化(containerized)应用的部署和执行，这些相关的组成的概念有：
| 成分 | 名称 |
| Cluster | 集群 |
| Node | 节点 |
| Pod | 不翻译 |
| Container | 容器 |
| Containerzed Application | 容器化应用 |
接下来的内容，按将从小到大的粒度介绍这些组成成分。
What are containerized applications?
containerized applications 指容器化的应用，我们常常说使用镜像打包应用程序，使用 Docker 发布、部署应用程序，那么当你的应用成功在 Docker 上运行时，称这个应用是 containerized applications。
定义：
Containerized applications are bundled with their required libraries, binaries, and configuration files into a container.
容器化的应用程序与它们所需的库、二进制文件和配置文件绑定到一个容器中。
当然，并不是说能够将一个应用程序打包到容器中运行，就可以鼓吹产品；并不是每个应用程序都是容器化的优秀对象，例如在 DDD 设计中被称为大泥球的应用程序，由于其设计复杂、依赖程度高、程序不稳定等原因，难以迁移、难以配置的应用程序明显是失败的产品。
在多年经验中，许多开发者总结了经验，形成十二个云计算应用程序因素指导原则：
1. Codebase: One codebase tracked in revision control, many deploys
代码库: 一个代码库可以在版本控制和多份部署中被跟踪
2. Dependencies: Explicitly declare and isolate dependencies
依赖项: 显式声明和隔离依赖项
3. Config: Store config in the environment
配置: 在环境中存储配置
4. Backing services: Treat backing services as attached resources
支持服务: 将支持服务视为附加资源(可拓展，而不是做成大泥球)
5. Build, release, run: Strictly separate build and run stages
构建、发布、运行: 严格区分构建和运行阶段(连 Debug、Release 都没有区分的产品是真的垃圾)
6. Processes: Execute the app as one or more stateless processes
过程: 作为一个或多个无状态过程执行应用程序
7. Port binding: Export services via port binding
端口绑定: 可通过端口绑定服务对外提供服务
8. Concurrency: Scale out via the process model
并发性: 通过进程模型进行扩展
9. Disposability: Maximize robustness with fast startup and graceful shutdown
可处理性: 快速启动和完美关机，最大限度地增强健壮性
10. Dev/prod parity: Keep development, staging, and production as similar as possible
Dev/prod parity: 尽可能保持开发中、演示时和生产时的相似性
11. Logs: Treat logs as event streams
Logs: 将日志视为事件流
12. Admin processes: Run admin/management tasks as one-off processes
管理流程: 将管理/管理任务作为一次性流程运行
上述内容可能有笔者翻译不到位的地方，读者可阅读原文了解：
https://www.vmware.com/topics/glossary/content/components-kubernetes
许多流行的编程语言和应用被容器化并存储在开源仓库中，然而，只使用运行应用程序所需的库和二进制文件来构建应用程序容器，不需要导入所有可用的东西，这样可能会更有效率。创建容器可以采用编程方式，从而可以创建持续集成和部署(CI/CD)管道以提高效率。容器化应用位于开发人员领域之中，开发人员需要掌握如何容器化应用。
What are Kubernetes containers?
Containers are standardized, self-contained execution enclosures for applications.
容器是应用的标准化、独立的执行外壳。
通常，容器都包含一个应用程序，以及正确执行二进制程序所需的依赖库、文件等，例如 Linux 文件系统+应用程序组成一个简单的容器。通过将容器限制为单个进程，问题诊断和更新应用程序都变得更加容易。与 VM(虚拟机)不同，容器不包含底层操作系统，因此容器被认为是轻量级的。Kubernentes 容器属于开发领域。
What are Kubernetes pods?
Pod 是 Kubernetes 集群中最小的执行单位。在 Kubernetes 中，容器不直接在集群节点上运行，而是将一个或多个容器封装在一个 Pod 中。Pod 中的所有应用程序共享相同的资源和本地网络，从而简化了 Pod 中应用程序之间的通讯。Pod 在每个节点(Node)上利用一个名为 Kubelet 的代理和 Kubernetes API 以及集群中其余部分进行通讯。尽管现在开发人员需要 API 访问完成集群管理，但 Pod 的管理是正在向 Devops 领域过渡。
随着 Pod 负载的增加，Kubernetes 可以自动复制 Pod 以达到预期的可拓展性(部署更多的 Pod 提供相同的服务，负载均衡)。因此，设计一个尽可能精简的 Pod 是很重要的，降低因复制扩容、减少收缩过程中带来的资源损失。
Pod 似乎被认为是 DevOps 的专业领域。
What is the difference between containers vs. pods?
容器包含执行特定流程或函数所需的代码(编译后的二进制可执行程序)。在 Kubernetes 之前，组织可以直接在物理或虚拟服务器上运行容器，但是缺乏 Kubernetes 集群所提供的可伸缩性和灵活性。
Pod 为容器提供了一种抽象，可以将一个或多个应用程序包装到一个 Pod 中，而 Pod 是 Kubernetes 集群中最小的执行单元。例如 Pod 可以包含初始化容器，这些容器为其它应用提供了准备环境，然后在应用程序开始执行前终结。Pod 是集群中复制的最小单位，Pod 中的容器作为整体被扩展或缩小。
如果应用程序需要访问持久性的存储，那么 Pod 也包括持久性存储和容器。
What are Kubernetes nodes?
Pod 是 Kubernetes 中最小的执行单元，而 Node 是 Kubernetes 中最小的计算硬件单元。节点可以是物理的本地服务器，也可以是虚拟机。
与容器一样，Node 提供了一个抽象层。如果操作团队认为一个 Node 只是一个具有处理能力和内存的资源，那么每个 Node 就可以与下一个 Node 互换。多个 Node 一起工作形成了 Kubernetes 集群，它可以根据需求的变化自动分配工作负载。如果一个节点失败，它将自动从集群中移除，由其他节点接管。每个节点都运行着一个名为 kubelet 的代理，该代理与集群控制平面通信。
Node 是 DevOps 和 IT 的专业领域。
What is the difference between Kubernetes pods vs. nodes?
Pod 是可执行代码的抽象，Node 是计算机硬件的抽象，所以这种比较有点像苹果和橘子。
Pods 是 Kubernetes 最小的执行单元，由一个或多个容器组成；
Node 是组成 Kubernetes 集群的物理服务器或虚拟机。Node 是可互换的，通常不会由用户或 IT 单独处理，除非需要进行维护。
What is a Kubernetes Control Plane?
Kubernetes 控制平面是用于 Kubernetes 集群的控制器，主要包含 apiserver、etcd、scheduler、controller-manager 。
在第一篇时已经提到过，这里不需要深入介绍，故不再赘述。
What is a Kubernetes Cluster?
Kubernetes 集群由 Node 组成，Node 可以是虚拟机或物理服务器。当你使用 Kubernetes 时，大多时间是在管理集群。在一个 Node 上必须至少有一个运行的 Kubernetes 控制平面的实例，以及至少一个要在其上运行的 Pod。通常，当工作负载发生变化时，集群将有多个节点来处理应用程序的变更。
What is the difference between Kubernetes Nodes vs. Clusters?
Node 是集群中最小的元素。集群由 Node 组成。集群是一个集体，共享 Pod 的总体执行，反映在 Google Kubernetes 集群项目的原始名称: Borg。
What are Kubernetes volumes?
由于容器最初设计为临时性和无状态的，因此几乎不需要解决存储持久性问题。然而，随着越来越多需要从持久性存储读写的应用程序被容器化，对持久性存储卷的访问需求也随之出现。
为了实现这一点，Kubernetes 有持久的卷。独特之处在于它们是集群外部的，可以将持久卷挂载到集群，而不需要将它们与特定节点、容器或 pod 关联。
持久卷可以是本地的，也可以是基于云的，并且是 DevOps 和 IT 的专业领域。
在 Docker 中，我们可以使用以下命令管理卷
# 创建自定义容器卷 docker volume create {卷名称}
# 查看所有容器卷 docker volume ls
# 查看指定容器卷的详细信息 docker volume inspect {卷名称}
我们可以在运行容器时，使用 -v 映射主机目录，或者映射容器卷到容器中。
docker -itd ... -v /var/tmp:/opt/app ... docker -itd ... -v {卷名}:/opt/app ...
How do the components of Kubernetes work together?
简单地说，刚开始时，应用程序被创建或迁移到容器中，然后运行在 Kubernetes 集群创建的 Pod上。
一旦 Pod 被创建，Kubernetes 会将它们分配给集群中的一个或多个 Node ，并确保运行的副本 Node 的正确数量。Kubernetes 扫描集群以确保每组 Container 都按照指定的方式运行。
