Not much has changed about end users’ hybrid and multi-cloud strategy in 10 years. Now that Kubernetes is everywhere—GKE, EKS, OKE, AKS, DIY, Konvoy—it is time to expand upon the staid approach by deploying a distribution on top of and Day-2-ify-ing those existing Kubernetes clusters.
May 14, 2020
Chris Gaun
D2iQ
May 14, 2020
Max Werner
D2iQ
4 min read
Not much has changed about end users’ hybrid and multi-cloud strategy in 10 years. Now that Kubernetes is everywhere—GKE, EKS, OKE, AKS, DIY, Konvoy—it is time to expand upon the staid approach by deploying a distribution on top of and Day-2-ify-ing those existing Kubernetes clusters.
Despite vast enhancements in cloud technology, little has changed in hybrid and multi-cloud strategy for a decade. While Kubernetes has made implementation easier, the basic goal is the same as ever: deliver identical infrastructure management across on-prem and public clouds. It is time for this strategy to evolve by deploying the distribution that is needed for Day 2 operations to the existing Kubernetes implementations that now exist everywhere, thanks to GKE, EKS, AKS, DIY K8s, Konvoy and others. Users have many, and expanding, Day 2 needs —like wanting to use Thanos and Grafana to monitor all their clusters—that could be easily solved with the fact that Kubernetes is everywhere.
At the same time Kubernetes has made setting up the same infrastructure on AWS, Google, Azure and on prem easier, the cloud vendors have begun providing Kubernetes services that make managing the cluster lifecycle breezy. Given this state, where the same Kubernetes API is readily available from public cloud services and software like Konvoy whether on prem or in the cloud, it is strange that hybrid and multi-cloud strategy has largely gone untouched. Given we now have the same Kubernetes API everywhere—EKS, GKE, AKS OKE, etc., why don’t we start thinking about delivering the same operational experience in terms of monitoring, workload configuration and the like on those clusters?
Federating Your Distribution With Kommander
The Kommander product strategy has always assumed that users will sometimes have existing Kubernetes clusters or have already decided on a particular vendor/provider. Kommander still delivers value to those customers. One way we planned to do that before even the first line of code was committed on any of our products was to take the Day 2 Kubernetes-based addons from Konvoy and federate them out to 3rd party clusters, making those clusters Konvoy-like and giving users the same operational view in Kommander no matter which managed cluster lies beneath. Over time, D2iQ will continue to expand our roster of Day 2 addons and give operators more consistent capabilities on all their clusters.
The Konvoy Kubernetes distribution itself was architected to treat lifecycle concerns of Kubernetes completely separately from the other features one would expect in a distribution—monitoring, logging, UI, etc. We wanted the value of the distribution above Kubernetes to come from the fact it is opinionated, pre-configured, patched and up to date, scanned for security vulnerabilities, bolstered with other D2iQ Kubernetes products (like Dispatch for CI/CD), and is tested in real world scenarios, including at scale. The guiding idea is that the only dependency would be on a Kubernetes version and not on anything specific to Konvoy or D2iQ.
With the latest version of Kommander, 1.1, we can now federate out these Day 2 addons. We started with single sign on and monitoring. You can see a demo of monitoring below:
What’s Next
Ultimately, we are working on backend by our next generally available release to make it very easy for D2iQ to expand what gets federated out to 3rd party clusters. We also want to give users the choice to federate some stacks (e.g., monitoring) and not others (e.g., logging) in case some users have pre-existing solutions, like Splunk, already in place. When Day-2-ifying these clusters and making them Konvoy-like, we want to give users the same experience of having an opinionated, pre-configured, patched and up- to-date, scanned for security vulnerabilities, and tested in real world scenarios—including at scale —stack, but like Konvoy, also allow them the freedom to choose the tools and solutions that fit their organization.
Getting Started
First, you need to get a copy of the newest version of Kommander. If you are an existing customer, you can download Kommander in the Support Portal. If you are not an existing customer, you can contact us.
Once you have obtained your copy of the software, follow the instructions to deploy Kommander found here.
Attach a GKE cluster as demonstrated in this video
Kommander will attach that cluster employing the Open Source Kubernetes Cluster Federation, aka kubefed. Kubefed allows operators to manage a fleet of clusters from a central command center, federating resources such as Deployments, CRDs or roles as explained in a previous blog.
At D2iQ, we have built kubeaddons, which is a lightweight wrapper around Helm charts and KUDO operators, that allows you to install charts or operators in a declarative way, just as you would do with a Deployment. D2iQ’s kubeaddons provides a CRD to specify an Addon and reference the accompanying Helm chart or KUDO operator.
Using this declarative application deployment facility together with kubefed, Kommander currently federates Addons for monitoring, logging and SSO to each attached cluster, rendering it production-ready within minutes.
