• Kubernetes kustomize 技术从入门到企业实战（下）

    一、Kustomize 进阶

            本次以 test1 环境为例介绍！

    1. root@jenkins:/data/kustomize# tree personal-web/
    2. personal-web/
    3. ├── base
    4. │   ├── deploy.yaml
    5. │   ├── ingress.yaml
    6. │   ├── kustomization.yaml
    7. │   ├── nginx.conf
    8. │   └── service.yaml
    9. └── overlays
    10.     ├── pre
    11.     │   ├── deploy-patch.yaml
    12.     │   ├── ing-patch.yaml
    13.     │   └── kustomization.yaml
    14.     ├── prod
    15.     │   ├── deploy-patch.yaml
    16.     │   ├── ing-patch.yaml
    17.     │   ├── kustomization.yaml
    18.     │   └── set_volumeMounts.yaml
    19.     ├── test1
    20.     │   ├── deploy-patch.yaml
    21.     │   ├── ing-patch.yaml
    22.     │   └── kustomization.yaml
    23.     └── test2
    24.         ├── deploy-patch.yaml
    25.         ├── ing-patch.yaml
    26.         └── kustomization.yaml

            1.1 使用覆盖定制资源

            1.1.1 kustomization.yaml

            创建一个名为 overlays 的目录，用于存放覆盖；在 overlays 目录下创建一个名为 test1 的目录，表示测试环境 1 的覆盖；在 overlays/test1 目录下创建一个名为 kustomization.yaml 的文件，内容如下：

    1. root@jenkins:/data/kustomize# cat personal-web/overlays/test1/kustomization.yaml 
    2. bases:
    3. - ../../base
    4. namespace: test1
    5. namePrefix: personal-web
    6. commonLabels: 
    7.   app: personal-web
    8.  
    9. patchesJson6902:
    10. - target:
    11.     group: apps
    12.     version: v1
    13.     kind: Deployment
    14.     name: -app 
    15.   path: deploy-patch.yaml
    16. - target:
    17.     group: networking.k8s.io
    18.     version: v1
    19.     kind: Ingress
    20.     name: -ingress
    21.   path: ing-patch.yaml

            文件位于 

    personal-web/overlays/test1/

            目录下，用于描述特定于 test1 环境的 Kustomize 配置。这个文件包含以下内容：

    • bases：指定基础资源所在的目录。在这个例子中，基础资源位于 ../../base 目录，即 personal-web/base。Kustomize 将在这个基础上应用 test1 环境的特定修改。

    • namespace：设置所有资源的 Kubernetes 命名空间。在这个例子中，所有资源将位于 test1 命名空间。

    • namePrefix：为所有资源添加名称前缀。在这个例子中，所有资源的名称将以 personal-web 作为前缀。

    • commonLabels：为所有资源添加通用标签。在这个例子中，给所有资源添加一个名为 app 的标签，其值为 personal-web。

    • patchesJson6902：是 Kustomize 中用于对 Kubernetes 资源应用 JSON 6902 标准补丁的配置。在这个例子中，有两个补丁要应用到不同的资源上：

      1. 第一个补丁：

        • target: 定义要修改的 Kubernetes 资源的目标。
          • group: 资源的 API 组，这里是 apps。
          • version: 资源的 API 版本，这里是 v1。
          • kind: 资源的类型，这里是 Deployment。
          • name: 资源的名称，这里是 -app（namePrefix 为所有资源添加名称前缀成为 personal-web-app）。
        • path: 定义补丁的文件路径，这里是 deploy-patch.yaml。此文件应包含针对 Deployment 资源的 JSON 6902 标准补丁。

      2. 第二个补丁：

        • target: 定义要修改的 Kubernetes 资源的目标。
          • group: 资源的 API 组，这里是 networking.k8s.io。
          • version: 资源的 API 版本，这里是 v1。
          • kind: 资源的类型，这里是 Ingress。
          • name: 资源的名称，这里是 -ingress（namePrefix 为所有资源添加名称前缀成为 personal-web-ingress）。
        • path: 定义补丁的文件路径，这里是 ing-patch.yaml。此文件应包含针对 Ingress 资源的 JSON 6902 标准补丁。
    1.1.2 deploy-patch.yaml
    1. root@jenkins:/data/kustomize# cat personal-web/overlays/test1/deploy-patch.yaml 
    2. #副本数
    3. - op: replace
    4.   path: /spec/replicas
    5.   value: 1
    6. #最大不可用数
    7. - op: replace
    8.   path: /spec/strategy/rollingUpdate/maxUnavailable
    9.   value: 1
    10. #image
    11. - op: replace
    12.   path: /spec/template/spec/containers/0/image
    13.   value: sky/test1/personal-web:26

            这个 deploy-patch.yaml 文件是一个使用 JSON 6902 标准定义的补丁文件，用于针对 test1 环境的 Deployment 资源应用修改。它包含以下操作：

    1. 修改副本数：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/replicas（相当于 spec.replicas 字段），表示 Deployment 的副本数。
      • value: 新值，这里是 1，将用于替换原有值。

    2. 修改最大不可用数：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/strategy/rollingUpdate/maxUnavailable，表示滚动更新策略中的最大不可用数。
      • value: 新值，这里是 1，将用于替换原有值。

    3. 修改容器镜像：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/template/spec/containers/0/image（0 可以解释为代替 - 符号），表示第一个容器的镜像。
      • value: 新值，这里是 sky/test1/personal-web:26，将用于替换原有值。

            这个补丁文件中的修改针对 test1 环境的 Deployment 资源，可以通过 Kustomize 配置自动应用，从而根据不同环境自动生成相应的资源清单。

    1.1.3 ing-patch.yaml
    1. root@jenkins:/data/kustomize# cat personal-web/overlays/test1/ing-patch.yaml 
    2. # tls
    3. - op: replace
    4.   path: /spec/tls/0/hosts/0
    5.   value: test1c.sky.net
    6. - op: replace
    7.   path: /spec/tls/0/secretName
    8.   value: sky.net20231029
    9. # 域名
    10. - op: replace
    11.   path: /spec/rules/0/host
    12.   value: test1c.sky.net
    13. # svc 名称
    14. - op: add
    15.   path: /spec/rules/0/http/paths/0/backend/service/name
    16.   value: personal-web-svc

            这个 ing-patch.yaml 文件是一个使用 JSON 6902 标准定义的补丁文件，用于针对 test1 环境的 Ingress 资源应用修改。它包含以下操作：

    1. 修改 TLS 配置的域名：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/tls/0/hosts/0，表示第一个 TLS 配置的第一个域名。
      • value: 新值，这里是 test1c.sky.net，将用于替换原有值。

    2. 修改 TLS 配置的 secretName：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/tls/0/secretName，表示第一个 TLS 配置的 secretName。
      • value: 新值，这里是 sky.net20231029，将用于替换原有值。

    3. 修改 Ingress 规则的域名：

      • op: 操作类型，这里是 replace，表示替换原有值。
      • path: 要修改的资源路径，这里是 /spec/rules/0/host，表示第一个 Ingress 规则的域名。
      • value: 新值，这里是 test1c.sky.net，将用于替换原有值。

    4. 修改 Ingress 规则中服务名称：

      • op: 操作类型，这里是 add，表示添加新值。如果该路径已存在值，则 add 操作将替换原有值。
      • path: 要修改的资源路径，这里是 /spec/rules/0/http/paths/0/backend/service/name，表示第一个 Ingress 规则中第一个 HTTP 路径的后端服务名称。
      • value: 新值，这里是 personal-web-svc，将用于替换或添加到原有值。

            这个补丁文件中的修改针对 test1 环境的 Ingress 资源，可以通过 Kustomize 配置自动应用，从而根据不同环境自动生成相应的资源清单。

    1.1.4 op 操作类型介绍

    在 JSON 6902 标准中，op 可以表示以下几种操作类型：

    1. add：添加一个新值。如果指定的路径已存在值，则替换该值；如果路径不存在，则创建路径并设置值。如果要在数组中添加新元素，可以使用 - 作为数组索引，表示将元素添加到数组末尾。

    2. remove：删除指定路径的值。如果路径不存在，该操作将失败。

    3. replace：替换指定路径的值。如果路径不存在，该操作将失败。

    4. move：将一个值从源路径移动到目标路径。源路径和目标路径都必须存在。该操作等效于先执行 remove 操作，然后执行 add 操作。

    5. copy：复制一个值从源路径到目标路径。源路径必须存在，目标路径可以不存在。该操作等效于先获取源路径的值，然后使用 add 操作将其添加到目标路径。

    6. test：测试指定路径的当前值是否与提供的值相等。如果值不相等，该操作将失败。

            这些操作类型可以在 JSON 6902 标准的补丁文件中使用，以便对 Kubernetes 资源或其他 JSON 数据进行修改。

    二、生成测试环境定制资源

            现在，我们可以使用 kubectl kustomize 命令生成测试环境定制资源（可用于检查发现哪里有不对的地方便于后续修改）：

    root@jenkins:/data/kustomize# kubectl kustomize personal-web/overlays/test1/

    三、使用 Kustomize 来应用、查看和删除对象

    3.1 创建应用

            在 kubectl 命令中使用 --kustomize 或 -k 参数来创建被 kustomization.yaml 所管理的资源应用。 注意 -k 要指向一个 kustomization 目录。例如：

    root@jenkins:/data/kustomize# kubectl apply -k personal-web/overlays/test1/

    3.2 查看应用

            运行下面的命令之一来查看生成的应用：

    1. root@jenkins:/data/kustomize# kubectl get -k personal-web/overlays/test1/
    2.  
    3. root@jenkins:/data/kustomize# kubectl describe -k personal-web/overlays/test1/
    4.  
    5. # 当然也可以使用 kubectl get pods -n test1 查看具体的资源

    3.3 删除应用

    root@jenkins:/data/kustomize# kubectl delete -k personal-web/overlays/test1/

    四、总结

            在本教程中，我们了解了 Kustomize 的基本概念、使用方法，并演示了如何应用于实际场景。通过使用 Kustomize，我们可以更方便地为不同环境和场景定制 Kubernetes 资源配置，提高了配置管理的灵活性和可维护性。希望这篇教程对你有所帮助，如果有任何问题，请随时在下方留言。

  • 相关阅读:
    【大厂AI课学习笔记NO.53】2.3深度学习开发任务实例（6）数据采集
    LangGraph实战
    POSTGIS数据库操作
    怎么移除pdf文件编辑限制，有哪些方法？
    98-docker命令
    poi-tl：基于Apache POI的轻量级Word模板引擎
    MTK外部按键新增
    通过python获取svn状态
    权限系统设计方案
    Bootstrap Collapse的使用
  • 原文地址：https://blog.csdn.net/qq_19734597/article/details/133992231