Kubernetes Tips: How to find the Port of a Service with a DNS request
The tip
As you probably know, DNS service runs on Kubernetes to resolve the local service names. When your app A needs access to an app B from the same namespace, you will use it as a root domain "app-b.svc". Then your app will look at the nameserver to target (the one running on Kubernetes) and request to resolve "app-b.svc" into an IP address. For your application, it is transparent.
I don't want to make it too long, so here is the DNS request to get the port of a Kubernetes service:
You should get an output similar to this one:
Not clear enough? Here is a request to get only the port
Yes, the port is 80!
How does it work
A DNS service is a database of records. You can see it as a KV store (it is a bit more complex, of course). You can store and return much more than just the IP address. This is what happens here. By asking the DNS service to resolve the SRV record of "*._tcp.app-z082e36c4.z489e9616-z209c3fd6.svc.cluster.local" I get the following answer.
The SRV record is used as a Service Discovery record. The structure is the following: "IN SRV 0 100 <port> <service>.<ns>.svc.<zone>."
Conclusion
Thanks to Romain Gerard - Software Engineer @ Qovery, for this tip that saves my day 😍
This trick is directly used in my API Gateway run.sh script and is super helpful for our customers. You know how to get the port of one of Kubernetes services right from one of your apps now.
.svg)
.svg)
.svg)
Suggested articles
Because various organizations need cloud application and service management that offers different levels of simplicity, cost-effectiveness, or feature sets than OpenShift, this article will review its top alternatives to help readers make an informed decision aligned with their specific infrastructure needs.
Running GPU workloads on EKS has never been easy, until now. With Qovery’s latest update, you can enable GPU nodes, configure GPU access, and optimize costs automatically, all without writing a single line of YAML or touching Helm charts. Qovery now handles everything behind the scenes so you can focus entirely on your applications.
Master Kubernetes deployment strategies: Rolling Update, Recreate, Blue/Green, and Canary. Learn the pros, cons, and use cases to choose the right strategy based on your uptime, risk tolerance, and resources. Simplify complex rollouts with automation.
Confused about which AWS container service to use? This comprehensive guide compares the trade-offs between simplicity, control, and complexity for ECS, EKS, and Elastic Beanstalk to help you choose the right platform for your application.
Planning your ECS to EKS migration? Learn the strategic business case (portability, ecosystem access), navigate the step-by-step roadmap, and avoid common pitfalls (networking, resource allocation). Discover how Qovery automates EKS complexity for a seamless transition.
Is Fargate too simple or Kubernetes too complex for your scale-up? Compare AWS Fargate vs. EKS on cost, control, and complexity. Then, see how Qovery automates Kubernetes, giving you its power without the operational headache or steep learning curve.
Dive into the ultimate FluxCD vs. ArgoCD debate! Learn the differences between these top GitOps tools (CLI vs. UI, toolkit vs. platform) and discover a third path: Qovery, the DevOps automation platform that abstracts away Kubernetes complexity, handles infrastructure, and lets you ship code faster.
Qovery unveils its new brand identity, reinforcing its mission to make DevOps simple, intuitive, and powerful. Discover how our DevOps automation platform simplifies infrastructure, scaling, security, and innovation across the full DevOps lifecycle.
.webp)