gjp311 - stock.adobe.com
There's no shortage of ways to run Kubernetes on the cloud, but it is a challenge to determine the best approach for your organization.
Kubernetes gained traction as developers sought to simplify the orchestration of Docker containers. It also introduced a whole other set of management complexities, which is why vendors flooded the market with managed Kubernetes services. As a result, IT shops are left to sort through the intricacies of these services themselves to find the right fit.
Review these top tips to make sense of what AWS, Google and Microsoft offer for managed Kubernetes services and to see if you're better off with a cloud-agnostic architecture.
Pros and cons of vendor-specific managed Kubernetes
Before you create a checklist and run an apples-to-apples comparison between the cloud-based offerings, you should determine whether you even need one of their managed Kubernetes services. These products provide consistency and solid availability and easily link to other native services on their respective clouds. But they're often a poor choice for organizations that plan to have applications that span multiple clouds or sync with their private data centers.
First, map out your deployment, and determine all the environments you plan to use to host your workloads. You may be a good candidate for one of these cloud-specific services if you plan to stick to one platform or if you have a static model that clearly separates workloads by environment. Those with a dynamic setup can still use a managed Kubernetes service, but they're better off with a cloud-agnostic framework that can work on AWS, Microsoft Azure and Google Cloud Platform.
Kubernetes and multi-cloud
Application portability is one of the key benefits of containers and Kubernetes. But cloud-specific Kubernetes managed services impair those capabilities because they each have their own configurations and interfaces. However, there are workarounds.
An organization can use a federated approach to sync workloads across clouds and enable clusters to share back-end services. This requires the same configuration, regardless of where the containers are hosted, and can be achieved with tools such as Kubefed and Kubernetes Anywhere. An IT team will need more time and expertise with this approach, but it may be worth it for companies that are deeply concerned about vendor lock-in.
Platform9 and StackPointCloud are examples of Kubernetes managers that can work across clouds, and there are several PaaS services, including Cloud Foundry and OpenShift, that have Kubernetes baked into them and integrate with all the major cloud providers or run on premises.
AWS vs. Azure
For those that opt for the vendor-specific approach, you'll need to pick a platform. The easiest choice is to stick with the cloud you're already on, but that might not be the best choice. Let's start with a comparison of what's available from AWS and Azure -- the two biggest cloud vendors on the market.
Azure Kubernetes Service (AKS) has autoscaling limitations and won't automatically install the latest Kubernetes version. However, its command structure makes it easy to do those tasks manually. AWS was the last of the major cloud providers to roll out a managed Kubernetes service, and it still maintains Amazon Elastic Container Service, which relies on a proprietary orchestration layer. Amazon Elastic Container Service for Kubernetes does have notable design differences from AKS, including added resiliency through automatic scheduler and control distributions across availability zones.
Even though these are managed services, IT teams still need to understand some Kubernetes fundamentals. For example, AKS users have to select either Basic or Advanced networking, and the wrong choice could result in higher bills and decreased performance.
Basic networking on AKS is easier to use and relies on the kubenet plugin to manage the container network interface. However, users have no control over the network configuration for their clusters with this option, which means they can't use it with Azure virtual networks (VNets). Conversely, Advanced networking does support VNets, which enables communications among Kubernetes pods within a cluster or other compute nodes within the same private network.
Users must also be mindful of how they configure customer monitoring, logging and access controls.
Google Cloud container choices
There would be no Kubernetes without Google, which open sourced the software that was based on its own internal technology. Google was also the first to offer a managed Kubernetes service when it added Google Kubernetes Engine. It supports cluster management through Google Cloud Console, Google Cloud Shell, kubectl and Cloud Tools for PowerShell. There are also plenty of open source tools available on GitHub that can save time, including Minikube and kubeadm.
Each of these management tools has its pros and cons, so users should select the one they're most comfortable with and best fits their needs. For example, those that are unfamiliar with Kuberntes may be better served by Google Cloud Console and Google Cloud Shell, while a more experienced Kubernetes admin may opt for kubectl.