Engineering notes that start with the basics

DNS turns a name into an address. Every answer is cached with an expiry, and there is no way to recall a cached answer early — which explains almost every DNS problem you will meet.

Almost every server, container and cloud instance you will ever touch runs Linux — so this is the layer underneath everything else in these notes.

Every "it can't connect" problem is one of four things: wrong address, wrong port, a firewall, or nothing listening.

SSH is how you reach every server you will ever manage — and once `~/.ssh/config` is set up, it becomes one short word instead of a long command.

Git tracks snapshots of your whole project, not changes to individual files — once that clicks, most of Git stops being confusing.

CI answers "did this change break anything?" CD answers "can this change reach users safely?" They are different problems and people conflate them constantly.

Jenkins is a job runner with an enormous plugin ecosystem — which is both why it survives everywhere and why every neglected Jenkins becomes a liability.

The cluster pulls its desired state from Git instead of a pipeline pushing into the cluster — which turns "what is deployed?" from an investigation into a `git log`.

Docker packages an application together with everything it needs to run, so the same package behaves identically on your laptop and in production.

An image is a stack of read-only layers. Understanding that one fact explains build caching, image size, and why deleted secrets are still in there.

You describe what you want running; Kubernetes keeps making reality match that description. Everything else is detail.

Both are key-value objects that decouple configuration from images. The only real difference is that a Secret is base64-encoded and handled slightly more carefully — it is **not** encrypted by default.

Helm is a templating engine plus a release ledger. Separating those two jobs in your head explains every Helm problem you will have.

An Ingress object is a set of routing rules that does nothing on its own. A **controller** has to be installed to read it — and "my Ingress is ignored" is almost always that it is not.

A Deployment is how you get zero-downtime updates: it never edits a running pod, it creates new ones and removes old ones in a controlled order.

A pod is not "a container" — it is a small group of containers that share an IP address and a filesystem, and always live and die together.

Pods get a new IP address every time they restart, so nothing can talk to them directly. A Service is the stable address that stays put.

Three commands solve most problems: `describe` tells you what Kubernetes thinks, `logs` tells you what the app said, `get endpoints` tells you why traffic is not arriving.

Autoscaling adds pods; the scheduler decides where they go; the cluster autoscaler adds machines when there is nowhere. Three separate systems, and most "autoscaling is broken" is really one of the other two.

kops treats a cluster as a declarative object stored in S3 — you edit the spec, then tell it to make reality match, which is exactly the Kubernetes model applied to the cluster itself.

Nothing in Kubernetes calls anything. Every component watches the API server for a gap between what you asked for and what exists, then acts to close it — and that single sentence explains the whole system.

Four object types and one rule: permissions are **purely additive**, there is no deny. If someone can do something they should not, you remove a binding — you cannot add a rule to stop them.

A PVC is a **request** for storage; a PV is the storage itself. You write the request, the cluster finds or creates the disk, and separating those two roles is what makes storage portable between clouds.

A Deployment assumes its pods are interchangeable. The other three workload types exist for the cases where they are not — because they have identity, because you need one per node, or because they are meant to finish.

You describe the infrastructure you want in files; Terraform works out the difference from what exists and makes only that change.

An availability target is only useful if missing it *changes what the team does* — otherwise it is a number in a slide deck, and everyone already knows it.

Grafana stores no data. It queries other systems and draws the answer — which is why "Grafana is broken" is almost always the datasource or the query.

Monitoring tells you **that** something is wrong. Observability is whether you can work out **why** without shipping new code — and the difference is what you can ask, not how many dashboards you have.

Prometheus does not receive metrics — it goes and fetches them, on a timer, and that one design decision explains almost everything else about it.

Almost nobody is rejected for not knowing a command. They are rejected for not being able to say *why*, and for having no method when the question has no clean answer.

The same knowledge scores a rejection or a staff offer depending on how it is framed — and framing is a skill you can practise in an afternoon.

The round that decides most offers, and the one people prepare least — because it is the only round where a confident guess scores worse than an honest method.

Grouped by what you are trying to find out, not alphabetically — because at 3am you know the question, not the flag.

Grouped by the question you are asking, because that is what you actually know when you need a command.