Chapter 3: Deploying your first application on Kubernetes

Introduction

This chapter introduces the upcoming steps of setting up a Kubernetes cluster, using kubectl, and deploying the container created in the previous chapter.

3.1 Deploying a Kubernetes cluster

This section explains why setting up a Kubernetes cluster can be difficult and identifies simpler starting options for newcomers.

• Multi-node cluster setup challenges: Explain why setting up a full multi-node Kubernetes cluster is difficult, particularly for someone unfamiliar with Linux and network administration.
  Why it matters: This explains why a first cluster need not be a full installation built from scratch.
• Beginner cluster setup options: Describe the kinds of places Kubernetes can run and why the section recommends simpler options for a newcomer.
  Why it matters: Choosing an approachable cluster lets you begin using Kubernetes without first mastering cluster administration.

Key terms: multi-node Kubernetes cluster, physical or virtual machines (VMs), network setup, Docker Desktop, Minikube, Kubernetes in Docker (Kind), Google Kubernetes Engine, managed Kubernetes

3.1.1 Using the built-in Kubernetes cluster in Docker Desktop

This subsection shows how to enable Docker Desktop’s single-node Kubernetes cluster, where its components run, and how to explore its Linux VM.

• Docker Desktop cluster setup: Describe how to enable Kubernetes in an existing Docker Desktop installation and explain when its single-node cluster is sufficient.
  Why it matters: This gives you a quick way to get a cluster for most of the book’s exercises.
• Kubernetes components in Docker Desktop: Explain where Docker Desktop runs the node agent, control-plane components, and deployed applications, and how to list their containers.
  Why it matters: Knowing where the components run helps you make sense of what Docker Desktop shows you.
• Shell access to the VM: Describe how the special container provides a shell that effectively enters Docker Desktop’s VM, including the roles of host namespaces, elevated access, and the mounted root filesystem.
  Why it matters: This explains why a container shell can be used to inspect the VM even without a Docker Desktop login command.

Key terms: Docker Desktop, single-node Kubernetes cluster, Enable Kubernetes, Linux virtual machine, Docker Daemon, Kubelet, control plane, docker CLI, host namespaces, --privileged

3.1.2 Running a local cluster using Minikube

This section shows how to start and check a local single-node Kubernetes cluster with Minikube and describes where its components run.

• Minikube cluster options: Explain why Minikube is useful for local testing and development, and distinguish its usual VM-based setup from the option to run directly on a Linux host.
  Why it matters: The setup you choose determines whether your machine needs a hypervisor or Docker.
• Cluster startup and status: Describe how to start a Minikube cluster and what its status output confirms, including the distinction between configuring kubectl and installing it.
  Why it matters: A running cluster and a configured command-line client are separate things to check before using Kubernetes.
• Minikube component placement: Describe where the control plane components and Kubelet run in a Minikube cluster, and how to inspect the VM when one is used.
  Why it matters: Knowing what runs in containers and what runs on the operating system makes the local cluster easier to inspect.

Key terms: Minikube, single node, Linux VM, hypervisor, Docker, minikube start, minikube status, Kubelet, Kubernetes API server, kubectl

3.1.3 Running a local cluster using kind (Kubernetes in Docker)

This section explains how kind runs a local Kubernetes cluster in containers, why that helps development, and how to create and inspect its nodes.

• Kind containerized cluster architecture: Explain that kind runs each Kubernetes node in a container rather than in a virtual machine or directly on the host, and that application containers run within those node containers.
  Why it matters: This explains what kind creates when you ask it for a local cluster.
• Local development and debugging: Explain why kind is useful for development and testing: its containerized processes run on the host OS, so cluster components and applications are local and can be debugged with local tools.
  Why it matters: It connects kind's container-based setup to the practical benefit of debugging locally.
• Kind cluster creation options: Describe the setup and cluster-creation options given here: kind requires Docker, creates a single-node cluster by default, and needs a configuration file to create a cluster with multiple worker nodes. State that kind configures kubectl for the cluster it creates.
  Why it matters: These are the key choices and prerequisite for getting a usable kind cluster.
• Node and container inspection: Distinguish the tools used to inspect a kind cluster: use kind get nodes to list nodes, docker ps to see their node containers, docker exec to enter a node, and crictl ps inside it to list its running containers.
  Why it matters: Choosing the tool for the right layer lets you find both the cluster nodes and the containers running within them.

Key terms: kind, cluster node, node containers, multi-node clusters, host OS, development and testing, debug, nsenter, Docker, single-node cluster

3.1.4 Creating a managed cluster with Google Kubernetes Engine

Explains why and how to create a managed multi-node GKE cluster, where its nodes run, and what happens when its worker-node count is scaled down.

• Managed cluster advantage: Explain why a beginner might choose GKE instead of setting up a multi-node Kubernetes cluster manually.
  Why it matters: This explains why the example uses a managed cluster for a first multi-node deployment.
• GKE setup and node placement: Describe the prerequisites and location choices for creating the example GKE cluster, including how the requested node count changes when nodes are spread across zones.
  Why it matters: The location choice affects how many worker nodes a creation request produces.
• Worker nodes and control plane: Distinguish where the example cluster’s worker nodes run from where its control plane runs.
  Why it matters: It clarifies which cluster machines you can list and log into in this example.
• Scaling workers to zero: Explain what remains available, and what stops running, when the GKE cluster’s worker-node count is reduced to zero.
  Why it matters: It shows how to reduce worker-node costs without discarding cluster objects.

Key terms: managed cluster, Google Kubernetes Engine (GKE), Google Cloud SDK, gcloud, region, zone, --num-nodes, worker nodes, Google Compute Engine (GCE), control plane

3.1.5 Creating a cluster using Amazon Elastic Kubernetes Service

This section shows how to create a three-node Amazon EKS cluster with eksctl and inspect a worker node.

• EKS cluster creation: Describe using Amazon EKS as a cloud alternative to GKE, installing eksctl, and running it to create a three-node cluster in the eu-central-1 region.
  Why it matters: It gives you a way to create the cluster needed for the chapter’s application exercises.
• EKS worker node inspection: Explain how SSH access to an EKS worker node is enabled and what command the section suggests running after logging in.
  Why it matters: Inspecting a worker node lets you see the containers running there.

Key terms: Amazon Elastic Kubernetes Service (EKS), eksctl, eu-central-1, worker node, --ssh-access, SSH public key, docker ps

3.1.6 Deploying a multi-node cluster from scratch

This subsection advises readers to gain experience with easier cluster deployments before attempting a multi-node Kubernetes cluster from scratch.

• Multi-node deployment progression: Explain why most readers should postpone installing a multi-node cluster from scratch and describe the suggested path toward a fully manual deployment.
  Why it matters: Choosing a manageable first deployment lets you build experience before tackling manual cluster setup.

Key terms: multi-node cluster, kubeadm, Kubernetes the Hard Way

3.2 Interacting with Kubernetes

Introduces kubectl as the command-line way to interact with a Kubernetes cluster and explains how its requests reach the control plane.

• Kubectl and control plane interaction: Trace how using kubectl leads to changes in a Kubernetes cluster: kubectl communicates with the API server, and the control plane triggers other components to act on changes made through the API.
  Why it matters: This gives you a basic picture of what happens when you use kubectl to work with a cluster.

Key terms: kubectl, Kubernetes API server, Kubernetes Control Plane

3.2.1 Setting up kubectl, the Kubernetes command-line client

This section explains how to install kubectl and make frequent command-line use easier with an alias and tab completion.

• Kubectl installation and configuration: Explain that kubectl is an executable placed on your path and that it needs a kubeconfig file to know which cluster to contact. Distinguish checking the installation with kubectl --help from having a working cluster connection.
  Why it matters: A successful installation check does not necessarily mean kubectl can contact your cluster.
• Short kubectl alias: Describe why users commonly alias kubectl to k and where the section suggests defining that alias on Linux, macOS, and Windows.
  Why it matters: A short alias makes commands you use repeatedly quicker to type.
• Command and object completion: Explain what kubectl tab completion completes, what bash needs to enable it, and why using the k alias requires additional completion setup.
  Why it matters: Completion saves typing, but an alias needs its own completion setup to get the same benefit.

Key terms: kubectl, kubeconfig, path, kubectl --help, alias, k, ~/.bashrc, doskey, set-alias, tab completion

3.2.2 Configuring kubectl to use a specific Kubernetes cluster

This section explains where kubectl finds its cluster configuration and how to point it to a file elsewhere.

• Kubectl configuration file location: Explain that kubectl normally uses ~/.kube/config, but can be pointed to a configuration file elsewhere by setting the KUBECONFIG environment variable.
  Why it matters: This lets you use a cluster configuration even when a tool has saved it outside kubectl’s default location.

Key terms: kubeconfig, ~/.kube/config, KUBECONFIG environment variable

3.2.3 Using kubectl

Shows how to use kubectl to check cluster connectivity, list nodes, and inspect an object in detail.

• Cluster connectivity check: Explain how kubectl cluster-info helps verify that the cluster is working and kubectl can communicate with it.
  Why it matters: It gives you a first check that kubectl can reach a working cluster.
• Node listing and objects: Describe what kubectl get nodes retrieves and why its output is a summary rather than a full description.
  Why it matters: This is the basic pattern for finding Kubernetes objects before inspecting them further.
• Detailed object inspection: Explain when to use kubectl describe and what happens when the node name is omitted.
  Why it matters: It lets you move from a brief listing to information useful for inspecting a node.

Key terms: kubectl cluster-info, API server, kubectl get, nodes, objects, RESTful API, kubectl describe, resource name

3.2.4 Interacting with Kubernetes through web dashboards

This section explains what the Kubernetes web dashboard offers, how it compares with kubectl, and how to access a dashboard in different cluster environments.

• Dashboard benefits and limits: Explain how the dashboard helps users explore and modify Kubernetes resources, and why kubectl remains the primary tool.
  Why it matters: The dashboard can help you see what is deployed without replacing kubectl.
• Docker Desktop dashboard access: Describe the access sequence for the dashboard on Docker Desktop, including authentication and cleanup.
  Why it matters: On Docker Desktop, opening the dashboard requires setup and authentication rather than just visiting a page.
• Other cluster dashboard options: Distinguish dashboard access with Minikube from the web-console options described for cloud and self-hosted clusters.
  Why it matters: The way you obtain a graphical cluster view depends on where Kubernetes is running.

Key terms: dashboard, kubectl, resources, Docker Desktop, Kubernetes dashboard, kubectl proxy, authentication token, Minikube, Google Kubernetes Engine, web-based console

3.3 Running your first application on Kubernetes

Introduces two ways to deploy an application to Kubernetes and chooses the simpler imperative approach for a first deployment.

• Declarative and imperative deployment: Distinguish the usual declarative approach of applying a JSON or YAML file describing an application's components from using one-line imperative commands, and explain why the section chooses commands for a first deployment.
  Why it matters: It explains why the first deployment uses commands rather than an application description file.

Key terms: declarative approach, JSON or YAML file, imperative commands

3.3.1 Deploying your application

This section deploys a containerized application with a Deployment, introduces pods as Kubernetes’ unit for running containers, and traces how the application starts on a worker node.

• Deployment creation and desired state: Explain how the imperative kubectl create deployment command creates a Deployment for Kiada using the luksa/kiada:0.1 image, and why creating that object tells Kubernetes to run the application.
  Why it matters: Creating the object is how you tell Kubernetes what application should be running.
• Pods as container groups: Describe why Kubernetes lists pods rather than individual containers, and how containers within one pod share an environment while remaining separate from other pods.
  Why it matters: Pods explain both what you inspect in Kubernetes and how related containers can work closely together.
• Deployment and pod status: Describe how to inspect the Deployment and its pod, including why a newly created pod can be Pending and where to look when it does not run.
  Why it matters: Checking status prevents you from mistaking a created Deployment for an application that is already ready.
• Scheduling and container startup: Trace what happens after kubectl creates the Deployment, from the API server through pod scheduling and the worker node’s Kubelet to the running container. Explain what scheduling means for that pod instance.
  Why it matters: The sequence connects the object you create to the container that actually runs on a node.

Key terms: imperative, kubectl create deployment, Deployment object, desired state, container image, pod, worker node, network namespace, UTS namespace, kubectl get pods

3.3.2 Exposing your application to the world

This section shows how to expose the deployed application through a Service and reach it through an external load balancer or a node port.

• Service exposure of pods: Explain why the application's pod needs a Service for external access and what the expose deployment command creates for the kiada Deployment.
  Why it matters: Running the application in a pod does not by itself give outside users an address they can reach.
• LoadBalancer address provisioning: Explain how a LoadBalancer Service obtains an external address and how that address is used to reach the application.
  Why it matters: An external IP appears only when the cluster's infrastructure can provide the load balancer.
• Node port access: Describe how to access a LoadBalancer-type Service through its node port when no external load balancer is available.
  Why it matters: A node port offers another route to the application when the Service has no external load-balancer IP.
• Local access constraints: Describe the access alternatives and limitations noted for Minikube, Docker Desktop, and nodes behind firewall rules.
  Why it matters: The usable address depends on how and where the cluster runs.

Key terms: pod IP address, Service object, LoadBalancer, kubectl expose deployment, LoadBalancer Service, external IP, load balancer, service port, node port, PORT(S)

3.3.3 Horizontally scaling the application

The section shows how to scale a Deployment to three pods, inspect the result, and use a Service to distribute requests among them.

• Desired state for scaling: Explain that scaling a Deployment sets a desired number of pod replicas, and Kubernetes compares that target with the current state to decide what to change. State that the application itself must support horizontal scaling.
  Why it matters: This explains why changing a replica count is enough to request more running instances, while application design still matters.
• Replica and node inspection: Describe how the section verifies that scaling produced three separate, running pods with one ready container each, and how wide pod output reveals their host nodes.
  Why it matters: Checking the pod list distinguishes successful replication from merely changing the requested count.
• Node-independent pod operation: Explain why the section says an application pod generally need not care which cluster node hosts it.
  Why it matters: This is why distributing replicas across nodes need not change how the application runs or communicates.
• Service load balancing across pods: Explain how requests to the Service reach multiple pod replicas, and distinguish that distribution from a cloud infrastructure load balancer.
  Why it matters: It explains how users can reach several application replicas through the same Service URL.

Key terms: Deployment object, replicas, desired state, scaling out, reconcile, kubectl get pods, READY column, Running, -o wide, container image

3.3.4 Understanding the deployed application

This section explains the deployed application’s logical objects and why a Deployment and Service are useful for running and reaching its pods.

• Logical and physical views: Distinguish the cluster-dependent physical view from the logical view of the application, and describe the Deployment, Pods, and Service shown in the logical view.
  Why it matters: The logical view lets you reason about the application without first resolving every detail of the cluster infrastructure.
• Pods as running replicas: Describe what a Pod represents in this application and what Kubernetes does with the containers in its definition.
  Why it matters: Pods are the running units that the Deployment maintains and the Service makes reachable.
• Deployment replica maintenance: Explain how a Deployment uses its desired replica count and why it is preferable here to creating pods individually.
  Why it matters: A Deployment maintains the requested number of application copies without requiring you to manage each pod yourself.
• Stable Service entry point: Explain why clients connect to a Service rather than directly to pods, including what happens when pods are replaced or replicas are added.
  Why it matters: A Service lets clients keep using one address even as the application’s pods change.

Key terms: physical view, logical view, Kubernetes API, Deployment, Pod, Service, replica, containers, Pod object, desired number of replicas

3.4 Summary

Summarizes ways to run a Kubernetes cluster and the kubectl workflow for deploying, scaling, inspecting, and exposing an application.