Skip to content

Latest commit

 

History

History
100 lines (69 loc) · 5.95 KB

README.md

File metadata and controls

100 lines (69 loc) · 5.95 KB
Raw

Main Pipeline Release Pipeline

Kuberpult Readme for users

Etymology

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

About

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.

Purpose

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.

Kuberpult Design Principles

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.

API

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.

Argo CD

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.

App Locks & Environment Locks

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.

Public releases of Kuberpult

Docker Registries

Kuberpult's docker images are currently available in one docker registry: (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)

Deprecation Notes

We used to maintain another docker registry on github as well: ghcr.io/freiheit-com/kuberpult/ . However, we are not maintaining it anymore and it will be removed in future releases. Please use the google registry to retrieve kuberpult images.

GitHub Releases

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

Helm Chart

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.

Releasing a new version

See endpoint-release

Release Train Overview

See release train

Environment Config

See environment

Best practices

Remove individual environments from a service

See Remove Env From Service

Remove a service entirely

See Remove Service Entirely