What is Kubernetes Support
Although you can download, install, and use Kubernetes for free, there are times when you are going to need professional support
Once you’ve gotten past the issue of what Kubernetes is and how it works, it’s time to start planning for your future. When and how support enters into the equation depends on where you are in your Kubernetes journey, and where you need to go.
Why do I need Kubernetes support?
Kubernetes support can help you figure out what kinds of Kubernetes clusters you need. Most users leverage Kubernetes for application development. And that, in turn, typically means they need several different kinds of Kubernetes clusters: small clusters (maybe even ‘desktop’ clusters) for individual developers; test clusters for running automated tests on applications, integrations, configurations, lifecycle management tooling, operators and other assets; perhaps staging clusters to evaluate applications in “production-like” environments; and of course, actual scaled-out production clusters: sometimes more than one of these, if you have ambitions to do blue/green deployments or explore similar accelerated release delivery strategies.
Kubernetes support can help you design these cluster types. So you need architectures for all these clusters (which should ideally be self-similar to one another, because building on Brand X, testing on Brand Y, and going to production on Brand Z is a formula for trouble, redundant work, and increased risk). And then you need code and processes for building and delivering and observing and maintaining and scaling and updating all these cluster models dynamically, because development and operations teams grow, and needs change, and projects evolve, and you want to utilize resources efficiently. If you do blue/green deployments, for example, you’ll need to clone your entire production environment, every time you do a release. And nowadays, that could be daily.
Kubernetes support can help you engineer and automate application development processes. You also need to figure out the specifics of your application development process (how you build containers, automate tests, scan and store and secure container images, Helm charts, and other stuff, etc.) and then automate it, using version control, CI/CD, registry, security and other tools, so you can get new features to your customers, quickly and safely. Exactly what you build and how depends very much on projects and priorities. An organization tasked with updating lots of legacy web applications to run in containers may need somewhat different tooling than an organization that’s building complex microservices applications from scratch. Many organizations need to build several software development supply chains, and run them in parallel.
Kubernetes support can help you learn to run all this efficiently, or even run it for you. Once all your systems are designed and built, the ongoing (so-called “Day 2”) job is learning how to operate them efficiently. A mature Kubernetes support organization can help train your folks, and can provide local and remote technical and operational support through each phase of your build-out. Some support organizations can even operate your infrastructure remotely: monitoring for issues, fixing things transparently, organizing to enable regular updates.
Kubernetes support can help you do your most important work. Mature Kubernetes support organizations may also be able to provide a range of professional services to help you get big jobs done with this new infrastructure. For example, some organizations are confronted with the need to update dozens or hundreds of self-similar web apps to run in containers. This kind of work, sometimes called a “brownfield” project, can often be accomplished much more quickly with professional services on hand to do some (or all) of the heavy lifting. In other cases, organizations need help architecting complex, innovative, cloud native solutions. Professional service teams can help with this kind of task (often called a “greenfield” project) as well.
What are Kubernetes support tiers?
Clearly, “one size fits all” is a bad model for Kubernetes support. Some organizations are more ready than others to shoulder parts of the burden of designing and automating around Kubernetes and modern software development and operations. So support organizations generally ‘tier’ their services appropriately for different project phases and customize them to meet specific customer requirements. For example, here at Mirantis, we have four basic support packages:
These packages aim to deliver “just right” support for customers through the phases of a typical cloud journey, which starts by building small “proof of concept” implementations of clusters and development processes, before moving on to create a mature production environment. A top tier of support is also available for customers who don’t want to operate their own production infrastructures, and want things to just work. To learn more, please visit our support page.
Who supports Kubernetes? Can’t I just use the Kubernetes community for support?
Kubernetes itself is administered by the Cloud Native Computing Foundation (CNCF) and the CNCF interactive community matrix shows more than 190 different companies that are certified to provide Kubernetes services. When choosing a Kubernetes support provider, here are some things to think about:
Expertise: How much experience does the provider have in Kubernetes support? Are they a single individual freelancing on the side, or a team of many experts with diverse skillsets that can be called upon depending on the problem? How well does the provider know not just Kubernetes, but the specific environment in which you will be running it? For example, if you will be running Kubernetes on top of OpenStack, you will want to choose a provider that has experience in both technologies.
Distribution: You’ll want to choose a provider who has experience not just with Kubernetes itself, but also with the distribution of Kubernetes you’re using. If you’re using a vendor distribution such as Mirantis Kubernetes Engine, that will usually — but not always — mean the distribution vendor will be best suited to serve you.
Availability: If your application is in production is someone available to help you if something goes down at 3am? If you’re not in production, does the vendor have experts available during your working hours? Can you reach someone by phone, or do you have to send an email or ticket and cross your fingers until they get back to you?
Escalation: Anyone who’s been responsible for a production system knows that heart-stopping moment when you realize that something has gone terribly, horribly, wrong. When it does — and it will — are there experts who can jump in immediately to remedy the situation?
Third party coordination: Cloud native infrastructures involve many different vendors and service providers. It’s easy to get caught up in whether the problem is in your network or operating system or the application itself. You want a vendor who will take responsibility for this coordination, rather than simply telling you, “Sorry, talk to your cloud provider.”
Because using the software itself is free, there’s another option that companies sometimes consider: using the Kubernetes community itself for support. While this seems tempting, it’s not actually practical, especially for production environments.
The Kubernetes community is filled with extremely knowledgeable practitioners, many of whom work for the same companies that contribute to and support Kubernetes, and often, posting a question in the community Slack channel or on StackOverflow will bring you a number of opinions. However, there’s no guarantee you will get an answer quickly — or at all — and none of those people are committed to seeing your issue through to resolution.
When your company’s work is at a standstill because of a problem, you need, as the saying goes, “one throat to choke.”
Mirantis has been providing open source support for more than a decade. Contact us and see what we can do to make your life easier.
Is Kubernetes dropping
Docker support?
Yes and no. Technically speaking, Kubernetes didn’t actually support Docker containers in the first place. Instead, it supports containers based on containerD, the engine inside of Docker containers. Docker support was provided by a component called Dockershim, which provided a translation between the containerD instruction set and the Docker instruction set. It is Dockershim that is being deprecated in Kubernetes 1.23.
For most users, this will be a non-issue; they’re not really using Docker anyway. For those who are, however, Dockershim will still be available, but not “out of the box.” Mirantis and Docker will continue to support and develop Dockershim as a separate package you can add to Kubernetes for Docker container support.
