It’s not always DNS — unless it is
<p>There is a classic Sysadmin explanation given when there’s something odd happening with the network, <strong>“it’s always DNS.”</strong></p>
<p>Most of the time, it’s actually something else though, for example, a layer-8 issue (human error). But in this blog post, I want to tell you about how we spent weeks jumping down a different rabbit hole until we found that this time the problem really was caused by <strong>DNS</strong>.</p>
<p><img alt="" src="https://miro.medium.com/v2/resize:fit:630/1*FHMRtwmo71YhrJihYwIEZQ.png" style="height:435px; width:700px" /></p>
<p>Good old Sysadmin joke</p>
<h1>Background</h1>
<p>Before rushing into the story, I first want to explain a little bit about what we do.</p>
<p>At<a href="https://www.adevinta.com/" rel="noopener ugc nofollow" target="_blank"> <strong>Adevinta</strong></a>, our team operates an internal Platform as a Service: <strong>The Common Platform</strong>, where Software Engineers from across <a href="https://www.adevinta.com/our-brands" rel="noopener ugc nofollow" target="_blank">our marketplaces</a> can build, deploy and manage their Microservices.</p>
<p>These Microservices run atop <strong>SCHIP</strong>, a runtime built on top of Kubernetes.</p>
<p>SCHIP runs a multi-tenant Kubernetes environment where we have more than 20 tenants in many clusters. In any given cluster, multiple deployments of several tenants are operating at the same time.</p>
<p><a href="https://medium.com/adevinta-tech-blog/its-not-always-dns-unless-it-is-16858df17d3f">Click Here</a></p>