Konvergenz mit Kubernetes

Ursprünglicher Autor: Paul Ingles
  • Übersetzung

Gesamtstandardisierung


Ich bereitete dieses Material für eine Rede auf der Konferenz vor und fragte unseren technischen Direktor, was die Hauptsache Kubernetes für unsere Organisation ist. Er antwortete:


Die Entwickler selbst wissen nicht, wie viel zusätzliche Arbeit sie geleistet haben.

Anscheinend wurde er von dem kürzlich gelesenen Buch „Factfulness“ inspiriert - es ist schwierig, geringfügige und kontinuierliche Änderungen zum Besseren zu bemerken, und wir verlieren ständig unseren Fortschritt aus den Augen.


Der Übergang zu Kubernetes kann jedoch nicht als unbedeutend bezeichnet werden.



Fast 30 unserer Teams führen die Workloads der Cluster ganz oder teilweise aus. Etwa 70% unseres HTTP-Datenverkehrs wird in Anwendungen auf Kubernetes-Clustern generiert. Dies ist wahrscheinlich die umfassendste Technologiekonvergenz seit meinem Eintritt in das Unternehmen, nachdem die Forward-Gruppe 2010 den uSwitch gekauft hatte, als wir von .NET- und physischen Servern zu AWS und von einem monolithischen System zu Mikrodienstleistungen wechselten .


Und alles ging sehr schnell. Ende 2017 nutzten alle Teams ihre AWS-Infrastruktur. Sie richten Lastverteiler, EC2-Instanzen, ECS-Clusteraktualisierungen usw. ein. Es hat etwas mehr als ein Jahr gedauert und alles hat sich verändert.


Wir haben ein wenig Zeit für Konvergenz aufgewendet, und Kubernetes hat uns dabei geholfen, dringende Probleme zu lösen - unsere Cloud wurde größer, die Organisation wurde komplexer und wir haben kaum neue Leute in die Teams aufgenommen. Wir haben die Organisation nicht geändert, um Kubernetes zu verwenden. Im Gegenteil - wir haben Kubernetes benutzt, um die Organisation zu verändern.


Vielleicht haben die Entwickler die großen Änderungen nicht bemerkt, aber die Daten sprechen für sich. Mehr dazu später.




Vor vielen Jahren war ich auf einer Clojure-Konferenz und hörte einen Vortrag von Michael Nygard über Architektur, der nicht in einen endgültigen Zustand gebracht werden kann . Er öffnete meine Augen. Ein ordentliches und ordentliches System sieht karik aus, wenn es die TV-Shops mit Küchenartikeln und einer großen Softwarearchitektur vergleicht. Das vorhandene System sieht aus wie ein stumpfes Messer, und anstelle von geraden Scheiben kommt so etwas Brei heraus. Ohne ein neues Messer gibt es an Salat nichts zu denken.


Es geht darum, wie Organisationen dreijährige Projekte lieben: Das erste Jahr ist Entwicklung und Vorbereitung, das zweite Jahr ist die Umsetzung, das dritte ist Rückkehr. In der Vorlesung sagt er, dass solche Projekte normalerweise kontinuierlich durchgeführt werden und selten bis zum Ende des zweiten Jahres kommen (häufig aufgrund der Übernahme eines anderen Unternehmens und Richtungswechsel und Strategieänderung), so dass die übliche Architektur ist


Schichtung der Veränderung in irgendeiner Art von Stabilität.

Und uSwitch ist ein gutes Beispiel.


Wir haben aus verschiedenen Gründen zu AWS gewechselt - unser System wurde den Spitzenlasten nicht gewachsen, und die Entwicklung der Organisation wurde durch ein zu starres System und eng verwandte Teams behindert, die für bestimmte Projekte gebildet und durch Spezialisierung aufgeteilt wurden.


Wir wollten nicht alles fallen lassen, alle Systeme verschieben und von vorne beginnen. Wir haben neue Dienste mit Proxy durch den vorhandenen Load Balancer erstellt und die alte Anwendung allmählich verschluckt . Wir wollten sofort eine Rückkehr zeigen und haben bereits in der ersten Woche A / B-Tests der ersten Version des neuen Services in der Produktion durchgeführt. Infolgedessen haben wir langfristige Produkte genommen und angefangen, Teams für Entwickler, Designer, Analysten usw. zu bilden. Das Ergebnis haben wir sofort gesehen. Im Jahr 2010 schien es eine echte Revolution zu sein.


Jahr für Jahr haben wir neue Befehle, Dienste und Anwendungen hinzugefügt und das monolithische System nach und nach erstickt. Die Teams kamen schnell voran - jetzt arbeiteten sie unabhängig voneinander und bestanden aus Spezialisten in allen erforderlichen Bereichen. Wir haben die Interaktion von Teams für die Produktveröffentlichung minimiert. Wir haben nur einige Befehle für die Konfiguration des Lastenausgleichs ausgewählt.


Die Teams wählten selbst Entwicklungsmethoden, Werkzeuge und Sprachen. Wir stellen ihnen eine Aufgabe, und sie haben selbst eine Lösung gefunden, weil sie die Frage am besten verstanden haben. Mit AWS sind diese Änderungen einfacher geworden.


Wir folgten intuitiv den Prinzipien des Programmierens: Teams, die lose miteinander verbunden sind, kommunizieren seltener, und wir müssen keine wertvollen Ressourcen für die Koordinierung ihrer Arbeit aufwenden. All dies ist großartig in dem kürzlich veröffentlichten Buch Accelerate beschrieben .


Als Ergebnis, wie Michael Nigard beschrieben hat, haben wir ein System aus vielen Schichten von Änderungen erhalten - einige Systeme wurden mit Puppet automatisiert, andere mit Terraform, irgendwo haben wir ECS verwendet, irgendwo - EC2.


2012 waren wir stolz auf unsere Architektur, die leicht verändert werden konnte , um zu experimentieren , erfolgreiche Lösungen zu finden und sie zu entwickeln.


Aber 2017 haben wir erkannt, dass sich vieles geändert hat.




Die AWS-Infrastruktur ist jetzt viel komplizierter als 2010. Sie bietet viele Optionen und Möglichkeiten - aber nicht ohne Konsequenzen. Heute muss jedes Team, das mit EC2 arbeitet, eine VPC, eine Netzwerkkonfiguration und vieles mehr auswählen.


Wir haben das an uns selbst erlebt - die Teams begannen zu beklagen, dass sie immer mehr Zeit für die Instandhaltung der Infrastruktur aufwenden, wie zum Beispiel das Aktualisieren von Instanzen in AWS ECS-Clustern , EC2-Maschinen, den Wechsel von ELB-Balancern zu ALB usw.


Mitte 2017 forderte ich bei einer Firmenveranstaltung alle auf, die Arbeit zu standardisieren, um die Gesamtqualität der Systeme zu verbessern. Ich habe eine gehackte Eisbergmetapher verwendet, um zu zeigen, wie wir Software erstellen und warten:



Ich sagte, dass die meisten Teams in unserem Unternehmen mit der Erstellung von Dienstleistungen oder Produkten befasst sein sollten und sich auf die Lösung von Problemen, Anwendungscode, Plattformen und Bibliotheken usw. konzentrieren sollten. In dieser Reihenfolge. Es gibt viel Arbeit unter Wasser - Log-Integration, erhöhte Beobachtbarkeit, geheimes Management usw.


Zu diesem Zeitpunkt war jedes Anwendungsentwicklungsteam an fast dem gesamten Eisberg beteiligt und traf alle Entscheidungen selbst. Es wurden eine Sprache, eine Entwicklungsumgebung, ein Bibliotheks- und Metriktool, ein Betriebssystem, ein Instanztyp und ein Speicher ausgewählt.


An der Basis der Pyramide hatten wir Amazon Web Services-Infrastruktur. Aber nicht alle AWS-Dienste sind gleich. Sie verfügen beispielsweise über Backend-as-a-Service (BaaS) zur Authentifizierung und Datenspeicherung. Und es gibt andere, relativ niedrige Dienste, wie beispielsweise EC2. Ich wollte die Daten studieren und verstehe, dass die Teams Grund haben, sich zu beschweren, und sie wirklich mehr Zeit damit verbringen, mit Low-Level-Diensten zu arbeiten, und viele unwichtige Entscheidungen treffen.


Ich habe die Dienste in Kategorien eingeteilt, alle verfügbaren Statistiken mit CloudTrail gesammelt und dann BigQuery , Athena und ggplot2 verwendet, um zu sehen, wie sich die Situation für Entwickler in letzter Zeit geändert hat. Wachstum für Dienste wie RDS, Redshift usw. halten wir für wünschenswert (und erwartet) und für EC2, CloudFormation usw. im Gegenteil.



Jeder Punkt im Diagramm zeigt die 90. (rot), 80. (grün) und 50. (Blau) Perzentile für die Anzahl der Low-Level-Dienste , die unsere Mitarbeiter für einen bestimmten Zeitraum jede Woche in Anspruch nahmen. Ich habe Glättungslinien hinzugefügt, um den Trend zu zeigen.


Obwohl wir bei der Bereitstellung von Software, z. B. mithilfe von Containern und Amazon ECS , nach Abstraktionen auf hoher Ebene strebten , verwendeten unsere Entwickler regelmäßig mehr und mehr AWS-Services und abstrahierten nicht von der Komplexität der Systemverwaltung. In zwei Jahren verdoppelte sich die Anzahl der Dienstleistungen bei 50% der Beschäftigten und verdreifachte sich bei 20% fast.


Dies begrenzt das Wachstum unseres Unternehmens. Die Teams wollten Autonomie, aber wie konnten sie neue Leute einstellen? Wir brauchten starke Applikations- und Produktentwickler und Kenntnisse über das immer komplexer werdende System von AWS.




Wir wollten das Team erweitern und gleichzeitig die Prinzipien bewahren, mit denen der Erfolg erzielt wurde: Autonomie, minimale Koordination und autonome Infrastruktur.


Mit Kubernetes haben wir dieses Ziel durch Abstraktionen mit einem Fokus auf Anwendungen und der Fähigkeit erreicht, Cluster für eine minimale Befehlskoordination aufrechtzuerhalten und abzustimmen.


Abstraktionen mit Fokus auf Anwendungen


Kubernetes-Konzepte können leicht mit der vom Anwendungsentwickler verwendeten Sprache verglichen werden. Angenommen, Sie verwalten Anwendungsversionen als Bereitstellung . Sie können mehrere Replikate für einen Dienst ausführen und diese über Ingress HTTP zuordnen . Durch Benutzerressourcen können Sie diese Sprache je nach Bedarf erweitern und spezialisieren.


Teams arbeiten produktiver mit diesen Abstraktionen. Im Prinzip enthält dieses Beispiel alles, was Sie zum Bereitstellen und Ausführen einer Webanwendung benötigen. Den Rest erledigen Kubernetes.


Im Bild mit dem Eisberg sind diese Konzepte auf Wasserstand und verbinden die Aufgaben des Entwicklers von oben mit der darunter liegenden Plattform. Das Cluster-Management-Team kann untergeordnete und irrelevante Entscheidungen treffen (zum Verwalten von Metriken, Protokollierung usw.) und gleichzeitig mit den Entwicklern über Wasser die gleiche Sprache sprechen.


2010 hatte uSwitch traditionelle Teams, die ein monolithisches System unterhalten, und kürzlich hatten wir eine IT-Abteilung, die unser AWS-Konto teilweise verwaltete. Es scheint mir, dass das Fehlen gemeinsamer Konzepte die Arbeit dieses Teams ernsthaft beeinträchtigte.


Versuchen Sie, etwas Nützliches zu sagen, wenn Sie nur EC2-Kopien haben und Balancer und Subnetze in Ihr Vokabular laden. Das Wesen der Anwendung zu beschreiben, war schwierig oder sogar unmöglich. Dies kann ein Debian-Paket, die Bereitstellung über Capistrano usw. sein. Wir konnten die Anwendung nicht in einer gemeinsamen Sprache für alle beschreiben.


In den frühen 2000er Jahren arbeitete ich in London bei ThoughtWorks. Im Interview wurde mir empfohlen, das problemorientierte Design von Eric Evans zu lesen . Ich kaufte mir auf dem Heimweg ein Buch und fing an, mehr im Zug zu lesen. Seitdem erinnere ich mich an fast jedes Projekt und System.


Eines der Hauptkonzepte des Buches ist eine einzige Sprache, in der verschiedene Teams kommunizieren. Kubernetes bietet eine solche gemeinsame Sprache für Entwickler und Infrastrukturwartungsteams. Dies ist einer der Hauptvorteile. Außerdem kann es durch andere Themenbereiche und Geschäftsbereiche erweitert und ergänzt werden.


In einer gemeinsamen Sprache ist Kommunikation produktiver, aber wir müssen die Interaktion zwischen den Teams so weit wie möglich einschränken.


Notwendiges Interaktionsminimum


Die Autoren des Buches "Accelerate" heben die Eigenschaften einer locker gekoppelten Architektur hervor, mit der IT-Teams effizienter arbeiten:


Der Erfolg einer kontinuierlichen Versorgung hing im Jahr 2017 davon ab, ob ein Team
die Struktur seines Systems ohne Zustimmung des Managements ernsthaft ändern konnte .
Ändern Sie die Struktur Ihres Systems ernsthaft, warten Sie nicht darauf, dass andere Teams ihr System ändern, und schaffen Sie keine zusätzliche Arbeit für andere Teams.
Erledigen Sie ihre Aufgaben, ohne mit anderen Teams zu kommunizieren und ihre Arbeit zu koordinieren.
Bereitstellen und Freigeben eines Produkts oder Services auf Abruf, unabhängig von anderen damit verbundenen Services.
Machen Sie die meisten Tests nach Bedarf, ohne eine integrierte Testumgebung.

Wir benötigten zentralisierte Software-Multi-Tenant-Cluster für alle Teams, gleichzeitig wollten wir diese Eigenschaften jedoch beibehalten. Das Ideal ist noch nicht erreicht, aber wir versuchen unser Bestes:


  • Wir haben mehrere Cluster, und die Teams entscheiden selbst, wo die Anwendung ausgeführt werden soll. Wir verwenden noch keinen Verbund (wir warten auf AWS-Unterstützung), aber wir haben Envoy zum Lastausgleich für Ingress- Balancer in verschiedenen Clustern. Die meisten dieser Aufgaben automatisieren wir mit Hilfe einer kontinuierlichen Lieferpipeline (wir haben Drone ) und anderen AWS-Services.
  • Alle Cluster haben den gleichen Namensraum . Etwa einer für jedes Team.
  • Der Zugriff auf Namespaces wird über RBAC (rollenbasierte Zugriffssteuerung) gesteuert. Zur Authentifizierung und Autorisierung verwenden wir in Active Directory eine Unternehmensidentität.
  • Cluster werden automatisch skaliert und wir tun unser Bestes, um die Startzeit des Knotens zu optimieren. Es dauert immer noch ein paar Minuten, aber im Allgemeinen verzichten wir auch bei großen Arbeitsbelastungen auf Koordination.
  • Die Skalierung von Anwendungen erfolgt automatisch auf der Grundlage von Prometheus-Metriken auf Anwendungsebene. Die Entwicklungsteams steuern die automatische Skalierung ihrer Anwendung durch Abfragemetriken pro Sekunde, Vorgänge pro Sekunde usw. Dank der automatischen Skalierung des Clusters bereitet das System Knoten vor, wenn die Anforderungen des aktuellen Clusters übersteigen.
  • In Go haben wir ein Befehlszeilentool namens u geschrieben , das die Authentifizierung von Befehlen in Kubernetes, die Verwendung von Vault , Anforderungen für temporäre AWS-Anmeldeinformationen und so weiter standardisiert .


Ich bin nicht sicher, ob wir mit Kubernetes mehr Autonomie haben, aber es ist definitiv auf hohem Niveau geblieben, und gleichzeitig haben wir einige Probleme gelöst.




Der Übergang zu Kubernetes war schnell. Das Diagramm zeigt die Gesamtzahl der Namespaces (in etwa gleich der Anzahl der Teams) in unseren Arbeitsclustern. Die erste erschien im Februar 2017.



Wir hatten Gründe zu eilen - wir wollten kleine Teams, die sich auf ihr Produkt konzentrieren, vor Infrastrukturproblemen retten.


Das erste Team stimmte zu, zu Kubernetes zu wechseln, wenn der Platz auf dem Anwendungsserver aufgrund einer falschen Konfiguration der Logrotate ausging. Die Umstellung dauerte nur wenige Tage und sie nahmen das Geschäft wieder auf.


In letzter Zeit ziehen die Teams wegen verbesserter Werkzeuge zu Kubetnetes. Kubernetes-Cluster vereinfachen die Integration mit unserem geheimen Verwaltungssystem ( Hashicorp Vault ), verteiltem Tracing ( Google Cloud Trace ) und ähnlichen Tools. Alle unsere Teams erhalten noch effizientere Funktionen.




Ich habe bereits ein Diagramm mit Perzentilen der Anzahl der Services gezeigt, die unsere Mitarbeiter von Ende 2014 bis 2017 jede Woche in Anspruch nahmen. Aber die Fortsetzung dieses Diagramms bis heute.



Wir haben Fortschritte beim Management der komplexen Struktur von AWS gemacht. Ich bin froh, dass jetzt die Hälfte der Mitarbeiter das Gleiche tut wie Anfang 2015. In einem Cloud-Computing-Team haben wir 4–6 Mitarbeiter, etwa 10% der Gesamtzahl. Es ist nicht verwunderlich, dass sich das 90. Perzentil fast nicht bewegt hat. Aber ich hoffe hier weiterzukommen.


Zum Schluss werde ich darüber sprechen, wie sich unser Entwicklungszyklus verändert hat, und noch einmal an das kürzlich gelesene Buch Accelerate erinnern.


Das Buch erwähnt zwei Indikatoren der Lean-Entwicklung: Vorlaufzeit und Paketgröße. Die Ausführungszeit wird von der Anfrage bis zur Auslieferung der fertigen Lösung berechnet Paketgröße ist der Arbeitsaufwand. Je kleiner das Paket, desto effizienter ist die Arbeit:


Je kleiner das Paket, desto kürzer der Produktionszyklus, desto geringer die Variabilität der Prozesse, desto geringer sind Risiken, Kosten und Kosten. Wir erhalten schneller Feedback, arbeiten effizienter, wir haben mehr Motivation und versuchen schneller fertig zu werden, und seltener verschieben wir die Änderung.

In diesem Buch wird vorgeschlagen, die Größe von Paketen anhand der Häufigkeit der Bereitstellung zu messen. Je öfter die Bereitstellung, desto kleiner sind die Pakete.


Wir haben Daten für einige Implementierungen. Die Daten sind nicht ganz genau - einige Teams senden Freigaben direkt an den Hauptzweig des Repositorys, andere verwenden andere Mechanismen. Dies umfasst nicht alle Bewerbungen, aber Daten für 12 Monate können als Richtwerte betrachtet werden.



Der Ausfall der dreißigsten Woche ist Weihnachten. Für den Rest sehen wir, dass die Bereitstellungshäufigkeit zunimmt, was bedeutet, dass die Paketgröße abnimmt. Von März bis Mai 2018 hat sich die Häufigkeit der Ausgaben fast verdoppelt, und in letzter Zeit machen wir manchmal mehr als hundert Ausgaben pro Tag.


Zu Kubernetes zu gehen ist nur ein Teil unserer Strategie zur Standardisierung, Automatisierung und Verbesserung von Werkzeugen. Wahrscheinlich haben alle diese Faktoren die Häufigkeit der Probleme beeinflusst.


In Accelerate gibt es einen Zusammenhang zwischen der Häufigkeit der Bereitstellung und der Anzahl der Mitarbeiter und der Geschwindigkeit, mit der ein Unternehmen arbeiten kann, wenn die Mitarbeiterzahl erhöht wird. Die Autoren betonen die Einschränkungen der zugehörigen Architektur und Befehle:


Traditionell wird davon ausgegangen, dass die Erweiterung eines Teams die Gesamtproduktivität erhöht, jedoch die Produktivität einzelner Entwickler verringert.

Wenn Sie dieselben Daten zur Häufigkeit von Bereitstellungen verwenden und ein Diagramm der Abhängigkeit von der Anzahl der Benutzer erstellen, ist es klar, dass wir die Häufigkeit der Veröffentlichungen erhöhen können, selbst wenn mehr Personen vorhanden sind.



Zu Beginn des Artikels erwähnte ich das Buch "Factfulness" (das unseren technischen Direktor inspirierte). Der Übergang zu Kubernetes ist für unsere Entwickler zur bedeutendsten und schnellsten Konvergenz der Technologie geworden. Wir bewegen uns in kleinen Schritten und es ist leicht, nicht zu bemerken, wie sich die Dinge zum Besseren verändert haben. Es ist gut, dass wir über Daten verfügen, und sie zeigen, dass wir das erreicht haben, was wir wollen - unsere Mitarbeiter arbeiten an ihrem Produkt und treffen wichtige Entscheidungen in ihrem eigenen Bereich.


Zuvor waren wir so gut. Wir hatten Microservices, AWS, etablierte Produktteams, Entwickler, die für ihre Produktionsdienstleistungen verantwortlich waren, lose gekoppelte Teams und Architektur. Ich habe darüber im Bericht "Unser Zeitalter der Aufklärung" ("Unser Zeitalter der Aufklärung") auf einer Konferenz im Jahr 2012 gesprochen. Der Perfektion sind jedoch keine Grenzen gesetzt.


Zum Schluss möchte ich noch ein anderes Buch zitieren - Scale . Ich habe es kürzlich angefangen, und es gibt ein interessantes Fragment über den Energieverbrauch in komplexen Systemen:


Um Ordnung und Struktur in einem sich entwickelnden System aufrechtzuerhalten, ist ein konstanter Energiefluss erforderlich, der Verwirrung stiftet. Um das Leben zu erhalten, müssen wir daher die ganze Zeit essen, um die unvermeidliche Entropie zu besiegen.
Wir bekämpfen die Entropie, liefern mehr Energie für Wachstum, Innovation, Wartung und Reparatur, was mit zunehmendem Alter immer schwieriger wird. Dieser Kampf steht im Mittelpunkt jeder ernsthaften Diskussion über das Altern, die Sterblichkeit, die Nachhaltigkeit und die Selbstversorgung eines Systems, sei es ein lebender Organismus. , Firma oder Gesellschaft.

Ich denke, Sie können hier IT-Systeme hinzufügen. Ich hoffe, dass unsere letzten Bemühungen die Entropie für eine Weile beibehalten werden.


Jetzt auch beliebt: