Eine kurze Analyse von Kubernetes-Controllern und -Labels

01 Gemeinsame Controller in k8s

Zuvor haben wir gelernt, dass Pod die kleinste Planungseinheit im K8S-Cluster ist. Pod besteht aus Pausencontainer + Anwendungscontainer.

In k8s kommt es häufig vor, dass ein Ressourcenobjekt ein anderes Ressourcenobjekt verwaltet. Wir nennen diese Art von Ressourcenobjekt einen „Controller“.

Werfen wir einen kurzen Blick auf die Controllertypen und ihre Funktionen. Tatsächlich hat jeder Controller seine eigenen Eigenschaften. Wir werden sie später einzeln analysieren. Jetzt müssen Sie nur noch eine allgemeine Vorstellung haben.

RC-Steuerung

Es definiert ein erwartetes Szenario, das besagt, dass die Anzahl der Replikate eines bestimmten Pods jederzeit einen bestimmten erwarteten Wert erreicht. Beispielsweise erwarten wir in der Ein-Master-Zwei-Slave-Struktur von MySQL, dass es zu jedem Zeitpunkt immer zwei Slave-Datenbanken gibt. Wenn das nicht ausreicht, müssen wir eine Slave-Datenbank erweitern.

Für seine Definition sind die folgenden drei Schlüsselparameter erforderlich:

1. Voraussichtliche Anzahl an Pods

2. Pod-Label, das eine Typkennung ist

3. Erstellen Sie eine Pod-Vorlage für einen neuen Pod

Der allgemeine Aufbau ist wie folgt:

API-Version: vl
Art: ReplikationsController
Metadaten:
    Name: rc-mysql-slave
Spezifikation:
    Replikate: 2 # erwarteter Wertselektor: # Tag-App: MySQL
    Vorlage: # Vorlage xxx: xxx

Durch Vergleichen des obigen Textes können Sie die grundlegende YAML-Dateivorlage von RC sehen.

Sobald der RC definiert und an den K8S-Master übermittelt wurde, überprüft der Controller-Manager die derzeit überlebenden Ziel-Pods und stellt sicher, dass die derzeit überlebenden Pods den erwarteten Pods entsprechen. Wenn mehr vorhanden sind, werden sie gelöscht; wenn weniger vorhanden sind, werden sie erstellt.

Bereitstellungscontroller

Es handelt sich um ein neues Konzept, das in k8s Version 1.2 eingeführt wurde. Dieser Controller ist zu 90 % dem RC-Controller ähnlich. Der Unterschied zwischen ihm und RC besteht darin, dass er jederzeit den „Bereitstellungsfortschritt“ des aktuellen Pods abrufen kann. Die YAML-Dateidefinition lautet wie folgt:

API-Version: Erweiterungen/vlbetal
Art: Bereitstellung
Metadaten:
    Name: dep-mysql-slave
Spezifikation:
    Replikate: 2
    Wähler:
       xxxx:xxxx
    Vorlage:
       xxxx:xxxx

Mit Deployment können fast alle Szenarien, in denen RC verwendet wird, durch Deployment ersetzt werden.

Statefulset-Controller

Dieser Controller generiert auch den erwarteten Wert bestimmter Pods, unterscheidet sich jedoch von RC und Deployment darin, dass die von ihm generierten Pods zustandsbehaftet sind.

In den von RC und Deployment generierten Pods müssen wir nur die erwartete Anzahl an Pods generieren, ähnlich den beiden Slave-Bibliotheken von MySQL in der 1-Master-2-Slave-Architektur. Sie haben kein Konzept von Ordnung oder Gewicht. Die vom Statefulset-Controller gesteuerten Pods haben eine bestimmte logische Beziehung in der Generierungsreihenfolge oder Gewichtung. Beispielsweise ist es in der MySQL-Master-Slave-Architektur erforderlich, zuerst den Masterknoten und dann den Slaveknoten zu generieren. In diesem Fall ist es besser, Statefulset zu verwenden.

Es gibt noch einige andere häufig verwendete Controllertypen, die wir beim nächsten Mal ausführlich erläutern werden. Hier müssen wir nur das Konzept des „Controllers“ kennen.

02 Das Konzept des Labels

Im vorherigen Artikel haben wir über mehrere Schlüsselfelder in der YAML-Datei des Pods in k8s gesprochen. Heute werden wir uns ein weiteres Attribut des Pods ansehen, nämlich Label.

Label bedeutet Label, und sein Format ist auch das Schlüssel-Wert-Format. Es kann an ein Objekt im K8S-Cluster angehängt werden, einschließlich, aber nicht beschränkt auf Pod, Node, RC usw. Die Bindungsbeziehung zwischen Ressourcenobjekten und Labels kann eins-zu-eins oder viele-zu-eins sein. Zur Verwaltung von Ressourcen in Gruppen können unterschiedliche Labels verwendet werden.

Nachdem wir eine Ressource beschriftet haben, können wir den Beschriftungsselektor verwenden, um die Ressource für die Planung wie folgt auszuwählen:

API-Version: vl
Art: Pod
Metadaten:
    Name: meinweb
    Beschriftungen:
       App: MySQL

Das obige Beispiel definiert einen Pod für uns und seine Bezeichnung ist app=mysql.

Dann definieren wir einen „Controller“ und verwenden den Label-Selektor im Controller, um den Pod mit app=mysql auszuwählen und behalten zwei Kopien dieses Pods wie folgt im Cluster:

API-Version: vl
Art: ReplikationsController
Metadaten:
    Name: meinweb
Spezifikation:
    Replikate: 2
    Wähler:
        App: MySQL
    Vorlage:
        xxxx

Die neue Version von Selector kann auch detailliertere Filterbedingungen angeben, die hauptsächlich auf den folgenden Parametern basieren:

API-Version: vl
Art: ReplikationsController
Metadaten:
    Name: meinweb
Spezifikation:
    Replikate: 1
    Wähler:
       Übereinstimmungslabels:
         App: myweb
       Übereinstimmungsausdrücke:
        - {Schlüssel: aaa, Parameter: In, Werte: [mysql-slave]}
        - {Schlüssel: bbb, Operator: Notin, Werte: [mysql-master)}
    Vorlage:
        xxxx

Ein Parameter ist matchLabels, auf den mehrere Label-Bedingungen im Schlüssel-Wert-Format folgen können;

Ein weiterer Parameter ist matchExpression, der ein Array angeben und mit bedingten Operationen kombinieren kann. Im obigen Beispiel bedeutet dies, dass sich die Pods mit dem Parameter aaa im mysql-slave befinden, der Parameter bbb jedoch nicht im mysql-master.

Wenn diese beiden Parameter gleichzeitig auftreten, werden sie automatisch mit UND verknüpft und ihre Schnittmenge wird als endgültige Filterbedingung zum Filtern des Pods verwendet.

Es ist ersichtlich, dass die Verwendung von Tags dem „Controller“ mehr Flexibilität und Komfort bei der Auswahl des gesteuerten Objekts bietet.

Oben finden Sie eine kurze Analyse der Details zu Kubernetes-Controllern und -Labels. Weitere Informationen zu Kubernetes-Controllern und -Labels finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!