Deploying Your First Application

Introduction: From Cluster to Running Application

You've successfully created an EKS cluster, but it's currently empty. This lesson will guide you through deploying your first containerized application. You'll learn to write a Deployment manifest, a YAML file that declaratively tells Kubernetes how to run your application. This manifest specifies the container image, the number of copies to run, resource allocation, and health checks. In Kubernetes, you don't run containers manually. Instead, you declare your desired state in a manifest, and Kubernetes works to maintain that state. If a container crashes, Kubernetes automatically restarts it. This declarative approach is what makes Kubernetes powerful and reliable for production applications. By the end of this lesson, you'll have a web application running on your EKS cluster, and you'll understand the fundamental workflow for deploying any containerized application.

Understanding Kubernetes Deployments

Join the 1M+ learners on CodeSignal

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

Anatomy of a Deployment Manifest

Let's look at the structure of a Deployment manifest and understand each section. Here's the complete manifest you'll use to deploy your web application:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-deploy
  namespace: apps
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web
  template:
    metadata:
      labels:
        app: my-web
    spec:
      containers:
        - name: web
          image: "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.0"
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          env:
            - name: APP_NAME
              value: "my-web-app"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 20
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-deploy
  namespace: apps
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-web
  template:
    metadata:
      labels:
        app: my-web
    spec:
      containers:
        - name: web
          image: "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.0"
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          env:
            - name: APP_NAME
              value: "my-web-app"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 20
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Every Kubernetes manifest is composed of several key fields that define the resource. Let's break down the main sections of this Deployment manifest.

apiVersion and kind: These required fields tell Kubernetes which API to use (apps/v1) and what type of resource is being defined (Deployment).
metadata: This section contains information about the Deployment itself, such as its name (my-web-deploy) and the namespace (apps) where it will be created. Namespaces help organize resources within a cluster.
spec: This is the most important section, as it defines the desired state of the Deployment.
replicas: Inside the spec, this field specifies how many identical Pods to run. Here, we're asking for 1.
selector: This tells the Deployment how to find the Pods it manages. It must match the labels defined in the Pod template.
template: This section defines the Pod that the Deployment will create. It has its own metadata (with labels that match the selector) and spec (which defines the containers).

Together, these fields form a complete declaration of your application's desired state. The selector and the template's labels are particularly important, as they create the link that allows the Deployment to manage its Pods. If these labels don't match, the Deployment controller won't know which Pods belong to it, and your application won't run as expected.

Configuring Your Container

The template.spec section defines the containers that will run in each Pod. Here you specify everything from the container image to its resource requirements and health checks. Let's examine the key fields for configuring your container.

image: This is the most critical field, specifying the container image to pull from a registry. In this example, we use an Amazon ECR URI: 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.0. This is the standard pattern for EKS deployments, where your account ID is 123456789012, your region is us-east-1, your repository is my-web-app, and your image tag is 1.0.0. ECR is the natural choice for EKS because it integrates seamlessly with AWS IAM for authentication and provides fast, private image storage within your AWS account. For the practice exercises using kind, you'll substitute this with nginx:alpine since kind doesn't have access to your ECR repositories.
imagePullPolicy: Set to Always, this forces Kubernetes to pull the image every time a Pod is created. This is useful in development to ensure you're always running the latest code.
ports: This declares that the container listens on a specific port (containerPort: 80). While this is informational and doesn't open the port on the network, it's a best practice and is used by other Kubernetes objects like Services.
env: This allows you to set environment variables inside the container. Environment variables are commonly used to pass configuration to containers, such as logging levels, feature flags, database connection strings, or application metadata like APP_NAME: "my-web-app". This is a standard way to pass configuration to applications without rebuilding container images.

These configuration options provide a powerful way to define how your application runs. By externalizing configuration through environment variables and clearly declaring ports, you create a portable and well-documented application that is easy for both Kubernetes and other developers to understand.

Deploying to Your Cluster

Now that you understand the Deployment manifest, let's deploy it to your cluster. Before you can apply the Deployment, you need to create the apps namespace because the Deployment specifies namespace: apps in its metadata. Creating a namespace is straightforward:

Shell

kubectl create namespace apps

kubectl create namespace apps

When you run this command, you'll see output confirming the namespace was created:

text

namespace/apps created

namespace/apps created

Namespaces in Kubernetes provide a way to organize and isolate resources. By creating a dedicated namespace for your applications, you're separating them from system components that run in the kube-system namespace. This makes it easier to manage permissions, apply policies, and view resources. You only need to create the namespace once — it will continue to exist until you explicitly delete it.

Now you can apply your Deployment manifest. Save the manifest shown earlier to a file named deployment.yaml. For the kind practice environment, replace the ECR image URI with nginx:alpine since kind doesn't have access to ECR. In a production EKS cluster, you would keep the ECR URI. Then run:

Shell

kubectl apply -f deployment.yaml

kubectl apply -f deployment.yaml

The -f flag tells kubectl to read the manifest from a file. When you run this command, you'll see output indicating that the Deployment was created:

text

deployment.apps/my-web-deploy created

deployment.apps/my-web-deploy created

The apply command is idempotent, which means you can run it multiple times safely. If the Deployment doesn't exist, kubectl creates it. If it already exists, kubectl updates it to match your manifest. This makes apply the preferred command for managing Kubernetes resources because you can use the same command whether you're creating or updating.

When you apply the Deployment, several things happen behind the scenes. First, Kubernetes creates the Deployment resource in the apps namespace. Then, the Deployment controller sees the new Deployment and creates a ReplicaSet, which is an intermediate resource that manages the Pods. The ReplicaSet then creates the Pod based on the template you provided. The Pod is scheduled to one of your worker nodes, and the kubelet on that node pulls the container image and starts the container. The readiness probe begins checking if the container is ready, and once it succeeds, the Pod is marked as ready.

You can check the status of your Deployment with this command:

Shell

kubectl get deployments -n apps

kubectl get deployments -n apps

The -n apps flag tells kubectl to look in the apps namespace. You should see output like this:

text

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
my-web-deploy    1/1     1            1           30s

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
my-web-deploy    1/1     1            1           30s

This output shows that your Deployment has 1 out of 1 replicas ready, which means your Pod is running and passed its readiness probe. The UP-TO-DATE column shows how many Pods are running the latest version of your template, and the AVAILABLE column shows how many Pods are ready to accept traffic.

You can also check the Pods directly:

Shell

kubectl get pods -n apps

kubectl get pods -n apps

You should see output showing your Pod:

text

NAME                              READY   STATUS    RESTARTS   AGE
my-web-deploy-7d4f8b9c5d-x7k2m    1/1     Running   0          45s

NAME                              READY   STATUS    RESTARTS   AGE
my-web-deploy-7d4f8b9c5d-x7k2m    1/1     Running   0          45s

The Pod name is generated automatically by combining the Deployment name, the ReplicaSet hash, and a random suffix. The READY column shows that 1 out of 1 containers in the Pod are ready. The STATUS column shows that the Pod is running. The RESTARTS column shows how many times the container has been restarted, which should be 0 for a healthy Pod.

If you want to see more details about your Pod, you can use the describe command:

Shell

kubectl describe pod my-web-deploy-7d4f8b9c5d-x7k2m -n apps

kubectl describe pod my-web-deploy-7d4f8b9c5d-x7k2m -n apps

This command shows detailed information about the Pod, including its events, which tell you what happened during the Pod's lifecycle. You'll see events like "Scheduled," "Pulling," "Pulled," and "Started," which show the progression from scheduling to running. If there were any problems, such as image pull errors or probe failures, they would appear in the events section.

Introduction: From Cluster to Running Application

Understanding Kubernetes Deployments

Join the 1M+ learners on CodeSignal

Anatomy of a Deployment Manifest

Configuring Your Container

Managing Resources and Limits

Adding Health Checks

Deploying to Your Cluster

About the Practice Environment

Summary: Your First Deployed Application