1.k8s基本概念概述
Kubernetes中的大部分概念如Node、Pod、Replication Controller、 Service等都可以被看作一种资源对象，几乎所有资源对象都可以通过 Kubernetes提供的kubectl工具（或者API编程调用）执行增、删、改、查 等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes 其实是一个高度自动化的资源控制系统，它通过跟踪对比etcd库里保存 的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控 制和自动纠错的高级功能。
2.Master
2.1.Master描述
Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群 里都需要有一个Master来负责整个集群的管理和控制，基本上 Kubernetes的所有控制命令都发给它，它负责具体的执行过程，我们后 面执行的所有命令基本都是在Master上运行的。
2.2.Master运行关键组件
- Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接 口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作 的唯一入口，也是集群控制的入口进程。
- Kubernetes Controller Manager（kube-controller-manager）：Kubernetes所有资源对象的自动化控制中心，可以将其理解为资源对 象的“大总管”。
- Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod 调度）的进程，相当于公交公司的“调度室”。
- Kubernetes ETCD：在Master上通常还需要部署etcd服务，因为Kubernetes里的所 有资源对象的数据都被保存在etcd中。
3.Node
3.1.Node描述
Kubernetes集群中的其他机器被称为Node，与Master一样，Node可以是一台物理主机，也 可以是一台虚拟机。Node是Kubernetes集群中的工作负载节点，每个 Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机 时，其上的工作负载会被Master自动转移到其他节点上。
3.2.Node运行关键组件
- kubelet：负责Pod对应的容器的创建、启停等任务，同时与 Master密切协作，实现集群管理的基本功能。
- kube-proxy：实现Kubernetes Service的通信与负载均衡机制的 重要组件。
- Docker Engine（docker）：Docker引擎，负责本机的容器创建 和管理工作。
4.Pod
4.1.Pod描述
Kubernetes 的基本调度单位，Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。我们知道容器本质上就是进程，那么 Pod 实际上就是进程组了，只是这一组进程是作为一个整体来进行调度的。
4.2.Pod与容器的关系
在docker环境中每个容器都是一个进程，在k8s中pod就是一组进程。当通过k8s创建一个pod资源时，schedule调度器会调用某个node节点的kubelet控制docker启动两个容器，一个是业务的容器，一个就是pod容器。在一个pod上创建的多个业务容器都会共用这个pod上的ip地址。
在这里插入图片描述
- 查看pod上启动的两个类型的容器
nginx -g：pod中的业务容器每个pod中可以有多个。
/pod：是pod的根容器共享pod中容器的IP和Volume
5.Label
5.1.Label描述
Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被 附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对 象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的 资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后 动态添加或者删除。
6.Replication Controller
6.1.Replication Controller描述
RC（Replication Controller）是Kubernetes系统中的核心概念之一，简单来说，它其实定义了 一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预 期值，所以RC的定义包括如下几个部分。
- Pod期待的副本数量。
- 用于筛选目标Pod的Label Selector。
- 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板 （template）。
7.Deployment
7.1.Deployment描述
Deployment是Kubernetes在1.2版本中引入的新概念，用于更好地解 决Pod的编排问题。为此，Deployment在内部使用了Replica Set来实现目 的，无论从Deployment的作用与目的、YAML定义，还是从它的具体命 令行操作来看，我们都可以把它看作RC的一次升级，两者的相似度超 过90%。Deployment相对于RC的一个最大升级是我们可以随时知道当前 Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目 标Node上启动对应的容器这一完整过程需要一定的时间，所以我们期待 系统启动N个Pod副本的目标状态，实际上是一个连续变化的“部署过 程”导致的最终状态。
8.Horizontal Pod Autoscaler
8.1.Horizontal Pod Autoscaler描述
通过手工执行kubectl scale命令，我们可以实现Pod扩容或缩容。如 果仅仅到此为止，显然不符合谷歌对Kubernetes的定位目标—自动化、 智能化。在谷歌看来，分布式系统要能够根据当前负载的变化自动触发 水平扩容或缩容，因为这一过程可能是频繁发生的、不可预料的，所以 手动控制的方式是不现实的。因此，在Kubernetes的1.0版本实现后，就有人在默默研究Pod智能 扩容的特性了，并在Kubernetes 1.1中首次发布重量级新特性— Horizontal Pod Autoscaling（Pod横向自动扩容，HPA）。在Kubernetes 1.2中HPA被升级为稳定版本（apiVersion: autoscaling/v1），但仍然保留 了旧版本（apiVersion: extensions/v1beta1）。Kubernetes从1.6版本开 始，增强了根据应用自定义的指标进行自动扩容和缩容的功能，API版 本为autoscaling/v2alpha1，并不断演进。HPA与之前的RC、Deployment一样，也属于一种Kubernetes资源对 象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定 是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。
8.2.HPA度量指标方式
当前，HPA有以下两种方式作为Pod负载的度量指标。
- CPUUtilizationPercentage是一个算术平均值，即目标Pod所有副本自 身的CPU利用率的平均值。
- 应用程序自定义的度量指标，比如服务在每秒内的相应请求数 （TPS或QPS）。
9.Service
9.1.Service描述
Service服务也是Kubernetes里的核心资源对象之一，Kubernetes里的 每个Service其实就是我们经常提起的微服务架构中的一个微服务，之前 讲解Pod、RC等资源对象其实都是为讲解Kubernetes Service做铺垫的
9.2.Pod、RC与Service的逻辑关系
在这里插入图片描述
从图中可以看到，Kubernetes的Service定义了一个服务的访问 入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由 Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过 Label Selector来实现无缝对接的。RC的作用实际上是保证Service的服务 能力和服务质量始终符合预期标准。
10.Job
10.1.Job描述
批处理任务通常并行（或者串行）启动多个计算进程去处理一批工 作项（work item），在处理完成后，整个批处理任务结束。从1.2版本 开始，Kubernetes支持批处理类型的应用，我们可以通过Kubernetes Job 这种新的资源对象定义并启动一个批处理任务Job。与RC、 Deployment、ReplicaSet、DaemonSet类似，Job也控制一组Pod容器。从 这个角度来看，Job也是一种特殊的Pod副本自动控制器。
10.2. Job与RC等控制pod副本区别
- 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副本同时启动运算。
11.Volume
11.1.Volume描述
Volume（存储卷）是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似，但 两者不能等价。首先，Kubernetes中的Volume被定义在Pod上，然后被 一个Pod里的多个容器挂载到具体的文件目录下；其次，Kubernetes中的 Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终 止或者重启时，Volume中的数据也不会丢失。最后，Kubernetes支持多 种类型的Volume，例如GlusterFS、Ceph等先进的分布式文件系统。
11.2.Volume类型
- 1.emptyDir
一个emptyDir Volume是在Pod分配到Node时创建的。从它的名称就 可以看出，它的初始内容为空，并且无须指定宿主机上对应的目录文 件，因为这是Kubernetes自动分配的一个目录，当Pod从Node上移除 时，emptyDir中的数据也会被永久删除。
- 2.hostPath
hostPath为在Pod上挂载宿主机上的文件或目录，容器应用程序生成的日志文件需要永久保存时，可以使用宿主 机的高速文件系统进行存储。
- 3.gcePersistentDisk
使用这种类型的Volume表示使用谷歌公有云提供的永久磁盘
（Persistent Disk，PD）存放Volume的数据，它与emptyDir不同，PD上 的内容会被永久保存，当Pod被删除时，PD只是被卸载（Unmount）， 但不会被删除。需要注意的是，你需要先创建一个PD，才能使用 gcePersistentDisk。
- 4.awsElasticBlockStore
与GCE类似，该类型的Volume使用亚马逊公有云提供的EBS Volume存储数据，需要先创建一个EBS Volume才能使用 awsElasticBlockStore。
- 5.NFS
使用NFS网络文件系统提供的共享目录存储数据时，我们需要在系 统中部署一个NFS Server。
12.Persistent Volume
12.1.Persistent Volume描述
Volume是被定义在Pod上的，属于计算资源的一部分， 而实际上，网络存储是相对独立于计算资源而存在的一种实体资源。比 如在使用虚拟机的情况下，我们通常会先定义一个网络存储，然后从中 划出一个“网盘”并挂接到虚拟机上。Persistent Volume（PV）和与之相 关联的Persistent Volume Claim（PVC）也起到了类似的作用。
12.2.PV与Volume区别
- PV只能是网络存储，不属于任何Node，但可以在每个Node上 访问。
- PV并不是被定义在Pod上的，而是独立于Pod之外定义的。
- PV目前支持的类型包括：gcePersistentDisk、 AWSElasticBlockStore、AzureFile、AzureDisk、FC（Fibre Channel）、 Flocker、NFS、iSCSI、RBD（Rados Block Device）、CephFS、 Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath（仅供单机测 试）。
13.Namespace
13.1.Namespace描述
Namespace（命名空间）是Kubernetes系统中的另一个非常重要的概 念，Namespace在很多情况下用于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上 分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群 的资源的同时还能被分别管理。
14.Annotation
14.1.Annotation描述
Annotation（注解）与Label类似，也使用key/value键值对的形式进 行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对 象的元数据（Metadata），并且用于Label Selector。Annotation则是用户 任意定义的附加信息，以便于外部工具查找。在很多时候，Kubernetes 的模块自身会通过Annotation标记资源对象的一些特殊信息。
14.2.Annotation使用场景
- build信息、release信息、Docker镜像信息等，例如时间戳、 release id号、PR号、镜像Hash值、Docker Registry地址等。
- 日志库、监控库、分析库等资源库的地址信息。
- 程序调试工具信息，例如工具名称、版本号等。
- 团队的联系信息，例如电话号码、负责人名称、网址等。
15.ConfigMap
15.1.ConfigMap描述
为了能够准确和深刻理解Kubernetes ConfigMap的功能和价值，我 们需要从Docker说起。我们知道，Docker通过将程序、依赖库、数据及 配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用的部 署的难题，但这同时带来了棘手的问题，即配置文件中的参数在运行期 如何修改的问题。我们不可能在启动Docker容器后再修改容器里的配置 文件，然后用新的配置文件重启容器里的用户主进程。为了解决这个问 题，Kubernetes提供了一种内建机制，将存储在etcd中的 ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目 标Pod被调度到哪台服务器上，都会完成自动映射。进一步地，如果 ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会 随之自动更新。于是，Kubernetes ConfigMap就成了分布式系统中最为 简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中 心。
16.结束语
上述这些组件是Kubernetes系统的核心组件，它们共同构成了 Kubernetes系统的框架和计算模型。通过对它们进行灵活组合，用户就 可以快速、方便地对容器集群进行配置、创建和管理。