Cloud Native Austin

April 2020

Today’s Meetup:

 

KUDO - Kubernetes Operators the Easy Way
 

Meshery - the service mesh management plane

6:00pm-6:20pm: Welcome, Socializing, and Announcements

6:20pm-8:00pm:
 

  • Talk 1: Kubernetes Universal Declarative Operator (KUDO)
    Michael Taunenbaum and Gerred Dillion, D2iQ
     

  • Talk 2: Meshery, the service mesh management plane
    Lee Calcote, Layer5

 

Agenda

Thank you to our past sponsors & volunteers

 

Your Logo Here

 

Us

Local Organizers

Vendor Neutral

Fosters of Community

Open Source Friendly

Speak

Sponsor

See forms on Cloud Native Austin's meetup page

You

 

Who’s Hiring?

 

Who’s Looking?

 

Other?

 

Announcements

Matt Jarvis
Senior Director, Community & Open Source Program Office D2iQ
@mattj_io

Tonight’s Sponsor

Open Source 101 Austin


 

Upcoming Events

Todd Lewis (@toddlew) 

Open Source 101 Austin


 

Tuesday, May 12

Presentations

#cloudnativeATX

Connect

 

Participate

 

Contribute

 

 

 

Join Slack http://slack.layer5.io

Subscribe to newsletter https://layer5.io/subscribe

Lee Calcote

linkedin.com/in/leecalcote

@lcalcote

gingergeek.com

lee@calcotestudios.com

cloud native and its management

calcotestudios.com/talks

github.com/leecalcote

Service Mesh Patterns

Developer Velocity
(aka speed)

Development Process

Application Architecture

Deployment and Packaging

Application Infrastructure

Agile

Waterfall

DevOps

N-Tier

Monolithic

Microservices

Cloud

Containers

Physical Servers

Virtual Servers

Data Center

Hosted

Evolution to Cloud Native

λ

Functions

Serverless

Events

SRE

(Unikernels)

@layer5

Service Meshes

Stacking up Service Mesh

analogous to the serverless value prop

...but for long-lived services (much the world's workloads)

IaaS

CaaS

PaaS

SaaS

Service Mesh

  • Short-lived

  • Event-driven

  • Long-lived

  • Process-driven

  • Always hot

FaaS

@layer5

bare metal

     AND

          virtual machines

               AND

                    containers

                         AND

                              unikernels

                                   AND

                                        functions

the future is AND not OR

We hold these truths to be self-evident...

@layer5

@layer5

Third step in Cloud Native journey

Meshery is interoperable with each abstraction.

Container

Orchestrator

Mesh

5.5 years
(Jun 2014)

4.5 years
(Jul 2015)

3 years
(Apr 2017)

5.5 years ago
(Jun 2014)

7 years ago
(Mar 2013)

4 years ago
(Feb 2016)

v1.0

Announced

DEV

OPS

Decoupling at Layer 5

where Dev and Ops meet

Problem: too much infrastructure code in services

@layer5

@layer5

layer5.io/landscape

It's meshy out there.

@layer5

Service mesh abstractions to the rescue

Meshery is interoperable with each abstraction.

Service Mesh Interface

(SMI)

Multi-Vendor Service Mesh Interoperation (Hamlet)

Service Mesh Performance Specification (SMPS)

A standard interface for service meshes on Kubernetes.

A set of API standards for enabling service mesh federation.

A format for describing and capturing service mesh performance.

Contrasting Performance

layer5.io/meshery

Pod Memory Usage

Application resource consumption

@layer5

layer5.io/meshery

Pod CPU Usage

Application resource consumption

@layer5

layer5.io/meshery

Control Plane Memory

Istio

Linkerd

Consul

@layer5

layer5.io/meshery

Control Plane CPU

Istio

Linkerd

Consul

@layer5

Service Mesh Architectures

Service Mesh Architecture

Data Plane

  • Touches every packet/request in the system.

  • Responsible for service discovery, health checking, routing, load balancing, authentication, authorization, and observability.

Ingress Gateway

Egress Gateway

@layer5

Service Mesh Architecture

No control plane? Not a service mesh.

Control Plane

  • Provides policy, configuration, and platform integration.

  • Takes a set of isolated stateless sidecar proxies and turns them into a service mesh.

  • Does not touch any packets/requests in the data path.

Data Plane

  • Touches every packet/request in the system.

  • Responsible for service discovery, health checking, routing, load balancing, authentication, authorization, and observability.

Ingress Gateway

Egress Gateway

@layer5

Service Mesh Architecture

Control Plane

Data Plane

  • Touches every packet/request in the system.

  • Responsible for service discovery, health checking, routing, load balancing, authentication, authorization, and observability.

  • Provides policy, configuration, and platform integration.

  • Takes a set of isolated stateless sidecar proxies and turns them into a service mesh.

  • Does not touch any packets/requests in the data path.

You need a management plane.

Ingress Gateway

Management
Plane

  • Provides monitoring, backend system integration, expanded policy and application configuration.

Egress Gateway

@layer5

Pilot

Citadel

Mixer

Control Plane

Data Plane

istio-system namespace

policy check

Foo Pod

Proxy Sidecar

Service Foo

tls certs

discovery & config

Foo Container

Bar Pod

Proxy Sidecar

Service Bar

Bar Container

Out-of-band telemetry propagation

telemetry

 

reports

Control flow

application traffic

Application traffic

application namespace

telemetry reports

Istio Architecture

Galley

Ingress Gateway

Egress Gateway

@layer5

Control Plane

Data Plane

octa-system namespace

policy check

Foo Pod

Proxy
Sidecar

Service Foo

discovery & config

Foo Container

Bar Pod

Service Bar

Bar Container

Out-of-band telemetry propagation

telemetry

 

reports

Control flow

application traffic

Application traffic

application namespace

telemetry reports

Octarine Architecture

Policy
Engine

Security Engine

Visibility
Engine

+

Proxy
Sidecar

+

@layer5

Control Plane

Data Plane

linkerd-system namespace

Foo Pod

Proxy Sidecar

Service Foo

Foo Container

Bar Pod

Proxy Sidecar

Service Bar

Bar Container

Out-of-band telemetry propagation

telemetry

 

scarping

Control flow during request processing

application traffic

Application traffic

application namespace

telemetry scraping

Architecture

destination

Prometheus

Grafana

tap

web

CLI

proxy-api

public-api

Linkerd

proxy-injector

@layer5

Service Mesh Deployment Models

Client

Edge Cache

Istio Gateway

(envoy)

Cache Generator

Collection of VMs running APIs

service mesh

Istio VirtualService

Istio VirtualService

Istio ServiceEntry

Situation:

  • existing services running on VMs (that have little to no service-to-service traffic).

  • nearly all traffic flows from client to the service and back to client.

 

Benefits:

  • gain granular traffic control (e.g path rewrites).

  • detailed service monitoring without immediately deploying a thousand sidecars.

Ingress

Istio - The Weather Company's Journey

Out-of-band telemetry propagation

Application traffic

@lcalcote

Control flow

Proxy per Node

Service A

Service A

Service A

linkerd

Node (server)

Service A

Service A

Service B

linkerd

Node (server)

Service A

Service A

Service C

linkerd

Node (server)

Advantages:

  • Less (memory) overhead.

  • Simpler distribution of configuration information.

  • primarily physical or virtual server based; good for large monolithic applications.
     

Disadvantages:

  • Coarse support for encryption of service-to-service communication, instead host-to-host encryption and authentication policies.

  • Blast radius of a proxy failure includes all applications on the node, which is essentially equivalent to losing the node itself.

  • Not a transparent entity, services must be aware of its existence.

layer5.io/books

Advantages:

  • Good starting point for building a brand-new microservices architecture or for migrating from a monolith.

Disadvantages:

  • When the number of services increase, it becomes difficult to manage.

Router "Mesh"

Fabric Model

Advantages:

  • Granular encryption of service-to-service communication.

  • Can be gradually added to an existing cluster without central coordination.

Disadvantages:

  • Lack of central coordination. Difficult to scale operationally.

Ingress or Edge Proxy

Advantages:

  • Works with existing services that can be broken down over time.

Disadvantages:

  • Is missing the benefits of service-to-service visibility and control.

Configuration

Security

Telemetry

Control Plane

Data
Plane

service mesh ns

Foo Pod

Proxy Sidecar

Service Foo

Foo Container

Bar Pod

Proxy Sidecar

Service Bar

Bar Container

Out-of-band telemetry propagation

Control flow

Application traffic

application namespace

Istio v1.0 Multi-Cluster

@lcalcote

Ingress Gateway

kube-api

kube-system

Barz Pod

Proxy Sidecar

Service Bar

Baz Container

application namespace

kube-api

kube-system

LOCAL CLUSTER

REMOTE CLUSTER

Egress Gateway

injector

Shared Root CA

Core Infrastructure
Initative

Service Mesh Interface (SMI)

Configuration

Security

Telemetry

Control Plane

Data
Plane

service mesh ns

Foo Pod

Proxy Sidecar

Service Foo

Foo Container

Bar Pod

Proxy Sidecar

Service Bar

Bar Container

Out-of-band telemetry propagation

Control flow

application

traffic

Application traffic

application namespace

Meshery Architecture

Ingress Gateway

Egress Gateway

Management
Plane

meshery

adapter

gRPC

kube-api

kube-system

@layer5

generated load

http / gRPC traffic

meshery.io

Deploy Management Plane

Management
Plane

Provides expanded governance, backend system integration, multi-mesh, federation, expanded policy, and dynamic application and mesh configuration.

Control Plane

Data Plane

brew tap layer5io/tap
brew install mesheryctl
mesheryctl start

Install Meshery

@lcalcote

Using brew

Using bash

curl -L https://git.io/meshery | sudo bash -  
kubectl config view --minify --flatten > config_minikube.yaml

If using minikube:

Lee Calcote

cloud native and its management

@lcalcote

calcotestudios.com/talks

linkedin.com/in/leecalcote

layer5.io/subscribe