Components

In this lesson, we will explore a powerful feature in Kustomize called components. Components allow you to define a reusable block of configuration logic that can be included in multiple overlays. This approach is particularly beneficial when an application supports optional features that should only be enabled in certain overlays instead of globally. By centralizing feature-specific configurations—such as Kubernetes resources, patches, config maps, and secrets—you reduce duplication and prevent configuration drift.

When to Use Components

Imagine a scenario where you have a set of configurations to enable a specific feature. If this feature were meant for all overlays, including the configuration in the Base might be appropriate. However, when the feature should only be activated in a subset of overlays, manually duplicating the configuration leads to scalability issues and potential errors. Components solve this problem efficiently by maintaining a centralized configuration that you can import wherever necessary.

Visual Example

Consider an application that can be deployed in three variations: development, premium, and self-hosted. The Base configuration holds common settings, while each variation is represented by its own overlay folder. Suppose the application has two optional features:

1. Caching: Only the premium and self-hosted versions require caching, which involves deploying a Redis instance along with its configurations and secrets.
2. External Database: A PostgreSQL database is enabled only for the development and premium versions.

Including the caching configuration directly in the Base would apply it to all overlays unintentionally, and duplicating the configuration across multiple overlays is error-prone. Components allow you to write the configuration once and reuse it across the specific overlays where it's needed.

Below is an image that illustrates the relationships between the Base, overlays, and components (caching and external databases):

Organizing Components

A well-organized project structure simplifies management. Consider the following directory layout:

k8s/
├── base/
│   ├── kustomization.yaml
│   └── api-depl.yaml
├── components/
│   ├── caching/
│   │   ├── kustomization.yaml
│   │   ├── deployment-patch.yaml
│   │   └── redis-depl.yaml
│   └── db/
│       ├── kustomization.yaml
│       ├── deployment-patch.yaml
│       └── postgres-depl.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    ├── premium/
    │   └── kustomization.yaml
    └── standalone/
        └── kustomization.yaml

In this setup:

• Base contains shared configurations.
• Overlays (dev, premium, standalone) inherit from the Base.
• Components store isolated configurations for individual features, such as caching and external database (db). Each component directory includes all the necessary Kubernetes resources to enable the feature.

The following image demonstrates the hierarchy of Base, overlays, and components:

Once organized into components, overlays simply import the desired component by referencing its path within the kustomization configuration. This method minimizes duplication and streamlines updates across all relevant overlays.

Implementing a Kustomize Component

Let's walk through an example by implementing the database component. In the db folder, you will find the following files:

• postgres-depl.yaml: Defines the deployment resource for a PostgreSQL database.
• deployment-patch.yaml: Contains a strategic merge patch to update the base deployment with database-specific configurations.
• kustomization.yaml: Declares the component by importing resources, generating secrets, and applying patches.

Postgres Deployment Configuration

The postgres-depl.yaml file creates a PostgreSQL deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      containers:
        - name: postgres
          image: postgres

Component kustomization.yaml

In the component’s kustomization.yaml, a different API version and kind indicate that this is a component. It imports the PostgreSQL deployment, generates a secret for the database password, and applies patches:

apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
resources:
  - postgres-depl.yaml
secretGenerator:
  - name: postgres-cred
    literals:
      - password=postgres123
patches:
  - deployment-patch.yaml

Deployment Patch

The deployment-patch.yaml file is a strategic merge patch that updates the Base deployment by adding an environment variable for the database password. This integration ensures that the Base application can securely access the database credentials when the feature is enabled:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  template:
    spec:
      containers:
      - name: api
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-cred
              key: password

Overlay Configuration

To integrate the database component into an overlay—such as the development overlay—the overlay’s kustomization.yaml file should reference both the Base configuration and the specific component:

bases:
  - ../../base
components:
  - ../../components/db

By listing the component path under the components section, the overlay effortlessly incorporates the external database feature without duplicating any configuration.

Conclusion

Components in Kustomize are an efficient way to manage feature-specific configurations. By encapsulating these configurations into reusable blocks, you can enable or disable features across different overlays without cluttering your Base configuration. This approach not only reduces duplication but also maintains a clean, manageable project structure that scales with your application.

For further reading on Kubernetes configuration management, consider visiting Kubernetes Documentation.