<p>I am trying to deploy my php symfony application on Azure Kubernetes Services. I have the following <code>deployment.yaml</code> for php pod</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: myphp-deployment
  labels:
    app: php
spec:
  replicas: 1
  selector:
    matchLabels:
      app: php
  template:
    metadata:
      labels:
        app: php
    spec:
      containers:
      - name: php
        image: myimage
        ports:
        - containerPort: 9000
</code></pre>
<p>Heres's the php service yaml</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: php
spec:
  selector:
    app: php
  ports:
    - protocol: TCP
      port: 9000
      targetPort: 9000
</code></pre>
<p>Here's my nginx deployment yaml</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: mynginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myimage
        ports: 
        - containerPort: 80
</code></pre>
<p>And my nginx-service yaml</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
type: LoadBalancer
</code></pre>
<p>With the above setup in place, everything is working fine. However, if I increase the replica set to two i.e <code>replicas:2</code> for php pod, the app is <strong>not consistently maintaining the states</strong>.</p>
<p>I found that the requests from my nginx pod is forwarded to either of the two replicas(of php), and it is logging me out. Sometimes, it logs me in but the application is not consitent in terms of behaviour.</p>
<p>How can I control to which replica set the requests should be forwarded to? Or is there a way to dynamically provision another replica if the existing pod fails?</p>
<p><strong>P.S I am very new to Kubernetes</strong></p>

<p><strong>How can I control to which replica set the requests should be forwarded to?</strong></p>
<p>What you are looking for is the session affinity or sticky session. This can be achieved with ingress. The kubernetes ingress controllers, such as <a href="https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/" rel="nofollow noreferrer">Nginx ingress</a> controller already has these requirement considered and implemented. The ingress controller replies the response with a Set-Cookie header to the first request. The value of the cookie will map to a specific pod replica. When the subsequent request come back again, the client browser will attach the cookie and the ingress controller is therefore able to route the traffic to the same pod replica.</p>
<p>Kubernetes has the mechanisms to have the stable pod name like <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a>  or discover the sets of pods with <a href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" rel="nofollow noreferrer">Headless Service</a> but those solutions while great, won't be as good as sticky session in your use case. Still if you're totally new to Kubernetes its worth checking them out.</p>
<p><strong>Or is there a way to dynamically provision another replica if the existing pod fails?</strong></p>
<p>If you're application will crash Kubernetes will try to restart it. This is being controller by <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy" rel="nofollow noreferrer">Container restart policy</a>:</p>
<blockquote>
<p>The  <code>spec</code>  of a Pod has a  <code>restartPolicy</code>  field with possible
values Always, OnFailure, and Never. The default value is Always.</p>
<p>The  <code>restartPolicy</code>  applies to all containers in the Pod.
<code>restartPolicy</code>  only refers to restarts of the containers by the
kubelet on the same node. After containers in a Pod exit, the kubelet
restarts them with an exponential back-off delay (10s, 20s, 40s, …),
that is capped at five minutes. Once a container has executed for 10
minutes without any problems, the kubelet resets the restart backoff
timer for that container.</p>
</blockquote>
<p>In some situation you may encounter that your application is falling or not working properly but still its not crashing/restarting. In this case you can use the Kubernetes <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">livenessProbe</a>. Kubernetes can check if a container is still alive through liveness probes. You can specify a liveness probe for each container in the pod’s specification. Kubernetes will periodically execute the probe and restart the container if the probe fails.</p>
