1.Kubernetes之Lable标签
Lable是kubernetes中的一个核心概念,一个lable是一个key=value的键值对,key与value由用户自己指定,lable可以附加到各种资源对象上,例如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Lable,同一个Lable也可以被添加到任意数量的资源对象上去,Lable通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除。
可以通过给一个资源对象绑定一个或多个不同的Lable来实现多维度的资源分组管理,例如,部署不同版本的应用到不同的环境中;或者监控和分析应用(日志记录、监控、告警)等。一些常用的标签示例如下:
- 版本标签 “release”:“stable”,“release”:“canary”。。。。。
- 环境标签 “environment”:"dev","environment":"production"
- 架构标签 "tier":"frontend","tier":"backend","tier":"middleware"
- 分区标签 "partition":"customerA"....
- 质量管控标签 "track":"daily","track":"weekly"
给资源对象定义一个Lable就相当于给他打了一个标签,随后可以通过Lable Selector(标签选择器)来查询和筛选拥有某些Lable的资源对象,kubernetes通过这种方式实现了类似SQL的对象查询机制。Lable Selector相当于SQL中的where查询条件,当前有两种Lable Selector的表达式:基于等式(equality-based)的和基于集合(set-based)的。
前者采用“等式类”的表达式匹配标签,如下示例:
- name = redis-slave:匹配所有具有标签name=redis-slave的资源对象
- env != production:匹配所有不具有标签env=production的资源对象
后者使用集合操作的表达式匹配标签,如下示例:
- name in (redis-master,redis-slave):匹配所有具有标签name=redis-master或者name=redis-slave的资源对象
- name not in (mysql-backend):匹配所有不具有标签name=mysql-backend的资源对象
可以通过多个lable selector表达式的组合实现复杂的条件选择,多个表达式之间用逗号","进行分隔即可,几个条件之间是“AND”的关系,即同时满足多个条件,如下示例:
- name=redis-master,env!=production
- 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中的重要使用场景有以下几处:
- kube-controller进程通过资源对象RC上定义的Lable Selector来筛选要监控的Pod副本的数量,从而实现Pod副本的数量始终符合预期设定的全自动控制流程
- kube-proxy进程通过Service的Lable Selector来选择对应的Pod,自动建立起每个Service到对应Pod的请求转发路由表,从而实现Service的智能负载均衡机制
- 通过对某些Node定义特定的Lable,并且在Pod定义文件中使用NodeSelector这种标签调度策略,kube-scheduler进程可以实现Pod “定向调度”的特性
2.Kubernetes之Replication Controller
Replication Controller在kubernetes中简称RC,它其实是定义了一个期望的场景,即声明某种Pod的副本数量在任意时刻都符合某个预期值,包括以下几个值:
- Pod期待的副本数(replicas)
- 用于筛选目标Pod的Lable Selector
- 当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中被称作 “滚动升级”。
原文地址:https://www.cnblogs.com/lemon-dog/p/12417048.html