Kustron NPM | npm.io

downloads version

Introduction

If you have started moving your services to kubernetes cluster and was looking for a way to know how to write manifest files in a manageable and idiomatic way- kustron is for you. kustron is a simple cli tool that helps you generate manifest files for your service. kustron uses kustomization for dynamic templating, to keep things simple and understandable.

Few of the manifest files are relevant(e.g. cert.yml) only if you are using GKE, but with some basic tweaking you can make the manifests work for any provider like AWS or Azure. Eventually kustron will be extended to support all the major providers out of the box.

Features

A few of the things kustron can do for you:

Generate k8s manifests with different env specific overrides
Generate a Makefile with helper commands that you can utilise in your CI/CD pipelines
Generate a gitlab pipeline with GCP integration format(more cloud providers and other pipeline runners will be available soon)

Prerequisite

Install via npm- npm i -g kustron
Your application must have been dockerized already, meaning a Dockerfile exists at application root dir

Usage

In your application root dir, you can run this- kustron -g e.g. cd projects/checkout-service && kustron -g
It will ask you a few questions regarding your application; the questions are pretty straight-forward and self-explanatory
Once you have provided all the answers, a k8s folder will be generated with all the necessary files
If you have chosen the option to generate pipeline, it will also generate a Makefile and gitlab pipeline for you
You can also do- kustron -g -p /absolute/path/of/your/application/folder to generate all the mentioned files and folders in the path you specified. e.g. kustron -g /users/lbm/projects/gaan-recorder/
You can always do kustron -h if you need

Next Steps

The generated k8s folder will have following structure

- k8s
  - base
    - config
      - configmap.yml
      - hpa.yml (only if you have told kustron that your application needs autoscaling)
    - deployment.yml
    - ... (other files like service.yml, ingress.yml etc.)
    - kustomization.yml
  - overrides (all the env specific overrides to base manifests reside here in proper folders)
    - dev
      - ...
    - stg
      - ...
    - prd
      - ...

base folder contains base configurations
overrides folder has specific overrides, it considers you will deploy your service at least into 3 envs(e.g. dev, stg, prd)
All the files have necessary comments to help you out with any modifications you want
Adding another env override should be as simple as creating a dir under overrides and copying the files from any of the existing env and doing necessary amendments
If you have asked kustron to generate pipeline as well, it will generate a Makefile as well as a .gitlab-ci.yml file(right now only gitlab pipeline with GCP integration is supported, more options with different providers will come in future)

Apart from these, you should know about few particular files to make things work for your application the right way-

configmap.yml

This is the place where you should put all the env vars that your application need at runtime. For example, in case of a nodejs application, you should put proper NODE_ENV in this file
Check the given comments in the file to understand what you can do with it or check official documentation

deployment.yml

Apart from the env variables that get loaded from configmap(and which is hard coded), there are some sensitive env variables(like api key for a third party service) that you can load via kubernetes secrets
These sensitive env variables can be loaded in deployment.yml during runtime, an example is given as comments in the file itself

cert.yml

Only relevant if you have defined your application to be https only
The certificate created by this yml is a GCP managed certificate resource
This is already tied to the ingress given in env specific overrides(as every env will have different url like dev.myapp.com, stg.myapp.com etc. and hence difference certificates)
If you are not using GCP, you might check how to add other certificates to your ingress. Here's one with let's encrypt

ingress.yml

It's a good practice to have ingress if you want to expose your service, this necessarily works as a load balancer and creates a public ip
If your answer to Is Public was No while creating manifests by kustron, this file won't be generated and your service will only be privately accessible by your other services in the cluster

Makefile & .gitlab-ci.yml

If your answer to Generate Pipeline was Yes, kustron will generate these files for you
These files give you the building blocks for your automated build and deployment pipeline
Check both the files, as they have lots of comments to make things self-explanatory
None of these files will require much changes when you use a different provider like Azure or AWS- but you should check the comments and understand what has to be changed