So installieren und konfigurieren Sie Kubernetes auf einem CoreOS-Cluster

Einführung

Kubernetes ist ein System zur Verwaltung von Anwendungen, die in Docker-Containern in Clusterumgebungen erstellt wurden. Es behandelt den gesamten Lebenszyklus einer containerisierten Anwendung, einschließlich Bereitstellung und Skalierung.

In diesem Handbuch wird gezeigt, wie Sie mit Kubernetes in einem CoreOS-Cluster beginnen. Mit diesem System können wir zusammengehörige Dienste für die Bereitstellung als Einheit auf einem einzelnen Host mithilfe der von Kubernetes als "Pods" bezeichneten Dienste gruppieren. Es bietet auch Integritätsprüfungsfunktionen, hohe Verfügbarkeit und effiziente Ressourcennutzung.

Dieses Tutorial wurde mit Kubernetes v0.7.0 getestet. Beachten Sie, dass sich diese Software häufig ändert. Führen Sie nach der Installation die folgenden Schritte aus, um Ihre Version anzuzeigen:

kubecfg -version

Voraussetzungen und Ziele

Wir werden mit denselben grundlegenden CoreOS-Clustern beginnen, die wir in früheren CoreOS-Handbüchern verwendet haben. Folgen Sie unserem CoreOS clustering guide, um diesen Cluster mit drei Mitgliedern zum Laufen zu bringen.

Dadurch müssen Sie drei Server konfigurieren. Während jeder Knoten auf CoreOS-Ebene im Wesentlichen austauschbar ist, müssen wir innerhalb von Kubernetes spezialisiertere Rollen zuweisen. Wir benötigen einen Knoten, der als Master fungiert. Auf diesem Knoten werden einige zusätzliche Dienste ausgeführt, z. B. ein API-Server und ein Controller-Manager.

In diesem Handbuch verwenden wir die folgenden Details:

Hostname	Public IPv4	Private IPv4	Role
coreos-1	192.168.2.1	10.120.0.1	Master
coreos-2	192.168.2.2	10.120.0.2	Minion1
coreos-3	192.168.2.3	10.120.0.3	Minion2

In der folgenden Konfiguration wird der Master auch ein voll funktionsfähiger Minion-Server sein, der in der Lage ist, die Arbeit abzuschließen. Die Idee für diese Konfiguration stammt von Brian Ketelsons Anleitung zum Einrichten von Kubernetes unter CoreOS hier.

Wenn Sie den obigen Anweisungen zum Erstellen des Clusters gefolgt sind, sollten sowohl "+ etcd " als auch " fleet +" so konfiguriert sein, dass die private IPv4-Adresse jedes Servers für die Kommunikation verwendet wird. Die öffentliche IP-Adresse kann zum Herstellen einer Verbindung von Ihrem lokalen Computer aus verwendet werden.

In diesem Handbuch wird dieser grundlegende CoreOS-Cluster verwendet und eine Reihe von Diensten darüber installiert.

Zuerst konfigurieren wir "+ flannel +", eine Netzwerkstrukturschicht, die jedem Computer ein eigenes Subnetz für die Containerkommunikation zur Verfügung stellt. Dies ist ein relativ neues CoreOS-Projekt, das größtenteils zur Anpassung an Kubernetes Annahmen über die Netzwerkumgebung erstellt wurde.

Wir werden Docker so konfigurieren, dass diese Netzwerkebene für Bereitstellungen verwendet wird. Darüber hinaus werden wir Kubernetes einrichten. Dies beinhaltet eine Reihe von Stücken. Wir müssen einen Proxy-Service, eine API-Schicht und ein Pod-Verwaltungssystem auf Knotenebene namens Kubelet konfigurieren.

Erstellen Sie die Flannel Network Fabric-Ebene

Als erstes müssen wir den Dienst + flannel + konfigurieren. Dies ist die Komponente, die für jeden Computer im Cluster einzelne Subnetze bereitstellt. Docker wird so konfiguriert, dass es dies für Bereitstellungen verwendet. Da dies eine Grundvoraussetzung ist, ist es ein großartiger Ort, um anzufangen.

Zum Zeitpunkt dieses Schreibens gibt es keine vorgefertigten Binärdateien von + flannel +, die vom Projekt bereitgestellt werden. Aus diesem Grund müssen wir die Binärdatei erstellen und selbst installieren. Um Build-Zeit zu sparen, bauen wir dies auf einem einzelnen Computer und übertragen die ausführbare Datei später auf unsere anderen Knoten.

Wie viele Teile von CoreOS ist Flannel in der Programmiersprache Go erstellt. Anstatt eine vollständige Go-Umgebung zum Erstellen des Pakets einzurichten, verwenden wir einen für diesen Zweck vorgefertigten Container. Google unterhält einen Go-Container speziell für diese Art von Situationen.

Alle Anwendungen, die wir installieren, werden im Verzeichnis "+ / opt / bin +" abgelegt, das in CoreOS nicht automatisch erstellt wird. Erstellen Sie jetzt das Verzeichnis:

sudo mkdir -p /opt/bin

Jetzt können wir das Projekt mit dem Go-Container erstellen. Führen Sie einfach diesen Docker-Befehl aus, um das Image von Docker Hub abzurufen, den Container auszuführen und das Paket im Container herunterzuladen und zu erstellen:

docker run -i -t google/golang /bin/bash -c "go get github.com/coreos/flannel"

Wenn der Vorgang abgeschlossen ist, können wir die kompilierte Binärdatei aus dem Container kopieren. Zuerst müssen wir die Container-ID kennen:

docker ps -l -q

Das Ergebnis ist die ID, die so aussieht:

Wir können diese ID verwenden, um eine Kopieroperation in das Verzeichnis "+ / opt / bin " anzugeben. Die Binärdatei wurde unter " / gopath / bin / flannel " im Container abgelegt. Da das Verzeichnis " / opt / bin " von unserem " core " - Benutzer nicht beschrieben werden kann, müssen wir " sudo +" verwenden:

sudo docker cp :/gopath/bin/flannel /opt/bin/

Wir haben jetzt Flanell auf unserer ersten Maschine. Etwas später werden wir dies auf unsere anderen Computer kopieren.

Erstellen Sie die Kubernetes-Binärdateien

Kubernetes besteht aus vielen verschiedenen Anwendungen und Schichttechnologien. Derzeit enthält das Projekt keine vorgefertigten Binärdateien für die verschiedenen Komponenten, die wir benötigen. Wir werden sie stattdessen selbst bauen.

Wir werden diesen Vorgang nur auf einem unserer Server abschließen. Da unsere Server von Natur aus einheitlich sind, können wir unnötige Erstellungszeiten vermeiden, indem wir einfach die von uns erstellten Binärdateien übertragen.

Der erste Schritt ist das Klonen des Projekts aus seinem GitHub-Repository. Wir werden es in unser Home-Verzeichnis klonen:

cd ~
git clone https://github.com/GoogleCloudPlatform/kubernetes.git

Als nächstes gehen wir in das Erstellungsverzeichnis im Repository. Von hier aus können wir die Binärdateien mit einem mitgelieferten Skript erstellen:

cd kubernetes/build
./release.sh

Dieser Vorgang wird ziemlich lange dauern. Es wird ein Docker-Container gestartet, um die erforderlichen Binärpakete zu erstellen.

Wenn der Erstellungsprozess abgeschlossen ist, können Sie die Binärdateien im Verzeichnis + ~ / kubernetes / _output / dockerized / bin / linux / amd64 + finden:

cd ~/kubernetes/_output/dockerized/bin/linux/amd64
ls

e2e          kube-apiserver           kube-proxy      kubecfg  kubelet
integration  kube-controller-manager  kube-scheduler  kubectl  kubernetes

Wir werden diese in das Verzeichnis "+ / opt / bin +" übertragen, das wir zuvor erstellt haben:

sudo cp * /opt/bin

Unsere erste Maschine verfügt nun über alle für unser Projekt erforderlichen Binärdateien. Wir können uns jetzt darauf konzentrieren, diese Anwendungen auf unseren anderen Servern zu installieren.

Übertragen Sie ausführbare Dateien auf Ihre anderen Server

Unsere erste Maschine verfügt über alle Komponenten, die zum Starten eines Kubernetes-Clusters erforderlich sind. Wir müssen diese jedoch auf unsere anderen Computer kopieren, bevor dies funktioniert.

Da Kubernetes keine einheitliche Installation ist (es gibt einen Master und mehrere Minions), benötigt jeder Host nicht alle Binärdateien. Jeder Minion-Server benötigt nur die ausführbaren Programme Scheduler, Docker, Proxy, Kubelet und Flannel.

Durch die Übertragung aller ausführbaren Dateien erhalten wir jedoch später mehr Flexibilität. Es ist auch einfacher. Wir werden alles in diesem Leitfaden übertragen.

Wenn Sie eine Verbindung zu Ihrem ersten Computer hergestellt haben, sollten Sie Ihre SSH-Agenteninformationen weitergeleitet haben, indem Sie eine Verbindung mit dem Flag "+ -A +" herstellen (nachdem Sie den Agenten gestartet und Ihren Schlüssel hinzugefügt haben). Dies ist ein wichtiger Schritt. Trennen Sie die Verbindung und stellen Sie die Verbindung wieder her, wenn Sie dieses Flag nicht zuvor bestanden haben.

Sie müssen die Befehle + eval + und + ssh-add + im Abschnitt * Step 2-Authenticate * von https://www.digitalocean.com/community/tutorials/how-to-connect-to- ausführen. your-droplet-with-ssh # ssh-login-as-root [dieses Tutorial] vor dem Verbinden mit + -A +.

Beginnen Sie, indem Sie in das Verzeichnis wechseln, in dem wir unsere Binärdateien abgelegt haben:

cd /opt/bin

Jetzt können wir die Dateien in diesem Verzeichnis auf unsere anderen Hosts kopieren. Wir werden dies tun, indem wir die ausführbaren Dateien direkt auf den Standard unserer Shell auslagern. Wir leiten dies dann in unseren SSH-Befehl weiter, wo wir uns mit einem unserer anderen Hosts verbinden.

Der von uns verwendete SSH-Befehl erstellt das Verzeichnis "+ / opt / bin +" auf unserem anderen Host, wechselt in das Verzeichnis und entpackt die Informationen, die er über den SSH-Tunnel empfängt. Der gesamte Befehl sieht folgendermaßen aus:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Dadurch werden alle ausführbaren Dateien an die von Ihnen angegebene IP-Adresse übertragen. Führen Sie den Befehl mit Ihrem dritten Host erneut aus:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Sie haben jetzt alle ausführbaren Dateien auf Ihren drei Computern installiert.

Einrichten von masterspezifischen Diensten

Der nächste Schritt besteht darin, unsere Unit-Dateien "+ systemd +" einzurichten, um unsere neuen Anwendungen korrekt zu konfigurieren und zu starten. Zunächst behandeln wir die Anwendungen, die nur auf unserem Master-Server ausgeführt werden.

Wir werden diese Dateien im Verzeichnis + / etc / systemd / system + ablegen. Bewege dich jetzt dorthin:

cd /etc/systemd/system

Jetzt können wir mit der Erstellung unserer Servicedateien beginnen. Wir werden nur zwei Dateien auf dem Master erstellen und fünf Dateien, die ebenfalls zu den Minions gehören. Alle diese Dateien befinden sich in + / etc / systemd / system / *. Service +.

Masterdateien:

+ apiserver.service
+ controller-manager.service

Minion-Dateien für alle Server:

+ scheduler.service
+ flannel.service +
+ docker.service
+ proxy.service
+ kubelet.service

Erstellen Sie die API Server Unit-Datei

Die erste Datei, die wir konfigurieren werden, ist die Unit-Datei des API-Servers. Der API-Server dient zum Bereitstellen von Informationen zum Cluster, zum Verarbeiten von Post-Requests zum Ändern von Informationen, zum Planen der Arbeit auf den einzelnen Servern und zum Synchronisieren freigegebener Informationen.

Wir werden diese Unit-Datei der Einfachheit halber "+ apiserver.service +" nennen. Erstellen und öffnen Sie diese Datei jetzt:

sudo vim apiserver.service

In dieser Datei beginnen wir mit den grundlegenden Metadaten zu unserem Service. Wir müssen sicherstellen, dass dieses Gerät nicht gestartet wird, bevor die Dienste "+ etcd +" und "Docker" ausgeführt werden:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Als nächstes vervollständigen wir den Abschnitt "+ [Service] +". Dies wird hauptsächlich verwendet, um den API-Server mit einigen Parametern zu starten, die unsere Umgebung beschreiben. Wir werden auch Neustartbedingungen einrichten:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

Der obige Abschnitt legt die Netzwerkadresse und den Port fest, an dem der Server ausgeführt wird, sowie den Ort, an dem "+ etcd " empfangsbereit ist. Der Parameter " portal_net " gibt den Netzwerkbereich an, den der " flannel +" - Dienst verwenden wird.

Nachdem wir den Dienst gestartet haben, überprüfen wir, ob er in einer Schleife ausgeführt wird. Dies stellt sicher, dass der Dienst tatsächlich Verbindungen akzeptieren kann, bevor die abhängigen Dienste initiiert werden. Ist dies nicht der Fall, kann dies zu Fehlern in den abhängigen Diensten führen, die einen manuellen Neustart erfordern würden.

Schließlich müssen wir dieses Gerät installieren. Wir können dies mit einem "+ [Install] +" - Abschnitt tun, der unseren Host anweist, diesen Dienst zu starten, wenn die Maschine vollständig gebootet ist:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Wenn Sie fertig sind, schließen Sie die Datei.

Erstellen Sie die Controller Manager Unit-Datei

Das nächste Stück, das Kubernetes benötigt, ist der Controller Manager-Server. Diese Komponente wird verwendet, um die Datenreplikation zwischen den Cluster-Einheiten durchzuführen.

Öffnen Sie eine Datei mit dem Namen "+ controller-manager.service +" im selben Verzeichnis:

sudo vim controller-manager.service

Wir beginnen erneut mit den grundlegenden Metadaten. Dies folgt dem gleichen Format wie die letzte Datei. Zusätzlich zu den anderen Abhängigkeiten muss dieser Dienst nach der soeben konfigurierten API-Servereinheit gestartet werden:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

Für den Teil "+ [Service] +" dieser Datei müssen nur einige Parameter an die ausführbare Datei übergeben werden. Hauptsächlich richten wir die Anwendung auf den Speicherort unseres API-Servers. Hier haben wir die privaten IP-Adressen der einzelnen Computer durch Kommas getrennt übergeben. Ändern Sie diese Werte, um Ihre eigene Konfiguration widerzuspiegeln. Auch hier stellen wir sicher, dass dieses Gerät bei einem Fehler neu gestartet wird, da es für die ordnungsgemäße Funktion unseres Kubernetes-Clusters erforderlich ist:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

Wir werden auch die gleichen Installationsanweisungen verwenden, damit dieses Gerät auch beim Booten startet:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Einrichten von Clusterdiensten

Nachdem wir unsere masterspezifischen Services konfiguriert haben, können wir die Einheitendateien konfigurieren, die auf * allen * unseren Maschinen vorhanden sein müssen. Das bedeutet, dass Sie diese Dateien sowohl dem Master- als auch dem Minion-Server hinzufügen und entsprechend konfigurieren sollten.

Diese fünf Dateien sollten auf allen Rechnern in + / etc / systemd / system / *. Service + erstellt werden.

+ scheduler.service
+ flannel.service +
+ docker.service
+ proxy.service
+ kubelet.service

Erstellen Sie die Scheduler-Unit-Datei

Die nächste Komponente ist der Scheduler. Der Scheduler entscheidet, auf welchem Minion Workloads ausgeführt werden sollen, und kommuniziert, um dies sicherzustellen.

Erstellen und öffnen Sie jetzt eine Datei für dieses Gerät:

sudo vim scheduler.service

Dieses Gerät startet auf die gleiche Weise wie das letzte. Es hat Abhängigkeiten von allen gleichen Diensten:

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

Der Servicebereich selbst ist sehr unkompliziert. Wir müssen die ausführbare Datei nur auf die Netzwerkadresse und den Port verweisen, auf dem sich der API-Server befindet. Im Falle eines Fehlers werden wir den Dienst erneut starten.

Der Installationsabschnitt spiegelt die anderen, die wir bisher gesehen haben, wider:

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-scheduler -master=127.0.0.1:8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Wenn Sie fertig sind, speichern und schließen Sie die Datei.

Erstellen Sie die Flanel Unit-Datei

Die nächste Komponente, die wir zum Laufen bringen müssen, ist + flannel +, unsere Netzwerk-Fabric-Schicht. Hiermit wird jedem Knoten ein eigenes Subnetz für Docker-Container zugewiesen.

Wechseln Sie erneut auf jedem Ihrer Computer in das Konfigurationsverzeichnis "+ systemd +":

cd /etc/systemd/system

Erstellen und öffnen Sie die Unit-Datei + flannel + in Ihrem Texteditor:

sudo vim flannel.service

In dieser Datei beginnen wir mit den Metadateninformationen. Da dieser Dienst "+ etcd " benötigt, um die Subnetzinformationen zu registrieren, müssen wir dies nach " etcd +" starten:

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

Für den Abschnitt "+ [Service] " werden wir zuerst die Datei " / etc / environment +" als Quelle verwenden, damit wir auf die private IP-Adresse unseres Hosts zugreifen können.

Der nächste Schritt besteht darin, eine Zeile "+ ExecStartPre = " einzufügen, die versucht, den Subnetzbereich mit " etcd " zu registrieren. Es wird kontinuierlich versucht, sich bei etcd zu registrieren, bis es erfolgreich ist. Wir werden den Bereich " 10.100.0.0 / 16 +" für diesen Leitfaden verwenden.

Dann starten wir "+ flannel +" mit der privaten IP-Adresse, die wir aus der Umgebungsdatei beziehen.

Danach wollen wir überprüfen, ob + flannel + seine Informationen in seine Datei geschrieben hat (damit Docker sie sofort lesen kann) und schlafen, wenn dies nicht der Fall ist. Dadurch wird sichergestellt, dass der Docker-Dienst nicht versucht, die Datei zu lesen, bevor sie verfügbar ist (dies kann auf dem ersten Server geschehen, der online geschaltet wird). Wir konfigurieren den Neustart mit den üblichen Parametern und installieren das Gerät erneut mit + multi-user.target +:

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/bin/bash -c "until /usr/bin/etcdctl set /coreos.com/network/config '{\"Network\": \"10.100.0.0/16\"}'; do echo \"waiting for etcd to become available...\"; sleep 5; done"
ExecStart=/opt/bin/flannel -iface=${COREOS_PRIVATE_IPV4}
ExecStartPost=-/bin/bash -c "until [ -e /run/flannel/subnet.env ]; do echo \"waiting for write.\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Erstellen Sie dieselbe Datei auf Ihren anderen Hosts.

Erstellen Sie die Docker Unit-Datei

Die nächste Datei, die wir erstellen, bezieht sich nicht wirklich auf die ausführbaren Dateien in unserem + / opt / bin + Verzeichnis. Wir müssen eine Docker-Servicedatei erstellen, damit der Service mit Kenntnis des soeben konfigurierten Netzwerk-Overlays "+ flannel +" gestartet wird.

Erstellen Sie die entsprechende Unit-Datei mit Ihrem Texteditor:

sudo vim docker.service

Beginnen Sie mit den üblichen Metadaten. Wir benötigen dies, um zu starten, nachdem der Dienst "+ flannel +" konfiguriert und online geschaltet wurde:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

Für den Abschnitt "+ [Service] " müssen wir die Datei " flannel +" verwenden, um die Umgebungsvariablen zu speichern, die erstellt werden. Hier werden die Subnetzinformationen des aktuellen Hosts angezeigt.

Wir fahren dann die aktuelle + docker0 + Bridge-Schnittstelle herunter und löschen sie. Dies ermöglicht es uns, Docker mit einem sauberen Slate neu zu starten. Der Prozess konfiguriert die Schnittstelle "+ docker0 " unter Verwendung der Netzwerkinformationen " flannel +".

Wir verwenden dieselben Neustart- und "+ [Installieren] +" -Details, die wir bei unseren anderen Einheiten verwendet haben:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

[Service]
EnvironmentFile=/run/flannel/subnet.env
ExecStartPre=-/usr/bin/ip link set dev docker0 down
ExecStartPre=-/usr/sbin/brctl delbr docker0
ExecStart=/usr/bin/docker -d -s=btrfs -H fd:// --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Erstellen Sie dieselbe Datei auf jedem Ihrer Hosts.

Erstellen Sie die Proxy-Unit-Datei

Die nächste zu diskutierende logische Einheit ist der Proxyserver, den jedes Clustermitglied ausführt. Der Kubernetes-Proxyserver wird zum Weiterleiten und Weiterleiten von Datenverkehr zu und von Containern verwendet.

Öffnen Sie eine Proxy-Unit-Datei mit Ihrem Texteditor:

sudo vim proxy.service

Für den Metadatenabschnitt müssen Abhängigkeiten von + etcd + und Docker definiert werden. Für den Abschnitt "+ [Service] " müssen wir nur die ausführbare Datei mit der lokalen " etcd +" - Serveradresse starten. Die Neustartkonfiguration und die Installationsdetails spiegeln unsere vorherigen Servicedateien wider:

[Unit]
Description=Kubernetes proxy server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-proxy -etcd_servers=http://127.0.0.1:4001 -logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Speichern Sie die Datei, wenn Sie fertig sind. Erstellen Sie dieselbe Datei auf jedem Ihrer Hosts.

Erstellen Sie die Kubelet Unit-Datei

Jetzt erstellen wir die Kubelet-Unit-Datei. Diese Komponente wird zum Verwalten von Containerbereitstellungen verwendet. Es stellt sicher, dass sich die Container in dem Zustand befinden, in dem sie sein sollen, und überwacht das System auf Änderungen des gewünschten Zustands der Bereitstellungen.

Erstellen und öffnen Sie die Datei in Ihrem Texteditor:

sudo vim kubelet.service

Der Metadatenabschnitt enthält die gleichen Abhängigkeitsinformationen zu "+ etcd +" und Docker:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Für den Abschnitt "+ [Service] " müssen wir erneut die Datei " / etc / environment " als Quelle verwenden, um Zugriff auf die private IP-Adresse des Hosts zu erhalten. Wir rufen dann die ausführbare Datei " kubelet " auf und setzen ihre Adresse und ihren Port. Wir überschreiben auch den Hostnamen, um dieselbe private IP-Adresse zu verwenden und den Dienst auf die lokale " etcd +" - Instanz zu verweisen. Wir stellen die gleichen Neustart- und Installationsdetails bereit, die wir verwendet haben:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
EnvironmentFile=/etc/environment
ExecStart=/opt/bin/kubelet \
-address=${COREOS_PRIVATE_IPV4} \
-port=10250 \
-hostname_override=${COREOS_PRIVATE_IPV4} \
-etcd_servers=http://127.0.0.1:4001 \
-logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Aktivieren der Dienste

Nachdem Sie alle Ihre Servicedateien gestartet haben, können Sie diese Einheiten aktivieren. Dabei werden die Informationen im Abschnitt "+ [Install] +" jeder Einheit verarbeitet.

Da unsere Einheiten angeben, dass sie vom Mehrbenutzerziel gewünscht werden, bedeutet dies, dass alle unsere Dienste automatisch gestartet werden, wenn das System versucht, den Server in den Mehrbenutzermodus zu versetzen.

Wechseln Sie dazu in Ihr Verzeichnis "+ / etc / systemd / system":

cd /etc/systemd/system

Von hier aus können wir alle Skripte aktivieren:

sudo systemctl enable *

Dadurch wird ein Verzeichnis "+ multi-user.target.wants " mit symbolischen Links zu unseren Gerätedateien erstellt. Dieses Verzeichnis wird von " systemd +" gegen Ende des Startvorgangs verarbeitet.

Wiederholen Sie diesen Schritt auf jedem Ihrer Server.

Nachdem wir unsere Dienste aktiviert haben, können wir die Server der Reihe nach neu starten.

Wir werden mit dem Master-Server beginnen, aber Sie können dies in beliebiger Reihenfolge tun. Es ist zwar kein Neustart erforderlich, um diese Dienste zu starten, dies stellt jedoch sicher, dass unsere Gerätedateien so geschrieben wurden, dass eine nahtlose Abhängigkeitskette möglich ist:

sudo reboot

Sobald der Master wieder online ist, können Sie Ihre Minion-Server neu starten:

sudo reboot

Sobald alle Ihre Server online sind, stellen Sie sicher, dass Ihre Dienste ordnungsgemäß gestartet wurden. Sie können dies überprüfen, indem Sie Folgendes eingeben:

systemctl status

Oder Sie können ins Tagebuch gehen, indem Sie Folgendes eingeben:

journalctl -b -u

Suchen Sie nach einem Hinweis, dass die Dienste ordnungsgemäß ausgeführt werden. Bei Problemen kann ein Neustart des jeweiligen Dienstes hilfreich sein:

sudo systemctl restart

Wenn Sie fertig sind, sollten Sie in der Lage sein, Ihre Computer von Ihrem Master-Server aus anzuzeigen. Überprüfen Sie nach der Anmeldung bei Ihrem Masterserver, ob alle Server verfügbar sind, indem Sie Folgendes eingeben:

kubecfg list minions

Minion identifier
----------

In einem zukünftigen Handbuch wird erläutert, wie Sie mithilfe von Kubernetes Dienste auf Ihrem CoreOS-Cluster planen und steuern können.

Fazit

Sie sollten jetzt Kubernetes in Ihrem CoreOS-Cluster einrichten. Auf diese Weise erhalten Sie eine hervorragende Verwaltungs- und Planungsoberfläche für die Arbeit mit Diensten in logischen Gruppierungen.

Sie haben wahrscheinlich bemerkt, dass die obigen Schritte zu einem sehr manuellen Vorgang führen. Ein großer Teil davon ist, dass wir die Binärdateien auf unseren Maschinen erstellt haben. Wenn Sie die Binärdateien auf einem Webserver hosten möchten, auf den in Ihrem privaten Netzwerk zugegriffen werden kann, können Sie die Binärdateien herunterladen und automatisch konfigurieren, indem Sie spezielle Cloud-Konfigurationsdateien erstellen.

Cloud-Konfigurationsdateien sind so flexibel, dass Sie die meisten Gerätedateien ohne Änderungen einfügen können (mit Ausnahme der Datei "+ apiserver.service +", die Zugriff auf die IP-Adressen jedes Knotens benötigt) und sie als CoreOS starten können Knoten wird gebootet. Dies liegt außerhalb des Geltungsbereichs dieses Handbuchs, ist jedoch ein guter nächster Schritt zur Automatisierung des Prozesses.

TOC