mcorbin

Nice article ;)

> The number of rules may be large, which may be problematic for certain traffic forwarding implementations (iptables linearly evaluates every rule)

Kube proxy also supports ipvs out of the box, and some CNI (like Cilium) can also replace kube proxy and rely on eBPF.

> When a Pod is moved to another node, the traffic will be forwarded twice until the old DNS entry expires Not sure to understand this one. On a standard setup what happens is:

- Pod A is running on a node, receiving traffic from a service

- The pod is stopped by kubelet (that send a SIGTERM to it).

- The pod should gracefully shutdown. During the shutdown phase, only _existing_ connections are forwarded to the stopping pod, new ones will be already forwarded elsewhere.

- If the pod stops before the terminationGracePeriodSeconds duration (default 30s), everything is fine. Else, the pod is killed by kubelet. So it's developers that should make sure pods handle signals correctly.

"Misbehaving clients (eg: ones that do not re-resolve DNS before reconnecting) will continue to work" => the services IP is stable so clients don't need to re-resolve.

> Why does it not matter if the state is unstable? If I'm operating a cluster that can't settle, I'd like to know immediately!

Kubernetes exposes a lot of metrics, on the control plane components or kubelet, usually using the Prometheus format. Look for example at the metrics exposed by kube state metrics: https://github.com/kubernetes/kube-state-metrics/tree/main/d...

With controllers metrics + kube state metrics about most Kubernetes resources, you can easily build alerts when a resource fails to reconcile.

> Basically, Horizontal Pod Autoscaler but with sensors which are not just "CPU"

Take a look at KEDA, it's exactly this: https://keda.sh/ It "extends" the autoscaler capabilities. If you're running Prometheus you can for example scale on any metric that is stored in Prometheus (and so exposed by your application/infrastructure components: queue depth, latency, request rate...).

Kubernetes was built to be extended like this. Same for your question "Why are the storage and networking implementations "out of tree" (CNI / CSI)?", to my experience support is very good today on various cloud providers or on premise infra components. Look at Karpenter for example, it's IMO a revolution in the Kubernetes node management world.

I was not happy with the current solutions to generate YAML files in the Kubernetes world (helm, kustomize) so I built my own tool.

It uses the EDN format and the Aero library to do so. EDN and Aero gives me powerful readers (and I can also add my own) to generate YAML files efficiently.

i'm the author of Commentator, a commenting system where comments are stored on any s3 compatible store (easier to manage than a DB or local storage): https://github.com/mcorbin/commentator

It's still WIP but it supports comments approval, has a rate limiter, a challenge system to avoid spammers... I already use it for my personal blog.

Hello,

I released today a new version of Cabourotte, a monitoring tool I worked on this year.

I started to work on this project because I wasn't satisfied with the on-premise tools available to execute infrastructure healthchecks. Here are some features I implemented

- DNS, TCP, HTTP(s), TLS healthchecks, with tons of options available for each type, including labels per healthchecks (which are added to the logs/metrics).

- Fully controllable using the API (but you can still configure healthchecks using the conf file)

- Exposes a lot of metrics in Prometheus format

- Exporters to export healthchecks results to external systems (only HTTP available today)

- Hot Reload on SIGHUP

- The latest result for healthchecks are available in the API (they expire after a while), and a small frontend also shows them.

- "One Off" healthchecks to execute arbitrary healthchecks: you send an healthcheck definition to the API, Cabourotte executes it and returns the result.

Now my goal is to work on the ecosystem. I would really like to have a Kubernetes Operator to automatically configure Cabourotte instances everytime a new pod/service with some annotations is deployed.

Don't hesitate to give me feedbacks.

Try Clojure.