前言

kubernates 1.3出了几个新的概念,其中包括deployments,Replica Sets,并且官网称之为是the next-generation Replication Controller。由于NCE项目马上就要使用其中包括deployments以及RS这个方式来管理pod,因此有必要了解下它的优越性。

回顾老版RC概念

说RC之前先要提一个container和pod,container就是docker中的容器,pod可以理解为一个或者一组container。pod中的container可以进行共享资源。 RC-Replication Controller是一种资源对象,它可以通过json模板来创建,通过模板中定义的pod模板(Templet)来创建相应的带Lable的pod。RC通过包含的标签选择器(Label selector)来管理所有带相应label的pod。 下面是一个RC的定义模板文件:

     "kind": "ReplicationController",
"apiVersion": "v1",
"metadata": {
"name": "haohua2aa22-13275-c059ac0f",
"namespace": "90ab293349704831aa3977c450235fe1",
"selfLink": "/api/v1/namespaces/90ab293349704831aa3977c450235fe1/replicationcontrollers/haohua2aa22-13275-c059ac0f",
"uid": "87ee2f1e-4f16-11e6-96bb-fa163e70fcd5",
"resourceVersion": "9565340",
"generation": 1,
"creationTimestamp": "2016-07-21T07:41:26Z",
"labels": {
"name": "haohua2aa22-13275-c059ac0f"
}
},
"spec": {
"replicas": 1,
"selector": {
"name": "haohua2aa22-13275-c059ac0f"
},
"podCreatePolicy": "New",
"template": {
"metadata": {
"name": "haohua2aa22-13275-c059ac0f",
"namespace": "90ab293349704831aa3977c450235fe1",
"creationTimestamp": null,
"labels": {
"name": "haohua2aa22-13275-c059ac0f"
}
},
"spec": {
"containers": [
{
...(此处省略)
],
}
],
}
}

可以看到这个RC里面包含了一个容器的pod:haohua2aa22-13275-c059ac0f,该pod有1个副本( "replicas": 1,)。 pod的模板文件中有一个labels标识pod是属于哪个rc

  "labels": {
"name": "haohua2aa22-13275-c059ac0f"
},

RC内pod变更大概有几种场景:

1.通过设置副本个数可以动态的调整pod资源,如果将replicas设置为2,则控制器会自动去创建一个pod并且标签也设置为haohua2aa22-13275-c059ac0f。

2.如果想删除资源,则需要将replicas设置为0,这时候控制器就会自动删除pod副本资源。需要注意如果直接删除RC,pod资源是不会被清理的。

3.如果想更新service内rc中的pod,则需要用rolling Updates滚动更新模式,即逐个替换pod的方式来支持service的滚动更新,新建一个只有1个pod的rc,若新的rc副本数量加1,则旧的rc副本数减1,直到旧的rc副本数量为0,则删除旧的rc。

deployments&RS概念

deployments是用来为pods和Replica Sets提供更新用的。Replica Sets被官网称之为下一代的RC,可见取而代之的决心,Replica Set 和Replication Controller仅有的区别是slector的支持,RS支持新的基于集合( set-based)的选择器,而RC只支持基于相等( equality-based )的选择器。

这边的两个概念基于集合( set-based);基于相等( equality-based ) 怎么来理解呢。

基于相等的就是说只能通过两种操作来设置:

environment = production
tier != frontend

基于集合的不只是包含等于和不等于两种规则,还可以包含 in 和notin的方式来筛选。

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

下面来看看kubernetes 1.3的deployments是如何用模板文件定义的 这是一个官网的3的deployments是如何用模板文件定义的例子,我在1.3的环境下试着用命令创建了1个deployment

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
 kubectl create -f /root/cxq/jsonxml/nginx-deployment.yaml
deployment "nginx-deployment" created
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 0 12s

这个时候查询当前的rs,发现多了一个名字跟deployment有点关联性的rs

root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get rs
NAME DESIRED CURRENT AGE
nginx-deployment-1159050644 3 3 8m

在后面随机加了一串数字。 检查rs的json说明文件,看下跟之前的rc有什么区别【重点在此,请注意】

kubectl get rs -o json
{
"kind": "List",
"apiVersion": "v1",
"metadata": {},
"items": [
{
"kind": "ReplicaSet",
"apiVersion": "extensions/v1beta1",
"metadata": {
"name": "nginx-deployment-1159050644",
"namespace": "default",
"selfLink": "/apis/extensions/v1beta1/namespaces/default/replicasets/nginx-deployment-1159050644",
"uid": "57fd01cc-4f29-11e6-9cce-fa163ee959c4",
"resourceVersion": "179452",
"generation": 1,
"creationTimestamp": "2016-07-21T09:56:06Z",
"labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
},
"annotations": {
"deployment.kubernetes.io/revision": "1"
}
},
"spec": {
"replicas": 3,
"selector": {
"matchLabels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}
},
"spec": {
"containers": [
{
...(此处省略)
}
}
},
}
]
}

可以看到labels的值不是只有一条name:value的格式,而是有两条。

 "labels": {
"app": "nginx",
"pod-template-hash": "1159050644"
}

说明app=nginx或者包含nginx的都可以被筛选出来作为rs的pod 查看pod,并且模拟selector的筛选方式实验一下

当前系统有4个pod,其中前3个属于新建的rs
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 4m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 4m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225
test-5-5tcql 1/1 Running 0 1d 192.168.5.2 10.180.217.225

使用过滤器equality-based方法筛选,可以准确的筛选出来3条app=nginx的pod

root@qa-control-master2-cluster-21:~/cxq/jsonxml#  kubectl get pod -o wide -l  app=nginx
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 5m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 5m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225

使用过滤器set-based方式筛选,看下能否筛选出来

使用in的规则筛选,则筛选出app中包含nginx的pod
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get pod -o wide -l 'app in (nginx)'
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-1159050644-kg654 1/1 Running 0 6m 192.168.5.10 10.180.217.225
nginx-deployment-1159050644-x6wk8 1/1 Running 0 6m 192.168.5.8 10.180.217.225
nginx-deployment-1159050644-z2kqi 1/1 Running 0 3h 192.168.5.6 10.180.217.225
使用notin规则,筛选出来app不包含nginx的pod(剩余的1条)
root@qa-control-master2-cluster-21:~/cxq/jsonxml# kubectl get pod -o wide -l 'app notin (nginx)'
NAME READY STATUS RESTARTS AGE IP NODE
test-5-5tcql 1/1 Running 0 1d 192.168.5.2 10.180.217.225

总结

简单来说 rs的selector选择器多了两种除了相等和非相等之外的筛选模式,使得筛选和管理pod更为灵活。

本文来自网易云社区,经作者崔晓晴授权发布。

原文地址:kubernetes 1.3管中窥豹- RS(Replica Sets):the next-generation Replication Controller

更多网易研发、产品、运营经验分享请访问网易云社区

kubernetes 1.3管中窥豹- RS(Replica Sets):the next-generation Replication Controller的更多相关文章

  1. Replication Controller、Replica Set

    假如我们现在有一个Pod正在提供线上的服务,我们来想想一下我们可能会遇到的一些场景: 某次运营活动非常成功,网站访问量突然暴增 运行当前Pod的节点发生故障了,Pod不能正常提供服务了 第一种情况,可 ...

  2. kubernetes进阶之五:Replication Controller&Replica Sets&Deployments

    一:Replication Controller RC是kubernetes的核心概念之一.它定义了一个期望的场景即声明某种Pod的副本数量在任意时候都要符合某个预期值. 它由以下几个部分组成: 1. ...

  3. 利用Mongodb的复制集搭建高可用分片,Replica Sets + Sharding的搭建过程

    参考资料 reference:  http://mongodb.blog.51cto.com/1071559/740131  http://docs.mongodb.org/manual/tutori ...

  4. Simple Automated Backups for MongoDB Replica Sets

    There are a bunch of different methods you can use to back up your MongoDB data, but if you want to ...

  5. 管理维护Replica Sets

    1.读写分离 有一些第三方的工具,提供了一些可以让数据库进行读写分离的工具.我们现在是否有一个疑问,从库要是能进行查询就更好了,这样可以分担主库的大量的查询请求. 1. 先向主库中插入一条测试数据 2 ...

  6. 部署Replica Sets及查看相关配置

    MongoDB 支持在多个机器中通过异步复制达到故障转移和实现冗余.多机器中同一时刻只有一台是用于写操作.正是由于这个情况,为MongoDB 提供了数据一致性的保障.担当Primary 角色的机器能把 ...

  7. Mongo之架构部署(Replica Sets+Sharding)

    一.环境 要构建一个 MongoDB Sharding Cluster,需要三种角色: •Shard Server: mongod 实例,用于存储实际的数据块. •Config Server: mon ...

  8. 第39章:MongoDB-集群--Replica Sets(副本集)---副本集基本原理

    ①操作日志oplog Oplog是主节点的local数据库中的一个固定集合,按顺序记录了主节点的每一次写操作,MongoDB的复制功能是使用oplog来实现的,备份节点通过查询这个集合就可以知道需要进 ...

  9. Mongodb集群搭建之 Sharding+ Replica Sets集群架构

    1.本例使用1台Linux主机,通过Docker 启动三个容器 IP地址如下: docker run -d -v `pwd`/data/master:/mongodb -p 27017:27017 d ...

随机推荐

  1. C#根据字体名通过注册表获取该字体文件路径(win10)两种方法推荐第二种

    方法一: 直接先上源码: private System.Collections.Generic.SortedDictionary<string, string> ReadFontInfor ...

  2. Bash读取/etc/passwd的特殊技巧

    在twitter上看到的,记录一下: 可以bypass基于正则的规则,这里还可以引申出其他的bypass方法,

  3. 微信小程序之本地缓存

    目前,微信给每个小程序提供了10M的本地缓存空间(哎哟妈呀好大) 有了本地缓存,你的小程序可以做到: 离线应用(已测试在无网络的情况下,可以操作缓存数据) 流畅的用户体验 减少网络请求,节省服务器资源 ...

  4. CNN感受野计算

    无痛理解CNN中的感受野receptive field CNN中感受野的计算 从直观上讲,感受野就是视觉感受区域的大小.在卷积神经网络中,感受野的定义是决定某一层输出结果中一个元素所对应的输入层的区域 ...

  5. 完美解决HALCON C#编程目标平台冲突问题

    完美解决HALCON C#编程目标平台冲突问题   楼主# 更多发布于:2016-11-23 10:06     背景: 目标机器工控机使用11.0.1 32位Halcon 原因你懂的.开发环境Win ...

  6. Libevent使用例子,从简单到复杂

    转载请注明出处:http://blog.csdn.net/luotuo44/article/details/39670221 本文从简单到复杂,展示如何使用libevent.网上的许多例子都是只有服务 ...

  7. MongoDB安全加固方案,防止数据泄露被勒索

    早上起来,发现生产数据库被删了,留下一个数据库名叫“PLEASE_READ”,里面内容如下: "Info" : "Your DB is Backed up at our ...

  8. VS 配置外部DLL的引用路径【可执行文件的环境路径】

    右键项目,属性->配置属性->调试->环境,在这里写入可执行文件运行时的环境路径,格式为:PATH=ABC,如PATH=$(SolutionDir)/env 这样,我们就可以把运行时 ...

  9. Hadoop之HDFS(二)HDFS基本原理

    HDFS 基本 原理 1,为什么选择 HDFS 存储数据  之所以选择 HDFS 存储数据,因为 HDFS 具有以下优点: 1.高容错性 数据自动保存多个副本.它通过增加副本的形式,提高容错性. 某一 ...

  10. java基础之多线程四:简单案例

    多线程案例: 有一个包包的数量为100个,分别从实体店和官网进行售卖.使用多线程的方式,分别打印实体店和官网卖出包包的信息.分别统计官网和实体店各卖出了多少个包包 第一种方法 继承Thread类: p ...