Cloud Native / Kubernetes / Tools / Sponsored / Contributed

A ‘No-BS’ Checklist for Kubernetes

9 Mar 2020 5:00am, by

KubeCon + CloudNativeCon sponsored this post, in anticipation of  KubeCon + CloudNativeCon EU, in Amsterdam.

If you’re new to Kubernetes and have been tasked with researching a vendor-supported platform for your enterprise, chances are you’re feeling overwhelmed. You’ll encounter a seemingly never-ending list of vendors, all promising more or less the same.

To help you navigate the space and ask vendors the right questions, we created this no-BS Kubernetes checklist. All of the “must-haves” for a future-ready Kubernetes strategy are included in the list.

Enterprise Kubernetes Must-Haves

Oleg Chunikhin
With 20 years of software architecture and development experience, Oleg, Kublr's CTO, is responsible for defining Kublr’s technology strategy and standards. Prior to joining Kublr, Oleg was chief software architect and technical partner, for EastBanc Technologies.
  • Infrastructure Management

Kubernetes can’t provision infrastructure by default, so if a node crashes, there is no way for Kubernetes to provision a new one. All Kubernetes can do is reorganize pods within available nodes. However, if there aren’t enough available infrastructure resources, Kubernetes can’t guarantee self-healing. And here’s a little dirty secret; most solutions on the market do not (yet) manage the infrastructure or they only provision it in selected environments.

  • Self-Healing Kubernetes

Nearly every platform promises self-healing. However, you need self-healing on three distinct layers: (1) infrastructure: contingent on the infrastructure management ability mentioned above; (2) Kubernetes components: this is what you’ll have to verify to check off this point; and (3) application level: provided by Kubernetes by default through self-healing pods. For truly reliable applications, you’ll need self-healing on ALL layers.

  • Multi-Cluster Support and Centralized Management

While an early Kubernetes adoption approach may include one or several static clusters, the growing scale of operations and mature DevOps practices require treating Kubernetes clusters as cattle, not pets. Most organizations must simultaneously run multiple clusters, create and destroy them as needed and enable self-service for their dev teams. If each cluster is managed separately, this scenario becomes quickly unmanageable.

  • Multi-Environment Support

As the cloud and software become more sophisticated, where you host your apps will increasingly impact system performance. According to 451 Research, more than half of all enterprises have chosen hybrid cloud and multi-cloud as their ideal IT architecture and about 63% are using two or more clouds. That’s why you need a solution that works across environments.

  • Multisite Support for Reliability and Disaster Recovery

Large enterprises don’t run their mission-critical applications in one datacenter, region, or cloud. They are distributed across different sites to ensure reliability and disaster recovery. If this is your case, your platform must support multisite deployments and be able to orchestrate automatic failover and recovery procedures across multiple sites.

  • Centralized Logging and Monitoring

Centralizing logging and monitoring is key for Ops and DevOps teams to quickly identify and fix infrastructure, Kubernetes and application issues. It provides a single integrated picture versus lots of fragmented views. Trends and correlations are easier to spot, facilitating preventive or corrective action early on. Additionally, infosec will want a centralized picture of all telemetry for security and audits.

  • Security

Kubernetes itself has strong security features but look for a provider that can connect these features to your enterprise systems. Not only should this include cluster and container security features (such as TLS, secret and certificate rotation and management, AAA and identity management, etc.), but also the ability to integrate with enterprise IdM (SAML, OIDC, LDAP) and Kubernetes’ RBAC.

  • Full Automation of Day 2 Operations

The solution should handle all management tasks on the cluster. Recovery, restore, updates, upgrades, etc. If it’s not automated, it falls to you to do it, which can quickly strain your resources and budget.

  • “Open” Open Source

A major benefit of open source is that it is open and flexible allowing users to pivot with market demands. Yet we are seeing a new breed of “opinionated open source” offerings that lock you in. While some tie you to a particular infrastructure or technology stack, others modifying the original open source technology. Though the latter may be open source, they are specific to that vendor and not supported by the community. Make sure your platform doesn’t tie you to a specific technology stack or infrastructure, compromising your agility.

  • Configurability

While the whole idea about leveraging a vendor-supported Kubernetes platform is that everything is pre-configured, you will need the ability to override parameters once you venture into more advanced use cases. Because Kubernetes is a complex multicomponent system, configuration flexibility may vary, for example, data science cluster configuration will differ from that for stateless apps or microservices. There simply is no one size fits all. Make sure that you have access to master and worker node component configuration, including switches, resource requests and limits, OS-level configuration, etc.

  • Command-line and API

Once your Kubernetes and container related use cases mature, some team members will prefer to work via command line (CLI). CLI and API enable complex automation and integration scenarios, including your Kubernetes clusters operations into your CI/CD pipelines, scaling, balancing, failover and recovery scenarios, etc.

  • Intelligent Monitoring and Alerts

Kubernetes and containerized applications generate a mass of raw data that you must translate to understand what’s going on with your cluster. Early detection and intervention are essential to preventing disasters. If you can’t decipher what Kubernetes is telling you, you have a problem. By incorporating automated intelligent monitoring and alerts, that don’t flood you with unimportant details, you’ll benefit from key information on status, errors, events and warnings so that your team has the insight it needs to take action.

  • Support for Multiple Kubernetes Versions

Any meaningful Kubernetes deployment in an enterprise will contain multiple clusters and environments, whether it is dev, prod, staging, QA environments, or environments and clusters used by different departments and groups within the organization or different applications. It is not feasible to expect all of them to maintain the same configuration and patch/Kubernetes version level, so an enterprise Kubernetes solution must be able to support multiple Kubernetes versions and configurations simultaneously.

  • Support for Kubernetes Upgrades and Updates

A Kubernetes platform is composed of an entire stack. Kubernetes alone has four major releases per year. Other projects have their own releases. How are updates and upgrades handled? And what about downtime? Note that while some vendors claim to support upgrades, if you dig deeper, you’ll find that they require, sometimes significant, downtime to allow for cluster re-initialization.

  • 24/7 Support

Finally, as your organization begins to acquire Kubernetes skills, it’s important to have a vendor that can provide 24/7 support and training to ensure your Kubernetes journey is a smooth one.

Nice-to-Haves

  • User-Friendly UI for Beginners

User-friendly UI is especially beneficial for enterprises new to Kubernetes. They simplify much of the deployment by offering convenient dropdown menus that make it nearly impossible to create a faulty cluster. This will allow your organization to adopt Kubernetes quickly while you start building your internal expertise.

  • Integrations with Kubernetes “Essentials”

There are a number of components that aren’t part of Kubernetes but are essential for Kubernetes users to achieve any meaningful goals. These include components and frameworks like container overlay network providers, ingress controllers, Kubernetes autoscaler, cloud native storage systems, persistent volume provisioners for different types of volumes, GPU integration, etc.

Clearly, there are multiple aspects enterprises need to consider when migrating to a Kubernetes-based future-ready architecture. Unfortunately, not all enterprises fully understand their requirements when researching their options. That isn’t really surprising if you consider how new Kubernetes and cloud native is for most.

Whether you select Kublr’s enterprise-grade platform or some other alternative, we hope that this list will help you navigate the ecosystem and find the right platform for your needs.

To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon EU, in Amsterdam.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.