Replication Controller

RC保证在同一时间能够运行指定数量的Pod副本,保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的,如果实际数量比指定的少就启动缺少的。

当Pod失败、被删除或被终结时,RC会自动创建新的Pod来保证副本数量,所以即使只有一个Pod,也应该使用RC来进行管理。

来个简单例子:

 1 apiVersion: v1
 2 kind: ReplicationController  //ReplicationController类型
 3 metadata:
 4   name: nginx               //pod名字
 5 spec:
 6   replicas: 2               //2个副本
 7   selector:
 8     app: nginx              //通过这个标签找到生成的pod
 9   template:                 //定义pod模板,在这里不需要定义pod名字,就算定义创建的时候也不会采用这个名字而是.metadata.generateName+5位随机数。
10     metadata:
11      labels:                //定义标签
12       app: nginx            //key:v   这里必须和selector中定义的KV一样
13     spec:
14      containers:            //rc 的容器重启策略必须是Always(总是重启),这样才能保证容器的副本数正确
15       - image: nginx
16         name: nginx
17         ports:
18         - containerPort: 80

提示:

K8S 通过template来生成pod,创建完后模板和pod就没有任何关系了,rc通过 labels来找对应的pod,控制副本

查询rc

[[email protected] pods]# kubectl get rc nginx
NAME DESIRED CURRENT READY AGE
nginx      2              2                2        1m

查询pod容器

[[email protected] pods]# kubectl get pod --selector app=nginx

NAME           READY       STATUS        RESTARTS          AGE
nginx-2jhlv      1/1              Running              0                     2m
nginx-hbtqj     1/1               Running              0                     2m

同时查询rc和rc创建的pod
[[email protected] pods]# kubectl get pod --selector app=nginx --label-columns app
NAME           READY            STATUS           RESTARTS          AGE       APP
nginx-2jhlv      1/1                  Running                 0                     2m       nginx
nginx-hbtqj     1/1                  Running                  0                    2m        nginx

删除pod会后会立刻在拉起一个pod

删除rc后pod也被删除(--cascade=false只删除rc保留创建的pod)

[[email protected] pods]# kubectl delete rc nginx
replicationcontroller "nginx" deleted

模板和RC可意分别定义

1先定义一个模板,然后创建

 1 apiVersion: v1
 2 kind: PodTemplate
 3 metadata:
 4   name: my-nginx
 5 template:
 6     metadata:
 7      labels:
 8       app: nginx
 9     spec:
10      containers:
11       - image: nginx
12         name: nginx
13         ports:
14         - containerPort: 80

创建后并不会把pod拉起来

[[email protected] pods]# kubectl create -f template.yml
podtemplate "my-nginx" created

查看模板池

2定义rc

1 apiVersion: v1
2 kind: ReplicationController
3 metadata:
4   name: my-nginx
5 spec:
6  replicas: 2
7  templateRef:
8     app: nginx        

这个暂时有问题还无法通过RC拉起来templatekubectl create -f rc.yml

修改rc模式下的一个pod label

[[email protected] pods]# kubectl label pod nginx-qqf16 app=debug --overwrite
pod "nginx-qqf16" labeled

当修改一个pod标签后就摆脱RC控制了,如果将标签在改回去那么将有一个POD被干掉,超过了RC最大副本数

将标签改回去

时间: 2024-09-29 21:04:19

Replication Controller的相关文章

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

1.Kubernetes之Lable标签 Lable是kubernetes中的一个核心概念,一个lable是一个key=value的键值对,key与value由用户自己指定,lable可以附加到各种资源对象上,例如Node.Pod.Service.RC等,一个资源对象可以定义任意数量的Lable,同一个Lable也可以被添加到任意数量的资源对象上去,Lable通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除. 可以通过给一个资源对象绑定一个或多个不同的Lable来实现多维度的资源分组

Kubenete study notes (Replication Controller)

Replication controller: ReplicationController schedules pod to one work node, kubelet application in node pulls image and create containers.Pod started by "kubectl run" is not created directly. ReplicationController is created by command and rep

k8s实践(四):Controller

环境说明: 主机名 操作系统版本 ip docker version kubelet version 配置 备注 master Centos 7.6.1810 172.27.9.131 Docker 18.09.6 V1.14.2 2C2G 备注 node01 Centos 7.6.1810 172.27.9.135 Docker 18.09.6 V1.14.2 2C2G 备注 node02 Centos 7.6.1810 172.27.9.136 Docker 18.09.6 V1.14.2

基于CentOS7.2安装Kubernetes-v1.2

摘要 使用swarm构建docker集群之后我们发现面临很多问题 swarm虽好但是还处于发展阶段功能上有所不足 我们使用kubernetes来解决这个问题 kubernetes 与swarm 比较 优点 复制集与健康维护 服务自发现与负载均衡 灰度升级 垃圾回收 自动回收失效镜像与容器 与容器引擎解耦 不仅仅支持docker容器 用户认证与资源隔离 缺点 大而全意味着 复杂度较高 从部署到使用都比swarm 复杂的多 相对而已swarm比较轻量级 而且跟docker引擎配合的更好 从精神上我是

Kubernetes基本概念

Basic knowledge 第一:docker是一款开源的容器,其实这个技术并不新鲜.早期在linux中就有LXC这样的轻量级的虚拟化系统.Docker其实只是换了一种语言来实现而已.Kubernetes意思是航海的舵手,它是docker的一款具有强大功能的编排+监控+灾备+负载管理系统 第二:kubernetes是基于google十五年的容器使用经验的总结和最佳实践,是google内部使用的borg系统的开源版本.改善了docker中很多的不足,可以说是与docker互补的一项技术. 第三

Kafka设计解析(四)- Kafka Consumer设计解析

本文转发自Jason’s Blog,原文链接 http://www.jasongj.com/2015/08/09/KafkaColumn4 摘要 本文主要介绍了Kafka High Level Consumer,Consumer Group,Consumer Rebalance,Low Level Consumer实现的语义,以及适用场景.以及未来版本中对High Level Consumer的重新设计–使用Consumer Coordinator解决Split Brain和Herd等问题. H

Apache的Mesos和Google的Kubernetes 有什么区别?

Apache的Mesos和Google的Kubernetes 有什么区别?本文来自StackOverFlow上的一个问题,主要讨论Mesos和Kubernetes的区别,相信我们很多人也有同意的疑问. Kubernetes的开发者Craig回答了这个问题,同时masi也做了概述,不一定对,供读者参考.Kubernetes主要针对容器集群,而 Mesos适用于任何的框架和应用,所以Kubernetes可以运行于Mesos上. Kubernetes是一个开源项目,它把谷歌的集群管理工具引入到虚拟机和

Kafka学习之一深度解析

背景介绍 Kafka简介 Kafka是一种分布式的,基于发布/订阅的消息系统.主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率.即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输 同时支持离线数据处理和实时数据处理 为什么要用消息系统 解耦在项目启动之初来预测将来项目会碰到什么需求,是极其困难的.消息队

kubernetes多节点部署解析

注:以下操作均基于centos7系统. 安装ansible ansilbe可以通过yum或者pip安装,由于kubernetes-ansible用到了密码,故而还需要安装sshpass: pip install ansible wget http://sourceforge.net/projects/sshpass/files/latest/download tar zxvf download cd sshpass-1.05 ./configure && make && m