OK, brauche ich wirklich Kubernetes?

In einem großen Unternehmen ist es oft sehr schwierig, die Zuweisung von Ressourcen für Arbeitsaufgaben zu koordinieren. All Agile knirscht gegen die Wand eines dreiwöchigen Abkommens mit dem IS über eine neue Infrastruktur. Daher erhalten wir häufig Anfragen, die Infrastruktur auf Container zu übertragen, um die Änderungen nicht alle drei Monate und bei Bedarf des Unternehmens einzuführen. Gleichzeitig bitten sie darum, Kubernetes als beliebtestes Orchestrierungsinstrument zu konfigurieren / zu implementieren, obwohl, wie die Praxis zeigt, von 10 Projekten maximal drei benötigt werden. Tatsächlich lohnt es sich jedoch, entweder Kubernetes, aber OpenShift zu verwenden oder damit nicht in Ihrer Infrastruktur, sondern beispielsweise in einer öffentlichen Cloud zu arbeiten. Ich werde versuchen, über die realen Geschäftsfälle zu sprechen, für die wir uns entschieden haben. Ich werde die Hauptunterschiede zwischen Kubernetes und OpenShift beschreiben. Und auch darüber, wie wir die Koordination der Informationssicherheit auf 30 Minuten reduziert haben und alle am Leben geblieben sind.

Wir hatten mehrere interessante Implementierungen, in denen wir die akkumulierten Probleme des Kunden aufgegriffen haben. Zum Beispiel kam ein Einzelhandelsunternehmen zu uns, das kontinuierlich neue Chips einführen musste. Die Konkurrenz ist wild! Und sie haben nur die Infrastruktur für die Entwicklung jedes Mal, wenn es sechs bis zehn Tage dauert, was zu Ausfallzeiten führt. Die Lösung des Problems durch den Kauf neuer Hardware zum Testen und Entwickeln ist teuer und der Weg ins Nirgendwo. Infolgedessen haben wir die IT-Infrastruktur auf die Containervirtualisierung übertragen. Infolgedessen konnte die Ladung dank Containern um 40% reduziert werden, und die Infrastruktur für die neue Entwicklung wird jetzt von einer auf vier Stunden vorbereitet. Der Bonus sind Einsparungen, da alle Prozesse weiterhin auf der Grundlage vorhandener Kapazitäten durchgeführt werden können, ohne neue zu kaufen.

Was machen wir mit Informationssicherheit?

IB sind sehr notwendige Leute. Ihre internen Anforderungen für Projekte gehen oft etwas zu weit, aber dies ist viel besser, als einmal zu sehen, dass Ihre rumänischen Hacker Ihren externen SFTP-Server umgeben haben.

Aber es gibt ein Problem mit ihnen. Wenn wir den Geschäftsprozess als Förderer betrachten, wird ihre Aufteilung oft zum Engpass, auf dem alle anderen beruhen. Einerseits sind sie für alle mit der Sicherheit verbundenen Risiken verantwortlich, andererseits schaffen sie es einfach nicht, den Code und alle Details der Architektur des neuen Produkts manuell anzuzeigen.

Die Situation ist den Sicherheitsdiensten in Gebieten mit einem großen Personenstrom sehr ähnlich. Wir können eine vollständige Inspektion jedes Passagiers in der U-Bahn arrangieren, indem wir sie auf Scanner richten, Taschen verdrehen und das Telefon inspizieren. Infolgedessen kommt es jedoch anstelle der Sicherheit zu einem vollständigen Transportkollaps und einer Lähmung des Systems. Die einzige Option in dieser Situation ist die Organisation automatisierter Systeme, die beispielsweise auf Einzelpersonen reagieren, gesuchte Personen identifizieren oder auf abnormales Verhalten reagieren.

In unserem Kontext sind solche automatisierten Systeme ordnungsgemäß organisierte CI / CD-Prozesse mit Code-Analysatoren in Zwischenstadien, wie Lösungen wie JFrog Xray for Artifactory, und korrekt festgezogene Kubernetes / OpenShift-Muttern, die keine unsicheren Ansätze wie das Starten eines Containers vom Root-Benutzer zulassen. Jetzt bereiten wir eine Box-Lösung vor, die all dies bietet.

Das Ziel ist es, vom Konzept "wird erst in den Verkauf gehen, wenn wir schauen" zu "wenn es keine Einwände gibt, wird es automatisch eingesetzt" überzugehen. Es macht keinen Sinn, zu automatisieren, wenn die organisatorischen Prozesse gleich bleiben.

In einem der Projekte konnten wir die Zeit für IS-Fehler auf 30 Minuten reduzieren. Mit anderen Worten, wenn der „Sicherheitsbeamte“ die Aktion innerhalb einer halben Stunde nicht ablehnt, wird dies automatisch vereinbart und die Änderungen werden in die Produktion übernommen. Jetzt versuchen wir, eine Frist von 60 Minuten für alle Koordinatoren im Projekt zu erreichen, ohne die Sicherheit zu beeinträchtigen.

Was ist der Unterschied zwischen Container-Management-Systemen?

Kubernetes und OpenShift sind die Hauptlösungen für die Container-Orchestrierung. Lassen Sie uns die wichtigsten Unterschiede und Vorteile für das Unternehmen analysieren.

Offenheit

Kubernetes ist ein vollständig offenes Produkt, das unabhängig bereitgestellt und entweder allein oder mit externer Unterstützung gewartet werden kann. Die Situation auf dem Arbeitsmarkt hat sich bereits mehr oder weniger stabilisiert, und die Suche nach Experten zu diesem Thema ist kein Problem mehr.

OpenShift ist ein halbgeschlossenes Produkt mit einem ausgeklügelten Lizenzsystem von RedHat. Tatsächlich enthält es Kubernetes, aber es enthält eine Reihe zusätzlicher Bindungen, die viele Aufgaben vereinfachen. Der Anbieter bietet voll bezahlten Support für sein Produkt.

Hier hängt die Wahl davon ab, was am besten zu Ihnen passt - Unterstützung durch die Kräfte Ihrer Spezialisten oder Lieferanten.

Plattformen

Kubernetes funktioniert auf fast jeder Linux-Plattform und den meisten Cloud-Anbietern.

OpenShift funktioniert nur unter RHEL, Red Hat Atomic und Red Hat CoreOS. Es gibt eine Community-Version - OKD, die jedoch eng mit Distributionen verbunden ist. Die einzige Ausnahme ist, dass es unter CentOS installiert werden kann. Und denken Sie daran, dass Red Hat offiziell keine bezahlte Unterstützung garantiert.

Sicherheitsrichtlinien

OpenShift hat sofort strengere Sicherheitseinstellungen. Dies ist ein Plus bei der Bereitstellung der Infrastruktur von Grund auf neu, kann jedoch aufgrund der Inkompatibilität einiger Bilder mit Politikern ein Problem darstellen. In OpenShift ist es beispielsweise verboten, den Container von root aus auszuführen, wodurch die Kompatibilität mit alten Images beeinträchtigt wird. Andererseits bietet dieser Ansatz in Kombination mit der bequemen Integration in AD und der bequemen Protokollierung auf der Basis des EFK-Stacks (ElasticSearch, Fluentd, Kibana) die sofortige Sicherheit, die zum Entladen der IS-Einheit erforderlich ist.

Kubernetes können auch bis zu diesem Level fertiggestellt werden, dies erfordert jedoch viel Aufwand und Zeit seitens der Ingenieure.

Muster

OpenShift-Vorlagen sind weniger flexibel als Kubernetes Helm-Diagramme. Aufgrund strengerer Sicherheitsrichtlinien kann Red Hat derzeit nicht die Flexibilität von Helm-Diagrammen bieten. In OpenShift 4 hat sich die Situation jedoch dank des integrierten OperatorHub abgeflacht.

Gut gestaltete Vorlagen erleichtern das Leben erheblich. Tatsächlich ist dies eine solche Paketmanageroption zum Erstellen und Konfigurieren verschiedener Dienste.

Ein bedingter Befehl "helm install prometheus-operator" stellt ein ziemlich komplexes System bereit, dessen Bereitstellung sehr lange dauert. Kubernetes ist führend.

Allgemeine Schlussfolgerungen

Wie die meisten Produkte ist Red Hat OpenShift eine kastenförmigere, aber architektonisch härtere Lösung. Es erfordert weniger rotäugige und erfahrenere Mitarbeiter, um zu arbeiten. Bequemere Bereitstellungsszenarien, hervorragende Integration in CI / CD-Lösungen, insbesondere in Jenkins. OpenShift eignet sich hervorragend für Unternehmen, die für die Unterstützung eines fertigen Produkts leichter zu bezahlen sind als für die Einstellung eigener Spezialisten.

Für Unternehmen mit starken Spezialisten auf diesem Gebiet ist Kubernetes möglicherweise eine flexiblere und interessantere Lösung. Es eignet sich möglicherweise auch für ein relativ kleines Unternehmen, das Red Hat-Lizenzen einsparen möchte, jedoch keine komplexen Aufgaben hat, für die hochqualifizierte Experten erforderlich sind.

Echte Fälle

Ich werde versuchen zu zeigen, wie Containerisierungstechnologien dazu beigetragen haben, geschäftliche Probleme zu lösen, Lizenzen zu speichern und Spitzenlasten bei Massenbenutzerrazzien zu glätten.

Fallstudie: E-Commerce

Das Problem

Der Kunde hatte über 100 aktive Services, auf denen die Cloud Foundation von VMware ausgeführt wurde. Und all dieser Park hatte verschiedene Probleme:

1. 12 ressourcenintensive und nicht margenstarke Services wurden auf VMware gesponnen und verbrauchen ein Budget von ca. 408.000 USD pro Jahr.
2. Drei Dienste (ein Portal und zwei mobile Anwendungen) begannen sich aktiv zu entwickeln: Innerhalb von sieben Monaten stieg der Ressourcenbedarf für die Arbeit um das 4,5-fache und wächst weiter.
3. Einige Kundendienstleistungen weisen Spitzenlasten auf, bei denen Ressourcen sechs- bis siebenmal mehr benötigt werden als in normalen Zeiten. Dementsprechend wurden die Geräte für ihren korrekten Betrieb zugewiesen, der die meiste Zeit von weniger als 15% genutzt wurde.

Darüber hinaus hat der Kunde den Wunsch, sich nicht mehr an einen Virtualisierungsanbieter zu binden.

Unsere Entscheidung

Die erste und einfachste Lösung: Wir übertragen Dienste mit Spitzenwerten in die öffentliche CROC-Cloud . Mit Abrechnung für verbrauchte Ressourcen. Alles ist so einfach und langweilig wie möglich. Der Wechsel von VMware zu unserer KVM ist einer der häufigsten Fälle für Cloud-Ingenieure.

Da der Kunde bereits Hardware für die Skalierung gekauft hat, mussten wir nur die Lizenzen berechnen. Für neue Hosts von VMware kosteten sie etwa 2.100.000 US-Dollar, was dem Kunden nicht sehr zusagte. Wir haben vorgeschlagen, einige der Dienste auf KVM zu übertragen, auf dem OpenStack ausgeführt wird. Um nicht verloren zu gehen, integrieren Sie die Verwaltung beider Infrastrukturen durch CloudForms (und gleichzeitig OpenShift).

Infolgedessen erhielt der Kunde die zweite Schulter einer auf OpenStack basierenden privaten Cloud, wodurch die Vendorlock-Frage geschlossen wurde. Durch die Verlagerung einiger ressourcenintensiver Dienste auf eine neue Schulter konnten die Kosten für VMware-Lizenzen gesenkt werden (der 24-Stunden-Support von CROC erwies sich als günstiger).

Fall: Einzelhandel

Das Problem

Während des Audits stellte sich heraus, dass mit dem Kunden etwas Schreckliches in Bezug auf die Zuweisung der Infrastruktur geschah. Projekte - mehr als 250, Entwicklungsteams - mehr als 150, Halbcontainer auf Kubernetes. Ressourcen für jedes neue Projekt werden gekauft und bleiben ihm zugewiesen, ohne dass eine Auswahl möglich ist, auch wenn sie nicht verwendet werden. Es gibt überhaupt keine Abrechnung, es gibt kein einziges Portal. Riesige Kosten für Test- und Vorproduktionsumgebungen, da diese auch auf VMware laufen.

Gleichzeitig möchte der Kunde nicht vollständig auf eine neue Plattform umsteigen und alles unter einem einzigen Verwaltungsportal zusammenstellen. Darüber hinaus ist „alles“ nicht nur VMware, sondern auch PaaS, Container und eine einzige Abrechnung.

Unsere Entscheidung

Infolgedessen erwies sich das Innere der Lösung als ziemlich aufgeschüttet, aber für den Kunden sieht draußen alles sehr einfach aus.

Das Verzeichnis, in dem der Benutzer die Parameter der virtuellen Maschine und die erforderliche Schaltung auswählt: DevTest, PreProd, Prod. Anschließend wählt CloudForms aus, wo die angeforderte Ressource bereitgestellt werden soll: unter VMware oder unter OpenShift. Wir arbeiten immer noch an der Einzelabrechnung, da die hybride VMware + OpenShift-Lösung nur schwer zusammenzustellen ist.

Auf diese Weise ordnen wir die Infrastruktur in Ordnung und sortieren die Trümmer, die der Kunde angehäuft hat.

Fall: Industrie

Das Problem

Das Kopieren von VMs in verschiedene Umgebungen (Test, Dev, Prod, Preprod) dauert mehr als drei Tage und erfordert die manuelle Ausführung von 15 verschiedenen Vorgängen, von denen jeder bis zu 30 Minuten dauert. Eine eingehendere Prüfung ergab, dass die Zuweisung von Ressourcen für ein neues Projekt früher zwei Wochen dauerte und 10 bis 20 Anfragen pro Monat eingingen. Mittlerweile gibt es mehr als zehn Anfragen nach Ressourcen pro Tag, die ohne Automatisierung zu einem Zusammenbruch führten.

Unsere Entscheidung

Tatsächlich musste der Kunde die IT-Infrastruktur auf das Servicemodell übertragen, Änderungen an der Infrastruktur neu erstellen und automatisieren, ein Self-Service-Portal erstellen, es mit einem Servicekatalog füllen und eine Umgebung für die Verwaltung containerisierter Anwendungen implementieren. Wir haben den VM-Kopiervorgang automatisiert, aber es hat immer noch viel Zeit in Anspruch genommen: 40-60 Minuten, dies passte nicht zum Kunden. Aus diesem Grund haben wir vorgeschlagen, auf Container umzusteigen, wodurch sich die Kopierzeit auf drei bis fünf Minuten verkürzte.

Schlussfolgerungen

Containerisierung und Microservices sind keine Ablässe für schlechten Code, der mit dem linken Fuß geschrieben wird und sofort in die Produktion geht. Im Gegenteil, dies ist ein ganzes Konzept, das aufgrund der umfassenden Automatisierung aller Prozesse eine Reihe von Verbesserungen beinhaltet:

• Code wird sauberer: Linter, Code-Analysatoren, automatisierte Tests.
• Code und Architektur werden sicherer: Sicherheitstools mit umfangreichen Funktionen bis hin zur automatischen Blockierung der Bereitstellung von unsicherem Code.
• Services werden flexibler und mobiler: Entwicklungszyklen sind jetzt extrem kurz und reagieren schnell auf Änderungen.
• Automatische Skalierung unter Last: Ihre Ressource sinkt während der Hauptverkehrszeit nicht mehr und verliert Umsatz und Kunden.
• Einfache Zuweisung von Ressourcen für neue Projekte, Reduzierung des Zeitaufwands für die Koordinierung.
• Oft kann die Containerisierung die Markteinführungszeit erheblich verkürzen.

Manchmal ist eine Containerisierung überhaupt nicht erforderlich, und das Problem kann durch Migration in eine externe Cloud gelöst werden. Aber um eine Entscheidung zu treffen, brauchen wir auf jeden Fall eine gute externe Prüfung und Analyse des Geschehens. Kurz gesagt, Container sind nur eines der Werkzeuge zur Lösung von Geschäftsproblemen, wenn auch sehr cool.