Service object is an abstraction that provides network access to a dynamic set of
Pod replicas. Rather than access
Pods directly via their IPs, you can use a
Service to proxy requests and deal with service discovery and load balancing.
Service usually uses a selector to decide which
Pods will receive traffic. As
Pods are dynamically added and removed, the
Service will maintain a list of active
Pods that are eligible to receive traffic.
Defining a Service
Below is a sample
apiVersion: v1 kind: Service metadata: name: my-service spec: type: ClusterIP selector: app: nginx ports: - protocol: TCP port: 8080 targetPort: 80
spec.type indicates the type of
Service we want to create. In this instance we’ve specified
ClusterIP, which is the default and exposes the
Service on an IP accessible only within the cluster (hence Cluster IP). Other common service types are
NodePort – is accessible on each nodes IP, using a fixed port. This allows a Service to be accessed from outside the cluster using the nodes IP and the node port. For example, Node_IP:Node_Port.
LoadBalancer – is used by cloud providers like AWS and Azure to stand up an internet facing load balancer for your cluster.
spec.selector is used in conjunction with
Pod selectors to specify which
Service should route traffic to. This
Service routes traffic to
Pods that have a selector matching
spec.ports specifies the protocol (TCP by default) as well as the
port is the port that the
Service receives inbound traffic on, while
targetPort is the port on the
Pods that the
Service sends traffic to.
Testing the Service
To test the
Service defined above we’ll need to create some
Pod replicas – we’ll do that by creating a
Deployment. You can find the
Deployment definitions on Github.
After creating the
Service we can list it as shown above. You’ll see the
Service IP and port 8080 as specified in the manifest. Running
kubectl get endpoints my-service will list the Pods that this
Service will route traffic to. Remember these are chosen based on the selector defined in the
Service definitions. As expected, these endpoints are accessible on port 80.
To test the
Service we can exec into one of the
Pods that we created and use the
Service to call another
Pod. The screenshot below shows us running a
curl request against the
Service ClusterIP and receiving a response from nginx.
We can also access the
Service using its DNS name,
my-service as follows.
The sample code for these notes is available on Github.
Leave A Comment