8 Managed Kubernetes deployment

This chapter moves from container fundamentals to running real workloads on Kubernetes, with a clear emphasis on using a managed service to simplify operations. It frames Kubernetes as a portable, declarative platform for orchestrating containers across a cluster and argues for managed Kubernetes over self-managed clusters due to speed, simplicity, a maintained control plane, built‑in public IPs, storage integration, and easy Infrastructure‑as‑Code. Everything revolves around manifests (YAML) that describe the desired state, making applications and their infrastructure highly reproducible and portable, while noting that cloud‑specific pieces like load balancers and volumes require extra care during migrations.

Readers provision a managed cluster (using Linode Kubernetes Engine as the example), install and configure kubectl with a kubeconfig, and learn the core resource model: clusters, nodes, pods, deployments, services, namespaces, ConfigMaps, Secrets, volumes, and StatefulSets. The chapter builds up from first principles—running a single pod, labeling it, and exposing it with services (NodePort, LoadBalancer, and ClusterIP)—to practical scaling with deployments and rolling updates. It demonstrates configuration without image rebuilds using ConfigMaps and Secrets (including env and volume mounts), shows internal service discovery via Kubernetes DNS, and uses namespaces to isolate teams and environments. Along the way, it reinforces label/selector patterns, troubleshooting with kubectl, and safe approaches to handling credentials.

Stateful needs are addressed through persistent volumes and claims, plus StatefulSets that provide ordered, named pods and per‑replica storage—illustrated by deploying PostgreSQL and connecting to it from a throwaway pod using port forwarding and in‑cluster DNS; Redis receives a similar treatment in its own namespace. The chapter culminates in “production‑style” deployments of the book’s Python and Node.js apps behind LoadBalancer services on port 80, suitable for pointing custom domains via DNS. Finally, it automates updates with a GitHub Actions workflow that authenticates via kubeconfig, applies manifests, and triggers rollout restarts, while recommending immutable image tags for reliable rollbacks and auditability. The result is a practical, end‑to‑end path from cluster provisioning to repeatable, automated application delivery on managed Kubernetes.

Preprovisioned Kubernetes cluster options

Linode Kubernetes Engine provisioning cluster

Kubernetes concepts

Kubernetes dashboard

Kubernetes dashboard nodes

kubectl version

kubectl get nodes

kubectl get pods

kubectl get service

kubectl get deployment

ConfigMap-based NGINX container output

kubectl get secret output.

kubectl get service output

Cross-service communication between services and psql

kubectl get pods and services output

• Kubeconfig files are used to connect to a Kubernetes cluster with the Kubernetes CLI, kubectl.
• The KUBECONFIG environment variable can be used to set the location of the kubeconfig file for use with kubectl.
• Service accounts contain permission to access various resources within a cluster. The default service account is unlimited in what it can do and access in the Kubeconfig file.
• Pods are the smallest Kubernetes resource and can be defined and provisioned for fast and efficient container deployment.
• Deployments are used to manage and scale stateless pods across a cluster of Kubernetes nodes.
• StatefulSets are used to manage a scale stateful pods and include built-in support for scaling and attaching volumes with scaled pods.
• Deployments and StatefulSets are designed to ensure a specific number of pods are running based on the replica count, and if a pod is deleted, failing, or otherwise not running, a new pod will be provisioned to meet the replica count.
• Updating or changing a container image within a deployment or StatefulSet will trigger a pod rollout, which is a no-downtime replacement of pods.
• ConfigMaps are reusable resources that store static key-value stores that can be attached to other resources like pods, deployments, and StatefulSets as environment variables values and read-only volumes.
• Secrets are exactly like ConfigMaps but obscure the value data from the key-value pairs using Base64 encoding. Secrets are designed to be readable when attached to pods, deployments, and StatefulSets as environment variable values and read-only volumes.
• Using third-party services such as HashiCorp Vault, AWS Secrets Manager, or Google Secrets Manager is a good alternative to Kubernetes secrets to obstruct values beyond Base64 encoding.
• Selectors can be used to filter pods and other resources by key-value pairs.
• Namespaces can be used to group resources together and can be used to filter resources.
• Services manage internal and external communication to pods, deployments, and StatefulSets.
• ClusterIP-type service resources only allow internal traffic and are not accessible from outside the cluster.
• NodePort service resources expose a port on each node to route external traffic to pods.
• The LoadBalancer service resource uses a cloud-managed load balancer service to route external traffic to Kubernetes nodes and pods.
• The service types of ClusterIP, NodePort, and LoadBalancer can direct and load balance internal traffic through an internal DNS endpoint or dynamically provisioned IP address called a Cluster IP.
• Container-to-container communication is possible through the use of service resources.
• A records, or address records, are used to configure a custom domain to a static IP address.
• GitHub Actions can automate and provision Kubernetes resources with manifest files by using a valid kubeconfig file with a service account with the correct permissions and kubectl.

FAQ