Why Those Gaps in Kubernetes Are Really a Good Thing
Diamanti sponsored this post.
Kubernetes allows users to choose from an open ecosystem of application management and infrastructure options and under the stewardship of the Cloud Native Computing Foundation (CNCF), Kubernetes has become the new Linux.
One of the reasons Kubernetes has become the de facto choice for container orchestration is because of what it does not offer.
Why?
In order to support a variety of use cases, early Kubernetes developers added intentional gaps to the platform in order to offer flexibility to its users. Rather than being a do-it-all platform, Kubernetes is designed to be an extensible platform that users and vendors can tailor their environments easily with custom resources definitions (CRDs), the Container Storage Interface (CSI) and the Container Networking Interface (CNI) based on their own requirements. The intentional gaps in Kubernetes offer flexibility in both infrastructure and application layers.
Building Blocks of the Cloud Native Environment.
Let’s explore these intentional gaps, the decisions that are left to the user and some key considerations in making the right decision.
Intentional Gaps for Cloud Native Infrastructure
Infrastructure
Today, there are many infrastructure choices to run Kubernetes. It can be run on premises or in public clouds. It can also be run on virtual machines or on bare metal servers. There is no “one size fits all” model. Users thus need to make conscious decisions based on their own feature, performance, efficiency and cost requirements. However, a wrong decision can lead to a significant negative impact on project outcomes and customer experience.
Storage
Just like infrastructure, choosing a storage solution can also be a daunting task for Kubernetes users. Even with the tremendous advancement in storage over the years, most users are still struggling with the I/O bottleneck. With Kubernetes becoming a standard for both stateless and stateful applications, it is important for users to select a storage system that provides modern data services, such as disaster recovery (DR) and high availability (HA) with the highest throughput and the lowest latency.
Networking
Networking is a basic requirement for any cloud native application. Kubernetes organically manages cluster networking, but exposing the application to the outside world and scaling or interconnecting applications securely are some of the biggest challenges for Kubernetes users. Users thus need to think about network topology, security, latency and throughput requirements when selecting a networking solution.
Resource Utilization
Kubernetes addresses the noisy neighbor problem at the CPU and memory levels but shared storage and networking are still vulnerable to applications that hog system resources. To prevent this, Kubernetes users end up overprovisioning the infrastructure which defeats the sole purpose of hardware or software virtualization. Users will need to implement measures that can avoid the noisy neighbor problem and maximize resource utilization.
Intentional Gaps for Cloud Native Application Management
User and Cluster Management
Since Kubernetes is infrastructure agnostic, it only provides basic cluster and user management. Most enterprises require more robust capabilities than what is available out-of-the-box, including things like Active Directory integration and user and event tracking and logging.
Advanced Customization Options
While Kubernetes is designed for container orchestration and management, it also includes many advanced options for further customization, including areas such as enhanced security and configuration controls. Like Linux, these options are available for those who are familiar with them but are not necessarily intuitive to new users. Users who are used to working with the traditional approach (of handling infrastructure and application management) may be bogged down by the complexity and intricacies of Kubernetes. The users are then left deciding which of these advanced options are important.
Application Lifecycle Management (ALM)
Kubernetes orchestrates containers but not applications. A developer usually cares more about application lifecycle management and not about managing individual containers. ALM components such as upgrading the application become complex with Kubernetes. Users need to take this into consideration.
Multicluster management
With the rapid adoption of Kubernetes, organizations prefer multiple Kubernetes clusters (for development, testing, production, etc.) to one for simplicity and isolation. However, this introduces the complexity of managing multiple clusters from a single pane of glass. There is also an added complexity of moving an application and its data across different (or same) cloud providers, across different data centers and across different regions.
Improvements by the Kubernetes Community
Under the stewardship of the CNCF, the Kubernetes community has been actively evolving and improving the core capabilities of the platform through standardized interfaces and frameworks. These efforts have enabled vendors and other contributors in the ecosystem to fill in some of the above-mentioned gaps.
The Operator Framework
Operators are purpose-built controllers for the lifecycle management of specific Kubernetes applications, with built-in operational knowledge. The Kubernetes community developed this framework to provide automation, standardization, ease of use and flexibility for application management. Some examples of operators are the database operators released by various vendors such as Microsoft SQL Server, MongoDB and Crunchy PostgreSQL. With a database operator, it is possible to create, destroy, clone, scale or shard databases in a fully automated fashion. In addition, operators provide critical capabilities required to run databases in production such as high availability (HA), replication, load balancing, failover and snapshots.
CSI and CNI
During the early years of Kubernetes, there was no support for storage integration into Kubernetes. Diamanti contributed a storage plugin called “FlexVolume” which paved the path for integrating storage into Kubernetes. The FlexVolume plugin enabled stateful applications to be run on Kubernetes. FlexVolume later evolved into the CSI, which is fully supported in Kubernetes 1.13 and later. Similarly, the Kubernetes community developed the CNI plugin which allows users to integrate Kubernetes with a preferred networking solution.
These standard interfaces help to extend Kubernetes with third-party solutions. However, this comes with the additional challenge of choosing the right vendor or solution to address the storage and networking needs.
Filling in the Gaps
As mentioned above, Kubernetes has many intentional gaps that give it the flexibility to run on any platform. It is the responsibility of service providers and infrastructure providers to fill those gaps.
Every public cloud provider offers a Kubernetes service with the intentional gaps filled by integrations to their particular compute, storage and networking infrastructure. However, public clouds are designed to be homogeneous resources. This means production applications suffer from noisy neighbors which force users to overprovision the infrastructure, resulting in increased costs.
-
A reference architecture for a Kubernetes ecosystem.
Alternatively, running Kubernetes on on-premises infrastructure is not always easy. Deploying Kubernetes using a DIY approach comes with the problem of selecting and managing the many different moving pieces together such as CSI, CNI, hardware, operating system, security, identity and user management. Over the last year, many vendors have started offering CNCF certified Kubernetes distributions. However, having a fully integrated Kubernetes platform addressing all the intentional gaps is very critical.
Diamanti Hyperconverged Infrastructure for Kubernetes.
An alternative to DIY Kubernetes is leveraging a modern hyperconverged infrastructure (HCI) approach which fills these gaps. Diamanti is a pioneer in this arena, offering a fully integrated compute, storage, networking and security solution that also takes care of cluster management, identity and user management, monitoring and hybrid cloud management. This enables developers and operators to focus on application development and deployment. Additionally, the Diamanti platform completely eliminates the noisy neighbor problem with its unique IO management solution, delivering unprecedented application performance.
Conclusion
Kubernetes is clearly the best platform for container orchestration and is designed to run in any environment. However, the principles based on which Kubernetes is built also makes it challenging to get it up and running out-of-the-box. The resulting challenge is there are many intentionally added gaps in Kubernetes left for the community and vendors to solve.
When adopting Kubernetes in an organization, it is thus important to consider how to minimize the required time, effort and cost with infrastructure and application management that can meet a holistic set of requirements. An integrated approach is one way to deliver faster time-to-value while ensuring all these gaps are filled.
Feature image from Pixabay.
