{"id":36246,"date":"2019-10-31T22:10:28","date_gmt":"2019-10-31T19:10:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada\/"},"modified":"2019-10-31T22:10:28","modified_gmt":"2019-10-31T19:10:28","slug":"avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada","title":{"rendered":"Automatisches Skalieren und Ressourcenmanagement in Kubernetes (\u00dcberblick und Vortragvideo)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am 27. April fand auf der Konferenz Streik-2019<\/a><\/noindex>, im Rahmen der Sitzung \u201eDevOps\u201c, wurde der Vortrag \u201eAutomatische Skalierung und Ressourcenmanagement in Kubernetes\u201c gehalten. Dabei wird erl\u00e4utert, wie man mit Hilfe von K8s hohe Verf\u00fcgbarkeit f\u00fcr Anwendungen sicherstellt und deren maximale Leistung garantiert.<\/p>\n

\"Automatisches
\n
\nTraditionell freuen wir uns, das Video mit dem Vortrag<\/b><\/a><\/noindex> (44 Minuten, deutlich informativer als der Artikel) sowie die Hauptinhalte in Textform. Lasst uns loslegen!<\/a><\/noindex><\/p>\n

Lassen Sie uns das Thema des Vortrags schrittweise durchgehen und am Ende beginnen.<\/p>\n

Kubernetes<\/h2>\n

\nStellen Sie sich vor, wir haben Docker-Container auf dem Host. Warum? Um Reproduzierbarkeit und Isolation zu gew\u00e4hrleisten, die wiederum einen einfachen und effektiven Deploy sowie CI\/CD erm\u00f6glichen. Wir haben viele Maschinen mit Containern.<\/p>\n

Was bietet uns in diesem Fall Kubernetes?<\/p>\n

    \n
  1. Wir h\u00f6ren auf, \u00fcber diese Maschinen nachzudenken, und beginnen stattdessen mit der Arbeit im \u201eCloud\u201c-Umfeld, einem Cluster von Containern<\/b> oder Pods (Gruppen von Containern).<\/li>\n
  2. Dar\u00fcber hinaus denken wir nicht einmal an separate Pods, sondern verwalten noch bgr\u00f6\u00dften<\/i>Solche hochrangigen Primitiven<\/b> erm\u00f6glichen es uns zu sagen, dass es eine Vorlage f\u00fcr das Starten einer bestimmten Arbeitslast gibt und wie viele Instanzen daf\u00fcr erforderlich sind. Wenn wir sp\u00e4ter die Vorlage \u00e4ndern, \u00e4ndern sich auch alle Instanzen.<\/li>\n
  3. Mit deklarative API<\/b> wir beschreiben anstelle der Ausf\u00fchrung einer bestimmten Sequenz von Befehlen das \"Weltmodell\" (in YAML), das von Kubernetes erstellt wird. Und erneut: Bei \u00c4nderungen der Beschreibung wird sich auch die tats\u00e4chliche Darstellung \u00e4ndern.<\/li>\n<\/ol>\n

    <\/p>\n

    Ressourcenmanagement<\/h2>\n

    <\/p>\n

    CPU<\/h3>\n

    \nAngenommen, wir betreiben nginx, php-fpm und mysql auf dem Server. Diese Dienste werden tats\u00e4chlich noch mehr Prozesse haben, die alle Rechenressourcen erfordern:<\/p>\n

    \"Automatisches
    \n(Die Zahlen auf der Folie sind \u201aPapageien\u2018, eine abstrakte Darstellung des Ressourcenbedarfs jedes Prozesses.)<\/i><\/p>\n

    Um damit bequem zu arbeiten, ist es sinnvoll, die Prozesse in Gruppen zusammenzufassen (alle nginx-Prozesse beispielsweise in einer Gruppe \u201anginx\u2018). Ein einfacher und offensichtlicher Weg, dies zu tun, besteht darin, jede Gruppe in einen Container zu platzieren:<\/p>\n

    \"Automatisches
    \n
    \nUm fortzufahren, sollten wir uns erinnern, was ein Container (in Linux) ist. Ihr Aufkommen wurde durch drei Schl\u00fcsselfunktionen im Kernel erm\u00f6glicht, die schon seit einiger Zeit implementiert sind:     Capabilities festzulegen.<\/a><\/noindex>, namespaces<\/a><\/noindex> und cgroups<\/a><\/noindex>. Die weitere Entwicklung wurde durch andere Technologien (einschlie\u00dflich benutzerfreundlicher \u201aSchalen\u2018 wie Docker) gef\u00f6rdert:<\/p>\n

    \"Automatisches
    \n
    \nIm Kontext dieses Vortrags interessiert uns nur cgroups<\/b>, denn genau die Kontrollgruppen sind der Teil der funktionalen M\u00f6glichkeiten von Containern (z. B. Docker), der das Ressourcenmanagement realisiert. Die Prozesse, die in Gruppen zusammengefasst sind, wie wir es wollten, sind genau diese Kontrollgruppen.<\/p>\n

    Kehren wir zu den CPU-Anforderungen dieser Prozesse zur\u00fcck, nun aber zu den Gruppen von Prozessen:<\/p>\n

    \"Automatisches
    \n(Ich wiederhole, dass alle Zahlen eine abstrakte Darstellung des Ressourcenbedarfs sind)<\/i><\/p>\n

    Dabei hat die CPU selbst eine gewisse begrenzte Ressource (in unserem Beispiel sind das 1000)<\/i>, die m\u00f6glicherweise nicht f\u00fcr alle ausreicht (die Summe der Bed\u00fcrfnisse aller Gruppen betr\u00e4gt 150+850+460=1460). Was passiert in einem solchen Fall?<\/p>\n

    Der Kernel beginnt, Ressourcen zu verteilen, und tut dies \u201efair\u201c, indem er jeder Gruppe die gleiche Menge an Ressourcen zuweist. Im ersten Fall ben\u00f6tigen sie jedoch mehr als n\u00f6tig (333>150), weshalb der \u00dcberschuss (333-150=183) als Reserve bleibt, die ebenfalls gleichm\u00e4\u00dfig auf die beiden anderen Container verteilt wird:<\/p>\n

    \"Automatisches
    \n
    \nAm Ende: der erste Container hatte gen\u00fcgend Ressourcen, der zweite hatte deutlich zu wenig, der dritte kam ein wenig zu kurz. So lautet das Ergebnis der Handlungen des \u201efairen\u201c Planers in Linux<\/b> \u2014     CFS<\/a><\/noindex>. Seine Arbeit kann durch die Zuweisung von Gewichtungen<\/b> f\u00fcr jeden der Container reguliert werden. Zum Beispiel so:<\/p>\n

    \"Automatisches
    \n
    \nLassen Sie uns einen Fall pr\u00fcfen, in dem Ressourcen beim zweiten Container (php-fpm) fehlen. Alle Ressourcen des Containers werden gleichm\u00e4\u00dfig zwischen den Prozessen verteilt. Infolgedessen funktioniert der Master-Prozess gut, w\u00e4hrend alle Worker verlangsamt werden und weniger als die H\u00e4lfte des ben\u00f6tigten erhalten:<\/p>\n

    \"Automatisches
    \n
    \nSo funktioniert der CFS-Scheduler. Die Gewichtungen, die wir den Containern zuweisen, werden wir sp\u00e4ter als Anfragen<\/b>bezeichnen. Warum genau so \u2013 siehe weiter.<\/p>\n

    Blicken wir auf die gesamte Situation aus einer anderen Perspektive. Wie bekannt ist, f\u00fchren alle Stra\u00dfen nach Rom und im Fall eines Computers zum CPU. Der CPU ist einzigartig, die Aufgaben sind zahlreich \u2013 es braucht eine Ampel. Der einfachste Ansatz zur Ressourcenverwaltung ist das \u201eAmpel\u201c-System: einem Prozess wird eine fixe Zugriffszeit auf den CPU zugewiesen, dann dem n\u00e4chsten usw.<\/p>\n

    \"Automatisches
    \n
    \nDieser Ansatz wird als hartes Quoting bezeichnet.<\/i>Wir merken uns einfach den Begriff Limits.<\/b>Wenn wir jedoch allen Containern Limits zuweisen, entsteht ein Problem: MySQL f\u00e4hrt auf der Stra\u00dfe und ben\u00f6tigt irgendwann CPU-Ressourcen, w\u00e4hrend alle anderen Prozesse warten m\u00fcssen, bis der CPU frei wird.<\/b>.<\/p>\n

    \"Automatisches
    \n
    \nKehren wir zum Linux-Kernel und seiner Interaktion mit dem CPU zur\u00fcck \u2013 das Gesamtbild sieht wie folgt aus:<\/p>\n

    \"Automatisches
    \n
    \nEine cgroup hat zwei Einstellungen \u2013 es handelt sich im Wesentlichen um zwei einfache \u201eRegler\u201c, die es erm\u00f6glichen zu bestimmen:<\/p>\n

      \n
    1. Gewicht f\u00fcr den Container (Anfragen) \u2014 das ist Anteile<\/b>;<\/li>\n
    2. der Prozentsatz der gesamten CPU-Zeit, die f\u00fcr die Bearbeitung von Aufgaben des Containers zur Verf\u00fcgung steht (Limits) \u2013 das ist Kontingent<\/b>.<\/li>\n<\/ol>\n

      <\/p>\n

      Wie misst man die CPU?<\/h3>\n

      \nEs gibt verschiedene Methoden:<\/p>\n

        \n
      1. Was ist Papageien<\/i>, niemand wei\u00df es \u2013 man muss sich jedes Mal absprechen.<\/li>\n
      2. Prozents\u00e4tze<\/i> sind verst\u00e4ndlicher, aber relativ: 50 % von einem Server mit 4 Kernen und mit 20 Kernen sind v\u00f6llig unterschiedliche Dinge.<\/li>\n
      3. Man kann die bereits erw\u00e4hnten von Gewichtungen<\/i>, die Linux kennt, verwenden, aber die sind ebenfalls relativ.<\/li>\n
      4. Die vern\u00fcnftigste M\u00f6glichkeit ist, die Rechenressourcen in Sekunden<\/i>zu messen. Das hei\u00dft, in CPU-Zeit im Verh\u00e4ltnis zu Echtzeit: 1 Sekunde CPU-Zeit in 1 realer Sekunde vergeben \u2013 das entspricht einem CPU-Kern vollst\u00e4ndig.<\/li>\n<\/ol>\n

        \nUm es noch einfacher auszudr\u00fccken, wird jetzt direkt in Kernen<\/i>gemessen, wobei damit genau die CPU-Zeit im Verh\u00e4ltnis zur Realit\u00e4t gemeint ist. Da Linux Gewichte versteht und nicht solche CPU-Zeiten\/Kerne, ben\u00f6tigte man einen Mechanismus zur Umrechnung von einem in das andere.<\/p>\n

        Betrachten wir ein einfaches Beispiel mit einem Server mit 3 CPU-Kernen, bei dem den drei Pods solche Gewichte (500, 1000 und 1500) zugewiesen werden, die leicht in die entsprechenden Anteile der zugewiesenen Kerne (0,5, 1 und 1,5) umgerechnet werden k\u00f6nnen.<\/p>\n

        \"Automatisches
        \n
        \nWenn Sie einen zweiten Server mit doppelt so vielen Kernen (6) nehmen und dort die gleichen Pods platzieren, l\u00e4sst sich die Verteilung der Kerne leicht durch einfache Multiplikation mit 2 (1, 2 und 3 entsprechend) berechnen. Ein wichtiger Punkt tritt jedoch ein, wenn auf diesem Server ein vierter Pod erscheint, dessen Gewicht zur Vereinfachung bei 3000 liegt. Er beansprucht einen Teil der CPU-Ressourcen (die H\u00e4lfte der Kerne), w\u00e4hrend die anderen Pods neu berechnet werden (sich halbieren):<\/p>\n

        \"Automatisches
        \n<\/p>\n

        Kubernetes und CPU-Ressourcen<\/h3>\n

        \nIn Kubernetes werden die CPU-Ressourcen \u00fcblicherweise in Milliarden<\/b>, d.h. als Basisgewicht wird 0,001 Kern verwendet. (Das Gleiche wird in der Linux-\/cgroups-Terminologie als CPU-Anteil bezeichnet, wobei 1000 Milliarden = 1024 CPU-Anteile entspricht, um es genauer zu sagen.)<\/i> K8s sorgt daf\u00fcr, dass nicht mehr Pods auf einem Server platziert werden, als CPU-Ressourcen f\u00fcr die Summe der Gewichte aller Pods verf\u00fcgbar sind.<\/p>\n

        Wie funktioniert das? Wenn ein Server dem Kubernetes-Cluster hinzugef\u00fcgt wird, wird die Anzahl der verf\u00fcgbaren CPU-Kerne mitgeteilt. Und beim Erstellen eines neuen Pods wei\u00df der Kubernetes-Planer, wie viele Kerne dieser Pod ben\u00f6tigt. So wird der Pod auf einen Server platziert, auf dem gen\u00fcgend Kerne vorhanden sind.<\/p>\n

        Was passiert, wenn nicht<\/b> Was passiert, wenn kein Request angegeben ist (d.h. die Anzahl der ben\u00f6tigten Kerne f\u00fcr den Pod nicht definiert ist)? Lassen Sie uns kl\u00e4ren, wie Kubernetes Ressourcen insgesamt berechnet.<\/p>\n

        F\u00fcr einen Pod k\u00f6nnen sowohl Requests (CFS-Planer) als auch Limits angegeben werden (denken Sie an die Ampel?):<\/p>\n