其实worker节点没必要做高可用，如果把worker2关机，等一段时间就会发现，pod都会在worker1上运行 ，当worker2重启后pod也不会回到worker2上运行
滚动升级
先scale这个deploy为5个副本[root@vms61 chap5-deploy]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web1-5c445ff8fc-dvd29 1/1 Running 0 10s
[root@vms61 chap5-deploy]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
web1 1/1 1 1 11m
[root@vms61 chap5-deploy]# kubectl scale deploy web1 --replicas=5
deployment.apps/web1 scaled
[root@vms61 chap5-deploy]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web1-5c445ff8fc-264n5 1/1 Running 0 7s
web1-5c445ff8fc-7bhnn 1/1 Running 0 7s
web1-5c445ff8fc-dvd29 1/1 Running 0 12m
web1-5c445ff8fc-lfw4n 1/1 Running 0 7s
web1-5c445ff8fc-w9cpp 1/1 Running 0 7s
[root@vms61 chap5-deploy]# kubectl get deploy -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 5/5 5 5 12m nginx nginx app=web1
在worker节点上docker pull nginx:1.7.9和docker pull nginx:1.9两个版本
通过修改配置文件将nginx版本修改成1.7.9后，pod会立马重启生效[root@vms61 chap5-deploy]# kubectl edit deployments.apps web1
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "2"
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"creationTimestamp":null,"labels":{"app":"web1"},"name":"web1","namespace":"chap5-deploy"},"spec":{"replicas":1,"selector":{"matchLabels":{"app":"web1"}},"strategy":{},"template":{"metadata":{"creationTimestamp":null,"labels":{"app":"web1","app1":"web1","app2":"web2"}},"spec":{"containers":[{"env":[{"name":"myenv1","value":"haha1"},{"name":"myenv2","value":"haha2"}],"image":"nginx","imagePullPolicy":"IfNotPresent","name":"nginx","ports":[{"containerPort":80}],"resources":{"requests":{"cpu":"400m"}},"volumeMounts":[{"mountPath":"/xx","name":"v1"}]}],"volumes":[{"emptyDir":{},"name":"v1"}]}}},"status":{}}
creationTimestamp: "2020-09-27T10:29:12Z"
generation: 3
labels:
app: web1
name: web1
namespace: chap5-deploy
resourceVersion: "364400"
selfLink: /apis/apps/v1/namespaces/chap5-deploy/deployments/web1
uid: 3fa8c9ae-c38d-42b2-91a9-68aed7b0bcdd
spec:
progressDeadlineSeconds: 600
replicas: 5
revisionHistoryLimit: 10
selector:
matchLabels:
app: web1
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: web1
app1: web1
app2: web2
spec:
containers:
- env:
- name: myenv1
value: haha1
- name: myenv2
value: haha2
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
protocol: TCP
更新成功更换镜像的本质：删除现有的pod，创建新的pod
如果想查看变更记录呢？
通过kubectl rollout history deployment web1查询，此时查询不到，因为没加record
通过kubectl set image 控制器类型 控制器名字 容器名=新的镜像名[root@vms61 chap5-deploy]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web1-5bb7b69555-sjwvp 1/1 Running 0 2s
[root@vms61 chap5-deploy]# kubectl get deploy -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 1/1 1 1 11s cname nginx app=web1
[root@vms61 chap5-deploy]# kubectl scale deploy web1 --replicas=5
deployment.apps/web1 scaled
[root@vms61 chap5-deploy]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web1-5bb7b69555-2rwgd 1/1 Running 0 3s
web1-5bb7b69555-5mxmc 1/1 Running 0 3s
web1-5bb7b69555-dd8sg 1/1 Running 0 3s
web1-5bb7b69555-fdvdj 1/1 Running 0 3s
web1-5bb7b69555-sjwvp 1/1 Running 0 42s
[root@vms61 chap5-deploy]# kubectl set image deploy/web1 cname=nginx:1.9 --record
deployment.apps/web1 image updated
[root@vms61 chap5-deploy]# kubectl get deploy -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 4/5 5 4 74s cname nginx:1.9 app=web1
[root@vms61 chap5-deploy]# kubectl rollout history deployment web1
deployment.apps/web1
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deploy/web1 cname=nginx:1.9 --record=true
通过kubectl rollout undo deployment web1 --to-revision=X 回滚到指定镜像——X为数字[root@vms61 chap5-deploy]# kubectl rollout undo --help | grep to
Rollback to a previous rollout.
# Rollback to the previous deployment
# Rollback to daemonset revision 3
kubectl rollout undo daemonset/abc --to-revision=3
# Rollback to the previous deployment with dry-run
--allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.
-f, --filename=[]: Filename, directory, or URL to files identifying the resource to get from a server.
-k, --kustomize='': Process the kustomization directory. This flag can't be used together with -f or -R.
-R, --recursive=false: Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory.
--template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
--to-revision=0: The revision to rollback to. Default to 0 (last revision).
Use "kubectl options" for a list of global command-line options (applies to all commands).
[root@vms61 chap5-deploy]# kubectl rollout undo deployment web1 --to-revision=1
如果现在有7个副本，如果更换镜像的时候，是否是一次性把7个pod全部删除然后重建？
实际生产环境不会这样做，可控制。
maxSurge：在升级过程中一次升级几个
maxUnavailable：在升级过程中，只能有1个不可用，一次性删除多少个pod
改成每次更新1台，每次关闭1台，也可写成百分比[root@vms61 chap5-deploy]# kubectl edit deployments.apps web1
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
这里重新将镜像设置为1.7.9时，可看到并没有一次性全部杀死pod
