Kubernetes For Intermediate
The concepts that separate "I can deploy a pod" from "I can run real, multi-team workloads reliably" — for readers already comfortable with Kubernetes basics.
This guide assumes you already understand pods, Deployments, Services, and basic kubectl usage. It moves into the concepts that matter once you’re running Kubernetes for a real team: controlling exactly where workloads land, securing traffic between them, packaging applications with Helm, observing what’s actually happening in the cluster, and extending Kubernetes itself with custom resources.
1Advanced Workload Patterns
Deployment strategies and pod patterns beyond a single container.
Deployment Strategies (RollingUpdate, Recreate)
RollingUpdate replaces pods gradually with zero downtime; Recreate terminates all old pods before creating new ones, useful when a new and old version can’t run simultaneously.
Blue-Green Deployments in K8s
Runs two full environments (old and new) simultaneously and switches traffic between them instantly via a Service selector change, enabling instant rollback at the cost of double resource usage.
Canary Deployments
Routes a small percentage of traffic to a new version before a full rollout, typically implemented via multiple Deployments behind a single Service or an Ingress/service mesh with traffic-splitting rules.
Init Containers
Run to completion before a pod’s main containers start, commonly used for setup tasks like waiting for a dependency or seeding configuration files.
Sidecar Containers
Run alongside the main container in the same pod, sharing its network and storage, commonly used for proxies, log shippers, or service mesh data planes.
Pod Disruption Budgets
Limits how many pods of a given application can be voluntarily disrupted at once (during node drains or upgrades), protecting availability during planned maintenance.
2Advanced Scheduling
Controlling exactly where pods run, beyond letting the scheduler decide freely.
Node Affinity / Anti-Affinity
Rules that attract or repel pods from nodes based on node labels, supporting both hard requirements and soft preferences.
Pod Affinity / Anti-Affinity
Rules that attract or repel pods based on what other pods are already running on a node, useful for co-locating related services or spreading replicas for resilience.
Taints and Tolerations
Taints on a node repel pods unless they have a matching toleration, commonly used to reserve nodes for specific workloads like GPU-heavy jobs.
Pod Priority and Preemption
Higher-priority pods can evict lower-priority pods to get scheduled when resources are scarce, ensuring critical workloads aren’t starved.
Topology Spread Constraints
Ensures pods are evenly distributed across failure domains (zones, nodes), reducing the blast radius if one domain goes down.
3Networking In Depth
Beyond basic Services — controlling and securing traffic between workloads.
Network Policies
Firewall-like rules controlling which pods can communicate with which other pods, denying all traffic by default once any policy is applied to a pod’s namespace.
CNI Plugins (Calico, Cilium, Flannel)
Implement the actual pod networking layer; the choice affects whether Network Policies are enforceable at all, since not every CNI plugin supports them.
Ingress Controllers
The actual software (NGINX Ingress, Traefik, etc.) that implements Ingress resources — Ingress rules do nothing without a controller installed to act on them.
Service Mesh Basics (Istio/Linkerd)
Adds a sidecar proxy to every pod to handle traffic encryption, retries, and observability transparently, without changing application code.
Headless Services
A Service with no cluster IP, returning individual pod IPs directly via DNS — used when clients need to connect to specific pod instances, common with StatefulSets.
ExternalName Services
Maps a Service name to an external DNS name, letting in-cluster applications reference external systems using standard Kubernetes service discovery.
4Storage In Depth
Managing persistent data more deliberately than a beginner PVC setup.
Dynamic Provisioning
Automatically creates a Persistent Volume when a PVC is requested, using a StorageClass, instead of requiring an administrator to pre-create volumes manually.
Access Modes (ReadWriteOnce, ReadOnlyMany, etc.)
Define how many nodes can mount a volume simultaneously and in what mode — ReadWriteOnce is the most common and most restrictive, limiting a volume to one node at a time.
StatefulSet Storage Patterns
Each replica in a StatefulSet gets its own PVC created from a volumeClaimTemplate, preserving a stable one-to-one relationship between pod identity and storage.
Volume Snapshots
Captures a point-in-time copy of a Persistent Volume’s data, usable for backups or cloning environments, if the underlying storage driver supports it.
CSI (Container Storage Interface)
A standardized plugin interface that lets Kubernetes support many different storage backends without needing storage-vendor-specific code built into Kubernetes itself.
5Configuration & Secrets Management
Handling configuration and sensitive data more rigorously at team scale.
Secret Types (Opaque, TLS, Docker Registry)
Kubernetes Secrets have typed variants for specific purposes — TLS secrets for certificates, docker-registry secrets for private image pulls — beyond the generic Opaque type.
External Secrets Management (Vault Integration)
Tools like External Secrets Operator or Vault sync secrets from a dedicated secrets manager into Kubernetes Secrets, avoiding storing sensitive values directly in cluster manifests.
ConfigMap/Secret Hot Reloading Challenges
Updating a mounted ConfigMap or Secret doesn’t automatically restart pods using it — applications must watch for file changes themselves, or a rollout must be triggered manually.
Immutable ConfigMaps/Secrets
Marking a ConfigMap or Secret as immutable prevents accidental edits and reduces load on the API server, since Kubernetes no longer needs to watch it for changes.
6Helm & Package Management
Packaging and templating Kubernetes applications instead of hand-writing every YAML file.
What Is Helm?
The most widely used package manager for Kubernetes, letting you install, upgrade, and manage complex applications as a single unit called a chart.
Helm Charts
A packaged collection of templated Kubernetes manifests plus metadata, representing one deployable application or service.
Helm Values Files
YAML files that customize a chart’s behavior (like replica count or image tag) without modifying the chart’s underlying templates.
Helm Releases
A specific, named, deployed instance of a chart in a cluster — the same chart can be installed multiple times as different releases with different values.
Helm Repositories
Remote collections of published charts that can be searched and installed from, similar to a package registry for applications.
7Observability
Knowing what’s actually happening inside a running cluster.
Metrics Server
Collects basic CPU and memory usage from nodes and pods cluster-wide, providing the data source that Horizontal Pod Autoscaler relies on.
Prometheus & Grafana Integration
The de facto standard combination for collecting detailed time-series metrics (Prometheus) and visualizing them in dashboards (Grafana) across a cluster.
Kubernetes Events
Short-lived records of significant occurrences (scheduling decisions, failures, scaling actions) visible via kubectl describe or kubectl get events, often the first place to look during troubleshooting.
Liveness/Readiness/Startup Probes (Deep Dive)
Startup probes delay liveness/readiness checks for slow-starting applications, preventing a healthy-but-still-initializing container from being killed prematurely.
Distributed Tracing Basics
Tracks a single request as it moves across multiple microservices, typically via tools like Jaeger or Zipkin, essential once an application spans more than a couple of services.
8Security Fundamentals
Locking down who and what can do what inside the cluster.
RBAC In Depth (Roles, ClusterRoles, Bindings)
Roles/RoleBindings grant permissions within a single namespace; ClusterRoles/ClusterRoleBindings grant permissions cluster-wide — mixing these up is a common source of over-permissioning.
Service Accounts
Identities used by pods (not humans) to authenticate to the Kubernetes API — every pod uses one by default, often with more permissions than it actually needs.
Pod Security Standards
Built-in policy levels (Privileged, Baseline, Restricted) that can be enforced per namespace to prevent pods from running with dangerous configurations like host networking or privileged mode.
Network Policies for Security
Beyond basic connectivity control, Network Policies are a core defense-in-depth layer, limiting lateral movement if one workload in the cluster is compromised.
Image Pull Secrets
Credentials attached to a Service Account or pod spec that allow nodes to pull container images from private registries.
9Autoscaling In Depth
Scaling pods, resources, and the cluster itself automatically.
Horizontal Pod Autoscaler (Metrics-Based)
Automatically adjusts the number of pod replicas based on observed CPU/memory usage or custom metrics, requiring the Metrics Server (or a custom metrics adapter) to function.
Vertical Pod Autoscaler
Automatically adjusts a pod’s CPU/memory requests and limits based on observed usage over time, though changing these values typically requires restarting the pod.
Cluster Autoscaler
Adds or removes worker nodes based on whether pending pods can’t be scheduled due to insufficient resources — works at the infrastructure level, separate from pod-level autoscaling.
Custom Metrics Autoscaling
Scales pods based on application-specific metrics (like queue length or requests per second) rather than just CPU/memory, requiring a custom metrics API adapter.
10Custom Resources & Extensibility
Teaching Kubernetes to understand new kinds of objects.
Custom Resource Definitions (CRDs)
Let you define entirely new object types in Kubernetes (like a “Database” resource) that behave just like built-in objects such as Pods or Deployments.
Operators
Custom controllers that watch a CRD and automate operational tasks for complex applications (like databases), encoding human operational knowledge into software.
Admission Controllers
Intercept requests to the API server before objects are persisted, allowing them to validate or modify resources — the mechanism Pod Security Standards and many policy tools rely on.
Webhooks (Validating/Mutating)
Custom admission controllers implemented as external services — validating webhooks can reject a request, mutating webhooks can modify it before it’s saved.
11CI/CD & GitOps with Kubernetes
Automating deployments in a way that treats Git as the single source of truth.
GitOps Principles
The cluster’s desired state is defined entirely in a Git repository, and an automated process continuously reconciles the live cluster to match that repository.
ArgoCD / Flux Basics
The two most popular GitOps controllers, both continuously watching a Git repo and applying changes to the cluster automatically, with drift detection if someone manually changes something.
Kustomize
A templating-free way to customize raw Kubernetes YAML for different environments using overlays, built directly into kubectl.
CI/CD Pipeline Integration
In a GitOps model, CI builds and pushes images and updates manifest references in Git, while a separate CD controller (ArgoCD/Flux) handles the actual cluster deployment.
12Cluster Operations & Maintenance
Keeping a cluster healthy and up to date over time.
Cluster Upgrades
Kubernetes control plane and node versions must be upgraded in a specific order and skew tolerance, typically one minor version at a time, to avoid compatibility issues.
etcd Backup and Restore
Since etcd holds the entire cluster’s state, regular backups are essential — losing etcd without a backup means losing the record of everything the cluster is supposed to be running.
Node Draining and Cordoning
Cordoning marks a node as unschedulable for new pods; draining safely evicts existing pods from it, both necessary steps before performing node maintenance.
Resource Quotas and LimitRanges
Resource Quotas cap total resource usage per namespace; LimitRanges set default and maximum resource values for individual pods/containers within a namespace.
Multi-Cluster Basics
Running workloads across multiple clusters (for isolation, geographic distribution, or blast-radius reduction) introduces cross-cluster networking and configuration-sync challenges beyond single-cluster operations.
Key Takeaways
- Affinity, anti-affinity, and taints/tolerations give you real control over pod placement — essential once workloads have specific hardware or resilience requirements.
- Network Policies are a core security layer, not an optional add-on — without them, any pod in the cluster can talk to any other pod by default.
- Helm and GitOps (ArgoCD/Flux) solve two different problems — packaging/templating versus continuous, Git-driven deployment — and are commonly used together.
- CRDs and Operators are how Kubernetes extends beyond its built-in object types to manage complex, stateful applications like databases.
- Autoscaling has three independent layers — HPA (pods), VPA (pod sizing), and Cluster Autoscaler (nodes) — that solve different scaling problems.
- etcd backups and careful cluster upgrades are unglamorous but among the highest-stakes operational responsibilities in running Kubernetes.