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
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes is an open-source platform that automates the deployment, scaling, and management of containerized applications. While originally designed to orchestrate single-cluster workloads, modern enterprise use cases require managing Kubernetes at fleet scale, coordinating thousands of clusters across multi-cloud environments to enforce cost governance, security policies, and automated lifecycle management.
The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards
Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.
A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.
Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
.webp)