目录
四、Deployment管理pod：扩容、缩容、滚动更新、回滚
一、Replicaset、Deployment控制器概念
1.Replicaset概述
ReplicaSet是kubernetes中的一种副本控制器，简称rs，主要作用是控制由其管理的pod，使pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的Pod能够在集群中正常运行，它会持续监听这些Pod的运行状态，在Pod发生故障时重启pod，pod数量减少时重新运行新的 Pod副本。官方推荐不要直接使用ReplicaSet，用Deployments取而代之，Deployments是比ReplicaSet更高级的概念，它会管理ReplicaSet并提供很多其它有用的特性，最重要的是Deployments支持声明式更新，声明式更新的好处是不会丢失历史变更。所以Deployment控制器不直接管理Pod对象，而是由 Deployment 管理ReplicaSet，再由ReplicaSet负责管理Pod对象。
2.Deployment控制器概念
1.Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.
使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚。
扩展：声明式定义是指直接修改资源清单yaml文件，然后通过kubectl apply -f 资源清单yaml文件，就可以更改资源
Deployment控制器是建立在rs之上的一个控制器，可以管理多个rs，每次更新镜像版本，都会生成一个新的rs，把旧的rs替换掉，多个rs同时存在，但是只有一个rs运行。
rs v1控制三个pod，删除一个pod，在rs v2上重新建立一个，依次类推，直到全部都是由rs v2控制，如果rs v2有问题，还可以回滚，Deployment是建构在rs之上的，多个rs组成一个Deployment，但是只有一个rs处于活跃状态.
2.Deployment工作原理：如何管理rs和pod？
Deployment可以使用声明式定义，直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，也就是通过打补丁的方式进行修改；Deployment能提供滚动式自定义自控制的更新；对Deployment来讲，我们在实现更新时还可以实现控制更新节奏和更新逻辑。
互动：什么叫做更新节奏和更新逻辑呢？
比如说Deployment控制5个pod副本，pod的期望值是5个，但是升级的时候需要额外多几个pod，那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本；比方说能多一个，但是不能少，那么升级的时候就是先增加一个，再删除一个，增加一个删除一个，始终保持pod副本数是5个；还有一种情况，最多允许多一个，最少允许少一个，也就是最多6个，最少4个，第一次加一个，删除两个，第二次加两个，删除两个，依次类推，可以自己控制更新方式，这种滚动更新需要加readinessProbe和livenessProbe探测，确保pod中容器里的应用都正常启动了才删除之前的pod。
启动第一步，刚更新第一批就暂停了也可以；假如目标是5个，允许一个也不能少，允许最多可以10个，那一次加5个即可；这就是我们可以自己控制节奏来控制更新的方法。
通过Deployment对象，你可以轻松的做到以下事情：
1、创建ReplicaSet和Pod
2、滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）
3、平滑地扩容和缩容
4、暂停和继续Deployment
二、Deployment资源清单文件编写技巧
举例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
#查看Deployment资源对象由哪几部分组成
[root@hd1 ~]# kubectl explain deployment
FIELDS:
apiVersion
kind
metadata
spec
#查看Deployment下的spec字段
[root@hd1.com ~]# kubectl explain deployment.spec
FIELDS:
replicas <integer> #副本数
revisionHistoryLimit <integer> #保留的历史版本，默认是10
selector <Object> -required- #标签选择器，选择它关联的pod
strategy <Object> #更新策略
template <Object> -required #定义的pod模板
#查看Deployment下的spec.strategy字段
[root@hd1.com ~]# kubectl explain deploy.spec.strategy
FIELDS:
rollingUpdate <Object>
type <string>
#支持两种更新，Recreate和RollingUpdate
#Recreate是重建式更新，删除一个更新一个
#RollingUpdate滚动更新，定义滚动更新方式，也就是pod能多几个，少几个
#查看Deployment下的spec.strategy.rollingUpdate字段
[root@hd1.com ~]# kubectl explain deploy.spec.strategy.rollingUpdate
FIELDS:
maxSurge <string>
#我们更新的过程当中最多允许超出的指定的目标副本数有几个；它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是5个，最多可以超出20%，那就允许多一个，最多可以超过40%，那就允许多两个
maxUnavailable <string>
#最多允许几个不可用，假设有5个副本，最多一个不可用，就表示最少有4个可用
#template为定义Pod的模板，Deployment通过模板创建Pod
[root@hd1.com ~]# kubectl explain deploy.spec.template
FIELDS:
metadata <Object> #定义模板的名字
spec <Object>
deployment.spec.template为Pod定义的模板，和Pod定义不太一样，template中不包含apiVersion和Kind属性，要求必须有metadata。deployment.spec.template.spec为容器的属性信息，其他定义内容和Pod一致。
#查看Deployment下的spec.template.spec字段
[root@hd1.com ~]# kubectl explain deploy.spec.template.spec
FIELDS:
activeDeadlineSeconds <integer>
#activeDeadlineSeconds表示Pod 可以运行的最长时间，达到设置的该值后，Pod 会自动停止。
affinity <Object> #定义亲和性，跟直接创建pod时候定义亲和性类似
automountServiceAccountToken<boolean> #身份认证相关的
containers <[]Object> -required- #定义容器属性
dnsConfig <Object> #设置Pod的DNS
三、Deployment使用案例：创建web站点
deployment是一个三级结构，deployment管理replicaset，replicaset管理pod，
例子：用deployment创建一个pod
#把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上传到hd2.com和hd3.com上，手动解压：
[root@hd2.com ~]# docker load -i myapp-blue-v1.tar.gz
[root@hd3.com ~]# docker load -i myapp-blue-v1.tar.gz
[root@hd2.com ~]# docker load -i myapp-blue-v2.tar.gz
[root@hd3.com ~]# docker load -i myapp-blue-v2.tar.gz
[root@hd1.com ~]# cat deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
spec:
replicas: 2
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: janakiramm/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
更新资源清单文件：
[root@hd1 ~]# kubectl apply -f deploy-demo.yaml
#kubectl apply：表示声明式的定义，既可以创建资源，也可以动态更新资源
查看deploy状态：
[root@hd1 ~]# kubectl get deploy
#创建的控制器名字是myapp-v1
1.NAME ：列出名称空间中deployment的名称。
2.READY：显示deployment有多少副本数。它遵循ready/desired的模式。
3.UP-TO-DATE： 显示已更新到所需状态的副本数。
4.AVAILABLE： 显示你的可以使用多少个应用程序副本。
5.AGE ：显示应用程序已运行的时间。
kubectl get rs 显示如下：
#创建deploy的时候也会创建一个rs（replicaset），67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值
1.NAME： 列出名称空间中ReplicaSet资源
2DESIRED：显示应用程序的所需副本数，这些副本数是在创建时定义的。这是所需的状态。
3.CURRENT： 显示当前正在运行多少个副本。
4.READY： 显示你的用户可以使用多少个应用程序副本。
5.AGE ：显示应用程序已运行的时间。
请注意，ReplicaSet的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是随机生成的
kubectl get pods
显示如下：
[root@hd1.com ~]# kubectl get pods -o wide | grep myapp
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 10.244.187.78 hd3.com
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 10.244.209.136 hd2.com
#请求刚才创建的pod资源
[root@hd1.com ~]# curl 10.244.187.78
background-color: blue;
[root@hd1.com ~]# curl 10.244.209.136
background-color: blue;
#资源清单文件详细解读
apiVersion: apps/v1 #deployment对应的api版本
kind: Deployment #创建的资源是deployment
metadata:
name: myapp-v1 #deployment的名字
spec:
replicas: 2 #deployment管理的pod副本数
selector: #标签选择器
matchLabels: # matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec: #定义容器的属性
containers:
- name: myapp
image: janakiramm/myapp:v1 #容器使用的镜像
imagePullPolicy: IfNotPresent #镜像拉取策略
ports:
- containerPort: 80 #容器里的应用的端口
四、Deployment管理pod：扩容、缩容、滚动更新、回滚
#通过deployment管理应用，实现扩容，把副本数变成3
[root@hd1.com ~]# vim deploy-demo.yaml
直接修改replicas数量，如下，变成3
spec:
replicas: 3
修改之后保存退出，执行
[root@hd1.com ~]# kubectl apply -f deploy-demo.yaml
注意：apply不同于create，apply可以执行多次；create执行一次，再执行就会报错复。
kubectl get pods
显示如下：
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 15m
myapp-v1-67fd9fc9c8-h9js5 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 17m
#上面可以看到pod副本数变成了3个
#查看myapp-v1这个控制器的详细信息
[root@hd1.com ~]# kubectl describe deploy myapp-v1
#通过deployment管理应用，实现缩容，把副本数变成2
[root@hd1.com ~]# cat deploy-demo.yaml
直接修改replicas数量，如下，变成2
spec:
replicas: 2
修改之后保存退出，执行
[root@hd1.com ~]# kubectl apply -f deploy-demo.yaml
[root@hd1.com ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 18m
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 20m
还可以通过kubectl edit deploy myapp-v1 实现自动扩容或缩容
[root@hd1 deploy]# kubectl edit deploy myapp-v1
#通过deployment管理应用，实现滚动更新
在一个终端窗口执行如下：
[root@hd1.com ~]# kubectl get pods -l app=myapp -w
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 19m
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 22m
打开一个新的终端窗口更改镜像版本，按如下操作：
[root@hd1.com ~]# vim deploy-demo.yaml
把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2
保存退出，执行
[root@hd1.com ~]# kubectl apply -f deploy-demo.yaml
再回到刚才执行监测kubectl get pods -l app=myapp -w的那个窗口，可以看到信息如下：
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 23m
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 26m
myapp-v1-75fb478d6c-fskpq 0/1 Pending 0 0s
myapp-v1-75fb478d6c-fskpq 0/1 Pending 0 0s
myapp-v1-75fb478d6c-fskpq 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-fskpq 0/1 ContainerCreating 0 1s
myapp-v1-75fb478d6c-fskpq 1/1 Running 0 4s
myapp-v1-67fd9fc9c8-fcprr 1/1 Terminating 0 24m
myapp-v1-75fb478d6c-x8stq 0/1 Pending 0 0s
myapp-v1-75fb478d6c-x8stq 0/1 Pending 0 0s
myapp-v1-75fb478d6c-x8stq 0/1 ContainerCreating 0 0s
myapp-v1-67fd9fc9c8-fcprr 1/1 Terminating 0 24m
myapp-v1-75fb478d6c-x8stq 0/1 ContainerCreating 0 1s
myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24m
myapp-v1-75fb478d6c-x8stq 1/1 Running 0 1s
myapp-v1-67fd9fc9c8-hw4f9 1/1 Terminating 0 26m
myapp-v1-67fd9fc9c8-hw4f9 1/1 Terminating 0 26m
myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m
myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m
myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m
myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24m
myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24m
pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运行一个pod，running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直到所有pod完成滚动升级
[root@hd1.com ~]# kubectl get rs
显示如下：
myapp-v1-67fd9fc9c8 0 0 0 27m
myapp-v1-75fb478d6c 2 2 2 79s
#上面可以看到rs有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚
#查看myapp-v1这个控制器的历史版本
[root@hd1.com ~]# kubectl rollout history deployment myapp-v1
deployment.apps/myapp-v1
REVISION CHANGE-CAUSE
1 <none>
2 <none>
#回滚
[root@hd1.com ~]# kubectl rollout undo deployment myapp-v1 --to-revision=1
deployment.apps/myapp-v1 rolled back
[root@hd1.com ~]# kubectl rollout history deployment myapp-v1
deployment.apps/myapp-v1
REVISION CHANGE-CAUSE
2 <none>
3 <none>
自定义滚动更新策略
maxSurge和maxUnavailable用来控制滚动更新的更新策
按数值
1. maxUnavailable: [0, 副本数]
2. maxSurge: [0, 副本数]
注意：两者不能同时为0。
按比例
1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
注意：两者不能同时为0。
建议配置
1. maxUnavailable == 0
2. maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：
1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。
总结：
maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
自定义策略：
修改更新策略：maxUnavailable=1，maxSurge=1
[root@hd1~ ]# vim deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: v1
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: janakiramm/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
执行上面的yaml文件
[root@hd1 ~]# kubectl apply -f deploy-demo.yaml
查看myapp-v1这个控制器的详细信息
[root@hd1.com ~]# kubectl describe deployment myapp-v1
显示如下：
RollingUpdateStrategy: 1 max unavailable, 1 max surge
总结：deployment 副本控制器，功能是控制无状态协议的应用的pod的，http协议 就是无状态，ftp协议就是无状态的
737
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
