Skip to content
This repository has been archived by the owner on Dec 3, 2020. It is now read-only.

Latest commit

 

History

History
58 lines (30 loc) · 3.44 KB

generator.md

File metadata and controls

58 lines (30 loc) · 3.44 KB

Generator

generators are the essential part of kustomize. it's a code that creates new resources. Basically there are only 2 ways to add new documents to resource list - add them directly to resources, or use generators.

Moreover despite on the name Generators may be used to modify resources: please refer to this page and pay attention to

kustomize.config.k8s.io/behavior

The values "merge" and "replace" can be used to partially or completely modify the previously existing resource.

It's very convenient to use Jinja in generator, because generating documents is the main purpose of template engines.

The exmpample has the following generator

In the current version generator must have 2 fields:

jinjaCatalog

and

jinjaTemplate

Any arbitrary yaml file can be used as jinjaCatalog. There is aspecial case - when this file has kind==JinjaCatalog - in that case the file may be rendered and that adds a lot of flexibility. Basically what is happening is that the resulting content of jinjaCatalog file is put to the jinja global variable catalog and this valiable can be used during resource rendering.

Kustomize allows generator to reture several resources as this example demonstrates.

What we can see in our exmpamle is that the first thing our generator is returning is the whole catalog:

{{ functions.yaml_dump(catalog) }}

here you can see how our renderred catalog looks like. We can avoid dumping the whole catalog by removing the line.

The line:

password: "{{ catalog.data.user }}"

renders password based on what we have in catalog. Here is the resulting yaml with renderred data.

Please note that only one of the config maps in the output has hashed suffix in the output. That is the result of adding the annotation to that ConfigMap:

kustomize.config.k8s.io/needs-hash: "true"

This is a good way to control cases where we need hashed suffix.

Crypted data

The catalog may have a fields with encrypted data: e.g.: here

Jinja template may decript it if ENV variable "JINJA_CRYPT_PASSWORD" is provided. There are 2 functions: crypt_encrypt and crypt_decrypt that use this value as a password. The generator will return error and kustomize build will not finish if the incorrect password is provided. These functions can be used either during catalog renderring or during renderring of the resource. In the example above we used the first approach. Here is the decrypted value.

There is one more potentially helpful function vault_getClient that requires 2 env variables "VAULT_ADDR" and "VAULT_TOKEN". This function returns the client that can be used to access vault parameters directly from jinja templates.