Kubernetes 中 Deployment 使用

news2025/1/9 1:07:24

Deployment的使用

之前我们了解了Replication ControllerReplica Set两种资源对象,RCRS的功能基本上是差不多的,唯一的区别就是RS支持集合的selector。也了解到了用RC/RS来控制Pod副本的数量,也实现了滚动升级Pod的功能。现在看上去似乎一切都比较完美的运行着,但是现在我们推荐使用Deployment这种控制器了,而不是我们之前的RC或者RS,这是为什么呢?

没有对比就没有伤害对吧,我们来对比下二者之间的功能吧,首先RCKubernetes的一个核心概念,当我们把应用部署到集群之后,需要保证应用能够持续稳定的运行,RC就是这个保证的关键,主要功能如下:

  • 确保Pod数量:它会确保Kubernetes中有指定数量的Pod在运行,如果少于指定数量的PodRC就会创建新的,反之这会删除多余的,保证Pod的副本数量不变。
  • 确保Pod健康:当Pod不健康,比如运行出错了,总之无法提供正常服务时,RC也会杀死不健康的Pod,重新创建新的。
  • 弹性伸缩:在业务高峰或者低峰的时候,可以用过RC来动态的调整Pod数量来提供资源的利用率,当然我们也提到过如果使用HPA这种资源对象的话可以做到自动伸缩。
  • 滚动升级:滚动升级是一种平滑的升级方式,通过逐步替换的策略,保证整体系统的稳定性,这个我们上节课已经给大家演示过了。

Deployment同样也是Kubernetes系统的一个核心概念,主要职责和RC一样的都是保证Pod的数量和健康,二者大部分功能都是完全一致的,我们可以看成是一个升级版的RC控制器,那Deployment又具备那些新特性呢?

  • RC的全部功能:Deployment具备上面描述的RC的全部功能
  • 事件和状态查看:可以查看Deployment的升级详细进度和状态
  • 回滚:当升级Pod的时候如果出现问题,可以使用回滚操作回滚到之前的任一版本
  • 版本记录:每一次对Deployment的操作,都能够保存下来,这也是保证可以回滚到任一版本的基础
  • 暂停和启动:对于每一次升级都能够随时暂停和启动

作为对比,我们知道Deployment作为新一代的RC,不仅在功能上更为丰富了,同时我们也说过现在官方也都是推荐使用Deployment来管理Pod的,比如一些官方组件kube-dnskube-proxy也都是使用的Deployment来管理的,所以当大家在使用的使用也最好使用Deployment来管理Pod

创建

在这里插入图片描述

可以看出一个Deployment拥有多个Replica Set,而一个Replica Set拥有一个或多个Pod。一个Deployment控制多个rs主要是为了支持回滚机制,每当Deployment操作时,Kubernetes会重新生成一个Replica Set并保留,以后有需要的话就可以回滚至之前的状态。
下面创建一个Deployment,它创建了一个Replica Set来启动3个nginx pod,yaml文件如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    k8s-app: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

将上面内容保存为: nginx-deployment.yaml,执行命令:

$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deploy" created

然后执行一下命令查看刚刚创建的Deployment:

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         0         0            0           1s

隔一会再次执行上面命令:

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         3         3            3           4m

我们可以看到Deployment已经创建了1个Replica Set了,执行下面的命令查看rs和pod:

$ kubectl get rs
NAME                     DESIRED   CURRENT   READY     AGE
nginx-deploy-431080787   3         3         3         6m
$ kubectl get pod --show-labels
NAME                           READY     STATUS    RESTARTS   AGE       LABELS
nginx-deploy-431080787-53z8q   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-bhhq0   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-sr44p   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787

上面的Deployment的yaml文件中的replicas:3将会保证我们始终有3个POD在运行。

由于DeploymentRC的功能大部分都一样的,我们上节课已经和大家演示了大部分功能了,我们这里重点给大家演示下Deployment的滚动升级和回滚功能。

滚动升级

现在我们将刚刚保存的yaml文件中的nginx镜像修改为nginx:1.13.3,然后在spec下面添加滚动升级策略:

minReadySeconds: 5
strategy:
  # indicate which strategy we want for rolling update
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1
  • minReadySeconds:
    • Kubernetes在等待设置的时间后才进行升级
    • 如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了
    • 如果没有设置该值,在某些极端情况下可能会造成服务不正常运行
  • maxSurge:
    • 升级过程中最多可以比原先设置多出的POD数量
    • 例如:maxSurage=1,replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD,整个升级过程中最多会有5+1个POD。
  • maxUnavaible:
    • 升级过程中最多有多少个POD处于无法提供服务的状态
    • maxSurge不为0时,该值也不能为0
    • 例如:maxUnavaible=1,则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。

然后执行命令:

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured

然后我们可以使用rollout命令:

  • 查看状态:
$ kubectl rollout status deployment/nginx-deploy
Waiting for rollout to finish: 1 out of 3 new replicas have been updated..
deployment "nginx-deploy" successfully rolled out
  • 暂停升级
$ kubectl rollout pause deployment <deployment>
  • 继续升级
$ kubectl rollout resume deployment <deployment>

升级结束后,继续查看rs的状态:

$ kubectl get rs
NAME                      DESIRED   CURRENT   READY     AGE
nginx-deploy-2078889897   0         0         0         47m
nginx-deploy-3297445372   3         3         3         42m
nginx-deploy-431080787    0         0         0         1h

根据AGE我们可以看到离我们最近的当前状态是:3,和我们的yaml文件是一致的,证明升级成功了。用describe命令可以查看升级的全部信息:

Name:     nginx-deploy
Namespace:    default
CreationTimestamp:  Wed, 18 Oct 2017 16:58:52 +0800
Labels:     k8s-app=nginx-demo
Annotations:    deployment.kubernetes.io/revision=3
      kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa...
Selector:   app=nginx
Replicas:   3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:   RollingUpdate
MinReadySeconds:  0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels: app=nginx
  Containers:
   nginx:
    Image:    nginx:1.13.3
    Port:   80/TCP
    Environment:  <none>
    Mounts:   <none>
  Volumes:    <none>
Conditions:
  Type    Status  Reason
  ----    ------  ------
  Progressing   True  NewReplicaSetAvailable
  Available   True  MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet:  nginx-deploy-3297445372 (3/3 replicas created)
Events:
  FirstSeen LastSeen  Count From      SubObjectPath Type    Reason      Message
  --------- --------  ----- ----      ------------- --------  ------      -------
  50m   50m   1 deployment-controller     Normal    ScalingReplicaSet Scaled up replica set nginx-deploy-2078889897 to 1
  45m   45m   1 deployment-controller     Normal    ScalingReplicaSet Scaled down replica set nginx-deploy-2078889897 to 0
  45m   45m   1 deployment-controller     Normal    ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 1
  39m   39m   1 deployment-controller     Normal    ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 2
  39m   39m   1 deployment-controller     Normal    ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 2
  38m   38m   1 deployment-controller     Normal    ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 1
  38m   38m   1 deployment-controller     Normal    ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 3
  38m   38m   1 deployment-controller     Normal    ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 0

回滚Deployment

我们已经能够滚动平滑的升级我们的Deployment了,但是如果升级后的POD出了问题该怎么办?我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本,Deployment就为我们提供了回滚机制。

首先,查看Deployment的升级历史:

$ kubectl rollout history deployment nginx-deploy
deployments "nginx-deploy"
REVISION  CHANGE-CAUSE
1   <none>
2   <none>
3   kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true

从上面的结果可以看出在执行Deployment升级的时候最好带上record参数,便于我们查看历史版本信息。

默认情况下,所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化,这无疑会占用资源,最重要的是,时间久了,当你kubectl get rs时,会有成百上千的垃圾RS返回给你,那时你可能就眼花缭乱了。

上生产时,我们最好通过设置Deployment的.spec.revisionHistoryLimit来限制最大保留的revision number,比如15个版本,回滚的时候一般只会回滚到最近的几个版本就足够了。其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某个ReplicaSet,对应的rollout history就会被删除,也就是还说你无法回滚到这个revison了。

rollout historyReplicaSet的对应关系,可以在kubectl describe rs $RSNAME返回的revision字段中得到,这里的revision就对应着rollout history返回的revison

同样我们可以使用下面的命令查看单个revison的信息:

$ kubectl rollout history deployment nginx-deploy --revision=3
deployments "nginx-deploy" with revision #3
Pod Template:
  Labels: app=nginx
  pod-template-hash=3297445372
  Annotations:  kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true
  Containers:
   nginx:
    Image:  nginx:1.13.3
    Port: 80/TCP
    Environment:  <none>
    Mounts: <none>
  Volumes:  <none>

假如现在要直接回退到当前版本的前一个版本:

$ kubectl rollout undo deployment nginx-deploy
deployment "nginx-deploy" rolled back

当然也可以用revision回退到指定的版本:

$ kubectl rollout undo deployment nginx-deploy --to-revision=2
deployment "nginx-deploy" rolled back

现在可以用命令查看Deployment现在的状态了。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/386039.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

【面试题】前端路由分类

0. 前言 在Web开发中&#xff0c;路由是指根据用户请求的URL地址&#xff0c;确定用户访问的页面资源、参数等&#xff0c;是前端开发中不可缺少的重要部分。Vue router中提供了两种路由模式&#xff0c;一种是hash模式&#xff0c;另一种是history模式。 1. Hash模式路由 H…

爆款升级!新系列南卡Neo最强旗舰杀到,业内首款无线充骨传导耳机!

中国专业骨传导耳机品牌NANK南卡于近日发布了全新南卡Neo骨传导运动耳机&#xff0c;打造一款佩戴最舒适、音质体验最好的骨传导耳机。推出第2代声学響科技技术&#xff0c;提供更优质的开放式骨传导听音体验&#xff0c;透过不一样的音质体验&#xff0c;打造更好的骨传导耳机…

MySQL基础(二)排序与分页、多表查询、单行函数

上接 MySQL基础&#xff08;一&#xff09;SQL分类、导入、SELECT语句&#xff0c;运算符_独憩的博客-CSDN博客 目录 排序与分页 排序 二级排序 分页 多表查询 基础多表查询 等值连接vs非等值连接 自连接vs非自连接 内连接vs外连接 自然连接 单行函数 数值函数 …

信息系统基本知识(四)新技术

大纲 信息系统与信息化信息系统开发方法常规信息系统集成技术软件工程新一代信息技术信息系统安全技术信息化发展与应用信息系统服务管理信息系统服务规划企业首席信息管及其责任 1.5 新一代技术 1.5.1 物联网 概念&#xff1a;&#xff08;The Internet of Things&#xf…

你只会说MVC模型是什么但是不会实现?今天带你走通Web、Servlet、MVC、SpringMVC。代码演示很清晰

文章目录HTTP请求和HTTP响应从0手写一个Web服务器&#xff0c;看看能有多累人使用Servlet实现一个服务器&#xff0c;看看多简单Serlvet的创建Servlet的运行Servlet的其他问题Servlet这么爽&#xff0c;我们简单地探索一下它的原理JSP跟Servlet合作啦&#xff0c;我们来看一下他…

学习ROS时针对gazebo相关的问题(重装与卸载是永远的神)

ResourceNotFound:gazebo_ros 错误解决 参考:https://blog.csdn.net/weixin_42591529/article/details/123869969 当将机器人加载到gazebo时,运行launch文件出现如下错误 这是由于缺少gazebo包所导致的。 解决办法:

Linux 学习 挂载、卸载光盘和实现虚拟机时间同步

/media&#xff1a;挂载光盘使用的 挂载光盘命令&#xff1a;mount /dev/cdrom /media 卸载光盘命令&#xff1a;umount /dev/cdrom 挂载光盘 使用挂在光盘命令挂载光盘&#xff0c;如图所示 卸载光盘 初次卸载光盘可能会出现问题 [rootlocalhost media]# umount /dev/cd…

linux定时任务打包提权docker组提权

定时任务有打包命令&#xff0c;这个命令有参数调用可以执行其他命令&#xff0c;定时任务因为是root用户执行的&#xff0c;所以就会造成提权。一、linux定时任务打包提权复现环境&#xff1a;ubuntun14.041.创建定时任务&#xff1a;在最下面写入&#xff1a;* * * * * …

CK-GW208-EIP与汇川5UPLC走EtherNET_IP通讯指南

CK-GW208-EIP是一款支持标准工业Ethernet/IP协议的IO-LINK主站网关&#xff0c;方便用户快速便捷的集成到PLC等控制系统中。CK-GW208-EIP主站网关集成8路IO-LINK通信端口&#xff0c;采用即插即用模式&#xff0c;无需繁琐的配置&#xff0c;减轻现场安装调试的工作量。为了满足…

几何算法——6.曲线曲面求交的方法总结(国内外文献调研、思考和总结)

几何算法——6.曲线曲面求交的方法总结&#xff08;国内外文献调研、思考和总结&#xff09;1 曲线曲线1.1 直线/二次曲线1.2 二次曲线/二次曲线1.3 其他类型2 曲线曲面2.1 直线/二次曲面&#xff0c;二次曲线/平面2.2 二次曲线/二次曲面2.3 其他类型3 曲面曲面3.1 平面/二次曲…

文件传输协议的五种安全文件传输替代方案

对安全文件传输协议的需求,过去&#xff0c;文件传输协议&#xff08;FTP&#xff09;是发送文件的常用协议。这是一个更简单的时期&#xff0c;安全性比今天要少得多。 但是随着黑客变得越来越复杂&#xff0c;他们发现FTP缺乏安全性。他们知道FTP可以通过有限的方式来确保访…

【IoT】压力式电子脉搏器设计

脉搏是指单位时间内心脏跳动的次数,一般指每分钟的心跳次数,它是衡量人体健康指数的重要指标之一。然而&#xff0c;传统的诊脉手段受到人为因素影响较多&#xff0c;在一定程度上降低了判断病情的准确性&#xff0c;随着电子科学技术的迅猛发展&#xff0c;就出现了电子脉搏计…

# 技术详解: 利用CI同步文章以及多端发布

技术详解: 利用CI同步文章以及多端发布 技术详解: 利用CI同步文章以及多端发布 前言文章的同步实现的细节 思路文章元数据的定义和提取修改文章的优化本地图片资源上传CDN并替换本地link 终于到了 CI 的部分了最后来一些碎碎念 前言 前几天我更新了一篇简单技术总结之后&am…

用C语言写一个自己的shell-Part Ⅲ--built-in commands

Part Ⅲ–Built-in commands Just as we have mentioned in part Ⅱ&#xff0c;the exec family of functions can’t perform built-in commands like cd. It’s like The reason for this is that cd is not a system command like ls or pwd.We need to write and inv…

云原生下最火的API网关-APISIX

文章目录一、APISIX是什么&#xff1f;二、APISIX有哪些功能&#xff1f;三、APISIX对比Spring Cloud Gateway、Zuul等其他网关有哪些优势&#xff1f;四、从0到1部署APIXSIX步骤1&#xff1a;准备环境步骤2&#xff1a;安装依赖步骤3&#xff1a;安装APISIX步骤4&#xff1a;配…

成都待慕电商:抖音虚假宣传虚构被比较价格违规细则

为了保护抖音消费者权益&#xff0c;规范创作者商品分享推广秩序&#xff0c;抖音平台制定《「虚假宣传-虚构被比较价格」违规细则》。 来看详细内容&#xff1a;一、什么是“被比较价格”&#xff1f;被比较价格&#xff1a;指创作者通过价格比较的方式宣传商品价格优惠时&…

opencv:运用cv2给视频加水印

前一段时间学了一下计算机视觉的相关知识,今天想了想,觉得可以利用cv2这个模块给视频加上水印,这样从一些方面也可以表明这个视频的原创。 1. 实现原理 小编的实现原理就是使用cv2模块读取视频文件,然后获取到每一张图片,在图片上的相应位置写上相应的字符串(小编最初打算…

MR虚拟直播是什么?

阿酷tony / 2023-3-3 / 长沙MR虚拟直播是通过机器人、虚拟人物、虚拟舞台或虚拟现实技术&#xff0c;将主播和场景实时转化的互动直播方式。MR技术&#xff08;混合现实技术&#xff09;结合大数据、人工智能等技术&#xff0c;可以在虚拟直播中实现更多的自由度和互动性&#…

认识BUG

如何描述 bug一个合格的 bug 描述应该包括以下几个部分&#xff1a;发现问题的版本开发人员需要知道出现问题的版本&#xff0c;才能够获取对应版本的代码来重现故障&#xff0c;并且版本的标识也有利于统计和分析每个版本的质量。问题出现的环境环境分为硬件环境和软件环境&am…

GUI 之 Tkinter编程

GUI 图形界面&#xff0c;Tkinter 是 Python 内置的 GUI 库&#xff0c;IDLE 就是 Tkinter 设计的。 1. Tkinter 之初体验 import tkinter as tkroot tk.Tk() # 创建一个窗口root.title(窗口标题)# 添加 label 组件 theLabel tk.Label(root, text文本内容) theLabel.p…