mirror of https://github.com/istio/istio.io.git
22 lines
65 KiB
HTML
22 lines
65 KiB
HTML
<!doctype html><html lang=en itemscope itemtype=https://schema.org/WebPage><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=theme-color content=#466BB0><meta name=title content="Delayering Istio with AppSwitch"><meta name=description content="Automatic application onboarding and latency optimizations using AppSwitch."><meta name=author content="Dinesh Subhraveti (AppOrbit and Columbia University)"><meta name=keywords content=microservices,services,mesh,appswitch,performance><meta property=og:title content="Delayering Istio with AppSwitch"><meta property=og:type content=website><meta property=og:description content="Automatic application onboarding and latency optimizations using AppSwitch."><meta property=og:url content=/v1.2/blog/2018/delayering-istio/><meta property=og:image content=/v1.2/img/istio-whitelogo-bluebackground-framed.svg><meta property=og:image:alt content="Istio Logo"><meta property=og:image:width content=112><meta property=og:image:height content=150><meta property=og:site_name content=Istio><meta name=twitter:card content=summary><meta name=twitter:site content=@IstioMesh><title>Istioldie 1.2 / Delayering Istio with AppSwitch</title><script async src="https://www.googletagmanager.com/gtag/js?id=UA-98480406-2"></script><script>window.dataLayer=window.dataLayer||[];function gtag(){dataLayer.push(arguments);}
|
||
gtag('js',new Date());gtag('config','UA-98480406-2');</script><link rel=alternate type=application/rss+xml title="Istio Blog" href=/v1.2/feed.xml><link rel="shortcut icon" href=/v1.2/favicons/favicon.ico><link rel=apple-touch-icon href=/v1.2/favicons/apple-touch-icon-180x180.png sizes=180x180><link rel=icon type=image/png href=/v1.2/favicons/favicon-16x16.png sizes=16x16><link rel=icon type=image/png href=/v1.2/favicons/favicon-32x32.png sizes=32x32><link rel=icon type=image/png href=/v1.2/favicons/android-36x36.png sizes=36x36><link rel=icon type=image/png href=/v1.2/favicons/android-48x48.png sizes=48x48><link rel=icon type=image/png href=/v1.2/favicons/android-72x72.png sizes=72x72><link rel=icon type=image/png href=/v1.2/favicons/android-96x96.png sizes=96xW96><link rel=icon type=image/png href=/v1.2/favicons/android-144x144.png sizes=144x144><link rel=icon type=image/png href=/v1.2/favicons/android-192x192.png sizes=192x192><link rel=manifest href=/v1.2/manifest.json><meta name=apple-mobile-web-app-title content=Istio><meta name=application-name content=Istio><link rel=stylesheet href="https://fonts.googleapis.com/css?family=Work+Sans:400|Chivo:400|Work+Sans:500,300,600,300italic,400italic,500italic,600italic|Chivo:500,300,600,300italic,400italic,500italic,600italic"><link rel=stylesheet href=/v1.2/css/all.css><script src=/v1.2/js/themes_init.min.js></script></head><body class="language-unknown archive-site"><script>const branchName="release-1.2";const docTitle="Delayering Istio with AppSwitch";const iconFile="\/v1.2/img/icons.svg";const buttonCopy='Copy to clipboard';const buttonPrint='Print';const buttonDownload='Download';</script><script src="https://www.google.com/cse/brand?form=search-form" defer></script><script src=/v1.2/js/all.min.js data-manual defer></script><header><nav><a id=brand href=/v1.2/><span class=logo><svg viewBox="0 0 300 300"><circle cx="150" cy="150" r="146" stroke-width="2" /><path d="M65 240H225L125 270z"/><path d="M65 230l60-10V110z"/><path d="M135 220l90 10L135 30z"/></svg></span><span class=name>Istioldie 1.2</span></a><div id=hamburger><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#hamburger"/></svg></div><div id=header-links><a title="Learn how to deploy, use, and operate Istio." href=/v1.2/docs/>Docs</a>
|
||
<span title="Posts about using Istio.">Blog</span>
|
||
<a title="Frequently Asked Questions about Istio." href=/v1.2/faq/>FAQ</a>
|
||
<a title="Get a bit more in-depth info about the Istio project." href=/v1.2/about/>About</a><div class=menu><button id=gearDropdownButton class=menu-trigger title="Options and settings" aria-label="Options and Settings" aria-controls=gearDropdownContent><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#gear"/></svg></button><div id=gearDropdownContent class=menu-content aria-labelledby=gearDropdownButton role=menu><a tabindex=-1 role=menuitem lang=en id=switch-lang-en class=active>English</a>
|
||
<a tabindex=-1 role=menuitem lang=zh id=switch-lang-zh>中文</a><div role=separator></div><a tabindex=-1 role=menuitem class=active id=light-theme-item>Light Theme</a>
|
||
<a tabindex=-1 role=menuitem id=dark-theme-item>Dark Theme</a><div role=separator></div><a tabindex=-1 role=menuitem id=syntax-coloring-item>Color Examples</a><div role=separator></div><h6>Other versions of this site</h6><a tabindex=-1 role=menuitem onclick="navigateToUrlOrRoot('https://istio.io/blog\/2018\/delayering-istio\/');return false;">Current Release</a>
|
||
<a tabindex=-1 role=menuitem onclick="navigateToUrlOrRoot('https://preliminary.istio.io/blog\/2018\/delayering-istio\/');return false;">Next Release</a>
|
||
<a tabindex=-1 role=menuitem href=https://archive.istio.io>Older Releases</a></div></div><button id=search-show title="Search this site" aria-label=Search><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#magnifier"/></svg></button></div><form id=search-form name=cse role=search><input type=hidden name=cx value=013699703217164175118:iwwf17ikgf4>
|
||
<input type=hidden name=ie value=utf-8>
|
||
<input type=hidden name=hl value=en>
|
||
<input type=hidden id=search-page-url value=/v1.2/search.html>
|
||
<input id=search-textbox class=form-control name=q type=search aria-label="Search this site">
|
||
<button id=search-close title="Cancel search" type=reset aria-label="Cancel search"><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#cancel-x"/></svg></button></form></nav></header><main class=primary><div id=sidebar-container class="sidebar-container sidebar-offcanvas"><nav id=sidebar aria-label="Section Navigation"><div class=directory><div class=card><button class="header dynamic" id=card0 title="Blog posts for 2019." aria-controls=card0-body><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#blog"/></svg>2019 Posts</button><div class=body aria-labelledby=card0 role=region id=card0-body><ul role=tree aria-expanded=true class=leaf-section aria-labelledby=card0><li role=none><a role=treeitem title="Istio 1.1.14 patch release." href=/v1.2/blog/2019/announcing-1.1.14/>Announcing Istio 1.1.14</a></li><li role=none><a role=treeitem title="Istio 1.2.5 patch release." href=/v1.2/blog/2019/announcing-1.2.5/>Announcing Istio 1.2.5</a></li><li role=none><a role=treeitem title="Upcoming Istio 1.1 end of life announcement." href=/v1.2/blog/2019/announcing-1.1-eol/>Support for Istio 1.1 ends on September 19th, 2019</a></li><li role=none><a role=treeitem title="Istio 1.1.13 patch release." href=/v1.2/blog/2019/announcing-1.1.13/>Announcing Istio 1.1.13</a></li><li role=none><a role=treeitem title="Istio 1.2.4 patch release." href=/v1.2/blog/2019/announcing-1.2.4/>Announcing Istio 1.2.4</a></li><li role=none><a role=treeitem title="Security vulnerability disclosure for multiple CVEs." href=/v1.2/blog/2019/istio-security-003-004/>Security Update - ISTIO-SECURITY-003 and ISTIO-SECURITY-004</a></li><li role=none><a role=treeitem title="The design principles behind Istio's APIs and how those APIs are evolving." href=/v1.2/blog/2019/evolving-istios-apis/>The Evolution of Istio's APIs</a></li><li role=none><a role=treeitem title="Istio 1.1.12 patch release." href=/v1.2/blog/2019/announcing-1.1.12/>Announcing Istio 1.1.12</a></li><li role=none><a role=treeitem title="Istio 1.2.3 patch release." href=/v1.2/blog/2019/announcing-1.2.3/>Announcing Istio 1.2.3</a></li><li role=none><a role=treeitem title="Comparison of alternative solutions to control egress traffic including performance considerations." href=/v1.2/blog/2019/egress-traffic-control-in-istio-part-3/>Secure Control of Egress Traffic in Istio, part 3</a></li><li role=none><a role=treeitem title="Use Istio Egress Traffic Control to prevent attacks involving egress traffic." href=/v1.2/blog/2019/egress-traffic-control-in-istio-part-2/>Secure Control of Egress Traffic in Istio, part 2</a></li><li role=none><a role=treeitem title="Tools and guidance for evaluating Istio's data plane performance." href=/v1.2/blog/2019/performance-best-practices/>Best Practices: Benchmarking Service Mesh Performance</a></li><li role=none><a role=treeitem title="Istio 1.1.11 patch release." href=/v1.2/blog/2019/announcing-1.1.11/>Announcing Istio 1.1.11</a></li><li role=none><a role=treeitem title="Istio 1.0.9 patch release." href=/v1.2/blog/2019/announcing-1.0.9/>Announcing Istio 1.0.9</a></li><li role=none><a role=treeitem title="Istio 1.1.10 patch release." href=/v1.2/blog/2019/announcing-1.1.10/>Announcing Istio 1.1.10</a></li><li role=none><a role=treeitem title="Istio 1.2.2 patch release." href=/v1.2/blog/2019/announcing-1.2.2/>Announcing Istio 1.2.2</a></li><li role=none><a role=treeitem title="Security vulnerability disclosure for CVE-2019-12995." href=/v1.2/blog/2019/cve-2019-12995/>Security Update - CVE-2019-12995</a></li><li role=none><a role=treeitem title="Istio 1.2.1 patch release." href=/v1.2/blog/2019/announcing-1.2.1/>Announcing Istio 1.2.1</a></li><li role=none><a role=treeitem title="Istio 1.0 end of life announcement." href=/v1.2/blog/2019/announcing-1.0-eol-final/>Support for Istio 1.0 has ended</a></li><li role=none><a role=treeitem title="Istio 1.2 release announcement." href=/v1.2/blog/2019/announcing-1.2/>Announcing Istio 1.2</a></li><li role=none><a role=treeitem title="Istio 1.1.9 patch release." href=/v1.2/blog/2019/announcing-1.1.9/>Announcing Istio 1.1.9</a></li><li role=none><a role=treeitem title="Istio 1.0.8 patch release." href=/v1.2/blog/2019/announcing-1.0.8/>Announcing Istio 1.0.8</a></li><li role=none><a role=treeitem title="Learn how to extend the lifetime of Istio self-signed root certificate." href=/v1.2/blog/2019/root-transition/>Extending Istio Self-Signed Root Certificate Lifetime</a></li><li role=none><a role=treeitem title="Istio 1.1.8 patch release." href=/v1.2/blog/2019/announcing-1.1.8/>Announcing Istio 1.1.8</a></li><li role=none><a role=treeitem title="Security vulnerability disclosure for CVE-2019-12243." href=/v1.2/blog/2019/cve-2019-12243/>Security Update - CVE-2019-12243</a></li><li role=none><a role=treeitem title="Upcoming Istio 1.0 end of life announcement." href=/v1.2/blog/2019/announcing-1.0-eol/>Support for Istio 1.0 ends on June 19th, 2019</a></li><li role=none><a role=treeitem title="Attacks involving egress traffic and requirements for egress traffic control." href=/v1.2/blog/2019/egress-traffic-control-in-istio-part-1/>Secure Control of Egress Traffic in Istio, part 1</a></li><li role=none><a role=treeitem title="Istio 1.1.7 patch release." href=/v1.2/blog/2019/announcing-1.1.7/>Announcing Istio 1.1.7</a></li><li role=none><a role=treeitem title="Istio 1.1.6 patch release." href=/v1.2/blog/2019/announcing-1.1.6/>Announcing Istio 1.1.6</a></li><li role=none><a role=treeitem title="Istio 1.1.5 patch release." href=/v1.2/blog/2019/announcing-1.1.5/>Announcing Istio 1.1.5</a></li><li role=none><a role=treeitem title="Istio 1.1.4 patch release." href=/v1.2/blog/2019/announcing-1.1.4/>Announcing Istio 1.1.4</a></li><li role=none><a role=treeitem title="Istio 1.1.3 patch release." href=/v1.2/blog/2019/announcing-1.1.3/>Announcing Istio 1.1.3</a></li><li role=none><a role=treeitem title="Istio 1.0.7 patch releases." href=/v1.2/blog/2019/announcing-1.0.7/>Announcing Istio 1.0.7 with Important Security Update</a></li><li role=none><a role=treeitem title="Istio 1.1.2 patch release." href=/v1.2/blog/2019/announcing-1.1.2/>Announcing Istio 1.1.2 with Important Security Update</a></li><li role=none><a role=treeitem title="Istio 1.1.1 patch release." href=/v1.2/blog/2019/announcing-1.1.1/>Announcing Istio 1.1.1</a></li><li role=none><a role=treeitem title="Istio 1.1 release announcement." href=/v1.2/blog/2019/announcing-1.1/>Announcing Istio 1.1</a></li><li role=none><a role=treeitem title="An overview of Istio 1.1 performance." href=/v1.2/blog/2019/istio1.1_perf/>Architecting Istio 1.1 for Performance</a></li><li role=none><a role=treeitem title="Istio 1.0.6 patch release." href=/v1.2/blog/2019/announcing-1.0.6/>Announcing Istio 1.0.6</a></li><li role=none><a role=treeitem title="Configuring Istio route rules in a multicluster service mesh." href=/v1.2/blog/2019/multicluster-version-routing/>Version Routing in a Multicluster Service Mesh</a></li><li role=none><a role=treeitem title="Announces the new Istio blog policy." href=/v1.2/blog/2019/sail-the-blog/>Sail the Blog!</a></li><li role=none><a role=treeitem title="De-mystify how Istio manages to plugin its data-plane components into an existing deployment." href=/v1.2/blog/2019/data-plane-setup/>Demystifying Istio's Sidecar Injection Model</a></li><li role=none><a role=treeitem title="Verifies the performance impact of adding an egress gateway." href=/v1.2/blog/2019/egress-performance/>Egress Gateway Performance Investigation</a></li><li role=none><a role=treeitem title="Addressing application startup ordering and startup latency using AppSwitch." href=/v1.2/blog/2019/appswitch/>Sidestepping Dependency Ordering with AppSwitch</a></li><li role=none><a role=treeitem title="Istio has a new discussion board." href=/v1.2/blog/2019/announcing-discuss.istio.io/>Announcing discuss.istio.io</a></li><li role=none><a role=treeitem title="Describes how to deploy a custom ingress gateway using cert-manager manually." href=/v1.2/blog/2019/custom-ingress-gateway/>Deploy a Custom Ingress Gateway Using Cert-Manager</a></li></ul></div></div><div class=card><button class="header dynamic" id=card1 title="Blog posts for 2018." aria-controls=card1-body><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#blog"/></svg>2018 Posts</button><div class="body default" aria-labelledby=card1 role=region id=card1-body><ul role=tree aria-expanded=true class=leaf-section aria-labelledby=card1><li role=none><a role=treeitem title="Istio 1.0.5 patch release." href=/v1.2/blog/2018/announcing-1.0.5/>Announcing Istio 1.0.5</a></li><li role=none><a role=treeitem title="Istio 1.0.4 patch release." href=/v1.2/blog/2018/announcing-1.0.4/>Announcing Istio 1.0.4</a></li><li role=none><a role=treeitem title="How to use Istio for traffic management without deploying sidecar proxies." href=/v1.2/blog/2018/incremental-traffic-management/>Incremental Istio Part 1, Traffic Management</a></li><li role=none><a role=treeitem title="Describes a simple scenario based on Istio's Bookinfo example." href=/v1.2/blog/2018/egress-mongo/>Consuming External MongoDB Services</a></li><li role=none><a role=treeitem title="Istio 1.0.3 patch release." href=/v1.2/blog/2018/announcing-1.0.3/>Announcing Istio 1.0.3</a></li><li role=none><a role=treeitem title="Istio 1.0.2 patch release." href=/v1.2/blog/2018/announcing-1.0.2/>Announcing Istio 1.0.2</a></li><li role=none><a role=treeitem title="Istio 1.0.1 patch release." href=/v1.2/blog/2018/announcing-1.0.1/>Announcing Istio 1.0.1</a></li><li role=none><a role=treeitem title="Istio hosting an all day Twitch stream to celebrate the 1.0 release." href=/v1.2/blog/2018/istio-twitch-stream/>All Day Istio Twitch Stream</a></li><li role=none><a role=treeitem title="Istio is ready for production use with its 1.0 release." href=/v1.2/blog/2018/announcing-1.0/>Announcing Istio 1.0</a></li><li role=none><a role=treeitem title="How HP is building its next-generation footwear personalization platform on Istio." href=/v1.2/blog/2018/hp/>Istio a Game Changer for HP's FitStation Platform</a></li><li role=none><span role=treeitem class=current title="Automatic application onboarding and latency optimizations using AppSwitch.">Delayering Istio with AppSwitch</span></li><li role=none><a role=treeitem title="Describe Istio's authorization feature and how to use it in various use cases." href=/v1.2/blog/2018/istio-authorization/>Micro-Segmentation with Istio Authorization</a></li><li role=none><a role=treeitem title="How to export Istio Access Logs to different sinks like BigQuery, GCS, Pub/Sub through Stackdriver." href=/v1.2/blog/2018/export-logs-through-stackdriver/>Exporting Logs to BigQuery, GCS, Pub/Sub through Stackdriver</a></li><li role=none><a role=treeitem title="Describes how to configure Istio for monitoring and access policies of HTTP egress traffic." href=/v1.2/blog/2018/egress-monitoring-access-control/>Monitoring and Access Policies for HTTP Egress Traffic</a></li><li role=none><a role=treeitem title="Introduction, motivation and design principles for the Istio v1alpha3 routing API." href=/v1.2/blog/2018/v1alpha3-routing/>Introducing the Istio v1alpha3 routing API</a></li><li role=none><a role=treeitem title="Describes how to configure Istio ingress with a network load balancer on AWS." href=/v1.2/blog/2018/aws-nlb/>Configuring Istio Ingress with AWS NLB</a></li><li role=none><a role=treeitem title="Using Kubernetes namespaces and RBAC to create an Istio soft multi-tenancy environment." href=/v1.2/blog/2018/soft-multitenancy/>Istio Soft Multi-Tenancy Support</a></li><li role=none><a role=treeitem title="An introduction to safer, lower-risk deployments and release to production." href=/v1.2/blog/2018/traffic-mirroring/>Traffic Mirroring with Istio for Testing in Production</a></li><li role=none><a role=treeitem title="Describes a simple scenario based on Istio's Bookinfo example." href=/v1.2/blog/2018/egress-tcp/>Consuming External TCP Services</a></li><li role=none><a role=treeitem title="Describes a simple scenario based on Istio's Bookinfo example." href=/v1.2/blog/2018/egress-https/>Consuming External Web Services</a></li></ul></div></div><div class=card><button class="header dynamic" id=card2 title="Blog posts for 2017." aria-controls=card2-body><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#blog"/></svg>2017 Posts</button><div class=body aria-labelledby=card2 role=region id=card2-body><ul role=tree aria-expanded=true class=leaf-section aria-labelledby=card2><li role=none><a role=treeitem title="Improving availability and reducing latency." href=/v1.2/blog/2017/mixer-spof-myth/>Mixer and the SPOF Myth</a></li><li role=none><a role=treeitem title="Provides an overview of Mixer's plug-in architecture." href=/v1.2/blog/2017/adapter-model/>Mixer Adapter Model</a></li><li role=none><a role=treeitem title="Istio 0.2 announcement." href=/v1.2/blog/2017/0.2-announcement/>Announcing Istio 0.2</a></li><li role=none><a role=treeitem title="How Kubernetes Network Policy relates to Istio policy." href=/v1.2/blog/2017/0.1-using-network-policy/>Using Network Policy with Istio</a></li><li role=none><a role=treeitem title="Using Istio to create autoscaled canary deployments." href=/v1.2/blog/2017/0.1-canary/>Canary Deployments using Istio</a></li><li role=none><a role=treeitem title="Istio Auth 0.1 announcement." href=/v1.2/blog/2017/0.1-auth/>Using Istio to Improve End-to-End Security</a></li><li role=none><a role=treeitem title="Istio 0.1 announcement." href=/v1.2/blog/2017/0.1-announcement/>Introducing Istio</a></li></ul></div></div></div></nav></div><div class=article-container><button tabindex=-1 id=sidebar-toggler title="Toggle the navigation bar"><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#pull"/></svg></button><nav aria-label=Breadcrumb><ol><li><a href=/v1.2/ title="Connect, secure, control, and observe services.">Istio</a></li><li><a href=/v1.2/blog/ title="Posts about using Istio.">Blog</a></li><li><a href=/v1.2/blog/2018/ title="Blog posts for 2018.">2018 Posts</a></li><li>Delayering Istio with AppSwitch</li></ol></nav><article aria-labelledby=title><div class=title-area><div><h1 id=title>Delayering Istio with AppSwitch</h1><p class=byline><span>By</span>
|
||
<span class=attribution>Dinesh Subhraveti (AppOrbit and Columbia University)</span><span> | </span><span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#calendar"/></svg><span> </span>July 30, 2018</span><span> | </span><span title="4697 words"><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#clock"/></svg><span> </span>23 minute read</span></p></div></div><nav class=toc-inlined aria-label="Table of Contents"><div><hr><ol><li role=none aria-label="Don’t optimize layers, remove them"><a href=#don-t-optimize-layers-remove-them>Don’t optimize layers, remove them</a><li role=none aria-label=AppSwitch><a href=#appswitch>AppSwitch</a><li role=none aria-label="Delayering the stack"><a href=#delayering-the-stack>Delayering the stack</a><ol><li role=none aria-label="Network Devirtualization"><a href=#network-devirtualization>Network Devirtualization</a><li role=none aria-label="Artifacts of Container Networking"><a href=#artifacts-of-container-networking>Artifacts of Container Networking</a><li role=none aria-label="Skip TCP/IP for colocated endpoints"><a href=#skip-tcp-ip-for-colocated-endpoints>Skip TCP/IP for colocated endpoints</a><li role=none aria-label="Data Pushing Proxy"><a href=#data-pushing-proxy>Data Pushing Proxy</a><li role=none aria-label="Proxyless Protocol Decoding"><a href=#proxyless-protocol-decoding>Proxyless Protocol Decoding</a><li role=none aria-label="Zero-Cost Load Balancer, Firewall and Network Analyzer"><a href=#zero-cost-load-balancer-firewall-and-network-analyzer>Zero-Cost Load Balancer, Firewall and Network Analyzer</a><li role=none aria-label="Traffic Redirection"><a href=#traffic-redirection>Traffic Redirection</a><ol><li role=none aria-label="Socket Delegation"><a href=#socket-delegation>Socket Delegation</a><li role=none aria-label="“Sidecar-Aware” Applications"><a href=#sidecar-aware-applications>“Sidecar-Aware” Applications</a></ol></li></ol></li><li role=none aria-label="How does it all come together?"><a href=#how-does-it-all-come-together>How does it all come together?</a><ol><li role=none aria-label="AppSwitch Client Injection"><a href=#appswitch-client-injection>AppSwitch Client Injection</a><li role=none aria-label="AppSwitch DaemonSet"><a href=#appswitch-daemonset>AppSwitch <code>DaemonSet</code></a><li role=none aria-label="Agent for policy acquisition"><a href=#agent-for-policy-acquisition>Agent for policy acquisition</a><li role=none aria-label="Platform Adapter for AppSwitch “Auto-Curated” Service Registry"><a href=#platform-adapter-for-appswitch-auto-curated-service-registry>Platform Adapter for AppSwitch “Auto-Curated” Service Registry</a><li role=none aria-label="Proxy integration and chaining"><a href=#proxy-integration-and-chaining>Proxy integration and chaining</a></ol></li><li role=none aria-label="It’s not just about performance"><a href=#it-s-not-just-about-performance>It’s not just about performance</a><ol><li role=none aria-label="Automatic application onboarding and policy authoring"><a href=#automatic-application-onboarding-and-policy-authoring>Automatic application onboarding and policy authoring</a><li role=none aria-label="Broader application and protocol support"><a href=#broader-application-and-protocol-support>Broader application and protocol support</a><li role=none aria-label="Client IP preservation and end-to-end principle"><a href=#client-ip-preservation-and-end-to-end-principle>Client IP preservation and end-to-end principle</a><li role=none aria-label="Enhanced application signal with access to encrypted headers"><a href=#enhanced-application-signal-with-access-to-encrypted-headers>Enhanced application signal with access to encrypted headers</a></ol></li><li role=none aria-label="So what’s the net?"><a href=#so-what-s-the-net>So what’s the net?</a><li role=none aria-label="Net Net"><a href=#net-net>Net Net</a><li role=none aria-label=Acknowledgements><a href=#acknowledgements>Acknowledgements</a><li role=none aria-label="See also"><a href=#see-also>See also</a></li></ol><hr></div></nav><div><aside class="callout quote"><div class=type><svg class="large-icon"><use xlink:href="/v1.2/img/icons.svg#callout-quote"/></svg></div><div class=content>All problems in computer science can be solved with another layer, except of course the problem of too many layers. – David Wheeler</div></aside></div><p>The sidecar proxy approach enables a lot of awesomeness. Squarely in the datapath between microservices, the sidecar can precisely tell what the application is trying to do. It can monitor and instrument protocol traffic, not in the bowels of the networking layers but at the application level, to enable deep visibility, access controls and traffic management.</p><p>If we look closely however, there are many intermediate layers that the data has to pass through before the high-value analysis of application-traffic can be performed. Most of those layers are part of the base plumbing infrastructure that are there just to push the data along. In doing so, they add latency to communication and complexity to the overall system.</p><p>Over the years, there has been much collective effort in implementing aggressive fine-grained optimizations within the layers of the network datapath. Each iteration may shave another few microseconds. But then the true necessity of those layers itself has not been questioned.</p><h2 id=don-t-optimize-layers-remove-them>Don’t optimize layers, remove them</h2><p>In my belief, optimizing something is a poor fallback to removing its requirement altogether. That was the goal of my initial work (broken link: <code>https://apporbit.com/a-brief-history-of-containers-from-reality-to-hype/</code>) on OS-level virtualization that led to Linux containers which effectively <a href=https://www.oreilly.com/ideas/the-unwelcome-guest-why-vms-arent-the-solution-for-next-gen-applications>removed virtual machines</a> by running applications directly on the host operating system without requiring an intermediate guest. For a long time the industry was fighting the wrong battle distracted by optimizing VMs rather than removing the additional layer altogether.</p><p>I see the same pattern repeat itself with the connectivity of microservices, and networking in general. The network has been going through the changes that physical servers have gone through a decade earlier. New set of layers and constructs are being introduced. They are being baked deep into the protocol stack and even silicon without adequately considering low-touch alternatives. Perhaps there is a way to remove those additional layers altogether.</p><p>I have been thinking about these problems for some time and believe that an approach similar in concept to containers can be applied to the network stack that would fundamentally simplify how application endpoints are connected across the complexity of many intermediate layers. I have reapplied the same principles from the original work on containers to create <a href=http://appswitch.io>AppSwitch</a>. Similar to the way containers provide an interface that applications can directly consume, AppSwitch plugs directly into well-defined and ubiquitous network API that applications currently use and directly connects application clients to appropriate servers, skipping all intermediate layers. In the end, that’s what networking is all about.</p><p>Before going into the details of how AppSwitch promises to remove unnecessary layers from the Istio stack, let me give a very brief introduction to its architecture. Further details are available at the <a href=https://appswitch.readthedocs.io/en/latest/>documentation</a> page.</p><h2 id=appswitch>AppSwitch</h2><p>Not unlike the container runtime, AppSwitch consists of a client and a daemon that speak over HTTP via a REST API. Both the client and the daemon are built as one self-contained binary, <code>ax</code>. The client transparently plugs into the application and tracks its system calls related to network connectivity and notifies the daemon about their occurrences. As an example, let’s say an application makes the <code>connect(2)</code> system call to the service IP of a Kubernetes service. The AppSwitch client intercepts the connect call, nullifies it and notifies the daemon about its occurrence along with some context that includes the system call arguments. The daemon would then handle the system call, potentially by directly connecting to the Pod IP of the upstream server on behalf of the application.</p><p>It is important to note that no data is forwarded between AppSwitch client and daemon. They are designed to exchange file descriptors (FDs) over a Unix domain socket to avoid having to copy data. Note also that client is not a separate process. Rather it directly runs in the context of the application itself. There is no data copy between the application and AppSwitch client either.</p><h2 id=delayering-the-stack>Delayering the stack</h2><p>Now that we have an idea about what AppSwitch does, let’s look at the layers that it optimizes away from a standard service mesh.</p><h3 id=network-devirtualization>Network Devirtualization</h3><p>Kubernetes offers simple and well-defined network constructs to the microservice applications it runs. In order to support them however, it imposes specific <a href=https://kubernetes.io/docs/concepts/cluster-administration/networking/>requirements</a> on the underlying network. Meeting those requirements is often not easy. The go-to solution of adding another layer is typically adopted to satisfy the requirements. In most cases the additional layer consists of a network overlay that sits between Kubernetes and underlying network. Traffic produced by the applications is encapsulated at the source and decapsulated at the target, which not only costs network resources but also takes up compute cores.</p><p>Because AppSwitch arbitrates what the application sees through its touchpoints with the platform, it projects a consistent virtual view of the underlying network to the application similar to an overlay but without introducing an additional layer of processing along the datapath. Just to draw a parallel to containers, the inside of a container looks and feels like a VM. However the underlying implementation does not intervene along the high-incidence control paths of low-level interrupts etc.</p><p>AppSwitch can be injected into a standard Kubernetes manifest (similar to Istio injection) such that the application’s network is directly handled by AppSwitch bypassing any network overlay underneath. More details to follow in just a bit.</p><h3 id=artifacts-of-container-networking>Artifacts of Container Networking</h3><p>Extending network connectivity from host into the container has been a <a href=https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/>major challenge</a>. New layers of network plumbing were invented explicitly for that purpose. As such, an application running in a container is simply a process on the host. However due to a <a href=http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/>fundamental misalignment</a> between the network abstraction expected by the application and the abstraction exposed by container network namespace, the process cannot directly access the host network. Applications think of networking in terms of sockets or sessions whereas network namespaces expose a device abstraction. Once placed in a network namespace, the process suddenly loses all connectivity. The notion of veth-pair and corresponding tooling were invented just to close that gap. The data would now have to go from a host interface into a virtual switch and then through a veth-pair to the virtual network interface of the container network namespace.</p><p>AppSwitch can effectively remove both the virtual switch and veth-pair layers on both ends of the connection. Since the connections are established by the daemon running on the host using the network that’s already available on the host, there is no need for additional plumbing to bridge host network into the container. The socket FDs created on the host are passed to the application running within the pod’s network namespace. By the time the application receives the FD, all control path work (security checks, connection establishment) is already done and the FD is ready for actual IO.</p><h3 id=skip-tcp-ip-for-colocated-endpoints>Skip TCP/IP for colocated endpoints</h3><p>TCP/IP is the universal protocol medium over which pretty much all communication occurs. But if application endpoints happen to be on the same host, is TCP/IP really required? After all, it does do quite a bit of work and it is quite complex. Unix sockets are explicitly designed for intrahost communication and AppSwitch can transparently switch the communication to occur over a Unix socket for colocated endpoints.</p><p>For each listening socket of an application, AppSwitch maintains two listening sockets, one each for TCP and Unix. When a client tries to connect to a server that happens to be colocated, AppSwitch daemon would choose to connect to the Unix listening socket of the server. The resulting Unix sockets on each end are passed into respective applications. Once a fully connected FD is returned, the application would simply treat it as a bit pipe. The protocol doesn’t really matter. The application may occasionally make protocol specific calls such as <code>getsockname(2)</code> and AppSwitch would handle them in kind. It would present consistent responses such that the application would continue to run on.</p><h3 id=data-pushing-proxy>Data Pushing Proxy</h3><p>As we continue to look for layers to remove, let us also reconsider the requirement of the proxy layer itself. There are times when the role of the proxy may degenerate into a plain data pusher:</p><ul><li>There may not be a need for any protocol decoding</li><li>The protocol may not be recognized by the proxy</li><li>The communication may be encrypted and the proxy cannot access relevant headers</li><li>The application (redis, memcached etc.) may be too latency-sensitive and cannot afford the cost of an intermediate proxy</li></ul><p>In all these cases, the proxy is not different from any low-level plumbing layer. In fact, the latency introduced can be far higher because the same level of optimizations won’t be available to a proxy.</p><p>To illustrate this with an example, consider the application shown below. It consists of a Python app and a set of memcached servers behind it. An upstream memcached server is selected based on connection time routing. Speed is the primary concern here.</p><figure style=width:75%><div class=wrapper-with-intrinsic-ratio style=padding-bottom:38.63965267727931%><a data-skipendnotes=true href=/v1.2/blog/2018/delayering-istio/memcached.png title="Latency-sensitive application scenario"><img class=element-to-stretch src=/v1.2/blog/2018/delayering-istio/memcached.png alt="Proxyless datapath"></a></div><figcaption>Latency-sensitive application scenario</figcaption></figure><p>If we look at the data flow in this setup, the Python app makes a connection to the service IP of memcached. It is redirected to the client-side sidecar. The sidecar routes the connection to one of the memcached servers and copies the data between the two sockets – one connected to the app and another connected to memcached. And the same also occurs on the server side between the server-side sidecar and memcached. The role of proxy at that point is just boring shoveling of bits between the two sockets. However, it ends up adding substantial latency to the end-to-end connection.</p><p>Now let us imagine that the app is somehow made to connect directly to memcached, then the two intermediate proxies could be skipped. The data would flow directly between the app and memcached without any intermediate hops. AppSwitch can arrange for that by transparently tweaking the target address passed by the Python app when it makes the <code>connect(2)</code> system call.</p><h3 id=proxyless-protocol-decoding>Proxyless Protocol Decoding</h3><p>Things are going to get a bit strange here. We have seen that the proxy can be bypassed for cases that don’t involve looking into application traffic. But is there anything we can do even for those other cases? It turns out, yes.</p><p>In a typical communication between microservices, much of the interesting information is exchanged in the initial headers. Headers are followed by body or payload which typically represents bulk of the communication. And once again the proxy degenerates into a data pusher for this part of communication. AppSwitch provides a nifty mechanism to skip proxy for these cases.</p><p>Even though AppSwitch is not a proxy, it <em>does</em> arbitrate connections between application endpoints and it <em>does</em> have access to corresponding socket FDs. Normally, AppSwitch simply passes those FDs to the application. But it can also peek into the initial message received on the connection using the <code>MSG_PEEK</code> option of the <code>recvfrom(2)</code> system call on the socket. It allows AppSwitch to examine application traffic without actually removing it from the socket buffers. When AppSwitch returns the FD to the application and steps out of the datapath, the application would do an actual read on the connection. AppSwitch uses this technique to perform deeper analysis of application-level traffic and implement sophisticated network functions as discussed in the next section, all without getting into the datapath.</p><h3 id=zero-cost-load-balancer-firewall-and-network-analyzer>Zero-Cost Load Balancer, Firewall and Network Analyzer</h3><p>Typical implementations of network functions such as load balancers and firewalls require an intermediate layer that needs to tap into data/packet stream. Kubernetes’ implementation of load balancer (<code>kube-proxy</code>) for example introduces a probe into the packet stream through iptables and Istio implements the same at the proxy layer. But if all that is required is to redirect or drop connections based on policy, it is not really necessary to stay in the datapath during the entire course of the connection. AppSwitch can take care of that much more efficiently by simply manipulating the control path at the API level. Given its intimate proximity to the application, AppSwitch also has easy access to various pieces of application level metrics such as dynamics of stack and heap usage, precisely when a service comes alive, attributes of active connections etc., all of which could potentially form a rich signal for monitoring and analytics.</p><p>To go a step further, AppSwitch can also perform L7 load balancing and firewall functions based on the protocol data that it obtains from the socket buffers. It can synthesize the protocol data and various other signals with the policy information acquired from Pilot to implement a highly efficient form of routing and access control enforcement. It can essentially “influence” the application to connect to the right backend server without requiring any changes to the application or its configuration. It is as if the application itself is infused with policy and traffic-management intelligence. Except in this case, the application can’t escape the influence.</p><p>There is some more black-magic possible that would actually allow modifying the application data stream without getting into the datapath but I am going to save that for a later post. Current implementation of AppSwitch uses a proxy if the use case requires application protocol traffic to be modified. For those cases, AppSwitch provides a highly optimal mechanism to attract traffic to the proxy as discussed in the next section.</p><h3 id=traffic-redirection>Traffic Redirection</h3><p>Before the sidecar proxy can look into application protocol traffic, it needs to first receive the connections. Redirection of connections coming into and going out of the application is currently done by a layer of packet filtering that rewrites packets such that they go to respective sidecars. Creating potentially large number of rules required to represent the redirection policy is tedious. And the process of applying the rules and updating them, as the target subnets to be captured by the sidecar change, is expensive.</p><p>While some of the performance concerns are being addressed by the Linux community, there is another concern related to privilege: iptables rules need to be updated whenever the policy changes. Given the current architecture, all privileged operations are performed in an init container that runs just once at the very beginning before privileges are dropped for the actual application. Since updating iptables rules requires root privileges, there is no way to do that without restarting the application.</p><p>AppSwitch provides a way to redirect application connections without root privilege. As such, an unprivileged application is already able to connect to any host (modulo firewall rules etc.) and the owner of the application should be allowed to change the host address passed by its application via <code>connect(2)</code> without requiring additional privilege.</p><h4 id=socket-delegation>Socket Delegation</h4><p>Let’s see how AppSwitch could help redirect connections without using iptables. Imagine that the application somehow voluntarily passes the socket FDs that it uses for its communication to the sidecar, then there would be no need for iptables. AppSwitch provides a feature called <em>socket delegation</em> that does exactly that. It allows the sidecar to transparently gain access to copies of socket FDs that the application uses for its communication without any changes to the application itself.</p><p>Here are the sequence of steps that would achieve this in the context of the Python application example.</p><ol><li>The application initiates a connection request to the service IP of memcached service.</li><li>The connection request from client is forwarded to the daemon.</li><li>The daemon creates a pair of pre-connected Unix sockets (using <code>socketpair(2)</code> system call).</li><li>It passes one end of the socket pair into the application such that the application would use that socket FD for read/write. It also ensures that the application consistently sees it as a legitimate TCP socket as it expects by interposing all calls that query connection properties.</li><li>The other end is passed to sidecar over a different Unix socket where the daemon exposes its API. Information such as the original destination that the application was connecting to is also conveyed over the same interface.</li></ol><figure style=width:50%><div class=wrapper-with-intrinsic-ratio style=padding-bottom:22.442748091603054%><a data-skipendnotes=true href=/v1.2/blog/2018/delayering-istio/socket-delegation.png title="Socket delegation based connection redirection"><img class=element-to-stretch src=/v1.2/blog/2018/delayering-istio/socket-delegation.png alt="Socket delegation protocol"></a></div><figcaption>Socket delegation based connection redirection</figcaption></figure><p>Once the application and sidecar are connected, the rest happens as usual. Sidecar would initiate a connection to upstream server and proxy data between the socket received from the daemon and the socket connected to upstream server. The main difference here is that sidecar would get the connection, not through the <code>accept(2)</code> system call as it is in the normal case, but from the daemon over the Unix socket. In addition to listening for connections from applications through the normal <code>accept(2)</code> channel, the sidecar proxy would connect to the AppSwitch daemon’s REST endpoint and receive sockets that way.</p><p>For completeness, here are the sequence of steps that would occur on the server side:</p><ol><li>The application receives a connection</li><li>AppSwitch daemon accepts the connection on behalf of the application</li><li>It creates a pair of pre-connected Unix sockets using <code>socketpair(2)</code> system call</li><li>One end of the socket pair is returned to the application through the <code>accept(2)</code> system call</li><li>The other end of the socket pair along with the socket originally accepted by the daemon on behalf of the application is sent to sidecar</li><li>Sidecar would extract the two socket FDs – a Unix socket FD connected to the application and a TCP socket FD connected to the remote client</li><li>Sidecar would read the metadata supplied by the daemon about the remote client and perform its usual operations</li></ol><h4 id=sidecar-aware-applications>“Sidecar-Aware” Applications</h4><p>Socket delegation feature can be very useful for applications that are explicitly aware of the sidecar and wish to take advantage of its features. They can voluntarily delegate their network interactions by passing their sockets to the sidecar using the same feature. In a way, AppSwitch transparently turns every application into a sidecar-aware application.</p><h2 id=how-does-it-all-come-together>How does it all come together?</h2><p>Just to step back, Istio offloads common connectivity concerns from applications to a sidecar proxy that performs those functions on behalf of the application. And AppSwitch simplifies and optimizes the service mesh by sidestepping intermediate layers and invoking the proxy only for cases where it is truly necessary.</p><p>In the rest of this section, I outline how AppSwitch may be integrated with Istio based on a very cursory initial implementation. This is not intended to be anything like a design doc – not every possible way of integration is explored and not every detail is worked out. The intent is to discuss high-level aspects of the implementation to present a rough idea of how the two systems may come together. The key is that AppSwitch would act as a cushion between Istio and a real proxy. It would serve as the “fast-path” for cases that can be performed more efficiently without invoking the sidecar proxy. And for the cases where the proxy is used, it would shorten the datapath by cutting through unnecessary layers. Look at this <a href=http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/>blog</a> for a more detailed walk through of the integration.</p><h3 id=appswitch-client-injection>AppSwitch Client Injection</h3><p>Similar to Istio sidecar-injector, a simple tool called <code>ax-injector</code> injects AppSwitch client into a standard Kubernetes manifest. Injected client transparently monitors the application and intimates AppSwitch daemon of the control path network API events that the application produces.</p><p>It is possible to not require the injection and work with standard Kubernetes manifests if AppSwitch CNI plugin is used. In that case, the CNI plugin would perform necessary injection when it gets the initialization callback. Using injector does have some advantages, however: (1) It works in tightly-controlled environments like GKE (2) It can be easily extended to support other frameworks such as Mesos (3) Same cluster would be able to run standard applications alongside “AppSwitch-enabled” applications.</p><h3 id=appswitch-daemonset>AppSwitch <code>DaemonSet</code></h3><p>AppSwitch daemon can be configured to run as a <code>DaemonSet</code> or as an extension to the application that is directly injected into application manifest. In either case it handles network events coming in from the applications that it supports.</p><h3 id=agent-for-policy-acquisition>Agent for policy acquisition</h3><p>This is the component that conveys policy and configuration dictated by Istio to AppSwitch. It implements xDS API to listen from Pilot and calls appropriate AppSwitch APIs to program the daemon. For example, it allows the load balancing strategy, as specified by <code>istioctl</code>, to be translated into equivalent AppSwitch capability.</p><h3 id=platform-adapter-for-appswitch-auto-curated-service-registry>Platform Adapter for AppSwitch “Auto-Curated” Service Registry</h3><p>Given that AppSwitch is in the control path of applications’ network APIs, it has ready access to the topology of services across the cluster. AppSwitch exposes that information in the form of a service registry that is automatically and (almost) synchronously updated as applications and their services come and go. A new platform adapter for AppSwitch alongside Kubernetes, Eureka etc. would provide the details of upstream services to Istio. This is not strictly necessary but it does make it easier to correlate service endpoints received from Pilot by AppSwitch agent above.</p><h3 id=proxy-integration-and-chaining>Proxy integration and chaining</h3><p>Connections that do require deep scanning and mutation of application traffic are handed off to an external proxy through the socket delegation mechanism discussed earlier. It uses an extended version of <a href=https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt>proxy protocol</a>. In addition to the simple parameters supported by the proxy protocol, a variety of other metadata (including the initial protocol headers obtained from the socket buffers) and live socket FDs (representing application connections) are forwarded to the proxy.</p><p>The proxy can look at the metadata and decide how to proceed. It could respond by accepting the connection to do the proxying or by directing AppSwitch to allow the connection and use the fast-path or to just drop the connection.</p><p>One of the interesting aspects of the mechanism is that, when the proxy accepts a socket from AppSwitch, it can in turn delegate the socket to another proxy. In fact that is how AppSwitch currently works. It uses a simple built-in proxy to examine the metadata and decide whether to handle the connection internally or to hand it off to an external proxy (Envoy). The same mechanism can be potentially extended to allow for a chain of plugins, each looking for a specific signature, with the last one in the chain doing the real proxy work.</p><h2 id=it-s-not-just-about-performance>It’s not just about performance</h2><p>Removing intermediate layers along the datapath is not just about improving performance. Performance is a great side effect, but it <em>is</em> a side effect. There are a number of important advantages to an API level approach.</p><h3 id=automatic-application-onboarding-and-policy-authoring>Automatic application onboarding and policy authoring</h3><p>Before microservices and service mesh, traffic management was done by load balancers and access controls were enforced by firewalls. Applications were identified by IP addresses and DNS names which were relatively static. In fact, that’s still the status quo in most environments. Such environments stand to benefit immensely from service mesh. However a practical and scalable bridge to the new world needs to be provided. The difficulty in transformation is not as much due to lack of features and functionality but the investment required to rethink and reimplement the entire application infrastructure. Currently most of the policy and configuration exists in the form of load balancer and firewall rules. Somehow that existing context needs to be leveraged in providing a scalable path to adopting the service mesh model.</p><p>AppSwitch can substantially ease the onboarding process. It can project the same network environment to the application at the target as its current source environment. Not having any assistance here is typically a non-starter in case of traditional applications which have complex configuration files with static IP addresses or specific DNS names hard-coded in them. AppSwitch could help capture those applications along with their existing configuration and connect them over a service mesh without requiring any changes.</p><h3 id=broader-application-and-protocol-support>Broader application and protocol support</h3><p>HTTP clearly dominates the modern application landscapes but once we talk about traditional applications and environments, we’d encounter all kinds of protocols and transports. Particularly, support for UDP becomes unavoidable. Traditional application servers such as IBM WebSphere rely extensively on UDP. Most multimedia applications use UDP media streams. Of course DNS is probably the most widely used UDP “application”. AppSwitch supports UDP at the API level much the same way as TCP and when it detects a UDP connection, it can transparently handle it in its “fast-path” rather than delegating it to the proxy.</p><h3 id=client-ip-preservation-and-end-to-end-principle>Client IP preservation and end-to-end principle</h3><p>The same mechanism that preserves the source network environment can also preserve client IP addresses as seen by the servers. With a sidecar proxy in place, connection requests come from the proxy rather than the client. As a result, the peer address (IP:port) of the connection as seen by the server would be that of the proxy rather than the client. AppSwitch ensures that the server sees correct address of the client, logs it correctly and any decisions made based on the client address remain valid. More generally, AppSwitch preserves the <a href=https://en.wikipedia.org/wiki/End-to-end_principle>end-to-end principle</a> which is otherwise broken by intermediate layers that obfuscate the true underlying context.</p><h3 id=enhanced-application-signal-with-access-to-encrypted-headers>Enhanced application signal with access to encrypted headers</h3><p>Encrypted traffic completely undermines the ability of the service mesh to analyze application traffic. API level interposition could potentially offer a way around it. Current implementation of AppSwitch gains access to application’s network API at the system call level. However it is possible in principle to influence the application at an API boundary, higher in the stack where application data is not yet encrypted or already decrypted. Ultimately the data is always produced in the clear by the application and then encrypted at some point before it goes out. Since AppSwitch directly runs within the memory context of the application, it is possible to tap into the data higher on the stack where it is still held in clear. Only requirement for this to work is that the API used for encryption should be well-defined and amenable for interposition. Particularly, it requires access to the symbol table of the application binaries. Just to be clear, AppSwitch doesn’t implement this today.</p><h2 id=so-what-s-the-net>So what’s the net?</h2><p>AppSwitch removes a number of layers and processing from the standard service mesh stack. What does all that translate to in terms of performance?</p><p>We ran some initial experiments to characterize the extent of the opportunity for optimization based on the initial integration of AppSwitch discussed earlier. The experiments were run on GKE using <code>fortio-0.11.0</code>, <code>istio-0.8.0</code> and <code>appswitch-0.4.0-2</code>. In case of the proxyless test, AppSwitch daemon was run as a <code>DaemonSet</code> on the Kubernetes cluster and the Fortio pod spec was modified to inject AppSwitch client. These were the only two changes made to the setup. The test was configured to measure the latency of GRPC requests across 100 concurrent connections.</p><figure style=width:100%><div class=wrapper-with-intrinsic-ratio style=padding-bottom:54.66034755134282%><a data-skipendnotes=true href=/v1.2/blog/2018/delayering-istio/perf.png title="Latency with and without AppSwitch"><img class=element-to-stretch src=/v1.2/blog/2018/delayering-istio/perf.png alt="Performance comparison"></a></div><figcaption>Latency with and without AppSwitch</figcaption></figure><p>Initial results indicate a difference of over 18x in p50 latency with and without AppSwitch (3.99ms vs 72.96ms). The difference was around 8x when mixer and access logs were disabled. Clearly the difference was due to sidestepping all those intermediate layers along the datapath. Unix socket optimization wasn’t triggered in case of AppSwitch because client and server pods were scheduled to separate hosts. End-to-end latency of AppSwitch case would have been even lower if the client and server happened to be colocated. Essentially the client and server running in their respective pods of the Kubernetes cluster are directly connected over a TCP socket going over the GKE network – no tunneling, bridge or proxies.</p><h2 id=net-net>Net Net</h2><p>I started out with David Wheeler’s seemingly reasonable quote that says adding another layer is not a solution for the problem of too many layers. And I argued through most of the blog that current network stack already has too many layers and that they should be removed. But isn’t AppSwitch itself a layer?</p><p>Yes, AppSwitch is clearly another layer. However it is one that can remove multiple other layers. In doing so, it seamlessly glues the new service mesh layer with existing layers of traditional network environments. It offsets the cost of sidecar proxy and as Istio graduates to 1.0, it provides a bridge for existing applications and their network environments to transition to the new world of service mesh.</p><p>Perhaps Wheeler’s quote should read:</p><div><aside class="callout quote"><div class=type><svg class="large-icon"><use xlink:href="/v1.2/img/icons.svg#callout-quote"/></svg></div><div class=content>All problems in computer science can be solved with another layer, <strong>even</strong> the problem of too many layers!</div></aside></div><h2 id=acknowledgements>Acknowledgements</h2><p>Thanks to Mandar Jog (Google) for several discussions about the value of AppSwitch for Istio and to the following individuals (in alphabetical order) for their review of early drafts of this blog.</p><ul><li>Frank Budinsky (IBM)</li><li>Lin Sun (IBM)</li><li>Shriram Rajagopalan (VMware)</li></ul><nav id=see-also><h2>See also</h2><div class=see-also><div class=entry><p class=link><a data-skipendnotes=true href=/v1.2/blog/2019/appswitch/>Sidestepping Dependency Ordering with AppSwitch</a></p><p class=desc>Addressing application startup ordering and startup latency using AppSwitch.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.2/blog/2019/performance-best-practices/>Best Practices: Benchmarking Service Mesh Performance</a></p><p class=desc>Tools and guidance for evaluating Istio's data plane performance.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.2/blog/2019/istio1.1_perf/>Architecting Istio 1.1 for Performance</a></p><p class=desc>An overview of Istio 1.1 performance.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.2/blog/2019/egress-performance/>Egress Gateway Performance Investigation</a></p><p class=desc>Verifies the performance impact of adding an egress gateway.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.2/docs/concepts/performance-and-scalability/>Performance and Scalability</a></p><p class=desc>Introduces performance and scalability for Istio.</p></div></div></nav></article><nav class=pagenav><div class=left><a title="How HP is building its next-generation footwear personalization platform on Istio." href=/v1.2/blog/2018/hp/><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#left-arrow"/></svg>Istio a Game Changer for HP's FitStation Platform</a></div><div class=right><a title="Describe Istio's authorization feature and how to use it in various use cases." href=/v1.2/blog/2018/istio-authorization/>Micro-Segmentation with Istio Authorization<svg class="icon"><use xlink:href="/v1.2/img/icons.svg#right-arrow"/></svg></a></div></nav><div id=endnotes-container aria-hidden=true><h2>Links</h2><ol id=endnotes></ol></div></div><div class=toc-container><nav class=toc aria-label="Table of Contents"><div id=toc><ol><li role=none aria-label="Don’t optimize layers, remove them"><a href=#don-t-optimize-layers-remove-them>Don’t optimize layers, remove them</a><li role=none aria-label=AppSwitch><a href=#appswitch>AppSwitch</a><li role=none aria-label="Delayering the stack"><a href=#delayering-the-stack>Delayering the stack</a><ol><li role=none aria-label="Network Devirtualization"><a href=#network-devirtualization>Network Devirtualization</a><li role=none aria-label="Artifacts of Container Networking"><a href=#artifacts-of-container-networking>Artifacts of Container Networking</a><li role=none aria-label="Skip TCP/IP for colocated endpoints"><a href=#skip-tcp-ip-for-colocated-endpoints>Skip TCP/IP for colocated endpoints</a><li role=none aria-label="Data Pushing Proxy"><a href=#data-pushing-proxy>Data Pushing Proxy</a><li role=none aria-label="Proxyless Protocol Decoding"><a href=#proxyless-protocol-decoding>Proxyless Protocol Decoding</a><li role=none aria-label="Zero-Cost Load Balancer, Firewall and Network Analyzer"><a href=#zero-cost-load-balancer-firewall-and-network-analyzer>Zero-Cost Load Balancer, Firewall and Network Analyzer</a><li role=none aria-label="Traffic Redirection"><a href=#traffic-redirection>Traffic Redirection</a><ol><li role=none aria-label="Socket Delegation"><a href=#socket-delegation>Socket Delegation</a><li role=none aria-label="“Sidecar-Aware” Applications"><a href=#sidecar-aware-applications>“Sidecar-Aware” Applications</a></ol></li></ol></li><li role=none aria-label="How does it all come together?"><a href=#how-does-it-all-come-together>How does it all come together?</a><ol><li role=none aria-label="AppSwitch Client Injection"><a href=#appswitch-client-injection>AppSwitch Client Injection</a><li role=none aria-label="AppSwitch DaemonSet"><a href=#appswitch-daemonset>AppSwitch <code>DaemonSet</code></a><li role=none aria-label="Agent for policy acquisition"><a href=#agent-for-policy-acquisition>Agent for policy acquisition</a><li role=none aria-label="Platform Adapter for AppSwitch “Auto-Curated” Service Registry"><a href=#platform-adapter-for-appswitch-auto-curated-service-registry>Platform Adapter for AppSwitch “Auto-Curated” Service Registry</a><li role=none aria-label="Proxy integration and chaining"><a href=#proxy-integration-and-chaining>Proxy integration and chaining</a></ol></li><li role=none aria-label="It’s not just about performance"><a href=#it-s-not-just-about-performance>It’s not just about performance</a><ol><li role=none aria-label="Automatic application onboarding and policy authoring"><a href=#automatic-application-onboarding-and-policy-authoring>Automatic application onboarding and policy authoring</a><li role=none aria-label="Broader application and protocol support"><a href=#broader-application-and-protocol-support>Broader application and protocol support</a><li role=none aria-label="Client IP preservation and end-to-end principle"><a href=#client-ip-preservation-and-end-to-end-principle>Client IP preservation and end-to-end principle</a><li role=none aria-label="Enhanced application signal with access to encrypted headers"><a href=#enhanced-application-signal-with-access-to-encrypted-headers>Enhanced application signal with access to encrypted headers</a></ol></li><li role=none aria-label="So what’s the net?"><a href=#so-what-s-the-net>So what’s the net?</a><li role=none aria-label="Net Net"><a href=#net-net>Net Net</a><li role=none aria-label=Acknowledgements><a href=#acknowledgements>Acknowledgements</a><li role=none aria-label="See also"><a href=#see-also>See also</a></li></ol></div></nav></div></main><footer><div class=user-links><a class=channel title="Go download Istio 1.2.5 now" href=https://github.com/istio/istio/releases/tag/1.2.5 aria-label="Download Istio"><span>download</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#download"/></svg>
|
||
</a><a class=channel title="Join the Istio discussion board to participate in discussions and get help troubleshooting problems" href=https://discuss.istio.io aria-label="Istio discussion board"><span>discuss</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#discourse"/></svg></a>
|
||
<a class=channel title="Stack Overflow is where you can ask questions and find curated answers on deploying, configuring, and using Istio" href=https://stackoverflow.com/questions/tagged/istio aria-label="Stack Overflow"><span>stack overflow</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#stackoverflow"/></svg></a>
|
||
<a class=channel title="Interactively discuss issues with the Istio community on Slack" href=https://istio.slack.com aria-label=slack><span>slack</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#slack"/></svg></a>
|
||
<a class=channel title="Follow us on Twitter to get the latest news" href=https://twitter.com/IstioMesh aria-label=Twitter><span>twitter</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#twitter"/></svg></a><div class=tag>for everyone</div></div><div class=info><p class=copyright>Istio Archive
|
||
1.2.5<br>© 2019 Istio Authors, <a href=https://policies.google.com/privacy>Privacy Policy</a><br>Archived on September 12, 2019</p></div><div class=dev-links><a class=channel title="GitHub is where development takes place on Istio code" href=https://github.com/istio/community aria-label=GitHub><span>github</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#github"/></svg></a>
|
||
<a class=channel title="Access our team drive if you'd like to take a look at the Istio technical design documents" href=https://groups.google.com/forum/#!forum/istio-team-drive-access aria-label="team drive"><span>drive</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#drive"/></svg></a>
|
||
<a class=channel title="If you'd like to contribute to the Istio project, consider participating in our working groups" href=https://github.com/istio/community/blob/master/WORKING-GROUPS.md aria-label="working groups"><span>working groups</span><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#working-groups"/></svg></a><div class=tag>for developers</div></div></footer><div id=scroll-to-top-container aria-hidden=true><button id=scroll-to-top title="Back to top"><svg class="icon"><use xlink:href="/v1.2/img/icons.svg#top"/></svg></button></div></body></html> |