deployment的特性:
使用deployment而不直接创建replicaset是因为deployment对象拥有许多replicaset没有的特性，列入滚动升级、金丝雀发布、蓝绿部署和回滚。
通过deployment对象，你可以轻松的做到以下事情：
1.创建replicaset和pod
2.滚动升级（不停止就服务和状态下升级）和回滚应用（将应用回滚到之前的版本）
3.平滑地扩容和缩容
4.暂停和继续deployment
deployment案例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-tomcat
namespace: tomcat
labels:
tomcat: v2
spec:
replicas: 2 #副本数
selector:
matchLabels: #关联pod的标签
tomcat: v2
template:
metadata: #pod的标签
labels:
tomcat: v2
spec:
containers:
- name: deploy-tomcat #容器名称
image: tomcat:8.5-jre8-alpine #镜像
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080 #容器端口
startupProbe: #启动探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
livenessProbe: #存活探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
readinessProbe: #就绪探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
---
apiVersion: v1
kind: Service
metadata:
name: deploy-svc
namespace: tomcat
labels:
deploy-svc: v1
spec:
selector: #关联pod标签
tomcat: v2
ports:
- port: 8080 #端口
protocol: TCP #协议
type: NodePort #svc类型
deployent 扩容和缩容：
1.可以修改yaml文件实现扩容和缩容
2.可以通过 kubectl edit deployment 名称 实现扩容和缩容。
deployment滚动更新：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-tomcat
namespace: tomcat
labels:
tomcat: v2
spec:
replicas: 2 #副本数
selector:
matchLabels: #关联pod的标签
tomcat: v2
strategy: #更新类型
rollingUpdate: #滚动更新
maxSurge: 25% #最多可以有几个副本（replicas+replicas*25%）
maxUnavailable: 25% #最少可以有几个副本（replicas-replicas*25%）
template:
metadata: #pod的标签
labels:
tomcat: v2
spec:
containers:
- name: deploy-tomcat #容器名称
image: tomcat:8.5-jre8-alpine #镜像
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080 #容器端口
startupProbe: #启动探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
livenessProbe: #存活探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
readinessProbe: #就绪探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
deployment查看历史版本：
kubectl rollout history deployment deploy-tomcat -n tomcat
deployment.apps/deploy-tomcat
REVISION CHANGE-CAUSE
1 <none>
2 <none>
deployment版本回滚：
root@k8s01:/k8s/tomcat# kubectl rollout undo deployment/deploy-tomcat --to-revision=1 -n tomcat
deployment.apps/deploy-tomcat rolled back
生产环境如何实现蓝绿部署？
1.什么是蓝绿部署？
蓝绿部署中，一共有两套系统：一套是正在提供服务的系统，标记为绿色，另一套是准备发布的系统，标记为蓝色，两套系统都是功能完善、正在运行的系统，只是系统的版本和对外服务情况不通过
开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统，这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统蓝色系统。
蓝绿部署案例
v1绿色发布：正在提供的服务
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-v1
namespace: tomcat
labels:
tomcat: v1
spec:
replicas: 3 #副本数
selector:
matchLabels: #关联pod的标签
tomcat: v1
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
metadata: #pod的标签
labels:
tomcat: v1
spec:
containers:
- name: deploy-tomcat #容器名称
image: tomcat:latest #镜像
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080 #容器端口
startupProbe: #启动探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
livenessProbe: #存活探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
readinessProbe: #就绪探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
service服务
apiVersion: v1
kind: Service
metadata:
name: tomcat
namespace: tomcat
spec:
selector:
tomcat: v1
type: NodePort
ports:
- protocol: TCP
port: 8080
蓝色发布,准备发布的系统
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-v2
namespace: tomcat
labels:
tomcat: v2
spec:
replicas: 3 #副本数
selector:
matchLabels: #关联pod的标签
tomcat: v2
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
metadata: #pod的标签
labels:
tomcat: v2
spec:
containers:
- name: deploy-tomcat #容器名称
image: tomcat:8.5-jre8-alpine #镜像
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080 #容器端口
startupProbe: #启动探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
livenessProbe: #存活探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
readinessProbe: #就绪探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
service服务，只需要修改labels标签
apiVersion: v1
kind: Service
metadata:
name: tomcat
namespace: tomcat
spec:
selector:
tomcat: v2
type: NodePort
ports:
- protocol: TCP
port: 8080
什么是金丝雀发布？
金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发一台，或者一个小比例，列如2%的服务器，主要做流量验证用，也称为金丝雀（canary）测试（国内常称灰度测试）
100个pod
更新了一个pod，用的新的代码做的镜像（1个pod就是金丝雀）
99个pod：没有更新
简单的金丝雀猜测是一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或退回的依据。如果金丝雀测试通过，则把剩余的v1版本全部升级为v2版本，如果金丝雀测试失败，则直接退回金丝雀，发布失败。
金丝雀优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度（比如不同账号，不同参数），出现问题不会影响全网用户
缺点：没有覆盖到所有的用户导致出现问题不好排查
金丝雀发布案例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-v1
namespace: tomcat
labels:
tomcat: v1
spec:
replicas: 3 #副本数
selector:
matchLabels: #关联pod的标签
tomcat: v1
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
metadata: #pod的标签
labels:
tomcat: v1
spec:
containers:
- name: deploy-tomcat #容器名称
image: tomcat:latest #镜像
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080 #容器端口
startupProbe: #启动探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
livenessProbe: #存活探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
readinessProbe: #就绪探测
httpGet: #探测返回状态码
port: 8080
path: /
initialDelaySeconds: 10 # 容器启动后10秒开始探测
periodSeconds: 10 #探测的间隔时间是10秒
timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间
successThreshold: 1 #成功1次就算探测成功
failureThreshold: 3 #探测失败3次就算失败
金丝雀暂停：
kubectl set image deployment deploy-v1 deploy-tomcat=tomcat:8.5-jre8-alpine -n tomcat && kubectl rollout pause deployment deploy-v1 -n tomcat
deployment.apps/deploy-v1 image updated
deployment.apps/deploy-v1 paused
金丝雀解除暂停：
kubectl rollout resume deployment deploy-v1 -n tomcat
deployment.apps/deploy-v1 resumed
