One of the great benefits of Kubernetes is its self-healing ability. If a containerized app or an application component goes down, Kubernetes will instantly redeploy it, matching the so-called desired state. But what if a Kubernetes component or a node goes down? Kubernetes doesn’t monitor itself nor does it have access to your infrastructure. And, guess what.
As your organization gets more comfortable with Kubernetes in development, you’ll want to prepare to adopt it in production. But mastering Kubernetes in dev does not necessarily translate into mastering it in prod. There are many additional components that must be configured and fine tuned to ensure reliable, self-healing production clusters. In this blog, we’ll walk through the key elements of a Kubernetes production setup.
If you’re an advanced Kubernetes user, you’ll likely want to configure parameters for specific use cases. While with Kublr, the most flexible Kubernetes platform on the market, literally everything is customizable (except, of course, if you want to replace Kubernetes with a different container orchestrator), a lot of the customization in the previous versions was still done via command line.
Kubernetes, the de facto container orchestrator, is great and should be part of any DevOps toolkit. But, just as any other open source technology, it’s not a full-fletched ready-to-use platform. To run in prod, you’ll need multiple addtional components such as logging and monitoring or RBAC integration. Check out our interactive Kubernetes architecture presetation to learn about key Kubernetes components and those added by Kublr.
When evaluating Kubernetes providers, you’ll quickly see that they ALL support upgrades. But here’s a little dirty secret, no independent Kubernetes multi-cloud, multi-cluster platform supports rolling updates. Instead, you’ll need to deploy a different cluster and replicate your app to ensure service delivery while the original cluster is updated. That process is cumbersome and requires far too many resources.
Easying enterprise Kubernetes adoption is at the core of what we do. Today, we are thrilled to announce Kublr’s simplified and comprehensive role-based-access-control (RBAC) management via the Kublr UI.
Open-sourced by Google in 2014, Kubernetes is a container orchestrator. That means it enables users to deploy and manage apps distributed and deployed in containers. It takes care of scaling, self-healing, load-balancing, rolling updates, etc. The project is managed by the Cloud Native Computing Foundation (CNCF) along with multiple other open source projects, and you can find it here on GitHub.
The cloud native stack, also referred to as the new stack, is composed of the new cloud-independent counterparts of cloud managed services. As enterprises moved to the cloud, they started leveraging cloud managed services such as AWS’ DynamoDB or GCP’s BigQuery. Very convenient, these on-demand services significantly increased developer productivity. Being proprietary, they only work on that specific cloud, however — a significant drawback.
Committed to providing reliable and secure Kubernetes across the enterprise, Kublr 1.14. brings further improvements to the UI, operations functionalities, and introduces support for SUSE Linux Enterprise Server.
While multi-site Kubernetes orchestration has numerous benefits, all of which have the potential to translate into a significant competitive edge, it still largely remains elusive — at least in the vendor space. The reason? Well, multi-site configuration is hard and, since during the first adoption wave, the focus was mainly on one cloud (most enterprises start with simple projects), there wasn’t a real need for it.
