文章目录

官网参考地址：

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/

1. Deployment 基础

1.1 什么是 Deployment

Deployment 属于 k8s 中的一种工作负载资源，一个 Deployment 为 Pod 和 ReplicaSet （副本控制器）提供声明式的更细能力：

  • 我们只需要描述 Deployment 中的目标状态
  • Deployment 控制器以受控的速率（不间断）更改实际状态，使其变成我们所描述的目标期望状态（控制循环）
  • Deployment 使 Pod 有自愈能力
  • 我们部署应用一般不会直接写 Pod，而是部署一个 Deployment

1.2 简单体验 Deployment

来自官网的一个示例文件

####deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

我们尝试启动一下：kubectl apply -f deploy-demo.yaml

image-20230303144416122

image-20230303144601951

  1. 创建了一个名字为 nginx-deployment 的 Deployment，这个名称成为后续创建 ReplicaSet 和 Pod 的命名基础

  2. Deployment 创建了一个 ReplicaSet，由它创建了三个 Pod 副本

  3. .spec.selector 字段定义所创建的 ReplicaSet 如何查找要管理的 Pod。 在这里，选择在 Pod 模板中定义的标签（app: nginx），建议就保持一致即可

  4. template 字段里面其实就是一个 Pod的模板，和之前学习 Pod 写法是一样的

  5. 一次 Deployment，产生了如下资源

    • Deployment 资源
    • ReplicaSet资源
    • Pod 资源

1.3 Deployment 信息描述

检查 Deployment 信息

kubectl get deploy

image-20230303145059439

  • NAME 列出了名字空间中 Deployment 的名称
  • READY 显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”
  • UP-TO-DATE 显示为了达到期望状态已经更新的副本数
  • AVAILABLE 显示应用可供用户使用的副本数
  • AGE 显示应用程序运行的时间

检查 Deployment 上线状态

kubectl rollout status deploy nginx-deployment

image-20230303145318742

检查 Deployment 创建出来的 ReplicaSet 信息

kubectl get replicaset

image-20230303145442405

  • NAME 列出名字空间中 ReplicaSet 的名称
  • DESIRED 显示应用的期望副本个数，即在创建 Deployment 时所定义的值。 此为期望状态
  • CURRENT 显示当前运行状态中的副本个数
  • READY 显示应用中有多少副本可以为用户提供服务
  • AGE 显示应用已经运行的时间长度

检查 Pod 自动生成的标签信息

kubectl get pod --show-labels

image-20230303145625914

1.4 如何编写 Deployment

官网参考：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/deployment-v1/

  • 老办法，官网加命令参考如何编写一个资源 yaml 文件：kubectl explain deploy
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>  ## 标准的元数据信息
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec <Object>  ## 需要我们手动描述的行为规约
     Specification of the desired behavior of the Deployment.

   status       <Object>  ## 最近观测到的状态，k8s自动更新，不需要我们描述
     Most recently observed status of the Deployment.
  • 注意再看一下 spec 规约如何描述：kubectl explain deploy.spec
FIELDS:
   minReadySeconds      <integer> ##Pod就绪后被视为可用的时间，默认为0
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)

   paused       <boolean> ## 暂停部署
     Indicates that the deployment is paused.

   progressDeadlineSeconds      <integer> ## deployment部署的最大秒数，默认600s，超过就报错误了
     The maximum time in seconds for a deployment to make progress before it is
     considered to be failed. The deployment controller will continue to process
     failed deployments and a condition with a ProgressDeadlineExceeded reason
     will be surfaced in the deployment status. Note that progress will not be
     estimated during the time a deployment is paused. Defaults to 600s.

   replicas     <integer>  ##pod数量（副本数），默认是1 `RS`控制器实现的
     Number of desired pods. This is a pointer to distinguish between explicit
     zero and not specified. Defaults to 1.

   revisionHistoryLimit <integer>  ##保留允许回滚的旧 ReplicaSet 的数量。默认10
     The number of old ReplicaSets to retain to allow rollback. This is a
     pointer to distinguish between explicit zero and not specified. Defaults to
     10.

   selector     <Object> -required- ##指定要控制的pod的标签
     Label selector for pods. Existing ReplicaSets whose pods are selected by
     this will be the ones affected by this deployment. It must match the pod
     template's labels.

   strategy     <Object>  ## 更新策略
     The deployment strategy to use to replace existing pods with new ones.
           rollingUpdate	<Object> ## 指定滚动更新策略
           maxSurge	<string> ## 【最大增量】一次最多新建几个Pod。 百分比和数字都可以
              MaxUnavailable：为0 的时候， maxSurge不能为0
           maxUnavailable ## 【最大不可用量】最大不可用的Pod数量,最多杀几个pod
      type	<string>: Recreate/RollingUpdate（默认）

   template     <Object> -required- ## 必须描述项，描述将要创建的Pod，这个里面的写法就是我们之前学过的pod的写法
     Template describes the pods that will be created.
  • 小小的验证几下：
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

image-20230303163157266

2. Deployment 简单特性

2.1 赋予 Pod 故障转移和自愈能力

Deployment 赋予了 Pod 故障转移和自愈能力

  • 我们部署一个测试 yaml
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

image-20230303214742582

  • 尝试删除一些 Pod，并在另一个控制台观察一下状态：会自愈
kubectl get pod -owide -w

image-20230303220738194

image-20230303220838151

image-20230303220854345

  • 我们直接将k8s-03关机，看一下状态：在特定的时间内，会在其他节点启动故障的 Pod

image-20230303223157612

image-20230303223234449

2.2 更新 Deployment

什么时候才会触发更新 Deployment 呢？仅当 Deployment Pod 模板（即 .spec.template）发生改变时，例如模板的标签或容器镜像被更新， 才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作

更新上线动作原理： 创建新的 rs，准备就绪后，替换旧的 rs（此时不会删除，因为revisionHistoryLimit 指定了保留几个版本）

更新 Pod 镜像

  • 现在我们有一个示例文件在运行
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

image-20230303170726092

  • 我们先来更新一下 Pod 的镜像为：nginx
##可以直接改yaml文件进行更新
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx  ##修改镜像
  • 再执行一次：kubectl apply -f deploy-demo.yaml

image-20230303170954505

  • 查看一下上线状态：kubectl rollout status deploy nginx-deployment

image-20230303171339188

  • 查看一下 ReplicaSet 的信息：kubectl get rs

通过创建新的 ReplicaSet 并将其扩容到 3 个副本并将旧 ReplicaSet 缩容到 0 个副本完成了 Pod 的更新操作

image-20230303214211872

  1. 更新时会关闭一定数量的 Pod，默认情况下确保至少所需 Pod 的75%处于运行状态（最大比例为25%）
  2. 还确保仅所创建 Pod 数量只可能比期望 Pod 数高一点点。 默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 125%（最大峰值 25%）。

再观测一下更新状态

  • 启动一个测试
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个
      maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

image-20230304182940591

  • 更新它
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个
      maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6-alpine
  • 追踪状态

停止2个，启动4个

image-20230304183430242

最终更新到一个期待状态

image-20230304183710113

  • 获取一下 Deployment 的信息
kubectl describe deploy nginx-deployment

image-20230304183818866

最开始创建的时候，`Deployment`创建了 `RS`并将直接扩容到5个副本
更新的时候，创建一个新的 `RS`，并将其扩容为2，等待其就绪
旧的 `RS` 缩容到3
新的 `RS` 扩容到4
继续对 `RS` 扩缩容
最终5个可用的副本在新的 `RS` 中
旧的 `RS` 缩容为0

加深一下这个地方的理解

      maxSurge: 3 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量8个
      maxUnavailable: 4 ##更新期间可能不可用的最大Pod数量4个

image-20230304185122412

创建了一个新的 `RS`扩容到3，就绪准备
旧的 `RS` 缩容到1，以便最大不可用数量有4个
将新的 `RS` 扩容到5
将旧的 `RS` 缩容到0

Kubernetes 在计算 availableReplicas 数值时不考虑终止过程中的 Pod， availableReplicas 的值一定介于 replicas - maxUnavailable 和 replicas + maxSurge 之间。 因此，你可能在上线期间看到 Pod 个数比预期的多，Deployment 所消耗的总的资源也大于 replicas + maxSurge 个 Pod 所用的资源，直到被终止的 Pod 所设置的 terminationGracePeriodSeconds 到期为止。

比例缩放图示

在这里插入图片描述

2.3 回滚 Deployment

有时，你可能想要回滚 Deployment；例如，当 Deployment 不稳定时（例如进入反复崩溃状态）。 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。

Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。 这意味着仅当 Deployment 的 Pod 模板（.spec.template）发生更改时，才会创建新修订版本 – 例如，模板的标签或容器镜像发生变化。 其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。 这是为了方便同时执行手动缩放或自动缩放。 换言之，当你回滚到较早的修订版本时，只有 Deployment 的 Pod 模板部分会被回滚。

模拟一下错误滚动升级

  • 准备一个测试 yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
  • 模拟一下错误升级
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.1555
  • 查看一下状态

image-20230304193555979

  • 查看一下上线状态
kubectl rollout status deployment/nginx-deployment

###上线处于一个停滞状态
[root@k8s-01 k8s-yaml]# kubectl rollout status deployment/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 5 new replicas have been updated...

Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。 这行为取决于所指定的 rollingUpdate 参数（具体为 maxUnavailable）。 默认情况下，Kubernetes 将此值设置为 25%。

回滚操作

  • 检查 Deployment 修订历史：kubectl rollout history deployment/nginx-deployment

image-20230304193903516

CHANGE-CAUSE 的内容是从 Deployment 的 kubernetes.io/change-cause 注解复制过来的。 复制动作发生在修订版本创建时。你可以通过以下方式设置 CHANGE-CAUSE 消息：

  • 使用 kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1" 为 Deployment 添加注解。
  • 手动编辑资源的清单。
  • 查看修订历史的详细信息：kubectl rollout history deployment/nginx-deployment --revision=2

image-20230304194012820

  • 回滚到之前的修订版本：我们要回滚到版本1：kubectl rollout undo deployment/nginx-deployment --to-revision=1

撤消当前上线回滚到以前的修订版本：

kubectl rollout undo deployment/nginx-deployment

image-20230304194147104

2.4 暂停、恢复 Deployment 的上线过程

在你更新一个 Deployment 的时候，或者计划更新它的时候， 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时，你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。

  • 一个测试
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1

image-20230304204613168

  • 修改 yaml 文件暂停上线
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  paused: true ##true表示暂停上线，默认false
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
  • 修改 yaml 更新镜像
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  paused: true ##true表示暂停上线，默认false
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

image-20230304205328490

  • 从可观测的状态来看，这次更新并没有产生新的上线动作，也不会产生新的 RS

  • 我们再次修改更新一下镜像

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  paused: true ##true表示暂停上线，默认false
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6-alpine
  • 修改 .spec.paused ，恢复上线
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  paused: false ##true表示暂停上线，默认false
  replicas: 5  ## 5个副本
  selector:
    matchLabels:
      app: nginx
  strategy: ## 更新策略
    type: RollingUpdate
    rollingUpdate: ## 指定滚动更新策略
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6-alpine
  • 看一下状态：正常上线

image-20230304210114934

不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。

2.5 Deployment 规约描述

Pod 模板

.spec.template 是一个 Pod 模板。 它和 Pod 的语法规则完全相同。 只是这里它是嵌套的，因此不需要 apiVersion 或 kind

副本数

.spec.replicas 是指定所需 Pod 的可选字段。它的默认值是1。

选择算符

.spec.selector 是指定本 Deployment 的 Pod 标签选择算符的必需字段。

策略

.spec.strategy 策略指定用于用新 Pod 替换旧 Pod 的策略。 .spec.strategy.type 可以是 “Recreate” 或 “RollingUpdate”。“RollingUpdate” 是默认值

  • 重新创建：如果 .spec.strategy.type==Recreate，在创建新 Pod 之前，所有现有的 Pod 会被杀死。

  • 滚动更新：Deployment 会在 .spec.strategy.type==RollingUpdate时，采取 滚动更新的方式更新 Pod。你可以指定 maxUnavailable 和 maxSurge 来控制滚动更新 过程。

最大不可用

.spec.strategy.rollingUpdate.maxUnavailable 是一个可选字段，用来指定更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是所需 Pod 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。 如果 .spec.strategy.rollingUpdate.maxSurge 为 0，则此值不能为 0。 默认值为 25%。

例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。 新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容， 确保在更新期间可用的 Pod 总数在任何时候都至少为所需的 Pod 个数的 70%。

最大峰值

.spec.strategy.rollingUpdate.maxSurge 是一个可选字段，用来指定可以创建的超出期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pod 的百分比（例如，10%）。 如果 MaxUnavailable 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。

例如，当此值为 30% 时，启动滚动更新后，会立即对新的 ReplicaSet 扩容，同时保证新旧 Pod 的总数不超过所需 Pod 总数的 130%。一旦旧 Pod 被杀死，新的 ReplicaSet 可以进一步扩容， 同时确保更新期间的任何时候运行中的 Pod 总数最多为所需 Pod 总数的 130%。

进度期限秒数

.spec.progressDeadlineSeconds 是一个可选字段，用于指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 type: Progressing、status: False、 reason: ProgressDeadlineExceeded。Deployment 控制器将在默认 600 毫秒内持续重试 Deployment。 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。

如果指定，则此字段值需要大于 .spec.minReadySeconds 取值。

最短就绪时间

.spec.minReadySeconds 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）

修订历史版本限制

Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。

.spec.revisionHistoryLimit 是一个可选字段，用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。

更具体地说，将此字段设置为 0 意味着将清理所有具有 0 个副本的旧 ReplicaSet。 在这种情况下，无法撤消新的 Deployment 上线，因为它的修订历史被清除了。

暂停

.spec.paused 是用于暂停和恢复 Deployment 的可选布尔字段。 暂停的 Deployment 和未暂停的 Deployment 的唯一区别是，Deployment 处于暂停状态时， PodTemplateSpec 的任何修改都不会触发新的上线。 Deployment 在创建时是默认不会处于暂停状态

# kubernetes # 学习 # 云原生 # 运维 # 容器
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes