Two more types. One looks outward, one looks inward.

LoadBalancer

type: LoadBalancer adds one thing to a NodePort Service: a request to the cloud provider for an external IP. A controller for the cloud creates a load balancer and writes the IP into the Service.

learner@shallows:~$ kubectl expose deployment market-web --port=80 --type=LoadBalancer
service/market-web exposed
learner@shallows:~$ kubectl get svc market-web
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
market-web   LoadBalancer   10.96.96.32    <pending>     80:32630/TCP   1s

This cluster has no cloud, so EXTERNAL-IP stays <pending> for ever. The NodePort and the ClusterIP underneath still work. On a real cloud the column fills in after a minute.

ExternalName

The other three types put a name in front of Pods. ExternalName puts a name in front of something that is not in the cluster at all:

learner@shallows:~$ kubectl create service externalname partner --external-name=api.partner.example
service/partner created
learner@shallows:~$ kubectl get svc partner
NAME      TYPE           CLUSTER-IP   EXTERNAL-IP           PORT(S)   AGE
partner   ExternalName   <none>       api.partner.example   <none>    1s

No selector, no cluster IP, no endpoints. DNS answers partner with a CNAME to api.partner.example, and the client connects there:

learner@shallows:~$ kubectl exec client -- nslookup partner
partner.default.svc.cluster.local	canonical name = api.partner.example

Use it to give an outside database or API a stable in-cluster name. Move the outside thing later, change one Service, and no client notices.