Deploying applications

In order to deploy applications with Kubernetes, we are going to need to define a set of resources called Kubernetes manifests. These manifests include specifications for pods, services, deployments, and more. Pods are the smallest deployable units in Kubernetes and contain one or more containers that run your application. In this section we are going to be focusing on deployments and services.

To deploy an application in Kubernetes, you typically create a deployment resource. A deployment specifies the desired number of replicas of your application and manages their lifecycle. Kubernetes ensures that the specified number of replicas are running at all times, and if a replica goes down, it automatically creates a new one. Here is an example of a deployment resource:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app.kubernetes.io/name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: my-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.26.2
        ports:
        - containerPort: 80

If you examine this deployment you see that it has a few interesting fields. It has the spec or specification which is our way of telling Kubernetes what we want out of our deployment such as the redundancy we want to achieve with a number of replicas (in this case only one for now) and the pod template for the nginx app.

The pod template has its own specification or spec and its main purpose is to tell Kubernetes which containers should run inside our pods. In some cases and maybe most cases pods only run a single container. In this template it is also possible to define initContainers. They are as the name might indicate containers which run when the pod initializes. This is useful for some preprocessing tasks such as database migrations.

In summary, deploying applications in Kubernetes offers scalability, resilience, and ease of management. By leveraging Kubernetes features and resources, you can ensure that your applications run smoothly in a containerized environment.

The sandbox above already has the manifest stored as nginx-deployment.yaml. Let's create a resource from it by running:

kubectl apply -f ./nginx-deployment.yaml

You should see a message saying deployment.apps/nginx-deployment created. Now verify that the deployment was created along with its pod:

kubectl get deployments

and

kubectl get pods

Note that this deployment was done in the default namespace and that is why we do not need to specify the namespace when we query. You can also inspect the deployment in detail with the describe command:

kubectl describe deployment nginx-deployment

Try running these commands in the sandbox above to explore the deployment you just created.

That's it, now you have deployed your first application to your Kubernetes cluster. But what now? It's just sitting there menacingly. We need to be able to communicate with it. We'll cover that in the next section on services.

Try clicking a pod above to see Kubernetes' self-healing in action. When a pod dies, the ReplicaSet notices and creates a replacement automatically.