Comment by remram

Comment by remram 2 days ago

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.

kube-system 2 days ago

> 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.

Reply View 7 replies

remram 2 days ago

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".

Reply View | 5 replies
- cherry_tree a day ago
  
  I think you are talking past each other about different stages of development.
  At early stages you are writing some code and tests within a single component, here you are iterating with a single binary/container. At some stage a change may involve multiple components.
  Once you are satisfied with your code changes you would want to run those components in an environment that simulates how they communicate normally.
  In kubernetes this may mean you need your cluster and its networking components which may need configuration changes tested as part of your new feature, you may have introduced new business metrics which you want to verify are collected and shipped to your desired metrics aggregator so that you can build and expose dashboards, you may want to create new alerts from these metrics and verify that the new alerts trigger as expected, etc
  You can see how you may need to run many components in order to test a change in only one. I don’t think this is bad engineering, and I don’t think it’s specific to kubernetes or “web-scale”.
  
  Reply View | 0 replies
- kube-system 2 days ago
  
  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.
  
  Reply View | 3 replies
  
  cassianoleal a day ago
  
  > the problem you're solving, your team structure, your integration footprint
  Those are factors to be accounted for in good engineering.
  
  Reply View | 2 replies
[removed] 2 days ago

[deleted]

Reply View | 0 replies

[removed] 2 days ago

[deleted]

Reply View 0 replies