<h2>We want to archieve the following:</h2>

<ul>
<li>Magento Shop running on Google Kubernetes</li>
<li>Deployment via config file (eg. stage.yaml, live.yaml) etc.</li>
<li>PHP 7.2</li>
<li>MySQL 5.6 / MariaDB</li>
<li>Redis</li>
<li>nginx:alpine</li>
<li>https</li>
<li>Persistent volume claims for Magento and MySQL</li>
</ul>

<p>I am learning kubernetes for a few weeks now but I am struggling with some design concepts and some basic questions came up.</p>

<p>I first tried docker-compose, than building docker images via Dockerfiles, stumbled over helm and kubectl. And now I came across building pods and building deployments. Now I know many different things but a real life example or some best practice knowledge would be appreciated. Google is great.. but it seems there is not just one way.</p>

<h3>1. Regarding Pods</h3>

<p>I understand, that pods should be able to be easily replaced / destroyed /recreated ... </p>

<p>Is it better to have a POD configuration like
- nginx container
- php container
- mysql container
- redis container
edit: as I just read, pods share an IP-Adress so it would make no sense to inlcude mysql or redis here, right?</p>

<p>or better one pod with a
- mysql container
and one pod with containers for
- nginx
- php</p>

<p>and another with a 
- redis container</p>

<h3>2. Mounting a persistent volume claim or a remote webroot like /var/www/html locally to work on.</h3>

<p>The content of the local webroot comes from a git repo.</p>

<h3>3. Handling of type: pod vs. type:deployment</h3>

<p>I can create a yaml file for defining the containers inside my pod (type:pod). But I also can define a deployment.yaml (type:deployment).</p>

<p>Do I have to reference my pod.yaml inside my deployment.yaml or does the deployment includes all pod configuration and replaces the pod.yaml?</p>

John Jameson
<p><strong>Regarding Pods.</strong>
You can create one pod with everything you need. But that will be very fat pod. Remember, pod runs only on one node, it is not possible to run one pod partially on one node, and partially on another. One pod runs only on one node. That means from scalability standpoint many small pods are better than one big. Many small pods also generally provide more uniform resource and load distribution between nodes.</p>

<p>Also when you update one container in pod - the whole pod gets restarted. So if you have application and database in the same pod - if you update app code - database will also be restarted. Not cool, eh?</p>

<p>But in some cases running several containers in one pod may be reasonable. Remember, all containers in pod share network address and localhost. So containers within pod have very low network latency. </p>

<p>Also containers within pod can share volumes between each other. That is also important in some cases. </p>

<p><strong>Persistent volumes</strong>
You cannot mount a Git repo into pod. Well, at least that's not what you should do. You should pack your webroot into Docker image and run that in Kubernetes. And this should be done by Jenkins which can build on commit. </p>

<p>Alternatively you can place your files onto shared persistent volume if you want to share files between deployment replicas. That is also possible, you must find so called ReadWriteMany volumes like NFS or GlusterFS that can be shared between multiple pods.</p>
