CoreDNS turns names into Service IPs
How Service names resolve through CoreDNS and common DNS pitfalls.
Study notes
- Applications refer to Services by name. CoreDNS, running as a Deployment in kube-system, is the cluster's DNS server for the cluster.local domain. Each Pod's /etc/resolv.conf points at it and contains a search path, so a short name such as checkout is expanded to checkout.shop.svc.cluster.local using the Pod's own namespace. A name in another namespace needs the namespace: checkout.payments.
- Reveal the four steps: the app asks for checkout, the resolver tries the search path, CoreDNS answers with the Service's ClusterIP, and kube-proxy's rules route that virtual IP to one ready Pod.
- Two settings cause real incidents. ndots defaults to 5, so any name with fewer than five dots, including ordinary external names like api.stripe.com, is first tried against each internal search domain, producing several failed lookups before the real one. For latency-sensitive workloads that call many external APIs, lower ndots or use fully qualified names with a trailing dot. And dnsPolicy: Default is misleadingly named: it uses the node's resolver and bypasses CoreDNS, so internal names break; the real default is ClusterFirst.
- On large clusters CoreDNS load can become significant. Node-local DNS caching (NodeLocal DNSCache) is a common mitigation, and GKE and EKS offer managed variants.
Deck map
01
Kubernetes, from zero to operator
02
Seven decks, one continuous path
03
Five questions you would otherwise answer by hand
04
From Borg to a universal control plane
05
Declare the state; controllers close the gap
06
Brain and muscle: control plane and worker nodes
07
Managed or self-managed: who owns which layer
08
Orientation on one page: five questions, five automatic answers
09
Core objects: the vocabulary of every manifest
10
A Pod is the smallest thing Kubernetes runs
11
Every manifest has the same five-part shape
12
Labels are the glue between objects
13
Namespaces partition one cluster; contexts choose where kubectl points
14
kubectl: get, describe, events first
15
Keep configuration out of the image
16
Probes tell Kubernetes when to restart and when to send traffic
17
Core objects on one page
18
The control plane: the brain that decides and records
19
Everything talks to one front door
20
Every request passes three gates before it is stored
21
Admission webhooks: mutate first, then validate
22
etcd is the cluster's entire memory
23
Raft: a majority must agree before any write commits
24
etcd needs housekeeping: compact, then defragment
25
Controllers compare desired with actual, forever
26
Only one controller manager acts: leader election with a Lease
27
The API server scales out because it is stateless
28
CRDs and aggregated APIs extend the API in two different ways
29
Versions, ports and health checks you will actually use
30
The control plane on one page
31
Worker nodes: where containers actually run
32
The kubelet is the node's local agent
33
Nodes report in; silence is tolerated, then acted on
34
kube-proxy builds Service routing; the runtime runs containers
35
The full journey from kubectl apply to a running container
36
From kubectl apply to a running Pod on one page
37
Scheduling: deciding where every Pod runs
38
Two phases: rule out, then rank
39
The scheduler is a pipeline of plugins
40
Requests decide placement; limits decide enforcement
41
Namespaces get budgets and defaults
42
Taints repel; tolerations are permission slips
43
Node affinity: Pods choosing their nodes
44
Spread replicas across failure domains
45
Priority, preemption and disruption budgets
46
Scheduling on one page
47
Workloads: the objects that create and manage Pods
48
Deployment owns a ReplicaSet, which owns the Pods
49
A rolling update replaces Pods gradually and waits for readiness
50
StatefulSet: stable identity and storage
51
DaemonSets run everywhere; Jobs run to completion
52
Init containers run first; native sidecars live alongside
53
Choosing the right workload object
54
Workloads on one page
55
Networking: flat Pod IPs, stable Services, controlled traffic
56
Every Pod gets its own IP, reachable without NAT
57
A Service is a stable address for changing Pods
58
Headless Services and the EndpointSlice behind every Service
59
CoreDNS turns names into Service IPs
60
NetworkPolicy: from default-open to default-deny
61
Ingress and Gateway API bring HTTP traffic in
62
A request from the internet to a Pod
63
Networking on one page
64
Storage: data that outlives Pods
65
A claim asks, a class provisions, a driver delivers
66
Zones and access modes decide whether a volume can attach
67
CSI adds snapshots, clones and online expansion
68
Storage on one page
69
Real-world platforms: GKE, EKS and an on-prem Rancher fleet
70
The Shopwave estate: three platforms, one Git repository
71
Same manifest, three platforms: what actually changes
72
Rancher: one control point for many clusters
73
Three foundations-level incidents, one cause each
74
kubectl cheat sheet for this deck
75
Who owns what on one page
76
What you should be able to explain now
77
Quiz 1 of 5: Architecture and control plane
78
Quiz 2 of 5: Control plane, scheduling and failures
79
Quiz 3 of 5: Scheduling, workloads and platforms
80
Quiz 4 of 5: Workloads, probes and Services
81
Quiz 5 of 5: Networking and storage
82
Your score and what to review