As mentioned previously, labels are just simple key-value pairs. They are available on pods, replication controllers, replica sets, services, and more. If you recall our service YAML, in Listing 2-3: nodejs-rc-service.yaml, there was a selector attribute. The selector attribute tells Kubernetes which labels to use in finding pods to forward traffic for that service.
K8s allows users to work with labels directly on replication controllers, replica sets, and services. Let's modify our replicas and services to include a few more labels. Once again, use your favorite editor and create these two files, as follows:
Let's take a look at how we can use labels in everyday management. The following table shows us the options to select labels:
Label selectors
Let's try looking for replicas with test deployments:
$ kubectl get rc -l deployment=test
The following screenshot is the result of the preceding command:
Replication controller listing
You'll notice that it only returns the replication controller we just started. How about services with a label named component? Use the following command:
$ kubectl get services -l component
The following screenshot is the result of the preceding command:
Listing of services with a label named component
Here, we see the core Kubernetes service only. Finally, let's just get the node-js servers we started in this chapter. See the following command:
$ kubectl get services -l "name in (node-js,node-js-labels)"
The following screenshot is the result of the preceding command:
Listing of services with a label name and a value of node-js or node-js-labels
Additionally, we can perform management tasks across a number of pods and services. For example, we can kill all replication controllers that are part of the demo deployment (if we had any running), as follows:
$ kubectl delete rc -l deployment=demo
Otherwise, kill all services that are part of a production or test deployment (again, if we had any running), as follows:
$ kubectl delete service -l "deployment in (test, production)"
It's important to note that, while label selection is quite helpful in day-to-day management tasks, it does require proper deployment hygiene on our part. We need to make sure that we have a tagging standard and that it is actively followed in the resource definition files for everything we run on Kubernetes.
While we used service definition YAML files to create our services thus far, you can actually create them using a kubectl command only. To try this out, first run the get pods command and get one of the node-js pod names. Next, use the following expose command to create a service endpoint for just that pod: $ kubectl expose pods node-js-gxkix --port=80 --name=testing-vip --create-external-load-balancer=true This will create a service named testing-vip and also a public vip (load balancer IP) that can be used to access this pod over port 80. There are number of other optional parameters that can be used. These can be found with the following command: kubectl expose --help