k8s-deployment
1.Deployment【无状态应用】
1.部署无状态应用
- 有状态的应用会发生数据交互
2.管理Pod和ReplicaSet【控制副本数量】
- RS的作用：
- 控制副本数量
- 管理滚动更新，缩容扩容【利用两个RS实现滚动升级】
- 发布版本管理
也就是说deployment想对Pod进行更新，回滚之类的都离不开RS，首先新起一个RS把Pod一个一个进行更新
3.具有上线部署，副本设定，滚动升级，回滚，暂停和继续Deployment等功能
4.提供声明式更新，例如只更新一个新的Image
Deployment概述
Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.
使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚。
扩展：声明式定义是指直接修改资源清单yaml文件，然后通过kubectl apply -f 资源清单yaml文件，就可以更改资源
Deployment控制器更新镜像：
Deployment控制器是建立在rs之上的一个控制器，可以管理多个rs，每次更新镜像版本，都会生成一个新的rs，把旧的rs替换掉，多个rs同时存在，但是只有一个rs运行。 
rs v1控制三个pod，删除一个pod，在rs v2上重新建立一个，依次类推，直到全部都是由rs v2控制，如果rs v2有问题，还可以回滚，Deployment是建构在rs之上的，多个rs组成一个Deployment，但是只有一个rs处于活跃状态. 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编写技巧
快速生成deployment的yaml格式文件
kubectl create deploy nginx --image=nginx --dry-run -o yaml > nginx-ds.yaml
创建deployment
[root@master01 ~]# kubectl create deployment web --image=nginx:1.17 deployment.apps/web created
[root@master01 ~]# kubectl get deployment,pods NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx 1/1 1 1 27h deployment.apps/web 1/1 1 1 58s NAME READY STATUS RESTARTS AGE pod/nginx-549f5fcb58-wzg2d 1/1 Running 0 6h41m pod/web-669588cb76-hwvbw 1/1 Running 0 58s
发布
[root@master01 ~]# kubectl expose deployment web --port=80 --target-port=80 --type=NodePort --name=web service/web exposed
升级
deployment控制RS，进行升级，RS一个一个进行升级
kubectl set image deployment/web nginx=nginx:1.15
kubectl rollout status deployment/web
回滚
查看历史版本：
- kubectl rollout history deployment/web
kubectl rollout undo deployment/web
回滚到指定版本：
- kubectl rollout undo deployment/web --revision=2
扩容/缩容
方法一：
- kubectl scale deployment nginx-deployment --replicas=10
方法二：
- 修改yaml文件，副本数量
方法三：
- kubectl edit 控制器名称 pod名称
- 手动修改
deploy一般模板
apiVersion: apps/v1
kind: Deployment
metadata:
name: portal
namespace: ms
spec:
replicas: 1
selector:
matchLabels:
project: ms
app: portal
template:
metadata:
labels:
project: ms
app: portal
spec:
containers:
- name: portal
image: xianchao/portal:v1
imagePullPolicy: Always
ports:
- protocol: TCP
containerPort: 8080
resources: #资源配额
limits: #资源限制，最多可用的cpu和内存
cpu: 1
memory: 1Gi
requests： #最少需要多少资源才可以运行Pod
cpu: 0.5
memory: 1Gi
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
自定义滚动更新策略
maxSurge和maxUnavailable用来控制滚动更新的更新策略
取值范围
数值
- maxUnavailable: [0, 副本数]
- maxSurge: [0, 副本数]
注意：两者不能同时为0。
比例
- maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
- maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
注意：两者不能同时为0。
建议配置
- maxUnavailable == 0
- maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：
1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。
总结：
maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
自定义策略：
修改更新策略：maxUnavailable=1，maxSurge=1
[root@master1 ~]# kubectl patch deployment myapp-v1 -p
'{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}' -n blue-green
评论