Istio

Over 2 years ago, I started working on some ideas to build better Kubernetes controllers. In this post, I wanted to give a bit of a retrospective on how things have gone since then. Over the years working on Istio and other projects, I observed a number of major issues with controllers: Most code was about error-prone event handling and state reconciliation, rather than business logic. Most tests, in turn, were about the same. This, in turn, made the code extremely complex, brittle, and often incorrect. This complexity lead to user facing compromise: incorrectness and performance issues. You might argue I should just write a better controller that is faster and without bugs. Maybe, but probably not. ...

Core problems with the API make it a challenging to use in a secure, scalable manner.

Zero trust architectures should not treat nodes as highly privileged components.

How we built a best-of-both-worlds experience with Istio ambient mode.

Sidecarless? Why not podless?

How Istio tests its networking proxy without Kubernetes, Docker, or root.

tl;dr: it just works

Like most other Kubernetes controllers in, Istio is written in Go and relies on the client-go library. While this provides an excellent low-level building block, usage in higher level code in Istio led to a variety of issues that led us to develop our own higher level, opinionated client for Istio. This post covers the issues we faced and how we incrementally solved them. Background knowledge At a high level, client-go provides a few layers for interactions with the API server: ...

Which features I recommend using, or not using, in Istio

Exploring an extreme service mesh architecture to maximize extensibility.