Kuberpult is a catapult for kubernetes :) it catapults the containers of microservices to different stages in kubernetes clusters.

Kuberpult helps you manage different versions of different microservices in different cluster. While Argo CD applies the current version of your services in clusters, Kuberpult also helps you with managing what is deployed next.

The purpose of Kuberpult is to help roll out quickly yet organized. We use it for requirements like this:

• We have 3 clusters, development, staging, production
• Any merged changes should instantly be deployed to development.
• After running some test on development, roll out to staging.
• Once a day we trigger a release train that deploys everything to production - using the versions of staging as source.
• Sometimes we want to prevent certain deployments, either of single services, or of entire clusters.
• We never want to deploy (to production) between 9am and 11am as these are peak business hours.

We use these principles to decide what features to focus on. We may deviate a little, but in general we don't want features in kuberpult that violate these points:

• Automatic and regular deployments: Kuberpult is built for teams who want to deploy often (e.g. daily) and setup automated processes for the deployments.
• All power to the engineers: Kuberpult never stops an engineer from deploying manually. The engineers know their services best, so they can decide which version to deploy.
• Microservices: Kuberpult is built on the assumption that our teams work with kubernetes microservices.
• Monorepo: Kuberpult is built for a monorepo setup. One product should be one monorepo. If you have multiple products, consider giving each one a kuberpult instance.

Kuberpult has an API that is intended to be used in CI/CD (GitHub Actions, Azure Pipelines, etc.) to release new versions of one (or more) microservices. The API can also roll out many services at the same time via "release trains". It also supports rolling out some groups of services.

Kuberpult works best with Argo CD which applies the manifests to your clusters and Kuberpult helps you to manage those manifests in the repository.

Kuberpult does not actually deploy. That part is usually handled by Argo CD.

Kuberpult can handle locks in its UI. When something is locked, it's version will not be changed via the API. Both environments and microservices can be locked.

Kuberpult's docker images are currently available in 2 docker registries: (Example with version 0.4.55)

• docker pull europe-west3-docker.pkg.dev/fdc-public-docker-registry/kuberpult/kuberpult-frontend-service:0.4.55 (Link for Kuberpult devs)
• docker pull ghcr.io/freiheit-com/kuberpult/kuberpult-frontend-service:0.4.55 (Link for Kuberpult devs) And the same applies for the kuberpult-cd-service - just replace "frontend" by "cd".

We may deprecate one of the registries in the future for simplicity.

If you're using Kuberpult's helm chart, generally you don't have to worry about that.

To use the helm chart, you can use this url (replace both versions with the current version!). You can see all releases on the Releases page on GitHub

See values.yaml.tpl for details like default values.

Most important helm chart parameters are:

• git.url: required - The url of the git manifest repository. This is a shared repo between Kuberpult and Argo CD.
• git.branch: recommended - Branch name of the git repo. Must be the same one that Argo CD uses.
• ssh.identity: required - The ssh private key to access the git manifest repo.
• ssh.known_hosts: - The ssh key fingerprints of for your git provider (e.g. GitHub)
• pgp.keyring: recommended - Additional security. Highly recommended if you do not us IAP. If enabled, calls to the REST API need to provide signatures with each call. See create-release for an example.
• ingress.create: recommended - If you want to use your own ingress, set to false.
• ingress.iap: recommended - We recommend to use IAP, but note that this a GCP-only feature.
• datadogTracing: recommended - We recommend using Datadog for tracing. Requires the Datadog daemons to run on the cluster.
• dogstatsdMetrics: optional - As of now Kuberpult sends very limited metrics to Datadog, so this is optional.
• auth.aureAuth.enabled: recommended - Enable this on Azure to limit who can use Kuberpult. Alternative to IAP. Requires an Azure "App" to be set up.

See endpoint-release

See release train

See environment

See Remove Env From Service

See Remove Service Entirely