A Kubernetes Service gives applications a stable name for reaching Pods. Pod IP addresses are ephemeral and can change when Pods are replaced, so clients should target the Service name instead. The Service uses endpoints to direct traffic to the Pods running the application. section 3.2.6
Services are namespaced. Their DNS names include both the Service and namespace: services named `myweb1` and `myweb2` in `sales` can be reached as `myweb1.sales.svc.cluster.local` and `myweb2.sales.svc.cluster.local`. section 3.2.6
Table 3.5 Services in Kubernetes (view table figure)
Compare Service types by network scope: ClusterIP is internal, NodePort also accepts connections through a worker node’s address, and LoadBalancer uses an external load balancer. An Ingress rule can expose a ClusterIP Service externally. section 3.2.6
Preview a Service in minikube
Start minikube, create the example Deployment, and expose it as a NodePort Service: `minikube start` `kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.4` `kubectl expose deployment hello-minikube --type=NodePort --port=8080` Check it with `kubectl get services hello-minikube`. Then run `kubectl port-forward service/hello-minikube 8080:8080` and open `http://localhost:8080`. section 12.3.1
During VM migration, preserving hostnames as Service names can keep naming consistent. If a VM runs multiple applications, consider a separate Service for each. For applications that depend on an external backend, consider an ExternalName Service without a selector. Place codependent Pods in a namespace when useful, and use NetworkPolicy to restrict access between them. section 15.5
