Library Charts and Organizational Standardization

In Chapters 1-9, you've built individual Helm charts that deploy applications with templating, hooks, and distribution strategies. But what happens when you have 10 microservices? Do you repeat the same labels, resource probes, and annotations in each chart? What if your security team requires specific SecurityContext defaults across all deployments?

This chapter introduces library charts—a Helm pattern that solves this through reusable templates. Instead of duplicating patterns across charts, you encode them once in a library chart that all application charts consume. Your organization then has a single source of truth for labels, probes, resource defaults, and organizational standards.

By the end of this chapter, you'll understand how library charts enforce consistency across your platform without forcing teams into rigid constraints.

---

What You'll Learn

This chapter covers 8 concepts organized into 3 groups:

Concept Groups

Prerequisites

• ✅ Completed Chapters 1-4 (Helm basics, templating, values)
• ✅ Understanding of include function and template helpers
• ✅ Experience creating application charts

Time Estimate: 45 minutes

---

Concept 1: Library Chart Type

Library charts declare their purpose in Chart.yaml with type: library. This tells Helm that this chart exists to be included as a dependency, not to be installed directly.

Creating a Library Chart

Start with the basic structure:

Create org-standards/Chart.yaml:

Create org-standards/values.yaml with organizational defaults:

Output:

The type: library field distinguishes this chart from application charts (which have no type field or type: application).

---

Concept 2: Why Library Charts Cannot Be Installed Directly

Helm refuses to install library charts directly. They contain only template definitions, not complete deployable resources.

Testing the Restriction

Try installing the library chart:

Output:

This restriction is intentional. Library charts have no .Chart.Name release—they're meant to provide helper functions that application charts use. Installing them directly would create an empty release with no resources, providing no value.

---

Checkpoint: Library Chart Fundamentals

Quick Reference:

Self-Check Questions:

1. What happens if you try to helm install a library chart?
2. Why does Helm prevent library chart installation?
3. Where does the library chart declaration go in Chart.yaml?

Answers:

1. Helm returns an error: "chart is a library chart. Library charts are not installable"
2. Library charts contain only template definitions, not complete deployable resources
3. type: library field in Chart.yaml

---

Concept 3: Common Templates for Organizational Consistency

Create reusable templates in the library chart that enforce organizational patterns.

Creating Labels Template

Create org-standards/templates/_labels.tpl:

Creating Common Annotations Template

Create org-standards/templates/_annotations.tpl:

Creating Probes Template

Create org-standards/templates/_probes.tpl:

Output:

These templates define labels, annotations, and probes that any application chart can use without reimplementation.

---

Concept 4: Consuming Library Charts as Dependencies

Application charts declare library charts as dependencies in Chart.yaml.

Create Application Chart with Library Dependency

Create my-api/Chart.yaml with library dependency:

Create my-api/values.yaml:

Update Helm dependencies:

Output:

The helm dependency update command fetches the library chart and places it in my-api/charts/org-standards/.

---

Concept 5: Using include to Pull Library Templates

Application charts use include function to reference templates from library charts.

Creating Application Deployment Using Library Templates

Create my-api/templates/deployment.yaml:

Output:

The include function pulls templates from the library chart and injects them into the deployment, automatically inheriting organization labels and probes.

---

Concept 6: Override Patterns for Application-Specific Values

Applications override library defaults through the values.yaml hierarchy while maintaining organizational standards.

Creating Multiple Application Charts with Overrides

Application 1: Web service

Create web-service/Chart.yaml:

Create web-service/values.yaml:

Application 2: Background worker

Create bg-worker/Chart.yaml:

Create bg-worker/values.yaml:

Output:

Each application overrides organizational defaults for its context while maintaining consistency through the library chart.

---

Checkpoint: Creating and Consuming Library Templates

Quick Reference:

Self-Check Questions:

1. How do application charts reference library chart templates?
2. What command fetches library chart dependencies?
3. How can applications override library default values?

Answers:

1. Using include function: {{- include "library-name.template-name" . }}
2. helm dependency update <chart-directory>/
3. Through values.yaml hierarchy under the library chart's name (e.g., org-standards:)

---

Concept 7: Enterprise Use Cases

Library charts solve real organizational problems: enforcing security policies, maintaining labeling conventions, and standardizing resource defaults across hundreds of deployments.

Common Enterprise Library Chart Patterns

Pattern 1: Security Enforcement

Create org-standards/templates/_security.tpl:

All deployments automatically get security hardening without individual configuration.

Pattern 2: Compliance Labels

Add to org-standards/values.yaml:

Platform teams enforce compliance requirements that auditors verify through labels.

Pattern 3: Cost Attribution

Create org-standards/templates/_costAttribution.tpl:

Finance teams track costs per team/project through labels injected by the library.

---

Concept 8: Template Inheritance and Overrides

Templates in library charts can be extended or overridden by application charts, creating a flexible inheritance pattern.

Base Probe Template with Override Points

Create org-standards/templates/_probes-extended.tpl:

Application Chart Overrides Probe Behavior

Create my-app/values.yaml:

Output:

The library chart defines structure and defaults, but applications customize behavior through values without modifying templates.

---

Checkpoint: Advanced Patterns

Quick Reference:

Self-Check Questions:

1. How can library charts enforce security policies across all deployments?
2. What's the pattern for allowing applications to override library defaults?
3. Why include compliance labels in library charts instead of application charts?

Answers:

1. Define security templates (SecurityContext, resource limits) that all apps include automatically
2. Use default function and conditional logic: {{ .Values.custom | default .Values.libraryDefault }}
3. Ensures consistency across all deployments, simplifies auditing, prevents human error

---

Common Mistakes

Before starting the exercises, be aware of these common pitfalls:

Example: Correct Overriding

---

Exercises

Exercise 8.1: Create a Library Chart

Create your own library chart with organizational standards.

Steps:

1. Create directory: mkdir -p org-lib/templates
2. Create Chart.yaml with type: library
3. Create values.yaml with default labels and annotations
4. Create _helpers.tpl with common label template

Validation: helm lint org-lib/ should show no errors

Expected outcome:

• Chart.yaml contains type: library
• values.yaml has default organization metadata
• _helpers.tpl defines reusable label template

---

Exercise 8.2: Verify Library Chart Cannot Be Installed

Attempt to install the library chart and observe Helm's protection.

Steps:

1. Run: helm install test org-lib/ --dry-run=client
2. Observe the error message

Expected error:

---

Exercise 8.3: Create Organizational Templates

Add security context, resource requests, and probe templates to your library.

Steps:

1. Create _security.tpl with SecurityContext template
2. Create _resources.tpl with resource requests/limits
3. Create _probes.tpl with liveness/readiness probes

Validation: helm lint org-lib/ should succeed

---

Exercise 8.4: Create Application Chart with Library Dependency

Build an application chart that declares the library as a dependency.

Steps:

1. Create app chart directory: mkdir -p my-service/templates
2. Add library dependency in Chart.yaml
3. Run: helm dependency update my-service/

Validation: ls my-service/charts/ should show org-lib

---

Exercise 8.5: Use include to Pull Library Templates

Create a deployment that uses library templates.

Steps:

1. Create templates/deployment.yaml in application chart
2. Use include "org-lib.labels" . for labels
3. Use include "org-lib.livenessProbe" . for probes
4. Run: helm template my-service .

Validation: Template output includes labels and probes from library

---

Exercise 8.6: Override Library Defaults

Modify application values to override library probe defaults.

Steps:

1. Add probe customization to values.yaml
2. Modify templates/deployment.yaml to use conditional overrides
3. Run: helm template my-service . twice:
   • First with defaults
   • Then with custom values

Validation: Second template output uses custom probe paths/timings

---

Try With AI

Step 1: Design Library Chart Structure

Ask AI: "I have 5 microservices that all need the same Kubernetes labels (organization, team, cost-center), security context (runAsNonRoot, readOnlyRootFilesystem), and health check probes. I want to avoid repeating this in each service's chart. How would I structure a library chart to enforce these standards across all services?"

Step 2: Evaluate the Recommendation

Review AI's response. Ask yourself:

• Does the recommendation include type: library in Chart.yaml?
• Does it separate reusable templates (helpers) from application logic?
• Can all 5 services consume this single library without modification?

Step 3: Request Implementation Guidance

Tell AI: "I need the library to provide templates for common labels, security context, and probes. The application charts should be able to override the probe paths (some use /health, others use /api/health-check). Walk me through how to structure the template conditionals so apps can override without duplicating code."

Step 4: Test the Pattern

Ask AI: "Show me how an application chart would declare this library as a dependency and use the library's label template. I want to see the Chart.yaml, values.yaml, and a sample deployment.yaml that pulls in the library templates."

Step 5: Validate the Approach

Ask yourself:

• Does the application chart dependency declaration match library chart naming?
• Can I see which values override organizational defaults?
• Is the include syntax correct for pulling templates from dependency charts?
• Would this pattern scale to 10+ applications without duplication?

---

Reflect on Your Skill

You built a helm-chart skill in Chapter 0. Test and improve it based on what you learned.

Test Your Skill

Identify Gaps

Ask yourself:

• Did my skill create a chart with type: library in Chart.yaml?
• Did it explain why library charts cannot be installed directly?
• Does it demonstrate creating reusable templates (_helpers.tpl patterns)?
• Did it show how application charts consume library dependencies?

Improve Your Skill

If you found gaps: