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

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

Kustomize是什么

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

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

Kustomize是怎么做的

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: appresources:- 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:- ../../basecommonLabels:  env: stagingnamePrefix: staging-patches:  - target:      kind: Deployment      name: app    patch: |      [        {"op":"replace","path":"/spec/replicas","value":1}      ]

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

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

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

bases:- ../productionpatches:  - 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的特点

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

Kustomize和Helm的比照

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的Kustomize组件实际

在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团队进行交换。