Kubernetes的基本概念
1、Kubernetes概述
1.1、kubernetes是什么
Kubernetes是一个可移植的、可扩展、分布式架构的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes的服务、支持和工具广泛可用。名称 Kubernetes 源于希腊语，意为 “舵手” 或 “飞行员”。Google 在 2014 年开源了 Kubernetes 项目。确切来说，Kubernetes是建立在Borg的一个开源版本，而Borg是谷歌的一个久负盛名的内部使 用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化，正是由于站在Borg这个前辈的肩膀上，汲取了Borg过去十年间的经验与教训， 所以Kubernetes一经开源就一鸣惊人，并迅速称霸容器领域。
1.2、容器优势
容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。
- 下面列出了容器的一些好处：
- 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
- 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。
- 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
- 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
- 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
- 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。
- 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
- 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
- 资源隔离：可预测的应用程序性能。
- 资源利用：高效率和高密度。
1.3、Kubernetes的特性
- Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力， 包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、 内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、 可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时，Kubernetes提供了完善的管理工具， 这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kubernetes是一个全新的基于容 器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。
- 服务发现和负载均衡：Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
- 存储编排：Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。
- 自动部署和回滚：您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
- 自动二进制打包：Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
- 自我修复：Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
- 密钥与配置管理：Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
2、Kubernetes 组件
前言：一个 Kubernetes 集群包含 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。
- 下图表展示了包含所有相互关联组件的 Kubernetes 集群
2.1、Master
Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群 里都需要有一个Master来负责整个集群的管理和控制，基本上 Kubernetes的所有控制命令都发给它， 它负责具体的执行过程，我们后面执行的所有命令基本都是在Master上运行的。Master通常会占据一个 独立的服务器（高可用部署建议用3台服务器） ，主要原因是它太重要了，是整个集群的“首脑”， 如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。
- Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的关键服务进程， 是Kubernetes里所有资源的增、 删、改、查等操作 的唯一入口，也是集群控制的入口进程
- Kubernetes Controller Manager（kube-controller-manager）： Kubernetes里所有资源对象的自动化控制中心， 可以将其理解为资源对象的“大总管”。
- 节点控制器
（Node Controller）: 负责在节点出现故障时进行通知和响应。 - 副本控制器
（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 - 端点控制器
（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 - 服务帐户和令牌控制器
（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.
- 节点控制器
Kubernetes Scheduler（kube-scheduler） ：负责资源调度（Pod 调度）的进程， 相当于公交公司的“调度室”。该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行
etcd：etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。
- cloud-controller-manager：云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。
cloud-controller-manager进运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部属的环境中不需要云控制器管理器。与kube-controller-manager类似，cloud-controller-manager将若干逻辑上独立的 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。- 节点控制器
（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除 - 路由控制器
（Route Controller）: 用于在底层云基础架构中设置路由 - 服务控制器
（Service Controller）: 用于创建、更新和删除云提供商负载均衡器
- 节点控制器
2.2、Node
- Kubernetes集群中的其他机器被称为Node， 在较早的 版本中也被称为Minion。 与Master一样， Node可以是一台物理主机， 也 可以是一台虚拟机。 Node是Kubernetes集群中的工作负载节点， 每个 Node都会被Master分配一些工作负载（Docker容器） ，当某个Node宕机时， 其上的工作负载会被Master自动转移到其他节点上。
kubelet： 负责Pod对应的容器的创建、启停等任务，同时与 Master密切协作， 实现集群管理的基本功能。kube-proxy： 实现Kubernetes Service的通信与负载均衡机制的重要组件。Docker Engine（docker）：Docker引擎，负责本机的容器创建 和管理工作。容器运行时（Container Runtime）：Kubernetes 支持多个容器运行环境: Docker、containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。
提示：Node可以在运行期间动态增加到Kubernetes集群中， 前提是在这个 节点上已经正确安装、 配置和启动了上述关键进程， 在默认情况下 kubelet会向Master注册自己， 这也是Kubernetes推荐的Node管理方式。 一旦Node被纳入集群管理范围， kubelet进程就会定时向Master汇报自身 的情报， 例如操作系统、 Docker版本、 机器的CPU和内存情况， 以及当 前有哪些Pod在运行等， 这样Master就可以获知每个Node的资源使用情 况， 并实现高效均衡的资源调度策略。 而某个Node在超过指定时间不上 报信息时， 会被Master判定为“失联”， Node的状态被标记为不可用 （Not Ready） ， 随后Master会触发“工作负载大转移”的自动流程
2.3、Pod
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于 在同一逻辑主机上运行的云应用。
Pod的两种用法
- 运行单个容器的 Pod：”每个 Pod 一个容器”模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
- 运行多个协同工作的容器的 Pod：Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， 而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。
Pod 和控制器
- 你可以使用工作负载资源来创建和管理多个 Pod。 资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。 例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作， 就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行
- 下面是一些管理一个或者多个 Pod 的工作负载资源的示例：
资源共享和通信
- Pod 使它的成员容器间能够进行数据共享和通信
Pod 中的存储
- 一个 Pod 可以设置一组共享的存储卷。 Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。 卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。 有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息， 请参考卷。
Pod 网络
- Kubernetes为每个Pod都分配了唯一的IP地址， 称之为Pod IP， 一个 Pod里的多个容器共享Pod IP地址。 Kubernetes要求底层网络支持集群内 任意两个Pod之间的TCP/IP直接通信， 这通常采用虚拟二层网络技术来 实现， 例如Flannel、 Open vSwitch等， 因此我们需要牢记一点： 在 Kubernetes里， 一个Pod里的容器与另外主机上的Pod容器能够直接通 信。
Pod及Pod周边对象示意图：
提示： 除了 Docker 之外，Kubernetes 支持 很多其他容器运行时， Docker 是最有名的运行时， 使用 Docker 的术语来描述 Pod 会很有帮助。 Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离 方面，即用来隔离 Docker 容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。
2.4、Label
Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是 一个
key=value的键值对，其中key与value由用户自己指定。Label可以被 附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对 象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的 资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后 动态添加或者删除。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实 现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调 度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境 中；监控和分析应用（日志记录、监控、告警）等。一些常用的Label 示例如下。
- 版本标签：”release”:”stable”、”release”:”canary”。
- 环境标签：”environment”:”dev”、”environment”:”qa”、”environment”:”production”。
- 架构标签：”tier”:”frontend”、”tier”:”backend”、”tier”:”middleware”。
- 分区标签：”partition”:”customerA”、”partition”:”customerB”。
- 质量管控标签：”track”:”daily”、”track”:”weekly”。
Label相当于我们熟悉的“标签”。给某个资源对象定义一个Label， 就相当于给它打了一个标签，随后可以通过
LabelSelector（标签选择 器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实 现了类似SQL的简单又通用的对象查询机制。LabelSelector可以被类比为SQL语句中的where查询条件，例如，name=redis-slave这个LabelSelector作用于Pod时，可以被类比为select* frompodwherepod’sname=‘redis-slave’这样的语句。当前有两种Label Selector表达式：基于等式的（Equality-based）和基于集合的（Setbased），前者采用等式类表达式匹配标签，下面是一些具体的例子。- name=redis-slave：匹配所有具有标签
name=redis-slave的资源对象。 - env!=production：匹配所有不具有标
签env=production的资源对象，比如env=test就是满足此条件的标签之一。后者则使用集合操作类表达式匹配标签，下面是一些具体的例子。 - namein（redis-master,redis-slave）：匹配所有具有标签
name=redis-master或者name=redis-slave的资源对象。 - namenotin（php-frontend）：匹配所有不具有标签
name=phpfrontend的资源对象。
- name=redis-slave：匹配所有具有标签
2.5、Replication Controller
RC是Kubernetes系统中的核心概念之一， 简单来说， 它其实定义了 一个期望的场景， 即声明某种Pod的副本数量在任意时刻都符合某个预 期值， 所以RC的定义包括如下几个部分。
- Pod期待的副本数量。
- 用于筛选目标Pod的Label Selector。
- 当Pod的副本数量小于预期数量时， 用于创建新Pod的Pod模板 （template） 。
RS是Kubernetes 1.2中， 将RC升级为另外一个新概念—
Replica Set，官方解释 其为“下一代的RC”。Replica Set与RC当前的唯一区别是，Replica Sets支 持基于集合的Label selector（Set-based selector） ， 而RC只支持基于等 式的Label Selector（equality-based selector） ， 这使得Replica Set的功能 更强Replica Set与Deployment这两个重要的资源对象逐步替代了之前RC的作用，是Kubernetes 1.3里Pod自动扩容（伸缩）这个告警功能实现的基础， 也将继续在Kubernetes未来的版本中发挥重要的作用，最后总结一下RC（Replica Set）的一些特性与作用。- 在大多数情况下，我们通过定义一个RC实现Pod的创建及副本数量的自动控制。
- 在RC里包括完整的Pod定义模板。
- RC通过Label Selector机制实现对Pod副本的自动控制。
- 通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容。
- 通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级。
2.6、Deployment
Deployment是Kubernetes在1.2版本中引入的新概念， 用于更好地解 决Pod的编排问题。 为此， Deployment在内部使用了Replica Set来实现目 的， 无论从Deployment的作用与目的、 YAML定义， 还是从它的具体命 令行操作来看， 我们都可以把它看作RC的一次升级， 两者的相似度超 过90%。
Deployment相对于RC的一个最大升级是我们可以随时知道当前 Pod“部署”的进度。 实际上由于一个Pod的创建、 调度、 绑定节点及在目 标Node上启动对应的容器这一完整过程需要一定的时间， 所以我们期待 系统启动N个Pod副本的目标状态， 实际上是一个连续变化的“部署过 程”导致的最终状态。
Deployment的典型使用场景有以下几个：
- 创建一个Deployment对象来生成对应的ReplicaSet并完成Pod副本的创建。检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到预期的值）。
- 更新Deployment以创建新的Pod（比如镜像升级）。如果当前Deployment不稳定，则回滚到一个早先的Deployment 版本。
- 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布。 扩展Deployment以应对高负载。
- 查看Deployment的状态，以此作为发布是否成功的指标。
- 清理不再需要的旧版本ReplicaSets。
2.7、Horizontal Pod Autoscaler
HPA与之前的RC、Deployment一样，也属于一种Kubernetes资源对象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。
Pod水平自动扩缩（HorizontalPodAutoscaler）可以基于CPU利用率自动扩缩ReplicationController、Deployment和ReplicaSet中的Pod数量。除了CPU利用率，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。Pod自动扩缩不适用于无法扩缩的对象，比如DaemonSet。
Pod水平自动扩缩工作机制：
2.8、StatefulSet
在Kubernetes系统中，Pod的管理对象RC、Deployment、DaemonSet和Job都面向无状态的服务。但现实中有很多服务是有状态的，特别是一些复杂的中间件集群，例如MySQL集群、MongoDB集群、Akka集群、ZooKeeper集群等，而StatefulSet则是用来创建有状态的集群控制器。
StatefulSet有如下特性：
- StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod叫kafka-0，-第2个叫kafka-1，以此类推。
- StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态。
- StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。
2.9、Service
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。
Pod、 RC与Service的逻辑关系：
2.10、Job
Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功
Job所控制的Pod副本是短暂运行的，可以将其视为一组Docker容器，其中的每个Docker容器都仅仅运行一次。当Job控制的所有Pod副本都运行结束时，对应的Job也就结束了。Job在实现方式上与RC等副本控制器不同，Job生成的Pod副本是不能自动重启的，对应Pod副本的RestartPoliy都被设置为Never。因此，当对应的Pod副本都执行完成时，相应的Job也就完成了控制使命，即Job生成的Pod在Kubernetes中是短暂存在的。Kubernetes在1.5版本之后又提供了类似crontab的定时任务——CronJob，解决了某些批处理任务需要定时反复执行的问题。
Job所控制的Pod副本的工作模式能够多实例并行计算，以TensorFlow框架为例，可以将一个机器学习的计算任务分布到10台机器上，在每台机器上都运行一个worker执行计算任务，这很适合通过Job生成10个Pod副本同时启动运算。
2.11、Volume
Volume（存储卷）是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。首先，Kubernetes中的Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。最后，Kubernetes支持多种类型的Volume，例如GlusterFS、Ceph等先进的分布式文件系统。
Volume的使用也比较简单，在大多数情况下，我们先在Pod上声明一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的某个目录上。举例来说，我们要给之前的TomcatPod增加一个名为datavol的Volume，并且挂载到容器的/mydata-data目录上，则只要对Pod的定义文件做如下修正即可（注意代码中的粗体部分）
Kubernetes 支持下列类型的卷：
- awsElasticBlockStore、azureDisk、azureFile、cephfs、cinder、configMap、csi、downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker、gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume
2.12、Persistent Volume
- Volume是被定义在Pod上的，属于计算资源的一部分，而实际上，网络存储是相对独立于计算资源而存在的一种实体资源。比如在使用虚拟机的情况下，我们通常会先定义一个网络存储，然后从中划出一个“网盘”并挂接到虚拟机上。
PersistentVolume（PV）和与之相关联的PersistentVolumeClaim（PVC）也起到了类似的作用。PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储，它与Volume类似，但有以下区别。PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。◎PV并不是被定义在Pod上的，而是独立于Pod之外定义的。PV目前支持的类型包括：gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC（FibreChannel）、Flocker、NFS、iSCSI、RBD（RadosBlockDevice）、CephFS、Cinder、GlusterFS、VsphereVolume、QuobyteVolumes、VMwarePhoton、PortworxVolumes、ScaleIOVolumes和HostPath（仅供单机测试）。
2.13、Namespace
Namespace（命名空间）是Kubernetes系统中的另一个非常重要的概念，Namespace在很多情况下用于实现多租户的资源隔离。Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。
Kubernetes 会创建三个初始名字空间：
default没有指明使用其它名字空间的对象所使用的默认名字空间kube-system Kubernetes系统创建对象所使用的名字空间kube-public这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。 这个名字空间的公共方面只是一种约定，而不是要求。kube-node-lease此名字空间用于与各个节点相关的租期（Lease）对象； 此对象的设计使得集群规模很大时节点心跳检测性能得到提升
当给每个租户创建一个Namespace来实现多租户的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU使用量、内存使用量等
2.14、Annotation
- Annotation（注解）与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对 象的元数据（Metadata），并且用于LabelSelector。Annotation则是用户 任意定义的附加信息，以便于外部工具查找。在很多时候，Kubernetes的模块自身会通过Annotation标记资源对象的一些特殊信息。通常来说，用Annotation来记录的信息如下。
- build信息、release信息、Docker镜像信息等，例如时间戳、 releaseid号、PR号、镜像Hash值、DockerRegistry地址等。
- 日志库、监控库、分析库等资源库的地址信息。
- 程序调试工具信息，例如工具名称、版本号等。
- 团队的联系信息，例如电话号码、负责人名称、网址等。
2.15、ConfigMap
ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。ConfigMap将您的环境配置信息和容器镜像解耦，便于应用配置的修改。当您需要储存机密信息时可以使用 Secret 对象
Kubernetes提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。进一步地，如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新。于是，KubernetesConfigMap就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。
ConfigMap配置集中化的一种简单方案如图：
