Kubernetes基本概念和术语之Lable和Replication Controller

1.Kubernetes之Lable标签

Lable是kubernetes中的一个核心概念,一个lable是一个key=value的键值对,key与value由用户自己指定,lable可以附加到各种资源对象上,例如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Lable,同一个Lable也可以被添加到任意数量的资源对象上去,Lable通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除。

可以通过给一个资源对象绑定一个或多个不同的Lable来实现多维度的资源分组管理,例如,部署不同版本的应用到不同的环境中;或者监控和分析应用(日志记录、监控、告警)等。一些常用的标签示例如下:

  1. 版本标签   “release”:“stable”,“release”:“canary”。。。。。
  2. 环境标签    “environment”:"dev","environment":"production"
  3. 架构标签   "tier":"frontend","tier":"backend","tier":"middleware"
  4. 分区标签   "partition":"customerA"....
  5. 质量管控标签  "track":"daily","track":"weekly"

给资源对象定义一个Lable就相当于给他打了一个标签,随后可以通过Lable Selector(标签选择器)来查询和筛选拥有某些Lable的资源对象,kubernetes通过这种方式实现了类似SQL的对象查询机制。Lable Selector相当于SQL中的where查询条件,当前有两种Lable Selector的表达式:基于等式(equality-based)的和基于集合(set-based)的。

前者采用“等式类”的表达式匹配标签,如下示例:

  1. name = redis-slave:匹配所有具有标签name=redis-slave的资源对象
  2. env != production:匹配所有不具有标签env=production的资源对象

后者使用集合操作的表达式匹配标签,如下示例:

  1. name in (redis-master,redis-slave):匹配所有具有标签name=redis-master或者name=redis-slave的资源对象
  2. name not in (mysql-backend):匹配所有不具有标签name=mysql-backend的资源对象

可以通过多个lable selector表达式的组合实现复杂的条件选择,多个表达式之间用逗号","进行分隔即可,几个条件之间是“AND”的关系,即同时满足多个条件,如下示例:

  1. name=redis-master,env!=production
  2. name in (redis-master,redis-slave),env!=production

通常,我们给一个Pod定义一个lable,如下:

apiVersion: v1

kind: pod

metadata:

   name:  myweb

   lables:

      app:  myweb

管理对象RC和Service在spec中定义Selector与Pod进行关联:

apiVersion: v1

kind:   ReplicationController

metadata:

   name:  myweb

spec:

  replicas:  1

  selector:

      app:  myweb

apiVersion: v1

kind:   Service

metadata:

   name:  myweb

spec:

  selector:

      app:  myweb

  ports:

  - port:  8080

新出现的管理对象如Deployment、ReplicaSet、DaemonSet何Job则可以在selector中使用基于集合的筛选条件定义,如下:

selector:

   matchLables:

       app: myweb

   matchExpressions:

       -  {key: tier,operator: In,values: [frontend]}

matchLables用于定义一组Lable,与直接写在Selector中作用相同,matchExpressions用于定义一组基于集合的筛选条件,可用的条件运算符包括:In,NotIn,Exists,DoesNotExist

如果同时设置了matchLables和matchExpressions,则两组条件为“AND”关系,需要同时满足才能完成selector的筛选。

Lable selector在kubernetes中的重要使用场景有以下几处:

  1. kube-controller进程通过资源对象RC上定义的Lable Selector来筛选要监控的Pod副本的数量,从而实现Pod副本的数量始终符合预期设定的全自动控制流程
  2. kube-proxy进程通过Service的Lable Selector来选择对应的Pod,自动建立起每个Service到对应Pod的请求转发路由表,从而实现Service的智能负载均衡机制
  3. 通过对某些Node定义特定的Lable,并且在Pod定义文件中使用NodeSelector这种标签调度策略,kube-scheduler进程可以实现Pod “定向调度”的特性

2.Kubernetes之Replication Controller

Replication Controller在kubernetes中简称RC,它其实是定义了一个期望的场景,即声明某种Pod的副本数量在任意时刻都符合某个预期值,包括以下几个值:

  1. Pod期待的副本数(replicas)
  2. 用于筛选目标Pod的Lable Selector
  3. 当Pod的副本数量小于预期数量时,用于创建新Pod的模板(template)

当我们定义了一个RC并提交到kubernetes后,Master节点上的Controller Manager组件就得到通知,定期巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于replicas的值,如果多于这个值,系统就会停掉一些Pod,少之则会创建一些Pod。可以说,通过RC,kubernetes实现了用户应用集群的高可用性,减少了许多手工的运维操作

通过RC,我们可以动态的进行Pod实例数的缩放,kubectl scale命令为我们提供了这一功能

kubectl scale rc redis-slave --replicas=3

需要注意的是,删除RC并不会影响通过该RC已经创建好的Pod,为了删除所有Pod,可以通过设置replicas的值为0,然后更新该RC。另外kubectl提供了stop和delete命令来一次性删除RC和RC控制的所有Pod

RC也提供用户应用平滑升级的功能,比如当前系统中有10个旧版本的Pod需要更新到新版,最好的方式是每次停止一个旧版本的Pod,就创建一个新版本的Pod,几分钟后当所有的Pod都是新版本时升级完成,用户不会感受到业务有任何影响,这种在kubernetes中被称作 “滚动升级”。

相关推荐