Die Entwicklung kann mit einem Bild verglichen werden, in dem der Künstler ein führender Entwickler ist. Erstellen einer eleganten Microservice-Anwendung - mit den Kreationen der besten Architekten - Modernisten. Aber um den Prozess in Gang zu setzen und die Möglichkeit zu lassen, zu wählen - Kunst. Im ersten Artikel der Reihe möchten wir darüber sprechen, wie der IBM Kubernetes-Service und der IBM Managed OpenShift-Cloud-Service erstellt und ausgeführt wurden und wie Sie Ihren Kubernetes-Cluster in der IBM Cloud kostenlos bereitstellen und testen können.

Die IBM Cloud hat in den letzten zehn Jahren an Funktionalität gewonnen. Angefangen hat alles mit dem Aufbau gemeinsamer Infrastrukturen für die Betreuung großer Unternehmen, dann mit virtuellen und physischen Maschinen auf Basis von SoftLayer-Rechenzentren, dem fünfjährigen Aufbau von PaaS (basierend auf Cloud Foundry-Laufzeiten) und der Entwicklung einer Vielzahl von Diensten. Das Moskauer Entwicklungsteam war auch an der Erstellung eines Teils der Dienste beteiligt. Heute geht es jedoch nicht um Services, sondern um verwaltete Kubernetes und verwaltete OpenShift und um die Funktionsweise in der IBM Cloud. Viele Details können nicht gesagt werden, da das Projekt intern ist, es jedoch möglich ist, einen bestimmten Vorhang zu öffnen.
Was ist kubernetes und wie wird kubernetes / openshift anders verwaltet als bei einer lokalen Installation
Kubernetes wurde ursprünglich als Open-Source-Plattform für die Verwaltung containerisierter Anwendungen und Dienste positioniert. Die Hauptaufgaben von Kubernetes sind (ich werde ohne Übersetzung gehen, um die Terminologie nicht zu brechen):
- Serviceerkennung und Lastenausgleich
- Speicher-Orchestrierung
- Automatisierte Rollouts und Rollbacks
- Automatische Behälterverpackung
- Selbstheilung
- Geheim- und Konfigurationsmanagement
Im Allgemeinen leistet kubernetes bei all diesen Aufgaben hervorragende Arbeit. Andererseits wurden Kubernetes als Datenbank für die Speicherung von Anwendungskonfigurationen oder als API-Tool für die Verwaltung Ihrer Komponenten positioniert (besonders relevant im Zusammenhang mit der Entwicklung von Betreibern).
Ein Vorteil von Kubernetes ist, dass Sie containerisierte Anwendungen sowohl auf Ihren Computerressourcen als auch in der Cloud ausführen können. Bei Cloud-Ressourcen bieten viele Cloud-Anbieter die Möglichkeit, Computerressourcen zum Ausführen von Anwendungen und zur vollständigen Verwaltung von Clustern zu verwenden:
- Cluster-Bereitstellung
- Festlegen der Netzwerkverfügbarkeit und -verteilung
- Installation von Updates und Fixpacks
- Cluster konfigurieren, um Fehlertoleranz und Sicherheit zu erhöhen (mehr im Artikel)
- ...
Wenn Sie in einer Cloud mit verwalteten Kubernetes arbeiten, sind Sie natürlich in einer Reihe von Aktionen eingeschränkt. Beispielsweise werden in der Regel mehrere Versionen von Kubernetes unterstützt, und es ist unwahrscheinlich, dass Sie Versionen von Kubernetes verwenden können, die seit langer Zeit nicht mehr unterstützt werden. Der Hauptvorteil ist zweifellos, dass nicht Ihr Team die Cluster verwaltet, wodurch sich die für die Entwicklung von Anwendungen erforderliche Zeit verkürzt. Natürlich können verwaltete Kubernetes und verwaltete OpenShift nicht in allen Organisationen und für jede Art von Anwendung verwendet werden, aber es gibt eine Vielzahl von Aufgaben, die sich hervorragend für das Computing in der Cloud eignen.
Cloud-Architektur
Innerhalb des Unternehmens werden das IBM Managed Kubernetes-Projekt und das IBM Managed OpenShift-Projekt als Armada-Projekt bezeichnet. Das Projekt begann mit einem Rechenzentrum. Jetzt ist es in 60 Cloud-Rechenzentren in 6 verschiedenen Regionen verfügbar. Um zu beschreiben, wie die Wolke skaliert, verwende ich zwei Begriffe: Hubs und Speichen. Das gesamte Armada-Projekt basiert auf Kubernetes, was bedeutet, dass seine Cluster von einem Kontrollfeld gesteuert werden, das auf Kubernetes ausgeführt wird. Sobald das Control Panel nicht über genügend Ressourcen verfügt, um die erforderlichen Cluster zu verwalten, werden zusätzliche Speichen bereitgestellt. Diese Speichen sind weiterhin für die Verwaltung von Clustern in einer bestimmten Region verantwortlich.
Das Control Panel besteht aus mehr als 1.500 Bereitstellungen und befindet sich in 60 Kubernetes-Clustern. All dies ist erforderlich, um mehr als 15.000 Cluster unserer Kunden zu verwalten (ohne testfreie Cluster, die auf demselben Worker bereitgestellt werden).
Um IKS und Managed OpenShift zu erstellen, verwendete das Team intern das OpenSource-Modell. Die meisten IBM Mitarbeiter haben Zugriff auf die meisten Armada-Repositorys und können ihre eigenen PRs erstellen, um ihre Services zu integrieren. Im Rahmen der Servicearbeiten wurden auch eine Vielzahl von CI / CD-Tools entwickelt, die in das Razee-Projekt integriert wurden. Im Sommer 2019 hat IBM alle Erfolge des Razee-Projekts auf OpenSource hochgeladen.
Im Allgemeinen sieht die Architektur für IKS und Managed OpenShift wie folgt aus:

Wenn Sie mit der IBM Cloud CLI arbeiten und die Erstellung eines Clusters anfordern, werden Ihre Anforderungen an die Armada-API gesendet. Anschließend ermittelt das Control Panel die Verfügbarkeit von Speichen und leitet die Erstellung der erforderlichen Anzahl von Mitarbeitern in den von Ihnen angegebenen Regionen ein. Die gesamte Infrastruktur für Mitarbeiter wird über die IBM Cloud Infrastructure (auch bekannt als Soflayer) bereitgestellt. Es werden dieselben virtuellen Instanzen und Bare-Metal-Hosts verwendet, die im Abschnitt "Compute" des Cloud-Service-Katalogs verfügbar sind. Nach einer Weile erhalten Sie ein Autorisierungstoken und können mit der Bereitstellung Ihrer Anwendungen beginnen.
Da sich OpenShift und Kubernet in ihren Fähigkeiten und ihrer Entwicklungsstrategie unterscheiden, ist der zugrunde liegende Technologie-Stack entsprechend unterschiedlich:

Wie ist die Sicherheit gewährleistet?
Wir können sowohl aus technischer als auch aus marketingtechnischer Sicht sehr lange über das Armada-Projekt sprechen. Vor allem aber stellt sich bei der Auswahl eines Cloud-Anbieters, der verwaltete Kubernetze bereitstellt, für alle die Frage, wie der Anbieter die Sicherheit und die Fehlertoleranz meiner Anwendungen gewährleistet und gewährleistet. Es ist unmöglich, die Leistung, den Komfort und den Grad des Service-Supports zu bewerten, ohne eine Antwort auf diese Frage zu erhalten. Als Entwicklungsleiter zeichne ich während der Entwicklung eines Großprojekts eine Karte der Bedrohungen. Es ist notwendig, alle möglichen Hacking-Optionen einzuführen und Ihre Infrastruktur, Anwendungen und Daten zu sichern. Um über die Sicherheit des Kubernetes-Clusters zu sprechen, müssen Sie die folgenden Punkte beschreiben:
- Sicherheit der Infrastruktur selbst und der Rechenzentren
- Zugriff auf Kubernetes API und etcd
- Sicherheitsknoten für Master und Worker
- Netzwerksicherheit
- dauerhafte Speichersicherheit
- Überwachung und Protokollierung
- Containersicherheit und Containerbilder
Nun, das Wichtigste zuerst:
Sicherheit der Infrastruktur selbst und der Rechenzentren
Unabhängig davon, wie wir uns von der Hardware und der Wartung des Hardware-Stopfens von IT-Systemen vollständig lösen möchten, müssen wir sicherstellen, dass der Dienstleister unser Rückgrat vollständig abdeckt und dies mit Hilfe von Industrie- und Industriezertifizierungen und gegebenenfalls mit Hilfe von Berichten über bestätigt Durchführung von Audits. Dieser Aspekt wurde vom IBM-Team mit aller Ernsthaftigkeit berücksichtigt, und alle erforderlichen Informationen wurden gesammelt und an einem Ort präsentiert ( https://www.ibm.com/cloud/compliance ).
Zugriff auf Kubernetes API und etcd
Um auf die Kubernetes-API und die Daten in etcd zuzugreifen, müssen Sie drei Berechtigungsstufen durchlaufen. Jedes ausgestellte Autorisierungstoken ist mit Authentifizierungstoken, Cluster-Autorisierungsdaten (RBAC) und dem Zugangscontroller verknüpft (siehe Abbildung unten).

Da die Assistenten zentral mithilfe von Speichen konfiguriert werden, können Sie die Assistentenkonfiguration nicht ändern. Die Assistenten selbst befinden sich nicht einmal in Ihrem Cloud-Konto und sind nicht in der Liste Ihrer Geräte sichtbar (im Gegensatz zu den Mitarbeitern). Alle Konfigurationsänderungen können nur innerhalb bestimmter Funktionen vorgenommen werden. Einerseits ist dies eine Einschränkung, aber aufgrund dieser Einschränkung haben Cyberkriminelle auch keinen Zugriff auf Ihre Assistenten. Außerdem gibt es keinen menschlichen Fehlerfaktor, es besteht kein Risiko, inkompatible Versionen von Kubernetes-Komponenten zu verwenden, und der gesamte Cluster-Verwaltungsprozess wird erleichtert. Im Allgemeinen können wir sagen, dass IBM für die Gewährleistung der Fehlertoleranz und die korrekte Konfiguration von kubernetes master verantwortlich ist. Wenn Ihr Projekt strenge Anforderungen an die Verwendung bestimmter Versionen von Komponenten stellt, würde ich an Ihrer Stelle keine verwalteten Kubernetze betrachten und meine eigene Installation verwenden.
Sicherheitsknoten für Master und Worker
Um die Sicherheit der Arbeiter und des Masters der Knoten zu gewährleisten, verwenden wir verschlüsselte VPN-Tunnel zwischen den Rechenknoten, und der Benutzer hat die Möglichkeit, einen Arbeiter mit verschlüsselten Festplatten zu bestellen. Wir verwenden Application Armor auch, um den Anwendungszugriff auf Ressourcen auf Betriebssystemebene einzuschränken. Application Armor ist eine Erweiterung des Linux-Kernels, um den Ressourcenzugriff für jede Anwendung zu konfigurieren.
Beim Erstellen eines Clusters werden nach Auswahl der für Sie geeigneten Konfiguration virtuelle oder Baremetal-Server für Sie erstellt, auf denen Komponenten für die Arbeit Ihrer Mitarbeiter installiert werden. Der Benutzer hat Zugriff auf das Betriebssystem des Mitarbeiters, jedoch nur, wenn er über ein Management-VPN verbunden ist. Dies kann zur Fehlerbehebung und zum Aktualisieren des Betriebssystems des Mitarbeiters hilfreich sein. Es gibt keinen öffentlichen IP-Zugriff über ssh. Um ssh in den Container zu bekommen, müssen Sie kubectl exec verwenden. Diese Verbindung wird über den OpenVPN-Tunnel hergestellt.

Netzwerksicherheit
In verwalteten Kubernet- und OpenShift-Umgebungen wird ein Calico-Netzwerk-Plugin als Netzwerk-Virtualisierungslösung verwendet. Die Netzwerksicherheit wird durch vorkonfigurierte Kubernetes- und Calico-Netzwerkrichtlinien erreicht. Ihre Mitarbeiter können sich im selben VLAN wie alle anderen Infrastrukturen im selben Rechenzentrum befinden, z. B. normale virtuelle Maschinen und Baremetal-Server sowie Netzwerkanwendungen und Speichersysteme. Dank der Kalikosysteme außerhalb Ihres Clusters können können über ein privates Netzwerk mit Ihren Bereitstellungen kommunizieren.
Wenn ein Cluster mit einem öffentlichen VLAN erstellt wird, erstellt das Control Panel eine HostEndpoint
Ressource mit der ibm.role: worker_public
für jeden Worker und seine externen Netzwerkschnittstellen. Um externe Netzwerkschnittstellen zu schützen, wendet das Control Panel alle Calico-Standardrichtlinien auf alle Endpunkte mit der ibm.role: worker_public
.
Die Standardrichtlinien von Calico erlauben den gesamten ausgehenden Verkehr und den eingehenden Verkehr vom Internet zu bestimmten Komponenten (Kubernetes NodePort, LoadBalancer und Ingress-Dienst). Der gesamte andere Verkehr ist gesperrt. Standardrichtlinien gelten nicht für Datenverkehr innerhalb des Clusters (Interaktion zwischen Pods)
Permanente Speichersicherheit
Für die Sicherheit auf der Persistenzebene werden Verschlüsselung und Schlüsselautorisierung verwendet. Derzeit verfügbar für IKS:
- Klassisches NFS
- Klassischer Blockspeicher (iSCSI)
- VP-Blockspeicher
- IBM Cloud-Objektspeicher
- Porworx-basiertes Sicherheitsdatenblatt (verwendet lokale Laufwerke Ihrer eigenen Mitarbeiter)
Überwachung und Protokollierung
Sie können IBM Cloud Monitoring oder eine Lösung von Sysdig verwenden, um IKS zu überwachen. Prometheus war natürlich nicht ohne. Managed OpenShift verwendet integrierte Überwachungstools.
Mit den Protokollen selbst sind die Dinge komplizierter. Es ist notwendig, Protokolle von völlig unterschiedlichen Ebenen zu sammeln, wir verwenden eine große Anzahl unserer eigenen und Open Source-Lösungen. Wir sammeln und speichern die folgenden Protokolle:
- Protokolle des Containers selbst (STDOUT, STDERR)
- Anwendungsprotokolle (wenn der Pfad zu ihnen angegeben ist)
- Protokolle vom Arbeitsknoten
- Kubernetes API-Protokolle
- Ingress Logs
- Protokolle aller Kubernetes-Systemkomponenten (Kubesystem-Namespace)
Zur Steuerung der Protokolle steht ein separater Service zur Verfügung: IBM Cloud Log Analysis mit LogDNA, mit dem Sie alle Protokolle in einer gemeinsamen Konsole anzeigen und je nach Tarif nachträglich oder in Echtzeit analysieren können. Sie können in jeder der 6 Regionen eine Instanz separat erstellen und diese dann zum Sammeln der Protokolle Ihres Kubernetes-Clusters und anderer Infrastrukturen in Ihrem Konto verwenden. Um diesen Dienst mit Ihrem Cluster zu verbinden, müssen Sie einen Pod mit dem LogDNA-Agenten gemäß den einfachen Anweisungen erstellen. Alle Protokolle werden an das LogDNA-Repository gesendet und stehen dann je nach ausgewähltem Plan für eine bestimmte Zeit zur weiteren Analyse zur Verfügung.
Zur Analyse der Aktivitäten in Ihren Cloud-Diensten, einschließlich Anmeldungen und vielem mehr, steht Activity Tracker mit LogDNA zur Verfügung. Mit dieser Funktion können Sie verschiedene Aktionen in Ihren Diensten nachverfolgen.
Als zusätzliches Überwachungstool können Sie IBM Cloud Monitoring mit Sysdig in Ihrem Cluster einrichten. Es ist in allen sechs Regionen verfügbar, sodass Sie viele Metriken in Ihrem Cluster in Echtzeit überwachen und die integrierten Integrationen mit vielen gängigen Umgebungen verwenden können, die in Containern ausgeführt werden. Außerdem können Sie die Reaktion auf Ereignisse mit der Möglichkeit von Benachrichtigungen über Slack, E-Mail, PagerDuty, WebHook usw. konfigurieren.
Container- und Container-Image-Sicherheit
Das Unternehmen hat eine eigene Meinung dazu, was in DevOps enthalten ist. Wenn jemand interessiert ist, können Sie in der IBM Garage-Methode mehr darüber lesen. Verstehen, was DevSecOps auch in vielen Unternehmen ausmacht und in der Praxis anwendet. In der folgenden Abbildung sehen Sie, welche Phasen ein Docker-Image durchläuft, um ein Docker-Container zu werden.

In der IBM Cloud kann die Docker-Registrierung als Service verwendet werden. Beim Senden eines Bildes an diese Registrierung wird das Docker-Bild signiert. Auf Seiten des Worker-Knotens wird das Addon installiert, das für die Überprüfung der Integrität und Einhaltung der Sicherheitsrichtlinien verantwortlich ist - Vulnerability Advisor. Mit diesen Richtlinien können Sie beispielsweise den Registrierungskreis einschränken, von dem aus Docker-Bilder heruntergeladen werden können.
apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1 kind: ClusterImagePolicy metadata: name: ibmcloud-default-cluster-image-policy spec: repositories: # CoreOS Container Registry - name: "quay.io/*" policy: # Amazon Elastic Container Registry - name: "*amazonaws.com/*" policy: # IBM Container Registry - name: "registry*.bluemix.net/*" policy
Vulnerability Advisor arbeitet mit der Ausführung von Containern, deren regelmäßige Überprüfung und der automatischen Erkennung installierter Pakete. Docker-Images mit potenziellen Schwachstellen werden als gefährlich eingestuft und enthalten detaillierte Informationen zu den gefundenen Schwachstellen.
Der Sicherheitsberater ist das Zentrum für die Verwaltung aller Schwachstellen Ihrer Anwendung. Es ermöglicht die Arbeit mit Problemen und deren Behebung. Es funktioniert sowohl mit den Ergebnissen des Vulnerability Advisor als auch mit dem Cluster selbst und warnt rechtzeitig vor der Notwendigkeit, eine bestimmte Komponente zu aktualisieren.
Beispiel für die Registrierung und Bereitstellung eines verwalteten Kubernet-Clusters
Sie können Ihren verwalteten Kubernetes-Cluster in der IBM Cloud absolut kostenlos bereitstellen und testen:
- Registrieren Sie sich in der IBM Cloud: https://ibm.biz/rucloud (Sie müssen Ihre E-Mail-Adresse bestätigen, Sie müssen zu diesem Zeitpunkt keine Kreditkartendaten hinzufügen.)
- Um den IKS-Service zu nutzen, können Sie Ihr Konto auf ein bezahltes Konto übertragen (indem Sie auf Upgrade klicken und Ihre Bankkartendaten eingeben - Sie erhalten 200 USD auf dem Konto). Oder speziell für Leser des Habr können Sie einen Gutschein erhalten, mit dem Sie Ihr Konto in den Testmodus versetzen können. Auf diese Weise können Sie 30 Tage lang kostenlos einen Mindestcluster bereitstellen. Nach diesem Zeitraum kann der Cluster erneut erstellt und der Test fortgesetzt werden. Sie können einen Gutschein unter folgendem Link anfordern: https://ibm.biz/cloudcoupon . Die Bestätigung des Gutscheins erfolgt während des Arbeitstages.
- Sie können einen kostenlosen Cluster (ein Worker 2 vCPUs 4 GB RAM) aus dem Servicekatalog erstellen: https://cloud.ibm.com/kubernetes/catalog/cluster/create
- Das Erstellen eines Clusters dauert 5-7 Minuten. Danach steht Ihnen der IKS-Cluster zur Verfügung.
Fazit
Ich hoffe, dass der Leser nach dem Lesen dieses Artikels weniger Fragen dazu hat, wie verwaltete Kubernetes und verwaltete offene Schichten funktionieren. Dieser Artikel kann auch als Handlungsanweisung für die Implementierung eigener Kubernetes verwendet werden. Alle von IBM verwendeten Methoden sind auf private Clouds anwendbar und werden mit einigem Aufwand in jedem Rechenzentrum implementiert.
Ressourcen
IKS locker
https://ibm-container-service.slack.com/
https://www.ibm.com/cloud/blog/announcements/ibm-cloud-activity-tracker-with-logdna-for-ibm-cloud-object-storage
https://www.ibm.com/cloud/blog/announcements/introducing-the-portworx-software-defined-storage-solution
https://cloud.ibm.com/docs/services/Monitoring-with-Sysdig?topic=Sysdig-getting-started