K8S Deployment 控制器 理论+代码+图例=深入浅出

原创 已于 2025-04-30 14:51:06 修改 · 1k 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #运维 #服务器

于 2025-02-05 22:30:41 首次发布

一、理论介绍

今天我们来实验 Deployment 控制器（也叫工作负载）。官网描述如下：

1、是什么？

Deployment 是一个非常重要的资源对象，它为 Pod 和 ReplicaSet 提供了声明式的更新能力，常用于管理无状态应用程序的部署和更新。

2、为什么需要？

为 Pod 和 ReplicaSet 提供了声明式的更新能力。

所谓声明式更新指的是用户只需描述期望的资源最终状态，比如定义 Deployment、Service 等资源的 YAML 文件，详细说明资源的属性、副本数量、使用的镜像等信息。Kubernetes 系统会自动对比当前资源的实际状态和期望状态，然后采取必要的操作，使实际状态逐渐趋近并最终达到期望状态。

声明式更新最常用的命令，就是 kubectl apply -f <directory>

3、缺点

无法部署有状态应用。

1.1、基础信息

kubectl explain deploy
# deploy 是 deployment 的缩写

apiVersion：当前资源使用的 api 版本，是 GROUP/VERSION 的组合。

kind：资源类型，跟 KIND 保持一致。

metadata：元数据。定义资源名称、标签、注解等。

spec：规范、规约。定义 Pod 副本数、Pod 标签选择器、Pod 模板。

status：状态信息，只读，一般不会去修改。

 1.2、DeplymentSpec 规约

kubectl explain deploy.spec

minReadySeconds：pod 变为就绪状态之后，还⾄少需要保持多少秒，才能被视为真正可⽤的，以继续后续部署过程。一般配合就绪探针使用。

paused：指示 deployment 是否被暂停。执行 kubectl rollout pause 后会被设置为 true。详细参考下文金丝雀发布。

replicas：Pod 副本数。

revisionHistoryLimit：保留的旧的 ReplicaSet 历史版本数。默认是 10。

Deployment 通过创建 ReplicaSet 来间接管理 Pod。

Deployment 控制器是建立在 rs 之上的一个控制器，可以管理多个 rs，每次更新镜像版本，都会生成一个新的 rs，把旧的 rs 替换掉，多个 rs 同时存在，但是只有一个 rs 运行。

Deployment 通过回滚 ReplicaSet 来回滚镜像版本。

selector：标签选择器。用于查找它所要管理的 Pod。它必须跟 Pod 模板的标签（template.metadata.labels）相匹配。

template：Pod 模板。定义 Pod 的模板。

可以看到 template 内部主要就是定义 Pod 的规范（PodSpec）它跟 Pod 定义里的规范（Pod.spec）是同一个类型。

strategy：pod 更新策略。

  • type：有两种取值 Recreate, RollingUpdate（默认）。

               ○ Recreate：重建式。删除所有已经存在的 Pod，再重新创建新的 Pod。

               ○ RollingUpdate：滚动更新式。以配置的速率来控制 pod 的增加和减少。

                                      配置详见 rollingUpdate 字段。

  • rollingUpdate：当 type=RollingUpdate 时，这个字段才起作用。

               ○ maxSurge：决定了在滚动升级期间，除了 replicas 配置的期望的副本数之外，                                          最多允许超出的 pod 实例的数量。它有两种取值方式，

                                      第一种是绝对值，第二种是根据百分比。

                                      默认值为 25%。

                                      绝对值按百分比向上取整（rounding up）。

               ○ maxUnavailable：决定了在滚动升级期间，

                                      最多允许几个不可用（相对于replicas）。它有两种取值方式，

                                      第一种是绝对值，第二种是根据百分比。

                                      默认值为 25%。

                                     绝对值按百分比向下取整（rounding down）。

               ○ 就比如 replicas=5，maxSurge=25%，maxUnavailable=25%，那么在滚动升级                                         期间，最多可以超出 5*25%=1.25 --> 2个。最多的时候，可以有                                             5+2=7 个 pod 在运行（不保证全部可用）。

                                     最多可以有 5*25%=1.25 --> 1个不可用。则最少有 5-1=4 个 pod 可                                         以提供服务。

1.3、滚动更新过程

  • 当 replicas=3，maxSurge=1，maxUnavailable=0 时，滚动更新的过程如下图。

rs1 控制三个 v1 pod，滚动更新开始后，先在 rs2 上新建一个 v2 pod，待该 pod 就绪后，在 rs1 上删除一个 v1 pod 的同时，又在 rs2 上新建一个 v2 pod。依次类推，直到全部都是由 rs2 控制。

  • 当 replicas=3，maxSurge=1，maxUnavailable=1 时，滚动更新的过程如下图。

rs1 控制三个 v1 pod，滚动更新开始后，先在 rs2 上新建两个 v2 pod 并在 rs1 上删除一个 v1 pod，待该两个 v2 pod 就绪后，马上又在 rs1 上删除两个 v1 pod 并新建一个 v2 pod。待这最后一个 pod 就绪后，所有的 pod 就全部都是由 rs2 控制。

 分析上图会发现，当 maxUnavailable=1，在更新过程中有一段时间会出现，可用的 pod 数，少于 replicas=3 期望的副本数（3-maxUnavailable=2）的情况，这在高可用系统中是不允许的。

比如，我有一个应用，它需要3个 pod 才能稳定提供服务。现在在更新的过程中，有一段时间，它有1个 pod 不可用，那势必造成另外两个 pod 流量短时间内激增。

  • 最佳实践：maxUnavailable 设置为 非0 的话，在滚动升级期间会有可用 pod 数少于期望副本数的情况。从高可用的角度来讲，这个值最好设置为 0。

 二、镜像准备

假设有如下三个节点的 K8S 集群：

k8s31master 是控制节点

k8s31node1、k8s31node2 是工作节点

容器运行时是 containerd

使用 springboot 打包两个镜像 hellok8s-1.0.jar.gz 和 hellok8s-2.0.jar.gz。

hellok8s:1.0

@RestController
public class HelloController {

    @GetMapping("/sayHello")
    @ResponseBody
    public String sayHello() {
        # 蓝
        return "Hello,I am Blue";
    }
}

hellok8s:2.0

@RestController
public class HelloController {

    @GetMapping("/sayHello")
    @ResponseBody
    public String sayHello() {
        # 绿
        return "Hello,I am Green";
    }
}

它们的区别仅在输出的问候信息不同，一个 Blue、一个 Green.

  •  导入镜像
# node1 执行
[root@k8s31node1 ~]# ctr -n=k8s.io images import hellok8s-1.0.jar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images import hellok8s-2.0.jar.gz
# node2 执行
[root@k8s31node2 ~]# ctr -n=k8s.io images import hellok8s-1.0.jar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images import hellok8s-2.0.jar.gz

三、Deployment 自动化部署

  • 资源文件编写

deploy-first.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hellok8s
  template:
    metadata:
      labels:
        app: hellok8s
    spec:
      containers:
      - name: hellok8s
        image: hellok8s:1.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
  • replicas=2，期望副本数是 2。
  • selector.matchLabels 要与 template.metadata.labels 相匹配。
  • startupProbe 是启动探针、readinessProbe 是继续探针、livenessProbe 是存活探针。

             ○ httpGet 是探测模式，以 http 请求方式探测。

             ○ initialDelaySeconds 初始探测延迟时间，表示容器启动后多少秒开始探测。

             ○ periodSeconds 表示两次探测的时间间隔是多少秒。

  • 执行并查看
kubectl apply -f deploy-first.yaml
kubectl get deploy

[root@k8s31master deploy]# kubectl get deploy
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
my-deploy   0/2          2                      0                   3s
[root@k8s31master deploy]# kubectl get deploy
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
my-deploy   2/2          2                      2                   12s

  1. NAME ：deployment 的名称。
  2. READY：显示 deployment 有多少副本数。它遵循 ready/desired的模式。
  3. UP-TO-DATE： 显示已更新到所需状态的副本数。
  4. AVAILABLE：已就绪的副本数。
  5. AGE ：显示应用程序已运行的时间。
  •  查看 ReplicaSet
kubectl get rs

创建 deploy 的时候也会创建一个 rs（ReplicaSet）。

  1. NAME： ReplicaSet 的名称。命名规范为 [deployment-name]-[pod-template-hash]。 
  2. DESIRED：期望的副本数。
  3. CURRENT：当前正在运行的副本数。
  4. READY： 已就绪的副本数。
  5. AGE ：显示应用程序已运行的时间。
kubectl describe rs my-deploy-569b69f85d

  •  查看 Pod
kubectl get pod

四、Deployment 实现 Pod 的动态扩容

修改 deploy-first.yaml，replicas: 2 改为 3

replicas: 3

  • 重新运行并查看
kubectl apply -f deploy-first.yaml
kubectl get pod -owide

可以看到 新创建了一个 pod，名称是 my-deploy-569b69f85d-hzfzg

  • 访问接口

 可以看到，三个 pod 的服务是一样的，返回的都是 Blue。

五、Deployment 实现 Pod 的滚动更新

修改 deploy-first.yaml，image: hellok8s:1.0 改为 2.0

image: hellok8s:2.0

  • 重新运行并监控
kubectl apply -f deploy-first.yaml
kubectl get pod -owide -w
NAMEREADYSTATUSAGEIPNODE
my-deploy-569b69f85d-cw7wt1/1Running52m10.244.9.3k8s31node2
my-deploy-569b69f85d-hzfzg1/1Running12m10.244.165.29k8s31node1
my-deploy-569b69f85d-qrm5p1/1Running52m10.244.165.28k8s31node1
my-deploy-7cf64887cf-kbjwg0/1Pending0s<none><none>
my-deploy-7cf64887cf-kbjwg0/1Pending0s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1ContainerCreating0s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1ContainerCreating1s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1Running1s10.244.9.6k8s31node2
my-deploy-7cf64887cf-kbjwg0/1Running11s10.244.9.6k8s31node2
my-deploy-7cf64887cf-kbjwg1/1Running11s10.244.9.6k8s31node2
my-deploy-569b69f85d-hzfzg1/1Terminating13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1Pending0s<none><none>
my-deploy-7cf64887cf-89w8b0/1Pending0s<none>k8s31node1
my-deploy-7cf64887cf-89w8b0/1ContainerCreating0s<none>k8s31node1
my-deploy-569b69f85d-hzfzg1/1Terminating13m10.244.165.29k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1ContainerCreating1s<none>k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1Running2s10.244.165.30k8s31node1
my-deploy-7cf64887cf-89w8b0/1Running11s10.244.165.30k8s31node1
my-deploy-7cf64887cf-89w8b1/1Running11s10.244.165.30k8s31node1
my-deploy-569b69f85d-qrm5p1/1Terminating53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1Pending0s<none><none>
my-deploy-7cf64887cf-crw520/1Pending0s<none>k8s31node2
my-deploy-7cf64887cf-crw520/1ContainerCreating0s<none>k8s31node2
my-deploy-569b69f85d-qrm5p1/1Terminating53m10.244.165.28k8s31node1
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1ContainerCreating1s<none>k8s31node2
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1Running2s10.244.9.5k8s31node2
my-deploy-7cf64887cf-crw520/1Running11s10.244.9.5k8s31node2
my-deploy-7cf64887cf-crw521/1Running11s10.244.9.5k8s31node2
my-deploy-569b69f85d-cw7wt1/1Terminating53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt1/1Terminating53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
  •  过程分析

我们 deploy-first.yaml 没有配置 spec.strategy，都走默认配置，等效于

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate: 
      maxSurge: 25%
      maxUnavailable: 25%
......
......
......

replicas=3

maxSurge=3*0.25=0.75=1（向上取整）最大允许超出 1 个。

maxUnavailable=3*0.25=0.75=0（向下取整）最大允许不可用为 0 个。也就是无论何时，系统都要保持至少3个副本可用。

 Deployment 滚动升级时的三个副本数和默认maxSurge、maxUnavailable 配置关系如下：

  1. 滚动更新之前，系统里面有3个 v1.0 的副本 cw7wt、qrm5p、hzfzg。
  2. 滚动更新开始后，kubelet 创建一个 v2.0 版本的 pod  kbjwg。因为有就绪探针，此时它并没有处于可用状态。系统中现在有3个可用副本，一个不可用副本。
  3. 等到 kbjwg 就绪探针探测成功后，系统中有4个可用副本。
  4. 紧接着 kubelet 删除一个 v1.0 的 pod hzfzg 并创建一个 v2.0 版本的 pod 89w8b。
  5. 以此类推，直到3个 v2.0 版本的 pod 都处于可用状态，这个时候 kubelet 才删除最后一个 v1.0 pod cw7wt。

 整个过程可以抽象成下面这张图：

  •  访问接口

可以看到，所有 pod 的版本，已经都被替换为 2.0 了。

  •   查看 ReplicaSet
kubectl get rs

可以看到有 2 个 rs 存在， my-deploy-569b69f85d 就是升级之前 v1.0 的 deploy 生成的 rs。

  • 扩展

 对于 replicas=3，maxSurge=1，maxUnavailable=1 大家可以很容易画出下面这张图。

大家可以根据我上面的思路，自行画看看。

 六、Deployment 实现 Pod 的版本回退

  • 查看控制器的滚动历史
kubectl rollout history deploy my-deploy

  • 版本号从1开始，依次递增
  • 版本号 0 表示最后的修订。

  • 创建 deploy 如果不给定 --record 参数，版本历史中的 CHANGE-CAUSE 这⼀栏会为空。这也会使⽤户很难辨别每次的版本做了哪些修改。
  •  回滚到⼀个特定的 Deployment 版本

通过在 undo 命令中指定⼀个特定的版本号，便可以回滚到那个特定的版本。例如，如果想回滚到第⼀个版本，可以执⾏下述命令:

kubectl rollout undo deploy/my-deploy --to-revision=1
或者
kubectl rollout undo deploy my-deploy --to-revision=1

  • 查看 ReplicaSet
kubectl get rs

 ReplicaSet 版本，回滚到上一个版本。

  •  访问接口

 可以看到，所有 pod 的版本，已经都被替换为 1.0 了。

  •  回滚到上一个版本
kubectl rollout undo deploy/my-deploy

 直接 undo 就行，因为 --to-revision 默认等于0，就是上一个版本。

 七、Deployment 实现 Pod 的动态缩容

副本数从 3 缩容到 2

kubectl patch deployment my-deploy -p '{"spec":{"replicas":2}}'
# patch 以打补丁的方式，修改资源
# -p  patch 的缩写

八、Deployment 实现 Pod 的重建式更新

修改 deploy-first.yaml，把 pod 更新策略变成 Recreate。

  • 执行并监控
kubectl apply -f deploy-first.yaml --record
kubectl get pod -owide -w
NAMEREADYSTATUSRESTARTSAGEIPNODE
my-deploy-569b69f85d-6bgg61/1Running1(11mago)2d8h
my-deploy-569b69f85d-k42m91/1Running1(11mago)2d8h
my-deploy-569b69f85d-jz8gb0/1Pending00s<none><none>
my-deploy-569b69f85d-jz8gb0/1Pending00s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerCreating00s<none>k8s31node1
my-deploy-569b69f85d-6bgg61/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-k42m91/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-jz8gb0/1Terminating00s<none>k8s31node1
my-deploy-569b69f85d-6bgg61/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-k42m91/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-7cf64887cf-4n7660/1Pending00s<none><none>
my-deploy-7cf64887cf-w8bhs0/1Pending00s<none><none>
my-deploy-7cf64887cf-4n7660/1Pending00s<none>k8s31node1
my-deploy-7cf64887cf-8hsdj0/1Pending00s<none><none>
my-deploy-7cf64887cf-w8bhs0/1Pending00s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Pending00s<none>k8s31node2
my-deploy-7cf64887cf-4n7660/1ContainerCreating00s<none>k8s31node1
my-deploy-7cf64887cf-w8bhs0/1ContainerCreating00s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1ContainerCreating00s<none>k8s31node2
my-deploy-7cf64887cf-4n7660/1ContainerCreating01s<none>k8s31node1
my-deploy-7cf64887cf-w8bhs0/1ContainerCreating01s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1ContainerCreating01s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Running02s10.244.9.11k8s31node2
my-deploy-7cf64887cf-w8bhs0/1Running02s10.244.9.10k8s31node2
my-deploy-7cf64887cf-4n7660/1Running02s10.244.165.33k8s31node1
my-deploy-7cf64887cf-4n7660/1Running011s10.244.165.33k8s31node1
my-deploy-7cf64887cf-w8bhs0/1Running011s10.244.9.10k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Running011s10.244.9.11k8s31node2
my-deploy-7cf64887cf-8hsdj1/1Running011s10.244.9.11k8s31node2
my-deploy-7cf64887cf-w8bhs1/1Running011s10.244.9.10k8s31node2
my-deploy-7cf64887cf-4n7661/1Running011s10.244.165.33k8s31node1
  • 过程分析
  • 刚开始我们有两个 1.0 版本的 pod：6bgg6、k42m9
  • 因为  deploy-first.yaml 文档 replicas=3，kubelet 尝试再创建一个 1.0 版本的 jz8gb。
  • kubelet 发现 pod 更新策略变成 Recreate。删除所有已经存在的 1.0 版本 Pod：6bgg6、k42m9、jz8gb，再重新创建新的 2.0 版本 Pod：8hsdj、w8bhs、4n766。
  • 重建式更新策略 Recreate，会删除所有已经存在的 pod，再重新创建新的 pod，所以会造成线上服务在版本更新的时候不可用，所以生产环境很少采用这种方式。
  •  查看滚动历史
kubectl rollout history deploy/my-deploy

  •  可以看到，加了 --record 参数后，CHANGE_CAUSE 会帮我们记录下更新原因了。
  • --record 参数已被官方标记为 已过时。

  • 可以通过手动添加 kubernetes.io/change-cause 注解的方式，来记录 CHANGE_CAUSE。
  • 例如，在更新 Deployment 后，运行以下命令来设置变更原因：
kubectl annotate deployment/<deployment-name> kubernetes.io/change-cause="Your change description here"
  • 确保替换 <deployment-name> 为你实际的 Deployment 名称，并将 "Your change description here" 替换为描述此次变更的实际文本。
  •  查看 rs、pod 

  •  访问接口

尝试在集群不同节点上访问接口：

[root@k8s31master ~]# curl 10.244.165.33:8080/sayHello
[root@k8s31node1 ~]# curl 10.244.9.11:8080/sayHello
[root@k8s31node2 ~]# curl 10.244.9.10:8080/sayHello

 可以看到，所有版本都升级为 2.0 了。

从这也能看出，pod 的 IP 是一种 clusterIp，集群内的任何节点都能正常访问到。

  • 删除 deploy

删除 deploy，为下面的实验做准备。

kubectl delete -f deploy-first.yaml
kubectl get deploy
kubectl get rs
kubectl get pod -owide

从这也能看出，删除 Deployment，则它所创建的 ReplicaSet、Pod 也会被一并删除。

九、Deployment 实战之 蓝绿 发布

参考我的另一篇博文。

十、Deployment 实战之 金丝雀 发布

参考我的另一篇博文。

K8S 专栏 —— Deployment 篇
dsd的博客
06-16 60
Deployment 是 K8S 中用于管理应用程序副本的对象，它提供了对应用程序的声明式定义，自动化部署、扩展和更新。
K8S中Deployment控制器的概念、原理解读以及使用技巧
景天科技苑
01-21 2269
Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法， 在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态， 通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器， 也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.
k8s之Deployment篇
weixin_51697758的博客
08-03 7296
Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源....
k8s之Deployment详解
热门推荐
lixinkuan的博客
01-15 4万+
一、官方介绍 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment为Pod和Replica Set提供声明式更新。 你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的...
k8s中的deployment
wang959512421的博客
12-27 1万+
Deployment是k8s中用来管理发布的控制器，在开发的过程中使用非常频繁，本篇文章主要介绍deployment相关的使用和原理。 声明式API 最终一致性 水平触发 资源对象 。。。 一，Deployment的作用 定义一组pod的期望数量，controller会维持Pod的数量和期望的一致（其实deployment是通过管理rs的状态来间接管理pod） 配置Pod的发布方式，controller会按照给定的策略去更新pod资源，以此来保证更新过程中可用的pod数量和不可...
k8s Deployment
xts_huangxin的博客
07-12 2万+
Deployment是新一代用于Pod管理的对象，与Replication Controller相比，它提供了更加完善的功能，使用起来更加简单方便。
【云原生|Kubernetes】13-Deployment资源控制器详解
qq_43714097的博客
07-11 2917
kubernetes中有很多资源控制器，这些资源控制器我们只说一些重要且常用的。在介绍Deploymen之前，我们会逐个介绍这些控制器。​ Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性一个 Deployment 为Pod和ReplicaSet。
【云原生_K8S系列】Kubernetes 控制器之 Deployment
didiplus
06-06 2274
Deployment 是 Kubernetes 中的一个控制器，它管理 Pod 的副本集（ReplicaSet）。通过定义 Deployment，用户可以描述一个应用的期望状态，例如需要多少个副本、使用什么镜像以及如何进行滚动更新。Deployment 会根据这些定义自动创建和管理 Pod，确保应用始终处于期望状态。动态创建和销毁 Pod查看升级进度和状态升级回滚，并具有版本记录暂停和恢复升级滚动重启Kubernetes Deployment 是管理应用生命周期的强大工具。
k8s控制器Deployment使用详解
congge
02-01 7165
k8s 中Deployment使用详解
【Jenkins+K8s】持续集成与交付 （二十）：K8s集群通过Deployment方式部署安装Jenkins
✨ 欢迎来到【Seal ^_^ 的优快云博客】！✨
06-11 2万+
本文将介绍如何在 Kubernetes 集群上安装和配置 Jenkins。
架构师系列-k8s（四）-Deployment控制器
dengwei_dw的专栏
04-27 1356
Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态，也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
【k8s 控制器：ReplicaSet、Deployment、StatefulSet ...】
CodeStar`
06-05 1290
ReplicaSet、Deployment、StatefulSet 和 DaemonSet 都是 Kubernetes 中的控制器对象，用于管理 Pod 的创建、扩展、缩减和更新等操作。
k8s之Deployment简介
花&败
04-16 1121
一、简介 ​ 在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。 在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。 二、Pod和Controller关系 Pod和Controller关系： Pod是通过Controller实现应用的运维比如伸...
K8S之Deployment的介绍和使用
weixin_40364776的博客
02-27 2844
Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。
K8S Deployment 简介， 1个简单的Kubernetes Deployment YAML 文件
nvd11的专栏
04-04 2048
当谈到 Kubernetes 集群中的应用程序部署和管理时，Deployment、ReplicaSet 和 Pod 是三个重要的概念。它们之间存在一定的关系和层次结构。下面是对 Deployment、ReplicaSet 和 Pod 的详细解释以及它们之间的关系。
k8s—pod副本控制器Deployment
最新发布
qinxue722的博客
07-26 1220
Deployment是⼀个定义及管理多副本应⽤（即多个副本 Pod）的新⼀代对象，与Replication Controller相⽐，它提供了更加完善的功能，使⽤起来更加简单⽅便。也会在宿主机上创建⼀个临时⽬录，这个⽬录将来就会被绑定挂载到容器所声明的 Volume ⽬录上。的副本，也就是副本集 ，这样就能够保证⼀定数量的副本⼀直可 ⽤，不会因为某⼀个Pod。所谓内部信息，指的是对这些信息感兴趣的，是 Kubernetes。#空的volume，创建出来的容器相应挂载目录也是空的。
Kubernetes — 了解k8s中的deployment部署单元
qq_38658567的博客
12-20 1693
一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。Kubernetes中的Deployment是一种资源对象，用于定义和管理Pod的副本集。它提供了一种声明式的方式来创建、更新和删除Pod副本。Deployment可以确保指定数量的Pod副本在集群中运行，并且可以自动处理Pod的扩容和缩容。Deployment通过使用ReplicaSet（RS）来实现Pod的副本控制。RS是一个控制器，它确保指定数量的Pod副本在集群中运行，并且可以根据需要进行扩展或缩减。
Kubernetes(k8s)的Pod控制器Deployment详细讲解
Bulut0907
07-27 6327
Deployment控制器并不直接管理Pod，而是通过管理ReplicaSet来间接管理Pod。所以Deployment的功能比ReplicaSet强大。支持扩缩容、发布的停止和继续、镜像版本滚动变更、ReplicaSet版本回退Deployment的资源清单文件模板apiVersionapps/v1kindmetadatanamepod-controller#deploy名称namespacedev#deploy所属命名空间labels#给deploy打标签。...
k8s之Deployment
Crazy博客
09-02 3470
Deployment快速了解
深入理解K8S集群控制器：从冰箱设计到实战解析
"K8S(kubernetes)学习指南.pdf 是一本入门级的Kubernetes书籍，主要涵盖K8S的关键概念和技术，包括集群控制器、网络、伸缩、认证与调度、服务实现、镜像管理等内容，并提供了实践案例，如集群节点管理、安全组配置和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值