Kubernetes is a system that runs containers on a group of machines and makes sure that exactly what has been described is running. It sounds simple, but behind that phrase lies a change in how you think about servers: instead of "log in to a machine and start a process", the administrator writes down what the state should be, and from then on dozens of independent loops in the cluster bring the world in line with that description and keep it that way. This part is about where this model came from, how the reconciliation loop works, how declarative management differs from imperative management, and what Kubernetes does not do, even though people often expect it to. There aren't many commands here: we'll set up the lab cluster in part 4, and at the end of this part we'll look at how everything described looks on it.
The series is aimed at readers who know Linux and networking. The network protocols the cluster relies on are covered in the "Networking for beginners" series — for example, VXLAN, which the network plugin uses to connect the nodes, is described in its part 18 — and there will be links to it wherever they're needed. A highly available control plane on three masters with BGP is the subject of a separate series, "Highly available Kubernetes on BGP"; the cluster here is simpler — one master and two worker nodes — but each of its components is examined in detail.
The DHCP protocol for IPv4 — the four messages Discover, Offer, Request, Ack, the option format, lease renewal and relaying — is covered in part 11 of the networking series. Here we're talking about the server side in a domain: how the DHCP Server role works in Windows, how a server in a domain differs from a server in a router, how two servers share one scope without conflicts, and how they register client names in DNS without breaking the secure updates from the previous part.
In a domain DHCP is traditionally installed on the controllers: these are two services that need the same availability and together take a few dozen megabytes of memory. We'll do the same in the lab: now on dc1, and in the second half of the part on dc2, once it appears in part 10. If the organization has dedicated infrastructure servers, DHCP goes there, and everything below stays the same except for one point about the DnsUpdateProxy group.
How the DNS protocol itself works — the name tree, recursive and authoritative servers, record types, TTL — is covered in part 12 of the networking series, and we won't repeat it here. This part is about what Active Directory does with DNS: how a zone turns into directory objects, who registers records in it and how, where the server sends queries about other people's names, and which settings distinguish a domain controller's DNS from DNS running on Linux.
A reminder of why a controller is almost always a DNS server as well. Clients find controllers by SRV records (part 3), and controllers register these records themselves and refresh them every hour. A DNS server that accepts such updates, checks who sent them and replicates the zone along with the directory, requiring neither zone transfers nor separate configuration, is the Windows DNS server with a zone in Active Directory. You can keep the domain zone on BIND, and that's supported, but then dynamic updates, record permissions and replication have to be configured by hand.
A search engine learns about a new page on a site in two ways: it finds it by following links while crawling, or it reads sitemap.xml. Both work on the search engine's schedule: it decides by itself when to visit the site next. For a small blog that means days, sometimes weeks. The new article is already published, but it isn't in search results.
IndexNow turns this around: instead of the search engine asking the site, the site tells the search engine. The protocol was created by Microsoft (Bing) and Yandex in 2021; today it is supported by Bing, Yandex, Naver, Seznam and a few other search engines. Google doesn't take part in the protocol and still learns about pages from the sitemap.
A single PostgreSQL server is fine right up to the day the hypervisor underneath it reboots for updates, taking down with it every application that keeps its databases on that server. This article is about building a PostgreSQL cluster out of three machines that survives the loss of any one of them on its own, without an administrator at the console: what parts it consists of, how they are installed on Ubuntu, what happens on failure, how to test it, how to back it up and how to maintain it afterwards. And separately, about the pitfalls I ran into while building such a cluster: some of them cost hours if you don't know where to look.
All names and addresses in the article are made up: the domain example.com, nodes db1, db2, db3 with addresses 192.0.2.11–192.0.2.13, the floating address 192.0.2.10. The operating system is Ubuntu 26.04 LTS, whose repository ships PostgreSQL 18, Patroni 4.1 and etcd 3.5; all commands in the article are run as root or via sudo.
Kerberos was invented at MIT in the 1980s for Project Athena: thousands of workstations, dozens of servers, and none of them could be trusted with a user's password. The solution was a trusted third party that knows the keys of all participants and issues them tickets: encrypted credentials with a limited lifetime that can be presented to a service instead of a password. Version 5 of the protocol is described in RFC 4120; Microsoft adopted it in Windows 2000 as the main domain authentication and added its own extensions, described in MS-KILE and MS-PAC. Since then every domain logon, every opening of a network folder and every LDAP request to a controller starts with Kerberos.
In the previous part we saw in Wireshark how an LDAP connection became unreadable after the SASL bind. Today we'll take apart exactly what happened there: message by message, field by field and key by key.
Everything that reads or changes the directory — the Active Directory Users and Computers snap-in, the PowerShell module, Exchange, sssd on Linux, a ticketing system that's "integrated with AD" — talks to the controller over LDAP. Active Directory is an LDAP server: version 3, per RFC 4510–4519, with Microsoft extensions described in the open MS-ADTS specification. Snap-ins show the directory edited and translated; LDAP shows it as it is. In this part that's exactly how we'll look at it, and it's the only part of the series where graphical tools — ldp.exe and ADSI Edit — aren't a side note but the subject: they show the raw directory, and next to each of their actions we'll put the same operation in PowerShell.
The second half of the part is about what in the directory breaks after a careless edit and can't be fixed by rolling back. The directory stores both data and its own configuration, and the configuration is protected from the administrator no better than the data.
In the previous part we went through what a forest, a domain, directory partitions and the global catalog are. Today all of it will appear on the disk of the dc1 server we prepared in part 1. Promoting a server to a domain controller is a ten-minute, one-command operation, but in those ten minutes almost everything changes: the local account database disappears, and a directory database, DNS zones, shared folders and six new services appear. Let's go step by step and look at each one.
Four years ago I wrote about setting up your own IKEv2 VPN on strongSwan, and that article is still one of the most read on this blog. Since then IKEv2 has got a competitor that does the same job noticeably more simply: WireGuard. Where strongSwan needs a certificate authority, certificates, a choice of algorithms and three configuration files, WireGuard gets by with a pair of keys and ten lines. Today: how to set up such a server on Ubuntu from scratch and connect Windows and Android to it.
What a VPN is in terms of interfaces and routes, how a full tunnel differs from a split one, and where DNS and IPv6 leaks come from is covered in part twenty of "Networking for beginners". None of that is repeated here, but everything that comes up along the way is explained on the spot. How the WireGuard protocol works inside — the handshake, the cryptography, the packet format — you don't need to know to configure it, and this article doesn't cover it.
The addresses in this article are documentation addresses: the server is 203.0.113.10 and 2001:db8::10, the tunnel network is 10.66.66.0/24. Keys are placeholders in angle brackets.
Before Active Directory, every Windows server had its own account database — the SAM, Security Account Manager — and a user with ten servers had ten passwords. Windows NT domains solved half of this: one server, the PDC, held the database, and the other controllers, BDCs, received a read-only copy, while the database remained a flat list of names capped at 40 thousand entries with no structure at all and a proprietary protocol for everything. In Windows 2000 Microsoft replaced it with a directory built from open standards: the data lives in an LDAP directory, authentication is done by Kerberos, servers are found through DNS, and replication runs between equal controllers with no single master. That is how Active Directory came to be, and in 26 years its design has hardly changed.
There are no commands that change anything in this part: before running Install-ADDSForest in the next one, you need to understand what this command will create. We'll go through the directory from top to bottom: the logical structure, objects, partitions, files on disk, and at the end, the protocols all of it speaks.