Requirements for Managing Multicloud Kubernetes
Enterprises are choosing to use multiple cloud providers to run their applications with Kubernetes as the clear leader in multicloud container deployments. But a multicloud Kubernetes configuration has unique requirements.
By Alison Forster
More and more enterprises are choosing to use multiple cloud providers to run their applications on, and Kubernetes is the clear leader in supporting multicloud container deployments. However, a multicloud Kubernetes configuration has unique requirements. The complexities of managing clusters spread across different hosts can slow down your operations and hinder security without the right kind of tools and policies in place. Before setting up your multicloud environment, you should be sure that you are prepared to support these conditions.
Key considerations before implementing
When setting up any Kubernetes configuration, one of the first things to consider is which cluster topology best meets the needs of your application. Naturally, if you are aiming for a multicloud deployment, this will require multiple nodes. But beyond that point, multicloud architecture does not dictate your node configuration. You can implement a multicloud strategy within a single Kubernetes cluster by having some worker nodes operating in a different cloud than the master node, or you can have multiple highly-available clusters, each operating in a different cloud. All options for organizing your Kubernetes clusters are available for multicloud configurations.
With any containerized deployment, it is important to keep development, staging, and production as similar as possible in order to minimize inconsistencies between stages. With the GitOps model, the declarative nature of Kubernetes is leveraged to prevent these inconsistencies and ensure a smooth CI/CD pipeline.
Through Git, changes to your configuration are deployed across clusters automatically. If inconsistencies between nodes appear, infrastructure as tools can help identify them quickly. This is especially important in a multicloud setup where slight differences between cloud providers might create friction. Another way to prevent variance between nodes is to choose a common container OS. In a multicloud configuration, this means that you won’t be able to use the cloud-specific container OS provided by each cloud service.
While it is possible to set up Kubernetes from scratch and manually deploy nodes to different clouds, it’s much more desirable to automate this process. That’s because automating the configuration of new nodes and clusters is essential for continuous delivery. Fortunately, there are many third-party tools available which support Kubernetes deployment to multiple cloud services, such as Weaveworks, and Terraform.
When choosing a multicloud configuration, you should be aware that it will be more complex to monitor. You won’t be able to rely on your cloud provider’s built-in visibility tools. Rather, you need a monitoring service that offers a single view of all your clusters. With a multicloud configuration, you need a way to filter out what is an artifact of the cloud host and what is an event that requires your attention. Thus, you will need integrated monitoring with metrics that are correlated with the runtime environments. For Kubernetes the monitoring solution of choice is Prometheus.
Furthermore, with increased complexity, it is important that your monitoring service provides analytics and data visualization. Good monitoring may deliver the data you need, but unless that data is processed and presented meaningfully, you won’t be able to separate the signal from the noise. Also, as each cloud will have its own pricing policies, you need to monitor your usage and expenses associated with each cloud-provider separately. Understanding these metrics is essential to your ability to scale your application appropriately.
Multicloud environments present some security challenges, namely the need to be able to detect and respond to threats in multiple environments simultaneously. It is not enough just to be able to detect a threat to each cloud environment; security teams must be able to immediately assess the impact of a threat to each cloud resource as well. Given the increasing speed of attacks, the monitoring and security tools put in place need to be able to gather and analyze data from different clouds continuously in order to understand attacks as they occur.
With finely-tuned monitoring and tightly-integrated security in place, you should learn about any incidents as they happen. But can you respond to them effectively? Every security team should have an incident response plan in order to restore operations quickly. However, a one-size-fits-all strategy for incident response won’t work with a multicloud deployment. Rather, a plan that dictates action based on the context in which the incident occurred - from the cloud provider down to the node - will utilize your security resources to their fullest. This means that the monitoring tools put in place must provide granular labelling of resources so that you can identify which have been compromised by an attack.
What do you need for secure clusters across multiple clouds?
The security features available from different cloud providers will vary. This can make it challenging for security teams to ensure that the same standards are in place for clusters hosted in separate clouds. In order to establish uniform security policies in a multicloud environment, it may be necessary to rely on container security tools that can implement a centralized policy across clouds.
Different cloud providers may fall under the jurisdiction of different regulations, so ensuring compliance in a multicloud configuration is complex. However, if you are utilizing integrated monitoring and logging tools to track your application, as recommended above, then you will be able to demonstrate compliance with the regulations of each domain as well as manage your own resources.
By hosting your application across multiple cloud hosts, you increase your attack surface and provide more opportunities for illicit connections. Thus, a multicloud application must defend against the same threats as any networked application, but from all sides. Each point of entry must be secured equally.
Kubernetes provides controls for specifying roles and permissions through custom role definitions (RBAC) that specify sets of permissions. In a multicloud configuration, you need a way to manage these roles across cloud providers. Kubernetes also includes a mechanism for encoding private configurations, but it is not very robust. Individual cloud providers have their own native secret management available, but for multicloud, you will want a single tool that you can use on all clusters. Fortunately, there are cloud-agnostic secret management tools (such as Vault or sealed secrets) that meet this need.
Cloud providers share responsibility for protecting the data they host with their customers, but the line between their responsibility and yours will vary from host to host. Beyond being familiar with your obligations under each cloud provider, the safest strategy is to give users the lowest level of access that they require. Thus, you will need to manage more roles in order to support finely-tuned privileges.
Implementing a multicloud strategy certainly carries an increase in complexity, but by leveraging cloud-agnostic tools to unify management across cloud environments, these complications can be mitigated. If you have a plan for how to unify your environments, especially with respect to monitoring and security, you will be in a sound position for leveraging the advantages of multiple cloud providers.
Have questions on what you need to create a cloud native platform?
The Weaveworks team can help you navigate the vast landscape of cloud native technologies – OSS and paid. Together we can create a cloud native reference architecture that fits your business needs. You can benefit from a Weaveworks’ validated design or you can design, review and select technology options with our expertise.