CODEWITHSUNDEEP
dockerkubernetes
korovaisdead
korovaisdead

Reputation: 6341

Kubernetes questions. Configuration files.

I'm quite new to the kubernetes and just wondering about several things.

Consider I have two repositories (front-e, backe-e). Each of them builds into the docker image.

I want to manage these two images with the kubernetes and run them inside the cluster.

What is the best practice to store deployments *.yml files in such a case? The separate repo?

Upvotes: 2

Views: 1053

Answers (2)

iamnat
iamnat

Reputation: 4166

Similar answer to a similar question here: Best practices for storing kubernetes configuration in source control

Like David says, you can always try using helm. However, I would recommend against helm for simple projects or if you're just starting out. I find it complex and hesitate to run another stateful component on my k8s cluster.

I'm listing out some other options below.

TL;DR: (In order of personal preference)

  • Monorepo with all source code and yaml files in one place
  • yaml files in a seperate k8s repo
  • yaml files in source code repos (next to the Dockerfile that you presumably have in each repo)

1. Monorepo

  • Seperate folders for each microservice.
  • Microservice specific k8s yamls (deployment.yml, service.yml) go inside the microservice folders
  • Folder for cluster-wide configuration and k8s resources (ingress/api-gateway)
  • Folder for integration tests

If you're worried about monorepos, do read about them before you decide to ditch them because they don't sound elegant ;)

Protip: Add some client-side jinja templating if you have multiple k8s clusters and you don't want to write a different k8s file per cluster.

2. Separate k8s repo

Same as 1, but without the source code.

3. k8s files inside separate source repos

Keep the deployment, service yml files within the repos. This is probably the best if both microservices are completely decoupled, can be independently tested and don't really need any common k8s resources that need to be created. I've never come across this in practice though. I've had to merge repos of 7 different microservices into one repo for release sanity.

Upvotes: 2

David Steiman
David Steiman

Reputation: 3145

IMHO the best practice for this is helm, the Kubernetes, package manager. In short, it allows you to use k8s manifests, such as deployment, service, persistence, etc., with the option to parameterize these with variables.

You ask if it is better to keep these files in-repo or outside. Both ways have their pros and cons.

the helm way

When using helm, the best practice is to make a separate repo for only the helm charts (chart = kubernetes package). The advantage is here that you can build your central repository, where all your "packages" are collected including their version history.

in-repo

This makes the work for other developers easier, as everything related to your project, is in its repository.

no helm, just the yaml files

You just can use the raw manifests, which is much easier and also has fewer options. My personal best practice here is: placing pure config files in-repo, until I push it to the helm level, and place it in a central chart.

Upvotes: 2

Related Questions