Kubernetes基本概念和术语之Lable和Replication Controller
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中被称作 “滚动升级”。