<p>I have the same problem as the following:
<a href="https://stackoverflow.com/questions/54289786/dual-nginx-in-one-kubernetes-pod">Dual nginx in one Kubernetes pod</a></p>

<p>In my Kubernetes <code>Deployment</code> template, I have 2 containers that are using the same port 80.
I understand that containers within a <code>Pod</code> are actually under the same network namespace, which enables accessing another container in the <code>Pod</code> with <code>localhost</code> or <code>127.0.0.1</code>. 
It means containers can't use the same port.</p>

<p>It's very easy to achieve this with the help of <code>docker run</code> or <code>docker-compose</code>, by using <code>8001:80</code> for the first container and <code>8002:80</code> for the second container.</p>

<p>Is there any similar or better solution to do this in Kubernetes Pod ? Without separating these 2 containers into different Pods.</p>

crossRT
<p>Basically I totally agree with <em>@David's</em> and <em>@Patric's</em> comments but I decided to add to it a few more things expanding it into an answer.</p>

<blockquote>
  <p>I have the same problem as the following: <a href="https://stackoverflow.com/questions/54289786/dual-nginx-in-one-kubernetes-pod">Dual nginx in one Kubernetes pod</a></p>
</blockquote>

<p>And there is already a pretty good answer for that problem in a mentioned thread. From the technical point of view it provides ready solution to your particular use-case however it doesn't question the idea itself.</p>

<blockquote>
  <p>It's very easy to achieve this with the help of docker run or
  docker-compose, by using 8001:80 for the first container and 8002:80
  for the second container.</p>
</blockquote>

<p>It's also very easy to achieve in <strong>Kubernetes</strong>. Simply put both containers in different <code>Pods</code> and you will not have to manipulate with nginx config to make it listen on a port different than <code>80</code>. Note that those two docker containers that you mentioned don't share a single network namespace and that's why they can both listen on ports <code>80</code> which are mapped to different ports on host system (<code>8001</code> and <code>8002</code>). This is not the case with <strong>Kubernetes</strong> <em>Pods</em>. Read more about <strong>microservices architecture</strong> and especially how it is implemented on <strong>k8s</strong> and you'll notice that placing a few containers in a single <code>Pod</code> is really rare use case and definitely should not be applied in a case like yours. There should be a good reason to put 2 or more containers in a single <code>Pod</code>. Usually the second container has some complimentary function to the main one.</p>

<p>There are <a href="https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/" rel="noreferrer">3 design patterns for multi-container Pods, commonly used in <strong>Kubernetes</strong></a>: sidecar, ambassador and adapter. Very often all of them are simply referred to as <strong>sidecar containers</strong>.</p>

<p>Note that 2 or more containers coupled together in a single <code>Pod</code> in all above mentioned use cases <em>have totally different function</em>. Even if you put more than just one container in a single <code>Pod</code> (which is most common), in practice it is never a container of the same type (like two nginx servers listening on different ports in your case). They should be complimentary and there should be a good reason why they are put together, why they should start and shut down at the same time and share same network namespace. Sidecar container with a monitoring agent running in it has complimentary function to the main container which can be e.g. nginx webserver. You can read more about container design patterns in general in <a href="https://techbeacon.com/enterprise-it/7-container-design-patterns-you-need-know" rel="noreferrer">this</a> article.</p>

<blockquote>
  <p>I don't have a very firm use case, because I'm still
  very new to Kubernetes and the concept of a cluster. </p>
</blockquote>

<p>So definitely don't go this way if you don't have particular reason for such architecture.</p>

<blockquote>
  <p>My initial planning of the cluster is putting all my containers of the system
  into a pod. So that I can replicate this pod as many as I want.</p>
</blockquote>

<p>You don't need a single <code>Pod</code> to replicate it. You can have in your cluster a lot of <code>replicaSets</code> (usually managed by <code>Deployments</code>), each of them taking care of running declared number of replicas of a <code>Pod</code> of a certain kind.</p>

<blockquote>
  <p>But according to all the feedback that I have now, it seems like I going
  in the wrong direction.</p>
</blockquote>

<p>Yes, this is definitely wrong direction, but it was actually already said. I'd like only to highlight why namely this direction is wrong. Such approach is totally against the idea of <em>microservices architecture</em> and this is what <strong>Kubernetes</strong> is designed for. Putting all your infrastructure in a single huge <code>Pod</code> and binding all your containers tightly together makes no sense. Remember that a <code>Pod</code> <em>is the smallest deployable unit in <strong>Kubernetes</em></strong> and when one of its containers crashes, the whole <code>Pod</code> crashes. There is no way you can manually restart just one container in a <code>Pod</code>.</p>

<blockquote>
  <p>I'll review my structure and try with the
  suggests you all provided. Thank you, everyone! =)</p>
</blockquote>

<p>This is a good idea :)</p>
