Convert Helm charts to Kubernetes resources.
kubecrt allows you to define your application's Kubernetes infrastructure based on a single configuration file.
The configuration file contains your application name, and namespace (both can also be set using CLI arguments), and you provide a list of charts that you want to install, optionally providing override values for those charts.
When running kubecrt, you provide it your project's configuration file, and in
turn, it returns you the parsed Kubernetes resource files generated by the
charts.
This allows you to use Helm Charts without actually using Helm, and instead
using regular kubectl to deploy and manage your resources.
The configuration file you feed into kubecrt will be processed using the epp templating tool, allowing you to inject variables at runtime, based on your own conditional logic (production vs staging, etc...).
brew tap blendle/blendle
brew install kubecrt
See kubecrt --help
kubecrt - convert Helm charts to Kubernetes resources
Given a charts.yml file, compile all the charts with
the provided template variables and return the
resulting Kubernetes resource files to STDOUT, or
write them to a provided file.
Doing this, you can use Kubernetes charts, without
having to use Helm locally, or Tiller on the server.
Usage:
kubecrt [options] CHARTS_CONFIG
kubecrt -h | --help
kubecrt --version
kubecrt --example-config
Where CHARTS_CONFIG is the location of the YAML file
containing the Kubernetes Charts configuration.
Arguments:
CHARTS_CONFIG Charts configuration file
Options:
-h, --help Show this screen
--version Show version
-n NS, --namespace=NS Set the .Release.Namespace chart variable,
used by charts during compilation
-a NAME, --name=NAME Set the .Release.Name chart variable, used by
charts during compilation
-o PATH, --output=PATH Write output to a file, instead of STDOUT
-r NAME=URL, --repo=NAME=URL,... List of NAME=URL pairs of repositories to add
to the index before compiling charts config
-p DIR, --partials-dir=DIR Path from which to load partial templates
[default: config/deploy/partials]
-j, --json Print resources formatted as JSON instead of
YAML. Each resource is printed on a single
line.
--example-config Print an example charts.yaml, including
extended documentation on the tunables
See kubecrt --example-config
# apiVersion defines the version of the charts.yaml structure. Currently,
# only "v1" is supported.
apiVersion: v1
# name is the .Release.Name template value that charts can use in their
# templates, which can be overridden by the "--name" CLI flag. If omitted,
# "--name" is required.
name: my-bundled-apps
# namespace is the .Release.Namespace template value that charts can use in
# their templates. Note that since kubecrt does not communicate with
# Kubernetes in any way, it is up to you to also use this namespace when
# doing kubectl apply [...]. Can be overridden using "--namespace". If omitted,
# "--namespace" is required.
namespace: apps
# charts is an array of charts you want to compile into Kubernetes resource
# files.
#
# A single chart might be used to deploy something simple, like a memcached pod,
# or something complex, like a full web app stack with HTTP servers, databases,
# caches, and so on.
charts:
# A Chart can either be in the format REPO/NAME, or a PATH to a local chart.
#
# If using REPO/NAME, kubecrt knows by-default where to locate the "stable"
# repository, all other repositories require the "repo" configuration (see
# below).
- stable/factorio:
# values is a map of key/value pairs used when compiling the chart. This
# uses the same format as in regular chart "values.yaml" files.
#
# see: https://git.io/v9Tyr
values:
resources:
requests:
memory: 1024Mi
cpu: 750m
factorioServer:
# charts.yaml supports the same templating as chart templates do,
# using the "sprig" library.
#
# see: https://masterminds.github.io/sprig/
name: >
{{ env "MY_SERVER_NAME" | default "hello world!" }}
- stable/minecraft:
# version is a semantic version constraint.
#
# see: https://github.com/Masterminds/semver#basic-comparisons
version: ~> 0.1.0
values:
minecraftServer:
difficulty: hard
- opsgoodness/prometheus-operator:
# repo is the location of a repositry, if other than "stable". This is
# the URL you would normally add using "helm repo add NAME URL".
repo: http://charts.opsgoodness.com
values:
sendAnalytics: false
# For the above charts, see here for the default configurations:
#
# * stable/factorio: https://git.io/v9Tyr
# * stable/minecraft: https://git.io/v9Tya
# * opsgoodness/prometheus-operator: https://git.io/v9SAYYou can optionally split your charts.yml file into multiple chunks, by using
partial templates. This works almost the same way as Helm's support for these
in charts. See the Helm documentation for more details.
To use these partials, you have to set the --partials-dir flag when calling
kubecrt, pass it the path to your partials directory, and then use those
partials in your charts.yml.
Example:
charts.yml:
apiVersion: v1
name: my-bundled-apps
namespace: apps
charts:
- stable/factorio:
values:
resources:
{{ include "factorio/resources" . | indent 8 }}partials/factorio/resources.yml
{{- define "factorio/resources" -}}
requests:
memory: 1024Mi
cpu: 750m
{{- end -}}You can then run this as follows:
kubecrt --partials-dir ./partials charts.yml
And the result is a fully-parsed charts printed to stdout.
Some notes:
- you can use subfolders to organise your partials
- each named
definehas to be uniquely named, or risk being overwritten - you can define multiple
defineblocks in a single file - the files don't need to be yaml files, you can use any content you need
make (major|minor|patch)
git push --tags
make dist
open _dist/
Next, go to the GitHub releases page, and edit the tag you just push:
- Release title: vx.x.x
- Describe this release: short description of important changes
- Attach binaries: drop the files created in
_disthere
Click "Update release".
Don't forget to update the Homebrew formula, located at blendle/homebrew-blendle.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent