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