Simplify continuous delivery with Tanzu Mission Control

Table of Contents

• Introduction
• The workflow
• Items to prepare for workflow
• The configuration
  • Add Git Repository
  • Git Credential
  • Add Kustomization
• Verify deployed application
• Configure policies for workload
• Summary

Introduction

Tanzu Mission Control (TMC) is a centralized management platform to create, operate and secure the managed Kubernetes cluster. TMC also provides a stable and simplified workflow to perform Continuous Delivery (CD) for cloud-native apps deployed on kubernetes cluster managed by TMC. Following GitOps, the entire DevSecOps pipeline can be built with handing over the CD responsibility to TMC. The application which is ready to deploy can connect it's config as kubernetes resources with kustomization or via Helm charts to TMC and configure the workflow. In this session, we would go through simple process to setup continuous delivery for a cloud-native application.

The workflow

1. Configure Git repository with app deploy resources with kustomization configs in Tanzu Mission Control
2. The continuous delivery extension in the managed Kubernetes cluster creates CRDs for Git repository and kustomization
3. Flux controllers configured by TMC would sync Git repository to the Kubernetes cluster

More information about continuous delivery using Flux, visit https://fluxcd.io/docs/.

The entire workflow can be modelled as below :

Brief about all the policy types for workloads can be found here.

Items to prepare for workflow

1. Application image to deploy in Kubernetes
2. Application deploy resources in Git repository.
3. Kustomization resource as template and for manipulating app deploy resources.
4. Kubernetes cluster configured to be managed by Tanzu Mission Control

NOTE

Application deploy resources can be maintained along side source code in folder or separate app deploy resource project. These resources can be managed by Operations team.

Helloappjava app which is used for this workflow is available at https://github.com/rajks24/helloappjava.git

The configuration

Add Git Repository

To start the process, need to add the App Git repository with the artifacts along with kustomization.

This option can be found as an add-on for the managed kubernetes cluster.

We can configure the git repository with fields :

• Repository Name
• Repository URL ( with the app artifacts)
• Repository credentials ( ⚠️ It needs to be configured before adding git repository.)

Under the advanced options, we can configure :

• Git Branch - When branch is given, then that branch from the git repository will be checked out. If no branch is given, the "master" branch will be used.
• Git Tag - When a tag is given, that tag from the git repository will be checked out. If both tag and branch are given, tag overrides branch and the branch value will be ignored.
• Semver - When semver is given, then the latest tag matching that semver will be checked out from the git repository. If semver is given, tag and branch will be ignored if they are populated.
• Commit - When the commit is given, then that commit is checked out from the git repository
• Sync Interval - (Default : 5 Min) This is the interval at which Tanzu Mission Control will attempt to reconcile changes in the repository to the cluster. A sync interval of 0 would result in no future syncs.
• Git Implementation ( Default : GO_GIT, another option to choose - LIBGIT2)

Git Credential

If the Git repository requires authentication, we need to register the credential before adding git repository. We can use the Git Credential to setup the app git repo with credential.

Add Kustomization

Once the Git repository is added, we can go ahead and locate the app kubernetes artifacts along with kustomization in the git project. We can specify the specific Git Repo folder to sync the artifacts.

$ tree kubernetes
kubernetes
|-- deployment.yaml
|-- ingress.yaml
|-- kustomization.yaml
`-- service.yaml

My Kustomization resource is specified as below :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
- ingress.yaml
images:
- name: helloappjava
  newName: ghcr.io/rajks24/helloappjava
  newTag: 1.1.0
 

Also, can specify the Namespace to sync the resources.

Once the kustomization is added, the sync process starts and TMC starts pulling the resources from Git Repository and deploy to Kubernetes cluster using FluxCD. We can get the ReconciliationSucceeded status for process completion.

Verify deployed application

We can verify the deployment within the specified target namespace.

Also, we can get the deployed resources in the workload section, to verify the state and the deployed yaml resources.

We can verify that the deployed app is labeled for fluxCD.

metadata:
  labels:
    app: helloappjava
    kustomize.toolkit.fluxcd.io/name: helloappjava-kustomize
    kustomize.toolkit.fluxcd.io/namespace: tanzu-continuousdelivery-resources
  annotations:
    deployment.kubernetes.io/revision: "1"

TMC with help of FluxCD would track the app artifacts in Git repository for any change, and resync would be triggered for any git revision to reconcile the deployment in Kubernetes cluster.

Configure policies for workload

TMC is packed with various OPA policy templates which can be used to configure secure and managed delivery for workloads.

Next Step: configure policies for workloads

The next step is to configure policies for workloads

• Security policy defines a set of conditions that a pod must run with in order to be accepted into the system.
• Image registry policies allow administrators to specify the image registries that developers can use in workspaces.
• Network policies allow administrators to specify default network rules on workspaces.
• Namespace quota policy defines a set of constraints that limit aggregate resource consumption per namespace.
• Custom policies allow us to implement policies based on custom policy templates that we define to fit the needs of our organization's Kubernetes objectives.
• Use a mutation policy to modify the properties of Kubernetes resources during admission.

With above points, we can get the required policies covered.

Workspaces in TMC are used to manage access, policies and resources for group of workloads in same or across kubernetes cluster.

Summary

This workflow helps us to build a robust continuous delivery for production ready cloud-native workloads. I hope this blog would help users to understand and get desired outcomes.

🙂 Thank You!