SREWorks云原生数智运维工程实践-Kubernetes资源编排之三:Kustomize篇(上)

简介: SREWorks云原生数智运维工程实践-

 

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

 

这是我们的《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.yam

 

 

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不变化。

 

 

 


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
11月前
|
运维 Dubbo Cloud Native
Dubbo 云原生重构出击:更快部署、更强控制台、更智能运维
Apache Dubbo 最新升级支持云原生,提供一键部署微服务集群与全新可视化控制台,提升全生命周期管理体验,助力企业高效构建云原生应用。
1525 25
|
11月前
|
运维 Kubernetes Cloud Native
云原生运维也能很稳:Kubernetes 运维避坑指南
云原生运维也能很稳:Kubernetes 运维避坑指南
378 1
|
12月前
|
运维 监控 Cloud Native
从“守机器”到“写策略”——云原生架构把运维逼成了架构师
从“守机器”到“写策略”——云原生架构把运维逼成了架构师
325 1
|
人工智能 运维 监控
阿里云携手神州灵云打造云内网络性能监测标杆 斩获中国信通院高质量数字化转型十大案例——金保信“云内网络可观测”方案树立云原生运维新范式
2025年,金保信社保卡有限公司联合阿里云与神州灵云申报的《云内网络性能可观测解决方案》入选高质量数字化转型典型案例。该方案基于阿里云飞天企业版,融合云原生引流技术和流量“染色”专利,解决云内运维难题,实现主动预警和精准观测,将故障排查时间从数小时缩短至15分钟,助力企业降本增效,形成可跨行业复制的数字化转型方法论。
785 6
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
874 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
636 8
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
运维 监控 Cloud Native
云原生之运维监控实践:使用 taosKeeper 与 TDinsight 实现对 时序数据库TDengine 服务的监测告警
在数字化转型的过程中,监控与告警功能的优化对保障系统的稳定运行至关重要。本篇文章是“2024,我想和 TDengine 谈谈”征文活动的三等奖作品之一,详细介绍了如何利用 TDengine、taosKeeper 和 TDinsight 实现对 TDengine 服务的状态监控与告警功能。作者通过容器化安装 TDengine 和 Grafana,演示了如何配置 Grafana 数据源、导入 TDinsight 仪表板、以及如何设置告警规则和通知策略。欢迎大家阅读。
554 0
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
672 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式