Exposing Applications with Services

Introduction: Making Your Application Accessible

In the previous lesson, you successfully deployed your application, but it remains isolated within the cluster, inaccessible to the outside world. This isolation is a default security feature in Kubernetes, but it means you can't visit your web application in a browser or share it with users. To make your application reachable, you need to explicitly expose it to external traffic. This lesson teaches you how to solve this problem using a Kubernetes Service . A Service is a resource that provides a stable network endpoint for your application's pods. You will focus on the LoadBalancer Service type, which is the standard way to expose applications publicly on cloud platforms like AWS. By the end of this lesson, you will have created a Service that provisions an AWS load balancer, giving your application a public hostname that anyone on the internet can use to access it.

The Problem That Services Solve

Before diving into how Services work, you need to understand the fundamental problem they solve. When you created your deployment, Kubernetes created pods, and each pod received its own internal IP address. Relying on these pod IP addresses to access your application is impractical for several critical reasons. These challenges make direct pod access unsuitable for any real-world application. Let's break down the specific problems: Pods are ephemeral. Pods are designed to be temporary and replaceable. They are destroyed and recreated with new IP addresses during scaling events, updates, restarts, or node failures. Any system trying to connect directly to a pod IP would constantly break. Pod IPs are not externally routable. Pod IP addresses exist on an internal, private network within the cluster. They cannot be reached from outside the cluster, such as from your local machine or by your users' browsers. Managing multiple pods is complex. A deployment with multiple replicas has multiple pods, each with a different IP address. You would need to implement your own client-side load balancing to distribute traffic among them, which is complex and brittle. Services solve all three of these problems by providing a stable abstraction layer in front of your pods. A Service gets its own stable IP address and automatically discovers and load-balances traffic to the correct pods using label selectors, ensuring reliable access regardless of how often your pods change.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Writing Your Service Manifest

Now you're ready to write the manifest that will expose your application. Like a Deployment manifest, a Service manifest is a YAML file that describes the desired state of the resource. It contains standard fields like apiVersion, kind, and metadata, along with a spec section for Service-specific configuration.

Create a file called service.yaml with the following content:

YAML

apiVersion: v1
kind: Service
metadata:
  name: my-web-svc
  namespace: apps
spec:
  type: LoadBalancer
  selector:
    app: my-web
  ports:
    - name: http
      port: 80
      targetPort: 80

apiVersion: v1
kind: Service
metadata:
  name: my-web-svc
  namespace: apps
spec:
  type: LoadBalancer
  selector:
    app: my-web
  ports:
    - name: http
      port: 80
      targetPort: 80

This manifest defines all the necessary components to expose your application. Let's examine the key fields:

apiVersion and kind: These fields declare that you are creating a Service resource using the core v1 API group of Kubernetes.
metadata: Here, you specify the Service's name as my-web-svc and place it in the apps namespace, ensuring it can find the deployment in the same namespace.
spec.type: Setting this to LoadBalancer is the critical instruction that tells Kubernetes to provision an external load balancer via the cloud provider (AWS in this case).
spec.selector: This tells the Service which pods to send traffic to. It selects all pods that have the label app: my-web, which matches the label you defined in your Deployment's pod template.
spec.ports: This section defines the port mapping. It specifies that the Service should accept traffic on port: 80 (the standard HTTP port) and forward it to targetPort: 80 on the selected pods, which is the port nginx is listening on.

The use of a label selector is what makes the Service so powerful. It decouples the Service from the individual pods, allowing the Service to automatically track the healthy pods of your deployment even as they are created, destroyed, or replaced.

Deploying and Testing Your Service

With your Service manifest written, you're ready to deploy it to your cluster and test that it works. The process is similar to deploying your Deployment manifest, using kubectl apply to create the resource. However, testing a Service requires a few additional steps because you need to wait for AWS to provision the load balancer and then extract the public hostname before you can access your application.

Start by applying the Service manifest to your cluster:

Shell

kubectl apply -f service.yaml

kubectl apply -f service.yaml

Kubernetes receives the manifest, validates it, and creates the Service resource. The output confirms that the Service was created:

text

service/my-web-svc created

service/my-web-svc created

At this point, the Service exists in Kubernetes, but the AWS load balancer hasn't been provisioned yet. If you immediately check the Service status with kubectl get svc, you'll see that the external IP field shows <pending>:

Shell

kubectl get svc my-web-svc -n apps

kubectl get svc my-web-svc -n apps

The output shows the Service but without an external endpoint yet:

text

NAME          TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
my-web-svc    LoadBalancer   10.100.200.50   <pending>     80:31234/TCP   10s

NAME          TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
my-web-svc    LoadBalancer   10.100.200.50   <pending>     80:31234/TCP   10s

The CLUSTER-IP field shows the internal IP address that was assigned to the Service. Other pods in the cluster can use this IP to access your application, but you can't use it from outside the cluster. The EXTERNAL-IP field shows <pending>, indicating that AWS is still provisioning the load balancer. The PORT(S) field shows 80:31234/TCP, which means the Service listens on port 80 and has been assigned NodePort 31234 on each cluster node. The NodePort is assigned automatically from the available range.

Rather than repeatedly running kubectl get svc to check whether the load balancer is ready, you can use the -w flag to watch for changes in real time:

Shell

kubectl get svc my-web-svc -n apps -w

kubectl get svc my-web-svc -n apps -w

This command displays the current Service status and then continues running, showing updates as they happen. You'll see the same <pending> status initially, and then after a few minutes, the output will update to show the external hostname:

text

NAME          TYPE           CLUSTER-IP      EXTERNAL-IP                                                              PORT(S)        AGE
my-web-svc    LoadBalancer   10.100.200.50   <pending>                                                                80:31234/TCP   10s
my-web-svc    LoadBalancer   10.100.200.50   a1b2c3d4e5f6g7h8-1234567890.us-east-1.elb.amazonaws.com                80:31234/TCP   2m15s

NAME          TYPE           CLUSTER-IP      EXTERNAL-IP                                                              PORT(S)        AGE
my-web-svc    LoadBalancer   10.100.200.50   <pending>                                                                80:31234/TCP   10s
my-web-svc    LoadBalancer   10.100.200.50   a1b2c3d4e5f6g7h8-1234567890.us-east-1.elb.amazonaws.com                80:31234/TCP   2m15s

When you see the hostname appear in the EXTERNAL-IP field, you can press Ctrl+C to stop watching and proceed to test your application. The hostname is the public DNS name of the AWS load balancer that was created for your Service. This hostname is what you'll use to access your application from anywhere on the internet.

To make testing easier, you can extract the hostname programmatically and store it in an environment variable. This is useful because the hostname is long and difficult to type manually:

Shell

EXTERNAL=$(kubectl get svc my-web-svc -n apps -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo "Service endpoint: http://$EXTERNAL/"

EXTERNAL=$(kubectl get svc my-web-svc -n apps -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo "Service endpoint: http://$EXTERNAL/"

This command uses JSONPath to extract just the hostname from the Service status and stores it in the EXTERNAL variable. The echo command then displays the full URL you can use to access your application:

Service endpoint: http://a1b2c3d4e5f6g7h8-1234567890.us-east-1.elb.amazonaws.com/

Service endpoint: http://a1b2c3d4e5f6g7h8-1234567890.us-east-1.elb.amazonaws.com/

Now you can test that your application is accessible by making an HTTP request to this URL. The curl command with the -I flag makes a HEAD request that retrieves just the HTTP headers without downloading the full response body:

Shell

curl -I "http://$EXTERNAL/"

curl -I "http://$EXTERNAL/"

If everything is working correctly, you'll see HTTP headers indicating a successful response:

text

HTTP/1.1 200 OK
Date: Thu, 15 Jan 2026 16:45:30 GMT
Server: Werkzeug/2.3.0 Python/3.11.0
Content-Type: text/html; charset=utf-8
Content-Length: 615
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 15 Jan 2026 16:45:30 GMT
Server: Werkzeug/2.3.0 Python/3.11.0
Content-Type: text/html; charset=utf-8
Content-Length: 615
Connection: keep-alive

The HTTP/1.1 200 OK status line indicates that your application responded successfully. The other headers show information about the server and response. You can also open this URL in a web browser to see your application's actual output, or you can use curl without the -I flag to see the full response body. The important thing is that you're now accessing your application from outside the cluster using a public endpoint, which means anyone with this URL can access your application.

If you want to clean up the resources you created in this lesson, you can delete the Service and Deployment. Deleting the Service is important because it triggers Kubernetes to delete the AWS load balancer, preventing ongoing charges for the load balancer resource:

Shell

kubectl delete svc my-web-svc -n apps
kubectl delete deploy my-web-deploy -n apps

kubectl delete svc my-web-svc -n apps
kubectl delete deploy my-web-deploy -n apps

These commands remove the Service and Deployment from your cluster. When you delete the Service, Kubernetes tells AWS to delete the load balancer, which takes a minute or two to complete. The Deployment deletion removes the pods that were running your application. If you want to keep your cluster running for future lessons but don't want to pay for the load balancer, make sure to delete the Service. You can always recreate it later by applying the same manifest file.

Introduction: Making Your Application Accessible

The Problem That Services Solve

Join the 1M+ learners on CodeSignal

Understanding Service Types in Kubernetes

How LoadBalancer Services Work on AWS

Understanding the AWS Provisioning Process

Accessing and Managing Your Load Balancer

Writing Your Service Manifest

Deploying and Testing Your Service

Summary and Next Steps