Die Zahlen zur Akzeptanz von Kubernetes variieren von Bericht zu Bericht, aber es ist unbestreitbar, dass das Vertrauen der Unternehmen in Kubernetes von Jahr zu Jahr zunimmt und der Prozentsatz der in der Produktion eingesetzten Container schnell wächst. Während Kubernetes das notwendige Vertrauen geschaffen hat, finden Unternehmen schnell Lücken in dieser Lösung, die es zu schließen gilt.
Wenn es um Ingress-Controller für Kubernetes geht, gibt es eine Fülle von Möglichkeiten, die alle ein gewisses Maß an Anwendungsbereitstellungsfunktionen bieten. Unabhängig davon, ob sie als Open-Source oder von einem Load-Balancing-Anbieter angeboten werden, sind fast alle so konzipiert, dass die Ingress-Controller-Rolle als containerisierte Komponente ausgeführt wird, was den vollen Funktionsumfang einschränkt, der bereitgestellt werden kann und verfügbar sein sollte, um die Erwartungen der Kunden zu erfüllen. Als Load-Balancing-Anbieter sind wir der Meinung, dass die Kunden Zugang zu allen Funktionen und Leistungen haben sollten, die sie von ihrem ADC erwarten:
- Funktionen des Application Delivery Controller (ADC)
- Native WAF-Funktionalität
- Vorauthentifizierung/SSO
- Erweitertes health checking
- Global Server-Load Balancing
- Erweitertes Content Switching
- Performance – Fähigkeit, im Kernel-Bereich zu laufen
- Koexistenz mit Legacy-Systemen – Verbessern Sie Migrationen und Support von Legacy- zu Microservices.
- Direkter Weg zu Pods – Reduzieren Sie den Ost-West-Datenverkehr
Bereitstellen von Funktionen
Nach Gesprächen mit Kunden und der Erörterung der Herausforderungen mit den heutigen Ingress-Controllern verfolgte Kemp diesen Ansatz, um Ingress-Funktionen außerhalb des Kubernetes-Clusters bereitzustellen (und damit den Kunden alle Funktionen zu bieten, die sie benötigen, um die Leistung, Verfügbarkeit und Sicherheit ihrer containerisierten Anwendungen zu gewährleisten).
Zusätzlich zu diesen Schlüsselfunktionen besteht die Herausforderung darin, die Teams im Unternehmen richtig auf das Ökosystem der Microservices auszurichten. Bei der Entwicklung von Kubernetes wird davon ausgegangen, dass jedes Unternehmen ein funktionsübergreifendes DevOps-Modell eingeführt hat, was nicht weiter von der Wahrheit entfernt sein könnte, und bisher haben sich die Ingress-Controller nicht mit dieser Herausforderung befasst. Der Kemp Ingress Controller (KIC) geht dieses Problem an, indem er in zwei Modi arbeitet, die die Individualität der Arbeitsweise von Organisationen unterstützen (siehe https://kemptechnologies.com/blog/netops-and-dev-for-microservice-load-balance/).
Service-Modus: Dieser Modus ist einzigartig für den Kemp Ingress Controller und ermöglicht es NetOps-Teams, die Netzwerkinfrastruktur einschließlich des Ingress Controllers / ADC für die Veröffentlichung dieser containerisierten Anwendungen nach außen zu besitzen. Das NetOps-Team kann die Veröffentlichung von Diensten über eine eingeschränkte API an das AppDev-Team delegieren und so die Fallstricke vermeiden, die ein gemeinsam genutzter Ingress-Controller bei dieser Art der gemeinsamen Nutzung mit sich bringt.
Ingress-Modus: Für Unternehmen, die DevOps eingeführt haben, bei denen funktionsübergreifende Teams die Veröffentlichung von Anwendungen und die zugrunde liegende Netzwerkinfrastruktur zur Unterstützung der Anwendungen verwalten, kann der standardmäßige Ingress-Modus von KIC genutzt werden.
Wenn Ihr Unternehmen mit den Herausforderungen der heutigen Ingress-Funktionen zu kämpfen hat oder wenn Sie gerade erst mit der Planung einer Migration zu Microservices oder einer Greenfield-Bereitstellung beginnen, ist der Kemp Ingress Controller jetzt verfügbar, der Kunden den Zugriff auf diese neuesten Funktionen ermöglicht.
