0308 19:51:03.118430 4484 node.go:197] Started Kubelet for node openshiftdev.local, server at 0.0.0.0:10250 I0308 19:51:03.118459 4484 node.go:199] Kubelet is setting 10.0.2.15 as a DNS nameserver for domain "local"
×
Networking
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. However, it is not recommended that you have a pod talk to another directly by using the IP address. Instead, we recommend that you create a service, then interact with the service.
OpenShift 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 IP, 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 has a built-in DNS so that the services can be reached by the service DNS as well as the service IP/port. OpenShift 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 Docker 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 Docker behavior. The master will answer queries on the .cluster.local domain
that have the following form:
| 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 creates a new IP for the service. This also removes the need to use
environment variables, as pods can use the service DNS. Also, as the DNS does not change, you can reference database services as
db.local in config files. Wildcard lookups are also supported, as 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.
OpenShift SDN
OpenShift deploys a software-defined networking (SDN) approach for connecting Docker containers in an OpenShift cluster. The OpenShift SDN connects all containers across all node hosts, providing a unified cluster network.
OpenShift SDN is automatically installed and configured as part of the Ansible-based installation procedure. Further administration should not be required; however, further details on the design and operation of OpenShift SDN are provided for those who are curious or need to troubleshoot problems.