<p>We are using k8s for deploying our application and it works awesome.But there is a small issue.We have moved from http layer communication to tcp layer.And the communication between different micro-services is through the service (k8s service) name and it works great but the developer can't test the same code locally as the service name will be resolved inside the cluster only.So here are some solutions that I have :-</p>
<p>1.Provided them a different name space where they can test the app with small changes.</p>
<p>The issue with this is that the developers use some break points and test some small changes in code and debug that will be hard by this method.</p>
<p>2.They can implement minikube in local but that doesn't sound good to even me.</p>
<p>3.They can run the container for ms locally and enter the ip of container in /etc/hosts corresponding to the k8s service name.In this the same code will work.
Any other better solutions are welcomed.
😔😔😭😭</p>

Renu Saharan
<p>Did you consider using <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-profiles" rel="nofollow noreferrer">spring boot profiles</a> for this purpose? We are using it effectively for long across our teams. For this purpose, you'll have to extract the service(s) host as separate properties in application.yml (or application.properties) and use this host in rest of the properties as a variable. Following snippet explains this</p>
<pre><code>application.yml
----------------
serviceA:
  host: service-A-Name
  api-one-endpoint: http://${serviceA.host}/api/v1/one
  api-two-endpoint: http://${serviceA.host}/api/v1/two
  api-three-endpoint: http://${serviceA.host}/api/v1/three
  api-four-endpoint: http://${serviceA.host}/api/v1/four
</code></pre>
<p>In production (any hosted/managed environment for that matter), you provide appropriate value for spring property serviceA.host. In your use case, you'll be using this value AS-IS and provide k8s service name binding instead.</p>
<p>For local dev environment, you only need to override single property. For simple use case (say you need to override only single property), you can pass it as an agrument to your spring boot launcher (e.g. &quot;--serviceA.host=localhost&quot;). If you have many services (you likely do) even then you'll need to override well known few host name properties only. Using a dedicated dev profiles is much better in this case. Following example illustrate same scenario</p>
<pre><code>application-dev.yml
-------------------
serviceA:
  host: mylocalhost:9090
</code></pre>
<p>Then you use this profile in your eclipse/intellij launcher configuraiton for execution or debugging purpose by adding &quot;--spring.profiles.active=dev&quot; as and additional argument and spring boot will use updated host from dev profile. In fact combining these two approaches gives you even more flexibility for advance cases. If you agree on a common port convention across team then you can even check-in application-dev.yml for usage by everyone pretty much as-is.</p>
<p>spring boot profiles is much more powerful feature, I'll strongly recommend to go through <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-profiles" rel="nofollow noreferrer">it's documentation</a> and few tutorial (<a href="https://www.baeldung.com/spring-profiles" rel="nofollow noreferrer">like this one</a>) to understand it fully and exploit it effectively for use cases like this one.</p>
