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
Build Your Own PaaS: Stop depending on fixed cloud offerings. Discover the top 8 tools, including Qovery, Dokku, and Cloud Foundry, that let you build a customizable, low-maintenance PaaS on your cloud infrastructure.
Simplify Kubernetes Deployment. Learn the difficult 6-step manual process for deploying Docker containers to Kubernetes, the friction of YAML and kubectl, and how platform tools like Qovery automate the entire workflow.
Observability in DevOps: Diagnose system failures faster. Learn how true observability differs from traditional monitoring. End context-switching, reduce MTTR, and resolve unforeseen issues quickly.
Integrate security seamlessly into your CI/CD pipeline. Learn the 6 best DevSecOps practices—from Policy as Code to continuous monitoring—and see how Qovery automates compliance and protection without slowing development.
Fed up of rising Heroku costs and frequent outages? This guide compares the top 10 Heroku alternatives and competitors based on features, pricing, pros, and cons—helping developers and tech leaders choose the right PaaS.
Provisioning cloud resources shouldn’t require a second stack of tools. With Qovery’s new Terraform and OpenTofu support, you can now define and deploy your infrastructure right alongside your applications. Declaratively, securely, and in one place. No external runners. No glue code. No tool sprawl.
Looking for a Flux CD alternative? Discover why Qovery stands out as the #1 choice. Compare features, pros, and cons of the top 10 platforms to simplify your deployment strategy and empower your team.
.webp)