【Kubernetes 企业项目实战】10、掌握 Kubernetes Kustomize 技术从入门到企业实战(上)

这篇具有很好参考价值的文章主要介绍了【Kubernetes 企业项目实战】10、掌握 Kubernetes Kustomize 技术从入门到企业实战(上)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一、Kustomize 概述

1.1 Kustomize 简介 

1.2 Kustomize 与 Helm 技术详细对比

1.2.1 区别

1.2.2 优缺点

1.2.3 适用场景

1.3 总结

二、Kustomize 入门

2.1 安装 Kustomize

2.2 Kustomize 项目目录结构及介绍

2.2.1 Kustomize 基本概念

2.2.2 personal-web 项目结构详细介绍

2.3 创建基础资源

2.3.1 deploy.yaml 

2.3.2 service.yaml

2.3.3 ingress.yaml

2.4 创建 kustomization.yaml

2.5 生成定制资源


一、Kustomize 概述

1.1 Kustomize 简介 

        Kustomize 是一款 Kubernetes 原生的配置管理工具,其核心理念是允许用户自定义 Kubernetes 资源配置,而无需直接修改原始的 YAML 文件。这在很大程度上提高了配置的可维护性和可重用性。Kustomize 使用声明式的方式来定制资源,通过一系列预定义的指令和规则,用户可以对基础资源进行修改、添加或删除。Kustomize 与其他模板技术相比,具有以下优势:

  1. 易于理解:Kustomize 使用简单的 YAML 语法,与 Kubernetes 资源本身的定义方式保持一致,易于学习和理解。

  2. 原子性:Kustomize 的覆盖策略允许用户精确地修改特定部分的配置,而不会影响其他部分。这样可以确保修改的原子性,避免出现意外的副作用。

  3. 可组合性:Kustomize 支持将多个覆盖层叠加在一起,从而形成一个完整的定制资源。这使得用户可以在多个环境和场景之间复用同一套基础配置,降低了维护成本。

  4. 集成 Kubernetes:Kustomize 自 Kubernetes v1.14 起已经被集成在 kubectl 中,用户无需安装额外的工具即可使用 Kustomize。

        总之,Kustomize 提供了一种更为灵活且高效的方式来管理 Kubernetes 资源配置。通过使用 Kustomize,开发者和运维人员可以轻松地为不同环境和场景创建定制的配置,提高了工作效率和配置的可维护性。

Kustomize 官方文档:配置定制(Bespoke configuration) | SIG CLI 

Kustomize 在 k8s 中的介绍:使用 Kustomize 对 Kubernetes 对象进行声明式管理 | Kubernetes 

1.2 Kustomize 与 Helm 技术详细对比

        Kustomize 和 Helm 都是 Kubernetes 生态中流行的配置管理工具,虽然它们有许多相似之处,但在实现方式和适用场景上有所不同。接下来,我们将从区别、优缺点和适用场景等方面详细对比 Kustomize 和 Helm。

Helm 的教程:【Kubernetes 企业项目实战】08、简化 K8s 应用部署工具 Helm V3 入门到企业实战_Stars.Sky的博客-CSDN博客

1.2.1 区别

  1. 实现方式:Kustomize 采用基于覆盖的策略,通过在原始资源上应用一系列覆盖来实现资源定制。而 Helm 使用 Go 模板语言,将变量嵌入到 YAML 文件中,通过替换变量的方式生成定制资源。

  2. 配置管理:Kustomize 使用 kustomization.yaml 文件进行配置管理,而 Helm 使用名为 Chart.yamlvalues.yaml 的文件。

  3. 依赖管理:Helm 支持依赖管理,允许用户将一个 Helm Chart 依赖于其他 Helm Chart。而 Kustomize 不具备依赖管理功能。

  4. 发布管理:Helm 支持版本控制和回滚功能,可以管理应用的发布历史。Kustomize 不具备类似功能。

  5. 安装方式:Kustomize 自 Kubernetes v1.14 起已经集成在 kubectl 中,而 Helm 需要单独安装。

1.2.2 优缺点

Kustomize

优点:

  • 易于学习和理解,与 Kubernetes 资源本身的定义方式保持一致。
  • 使用声明式方式进行资源定制,避免了模板语言带来的复杂性。
  • 支持多层覆盖,有利于组织和管理复杂的配置。
  • 无需安装额外工具,与 kubectl 无缝集成。

缺点:

  • 不支持依赖管理和发布管理。
  • 在处理复杂逻辑和动态生成内容时,相较于 Helm 的模板语言,Kustomize 的能力有限。

Helm

优点:

  • 支持依赖管理和发布管理,提供了完整的应用生命周期管理功能。
  • 使用 Go 模板语言,可以处理复杂的逻辑和动态生成内容。
  • 拥有丰富的社区资源,如 Helm Chart 仓库等。

缺点:

  • 需要单独安装,并学习 Go 模板语言。
  • 模板语言可能导致配置的复杂性增加。

1.2.3 适用场景

Kustomize

  • 适用于简单到中等复杂度的 Kubernetes 资源配置管理。
  • 更适合那些需要在多个环境和场景下复用基础配置的场景。
  • 当对模板语言的需求较低时,Kustomize 是一个更简洁的选择。

Helm

  • 适用于具有复杂依赖关系和发布管理需求的应用。
  • 当需要处理复杂逻辑和动态生成内容时,Helm 的模板语言更具优势。
  • 如果需要使用丰富的社区资源,例如 Helm Chart 仓库,Helm 是一个更好的选择。

1.3 总结

        Kustomize 和 Helm 都是优秀的 Kubernetes 配置管理工具,它们各自具有独特的优势和不同的适用场景。在选择 Kustomize 还是 Helm 时,需要根据实际需求和场景来权衡。

        Kustomize 以其简单易用、声明式的方式在 Kubernetes 生态中脱颖而出,特别适合那些需要在多个环境和场景下复用基础配置的场景。

        而 Helm 则作为一个功能更为完善的应用生命周期管理工具,更适合具有复杂依赖关系和发布管理需求的应用。在处理复杂逻辑和动态生成内容时,Helm 的模板语言具有显著优势。同时,Helm 也拥有丰富的社区资源,如 Helm Chart 仓库等,为用户提供了更多的便利。

        最终,你可以根据实际项目需求、团队技能和个人喜好来选择 Kustomize 或 Helm。无论选择哪种工具,都能在 Kubernetes 配置管理方面为你带来很大的帮助。

二、Kustomize 入门

kustomize API 介绍:kustomization.yaml | SIG CLI

2.1 安装 Kustomize

        Kustomize 自 Kubernetes v1.14 起已经被集成在 kubectl 中,因此无需额外安装。只需确保你的 kubectl 版本在 v1.14 以上即可使用 Kustomize。

root@jenkins:/data/kustomize# kubectl version

root@jenkins:/data/kustomize# kubectl kustomize 

2.2 Kustomize 项目目录结构及介绍

此次教程以 personal-web 前端项目作为讲解例子:

root@jenkins:/data/kustomize# tree personal-web
personal-web
├── base
│   ├── deploy.yaml
│   ├── ingress.yaml
│   ├── kustomization.yaml
│   ├── nginx.conf
│   └── service.yaml
└── overlays
    ├── pre
    │   ├── deploy-patch.yaml
    │   ├── ing-patch.yaml
    │   └── kustomization.yaml
    ├── prod
    │   ├── deploy-patch.yaml
    │   ├── ing-patch.yaml
    │   ├── kustomization.yaml
    │   └── set_volumeMounts.yaml
    ├── test1
    │   ├── deploy-patch.yaml
    │   ├── ing-patch.yaml
    │   └── kustomization.yaml
    └── test2
        ├── deploy-patch.yaml
        ├── ing-patch.yaml
        └── kustomization.yaml

2.2.1 Kustomize 基本概念

  1. 基础资源(Base):基础资源是原始的 Kubernetes YAML 文件,用于描述 Kubernetes 对象。

  2. 覆盖(Overlay):覆盖是对基础资源的定制,用于为特定环境或场景提供额外的配置信息。

  3. kustomization.yaml:Kustomize 的配置文件,用于描述如何生成定制的资源。

2.2.2 personal-web 项目结构详细介绍

        上面是一个使用 Kustomize 的项目目录结构,用于管理一个名为 personal-web 的 Kubernetes 应用。该项目包含一个基础配置目录(base)和一个覆盖层配置目录(overlays)。我们来详细了解这个项目结构:

  • base 目录:包含该应用的基本 Kubernetes 资源配置文件,如 deploy.yaml(Deployment 配置)、ingress.yaml(Ingress 配置)和 service.yaml(Service 配置)。此外,还包含一个名为 nginx.conf 的 Nginx 配置文件。这些文件定义了应用的基本架构和行为。

    • kustomization.yaml:这是 Kustomize 的核心配置文件,用于声明基本资源,以及如何修改这些资源。在这个例子中,kustomization.yaml 将其他 YAML 文件(如 deploy.yamlingress.yamlservice.yaml)视为基础资源。
  • overlays 目录:包含用于不同环境(如预生产、生产和两个测试环境)的覆盖层配置。每个子目录(preprodtest1test2)代表一个环境,包含针对该环境的特定修改。

    • 每个子目录中的 kustomization.yaml 文件指定了要应用的基础配置(在本例中为 base 目录)以及覆盖层资源(如 deploy-patch.yamling-patch.yaml),这些资源用于修改基本配置以满足特定环境的需求。

    • deploy-patch.yamling-patch.yaml 文件包含针对 Deployment 和 Ingress 的定制修改。例如,可以更改副本数量、镜像标签或 Ingress 的主机名。

    • prod 目录下的 set_volumeMounts.yaml 文件是一个专门针对生产环境的额外配置,用于设置特定的 VolumeMounts。这表明生产环境与其他环境可能有不同的存储配置。

        总之,这个 Kustomize 项目目录结构允许您在不同环境之间复用基础配置,同时提供了覆盖层来实现针对特定环境的定制修改。这有助于提高配置的可维护性和可重用性。

2.3 创建基础资源

2.3.1 deploy.yaml 

        首先,我们创建一个项目目录(personal-web),在该项目下创建 base 目录用于存放基础资源。例如,创建一个名为 deploy.yaml 的文件,内容如下:

root@jenkins:/data/kustomize# cat personal-web/base/deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: -app 
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      imagePullSecrets:
      - name: registry
      containers:
      - name: personal-web
        image: 
        imagePullPolicy: Always
        env:
        - name: CONTAINER_APP_NAME
          value: personal-web
        - name: CONTAINER_PODIP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: CONTAINER_PODPORT
          value: "80"
        - name: CONTAINER_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        ports:
        - name: http
          containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            scheme: HTTP
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 3
          timeoutSeconds: 2
          successThreshold: 2
          failureThreshold: 3
        resources:
          limits:
            cpu: 500m
            memory: 2000Mi
          requests:
            cpu: 200m
            memory: 500Mi
        volumeMounts:
        - name: conf
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
      volumes:
      - name: conf
        configMap:
          name: -cm

        这个 deploy.yaml 文件定义了一个 Kubernetes Deployment 资源。Deployment 资源用于描述应用程序的部署,确保特定数量的副本始终处于运行状态。以下是详细的字段解释:

  • apiVersion: apps/v1:指定 Kubernetes API 的版本,本例中使用的是 apps/v1

  • kind: Deployment:指定资源类型为 Deployment。

  • metadata:资源元数据,包括资源名称等信息。

    • name: -app:Deployment 资源的名称。这里的是个伏笔,后面会介绍,会自动生成 name: personal-web-app
  • spec:Deployment 资源的详细规格。

    • replicas: 1:指定运行的副本数量为 1。

    • strategy:定义升级策略。

      • rollingUpdate:指定滚动更新策略。

        • maxSurge: 1:在更新过程中允许的最大超出副本数。

        • maxUnavailable: 0:在更新过程中允许的最大不可用副本数。

    • selector:定义用于匹配 Pod 的标签选择器。

      • matchLabels:指定要匹配的标签。这里的值缺失,应该添加一个键值对,例如 app: personal-web
    • template:定义 Pod 模板。

      • metadata:Pod 元数据。

        • labels:指定 Pod 标签。这里的值缺失,应该添加一个键值对,例如 app: personal-web
      • spec:Pod 详细规格。

        • imagePullSecrets:指定用于拉取镜像的 Secret。在这个例子中,Secret 名称为 registry

        • containers:定义容器列表。

          • name: personal-web:容器名称。

          • image:容器使用的镜像。这里的值缺失,应该添加一个有效的镜像,例如 image: myrepo/personal-web:latest

          • imagePullPolicy: Always:镜像拉取策略,始终拉取新的镜像。

          • env:定义容器的环境变量。

          • ports:定义容器的端口映射。

          • readinessProbe:定义容器的就绪探针,用于检查容器是否已经准备好接收流量。

          • resources:定义容器的资源限制和请求。

          • volumeMounts:定义容器的卷挂载。

        • volumes:定义 Pod 的卷。

          • name: conf:卷的名称。

          • configMap:使用 ConfigMap 作为卷的数据来源。

            • name: -cm:指定 ConfigMap 的名称。后续会自动生成,例如 name: personal-web-cm

        这个 deploy.yaml 文件定义了一个名为 personal-web 的容器,它会使用指定的镜像并将其部署为一个 Kubernetes Deployment。这个 Deployment 包含了一个 Pod,其中包括环境变量、端口映射、就绪探针和资源限制等配置信息。

        容器将使用名为 registry 的 Secret 来拉取镜像,并始终拉取最新的镜像。容器的环境变量包括 CONTAINER_APP_NAMECONTAINER_PODIPCONTAINER_PODPORTCONTAINER_NAMESPACE,它们分别表示应用名称、Pod IP 地址、Pod 端口和命名空间。

        容器的端口映射将内部的 80 端口映射为名称为 http 的端口。就绪探针将检查容器的根路径(/),使用 HTTP 协议和 80 端口,以确保容器已经准备好接收流量。容器的资源限制和请求分别定义了 CPU 和内存的最大使用量以及基本需求。

        卷挂载部分将名为 conf 的卷挂载到容器的 /etc/nginx/nginx.conf 路径上。此卷使用名为 personal-web-cm 的 ConfigMap 作为数据来源。这样,您可以在 ConfigMap 中存储和管理 Nginx 配置,并自动将其应用到容器中。

        这个 deploy.yaml 文件为 personal-web 应用提供了一个基础的 Kubernetes Deployment 配置。通过 Kustomize 的覆盖层,您可以根据不同环境的需求对其进行修改。

2.3.2 service.yaml

root@jenkins:/data/kustomize# cat personal-web/base/service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: -svc
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 300
  type: ClusterIP
  ports:
  - name: http-nginx
    port: 80
    targetPort: 80
  selector:
    app:

        这个 service.yaml 文件定义了一个 Kubernetes Service 资源。Service 资源用于为一组运行的 Pod 提供一个稳定的 IP 地址和 DNS 名称,实现负载均衡和网络流量分发。以下是详细的字段解释:

  • apiVersion: v1:指定 Kubernetes API 的版本,本例中使用的是 v1

  • kind: Service:指定资源类型为 Service。

  • metadata:资源元数据,包括资源名称等信息。

    • name: -svc:Service 资源的名称。这里的名称似乎有误,应该是一个有效的名称,例如 name: personal-web-svc
  • spec:Service 资源的详细规格。

    • sessionAffinity: ClientIP:设置会话亲和性(session affinity)为 ClientIP。这意味着来自同一客户端 IP 的请求会被发送到同一个 Pod。

    • sessionAffinityConfig:会话亲和性配置。

      • clientIP:针对客户端 IP 的会话亲和性配置。

        • timeoutSeconds: 300:设置客户端 IP 会话亲和性的超时时间为 300 秒。
    • type: ClusterIP:设置 Service 类型为 ClusterIP。这意味着 Service 会分配一个内部集群 IP 地址,仅在集群内部可访问。

    • ports:定义 Service 的端口映射。

      • name: http-nginx:端口名称。

      • port: 80:Service 的端口。

      • targetPort: 80:Pod 中的目标端口。

    • selector:定义用于匹配 Pod 的标签选择器。

      • app:指定要匹配的标签。这里的值缺失,应该添加一个键值对,例如 app: personal-web

        这个 service.yaml 文件为 personal-web 应用提供了一个基础的 Kubernetes Service 配置。Service 资源将在集群内部将流量分发到具有 app: personal-web 标签的 Pod,并确保来自同一客户端 IP 的请求会被发送到同一个 Pod。通过 Kustomize 的覆盖层,您可以根据不同环境的需求对其进行修改。

2.3.3 ingress.yaml

root@jenkins:/data/kustomize# cat personal-web/base/ingress.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: ""
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
  name: -ingress
spec:
  tls:
  - hosts:
    - 
    secretName: 
  ingressClassName: nginx
  rules:
  - host: 
    http:
      paths:
      - backend:
          service:
            name: 
            port:
              number: 80
        path: /
        pathType: Prefix

        这个 ingress.yaml 文件定义了一个 Kubernetes Ingress 资源。Ingress 资源用于管理外部访问集群内部服务的规则,允许您通过一个或多个 HTTP 或 HTTPS 路径将流量路由到集群内部的 Service。以下是详细的字段解释:

  • apiVersion: networking.k8s.io/v1:指定 Kubernetes API 的版本,本例中使用的是 networking.k8s.io/v1

  • kind: Ingress:指定资源类型为 Ingress。

  • metadata:资源元数据,包括资源名称、注解等信息。

    • annotations:为 Ingress 添加注解,用于配置 Ingress 控制器的行为。本例中使用了 nginx Ingress 控制器。

      • nginx.ingress.kubernetes.io/service-weight:为后端服务设置权重,用于流量分发。这里的值为空,表示使用默认权重。

      • nginx.ingress.kubernetes.io/rewrite-target:重写目标路径,将客户端请求的路径重写为指定值。本例中,所有请求的路径都被重写为 /

      • nginx.ingress.kubernetes.io/ssl-redirect:设置为 'true' 以启用 SSL 重定向。这意味着非 SSL 请求将被重定向到 SSL 端点。

    • name: -ingress:Ingress 资源的名称。这里的名称似乎有误,应该是一个有效的名称,例如 name: personal-web-ingress

  • spec:Ingress 资源的详细规格。

    • tls:配置 Ingress 的 TLS 设置。

      • hosts:指定 TLS 证书适用的域名。这里的值缺失,应该添加一个有效的域名,例如 - example.com

      • secretName:指定包含 TLS 证书和密钥的 Kubernetes Secret。这里的值缺失,应该添加一个有效的 Secret 名称,例如 secretName: example-tls-secret

    • ingressClassName: nginx:指定 Ingress 类名为 nginx,用于选择正确的 Ingress 控制器。

    • rules:定义 Ingress 规则。

      • host:指定规则适用的域名。这里的值缺失,应该添加一个有效的域名,例如 host: example.com

      • http:配置 HTTP 规则。

        • paths:定义 HTTP 路径列表。

          • backend:配置后端服务。

            • service:指定后端服务。

              • name:后端服务的名称。这里的值缺失,应该添加一个有效的名称,例如 name: personal-web-svc

              • port:指定后端服务的端口。

                • number: 80:后端服务的端口号。
          • path: /:指定匹配的路径。

          • pathType: Prefix:指定路径类型为 Prefix,表示匹配请求路径的前缀

2.4 创建 kustomization.yaml

接下来,我们创建一个名为 kustomization.yaml 的文件,内容如下:

root@jenkins:/data/kustomize# cat personal-web/base/kustomization.yaml 
resources:
- deploy.yaml
- service.yaml
- ingress.yaml

configMapGenerator:
- name: -cm
  files:
  - nginx.conf

   kustomization.yaml 文件是 Kustomize 的核心配置文件,用于描述资源的基本配置和修改。在这个例子中,kustomization.yaml 文件位于 base 目录下,包含以下内容:

  • resources:列出了本层次结构中包含的 Kubernetes 资源文件。在这个例子中,包括 deploy.yaml(Deployment),service.yaml(Service)和 ingress.yaml(Ingress)。

  • configMapGenerator:指定 ConfigMap 生成器,用于从文件或字面值创建 ConfigMap。在这个例子中,生成器用于创建一个名为 -cm 的 ConfigMap。这个名称似乎有误,应该是一个有效的名称,例如 name: personal-web-cm

    • files:指定用于生成 ConfigMap 的文件列表。在这个例子中,生成器将 nginx.conf 文件内容添加到 ConfigMap 中。

        通过 kustomization.yaml 文件,您可以定义和组织 Kubernetes 资源的基本结构。在其他覆盖层中,您可以根据不同环境的需求对这些资源进行修改。这使得您能够更轻松地管理和维护多个环境的 Kubernetes 配置。

    configMapGenerator 是 Kustomize 中的一个功能,用于动态生成 Kubernetes ConfigMap。它允许您将配置数据与应用程序资源分离,从而更好地管理和维护配置信息。下面详细介绍 configMapGenerator 的优势和作用:

  1. 分离配置和应用程序资源:configMapGenerator 允许您将配置信息(如配置文件、属性、参数等)与应用程序资源(如 Deployment、Service 等)分离。这样做有助于提高配置管理的灵活性和可维护性,方便您在不同环境中使用不同的配置。

  2. 简化配置管理:通过使用 configMapGenerator,您可以直接从本地文件或字面值创建 ConfigMap,无需手动创建和更新 YAML 文件。这降低了出错的可能性,同时简化了配置管理过程。

  3. 避免重复和冗余:当您的应用程序需要使用相同的配置数据时,configMapGenerator 可以避免重复和冗余。通过在 Kustomize 层次结构中复用相同的配置文件或字面值,您可以确保配置数据在各个环境中保持一致。

  4. 自动生成名称后缀:configMapGenerator 会自动为生成的 ConfigMap 添加一个唯一的后缀。这确保了当配置数据发生变化时,所有使用这个 ConfigMap 的资源都会得到更新。这样可以避免因为未更新配置导致的应用程序错误或故障。

  5. 支持多种数据来源:configMapGenerator 支持从多种来源生成 ConfigMap,包括文件、目录、字面值、环境变量文件等。这使得您可以根据实际需求选择合适的数据来源,灵活处理不同类型的配置数据。

        总之,按照传统的部署方式,我们需要先提前创建 configmap 资源,再把创建好的资源名称填入 deploy.yaml 文件中才能生效,而 configMapGenerator 的存在则无需提前创建 configmap 资源,直接生成有效的 configmap,大大提高效率。

2.5 生成定制资源

现在,我们可以使用 kubectl kustomize 命令生成定制资源:

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

   kubectl kustomize 命令用于处理指定目录下的 Kustomize 配置文件(kustomization.yaml),并生成最终的 Kubernetes 资源清单(manifest)。它根据 kustomization.yaml 文件中定义的基础资源、覆盖层、变量替换等指令,将不同环境的配置进行合并和修改,输出一个最终的资源清单。

这个命令的主要作用如下:

  1. 处理 Kustomize 配置:kubectl kustomize 会根据 kustomization.yaml 文件的指令,处理基础资源和覆盖层,生成一个适用于特定环境的资源清单。

  2. 生成最终资源清单:该命令会生成一个最终的 Kubernetes 资源清单,该清单包含所有经过修改和合并的资源配置,可以直接应用于 Kubernetes 集群。

  3. 方便资源部署和管理:kubectl kustomize 命令简化了在不同环境中部署和管理 Kubernetes 资源的过程。您可以轻松地在开发、测试和生产等不同环境中使用相应的覆盖层,以确保配置正确。

注意:我们前面所介绍的一些资源清单文件的字段值有些是为空的、甚至是一些名称没有填写完整等,这些空缺的部分,就是我们后续手动调整的地方,也叫补丁,大白话就是用于 DIY。 

上一篇文章:【Kubernetes 企业项目实战】09、Rancher 2.6 管理 k8s-v1.23 及以上版本高可用集群_rancher 高可用_Stars.Sky的博客-CSDN博客

下一篇文章:【Kubernetes 企业项目实战】11、掌握 Kubernetes Kustomize 技术从入门到企业实战(下)_Stars.Sky的博客-CSDN博客文章来源地址https://www.toymoban.com/news/detail-405279.html

到了这里,关于【Kubernetes 企业项目实战】10、掌握 Kubernetes Kustomize 技术从入门到企业实战(上)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Kubernetes 企业项目实战】06、基于 Jenkins+K8s 构建 DevOps 自动化运维管理平台(中)

    目录 一、基于 Jenkins+k8s+Git+Docker Hub 等技术链构建企业级 DevOps 容器云平台 1.1 安装 Jenkins 1.1.1 安装 nfs 服务 1.1.2 在 kubernetes 中部署 jenkins 1.2 配置 Jenkins ​1.2.1 获取管理员密码 1.2.2 安装插件 1.2.3 创建第一个管理员用户 1.3 测试 jenkins 的 CI/CD 1.3.1 在 Jenkins 中安装 kubernetes 插件

    2024年01月16日
    浏览(75)
  • 在CSDN学Golang云原生(Kubernetes声明式资源管理Kustomize)

    在 Kubernetes 中,我们可以通过 YAML 或 JSON 文件来定义和创建各种资源对象,例如 Pod、Service、Deployment 等。下面是一个简单的 YAML 文件示例,用于创建一个 Nginx Pod: 该文件包含了以下信息: apiVersion :指定 Kubernetes API 的版本。 kind :指定资源类型,这里为 Pod。 metadata :定义

    2024年02月15日
    浏览(34)
  • Python入门教程+项目实战-10.5节: 程序实战-冒泡排序算法

    目录 10.5.1 排序算法简介 10.5.2 冒泡排序算法 10.5.3 系统学习python 所谓排序,是指将数据集合中的元素按从小到大的顺序进行排列,或按从大到小的顺序进行排列。前者称为升序排序,后者称为降序排序。在数据结构与算法这门课程中,我们会学习到诸多与排序相关的算法,

    2023年04月21日
    浏览(42)
  • ROS从入门到精通10-1:项目实战之智能跟随机器人原理与实现

    本专栏旨在通过对ROS的系统学习,掌握ROS底层基本分布式原理,并具有机器人建模和应用ROS进行实际项目的开发和调试的工程能力。 🚀详情:《ROS从入门到精通》 机器人是传感器网络、通信、人工智能、分布式计算、自动化等多种技术的集大成者, 机器人技术的发展水平标

    2024年02月07日
    浏览(44)
  • 2023必须掌握的10大Web3技术

    到 2028 年,估计 Web3 的市场规模将超过 125 亿美元。该领域的潜力意味着对 Web3 技术专家的需求将猛增。如果您想让您的技能对雇主有吸引力,您需要加入 Web3 的潮流。 如果你想保持领先,那么在接下来的十年里开始学习Web3的十大技术是非常重要的。 区块链是Web3最知名的方

    2024年02月12日
    浏览(48)
  • kubernetes--技术文档--基本概念--《10分钟快速了解》

    Kubernetes 也称为 K8s,是用于自动部署、扩缩和管理容器化应用程序的开源系统。 它将组成应用程序的容器组合成逻辑单元,以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验,同时凝聚了社区的最佳创意和实践。 Kubernetes 是开源系统,可以自由地部署在企

    2024年02月12日
    浏览(53)
  • 《DevOps企业级CI/CD实战》:一站式掌握DevOps核心方法论,实现高效自动化部署

    DevOps是一组实践,由人、工具和文化理念组成。DevOps的核心是实现软件开发团队和IT运维团队之间的流程自动化。自2018年起,笔者参与了大型企业中多个项目的DevOps项目实施和改进,从中积累了丰富的实践经验。于是将实践思考与开发经验整理成一本书分享给同路人共同学习

    2024年04月14日
    浏览(67)
  • 最强AIGC实战应用速成指南来了!14天掌握核心技术

    ‍‍OpenAI 创始人 Sam Altman 在近期采访中说到:\\\" AI 是少有的被严重炒作之后,还被严重低估的东西。\\\"  现在的 AI 几乎把互联网上所有的数据都学习了一遍,相当于一个世界知识的统一建模。在如此规模的参数量下,更好的关联推理就能够实现了,也能够通过算法更好地模拟

    2024年02月12日
    浏览(57)
  • 《Kubernetes入门实战课》课程学习笔记(一)

    现在 Kubernetes 已经没有了实际意义上的竞争对手,它的地位就如同 Linux 一样,成为了事实上的云原生操作系统,是构建现代应用的基石。 现代应用是什么? 是微服务,是服务网格,这些统统要围绕着容器来开发、部署和运行。 使用容器就必然要用到容器编排技术,在现在只

    2024年02月17日
    浏览(72)
  • 从零开发JavaWeb入门项目--十天掌握

    原文网址:从零开发JavaWeb入门项目--十天掌握_IT利刃出鞘的博客-CSDN博客 这是一个靠谱的JavaWeb入门项目实战,名字叫蚂蚁爱购。 从零开发项目 , 视频加文档 , 十天就能学会开发JavaWeb项目 ,教程路线是: 搭建环境 = 安装软件 = 创建项目 = 添加依赖和配置= 通过表生成代码

    2024年02月10日
    浏览(34)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包