Networking using Services
Each Pod has its own IP address. Containers within a Pod can communicate with each other via their ports over
localhost. But how does one Pod communicate with another? We cannot rely on a Pod’s IP address because they get dynamically created or destroyed along with the Pod. The solution: We use a Kubernetes Service which sits in front of a group of Pods and which will give us a stable DNS name and IP address that never change, no matter if more Pods are created or destroyed.
How does a Service know which Pods it should service? Answer: It looks for any Pods having at least (!) the same Labels defined as the Service itself.
In the image above, the Service additionally serves Pods labeled as “1.3” and “1.4”, meaning both versions are load balanced. In a next step you could add label “1.4” to the Service to kick the “1.3” Pods out.
Nice to know: Services only send traffic to healthy Pods. They can do session affinity, send traffic to endpoints outside the cluster, and can do TCP (default) and UDP.
Pods don’t self-heal. We have to rely on higher ordered layers such as rs (replica set) and deploy.
You can create Services declaratively (preferred) via YAML file or imperatively via kubectl commands.
Declarative: You define services via a YAML file and connect Services to Pods by defining the same label for the Service and Pods. A Service is a REST object of the Kubernetes API. Together with creating a service, Kubernetes is additionally creating an Endpoint object which contains a list of all the healthy pods which match the service Label.
When accessing Pods we have to distinguish between accessing the service from inside the cluster or externally (e.g. via browser from your laptop).
If you have minikube installed you can use that handy command to output under which url a service is reachable:
minikube service <service-name> --url.
A Service provides a single cluster IP address and the service name is registered with the cluster’s DNS table. Every cluster gets such an internal DNS server called CoreDNS. As a consequence every container and Pod can resolve service names.
In the following image
App2 wants to communicate internally with
app1-svc, so it first looks up the IP in the DNS table and then uses the resolved IP to communicate:
In the YAML file you would specify type: ClusterIP or leave it out, because it is default:
apiVersion: v1 kind: Service metadata: name: nginx # becomes the internal DNS name thus service can be referenced as labels: app: nginx spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80
External communication (via NodePort)
Access from outside the cluster can be achieved like this: A service gets a network port, for example
app1-svc is available on port
31111. That port can get mapped on every cluster node and point back to the
app1-svc IP address. So when a request from outside is done to any of the nodes, the IP can be resolved and the request is forwarded to the Pods behind the service.
Here is an imperative (instead of declarative) way to achieve external access to a Pod. The following command will register the pod
hello-pod in the DNS as
hello-svc on port 8080:
kubectl expose pod hello-pod --name=hello-svc --target-port=8080 --type=NodePort
And this is how you would define it declaratively:
apiVersion: v1 kind: Service metadata: name: nginx # becomes the internal DNS name thus service can be referenced as labels: app: nginx spec: type: NodePort selector: app: nginx ports: - name: http port: 80 targetPort: 80 nodePort: 31000
Now, when you call the cluster IP from your browser with port 31111, then the underlying web server on port 8080 should be displayed.
External communication (via LoadBalancer)
Sets up a load balancer that can be reached externally
apiVersion: v1 kind: Service metadata: name: nginx # becomes the internal DNS name thus service can be referenced as labels: app: nginx spec: type: LoadBalancer selector: app: nginx ports: - name: http port: 80 targetPort: 80
Apply the service file:
kubectl apply -f service.yml.
Get a description of the service with
kubectl describe svc ps-lb.
Get a description of the endpoint (list of healthy pods) with
kubectl describe ep ps-lb.
If your Pods want to reach out to an external service whose IP or DNS name might change frequently, then it is better to let the Pods go through a custom internal service first, that will simply forward anything to the external service. By doing this you only have to adjust that internal service whenever the external service change.
In the following example we want to reach out to an external service hosted at
api.acmecorp.com by creating an internal service (that we call
external-service, a bit odd, I know) on port 9000 that will proxy everything:
apiVersion: v1 kind: Service metadata: name: external-service spec: type: ExternalName externalName: api.acmecorp.com ports: - port: 9000
Namespaces and DNS
When you create a Service, it creates a corresponding DNS entry. This entry is of the form
<service-name>.<namespace-name>.svc.cluster.local, which means that if a container just uses
<service-name>, it will resolve to the service which is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN).