关于资源管理器:Kubernetes资源编排系列之三-Kustomize篇

作者艄公(杨京华) 雪尧(郭耀星)

这是咱们的《Kubernetes 资源编排系列》的第三篇——Kustomize 篇，在上篇（《Kubernetes 资源编排系列之二: Helm 篇》，可从文末链接中转）咱们见识到了 Helm 弱小的治理能力，然而 Helm 对于服务的定制仅限于预置变量，那么如果须要更多更灵便的 YAML 定制，有什么方法吗？于是本篇咱们来介绍一下 Kustomize。

Kustomize 是一套采纳合并思维，对 Kubernetes 原生配置进行治理的工具，应用无模板的计划定义利用配置。容许用户应用一系列的形容文件为根底，而后通过 overlay 的形式生成最终部署利用所需的形容文件。

Kustomize 通过 Base&Overlays 形式保护不同环境的利用配置，在 Overlay 中形容差别来实现资源复用，治理的是 Kubernetes 原生 YAML 文件，不须要学习额定的 DSL 语法。

Kustomize 的文件构造如下：

app
├── base
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays
    ├── production
    │   └── kustomization.yaml
    ├── staging
    │   └── kustomization.yaml
    └── production-large
        └── kustomization.yaml

app/base/kustomization.yaml 申明资源及要利用于它们的一些自定义，如增加一个通用的标签，其内容如下。kustomization 还提供了 namePrefix、commonAnnoations、images 等配置项。

commonLabels:
  name: app
resources:
- deployment.yaml
- service.yaml

能够通过 kustomize build 命令来看残缺的配置，build 进去的每个资源对象上都会存在通用的标签 name: app。

kustomize build app/base  # 构建
kustomize build app/base | kubectl apply -f -  # 构建并部署
kubectl apply -k app/base # 1.14 及更新的版本能够应用该命令间接部署

app/overlays/staging/kustomization.yaml 中能够为演示环境定义不同的名称前辍、标签，通过 patch 的计划将正本数设置为 1

bases:
- ../../base
commonLabels:
  env: staging
namePrefix: staging-
patches:
  - target:
      kind: Deployment
      name: app
    patch: |
      [{"op":"replace","path":"/spec/replicas","value":1}
      ]

app/overlays/production/kustomization.yaml 中能够为生产环境定义不同的名称前辍、标签，通过 patch 的计划将正本数设置为 2

bases:
- ../../base
commonLabels:
  env: production
namePrefix: production-
patches:
  - target:
      kind: Deployment
      name: app
    patch: |
      [{"op":"replace","path":"/spec/replicas","value":2}
      ]

app/overlays/production-large/kustomization.yaml 中能够继承生产环境的定义，同时将正本数设置为 10 撑持大规模场景需要。

bases:
- ../production
patches:
  - target:
      kind: Deployment
      name: app
    patch: |
      [{"op":"replace","path":"/spec/replicas","value":10}
      ]

通过不同的部署门路，指定不同的环境部署

kustomize build app/overlays/production | kubectl apply -f -
kustomize build app/overlays/staging | kubectl apply -f -
kustomize build app/overlays/production-large | kubectl apply -f -

通过下面的例子咱们能够看出，通过 kustomization.yaml 来申明继承和 patch，能够为各种场景结构不同的 YAML 输入，同时放弃底座 YAML 不变动。

Kustomize 的 Overlay 能够在 Base 的根底上，通过对 resource / generator / transformer 等的定义，造成新的利用定义，不论是 Base 还是 Overlay，都能够通过 kustomize build 生成无效的 YAML。
● 性能简略清晰，kubectl 间接外部反对
● 不思考派生，仅仅作为组件的 YAML 组织形式也很有帮忙
● 也有本人的插件零碎，例如能够用简略的 YAML 定义，应用文件生成 ConfigMap / Secret 等
● 容许注入 K8S 运行时数据

Kustomize 绝对于 Helm 而言，更加的轻量，只有一个 CLI 工具。也集成到了 kubectl 本身，应用及配置老本靠近于 0。Kustomize 放弃了对模板的要求，改为参考 Docker 镜像的模式，通过 Base + Overlay 的形式对利用的原始 YAML 进行派生。
● Base YAML 管控：Helm 最大的特点是定制仅限于事后存在的配置选项。不仅如此，Chart 作者还必须用有点麻烦的模板化形式实现这些定制选项。这个时候 Kustomize 不受限制的 Overlay 会更加灵便，想怎么笼罩就怎么笼罩。所以 Helm 对 Base YAML 强管控；而 Kustomize 尽管也有 Base，但 Overlay 的存在让这个限度简直不存在。
● 模板语法层面：Kustomize 相较于 Helm 去掉了模板语法，入门门槛更低，更易使用。当然如果玩的高阶，两者都要学习很多货色。
● 部署层面：尽管 Kustomize 最为轻量，但因为 Helm3 勾销了 Tiller 依赖，所以差异也不是很大，两者都是二进制命令工具生成 YAML 后间接下发。
● 工作流程上：
○ Helm: 定义 Chart -> 填充 -> 运行。在 Chart 中没有定义的内容是无奈更改的
○ Kustomize: Base 和 Overlay 都是能够独立运作的，减少新对象，或者对编写 Base 时未预料到的内容进行变更，都非常简单

基于上述工作流程的比照，如果是要公开公布一个简单的组件，编写一个简单而设计良好的 Helm Chart 能够给用户很大帮忙。用户在缺失了自由性之下，仅仅通过 values.yaml 的浏览和配置就能够对这种简单的部署产生一个较为深刻的认知。

如果是常见的业务利用，尽管不同的部署之间差别不大（比方日常预发生产），然而因为疾速迭代及需要变动，未必能够一开始就做好相干的变动限度，用 Kustomize 是更好的抉择。

对于承载利用 (Application) 这个概念而言，Kustomize 和 Helm 的短板是统一的，都没有进一步提供包之间的依赖解决、内部资源申请及保护、变量间传递等能力。

对于承载组件 (Component) 这个概念而言，Kustomize 和 Helm 相似，都是适合的工具。尽管 Helm 和 Kustomize 在本身的能力和流程上有着很多区别，但最终流程都是：开发者(一堆 YAML) -> 适合的参数映射及渲染形式 -> 使用者(填参 / 笼罩) -> apply 到指标 K8S 中。萝卜青菜，各有所爱。

在 SREWorks 的 appmanager 中，将 Kustomize 与 Helm 并列放在一起成为一种组件类型，以后这种组件类型还未内置到出厂组件中，后续会上架到云端市场，供用户插拔装置。

- revisionName: "CHART|sreworks@management-controlplane@1.0|_"
  parameterValues:
    - name: Map
      value:
        clusterId: "{{Global.clusterId}}"
        product: es
        userID: "{{Global.uid}}"
        vpcID: "{{Global.vpcID}}"
        vswitchID: "{{Global.vswitchID}}"
        namespaceRegexes: "^(essen|es)$"
- revisionName: KUSTOMIZE|elasticsearch-repos@2.0.1@test|_
  parameterValues:
    - name: kubeconfig
      value: "{{Global.kubeconfig}}"
      toFieldPaths:
        - spec.base64Kubeconfig
    - name: path
      value: "./"
      toFieldPaths:
        - spec.path
  dependencies:
    - component: "CHART|sreworks@management-controlplane@1.0"
- revisionName: "STATUS|KUSTOMIZE@esonack-cluster-baselines|_"
  dependencies:
    - component: KUSTOMIZE|es-cluster-baselines@3.1.0@test
  parameterValues:
    - name: kubeconfig
      value: "{{Global.kubeconfig}}"
      toFieldPaths:
        - spec.base64Kubeconfig
    - name: options
      value:
        groups:
          - namespace: sreworks-system
            labels:
              app: sreworks
            resources:
              - v1/pods
      toFieldPaths:
        - spec.options

如下面所示，在 appmanager 中的 OAM YAML 中，插入 Helm 和 Kustomize 两种组件，并且设置依赖关系，在 Helm 组件下发实现后，再进行 Kustomize 组件的下发；在 Kustomize 组件下发实现后，对外围 Pod 进行状态探测，待 Pod 失常之后才算作部署实现。

Kustomize 是一个通用工具，它的作用是对 Kubernetes 资源进行定制后产生新的 YAML 文件，并放弃原始的 YAML 文件不变。从这个意义上来说，你能够把 Kustomize 看成是 Kubernetes YAML 文件的转换工具，相似 XML 和 XSLT 的关系。

Kustomize 的一个重要特色是不应用模板，而是间接工作在原始的 YAML 文件上。这一点与 Helm 是不同的。不应用模板益处在于简略易懂，不须要把握简单的模板语法，而 Helm 的 YAML 文件根本都被预置变量抠得毫无可读性。

Kustomize 的另外一个劣势是集成在 kubectl 中，这就意味着不须要装置额定的工具就能够进行定制。须要留神的是，因为实现上的起因，kubectl 自带的 kustomize 的版本比拟低，目前依然须要装置独自的 Kustomize 工具。这个问题要到 1.20 版本才会解决。

后续文章咱们会分享更多的 Kubernetes 组件和利用管理工具，均会公布在咱们的公众号“阿里智能运维 ”上，请大家继续关注～也欢送大家在公众号后盾留言想理解的内容和感兴趣的相干话题，与SREWorks 团队进行交换。

关于资源管理器:Kubernetes资源编排系列之三-Kustomize篇

Kustomize 是什么

Kustomize 是怎么做的

Kustomize 的特点

Kustomize 和 Helm 的比照

SREWorks 的 Kustomize 组件实际

总结