charts | ||
lib | ||
.gitignore | ||
flake.lock | ||
flake.nix | ||
LICENSE | ||
Makefile | ||
README.md |
Turboprop
Problem: I have twenty or thirty Helm releases, all of which I template semi-manually to retain WYSIWYG control. Deploying new applications involves a lot of copy-pasta.
Solution: Use Nix. With Nix, I can ensure chart integrity, generate repetitive data in subroutines, and easily inherit data from elsewhere.
Prior art
Without farcaller's "Nix and Kubernetes: Deployments Done Right" (notes), this project would not exist.
I also used heywoodlh's Kubernetes flake as a starting point early on.
Usage
{ charts, lib, user, ... }: { # 1
builder = lib.builders.helmChart; # 2
args = { # 3
chart = charts.jetstack.cert-manager;
values = {
featureGates = "ExperimentalGatewayAPISupport=true";
installCRDs = true;
prometheus = {
enabled = true;
servicemonitor = {
enabled = true;
prometheusInstance = "monitoring";
};
};
startupapicheck.podLabels."sidecar.istio.io/inject" = "false";
};
};
extraObjects = [ # 4
{
apiVersion = "cert-manager.io/v1";
kind = "ClusterIssuer";
metadata.name = user.vars.k8sCert.name; # 5
spec.ca.secretName = user.vars.k8sCert.name;
}
];
}
lib
flake builders
charts
Signature, etc.
Architecture
Services expected to provide custom APIs (e.g.: Gateway API,
Istio, Longhorn) go in ./system
. All others in ./services
,
including system-service charts dependent on other APIs.
This prevents infinite recursion when gathering APIs.
Each of the leaves of the services
attrsets is a derivation
(explained better in lib/flake-builders.nix
).
Here, they are gathered into one mega-derivation, with Kustomizations
at each level for usage with k apply -k $path
.
namespaces
Assign extra metadata in namespaces.nix
. For example,
svc = {labels."istio.io/rev" = "1-18-1"}
is the equivalent of
k label ns/svc istio.io/rev=1-18-1