An optimal CI/CD system
Exploring an (unfortunately, hypothetical) CI/CD system for end to end tests on Kubernetes.
Exploring an (unfortunately, hypothetical) CI/CD system for end to end tests on Kubernetes.
The common messaging around Istio Ambient Mesh is that is a "node proxy." For example, from The New Stack ... architecture that moves the proxy functionality from the pod-level to the node-level. While this is technically accurate, it is misleading and really missing the point and benefits of Ambient. A brief history of service mesh architectures This skips quite a bit of information, but is close enough. One of the earlier service meshes on the market was Linkerd 1 - not to be confused with Linkerd 2, which most people just call "Linkerd" today. Linkerd 1 was a per-node proxy that did all the service mesh functionality we know and love, at the node level. ...
How to achieve an architecture similar to "Waypoint Proxies" without ambient mesh, or even Istio.
Fully utilizing buildkit's potentional
How and why to easily these fields
As an open source maintainer, I am reviewing roughly 25 ideas per day - whether they are feature requests, design proposals, or pull requests. Inevitably, this leads to saying "No" quite a bit as well. Usually, this is in a softer for like "No, not right now", "No, not in its current form", or "No, unless someone else approves", but the outcome is the same: the change is not accepted, and the emotional impact on the reviewer and contributor is similar. ...
Most people using Kubernetes extensive have already defined alias k=kubectl and are using tools like kubectx. As someone really lazy though, I have found/developed a few less common tools to help work with Kubernetes efficiently. kubectl apply from clipboard This relies on zsh, and uses the zle to define a custom command. function zle_apply { LBUFFER=" cat <<EOF | kubectl apply -f - $(xclip -se c -o) EOF" CURSOR=31 } zle -N zle_apply; bindkey "^k" zle_apply This defines a function and binds it to Ctrl+k. ...
A little bit of OpenTelemetry, a lot of shell hackery
In the past, Istio has suffered from performance issues from OpenCensus, which was used for metrics reporting. At extremes, we saw up to 20% of CPU spent just on incrementing various metrics. This was mitigated to some extent by batching metrics updates, optimizing OpenCensus itself, and caching parts of our OpenCensus usage. At best, we got down to roughly 600ns and 3 allocations per metric update. As OpenCensus is now deprecated, I have been looking into migration to OpenTelemetry - and hoping to avoid these issues this time around. ...
Go is often praised for its fast build times. While they are pretty quick, they are slow enough that I spend a lot of time waiting for them, enough that it prompted me to go down the rabbit hole of thoroughly analyzing them. This post covers all aspects of what makes Go builds fast or slow. Throughout this blog, we will use Istio as an example of real-world codebase. For reference on its size: ...