K8s Pod 控制器(一)

K8s workload architecture

一、RC/RS 控制器

控制Pod,使Pod拥有自愈,多副本,扩缩容的能力

RC的定义包括如下几个部分:

(1)、Pod期待的副本数(replicas)

(2)、用于筛选目标Pod的Label Selector

(3)、当Pod的副本数量小预期数量时,用于创建新Pod的Pod模板(template)

2、Label and Selector

标签是关键值对,可以配置到 K8s 中任何的对象(例如 Pods)。标签用于根据要求组织和选
择子对象集。许多对象可以具有相同的标签。标签不为对象提供独特性。
在图中,我们使用了两个标签:app 和 env。根据我们的要求,我们为我们的四个 Pod 赋予了不同的价值。

K label resource-name app=test

3、Label Selectors – 标签选择器

通过标签选择器,我们可以选择对象的子集。K8s 支持两种类型的选择器:
基于平等的选择器
基于平等的选择器允许基于标签键和值对对象进行过滤。使用这种类型的选择器,
我们可以使用 [,],或!例如,通过 env=dev,我们选择的是设置 env 标签的对象。
基于设置的选择器
基于设置的选择器允许基于一组值对对象进行筛选。使用这种类型的选择器,我们
可以使用内、不和存在操作员。例如,在 env 中(dev,qa),我们选择的对象是 env 
标签设置为开发或卡。

k get rc owide
k get pod –show-label
k get rs -owide

4、ReplicaSet/Replication Controller 创建

RS 的 yaml 文件创建

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: frontend
 labels:
 app: guestbook
 tier: frontend
spec:
 # modify replicas according to your case
 replicas: 3
 selector:
 matchLabels:
 tier: frontend
--------------------------------------------
 template:
 metadata:
 labels:
 tier: frontend
 spec:
 containers:
 - name: php-redis
 image: nginx:1.7.9

5、RS 自愈能力

K delete rs 

6、RS 多副本

–replicas=2
注意名字的变化

7、RS 扩缩容能力

K scale

二、Deployment 

控制 Pod,使 Pod 拥有自愈,多副本,扩缩容和滚动更新的能力

1、使用 Deployment 部署应用

k run nginx --image=nignx:alpine
K create deployment test –image=nginx:alpine 

apiVersion: apps/v1
kind: Deployment
metadata:
 name: myngx
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myngx
 template:
 metadata:
 labels:
 app: myngx
 spec:
 containers:
 - image: nginx:1.7.9
 name: myngx
 ports:
 - containerPort: 80
 resources:
    requests:
     cpu: 8m

2、Deployment 的多副本能力

K scale deploy name –replicas=4

3、Deployment 扩缩容能力

K scale deploy name –replicas=4

4、Deployment 自愈&故障转移能力

演示 POD 故障以及 node 故障部署的故障转移能力
Deployment,RepliaSet and Pod 关系

Delete docker
Delete pod

5、升级部署方式介绍

kubernetes 多种发布方式概述

Kubernetes 蓝绿部署,金丝雀发布,滚动更新的介绍

6、金丝雀发布(又称灰度发布、灰度更新): 

金丝雀发布一般是先发 1 台机器,或者一个小比例,例如 2%的服务器,主要做流量
验证用,也称为金丝雀 (Canary) 测试,国内常称灰度测试。以前旷工下矿前,会先放一
只金丝雀进去用于探测洞里是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得
名。简单的金丝雀测试一般通过手工测试验证,复杂的金丝雀测试需要比较完善的监控
基础设施配合,通过监控指标反馈,观察金丝雀的健康状况,作为后续发布或回退的依
据。如果金丝测试通过,则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失
败,则直接回退金丝雀,发布失败。

7、滚动更新 

在金丝雀发布基础上的进一步优化改进,是一种自动化程度较高的发布方式,用户
体验比较平滑,是目前成熟型技术组织所采用的主流发布方式。一次滚动式发布一般由
若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如,
第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察
间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过
程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后
续间隔 2 分钟)。

8、蓝绿部署 

一些应用程序只需要部署一个新版本,并需要立即切到这个版本。因此,我们需要
执行蓝/绿部署。在进行蓝/绿部署时,应用程序的一个新副本(绿)将与现有版本(蓝)
一起部署。然后更新应用程序的入口/路由器以切换到新版本(绿)。然后,您需要等待
旧(蓝)版本来完成所有发送给它的请求,但是大多数情况下,应用程序的流量将一次
更改为新版本;Kubernetes 不支持内置的蓝/绿部署。目前最好的方式是创建新的部署,
然后更新应用程序的服务(如 service)以指向新的部署;蓝绿部署是不停老版本,部署
新版本然后进行测试,确认 OK 后将流量逐步切到新版本。蓝绿部署无需停机,并且风
险较小。

9、A/B 测试 

AB 测试是为 Web 或 App 界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间
维度,分别让组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本,收集各
群组的用户体验数据和业务数据,最后分析、评估出最好版本,正式采用。

10、Deloyment 滚动更新

Deployment upgrade 
• Method 1 
• kubectl set image deployment/NAME containername=imagename:version 
• kubectl set image deployment/myngx myngx=nginx:latest
• Method2:
• Kubectl edit deployment name
• Method3:
• Kubectl apply –f yaml file
• 生成一个新的 RS
check 升级记录
• kubectl rollout history deployment/name
• kubectl rollout history deployment/name --revision=3
• Kubectl get rs -owide
• k get deployments.apps myngx -o yaml # check metadata.generation: 2
• This number is same with RS # rollback is not counted.

RollingUpdate Parameter

strategy:
 rollingUpdate:
 maxSurge: 25%
 maxUnavailable: 25%
type: RollingUpdate

maxSurge <string>
• 可调度的 Pod 最大数量超过所需数量 pod。值可以是绝对数(例如:5)或所需值的
百分比豆荚(ex:10%)。绝对数通过四舍五入从百分比计算。默认为 25%。
• 例子:
• 当该值设置为 30%时,当滚动更新开始时可以立即放大新的复制集,旧的和
新的 pod 不超过所需吊舱的 130%。一旦老 pod 被杀死,新的 ReplicaSet 可
以进一步扩展,确保 POD 的总数在更新过程中的任何时间运行最多为所需
POD 的 130%。


maxUnavailable<string>
• 更新期间不可用的最大 pod。价值可以是绝对数(例如:5)或所需 pod 的百分比
(例如:10%). 绝对数由百分比向下舍入计算得出。这如果 MaxSurge 为 0,则不能
为 0。默认值为 25%。
• 示例:
• 设置此选项时到 30%,旧的 pod 可以缩小到所需 POD 的 70%滚动更新开始
时立即执行。一旦新 pod 准备好,旧豆荚 ReplicaSet 可以进一步缩小,然后
再放大新的 ReplicaSet,确保始终可用的 POD 总数在更新过程中,至少有70%的 POD 是所需的。

11、Deployment 版本回退能力

回滚到上一个版本:
kubectl rollout undo deployment/NAME
回滚到先前的任何版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

30岁老阿姨

支持一下哦!!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值