3 ms·

https://kubernetes.io/docs/getting-started-guides/minikube/ https://kubernetes.io/docs/getting-started-guides/minikube/ > Running Kubernetes Locally via Miniku

https://kubernetes.io/docs/getting-started-guides/minikube/ https://kubernetes.io/docs/getting-started-guides/minikube/ > Running Kubernetes Locally via Minikube > Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.

tinco 10y ago
Yes, so the problem is I think that for the parent it is hard to scale minikube out to a full cluster.
- hosh 10y ago
  I don't contribute to Kubernetes, but I am curious about what the parent or what you mean by that. We use 1-node for dev work and then n-node cluster on staging and production. My team's dev workflow spans from 1-node to n-node just fine. Granted, I also wrote Matsuri to consolidate managing dev and production systems. But I also know that K8S 1.5 and 1.6 introduced a lot of resources that makes it easier to manage things like that (such as ConfigSets). I also know that Helm has been doing a lot in this area. (I had never used it because it overlaps with what Matsuri does).
  - tinco 10y ago
    I think they want to start their production environment on one node, and then scale as their product grows. I'm not saying that it's a particularly good approach, but I've seen situations where people frown when you say that your 10 user product needs at least 3 machines to function, just because it's run on cluster software that's designed to build products for millions of users on. It would be easier to sell if you could run it on 2 or even 1 server, and still grow the cluster to proper size when the circumstances demand it. Of course, there are very good reasons for it to require 3 machines, and since machines are so cheap, it should be absolutely a no brainer to spawn a $5 node to get that quorum running, but that's I think the argument for it.
    - hosh 10y ago
      I think maybe people are under the mistaken impression K8S requires forming some sort of quorum. You can run 1 node in production if that is what you really want. You run 3-nodes for availability and resilience. You can spread the 3-nodes across availability zones (isolating failure domains). If there is sufficient capacity, then one out of three nodes can go down, and K8S master will reschedule the pods in the down node. This also allows for controlled upgrades. If those are not a requirement (your prototype doesn't need that kind of uptime), then why not run it in 1-node? The only subsystem I know of that has a quorum mechanic is etcd backing k8s master. The docs will recommended to run the backing etcd in a 3-node configuration-- again, for availability. However, I run k8s worker, k8s master, and 1-node etcd on the same dev box. (The trick is to tell etcd to listen to three ports and tell the single etcd node that those other ports are part of the quorum). There is no reason the 10-user app that can tolerate some downtime cannot run like that either. I do think though, K8S has not yet closed the gap for people who want to prototype quickly and get something out. Heroku is a great platform for that. There is an migration path that goes from Heroku to Deis (which is built on top of Kubernetes and will work with Heroku build-paths).
cookiecaper 10y ago
Correct, minikube emulates a cluster via virtual machines for local development. It's a hack.
- lobster_johnson 10y ago
  It's not a hack, it's a product: "A version of Kubernetes that works anywhere, with zero configuration." You can run Kubernetes locally without a VM just fine, but a VM encapsulates everything nicely without needing to configure the host's network and so on. It doesn't "emulate" a cluster, it creates a cluster that happens to contain only one node. Plus, it works on non-Linux machines.

tinco 10y ago

Yes, so the problem is I think that for the parent it is hard to scale minikube out to a full cluster.

hosh 10y ago
I don't contribute to Kubernetes, but I am curious about what the parent or what you mean by that. We use 1-node for dev work and then n-node cluster on staging and production. My team's dev workflow spans from 1-node to n-node just fine. Granted, I also wrote Matsuri to consolidate managing dev and production systems. But I also know that K8S 1.5 and 1.6 introduced a lot of resources that makes it easier to manage things like that (such as ConfigSets). I also know that Helm has been doing a lot in this area. (I had never used it because it overlaps with what Matsuri does).
- tinco 10y ago
  I think they want to start their production environment on one node, and then scale as their product grows. I'm not saying that it's a particularly good approach, but I've seen situations where people frown when you say that your 10 user product needs at least 3 machines to function, just because it's run on cluster software that's designed to build products for millions of users on. It would be easier to sell if you could run it on 2 or even 1 server, and still grow the cluster to proper size when the circumstances demand it. Of course, there are very good reasons for it to require 3 machines, and since machines are so cheap, it should be absolutely a no brainer to spawn a $5 node to get that quorum running, but that's I think the argument for it.
  - hosh 10y ago
    I think maybe people are under the mistaken impression K8S requires forming some sort of quorum. You can run 1 node in production if that is what you really want. You run 3-nodes for availability and resilience. You can spread the 3-nodes across availability zones (isolating failure domains). If there is sufficient capacity, then one out of three nodes can go down, and K8S master will reschedule the pods in the down node. This also allows for controlled upgrades. If those are not a requirement (your prototype doesn't need that kind of uptime), then why not run it in 1-node? The only subsystem I know of that has a quorum mechanic is etcd backing k8s master. The docs will recommended to run the backing etcd in a 3-node configuration-- again, for availability. However, I run k8s worker, k8s master, and 1-node etcd on the same dev box. (The trick is to tell etcd to listen to three ports and tell the single etcd node that those other ports are part of the quorum). There is no reason the 10-user app that can tolerate some downtime cannot run like that either. I do think though, K8S has not yet closed the gap for people who want to prototype quickly and get something out. Heroku is a great platform for that. There is an migration path that goes from Heroku to Deis (which is built on top of Kubernetes and will work with Heroku build-paths).

cookiecaper 10y ago

Correct, minikube emulates a cluster via virtual machines for local development. It's a hack.

lobster_johnson 10y ago
It's not a hack, it's a product: "A version of Kubernetes that works anywhere, with zero configuration." You can run Kubernetes locally without a VM just fine, but a VM encapsulates everything nicely without needing to configure the host's network and so on. It doesn't "emulate" a cluster, it creates a cluster that happens to contain only one node. Plus, it works on non-Linux machines.