I’ll preface this with everyone’s work pattern is different, but the docker workflow and kubernetes aren’t mutually exclusive. I use docker and docker-compose for a lot of my local testing and hacking on things. That isn’t to say that I don’t have templates for my deployments / services etc, but that workflow is still the easiest when working local.
Tools like skaffold and tilt do make it easier for a more hybrid approach.
For this, it’s sort of how much is acceptable risk. Outside of your own application you may also want to take into account Kubernetes versions and test upgrade/downgrade - this sort of thing lends itself to more multiple clusters where at least prod is running in its own.
Do you mean separate ones for dev/test/prod? If so, I’d suggest just tagging them at the version of your application or use the git commit hash. That way you always know what version of the code is running. These can be promoted from dev/test/prod.
- Sort of your call on skaffold (to my knowledge).
- You definitely can have test be local.If you want to try local kubernetes testing instead of through docker-compose, check out kind.
- If your images are all very tightly coupled it’d probably make sense to keep them together and version them together. If they can vary, it may be worth keeping separate so you can increment or bump them independently.
- Secret is preferred, they’d be passed into the container the same way no matter the env and the db server itself could be an ExternalName service.
- You can access secrets/configmaps the same way in a pod.
- There really isn’t just one good way to go about it. Part of what makes Kubernetes so powerful is its flexibility. This can certainly lead to some level of decision paralysis though. Much of it is just trying to get an idea about what options exist and then trying to align them with what works best for you/your company.
I’m not sure how much those answers will help, but hopefully it sheds a little light on it 