HN user

tennix

48 karma
Posts8
Comments10
View on HN

This is particularly problematic for hosted Kubernetes services like Google Kubernetes Engine (GKE), which often limit the CPU and memory available to the API server. These services can gracefully scale the API server up when they predict it will require more resources - e.g. when more nodes are created. Unfortunately at the time of writing most don’t factor in more CRDs being created and won’t begin scaling until the API server is repeatedly “OOM killed” (terminated for exceeding its memory budget).

Yeah, that's the limitation of hosted kubernetes services. Internally we used crossplane a lot. Though we haven't reached this limitation yet, we used another approach by deploying a standalone etcd + k8s apiserver as k8s (eks/gke) pods. And register the CRDs into this apiserver. So we can scale the etcd and apiserver easily.

You can debug such containers by running another debugging container to join their corresponding namespaces. For example the most frequently used namespaces are pid and network, with these two namespaces joined the target container, you can see its pid and binary as well as the network traffic.

For docker and k8s, there are two helpful tools which implement what I said with simple and intuitive UI:

* https://github.com/zeromake/docker-debug

* https://github.com/aylei/kubectl-debug

Edit: Add links for the helper tools.

Agreed on dependent type, and I also love ML syntax more than haskell(yes I don't like indentation sensitive language). BTW I suggest you give FStar a try, it has dependent type and OCaml/F# like syntax and support theorem proving

I believe emoji is designed to be expressive, if we need to look it up in a emoji dictionary ,then emoji goes wrong. The fact is that everybody wants to add their favourite emoji, but more emoji added more confusion it will be make. Just imagine we lookup an emoji before we send to others, and the receiver has to look it up in a dictionary to know what the sender want to express. Why not just using the normal words we already know very well