| I'm tired to read this as if it was impossible. > How do you implement healthcheck? Most applications implement a simple endpoint which returns a known answer (whether it's an HTTP 200 code, a banner, etc.)
You can just hit this endpoint using your favorite tool. > Does the loadbalancer know how the healthceck is implemented? Well, a lot of tooling supports native (periodic) healthchecks, e.g. NGINX or NGINX Plus (if you want to pay something else than managing K8S). > How do you determine it's time to scale? It is not that expensive to run performance monitoring such as netdata, sometimes, it is just a call to your distribution package manager, put it in your intranet, then you're done. > How do you implement always-on-process? service unit, initd, cron? Depending on what you're using in Linux distributions, why bother with initd and cron if you're running on a systemd-based distribution? Just use unit, timers, service, scope, slice and so on. > How do you export the logs? Again, if you're using a systemd-based distribution: `man systemd-journald-remote`. Otherwise, Loki, rsyslog, many solutions do exist for these scenarios and do not require that much fancy configuration. For mono-nodes, I would argue that the null logger exporter, called: "rsync your logs somewhere", is quite efficient. > How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config? I do not even know why people worry about that.
If you're using a systemd-based distribution, your configuration should live more or less in the service unit using Environment, EnvironmentFile and LoadCredential(Encrypted), if your app want some files, sure, put it in /etc/xxx or /var/lib/xxx/config. As long as you do separate configuration from state (and use StateDirectory, etc.) and you do backup them, it is okay. > What about secrets? As said earlier, LoadCredential do the job, if you want to be fancy, you can run a UNIX socket server to distribute the secrets and some secret engine such as HashiCorp Vault. Uncertain that K8S has a better story than that. > Service discovery? Is unbound/bind9? Uncertain you actually need service discovery in early stages. Assuming you need, you could run envoy if you have advanced needs.
Or you could run PowerDNS/nsd/unbound/BIND9 as you said with a thin wrapper to register your services. > And on and on and on and on. Well, I do not agree, those are items you choose. Not everyone has these requirements, and not everyone needs to solve them the k8s way. > These items are best done in a standard way. That's a major selling point in k8s. You define and implement these in a consistent way that also integrates seamlessly with other tools. Doubly so on cloud. Less reinventing the wheel means less money. The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview. That is a fallacy, k8s is not a standard way, they push for their standard way and it is in no case what everyone is doing. Defining and implementing thing in a "consistent way" is something we have been doing for a long time before k8s, through standardization process with IETF and W3C for example. k8s creates its own world, and it is indeed compatible with the external world sometimes, but I do not believe that a pile of complexity on the top of YAML files and YAML manipulation tooling is a "consistent way" to define and implement things, no offense here. > Doubly so on cloud. Yeah, because the "cloud ecosystem" is pushing for this, but it has not been a standard. > Less reinventing the wheel means less money. Using a "simple feature" is not reinventing the wheel, but if we go this way, I have a challenger: NixOS. Just reuse their expert modules database and do your classical YAML stuff, but this time with a simple functional programming language. > The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview. I think GP was discussing of an early stage and I do not think that all teams require to push at a very fast rate, there is definitely time for packaging and shipping it.
BTW, in these organizations where I have worked, they adopted k8s and these "teams" could not use it because it was too complicated and wondered where their packaging team has gone. There is no silver bullet and choosing a deployment platform stack is not a figured out science, but there is a lot of value of choosing composable and simple tools before moving to more integrated ecosystems. > Take this into consideration before your next interview. That is an amazing level of arrogance, I only hope you may accept there are alternatives. :) |