Expose a Deployment Behind a Service
A 5-step recipe with Kubernetes. We can help you get access.
Recipe · 5 steps
Expose a Deployment Behind a Service
with Kubernetes
Create or reconcile the service that fronts a deployment's pods.
- Read the deployment to confirm it exists and to capture the pod template labels the service selector must match for traffic to reach any pod.
- List services carrying the app label to determine whether the deployment is already fronted, so the flow creates or reconciles accordingly.
- Replace the existing service so its type, selector, and ports match the intent. The assigned clusterIP must be carried over, as it is immutable.
- Create the service fronting the deployment's pods when none exists. The API server assigns the cluster IP unless one is specified.
- Read the service back to report the cluster IP, resolved ports, and the selector traffic is routed by.
What you'll need to have ready
- namespace: The namespace holding the deployment and the service.
- deploymentName: The deployment whose pods the service will route to.
- serviceName: Name for the service. Defaults to the app name by convention.
- appName: The app label value the service selector matches on.
- servicePort: Port the service listens on.
- targetPort: Port on the pod that traffic is forwarded to.
- serviceType: Service type — ClusterIP, NodePort, LoadBalancer, or ExternalName.
- labelSelector: Label selector used to find an existing service (e.g. app=nginx).
For your developer
Arazzo workflow kubernetes:expose-deployment, 5 operations: getNamespacedDeployment → listNamespacedServices → replaceNamespacedService → createNamespacedService → getNamespacedService. Specs on APIs.io.