5 ms·

1. Kubernetes is when your service needs google kind of load which 90% of systems don't. Just trade it for simple VM or use LXD containers. Don't jump on next h

1. Kubernetes is when your service needs google kind of load which 90% of systems don't. Just trade it for simple VM or use LXD containers. Don't jump on next hype cycle. If something works for Google does not mean will work for you. 2. Don't spend too much on it just use traditional knowledge and, you can still use bare-metal, VM or LXD container. Focus on application not on programming a tool designed to solve problems for Google size deployment. 3. Kubernetes is a completely different way of doing things. So if you want to leverage old cluster and distributed system knowledge you can use VM or LXD containers. Kubernetes is an overkill. 4. Abandon kubernetes instead of complaining, just use simple systems.

arpa 7y ago
for development, i agree. For production/testing/staging - hmmmm, it depends. I have taken a particular liking to the self-healing/HA properties of kubernetes. You just swap the dead nodes out without significant impact on the production... it's awesome.
- sametmax 7y ago
  The trick is to understand that most products don't need to have 99% uptime. Your business will be fine if you are offline once in a while. Hell, the stock market goes offline every night. Those last % of uptime are very, very expensive at every level (money, people, logistic...). They better be worth it.
  - tinco 7y ago
    There's a difference between going offline at a set time for a set amount of time, and going offline randomly for unpredictable amounts of time. HA is not just about getting that sixth 9, it's also about the peace of mind that you are insulated from a range of problems. Not only would I not worry about our SQL service going down, I also don't have to worry about what I have to do when a node goes down, because that's automated.
    - sametmax 7y ago
      Even an occasional site crash is ok. I'm not saying it's a good user xp, and avoiding it is both better for the tech team and the marketting one. But the cost of a 500 is always to be balanced with the cost of going full throttle with micro services. As perfectionists, it's easy to fall into the trap of choosing the later by default.
      - tinco 7y ago
        What do micro services have to do with it? If anything, HA is harder to achieve with microservices. There's all these weird false dichotomies going around in this thread.
    - ninkendo 7y ago
      Exactly... HA is about being able to sleep more peacefully each night.
nouney 7y ago
Managing a VM vs a managed Kubernetes cluster? I'd choose kubernetes without hesitating
- dragonsh 7y ago
  Don't manage VM, try LXD containers [1], they are containers with much better security and you can still use the same tools you learned for last decade or two to manage including the DSL if you like that. Kubernetes is an Overkill for majority of development and production systems. [1] https://linuxcontainers.org/ https://linuxcontainers.org/
- oblio 7y ago
  > Managing a VM vs a managed Kubernetes cluster? So the win is not having to manage something :-) How is that a fair comparison?
  - ninkendo 7y ago
    > So the win is not having to manage something Exactly! > How is that a fair comparison? Not only is it a fair comparison, but I'd say it's the entire raison d'etre of using any orchestration platform: You get to farm out bits of the infrastructure to others. Getting on k8s enables you to not have to run your own infrastructure, whereas having VMs being your abstraction sorta by definition does not.
te_chris 7y ago
This misses the genius of k8s. When you adopt it, you’re adopting a completely declarative way of provisioning your system. It’s a total paradigm shift and I will never go back. My big want, is a kube as a service for small workloads - I.e I can just apply a deployment and everything goes up, no cluster considerations or whatever.
- dragonsh 7y ago
  It's good if you found it working for you. If your team can grok over all of k8s complexity and moving parts, stick with it, use the tools your team is comfortable with. I tried working with docker since 2013 and later with Kubernetes, I still go back to LXD. In my view less systems and moving parts less complexity, maintenance and cognitive load. On top of it I don't have to give up decades of knowledge I learned regarding cluster and distributed computing on bare-metal and VM as I can apply the same to LXD. Obviously I can do that with Kata containers, but they didn't fit with my team either. Also for most of services with users in the range of 160-180 million LXD work fine.
OJFord 7y ago
> Kubernetes is when your service needs google kind of load which 90% of systems don't. This is the most frustrating but oft repeated nonsense about k8s. Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc. When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes. Machine count corresponds to load; abstraction doesn't.
- dragonsh 7y ago
  > Machine count corresponds to load; abstraction doesn't. K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with lots of moving parts.
  - tutfbhuf 7y ago
    > It doesn't help when a service is only for few million users with few hundred or thousand containers. Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.
    - oblio 7y ago
      Do you manage Kubernetes, personally? Did you manage the VMs?
      - tutfbhuf 7y ago
        Yes, i'm a DevOps engineer. I have to say, we use the Google Cloud and many Google Services, this makes live so much easier. Before that we managed everything ourselves on bare metal with debian VMs.
        oblio 7y ago
atombender 7y ago
This meme needs to die. Kubernetes is not overkill for non-Google workloads. In my current work, we run several Kubernetes clusters via GKE on Google Cloud Platform. We're a tiny company — less than 20 nodes running web apps, microservices and search engines — but we're benefiting hugely from the operational simplicity of Kubernetes. Much, much, much better than the old fleet of Puppet-managed VMs we used to run. Having surveyed the competition (Docker Swarm, Mesos/Marathon, Rancher, Nomad, LXD, etc.), I'm also confident that Kubernetes was the right choice. Kubernetes may be a large and complex project, but the problem it solves is also complex. Its higher-level cluster primitives are vastly better adapted to modern operations than the "simple" Unix model of daemons and SSH and what not. The attraction isn't just the encapsulation that comes with containers, but the platform that virtualizes physical nodes and allows containers to be treated as ephemeral workloads, along with supporting primitives like persistent volumes, services, ingresses and secrets, and declarative rules like horizontal autoscalers and disruption budgets. Given this platform, you have a "serverless"-like magically scaling machine full of tools at your fingertips. You don't need a huge workload to benefit from that. As for LXD and the other alternatives, these might be great, but Kubernetes has vastly more mainstream adoption these days. That's more important than mere technological superiority, or everyone would be using OpenSolaris with Zones and ZFS these days.

arpa 7y ago

for development, i agree. For production/testing/staging - hmmmm, it depends. I have taken a particular liking to the self-healing/HA properties of kubernetes. You just swap the dead nodes out without significant impact on the production... it's awesome.

sametmax 7y ago
The trick is to understand that most products don't need to have 99% uptime. Your business will be fine if you are offline once in a while. Hell, the stock market goes offline every night. Those last % of uptime are very, very expensive at every level (money, people, logistic...). They better be worth it.
- tinco 7y ago
  There's a difference between going offline at a set time for a set amount of time, and going offline randomly for unpredictable amounts of time. HA is not just about getting that sixth 9, it's also about the peace of mind that you are insulated from a range of problems. Not only would I not worry about our SQL service going down, I also don't have to worry about what I have to do when a node goes down, because that's automated.
  - sametmax 7y ago
    Even an occasional site crash is ok. I'm not saying it's a good user xp, and avoiding it is both better for the tech team and the marketting one. But the cost of a 500 is always to be balanced with the cost of going full throttle with micro services. As perfectionists, it's easy to fall into the trap of choosing the later by default.
    - tinco 7y ago
      What do micro services have to do with it? If anything, HA is harder to achieve with microservices. There's all these weird false dichotomies going around in this thread.
  - ninkendo 7y ago
    Exactly... HA is about being able to sleep more peacefully each night.

nouney 7y ago

Managing a VM vs a managed Kubernetes cluster? I'd choose kubernetes without hesitating

dragonsh 7y ago
Don't manage VM, try LXD containers [1], they are containers with much better security and you can still use the same tools you learned for last decade or two to manage including the DSL if you like that. Kubernetes is an Overkill for majority of development and production systems. [1] https://linuxcontainers.org/ https://linuxcontainers.org/
oblio 7y ago
> Managing a VM vs a managed Kubernetes cluster? So the win is not having to manage something :-) How is that a fair comparison?
- ninkendo 7y ago
  > So the win is not having to manage something Exactly! > How is that a fair comparison? Not only is it a fair comparison, but I'd say it's the entire raison d'etre of using any orchestration platform: You get to farm out bits of the infrastructure to others. Getting on k8s enables you to not have to run your own infrastructure, whereas having VMs being your abstraction sorta by definition does not.

te_chris 7y ago

This misses the genius of k8s. When you adopt it, you’re adopting a completely declarative way of provisioning your system. It’s a total paradigm shift and I will never go back. My big want, is a kube as a service for small workloads - I.e I can just apply a deployment and everything goes up, no cluster considerations or whatever.

dragonsh 7y ago
It's good if you found it working for you. If your team can grok over all of k8s complexity and moving parts, stick with it, use the tools your team is comfortable with. I tried working with docker since 2013 and later with Kubernetes, I still go back to LXD. In my view less systems and moving parts less complexity, maintenance and cognitive load. On top of it I don't have to give up decades of knowledge I learned regarding cluster and distributed computing on bare-metal and VM as I can apply the same to LXD. Obviously I can do that with Kata containers, but they didn't fit with my team either. Also for most of services with users in the range of 160-180 million LXD work fine.

OJFord 7y ago

> Kubernetes is when your service needs google kind of load which 90% of systems don't. This is the most frustrating but oft repeated nonsense about k8s. Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc. When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes. Machine count corresponds to load; abstraction doesn't.

dragonsh 7y ago
> Machine count corresponds to load; abstraction doesn't. K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with lots of moving parts.
- tutfbhuf 7y ago
  > It doesn't help when a service is only for few million users with few hundred or thousand containers. Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.
  - oblio 7y ago
    Do you manage Kubernetes, personally? Did you manage the VMs?
    - tutfbhuf 7y ago
      Yes, i'm a DevOps engineer. I have to say, we use the Google Cloud and many Google Services, this makes live so much easier. Before that we managed everything ourselves on bare metal with debian VMs.
      - oblio 7y ago

atombender 7y ago

This meme needs to die. Kubernetes is not overkill for non-Google workloads. In my current work, we run several Kubernetes clusters via GKE on Google Cloud Platform. We're a tiny company — less than 20 nodes running web apps, microservices and search engines — but we're benefiting hugely from the operational simplicity of Kubernetes. Much, much, much better than the old fleet of Puppet-managed VMs we used to run. Having surveyed the competition (Docker Swarm, Mesos/Marathon, Rancher, Nomad, LXD, etc.), I'm also confident that Kubernetes was the right choice. Kubernetes may be a large and complex project, but the problem it solves is also complex. Its higher-level cluster primitives are vastly better adapted to modern operations than the "simple" Unix model of daemons and SSH and what not. The attraction isn't just the encapsulation that comes with containers, but the platform that virtualizes physical nodes and allows containers to be treated as ephemeral workloads, along with supporting primitives like persistent volumes, services, ingresses and secrets, and declarative rules like horizontal autoscalers and disruption budgets. Given this platform, you have a "serverless"-like magically scaling machine full of tools at your fingertips. You don't need a huge workload to benefit from that. As for LXD and the other alternatives, these might be great, but Kubernetes has vastly more mainstream adoption these days. That's more important than mere technological superiority, or everyone would be using OpenSolaris with Zones and ZFS these days.