Text size
Ausprobiert & getestet7 Min. Lesezeit

Netzwerkbasierte Grundlagen, die jeder DevOps-Ingenieur braucht

DNS, TLS, Lastbalancer und Subnetze, erklärt, wie ich wünschte, jemand hätte es mir erklärt.

Networking basics every DevOps engineer needs
KI-generierte Illustration

Wenn ich auf die schwierigsten Probleme zurückschaue, die ich debuggt habe, waren eine überraschende Anzahl Netzwerkprobleme in Verkleidung. "Die App ist langsam" stellte sich als DNS heraus. "Die Einführung scheiterte" stellte sich als Sicherheitsgruppe heraus. "Kubernetes ist kaputt" stellte sich heraus, dass sich IP-Bereiche überschneiden.

Man muss kein Netzwerkingenieur sein, um in DevOps zu arbeiten. Aber man braucht ein solides mentales Modell, wie Pakete von A nach B gelangen. Das ist die Version, die ich mir gewünscht hätte.

Die Schichten, die wichtig sind

Sie werden von dem OSI-Modell mit sieben Schichten hören. In der täglichen DevOps-Arbeit sind vier Ideen am wichtigsten:

  • IP (Schicht 3): Jeder Computer hat eine Adresse, und Router entscheiden, wie Pakete von einem Netzwerk zum anderen gelangen.
  • TCP und UDP (Schicht 4): TCP liefert zuverlässige, geordnete Verbindungen (meist Webverkehr). UDP ist Feuer-und-Vergessen (DNS, Video, einige neuere Protokolle wie QUIC). Die Ports geben an, welche Anwendung auf einer Maschine den Datenverkehr empfangen soll.
  • TLS: Verschlüsselung auf TCP. Das ist, was das "S" in HTTPS setzt.
  • HTTP (Schicht 7)Die meisten unserer Dienste sprechen über das Anwendungsprotokoll.

Wenn etwas nicht funktioniert, gehe ich die Schichten hoch: Kann ich die IP erreichen? Ist der Hafen geöffnet? Funktioniert TLS? Gibt HTTP die richtige Antwort zurück?

IP-Adressen und Subnetze

Eine IP-Adresse wie 10.0.12.34 gehört zu einem Unternetz, geschrieben in CIDR-Notierung: 10.0.0.0/16 bedeutet "alle Adressen, bei denen die ersten 16 Bits 10.0"was 65.536 Adressen sind.

  • /16: 65.536 Adressen
  • /20: 4,096
  • /24: 256
  • /28: 16

Privatbereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) werden innerhalb von Netzwerken verwendet und sind nicht direkt über das Internet erreichbar. NAT (Network Address Translation) ermöglicht es Maschinen mit privaten Adressen, über eine gemeinsame öffentliche Adresse ins Internet zu gelangen.

Der häufigste Fehler, den ich sehe: Überlappende Bereiche- Ich weiß . Zwei VPC, die beide 10.0.0.0/16 kann nie verbunden werden. Kubernetes-Pod und Servicebereiche, die sich mit Ihrem Büro-VPN überschneiden, verursachen mysteriöse Ausfälle. Planen Sie IP-Bereiche in der Mitte, früh.

DNS-Daten

DNS übersetzt Namen (shop.example.com) in die Adressen. Es ist in fast jeder Anfrage involviert, weshalb "es ist immer DNS" ein laufender Witz ist.

Schlüsselbegriffe:

  • A / AAAA-Datensätze: Name der IPv4 / IPv6-Adresse.
  • NAME: ein Alias, der auf einen anderen Namen hinweist.
  • TTL: wie lange Resolver eine Antwort speichern. Niedrige TTLs führen zu schnellen Änderungen; hohe TTLs reduzieren die Belastung und Abhängigkeit von DNS.
  • AuflösungsgeräteDie Server, die nach Namen für Sie suchen. In Kubernetes ist das CoreDNS.
dig shop.example.com +short
dig shop.example.com +trace     # follow the lookup from the root servers

Wenn etwas mit IP funktioniert, aber nicht mit Namen, dann ist es DNS. Wenn es manchmal funktioniert, aber nicht immer, ist es wahrscheinlich auch DNS.

TLS und Zertifikate

TLS macht zwei Dinge: Verschlüsselung Verkehr und Identitätsnachweis- Ich weiß . Der Server stellt ein Zertifikat vor, das von einer Zertifizierungsstelle (CA) unterzeichnet ist, der der Client vertraut, und besagt: "Ich bin shop.example.com".

Häufige Probleme:

  • Verfallene Zertifikate: automatische Erneuerung (Cert-Manager, Let's Encrypt, Cloud-Zertifikatsmanager).
  • Name-Missmatch: die Bescheinigung ist für www.example.comAber du hast angerufen . example.com.
  • Fehlende Zwischenbescheinigungen in der Kette.
  • Interne Zertifizierungsstellen - dass Kunden nicht vertrauen.
openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null | openssl x509 -noout -dates -subject

Lastgleichgeräte

Ein Lastbalancer verteilt den Datenverkehr über mehrere Backends und verbirgt Ausfälle:

  • Schicht 4 (TCP/UDP) Lastbalancer, Anschlüsse nach vorne, ohne nach innen zu schauen. Schnell und einfach. Beispiel: AWS Netzwerk-Lastenausgleich.
  • Schicht 7 (HTTP) Lastbalancer verstehen Anfragen: sie können nach Pfad oder Host routen, TLS beenden, Header hinzufügen. Beispiele: AWS-Anwendungslastgleichgerät, Envoy, NGINX, Kubernetes Gateway API-Implementierungen.

Sie verlassen sich auf Gesundheitskontrollen um zu wissen, welche Backends gesund sind. Ein falscher Gesundheitscheck ist ein sehr häufiger Grund für "all Backends ungesund".

Entwurf eines Netzwerks in der Cloud

Ein typisches VPC-Design:

  • Öffentliche Teilnetze: für Lastbalancer und NAT-Gateways. Haben Sie eine Route zum Internet-Gateway.
  • Privates Teilnetz: für Anwendungen und Kubernetes-Knoten. Erreichen Sie das Internet über NAT, nicht direkt von außen erreichbar.
  • Datenunternetze: für Datenbanken, die nur von den Anwendungsunternetzen aus erreichbar sind.
  • Verbreitung auf Verfügbarkeitszonen, also eine Zone versagt, bringt dich nicht runter.
  • Sicherheitsgruppen (stateful, verbunden mit Ressourcen) als Hauptfirewall und Netzwerk-ACLs (stateless, pro Subnetz) nur bei Bedarf.

Lassen Sie Raum für Wachstum: Geben Sie Ihrem VPC eine große Bandbreite und Kubernetes viele Pod-IPs, insbesondere mit CNIs, die VPC-Adressen an Pods zuweisen.

Meine Debugger-Tools

Frage Werkzeug
Was ist meine IP und Route? ip a, ip r
- Ist der Name klar? dig, nslookup
Ist der Gastgeber erreichbar? ping, mtr
Ist der Hafen geöffnet? nc -zv host port
Was hört vor Ort? ss -tulpn
Funktioniert HTTP/TLS? curl -v
Was ist eigentlich auf dem Abhör? tcpdumpWireshark , du bist ein guter Kerl .

Und noch eine Frage , die viel Zeit spart: Woher kommt er? - Test ich das? Ihr Laptop, eine Kapsel, ein Knoten und ein Informanten-Laufwerk können alle sehr unterschiedliche Netzwerke sehen.

Also, wo fange ich an?

Lernen Sie CIDR, bis sich das Subnetzen natürlich anfühlt, verstehen Sie, wie DNS-Auflösung in Ihrer Umgebung (insbesondere in Kubernetes) funktioniert, und üben Sie das Debugging mit dig, nc, curl und ss- Ich weiß . Diese Grundlage wird Ihnen unzählige Stunden sparen.

Meine Meinung: Netzwerke sind keine Magie, sondern nur Schichten. Lerne sie einzeln zu überprüfen, und die meisten Rätsel lösen sich von selbst.

Desly