Der heutige Tag ist ein spannender und wichtiger Meilenstein in der Produktentwicklung bei Juniper Networks. Im Laufe der letzten beiden Jahre hat unser Engineering-Team unser Produkt Contrail Networking unter dem Projektnamen „CN2“ komplett umgestaltet. Zwar könnte man annehmen, CN2 sei die Abkürzung für die zweite Version von Contrail, aber tatsächlich steht das Kürzel für „Cloud-Native Contrail Networking“. CN2 war nur einfach griffiger als CNCN oder CN2.
Mit CN2 und Contrail 22.1 bringt Juniper eine moderne, Kubernetes-native Architektur auf den Markt, die die automatisierte Skalierbarkeit einer extrem leistungsfähigen, Cloud-nativen Netzwerklösung mit den effizienten DevOps-Prozessen auf Hyperscaler-Niveau vereint. Und nicht zu vergessen: CN2 ist speziell auf die Vernetzung von Kubernetes- und OpenStack-Anwendungen ausgelegt, um beide Welten miteinander zu verbinden.
Was ist neu? Schwerpunktverlagerung von OpenStack auf Kubernetes
Ich war dabei, als Juniper im Jahr 2012 Contrail Systems übernahm und 2013 das erste Produkt der Contrail-Familie auf den Markt brachte. In dieser Zeit – und insbesondere zu Beginn der Contrail-Ära im Jahr 2012 – wurde Contrail als Problemlösung für skalierbares SDN für die Anwendungsbereiche IaaS (Infrastructure as a Service) und NFV (Network Functions Virtualization) mit OpenStack als Orchestrator angesehen. Seit 2015 hat Kubernetes radikal verändert, wie wir Anwendungen entwickeln und ausführen – und in jüngster Zeit auch die Verwendung von VMs beeinflusst.
Kubernetes ist schon seit einiger Zeit weiter verbreitet als OpenStack. Uns war bewusst, dass wir wichtige moderne Funktionalität in CN2 integrieren mussten, um unseren Kunden die Nutzung von Kubernetes und OpenShift zu erleichtern, ohne die Unterstützung von OpenStack zu vernachlässigen, damit Kunden, die beide Umgebungen nutzen (oder dabei sind, auf Kubernetes umzustellen), weiterhin dieselbe erstklassige Nutzererfahrung erhalten.
CN2 ist also eine auf Kubernetes ausgerichtete und vor allem eine Kubernetes-native Lösung.
Was hat sich geändert? CN2 als Kubernetes-native Umgebung
Bei der Weiterentwicklung von Contrail ging es nicht nur darum, Cloud-native Anwendungen und das Kubernetes-Ökosystem zu unterstützen. Vielmehr handelt es sich um eine grundlegende Optimierung für alles, was mit Kubernetes zu tun hat – CN2 ist im Prinzip eine Erweiterung von Kubernetes.
CN2 fungiert unter anderem als Kubernetes-CNI (Container Network Interface) und wird als grundlegender Bestandteil der Cluster-Infrastruktur integriert (mithilfe des Kubernetes-Erweiterungs-Frameworks aus maßgeschneiderten Ressourcen). Damit wird nun jede Komponente von CN2 genau wie bei Kubernetes bereitgestellt. Kunden können kubectl, K9s oder jedes andere beliebige Kubernetes-Tool verwenden. Wir haben außerdem ein Contrail-Plug-in für Lens, das beliebte Dashboard von Kubernetes, hinzugefügt. So lässt sich die API von CN2 nun über die native rollenbasierte Zugriffskontrolle von Kubernetes und die entsprechenden Systeme für das Identitäts- und Zugriffsmanagement (IAM) integrieren. Ein weiteres Plus: CN2 ist nun als Codekonfiguration verfügbar – für die einfache Nutzung mit GitOps, IaC (Infrastructure as Code) und CI/CD. Darüber hinaus gibt es nun Contrail-Pipelines auf der Basis von Argo CD und Argo Workflows, also einsatzbereite CI/CD-Prozesse für die SDN-Funktionalität von Contrail wie die neuen Testsuites von Juniper.
CN2 wurde im Gegensatz zu den früheren Open-Source-Versionen von Contrail (21.4 und davor) als Closed-Source-Software konzipiert und Interessenten können eine kostenlose Testlizenz von Juniper anfordern.
Was ist gleich geblieben? Skalierbarkeit, Leistung und Open Networking
Das Konzept einer CNI (Container Network Interface) ist eine stark reduktionistische Sichtweise von Contrail in Bezug auf Kubernetes. Contrail bietet eine große Vielfalt an SDN-Funktionen, darunter Sicherheitsrichtlinien für die Mikrosegmentierung, Sicherheitsfunktionen für die Namespace-Isolierung, am Eingang implementiertes Load Balancing, natives Load Balancing für extern zugängliche Microservices, Datenverkehrsspiegelung, Routing-Richtlinien, native BGP-Unterstützung, virtuelle Netzwerktopologien und virtuelle Netzwerke – die alle mit oder ohne Overlays genutzt werden können (wobei die Verwendung von Overlays empfohlen wird).
Im Rahmen dieses Artikels können wir natürlich nicht auf alle der zahlreichen Netzwerkfunktionen für Unternehmen, Cloud- und Serviceanbieter eingehen, aber wir werden in unseren technischen Blogs und Demovideos sämtliche Funktionen näher besprechen, die CN2 zu bieten hat. Halten Sie also Ausschau!
Es ist kein Geheimnis, dass Kubernetes oft in der Cloud ausgeführt wird. Auch für Contrail war die Cloud kein Problem – Juniper bietet viele solcher Bereitstellungen. Dennoch ist die Ausführung von CN2 in einer selbstverwalteten Bare-Metal-Cloud eine richtungsweisende Innovation für private Datencenter, insbesondere weil das einfache, auf offenen Standards basierte Föderationsmodell von CN2 es möglich macht, virtuelle Netzwerke vom logisch zentralisierten Controller mit anderen CN2-Controllern (und vor allem mit BGP-basierten Controllern) zu verbinden. Dabei spielt es keine Rolle, ob es sich um Hardware von Juniper oder von anderen Anbietern handelt. On-Premises-Bereitstellungen ermöglichen Kunden zudem die Nutzung von SmartNICs, um eine besonders hohe Leistungsfähigkeit zu erzielen.
Gut, besser, am besten
Nicht nur Multicloud-Architekturen ändern sich, sondern auch Multi-Kubernetes-Umgebungen, und zwar auf zweierlei Weise: durch die Anzahl der Cluster und die Art der Kubernetes-Distributionen.
Viele Unternehmen haben in der Vergangenheit Kubernetes-Serivces sowohl in der Cloud als auch in Form von selbstverwalteten, bereitgestellten Distributionen genutzt. CN2 ist nach wie vor eine hervorragende SDN-Lösung, da es all diese hybriden Kubernetes-Konstellationen unterstützt (einschließlich OpenShift und OpenStack) und sowohl eine nahtlose Interkonnektivität als auch eine durchgängige Nutzererfahrung sicherstellt.
Hier lohnt sich ein Blick auf den Begriff KubeSprawl, der eine große Anzahl von Kubernetes-Clustern bezeichnet (anstelle eines großen gemeinsamen Clusters), die durch die Erstellung eigener Cluster für jeden Orchestrator entstehen. Die erfreuliche Nachricht ist, dass Multicluster-Kubernetes-Umgebungen zu den Stärken von CN2 zählen.
Contrail ist seit je her auf Skalierbarkeit, Sicherheit und robuste Mehrfachmandantenfähigkeit ausgelegt, weshalb es sich so gut für große Mehrzweck-, teamübergreifende und gemeinsam genutzte Cluster eignet. Doch nun da viele Unternehmen den entgegengesetzten Weg einschlagen und zahlreiche kleine Cluster bereitstellen (für jedes Team, jede Anwendung, für die Entwicklung, zum Testen, für die Bereitstellung und die Produktion), hilft CN2, das SDN „aufzuräumen“ und diese Cluster-Vielfalt in Einklang zu bringen. CN2 kann für einen einzelnen Haupt-Cluster ausgeführt werden und als CNI für diesen und viele weitere Cluster dienen. CN2 kann darüber hinaus Analysen für mehrere Cluster zusammenführen. Und obwohl CN2 ein bekanntermaßen gutes Föderationsmodell bietet, ist die Zusammenführung von Clustern keine Voraussetzung für ein nahtloses virtuelles Netzwerkmanagement und die reibungslose Verwaltung von Sicherheitsrichtlinien.
Ein weiterer Vorteil von Kubernetes im Vergleich zu OpenStack ist die einfache Bereitstellung. Kubernetes kann in privaten und öffentlichen Clouds sowie in Bare-Metal-Umgebungen verwendet werden und ist auch für kleine Bereitstellungen mit einem einzigen Knoten geeignet. Vor diesem Hintergrund war uns klar, dass wir Nutzern das Testen von CN2 erleichtern mussten – und das geht mit dem minikube-Tool auf einem Laptop in Minutenschnelle. Mit Juniper kann jede Bereitstellung gestrafft und ressourcenschonend ausgeführt werden, denn Protokollierung, System- und Netzwerkanalysen sowie datenstrombasierte Telemetriedaten sind optional.
Damit haben die Produkt- und Entwicklungsteams von Juniper eine enorme Leistung erbracht, die eine innovative Contrail-Version und ein neues Zeitalter für CN2 einläutet.
Weitere Ressourcen
