A Pod runs an application container, but it needs additional configuration to receive traffic. A Kubernetes Service provides an endpoint for reaching selected Pods. Use one alongside a Deployment when its Pods need to communicate with other applications or receive internet traffic. section 8.1.3 section 8.3.2
Choose a Service type based on who needs to connect:
- ClusterIP accepts traffic within the cluster, making it suitable for a database or internal API. section 8.3.2
- NodePort opens a specified port on every cluster node. It is a quick way to test external access. section 8.3.2
- LoadBalancer requests a managed cloud load balancer with a public IP address. It can route traffic across nodes and Pods, but the managed resource may cost extra. section 8.5.1
Expose an NGINX Pod
Give the Pod the label app: my-nginx, then define a NodePort Service whose selector matches that label. Set port to 5050, targetPort to the container's port 80, and nodePort to 30007. Traffic arriving at port 30007 on a node can then reach the selected Pod. section 8.3.2
For communication inside the cluster, a Service has a cluster IP, but its assigned value is unpredictable. Kubernetes DNS gives other containers a predictable name instead. For example, a PostgreSQL client Pod can connect through its database Service rather than copying an IP address into its configuration. section 8.4.3
Route traffic to a deployed application
A Python application runs as three Pods managed by a Deployment. Its LoadBalancer Service selects Pods labeled app: py-deploy and forwards public port 80 to their named http-port, configured as container port 8080. The resulting public IP can be the target of a domain's DNS A record. section 8.5.1
Listing 8.27 Service for the Python app
apiVersion: v1
kind: Service
metadata:
name: py-book
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: http-port
selector:
app: py-deploy
See the complete Python Service manifest for the LoadBalancer type, port mapping, and Pod selector. section 8.5.1
