Networking

Overview

Kubernetes ensures that pods are able to network with each other, and
allocates each pod an IP address from an internal network. This ensures all
containers within the pod behave as if they were on the same host. Giving each
pod its own IP address means that pods can be treated like physical hosts or
virtual machines in terms of port allocation, networking, naming, service
discovery, load balancing, application configuration, and migration.

Creating links between pods is unnecessary, and it is not recommended that
your pods talk to one another directly using the IP address. Instead, it is
recommended that you create a
service, then interact
with the service.

OpenShift Container Platform DNS

If you are running multiple
services, such as
frontend and backend services for use with multiple pods, in order for the
frontend pods to communicate with the backend services, environment variables
are created for user names, service IPs, and more. If the service is deleted and
recreated, a new IP address can be assigned to the service, and requires the
frontend pods to be recreated in order to pick up the updated values for the
service IP environment variable. Additionally, the backend service has to be
created before any of the frontend pods to ensure that the service IP is
generated properly, and that it can be provided to the frontend pods as an
environment variable.

For this reason, OpenShift Container Platform has a built-in DNS so that the services can be
reached by the service DNS as well as the service IP/port. OpenShift Container Platform
supports split DNS by running
SkyDNS on the master that answers
DNS queries for services. The master listens to port 53 by default.

When the node starts, the following message indicates the Kubelet is correctly
resolved to the master:

If the second message does not appear, the Kubernetes service may not be available.

On a node host, each container’s nameserver has the master name added to the
front, and the default search domain for the container will be
.<pod_namespace>.cluster.local. The container will then direct any nameserver
queries to the master before any other nameservers on the node, which is the
default behavior for Docker-formatted containers. The master will answer queries on the .cluster.local domain
that have the following form:

Table 1. DNS Example Names

Object Type

Example

Default

<pod_namespace>.cluster.local

Services

<service>.<pod_namespace>.svc.cluster.local

Endpoints

<name>.<namespace>.endpoints.cluster.local

This prevents having to restart frontend pods in order to pick up new services,
which would create a new IP for the service. This also removes the need to use
environment variables, because pods can use the service DNS. Also, as the DNS does not change, you can reference database services as
db.local in configuration files. Wildcard lookups are also supported, because any lookups
resolve to the service IP, and removes the need to create the backend service
before any of the frontend pods, since the service name (and hence DNS) is
established upfront.

This DNS structure also covers headless services, where a portal IP is not
assigned to the service and the kube-proxy does not load-balance or provide
routing for its endpoints. Service DNS can still be used and responds with
multiple A records, one for each pod of the service, allowing the client to
round-robin between each pod.