{"id":269484,"date":"2023-12-11T11:35:12","date_gmt":"2023-12-11T16:35:12","guid":{"rendered":"https:\/\/www.webscale.com\/?page_id=269484"},"modified":"2024-12-07T02:04:05","modified_gmt":"2024-12-07T07:04:05","slug":"modernizing-apps-with-distributed-multi-cluster-kubernetes","status":"publish","type":"page","link":"https:\/\/www.webscale.com\/modernizing-apps-with-distributed-multi-cluster-kubernetes\/","title":{"rendered":"Why Organizations are Modernizing their Applications with Distributed Multi-Cluster Kubernetes Deployments"},"content":{"rendered":"<p>[et_pb_section fb_built=&#8221;1&#8243; module_id=&#8221;top&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;d7d52715-bafd-4e3f-b538-c08d8918d9eb&#8221; background_color=&#8221;#F9F9F9&#8243; background_image=&#8221;https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/05\/Intelligent-CloudOps-TechGuide-banner.jpg&#8221; background_position=&#8221;bottom_center&#8221; locked=&#8221;off&#8221; global_colors_info=&#8221;{}&#8221;][et_pb_row use_custom_gutter=&#8221;on&#8221; make_equal=&#8221;on&#8221; custom_padding_last_edited=&#8221;on|phone&#8221; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;default&#8221; min_height=&#8221;280px&#8221; custom_padding=&#8221;||||false|false&#8221; custom_padding_tablet=&#8221;45px||45px||true|false&#8221; custom_padding_phone=&#8221;45px||45px||false|false&#8221; custom_css_main_element=&#8221;margin: auto;&#8221; global_colors_info=&#8221;{}&#8221; custom_css_main_element_last_edited=&#8221;off|phone&#8221; custom_css_main_element_phone=&#8221;padding: 45px 0px !important;||margin: auto;&#8221;][et_pb_column type=&#8221;4_4&#8243; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;19a24ed3-a59d-47e1-b2e9-67efe8fc92f3&#8243; custom_padding_phone=&#8221;||30px||false|false&#8221; custom_css_main_element=&#8221;margin:auto;&#8221; pac_dcm_carousel_specific_module_num=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221; custom_css_main_element_last_edited=&#8221;off|phone&#8221; custom_css_main_element_tablet=&#8221;margin:auto;&#8221; custom_css_main_element_phone=&#8221;||padding: 4vw 0vw;&#8221;][et_pb_text module_class=&#8221;grd-vio-blu&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; text_text_color=&#8221;#231F20&#8243; text_font_size=&#8221;20px&#8221; header_font=&#8221;|800|||||||&#8221; header_text_align=&#8221;center&#8221; header_text_color=&#8221;#FF6700&#8243; header_font_size=&#8221;40px&#8221; text_orientation=&#8221;center&#8221; background_layout=&#8221;dark&#8221; custom_margin=&#8221;||0px||false|false&#8221; custom_padding_tablet=&#8221;&#8221; custom_padding_phone=&#8221;60px||||false|false&#8221; custom_padding_last_edited=&#8221;on|phone&#8221; filter_brightness=&#8221;120%&#8221; filter_contrast=&#8221;90%&#8221; custom_css_main_element=&#8221;margin: auto;&#8221; custom_css_free_form=&#8221;h1 {||  font-weight: 800 !important;||}&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h1>Why Organizations are Modernizing their Applications with Distributed, Multi-Cluster Kubernetes Deployments<\/h1>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;sub-title&#8221; module_class=&#8221;sub-title&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; text_text_color=&#8221;#F9F9F9&#8243; text_font_size=&#8221;20px&#8221; header_font=&#8221;|600|||||||&#8221; header_text_align=&#8221;center&#8221; header_text_color=&#8221;#FF6700&#8243; text_orientation=&#8221;center&#8221; background_layout=&#8221;dark&#8221; custom_padding_phone=&#8221;30px||||false|false&#8221; custom_padding_last_edited=&#8221;off|desktop&#8221; custom_css_main_element=&#8221;margin: auto;&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p>An exploration of the substantial advantages and opportunities for evolving from a centralized cluster deployment to a distributed multi-cluster topology<\/p>\n<p>[\/et_pb_text][et_pb_button button_url=&#8221;https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Why-Organizations-are-Modernizing-their-Applications-with-Distributed-Multi-Cluster-Kubernetes-Deployments-Tech-Guide.pdf&#8221; button_text=&#8221;Downloadable Version&#8221; button_alignment=&#8221;center&#8221; module_class=&#8221;learn-more wht-btn mr-at wd-240&#8243; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;default&#8221; custom_button=&#8221;on&#8221; button_text_size=&#8221;17px&#8221; button_border_width=&#8221;1px&#8221; button_use_icon=&#8221;off&#8221; custom_margin_tablet=&#8221;&#8221; custom_margin_phone=&#8221;||45px||false|false&#8221; custom_margin_last_edited=&#8221;on|phone&#8221; custom_padding=&#8221;10px|20px|10px|20px|true|true&#8221; locked=&#8221;off&#8221; global_colors_info=&#8221;{}&#8221;][\/et_pb_button][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=&#8221;1&#8243; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;497f5b94-fe41-4fd2-abfd-4bceb314f182&#8243; global_colors_info=&#8221;{}&#8221;][et_pb_row column_structure=&#8221;1_4,3_4&#8243; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;default&#8221; custom_margin=&#8221;0px||||false|false&#8221; custom_padding=&#8221;0px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;][et_pb_column type=&#8221;1_4&#8243; module_id=&#8221;left-col&#8221; disabled_on=&#8221;on|on|off&#8221; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;1c9af76d-3b01-4760-84a2-f9d64b97fe9e&#8221; pac_dcm_carousel_specific_module_num=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221;][et_pb_text ul_type=&#8221;none&#8221; disabled_on=&#8221;off|off|off&#8221; module_id=&#8221;table-of-cont&#8221; module_class=&#8221;li-content&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; link_font=&#8221;||||||||&#8221; link_text_color=&#8221;#b0b0b0&#8243; background_enable_color=&#8221;off&#8221; width=&#8221;300px&#8221; max_width=&#8221;300px&#8221; module_alignment=&#8221;left&#8221; max_height=&#8221;400px&#8221; custom_padding=&#8221;60px|25px|25px|25px|false|true&#8221; sticky_position=&#8221;top&#8221; sticky_offset_top=&#8221;150px&#8221; sticky_limit_top=&#8221;section&#8221; sticky_limit_bottom=&#8221;section&#8221; motion_trigger_start=&#8221;bottom&#8221; link_font_last_edited=&#8221;off|desktop&#8221; sticky_position_tablet=&#8221;top&#8221; sticky_position_phone=&#8221;none&#8221; sticky_position_last_edited=&#8221;off|desktop&#8221; custom_css_main_element=&#8221;margin-top: 60px;&#8221; border_color_all=&#8221;#eaeaea&#8221; global_colors_info=&#8221;{}&#8221; link_text_color__hover_enabled=&#8221;on|hover&#8221; link_text_color__hover=&#8221;#FF6700&#8243;]<\/p>\n<h3>Table of Contents:<\/h3>\n<ul>\n<li class=\"intro\"><a href=\"#link1\">Introduction<\/a><\/li>\n<li class=\"intro\"><a href=\"#link2\">Understanding Multi-Cluster Deployments<\/a><\/li>\n<li class=\"intro\"><a href=\"#link3\">Centralized Kubernetes Container Deployments<\/a><\/li>\n<li class=\"intro\"><a href=\"#link4\">The Benefits of Distributed Multi-Cluster Deployment<\/a><\/li>\n<li class=\"intro\"><a href=\"#link5\">Application Architecture Approaches<\/a><\/li>\n<li class=\"intro\"><a href=\"#link6\">Distributed Multi-Cluster Edge Deployment<\/a><\/li>\n<\/ul>\n<p>[\/et_pb_text][\/et_pb_column][et_pb_column type=&#8221;3_4&#8243; module_id=&#8221;right-col&#8221; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;1c9af76d-3b01-4760-84a2-f9d64b97fe9e&#8221; pac_dcm_carousel_specific_module_num=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221;][et_pb_code _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;default&#8221; min_height=&#8221;20px&#8221; hover_enabled=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221; sticky_enabled=&#8221;0&#8243;]<script><!-- [et_pb_line_break_holder] -->    jQuery(document).ready(function($) {<!-- [et_pb_line_break_holder] -->        if ($(window).width() > 1200) {<!-- [et_pb_line_break_holder] -->            $('#right-cont').appendTo('#right-col');<!-- [et_pb_line_break_holder] -->        }<!-- [et_pb_line_break_holder] -->      <!-- [et_pb_line_break_holder] -->            $('#table-of-cont li a').on('click', function(e) {<!-- [et_pb_line_break_holder] -->            e.preventDefault(); \/\/ Prevent default link behavior<!-- [et_pb_line_break_holder] -->            $('#table-of-cont li').removeClass('active');<!-- [et_pb_line_break_holder] -->            $(this).parent('li').addClass('active');<!-- [et_pb_line_break_holder] -->        });<!-- [et_pb_line_break_holder] -->       $('.et-db #et-boc .et-l #table-of-cont.li-content li').addClass('scroll');<!-- [et_pb_line_break_holder] -->       $('#table-of-cont li a').hover(<!-- [et_pb_line_break_holder] -->            function() {<!-- [et_pb_line_break_holder] -->                \/\/ Mouse enter event<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li').removeClass('scroll');<!-- [et_pb_line_break_holder] -->            },<!-- [et_pb_line_break_holder] -->            function() {<!-- [et_pb_line_break_holder] -->                \/\/ Mouse leave event<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li').addClass('scroll');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->        );<!-- [et_pb_line_break_holder] --><!-- [et_pb_line_break_holder] -->        $(window).scroll(function() {<!-- [et_pb_line_break_holder] -->            var height = $(window).scrollTop();<!-- [et_pb_line_break_holder] -->            console.log(height);<!-- [et_pb_line_break_holder] --><!-- [et_pb_line_break_holder] -->            var bottom = $(document).height() - $(window).height() - $(window).scrollTop() + 750;<!-- [et_pb_line_break_holder] --><!-- [et_pb_line_break_holder] -->            \/\/ Attach click event handler to elements matching the selector<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() < 5987) {<!-- [et_pb_line_break_holder] -->                $('#table-of-cont').css('top', '60px');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() > 500) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(1)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() > 1400) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(2)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() > 3300) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(3)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() > 4550) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(4)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->            if ($(document).scrollTop() > 8800) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(5)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->          if ($(document).scrollTop() > 10910) {<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll').removeClass('active');<!-- [et_pb_line_break_holder] -->                $('.et-db #et-boc .et-l #table-of-cont.li-content li.scroll:nth-child(6)').addClass('active');<!-- [et_pb_line_break_holder] -->            }<!-- [et_pb_line_break_holder] -->        });<!-- [et_pb_line_break_holder] -->      <!-- [et_pb_line_break_holder] -->    });<!-- [et_pb_line_break_holder] --><\/script><!-- [et_pb_line_break_holder] -->[\/et_pb_code][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=&#8221;1&#8243; custom_padding_last_edited=&#8221;off|phone&#8221; module_id=&#8221;right-cont&#8221; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;d7d52715-bafd-4e3f-b538-c08d8918d9eb&#8221; background_enable_color=&#8221;off&#8221; locked=&#8221;off&#8221; global_colors_info=&#8221;{}&#8221;][et_pb_row use_custom_gutter=&#8221;on&#8221; make_equal=&#8221;on&#8221; custom_padding_last_edited=&#8221;off|desktop&#8221; _builder_version=&#8221;4.22.1&#8243; _module_preset=&#8221;default&#8221; module_alignment=&#8221;center&#8221; custom_margin=&#8221;0px||||false|false&#8221; custom_padding=&#8221;0px||60px||false|false&#8221; custom_padding_tablet=&#8221;|15px||15px|false|true&#8221; custom_padding_phone=&#8221;|15px||15px|false|true&#8221; global_colors_info=&#8221;{}&#8221;][et_pb_column type=&#8221;4_4&#8243; module_class=&#8221;toc&#8221; _builder_version=&#8221;4.22.0&#8243; _module_preset=&#8221;1c9af76d-3b01-4760-84a2-f9d64b97fe9e&#8221; custom_css_main_element=&#8221;width: 100% !important;&#8221; pac_dcm_carousel_specific_module_num=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221;][et_pb_text admin_label=&#8221;Getting Started with Varnish Cache&#8221; module_id=&#8221;link1&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; text_font=&#8221;|800|||||||&#8221; text_font_size=&#8221;50px&#8221; text_line_height=&#8221;1.2em&#8221; header_2_font=&#8221;||||||||&#8221; header_2_text_color=&#8221;#231F20&#8243; header_2_font_size=&#8221;32px&#8221; max_width_tablet=&#8221;100%&#8221; max_width_phone=&#8221;100%&#8221; max_width_last_edited=&#8221;off|desktop&#8221; module_alignment=&#8221;center&#8221; custom_margin=&#8221;||||false|false&#8221; custom_padding=&#8221;60px||||false|false&#8221; custom_padding_tablet=&#8221;60px||||false|false&#8221; custom_padding_phone=&#8221;0px||||false|false&#8221; custom_padding_last_edited=&#8221;on|phone&#8221; text_font_size_tablet=&#8221;32px&#8221; text_font_size_phone=&#8221;32px&#8221; text_font_size_last_edited=&#8221;on|tablet&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>Introduction<\/h2>\n<p>[\/et_pb_text][et_pb_text module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p>According to a <a href=\"https:\/\/www.cncf.io\/wp-content\/uploads\/2020\/11\/CNCF_Survey_Report_2020.pdf\" target=\"_blank\" rel=\"noopener\">survey<\/a> from the Cloud Native Computing Foundation, more than 92% of respondents worldwide have adopted containers in their production environments, and 83% of those are using Kubernetes to orchestrate those containers.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Artboard-1.svg\" width=\"undefined\" height=\"undefined\" alt=\"\" class=\"wp-image-269352 aligncenter size-full\" \/><i><span style=\"font-weight: 400;\">Image source: <\/span><\/i><a href=\"https:\/\/www.cncf.io\/wp-content\/uploads\/2020\/11\/CNCF_Survey_Report_2020.pdf\" target=\"_blank\" rel=\"noopener\"><i><span style=\"font-weight: 400;\">CNCF Survey Report (2020)<\/span><\/i><\/a><\/p>\n<p><span style=\"font-weight: 400;\">As these organizations mature their containerized applications, many are looking to multi-cluster, multi-region, multi-provider deployments.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Why?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A distributed multi-cluster deployment offers numerous, substantial benefits over centralized clusters in terms of availability, resilience, scalability, performance, cost and more. Let\u2019s look at each benefit in turn, and then discuss what organizations need to consider in adopting a distributed, multi-cluster, multi-region topology.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">But before we do that, it\u2019s important to frame what we mean by distributed, multi-cluster, multi-region deployments.<\/span><\/p>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Understanding VCL (Varnish Configuration Language)&#8221; module_id=&#8221;link2&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; custom_padding=&#8221;60px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>Understanding Multi-Cluster Deployments<br \/><em><\/em><\/h2>\n<p>[\/et_pb_text][et_pb_text module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><span style=\"font-weight: 400;\">When looking at containerized Kubernetes environments, it\u2019s important to understand that they vary along several vectors. First and foremost, they may be single or multi-cluster.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">While the definition of multi-cluster might be obvious to anyone comfortable with basic arithmetic, there are important nuances. A true multi-cluster deployment does not simply mean having more than one cluster. It means orchestrating and managing those clusters as though they were a single platform. While you certainly could set up and control different clusters using separate control planes and tooling, that would be both inefficient and negate many of the benefits to be had.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That doesn\u2019t mean that clusters need to be the same; far from it. Each cluster is independent, and controls its own provisioning, services, security schema and resources.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><img decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Artboard-2.svg\" width=\"undefined\" height=\"undefined\" alt=\"\" class=\"wp-image-269353 aligncenter size-full\" \/><i>Image source: <\/i><a href=\"https:\/\/blogs.gartner.com\/tony-iams\/prepare-to-deploy-and-operate-multiple-kubernetes-clusters-at-scale\/\" target=\"_blank\" rel=\"noopener\"><i>Gartner Blog<\/i><\/a><\/span><\/p>\n<p><span style=\"font-weight: 400;\">Second, the deployment may be centralized or distributed. It is entirely possible, and often advantageous, to have multiple clusters within a centralized hosting environment, for instance so you can have separate clusters for staging\/testing and production (more on this later). Conversely, you can distribute these clusters more broadly across hosting environments (for instance, on-prem and cloud), providers, even geographies. Each offers its own benefits and challenges, so when looking at a distributed environment it\u2019s important to consider <\/span><i><span style=\"font-weight: 400;\">how distributed<\/span><\/i><span style=\"font-weight: 400;\">? As we\u2019ll get into, it\u2019s generally true that the more distributed, the better.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Finally, a deployment can be single-region or multi-region. A distributed multi-cluster deployment that\u2019s limited to North America, for instance, will have different considerations than an application workload that needs to address the needs of users in both North America and the European Union. A truly global deployment will have its own set of unique requirements and challenges.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In a very real sense, this creates a progression in Kubernetes containerization that typically mirrors application maturity, from single cluster to centralized multi-cluster to distributed multi-cluster to, ultimately, multi-region edge deployments. And it\u2019s at the edge that the true magic happens for users and organizations, as we\u2019ll see.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Interestingly, there\u2019s an <\/span><a href=\"https:\/\/www.webscale.com\/blog\/top-considerations-for-containers-at-the-edge\/\"><span style=\"font-weight: 400;\">important subtext to understand<\/span><\/a><span style=\"font-weight: 400;\"> in the relationship between Kubernetes containerization and workload distribution. Simply put, the lightweight portability of containers makes them ideally suited to distribution, while their abstraction facilitates deployment to non-homogenous federated compute platforms. Moreover, Kubernetes adds the orchestration needed to best coordinate this sort of distributed multi-region, multi-cluster topology.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In other words, organizations that have already adopted Kubernetes are primed to rapidly adopt modern edge deployments for their application workloads. Even those that are still at the single-cluster stage are in position to rapidly leap-frog to the distributed edge. Recent <\/span><a href=\"https:\/\/www.cncf.io\/wp-content\/uploads\/2021\/12\/Q1-2021-State-of-Cloud-Native-development-FINAL.pdf\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">research<\/span><\/a><span style=\"font-weight: 400;\"> by SlashData on behalf of the Cloud Native Computing Foundation confirms this correlation between edge, containers, and Kubernetes, noting developers working on edge computing having the highest usage of both containers (76%) and Kubernetes (63%) of surveyed segments.<\/span><\/p>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Caching Strategies with Varnish&#8221; module_id=&#8221;link3&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; custom_padding=&#8221;60px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>Centralized Kubernetes Container Deployments<br \/><em><\/em><\/h2>\n<p>[\/et_pb_text][et_pb_text module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><span style=\"font-weight: 400;\">For most organizations, initial Kubernetes adoption starts with centralized clusters. Primarily this is due to simplicity: whether single or multi-cluster, a centralized deployment eliminates the need to deal with the underlying complexities that can be involved in distributed topologies, as covered in our white paper on <\/span><a href=\"\/solving-the-edge-puzzle\/\"><span style=\"font-weight: 400;\">Solving the Edge Puzzle<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Once they\u2019ve started down this path, it\u2019s also the more familiar approach, allowing them to continue using the same tooling and management strategies they\u2019ve become comfortable with (kubectl, Helm Charts, etc.). This combination of simplicity and familiarity holds true whether the deployment is centralized in a data center, or through a single cloud provider or hyper scaler.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What these organizations need to weigh, however, is what they\u2019re giving up with centralized clusters. Are the benefits of a distributed multi-cluster deployment worth the added complexity? Moreover, what if we can eliminate that complexity? What then?<\/span><\/p>\n<p style=\"text-align: center;\"><strong>Building for Edge is a complex and always shifting puzzle to be solved and then managed<\/strong><\/p>\n<p style=\"text-align: center;\"><strong><img decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Artboard-3.svg\" width=\"undefined\" height=\"undefined\" alt=\"\" class=\"wp-image-269354 aligncenter size-full\" \/><\/strong><\/p>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Extending Varnish Cache capabilities with VMODs&#8221; module_id=&#8221;link4&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; custom_padding=&#8221;60px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>The Benefits of Distributed Multi-Cluster Deployment<br \/><em><\/em><\/h2>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Text&#8221; module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; quote_font=&#8221;|600|||||||&#8221; quote_text_color=&#8221;#231F20&#8243; quote_font_size=&#8221;18px&#8221; header_4_font=&#8221;||||||||&#8221; header_4_font_size=&#8221;26px&#8221; custom_css_free_form=&#8221;h4 {||    margin: 60px auto !important;||}&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><span style=\"font-weight: 400;\">As noted, application maturity and scale tend to drive distributed multi-cluster adoption. The question is: why? What are the advantages and benefits of a distributed topology over centralized clusters? As importantly, does the breadth of distribution matter? Are organizations that adopt a multi-region, multi-provider approach gaining advantage over those that don\u2019t? Let\u2019s dive in.<\/span><\/p>\n<h4 style=\"text-align: center; max-width: 900px; margin: auto;\"><span style=\"font-weight: 400; color: #007a87;\">Every year there are reports of wide swaths of the internet &#8216;going dark&#8217; and taking down well-known brands and applications. Invariably, those issues are traced back to problems within a particular provider network. Distributed multi-cluster deployments help mitigate those risks.<\/span><\/h4>\n<h3><strong>Availability and Resiliency<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">By mirroring workloads across clusters, you increase availability and resiliency through elimination of single points of failure. At its most basic level, this means using one cluster as a backup or failover should another cluster fail. As you increase cluster distribution outside of a single data center\/cloud instance to stretch across clouds and providers, you further minimize risk \u2013 from failure of single endpoints within a provider network, or even failure of an entire provider network \u2013 by ensuring your application can fail over to other endpoints or providers.<\/span><\/p>\n<h3><strong>Vendor Lock-in<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">Avoiding reliance on a single vendor is an operational mantra for many organizations, making the ability to distribute workloads not only across locations, but across providers a key advantage. This multi-vendor approach improves pricing flexibility, as well as ensuring better continuity and quality of service. Similarly, this can help mitigate data lock-in, whereby it can become prohibitively expensive to migrate data off a provider\u2019s network.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In fact, a distributed multi-cluster, multi-vendor approach even helps mitigate managed Kubernetes lock-in, ensuring you are not committed to a particular provider\u2019s version of Kubernetes and any proprietary extensions supported by a specific cloud provider\u2019s managed Kubernetes service.<\/span><\/p>\n<h3><strong>Performance and Latency<\/strong><\/h3>\n<blockquote>\n<p><span>According to a <\/span><a href=\"https:\/\/assets.lumen.com\/is\/content\/Lumen\/trend-report-the-edge-compute-imperative\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">recent survey of IT decision makers<\/span><\/a><span> by Lumen, 86% of organizations identify application latency as a key differentiator. And the single best way to reduce latency is to reduce geographic distance by physically placing applications closer to the user base.<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">Distributed multi-cluster Kubernetes facilitates this strategy, allowing organizations to use an edge topology to process data and application interactions closer to the source. This becomes especially important \u2013 <\/span><a href=\"https:\/\/www.webscale.com\/blog\/webscale-cloudflow-simplifies-global-saasification\/\"><span style=\"font-weight: 400;\">in fact, arguably a necessity<\/span><\/a><span style=\"font-weight: 400;\"> \u2013 for applications that have a global user base, where multi-region edge deployments can geographically distribute workloads to best reduce latency while efficiently managing resources (e.g. spinning up\/down infrastructure to adapt to \u201cfollow the sun\u201d or other regional and ad hoc traffic patterns).<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Organizations that elect a centralized approach are, by definition, treating users outside of the primary geography as second-class citizens when it comes to application performance. In fact, this is the primary consideration when organizations choose a particular cloud instance for deployment (e.g. AWS EC2 US-East): where are most of my users based, so those within or close to that region will enjoy a premium experience? The unspoken corollary is that as customers get geographically further from that particular region, application performance, responsiveness, resilience and availability will naturally degrade. In short, this is the default \u201cgood enough\u201d cloud deployment for application workloads that cater largely to a home-grown user base. As these applications mature and broaden adoption, this strategy becomes increasingly tenuous, and organizations find themselves compelled to move workloads to the edge.<\/span><\/p>\n<h3><strong>Scalability<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">A closely related factor: running multiple distributed clusters also improves an organization\u2019s ability to fine tune and scale workloads as needed, providing greater flexibility than centralized clusters. This scaling is required when an application can no longer handle additional requests effectively, either due to steadily growing volume or episodic spikes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It\u2019s important to note that scaling can happen horizontally (scaling out), by adding more machines to the pool of resources, or vertically (scaling up), by adding more power in the form of CPU, RAM, storage, etc. to an existing machine. There are <\/span><a href=\"https:\/\/www.webscale.com\/blog\/webscale-cloudflow-simplifies-global-saasification\/\"><span style=\"font-weight: 400;\">advantages<\/span><\/a><span style=\"font-weight: 400;\"> to each, and there\u2019s something to be said for combining both approaches.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A distributed multi-cluster topology facilitates this flexibility in scaling. Among other things, when run on different clusters\/providers\/regions, it becomes significantly easier to identify and understand which particular workloads require scaling (and whether best served by horizontal or vertical scaling), whether that workload scaling is provider- or region-dependent, and ensure adequate resource availability while minimizing load on backend services and databases.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Those familiar with Kubernetes will recognize that one of its strengths is its ability to perform effective autoscaling of resources in response to real time changes in demand. Kubernetes doesn\u2019t support just one autoscaler or autoscaling approach, but three:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Pod replica count &#8211; This involves adding or removing pod replicas in direct response to changes in demand for applications using the <\/span><a href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">Horizontal Pod Autoscaler (HPA)<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cluster autoscaler &#8211; As opposed to scaling the number of running pods in a cluster, the <\/span><a href=\"https:\/\/github.com\/kubernetes\/autoscaler\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">cluster autoscaler<\/span><\/a><span style=\"font-weight: 400;\"> is used to change the number of nodes in a cluster. This helps manage the costs of running Kubernetes clusters across cloud and edge infrastructure.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Vertical pod autoscaling &#8211; the <\/span><a href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">Vertical Pod Autoscaler (VPA)<\/span><\/a><span style=\"font-weight: 400;\"> works by increasing or decreasing the CPU and memory resource requests of pod containers. The goal is to match cluster resource allotment to actual usage.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Worth noting for those running centralized workloads on single clusters: a multi-cluster approach might become a requirement for scaling if a company\u2019s application threatens to hit the ceiling for Kubernetes nodes per cluster, <\/span><a href=\"https:\/\/kubernetes.io\/docs\/setup\/best-practices\/cluster-large\/\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">currently limited to 5,000<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<h3><strong>Cost<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">Another advantage to a distributed multi-cluster strategy is fine-grained control of costly compute resources. As mentioned above, this can be time-dependent, where global resources are spun down after hours. It can be provider-dependent, where workloads can take advantage of lower cost resources in other regions. Or it can be performance-dependent, whereby services that aren\u2019t particularly sensitive to factors like performance or latency can take advantage of less performant, and less costly, compute resources.<\/span><\/p>\n<h3><strong>Isolation<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">A multi-cluster deployment physically and conceptually isolates workloads from each other, blocking communication and sharing of resources. There are several reasons this is desirable. First, it improves security, mitigating risk by limiting the ability of a security issue with one cluster to impact others. It can also have implications for compliance and data privacy (more on that below). It further ensures that the compute resources you intend for a specific cluster are, in fact, available to that cluster, and not consumed by a noisy neighbor.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">But by far the most common rationale behind workload isolation is the desire to separate development, staging\/testing and production environments. By separating clusters, any change to one cluster affects only that particular cluster. This improves issue identification and resolution, supports testing and debugging, and promotes experimentation and optimization. In short, you can ensure a change is working as expected on an isolated cluster before rolling it into production.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As noted, this isolation is an inherent benefit of multi-cluster vs single cluster deployments, and not particularly dependent on how widely distributed those clusters are \u2013 you could have isolated stage\/test\/production clusters in a centralized hosting environment, for example. That said, when you distribute multiple clusters, this isolation can have important implications.<\/span><\/p>\n<h3><strong>Compliance Requirements<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">Compliance is a critical consideration for many organizations. It can be closely related to isolation \u2013 workload isolation is required for compliance with standards such as PCI-DSS, for example \u2013 but it also has broader implications in regard to distributed or multi-region workloads.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In this instance, different countries and regions have unique rules and regulations governing data handling, and a distributed multi-cluster topology facilitates a region-by-region approach to compliance. A notable example is the European Union\u2019s General Data Protection Regulation (GDPR), which governs data protection and privacy for any user that resides in the European Economic Area (EEA). Importantly, it applies to any company, regardless of location, that is processing and\/or transferring the personal information of individuals residing in the EEA. For instance, GDPR may regulate how and where data is stored, something that is readily addressed through multiple clusters.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Similarly, other regulatory or governance requirements might stipulate that certain types of data or workloads must remain on-premises; a distributed multi-cluster topology allows an organization to meet this requirement while simultaneously deploying clusters elsewhere to address other business needs (to the edge for lower latency, for example).<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/DLA-Piper-Data-Protection-Laws-of-the-World-interactive-tool-1024x515-1.png\" width=\"1024\" height=\"515\" alt=\"\" class=\"wp-image-269358 aligncenter size-large\" \/><i><br \/>Image source: <\/i><a href=\"https:\/\/www.dlapiperdataprotection.com\/\" target=\"_blank\" rel=\"noopener\"><i>DLA Piper Data Protection Laws of the World interactive tool<\/i><\/a><\/span><\/p>\n<p><span style=\"font-weight: 400;\"><\/span><\/p>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Extending Varnish Cache capabilities with VMODs&#8221; module_id=&#8221;link5&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; custom_padding=&#8221;60px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>Application Architecture Approaches<br \/><em><\/em><\/h2>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Text&#8221; module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><span style=\"font-weight: 400;\">When it comes to selecting an application architecture for your distributed multi-cluster deployment, you have two basic choices: a replicated architecture or service-based (sometimes called segmented) approach. Which approach you select can have a profound implication for whether and how you can take advantage of all that a distributed multi-cluster topology has to offer.<\/span><\/p>\n<h3><strong>Replicated Architecture<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">The simplest way to handle a distributed multi-cluster deployment is to replicate the complete application across multiple different Kubernetes clusters. Each cluster is an exact copy \u2013 a replica \u2013 of the others, and can be physically proximate or distant from each other, as required. Load balancers allocate traffic between the clusters, typically based on origination.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><img decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Artboard-4.svg\" width=\"undefined\" height=\"undefined\" alt=\"\" class=\"wp-image-269355 aligncenter size-full\" \/><i>Image source: <\/i><a href=\"https:\/\/www.redhat.com\/architect\/multi-cluster-kubernetes-architecture\" target=\"_blank\" rel=\"noopener\"><i>Implementing replication using a multi-cluster Kubernetes architecture (Bob Reselman, CC BY-SA 4.0)<\/i><\/a><\/span><\/p>\n<p><span style=\"font-weight: 400;\">Assuming clusters are reasonably distributed, a replicated architecture delivers most, but not all, of the potential advantages described above. What organizations lose, because all clusters are identical, is the ability to fine-tune around performance, cost, regulatory requirements, etc.<\/span><\/p>\n<h3><strong>Service-based Architecture<\/strong><\/h3>\n<p><span style=\"font-weight: 400;\">In a service-based application architecture, an application gets segmented into its constituent components (each a Kubernetes service) which are then assigned to specific clusters based on operational requirements. Services interact with each other across clusters, and the communication layer must be designed to appropriately route user and application traffic. If this sounds familiar, it\u2019s because it mirrors the loose coupling typically seen with a micro-service oriented architecture.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><img decoding=\"async\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Artboard-5.svg\" width=\"undefined\" height=\"undefined\" alt=\"\" class=\"wp-image-269356 aligncenter size-full\" \/><\/span><i><span style=\"font-weight: 400;\">Image source: <\/span><\/i><a href=\"https:\/\/www.redhat.com\/architect\/multi-cluster-kubernetes-architecture\" target=\"_blank\" rel=\"noopener\"><i><span style=\"font-weight: 400;\">A multi-cluster segmentation architecture (Bob Reselman, CC BY-SA 4.0)<\/span><\/i><\/a><\/p>\n<p><span style=\"font-weight: 400;\">A service-based architecture has distinct advantages and disadvantages over a replicated architecture. Its advantages are primarily improved isolation and granular control of data, workloads and compute resources, which in turn facilitate performance tuning\/optimization, compliance, testing\/production, troubleshooting, security, etc. It\u2019s simply more versatile and flexible.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The downside of this approach is added complexity in design and management. But these issues can be mitigated with the right partner.<\/span><\/p>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Extending Varnish Cache capabilities with VMODs&#8221; module_id=&#8221;link6&#8243; module_class=&#8221;dual-org&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; custom_padding=&#8221;60px||||false|false&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<h2>Distributed Multi-Cluster Edge Deployment<br \/><em><\/em><\/h2>\n<p>[\/et_pb_text][et_pb_text admin_label=&#8221;Text&#8221; module_class=&#8221;bold-org li-content link-tel&#8221; _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;0dc03d15-36bb-44ea-920c-2eb30df949ea&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><span style=\"font-weight: 400;\">Ultimately, there are substantial benefits to be had in moving to a multi-cluster Kubernetes topology, and these advantages come together in the form of distributed edge computing. Nothing else delivers the same level of availability, resilience, reduced latency, geographic flexibility, improved isolation, elimination of lock-in, etc.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Organizations looking to take full advantage of edge computing while avoiding the complexity that can be inherent in deploying and operating a service-based architecture or distributed network often need to partner with a provider that understands and can mitigate these challenges. For many, the CloudFlow Edge as a Service (EaaS) solution from Webscale is the fastest and simplest path forward.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Webscale CloudFlow\u2019s EaaS accelerates deployment of your application to the edge through a service-based architecture, allows you to use familiar tooling and methodologies, and provides centralized visibility and simplified management. You gain immediate access to our global network of providers, the sophisticated Webscale CloudFlow control plane, and our patent-pending Adaptive Edge Engine, which intelligently and continuously tunes and configures your edge delivery network to ensure optimal workload placement and efficiency.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Steadily increasing demands on application workloads are driving many organizations to modernize application delivery by embracing multi-cluster Kubernetes deployments across distributed edge cloud topologies. Companies that want to take advantage of the inherent cost, performance and availability benefits without needing to master distributed systems management should look to Webscale\u2019s CloudFlow EaaS as the solution.<\/span><\/p>\n<p>[\/et_pb_text][et_pb_text _builder_version=&#8221;4.23.1&#8243; _module_preset=&#8221;abcb5263-cfc3-42ee-ace8-93972da9f825&#8243; background_color=&#8221;#f2f2f2&#8243; custom_margin=&#8221;90px||||false|false&#8221; custom_padding=&#8221;25px|25px|15px|25px|false|true&#8221; border_radii=&#8221;on|15px|15px|15px|15px&#8221; global_colors_info=&#8221;{}&#8221;]<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" width=\"312\" height=\"98\" src=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Webscale-CloudFlow-Logo-1.svg\" alt=\"\" class=\"size-medium alignleft\" \/>A scalable, and secure solution for deploying and managing containerized applications on public, private or multi-cloud infrastructure.<\/p>\n<p>Designed as a PaaS (Platform-as-a-Service) to run high-performing applications at the lowest cost by proactively monitoring compute resource utilization and automatically rightsizing infrastructure.<\/p>\n<p>Purpose built to enable businesses to optimize cloud-agnostic application delivery in dense containerized environments.<\/p>\n<p>Webscale CloudFlow combines three core patented technologies: Kubernetes Edge Interface (KEI) for simplified container management, Adaptive Edge Engine (AEE) for AI-enabled workload placement, and an available Composable Edge Cloud (CEC) for scalable compute capacity across the cloud vendors of your choice.<\/p>\n<p>[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Why Organizations are Modernizing their Applications with Distributed, Multi-Cluster Kubernetes DeploymentsAn exploration of the substantial advantages and opportunities for evolving from a centralized cluster deployment to a distributed multi-cluster topologyTable of Contents: Introduction Understanding Multi-Cluster Deployments Centralized Kubernetes Container Deployments The Benefits of Distributed Multi-Cluster Deployment Application Architecture Approaches Distributed Multi-Cluster Edge Deployment IntroductionAccording to [&hellip;]<\/p>\n","protected":false},"author":37,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_acf_changed":false,"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","rank_math_lock_modified_date":false,"_aioseo_description":"","_aioseo_keywords":"","_aioseo_og_article_section":"","_aioseo_og_article_tags":"","_aioseo_og_description":"","_aioseo_og_title":"","_aioseo_title":"","_aioseo_twitter_description":"","_aioseo_twitter_title":"","_author_photo":"","_doc_url":"","_dp_original":"","_et_autogenerated_title":"","_et_body_layout_enabled":"","_et_body_layout_id":"","_et_builder_dynamic_assets_loading_attr_threshold":"8","_et_builder_module_features_cache":null,"_et_builder_version":"VB|Divi|4.23.1","_et_default":"","_et_enabled":"","_et_footer_layout_enabled":"","_et_footer_layout_id":"","_et_header_layout_enabled":"","_et_header_layout_id":"","_et_pb_ab_current_shortcode":"[et_pb_split_track id=\"269484\" \/]","_et_pb_ab_subjects":"","_et_pb_built_for_post_type":"page","_et_pb_custom_css":"img.wp-image-268979.aligncenter.size-full {\n    margin: 30px auto;\n}\n#right-cont>.et_pb_row {\n    width: 80%;\n}\n.et-search-form, blockquote {\n    border-color: #00c085;\n}\ndiv#left-col {\n    width: 0%;\n}\ndiv#right-col {\n    width: 97%;\n}\n#table-of-cont{\nleft: calc(540px - 50vw);\nwidth: 300px;\ntop:60px;\n}\n.et_pb_blurb.storefront .et_pb_blurb_container {\n    margin-left: 12%;\n}\n.et_pb_blurb.storefront .et_pb_main_blurb_image {\n    margin: auto;\n}\n.et_pb_blurb.storefront .et_pb_blurb_content {\n    display: flex;\n    border-bottom: 1px solid #ccc;\n}\n.bold-org .et_pb_blurb_content {\n    display: flex;\n    max-width: 100%;\n}\n.bold-org .et_pb_blurb_content .et_pb_main_blurb_image {\n    min-width: 55%;\n  margin: auto !important;\n}\n.bold-org.li-content.link-tel a {\n    color: var(--tel) !important;\n}\n.info-box .et_pb_text_inner {\n    padding: 30px;\n  padding-bottom: 20px;\n    border: 1px solid #ccc;\n    max-width: 900px;\n    margin: auto;\n    border-radius: 15px;\n}\n.info-box h3 {\n    color: var(--tel);\n    font-size: 24px;\n}\n.dual-org .et_pb_text_inner i, .dual-org .et_pb_text_inner i span, .dual-org .et_pb_text_inner em, .dual-org .et_pb_text_inner p i, .dual-org .et_pb_text_inner p em {\n    padding-bottom: 10px;\n    display: block;\n    font-size: 20px;\n  text-align:center;\n  font-weight: bold !important;\n  line-height: 1.4em;\n  max-width: 800px;\n    margin: auto;\n}\n.dual-org h2 strong {\n    color: var(--org);\n  font-weight:600;\n}\n.bold-org .et_pb_text_inner b, .bold-org .et_pb_text_inner strong, .bold-org .et_pb_blurb_description b, .bold-org .et_pb_blurb_description strong, .success-block.bold-org b {\n    color: var(--org);\n}\n.dual-org .et_pb_text_inner h2:after {\n    content: \"\";\n    border-bottom: 2px solid var(--org);\n    padding-bottom: 15px;\n    width: 130px;\n    display: block;\n    margin: auto;\n    text-align: center;\n}\n.et-db #et-boc .et-l #table-of-cont.li-content li::marker {\n    content: \"\";\n}\n.et-db #et-boc .et-l #table-of-cont.li-content li:before {\n    content: \"\";\n    display: block;\n    width: 60px !important;\n    border-top: 2px solid #ccc;\n    position: absolute;\n    left: -50px;\n    margin-top: 12px;\n}\n.et-db #et-boc .et-l #table-of-cont.li-content li:hover:before, .et-db #et-boc .et-l #table-of-cont.li-content li.active:before {\n    border-top: 2px solid var(--org);\n}\n.et-db #et-boc .et-l #table-of-cont.li-content li:hover a, .et-db #et-boc .et-l #table-of-cont.li-content li.active a{\n    color: var(--blk) !important;\n  font-weight: bold;\n  font-size: 0.975em;\n  padding: 5px 0px;\n}\nfooter.et-l.et-l--footer {\n    z-index: 99;\n    position: relative;\n}\n@media (max-width: 540px) {\n  .bold-org .et_pb_blurb_content {\n    display: block;\n}\n  .et_pb_blurb.storefront .et_pb_blurb_content {\n    display: block;\n    border-bottom: 1px solid #ccc;\n}\n.et_pb_blurb.storefront .et_pb_main_blurb_image {\n    margin: 0px;\n    display: block;\n    margin-bottom: 15px;\n    width: 95%;\n}\n}","_et_pb_enable_shortcode_tracking":"","_et_pb_excluded_global_options":"","_et_pb_first_image":"","_et_pb_gutter_width":"2","_et_pb_module_type":"","_et_pb_page_layout":"et_no_sidebar","_et_pb_page_z_index":"","_et_pb_post_hide_nav":"default","_et_pb_row_layout":"","_et_pb_show_page_creation":"off","_et_pb_show_title":"","_et_pb_side_nav":"off","_et_pb_static_css_file":"","_et_pb_truncate_post":"<p><div id=\"top\" class=\"et_pb_section et_pb_section_3 et_pb_with_background et_section_regular\" >\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_row et_pb_row_3 et_pb_equal_columns et_pb_gutters2\">\n\t\t\t\t<div class=\"et_pb_column et_pb_column_4_4 et_pb_column_4  et_pb_css_mix_blend_mode_passthrough et-last-child\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_module et_pb_text et_pb_text_14 grd-vio-blu  et_pb_text_align_center et_pb_bg_layout_dark\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Why Organizations are Modernizing their Applications with Distributed, Multi-Cluster Kubernetes Deployments<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_15 sub-title  et_pb_text_align_center et_pb_bg_layout_dark\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">An exploration of the substantial advantages and opportunities for evolving from a centralized cluster deployment to a distributed multi-cluster topology<\/div>\n\t\t\t<\/div><div class=\"et_pb_button_module_wrapper et_pb_button_1_wrapper et_pb_button_alignment_center et_pb_module \">\n\t\t\t\t<a class=\"et_pb_button et_pb_button_1 learn-more wht-btn mr-at wd-240 et_pb_bg_layout_light\" href=\"https:\/\/www.webscale.com\/wp-content\/uploads\/2023\/12\/Why-Organizations-are-Modernizing-their-Applications-with-Distributed-Multi-Cluster-Kubernetes-Deployments-Tech-Guide.pdf\" target=\"_blank\" rel=\"noopener\">Downloadable Version<\/a>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div><div class=\"et_pb_section et_pb_section_4 et_section_regular\" >\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_row et_pb_row_4\">\n\t\t\t\t<div class=\"et_pb_column et_pb_column_1_4 et_pb_column_5  et_pb_css_mix_blend_mode_passthrough\" id=\"left-col\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div id=\"table-of-cont\" class=\"et_pb_module et_pb_text et_pb_text_16 li-content  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Table of Contents:<\/p>\n<p>Introduction<br \/>\nUnderstanding Multi-Cluster Deployments<br \/>\nCentralized Kubernetes Container Deployments<br \/>\nThe Benefits of Distributed Multi-Cluster Deployment<br \/>\nApplication Architecture Approaches<br \/>\nDistributed Multi-Cluster Edge Deployment<\/div>\n\t\t\t<\/div>\n\t\t\t<\/div><div class=\"et_pb_column et_pb_column_3_4 et_pb_column_6  et_pb_css_mix_blend_mode_passthrough et-last-child\" id=\"right-col\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_module et_pb_code et_pb_code_1\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div><div id=\"right-cont\" class=\"et_pb_section et_pb_section_5 et_section_regular\" >\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_row et_pb_row_5 et_pb_equal_columns et_pb_gutters2\">\n\t\t\t\t<div class=\"et_pb_column et_pb_column_4_4 et_pb_column_7 toc  et_pb_css_mix_blend_mode_passthrough et-last-child\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div id=\"link1\" class=\"et_pb_module et_pb_text et_pb_text_17 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Introduction<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_18 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">According to a survey from the Cloud Native Computing Foundation, more than 92% of respondents worldwide have adopted containers in their production environments, and 83% of those are using Kubernetes to orchestrate those containers.<br \/>\nImage source: CNCF Survey Report (2020)<br \/>\nAs these organizations mature their containerized applications, many are looking to multi-cluster, multi-region, multi-provider deployments.<br \/>\nWhy?<br \/>\nA distributed multi-cluster deployment offers numerous, substantial benefits over centralized clusters in terms of availability, resilience, scalability, performance, cost and more. Let\u2019s look at each benefit in turn, and then discuss what organizations need to consider in adopting a distributed, multi-cluster, multi-region topology.<br \/>\nBut before we do that, it\u2019s important to frame what we mean by distributed, multi-cluster, multi-region deployments.<\/div>\n\t\t\t<\/div><div id=\"link2\" class=\"et_pb_module et_pb_text et_pb_text_19 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Understanding Multi-Cluster Deployments<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_20 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">When looking at containerized Kubernetes environments, it\u2019s important to understand that they vary along several vectors. First and foremost, they may be single or multi-cluster.<br \/>\nWhile the definition of multi-cluster might be obvious to anyone comfortable with basic arithmetic, there are important nuances. A true multi-cluster deployment does not simply mean having more than one cluster. It means orchestrating and managing those clusters as though they were a single platform. While you certainly could set up and control different clusters using separate control planes and tooling, that would be both inefficient and negate many of the benefits to be had.<br \/>\nThat doesn\u2019t mean that clusters need to be the same; far from it. Each cluster is independent, and controls its own provisioning, services, security schema and resources.<br \/>\nImage source: Gartner Blog<br \/>\nSecond, the deployment may be centralized or distributed. It is entirely possible, and often advantageous, to have multiple clusters within a centralized hosting environment, for instance so you can have separate clusters for staging\/testing and production (more on this later). Conversely, you can distribute these clusters more broadly across hosting environments (for instance, on-prem and cloud), providers, even geographies. Each offers its own benefits and challenges, so when looking at a distributed environment it\u2019s important to consider how distributed? As we\u2019ll get into, it\u2019s generally true that the more distributed, the better.<br \/>\nFinally, a deployment can be single-region or multi-region. A distributed multi-cluster deployment that\u2019s limited to North America, for instance, will have different considerations than an application workload that needs to address the needs of users in both North America and the European Union. A truly global deployment will have its own set of unique requirements and challenges.<br \/>\nIn a very real sense, this creates a progression in Kubernetes containerization that typically mirrors application maturity, from single cluster to centralized multi-cluster to distributed multi-cluster to, ultimately, multi-region edge deployments. And it\u2019s at the edge that the true magic happens for users and organizations, as we\u2019ll see.<br \/>\nInterestingly, there\u2019s an important subtext to understand in the relationship between Kubernetes containerization and workload distribution. Simply put, the lightweight portability of containers makes them ideally suited to distribution, while their abstraction facilitates deployment to non-homogenous federated compute platforms. Moreover, Kubernetes adds the orchestration needed to best coordinate this sort of distributed multi-region, multi-cluster topology.<br \/>\nIn other words, organizations that have already adopted Kubernetes are primed to rapidly adopt modern edge deployments for their application workloads. Even those that are still at the single-cluster stage are in position to rapidly leap-frog to the distributed edge. Recent research by SlashData on behalf of the Cloud Native Computing Foundation confirms this correlation between edge, containers, and Kubernetes, noting developers working on edge computing having the highest usage of both containers (76%) and Kubernetes (63%) of surveyed segments.<\/div>\n\t\t\t<\/div><div id=\"link3\" class=\"et_pb_module et_pb_text et_pb_text_21 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Centralized Kubernetes Container Deployments<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_22 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">For most organizations, initial Kubernetes adoption starts with centralized clusters. Primarily this is due to simplicity: whether single or multi-cluster, a centralized deployment eliminates the need to deal with the underlying complexities that can be involved in distributed topologies, as covered in our white paper on Solving the Edge Puzzle.<br \/>\nOnce they\u2019ve started down this path, it\u2019s also the more familiar approach, allowing them to continue using the same tooling and management strategies they\u2019ve become comfortable with (kubectl, Helm Charts, etc.). This combination of simplicity and familiarity holds true whether the deployment is centralized in a data center, or through a single cloud provider or hyper scaler.<br \/>\nWhat these organizations need to weigh, however, is what they\u2019re giving up with centralized clusters. Are the benefits of a distributed multi-cluster deployment worth the added complexity? Moreover, what if we can eliminate that complexity? What then?<br \/>\nBuilding for Edge is a complex and always shifting puzzle to be solved and then managed<\/div>\n\t\t\t<\/div><div id=\"link4\" class=\"et_pb_module et_pb_text et_pb_text_23 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">The Benefits of Distributed Multi-Cluster Deployment<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_24 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">As noted, application maturity and scale tend to drive distributed multi-cluster adoption. The question is: why? What are the advantages and benefits of a distributed topology over centralized clusters? As importantly, does the breadth of distribution matter? Are organizations that adopt a multi-region, multi-provider approach gaining advantage over those that don\u2019t? Let\u2019s dive in.<br \/>\nEvery year there are reports of wide swaths of the internet &#8216;going dark&#8217; and taking down well-known brands and applications. Invariably, those issues are traced back to problems within a particular provider network. Distributed multi-cluster deployments help mitigate those risks.<br \/>\nAvailability and Resiliency<br \/>\nBy mirroring workloads across clusters, you increase availability and resiliency through elimination of single points of failure. At its most basic level, this means using one cluster as a backup or failover should another cluster fail. As you increase cluster distribution outside of a single data center\/cloud instance to stretch across clouds and providers, you further minimize risk \u2013 from failure of single endpoints within a provider network, or even failure of an entire provider network \u2013 by ensuring your application can fail over to other endpoints or providers.<br \/>\nVendor Lock-in<br \/>\nAvoiding reliance on a single vendor is an operational mantra for many organizations, making the ability to distribute workloads not only across locations, but across providers a key advantage. This multi-vendor approach improves pricing flexibility, as well as ensuring better continuity and quality of service. Similarly, this can help mitigate data lock-in, whereby it can become prohibitively expensive to migrate data off a provider\u2019s network.<br \/>\nIn fact, a distributed multi-cluster, multi-vendor approach even helps mitigate managed Kubernetes lock-in, ensuring you are not committed to a particular provider\u2019s version of Kubernetes and any proprietary extensions supported by a specific cloud provider\u2019s managed Kubernetes service.<br \/>\nPerformance and Latency<\/p>\n<p>According to a recent survey of IT decision makers by Lumen, 86% of organizations identify application latency as a key differentiator. And the single best way to reduce latency is to reduce geographic distance by physically placing applications closer to the user base.<\/p>\n<p>Distributed multi-cluster Kubernetes facilitates this strategy, allowing organizations to use an edge topology to process data and application interactions closer to the source. This becomes especially important \u2013 in fact, arguably a necessity \u2013 for applications that have a global user base, where multi-region edge deployments can geographically distribute workloads to best reduce latency while efficiently managing resources (e.g. spinning up\/down infrastructure to adapt to \u201cfollow the sun\u201d or other regional and ad hoc traffic patterns).<br \/>\nOrganizations that elect a centralized approach are, by definition, treating users outside of the primary geography as second-class citizens when it comes to application performance. In fact, this is the primary consideration when organizations choose a particular cloud instance for deployment (e.g. AWS EC2 US-East): where are most of my users based, so those within or close to that region will enjoy a premium experience? The unspoken corollary is that as customers get geographically further from that particular region, application performance, responsiveness, resilience and availability will naturally degrade. In short, this is the default \u201cgood enough\u201d cloud deployment for application workloads that cater largely to a home-grown user base. As these applications mature and broaden adoption, this strategy becomes increasingly tenuous, and organizations find themselves compelled to move workloads to the edge.<br \/>\nScalability<br \/>\nA closely related factor: running multiple distributed clusters also improves an organization\u2019s ability to fine tune and scale workloads as needed, providing greater flexibility than centralized clusters. This scaling is required when an application can no longer handle additional requests effectively, either due to steadily growing volume or episodic spikes.<br \/>\nIt\u2019s important to note that scaling can happen horizontally (scaling out), by adding more machines to the pool of resources, or vertically (scaling up), by adding more power in the form of CPU, RAM, storage, etc. to an existing machine. There are advantages to each, and there\u2019s something to be said for combining both approaches.<br \/>\nA distributed multi-cluster topology facilitates this flexibility in scaling. Among other things, when run on different clusters\/providers\/regions, it becomes significantly easier to identify and understand which particular workloads require scaling (and whether best served by horizontal or vertical scaling), whether that workload scaling is provider- or region-dependent, and ensure adequate resource availability while minimizing load on backend services and databases.<br \/>\nThose familiar with Kubernetes will recognize that one of its strengths is its ability to perform effective autoscaling of resources in response to real time changes in demand. Kubernetes doesn\u2019t support just one autoscaler or autoscaling approach, but three:<\/p>\n<p>Pod replica count &#8211; This involves adding or removing pod replicas in direct response to changes in demand for applications using the Horizontal Pod Autoscaler (HPA).<br \/>\nCluster autoscaler &#8211; As opposed to scaling the number of running pods in a cluster, the cluster autoscaler is used to change the number of nodes in a cluster. This helps manage the costs of running Kubernetes clusters across cloud and edge infrastructure.<br \/>\nVertical pod autoscaling &#8211; the Vertical Pod Autoscaler (VPA) works by increasing or decreasing the CPU and memory resource requests of pod containers. The goal is to match cluster resource allotment to actual usage.<\/p>\n<p>Worth noting for those running centralized workloads on single clusters: a multi-cluster approach might become a requirement for scaling if a company\u2019s application threatens to hit the ceiling for Kubernetes nodes per cluster, currently limited to 5,000.<br \/>\nCost<br \/>\nAnother advantage to a distributed multi-cluster strategy is fine-grained control of costly compute resources. As mentioned above, this can be time-dependent, where global resources are spun down after hours. It can be provider-dependent, where workloads can take advantage of lower cost resources in other regions. Or it can be performance-dependent, whereby services that aren\u2019t particularly sensitive to factors like performance or latency can take advantage of less performant, and less costly, compute resources.<br \/>\nIsolation<br \/>\nA multi-cluster deployment physically and conceptually isolates workloads from each other, blocking communication and sharing of resources. There are several reasons this is desirable. First, it improves security, mitigating risk by limiting the ability of a security issue with one cluster to impact others. It can also have implications for compliance and data privacy (more on that below). It further ensures that the compute resources you intend for a specific cluster are, in fact, available to that cluster, and not consumed by a noisy neighbor.<br \/>\nBut by far the most common rationale behind workload isolation is the desire to separate development, staging\/testing and production environments. By separating clusters, any change to one cluster affects only that particular cluster. This improves issue identification and resolution, supports testing and debugging, and promotes experimentation and optimization. In short, you can ensure a change is working as expected on an isolated cluster before rolling it into production.<br \/>\nAs noted, this isolation is an inherent benefit of multi-cluster vs single cluster deployments, and not particularly dependent on how widely distributed those clusters are \u2013 you could have isolated stage\/test\/production clusters in a centralized hosting environment, for example. That said, when you distribute multiple clusters, this isolation can have important implications.<br \/>\nCompliance Requirements<br \/>\nCompliance is a critical consideration for many organizations. It can be closely related to isolation \u2013 workload isolation is required for compliance with standards such as PCI-DSS, for example \u2013 but it also has broader implications in regard to distributed or multi-region workloads.<br \/>\nIn this instance, different countries and regions have unique rules and regulations governing data handling, and a distributed multi-cluster topology facilitates a region-by-region approach to compliance. A notable example is the European Union\u2019s General Data Protection Regulation (GDPR), which governs data protection and privacy for any user that resides in the European Economic Area (EEA). Importantly, it applies to any company, regardless of location, that is processing and\/or transferring the personal information of individuals residing in the EEA. For instance, GDPR may regulate how and where data is stored, something that is readily addressed through multiple clusters.<br \/>\nSimilarly, other regulatory or governance requirements might stipulate that certain types of data or workloads must remain on-premises; a distributed multi-cluster topology allows an organization to meet this requirement while simultaneously deploying clusters elsewhere to address other business needs (to the edge for lower latency, for example).<br \/>\nImage source: DLA Piper Data Protection Laws of the World interactive tool<\/div>\n\t\t\t<\/div><div id=\"link5\" class=\"et_pb_module et_pb_text et_pb_text_25 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Application Architecture Approaches<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_26 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">When it comes to selecting an application architecture for your distributed multi-cluster deployment, you have two basic choices: a replicated architecture or service-based (sometimes called segmented) approach. Which approach you select can have a profound implication for whether and how you can take advantage of all that a distributed multi-cluster topology has to offer.<br \/>\nReplicated Architecture<br \/>\nThe simplest way to handle a distributed multi-cluster deployment is to replicate the complete application across multiple different Kubernetes clusters. Each cluster is an exact copy \u2013 a replica \u2013 of the others, and can be physically proximate or distant from each other, as required. Load balancers allocate traffic between the clusters, typically based on origination.<br \/>\nImage source: Implementing replication using a multi-cluster Kubernetes architecture (Bob Reselman, CC BY-SA 4.0)<br \/>\nAssuming clusters are reasonably distributed, a replicated architecture delivers most, but not all, of the potential advantages described above. What organizations lose, because all clusters are identical, is the ability to fine-tune around performance, cost, regulatory requirements, etc.<br \/>\nService-based Architecture<br \/>\nIn a service-based application architecture, an application gets segmented into its constituent components (each a Kubernetes service) which are then assigned to specific clusters based on operational requirements. Services interact with each other across clusters, and the communication layer must be designed to appropriately route user and application traffic. If this sounds familiar, it\u2019s because it mirrors the loose coupling typically seen with a micro-service oriented architecture.<br \/>\nImage source: A multi-cluster segmentation architecture (Bob Reselman, CC BY-SA 4.0)<br \/>\nA service-based architecture has distinct advantages and disadvantages over a replicated architecture. Its advantages are primarily improved isolation and granular control of data, workloads and compute resources, which in turn facilitate performance tuning\/optimization, compliance, testing\/production, troubleshooting, security, etc. It\u2019s simply more versatile and flexible.<br \/>\nThe downside of this approach is added complexity in design and management. But these issues can be mitigated with the right partner.<\/div>\n\t\t\t<\/div><div id=\"link6\" class=\"et_pb_module et_pb_text et_pb_text_27 dual-org  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Distributed Multi-Cluster Edge Deployment<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_28 bold-org li-content link-tel  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">Ultimately, there are substantial benefits to be had in moving to a multi-cluster Kubernetes topology, and these advantages come together in the form of distributed edge computing. Nothing else delivers the same level of availability, resilience, reduced latency, geographic flexibility, improved isolation, elimination of lock-in, etc.<br \/>\nOrganizations looking to take full advantage of edge computing while avoiding the complexity that can be inherent in deploying and operating a service-based architecture or distributed network often need to partner with a provider that understands and can mitigate these challenges. For many, the CloudFlow Edge as a Service (EaaS) solution from Webscale is the fastest and simplest path forward.<br \/>\nWebscale CloudFlow\u2019s EaaS accelerates deployment of your application to the edge through a service-based architecture, allows you to use familiar tooling and methodologies, and provides centralized visibility and simplified management. You gain immediate access to our global network of providers, the sophisticated Webscale CloudFlow control plane, and our patent-pending Adaptive Edge Engine, which intelligently and continuously tunes and configures your edge delivery network to ensure optimal workload placement and efficiency.<br \/>\nSteadily increasing demands on application workloads are driving many organizations to modernize application delivery by embracing multi-cluster Kubernetes deployments across distributed edge cloud topologies. Companies that want to take advantage of the inherent cost, performance and availability benefits without needing to master distributed systems management should look to Webscale\u2019s CloudFlow EaaS as the solution.<\/div>\n\t\t\t<\/div><div class=\"et_pb_module et_pb_text et_pb_text_29  et_pb_text_align_left et_pb_bg_layout_light\">\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<div class=\"et_pb_text_inner\">A scalable, and secure solution for deploying and managing containerized applications on public, private or multi-cloud infrastructure.<br \/>\nDesigned as a PaaS (Platform-as-a-Service) to run high-performing applications at the lowest cost by proactively monitoring compute resource utilization and automatically rightsizing infrastructure.<br \/>\nPurpose built to enable businesses to optimize cloud-agnostic application delivery in dense containerized environments.<br \/>\nWebscale CloudFlow combines three core patented technologies: Kubernetes Edge Interface (KEI) for simplified container management, Adaptive Edge Engine (AEE) for AI-enabled workload placement, and an available Composable Edge Cloud (CEC) for scalable compute capacity across the cloud vendors of your choice.<\/div>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t<\/div><\/p>\n","_et_pb_truncate_post_date":"2023-12-19 22:37:25","_et_post_bg_color":"","_et_post_bg_layout":"","_et_template":[],"_et_theme_builder_marked_as_unused":"","_et_use_on":"","_gallery_link_target":"","_global_colors_info":"[]","_lh_copy_from_url-original_file":"","_version_history":"","_wp_old_date":[],"_wpcode_auto_insert":"","_wpcode_auto_insert_number":"","_wpcode_conditional_logic":[],"_wpcode_conditional_logic_enabled":"","_wpcode_library_id":"","_wpcode_library_version":"","_wpcode_location_extra":"","_wpcode_note":"","_wpcode_priority":"","_wpcode_shortcode_attributes":[],"_wpmf_gallery_custom_image_link":"","ao_post_optimize":[],"author_photo":"","doc_url":"","et_enqueued_post_fonts":{"family":{"et-gf-lato":"Lato:100,100italic,300,300italic,regular,italic,700,700italic,900,900italic"},"subset":["latin","latin-ext"],"cache_key":"{\"gph\":0,\"divi\":\"4.24.1\",\"wp\":\"6.6.2\",\"enable_all_character_sets\":\"false\"}"},"rank_math_contentai_score":{"wordCount":"100","linkCount":"0","headingCount":"100","mediaCount":"62.22"},"rank_math_description":"","rank_math_facebook_image":"","rank_math_facebook_image_id":"","rank_math_internal_links_processed":["1"],"rank_math_og_content_image":{"check":"0eabc29a941198f21b3dbd04b0acaf12","images":[269490,269491,269492,269493]},"rank_math_seo_score":"4","rank_math_title":"","version_history":"","wp-smpro-smush-data":[],"wp-smush-animated":"","wpmf_filetype":"","wpmf_order":"","wpmf_size":"","_":"","_bj_lazy_load_skip_post":[],"_divi_filters_post_type":"","_et_dynamic_cached_attributes":{"sticky_position":["top"],"use_custom_gutter":["on"],"button_icon":["&#x24;||divi||400"],"social_network":["facebook","twitter","linkedin","youtube","last_fm"],"header_2_font":"|800|||||||","header_2_font_size":"34px","header_2_text_align":"center","animation_intensity_slide":"10%","animation_duration":"800ms","animation_delay":"15ms","animation_intensity_zoom":"15%","animation_intensity_flip":"15%","animation_intensity_fold":"15%","animation_intensity_roll":"15%","animation_direction":"center","animation_style":"none","background_color_gradient_start":"rgba(255,255,255,0)","background_color_gradient_end":"#fafafa","custom_padding":"120px||0px||false|false","background_color_gradient_stops":"rgba(255,255,255,0) 0%|#fafafa 100%","custom_padding_last_edited":"on|desktop","custom_padding_tablet":"||30px||false|false","custom_padding_phone":"60px||||false|false"},"_et_dynamic_cached_shortcodes":["et_pb_contact_field","et_pb_signup_custom_field","et_pb_social_media_follow_network","et_pb_section","et_pb_row","et_pb_column","et_pb_blurb","et_pb_button","et_pb_code","et_pb_contact_form","et_pb_signup","et_pb_social_media_follow","et_pb_text"],"_et_pb_ab_bounce_rate_limit":"","_et_pb_ab_stats_refresh_interval":[],"_et_pb_content_area_background_color":"","_et_pb_dark_text_color":"","_et_pb_light_text_color":"","_et_pb_section_background_color":"","_job_location":"","_job_locations":"","_links_to":"","_links_to_target":"","_product_image_gallery":"","_schema_code":"","_synced_version":"","_wp_attachment_context":"","_wp_attachment_image_alt":[],"_wpie_source_url":"","_yoast_wpseo_content_score":"","_yoast_wpseo_focuskeywords":"","_yoast_wpseo_metadesc":"","_yoast_wpseo_opengraph-image":"","_yst_prominent_words_version":"","inline_featured_image":[],"job_location":[],"job_locations":"","options":"","original-file":"","post_views_count":"","rank_math_analytic_object_id":"","rank_math_canonical_url":"","rank_math_focus_keyword":[],"rank_math_news_sitemap_robots":"","rank_math_primary_category":"","rank_math_primary_ccategory":"","rank_math_primary_job_locations":"","rank_math_primary_partners_category":"","rank_math_primary_pr_category":"","rank_math_primary_press_release_year":"","rank_math_rich_snippet":"","rank_math_robots":[],"rank_math_schema_Article":[],"rank_math_schema_Organization":[],"rank_math_schema_VideoObject":[],"rank_math_shortcode_schema_s-23675683-fff5-4300-88fe-da8afc8b1bb9":"","rank_math_shortcode_schema_s-307bbc91-c6b1-41aa-950d-c50d435a949c":"","rank_math_shortcode_schema_s-63a052dbc0384":"","rank_math_shortcode_schema_s-63a052dbc039d":"","rank_math_shortcode_schema_s-63a052dbc03a6":"","rank_math_shortcode_schema_s-63a052dbc03aa":"","rank_math_shortcode_schema_s-63a052dbc03b5":"","rank_math_shortcode_schema_s-63a052dbc03ba":"","rank_math_shortcode_schema_s-63a052dbc03bd":"","rank_math_shortcode_schema_s-63b6dd7d53a96":"","rank_math_shortcode_schema_s-63b6dd7d53a9f":"","rank_math_shortcode_schema_s-63b6dd7d53aa2":"","rank_math_shortcode_schema_s-63b6dd7d53aa4":"","rank_math_shortcode_schema_s-63b6dd7d53aa7":"","rank_math_shortcode_schema_s-63b6dd7d53aa9":"","rank_math_shortcode_schema_s-63b6dd7d53aab":"","rank_math_shortcode_schema_s-63b6dd7d53aad":"","rank_math_shortcode_schema_s-63b6dd7d53aaf":"","rank_math_shortcode_schema_s-63c15fcf43311":"","rank_math_shortcode_schema_s-63c15fcf43322":"","rank_math_shortcode_schema_s-63c15fcf43325":"","rank_math_shortcode_schema_s-63c15fcf43327":"","rank_math_shortcode_schema_s-63c15fcf43329":"","rank_math_shortcode_schema_s-63c15fcf4332a":"","rank_math_shortcode_schema_s-63c15fcf4332c":"","rank_math_shortcode_schema_s-63c15fcf4332e":"","rank_math_shortcode_schema_s-63c15fcf43330":"","rank_math_shortcode_schema_s-63f52c5ed40bb":"","rank_math_shortcode_schema_s-6409f40a9b7d5":"","rank_math_shortcode_schema_s-64354a3892419":"","rank_math_shortcode_schema_s-6440158136148":"","rank_math_shortcode_schema_s-6446d2f9353ee":"","rank_math_shortcode_schema_s-6446d2f9353f3":"","rank_math_shortcode_schema_s-6447c0fe4673c":"","rank_math_shortcode_schema_s-64e4d743542d7":"","schema_code":"","smush-complete":"","smush-info":"","smush-stats":[],"synced_version":"","wpmf_remote_video_link":"","_exp":"","_inc":"","_mc4wp_settings":[],"_post-subtitle":"","_pwh_dcfh_contact_email":"","_pwh_dcfh_contact_form_id":"","_pwh_dcfh_form_fields":"","_pwh_dcfh_ip_address":"","_pwh_dcfh_page_id":"","_pwh_dcfh_read_by":"","_pwh_dcfh_referer_url":"","_pwh_dcfh_user_agent":[],"_section1_col1":"","_section1_col2":"","_section1_col3":"","_section1_col4":"","_section2_col1":"","_section2_col2":"","_section2_col3":"","_section2_col4":"","_section2_col5":"","_section2_col6":"","_section3_col1":"","_section3_col2":"","_section3_col3":"","_section3_col4":"","_section3_col5":"","_section3_col6":"","_section4_col1":"","_section4_col2":"","_section4_col3":"","_section4_col4":"","_section4_col5":"","_section4_col6":"","_section5_col1":"","_section5_col2":"","_section5_col3":"","_section5_col4":"","_section5_col5":"","_section5_col6":"","_section6_col1":"","_section6_col2":"","_section6_col3":"","_section6_col4":"","_section6_col5":"","_section6_col6":"","_select_author":"","_test":"","_wp_attachment_backup_sizes":[],"_yoast_wpseo_estimated-reading-time-minutes":[],"_yoast_wpseo_focuskw":[],"_yoast_wpseo_focuskw_text_input":[],"_yoast_wpseo_linkdex":[],"_yoast_wpseo_meta-robots-nofollow":[],"_yoast_wpseo_meta-robots-noindex":[],"_yoast_wpseo_primary_category":[],"_yoast_wpseo_title":[],"_yoast_wpseo_wordproof_timestamp":"","exp":"","inc":"","post-subtitle":[],"rank_math_schema_BlogPosting":[],"section1_col1":"","section1_col2":"","section1_col3":"","section1_col4":"","section2_col1":"","section2_col2":"","section2_col3":"","section2_col4":"","section2_col5":"","section2_col6":"","section3_col1":"","section3_col2":"","section3_col3":"","section3_col4":"","section3_col5":"","section3_col6":"","section4_col1":"","section4_col2":"","section4_col3":"","section4_col4":"","section4_col5":"","section4_col6":"","section5_col1":"","section5_col2":"","section5_col3":"","section5_col4":"","section5_col5":"","section5_col6":"","section6_col1":"","section6_col2":"","section6_col3":"","section6_col4":"","section6_col5":"","section6_col6":"","select_author":"","test":"","footnotes":""},"class_list":["post-269484","page","type-page","status-publish","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/pages\/269484"}],"collection":[{"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/users\/37"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/comments?post=269484"}],"version-history":[{"count":1,"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/pages\/269484\/revisions"}],"predecessor-version":[{"id":271051,"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/pages\/269484\/revisions\/271051"}],"wp:attachment":[{"href":"https:\/\/www.webscale.com\/wp-json\/wp\/v2\/media?parent=269484"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}