© Sarawuth Pamoon, 123RF

Calico wählt einen ungewöhnlichen Ansatz für Software Defined Networking und setzt massiv auf offene Standards wie BGP. Worin liegt der Unterschied zu anderen Lösungen, und welche Vorteile bietet Calico?

Zwar war früher längst nicht alles besser, aber viele Dinge waren viel übersichtlicher als heute. Netzwerke in Rechenzentren geben ein hervorragendes Beispiel dafür ab. Einst herrschte im RZ eine strikte Trennung: Admins kümmerten sich um ihre Linux-Systeme, Storage-Admins um ihre Netzwerkspeicher und Netzwerkadmins um ihre Router und Switches. Für einzelne Kunden baute man spezifische Setups auf eigener Hardware, richtete alles einmal ein, und fertig war der Lack.

In den vergangenen Jahren haben sich die Zuständigkeiten jedoch stark verschoben. Dafür ist maßgeblich die Cloud verantwortlich: Sie hat die Dienstleistung IT viel dynamischer gemacht, als sie es zuvor war. Kunden warten heute nicht mehr Wochen und Monate auf die Infrastruktur für ein Setup, sie wollen Storage und Compute sofort. Das macht IT-Anbieter zu Plattformbetreibern: Statt kundenspezifischer Setups betreiben sie eine generische Plattform aus Compute- und Storage-Ressourcen. Die konsumieren Kunden dann Stück für Stück.

Mit der aus der Vergangenheit gewohnten Trennung der Aufgaben ginge das aber nicht mehr: Noch ehe er es sich versieht, betreibt der Switch-Admin dumme Paketweiterleiter in einer komplett flachen Hierarchie. Die Netzwerkmagie spielt sich stattdessen auf der Kundenseite ab: Das Software Defined Networking stellt genau das sicher.

Calico ist innovativ

Calico tritt auf der Software-Seite an, um in virtuellen Umgebungen die Funktionen von klassischen Netzwerkgeräten zu ersetzen. Zwar steht das Projekt [1] keineswegs an der Spitze der SDN-Bewegung – andere Ansätze wie Open vSwitch glänzen mit einem höheren Dienstalter. Allerdings unterscheidet sich Calico grundlegend von den meisten anderen Lösungen: Es kommt ohne eine Verkapselungstechnik daher und setzt stattdessen auf Standard-Layer-3-Protokolle.

Parallel dazu hält Calico sich mit Versprechen kaum zurück: Besondere Sicherheit sowie native Kernel-Geschwindigkeit auf Linux-Systemen versprechen die Entwickler der Lösung. Grund genug, dem Produkt auf den Zahn zu fühlen: Wie funktioniert Calico? Für welche Einsatzzwecke eignet es sich grundsätzlich?

SDNs

Ein kleiner Ausflug in die Begrifflichkeiten und Funktionsweisen von Software Defined Networking hilft dabei, die zentrale Unique Selling Proposition von Calico zu verstehen.

Software Defined Networking ist längst kein homogener Ansatz mehr, und verschiedene Implementationsvarianten buhlen um die Gunst der Admins. Die Kernidee des SDN besteht darin, Netzwerkfunktionen aus typischer Netzwerk-Hardware auf die Software-Ebene und mithin auf die einzelnen Systeme zu verschieben.

Beispielhaft dafür steht die Trennung des Traffics unterschiedlicher Systeme: Auf Switches kommen dafür VLANs zum Einsatz, die diese Teilung im Layer 2 implementieren. De facto reicht SDN damit einen Teil der Virtualisierung nach, der bis zum Aufkommen erster Netzwerkkonzepte fehlte. RAM und CPUs waren lange schon virtualisierbar, als man physische Netze noch immer per Bridge-Interface in virtuelle Maschinen durchreichte.

In großen Umgebungen, wie Plattformanbieter sie betreiben, hilft das aber nicht weiter. Es wäre dort schlechterdings unmöglich, sämtliche Switches im System umzukonfigurieren, um einen neuen Kunden und dessen virtuelle Netze anzulegen. Stattdessen kümmert sich in einem komplett flachen Layer-2-Segment die SDN-Lösung selbst um das Problem.

Underlay und Overlay

Konventionelle SDN-Implementierungen teilen sich deshalb in ein Underlay und ein Overlay. Das Underlay ist das bereits beschriebene Layer-2-Segment. Das Overlay hingegen beschreibt die virtuelle Umgebung, innerhalb der die Pakete mit Payload-Traffic ihren Weg durch das Setup finden.

Fast alle gängigen SDN-Ansätze nutzen im Underlay Verkapselungslösungen wie GRE, VxLAN oder Geneve, um Datenverkehr aus dem Overlay von jenem im Underlay zu trennen. Durch die Verkapselung findet ein Paket dann seinen Weg von VM A auf Host 1 zu VM B auf Host 2. Eben jene Verkapselung sorgt aber im Kontext des Software Defined Networking regelmäßig für Ärger: Theoretisch sollte die Verkapselung keinen Einfluss auf die Performance haben, in der Praxis wirkt sie sich jedoch ganz erheblich aus.

Bekannt ist etwa Open vSwitch, das in früheren Versionen eine Art Paket-Multitron baute und Hosts auch gern einmal in ARP-Anfragen ersaufen ließ. Solche Schwachstellen haben die Entwickler zwar mittlerweile beseitigt, doch die Trennung in Overlay und Underlay samt damit einhergehender Verkapselung stößt bis heute vielen Admins ungut auf.

Auf Layer 3

Hier kommt Calico ins Spiel, das verspricht, auf diese Trennung zu verzichten. Stattdessen setzt es vollständig auf den Layer 3. Damit nutzt Calico ein Netzwerkkonzept, das bereits seit einiger Zeit existiert, das sich aber bisher kaum durchsetzen konnte: das Routing im Layer 3.

Zur Rekapitulation: Der Layer 2, die sogenannte Verbindungsschicht, hat unter anderem die Aufgabe, Pakete innerhalb eines physischen Netzes zu vermitteln. Er adressiert die Kommunikationspartner über die MAC-Adressen (Media Access Control) ihrer Netzwerkkarten. Layer 3, die Vermittlungsschicht, kümmert sich dagegen um die Paketweiterleitung über die Grenzen lokaler Netze hinweg. Hier ist das IP-Protokoll zu Hause, dessen Adressen dafür sorgen, dass sich weltweit bestimmte Netzwerkknoten in vollkommen verschiedenen Netzen ansprechen lassen. Als Gerät für die Paketweiterleitung dient in Layer 2 der einfache Switch, in Layer 3 der Router.

Als diese Arbeitsteilung Eingang in das OSI-Schichtenmodell fand, waren allerdings riesige Layer-2-Netzwerkverbünde, wie sie heute in Clouds mit Tausenden Servern vorkommen, noch nicht vorstellbar. Damals hilfreiche Erfindungen wie das Spanning-Tree-Protocol werden darin heute zum Problem. Einen Ausweg will das sogenannte Layer-3-Routing schaffen, indem es den Weg eines Pakets von Host zu Host ganz allein auf Grundlage der IP-Adressen bestimmt.

Das Perpetuum Mobile in einem solchen Setup ist das Border Gateway Protokoll (BGP). Jeder Router, der BGP spricht, kennt die Routen zu allen anderen Hosts des Verbunds. Ein Router muss dabei längst kein eigener Kasten mehr sein: Dienste wie Quagga, Bird und FRR laufen auf jedem Linux-Host, und jeder Standard-Switch der großen Hersteller beherrscht mittlerweile ebenfalls BGP.

So mutiert jeder Linux-Server zum kleinen Router, und entsprechend kennt jeder Server im Netz die Route zu jedem anderen Host. Die Relevanz der physischen Infrastruktur gerät faktisch ins Hintertreffen: Weil der ganze Traffic im Layer 3 geroutet wird, spielen die physischen Grenzen von Netzwerken keine Rolle mehr.

Weitergedacht

Mittlerweile existieren etliche Lösungen, die Teile des Konzepts nutzen oder miteinander kombinieren. EVPN etwa fußt im Kern ebenfalls auf BGP, verschiebt das Routing allerdings ganz auf die Switch-Ebene. Die einzelnen Hosts brauchen also keine BGP-Daemons mehr.

Selbst für echtes Layer-3-Routing bis hin zum Host gibt es vorgefertigte Anleitungen und Lösungen: Die Hosts nutzen dann die Unnumbered-Erweiterung von BGP, bei der nicht mehr jeder Host eine interne Autonomous System Number (ASN) benötigt. Die Konfiguration erfolgt weitgehend automatisch. Für Routing on the Host braucht es aber eben wieder Unterstützung in der SDN-Lösung, die der Admin in seiner Umgebung nutzt.

Genau hier kommt Calico ins Spiel – und weitet das Prinzip sogar noch aus. Im Grunde versteht Calico sich als SDN-Lösung, die das klassische SDN-Overlay nicht in Form von Verkapselung implementiert, sondern mittels BGP. Konkret dockt Calico auf der einen Seite an die jeweilige Virtualisierungslösung an, etwa an OpenStack (Abbildung 1) oder Kubernetes (Abbildung 2). Auf der anderen Seite spricht es dann BGP, um die Instanzen in der virtuellen Umgebung miteinander zu verbinden.

Abbildung 1: Calico unterstützt als SDN-Lösung sowohl OpenStack … Quelle: OpenStack

Abbildung 2: … als auch Kubernetes und etliche andere Lösungen. Quelle: Kubernetes

Eine herausgehobene Rolle spielt dabei das Thema Sicherheit: Weil eine Trennung des Traffics auf der Layer-2-Ebene wegfällt, wenn keine Verkapselung zum Einsatz kommt, muss Calico dieses Problem anders lösen. Die Entwickler halten sich streng an die Vorgabe, vorhandene Technologie so weit wie möglich zu nutzen. Entsprechend greifen sie auf die Filtermechanismen zurück, die Linux ohnehin mitbringt: Network Namespaces, Cgroups und Paketfilter.

Die Calico-Architektur

Wie im Cloud-Kontext mittlerweile üblich, steht Calico vor der Herausforderung, dass die Konfiguration nicht an der Stelle liegt, an der man sie braucht. Die meisten Cloud-Konzepte setzen die Existenz von Controllern voraus, die den Status sämtlicher Ressourcen der Umgebung enthalten. Die virtuellen Instanzen, ganz gleich ob Container oder echte VMs, laufen allerdings auf separaten Systemen. Dort muss die auf den Controllern hinterlegte Konfiguration irgendwie in die Praxis umgesetzt werden.

Calico folgt dieser Architektur (Abbildung 3) und fußt entsprechend auf einer Architektur aus Control Plane (auf den Controllern) und Agents (auf den Zielsystemen). Hinzu kommen mehrere Plugins für externe Lösungen wie OpenStack oder Kubernetes, die der Artikel im Folgenden kurz vorstellt.

Abbildung 3: Die Calico-Architektur (hier am Beispiel Kubernetes) ist simpel: Auf den Hosts läuft Felix, die Controller-Instanz hat die Aufsicht. Quelle: Project 9

Zentraler Datastore

Den Calico-Entwicklern ist es wichtig, dass ihre Software als Anwendung des Cloud-Zeitalters den gängigen Maximen moderner Entwicklung folgt. Daraus ergibt sich, dass Calico seine Konfigurationsdaten in einer zentralen Datenbank ablegt.

Dem Datenspeicher kommt in einer verteilten Lösung eine große Bedeutung zu: Er dient als Single Source of Truth, also als jene Instanz im Cluster, deren Datenbasis als korrekt und verbindlich für sämtliche clusterweiten Aktionen gilt. Die Calico-Entwickler hätten an dieser Stelle das Rad neu erfinden können, sinnvoll wäre das aber nicht gewesen. Leistungfähige Datenspeicher existieren mehrfach, zu den bekanntesten Implementierung zählen etwa Consul und Etcd. Letzteres ist dann auch eine der zwei Varianten, für die die Calico-Entwickler sich entschieden haben: Auf Wunsch legt Calico seine komplette Konfiguration in Etcd ab.

Das bringt mehrere Vorteile mit sich. Zum einen hat sich Etcd als robuster Consensus-Algorithmus für verteilte Systeme erwiesen, dem der Ausfall einzelner Knoten nichts ausmacht. Zum anderen ist Etcd selbst verteilt: Der in Go verfasste Dienst benötigt nicht viele Ressourcen und läuft auf den Hosts der Umgebung mit.

Weil eine Konfigurationsänderung in Etcd automatisch zu allen anderen Etcd-Instanzen propagiert wird, steht auf jedem Host stets die vollständige Konfigurationsdatenbank mit allen relevanten Parametern zur Verfügung. Der Agent auf den Zielsystemen erspart sich damit viel Netzwerktraffic, um bei einer zentralen Datenbank wie MySQL jene Werte abzufragen. Die Anbindung an Etcd eignet sich spezifisch für Setups mit konventionellen Virtualisierern wie OpenStack oder ganz ohne zentralen Steuermechanismus.

Confd als Anhängsel

Speziell für solche Setups kommt Calico übrigens auch mit einer eigens abgestimmten Version von Confd daher. Letzteres dockt im Hintergrund an Etcd an und holt sich von dort Konfigurationsdaten. Daraus generiert es dann auf den jeweiligen Systemen Konfigurationsdateien für solche Dienste, die ihre Konfiguration nicht direkt aus Etcd beziehen können. Faktisch ersetzt Confd dadurch einen Teil der Funktionalität von Puppet, Ansible und Konsorten, doch geht es dabei deutlich dynamischer vor.

Obendrein kann sich in Calico die Konfiguration einzelner oder aller Systeme kontinuierlich verändern. Wollte der Admin das händisch abbilden, müsste er mit Lösungen wie Inotify die relevanten Konfigurationsdateien überwachen, neu schreiben und danach dem Dienst, der sie nutzt, ein »SIGHUP« schicken. Confd in der Calico-Variante nimmt dem Admin all diese Aufgaben im Hinblick auf die eigenen Belange ab.

Variante B: Kubernetes

Etwas anders liegen die Dinge, wenn Kubernetes zum Einsatz kommt. Zwar ist Calico auch und explizit für Kubernetes konzipiert, doch kommt der Container-Manager mit eigenen Controller-Diensten daher, die die benötigten Konfigurationsdaten ja schon enthalten. Hier erwächst Calico zum Vorteil, dass seine Entwickler die Anbindung an den Datastore modular gebaut haben: Anstelle des Moduls für Etcd kann Calico so ein Modul für Kubernetes laden und im Anschluss direkt mit der Kubernetes-API kommunizieren.

Wer mit Calico viele Kubernetes-Instanzen versorgen will, bekommt dafür von den Entwicklern sogar Schützenhilfe: Typha ermöglicht es, eine Instanz von Calico samt Datastore in die Breite zu skalieren. Kubernetes redet dann nur noch indirekt mit Calico – durch Typha hindurch, das als eine Art Cache fungiert. Diese Architektur erlaubt es dem Admin, mit einer Calico-Instanz riesige Umgebungen auf Kubernetes-Basis zu bespielen, ohne den Vorteil eines Single Point of Administration zu verlieren.

Intelligenz im Controller

Eine zentrale Bedeutung hat bei Calico dessen Controller. Hier ist begriffliche Abgrenzung nötig: Der Datastore enthält zwar Angaben zur Konfiguration – aber im Wesentlichen zur Konfiguration, die auf den Zielsystemen letztlich implementiert sein muss.

Der Calico-Controller zeichnet dafür verantwortlich, diese Konfiguration in Calico-Sprache zu übersetzen. Erst dadurch entsteht auf den Zielsystemen das Zusammenspiel aus Interfaces, Namespaces, Iptables und BGP-Daemon, das die Calico-Konfiguration erfordert. Die Control Plane liest die gewünschte Konfiguration also auf der einen Seite ein und wandelt sie auf der anderen Seite in eine konkrete Systemkonfiguration um.

Das Pendant zur Calico-API auf den Zielsystemen ist Felix, der Calico-Agent: Er empfängt Anweisungen von der Calico-Control-Plane und legt die entsprechende Konfiguration auf dem System an. Das geschieht idempotent: Solange das System mit derselben Konfiguration in der Control-Plane hinterlegt ist, stellt Felix auf dem Server auch zuverlässig dieselbe Konfiguration her – und verteidigt sie gegebenenfalls gegen jegliche externe Eingriffe.

Bird und Iptables

Auf den Zielsystemen erledigt Felix mehrere Arbeiten. Für echtes Routing-on-the-Host braucht es freilich einen BGP-Daemon. Die Wahl der Entwickler fiel hier auf Bird, das etwas moderner daherkommt als Quagga und den BGP-Standard zusammen mit einigen Erweiterungen implementiert. Obendrein konfiguriert Felix über seine eingebaute Policy-Engine auch den Paketfilter Iptables.

Die Calico-Website wirbt ausdrücklich damit, dass Calico mit einer Vielzahl von Flottenvirtualisierern funktioniert. Wie fast überall in der hippen IT-Welt liegt der primäre Fokus beim Calico-Projekt in letzter Zeit aber klar auf Kubernetes. Das lässt sich einerseits daran erkennen, dass dem Thema Kubernetes in der Calico-Dokumentation deutlich mehr Platz zukommt als dem Deployment auf anderen Plattformen. Andererseits sprechen auch die Komponenten in Calico eine klare Sprache, die explizit die Nutzung mit Kubernetes anvisieren.

Entsprechend gut performt Calico im Kubernetes-Kontext: Es implementiert insbesondere eine CNI-Schnittstelle, also das Container Networking Interface, das Containern die Nutzung von Netzwerkschnittstellen nach festgelegten Kriterien erlaubt.

Calico als Profiler

Einen Kernaspekt seiner Arbeit sieht Calico darin, überhaupt eine Verbindung zwischen mehreren Kommunikationspartnern zu etablieren. Ein zweites, sehr wichtiges Thema ist komplementär dazu die Sicherheit: Weil es in Calico keine Trennung in Overlay und Underlay gibt, fallen selbst die grundlegenden Techniken der Verkapselung weg, um Traffic unterschiedlicher Herkunft voneinander zu trennen.

Alles nimmt dieselben Pfade über dieselben Netzwerkschnittstellen. Für die Absicherung der Verbindung muss entsprechend das in Linux vorhandene Bordwerkzeug zum Einsatz kommen. Und hier haben sich die Entwickler etwas Schlaues überlegt: Calico nutzt Profile (Abbildung 4), also vorher angelegte Standardkonfigurationen für bestimmte Sicherheitseinstellungen, und kann diese situationsbezogen einsetzen.

Abbildung 4: Über Profile setzt Calico seine Security-Guidelines in die Tat um; mit Lösungen wie Kubernetes kooperiert es dafür direkt.

Ein einfaches Beispiel könnte etwa ein Calico-Profil für einen Webserver sein, der in einem Container läuft: Ports wie 80 und 443 wären hier erlaubt, darüber hinaus stünden aber keine Ports offen. Sein volles Potenzial entfaltet der Ansatz zudem, wenn Calico sich an die Sicherheitsvorgaben des Orchestrierers anhängt, mit dem es zusammenarbeitet: Kubernetes kann Calico etwa automatisch sagen, um welche Art von Container es sich beim Deployment handelt, und Calico wählt auf dieser Basis dann automatisch das passende Profil aus.

Automatische Verschlüsselung

Besonders interessant erscheint in Calico im Security-Kontext außerdem ein Feature, das bisher nur als Technology Preview vorliegt, von den Entwicklern also noch nicht für den produktiven Einsatz freigegeben ist: die automatische Transportverschlüsselung.

Dazu muss man wissen: Viele Admins verzichten innerhalb ihrer Setups auf den Einsatz von SSL, weil sie schlicht davon ausgehen, ihr Netz sei schließlich sicher und vor Eindringlingen geschützt. Diesem Ansatz allerdings stehen die Calico-Entwickler sehr kritisch gegenüber, und das aus gutem Grund: Immer häufiger zeigt sich, dass Angreifer sich in Netzen über Monate hinweg vollständig unbemerkt ausbreiten und mitlesen. Dem Konzept des lokalen Netzes als Security-Domäne sagt Calico deshalb den Kampf an.

Die Idee: Wenn man sich per IP und BGP ohnehin die Kontrolle darüber verschafft, welchen Weg Pakete zwischen den Hosts nehmen, lässt sich auch eine Transportverschlüsselung transparent in diesen Prozess integrieren. Im Grunde erinnert das an Lösungen wie Istio, die ähnliche Features in der Cloud für ihre Container implementieren. Bei Calico erstreckt sich die Funktion aber eben auch auf den physischen Layer 3.

Der Admin müsste in solchen Situationen dann nicht mehr darauf achten, dass seine Dienste SSL überhaupt beherrschen, und hätte trotzdem durchgängige Transportverschlüsselung im Netz. Noch ist das zwar Zukunftsmusik, aber Calico wird das Feature früher oder später in die Produktion übernehmen.

Erweitertes Zusammenspiel

Insgesamt erweist Calico sich als vielseitige SDN-Lösung, die im direkten Vergleich mit Open vSwitch und ähnlichen Lösungen erfrischend neue Ansätze verfolgt. Und noch eine weitere Eigenschaft macht die Lösung sympathisch: Calico bietet über seine API auch für andere Netzwerklösungen direkte Anknüpfungspunkte. Exemplarisch dafür steht Istio (Abbildung 5), das mit Calico praktisch gemeinsame Sache macht.

Abbildung 5: Istio und Calico sind für Container-Netze quasi ein Dream-Team: Calico stellt die L3-Verbindung her, Istio nutzt sie dynamisch. Quelle: Tigera

Zur Erinnerung: Nicht nur für den Administrator gestaltet sich beim Umzug in die Cloud das Thema Netzwerk viel komplexer als vorher. Zwar muss der Admin sich mit SDN und Co. beschäftigen und seine Cloud so vorbereiten, dass entsprechende Dienste dort zur Verfügung stehen. Hat er das aber einmal erledigt, braucht er dem Thema nur noch dann Aufmerksamkeit zu widmen, wenn etwas nicht wie gewünscht funktioniert. Der Entwickler hingegen hat es mit einem viel komplexeren Netzwerk zu tun als zuvor.

Komplizierte Mikroarchitektur

Mit der physischen Cloud geht der Wunsch einher, deren Dienste optimal zu nutzen. Das Prinzip der Cloud-Ready-Anwendungen sieht daher vor, dass es sich bei Programmen für die Cloud immer auch um verteilte Programme handelt.

Die Verteilung lässt sich nach gängiger Lehrmeinung idealerweise durch Dienste auf Basis der sogenannten Mikroarchitektur realisieren. Statt Monolithen bauen Entwickler dieser Tage also Anwendungen, die aus diversen Einzelteilen bestehen und über definierte API-Schnittstellen miteinander kommunizieren. Es genügt aus Sicht des Entwicklers also nicht mehr, eine Applikation auszurollen: Stattdessen muss er sich Gedanken über die Frage machen, wie er die Kommunikation zwischen den Komponenten seiner Applikation abhärtet – sowohl im Hinblick auf zuverlässige Funktion als auch im Hinblick auf Sicherheit.

Istio richtet sich speziell an Entwickler mit diesem Problem und verspricht den Aufbau eines Full-Mesh-Netzes zwischen den Komponenten einer Applikation, die der Microservices-Lehre folgt. Load Balancer, Firewall-Regeln und Routing sind auch hier also wieder relevante Themen. Da liegt es nur nahe, dass die Entwickler von Istio und Calico eng zusammenarbeiten.

Zugriff auf alle Details

In der Praxis sieht das konkret so aus, dass Istio sich direkt mit den Calico-Diensten verbindet und von dort den größten Teil der Parameter bezieht, die es für die eigene Konfiguration braucht. Ändert sich im laufenden Betrieb das Netz, passt Istio sich auf Basis der empfangenen Daten automatisch selbst an.

Es leuchtet ein, dass es eine gute Idee ist, die SDN-Anwendung in der Cloud und Mesh-Lösungen wie Istio unmittelbar miteinander zu verknüpfen. Calico und Istio machen eindrucksvoll vor, wie das aussehen kann.

Fazit

Riesige Layer-2-Netzwerke bereiten Admins oft schlaflose Nächte und gehören eigentlich in die Mottenkiste der IT: Mittlerweile stehen mehr als genug mögliche Alternativen zur Verfügung.

Calico beweist, dass Router-on-the-Host einen validen Ansatz darstellt, der gut funktioniert. In komfortabler Art und Weise realisiert es Netzwerke für Cloud-VMs und Container, ohne den Overhead der Verkapselung oder anderer Mittel im Schlepptau zu haben. Seine Vorliebe für Kubernetes kann es dabei nicht verbergen, funktioniert aber auch mit anderen Orchestrierern gut. Wer eine vielseitige SDN-Lösung fernab von Open vSwitch und Konsorten sucht, sollte sich Calico genauer ansehen. (jcb/jlu)