K8s会通过各种Controller来管理Pod的生命周期,为了满足不同的业务场景,K8s开发了Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job、cronJob等多种Controller ,这里我们首先来学习下最常用的Deployment,这是我们生产中用的最多的一个controller,适合用来发布无状态应用.

创建一个deployment,引用nginx的服务镜像,这里的副本数量默认是1,nginx容器镜像用的是latest

  1. [root@master1 ~]# kubectl create deployment nginx --image=nginx
  2. deployment.apps/nginx created

查看创建结果

  1. [root@master1 ~]# kubectl get deployments.apps
  2. NAME READY UP-TO-DATE AVAILABLE AGE
  3. nginx 1/1 1 1 34s

kubectl get rs # <— 看下自动关联创建的副本集replicaset

  1. [root@master1 ~]# kubectl get rs
  2. NAME DESIRED CURRENT READY AGE
  3. nginx-6799fc88d8 1 1 1 2m37s

kubectl get pod # <— 查看生成的pod,注意镜像下载需要一定时间,耐心等待

  1. [root@master1 ~]# kubectl get pod
  2. NAME READY STATUS RESTARTS AGE
  3. nginx-6799fc88d8-dn2xr 1/1 Running 0 3m53s

扩容pod的数量

  1. [root@master1 ~]# kubectl scale deployment nginx --replicas=2 --record
  2. deployment.apps/nginx scaled

查看扩容后的pod结果

  1. [root@master1 ~]# kubectl get pod
  2. NAME READY STATUS RESTARTS AGE
  3. nginx-6799fc88d8-dn2xr 1/1 Running 0 7m10s
  4. nginx-6799fc88d8-f44qt 1/1 Running 0 37s

具体看下pod是不是分散运行在不同的node上

  1. [root@master1 ~]# kubectl get pod -o wide
  2. NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
  3. nginx-6799fc88d8-dn2xr 1/1 Running 0 8m1s 172.20.104.10 172.16.123.62 <none> <none>
  4. nginx-6799fc88d8-f44qt 1/1 Running 0 88s 172.20.166.140 172.16.123.61 <none> <none>

接下来替换下这个deployment里面nginx的镜像版本,来讲解下为什么需要rs副本集呢,这个很重要哦
# 我们先看看目前nginx是哪个版本,随便输入一个错误的url,页面就会打印出nginx的版本号了

  1. [root@master1 ~]# curl 172.20.104.10/2
  2. <html>
  3. <head><title>404 Not Found</title></head>
  4. <body>
  5. <center><h1>404 Not Found</h1></center>
  6. <hr><center>nginx/1.19.10</center> #当前是1.19.10版本
  7. </body>
  8. </html>

根据输出可以看到版本号是nginx/1.19.10,这里利用上面提到的命令docker-tag来看下nginx有哪些其他的版本,然后我在里面挑选了1.9.9这个tag号
# 注意命令最后面的 --record 参数,这个在生产中作为资源创建更新用来回滚的重要标记,强烈建议在生产中操作时都加上这个参数

[root@master1 ~]# docker-tag tags nginx
[root@master1 ~]# kubectl set image deployment/nginx nginx=nginx:1.9.9 --record 
deployment.apps/nginx image updated

观察下pod的信息,可以看到旧nginx的2个pod逐渐被新的pod一个一个的替换掉

[root@master1 ~]# kubectl  get pod -w
NAME                     READY   STATUS        RESTARTS   AGE
nginx-6799fc88d8-f44qt   0/1     Terminating   0          8m41s
nginx-78d698d9f7-mxrr2   1/1     Running       0          36s
nginx-78d698d9f7-z7w26   1/1     Running       0          82s
nginx-6799fc88d8-f44qt   0/1     Terminating   0          8m51s
nginx-6799fc88d8-f44qt   0/1     Terminating   0          8m51s

我们再看下nginx的rs,可以看到现在有两个

[root@master1 ~]# kubectl get rs
NAME               DESIRED   CURRENT   READY   AGE
nginx-6799fc88d8   0         0         0       16m
nginx-78d698d9f7   2         2         2       2m52s

升级nginx的版本到1.9.15

[root@master1 ~]# kubectl set image deployment/nginx nginx=nginx:1.9.15 --record 
deployment.apps/nginx image updated

这里假设是我们在发版服务的新版本,结果线上反馈版本有问题,需要马上回滚,看看在K8s上怎么操作吧
# 首先通过命令查看当前历史版本情况,只有接了--record参数的命令操作才会有详细的记录,这就是为什么在生产中操作一定得加上的原因了

[root@master1 ~]# kubectl rollout history deployment nginx 
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         kubectl scale deployment nginx --replicas=2 --record=true
2         kubectl set image deployment/nginx nginx=nginx:1.9.9 --record=true
3         kubectl set image deployment/nginx nginx=nginx:1.9.15 --record=true

根据历史发布版本前面的阿拉伯数字序号来选择回滚版本,这里我们回到上个版本号,也就是选择2 ,执行命令如下

[root@master1 ~]# kubectl rollout undo deployment nginx  --to-revision=2
deployment.apps/nginx rolled back

可以看到现在最新版本号是4了,具体版本看操作的命令显示是1.9.9 ,并且先前回滚过的版本号2已经没有了,因为它已经变成4了

[root@master1 ~]# kubectl rollout history deployment nginx
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         kubectl scale deployment nginx --replicas=2 --record=true
3         kubectl set image deployment/nginx nginx=nginx:1.9.15 --record=true
4         kubectl set image deployment/nginx nginx=nginx:1.9.9 --record=true