How versioning works in Kubernetes, especially with CustomResourceDefinitions, is a common source of confusion. The documentation is pretty comprehensive but a bit complicated. This post aims to give a simple description of how versioning works and dispel some misunderstandings. There is only one primary version Consider a CRD with versions alpha and beta. A user can create and view either resource version. Intuitively, they must be distinct things -- they are not....

Across the ecosystem, a variety of software support policies can be found, where "support" can mean, bug fixes, security patches, and sometimes technical support. However, they can be roughly categorized into two types: Rolling release: only latest release supported. At an extreme, this is the HEAD git commit. LTS (Long Term Support): Support latest N versions. Sometimes specific versions have extended support. "Long" is relative: Kubernetes supports a version for around a year, while RHEL does for 10 years....

It is a very common misconception that egress policies in Istio can be used for security purposes. This is not true. Despite repeatedly explaining this (and documenting it), I still often see people that do not believe it, and that they can just add one more check to lock things down. In this post, I will show a variety of ways to bypass any possible check, and prove that these policies cannot be used as secure policies....

In many languages, on of the things I find myself doing is maping over a list to extract some field. For example, coverting a []Person to []Name. Most languages these days have ways to do this pretty easily: Kotlin: people.map { it.Name } JavaScript: people.map(p => p.Name) Rust: people.map(|p| p.Name) Scala: people.map(_.Name) With generics, Go finally can do this in a type safe manner: Map(people, func(t Person) string { return t....

This post follows the journey Istio has taken over the years to optimize our docker image builds. While there is some useful tips to take out of this, this is not intended to be a guide on how a project should build images - the steps taken here go far past the needs of a typical project, optimizing exclusively for speed (and fun) regardless of the complexity to maintain. For background, over the years Istio has consisted of ~10-20 docker images (many are for tests only) made up of ~10-15 Go binaries and various static files....

Kubernetes Operators are powerful tools when used right, pushing complex operations from human operators to code. This sounds great - and is in some cases - but often the tradeoffs operators expose are not taken into account, both by operator developers and users. This article goes over my take on when operators are useful and not, and what makes a good operator. A basic installation operator A common feature amongst almost all operators is the ability to deploy Kubernetes resources....

When deploying a proxy outside of Kubernetes, users typically reach for solutions like nginx or Traefik; it's pretty rare to see Kubernetes-native load balancers, like Istio, used outside of the Kubernetes context. While it is not documented anywhere on istio.io, it is completely possible to set up an Istio Gateway outside of Kubernetes - not just running out of the cluster, but not connected to any Kubernetes api-server whatsoever. In this post, we will set up Istiod, and Istio ingress gateway, and a test application using docker-compose....

The following graph shows PR approvals for istio/istio since 2020. DevA 100 <-> DevB 50 indicates DevB approved 100 PRs from DevA, and DevA approved 50 PRs from DevB. The data was collected from our policy bot data and graphed using flourish: gcloud spanner databases execute-sql main --instance istio-policy-bot --project istio-testing --format=json --sql='select prr.Author as Approver, pr.Author as Author, count(*) from PullRequestReviews as prr join PullRequests as pr on pr.PullRequestNumber = prr....