The Kubernetes Service has four types: ClusterIP, NodePort, LoadBalancer, and ExternalName. In the How to do it... section in this recipe, we only demonstrate the default type, ClusterIP. The type ClusterIP indicates that the Kubernetes Service is assigned a unique virtual IP in the overlay network, which also means the identity in this Kubernetes cluster. ClusterIP guarantees that the Service is accessible internally.
The following diagram expresses the availability coverage of the types, and their entry points:
For the NodePort type, it covers the ClusterIP's features, has a peer-accessible virtual IP, and also allows the user to expose Services on each node with the same port. The type LoadBalancer is on the top of the other two types. The LoadBalancer Service would be exposed internally and on the node. More than that, if your cloud provider supports external load balancing servers, you can bind the load balancer IP to the Service, and this will become another exposing point. On the other hand, the type ExternalName is used for the endpoint out of your Kubernetes system. It is similar to the Endpoint we created with the configuration file in a previous section; moreover, a single ExternalName Service can provide this feature.
We can use the subcommand create to create Services in different types:
// create a NodePort Service
// the tag "tcp" is for indicating port configuration: SERVICE_PORT:TARGET_PORT
$ kubectl create service nodeport my-nginx --tcp=8080:80
service "my-nginx" created
$ kubectl describe svc my-nginx
Name: my-nginx
Namespace: default
Labels: app=my-nginx
Annotations: <none>
Selector: app=my-nginx
Type: NodePort
IP: 10.105.106.134
Port: 8080-80 8080/TCP
TargetPort: 80/TCP
NodePort: 8080-80 31336/TCP
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
In this example of the NodePort Service, you can see that it still has the virtual IP (10.105.106.134) in the cluster, and can be accessed through port 31336 of any Kubernetes node:
// run an nginx Deployment with the label as NodePort Service my-nginx's selector
$ kubectl run test-nodeport --image=nginx --labels="app=my-nginx"
deployment.apps "test-nodeport" created
// check the Kubernetes node with Service port on the node
$ curl ubuntu02:31336
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
In the case here, we demonstrate creating an ExternalName Service which exposes the CNAME kubernetes.io:
$ kubectl create service externalname k8s-website --external-name kubernetes.io
service "k8s-website" created
// create a CentOS Pod for testing the Service availability
$ kubectl run my-centos --image=centos --restart=Never sleep 600
pod "my-centos" created
//now you can check the Service by Service's DNS name
$ kubectl exec -it my-centos -- /bin/sh -c 'curl k8s-website.default.svc.cluster.local '
//Check all the Services we created in this section
//ExternalName Service has no cluster IP as defined
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
k8s-website ExternalName <none> kubernetes.io <none> 31m
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
my-nginx NodePort 10.105.106.134 <none> 8080:31336/TCP 1h
Yet, we cannot build an ExternalName Service in CLI with the subcommand expose, because expose works on exposing the Kubernetes resources, while the ExternalName Service is for the resources in the outside world. Then, it is also reasonable that the ExternalName Service doesn't need to be defined with the selector.
While using the subcommand create on Service creation, the command line would look like this: kubectl create service <SERVICE TYPE> <SERVICE NAME> [OPTIONS]. And we can put the Service types at <SERVICE TYPE>, such as clusterip, nodeport, loadbalancer, and externalname. With this method, we cannot specify the selector of the Service. As with the NodePort Service we created in that section, only a default selector, app: my-nginx, is created, and we have to assign this label to a later created Deployment test-nodeport. Except for the type ExternalName, Service types can be created with the subcommand expose with the tag type. Try to create the NodePort service with kubectl expose for existing resources!