<p>I am very new to <code>k8s</code> and <code>docker</code>. But I have task on k8s. Now I stuck with a use case. That is:</p>
<blockquote>
<p>If a container is busy with requests. Then incoming request should redirect to another container.</p>
</blockquote>
<p><strong>deployment.yaml</strong></p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: twopoddeploy
  namespace: twopodns
spec:
  selector:
    matchLabels:
      app: twopod
  replicas: 1
  template:
    metadata:
      labels:
        app: twopod
    spec:
      containers:
      - name: secondcontainer
        image: &quot;docker.io/tamilpugal/angmanualbuild:latest&quot;
        env:
        - name: &quot;PORT&quot;
          value: &quot;24244&quot;
      - name: firstcontainer
        image: &quot;docker.io/tamilpugal/angmanualbuild:latest&quot;
        env:
        - name: &quot;PORT&quot;
          value: &quot;24243&quot;

          
</code></pre>
<p><strong>service.yaml</strong></p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: twopodservice
spec:
  type: NodePort
  selector:
    app: twopod
  ports:
  - nodePort: 31024
    protocol: TCP
    port: 82
    targetPort: 24243
</code></pre>
<p>From <code>deployment.yaml</code>, I created a pod with two containers with same image. Because, <strong><code>firstcontainer</code> is not reachable/ busy, then <code>secondcontainer</code> should handles the incoming requests.</strong> This our idea and use case. So (only for checking our use case) I delete <code>firstcontainer</code> using <code>docker container rm -f id_of_firstcontainer</code>. Now site is not reachable until, docker recreates the <code>firstcontainer</code>. But I need k8s should redirects the requests to <code>secondcontainer</code> instead of waiting for <code>firstcontainer</code>.</p>
<p>Then, I googled about the solution, I found <code>Ingress</code> and <code>Liveness - Readiness</code>. But <code>Ingress</code> does route the request based on the path instead of container status. <code>Liveness - Readiness</code> also recreates the container. <code>SO</code> also have some question and some are using <code>ngix</code> server. But no luck. That why I create a new question.</p>
<p>So my question is how to configure the two containers to reduce the downtime?</p>
<p>what is keyword for get the solution from the google to try myself?</p>
<p>Thanks,</p>
<p>Pugal.</p>

Pugal
<p>A service can load-balance between multiple pods.  You should delete the second copy of the container inside the deployment spec, but also change it to have <code>replicas: 2</code>.  Now your deployment will launch two identical pods, but the service will match both of them, and requests will go to both.</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: onepoddeploy
  namespace: twopodns
spec:
  selector: { ... }
  replicas: 2 # not 1
  template:
    metadata: { ... }
    spec:
      containers:
      - name: firstcontainer
        image: &quot;docker.io/tamilpugal/angmanualbuild:latest&quot;
        env:
        - name: &quot;PORT&quot;
          value: &quot;24243&quot;
      # no secondcontainer
</code></pre>
<p>This means if two pods aren't enough to handle your load, you can <code>kubectl scale deployment -n twopodns onepoddeploy --replicas=3</code> to increase the replica count.  If you can tell from CPU utilization or another metric when you're getting to &quot;not enough&quot;, you can configure the <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/" rel="nofollow noreferrer">horizontal pod autoscaler</a> to adjust the replica count for you.</p>
<p>(You will usually want only one container per pod.  There's no way to share traffic between containers in the way you're suggesting here, and it's helpful to be able to independently scale components.  This is doubly true if you're looking at a stateful component like a database and a stateless component like an HTTP service.  Typical uses for multiple containers are things like log forwarders and network proxies, that are somewhat secondary to the main operation of the pod, and can scale or be terminated along with the primary container.)</p>
<p>There are two important caveats to running multiple pod replicas behind a service.  The service load balancer isn't especially clever, so if one of your replicas winds up working on intensive jobs and the other is more or less idle, they'll still each get about half the requests.  Also, if your pods are configure for HTTP health checks (recommended), if a pod is backed up to the point where it can't handle requests, it will also not be able to answer its health checks, and Kubernetes will kill it off.</p>
<p>You can help Kubernetes here by trying hard to answer all HTTP requests &quot;promptly&quot; (aiming for under 1000 ms <em>always</em> is probably a good target).  This can mean returning a &quot;not ready yet&quot; response to a request that triggers a large amount of computation.  This can also mean rearranging your main request handler so that an HTTP request thread isn't tied up waiting for some task to complete.</p>
