<p>I have a frontend instance (Angular app on nginx), which proxies calls to backend under a specific domain (let's say <code>backend-app</code>). Everything's easy when there is only one instance of both backend and frontend - I name the Service <code>backend-app</code> and DNS resolves to the correct backend Deployment.</p>

<p>Let's say I have another version of backend which I would like to test before merging to master. As nginx configuration of frontend instance is hardcoded to proxy to <code>backend-api</code>, creating another Service under the same name for a newer version of backend doesn't work. </p>

<p>I considered these options:</p>

<ol>
<li>Making an environment variable and substituting domain name in nginx proxy configuration during runtime. This way I could be flexible about where do I want to route frontend calls to. Cons of this solution, as far as I have investigated, is that this approach beats the purpose of self-containment, that is, it becomes ambiguous what is the frontend's backend client and this type of configuration is prone to errors.</li>
<li>Creating different namespace every time I want to test things. While this allows spinning the whole stack without any problem or conflict, it seems to me that it's a huge overhead to create namespaces just for testing something once.</li>
<li>Having some fancy configurations combining labels and selectors. I couldn't think or find how to do it.</li>
</ol>

<p>Any other opinions/suggestions you might have?</p>

pkey
<h1>Try this approach</h1>

<p>add label name:backend-1 to backend1 pod<br>
add label name:backend-2 to backend2 pod  </p>

<p>create a service using backend-1 selector.</p>

<p>to test against other backend, say backend2, all you have to do is edit the service yaml file and update the selector. you can toggle this way to test between backend1 and backend2</p>
