istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
istio.io/archive/v1.7/blog/2018/delayering-istio/index.html

26 lines
69 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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.7/blog/2018/delayering-istio/"><meta property="og:image" content="/v1.7/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.7 / 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.7/blog/feed.xml><link rel=alternate type=application/rss+xml title="Istio News" href=/v1.7/news/feed.xml><link rel=alternate type=application/rss+xml title="Istio Blog and News" href=/v1.7/feed.xml><link rel="shortcut icon" href=/v1.7/favicons/favicon.ico><link rel=apple-touch-icon href=/v1.7/favicons/apple-touch-icon-180x180.png sizes=180x180><link rel=icon type=image/png href=/v1.7/favicons/favicon-16x16.png sizes=16x16><link rel=icon type=image/png href=/v1.7/favicons/favicon-32x32.png sizes=32x32><link rel=icon type=image/png href=/v1.7/favicons/android-36x36.png sizes=36x36><link rel=icon type=image/png href=/v1.7/favicons/android-48x48.png sizes=48x48><link rel=icon type=image/png href=/v1.7/favicons/android-72x72.png sizes=72x72><link rel=icon type=image/png href=/v1.7/favicons/android-96x96.png sizes=96xW96><link rel=icon type=image/png href=/v1.7/favicons/android-144x144.png sizes=144x144><link rel=icon type=image/png href=/v1.7/favicons/android-192x192.png sizes=192x192><link rel=manifest href=/v1.7/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.7/css/all.css><script src=/v1.7/js/themes_init.min.js></script></head><body class="language-unknown archive-site"><script>const branchName="release-1.7";const docTitle="Delayering Istio with AppSwitch";const iconFile="\/v1.7/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.7/js/all.min.js data-manual defer></script><header><nav><a id=brand href=/v1.7/><span class=logo><svg viewBox="0 0 300 300"><circle cx="150" cy="150" r="146" stroke-width="2"/><polygon points="65 240 225 240 125 270"/><polygon points="65 230 125 220 125 110"/><polygon points="135 220 225 230 135 30"/></svg></span><span class=name>Istioldie 1.7</span></a><div id=hamburger><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#hamburger"/></svg></div><div id=header-links><a title="Learn how to deploy, use, and operate Istio." href=/v1.7/docs/>Docs</a>
<a class=current title="Posts about using Istio." href=/v1.7/blog/2020/>Blog<i class=dot data-prefix=/blog></i></a>
<a title="Timely news about the Istio project." href=/v1.7/news/>News<i class=dot data-prefix=/news></i></a>
<a title="Frequently Asked Questions about Istio." href=/v1.7/faq/>FAQ</a>
<a title="Get a bit more in-depth info about the Istio project." href=/v1.7/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.7/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://istio.io/archive>Older Releases</a></div></div><button id=search-show title="Search this site" aria-label=Search><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#magnifier"/></svg></button></div><form id=search-form name=cse role=search><input type=hidden name=cx value=002184991200833970123: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.7/search>
<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.7/img/icons.svg#cancel-x"/></svg></button></form></nav></header><div class=banner-container></div><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 2020." aria-controls=card0-body><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#blog"/></svg>2020 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="Announcing the four newest Istio Steering Committee members (September 29, 2020)" href=/v1.7/blog/2020/steering-election-results/>2020 Steering Committee Election Results</a></li><li role=none><a role=treeitem title="The effect of security policies on latency of requests (September 15, 2020)" href=/v1.7/blog/2020/large-scale-security-policy-performance-tests/>Large Scale Security Policy Performance Tests</a></li><li role=none><a role=treeitem title="A new deployment model for Istio (August 27, 2020)" href=/v1.7/blog/2020/new-deployment-model/>Deploying Istio Control Planes Outside the Mesh</a></li><li role=none><a role=treeitem title="The Istio Steering Committee is now in part proportionally allocated to companies based on contribution, and in part elected by community members (August 24, 2020)" href=/v1.7/blog/2020/steering-changes/>Introducing the new Istio steering committee</a></li><li role=none><a role=treeitem title="An alternative sidecar proxy for Istio (July 28, 2020)" href=/v1.7/blog/2020/mosn-proxy/>Using MOSN with Istio: an alternative data plane</a></li><li role=none><a role=treeitem title="An update on trademarks and project governance (July 8, 2020)" href=/v1.7/blog/2020/open-usage/>Open and neutral: transferring our trademarks to the Open Usage Commons</a></li><li role=none><a role=treeitem title="A new way to manage installation of telemetry addons (June 4, 2020)" href=/v1.7/blog/2020/addon-rework/>Reworking our Addon Integrations</a></li><li role=none><a role=treeitem title="Describing the new functionality of Workload Entries (May 21, 2020)" href=/v1.7/blog/2020/workload-entry/>Introducing Workload Entries</a></li><li role=none><a role=treeitem title="Simplifying Istio upgrades by offering safe canary deployments of the control plane (May 19, 2020)" href=/v1.7/blog/2020/multiple-control-planes/>Safely Upgrade Istio using a Canary Control Plane Deployment</a></li><li role=none><a role=treeitem title="Configure the IBM Cloud Kubernetes Service Application Load Balancer to direct traffic to the Istio Ingress gateway with mutual TLS (May 15, 2020)" href=/v1.7/blog/2020/alb-ingress-gateway-iks/>Direct encrypted traffic from IBM Cloud Kubernetes Service Ingress to Istio Ingress Gateway</a></li><li role=none><a role=treeitem title="Community partner tooling of Wasm for Istio by Solo.io (March 25, 2020)" href=/v1.7/blog/2020/wasmhub-istio/>Extended and Improved WebAssemblyHub to Bring the Power of WebAssembly to Envoy and Istio</a></li><li role=none><a role=treeitem title="A mechanism to acquire and share an application certificate and key through mounted files (March 25, 2020)" href=/v1.7/blog/2020/proxy-cert/>Provision a certificate and key for an application without sidecars</a></li><li role=none><a role=treeitem title="Istiod consolidates the Istio control plane components into a single binary (March 19, 2020)" href=/v1.7/blog/2020/istiod/>Introducing istiod: simplifying the control plane</a></li><li role=none><a role=treeitem title="Configuring Wasm extensions for Envoy and Istio declaratively (March 16, 2020)" href=/v1.7/blog/2020/deploy-wasm-declarative/>Declarative WebAssembly deployment for Istio</a></li><li role=none><a role=treeitem title="The future of Istio extensibility using WASM (March 5, 2020)" href=/v1.7/blog/2020/wasm-announce/>Redefining extensibility in proxies - introducing WebAssembly to Envoy and Istio</a></li><li role=none><a role=treeitem title="A vision statement and roadmap for Istio in 2020 (March 3, 2020)" href=/v1.7/blog/2020/tradewinds-2020/>Istio in 2020 - Following the Trade Winds</a></li><li role=none><a role=treeitem title="A more secure way to manage secrets (February 20, 2020)" href=/v1.7/blog/2020/istio-agent/>Remove cross-pod unix domain sockets</a></li><li role=none><a role=treeitem title="Automating Istio configuration for Istio deployments (clusters) that work as a single mesh (January 5, 2020)" href=/v1.7/blog/2020/multi-cluster-mesh-automation/>Multicluster Istio configuration and service discovery using Admiral</a></li></ul></div></div><div class=card><button class="header dynamic" id=card1 title="Blog posts for 2019." aria-controls=card1-body><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#blog"/></svg>2019 Posts</button><div class=body 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="Introduction to Istio's new operator-based installation and control plane management feature (November 14, 2019)" href=/v1.7/blog/2019/introducing-istio-operator/>Introducing the Istio Operator</a></li><li role=none><a role=treeitem title="Introduction, motivation and design principles for the Istio v1beta1 Authorization Policy (November 14, 2019)" href=/v1.7/blog/2019/v1beta1-authorization-policy/>Introducing the Istio v1beta1 Authorization Policy</a></li><li role=none><a role=treeitem title="A more secure way to manage Istio webhooks (November 14, 2019)" href=/v1.7/blog/2019/webhook/>Secure Webhook Management</a></li><li role=none><a role=treeitem title="Provision and manage DNS certificates in Istio (November 14, 2019)" href=/v1.7/blog/2019/dns-cert/>DNS Certificate Management</a></li><li role=none><a role=treeitem title="Getting programmatic access to Istio resources (November 14, 2019)" href=/v1.7/blog/2019/announcing-istio-client-go/>Announcing Istio client-go</a></li><li role=none><a role=treeitem title="Analyze your Istio configuration to detect potential issues and get general insights (November 14, 2019)" href=/v1.7/blog/2019/introducing-istioctl-analyze/>Introducing istioctl analyze</a></li><li role=none><a role=treeitem title="Configure Istio ingress gateway to act as a proxy for external services (October 15, 2019)" href=/v1.7/blog/2019/proxy/>Istio as a Proxy for External Services</a></li><li role=none><a role=treeitem title="Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation (October 2, 2019)" href=/v1.7/blog/2019/isolated-clusters/>Multi-Mesh Deployments for Isolation and Boundary Protection</a></li><li role=none><a role=treeitem title="How can you use Istio to monitor blocked and passthrough external traffic (September 28, 2019)" href=/v1.7/blog/2019/monitoring-external-service-traffic/>Monitoring Blocked and Passthrough External Service Traffic</a></li><li role=none><a role=treeitem title="Using Istio to secure multi-cloud Kubernetes applications with zero code changes (September 18, 2019)" href=/v1.7/blog/2019/app-identity-and-access-adapter/>App Identity and Access Adapter</a></li><li role=none><a role=treeitem title="Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic (September 18, 2019)" href=/v1.7/blog/2019/knative-activator-adapter/>Mixer Adapter for Knative</a></li><li role=none><a role=treeitem title="Taking advantage of Kubernetes trustworthy JWTs to issue certificates for workload instances more securely (September 10, 2019)" href=/v1.7/blog/2019/trustworthy-jwt-sds/>Change in Secret Discovery Service in Istio 1.3</a></li><li role=none><a role=treeitem title="The design principles behind Istio's APIs and how those APIs are evolving (August 5, 2019)" href=/v1.7/blog/2019/evolving-istios-apis/>The Evolution of Istio's APIs</a></li><li role=none><a role=treeitem title="Comparison of alternative solutions to control egress traffic including performance considerations (July 22, 2019)" href=/v1.7/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 (July 10, 2019)" href=/v1.7/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 (July 9, 2019)" href=/v1.7/blog/2019/performance-best-practices/>Best Practices: Benchmarking Service Mesh Performance</a></li><li role=none><a role=treeitem title="Learn how to extend the lifetime of Istio self-signed root certificate (June 7, 2019)" href=/v1.7/blog/2019/root-transition/>Extending Istio Self-Signed Root Certificate Lifetime</a></li><li role=none><a role=treeitem title="Attacks involving egress traffic and requirements for egress traffic control (May 22, 2019)" href=/v1.7/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="An overview of Istio 1.1 performance (March 19, 2019)" href=/v1.7/blog/2019/istio1.1_perf/>Architecting Istio 1.1 for Performance</a></li><li role=none><a role=treeitem title="Configuring Istio route rules in a multicluster service mesh (February 7, 2019)" href=/v1.7/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 (February 5, 2019)" href=/v1.7/blog/2019/sail-the-blog/>Sail the Blog!</a></li><li role=none><a role=treeitem title="Verifies the performance impact of adding an egress gateway (January 31, 2019)" href=/v1.7/blog/2019/egress-performance/>Egress Gateway Performance Investigation</a></li><li role=none><a role=treeitem title="De-mystify how Istio manages to plugin its data-plane components into an existing deployment (January 31, 2019)" href=/v1.7/blog/2019/data-plane-setup/>Demystifying Istio's Sidecar Injection Model</a></li><li role=none><a role=treeitem title="Addressing application startup ordering and startup latency using AppSwitch (January 14, 2019)" href=/v1.7/blog/2019/appswitch/>Sidestepping Dependency Ordering with AppSwitch</a></li><li role=none><a role=treeitem title="Istio has a new discussion board (January 10, 2019)" href=/v1.7/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 (January 10, 2019)" href=/v1.7/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=card2 title="Blog posts for 2018." aria-controls=card2-body><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#blog"/></svg>2018 Posts</button><div class="body default" 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="How to use Istio for traffic management without deploying sidecar proxies (November 21, 2018)" href=/v1.7/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 (November 16, 2018)" href=/v1.7/blog/2018/egress-mongo/>Consuming External MongoDB Services</a></li><li role=none><a role=treeitem title="Istio hosting an all day Twitch stream to celebrate the 1.0 release (August 3, 2018)" href=/v1.7/blog/2018/istio-twitch-stream/>All Day Istio Twitch Stream</a></li><li role=none><a role=treeitem title="How HP is building its next-generation footwear personalization platform on Istio (July 31, 2018)" href=/v1.7/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 (July 30, 2018)">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 (July 20, 2018)" href=/v1.7/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 (July 9, 2018)" href=/v1.7/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 (June 22, 2018)" href=/v1.7/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 (April 25, 2018)" href=/v1.7/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 (April 20, 2018)" href=/v1.7/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 (April 19, 2018)" href=/v1.7/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 (February 8, 2018)" href=/v1.7/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 (February 6, 2018)" href=/v1.7/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 (January 31, 2018)" href=/v1.7/blog/2018/egress-https/>Consuming External Web Services</a></li></ul></div></div><div class=card><button class="header dynamic" id=card3 title="Blog posts for 2017." aria-controls=card3-body><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#blog"/></svg>2017 Posts</button><div class=body aria-labelledby=card3 role=region id=card3-body><ul role=tree aria-expanded=true class=leaf-section aria-labelledby=card3><li role=none><a role=treeitem title="Improving availability and reducing latency (December 7, 2017)" href=/v1.7/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 (November 3, 2017)" href=/v1.7/blog/2017/adapter-model/>Mixer Adapter Model</a></li><li role=none><a role=treeitem title="How Kubernetes Network Policy relates to Istio policy (August 10, 2017)" href=/v1.7/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 (June 14, 2017)" href=/v1.7/blog/2017/0.1-canary/>Canary Deployments using Istio</a></li><li role=none><a role=treeitem title="Istio Authentication 0.1 announcement (May 25, 2017)" href=/v1.7/blog/2017/0.1-auth/>Using Istio to Improve End-to-End Security</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.7/img/icons.svg#pull"/></svg></button><nav aria-label=Breadcrumb><ol><li><a href=/v1.7/ title="Connect, secure, control, and observe services.">Istio</a></li><li><a href=/v1.7/blog/ title="Posts about using Istio.">Blog</a></li><li><a href=/v1.7/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 style=width:100%><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.7/img/icons.svg#calendar"/></svg><span>&nbsp;</span>July 30, 2018</span><span> | </span><span title="4697 words"><svg class="icon"><use xlink:href="/v1.7/img/icons.svg#clock"/></svg><span>&nbsp;</span>23 minute read</span>
<span>&nbsp;</span>
<span></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="&ldquo;Sidecar-aware&rdquo; applications"><a href=#sidecar-aware-applications>&ldquo;Sidecar-aware&rdquo; 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 &ldquo;Auto-Curated&rdquo; service registry"><a href=#platform-adapter-for-appswitch-auto-curated-service-registry>Platform adapter for AppSwitch &ldquo;Auto-Curated&rdquo; 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&rsquo;s not just about performance"><a href=#it-s-not-just-about-performance>It&rsquo;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 warning"><div class=type><svg class="large-icon"><use xlink:href="/v1.7/img/icons.svg#callout-warning"/></svg></div><div class=content>This blog post was written assuming Istio 1, so some of this content may now be outdated.</div></aside></div><div><aside class="callout quote"><div class=type><svg class="large-icon"><use xlink:href="/v1.7/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. &ndash; 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&rsquo;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.7/blog/2018/delayering-istio/memcached.png title="Latency-sensitive application scenario"><img class=element-to-stretch src=/v1.7/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 &ndash; 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&rsquo; 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 &ldquo;influence&rdquo; 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&rsquo;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&rsquo;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.7/blog/2018/delayering-istio/socket-delegation.png title="Socket delegation based connection redirection"><img class=element-to-stretch src=/v1.7/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 &ndash; 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>&ldquo;Sidecar-aware&rdquo; 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 &ndash; 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 &ldquo;fast-path&rdquo; 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 &ldquo;AppSwitch-enabled&rdquo; 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 &ldquo;Auto-Curated&rdquo; 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&rsquo;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&rsquo;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&rsquo;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 &ldquo;application&rdquo;. 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 &ldquo;fast-path&rdquo; 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&rsquo;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&rsquo;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.7/blog/2018/delayering-istio/perf.png title="Latency with and without AppSwitch"><img class=element-to-stretch src=/v1.7/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&rsquo;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 &ndash; no tunneling, bridge or proxies.</p><h2 id=net-net>Net Net</h2><p>I started out with David Wheeler&rsquo;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&rsquo;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.7/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.7/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.7/blog/2020/large-scale-security-policy-performance-tests/>Large Scale Security Policy Performance Tests</a></p><p class=desc>The effect of security policies on latency of requests.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.7/blog/2020/wasmhub-istio/>Extended and Improved WebAssemblyHub to Bring the Power of WebAssembly to Envoy and Istio</a></p><p class=desc>Community partner tooling of Wasm for Istio by Solo.io.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.7/blog/2020/wasm-announce/>Redefining extensibility in proxies - introducing WebAssembly to Envoy and Istio</a></p><p class=desc>The future of Istio extensibility using WASM.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.7/blog/2020/tradewinds-2020/>Istio in 2020 - Following the Trade Winds</a></p><p class=desc>A vision statement and roadmap for Istio in 2020.</p></div><div class=entry><p class=link><a data-skipendnotes=true href=/v1.7/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></nav></article><nav class=pagenav><div class=left><a title="How HP is building its next-generation footwear personalization platform on Istio." href=/v1.7/blog/2018/hp/><svg class="icon"><use xlink:href="/v1.7/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.7/blog/2018/istio-authorization/>Micro-Segmentation with Istio Authorization<svg class="icon"><use xlink:href="/v1.7/img/icons.svg#right-arrow"/></svg></a></div></nav><div id=feedback><div id=feedback-initial>Was this information useful?<br><button class="btn feedback" onclick="sendFeedback('en',1)">Yes</button>
<button class="btn feedback" onclick="sendFeedback('en',0)">No</button></div><div id=feedback-comment>Do you have any suggestions for improvement?<br><br><input id=feedback-textbox type=text placeholder="Help us improve..." data-lang=en></div><div id=feedback-thankyou>Thanks for your feedback!</div></div><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="&ldquo;Sidecar-aware&rdquo; applications"><a href=#sidecar-aware-applications>&ldquo;Sidecar-aware&rdquo; 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 &ldquo;Auto-Curated&rdquo; service registry"><a href=#platform-adapter-for-appswitch-auto-curated-service-registry>Platform adapter for AppSwitch &ldquo;Auto-Curated&rdquo; 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&rsquo;s not just about performance"><a href=#it-s-not-just-about-performance>It&rsquo;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.7.4 now" href=/v1.7/docs/setup/getting-started/#download aria-label="Download Istio"><span>download</span><svg class="icon"><use xlink:href="/v1.7/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.7/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.7/img/icons.svg#stackoverflow"/></svg></a>
<a class=channel title="Interactively discuss issues with the Istio community on Slack" href=https://slack.istio.io aria-label=slack><span>slack</span><svg class="icon"><use xlink:href="/v1.7/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.7/img/icons.svg#twitter"/></svg></a><div class=tag>for everyone</div></div><div class=info><p class=copyright>Istio Archive
1.7.4<br>&copy; 2020 Istio Authors, <a href=https://policies.google.com/privacy>Privacy Policy</a><br>Archived on November 19, 2020</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.7/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.7/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.7/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.7/img/icons.svg#top"/></svg></button></div></body></html>
Reference in New Issue View Git Blame Copy Permalink