You’re probably familiar with the concept of packages. Every time you install a new software using the apt-get or brew commands, the CLI downloads a package that includes everything you need to install the software you want on your operating system. Kubernetes too has a system to manage packages, and it’s called Helm. But what’s included in Helm’s package and why we need it?
We helped a few B2B companies ranging from 10+ and 100+ people in size migrate their legacy deployment systems to Kubernetes. It’s possible to make the switch and do it without service interruptions. With some advance planning, you can make the changeover smooth and fairly risk-free. Here’s the process I’ve developed to make the transition easier.
As long as your development team consists of a few developers who are focused on their part of the service, you probably won’t hit the limitations mentioned below. Most of the time, these problems manifest themselves in bigger teams. But as your team grows and the development processes become complicated, here are a few things you’ll begin to notice:
If you’re planning to start using Kubernetes in your team, I’ve listed a few topics that seemed to be especially hard to grasp for my students. If you want to make sure your team gets the most out of a Kubernetes training, here are my recommendations for the topics that need special attention so the…
Most Kubernetes implementations don’t have the luxury of starting a new environment from scratch. We’ve been through this situation many times, so we thought it would be helpful to give you a high-level step-by-step overview of a typical migration process. Obviously your situation may differ, so plan on some level of readjustment based on our preliminary conversations.
Many Kubernetes examples you find online usually concentrate on running stateless applications. But how about running a stateful application that occasionally needs to write data on disk and make sure this data persists between container restarts or when the container is rescheduled to another node? Or running a database like MongoDB on Kubernetes?
Today, there are tools like kops that automate most of the Kubernetes provisioning tasks and can help you spin HA Kubernetes clusters on AWS. Will EKS (AWS managed Kubernetes service) dramatically reduce the time needed to migrate a company to Kubernetes?
With other Docker scheduling platforms, like ECS for example, you have no choice but to roll up your sleeves and code your way out. I’ve done that a few times. Working with AWS’ APIs is always “a pleasure”. Kubernetes, on the other hand, has a much larger ecosystem of open source addons ready to be installed. The hard part is to find the right tool for the job.