Kubernetes (often abbreviated as K8s) has become the de‑facto standard for orchestrating containerized applications. Modern web services need to be available around the clock, and developers expect to push new versions without downtime. Containerization makes that possible, and Kubernetes helps make sure those containers run where and when they should and have the resources they need. This tutorial walks through the key concepts of Kubernetes, shows how to deploy a simple application on Amazon EKS, and demonstrates how to scale both your application and the underlying infrastructure.<h3>1&nbsp;Understanding Kubernetes</h3><h4>1.1&nbsp;Cluster architecture</h4>A Kubernetes cluster consists of a control plane and a set of worker nodes that run containerized applications. The control plane hosts components such as the API server, scheduler, controller managers and etcd, which make global decisions for the cluster (for example, scheduling pods). Worker nodes run the pods—the smallest deployable units—that contain one or more containers. This separation lets you add or remove worker nodes without affecting the control plane, enabling high availability and fault tolerance.Key components include:<ul><li>kube‑apiserver – exposes the Kubernetes API. It scales horizontally by running multiple instances behind a load balancer.</li><li>etcd – the consistent, highly‑available key–value store for all cluster data.</li><li>kube‑scheduler – assigns newly created pods to nodes based on resource requirements, policy constraints and scheduling algorithms.</li><li>kube‑controller‑manager and cloud‑controller‑manager – run various controllers that handle tasks such as node lifecycles, jobs, endpoints and cloud provider interactions.</li><li>kubelet – an agent running on each worker node that ensures containers described in pod specifications are running and healthy.</li><li>kube‑proxy – a network proxy on each node that implements the Service abstraction and load‑balances traffic to pods.</li></ul><h4>1.2&nbsp;Workloads, pods and deployments</h4>A Deployment manages a set of pods for stateless applications. You describe your desired state (for example, the number of replicas and the container image) in a deployment object, and Kubernetes ensures that reality matches your declaration. Behind the scenes, deployments create and manage ReplicaSets, which in turn manage the individual pods. Deployments enable declarative updates and rollbacks and provide a simple way to scale up or down your application.The typical workflow for a deployment is:<ol><li>Define a deployment manifest specifying the container image, number of replicas and labels.</li><li>Apply the manifest with <code>kubectl apply -f &lt;file&gt;</code>.</li><li>Kubernetes creates a ReplicaSet and schedules pods on nodes.</li><li>You can scale or update the deployment declaratively (see section&nbsp;5).</li></ol><h4>1.3&nbsp;Services and load‑balancing</h4>Pods are mortal; they can be destroyed and recreated at any time. Services provide a stable network endpoint to access pods, load‑balancing traffic across all healthy instances. When you expose a deployment via a Service of type LoadBalancer, Kubernetes configures an external load balancer (on AWS this becomes an Elastic Load Balancer) and routes incoming traffic to your pods. This mechanism is essential when running multiple instances of an application.<h3>2&nbsp;Why Use Amazon EKS?</h3>Operating your own Kubernetes control plane on cloud virtual machines is certainly possible, but it requires ongoing maintenance, upgrades and high‑availability planning. Amazon Elastic Kubernetes Service (EKS) provides a managed control plane that takes care of these responsibilities for you. When you create an EKS cluster, AWS provisions and runs the Kubernetes control plane across multiple Availability&nbsp;Zones, applies security patches and upgrades, and manages critical components such as the API server and etcd. Because EKS integrates with AWS networking and security services—such as IAM, VPC networking and encryption—you can focus on building and deploying your workloads while AWS handles the underlying Kubernetes infrastructure. All that remains under your control are the worker nodes and the applications they run. This managed experience reduces operational overhead and enables you to adopt best practices with minimal effort.<h3>3&nbsp;Prerequisites and Tooling</h3>Before creating a cluster you need a few prerequisites:<ul><li>An AWS account with permissions to create EKS clusters and associated resources.</li><li><code>eksctl</code> – a command‑line tool for creating and managing EKS clusters. It automates the provisioning of the control plane and node groups.</li><li><code>kubectl</code> – the Kubernetes command‑line tool used to interact with your cluster for tasks such as applying manifests, inspecting resources and scaling workloads.</li><li>Docker – to build and package your application into container images. You’ll also need a container registry, such as Amazon Elastic Container Registry (ECR) or Docker Hub, to store your images.</li></ul>Install <code>eksctl</code> and <code>kubectl</code> using the instructions provided by AWS and Kubernetes, then verify the installation by running <code>eksctl version</code> and <code>kubectl version</code> on your local machine. A supported programming language runtime (for example, Python or Node.js) is needed to build your application.<h3>4&nbsp;Creating an EKS Cluster</h3><ol><li>Create the cluster – Use <code>eksctl</code> to create a cluster. The following command creates a cluster named <code>k8s-example</code> in the <code>eu-west-2</code> region:<pre><code class="language-bash">eksctl create cluster --name k8s-example --region eu-west-2</code></pre>This command provisions the Kubernetes control plane and an initial node group. Once provisioning completes, <code>eksctl</code> updates your <code>~/.kube/config</code> file so that <code>kubectl</code> can communicate with the new cluster.</li><li>Verify the cluster – After creation, confirm that the cluster is reachable by listing its resources:<pre><code class="language-bash">kubectl get nodes
kubectl get pods --all-namespaces
kubectl get namespaces</code></pre>These commands list nodes, pods and namespaces, verifying that the API server is responsive.</li><li>Configure AWS credentials – Ensure that your AWS CLI or SDK is configured with credentials that allow cluster creation and management. When you run <code>eksctl</code>, it automatically creates the necessary IAM roles for the control plane and node groups, but the underlying AWS account must have sufficient permissions.</li></ol><h3>5&nbsp;Building and Packaging Your Application</h3>To deploy an application on Kubernetes you first need to package it as a container image. For demonstration, assume a simple web service that listens on port&nbsp;3000. Create a <code>Dockerfile</code> in your project directory:<pre><code class="language-dockerfile">FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["npm", "start"]</code></pre>Build and push the image:<pre><code class="language-bash">docker build -t &lt;your-dockerhub-username&gt;/myapp:1.0 .
docker push &lt;your-dockerhub-username&gt;/myapp:1.0</code></pre>If you’re using Amazon ECR, login using <code>aws ecr get-login-password</code>, create a repository and push the image there.<h3>6&nbsp;Defining Kubernetes Manifests</h3>Next, define a Deployment and a Service in a YAML file (for example <code>deployment-example.yaml</code>). The deployment ensures a specified number of pod replicas using your container image, and the service exposes the pods via a load balancer. A sample manifest looks like this:<pre><code class="language-yaml">apiVersion: apps/v1
kind: Deployment
metadata:
 name: myapp-deployment
 namespace: default
 labels:
 app: myapp
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myapp
 template:
 metadata:
 labels:
 app: myapp
 spec:
 containers:
 - name: myapp-container
 image: &lt;your-dockerhub-username&gt;/myapp:1.0
 ports:
 - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
 name: myapp-service
 labels:
 app: myapp
spec:
 type: LoadBalancer
 ports:
 - port: 80
 targetPort: 3000
 selector:
 app: myapp</code></pre>In this example the Deployment runs 3 replicas, and the Service uses <code>type: LoadBalancer</code>. On AWS, this service type provisions an Elastic Load Balancer and routes traffic to your pods automatically. The <code>selector</code> field ensures that only pods with matching labels receive traffic.<h3>7&nbsp;Deploying the Application</h3>Apply your manifest to the cluster using <code>kubectl</code>:<pre><code class="language-bash">kubectl apply -f deployment-example.yaml</code></pre>Kubernetes creates the Deployment, ReplicaSet, pods and Service accordingly. Verify the status:<pre><code class="language-bash">kubectl get deployments
kubectl get pods
kubectl get svc</code></pre>When the Service shows an <code>EXTERNAL-IP</code>, open that IP in a browser to access your application. The load balancer distributes traffic across the pod replicas.<h3>8&nbsp;Scaling Your Application</h3><h4>8.1&nbsp;Manual scaling</h4>You can scale a deployment by changing the number of replicas. At creation time you can specify the <code>--replicas</code> flag with <code>kubectl create deployment</code>. Afterwards you can adjust the replica count declaratively by editing the manifest or imperatively using the <code>kubectl scale</code> command. For example, to scale to four replicas:<pre><code class="language-bash">kubectl scale deployments/myapp-deployment --replicas=4</code></pre>Scaling out a deployment ensures that new pods are created and scheduled on nodes with available resources. If you scale down, Kubernetes terminates excess pods while keeping the service available. Listing the deployment again shows updated <code>READY</code>, <code>UP‑TO‑DATE</code> and <code>AVAILABLE</code> columns.<h4>8.2&nbsp;Horizontal Pod Autoscaler (HPA)</h4>Manual scaling is useful for predictable workloads, but applications often experience fluctuating demand. The HorizontalPodAutoscaler resource automatically updates a Deployment or StatefulSet to match demand. Horizontal scaling means deploying more pods to handle increased load; vertical scaling (assigning more CPU or memory to existing pods) is a separate concept. The HPA controller runs in the control plane and periodically adjusts the desired scale based on metrics such as average CPU or memory utilization. When load decreases, it scales the deployment back down as long as the number of pods remains above the configured minimum.To use HPA you need the metrics server installed in your cluster. A simple HPA YAML might look like this:<pre><code class="language-yaml">apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: myapp-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: myapp-deployment
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50</code></pre>This configuration maintains between 2 and 10 replicas, targeting 50&nbsp;% average CPU utilization across the pods.<h4>8.3&nbsp;Scaling the underlying infrastructure</h4>Horizontal scaling of pods does not provision additional worker nodes. If your cluster lacks spare capacity, new pods remain in a <code>Pending</code> state. To scale the underlying compute resources automatically you need a Node autoscaler. The Kubernetes community sponsors two autoscalers: Cluster&nbsp;Autoscaler and Karpenter.Both autoscalers provision additional Nodes for unschedulable Pods and consolidate underutilized Nodes. Their differences lie in how they integrate with the cloud provider and how flexible they are:<ol><li>Cluster Autoscaler&nbsp;– adds or removes Nodes from pre‑configured Node groups. Node groups usually map to cloud‑provider scaling groups (for example Auto Scaling groups on AWS). A single Cluster Autoscaler instance can manage multiple Node groups and will add Nodes to the group that best fits the resource requests of pending Pods. When consolidating, it selects specific Nodes to remove, rather than simply shrinking the underlying group.</li><li>Karpenter&nbsp;– auto‑provisions Nodes based on NodePool (also called Provisioner) configurations defined by the cluster operator. Karpenter handles the entire node lifecycle: it provisions Nodes when pods cannot be scheduled, refreshes them when they reach a certain age and automatically upgrades them when new images are available. Karpenter works directly with individual cloud provider resources and does not rely on pre‑configured Node groups. It supports auto‑provisioning, meaning you specify only constraints and Karpenter chooses appropriate instance types.</li></ol>Cluster Autoscaler is part of the Kubernetes project and includes cloud provider integrations; Karpenter is published as a library that providers can integrate with. Karpenter currently has fewer provider integrations, but it offers faster scaling and more granular control. You can even run both autoscalers together: Cluster Autoscaler can handle steady‑state workloads, while Karpenter reacts quickly to sudden spikes. Combining a node‑level autoscaler with the Horizontal Pod Autoscaler ensures that your cluster scales pods and nodes in tandem.<h3>9&nbsp;Cleaning Up</h3>When you finish experimenting, delete the resources to avoid ongoing costs:<pre><code class="language-bash">kubectl delete -f deployment-example.yaml
eksctl delete cluster --name k8s-example --region eu-west-2</code></pre>Deleting the cluster removes all associated resources (node groups, VPCs and load balancers). Always verify that no additional AWS resources remain to prevent unexpected charges.<h3>10&nbsp;Conclusion</h3>In this tutorial you learned:<ul><li>The fundamental architecture of Kubernetes—including control plane components and worker nodes—and how deployments, pods and services work.</li><li>The advantages of Amazon EKS, which provides a managed control plane and integrates tightly with AWS networking and security services.</li><li>How to install the necessary tools (<code>eksctl</code> and <code>kubectl</code>), create an EKS cluster, package a simple application into a container image, define Kubernetes manifests and deploy the application on AWS.</li><li>How to scale your application manually with <code>kubectl scale</code>, automatically with a Horizontal Pod Autoscaler and scale your node pool using Cluster Autoscaler or Karpenter.</li></ul>Kubernetes and AWS EKS together provide a powerful, flexible platform for running containerized workloads in production. Starting from a basic deployment, you can layer on services, ingress controllers, continuous integration/continuous delivery (CI/CD) pipelines, observability tools and advanced autoscaling strategies. With a solid understanding of these fundamentals you’re ready to explore more advanced topics such as stateful workloads, service meshes and multi‑cluster deployments.

Getting Started with Kubernetes: Deploying and Scaling an Application on AWS

<h1>Kubernetes v1.33 “Octarine” – A Game-Changing Release</h1>Kubernetes v1.33, released on 23 April 2025, is codenamed “Octarine: The Color of Magic.” The release cycle lasted 15 weeks (13 Jan – 23 Apr 2025) and involved 570 contributors from 121 companies. It delivers 64 enhancements (18 stable, 20 beta, 24 alpha) targeting scalability, security, usability, and developer experience.For DevOps engineers balancing efficiency, security, and reliability, this release introduces features like native sidecars, dynamic resource scaling, and user namespaces by default, making it a true milestone.<a target="_blank" rel="noopener noreferrer nofollow" href="https://kubernetes.io/">Official release notes → kubernetes.io</a><hr><h2>From v1.32 (Penelope) to v1.33 (Octarine)</h2>Kubernetes v1.32 “Penelope” (Dec 2024) focused on stability and storage management, introducing:<ul><li>Single-process OOM kill – kubelet kills only the offending process during OOM instead of the entire container.</li><li>Auto-remove PVCs – StatefulSets clean up unused PVCs.</li><li>Dynamic Resource Allocation (DRA) improvements – structured parameter support for the scheduler.</li><li>Memory manager GA – better memory allocation across NUMA nodes.</li></ul>These laid the groundwork for v1.33’s breakthroughs in live scaling, isolation, and scheduling.<hr><h2>Key Stable Enhancements in v1.33</h2><h3>1. Native Sidecar Containers (GA)</h3>The sidecar pattern is now a first-class citizen. Sidecars:<ul><li>Start before app containers.</li><li>Run continuously with <code>restartPolicy: Always</code>.</li><li>Use readiness/liveness probes.</li></ul>Example: Running a logging sidecar with Fluent Bit alongside your main Nginx container:<pre><code class="language-yaml">apiVersion: v1
kind: Pod
metadata:
 name: web-with-logger
spec:
 initContainers:
 - name: sidecar-logger
 image: fluent/fluent-bit:latest
 restartPolicy: Always
 containers:
 - name: nginx
 image: nginx:latest</code></pre>This ensures logs are always collected without hacks.<hr><h3>2. Backoff Limits per Index &amp; Job Success Policy (GA)</h3>Indexed Jobs now support per-index retry limits and success policies.Example: Run a simulation where only one index must succeed:<pre><code class="language-yaml">apiVersion: batch/v1
kind: Job
metadata:
 name: simulation
spec:
 completions: 10
 backoffLimitPerIndex: 3
 successPolicy:
 type: Indexed
 indexes: ["0"] # Job succeeds if index 0 finishes</code></pre><hr><h3>3. Bound Service-Account Token Improvements (GA)</h3>Service account tokens now include:<ul><li>Unique JTI (token ID).</li><li>Node-specific binding.</li></ul>Example use case: You can restrict a token to only be valid on Node <code>worker-1</code>. This reduces lateral movement risks in compromised clusters.<hr><h3>4. Multiple Service CIDRs &amp; Subresource Support (GA)</h3>Clusters can allocate Service IPs from multiple CIDR ranges, avoiding IP exhaustion.Example:<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata:
 name: extra-service-cidr
spec:
 cidrs:
 - 10.97.0.0/16</code></pre>Also, <code>kubectl --subresource</code> lets you patch status directly:<pre><code class="language-bash">kubectl patch deployment myapp --subresource='status' \
 -p '{"status":{"availableReplicas":2}}'</code></pre><hr><h3>5. nftables Backend &amp; Topology-Aware Routing (GA)</h3><ul><li>nftables backend → more scalable alternative to iptables.</li><li>PreferClose traffic distribution → keep traffic within the same AZ.</li></ul>Example: A multi-zone Service routes traffic to the closest backend, reducing egress costs in AWS/GCP.<hr><hr><h2>Beta Features: Live Scaling &amp; Better Isolation</h2><h3>1. In-Place Pod Resource Resize (Vertical Pod Autoscaling)</h3>You can now resize CPU/memory of a running pod without restarting it.Example:<pre><code class="language-bash">kubectl patch pod myapp-123 --type='merge' \
 -p '{"spec":{"containers":[{"name":"myapp","resources":{"requests":{"memory":"2Gi"}}}]}}'</code></pre>This eliminates downtime for memory-intensive stateful apps like databases.<hr><h3>2. User Namespaces Enabled by Default</h3>Pods can run as root inside the container while being mapped to an unprivileged UID on the host.Example:<pre><code class="language-yaml">securityContext:
 runAsUser: 0 # root inside
 runAsNonRoot: true # mapped to non-root outside</code></pre>This prevents privilege escalation attacks.<hr><h3>3. Image Volumes (Beta)</h3>Pods can mount OCI images as volumes, separating tools from app images.Example:<pre><code class="language-yaml">volumes:
- name: tools
 csi:
 driver: image.csi.k8s.io
 volumeAttributes:
 image: myorg/debug-tools:latest</code></pre>This lets you inject debugging binaries without bloating your main image.<hr><hr><h2>Alpha Features: Future Directions</h2>Some experimental capabilities:<ul><li>Custom stop signals – define how containers should terminate.</li><li>Configurable HPA tolerance – fine-tune scaling oscillations.</li><li>Secret-less image pulls – kubelet fetches tokens automatically.</li><li>PSI (Pressure Stall Information) – advanced scheduling signals.</li></ul>These require feature gates enabled explicitly.<hr><h2>Deprecations &amp; Removals</h2><ul><li>Endpoints API → replaced by EndpointSlices.</li><li>gitRepo volume driver → removed (use <code>initContainers + git-sync</code>).</li><li>status.nodeInfo.kubeProxyVersion → dropped due to inaccuracy.</li></ul><hr><h2>Why v1.33 Is a Game-Changer for DevOps</h2><ol><li>Seamless Scaling Resize pods live → better elasticity for apps like Redis or Kafka.</li><li>Stronger Security User namespaces, node-scoped service tokens, ClusterTrustBundles → safer multi-tenant clusters.</li><li>Improved Scheduling NUMA-aware CPU assignment and topology-aware routing → lower latency for ML/AI workloads.</li><li>Better Developer Experience Sidecars as stable, image volumes, kubectl subresources → fewer hacks, faster iteration.</li></ol><hr><h2>Conclusion</h2>Kubernetes v1.33 “Octarine” transforms patterns like sidecars into stable primitives, enables in-place vertical scaling, and strengthens isolation with user namespaces by default. It streamlines networking, scheduling, and job management, while also cleaning up deprecated APIs.For DevOps teams, this release marks a new phase: clusters that scale live, isolate securely, and optimize resources intelligently.Read the official release notes at <a target="_blank" rel="noopener noreferrer nofollow" href="https://kubernetes.io/">kubernetes.io</a>.

Kubernetes

Getting Started with Kubernetes: Deploying and Scaling an Application on AWS

Kubernetes v1.33 “Octarine" – A Game-Changing Release