Most enterprises already have a reliable logging and monitoring system in place, so why should you worry about it in the context of Kubernetes? Well, traditional logging and monitoring tools are designed for stable infrastructure and application deployments. Cloud native environments, on the other hand, are highly dynamic. The IT world has changed and so must your toolkit.

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.