Deploying a Multi-Cloud Kubernetes environment FAQ

Kubernetes offers many features dedicated to scalability to simplify infrastructure management for companies of any size. Those features present the expected, straightforward behaviors when used in a single-cloud Kubernetes cluster, but one question remains: how will they react when a single Kubernetes cluster regroups servers from multiple cloud providers?

Working in a multi-cloud environment presents multiple perks in terms of redundancy, reliability, and customer coverage. However, it also raises questions that we will address here about the particularity of the management and the implementation of Multi-Cloud.

How are Horizontal Node Auto-Scaling (HNA) and Auto-Healing managed?

As of today (october 2021), HNA and Auto-Healing are not covered by Kubernetes Kosmos for external servers. However, they are available for managed Scaleway node pools in any Availability Zone, regardless of the region of the Kubernetes Kosmos Control-Plane.

How can traffic be load-balanced between multiple Cloud providers?

Scaleway's Kubernetes Kosmos is fully integrated within the Scaleway ecosystem, which means that it benefits from the conversion of a Kubernetes service of type LoadBalancer into a Scaleway Multi-Cloud Load Balancer

How can persistent volumes be managed in a Multi-Cloud Kubernetes cluster?

Persistent Volumes are created through the Container Storage Interface (CSI) of each cloud provider. In a Kubernetes Kosmos cluster, Scaleway's CSI is only deployed on the cluster's managed Scaleway Instances. Nonetheless, almost every Cloud provider's CSI is open-sourced and can be deployed on the corresponding nodes to benefit from Persistent Volumes from any cloud provider, within the same cluster.

How is communication managed between the nodes of a Kubernetes Kosmos cluster?

By design, it is not possible to have a private network regrouping servers from different cloud providers, but it is possible to have them communicate with each other.

Kubernetes Kosmos uses Kilo, a Container Network Interface (CNI) based on Wireguard, managing a Virtual Private Network (VPN).

Can the CNI be changed in a Kubernetes Kosmos cluster?

Kilo - the CNI used by Kubernetes Kosmos - is the solution allowing a multi-cloud Kubernetes. Indeed, if we were to change the CNI, every unmanaged node would become unreachable from the API-Server of the cluster Control-Plane. Furthermore, the cluster would be highly impacted and mostly unavailable.

How can application workloads be distributed between Cloud providers across a Kubernetes Kosmos cluster?

Kubernetes has configuration options designed specifically for this kind of use case, such as selectors, taints, and tolerations.

How does a Multi-Cloud environment impact the services availability and latency?

Choosing between High Availability and Low Latency needs to be taken into account, whether we are working in a Multi-Cloud environment or not. On a Kubernetes Kosmos cluster, pods will be scheduled by default on the nodes with the least latency from the cluster's Control-Plane.

Does Multi-Cloud make infrastructure management more complicated?

Of course, managing multiple cloud providers’ accounts and credentials is more restrictive than keeping a single provider. However, studies have shown that over 80% of IT companies already use multiple cloud providers. That way, they can benefit from a larger range of services.

Which type of Instance to deploy?

If you are looking for the proper ally to deploy your project on, you might want to look into our range of Virtual Instances. We divided in four main categories to help you navigate among all the different specificities of each machines.

Learning

The Instances from the Learning range are perfect for small workloads and simple applications. They are built to host small internal applications, staging environments, or low-traffic web servers.

Cost-Optimized

The Cost-Optimized range balances compute, memory, and networking resources. They can be used for a wide range of workloads - scaling a development and testing environment, but also Content Management Systems (CMS) or microservices. They're also a good default choice if you need help determining which instance type is best for your application.

Production-Optimized

The Production-Optimized range includes the highest consistent performance per core to support real-time applications, like Enterprise Instances. In addition, their computing power makes them generally more robust for compute-intensive workloads.

Workload-Optimized

Expanding the Production-Optimized range, the Worload-Optimized range will be launched in the near future and will provide the same highest consistent performance than the Production-Optimized instances But they will come with the added flexibility of additional vCPU:RAM ratio in order to perfectly fits to your application’s requirements without wasting any vCPU or GB of RAM ressources.