←back to thread

KubeVPN: Revolutionizing Kubernetes Local Development

(github.com)
67 points naison | 4 comments | 20 Feb 25 05:09 UTC | HN request time: 0.95s | source
Show context
remram ◴[20 Feb 25 16:28 UTC] No.43116704[source]▶
I don't really understand the point of this. I have a production cluster and I develop locally. My dev environment is not connected to the production cluster. That seems super dangerous.

My dev environment has the database with mock data, the backend, etc all running there. I would never connect to the production cluster. I don't need to VPN into another cluster to run locally.

Even if I have a dev cluster/namespace, then I will run the code I'm currently developing there. That's the point of a dev cluster. (Tilt for example can do both: a local cluster (minikube/k3d/...) or a remote test cluster)

I don't understand in what situation you have an app that needs to partially run in the cluster and needs to partially run on your machine.

replies(2): >>43116864 #>>43116868 #
kube-system ◴[20 Feb 25 16:40 UTC] No.43116864[source]▶
> the database

> the backend

Many k8s clusters are quite a bit more complicated than a single database and single backend. Some have dozens or hundreds of deployments. Even if you have the horsepower to run large deployments on your system, you will have problems wiring it all up to match production.

replies(2): >>43116932 #>>43117848 #
remram ◴[20 Feb 25 16:45 UTC] No.43116932[source]▶
And you can't develop one of those "deployments" without all the other ones being present?

That just seems like super-terrible engineering, but I can believe it. Gotta be "web-scale".

replies(2): >>43117089 #>>43122197 #
1. kube-system ◴[20 Feb 25 16:55 UTC] No.43117089[source]▶
That's quite a big conclusion to draw from my statement. Whether or not it is good engineering or not really depends on the problem you're solving, your team structure, your integration footprint, etc. Not everything is a custom CRUD app.
replies(1): >>43119362 #
2. cassianoleal ◴[20 Feb 25 19:57 UTC] No.43119362[source]▶
> the problem you're solving, your team structure, your integration footprint

Those are factors to be accounted for in good engineering.

replies(1): >>43120720 #
3. kube-system ◴[20 Feb 25 21:48 UTC] No.43120720[source]▶
Engineering is dictated by the problems you are given to solve, not the other way around. There are many valid situations in which well engineered solutions will have a developer running an entire kubernetes cluster.

For a dead simple example: You may want to do this if the team is small enough that your developer is also your QA engineer... because you can't test the entire application if you're not running the entire application. There are likely hundreds of other reasons too.

To suggest that "any technology with >3 interconnected components is bad engineering" is naive.

replies(1): >>43133100 #
4. remram ◴[21 Feb 25 21:17 UTC] No.43133100{3}[source]▶
You shifted the goalpost from "needs a cluster to run" to "3 components" just so you could call us naive?