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.
It is recommended that apps deployed on Kubernetes has a design following the The Twelve Factor App.
Everything will be easier if the app is stateless and share nothing with other instances. See Twelve Factor App - Processes
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.
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.
Using Redis is one way to store temporary data belonging to the user.
For authentication, I would recommend to use OpenID Connect with JWT tokens in the Authorization: Bearer <token> header. See e.g. Azure Active Directory B2C for an example of an OpenID Connect provider.