- SAP Managed Tags:
What is Kyma
project "Kyma" enables you to extend applications in a cloud-native fashion using side-by-side extensibility. Mostly those extensions can be implemented using lambdas in Kyma using Javascript as the programming language.
Why do I need to use microservices?
There could be scenarios and use cases where lambdas are not the right fit for the extension logic.
- Complex domain model,
- Programming language other than Javascript
- The codebase is large. It doe not make sense to maintain it inside a Kyma lambda.
Kyma being Kubernetes native exposes the Kubernetes semantics to deploy and run microservices.
What about deployments and operations?
From the operations perspective, the next question naturally arises is about having a seamless mechanism to deploy microservices to a Kyma cluster.
GitOps
This is where GitOps comes to picture.
- Define and store all the information, Kubernetes configurations required to deploy microservices on Kyma in a version control system. (e.g. Github)
- Use automated controllers and directors to deploy changes to the Kyma cluster.
The advantages of such an approach are:
Single Source of truth
My source code repository is my source of truth.
Out-of-the-box Versioning support
All deployments and changes are versioned making it easy to audit or revert.
Deployment is Pull based
No need to manage any Kubernetes/Kyma cluster access in any CI/CD or build pipeline. The Kubernetes configurations are not pushed but pulled by a controller running in Kyma.
Fewer tools overhead
The team does not need to bother with learning a new tool to manage infrastructure.
Setting up a new cluster got easier
If required to set up a new cluster for migration, dev, staging, and other reasons, all one has to do is to set up the controller and director and point to the repository. We will see that shortly 🙂 .
Reference Open source projects
There are a few open-source projects available in the Kubernetes ecosystem that could be a good fit:
Using Flux CD with Kyma
In this blog, we will see how one can use Flux CD to achieve GitOps flow for deploying microservices in Kyma.
Installing Flux as a Helm chart in Kyma.
Prerequisites
- Kyma Namespace in which to deploy pre-created (e.g. dev in the instructions below)
- Helm CLI and certificates setup. (Only required by admin)
- FluxCtl (Only required by admin)
- kubectl
- kubeconfig pointing to Kyma cluster.
Installing Flux
The admin of the Kyma cluster will be required to install the flux controller. This is the component that will be continuously watching the source code repository and applying any changes to the Kyma cluster. Some example of these changes could be
- Updating the image for code changes in the microservice.
- Adding new properties or configurations, feature flags.
- Adding new secrets or config maps
- Other resources required to have the extension running.
Steps
Below are the steps to install Flux via Helm Charts on Kyma cluster. For other installation options, please refer to the flux installation page. I choose Helm as I find setting up the configurations easier this way.
- Add the Flux Helm repository
helm repo add fluxcd https://charts.fluxcd.io- Install the Flux operator using the helm chart. The various configuration parameters are defined in the Helm Chart home page.
helm upgrade -i dev-flux \ # dev-flux is the name of the helm chart
--set helmOperator.create=false \ # start with basic setup
--set helmOperator.createCRD=false \ # disabling helm operator
--set git.url=git@github.com:abbi-gaurav/kyma-gitops \ # specify the github repository from where flux will apply the changes
--set git.branch=master \
--set git.path=extensions \ # directory in the repository which flux will watch
--set git.pollInterval=2m \ # internal on which flux will look for new changes
--set git.readonly=true \ # instructing flux to only read from the repo
--set registry.excludeImage="*" \
--set clusterRole.create=false \ # Do not create any cluster level resources
--set syncGarbageCollection.enabled=true \ # enable clean up of resources when they are deleted from the repo. only applicable to resources created by flux
--set syncGarbageCollection.dry=false \
--namespace dev \ # flux will be deployed in dev namespace
fluxcd/flux --tls # chart name- Give the controller the read access to the Github repository to watch any changes and apply them to the Kyma cluster.
fluxctl identity --k8s-fwd-ns=flux
- In the repository, go to Settings --> Deploy Keys
- Click on Add deploy key, give it a Title,
- Paste the Flux public key and click Add key.
GitOps in Place
Once the controller is up and running and the key has been added, the Gitops flow is in place.
Now whenever a developer makes any changes to the code and pushes to the repository, the controller will pick up those changes and apply it to the Kyma cluster.
Example Repository
I have created an example repository containing extensions in various languages (Java, Scala, Go to start) as a reference to implement GitOps in Kyma. The examples by themselves are rudimentary and focus is on demonstrating the GitOps flow with such extensions.
Each example extension contains instructions for the developer flow.
- Building and pushing the docker image
- Create necessary Kubernetes configurations for exposing the extension as a Kyma API.
- To try out the examples,
- Fork the repository
- Follow instructions to install the flux and point to your forked repo.
Conclusion
Leveraging GitOps for automated deployments can make the operational flow with Kyma easier and reduce the overhead for the operations team.
It is always possible to enrich these basic examples with any other resources required for working with extensions as well as deploying Kyma event triggers. You can keep a watch on the repository as I will adding more examples and scenarios pertaining to Kyma usage!!!
3 Comments
