A Deployment can run several copies of an application, but each Pod has its own internal IP address. A Service gives those Pods one stable access point. It can connect applications inside the cluster or expose an application to users outside it. section 3.2.5 section 1.2.1
For a typical application:
- A Deployment manages the Pods; a Service selects the Pods that receive traffic using their labels. section 3.1.2 section 3.5
- The Service balances requests across running Pods. Its address remains useful even when a Deployment has fewer available replicas or temporarily has extra ones during a rollout. section 3.2.5
- Use a ClusterIP Service for communication within the cluster, or a LoadBalancer Service to make an application available externally. section 7.1.1 section 3.2.5
Listing 3.3 Chapter03/3.2_DeployingToKubernetes/service.yaml
apiVersion: v1
kind: Service
metadata:
name: timeserver
spec:
selector: #1
pod: timeserver-pod #1
ports:
- port: 80 #2
targetPort: 80 #3
protocol: TCP #4
type: LoadBalancer #5
This Service YAML selects Pods by label and exposes port 80. The port field is the Service port; targetPort is the port receiving traffic on each Pod. Its LoadBalancer type is intended for external access. section 3.2.5
Publish and check an application
Create the Service with `kubectl create -f service.yaml`, then use `kubectl get service` to find its address. For a LoadBalancer Service with an external IP, send an HTTP request to that IP to check the application. section 3.2.5
An ordinary Service has a virtual IP, not an IP tied to one Pod or node. Kubernetes keeps the routing information current and directs a request to a Pod backing the Service. This lets an application call an internal Service without choosing a particular replica. section 7.1.1
A Service can also be the cutover point in a blue/green rollout: one Service alternates between Deployments running different application versions. The old version can remain available until the new one has been validated. section 4.2.3
