Migrating Legacy Apps to Kubernetes with GitOps
For many organizations, moving legacy applications to Kubernetes holds great promise including reduced IT overhead, and accelerated development times. But in reality, migration projects can be delayed with service interruptions while the entire team transitions.
At a recent online virtual event with Kong, Paul Curtis (@pfcurtis_NY), Weaveworks’ Principle Solutions Architect demonstrated how you can use Weave Kubernetes Platform and GitOps to make your transition from running legacy applications on Virtual Machines onto Kubernetes much simpler.
For many organizations, moving legacy applications to modern cloud infrastructure holds great promise including reduced IT overhead, and accelerated development times. But in reality, these projects can be caught up in delays and service interruptions while the entire team transitions to cloud native.
GitOps allows you to seamlessly connect the old world with the new, and modernize legacy services so they can run on modern cloud native stacks. With technologies such as Kong Mesh, a control plane for service mesh built on Kuma, and Weave Kubernetes Platform, teams can progressively move legacy applications to Kubernetes in a secure and controlled fashion.
While Kong’s API gateway and networking solutions allow engineering teams to easily access mission critical apps, deploying them to Kubernetes with the rest of your cloud native stack can be time consuming and error prone. The Kubernetes distributed system for orchestrating containers is very different architecturally from the way legacy stacks run on traditional standalone Virtual Machines. In order to take full advantage of all that Kubernetes has to offer, legacy apps will eventually need a greenfield cloud native solution.
Weaveworks customers have found a simple way to ease the transition by managing and deploying legacy stacks on Kubernetes with GitOps. In this post, we’ll discuss how GitOps works and more importantly why you would want to use it as a migration strategy for legacy applications running on virtual machines into a Kubernetes environment.
Easing the Transition From VMs to Kubernetes
GitOps is a term that was coined by the Weaveworks CEO after witnessing the Weaveworks engineering team recover within minutes from a cluster meltdown. At the time, the team were responsible for managing SaaS, Weave Cloud. Read the whole history in the post that started it all: GitOps - Operations by Pull Request.
From those early experiences with managing Kubernetes at scale, Weaveworks engineering developed these four principles to describe how GitOps works and how it differs from run of the mill infrastructure as code tools:
#1 The entire system is described declaratively
Kubernetes and its ecosystem of cloud native tools, including Kong’s API gateway is declarative, meaning that your system’s state can be described and also implemented through structured text. Manifests or Helm charts or even customized templates describe exactly what should be operating in a cluster.
Declarative systems differ from imperative ones that require the operator to run a command to apply an action. A declarative system provides absolute assurance that what’s been declared is what will actually be running in the cluster.
#2 The canonical desired system state is versioned (with Git)
The desired state is versioned as the single source of truth, representing the desired state of your system in Git (or any other source control system). These declarations are not scripts, but are actual descriptions of your system created in manifests or in Helm charts. For example, install this ingress controller configured in this manner and these node types with these particular Pods. Keeping all of this in Git, gives you a number of benefits such as: a full audit trail of who did what, as well as built-in security guarantees of authorship.
Note: One could easily argue that many Infrastructure as Code tools do the same thing, but GitOps takes it a few steps further than “just keeping everything in Git”, as we’ll see in points 3 and 4.
#3 Approved changes to the desired state are automatically applied to the system
With the declared state versioned in Git, the use of software agents automatically maintains that state when there is a drift. Instead of relying on a command to run your configuration from Git, software agents can do that on your behalf. In the Weave Kubernetes Platform (WKP), we use Flux to automatically make changes on any configuration drift that may have occurred.
#4 Software agents ensure correctness and alert on divergence
The final principle states that the software agents must not only be available to deploy things, but they also need to alert, when there has been a configuration drift or some other divergence, so that it can be mitigated. The agents need to be available in order to constantly reconcile what you’ve declared with what you have running in the cluster.
Reconciliation and control loop
Ensuring correctness and alerting on divergence is what makes GitOps different from infrastructure as code. GitOps constantly monitors and compares the desired state from what’s running in the cluster.
The diagram below illustrates this feedback and control loop. On the left side of this diagram is your normal CI processes for developing and containerizing applications. After the container is deposited into the Container Registry, the right side takes over and automatically deploys the change. These are the software controllers running in the cluster that notice the new image, indicating a change from the source of truth and will deploy the newly updated container.
When using GitOps to deploy changes to the cluster, developers don’t need to log into the Kubernetes, but instead, they only interact with Git. This is convenient for when you need to rollback a deployment that didn’t work out or you need to roll forward to a known good state. In essence what GitOps makes the cluster fully observable. Developers are then autonomous and free to experiment without fearing a complete cluster meltdown with a bad deployment, since they can easily back out of it and can also see who changed what through Git’s log and auditing features. All of this ultimately leads to an increase in your team’s velocity.
To see the Demo of WKP and GitOps with Kong’s API Gateway, watch the entire video.
