Kubernetes Pods covered by Service require labels, so that Service can recognize who is the one it should take charge of. In the following commands, we create a Pod with labels first, and attach a Service on it:

// using subcommand "run" with "never" restart policy, and without replica, you can get a Pod
// here we create a nginx container with port 80 exposed to outside world of Pod
$ kubectl run nginx-pod --image=nginx --port=80 --restart="Never" --labels="project=My-Happy-Web,role=frontend,env=test"
pod "nginx-pod" created

// expose Pod "nginx-pod" with a Service officially with port 8080, target port would be the exposed port of pod
$ kubectl expose pod nginx-pod --port=8080 --target-port=80 --name="nginx-service"
service "nginx-service" exposed

You may find that, based on the preceding command, we did not assign any selector to this Service. Nonetheless, since Service nginx-service takes the port forwarding task of Pod nginx-pod, it will take the labels of the Pod as its selector. Go ahead and check the details of the Service with the subcommand describe:

// "svc" is the abbreviate of Service, for the description's resource type
$ kubectl describe svc nginx-service
Name:              nginx-service
Namespace:         default
Labels:            env=test
                   project=My-Happy-Web
                   role=frontend
Annotations:       <none>
Selector:          env=test,project=My-Happy-Web,role=frontend
Type:              ClusterIP
IP:                10.96.107.213
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         192.168.79.24:80
Session Affinity:  None
Events:            <none>

Now you can see that, for guaranteeing the responsibility, this successfully exposed Service just copied the labels of the Pod as its selector. The value list after Endpoints was the IP of the Pod and its exposed port 80. Furthermore, the Service took the Pod's labels as its own. According to this example, the Pod can be accessed through Service by surfing 10.96.107.213:8080.

Except for the selector of Service, some parameters can be automatically configured if they are bypassed by users. One parameter is the labels of the Pod; another is the name of the Service; and the other is the exposed port of the Service. Let's take a look at how this simple set of Pod and Service can be managed:

// create a Pod and a Service for it
$ kubectl run nginx-no-label --image=nginx --port=80 --restart="Never" && kubectl expose pod nginx-no-label
pod "nginx-no-label" created
service "nginx-no-label" exposed
// take a lookat the configurations of the Service
$ kubectl describe svc nginx-no-label
Name:              nginx-no-label
Namespace:         default
Labels:            run=nginx-no-label
Annotations:       <none>
Selector:          run=nginx-no-label
Type:              ClusterIP
IP:                10.105.96.243
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         192.168.79.10:80
Session Affinity:  None
Events:            <none>

Here, we can see that the Service inherited the name, label, and port from the Pod. The selector was assigned the dummy label with the key named run and the value named as Pod's name, which is just the same dummy one of Pod nginx-no-label. Users should access the Service through port 80, as well. For such simple settings, you can alternatively try the following command to create the Pods and Service at the same time:

// through leveraging tag "--expose", create the Service along with Pod
$ kubectl run another-nginx-no-label --image=nginx --port=80 --restart="Never" --expose
service "another-nginx-no-label" created
pod "another-nginx-no-label" created