In this post, I’d like to share my perspective on Kapitan’s inventory/classes and inventory/targets, along with a few examples.

For those who need a brief introduction, you can read my previous post, “Kapitan — Rise and Shine,” and follow along with the entire Kapitan blog.

I’ll explain my understanding of Kapitan’s “inventory section” and how I utilize it in my workflows.

Overview

Here you can see the overall components.

NOTE:

In the following, I will explain how I use Kapitan. It’s designed to be flexible and adaptable to various needs, so my approach may not fit your specific use case. I encourage you to share your methods and experiences in the comments section.

Inventory

inventory/classes

Classes represent the most generic form of an application or microservice, including its default parameters.

I prefer to organize these classes into folders. For instance, I have a “database” folder where I store my generic PostgreSQL and MySQL configurations.

When defining a service, certain default parameters may or may not be necessary. In my case, I like to use the image postgres:10 by default, set a backup interval of every 6 hours, and specify the storage class longhorn, which I usually have installed.

Given these requirements, I set the following values as my default parameters:

Note: The following two code blocks are from the same file.

$ cat inventory/classes/database/postgres.yml
parameters:
  postgres:
    image: postgres:${postgres:version}
    version: "10"
    backup:
      interval: "0 */6 * * *"
      size: 10Gi
    component: database
    users:
      postgres:
        password: ?{plain:targets/${target_name}/postgres-password||randomstr|base64}
    persistence:
      storageclass: "longhorn"
      accessModes: ["ReadWriteOnce"]
      size: 10Gi
[...]

I even let create the postgres.users.postgres.passwordsecret by Kapitan, if its not pre-existing using:

?{plain:targets/${target_name}/postgres-password||randomstr|base64}

But more on that in another post…

These parameters can now be referenced in the components section of Kapitan like so:

$ cat inventory/classes/database/postgres.yml
[...]  #
  # Components / Parts
  #
  components:
    postgres:
      type: statefulset
      image: ${postgres:image}
      labels:
        app.kubernetes.io/version: ${postgres:version}
        app.kubernetes.io/component: ${postgres:component}
      service:
        type: ClusterIP
      ports:
        tcp:
          service_port: ${database:port}
      env:
        POSTGRES_PASSWORD: ${postgres:users:postgres:password}
        POSTGRES_USER: ${database:user}
        POSTGRES_DB: ${database:name}
      volume_mounts:
        pgdata:
          mountPath: /var/lib/postgresql/data/
          subPath: pgdata
      volume_claims:
        pgdata:
          spec:
            accessModes: ${postgres:persistence:accessModes}
            storageClassName: ${postgres:persistence:storageclass}
            resources:
              requests:
                storage: ${postgres:persistence:size}

As shown above, I have linked all my default parameters into the relevant component. This approach is similar to using a JSON/YAML path.

inventory/targets

Targets are a combination of available classes, parameter overrides, and additional compile tasks for Kapitan. They can also encapsulate information about a complete deployment, such as Nginx, microservices, databases, and backup jobs.

The references under “classes” point directly to files inside the inventory/classes directory.

In the following example, Kapitan expects the following files to be present:

• inventory/classes/common.yml
• inventory/classes/database/postgres.yml
• inventory/classes/database/postgres-backup.yml
• inventory/classes/gitea/gitea.yml
• templates/docs/global/<one or multiple templates>.md.j2

$ cat inventory/targets/gitea/gitea.yml
classes:
  - common
  - database.postgres
  - database.postgres-backup
  - gitea.giteaparameters:
  target_name: gitea
  domain: <my domain>

  components:
    gitea:
      service:
        type: NodePort  kapitan:
    compile:
    - output_path: .
      input_type: jinja2
      input_paths:
      - templates/docs/global/

I also set a target_name here as gitea. This could also be something like target_name: gitea-dev or any similar identifier.

For instance, if I specified the service type in a class’s components section as ClusterIP, but need it to be NodePort for a particular use case, I can simply override it by setting parameters.components.gitea.service.type within the target file.

With parameters.kapitan.compile, I can also add additional documentation for a project or stage.

If I want to set up a multistage environment, I can use the following structure for a development environment:

$ cat inventory/targets/gitea/gitea-dev.yml
classes:
  - common
  - database.postgres
  - database.postgres-backup
  - gitea.giteaparameters:
  target_name: gitea-dev
  domain: <my dev domain>
[...]

for a QS environment:

$ cat inventory/targets/gitea/gitea-qs.yml
classes:
  - common
  - database.postgres
  - database.postgres-backup
  - gitea.giteaparameters:
  target_name: gitea-qs
  domain: <my qs domain>
[...]

Summary

In this post, we explored how to configure and utilize Kapitan’s inventory/classes and inventory/targets to streamline your deployment processes. We discussed how to set default parameters for different services, organize them efficiently, and use targets to combine classes, override parameters, and add custom compile tasks. By following these practices, you can create a flexible and efficient deployment strategy tailored to your specific needs.

I can also define specific compilations for particular targets of your deployment configurations.

For more detailed examples and further reading, be sure to check the Kapitan-reference repository.

Cheers!

Sources:

• https://medium.com/kapitan-blog
• https://kapitan.dev/kapitan_overview/
• https://kapitan.dev/#faq
• https://github.com/kapicorp/kapitan-reference