Short Summary
Who should read this article?
- KKP Admins, Architects and Developers using the KKP Dashboard
- Anyone who wants to run large scale infrastructure on multiple clouds
What pain points are we addressing?
- Multiple dashboards can be confusing to access. In response to this challenge, KKP 2.19 allows users to access AKS, EKS, and GKE clusters directly from the KKP Dashboard.
What can you expect from this content?
- In this blog, we describe how users can add their AKS, EKS, and GKE clusters to KKP, the method by which we enabled this feature and the benefits users can expect as a direct result of this implementation.
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:
Import AKS, EKS and GKE clusters.
View the status of external Kubernetes cluster endpoints that indicate their current state.
- View external Kubernetes cluster details, cluster machine deployments and machine deployment nodes of the above mentioned external clusters.
- Manage the lifecycle of the external Kubernetes clusters: Create, Delete, Upgrade, Cluster & Node Deployments, and Scale Node Deployments.
- 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!
