3 ms·

>>The whole point of kubernetes is to not think about your servers anymore because they in essence can be replaced at any time. Isn't that also the case for VM

by awill 4y ago

>>The whole point of kubernetes is to not think about your servers anymore because they in essence can be replaced at any time. Isn't that also the case for VMs?

pixl97 4y ago
How are you orchestrating the configuration of your VMs?
- mmh0000 4y ago
  Terraform (for cloudy stuff), kickstart and ansible (for on-prem stuff) would be my first go-to(s) for automatic installation, configuration, and config management. https://www.terraform.io/ https://www.terraform.io/ https://en.wikipedia.org/wiki/Kickstart_(Linux) https://en.wikipedia.org/wiki/Kickstart_(Linux) https://www.ansible.com/ https://www.ansible.com/
  - jhoelzel 4y ago
    The question was not "what tools do you use" but how do you achieve orchestration on the same level as kubernetes. Your machines are still named. Your resources still multiplicative. Your setup is not idempotent. Don't get me wrong, i have been using ansible and terraform for over a decade too, but this truly is an apple and oranges comparison.
    - 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

>>The whole point of kubernetes is to not think about your servers anymore because they in essence can be replaced at any time. Isn't that also the case for VMs?

pixl97 4y ago

How are you orchestrating the configuration of your VMs?

mmh0000 4y ago
Terraform (for cloudy stuff), kickstart and ansible (for on-prem stuff) would be my first go-to(s) for automatic installation, configuration, and config management. https://www.terraform.io/ https://www.terraform.io/ https://en.wikipedia.org/wiki/Kickstart_(Linux) https://en.wikipedia.org/wiki/Kickstart_(Linux) https://www.ansible.com/ https://www.ansible.com/
- jhoelzel 4y ago
  The question was not "what tools do you use" but how do you achieve orchestration on the same level as kubernetes. Your machines are still named. Your resources still multiplicative. Your setup is not idempotent. Don't get me wrong, i have been using ansible and terraform for over a decade too, but this truly is an apple and oranges comparison.
  - 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.