A Kubernetes Service provides stable network access to a changing set of pods. Pods may restart, move, or be replaced during deployments, while users and other applications need a dependable endpoint. The Service decouples that transient pod lifecycle from network clients and enables communication inside the cluster. section 3.3.4
Figure 3.6 The user interacts with service 1 to access the frontend application. The frontend application talks to the backend application via service 2. Services here act as an abstraction.
Use the frontend/backend topology to trace how users reach an application through one Service and how application components communicate through another. section 3.3.4
Choose the Service type according to how clients must reach the application:
- ClusterIP exposes the application only within the cluster and supports internal communication using a stable cluster IP or Service name. section 3.3.4
- NodePort exposes the application through a specified port on every node, keeping access available when pods move or nodes are added. section 3.3.4
- LoadBalancer exposes the application through a cloud provider’s external load balancer and suits production access requiring external routing. section 3.3.4
Expose a FastAPI pod with NodePort
A Service can map external node port 30420 to Service port 80 and pod target port 8083, selecting pods labeled app: fast-api. Applying the manifest with kubectl create -f node-port-service.yaml enables requests such as curl http://<node_IP>:30420. section 3.3.4
Connect to a ClusterIP service
A ClusterIP Service mapping port 80 to target port 8083 can be queried from a temporary curl pod by cluster IP or by the DNS name joker-cluster-ip-service. section 3.3.4
In ML deployments, an ingress service can expose an API Server while separate Runner pods hold models and perform inference. Independent scaling keeps request handling and model execution adjustable, and generated endpoints can support prediction testing and metrics scraping. section 6.1.3
