> For the complete documentation index, see [llms.txt](https://dinush-chathurya.gitbook.io/kustomize-e-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dinush-chathurya.gitbook.io/kustomize-e-book/additional-topics/16-production-grade-templates.md).

# Production-Grade Templates

Reusable Kustomize templates (also called “components”) speed up development, enforce consistency, and reduce duplication. In this chapter, we’ll explore patterns for creating and consuming production-grade templates across multiple teams and services.

***

## What Are Production-Grade Templates?

* **Templates/Components**: Pre-built sets of resources (e.g., logging sidecars, service monitors, network policies) packaged as Kustomize overlays or bases.
* **Goals**:
  * Promote reuse of vetted, tested configurations
  * Enforce organizational standards
  * Simplify on-boarding of new services

***

## Folder Layout for Templates

A centralized repository of components might look like:

```yaml
kustomize-templates/
├── service-monitor/
│   ├── base/
│   │   ├── service-monitor.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       └── default/
│           └── kustomization.yaml
├── logging-sidecar/
│   ├── base/
│   │   ├── fluentd-sidecar.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       └── high-throughput/
│           └── kustomization.yaml
└── README.md
```

***

## Consuming a Template

In your service repo:

```yaml
# service-a/base/kustomization.yaml
resources:
  - ../../kustomize-templates/service-monitor/base
  - ../../kustomize-templates/logging-sidecar/base
  - deployment.yaml
  - service.yaml
```

If you need custom tweaks:

```yaml
# service-a/overlays/dev/kustomization.yaml
resources:
  - ../../base
patchesStrategicMerge:
  - ../../kustomize-templates/logging-sidecar/overlays/high-throughput/kustomization.yaml
```

## Example: Service Monitor Component

`kustomize-templates/service-monitor/base/service-monitor.yaml`

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: default-service-monitor
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: http
      path: /metrics
```

`kustomize-templates/service-monitor/overlays/default/kustomization.yaml`

```yaml
resources:
  - service-monitor.yaml
```

## Best Practices for Templates

### Version & Tag

* Release templates with semver tags (e.g., `v1.2.0`).
* Pin component versions in service overlays.

### Parameterize with Generators

* Use `configMapGenerator` in the template base to accept environment-specific values.

### Document Usage

* Include examples in each template’s `README.md`.
* Show default values and override patterns.

### Test Components

* Validate with `kustomize build` + `--dry-run`.
* Incorporate in CI (e.g., a “template-lint” job).

### Keep Templates Focused

* One responsibility per template (e.g., logging, monitoring—not both in one template).

***

## Updating Templates

### Deprecation Policy

* Support older versions for a transition period.

### Migration Guides

* Document breaking changes and upgrade paths.

### Automated PRs

* Use bots (e.g., Renovate) to bump template versions in service repos.

***

## Auditing & Governance

### Security Review

* Scan template images for vulnerabilities.

### Policy Compliance

* Ensure templates embed organizational policies (RBAC, network policies).

### Approval Process

* Merge templates via protected branches and peer review.

***

## Summary

Production-grade templates unlock consistency and accelerate delivery across teams. By versioning, documenting, and testing your components, you create a reliable library of best-practice configurations that every service can consume.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://dinush-chathurya.gitbook.io/kustomize-e-book/additional-topics/16-production-grade-templates.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.