<p>I'm quite new to the kubernetes and just wondering about several things.</p>

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

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

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

<p>Similar answer to a similar question here: <a href="https://stackoverflow.com/questions/47168381/best-practices-for-storing-kubernetes-configuration-in-source-control">Best practices for storing kubernetes configuration in source control</a></p>

<p>Like David says, you can always try using <a href="https://github.com/kubernetes/helm" rel="nofollow noreferrer">helm</a>. 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. </p>

<p>I'm listing out some other options below.</p>

<p><strong>TL;DR: (In order of personal preference)</strong></p>

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

<hr>

<p><strong>1. Monorepo</strong></p>

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

<p>If you're worried about monorepos, do read <a href="https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9" rel="nofollow noreferrer">about</a> <a href="https://developer.atlassian.com/blog/2015/10/monorepos-in-git/" rel="nofollow noreferrer">them</a> before you decide to ditch them because they don't sound elegant ;)</p>

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

<p><strong>2. Separate k8s repo</strong></p>

<p>Same as 1, but without the source code. </p>

<p><strong>3. k8s files inside separate source repos</strong></p>

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