• Distinct from the app itself What is a mesh? Endpoint management • Constituency, health-checking Traffic management • Routing, splitting, fault injection
• Distinct from the app itself Identity • Who is sending/receiving What is a mesh? Endpoint management • Constituency, health-checking Traffic management • Routing, splitting, fault injection
• Distinct from the app itself Identity • Who is sending/receiving What is a mesh? Endpoint management • Constituency, health-checking Traffic management • Routing, splitting, fault injection Access control • Who may send/receive
• Distinct from the app itself Identity • Who is sending/receiving Telemetry • What happened What is a mesh? Endpoint management • Constituency, health-checking Traffic management • Routing, splitting, fault injection Access control • Who may send/receive
• Distinct from the app itself Identity • Who is sending/receiving Telemetry • What happened What is a mesh? Endpoint management • Constituency, health-checking Traffic management • Routing, splitting, fault injection Access control • Who may send/receive Encryption & zero-trust • Why do I believe it
proxies • Sidecars, middle-proxies, gateways Work best at L7 • e.g. HTTP, but not exclusively Lots of thinking, experimenting, and development happening here! The mesh market today https://www.flickr.com/photos/foxypar4/2124673642
APIs in Kubernetes Generally described by VIPs Service type=LoadBalancer often has an “internal” option Plugs into DNS automatically Service virtualization
sets of Endpoints Automatically managed by Kubernetes Unhealthy Pods are automatically removed from endpoint sets EndpointSlice is a new, more flexible API Endpoint management
frequently Well, ACTUALLY... The Node’s kernel is the proxy • The root netns considers every packet • Policy is applied (iptables, ipvs, eBPF, etc) • Routing decisions are made • Connections are tracked Client-side load-balancing
at L4 • Traffic split by labels & selectors Very coarse - barely useful, really Ingress is slightly more capable • Hostnames and paths • Non-portable annotations • Only targets Kubernetes Services • More extensible for v1 GA • Not really what Ingress was designed for Traffic management
of trust - cluster CA Does not automatically use identity on-the-wire • Some implementations offer this Does not associate identity with NetworkPolicy Identity
to which server Pods Describes a DAG of “allow” Described in terms of selectors • Not deployments Does not consider identity by default • Some implementations off this Access control
No encryption on-the-wire by default • Apps must do their own TLS • Can use Kubernetes API server for some, but not automatic Several 3rd party implementations Encryption & zero-trust
we have a cluster mesh! This does not invalidate “real” meshes If anything it validates them It proves that mesh is a good idea Lots of R&D on mesh - we should pay attention What next?
mesh should be easy and incremental Kubernetes should be general-purpose enough to handle most workloads We should start to break down the walls around clusters: there are other things we want to integrate with Tim’s opinions: 1/2
full-featured, opinionated, L7 service mesh at this time We should embrace our inner mesh and learn from the experiences of others We should lean on the extensibility and pluggability that has made Kubernetes successful Tim’s opinions: 2/2
• Details are fuzzy, demand is not Services kind of allow this already • A bit clunky EndpointSlice is better - is that good enough? Out-of-core CRDs+controllers ==> EndpointSlice Non-Pod endpoints
Better API and data model Maybe better L4 at the same time • A grand unified model • Incremental API Focus on the “right” extension points Requires plug-in implementations KEP coming soon! Replace Ingress
assume it is required • It’s not - it’s just one implementation of the Service API We should encourage alternate implementations • No more new proxy modes Looking for creative new options Treat kube-proxy as a plugin
Especially when crossing Namespaces More general purpose • Remember “external” workloads? Pods can join and leave a Service, but are born into ServiceAccounts BUT: Identity is not carried on the wire • Well, it is in some implementations! Use ServiceAccount in NetworkPolicy
• There is a world beyond our borders Cross-cluster identity Cross-cluster Services • EndpointSlice enables some of this? Cross-cluster NetworkPolicy • See discussion of identity Multi-cluster
• Not required • Don’t have to be on network (exec) • Can be TCP or HTTP Hard to build or integrate higher-level mesh control on that Logically belongs with Service • Hard to retrofit, but probably worthwhile Better health checks
thockin
magicpod
nulabinc
terapyon
atsushiyoshikawa
shinpr
itohiro73
tomokusaba
.png){kind=avatar}
tomodo_ysys
donkomura
ewolff
ytaka23
ogugu9
shpigford
bryan
tammyeverts
brad_frost
skipperchong
marktimemedia
bermonpainter
notwaldorf
sferik
thoeni
smashingmag
morganepeng
