-
Notifications
You must be signed in to change notification settings - Fork 9
Home
Spinnaker is a multi-cloud and multi-environment Continuous Deployment tool. One of the target environment is Kubernetes(k8s) to deploy micro-services.
Deploying microservices onto K8s driven by creating object-manifest file and applying them by kubectl command. For example, if you need to create a K8s service, you would need to define the service.yaml file with required specification within. Then you would use the kubectl apply command to create the actual service within K8ds infrastructure, like the below
kubectl apply -f <app>-service.yaml
So if we have to create inter-connected object for one single application, there will be multiple manifest files like Deployment, Service, ConfigMap, StatefulSet, Namespace, NetworkPolicy, etc. Then, the number of manifest files are multiplied when there are few enviornments like dev, system-test, staging, and production environments.
Creating multiple manifest files and applying the configuration to K8s cluster with kubectl apply command for every manifest makes it cumbersome and becomes unmanageable. So a command-line tool like rpm or apt-get which will take care of installing connected objects in K8s is required. Here comes the saviour Helm.
Helm is package-manager for Kubernetes that will bundle the manifests, install and rollback connected release objects together.
Helm charts are simply the manifest files as templates and substitutable values in a values.yaml file. The files are bundled into .tar.gz and used for deployment. The tar.gz is then referred as Helm package.
Helm has two components
- Helm CLI => This is installed on Client Desktops/VMs as native OS package and is used to create Helm chart, and package.
- Tiller => This is Helm Server side component and is installed to K8s as POD. On recieving the helm install command, the tiller translates the templates yaml files into baked manifests files, then installs the application using the manifests.
With helm install <package> command, User is able to save typing number of kubectl commands, and Helm also maintains what releases are installed for future references and rollback requirements.
When it comes to using Helm charts in Spinnaker, we will use helmil CLI for crating package, Spinnaker will use the helm template command internally to convert the package into baked manifest files before deploying. Spinnaker uses kubectl interface to connect with K8s, instead of Tiller service. Technically helm list command will not show anything installed by Spinnaker, because this command populates the releases installed by Tiller.
- Helm does plain vanila deployment, and rollback to previous versions. It does not provide any advanced deployments like Canary, Blue-Green deployments. On the other hand, Spinnaker is a purpose built tool for Deployment, encompassing the advanced features of deployments like Blue-Green, Rolling update, and Canary deployment.
- Helm install command plainly instructs the Tiller deploy package. It does not report back if the deployment failed or succeeded. However, Spinnaker has the ability to continuously track the status of Deployment and report back the success/failure result. It also gives UI information about the deployment like replicas, service and infrastructure information.
The procedure is,
- Create Helm chart (
helm create <chart-name>) - Package Helm chart (
helm package <chart-name>) - Publish the chart to Binary repository (AWS S3, GCP Bucket, Jfrog Artifactory, GitHub, etc)
- Spinnaker Pipeline -- Create Pipeline (PL) -- Create PL step: Configure (GitHub Artifact - tar.gz) -- Create PL step: Bake the Helm chart (from artifact - tar.gz), with optional override values file -- Create PL step: Deploy the baked manifests into K8s
It is required that you know
- How to create Docker image for your application
- How to work with Helm charts - including Creating Helm chart package and publishing to any Binary repository.
- The docker image to be used in the K8s deployment, is already created and published into docker-hub.
- We will use GitHub repository as Helm Chart store. The chart package .tar.gz is committed into gh-page branch of the git repo. The repo also contains the chart's base yaml files.
Objective is to deploy a Helmchart package in a Github repo into a Kubernetes cluster environment.
Note: Ensure to create a Spinnaker pipeline with a suitable name. The pipeline stages below are configured under this Pipeline.
Step 1: Configuration Stage:
The pipeline does require input parameters are defined in the Configurations stage as a requirement.
1.a) We would need to define which Chart are we going to deploy into our K8s environment. Let us define it in the Configuration stage under the Expected Artifacts section.
<>
Kind: should be Github
File Path: should be the path inside the repository (not including the repository and branch information). Repository and branch information are captured in the section Automated Triggers.
Display name: You can give any name - choose a name you can relate with the repository artifact later. This will be referenced in the subsequent changes.
Ensure to select Use Default Artifact field. This is mandatory to perform manual triggers. Otherwise, the pipeline will fail before even performing any action.
Under Default Artificat section, Kind should be GitHub, Content URL should be the complete GitHub API path and Commit/Branch should capture your Git branch where the file resides.
Note: If you try to access the artifact URL via any browser, it should return Json output. In case the file is available on a branch, suffix the API url with ?ref=<branch>. An example would be https://api.github.com/repos/sagayd/helm-demo/contents/helmchart/hello-world-0.1.0.tgz?ref=gh-pages. Use this URL just for testing in a browser. Your configuration Content URL will not include branch information.
1.b) The Expected Artifact actually had just the file information. But the repository name and branch information for those Artifact is fetched from the repository mentioned in the ### Auromated Triggers section. Lets define them.
<< Automated Trigger Image>>
Type should be Git, Repo Type should be github, Organization User should be the repository owner, Project should be the reponame and Branch should be the branch containing the artifact. Artifact Contrains will include which artifacts defined in the Expected Artifact area, rely on this GitHub configuration; So choose your artifacts defined in the Expected Artifacts.
Step 2: Bake Stage:
Note: This is the actual stage that Spinnaker uses Helm render with the help of helm template command to bake (generate manifest files by replacing the variables with values). Lets configure it.
2.a). Bake Artifact
<< Bake Image Here >>
Choose the Renderer Engine to Helm2.
Name field here actually refers to the release-name of Kubernetes deployment.
Namespace is the target K8s namespace to deploy the release.
Under Template Artifact Expected Artifact should be pointed to the artifact defined in the Configuration stage Expected Artifact.
Select the Artifact account.
2.b). Produces Artifact
<< ProducesArtifact Image Here >>
The kind should be base64. The release name will be the same what you have defined in the step 2.a.
Display name: can be your choice, this will be referenced in the Deploy stage.
Step 3: Deploy Stage:
Note: This is the stage that Spinnaker uses uses the manifes files generated by helm template command /Bake Stage. Lets configure it.
<< Deploy Image Here >>
In the Basic settings, choose the target Kubernetes environment to deploy.
In Manifest section, choose the artifact base64 that you configured in the previous Bake stage Produces section.