| > How do you implement healthcheck? > Does the loadbalancer know how the healthceck is implemented? Write a ping/sping endpoint like people did pre-Kubernetes? LBs provided by Cloud provider all have a trivial way of setting a healthcheck endpoint. If you are not in the cloud, nginx and HAProxy make it equally simple to configure a healthcheck. There is no k8s secret sauce behind healtchecks. > How do you determine it's time to scale? Monitor relevant metrics (CPU/Memory/DB), have alerts and add new vms or whatever when they hit a specified threshold. Or use your cloud provider's "elastic scaling". > How do you implement always-on-process? service unit, initd, cron? Yes. And the problem with that is? Processmanagers have been around forever, are simple to use and a well understood technology. > How do you export the logs? Cloud providers generally have a built in mechanism for pumping logs out, if you are not a cloud provider log export daemons exist that much simpler to work than running k8s deployment. > How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config? Do whatever your organizations feels comfortable with... config files, json, .properties files, env vars whatever, it doesn't really matter, since the code needs to be aware of the configuration mechanism anyways it doesn't make a difference. And again not worth the tradeoff of running full blown k8s deployment with its significant complexities > What about secrets? Cloud providers have convenient ways of solving this problem without involving k8s. If you are not on the cloud one can use cloud secret solutions (AWS Secret Manager, Google Secret Manager, Cloud Vault). All of which are much simpler to use than k8s secrets > Service discovery? Is unbound/bind9? DNS works well enough for most projects. Static configuration which lists domain names of whatever services you depend on (which are behind a load balancer) likely works for 90% of all applications. I am not trying to be argumentative just making a point that "standardizing" all these things you mentioned "the Kubernetes way" are not worth the significant complexity of running and managing k8s for most organizations. And certainly, non-k8s ways of doing these things are much simpler to reason about for developers. A team of 2-3 developers can handle of these things and be able to keep the entire state of their system in there head, whereas with k8s it is suicide to have a k8s cluster without having a dedicated devops team. And I disagree that there needs to be an industry wide standard of doing these things in the first place (and certainly not a standard like k8s that adds mountains of complexity). The standardization if needed, needs to happen at a team or organization level. Individual organizations should be free to pick and choose how they solve these problems rather than be pressured into the complexity of k8s. |