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 -owide4、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: 8m2、Deployment 的多副本能力
K scale deploy name –replicas=43、Deployment 扩缩容能力
K scale deploy name –replicas=44、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: RollingUpdatemaxSurge <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