k8s快速入门教程-----6. 滚动更新与状态检测

K8s 滚动升级与回退 K8s 滚动升级与回退。 阅读详情

上一篇:5 Service

6.1 滚动更新

滚动更新是一次只更新小部分副本,成功后再更新更多的副本,最终完成所有副本的更新。滚动更新的最大好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性。

6.1.1 更新

6.1.1.1 set image

kubectl set image deployment/web container-eh09qq=wordpress:6.8 --record

备注:container-eh09qq为容器名字。

6.1.1.2 edit yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1001
  name: nginx1001
  namespace: default
spec:
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx1001
  template:
    metadata:
      labels:
        app: nginx1001
    spec:
      containers:
      - image: wangjinxiong/nginx:tools  #修改这个
        imagePullPolicy: Always
        name: nginx
      restartPolicy: Always

6.1.2 回滚

查看历史版本

kubectl rollout history deployment/web

查看历史版本的镜像

kubectl rollout history deployment/web --revision=3

回滚到上一个版本

kubectl rollout undo deployment/web

回滚到指定版本

kubectl rollout undo deployment/web --to-revision=1

6.2 状态检测

6.2.1 Init容器

container的restartPolicy有三种:Nerver,OnFailure, Always(默认)。

  • Init容器总是运行到成功完成为止。也就是Init容器会退出结束。
  • 每个Init容器都必须在下一个Init容器启动之前成功完成。

Init容器可以通过kubectl explain pod.spec.initContainers查看init容器的属性配置。init容器属于 pod 的初始化容器列表。初始化容器是在容器启动之前按顺序执行。如果Pod的Init容器失败,Kubernetes会不断重启该Pod,直到Init容器成功为止(除非Pod对应的restartPolicy为Never)。因为Init容器具有与应用程序容器分离的单独镜像,所以它们的启动相关代码具有如下优势:

  • 应用程序镜像可以分离出创建和部署的角色,而没必要联合它们构建一个单独的镜像。
  • Init容器使用Linux Namespace,所以相比应用程序容器来说具有不同的文件系统视图。因此,它们能够具有访问Secret的权限,而应用程序则不能。
  • 它们必须在应用容器启动之前运行完成,而应用程序容器是并行运行的,所以Init容器能够提供一种简单的阻塞或延迟应用容器的启动方法,直到满足一组先决条件。
  • 如果Pod重启,所有Init容器必须重新执行
  • Init容器具有应用容器的所有字段,除了readinessProbe。因为Init容器无法定义不同于完成(completion)的就绪(readiness)之外的其他状态。

Init Container(初始化容器) 在很多应用场景中,应用在启动之前都需要进行如下初始化操作。

  • 等待其他关联组件正确运行(例如数据库或某个后台服务)。
  • 基于环境变量或配置模板生成配置文件。 ◎ 从远程数据库获取本地所需配置,或者将自身注册到某个中央 数据库中。
  • 下载相关依赖包,或者对系统进行一些预配置操作。

例子:

cat init-test0915.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx0915
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx0915
  template:
    metadata:
      labels:
        app: nginx0915
    spec:
      volumes:
        - name: host-time
          hostPath:
            path: /etc/localtime
            type: ''
        - name: pvc0915
          persistentVolumeClaim:
            claimName: pvc0915
      initContainers:
      - name: busybox
        image: wangjinxiong/busybox:1.28.4.1
        imagePullPolicy: IfNotPresent
        command:
        - cp 
        - "/home/index.html"
        - "/work-dir"
        volumeMounts:
        - mountPath: /etc/localtime
          name: host-time
          readOnly: true
        - name: pvc0915
          mountPath: /work-dir
      containers:
      - image: nginx
        name: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web80
        volumeMounts:
        - mountPath: /etc/localtime
          name: host-time
          readOnly: true
        - name: pvc0915
          mountPath: /usr/share/nginx/html

6.2.2 LivenessProbe 和ReadinessProbe

Kubernetes 对 Pod 的健康状态可以通过两类探针来检查: LivenessProbe 和ReadinessProbe,kubelet定期执行这两类探针来诊断容 器的健康状况。
(1)LivenessProbe探针:用于判断容器是否存活(Running状 态),如果LivenessProbe探针探测到容器不健康,则kubelet将杀掉该容器,并根据容器的重启策略做相应的处理。如果一个容器不包含 LivenessProbe探针,那么kubelet认为该容器的LivenessProbe探针返回的 值永远是Success。
(2)ReadinessProbe探针:用于判断容器服务是否可用(Ready状 态),达到Ready状态的Pod才可以接收请求。对于被Service管理的 Pod,Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设 置。如果在运行过程中Ready状态变为False,则系统自动将其从Service 的后端Endpoint列表中隔离出去,后续再把恢复到Ready状态的Pod加回 后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到 服务不可用的Pod实例上。
LivenessProbe和ReadinessProbe均可配置以下三种实现方式。
(1)ExecAction:在容器内部执行一个命令,如果该命令的返回 码为0,则表明容器健康。 在下面的例子中,通过执行“cat /tmp/health”命令来判断一个容器运 行是否正常。在该Pod运行后,将在创建/tmp/health文件10s后删除该文 件,而LivenessProbe健康检查的初始探测时间(initialDelaySeconds)为 15s,探测结果是Fail,将导致kubelet杀掉该容器并重启它。
(2)TCPSocketAction:通过容器的IP地址和端口号执行TCP检 查,如果能够建立TCP连接,则表明容器健康。
在下面的例子中,通过与容器内的localhost:80建立TCP连接进行健 康检查:
(3)HTTPGetAction:通过容器的IP地址、端口号及路径调用 HTTP Get方法,如果响应的状态码大于等于200且小于400,则认为容器 健康。 在下面的例子中,kubelet定时发送HTTP请求到 localhost:80/_status/healthz来进行容器应用的健康检查。
探测的时间:
(1) initialDelaySeconds: 10 指定容器启动10 之后开始执行Liveness探测,我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花30秒,那么initialDelaySeconds的值就应该大于30。
(2) periodSeconds: 5 指定每5秒执行一次Liveness 探测。Kubernetes如果连续执行3次Liveness 探测均失败,则会杀掉并重启容器。
(3) failureThreshold:当探测失败时,Kubernetes将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器,就绪探测情况下的放弃Pod会被打上未就绪的标签。默认值是3,最小值是1。
(4) timeoutSeconds:探测的超时后等待多少秒。默认值是1秒,最小值是1。(在Kubernetes 1.20版本之前,exec探针会忽略timeoutSeconds,探针会无限期地持续运行,甚至可能超过所配置的限期,直到返回结果为止。)

6.2.2.1 LivenessProbe例子

6.2.2.1.1 ExecAction
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod0922
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
6.2.2.1.2 TCPSocketAction
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket-pod0922
spec:
  containers:
  - name: liveness-tcpsocket-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
6.2.2.1.3 HTTPGetAction
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod0922
spec:
  containers:
  - name: liveness-httpget-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

6.2.2.2 ReadinessProbe

6.2.2.2.1 ExecAction
apiVersion: v1
kind: Pod
metadata:
  name: readiness-exec-pod0922
spec:
  containers:
  - name: readiness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 600"]
    readinessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
6.2.2.2.2 TCPSocketAction
apiVersion: v1
kind: Pod
metadata:
  name: readiness-tcpsocket-pod0922
spec:
  containers:
  - name: readiness-tcpsocket-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
6.2.2.2.3 HTTPGetAction
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod0922
spec:
  containers:
  - name: readiness-httpget-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

下一篇:7 数据管理

MinIO高危漏洞CVE-2023-28432应急响应:从检测到安全升级的完整指南 在分布式对象存储系统中,信息泄露漏洞是威胁数据安全的严重风险之一。这类漏洞的原理通常源于服务端对特定HTTP请求的处理逻辑存在缺陷,导致未经授权的攻击者能够绕过身份验证机制,直接获取系统内部敏感信息。从技术价值角度看,及时修复此类漏洞不仅是满足合规性要求,更是保护企业核心数字资产、维护业务连续性的关键。在实际应用场景中,对象存储集群常作为大数据分析、备份归档和云原生应用的后端存储,一旦根凭据等关键环境变量泄露,攻击者便可实施数据窃取、篡改甚至勒索攻击。本文聚焦于近期披露的MinIO高危漏洞CVE-2023- 阅读详情

相关推荐

数据科学六大角色协作全景图:从岗位迷思到闭环落地

数据科学不是单一岗位的技术堆砌,而是由数据工程师、数据分析师、数据科学家、ML工程师、MLOps工程师及支撑角色共同构成的协同生态。其底层逻辑在于:以业务问题为起点,通过数据契约、特征可解释性、模型可观测性与服务韧性等关键技术能力,实现从需求定义到价值归因的完整闭环。在AutoML与数据网格趋势下,角色边界正从技术栈划分转向业务域融合,核心能力也从工具熟练度升维为问题抽象、约束建模与人机协同设计。本文基于47个真实项目复盘,系统拆解六大角色的职责红线、技能接口与协作机制,助力从业者穿透JD噪音,锚定真实工程

wangqiaowqo的专栏 417

K8S之使用Deployment实现滚动更新

滚动更新是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式,一次滚动发布一般由若干个批次组成,每批的数量一般是可以配置的(通过发布模板定义)。批次间可留观察间隔,通过手工验证或监控反馈确保没有问题再继续下一批次,所以总体上滚动式发布过程是比较缓慢的。paused:暂停,当我们更新的时候创建pod先暂停,不是立即更新(ps.金丝雀发布会使用到)strategy:更新策略,支持的滚动更新策略。

weixin_40364776的博客 3170

【K8S系列】深入解析滚动升级

Kubernetes是一个流行的容器编排平台,其中的控制器是Kubernetes的核心组件之一,它可以控制Pod的部署和管理。滚动升级是Kubernetes中的一种重要的控制器操作,可以让用户在不中断服务的情况下对应用程序进行升级。本文将深入解析Kubernetes控制器滚动升级的原理和实现方法。滚动升级是指在不中断服务的情况下对应用程序进行升级的操作。在Kubernetes中,滚动升级是通过控制器来实现的。

颜淡慕潇 3万+

k8s如何滚动升级应用

介绍在k8s平台手动升级应用和借助Deployment进行升级

qq_22548549的博客 3112

【信息科学与工程学】【数据中心】 第七篇 智算中心CLOS组网整体设计

区域主要功能网络要求技术选型安全等级可用性要求训练区​大规模AI模型训练,分布式计算超高带宽(100G+),超低延迟(<1ms),无损网络RoCEv2,PFC,DCQCN,多路径P4(最高)99.99%推理区​实时AI推理,模型服务低延迟(<10ms),高可用,弹性扩展智能负载均衡,服务网格,容器网络P3(高)99.999%公共服务区​统一认证,API网关,数据服务多租户隔离,安全防护,弹性带宽VXLAN,EVPN,微隔离P3(高)99.99%存储区​高性能存储,数据湖超高带宽,低延迟,高IOPSNVMe-

weixin_49199313的博客 1371

【信息科学与工程学】【通信工程】【企业网、园区网、数据中心、广域网】各类业务网络及其网络演算算法

企业网络是一个复杂的系统,其业务、人员、流量和安全特征相互交织。下面这张表格梳理了这些核心特征及其关联的数学模型,帮你先建立整体概念。特征维度核心特征关联数学模型/方法业务特征​多样性、服务等级协议、混合云趋势图论(拓扑优化)、排队论(M/M/1)、随机过程(业务到达)、优化理论(资源调度)人员特征​角色权限差异、访问行为随机性、安全意识差异概率统计(行为建模)、随机过程(会话生成)、博弈论(安全策略)、访问控制矩阵流量特征​混合性、突发性、时空规律性、方向性(南北/东西向)泊松过程(短时突发)、重尾分布(

weixin_49199313的博客 889

【独家披露】大厂都在用的Kubernetes运维神器:5个核心Python脚本

解决Kubernetes运维复杂难题,5个高效Python脚本轻松管理集群。涵盖自动扩缩容、故障检测、日志收集等场景,基于Kubernetes Python运维脚本实现自动化运维,提升稳定性与效率,大厂实战经验总结,值得收藏。

VarChat的博客 968

【DevOps】kubernetes 健康检查,POD状态事件events日志数据持久化(ES+Kibana)

目录需求现有方案实现 需求 查看K8S集群被探针检测重启的pod什么时间段,因为什么重启了。 现有方案 如果环境中只有一种探针方式(HTTP),可以通过Prometheus+grafana来监控pod的可用状态数量,来达到pod什么时间被重启了,原因当然就HTTP方式检测状态码失败导致的。 如果环境中存在多种探针方式(HTTPS、HTTP、TCP),再加上kubernetes目前events事件保留一个小时,超时后就查不到events事件了,我们可以把events做到持久化数据,并可以通知企业微信????。

CN_Eden 2251

Qwen3-14B模型滚动升级方案避免服务中断

本文详解如何在Kubernetes环境中对Qwen3-14B大模型进行滚动升级,实现服务不中断的平滑迭代。涵盖Readiness/Liveness探针配置、优雅终止、健康检查、HPA自动扩缩容及灰度发布等关键实践,确保AI服务持续稳定可用。

weixin_42584507的博客 499

docker-update-check:检查Docker容器是否需要更新

Docker更新检查 运行服务器意味着您必须跟上错误修复和安全更新。 使用apt等工具,只要您的服务不在容器中运行,Linux发行版就会提供或多或少的便捷机制来应用这些更新。 容器化服务使检查需要更新的内容变得更加困难,并且需要不同的工作流程来更新软件包。 该软件包为Ubuntu提供了概念验证的实现,可帮助您确定哪些运行中的容器需要更新。 然后,您可以重建受影响的Docker映像并重新部署容器。 它是如何工作的? 这个想法很简单。 在Ubuntu中,您可以从update-notifier-common包运行/usr/lib/update-notifier/apt-check工具,以查看是否需要安装安全更新或其他更新。 为此, apt-check将/var/lib/dpkg/status文件中找到的已安装软件包列表与/var/lib/apt/lists/软件包列表进行比较。 软件包管理工

Obsidian跨设备同步实战:阿里云OSS与Remotely Save插件配置指南

本文详细介绍了如何利用阿里云OSS对象存储与Remotely Save插件,为Obsidian笔记软件搭建一个低成本、高可靠性的私有化多端同步方案。从创建OSS Bucket、配置CORS规则、生成子账户密钥,到插件安装与多设备同步策略,提供了完整的实战配置指南,有效解决Obsidian用户的跨设备同步痛点。

qsc901234567的博客 1284

如何用Spring Boot 3.x实现真正的零停机发布?揭秘蓝绿部署与热更新底层机制

掌握Spring Boot 3.x企业级应用开发最佳实践,实现零停机发布的完整方案。涵盖蓝绿部署流程、热更新机制与云原生环境适配技巧,提升系统可用性与发布效率。适用于高并发、持续交付场景,值得收藏。

BreakVein的博客 1082

Scipy优化踩坑实录:trust-constr和SLSQP约束定义到底差在哪?

本文深入解析了Scipy优化模块中trust-constr和SLSQP两种方法在约束定义上的差异。通过对比面向对象的trust-constr和字典式定义的SLSQP,揭示了它们各自的优势与适用场景,帮助开发者在有约束优化问题中选择合适的算法,提升计算效率与准确性。

weixin_42573113的博客 271

Apache ShenYu网关K8s就绪探针终极指南:确保微服务高可用性

Apache ShenYu是Java原生的API网关,专注于服务代理、协议转换和API治理,是构建高可用微服务架构的关键组件。在Kubernetes环境中,就绪探针(Readiness Probe)是保障服务稳定性的核心机制,本文将全面介绍如何为Apache ShenYu网关配置K8s就绪探针,确保微服务集群持续可用。 ## 为什么Apache ShenYu网关需要K8s就绪探针? 在K8s集

gitblog_00241的博客 902

Spirent TestCenter 3.90吞吐测试全流程详解(附RFC 2544配置避坑指南)

本文详细解析了使用Spirent TestCenter 3.90进行网络吞吐测试的全流程,并提供了符合RFC 2544标准的配置指南与避坑要点。内容涵盖测试环境搭建、核心概念澄清、STC软件配置步骤、结果深度解读以及自动化脚本入门,旨在帮助网络测试工程师精准评估设备性能,规避常见配置陷阱。

weixin_42602368的博客 370

Camera metadata

Camera metadata

weixin_42136255的博客 2530

SSM框架实现户外广告监测平台的技术解析

SSM框架(Spring+SpringMVC+MyBatis)是Java企业级开发的经典组合,特别适合中等并发和复杂查询场景。其核心优势在于Spring的声明式事务管理、MyBatis的动态SQL灵活性以及SpringMVC的快速扩展能力。在广告监测领域,这种架构能有效处理物理状态监测、投放内容验证等业务需求,通过图像比对算法和实时数据可视化实现自动化管理。本文以户外广告监测平台为例,详细解析如何利用SSM框架处理动态查询优化、图像特征匹配等关键技术难点,为数字化广告管理提供可靠解决方案。

weixin_33778544的博客 335

机器人环境仿真软件:Gazebo_(6).传感器仿真

通过 Gazebo 和 ROS,我们可以方便地配置和使用多种传感器,进行机器人环境的仿真和调试。传感器仿真不仅帮助我们验证和测试机器人的感知能力,还可以在真实部署前发现和解决潜在的问题。本节详细介绍了如何在 Gazebo 中配置激光雷达、摄像头、IMU、声纳和 GPS 传感器,并展示了如何在 ROS 中接收和处理这些传感器数据。此外,还介绍了多传感器融合的基本方法和调试工具,希望这些内容能对你的机器人仿真工作有所帮助。

kkchenjj的博客 1389

ComfyUI-LTXVideo 使用指南:从安装、下模型到跑通第一个 LTX-2 视频工作流

ComfyUI-LTXVideo 是为 ComfyUI 打造的 LTX-2 视频生成模型配套节点包。它把文本生成视频、图像驱动视频、IC-LoRA 控制、HDR 与配音等功能拆成一个个可视化节点,并附带大量可直接导入的示例工作流。本文面向第一次接触该插件的用户,读完后你能完成:装好插件、下齐模型、导入示例工作流并生成第一条视频,知道各目录模型该放哪里、显存不够时怎么调。 ## 项目能帮你解决什么

gitblog_00514的博客 733

华为OD机试双机位C卷-几何平均值最大子数组(Py/Java/C/C++/Js/Go)

华为OD机试(机考)2026双机位C卷 【几何平均值最大子数组】,提供C语言、Java、C++、Python、Go、JavaScript源码实现,并提供完整思路讲解,以及在线OJ模拟做题。华为OD机试真题【几何平均值最大子数组】。

qq_45776114的博客 1367

ArcGIS笔记13_利用ArcGIS制作岸线与水深地形数据?建立水动力模型之前的数据收集与处理?

在利用MIKE建立水动力模型之前,需要收集、处理和制作诸多数据和资料,主要有岸线数据、水深地形数据、开边界潮位驱动数据、风场数据、潮位和海流观测资料和站点潮汐调和常数资料等。本篇主要介绍这些资料的获取与处理。

晏长街的博客 5949

生产级机器学习系统:从模型上线到可治理决策基础设施

机器学习模型部署不是终点,而是进入真实业务系统的起点。在金融、支付、风控等高敏场景中,模型必须作为可观察、可控制、可追责的工程实体运行——这要求超越算法本身,覆盖输入输出契约、特征时效性、SLA分级保障、决策链路完整性与漂移响应闭环。尤其当面临特征延迟、字段语义漂移、协议不兼容等集成风险时,‘模型服务’的稳定性往往由最弱依赖决定。本文聚焦生产环境中的防御性设计实践,融合监控信号预判衰减、三态决策流架构、业务导向的压力测试及区块链存证级审计追踪,将ML从黑箱决策还原为符合监管要求、支撑业务连续性的可信基础设施

dengkuituo0680的博客 439

深度学习(五)迁移学习(实战:新数据预测+vgg16和聚类预测)

6、成功引入PCA数据降维技术,剔除了数据中的噪音信息、降低了模型复杂度、减少了模型训练时间,并最终提高了模型表现;gen=datagen.flow_from_directory(path,target_size=(224,224),batch_size=2,save_to_dir=dst_path,save_prefix='gen',save_format='jpg') # 生成图片大小224*224,bs产生多少组图像,存储路径和前缀。1、通过使用新数据,实现了模型的2次训练,达到了较好的预测效果;

weixin_37699342的博客 775

Kubeadm 部署k8s实现并且演示滚动不停服务更新

k8s kubeadm pods 用户无感滚动更新

Harry_z666的博客 2280

lwip-2.0.3

lwip是瑞典计算机科学院(SICS)的Adam Dunkels 开发的一个小型开源的TCP/IP协议栈。实现的重点是在保持TCP协议主要功能的基础上减少对RAM 的占用。

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

Kubernetes 节点异常检测

我们需要通过某种机制来检查硬件的问题,基础服务的问题,比如NTP,社区提供了一个机制,它提供了node-problem-detector组件,它是一个demonset,在每个节点上面运行守护进程,这个守护进程就会对节点去做健康的诊断,它发现问题之后,就要以某种机制上报给kubernetes。这个组件在生产化集群里面它是一个非常必要的组件,可以去扩展你任何想要做的监控,当出现问题的时候,你去更新节点的信息,比如condition或者发送event来通知说这个节点出现了问题。内核问题∶内核死锁,文件系统损坏;.

小楼一夜听春雨,深巷明朝卖杏花 1409

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

K8s Deployment 滚动更新、金丝雀发布、自定义钩子、生命周期解析

本文深入剖析了Kubernetes Deployment的核心功能,包括滚动更新、金丝雀发布、自定义钩子以及生命周期管理。滚动更新策略通过逐步替换Pod实例,实现了服务的无缝升级,确保了业务连续性。金丝雀发布则通过在少量用户或节点上先行部署新版本,验证了其稳定性和性能,为全面上线提供了有力保障。自定义钩子则为开发者提供了在Deployment生命周期中的额外控制点,通过执行自定义操作满足复杂部署需求。

博客虽小,世界尽在其中 2460

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

上一篇: 计算机网络------数据链路层与交换机
下一篇: 计算机网络------虚拟局域网
cloud_engineer
博客等级 码龄5年 9390粉丝 65原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值