Internal services

Let's explore the other types of services that we can deploy. First, by default, services are only internally facing. You can specify a type of clusterIP to achieve this, but, if no type is defined, clusterIP is the assumed type. Let's take a look at an example, nodejs-service-internal.yaml; note the lack of the type element:

apiVersion: v1 
kind: Service 
metadata: 
  name: node-js-internal 
  labels: 
    name: node-js-internal 
spec: 
  ports: 
  - port: 80 
  selector: 
    name: node-js 

Use this listing to create the service definition file. You'll need a healthy version of the node-js RC (Listing nodejs-health-controller-2.yaml). As you can see, the selector matches on the pods named node-js that our RC launched in the previous chapter. We will create the service and then list the currently running services with a filter as follows:

$ kubectl create -f nodejs-service-internal.yaml
$ kubectl get services -l name=node-js-internal

The following screenshot is the result of the preceding command:

As you can see, we have a new service, but only one IP. Furthermore, the IP address is not externally accessible. We won't be able to test the service from a web browser this time. However, we can use the handy kubectl exec command and attempt to connect from one of the other pods. You will need node-js-pod (nodejs-pod.yaml) running. Then, you can execute the following command:

$ kubectl exec node-js-pod -- curl <node-js-internal IP>

This allows us to run a docker exec command as if we had a shell in the node-js-pod container. It then hits the internal service URL, which forwards to any pods with the node-js label.

If all is well, you should get the raw HTML output back. You have successfully created an internal-only service. This can be useful for backend services that you want to make available to other containers running in your cluster, but not open to the world at large.