Author : John Matthews, Savitha Raghunathan , Red Hat (Platinum Sponsor, KCD Chennai 2022)
This post will introduce Crane, a tool under the Konveyor community that helps application owners migrate Kubernetes workloads, and their state between clusters.
Migrating an application between Kubernetes clusters may be more nuanced than one would imagine. In an ideal situation, this would be as simple as applying the YAML manifests to the new cluster and adjusting DNS records to redirect external traffic, yet often there is more that is needed. Below are a few of the common concerns that need to be addressed:
- YAML manifests - do we have the original YAML manifests stored in version control or accessible so we can reapply to the new cluster?
- Configuration drift - if we do have the YAML manifests, do we have confidence they are still accurate and represent the application as it’s running in the cluster? Perhaps the application has been running for a while, been modified, and we no longer have confidence we can reproduce it exactly as it’s currently running.
- State - we may need to address persisted state that has been generated inside of the cluster, either small elements of state such as generated certificates stored in a Secret, data stored in Custom Resources, or gigabytes of data in persistent volumes.
- Customizations needed for a new environment - we may be migrating across cloud vendors or environments that require transformations to the applications so they can run in the new environment.
Crane helps users do more than just handle a point in time migration of a workload, it is intended to help users adopt current best practices such as onboarding to GitOps by reconstructing redeployable YAML manifests from inspecting a running application. The project is the result of several years of experience performing large-scale production Kubernetes migrations and addressing the lessons learned.
Crane follows the Unix philosophy of building small sharply focused tools that can be assembled in powerful ways. It is designed with transparency and ease-of-diagnostics in mind. It drives migration through a pipeline of non-destructive tasks that output results to disk so the operation can be easily audited and versioned without impacting live workloads. The tasks can be run repeatedly and will output consistent results given the same inputs without side effects on the system at large.
The process uses a few tools:
- crane: The command-line tool that migrates applications to the terminal.
- crane-lib: The brains behind Crane functionality responsible for transforming resources.
- crane-plugins: Collection of plugins from the Konveyor community based on experience from performing Kube migrations.
- crane-plugin-openshift: An optional plugin specifically tailored to manage OpenShift migration workloads and an example of a repeatable best practice.
- pvc-transfer: The library that powers the Persistent Volume migration ability, shared with the VolSync project. State migration of Persistent Volumes is handled by rsync allowing storage migrations between different storage classes.
- crane-runner: A collection of resources showing how to leverage Tekton to build migration workflows with Crane
A Walkthrough Migration using Crane
Crane works by exporting the application-specific resources from one cluster, transforming the manifests to create re-deployable manifests, and applying the transformed manifests into the destination cluster. We will be using crane-runner to migrate a stateful application.
Requirements
- Linux VM with a minimum of 2vCPUs and 8GB of RAM. If using an Amazon EC2 instance, the recommended VM size is t2.large.
- Ensure the following tools are installed and available in the PATH: Podman, kubectl, minikube, kustomize, jq, yq
Stateful Guestbook App Migration
We will migrate a simple PHP Guestbook application with a Redis database that will use the underlying persistent storage. The diagram below shows the high-level operations that will be performed by Crane as a part of this migration,
Figure: Stateful App Migration using Crane
Follow this step-by-step guide to complete the migration. This example demonstrates how simple, yet powerful Crane can be and how easily it can be configured to perform complex operations with ease.
What’s Next?
- Check out more examples using crane-runner.
- Participate in Konveyor community meetings to learn more about the projects in the ecosystem.
About Konveyor:
Konveyor community is home for several open source projects that help with your Application Modernization & Migration journey. The community is actively working on expanding the tools to cater to various real world migration scenarios. If you would like to get involved with the community, reach out to us via Kubernetes slack channel. You can also subscribe to our mailing list from the Konveyor website to hear about what's happening in the community, the latest meetups, and read about new migration stories.
Acknowledgements:
Huge shout out to David Zager & Erik Nelson for contributing to this blog post with their wonderful crane-runner examples.
Authors:
John Matthews:
John Matthews has a 20+ year background in software engineering specializing in Linux systems. He's been focused primarily on Kubernetes since Kubernetes 1.6. At Red Hat, John serves in a hybrid role of technical architect and people manager for solutions related to Kubernetes Migration and Data Protection. He lives in Raleigh, NC with his wife, daughter, and a growing pack of Dobermans.
LinkedIn: https://www.linkedin.com/in/johnwmatthews/
Savitha Raghunathan:
Savitha is a Senior Software Engineer at Red Hat, working on Kubernetes/OpenShift Data Protection software solutions. She is an upstream Kubernetes contributor and passionate about mentoring individuals new to open source communities. She likes to read, travel, and crochet in her free time.
LinkedIn: https://www.linkedin.com/in/savitharaghunathan/
Top comments (0)