Kubernetes组件：一个典型应用中的资源
Kubernetes是希腊文，意思是“舵手”，寓意是能带领我们安全地到达未知水域。Kubernetes这样的容器编排系统，会帮助我们妥善地管理分布式应用的部署结构和线上流量，高效地组织容器和服务。Kubernetes 作为数据中心操作系统，在设计软件系统时，能够尽量降低在底层网络和硬件设施上的负担。
下图显示了一个典型应用中所使用的各个 Kubernetes 组件。我们一起来看看一个实际应用程序的各个组成部分，试着从全局来审视它们。
一个典型应用中的资源
一个典型的应用 manifest 包含了一个或者多个 Deployment 和 StatefulSet 对象。这些对象中包含了一个或者多个容器的 pod 模板，每个容器都有一个存活探针，并且为容器提供的服务（如果有的话）提供就绪探针。提供服务的 pod 是通过一个或者多个服务来暴露自己的。当需要从集群外访问这些服务的时候，要么将这些服务配置为 LoadBalancer 或者 NodePort 类型的服务，要么通过 Ingress 资源来开放服务。
pod 模板（从中创建 pod 的配置文件）通常会引用两种类型的私密凭据（Secret）。一种是从私有镜像仓库拉取镜像时使用的 ；另一种是 pod 中运行的进程直接使用的。私密凭据本身通常不是应用 manifest 的一部分，因为它们不是由应用开发者来配置，而是由运维团队来配置的。私密凭据通常会被分配给ServiceAccount，然后ServiceAccount 会被分配给每个单独的 pod。
一个应用还包含一个或者多个 ConfigMap 对象，可以用它们来初始化环境变量，或者在pod中以 configMap卷来挂载。有一些pod会使用额外的卷，例如 emptyDir 或 gitRepo 卷，而需要持久化存储的 pod 则需要persistentVolumeClaim 卷。PersistentVolumeClaim 也是一个应用 manifest 的一部分，而被PersistentVolumeClaim 所引用的 StorageClass 则是由系统管理员事先创建的。
在某些情况下，一个应用还需要使用任务（Jobs）和定时任务（CronJobs）。守护进程集（DaemonSet）通常不是应用部署的一部分，但是通常由系统管理员创建，以在全部或者部分节点上运行系统服务。水平 pod 扩容器（HorizontalpodAutoscaler）可以由开发者包含在应用 manifest 中或者后续由运维团队添加到系统中。集群管理员还会创建 LimitRange 和 ResourceQuota 对象，以控制每个 pod 和所有的 pod（作为一个整体）的计算资源使用情况。
在应用部署后，各种 Kubernetes 控制器会自动创建其他的对象。其中包括端点控制器（Endpoint controller）创建的服务端点（Endpoint）对象，部署控制器（Deployment controller）创建的ReplicaSet 对象，以及由 ReplicaSet（或者 Job、CronJob、StatefulSet、DaemonSet）创建的实际的 pod 对象。
资源通常通过一个或者多个标签来组织。这不仅仅适用于 pod，同时也适用于其他的资源。除了标签，大多数的资源还包含一个描述资源的注解，列出负责该资源的人员或者团队的联系信息，或者为管理者和其他的工具提供额外的元数据。
