Kubernetes makes deploying code easy, but conflating deploys and releases is risky. Using smarter proxies you can dramatically reduce the risk of a release, which in turn helps you ship code to customers faster.

1. Mark McBride, 2017/07/26
Beyond Ingresses
Next Level Kubernetes Traffic Management

2. Ingress Overview
Ingresses have two conflated goals.
Get traffic from outside k8s into k8s.
Route traffic in a single URL space to mul?ple backend services.
Ingresses have two parts.
The Ingress resource defines policy in a plaBorm neutral way.
The Ingress controller executes that policy.
The Ingress controller is oDen plaBorm dependent, e.g. GKE LB.

3. What Can You Do
Ingresses are ~equivalent to what you get with nginx et al.
Take a given URL space and “mount” services.
Send all traffic to /users to the kubernetes service “user”.
Send all traffic to /search to the kubernetes service “search”.
This is mostly fine for stable systems.

4. Dynamism
You want to upgrade?
Simple! Switch, old version for new.
What if it goes wrong?
How do you find out?
How do you fix it?

5. Limitations of Deploy as Release
Deploy rollout is for reals.
You are affec?ng real customers.
Deploy rollout proceeds as long as liveness probes pass.
Your liveness probes are probably rock solid 😬
Rolling back requires a bunch of pod creates/destroys.
This can be fast, but oDen isn’t.

6. 😑

7. 😔

8. 😫

9. You’ll never be 100% sure it’s right

10. 😪

11. 🤔

12. But you can limit the damage
And you can detect problems faster
And you can fix problems faster

13. Smarter proxies enable smarter
workflows

14. A better way
Limit the scope of defects.
Rollout is for reals -> targeted rollout.
Detect defects faster.
Liveness probes -> observing customer experience.
Fix defects faster.
Rollback deployment -> turn off rou?ng change.

15. Targeted rollout part 1 - test in production
Many pods that implement a given service can exist.
You need not route produc?on traffic to all of them.
Use some aspect of the request (headers, source IP) to
route to the unreleased version.

16. Targeted rollout part 2 - incremental blue/green
Weight traffic between two different logical services.
Send x% to the new (green) version, (100-x)% to the
exis?ng (blue) version.
When x is small, the impact of a bad release is small(er).

17. Observing customer experience
Health checks are usually a poor approxima?on of user
experience.
Your proxy can give you a much becer picture.
Watch metrics customers care about - latency, success rate, request rate.
Break them out by endpoint.
Break them out by soDware version.

18. Turn off release
Weight traffic between two different logical services.
Send x% to the new (green) version, (100-x)% to the
exis?ng (blue) version.
When x is small, the impact of a bad release is small(er).

19. 😃

20. So what do I need?
Data Plane - smarter proxies for fine grained traffic rou?ng.
envoy, linkerd, linkerd-tcp, traefik
Management Plane - a way to manage a bunch of proxies.
Is?o, namerd API
Applica?on plane - this is where you solve problems.
Houston
Note that at any of these layers DIY is an op?on.

21. How do I roll this out?
It’s easier and faster than you might think.
5 minutes to get Houston running on GKE.
You can mi?gate rollout risk in a variety of ways.
Stand up new proxies and test on a different hostname.
Start with staging/test environments.
Blue/green deploy of proxy layer.

22. How much happier will I be when I do?
😍

23. Thank you!
I love to talk about this stuff.
Hit me up at mark@turbinelabs.io.
Or @mccv on Twi=er.
Or check out our take on this at
h=ps://go.turbinelabs.io/release/