• 【云原生 | Kubernetes 系列】K8s 实战 使用 Kustomize 对 Kubernetes 对象进行声明式管理



    前言

    在这里插入图片描述

    Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理应用配置文件:

    • 从其他来源生成资源
    • 为资源设置贯穿性(Cross-Cutting)字段
    • 组织和定制资源集合

    一、生成资源

    ConfigMap 和 Secret 包含其他 Kubernetes 对象(如 Pod)所需要的配置或敏感数据。 ConfigMap 或 Secret 中数据的来源往往是集群外部,例如某个 .properties 文件或者 SSH 密钥文件。 Kustomize 提供 secretGenerator 和 configMapGenerator,可以基于文件或字面值来生成 Secret 和 ConfigMap。

    1.1、configMapGenerator

    configMapGenerator 要基于文件来生成 ConfigMap,可以在 configMapGenerator 的 files 列表中添加表项。 下面是一个根据 .properties 文件中的数据条目来生成 ConfigMap 的示例:

    # 生成一个  application.properties 文件
    cat <>application.properties
    FOO=Bar
    EOF
    
    cat <>./kustomization.yaml
    configMapGenerator:
    - name: example-configmap-1
      files:
      - application.properties
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11

    所生成的 ConfigMap 可以使用下面的命令来检查:

    $ kubectl kustomize ./

    所生成的 ConfigMap 为:

    apiVersion: v1
    data:
      application.properties: |
            FOO=Bar
    kind: ConfigMap
    metadata:
      name: example-configmap-1-8mbdf7882g
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    要从 env 文件生成 ConfigMap,请在 configMapGenerator 中的 envs 列表中添加一个条目。 下面是一个用来自 .env 文件的数据生成 ConfigMap 的例子:

    # 创建一个 .env 文件
    cat <>.env
    FOO=Bar
    EOF
    
    cat <>./kustomization.yaml
    configMapGenerator:
    - name: example-configmap-1
      envs:
      - .env
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11

    可以使用以下命令检查生成的 ConfigMap:

    $ kubectl kustomize ./

    生成的 ConfigMap 为:

    apiVersion: v1
    data:
      FOO: Bar
    kind: ConfigMap
    metadata:
      name: example-configmap-1-42cfbf598f
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    ConfigMap 也可基于字面的键值偶对来生成。要基于键值偶对来生成 ConfigMap, 在 configMapGenerator 的 literals 列表中添加表项。下面是一个例子, 展示如何使用键值偶对中的数据条目来生成 ConfigMap 对象:

    cat <>./kustomization.yaml
    configMapGenerator:
    - name: example-configmap-2
      literals:
      - FOO=Bar
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    可以用下面的命令检查所生成的 ConfigMap:

    $ kubectl kustomize ./

    所生成的 ConfigMap 为:

    apiVersion: v1
    data:
      FOO: Bar
    kind: ConfigMap
    metadata:
      name: example-configmap-2-g2hdhfc6tk
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    要在 Deployment 中使用生成的 ConfigMap,使用 configMapGenerator 的名称对其进行引用。 Kustomize 将自动使用生成的名称替换该名称。

    这是使用生成的 ConfigMap 的 deployment 示例:

    # 创建一个 application.properties 文件
    cat <>application.properties
    FOO=Bar
    EOF
    
    cat <>deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-app
      labels:
        app: my-app
    spec:
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - name: app
            image: my-app
            volumeMounts:
            - name: config
              mountPath: /config
          volumes:
          - name: config
            configMap:
              name: example-configmap-1
    EOF
    
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    configMapGenerator:
    - name: example-configmap-1
      files:
      - application.properties
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41

    生成 ConfigMap 和 Deployment:

    $ kubectl kustomize ./

    生成的 Deployment 将通过名称引用生成的 ConfigMap:

    apiVersion: v1
    data:
      application.properties: |
            FOO=Bar
    kind: ConfigMap
    metadata:
      name: example-configmap-1-g4hk9g2ff8
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: my-app
      name: my-app
    spec:
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - image: my-app
            name: app
            volumeMounts:
            - mountPath: /config
              name: config
          volumes:
          - configMap:
              name: example-configmap-1-g4hk9g2ff8
            name: config
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33

    1.2、secretGenerator

    secretGenerator 可以基于文件或者键值偶对来生成 Secret。要使用文件内容来生成 Secret, 在 secretGenerator 下面的 files 列表中添加表项。 下面是一个根据文件中数据来生成 Secret 对象的示例:

    # 创建一个 password.txt 文件
    cat <>./password.txt
    username=admin
    password=secret
    EOF
    
    cat <>./kustomization.yaml
    secretGenerator:
    - name: example-secret-1
      files:
      - password.txt
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    所生成的 Secret 如下:

    apiVersion: v1
    data:
      password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
    kind: Secret
    metadata:
      name: example-secret-1-t2kt65hgtb
    type: Opaque
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    要基于键值偶对字面值生成 Secret,先要在 secretGenerator 的 literals 列表中添加表项。下面是基于键值偶对中数据条目来生成 Secret 的示例:

    cat <>./kustomization.yaml
    secretGenerator:
    - name: example-secret-2
      literals:
      - username=admin
      - password=secret
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    所生成的 Secret 如下:

    apiVersion: v1
    data:
      password: c2VjcmV0
      username: YWRtaW4=
    kind: Secret
    metadata:
      name: example-secret-2-t52t6g96d8
    type: Opaque
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    与 ConfigMap 一样,生成的 Secret 可以通过引用 secretGenerator 的名称在 Deployment 中使用:

    # 创建一个 password.txt 文件
    cat <>./password.txt
    username=admin
    password=secret
    EOF
    
    cat <>deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-app
      labels:
        app: my-app
    spec:
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - name: app
            image: my-app
            volumeMounts:
            - name: password
              mountPath: /secrets
          volumes:
          - name: password
            secret:
              secretName: example-secret-1
    EOF
    
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    secretGenerator:
    - name: example-secret-1
      files:
      - password.txt
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42

    1.3、generatorOptions

    generatorOptions 所生成的 ConfigMap 和 Secret 都会包含内容哈希值后缀。 这是为了确保内容发生变化时,所生成的是新的 ConfigMap 或 Secret。 要禁止自动添加后缀的行为,用户可以使用 generatorOptions。 除此以外,为生成的 ConfigMap 和 Secret 指定贯穿性选项也是可以的。

    cat <>./kustomization.yaml
    configMapGenerator:
    - name: example-configmap-3
      literals:
      - FOO=Bar
    generatorOptions:
      disableNameSuffixHash: true
      labels:
        type: generated
      annotations:
        note: generated
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    运行 kubectl kustomize ./ 来查看所生成的 ConfigMap:

    apiVersion: v1
    data:
      FOO: Bar
    kind: ConfigMap
    metadata:
      annotations:
        note: generated
      labels:
        type: generated
      name: example-configmap-3
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    二、设置贯穿性字段

    在项目中为所有 Kubernetes 对象设置贯穿性字段是一种常见操作。 贯穿性字段的一些使用场景如下:

    • 为所有资源设置相同的名字空间
    • 为所有对象添加相同的前缀或后缀
    • 为对象添加相同的标签集合
    • 为对象添加相同的注解集合

    我们先来看一个例子:

    # 创建一个 deployment.yaml
    cat <>./deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx
    EOF
    
    cat <>./kustomization.yaml
    namespace: my-namespace
    namePrefix: dev-
    nameSuffix: "-001"
    commonLabels:
      app: bingo
    commonAnnotations:
      oncallPager: 800-555-1212
    resources:
    - deployment.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33

    执行 kubectl kustomize ./ 查看这些字段都被设置到 Deployment 资源上:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      annotations:
        oncallPager: 800-555-1212
      labels:
        app: bingo
      name: dev-nginx-deployment-001
      namespace: my-namespace
    spec:
      selector:
        matchLabels:
          app: bingo
      template:
        metadata:
          annotations:
            oncallPager: 800-555-1212
          labels:
            app: bingo
        spec:
          containers:
          - image: nginx
            name: nginx
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23

    三、组织和定制资源

    一种常见的做法是在项目中构造资源集合并将其放到同一个文件或目录中管理。 Kustomize 提供基于不同文件来组织资源并向其应用补丁或者其他定制的能力。

    3.1、组织

    Kustomize 支持组合不同的资源。kustomization.yaml 文件的 resources 字段定义配置中要包含的资源列表。 你可以将 resources 列表中的路径设置为资源配置文件的路径。 下面是由 Deployment 和 Service 构成的 NGINX 应用的示例:

    # 创建 deployment.yaml 文件
    cat <> deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            ports:
            - containerPort: 80
    EOF
    
    # 创建 service.yaml 文件
    cat <> service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: my-nginx
      labels:
        run: my-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
      selector:
        run: my-nginx
    EOF
    
    # 创建 kustomization.yaml 来组织以上两个资源
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    - service.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45

    kubectl kustomize ./ 所得到的资源中既包含 Deployment 也包含 Service 对象。

    3.2、定制

    补丁文件(Patches)可以用来对资源执行不同的定制。 Kustomize 通过 patchesStrategicMerge 和 patchesJson6902 支持不同的打补丁机制。 patchesStrategicMerge 的内容是一个文件路径的列表,其中每个文件都应可解析为 策略性合并补丁(Strategic Merge Patch)。 补丁文件中的名称必须与已经加载的资源的名称匹配。 建议构造规模较小的、仅做一件事情的补丁。 例如,构造一个补丁来增加 Deployment 的副本个数;构造另外一个补丁来设置内存限制。

    # 创建 deployment.yaml 文件
    cat <> deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            ports:
            - containerPort: 80
    EOF
    
    # 生成一个补丁 increase_replicas.yaml
    cat <> increase_replicas.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      replicas: 3
    EOF
    
    # 生成另一个补丁 set_memory.yaml
    cat <> set_memory.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      template:
        spec:
          containers:
          - name: my-nginx
            resources:
              limits:
                memory: 512Mi
    EOF
    
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    patchesStrategicMerge:
    - increase_replicas.yaml
    - set_memory.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56

    执行 kubectl kustomize ./ 来查看 Deployment:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          run: my-nginx
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - image: nginx
            name: my-nginx
            ports:
            - containerPort: 80
            resources:
              limits:
                memory: 512Mi
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22

    并非所有资源或者字段都支持策略性合并补丁。为了支持对任何资源的任何字段进行修改, Kustomize 提供通过 patchesJson6902 来应用 JSON 补丁的能力。 为了给 JSON 补丁找到正确的资源,需要在 kustomization.yaml 文件中指定资源的组(group)、 版本(version)、类别(kind)和名称(name)。 例如,为某 Deployment 对象增加副本个数的操作也可以通过 patchesJson6902 来完成:

    # 创建一个 deployment.yaml 文件
    cat <> deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            ports:
            - containerPort: 80
    EOF
    
    # 创建一个 JSON 补丁文件
    cat <> patch.yaml
    - op: replace
      path: /spec/replicas
      value: 3
    EOF
    
    # 创建一个 kustomization.yaml
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    
    patchesJson6902:
    - target:
        group: apps
        version: v1
        kind: Deployment
        name: my-nginx
      path: patch.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43

    执行 kubectl kustomize ./ 以查看 replicas 字段被更新:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          run: my-nginx
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - image: nginx
            name: my-nginx
            ports:
            - containerPort: 80
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19

    除了补丁之外,Kustomize 还提供定制容器镜像或者将其他对象的字段值注入到容器中的能力,并且不需要创建补丁。 例如,你可以通过在 kustomization.yaml 文件的 images 字段设置新的镜像来更改容器中使用的镜像。

    cat <> deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            ports:
            - containerPort: 80
    EOF
    
    cat <>./kustomization.yaml
    resources:
    - deployment.yaml
    images:
    - name: nginx
      newName: my.image.registry/nginx
      newTag: 1.4.0
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30

    执行 kubectl kustomize ./ 以查看所使用的镜像已被更新:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          run: my-nginx
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - image: my.image.registry/nginx:1.4.0
            name: my-nginx
            ports:
            - containerPort: 80
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19

    有些时候,Pod 中运行的应用可能需要使用来自其他对象的配置值。 例如,某 Deployment 对象的 Pod 需要从环境变量或命令行参数中读取读取 Service 的名称。 由于在 kustomization.yaml 文件中添加 namePrefix 或 nameSuffix 时 Service 名称可能发生变化,建议不要在命令参数中硬编码 Service 名称。 对于这种使用场景,Kustomize 可以通过 vars 将 Service 名称注入到容器中。

    # 创建一个 deployment.yaml 文件(引用此处的文档分隔符)
    cat <<'EOF' > deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            command: ["start", "--host", "$(MY_SERVICE_NAME)"]
    EOF
    
    # 创建一个 service.yaml 文件
    cat <> service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: my-nginx
      labels:
        run: my-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
      selector:
        run: my-nginx
    EOF
    
    cat <>./kustomization.yaml
    namePrefix: dev-
    nameSuffix: "-001"
    
    resources:
    - deployment.yaml
    - service.yaml
    
    vars:
    - name: MY_SERVICE_NAME
      objref:
        kind: Service
        name: my-nginx
        apiVersion: v1
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53

    执行 kubectl kustomize ./ 以查看注入到容器中的 Service 名称是 dev-my-nginx-001:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: dev-my-nginx-001
    spec:
      replicas: 2
      selector:
        matchLabels:
          run: my-nginx
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - command:
            - start
            - --host
            - dev-my-nginx-001
            image: nginx
            name: my-nginx
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21

    四、基准(Bases)与覆盖(Overlays)

    Kustomize 中有 基准(bases) 和 覆盖(overlays) 的概念区分。 基准 是包含 kustomization.yaml 文件的一个目录,其中包含一组资源及其相关的定制。 基准可以是本地目录或者来自远程仓库的目录,只要其中存在 kustomization.yaml 文件即可。 覆盖 也是一个目录,其中包含将其他 kustomization 目录当做 bases 来引用的 kustomization.yaml 文件。 基准不了解覆盖的存在,且可被多个覆盖所使用。 覆盖则可以有多个基准,且可针对所有基准中的资源执行组织操作,还可以在其上执行定制。

    # 创建一个包含基准的目录 
    mkdir base
    # 创建 base/deployment.yaml
    cat <> base/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
    EOF
    
    # 创建 base/service.yaml 文件
    cat <> base/service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: my-nginx
      labels:
        run: my-nginx
    spec:
      ports:
      - port: 80
        protocol: TCP
      selector:
        run: my-nginx
    EOF
    
    # 创建 base/kustomization.yaml
    cat <> base/kustomization.yaml
    resources:
    - deployment.yaml
    - service.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45

    此基准可在多个覆盖中使用。你可以在不同的覆盖中添加不同的 namePrefix 或其他贯穿性字段。 下面是两个使用同一基准的覆盖:

    mkdir dev
    cat <> dev/kustomization.yaml
    bases:
    - ../base
    namePrefix: dev-
    EOF
    
    mkdir prod
    cat <> prod/kustomization.yaml
    bases:
    - ../base
    namePrefix: prod-
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13

    五、如何使用 Kustomize 来应用、查看和删除对象

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

    $ kubectl apply -k /

    我们再来写一个 kustomization.yaml 文件:

    # 创建 deployment.yaml 文件
    cat <> deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx
    spec:
      selector:
        matchLabels:
          run: my-nginx
      replicas: 2
      template:
        metadata:
          labels:
            run: my-nginx
        spec:
          containers:
          - name: my-nginx
            image: nginx
            ports:
            - containerPort: 80
    EOF
    
    # 创建 kustomization.yaml
    cat <>./kustomization.yaml
    namePrefix: dev-
    commonLabels:
      app: my-nginx
    resources:
    - deployment.yaml
    EOF
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31

    执行下面的命令来应用 Deployment 对象 dev-my-nginx:

    $ kubectl apply -k ./

    $ deployment.apps/dev-my-nginx created

    运行下面的命令之一来查看 Deployment 对象 dev-my-nginx:

    $ kubectl get -k ./

    $ kubectl describe -k ./

    执行下面的命令来比较 Deployment 对象 dev-my-nginx 与清单被应用之后集群将处于的状态:

    $ kubectl diff -k ./
    执行下面的命令删除 Deployment 对象 dev-my-nginx:

    $ kubectl delete -k ./

    $ deployment.apps “dev-my-nginx” deleted

    六、Kustomize 功能特性列表

    字段类型解释
    namespacestring为所有资源添加名字空间
    namePrefixstring此字段的值将被添加到所有资源名称前面
    nameSuffixstring此字段的值将被添加到所有资源名称后面
    commonLabelsmap[string]string要添加到所有资源和选择算符的标签
    commonAnnotationsmap[string]string要添加到所有资源的注解
    resources[]string列表中的每个条目都必须能够解析为现有的资源配置文件
    configMapGenerator[]ConfigMapArgs列表中的每个条目都会生成一个 ConfigMap
    secretGenerator[]SecretArgs列表中的每个条目都会生成一个 Secret
    generatorOptionsGeneratorOptions更改所有 ConfigMap 和 Secret 生成器的行为
    bases[]string列表中每个条目都应能解析为一个包含 kustomization.yaml 文件的目录
    patchesStrategicMerge[]string列表中每个条目都能解析为某 Kubernetes 对象的策略性合并补丁
    patchesJson6902[]Patch列表中每个条目都能解析为一个 Kubernetes 对象和一个 JSON 补丁
    vars[]Var每个条目用来从某资源的字段来析取文字
    images[]Image每个条目都用来更改镜像的名称、标记与/或摘要,不必生成补丁
    configurations[]string列表中每个条目都应能解析为一个包含 Kustomize 转换器配置 的文件
    crds[]string列表中每个条目都应能够解析为 Kubernetes 类别的 OpenAPI 定义文件

    总结

    全文加源码文件文字,共计一万三千字,配置文件代码占比较大。我原本打算分两篇文章来写,担心分文会影响各位看官的阅读感受。

    看到这里了,给个双击呗!!!

  • 相关阅读:
    matlab小车运动轨迹增量式PID控制
    拖拽表单设计器易操作、好灵活,创造高效办公!
    Java8中并行化流parallel的使用
    C专家编程 第7章 对内存的思考 7.2 Intel 80x86内存模型以及它的工作原理
    Canvas录制视频
    一、安全完善度等级SIL(Safety Integrity Level)介绍
    排列组合初赛详解
    EtherCAT转Modbus-TCP协议网关与DCS连接的配置方法
    Linux环境下Docker安装mysql数据的导入和导出备份操作
    【xshell7】设置语法高亮(突出显示集)方式
  • 原文地址:https://blog.csdn.net/u010755471/article/details/126359384