This documentation is for an older Keptn release. Please consider the newest one when working with the latest Keptn.

Helm

Intro

During keptn install, we are installing Tiller (Helm v2.12.3) on the Kubernetes cluster. Keptn then uses Helm for deploying onboarded services to a Kubernetes cluster. This is currently implemented in Keptn’s helm-service.

Onboarding

Based on the onboarding the carts service tutorial we will describe the two different deployment types that the helm-service manages and what this does on Kubernetes level.

Those deployments are based on the provided helm-chart for the carts microservice, see https://github.com/keptn/examples/tree/0.6.2/onboarding-carts/carts for details.

Direct deployments

In case of deployment_strategy: direct (see shipyard.yaml), Helm deploys a release called sockshop-dev-carts as carts in namespace sockshop-dev.

$ kubectl get deployments -n sockshop-dev carts -owide
NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                 SELECTOR
carts   1/1     1            1           56m   carts        docker.io/keptnexamples/carts:0.11.1   app=carts

When sending a new-artifact, we are updating the helm charts values.yaml file with the respective image name.

Blue-green deployments

In case of deployment_strategy: blue_green_service (see shipyard.yaml), Helm creates two deployments within the Kubernetes cluster: the primary and the canary deployment. This can be inspected using the following command:

$ kubectl get deployments -n sockshop-staging carts carts-primary -owide
NAME            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                 SELECTOR
carts-primary   1/1     1            1           56m   carts        docker.io/keptnexamples/carts:0.11.1   app=carts-primary
carts           0/0     0            0            3m   carts        docker.io/keptnexamples/carts:0.11.2   app=carts

When a new artifact is deployed (e.g., 0.11.2), a canary deployment will be modified and scaled up.

NAME            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                 SELECTOR
carts-primary   1/1     1            1           57m   carts        docker.io/keptnexamples/carts:0.11.1   app=carts-primary
carts           0/1     1            1            1m   carts        docker.io/keptnexamples/carts:0.11.2   app=carts

The primary deployment is always available (and called carts-primary). The canary deployment (called carts) gets scaled up in the case of a new-artifact event (e.g., in this case someone has sent a new-artifact for 0.11.2). Traffic is shifted to the canary release.

Once testing has finished, the primary deployment is upgraded to the new version (0.11.2).

NAME            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                 SELECTOR
carts-primary   1/1     1            1            3m   carts        docker.io/keptnexamples/carts:0.11.2   app=carts-primary
carts           1/1     1            1            1d   carts        docker.io/keptnexamples/carts:0.11.2   app=carts

After a new pod for the primary deployment has been successfully deployed, traffic is shifted to the primary deployment and the canary deployment is scaled down:

NAME            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                 SELECTOR
carts-primary   1/1     1            1            4m   carts        docker.io/keptnexamples/carts:0.11.2   app=carts-primary
carts           0/0     0            0            1d   carts        docker.io/keptnexamples/carts:0.11.2   app=carts

Clean-up after deleting a project

When executing keptn delete project PROJECTNAME (see cli docs), we do not clean up existing deployments nor helm releases. To do so, the following manual steps are necessary:

  1. Delete all relevant helm releases:

    • Connect directly to the helm-service using kubectl exec -it svc/helm-service -n keptn sh
    • Execute the following command to verify that releases still exists using helm ls, e.g.:
    helm ls | grep sockshop
    

    Note: Take special care and double check that this command only lists the releases related to the project, and no others!

    • Delete the relevant releases using helm delete --purge, e.g.:
    helm delete --purge $(helm ls | grep sockshop | cut -f1 | tr '\n' ' ')
    
  2. Delete all relevant namespaces:

    • For each stage defined the shipyard.yaml file, execute kubectl delete namespace PROJECTNAME-STAGENAME, e.g.:
    kubectl delete namespace sockshop-dev
    kubectl delete namespace sockshop-staging
    kubectl delete namespace sockshop-production