Nice article, I like the emphasis that "you don't need anything else than HTTP and JSON to extend Kubernetes !".<p>Regarding the use-case, I just want to note that if you want to add a container next to every scheduled pod, it is best to have it be part of the pod itself rather than in another pod with another lifecycle. And to achieve that the best tool is not a plain controller, but a "mutating admission controller webhook", described here <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks" rel="nofollow">https://kubernetes.io/docs/reference/access-authn-authz/exte...</a>, which will allow you to, well, mutate, pod descriptions on the fly as they are submitted to the cluster (and add your sidecar container to it).<p>Of course, the goal of the article is to demonstrate lifecycle management by reacting to change (a controller), so it's all fair in this case :).
Nice article(s)!<p>> Notice all the null parameters that need to be passed<p>Why, yes, I think we noticed those :)<p>Thanks to your article(s), I've begun calling the k8s api myself now in some experiments.<p>It actually works to call the REST API manually in dotnetcore (without a library), but I fear having to do with any self signed certificates that may be "defined" (? I've only heard of them so far) in kubeconfig would be too much to do oneself.