2 ms·

well, the old way of doing it is with named VMs "webserver01". The more modern way of for those names to essentially be UUIDs. They're individually unimportant,

by awill 4y ago

well, the old way of doing it is with named VMs "webserver01". The more modern way of for those names to essentially be UUIDs. They're individually unimportant, and get spun up/down automatically based on load and/or health.

jhoelzel 4y ago
so in essence making it harder on yourself to avoid using yaml? The point of kubernetes is that its APIs all the way down, controlled by a central loop. Its not that we can not know the uuids or names of containers, its that we usually do not even need them. Hardware problems are reduced to Node levels and workloads are completely replaceable. So in essence Kubernetes is a vendor neutral "vm server creator". In any bare-metal scenario i prefer the approach to provision the cluster itself with terraform or ansible, because i am able to point at hardware itself, but otherwise the whole point of having multiple servers is to scale. I can also still have the same attachment to a lovely server without naming it peter. Stuff happens. at some point you need to take down a node or two. What happens here is up to you. I also understand that everything is possible if you script it enough, but there again we are basically just talking to an API server for the workloads. Even in traditional system admin vs cloud admin teams, each can focus on what they are good at in the same way your hardware should be separate from your software.
- awill 4y ago
  You add a lot of complexity and points of failure with this model.
  - jhoelzel 4y ago
    you inevitably do too. The difference is your complexcity is usally done by hand and the complexcity in kubernetes only comes from your perspective. Most of these controlling "algorythms" used in kubernetes literally only wrap the api of the underlying software, which in den end is the same you use too. You too need networking, compute and storage just in the same way, but either you can orchestrate it or get orchestrated.

by awill 4y ago

jhoelzel 4y ago

so in essence making it harder on yourself to avoid using yaml? The point of kubernetes is that its APIs all the way down, controlled by a central loop. Its not that we can not know the uuids or names of containers, its that we usually do not even need them. Hardware problems are reduced to Node levels and workloads are completely replaceable. So in essence Kubernetes is a vendor neutral "vm server creator". In any bare-metal scenario i prefer the approach to provision the cluster itself with terraform or ansible, because i am able to point at hardware itself, but otherwise the whole point of having multiple servers is to scale. I can also still have the same attachment to a lovely server without naming it peter. Stuff happens. at some point you need to take down a node or two. What happens here is up to you. I also understand that everything is possible if you script it enough, but there again we are basically just talking to an API server for the workloads. Even in traditional system admin vs cloud admin teams, each can focus on what they are good at in the same way your hardware should be separate from your software.

awill 4y ago
You add a lot of complexity and points of failure with this model.
- jhoelzel 4y ago
  you inevitably do too. The difference is your complexcity is usally done by hand and the complexcity in kubernetes only comes from your perspective. Most of these controlling "algorythms" used in kubernetes literally only wrap the api of the underlying software, which in den end is the same you use too. You too need networking, compute and storage just in the same way, but either you can orchestrate it or get orchestrated.