<p>I am planning to deploy the Asp.net application that uses session on Azure kubernetes. How do I make sure that the incoming request goes to the same pod where session is created.</p>

One Developer
<p>It is recommended that apps deployed on Kubernetes has a design following the <a href="https://12factor.net/" rel="nofollow noreferrer">The Twelve Factor App</a>.</p>
<p>Everything will be easier if the app is <em>stateless</em> and <em>share nothing</em> with other instances. See <a href="https://12factor.net/processes" rel="nofollow noreferrer">Twelve Factor App - Processes</a></p>
<blockquote>
<p>Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.</p>
</blockquote>
<blockquote>
<p>Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.</p>
</blockquote>
<p>Using <a href="https://redis.io/" rel="nofollow noreferrer">Redis</a> is one way to store temporary data belonging to the user.</p>
<p>For authentication, I would recommend to use OpenID Connect with JWT tokens in the <code>Authorization: Bearer &lt;token&gt;</code> header. See e.g. <a href="https://azure.microsoft.com/en-us/services/active-directory/external-identities/b2c/" rel="nofollow noreferrer">Azure Active Directory B2C</a> for an example of an OpenID Connect provider.</p>
