07-Mar-2023 05:00 - edited 03-Jul-2023 15:49
This is a two-part architecture pattern series
Applications are part of our daily live. Indeed, it is part of our daily necessity. We use apps for digital wallet, check weather, navigation, online shopping and so on. We interact with it every mins or perhaps seconds. Application itself also transforming and evolving – from simple, static apps to complex, highly interactive over time. With the proliferation of various application framework, cloud and edge computing, distributed apps, microservices and so on, IT and application complexity has built up over time. This complexity has become an operational burden and essential threat to business success. According to F5’s State of Application Strategy 2022 (https://www.f5.com/state-of-application-strategy-report), the application landscape keeps changing and most organization manage 200-1,000 apps and 26% of app security and delivery technologies are distributed and deployed at the edge for efficiency outcomes.
Organization applications are constantly being transformed from traditional monolithic to modern microservices applications. Kubernetes platform such as F5 Distributed Cloud (F5 XC) AppStack, OpenShift Container Platform (OCP), EKS, AKS, GKE and etc is one of the key enabler for modern microservices application, which itself an important component of organization digital transformation strategy.
In this two-part architecture pattern document, I will share on how F5 XC with Secure Application Mesh Fabric essentially helps to simplify connectivity and security for your modern microservices applications.
“Any architect will know that a solid foundation is crucial to any building. Once the foundations are laid, necessary supports are put in place and permitting the rest of the structure to be built”. Success depends on a solid foundation. It is true as well for multi-cluster, multi-cloud/site networking for Kubernetes (K8S). Solid architecture pattern – “The Foundations”, are paramount for the success. An architecture pattern that fit for purpose, simple to consume, repeatable, secure and easy to operate that meet business and consumer requirements are important. Hence, the following architecture patterns for multi-cluster, multi-cloud/site networking for K8S will be described and explained.
Please do notes that this document is not about multi-cluster Kubernetes architecture design which commonly refer to single K8S cluster with single K8S control plane with distributed multiple worker nodes. This document related to multi-cluster K8S networking use cases (cluster to cluster) where each individual apps/pods distributed across multiple K8S cluster with each individual K8S control plane linked up or connected to form an application mesh network.
It is also important to acknowledge that generally it is a good practice to avoid “over-engineered” the entire solution that potentially may increases the complexities and Total Cost of Ownership (TCO). Hence, this pattern document may also be use as the baseline foundation for future additional use cases.
Here are just a few common reasons
Architecture Pattern is a deployment scaffolding to address specific use cases. It purposes it to describe a recommendation and commonly accepted industry best practices way of solving a problem. Pattern represent a repeatable and reusable solution in decision making. It captures the design structure and the reasons behind and the desirable outcome. It intended purpose it to helps architect, solution designer, IT manager, subject matter expert and decision maker to avoid “over engineer” a particular solution, inconsistent implementation and to reduce operational complexities.
Note: OCP being use in this pattern document as the K8S platform. This pattern also applicable for Amazon EKS, Microsoft AKS and Google GKE.
By default, when each VER pod(s) spin up (Volterra Edge Router), (single pod or cluster of three pods) it will auto register to F5 XC Regional Edge (RE) for control and management plane. These encrypted tunnels (dual for redundancy) can be used by VER pod(s) to mesh applications across K8S cluster. All K8S cluster network can have overlapping CIDR (Classless Inter-Domain Routing).
Pros | Cons |
|
|
Pros | Cons |
|
|
Application is the center of attention for majority organization. It is an important asset for business. Application evolves from simple application to complex application with multitude of integrated systems and distributed – simple to complex. Application becoming so complex. Complexities are the real threat to business regardless from security or operation aspect. Security, clouds, multi-cloud networking and so on exist because of application. Those technologies will cease to exist without existence of application. F5 Distributed Cloud is design to address business most important asset - application. It bring F5 vision to reality for our customer - “Secure, Deliver and Optimize every app and API anywhere”.
In Part 2 – Deployment Guide, I am going to demonstrate and provides guidance on how you build the following demo environment base on sample Arcadia financial application and Nginx web server.
Egress control for Kubernetes using F5 Distributed Cloud Services
Securely connecting Kubernetes Microservices with F5 Distributed Cloud
Multiple Kubernetes Clusters and Path-Based Routing with F5 Distributed Cloud
Thanks for the article Foo-Bang! I am also interested to see how XC can help overcome cluster sprawl in terms of observability. You mention in your article "visibility" and pod-to-pod communications across clusters. I have not yet had a serious challenge to provide this visibility but I do like the idea of providing this visibility without forcing changes on the administrators of various clusters.
Thanks for your lights. I think we can also combined vk8s into site secure mesh.
Yes. You can deploy apps into vK8s. Please do notes that vk8s only will works for CE node as VM. Not CE on K8S (OCP). vK8s address apps deployment. Your apps deployed on vk8s can be exposed to the secure mesh fabric and consume by other apps inside OCP.