Package: kubetools
KubetoolsKubetools is a tool and processes for developing and deploying microservices to Kubernetes. Say that:You havea bunch of repositories, each containing one or more microservicesYou want todeploy each of these microservices into one or more Kubernetes clustersYou want asingle configuration file per project(repository)And you would like:Development setup should be near-instant- andnotrequire specific K8s knowledgeDeployment to production can be automated- and integrated with existing CI toolingKubetools provides the tooling required to achieve this, by way of two CLI tools:ktd: generates100% localdevelopment environments using Docker/docker-composekubetools: deploys projects to Kubernetes, handling any changes/jobs as requiredBoth of these use a single configuration file,kubetools.yml, for example a basicdjangoapp:name:my-appcontainerContexts:django_app:build:registry:my-registry.netdockerfile:Dockerfiledev:volumes:-./:/opt/django_appupgrades:-name:Upgrade databasecontainerContext:django_appcommand:[./manage.py,migrate,--noinput]tests:-name:NosetestscontainerContext:django_appcommand:[./manage.py,test]deployments:my-app-webserver:serviceAccountName:webserversecrets:secret-volume:mountPath:/mnt/secrets-storesecretProviderClass:webserver-secretscontainers:uwsgi:command:[uwsgi,--ini,/etc/uwsgi.conf]containerContext:django_appports:-80dev:command:[./manage.py,runserver,'0.0.0.0:80']dependencies:mariadb:containers:mariadb:image:mariadb:v10.4.1cronjobs:my-cronjob:batch-api-version:'batch/v1beta1'# Must add if k8s version < 1.21+schedule:"*/1****"concurrency_policy:"Replace"containers:hello:image:busyboxcommand:[/bin/sh,-c,date; echo Hello from the Kubernetes cluster]With this in your current directory, you can now:# Bring up a local development environment using docker-composektdup# Deploy the project to a Kubernetes namespacekubetoolsdeploymy-namespaceInstallingpipinstallkubetoolsNOTE: Since Cython 3.0 was released, the installation ofkubetoolsdependencies will fail
due to compatibility issues between Cython 3 and PyYaml (seethis issue). This can be worked around for example
withpipby using a "constraints" file containingcython<3.ConfigurationUsers can configure some aspects ofkubetools. The configuration folder location depends on the
operating system of the user. See theClick documentationto find the appropriate one for you. Note that we use the "POSIX" version (for example~/.kubetools/on Unix systems).kubetools.confcontains key-value settings, seesettings.pyfor the
possible settings and their meaning.scripts/can contain scripts to be made available toktd scriptcommandDevelopingInstall the package in editable mode, with the dev extras:pipinstall-e.[dev]Local deployment testingFor deployment testing, you will need a kubernetes cluster and a docker registry. You can get both
easily usingminikube:minikubestart--addonsregistry--insecure-registry${MINIKUBE_IP}:5000Then you can deploy to that environment:kubetools--contextminikubedeploy--default-registry${MINIKUBE_IP}:5000default.MINIKUBE_IPvalue can vary depending on your local environment. The easiest way to get the correct
value is to start minikube once then reset it:minikubestartMINIKUBE_IP=$(minikubeip)minikubedelete
...Releasing (admins/maintainers only)UpdateCHANGELOGto add new version and document itIn GitHub, create a new releaseTitle the releasev<version>(for examplev1.2.3)Select to create a new tagv<version>againstmasterbranchCopy changes in the release fromCHANGELOG.mdinto the release descriptionGitHub Actionswill package the release and
publish it toPypiMounting K8s SecretsWe assume thatServiceAccountandSecretProviderClassare already created (if needed), before deploying the project with kubetools.Docker build argskubetoolsnow supports passing values forARGparameters used in Dockerfiles, using--build-args. This has a couple of caveats though:it is NOT supported inktd. A workaround for this is to use the default value of theARGinstruction.this doesn't affect the image tag pushed to the docker registry, which is based only on the git
commit hash. This means that these arguments cannot be used to generate multiple images from the
same Dockerfile. So their main usage should be to pass secrets that should not be recorded in the
git repository but are needed at build time, to access external resources for example.these values could be recorded in the docker image layer history. To prevent leaking secrets, you
should consider using multi-stage builds where the secrets are only used in a "builder" image.