如果没有KubeSphere可视化界面，同样也能保持部署的能力。因此使用deployment文件来部署的相关应用。Deployment对象，顾名思义，是用于部署应用的对象。它使Kubernetes中最常用的一个对象，它为ReplicaSet和Pod的创建提供了一种声明式的定义方法，从而无需像前两篇文章中那样手动创建ReplicaSet和Pod对象（使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚）。
一、Deployment文件详细解释apiVersion: extensions/v1beta1 #接口版本
kind: Deployment #接口类型
metadata:
name: cango-demo #Deployment名称
namespace: cango-prd #命名空间
labels:
app: cango-demo #标签
spec:
replicas: 3
strategy:
rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
maxSurge: 1 #滚动升级时会先启动1个pod
maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
template:
metadata:
labels:
app: cango-demo #模板名称必填
sepc: #定义容器模板，该模板可以包含多个容器
containers:
- name: cango-demo #镜像名称
image: swr.cn-east-2.myhuaweicloud.com/cango-prd/cango-demo:0.0.1-SNAPSHOT #镜像地址
command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ] #启动命令
args: #启动参数
- '-storage.local.retention=$(STORAGE_RETENTION)'
- '-storage.local.memory-chunks=$(STORAGE_MEMORY_CHUNKS)'
- '-config.file=/etc/prometheus/prometheus.yml'
- '-alertmanager.url=http://alertmanager:9093/alertmanager'
- '-web.external-url=$(EXTERNAL_URL)'
#如果command和args均没有写，那么用Docker默认的配置。
#如果command写了，但args没有写，那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command（不带任何参数的）。
#如果command没写，但args写了，那么Docker默认配置的ENTRYPOINT的命令行会被执行，但是调用的参数是.yaml中的args。
#如果如果command和args都写了，那么Docker默认的配置被忽略，使用.yaml的配置。
imagePullPolicy: IfNotPresent #如果不存在则拉取
livenessProbe: #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；
httpGet:
path: /health #如果没有心跳检测接口就为/
port: 8080
scheme: HTTP
initialDelaySeconds: 60 ##启动后延时多久开始运行检测
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:
readinessProbe:
httpGet:
path: /health #如果没有心跳检测接口就为/
port: 8080
scheme: HTTP
initialDelaySeconds: 30 ##启动后延时多久开始运行检测
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
resources: ##CPU内存限制
requests:
cpu: 2
memory: 2048Mi
limits:
cpu: 2
memory: 2048Mi
env: ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量
- name: LOCAL_KEY #本地Key
value: value
- name: CONFIG_MAP_KEY #局策略可使用configMap的配置Key，
valueFrom:
configMapKeyRef:
name: special-config #configmap中找到name为special-config
key: special.type #找到name为special-config里data下的key
ports:
- name: http
containerPort: 8080 #对service暴露端口
volumeMounts: #挂载volumes中定义的磁盘
- name: log-cache
mount: /tmp/log
- name: sdb #普通用法，该卷跟随容器销毁，挂载一个目录
mountPath: /data/media
- name: nfs-client-root #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfs
mountPath: /mnt/nfs
- name: example-volume-config #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。
mountPath: /etc/config
- name: rbd-pvc #高级用法第2中，挂载PVC(PresistentVolumeClaim)
#使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，
volumes: # 定义磁盘给上面volumeMounts挂载
- name: log-cache
emptyDir: {}
- name: sdb #挂载宿主机上面的目录
hostPath:
path: /any/path/it/will/be/replaced
- name: example-volume-config # 供ConfigMap文件内容到指定路径使用
configMap:
name: example-volume-config #ConfigMap中名称
items:
- key: log-script #ConfigMap中的Key
path: path/to/log-script #指定目录下的一个相对路径path/to/log-script
- key: backup-script #ConfigMap中的Key
path: path/to/backup-script #指定目录下的一个相对路径path/to/backup-script
- name: nfs-client-root #供挂载NFS存储类型
nfs:
server: 10.42.0.55 #NFS服务器地址
path: /opt/public #showmount -e 看一下路径
- name: rbd-pvc #挂载PVC磁盘
persistentVolumeClaim:
claimName: rbd-pvc1 #挂载已经申请的pvc磁盘apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
# 如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是 .spec.template.metadata.labels。
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: frontend
spec:
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
replicas: 25
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google-samples/gb-frontend:v4
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# If your cluster config does not include a dns service, then to
# instead access environment variables to find service host
# info, comment out the 'value: dns' line above, and uncomment the
# line below:
# value: env
ports:
- containerPort: 80
通过kubectl create -f nginx-deployment.yaml命令或者kubectl apply -f nginx-deployment.yaml命令创建名为nginx-deployment的Deployment对象。
通过Deployment对象，你可以轻松的做到以下事情：
- 创建ReplicaSet和Pod
- 滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）
- 平滑地扩容和缩容
- 暂停和继续Deployment
以上面的nginx-deployment.yaml文件为例，使用以下命令创建一个nginx的 Deployment：
kubectl create -f nginx-deployment.yaml --record
--record参数可以记录当前版本的Deployment都执行过哪些命令。创建完成后立即执行get命令可以查看这个Deployment：
$kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
NAME代表Deployment的名字，DESIRED代表这个Deployment期望的副本数量，CURRENT代表当前已经创建了的副本数量，UP-TO-DATE代表已经更新完成的副本数量，AVAILABLE代表对于当前用户可用的副本数量，AGE代表当前Deployment已经运行的时长。等待几秒钟，再次运行get命令，可以查看到变化：
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
通过kubectl get rs来查看系统中ReplicaSet对象，由此可以看出Deployment会自动创建一个ReplicaSet对象。通过kubectl get pods --show-labels命令来查看当前系统中的Pod对象，可以成功观察到nginx-deployment创建的3个Pod。
假如我们现在想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx:1.7.9 的镜像，运行以下命令：
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
或者我们可以使用 edit 命令来编辑 Deployment，将image从nginx:1.7.9 改写成 nginx:1.9.1。
kubectl edit deployment/nginx-deployment
查看更新进度：
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
扩容：
kubectl scale deployment nginx-deployment --replicas 10
如果集群支持 horizontal pod autoscaling 的话，还可以为 Deployment 设置自动扩展：
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
Deployment更新时会创建一个新的ReplicaSet，然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数，将旧的ReplicaSet慢慢缩容到0。因此，更新时总能够确保旧的服务不会停止，这就是滚动更新。
五、Deployment的回滚当我们像上文一样更新了Deployment之后，我们发现nginx:1.9.1的镜像不是很稳定，因此想要修改回nginx:1.7.9的版本，此时我们不需要手动更改Deployment文件，而是利用Deployment的回滚功能。
使用rollout history命令查看Deployment的版本（revision）：
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
因为我们创建 Deployment 的时候使用了 —recored 参数可以记录命令，我们可以很方便的查看每次 revison 的变化。
查看单个 revision 的详细信息：
kubectl rollout history deployment/nginx-deployment --revision=2
现在，可以使用rollout undo命令回滚到前一个revision：
$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back
也可以使用--to-revision参数指定某个历史版本：
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
你可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的 revision；如果将该项设置为 0，Deployment 就不允许回退了。
只有 Deployment 的 rollout 被触发才会创建一个 revision！注意！当且仅当 Deployment 的 Pod template被更改，例如更新 template 中的 label 和容器镜像时，才会触发一个rollout，从而为Deployment创建出一个新的 revision。
rollout命令的更多用法：
- history（查看历史版本）
- pause（暂停Deployment）
- resume（恢复暂停的Deployment）
- status（查看资源状态）
- undo（回滚版本）
滚动更新相关配置：
.spec.minReadySeconds: 新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds才认为Pod Available(Ready)。.spec.strategy.rollingUpdate.maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以为整数或者百分比，默认为desired Pods数的25%. Scale Up新的ReplicaSet时，按照比例计算出允许的MaxSurge，计算时向上取整(比如3.4，取4)。.spec.strategy.rollingUpdate.maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以为整数或者百分比，默认为desired Pods数的25%. Scale Down旧的ReplicaSet时，按照比例计算出允许的maxUnavailable，计算时向下取整(比如3.6，取3)。
因此，在Deployment rollout时，需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable; 保证所有的Pods数不多于 desired pods number + maxSurge。
博文参考
Kubernetes（k8s）Deployment、StatefulSet、DaemonSet、Job、CronJob五种控制器详解_匠人精神，持之以恒！-CSDN博客
