Kubernetes Microservice Networking Fix - CoreDNS and DNS resolution
Budget: ₹1,250 – ₹2,500 INR
I run a Spring Boot-based microservices platform on Kubernetes, and lately the cluster has been suffering intermittent service-to-service time-outs. The pattern is clearest inside the cluster: internal services occasionally fail to resolve one another’s DNS names or can’t establish a TCP connection even though the target pods are healthy.
The environment uses both CoreDNS and some legacy Kube-DNS deployments, so part of the job will be digging into how those two interact, spotting misconfigurations, and capturing any odd CoreDNS behaviours that only surface under load. No service mesh is currently deployed, but if you discover that introducing Istio, Linkerd, or Consul would give a cleaner answer to our traffic-routing problems, I’m open to that discussion as a follow-up.
***************************************************************************
Key Responsibilities:
1. Analyze CoreDNS, kube-proxy, and service routing behavior
2. Diagnose and fix intermittent internal HTTP call failures
3. Review service definitions, readinessProbe, DNS, and retry policies
4. Enable and analyze CoreDNS query logs
5. Suggest improvements to:
6. Service definitions
7. Retry and timeout handling in Spring Boot
8. Circuit breaker configurations (e.g., Resilience4j/Spring Retry)
9. Document root cause and permanent fixes
*********************************************************************************
Required Skills:
✅ Expert in Kubernetes Networking: Services, Endpoints, CoreDNS, kube-proxy, FQDNs
✅ Hands-on debugging experience in RKE2, RKE, EKS, or other k8s clusters
✅ Strong Spring Boot expertise (especially RestTemplate, WebClient, Feign clients)
✅ Experience with logging, tracing (Zipkin/Jaeger), and circuit breakers (Resilience4j/Spring Retry)
✅ Familiar with Linux tools: nslookup, dig, tcpdump, etc.
✅ Familiar with YAMLs, ConfigMaps, and Helm-based deployments
✅ Optional: Experience with service mesh (Istio, Linkerd) and observability tools
The environment uses both CoreDNS and some legacy Kube-DNS deployments, so part of the job will be digging into how those two interact, spotting misconfigurations, and capturing any odd CoreDNS behaviours that only surface under load. No service mesh is currently deployed, but if you discover that introducing Istio, Linkerd, or Consul would give a cleaner answer to our traffic-routing problems, I’m open to that discussion as a follow-up.
***************************************************************************
Key Responsibilities:
1. Analyze CoreDNS, kube-proxy, and service routing behavior
2. Diagnose and fix intermittent internal HTTP call failures
3. Review service definitions, readinessProbe, DNS, and retry policies
4. Enable and analyze CoreDNS query logs
5. Suggest improvements to:
6. Service definitions
7. Retry and timeout handling in Spring Boot
8. Circuit breaker configurations (e.g., Resilience4j/Spring Retry)
9. Document root cause and permanent fixes
*********************************************************************************
Required Skills:
✅ Expert in Kubernetes Networking: Services, Endpoints, CoreDNS, kube-proxy, FQDNs
✅ Hands-on debugging experience in RKE2, RKE, EKS, or other k8s clusters
✅ Strong Spring Boot expertise (especially RestTemplate, WebClient, Feign clients)
✅ Experience with logging, tracing (Zipkin/Jaeger), and circuit breakers (Resilience4j/Spring Retry)
✅ Familiar with Linux tools: nslookup, dig, tcpdump, etc.
✅ Familiar with YAMLs, ConfigMaps, and Helm-based deployments
✅ Optional: Experience with service mesh (Istio, Linkerd) and observability tools