Behälter. Es handelt sich dabei nicht um eine Modeerscheinung oder Phase. Ihre Akzeptanzrate ist im Vergleich zu ihrem Vorgänger, der Virtualisierung, tatsächlich deutlich gestiegen. In weniger als zwei Jahren sehen wir bereits ein Interesse an der Bereitstellung von App-Diensten in Containern , was im Allgemeinen auf bereits in der Produktion befindliche Apps hinweist, die Skalierbarkeit, Sicherheit und Geschwindigkeit benötigen, um die hohen Erwartungen an die heutige Anwendungserfahrung zu erfüllen.
Interessanterweise werden Container zusammen mit ihren Verwaltungs- und Orchestrierungsframeworks reifer. Bei der Virtualisierung war dies nicht der Fall, doch andererseits gab es die Virtualisierung schon vor der Cloud, die wiederum eine Zwangsfunktion für andere agile Technologien darstellte, die APIs und Vorlagen zu übernehmen, die die Automatisierung und Orchestrierung der Cloud ermöglichten und auf die virtuelle Infrastruktur angewendet werden konnten. Heutzutage werden sowohl Container als auch Virtualisierung (die man wohl als verwandte Technologien betrachten könnte) im Allgemeinen zusammen mit einem Orchestrierungsframework bereitgestellt, das die Bereitstellung, Skalierung und sogar das Routing des Datenverkehrs zu und von anderen Apps und Diensten (Ost-West-Verkehr) koordiniert.
Obwohl diese Mechanismen innerhalb der Domänengrenzen dieser Frameworks problemlos funktionieren, um lokalisierte Skalierung und Routen bereitzustellen, sind diese Apps und Dienste in Wirklichkeit Teil eines größeren Gesamtbilds; eines Gesamtbilds, das eine umfassendere „App“ enthält, die eine Interaktion mit Benutzern erfordert (Nord-Süd-Verkehr). Eine Ende 2016 von Portworx durchgeführte Umfrage ergab, dass mit 48 % der Befragten „Web-Frontends“ der zweitbeliebteste Workload war, der in Containern geplant war.
Dies garantiert nahezu, dass es einen Upstream-Dienst (oder ein Upstream-Gerät, wenn Sie so wollen) gibt, der Skalierbarkeit, Sicherheit und Geschwindigkeit zwischen den Benutzern und der „App“ bereitstellt, die aus Diensten besteht, die in einer Containerumgebung bereitgestellt werden.
Das bedeutet ausnahmslos, dass eine Koordination zwischen dem Container-Orchestrierungsframework und dem Upstream-Gerät/-Dienst stattfinden muss.
Geben Sie F5 Container Connectors ein. Als wir Container Connectors erstmals ankündigten, gaben wir unserer Mesos-Unterstützung den letzten Schliff. Wir freuen uns, heute auch Unterstützung für Kubernetes bekannt zu geben.
Der F5 Container Connector bietet die erforderliche Integration, um die letzte interne Meile zwischen dem Übergang vom Nord-Süd-Verkehr zum Ost-West-Verkehr zu überbrücken. Hier übergibt der Upstream-BIG-IP (von dem aus Kubernetes sitzt) die Anfragen an den entsprechenden lokalen Proxy (das kann beispielsweise unser eigener Application Services Proxy oder im Fall von Kubernetes Kube-Proxy sein) oder Pod zur Verarbeitung.
Anschließend wartet es auf eine Antwort, führt die ihm zugewiesenen Aufgaben aus, z. B. Datenbereinigung (zur Vermeidung von Datenlecks) und Bildoptimierung (zur Verbesserung der Leistung) und sendet die Daten zurück an den Benutzer.
Die Schlüsselkomponente ist der Container Connector, der in einem Kubernetes-Cluster liegt und wie andere Komponenten Ereignisse abonniert. Wenn es ein entsprechendes Ereignis erkennt, konfiguriert oder ändert es dynamisch eine vorhandene Konfiguration in der Upstream-Konfiguration (BIG-IP) mit den entsprechenden Details. Dabei kann es sich um eine Hochskalierung handeln, indem einem Cluster/Pool neue Mitglieder hinzugefügt werden, oder um eine Herunterskalierung, bei der die Mitglieder wieder entfernt werden.
Der wichtigste Aspekt besteht darin, dass es integriert ist und automatisch erfolgt. Dies bedeutet eine konsistente Anwendung von Sicherheitsrichtlinien am Nord-Süd-Ein-/Ausgang, ohne die Containerumgebung weiter zu komplizieren. Darüber hinaus fördert es die Verwendung von SSL/TLS, um den App- (und API-)Datenverkehr mit Benutzern zu sichern, indem es einen einzigen Punkt für die Verwaltung und Pflege von Zertifikaten bereitstellt. Dadurch bleibt die Containerumgebung auch frei von zusätzlicher Betriebskomplexität, einer häufigen Beschwerde bei der Einführung von Containern und den zugehörigen App-Architekturen.
Was F5 Container Connectors bieten, ist die Möglichkeit, die für containerisierte Apps erforderlichen App-Dienste automatisch in einer Produktionsumgebung bereitzustellen und zu verwalten, ohne dass umfassende Überarbeitungen der bereits in der Entwicklung und im Test vorhandenen Umgebung erforderlich sind (Sie haben ja getestet, oder?). Es unterstützt das Konzept reibungsloser Bereitstellungen und bewahrt das Konzept der Portabilität, das für containerisierte Anwendungen heute so wichtig ist.
F5 setzt sich dafür ein, dass die von Apps benötigten Bereitstellungs- und Sicherheitsdienste in jeder Art von Umgebung verfügbar sind, seien es Container oder virtuelle Maschinen, in jeder Cloud oder einer herkömmlichen Umgebung. Wir setzen uns aber auch dafür ein, dass die Bereitstellung und Verwaltung dieser Dienste möglichst einfach und problemlos ist. Das bedeutet, dass wir Lösungen anbieten, die in alle Arten von Architekturen passen.
Zur Unterstützung von DevOps-Toolchains haben wir die Container Connectors und unsere Version von Kube-Proxy kostenlos unter https://hub.docker.com/r/f5networks/ verfügbar gemacht. Eine Open-Source-Version unseres Kubernetes-Controllers kann aus unserem Git-Repository unter https://github.com/F5Networks/k8s-bigip-ctlr heruntergeladen werden.