K8S 控制器Replicaset
# 我们在定义pod资源时,可以直接创建一个kind:Pod类型的自主式pod,但是这存在一个问题,假如pod被删除了,那这个pod就不能自我恢复,就会彻底被删除,线上这种情况非常危险,所以今天就给大家讲解下pod的控制器,所谓控制器就是能够管理pod,监测pod运行状况,当pod发生故障,可以自动恢复pod。也就是说能够代我们去管理pod中间层,并帮助我们确保每一个pod资源始终处于我们所定义或者我们所期望的目标状态,一旦pod资源出现故障,那么控制器会尝试重启pod或者里面的容器,如果一直重启有问题的话那么它可能会基于某种策略来进行重新布派或者重新编排;如果pod副本数量低于用户所定义的目标数量,它也会自动补全;如果多余,也会自动终止pod资源。
kubectl explain rs
Replicaset组成部分
1. 用户期望的pod副本数:用来定义由这个控制器管控的pod副本有几个
2. 标签选择器:选定哪些pod是自己管理的,如果通过标签选择器选到的pod副本数量少于我们指定的数量,需要用到下面的组件
3. pod资源模板:如果集群中现存的pod数量不够我们定义的副本中期望的数量怎么办,需要新建pod,这就需要pod模板,新建的pod是基于模板来创建的。
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
namespace: default
labels:
app: guestbook
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier1: frontend1
# template就相当于定义pod的配置
template:
metadata:
labels:
tier1: frontend1
spec:
containers:
- name: php-redis
image: docker.io/yecc/gcr.io-google_samples-gb-frontend:v3
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
# 探测http://localhost:80
startupProbe:
periodSeconds: 5
initialDelaySeconds: 20
timeoutSeconds: 10
httpGet:
scheme: HTTP
port: 80
path: /
livenessProbe:
periodSeconds: 5
initialDelaySeconds: 20
timeoutSeconds: 10
httpGet:
scheme: HTTP
port: 80
path: /
readinessProbe:
periodSeconds: 5
initialDelaySeconds: 20
timeoutSeconds: 10
httpGet:
scheme: HTTP
port: 80
path: /
#资源清单详细说明
apiVersion: apps/v1 #ReplicaSet 这个控制器属于的核心群组
kind: ReplicaSet #创建的资源类型
metadata:
name: frontend #控制器的名字
labels:
app: guestbook
tier: frontend
spec:
replicas: 3 #管理的pod副本数量
selector:
matchLabels:
tier1: frontend1 #管理带有tier=frontend标签的pod
template: #定义pod的模板
metadata:
labels:
tier1: frontend 1
#pod标签,一定要有,这样上面控制器就能找到它要管理的pod是哪些了
spec:
containers: #定义pod里运行的容器
- name: php-redis #定义容器的名字
image: yecc/gcr.io-google_samples-gb-frontend:v3
ports: #定义端口
- name: http #定义容器的名字
containerPort: 80 #定义容器暴露的端口
Replicaset管理pod:扩容、缩容、更新
### 扩容缩容
# 如果pods需要副本数的扩容或缩容
1. 修改Replicaset配置文件中的replicas值
2. 重新apply配置文件,就可以增加或减少其副本数
### 更新
#如果修改了其他配置信息(如镜像)
1. 修改Replicaset配置文件
2. 重新apply配置文件(Replicaset这里并不会滚动更新,因此有下一步)
3. 删除此replicaset生成的单个pod副本,这时会自动根据新的配置文件补全pod
4. 等待新pod状态正常,重复第三步操作,删除所有旧pod
总结:
生产环境如果升级,可以删除一个pod,观察一段时间之后没问题再删除另一个pod,但是这样需要人工干预多次;实际生产环境一般采用蓝绿发布,原来有一个rs1,再创建一个rs2(控制器),通过修改service标签,修改service可以匹配到rs2的控制器,这样才是蓝绿发布,这个也需要我们精心的部署规划,我们有一个控制器就是建立在rs之上完成的,叫做Deployment