Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。

Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器， 这些容器相对紧密地耦合在一起。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

通常创建 Pod 是为了运行单个主容器。 Pod 还可以运行可选的边车（sidecar）容器，以添加诸如日志记录之类的补充特性。 通常用 Deployment来管理 Pod。

就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。

注意：Pod 不是进程，而是容器运行的环境。 在被删除之前，Pod 会一直存在。

相关命令：

# 获取pod列表
kubectl get pods

Deployment（部署）

一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。

你负责描述 Deployment 中的 目标状态，而 Deployment 控制器（Controller）以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。

Service（服务）

将运行在一组Pod上的应用程序公开为网络服务的抽象方法。

使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pod 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。

Namespace（命名空间）

在 Kubernetes 中，Namespace 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。

相关命令：

# 列出集群中现存的名字空间
kubectl get namespace

# 要为当前请求设置名字空间，请使用 --namespace 参数。
kubectl run nginx --image=nginx --namespace=<名字空间名称>
kubectl get pods --namespace=<名字空间名称>

# 设置名字空间偏好
# 永久保存
kubectl config set-context --current --namespace=<名字空间名称>
# 验证
kubectl config view --minify | grep namespace:

Kubernetes 会创建四个初始名字空间：

• default 没有指明使用其它名字空间的对象所使用的默认名字空间
• kube-system Kubernetes 系统创建对象所使用的名字空间
• kube-public 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。 这个名字空间的公共方面只是一种约定，而不是要求。
• kube-node-lease 此名字空间用于与各个节点相关的 租约（Lease）对象。 节点租期允许 kubelet 发送心跳，由此控制面能够检测到节点故障。

Node（节点）

Kubernetes 中的工作机器称作节点

Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。

节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pod所需的服务； 这些节点由 控制面负责管理。

通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。

节点上的组件包括 kubelet、 容器运行时以及kube-proxy。

Container（容器）

容器是可移植、可执行的轻量级的镜像，包含其中的软件及其相关依赖。

容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。

Event（事件）

每个 Event 是集群中某处所发生事件的报告。 它通常用来表述系统中的某种状态变更。

事件的保留时间有限，随着时间推进，其触发方式和消息都可能发生变化。 事件用户不应该对带有给定原因（反映下层触发源）的时间特征有任何依赖， 也不要寄希望于该原因所造成的事件会一直存在。

事件应该被视为一种告知性质的、尽力而为的、补充性质的数据。

在 Kubernetes 中，审计机制会生成一种不同类别的 Event 记录。

Control Plane（控制平面）

控制平面（Control Plane）是指容器编排层，它暴露 API 和接口来定义、 部署容器和管理容器的生命周期。

这个编排层是由多个不同的组件组成，例如以下（但不限于）几种：

• etcd
• API Server（API 服务器）
• Scheduler（调度器）
• Controller Manager（控制器管理器）
• Cloud Controller Manager（云控制器管理器）

这些组件可以作为传统的操作系统服务（守护程序）或容器运行。运行这些组件的主机在历史上被称为 masters。

kube-apiserver（API 服务器）

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

Job

Job 是需要运行完成的确定性的或批量的任务。

Job 创建一个或多个 Pod 对象，并确保指定数量的 Pod 成功终止。 随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。

Kubectl

kubectl 是使用 Kubernetes API 与 Kubernetes 集群的控制面进行通信的命令行工具。

你可以使用 kubectl 创建、检视、更新和删除 Kubernetes 对象。

Kubelet

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

ReplicaSet（副本控制器）

ReplicaSet 是下一代副本控制器。

ReplicaSet 就像 ReplicationController 那样，确保一次运行指定数量的 Pod 副本。ReplicaSet 支持新的基于集合的选择器需求（在标签的用户指南中有相关描述），而副本控制器只支持基于等值的选择器需求。

Object（对象）

Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。

Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes 控制平面（Control Plane） 不断工作，以确保它代表的项目确实存在。 创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。

Workload（工作负载）

工作负载是在 Kubernetes 上运行的应用程序。

代表不同类型或部分工作负载的各种核心对象包括 DaemonSet， Deployment， Job， ReplicaSet， and StatefulSet。

例如，具有 Web 服务器和数据库的工作负载可能在一个 StatefulSet 中运行数据库， 而 Web 服务器运行在 Deployment。

Cluster（集群）

集群是由一组被称作节点（node）的机器组成， 这些节点上会运行由 Kubernetes 所管理的容器化应用。 且每个集群至少有一个工作节点。

工作节点会托管所谓的 Pods，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pods。 为集群提供故障转移和高可用性， 这些控制平面一般跨多主机运行，而集群也会跨多个节点运行。

Image（镜像）

镜像是保存的容器实例，它打包了应用运行所需的一组软件。

镜像是软件打包的一种方式，可以将镜像存储在容器镜像仓库、拉取到本地系统并作为应用来运行。 镜像中包含的元数据指明了运行什么可执行程序、是由谁构建的以及其他信息。

affinity（亲和性）

在 Kubernetes 中 亲和性（affinity） 是一组规则，它们为调度程序提供在何处放置 Pod 提示信息。

亲和性有两种：

• 节点亲和性
• Pod 间亲和性

这些规则是使用 Kubernetes 标签（label） 和 Pod 中指定的 选择算符定义的， 这些规则可以是必需的或首选的，这取决于你希望调度程序执行它们的严格程度。

Volume（卷）

包含可被 Pod 中容器访问的数据的目录。 每个 Kubernetes 卷在所处的 Pod 存在期间保持存在状态。 因此，卷的生命期会超出 Pod 中运行的容器， 并且保证容器重启之后仍保留数据。

包含可被 Pod 中容器访问的数据的目录。每个 Kubernetes 卷在所处的 Pod 存在期间保持存在状态。 因此，卷的生命期会超出 Pod 中运行的容器， 并且保证容器重启之后仍保留数据。

Container Runtime（容器运行时）

容器运行环境是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 containerd、CRI-O以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

Label（标签）

用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。

标签是一些关联到 Pods 这类对象上的键值对。 它们通常用来组织和选择对象子集。

Controller（控制器）

在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。 控制器（控制平面的一部分） 通过 API 服务器监控你的集群中的公共状态。

其中一些控制器是运行在控制平面内部的，对 Kubernetes 来说，他们提供核心控制操作。 比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、 命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume controller）（等） 都是运行在 kube-controller-manager 中的。

StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象。

StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

StatefulSet 对于需要满足以下一个或多个需求的应用程序很有价值：

• 稳定的、唯一的网络标识符。
• 稳定的、持久的存储。
• 有序的、优雅的部署和扩缩。
• 有序的、自动的滚动更新。

---

本文章来自官方网站https://kubernetes.io/docs/home