Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Christian Posta, profile picture
Uploaded byChristian Posta
PDF, PPTX1,111 views

Comparing Sidecar-less Service Mesh from Cilium and Istio

The document discusses the evolution of service mesh architectures, focusing on sidecar-less implementations using Cilium and Istio. It highlights the benefits of such architectures, including reduced latency, resource optimization, and enhanced security, while addressing the challenges faced by traditional sidecar proxies. The document emphasizes the separation of Layer 4 and Layer 7 functionality and provides insights into control plane architecture, mutual authentication, and observability features in modern service meshes.

Technology◦
Related topics:
Information Security• cloud-native•Platform Engineering•
Download as PDF, PPTX
Christian Posta - Global Field CTO, Solo.io Sidecar-less Service Mesh Architectures: Cilium and Istio
VP, Global Field CTO, Solo.io @christianposta christian@solo.io /in/ceposta Christian Posta
Service Mesh is Networking Infrastructure
Business Value of A Service Mesh Security Observability Traffic Control Avoid breaches, implement policy, simplify apps, satisfy industry compliance Reduce MTTR (Mean Time To Recover), measure changes, improve operations Improve business continuity, failover, high availability, cost control
The “First” Service Mesh (Linkerd 1.x)
LinkerD (1.x) Architecture
Challenges with LinkerD (1.x) ● JVM-based, difficult to size/constrain ● High tail latencies ● Difficult to require traffic to go through the proxy ● Noisy neighbor problems (unconstrained L7 issues)
The Case For the Sidecar ● Per-host proxy resource consumption is unpredictable ● Per-host proxy must ensure fairness and QoS, or the application risks starvation ● Upgrades, blast radius, etc, affect all workloads on that node (or worse) ● Per-host proxy must account for the key material for all workloads on the node, becomes a new attack vector The case for the sidecar: https://thenewstack.io/ebpf-or-not-sidecars-are-the-future-of-the-service-mesh/
Move Networking Closer to Application
Move Networking Closer to Application
Benefits of Sidecar Containers ● Transparent * ● Part of the application lifecycle ● Finer grained, can associate workload identity (SPIFFE, etc), pod-level encryption ● Single-tenant (ie, per workload identity) ● No “noisy neighbor problems” ● Customizable
Sidecars were a “necessary point in time implementation” to deliver networking value
Drawbacks to Service Mesh Sidecars ● Container race conditions ● Security: cert/key material ● Difficult to size / easy to over-provision ● Jobs/CronJobs have issues ● Apps need to be aware ● Can be circumvented ● Upgrades can be challenging
Goodbye Sidecar, Hello eBPF? https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/
What can eBPF do? https://www.solo.io/blog/ebpf-for-service-mesh/ https://www.youtube.com/watch?v=heDVglDRDNw
TL;DR, You Still Need a Proxy Separation of L7 and L4
Digging into Cilium and Istio Service Mesh (sidecar-less, service-mesh implementations)
Benefits of a Sidecar-less Service Mesh ● Fully transparent, cannot opt-out ● Optimize networking paths/reduce latency in service calls ● Reduce overall resource allocation (Mem/CPU) ● Eliminate in-Pod container race conditions ● Eliminate pod injection ● Remove security credentials from the app ● Implementations vary, may have more benefits
Cilium ● eBPF based L3/L4 data plane ● Container networking (Kubernetes needs a CNI) ● Networking flows/observability ● Kubernetes NetworkPolicy (and more advanced NetworkPolicy) ● KubeProxy replacement ● Lay the foundation for a sidecar-less service mesh
Cilium Service Mesh Functionality ● Ingress (Gateway API) ● Mutual Authentication (beta) ● CiliumNetworkPolicy ● Direct Envoy Configuration
Istio ● Stable, mature, multi-cluster L4/L7 service mesh ● Diverse, multi-vendor CNCF community, broad industry adoption ● Based on Envoy Proxy ● Workload identity based on SPIFFE ● Authentication (mTLS) and Authorization ● Observability, tracing, audit logging ● Recently added support for sidecarless (ambient) ● CNI/Kubernetes independent
Istio (Ambient Mode) ● Explicitly separate L4 and L7 into composable pieces ● Supports any CNI (works great on Cilium CNI) ● L7 authorization policy, observability, traffic control ● Standards based mTLS mutual authentication (FIPS, compliance, etc) ● Gateway API support ● Production ready in next Istio release (v1.22)
Sidecar-less Service Mesh Architecture ● Control Plane ● Data Plane ● Mutual Authentication / mTLS ● Observability ● Traffic Control
Control Plane Architecture and API
Cilium Control Plane Architecture
Cilium Control Plane API ● Gateway API ● CiliumNetworkPolicy ● CiliumEnvoyConfig (caution) ● CiliumClusterwideEnvoyConfig (caution)
Istio Control Plane Architecture https://github.com/cncf/xds
Istio Control Plane API ● Gateway API ● VirtualService ● DestinationRule ● AuthorizationPolicy ● PeerAuthentication ● RequestAuthentication ● JWTRule
Data Plane Architecture
Cilium (L4)
Cilium (L7) Separation of L4 and L7
Cilium (L7)
Cilium (L7)
Istio Ambient Mode (L4)
Istio Ambient Mode (L4) https://istio.io/latest/blog/2024/inpod-traffic-redirection-ambient/
Istio Ambient Mode (L4)
Istio Ambient Mode (L7)
Istio Ambient Mode (L7) Separation of L4 and L7
Mutual Authentication / mTLS
Cilium (mutual authentication)
Cilium (mutual authentication)
Cilium (mutual authentication)
Cilium (mutual authentication)
Cilium (mutual authentication)
Cilium (mutual authentication) https://thenewstack.io/how-ciliums-mutual-authentication-can-compromise-security/ Could network cache-based identity be mistaken?
Istio Ambient Mode mTLS
Istio Ambient Mode mTLS ● Uses standard mTLS ● Peer-to-peer tunnelling ● mTLS originates directly from Pod network namespace ● Identity model based on SPIFFE ● Standard x509 / expiry / rotation ● No caching, state, or eventual consistency issues ● Can be combined with Cilium CNI
Observability
Cilium (Observability) https://github.com/cilium/hubble
Istio Ambient Mode Observability
Traffic Control / Ingress
Cilium (Ingress / Gateway API)
Istio (Ingress / Gateway API)
Recap
Service Mesh Functionality Separation of L7 and L4
Cilium Service Mesh Architecture Recap Separation of L7 and L4
Cilium Service Mesh Architecture Recap Separation of L7 and L4
Cilium Service Mesh Architecture Recap
Istio (Ambient Mode) Separation of L7 and L4
Architecture Recap Separation of L7 and L4
Istio (Ambient Mode)
More Service Mesh Talks (Friday!) ● “At the intersection of Cilium CNI and Service Mesh - Who has the right of way” - Christine Kim (Isovalent) Friday 11:00 ● Next level security: mTLS in Istio Multi Cluster with Spire” - Eduardo Bonilla & Samuel Veloso (Solo.io) Friday 16:00
The CAKES Stack An Open Source Modern Cloud Networking Stack
Thank you! Please reach out with any questions! VP, Global Field CTO, Solo.io @christianposta christian@solo.io /in/ceposta
Thank you! Please reach out with any questions! VP, Global Field CTO, Solo.io @christianposta christian@solo.io /in/ceposta Slides Online: