Multicloud Communication for Kubernetes

Large enterprises have complex on-premises, private cloud, and public cloud implementations. There are many reasons for these complex multicloud deployments, including the need to support regional or functional requirements, load balancing, scaling, and failover. However, such deployments can lead to message routing, scalability, and security challenges for modern Kubernetes microservice-based applications that need to communicate. This article discusses some approaches to help manage and scale these applications.

Before we start, let’s define the different implementations. Multicloud refers to the presence of more than one cloud deployment of the same type (public or private), sourced from different vendors. Hybrid cloud refers to the presence of multiple deployment types (public or private) with some form of integration or orchestration between them. 

Every service as if it is “local”

In multicloud environments, the topology can be abstracted and transparent. Kubernetes services can be accessed by their clients as if they were local, regardless of their actual location. Such an approach reduces complexity by avoiding registry lookups or complex proxy configurations. It also allows clouds to be reconfigured without affecting the services or the clients that consume or communicate with the services. The microservice developer is freed from the concern about location of services. 

Secure access from the public cloud to private cloud services without VPNs

A VAN (virtual application network) allows distributed applications to communicate with each other as if they were local, without a point-to-point virtual private network (VPN). VANs are able to provide connectivity across the multiclouds because they operate at Layer 7—the application layer. They can offer connectivity either directly between each pair of clouds or by transitioning through other clouds, ideally without any central controllers or other single points of failure.

Skupper is an open-source tool for creating secure VANs across Kubernetes clusters. It sets up simply without requiring changes to the existing applications. And it provides smart routing, dynamic load balancing, and high availability.

Connect and disconnect new multicloud clusters dynamically

When Skupper instances connect, they share details about the services that they expose. Each instance is always aware of every service that has been exposed to the network, no matter where the service resides. When a Skupper instance disconnects, the remaining instances update the information to reflect the available services. 

Together with “every service as it’s local” (i.e., service location transparency), these features allow seamless communication across the services in the multicloud, even as the multicloud changes topology dynamically, to adapt to new requirements.

One area where Skupper offers advantages is during the development of services. Developers can export their local service into a remote cluster. Skupper manages the connectivity, which is very useful when developing new services and components.

Cost and locality-aware traffic forwarding

Smart traffic routing will take into account the location of the servers and clients and the cost of forwarding traffic between them. Skupper can assign a cost to each inter-cluster connection. For example, if demand is normal, all traffic can remain on your private cloud to avoid network costs. If demand peaks, you can dynamically route some traffic over to public cloud resources. 

Redundancy is also important to increase the resiliency of the solution and avoid unnecessary outages. Skupper uses redundant network paths and smart routing to provide highly available connectivity at scale.

Some of the traffic routing options in a VAN include using redundant paths for resiliency. Such a capability is an important feature to look for when comparing VAN middleware. Also, support for multicast is important for most enterprise applications.

A network of interconnected event brokers

An event mesh is a dynamic infrastructure that enables messages to be delivered reliably across the network without a need for applications to be aware of the topology of the network. The event mesh decouples producers and consumers of events and can provide features such as high availability, high scalability, publish-subscribe for volatile and persisted events.

Skupper uses an Apache Qpid Dispatch Router, which is based on the AMQP protocol (an OASIS standard protocol for reliably sending and receiving messages). Acting as a lightweight AMQP message router, it can flexibly route messages between any AMQP-enabled endpoints, supporting high-performance messaging, redundant paths, and topology-independent addressing. Event brokers based on the Apache ActiveMQ Artemis project provide local services such as persistent messages, queues and topics, and multi-protocol support like JMS and MQTT to better integrate with legacy and Kubernetes based services. Event brokers based on Kafka provide a highly scalable infrastructure for pub-sub communication for microservices and non-microservices-based applications. 

Conclusion

Management, security, and scaling of modern Kubernetes microservice-based applications that span multiclouds can take advantage of virtual application networks like Skupper to provide more reliable and flexible communication patterns. Such an approach simplifies the application development process, deployment, and operation of large distributed applications that leverage local event brokers in an event-driven architecture. 

Read the other event-driven architecture (EDA) blogs in this series.