# Networks
All Networks notes →# Agentic Ai Projects And Mastery
All Agentic Ai Projects And Mastery notes →# Ci Cd
All Ci Cd notes →What is ArgoCD
CNCF-graduated declarative GitOps continuous delivery tool for Kubernetes — pull-based reconciliation from Git via an Application CRD, the App-of-Apps pattern for fleet management, and Argo Rollouts for canary/blue-green progressive delivery.
What is FluxCD
CNCF-graduated GitOps toolkit for Kubernetes, built as a set of composable controllers (source, kustomize, helm, notification, image-automation) rather than one monolithic app — Flagger is its progressive-delivery counterpart to Argo Rollouts.
What is GitOps
A declarative delivery model where Git is the single source of truth for desired system state, and an in-cluster controller continuously reconciles live state to match it — the operating model behind ArgoCD and FluxCD.
# Patterns
All Patterns notes →# Kubernetes Platform Engineering
All Kubernetes Platform Engineering notes →1 — Why Kubernetes Became the Platform Standard
Covers Evolution of Container Orchestration, Kubernetes as a Platform, Platform Engineering on Kubernetes, and Platform Responsibilities.
2 — Kubernetes Platform Architecture
Covers Control Plane, Worker Nodes, Cluster Services, Platform Layers, and Platform Boundaries.
3 — Kubernetes as an Internal Developer Platform
Covers Platform Users, Platform Services, Shared vs Dedicated Clusters, and Platform Interfaces.
4 — Kubernetes Platform Maturity Model
Covers Foundational Platform, Self-Service Platform, Enterprise Platform, and Autonomous Platform.
1 — Reference Platform Architecture
Covers Compute Layer, Networking Layer, Storage Layer, Security Layer, and Observability Layer.
2 — Cluster Architecture Patterns
Covers Single Cluster, Multi-Cluster, Regional Clusters, Global Clusters, and Fleet Architecture.
3 — Control Plane Design
Covers High Availability, Managed vs Self-Managed, Upgrade Strategies, and API Server Scaling.
4 — Node Architecture
Covers Node Pools, Specialized Nodes, Autoscaling, Spot Nodes, and GPU Nodes.
# Kubernetes
All Kubernetes notes →1 — Why Kubernetes Exists
Why declarative, self-healing reconciliation beat hand-rolled scripts and imperative config management once server fleets outgrew what humans could reconcile by hand.
2 — Linux Fundamentals
Why a container is just a regular Linux process wearing namespaces for isolation and cgroups for resource limits, not a lightweight virtual machine.
3 — Containers & OCI
Why the OCI image and runtime specs matter more than Docker itself — they let containerd, CRI-O, and Podman run the same artifact without vendor lock-in.
4 — Kubernetes Architecture
Why the control plane's continuous reconciliation loop, not the scheduler alone, is what makes Kubernetes self-healing rather than merely self-installing.
5 — Installing Kubernetes
Why kubeadm, managed control planes, and kubeadm-free distros mainly differ in who owns lifecycle and upgrade risk, not in what a conformant cluster actually runs.
6 — Kubernetes API & Object Model
Why kubectl is just a REST client — every object is a resource in the API server's store, making the API server the only legitimate path to change cluster state.
1 — Pods
Why a Pod, not a container, is the atomic unit of scheduling — containers sharing a Pod share network namespace and IPC but never share a lifecycle.
2 — Labels, Selectors & Annotations
Labels are indexed and queryable for selection and grouping; annotations hold non-identifying metadata the scheduler never selects on.
3 — ReplicaSets
A ReplicaSet only guarantees replica count and pod-template match — it has no concept of rollout history, which is why Deployments layer on top of it.
4 — Deployments
Deployments add rollout history and rollback on top of ReplicaSets by keeping old ReplicaSets scaled to zero instead of deleting them.
5 — StatefulSets
StatefulSets trade the Deployment's disposable-replica model for stable pod identity and ordinal-indexed PersistentVolumeClaims that survive rescheduling.
6 — DaemonSets
DaemonSets bind pod placement to node lifecycle rather than replica count — one pod per matching node, added and removed as nodes join or leave the cluster.
7 — Jobs & CronJobs
Jobs track completion count rather than desired replica count, which is why a CrashLoopBackOff in a Job looks nothing like one in a Deployment.
8 — Namespaces
Namespaces partition names and quota, not network or security — RBAC and NetworkPolicy have to be added explicitly, isolation is never implied by the namespace boundary alone.
9 — Resource Management (Requests, Limits, QoS)
The scheduler only reads requests, never limits — the requests-to-limits ratio instead decides the pod's QoS class, which is what actually governs eviction order under node pressure.
1 — ConfigMaps
ConfigMaps mounted as volumes update live on the filesystem when the source changes, but env vars sourced from a ConfigMap are frozen at container start until the pod restarts.
10 — ResourceQuota & LimitRange
ResourceQuota caps aggregate consumption per namespace while LimitRange sets per-object defaults and min/max — without a LimitRange, one pod that omits resource requests can exhaust the whole namespace's quota.
2 — Secrets
Kubernetes Secrets are base64-encoded, not encrypted, by default — real confidentiality at rest requires enabling etcd encryption or an external secrets store, not just using the Secret object.
3 — Downward API
The Downward API lets a container read its own pod's metadata — labels, annotations, resource limits, IP — as env vars or files, avoiding an API server round trip and the RBAC permissions that would require.
4 — Environment Variables
Env vars are resolved once when the container process starts, so a downstream ConfigMap or Secret edit has no effect until the pod is recreated — unlike a mounted volume, which the kubelet syncs live.
5 — Probes (Liveness, Readiness, Startup)
Startup probes exist to hold off liveness checks during a slow boot, since without one a container that's merely still initializing gets killed and crash-looped as if it were actually hung.
6 — Init Containers
Init containers run sequentially to completion before any app container starts, making them the natural place for one-time setup like schema migrations or dependency wait-checks that shouldn't re-run on every app-container restart.
7 — Sidecars
A sidecar shares the pod's network namespace and volumes with the main container, which is exactly what lets patterns like a local Envoy proxy or log shipper attach without any code change to the primary app.
8 — Multi-Container Pods
Containers in the same pod are always co-scheduled on one node and share the same lifecycle, which is why you can't scale or restart one container independently of the others in the pod.
9 — Application Health Patterns
Conflating liveness (should this be restarted) with readiness (should this receive traffic) causes cascading restarts when a pod is merely overloaded and slow rather than actually broken.
1 — Scheduler Internals
Why the scheduler's filter-then-score two-phase pipeline exists instead of just placing a pod on the first node that fits.
10 — Upgrades & Version Skew
Why the N-2 kubelet-to-API-server version skew policy is what lets a large fleet upgrade gradually instead of needing a synchronized all-at-once cutover.
2 — nodeSelector
Why nodeSelector's exact-match label equality makes it too blunt for anything beyond simple hardware-tier pinning.
3 — Node Affinity
Why splitting node affinity into required (hard) and preferred (soft) rules lets you express 'must have SSD' and 'prefer us-east' in the same spec.
4 — Pod Affinity & Anti-Affinity
Why the topology key, not just 'same node' or 'different node', is what actually spreads replicas across real failure domains.
5 — Taints & Tolerations
Why taints repel pods by default while tolerations only grant permission to land there — they never force placement the way affinity does.
6 — Priority Classes
Why priority classes only matter at eviction and preemption time under resource pressure, not as a routine scheduling hint.
7 — Topology Spread Constraints
Why maxSkew is the one knob that finally balances replicas evenly across zones without the all-or-nothing rigidity of anti-affinity.
8 — Node Maintenance
Why cordon-then-drain, not a bare delete, is the only sequence that respects PodDisruptionBudgets while evacuating a node.
9 — Cluster Lifecycle
Why control-plane and etcd lifecycle, not just worker node churn, is the part of 'cluster lifecycle' most operators under-plan for.
1 — Kubernetes Networking Model
Why the flat 'every Pod gets a routable IP, no NAT' contract is what lets Kubernetes treat networking as a pluggable implementation detail instead of a per-app concern.
2 — CNI Architecture
CNI is a thin exec-based plugin contract, not a networking stack itself — which is why Calico, Cilium, and Flannel can implement wildly different dataplanes (iptables, eBPF, VXLAN) behind the same interface.
3 — Services
A Service is a stable virtual IP backed by an ever-changing Endpoints/EndpointSlice list — the abstraction exists precisely because Pod IPs are ephemeral and cannot be a load-balancing target.
4 — kube-proxy
kube-proxy doesn't proxy traffic in the IPVS/iptables modes — it only programs kernel-level NAT rules on each node, so a kube-proxy crash doesn't break existing connections, only new rule updates.
5 — CoreDNS
CoreDNS resolves Service names by querying the API server, not by watching iptables — so a Service can be DNS-resolvable milliseconds before kube-proxy has actually wired up a route to it.
6 — Ingress
The Ingress resource is a portable schema with no built-in implementation — every annotation you add to make it actually do something ties you to one specific controller, quietly breaking portability.
7 — Gateway API
Gateway API splits the single Ingress object into role-scoped resources (GatewayClass, Gateway, HTTPRoute) specifically so platform teams and app teams can own different layers without stepping on each other's config.
8 — Network Policies
NetworkPolicy is default-permissive until the first policy selects a Pod — the moment you write one ingress rule for a Pod, all other traffic to it is implicitly denied, which is a common outage-by-surprise.
9 — Service Mesh Overview
A service mesh moves retries, mTLS, and traffic shaping out of application code into a sidecar proxy — trading a real latency and operational-complexity cost for uniform policy enforcement across every service.
1 — Volumes
A Kubernetes volume is scoped to the pod, not the container, so it survives container crashes and restarts but is deleted the moment the pod itself is removed.
2 — Persistent Volumes
PersistentVolumes decouple storage provisioning from pod scheduling by making storage a cluster-scoped resource with its own lifecycle, independent of any pod or namespace.
3 — Persistent Volume Claims
A PVC lets an application manifest request storage abstractly, by size and access mode, so developers never need to know or care which physical backend actually satisfies it.
4 — Storage Classes
StorageClasses turn PV provisioning into a self-service API, letting a PVC request storage by named profile instead of an admin having to hand-create a matching PV first.
5 — CSI Drivers
The Container Storage Interface moved vendor-specific storage code out of Kubernetes core entirely, so new backends can ship as independently versioned plugins instead of waiting on a Kubernetes release.
6 — Stateful Storage Design
Pairing StatefulSet ordinal identity with per-replica PVCs is what lets a rescheduled database pod reattach to its own disk instead of a peer's, which is the whole trick behind running stateful workloads on Kubernetes.
1 — Authentication
Kubernetes has no built-in user database — every request is authenticated by delegating identity checks to external mechanisms like X.509 client certs, OIDC tokens, or webhook callouts.
2 — Authorization
Authorization modes configured on the API server are OR'd together and evaluated in sequence, so a single permissive authorizer overrides every stricter one you also enabled.
3 — RBAC
RBAC bindings are purely additive with no deny rule, so a subject's effective permissions are the union of every Role and ClusterRole granted across all its bindings, not just the narrowest one.
4 — Service Accounts
Every pod is auto-mounted a default ServiceAccount token whether it calls the API or not, which is why disabling automountServiceAccountToken is a low-cost baseline hardening step.
5 — kubeconfig
A kubeconfig keeps clusters, users, and contexts as three independent lists, which is why one merged file (via the KUBECONFIG env var) can cleanly mix-and-match many identities across many clusters.
6 — Admission Controllers
Admission runs in two strict phases — all mutating webhooks complete before any validating webhook fires — so validation always inspects the final, already-mutated object, never the raw request.
7 — API Server Security
The API server is the single choke point for every cluster interaction, so disabling anonymous-auth and turning on audit logging there closes more risk surface than hardening any individual workload.
8 — Secret Encryption
Secrets are only base64-encoded in etcd by default, not encrypted, so without an EncryptionConfiguration enabling envelope encryption (ideally via a KMS provider) anyone with etcd access reads them in plaintext.
1 — Pod Security Standards
Pod Security Standards replaced the removed PodSecurityPolicy admission controller with three built-in profiles (Privileged, Baseline, Restricted) enforced declaratively via namespace labels.
10 — Protecting the Control Plane
Because etcd stores every cluster secret unencrypted by default, encryption at rest, mutual TLS between control plane components, and tightly scoped RBAC on kube-system are the highest-leverage hardening steps, not just API server firewalling.
2 — Security Contexts
A securityContext can be set at both pod and container level to drop capabilities, force non-root execution, or make the root filesystem read-only, and container-level fields always override pod-level defaults.
3 — Seccomp
Seccomp filters which syscalls a container's process is allowed to make at the kernel level, and the RuntimeDefault profile alone blocks dozens of dangerous syscalls that ordinary application workloads never legitimately need.
4 — AppArmor
AppArmor confines a process with path-based file, network, and capability rules rather than syscall filtering, and since Kubernetes 1.30 it is configured as a first-class securityContext field instead of only through legacy annotations.
5 — SELinux
SELinux enforces mandatory access control by comparing security-context labels on processes and objects rather than relying on discretionary Unix permissions, and label mismatches are the most common cause of unexplained permission-denied errors in hardened clusters.
6 — Capabilities
Linux capabilities split root's monolithic power into roughly forty discrete privileges, so dropping ALL and adding back only what's needed, like NET_BIND_SERVICE, is a far narrower grant than running the container as root.
7 — Linux Kernel Isolation
Containers isolate processes using namespaces and cgroups on a single shared host kernel rather than virtualizing hardware, so a kernel-level exploit inside one container can compromise every other container scheduled on that node.
8 — RuntimeClass
RuntimeClass lets a pod select a different container runtime, such as runc, gVisor, or Kata, so untrusted or multi-tenant workloads can get stronger isolation without changing the cluster-wide default runtime for every other workload.
9 — Sandboxed Containers (gVisor, Kata)
gVisor intercepts syscalls through a userspace kernel while Kata runs each pod inside a lightweight VM, and both trade some raw performance for a dramatically smaller attack surface than a shared-kernel container runtime.
1 — Image Security
Why minimal or distroless base images shrink the attack surface far more than patching CVEs in a bloated one ever will.
2 — Image Signing
A signature only proves who built the image, not that it's safe — signing and scanning solve different problems and neither substitutes for the other.
3 — Sigstore & Cosign
Keyless signing binds an image to an OIDC identity and a public transparency log instead of a long-lived private key that can leak or expire.
4 — SBOM
An SBOM turns 'are we affected by this CVE' from a multi-day manual audit into a single query against a manifest already generated at build time.
5 — Vulnerability Scanning
Scanning only at build time catches CVEs known when the image shipped — rescanning at admission and runtime is what catches the ones disclosed afterward.
6 — Trusted Registries
A registry allowlist enforced at the admission layer is what actually stops an untrusted image from running — scanning alone only warns, it doesn't block.
7 — Policy Enforcement (OPA Gatekeeper, Kyverno)
Kyverno's native Kubernetes-resource policies trade Rego's expressiveness for a much shorter path from 'write policy' to 'policy enforced'.
8 — Software Supply Chain Security
Most real-world breaches like SolarWinds and xz-utils compromised the build pipeline itself, not the shipped artifact — securing the artifact after the fact is too late.
9 — SLSA Framework
SLSA's levels grade the provenance of the build process, not the code's security — a perfectly secure app built on an untrusted pipeline still fails the bar.
1 — Falco
Falco flags anomalous behavior by matching live kernel syscalls against declarative rules, catching threats that only manifest at runtime and never show up in a static image scan.
2 — eBPF Security
eBPF lets security tooling observe and enforce policy directly in the kernel without loading custom kernel modules or injecting sidecars, trading portability risk for near-zero-overhead visibility.
3 — Runtime Threat Detection
Runtime threat detection catches attacks that exist only as live processes or in-memory payloads — exactly the class of compromise that image scanning and admission control cannot see because nothing malicious was ever written to disk.
4 — Audit Logs
Kubernetes audit logs record every API server request as a structured, replayable trail of who-did-what-when, but a loosely scoped audit policy can silently omit the exact response stage where a compromise actually happened.
5 — Incident Response
Kubernetes incident response means isolating a compromised pod with a NetworkPolicy or node cordon before killing it, because deleting it first destroys the ephemeral evidence needed to determine how the attacker got in.
6 — Forensics
Container forensics is a race against ephemeral filesystems and pod rescheduling, so memory dumps, process trees, and network state must be captured at detection time, not after triage begins.
7 — Container Escape Techniques
Most container escapes exploit a workload's own misconfiguration — privileged mode, a hostPath mount, or a mounted container-runtime socket — rather than a kernel zero-day, making prevention primarily a policy problem, not a patching problem.
8 — Mitigations
Layered runtime controls — seccomp profiles, AppArmor/SELinux, Pod Security Admission, and non-root enforcement — each close a different escape vector, so relying on any single control leaves the others wide open.
9 — Security Monitoring
Security monitoring only works when signals from the control plane (audit logs), the kernel (eBPF/Falco), and the network (CNI flow logs) are correlated together, since any single layer alone leaves a blind spot an attacker can walk through.
1 — Logging
Why Kubernetes has no built-in log aggregation by design — stdout/stderr capture by the kubelet is node-local and ephemeral, so durability is a platform-team responsibility, not a cluster feature.
2 — Metrics
Why metrics-server only ever powers kubectl top and the HPA — it holds no history by design, which is exactly the gap Prometheus was built to fill in every real cluster.
3 — Tracing
Why distributed tracing across a cluster is a service-mesh and instrumentation problem, not a kubelet one — Kubernetes has no native concept of a request, so context has to survive every sidecar hop on its own.
4 — Events
Why Kubernetes Events default to a 1-hour TTL in etcd — they're built as a live debugging signal for right-now, not an audit trail, and vanish before most incident retros even start.
5 — kubectl Debug
Why kubectl debug's ephemeral containers can attach to a running pod's process namespace without restarting it — the only clean way to get a shell into a distroless container that ships none of its own.
6 — Troubleshooting Production Clusters
Why most production cluster incidents trace back to control-plane pressure or misconfigured resource requests rather than application bugs — the debugging path starts at the scheduler and kubelet, not the pod logs.
1 — Scheduler Deep Dive
Why the scheduler keeps three separate queues (active, backoff, unschedulable) instead of one, so a pod that can't yet be placed doesn't hot-loop the whole pipeline.
2 — Controller Manager
Why every built-in controller is level-triggered against the informer cache rather than edge-triggered off individual watch events, which is what makes reconciliation idempotent after a restart.
3 — kubelet Internals
How the kubelet's PLEG polls the container runtime out-of-band from the main SyncLoop, trading a few seconds of detection latency for immunity to missed or coalesced CRI events.
4 — etcd Internals
How etcd's MVCC revision counter, not object timestamps, is what makes watch resumption after a disconnect and optimistic concurrency via resourceVersion possible.
5 — API Server Internals
Why every request, regardless of which controller or kubectl call triggered it, passes through the same authn -> authz -> admission -> validation chain, making the API server the single enforcement point for cluster policy.
6 — Admission Webhooks
Why mutating webhooks always run before validating webhooks in the admission chain, so validation only ever sees the final, defaulted version of an object.
7 — Aggregated APIs
How the aggregation layer lets extension API servers, like metrics-server, register under the same /apis path so kubectl, RBAC, and discovery treat them identically to built-in resources.
1 — Helm
Helm's Go-template-over-YAML approach turns configuration into string manipulation instead of structured data, trading type safety for reusability across charts.
2 — Kustomize
Kustomize edits valid YAML with strategic-merge patches instead of templating it, so every intermediate step stays parseable and diffable.
3 — Argo CD
Argo CD's pull-based reconciliation means the cluster fetches its own desired state from Git, so a compromised CI pipeline never gets a credential that can write to the cluster.
4 — Flux
Flux splits GitOps into composable controllers — source, kustomize, and notification — so drift detection and reconciliation are independent concerns instead of one monolithic sync job.
5 — Operator Framework
The Operator Framework's real value isn't wrapping CRUD around a CRD — it's encoding an SRE's operational runbook into a reconcile loop so failure recovery happens without a human paging in.
1 — AKS
AKS makes the control plane free specifically so Azure can win on node-hour billing, which is why the real cost and design battle moves to node pool sizing, availability zones, and Azure CNI IP exhaustion.
2 — EKS
EKS charges for the control plane yet still leaves CoreDNS, kube-proxy, and the CNI as self-managed add-ons, proving that 'managed Kubernetes' is a spectrum of responsibility rather than a single guarantee.
3 — GKE
GKE Autopilot bills per-pod resource request rather than per-node, which inverts the usual capacity-planning problem by making the scheduler itself the thing you optimize for cost, not the node pool.
4 — Cluster API
Cluster API models a whole cluster's lifecycle (bootstrap, upgrade, scale, teardown) as Kubernetes custom resources, turning fleet management into just another reconciliation loop instead of a bespoke provisioning script.
5 — Federation
KubeFed's decline in favor of GitOps-pushed manifests showed that replicating API objects across clusters is the wrong abstraction — the failure mode isn't the sync mechanism, it's treating clusters as one logical API server.
6 — Multi-Cluster Networking
Flat pod-to-pod routing across clusters (Submariner, Cilium ClusterMesh) is the easy part; the hard part is keeping service identity and mTLS trust consistent once two clusters' CAs and DNS zones have to agree.
7 — Multi-Region Architecture
Active-active multi-region Kubernetes trades away a single source of truth for lower latency, so the design question stops being 'how do we replicate' and becomes 'how do we resolve conflicting writes during a partition.'
8 — Hybrid Kubernetes
Hybrid Kubernetes (Anthos, Azure Arc) only holds together when the control plane's API surface is identical on-prem and in cloud; the moment it diverges, workloads behave differently depending on where they land.
1 — Resource Optimization
Why requests should track real p95 usage while limits stay loose — tight CPU limits throttle a container even when the node has idle capacity sitting unused right next to it.
2 — Scheduler Performance
Why scheduling throughput degrades non-linearly past a few thousand nodes unless percentageOfNodesToScore is tuned down from its default of scoring every feasible node.
3 — Cluster Autoscaler
Why Cluster Autoscaler scales purely on unschedulable pending pods rather than utilization metrics, making it reactive by design and blind to a burst until pods have already failed to schedule.
4 — Karpenter
Why Karpenter provisions right-sized nodes directly from pending pod shape instead of scaling pre-defined node groups, collapsing the ASG-and-node-group abstraction Cluster Autoscaler depends on.
5 — Vertical Pod Autoscaler
Why VPA's Auto and Recreate update modes still evict and restart a pod to resize it — true in-place resize without disruption only lands with the still-maturing InPlacePodVerticalScaling feature.
6 — Horizontal Pod Autoscaler
Why HPA's polling-interval and stabilization-window defaults make it structurally too slow for sub-minute traffic spikes, forcing teams toward custom metrics or KEDA to react in time.
7 — Network Performance
Why the CNI's choice between an overlay (VXLAN/IPIP encapsulation) and native BGP routing is usually the single biggest lever on pod-to-pod latency and throughput, ahead of kube-proxy mode.
8 — Storage Performance
Why local NVMe (local-path or a CSI ephemeral volume) beats network-attached PVs on latency, but only by trading away the pod-to-node decoupling that makes rescheduling safe.
9 — Large Cluster Design
Why Kubernetes' official node-count ceiling is really an etcd write-throughput and API server watch-fanout limit, which is why hyperscalers split fleets into many smaller clusters instead of pushing past it.
1 — High Availability
Running three or more control-plane replicas behind a load balancer only buys availability if etcd quorum, not just the API server, survives the loss of any single node.
2 — Disaster Recovery
Disaster recovery is defined by RTO and RPO targets negotiated before an outage, not by how fast a runbook can be executed after one.
3 — Backup & Restore
Backing up etcd snapshots without also capturing PV data and CRDs restores a control plane that boots but manages nothing.
4 — Multi-Tenancy
Namespace isolation alone is not a security boundary; without NetworkPolicies, ResourceQuotas, and PodSecurityAdmission, one hostile tenant can starve or reach every other tenant on the same node.
5 — Cost Optimization
Most Kubernetes clusters waste money on the requested-vs-used gap, not on compute price: pods routinely request two to three times what they actually consume, so right-sizing requests beats chasing spot-instance discounts.
6 — Reliability Engineering
Kubernetes self-healing masks the symptoms of reliability problems, not the causes, so an SLO-driven error budget is what actually tells you whether the system is healthy.
7 — Production Anti-Patterns
Missing resource requests/limits, floating 'latest' image tags, and skipped liveness/readiness probes are the three anti-patterns responsible for the majority of production Kubernetes incidents.
8 — Kubernetes Failure Modes
The most dangerous Kubernetes failures are control-plane and etcd degradations, not pod crashes, because they fail silently — the API server keeps serving stale state while nothing can actually be scheduled or reconciled.
9 — Real Production Case Studies
Post-incident reviews from real Kubernetes outages consistently trace root cause to a control-plane or DNS bottleneck — CoreDNS, etcd, API server throttling — rather than the workload code itself.
1 — Kubernetes in Distributed Systems
Why the reconciliation loop — declare desired state, continuously converge toward it — replaces imperative orchestration as Kubernetes' core distributed-systems primitive.
2 — Running Thousands of Microservices
Why organizational boundaries, not etcd or scheduler limits, become the real constraint on cluster and namespace design once service count crosses into the thousands.
3 — Event-Driven Platforms
Why event-driven platforms on Kubernetes trade request-response simplicity for the ability to absorb bursty load and isolate producer and consumer failure domains.
4 — AI/ML Platforms on Kubernetes
Why GPU scheduling — bin-packing, MIG partitioning, gang scheduling for distributed training — is the hard problem in running ML workloads on Kubernetes, not container orchestration itself.
5 — Platform Engineering at Scale
Why platform teams that ship a self-service golden path scale sublinearly with tenant count, while teams that field tickets scale linearly with headcount.
6 — Large-Scale Observability
Why cardinality, not raw data volume, is the constraint that breaks observability pipelines first once a platform spans hundreds of clusters.
7 — Designing Control Planes
Why every control plane is a distributed consensus problem in disguise — the API server and etcd exist to answer 'what is true right now' under concurrent writers.
8 — Architecture Interview Case Studies
Why the strongest system-design interview answers name the failure mode they're trading against, not just the components drawn on the whiteboard.
1 — CKAD Objectives
Maps the CNCF CKAD curriculum domains (application design, deployment, observability, networking, state) to weighted exam percentages and the specific kubectl imperative commands each domain tests
10 — Incident Response Exercises
Simulated compromise scenarios (exposed API server, malicious container escape, leaked service account token) that train the CKS incident-response workflow: isolate, capture forensic evidence, and remediate
11 — CKS Mock Exams
Full-length timed mock exams that simulate the CKS's 2-hour, security-remediation task format to train fast triage of hardening gaps, admission-control debugging, and forensic response under time pressure
2 — CKAD Hands-on Labs
Timed lab exercises that drill Deployment/Job/CronJob manifests, ConfigMap and Secret wiring, and multi-container Pod patterns using only kubectl and vim under the exam's browser-terminal constraints
3 — CKAD Mock Exams
Full-length timed mock exams that simulate the CKAD's 2-hour, 15-19 task format to train question triage, kubectl imperative speed, and flagging-for-review under real exam time pressure
4 — CKA Objectives
Maps the CNCF CKA curriculum domains (cluster architecture/installation, workloads, services/networking, storage, troubleshooting) to weighted exam percentages and the kubeadm/etcd/control-plane operations each domain tests
5 — Cluster Administration Labs
Hands-on labs covering kubeadm cluster bootstrap, etcd backup/restore, node cordon/drain/upgrade sequencing, and control-plane component troubleshooting via static pod manifests
6 — CKA Mock Exams
Full-length timed mock exams that simulate the CKA's 2-hour, multi-cluster task format to train fast context-switching between kubeconfig contexts, ssh-into-node debugging, and etcd/control-plane recovery under time pressure
7 — CKS Objectives
Maps the CNCF CKS curriculum domains (cluster hardening, minimize microservice vulnerabilities, supply chain security, monitoring/logging/runtime security) to weighted exam percentages and their required CIS benchmark and admission-control tooling
8 — CKS Security Labs
Hands-on labs applying PodSecurity admission, NetworkPolicy default-deny, image signature verification, and kube-bench CIS hardening remediation against a live cluster
9 — Runtime Security Labs
Hands-on labs using Falco rule tuning and seccomp/AppArmor profile enforcement to detect and block anomalous syscalls, container drift, and privilege escalation at runtime
1 — Kubernetes Design Questions
Why the strongest answer to a multi-tenant platform design question starts from isolation boundaries (namespace vs. cluster vs. node) rather than jumping straight to YAML.
2 — Kubernetes Troubleshooting Interviews
Why interviewers grade the diagnostic sequence (events, describe, logs, then metrics) more heavily than whether you name the eventual root cause.
3 — Kubernetes Internals Interviews
Why grasping the reconciliation loop (watch, diff, act) explains almost every 'why didn't my change take effect' internals question the interviewer can ask.
4 — Production Incident Walkthroughs
Why a credible incident narrative names the blast-radius containment step before the root cause, since sequencing is what separates senior candidates from mid-level ones.
5 — Leadership & Architecture Discussions
Why staff+ architecture interviews probe how you built cross-team consensus on a platform decision, not just whether the decision itself was technically correct.
6 — Common MAANG Kubernetes Questions
Why 'what happens when a pod is scheduled' and 'what happens when a node dies' stay the two highest-frequency questions because they force you to narrate the whole control plane.
7 — Whiteboard Exercises
Why whiteboard Kubernetes exercises reward drawing the control plane and data plane as separate boxes first, since conflating them is the most common early mistake.
8 — Final Revision Checklist
Why a pre-interview revision checklist should be organized by failure mode (scheduling, networking, storage, control plane) rather than by Kubernetes object type.
Kubernetes
A book-shaped table of contents for Kubernetes: cloud-native foundations, the CKAD/CKA/CKS certification tracks, control-plane internals, platform tooling, multi-cluster architecture, and MAANG-level system design and interview prep — cross-linking the existing Prometheus, Observability, and Platform Engineering chapters instead of duplicating them.
# Observability
All Observability notes →1 — Kubernetes Metrics
Covers the cAdvisor/kubelet/kube-state-metrics metric surfaces and which one answers which question about a cluster.
2 — Control Plane Monitoring
Covers monitoring the API server, etcd, scheduler, and controller-manager — the control plane's own health as a distinct concern from workload health.
3 — Node Monitoring
Covers node-level resource pressure signals and how they surface as pod evictions and scheduling failures.
4 — Pod Monitoring
Covers pod lifecycle, restart, and readiness/liveness signal correlation with application-level telemetry.
5 — Cluster Events
Covers the Kubernetes Events API as a signal type distinct from metrics and logs, and its short default retention.
6 — Container Runtime
Covers container-runtime-level signals (CRI metrics, OOM kills) that sit below the kubelet's own reporting.
7 — Service Mesh Observability
Covers the telemetry a sidecar mesh generates for free — mTLS, retries, and per-hop latency — versus what still needs app-level instrumentation.
8 — eBPF Based Observability
Covers kernel-level eBPF telemetry collection as a zero-instrumentation alternative for network and syscall-level visibility.