A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them.


At the end of the module, you will :

  • Learn how to expose a Pod internally

  • Learn how the domain name resolution works on a Kubernetes cluster

  • Learn how to expose a Pod externally


Create the directory data/services in your home folder to manage the YAML file needed in this module.

mkdir ~/data/services


Kubernetes Pods are mortal. They are born and when they die, they are not resurrected. ReplicaSets in particular create and destroy Pods dynamically. While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem.

A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them. The set of Pods targeted by a Service is determined by a label selector.

Kubernetes manage four kinds of services depending on the exposition needed for the Pods attached :




Only accessed within the Kubernetes cluster


Host exposition accessible from the local network


External exposition, Internet access


External endpoint definition to easily use it in the cluster

The create command can directly ask the API resource to create a Service in command line or create a Service object based on a yaml file definition.

Exercise n°1

Create an Nginx Deployement and expose the Nginx Deployemnt to be able to access it from the local network on HTTP (80) port in command line.

# Create an Nginx Pods
kubectl run nginx --image=nginx --port=80
# Expose the Nginx Pods on port 80
kubectl expose deployment nginx --port=80 --type=NodePort

Exercise n°2

Update the Nginx Pod in the namespace app-demo to be able to access it on HTTP (80) and HTTPS (443) port thanks to a YAML file.

apiVersion: v1
kind: Service
  name: nginx
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
    run: nginx
  type: NodePort

Update the service with the new yaml file definition.

kubectl apply -f ~/data/services/01_service.yaml


The get command list the object asked. It could be a single object or a list of multiple objects comma separated. This command is useful to get the status of each object. The output can be formatted to only display some information based on some json search or external tools like tr, sort, uniq.

The default output display some useful information about each services :

  • Name : the name of the newly created resource

  • Type : the type of exposition defined at service creation (see previous table).

  • Cluster-IP : the internal cluster IP of the resources

  • External-IP : the external resources IP of the resources, field configured when LoadBalancer type is used

  • Port(s) : a list of ports opened in the pods managed by the service

  • Age : the age since his creation

Exercise n°1

Get the list of existing service in the default namespace.

kubectl get service


Once an object is running, it is inevitably a need to debug problems or check the configuration deployed.

The describe command display a lot of configuration information about the Service(s) (labels, resource requirements, etc.) or any other Kubernetes objects, as well as status information about the Service(s) and Pod (state, readiness, restart count, events, etc.).

This command is really useful to introspect and debug an object deployed in a cluster.

Exercise n°1

Describe one of the existing service in the default namespace.

kubectl describe service nginx


Kubernetes come with a lot of documentation about his objects and the available options in each one. Those information can be fin easily in command line or in the official Kubernetes documentation.

The explain command allows to directly ask the API resource via the command line tools to display information about each Kubernetes objects and their architecture.

Exercise n°1

Get the documentation of a specific field of a resource.

kubectl explain service.spec

Add the --recursive flag to display all of the fields at once without descriptions.


The delete command delete resources by filenames, stdin, resources and names, or by resources and label selector.

Deleting a Service will have no effect on the Pod state. It only delete the access to each resources managed by the service.

Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource.

Exercise n°1

Delete the service and the deployment created previously in the default namespace.

# Delete the service previously created
kubectl delete service nginx

# Delete the previous deployment created
kubectl delete deployment nginx

Module exercise

The purpose of this section is to manage each steps of the lifecycle of an application to better understand each concepts of the Kubernetes course.

The main objective in this module is to understand how to expose a service depending on the security level needed.

For more information about the application used all along the course, please refer to the Exercise App > Voting App link in the left panel.

Based on the principles explain in this module, try by your own to handle this steps. The development of a yaml file is recommended.

The file developed has to be stored in this directory : ~/data/votingapp/04_services

  1. Manage the access of each part of the Voting App based on those conditions :

    1. The PostgreSQL database Deployment must only be access from the Kubernetes cluster on port 5432.

    2. The Redis queue Deployment must only be access from the Kubernetes cluster on port 6379.

    3. The vote and result Deployment must be publicly access on port 8080.

    4. The worker Pods must not be exposed.

  2. Try to access the vote web site

  3. Try to access the result web site

External documentation

Those documentations can help you to go further in this topic :

  • Kubernetes official documentation on services

Last updated