Kustomize with Nirmata
Kustomize allows management of variation and customization for resource manifests from a single base definition (for more information, visit: https://kustomize.io). This allows developers to build single manifest file for their applications and customize the application configuration based on the environment it is being deployed in.
As part of its workflow, Nirmata supports and extends the kustomize capability in the followings ways:
- Fixed Kustomization - Customize an application for specific namespace with “Fixed Kustomization”. In this case, fixed configuration updates, specific to the application can be created as part of the application in the Nirmata catalog.
- Target Based Kustomization - With target based kustomization, multiple configurations to the base manifest file can be specified and selected based on the target application namespace or cluster. Nirmata will automatically match the target labels, and overlay the appropriate configuration specific to that namespace or cluster to the base manifest file.
Configure Fixed Kustomization
For fixed kustomization for an application, when creating a Git application, click the kustomize button, which will open kustomize options menu. Here, pick kustomization file (syntax - kustomization.yaml) that you would use for customizing configuration for the base manifest file.
Target Based Kustomization
Nirmata supports both namespaces (environments in Nirmata) and clusters as targets for customizing manifest configurations. The cluster based kustomization is useful for managing cluster level services such as add-ons, across a fleet of clusters. Environment based kustomizations allow deploying an application across multiple namespaces with necessary custom configurations specific to those namespaces. The namespaces may exist on the same cluster or across multiple clusters. As long as the name and labels match, the configuration can be customized based on the target.
Environments as Kustomization Targets
For environment (namespace on a cluster) based target kustomization, refer to sample kustomization files and directory structure shown here . It is important to note that the kustomize file should have the name “kustomize-patches.yaml”.
The directory structure is shown below -
Here is an example of kustomize-patches.yaml file for environments:
environmentPatches: - target: kind: Environment name: environment-1 labelSelector: env: "env01" kustomizePatch: ./environment-1/ - target: kind: Environment labelSelector: env: "env02" kustomizePatch: ./environment-2/ - target: kind: Environment name: environment-3 kustomizePatch: ./environment-3/
Here is a sample kustomization file for individual environment:
resources: - ../ghost.yaml patchesStrategicMerge: - |- apiVersion: apps/v1 kind: Deployment metadata: name: ghost labels: nirmata.io/deployment.name: "ghost" nirmata.io/component: "ghost" spec: replicas: 2
Clusters as Kustomization Targets
For cluster based target kustomization, refer to sample kustomition file and directory structure shown here . Again, the kustomization file for clusters should have the name “kustomize-patches.yaml”.
The directory structure looks as shown below:
Here is an example of kustomize-patches.yaml file:
clusterPatches: - target: kind: Cluster labelSelector: cluster-name: "cluster-001" kustomizePatch: ./cluster-001/ - target: kind: Cluster name: cluster-002 kustomizePatch: ./cluster-002/ - target: kind: Cluster name: cluster-003 labelSelector: cluster-type: eks
Below is sample kustomization file for individual cluster:
resources: - ../base/ patchesStrategicMerge: - |- apiVersion: apps/v1 kind: Deployment metadata: name: frontend labels: app.kubernetes.io/name: guestbook app.kubernetes.io/component: frontend spec: selector: matchLabels: app.kubernetes.io/name: guestbook app.kubernetes.io/component: frontend replicas: 1 template: metadata: labels: app.kubernetes.io/name: guestbook app.kubernetes.io/component: frontend spec: containers: - name: guestbook resources: requests: cpu: 10m memory: 10Mi limits: cpu: 510m memory: 510Mi