The post Swarm to Kubernetes workload migration appeared first on Mirantis | Pure Play Open Cloud.
For customers, making the choice to migrate from a production Swarm cluster to a production Kubernetes cluster is not an easy decision. Many factors go into such a decision, such as wanting to take advantage of advanced scheduling capabilities or the growing Kubernetes ecosystem. While we continue to support Swarm, for those customers who have made the decision to embrace Kubernetes, we have good news: Mirantis is committed to freedom of choice for container orchestrators and has developed a suite of process, professional services, and automated tooling to make this migration as automated and painless as possible.
Because Kubernetes is very flexible (and hence complex), customers should be wary of going it alone. Mirantis has unique expertise to ensure our customers enjoy a fast and successful migration of production workloads from Swarm to Kubernetes. We have worked with customers for over 5 years on Swarm workloads and over 2 years on Kubernetes workloads and we understand the real world challenges and solutions of running at production scale. We will be announcing our Migration Package in April, but we wanted to take a moment to highlight some of the issues involved and the areas of concern you need to keep in mind.
Why moving from Swarm to Kubernetes is complicated
In some ways, Swarm and Kubernetes have a lot in common. They both orchestrate containers. They both provide ways to manage resources such as storage, networking, and ingress, all via YAML files.
Unfortunately, in many ways that’s where the similarities end.
For example, Swarm is simple and very easy for a newcomer to successfully deploy containers, whereas Kubernetes can have a steep learning curve and may be overkill for certain scenarios. Kubernetes lends itself to very large, complex infrastructures where Swarm may not be a perfect fit. Swarm YAML (Docker Compose) is built around services for applications, whereas Kubernetes YAML is built around pods and other deployment artifacts.
Some of these problems can be resolved through the use of automated tooling, and we are creating all of the processes and automated tooling needed to eliminate (or at least minimize) any production impact. We will also be taking this opportunity to automate the clean up of any Compose files to make sure the new YAML files are meeting best practice standards.
In order to perform a successful migration, we consider dozens of different aspects of your existing deployment. They fall into a number of different areas, such as:
Architecture, configuration, and scale: Obviously, the larger and more complex your current infrastructure, the more complex the migration. Part of our process involves not just ensuring that we’ve duplicated the application and infrastructure environment, but that configuration is managed in a testable, auditable, and repeatable way using Infrastructure as Code. We also examine not just the application, but the infrastructure that hosts it. For example, if you’re using an external storage appliance, we want to ensure that it can be used with Kubernetes, and determine whether any integration code needs to be modified.
Governance: Another area you must consider is that of governance. For trial applications this doesn’t have the same importance as for production applications, but when your business depends on your cluster remaining up, stable, and secure, having a handle on governance issues is crucial. For example, we would want to examine the ways in which you are capturing logs for Swarm workloads. Are you redirecting logs to a 3rd party provider? Will those logs be available in your Kubernetes cluster? We will determine whether you need to re-architect monitoring policies and procedures.
Identity: One area where Swarm and Kubernetes differ is in their handling of identity.
UCP contains its own role-based access control (RBAC) system for ensuring that the proper user has the proper access to the proper Swarm resources, but this RBAC system is independent of the native Kubernetes RBAC also deployed to the cluster. As a result, transitioning from Swarm to Kubernetes mapping between these disparate RBAC systems. We spend time identifying both out of the box and custom roles, then take care of the re-creation and mapping of those roles and the assignment of roles to various individuals and service accounts. Other complications we’ve seen at clients include custom UCP Roles, such as specific restricted role for CI/CD, which need to be redefined in Kubernetes?
Networking and storage: Another place Swarm and Kubernetes differ is in how they handle networks. Swarm has the concept of application isolation via network partitions, but Kubernetes comes with a flat network. If the application needs to be isolated based on network, then we will need to create additional Kubernetes network policies to implement that. If you have deployed a Layer 7 ingress solution to the existing cluster, we will need to ensure that it’ll work with Kubernetes, and if not, we will help you rethink or replace it. Similarly, storage, being hardware-dependent, can be an issue. For example, which Docker Volume driver(s) are you using to provide persistent storage? Do appropriate Kubernetes CSI drivers exist for the storage you’re using? These are all questions we’ve encountered during multiple engagements.
Customer-specific integration and applications: The final thing we think about when transitioning a customer from Swarm to Kubernetes is all of the aspects of their cloud that are specific to their situation and applications. For example, what CI/CD tools are you using, and how will that pipeline be impacted by switching to Kubernetes? Are you using a CI/CD pipeline to build, scan, sign and deploy your applications? Which one? Can you integrate that pipeline into Kubernetes using a solution such as Docker Trusted Registry? To ensure a successful transition, we must take all of that into consideration.
These are just a few of the dozens of things we think about when doing the careful work of planning the migration of your production workloads.
It’s a lot to think about — but you’re not alone
Migrating production workloads from Swarm to Kubernetes can be complicated and when we’re talking about the production applications on which your business depends, you need to tread carefully. Mirantis is the recognized leader in container orchestration and we’re working to bring you a comprehensive Professional Services Swarm to Kubernetes Migration package that will ensure your transition is successful.
At Mirantis, we are committed to ensuring freedom of choice for the orchestrator that’s right for you, and whether you choose Swarm or Kubernetes, we want you to have the best possible experience.
If you’re thinking about moving orchestrators from Swarm to Kubernetes, please look for our upcoming announcements.
The post Swarm to Kubernetes workload migration appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis
Published by