你好

第10节 Deployment



❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.topopen in new window

[TOC]

Deployment

⚠️ Deployment：控制pod，使pod具有多个副本，自愈，扩缩容等能力~

deployment and pod?

Pod是单一亦或一组容器的合集

Pod是k8s的最小调度单位，一个Pod中可以有多个containers，彼此共享网络等，这是k8s的核心概念。

deployment是pod版本管理的工具 用来区分不同版本的pod

从开发者角度看，deployment顾明思意，既部署，对于完整的应用部署流程，除了运行代码(既pod)之外，需要考虑更新策略，副本数量，回滚，重启等步骤，

deployment，StatefulSet是Controller，保证Pod一直运行在你需要的状态。

有一次性的也就是job，有定时执行的也就是crontabjob，有排号的也就是sts

用deployment创建有何不同

# 清除所有pod，比较下面两条命令有啥不同
kubectl delete pod my-nginx-7fb96c846b-cnhbz my-nginx-7fb96c846b-g55km my-nginx-7fb96c846b-m9rjp myapp  mynginx  -n default

kubectl  run mynginx --image=nginx #第一条

kubectl create deployment mytomcat --image=tomcat:8.5.68  #第二条

🚀 结果如下：

image-20221022160112746

📜 对上面的解释：

可能我们现在没办法看出来很大的区别，但是我们使用delete删除这个deployment部署tomcat会怎么样？

kubectl delete pod mytomcat-dc7db794-mkfxn mynginx

image-20221022160515168

可以看出是没有办法删除掉的，因为删除后k8s又拉取了，这个功能是很强大的~yyds

这样的话即使机器宕机了也是不会影响的~

如果想要真正的删除怎么办？

我们可以使用deploy查看部署（deployment简写）：

[root@k8s-master01 ~]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3/3     3            3           42h
mytomcat   1/1     1            1           10m

接下来可以删除了

[root@k8s-master01 ~]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3/3     3            3           42h
mytomcat   1/1     1            1           10m

[root@k8s-master01 ~]# kubectl delete deploy mytomcat 
deployment.apps "mytomcat" deleted

[root@k8s-master01 ~]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3/3     3            3           42h

多副本

我们可以指定副本个数，比如说下面指定三份：

kubectl create deployment my-dep --image=nginx --replicas=3

📜 对上面的解释：

image-20221022161337428

  • UP-TO-DATE：表示成功启动的个数
  • AVAILABLE：表示一共副本的总数

当然同样的我们可以使用dashboard可视化界面进行部署~

⚡ 我们还可以用下面命令打印pod详细信息：

 kubectl get pod -owide

image-20221022161843319

每台机器都创建了一台，同样的，每台机器的ip是不一样的~

工作负载-deployment扩容缩容能力

⚡ 将现有的机器（因为满足不了需求）多部署几台pod，这个过程叫做扩容。同样的缩容就是将一些pod下线（流量高峰期过了）

扩缩容

技巧

我们可以动态查看pod情况

watch -n 1 kubectl get pod

缩容为两份

kubectl scale deploy/my-nginx  --replicas=2

image-20221022163051069

扩容为三份

kubectl scale deploy/my-nginx  --replicas=3

image-20221022163210228

注意：你是可以扩容多份（即使你的服务器没有这么多）

image-20221022163510801

你可以直接修改deplot配置文件达到扩缩容

kubectl edit deploy my-nginx

image-20221022163752641

提示

当然你也可以用可视化界面实现（点击缩放：可以实现扩容和缩容）

yaml 声明式创建

自愈和故障转移

自愈和故障转移

当我们有一台pod出现问题，depoyment会感知到错误，然后将其修复（杀死重启）。

也有一种情况：某一个机器突然宕机或者下线了，整个机器没办法运行，此时depoyment会将这个机器的所有pod转移到其他机器正常运行，这个过程叫做故障转移。

depoyment滚动和更新能力

🚸 如果pod有新的版本，我们怎么样去升级pod？

v1 --> v2

查看源图像

注意⚠️

我们是不会同时更新所有的pod，因为这样的话需要停机维护，成本很大。

我们使用的方式是滚动更新，一个pod更新完了再更新下一个。

这样就不需要停机维护了~ 也不会影响正常运行

滚动更新

命令：

  • --record：显示更新的效果
kubectl set image deploy/my-nginx nginx=1.16.1  --record

升级前效果：

kubectl get pod -w #可以观察到实时的更新状态

image-20221022170358831

升级后效果：

image-20221022170823962

版本回退

查看当前的pod版本：

image表示对应的当前镜像版本号

[root@k8s-master01 ~]# kubectl get deploy/my-nginx -o yaml |grep image
      {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"my-nginx","namespace":"default"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"nginx"}},"template":{"metadata":{"labels":{"app":"nginx"}},"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx","ports":[{"containerPort":80}]}]}}}}
    kubernetes.io/change-cause: kubectl set image deploy/my-nginx nginx=1.16.1 --record=true
      - image: 1.16.1
        imagePullPolicy: IfNotPresent

查看历史记录：

[root@k8s-master01 ~]# kubectl rollout history deployment/my-nginx
deployment.apps/my-nginx 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deploy/my-nginx nginx=1.16.1 --record=true

两次版本：

  1. 部署my-nginx产生的<none>
  2. 版本升级镜像产生的内容

回滚到上一次

我们使用rollout命令

kubectl rollout undo deploy/my-dep --to-revision=1

image-20221022171946361

其他工作负载

工作负载是在kubernetes上运行的应用程序

无论你的负载是单一组件还是由多个一同工作的组件构成，在Kubernetes中你可以在一组Pods中运行它。在Kuberneres中，pod代表的是集群上处于运行状态的一组容器。

Kubernetes Pods有确定的生命周期。例如，当某Pod在你的集群中运行时，Pod运行所在的节点出现致命错误时，所有该节点上的Pods都会失败。Kubernetes将这类失败视为最终状态：即使该节点后来恢复正常运行，你也需要创建新的Pod来恢复应用。

不过，为了让用户的日子略微好过一点，你并不需要直接管理每个Pod。相反，你可以使用负载资源来替你管理一组Pods。这些资源配置控制器来确保合适类型的、处于运行状态的Pod个数是正确的，与你所指定的状态相一致。

常用的工作负载控制器：

  • Deployment：无状态应用部署（微服务）
  • StatefulSet：有状态应用部署（redis、mysql，提供存储、网络等）
  • DaemonSet：确保所有Node运行同一个Pod（守护型应用部署，比如日志收集组件）
  • Job：一次性任务
  • CronJob：定时任务

在平常我们是不会直接的创建pod，而是使用工作负载来创建pod

image-20221022172816219

⚠️注意

我们所有的部署（mysql、redis、tomcat）都是没办法通过浏览器访问的，所以没有办法看到效果，或许我们可以通过内网的地址访问（curl）

[root@k8s-master01 ~]# curl 100.66.195.43
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

END 链接