Why We Decided to Support External Kubernetes Clusters Via API

April 14, 2022

Short Summary

Introduction

Kubernetes clusters are becoming an integral part of how businesses operate. As organizations continue to grow, it becomes increasingly important to have a scalable IT infrastructure that can keep up. Multi-cluster deployments are one way to overcome this challenge.

By using the Kubermatic Kubernetes Platform (KKP), businesses can manage a multitude of clusters effectively and efficiently. Additionally, Kubernetes clusters are now being run on multiple platforms. Our goal is to make it easier for customers to monitor and manage these external clusters.

What Are External Kubernetes Clusters (AKS, EKS & GKE), and Why Do They Matter?

The 2021 CNCF survey found that the three most popular Kubernetes hosted platforms are Amazon Elastic Container Service for Kubernetes, Azure Kubernetes Services (AKS) and Azure (AKS) Engine. After several discussions, we realized that many of our customers, prospects and users already have clusters in Amazon Elastic Kubernetes Service (EKS) and in the Google Kubernetes Engine (GKE).

Our prospects and customers would like to use the Kubermatic Kubernetes Engine (KKP), but they don’t want to disrupt their existing workloads on other platforms. In order to keep track of these workloads, they would have to refer to the KKP dashboard, as well as the external dashboards. 

Flipping from one dashboard to another is counterintuitive, and defeats the whole purpose of the dashboard! So we decided to provide a solution that initially will allow our users to view, import, and manage their existing clusters on EKS, AKS, and GKE. Our users can continue to take advantage of the innovative products from these hyperscalers with the added convenience of managing the clusters within KKP directly! 

The benefits of this implementation are clear. By being able to view all of their clusters in one place, users can save time and improve efficiency. Additionally, by having a single point of contact for all cluster management tasks, users can minimize the risk of human error.

What Made Us Choose An API-First Approach?

The rise of Kubernetes as an orchestration platform meant the need for quicker and more stable methods for the deployment and development of applications. Thanks to new technologies like Edge and IoT, data needs to be exchanged between platforms ever faster.

To take full advantage of cloud architectures, monolithic applications must be reworked, first into microservices, and then as APIs that are easily managed and developed, increasing the importance of a highly manageable API infrastructure.

At its core, KKP is built around efficiency and performance. As such, API management as an essential feature that helps us leverage the inherent advantages of Kubernetes’ most powerful elements - its APIs. This enables you to create better design patterns that permit improved monitoring, enhanced workflows, and architectural designs that are sustainable, scalable, and flexible throughout the application lifecycle. 

At the heart of KKP is the principle of expanding Kubernetes capabilities. By adding the power of Kubermatic’s APIs, we’re able to deliver more predictable patterns, easier adoption and development of new features, as well as the ability to create your work API paths for your own use cases, creating a vastly superior and personalized user experience.

Managing an external Kubernetes cluster requires a minimum of 20 mCPU and 40 MB RAM. This consumption ultimately translates into a cost for the users, which is neither justified nor beneficial, and a lean implementation is therefore mandatory.

Sidecars deploy relatively quickly and are scalable. Implementing sidecars, however, means increasing the number of clusters that we need to monitor, manage, and control. It’s clear that sidecars don’t meet our needs for a long-term, scalable and manageable system.

APIs are reliable, consistent, and almost everyone has used them. Both from a development and usage perspective, this minimizes the risk of failure. Likewise, cluster detachment has no effect on managed or on managing clusters.

How to Manage Your External Kubernetes Clusters with KKP

KKP doesn‘t require any additional steps like installing external controllers or agents. We rely on provider-client, which allows us to fully manage the clusters. The user with the proper credentials can immediately start managing the native clusters in the KKP.

With KKP 2.19, users can:

  1. Import AKS, EKS and GKE clusters.

    Adding external clusters to the KKP dashboard

    Importing external clusters with Kubermatic Kubernetes Platform

  2. View the status of external Kubernetes cluster endpoints that indicate their current state.

Imported AKS Cluster

  1. View external Kubernetes cluster details, cluster machine deployments and machine deployment nodes of the above mentioned external clusters.

Events for the imported cluster

  1. Manage the lifecycle of the external Kubernetes clusters: Create, Delete, Upgrade, Cluster & Node Deployments, and Scale Node Deployments.

Upgrade the Control Plane Version on availability

  1. Edit replica count for external Kubernetes clusters.

We are really excited to release this new functionality and would love to hear what you think. Managing Kubernetes clusters can be a daunting task, but with this update, you can now control your external clusters from the dashboard, giving you more flexibility and greater ease of use when managing your installations.

If you’d like to find out how KKP can help you achieve  your business goals, get in touch with us!

Learn More

Mita Bhattacharya

Mita Bhattacharya

Product Marketing Manager