21、K8S-控制器之RC、RS

1、RC-Replication Controller

1.1、RC介绍

Replication Controller（RC），是kubernetes系统中的核心概念之一。RC是Kubernetes集群实现
Pod资源对象自动化管理的基础。
简单来说，RC其实是定义了一个期望的场景，RC有以下特点：
1、组成：定义了Pod副本的期望状态：包括数量，筛选标签和模板
 Pod期待的副本数量(replicas).
 永远筛选目标Pod的标签选择器(Label Selector)
 Pod数量不满足预期值，自动创建Pod时候用到的模板(template)
2、意义：自动监控Pod运行的副本数目符合预期，保证Pod高可用的核心组件，常用于Pod的生命周期管理

拓展：自动监控的功能是基于哪些资源对象？
如果我们手动删除pod则会重新创建新的pod。

1.2、RC示例

1.2.1、准备rc的yaml

cat > rc.yml <<'EOF'
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:   
      containers:
      - name: nginx-container
        image: 192.168.10.33:80/k8s/my_nginx:v1
EOF

1.2.2、应用并且查询

master1 ]# kubectl apply  -f rc.yml 

master1 ]# kubectl get rc -o wide
NAME    DESIRED   CURRENT   READY   AGE   CONTAINERS        IMAGES                             SELECTOR
nginx   2         2         2       53s   nginx-container   192.168.10.33:80/k8s/my_nginx:v1   app=nginx

master1 ]# kubectl get pods
]NAME          READY   STATUS    RESTARTS   AGE
nginx-tgpw6   1/1     Running   0          2m7s
nginx-zxzx6   1/1     Running   0          2m7s

1.2.3、关键点

RC的期望状态三结构：
replicas-副本数量 
selector-标签选择器
template-容器模板文件

spec.template.metadata.labels 的属性必须跟Pod资源对象的metadata.labels属性一致

1.3、RC作用

当我们通过"资源定义文件"定义好了一个RC资源对象，把它提交到Kubernetes集群中以后，Master节点上
的Controller Manager组件就得到通知(问：为什么？因为什么？)，定期巡检系统中当前存活的Pod，并确保Pod实例数量刚到满足RC的期望值。
 如果Pod数量大于RC定义的期望值，那么就杀死一些Pod
 如果Pod数量小于RC定义的期望值，那么就创建一些Pod
所以：通过RC资源对象，Kubernetes实现了业务应用集群的高可用性，大大减少了人工干预，提高了管理的自动化。

拓展：
 想要扩充Pod副本的数量，可以直接修改replicas的值即可

1.4、实现机制

当其中一个Node的Pod意外终止，根据RC的定义，Pod的期望值是2，所以会随机找一个Node结点重新再创建一个新的Pod，来保证整个集群中始终存在两个Pod运行

1.5、注意事项

删除RC并不会影响通过该RC资源对象创建好的Pod。如果要删除所有的Pod那么可以设置RC的replicas的值为0，然后更新该RC。

另外kubectl提供了stop和delete命令来一次性删除RC和RC控制的Pod。

Pod提供的是无状态服务，不会影响到客户的访问效果。

2、RS-Replica Set Controller

2.1、rs介绍

由于Replication Controller与Kubernetes代码中的模块Replication Controller同名，而
且这个名称无法准确表达它的本意，即Pod副本的控制，所以从kubernetes v1.2开始，它就升级成了一个
新的概念：Replica Set（RS）。
RS和RC两者功能上没有太大的区别，只不过是表现形式上不一样：
   RC中的Label Selector是基于等式的
   RS中的Label Selector是基于集合的
因为集合的特点，这就使得Replica Set的功能更强大。

2.2、RS清单文件的介绍

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: …
  namespace: …
spec:
 minReadySeconds <integer> # Pod就绪后多少秒内，Pod任一容器无crash方可视为“就绪”
 replicas <integer>        # 期望的Pod副本数，默认为1
 selector:                 # 标签选择器，必须匹配template字段中Pod模板中的标签；
   matchExpressions <[]Object>     # 标签选择器表达式列表，多个列表项之间为“与”关系
   matchLabels <map[string]string> # map格式的标签选择器
 template:           # Pod模板对象
   metadata:         # Pod对象元数据
     labels:         # 由模板创建出的Pod对象所拥有的标签，必须要能够匹配前面定义的标签选择器
   spec:             # Pod规范，格式同自主式Pod
     ……

注意：
   RS和RC之间selector的格式区别

2.3、RS应用方面

RS很少单独使用，它主要是被Deployment这个更高层的资源对象所使用，从而形成了一整套Pod的创建、删除、更新的编排机制。
Replica Set 与Deployment这两个重要资源对象逐步替换了RC的作用

2.4、RS实现逻辑

Controller Manager 根据 ReplicaSet Control Loop 管理 ReplicaSet Object，由该对象向API Server请求管理Pod对象(标签选择器选定的)
如果没有pod：
以Pod模板向API Server请求创建Pod对象，由Scheduler调度并绑定至某节点，由相应节点kubelet负责运行。

2.5、RS实践

2.5.1、准备rs的yaml

cat >rs.yml<<'EOF'
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-test
spec:
  minReadySeconds: 0
  replicas: 3
  selector:
    matchLabels:
      app: rs-test
      release: stable
      version: v1.0
  template:
    metadata:
      labels:
        app: rs-test
        release: stable
        version: v1.0
    spec:
      containers:
      - name: rs-test
        image: 192.168.10.33:80/k8s/pod_test:v0.1
EOF

2.5.2、应用并且查询

master1 ]# kubectl apply  -f rs.yml 

master1 ]# kubectl get rs
NAME              DESIRED   CURRENT   READY   AGE
replicaset-test   3         3         3       59s

master1 ]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
replicaset-test-ch5vz   1/1     Running   0          65s
replicaset-test-j7kwt   1/1     Running   0          65s
replicaset-test-l9jzs   1/1     Running   0          65s

2.5.3、删除一个pod，验证是否自动重新创建pod

master1 ]# kubectl delete  pod replicaset-test-ch5vz 

master1 ]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
replicaset-test-dtvxk   1/1     Running   0          2s
replicaset-test-j7kwt   1/1     Running   0          2m46s
replicaset-test-l9jzs   1/1     Running   0          2m46s

可以看到：删除一个Pod，RC/RS又创建了一个Pod，证明上面我们对Replication Controller\ReplicaSet Controller的作用分析没有任何问题。

3、RC & RS 其他操作

3.1、调整Pod数量-基于对象调整副本数

3.1.1、RC

# 调整前
master1 ]# kubectl get rc
NAME    DESIRED   CURRENT   READY   AGE
nginx   3         3         3       32m

master1 ]# kubectl scale --replicas=5 rc/nginx 
replicationcontroller/nginx scaled

# 调整后
master1 ]# kubectl get rc
NAME    DESIRED   CURRENT   READY   AGE
nginx   5         5         5       32m

3.1.2、RS

master1 ]# kubectl get rs
NAME              DESIRED   CURRENT   READY   AGE
replicaset-test   3         3         3       12m

master1 ]# kubectl scale --replicas=5 rs/replicaset-test 

master1 ]# kubectl get rs
NAME              DESIRED   CURRENT   READY   AGE
replicaset-test   5         5         3       12m

3.2、调整Pod数量-基于文件调整副本数

3.2.1、RC

kubectl scale --replicas=3 -f rc.yml

3.2.2、RS

kubectl scale --replicas=5 -f rs.yml

3.3、手动更新pod的镜像地址

master1 ]# kubectl set image rs/replicaset-test rs-test=192.168.10.33:80/k8s/my_nginx:v1

# 需要删除除的pod访问才生效
master1 ]# kubectl delete pod replicaset-test-t24z8 

master1 ]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
replicaset-test-pf8w6   1/1     Running   0          36s     10.244.4.72    node2   <none>           <none>

master1 ]# curl 10.244.4.72
nginx v1版本

4、RS更新

4.1、基础知识

4.1.1、蓝绿部署介绍和流程图

蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中（两
者均保持在生产环境中运行）。
旧版本可以称为蓝色环境，而新版本则可称为绿色环境。一旦生产流量从蓝色完全转移到绿色，蓝色就可以在
回滚或退出生产的情况下保持待机，也可以更新成为下次更新的模板。
这种持续部署模式原本存在不足之处
 - 并非所有环境都具有相同的正常运行时间要求或正确执行 CI/CD 流程（如蓝绿部署）所需的资源。
 - 在部署过程中，可能导致大量资源占用

4.1.2、滚动更新

所谓的滚动更新是在蓝绿部署的基础上，加快了更新的效率，其特点在于：
 - 一次只更新一小部分副本
 - 上次更新成功后，再更新更多的副本
 - 最终完成所有副本的更新
这个过程中，新旧版本同时存在，并不会导致大量的资源浪费。

4.1.3、蓝绿部署 VS 滚动更新

类型          蓝绿          滚动
配置文件      两个          两个
更新时间      长            短
资源需求      多            少
访问特点      一个版本      多个版本
部署影响      影响范围大    影响范围小

4.2、滚动更新-实践

4.2.1、准备两个版本的RS

cat >rs-v0.1.yml<<'EOF' 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-v01
spec:
  minReadySeconds: 0
  replicas: 3
  selector:
    matchLabels:
      app: pod-test-v0.1
      release: stable
      version: v0.1
  template:
    metadata:
      labels:
        app: pod-test-v0.1
        release: stable
        version: v0.1
    spec:
      containers:
      - name: pod-test-v01
        image: 192.168.10.33:80/k8s/pod_test:v0.1
EOF

cat >rs-v0.2.yml<<'EOF' 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-v02
spec:
  minReadySeconds: 0
  replicas: 0
  selector:
    matchLabels:
      app: pod-test-v0.2
      release: stable
      version: v0.2
  template:
    metadata:
      labels:
        app: pod-test-v0.2
        release: stable
        version: v0.2
    spec:
      containers:
      - name: pod-test-v02
        image: 192.168.10.33:80/k8s/pod_test:v0.2
EOF

4.2.2、应用并且查看

kubectl apply -f rs-v0.1.yml 
kubectl apply -f rs-v0.2.yml 

# 此处v0.2版本还没有创建pod
master1 ]# kubectl get rs
NAME             DESIRED   CURRENT   READY   AGE
replicaset-v01   3         3         3       2m33s
replicaset-v02   0         0         0       5m34s

master1 ]# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
replicaset-v01-8xlfs   1/1     Running   0          2m36s
replicaset-v01-bz2lw   1/1     Running   0          2m36s
replicaset-v01-zprn5   1/1     Running   0          2m36s

4.2.3、轮询将 1版本减1，2版本加1

master1 ~]# kubectl edit rs replicaset-v01
spec:
  replicas: 2 # 3 修改为 2
  

master1 ~]# kubectl edit rs replicaset-v02
spec:
  replicas: 1 # 0 修改为 1
  
# 以此类推的升级

# 观察效果
master1 ~]# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
replicaset-v01-8xlfs   1/1     Running   0          6m50s
replicaset-v01-zprn5   1/1     Running   0          6m50s
replicaset-v02-rz48d   1/1     Running   0          32s

4.2.4、总结

整体来说，这种方式的滚动更新，太麻烦了

4.3、蓝绿更新-实践

4.3.1、基于envsubst的方式生成对应的配置清单

cat >rs-blue-green.yml<<'EOF'
apiVersion: v1
kind: Service
metadata:
  name: replicaset-blue-green
spec:
  type: ClusterIP
  selector:
    app: rs-test
    ctr: rs-${DEPLOY}
    version: ${VERSION}
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-${DEPLOY}
spec:
  minReadySeconds: 3
  replicas: 2
  selector:
    matchLabels:
      app: rs-test
      ctr: rs-${DEPLOY}
      version: ${VERSION}
  template:
    metadata:
      labels:
        app: rs-test
        ctr: rs-${DEPLOY}
        version: ${VERSION}
    spec:
      containers:
      - name: pod-test
        image: 192.168.10.33:80/k8s/pod_test:${VERSION}
EOF

# 基于envsubst的方式生成对应的文件,减少重复编辑文件
DEPLOY=blue VERSION=v0.1 envsubst < rs-blue-green.yml

4.3.2、创建蓝的更新

master1 ]# DEPLOY=blue VERSION=v0.1 envsubst < rs-blue-green.yml | kubectl apply -f -
service/replicaset-blue-green created
replicaset.apps/rs-blue created

master1 ]# kubectl get rs
NAME      DESIRED   CURRENT   READY   AGE
rs-blue   2         2         2       21s

master1 ]# kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
rs-blue-pttwb   1/1     Running   0          26s
rs-blue-zqvgt   1/1     Running   0          26s

4.3.3、创建绿的更新

master1 ]# DEPLOY=green VERSION=v0.2 envsubst < rs-blue-green.yml | kubectl apply -f -
service/replicaset-blue-green configured
replicaset.apps/rs-green created

master1 ]# kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
rs-blue    2         2         2       80s
rs-green   2         2         2       5s

master1 ]# kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
rs-blue-pttwb    1/1     Running   0          83s
rs-blue-zqvgt    1/1     Running   0          83s
rs-green-cgsvk   1/1     Running   0          8s
rs-green-ltr5l   1/1     Running   0          8s

4.3.4、总结

进行蓝绿部署的时候，必须等到所有新的版本更新完毕后，再开放新的service，否则就会导致服务中断的效果

posted @ 2023-03-20 19:50 小粉优化大师阅读(829) 评论(0) 编辑收藏举报

刷新页面返回顶部

小粉优化大师

闻道有先后，术业有专攻 -《师说》

21、K8S-控制器之RC、RS

1、RC-Replication Controller

1.1、RC介绍

1.2、RC示例

1.2.1、准备rc的yaml

1.2.2、应用并且查询

1.2.3、关键点

1.3、RC作用

1.4、实现机制

1.5、注意事项

2、RS-Replica Set Controller

2.1、rs介绍

2.2、RS清单文件的介绍

2.3、RS应用方面

2.4、RS实现逻辑

2.5、RS实践

2.5.1、准备rs的yaml

2.5.2、应用并且查询

2.5.3、删除一个pod，验证是否自动重新创建pod

3、RC & RS 其他操作

3.1、调整Pod数量-基于对象调整副本数

3.1.1、RC

3.1.2、RS

3.2、调整Pod数量-基于文件调整副本数

3.2.1、RC

3.2.2、RS

3.3、手动更新pod的镜像地址

4、RS更新

4.1、基础知识

4.1.1、蓝绿部署介绍和流程图

4.1.2、滚动更新

4.1.3、蓝绿部署 VS 滚动更新

4.2、滚动更新-实践

4.2.1、准备两个版本的RS

4.2.2、应用并且查看

4.2.3、轮询将 1版本减1，2版本加1

4.2.4、总结

4.3、蓝绿更新-实践

4.3.1、基于envsubst的方式生成对应的配置清单

4.3.2、创建蓝的更新

4.3.3、创建绿的更新

4.3.4、总结

公告