A Kubernetes Service gives clients an endpoint for reaching Pods. Its selector finds the backend Pods, while its port configuration routes traffic to the application port. Clients may be inside the cluster or outside it; the Service type determines how they connect. section 8.2.6
Choose the Service type by who needs access:
- ClusterIP exposes an endpoint inside Kubernetes, suitable for a service such as Shipping that only other cluster workloads call. section 8.2.6
- LoadBalancer exposes a Service externally through a cloud-provider load balancer. On AWS, Kubernetes can provision the load balancer without requiring you to manage its provider-specific setup. section 8.2.6
- NodePort exposes a specified port on a worker node. Clients need the public IP of at least one worker node and connect to that IP and port. section 8.2.6
apiVersion: v1
kind: Service
metadata:
name: payment
labels:
app: payment
spec:
selector:
app: payment #1
ports:
- name: grpc #2
port: 80 #3
protocol: TCP #4
targetPort: 8081 #5
type: LoadBalancer #6
This Payment Service selects Pods labeled app: payment. It exposes TCP port 80 and forwards traffic to port 8081 on those Pods; type: LoadBalancer requests external exposure. section 8.2.6
For path-based routing, Ingress can map a request path to a Service. A Service also provides a stable routing point during a canary deployment: keep one Service, add a deployment whose Pods match its selector, then gradually shift the replica mix from the old version to the new one. section 8.2.3 section 8.4.3
