Internal Networking

Kubernetes Cluster: Internal Networking

Internal networking inside a Kubernetes Cluster is configured automatically. The cluster CNI creates an overlay network and assigns IP addresses to pods, while Kubernetes Services and CoreDNS provide stable service discovery and name resolution between workloads.
CNI Overlay Network Automatically creates the Kubernetes pod network and provides IP addresses to pods.
Kubernetes Services Provide stable internal access to applications without relying on changing individual pod IP addresses.
CoreDNS Resolves Kubernetes service names and internal platform hostnames from inside pods.
Platform Connectivity Kubernetes pods can connect directly to other containers hosted inside the same platform using platform DNS names.
On this page

Automated Pod Networking

The Kubernetes Cluster automatically configures its internal networking. The CNI plugin creates an overlay network that connects Kubernetes workloads and assigns IP addresses to pods.

  • No manual pod-network setup is required for the standard Kubernetes Cluster package.
  • Pods receive network addresses through the cluster networking layer.
  • The overlay network allows workloads running on different Kubernetes nodes to communicate through the Kubernetes networking model.
Pod IP addresses should not normally be treated as permanent application endpoints. Use Kubernetes Service objects to provide stable access to groups of pods.

Access Services by Name

Kubernetes supports direct access to Services by DNS name. A separate service-discovery mechanism is therefore not required for ordinary communication between Kubernetes applications.

For example, an application can connect to a database using the database Service name. Kubernetes resolves that DNS name to the Service’s internal address and forwards traffic to the pods selected by the Service.

Service requirement: Create a Kubernetes Service object with the correct selector so the Service targets the intended application pods.
Application Pod Connects to the database by Service name rather than by an individual database pod IP.
Service Object Uses selectors to locate the correct backend pods and provides a stable internal address.

Default Hello World Example

The standard Kubernetes Cluster package includes a Hello World deployment, Service, and Ingress by default unless the Custom Deployment option was selected during cluster installation.

The pre-deployed Hello World application can be examined as a practical example of how a Kubernetes Deployment, Service, and Ingress work together.

Platform DNS Resolution inside Pods

Kubernetes uses CoreDNS to resolve internal Kubernetes DNS names. The DNS configuration is automatically added to the /etc/resolv.conf file inside each pod.

/etc/resolv.conf

CoreDNS also uses the platform nameservers. This allows Kubernetes pods to resolve and connect directly to other containers running inside the platform, not only to Kubernetes Services.

Connect Kubernetes Pods to Platform Databases

If a database is running in another platform environment, a Kubernetes pod can connect to it using the database node’s internal platform hostname.

${nodeId}-${envName}.${platformDomain}

Use the database’s standard port together with this hostname. Common examples include:

MySQL / MariaDB Default port: 3306
PostgreSQL Default port: 5432
Because CoreDNS can use the platform DNS infrastructure, this connection can remain internal to the platform and does not require exposing the database publicly.

Access from Outside the Platform

Internal platform DNS names are intended for communication inside the platform. If an external system must connect to a database or another internal service, create an appropriate platform endpoint for that service.

Networking summary: Kubernetes pod networking is created automatically by the CNI layer, Kubernetes Services provide stable internal endpoints, CoreDNS resolves both Kubernetes and platform names, and platform endpoints are required when a service must be reached from outside the platform.

What’s next?

  • Kubernetes Helm Integration
  • Kubernetes YAML Deployments
  • Kubernetes Exposing Services
  • Kubernetes Creating Ingresses