k8s基础概念

Kubernetes中的大部分概念如Node、Pod、Replication Controller、 Service等都可以被看作一种资源对象，几乎所有资源对象都可以通过 Kubernetes提供的kubectl工具（或者API编程调用）执行增、删、改、查    等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes其实是一个高度自动化的资源控制系统，它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

1、在Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征。

◎ 拥有唯一指定的名称（比如mysql-server）。
◎ 拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号。
◎ 能够提供某种远程服务能力。
◎ 被映射到提供这种服务能力的一组容器应用上。

Service的服务进程目前都基于Socket通信方式对外提供服务，虽然一个Service通常由多个相关的服务进程提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过Service（虚拟Cluster IP +Service Port）连接到指定的Service。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否由于发生故障而被重新部署到其他机器，都不会影响对服务的正常调用。更重要的是，这个Service本身一旦创建就不再变化，这意味着我们再也不用为Kubernetes集群中服务的IP地址变来变去的问题而头疼了。

 

 

 

 

 

 

◎ Node IP：Node的IP地址。
◎ Pod IP：Pod的IP地址。
◎ Cluster IP：Service的IP地址。

 首先，Node IP是Kubernetes集群中每个节点的物理网卡的IP地址， 是一个真实存在的物理网络，所有属于这个网络的服务器都能通过这个 网络直接通信，不管其中是否有部分节点不属于这个Kubernetes集群。 这也表明在Kubernetes集群之外的节点访问Kubernetes集群之内的某个节 点或者TCP/IP服务时，都必须通过Node IP通信。

其次，Pod IP是每个Pod的IP地址，它是Docker Engine根据docker0 网桥的IP地址段进行分配的，通常是一个虚拟的二层网络，前面说过， Kubernetes要求位于不同Node上的Pod都能够彼此直接通信，所以 Kubernetes里一个Pod里的容器访问另外一个Pod里的容器时，就是通过 Pod IP所在的虚拟二层网络进行通信的，而真实的TCP/IP流量是通过 Node IP所在的物理网卡流出的。

最后说说Service的Cluster IP，它也是一种虚拟的IP，但更像一 个“伪造”的IP网络，原因有以下几点。

◎ Cluster IP仅仅作用于Kubernetes Service这个对象，并由 Kubernetes管理和分配IP地址（来源于Cluster IP地址池）。

◎ Cluster IP无法被Ping，因为没有一个“实体网络对象”来响应。

◎ Cluster IP只能结合Service Port组成一个具体的通信端口，单独 的Cluster IP不具备TCP/IP通信的基础，并且它们属于Kubernetes集群这 样一个封闭的空间，集群外的节点如果要访问这个通信端口，则需要做 一些额外的工作。

◎ 在Kubernetes集群内，Node IP网、Pod IP网与Cluster IP网之间 的通信，采用的是Kubernetes自己设计的一种编程方式的特殊路由规 则，与我们熟知的IP路由有很大的不同。

 

 

 

 

 

 想做到自动负载均衡，如果我们的集群运行在谷歌的 公有云GCE上，那么只要把Service的type=NodePort改为 type=LoadBalancer，Kubernetes就会自动创建一个对应的Load balancer实 例并返回它的IP地址供外部客户端使用。其他公有云提供商只要实现了 支持此特性的驱动，则也可以达到上述目的。此外，裸机上的类似机制 （Bare Metal Service Load Balancers）也在被开发。

 

2、Kubernetes将集群中的机器划分为一个Master和一些Node。

Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它负责具体的执行过程，我们后面执行的所有命令基本都是在Master上运行的。Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），主要原因是它太重要了，是整个集群的“首脑”，如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。在Master上运行着以下关键进程。

◎ Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接
口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作
的唯一入口，也是集群控制的入口进程。
◎ Kubernetes Controller Manager（kube-controller-manager）：
Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对
象的“大总管”。
◎ Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod
调度）的进程，相当于公交公司的“调度室”。
另外，在Master上通常还需要部署etcd服务，因为Kubernetes里的所
有资源对象的数据都被保存在etcd中。

Node是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。在每个Node上都运行着以下关键进程。

◎ kubelet：负责Pod对应的容器的创建、启停等任务，同时与
Master密切协作，实现集群管理的基本功能。
◎ kube-proxy：实现Kubernetes Service的通信与负载均衡机制的
重要组件。
◎ Docker Engine（docker）：Docker引擎，负责本机的容器创建
和管理工作。

Node可以在运行期间动态增加到Kubernetes集群中，前提是在这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为“失联”，Node的状态被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程。

3、pod：

Pod运行在一个被称为节点（Node）的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的一个虚拟机，通常在一个节点上运行几百个Pod；其次，在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中；最后，需要注意的是，并不是每个Pod和它里面运行的容器都能被映射到一个Service上，只有提供服务（无论是对内还是对外）的那组Pod才会被映射为一个服务。

Kubernetes为每个Pod都分配了唯一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP地址。在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

 

 

 Kubernetes里的所有资源对象都可以采用YAML或者JSON格式的文
件来定义或描述

下 图中是一个MySQL的pod：

 

4、Label

Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，如下图例子：

 

 

 matchLabels用于定义一组Label，与直接写在Selector中的作用相 同；matchExpressions用于定义一组基于集合的筛选条件，可用的条件 运算符包括In、NotIn、Exists和DoesNotExist。 如果同时设置了matchLabels和matchExpressions，则两组条件为 AND关系，即需要同时满足所有条件才能完成Selector的筛选。

 

 

5、Replication Controller

对Replication Controller（简称RC），简单来说，它其实定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下几个部分。

◎ Pod期待的副本数量。
◎ 用于筛选目标Pod的Label Selector。
◎ 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板
（template）。

 

 

 

 如果有过多 的Pod副本在运行，系统就会停掉一些Pod，否则系统会再自动创建一些 Pod。在运行时，我们可以通过修改RC的副本数量，来实现Pod的 动态缩放（Scaling），这可以通过执行kubectl scale命令来一键完成：

 

 

 

需要注意的是，删除RC并不会影响通过该RC已创建好的Pod。为 了删除所有Pod，可以设置replicas的值为0，然后更新该RC。

 

 

 最后总结一下RC（Replica Set）的一些特性与作用。 ◎ 在大多数情况下，我们通过定义一个RC实现Pod的创建及副本 数量的自动控制。 ◎ 在RC里包括完整的Pod定义模板。 ◎ RC通过Label Selector机制实现对Pod副本的自动控制。 ◎ 通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容。 ◎ 通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升 级。

6、Deployment

我们都可以把Deployment看作RC的一次升级，两者的相似度超 过90%。

 Deployment的典型使用场景有以下几个。

◎ 创建一个Deployment对象来生成对应的Replica Set并完成Pod副 本的创建。

◎ 检查Deployment的状态来看部署动作是否完成（Pod副本数量 是否达到预期的值）。

◎ 更新Deployment以创建新的Pod（比如镜像升级）。

◎ 如果当前Deployment不稳定，则回滚到一个早先的Deployment 版本。

◎ 暂停Deployment以便于一次性修改多个PodTemplateSpec的配 置项，之后再恢复Deployment，进行新的发布。

◎ 扩展Deployment以应对高负载。

◎ 查看Deployment的状态，以此作为发布是否成功的指标。

◎ 清理不再需要的旧版本ReplicaSets。

 

 

 

 

 

 

 

 

 7、Horizontal Pod Autoscaler

HPA与之前的RC、Deployment一样，也属于一种Kubernetes资源对 象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定 是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。

当前，HPA有以下两种方式作为Pod负载的度量指标。

◎ CPUUtilizationPercentage。

◎ 应用程序自定义的度量指标，比如服务在每秒内的相应请求数 （TPS或QPS）。

 

 

 8、StatefulSet

在Kubernetes系统中，Pod的管理对象RC、Deployment、DaemonSet 和Job都面向无状态的服务。但现实中有很多服务是有状态的，特别是 一些复杂的中间件集群，例如MySQL集群、MongoDB集群、Akka集 群、ZooKeeper集群等。

◎ StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来 发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod 叫kafka-0，第2个叫kafka-1，以此类推。

◎ StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod 时，前n-1个Pod已经是运行且准备好的状态。

◎ StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来 实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数 据的安全）。

 

9、job

 我们可以通过Kubernetes Job 这种新的资源对象定义并启动一个批处理任务Job。与RC、 Deployment、ReplicaSet、DaemonSet类似，Job也控制一组Pod容器。从 这个角度来看，Job也是一种特殊的Pod副本自动控制器，同时Job控制 Pod副本与RC等控制器的工作机制有以下重要差别。

（1）Job所控制的Pod副本是短暂运行的，可以将其视为一组 Docker容器，其中的每个Docker容器都仅仅运行一次。当Job控制的所 有Pod副本都运行结束时，对应的Job也就结束了。Job在实现方式上与 RC等副本控制器不同，Job生成的Pod副本是不能自动重启的，对应Pod 副本的RestartPoliy都被设置为Never。因此，当对应的Pod副本都执行完 成时，相应的Job也就完成了控制使命，即Job生成的Pod在Kubernetes中 是短暂存在的。Kubernetes在1.5版本之后又提供了类似crontab的定时任 务——CronJob，解决了某些批处理任务需要定时反复执行的问题。

（2）Job所控制的Pod副本的工作模式能够多实例并行计算，以 TensorFlow框架为例，可以将一个机器学习的计算任务分布到10台机器 上，在每台机器上都运行一个worker执行计算任务，这很适合通过Job 生成10个Pod副本同时启动运算。

10、Volume

Volume（存储卷）是Pod中能够被多个容器访问的共享目录。

首先，Kubernetes中的Volume被定义在Pod上，然后被 一个Pod里的多个容器挂载到具体的文件目录下；其次，Kubernetes中的 Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终 止或者重启时，Volume中的数据也不会丢失。最后，Kubernetes支持多 种类型的Volume，例如GlusterFS、Ceph等先进的分布式文件系统。

Volume的使用也比较简单，在大多数情况下，我们先在Pod上声明 一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的 某个目录上。

 

 11、Persistent Volume

之前提到的Volume是被定义在Pod上的，属于计算资源的一部分，PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存 储，它与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（仅供单机测 试）。

 

 

 

 12、Namespace

Namespace（命名空间）是Kubernetes系统中的另一个非常重要的概 念，Namespace在很多情况下用于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上 分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群 的资源的同时还能被分别管理。

 

 接下来，如果不特别指明Namespace，则用户创建的Pod、RC、 Service都将被系统创建到这个默认的名为default的Namespace中。

 

 

 

 13、Annotation

Annotation（注解）与Label类似，也使用key/value键值对的形式进 行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对 象的元数据（Metadata），并且用于Label Selector。Annotation则是用户 任意定义的附加信息，以便于外部工具查找。在很多时候，Kubernetes 的模块自身会通过Annotation标记资源对象的一些特殊信息。

通常来说，用Annotation来记录的信息如下。

◎ build信息、release信息、Docker镜像信息等，例如时间戳、 release id号、PR号、镜像Hash值、Docker Registry地址等。

◎ 日志库、监控库、分析库等资源库的地址信息。

◎ 程序调试工具信息，例如工具名称、版本号等。

◎ 团队的联系信息，例如电话号码、负责人名称、网址等。

14、ConfigMap