Hallo Techies, in unserem vorherigen Tutorial haben wir bereits die Installationsschritte von Kubernetes auf CentOS 7 / RHEL 7 besprochen. In diesem Tutorial werden wir besprechen, wie wir Pods, Replication Controller und Service bereitstellen können.
Ich gehe davon aus, dass das Kubernetes-Setup bereits ausgeführt wird. Falls dies nicht der Fall ist, lesen Sie die folgende Anleitung:
-
So installieren Sie Kubernetes (k8s) 1.7 auf CentOS 7 / RHEL 7
Lassen Sie uns nun in die Pod-Bereitstellung einsteigen. Pod ist ein Multi-Tier oder eine Gruppe von Containern, die auf einem beliebigen Worker-Knoten oder Minion gestartet wird. Um einen Pod bereitzustellen, müssen wir zuerst eine yml- oder json-Datei auf dem Master-Knoten oder in einem System erstellen, auf dem das kubectl-Tool installiert ist. Kubectl verwendet die yml-Datei und stellt eine Verbindung zum kube-apiserver her auf Port 6443 und dann stellt kube-apiserver eine Verbindung zu kube-controller-manager her und Kube-controller-manager verbindet sich weiter mit Kube-Scheduler und das Scheduler-Programm stellt über kubelet eine Verbindung zu Worker-Knoten her Der Agent und dann der Kubelet-Agent verbinden sich mit dem Docker-Daemon auf dem Knoten und starten einen Container basierend auf der Pod-Definition.
Bevor Sie mit dem Erstellen der Pod-YML-Datei beginnen, stellen Sie zunächst sicher, dass Sie ein Test-Docker-Image auf dem Docker-Hub haben. In meinem Fall habe ich bereits ein Docker-Image (linuxtechi/web-server-php) auf den Docker-Hub gepusht.
Lassen Sie uns nun eine Datei pod.yml auf dem Masterserver erstellen.
[[email protected] ~]# mkdir /techcode [[email protected] ~]# cd /techcode/ [[email protected] techcode]# vi pod.yml apiVersion: v1 kind: Pod metadata: name: web-server-pod labels: app: webserver-app1 region: IN rack: r1 version: "1.1" spec: containers: - name: web-server-test-container image: linuxtechi/web-server-php:testversion ports: - containerPort: 80
Speichern und beenden Sie die Datei.
In der Datei, in der wir apiversion als v1 angegeben haben, können Sie die apiversion aus der Datei „/root/.kube/config“ verifizieren, geben Sie Kind als „Pod“ an “, während wir den Pod mit dieser yml-Datei bereitstellen. Geben Sie die Metadaten und das Label für den Pod an.
Abgesehen davon haben wir die Spezifikation für den Container wie „Image Name“ und den vom Container bereitgestellten Port usw. erwähnt.
Verwenden Sie unten „kubectl ‘ Befehl zum Bereitstellen des Pods.
[[email protected] techcode]# kubectl create -f pod.yml pod "web-server-pod" created [[email protected] techcode]#
Überprüfen Sie den Pod-Status vom Master-Knoten mit dem folgenden Befehl
[[email protected] ~]# kubectl get pods NAME READY STATUS RESTARTS AGE web-server-pod 1/1 Running 0 4m [[email protected] ~]# [[email protected] ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE web-server-pod 1/1 Running 0 4m 10.32.0.2 worker-node2 [[email protected] ~]#
Gemäß der obigen Ausgabe wurde der Pod auf Worker-Knoten 2 bereitgestellt. Wir können nicht auf die Anwendung zugreifen, die im Pod ausgeführt wird, da wir bisher keine Patting- oder Natting-Regel für den Pod festgelegt haben.
Lassen Sie uns eine Regel so erstellen, dass jede Anfrage, die an der IP-Adresse des Worker-Knotens 2 an einem bestimmten Port eingeht, an den Pod (Web-Server-Pod) an Port 80 umgeleitet werden soll. Dies kann mit Service erreicht werden. Ein Dienst kann entweder über einen Befehl oder über eine yml-Datei definiert werden.
Erstellen eines Dienstes von der Befehlszeile aus mit „kubectl Expose“
[[email protected] ~]# kubectl expose pods web-server-pod --name=webpod-service --target-port=80 --type=NodePort service "webpod-service" exposed [[email protected] ~]#
Der obige Befehl macht den Pod oder Container der Außenwelt zugänglich. Es generiert den zufälligen Port auf dem Knoten, auf dem Pods erstellt werden, und wir können sagen, dass der obige Befehl die Patting-Aufgabe für uns erledigt. Externe Benutzer können mit der Knoten-IP zusammen mit dem zufälligen Port auf meinen Webserver zugreifen, der im Pod ausgeführt wird.
Überprüfen Sie den Dienststatus mit den folgenden Befehlen
[[email protected] ~]# kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes 10.96.0.1 <none> 443/TCP 2h webpod-service 10.101.51.190 <nodes> 80:30108/TCP 2m [[email protected] ~]# [[email protected] ~]# kubectl get svc -o wide NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes 10.96.0.1 <none> 443/TCP 2h <none> webpod-service 10.101.51.190 <nodes> 80:30108/TCP 3m app=webserver-app1,rack=r1,region=IN,version=1.1 [[email protected] ~]#
Versuchen Sie nun, auf den Webserver zuzugreifen
~]# curl 192.168.1.50:30108
Wir können den oben erstellten Dienst mit dem folgenden Befehl löschen
[[email protected] ~]# kubectl delete svc webpod-service service "webpod-service" deleted [[email protected] ~]#
Dienst mit YML-Datei erstellen
Erstellen Sie eine neue yml-Datei mit dem Namen „service.yml“. ‘ mit folgendem Inhalt. Diesmal ist der Art-Parameterwert „Service“. Unter dem Feld Spezifikation wird der Port angegeben, auf dem der Webserver oder die Anwendung im Container ausgeführt wird, und NodePort ist ein zufälliger Port auf dem Arbeitsknoten. Der Selektor gibt an, dass dieser Dienst für den Pod gilt, dessen Versionsparameter „1.1“ ist. In unserem Fall gilt dieser Dienst also für den Pod „web-server-pod“
[[email protected] techcode]# vi service.yml apiVersion: v1 kind: Service metadata: name: webpod-service labels: app: webpod-service-label spec: type: NodePort ports: - port: 80 nodePort: 30001 protocol: TCP selector: version: "1.1"
Erstellen Sie nun den Dienst, indem Sie den folgenden Befehl ausführen
[[email protected] techcode]# kubectl create -f service.yml service "webpod-service" created [[email protected] techcode]#
Lassen Sie uns den Dienststatus mit dem folgenden Befehl überprüfen
[[email protected] techcode]# kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes 10.96.0.1 <none> 443/TCP 2h webpod-service 10.102.18.35 <nodes> 80:30001/TCP 1m [[email protected] techcode]# [[email protected] techcode]# kubectl get svc -o wide NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes 10.96.0.1 <none> 443/TCP 2h <none> webpod-service 10.102.18.35 <nodes> 80:30001/TCP 2m version=1.1 [[email protected] techcode]#
Greifen Sie nun mit dem Curl-Befehl auf Ihre Anwendung zu:
[[email protected] ~]# curl http://192.168.1.50:30001
Die Ausgabe wäre so etwas wie unten
Bis jetzt haben wir einen Pod und seinen Dienst bereitgestellt. Nehmen wir an, ich möchte 5 Pods der gleichen Art bereitstellen, dann kann es mit dem Replikationscontroller bereitgestellt werden. Kurz gesagt, es heißt "rc". ‘. Wann immer wir Pods mit rc bereitstellen, sind Pods hochverfügbar und fehlertolerant, das heißt, wenn etwas mit Pods schief geht, werden Pods der gleichen Art automatisch vom Cluster bereitgestellt.
Replication Controller bereitstellen
Der Replikationscontroller wird auch mit der yml-Datei mithilfe des kubectl-Befehls bereitgestellt. Lassen Sie uns eine yml-Datei für rc erstellen.
[[email protected] techcode]# vi replication-controller.yml apiVersion: v1 kind: ReplicationController metadata: name: webserver-rc spec: replicas: 5 selector: app: lamp-app1 template: metadata: labels: app: lamp-app1 region: IN rack: r1 version: "1.1" spec: containers: - name: webserver-php-con1 image: linuxtechi/web-server-php:testversion ports: - containerPort: 80
Dieser Parameterwert für die Zeitart ist „ReplicationController “ und unter Spezifikation haben wir „replicas=5 ‘, bedeutet dies, dass 5 Pods über Worker-Knoten mithilfe des Docker-Images „linuxtechi/web-server-php:testversion“ bereitgestellt werden
Führen Sie den folgenden Befehl aus, um den Replikationscontroller bereitzustellen
[[email protected] techcode]# kubectl create -f replication-controller.yml replicationcontroller "webserver-rc" created [[email protected] techcode]#
Überprüfen Sie den Pod-Status und sehen Sie, wo sie bereitgestellt wurden
[[email protected] techcode]# kubectl get pods [[email protected] techcode]# kubectl get pods -o wide
Überprüfen Sie den Status des Replikationscontrollers mit dem folgenden kubectl-Befehl
[[email protected] techcode]# kubectl get rc NAME DESIRED CURRENT READY AGE webserver-rc 5 5 5 5m [[email protected] techcode]# kubectl get rc -o wide NAME DESIRED CURRENT READY AGE CONTAINER(S) IMAGE(S) SELECTOR webserver-rc 5 5 5 5m webserver-php-con1 linuxtechi/web-server-php:testversion app=lamp-app1 [[email protected] techcode]#
Lassen Sie uns den Dienst für den oben erstellten Replikationscontroller definieren.
[[email protected] techcode]# vi rc-service.yml apiVersion: v1 kind: Service metadata: name: webserver-service labels: app: webserver-service-label spec: type: NodePort ports: - port: 80 nodePort: 30002 protocol: TCP selector: version: "1.1"
Erstellen Sie den Dienst mit dem kubectl-Befehl
[[email protected] techcode]# kubectl create -f rc-service.yml service "webserver-service" created [[email protected] techcode]#
Rufen Sie den Status des Dienstes mit dem folgenden kubectl-Befehl ab
[[email protected] techcode]# kubectl get svc -o wide NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes 10.96.0.1 <none> 443/TCP 3h <none> webserver-service 10.111.34.34 <nodes> 80:30002/TCP 1m version=1.1 [[email protected] techcode]#
Versuchen Sie nun, von beiden Knoten aus auf den Webserver zuzugreifen
[[email protected] ~]# curl http://192.168.1.40:30002
[[email protected] ~]# curl http://192.168.1.50:30002
Gemäß der obigen Ausgabe können wir über die IP-Adresse beider Worker-Knoten auf unseren Webserver zugreifen. Wann immer wir mit Worker-Knoten-IP auf den Webserver zugreifen, wird die Anforderung automatisch zwischen den Pods auf den Knoten verteilt.
Damit ist der Artikel abgeschlossen. Bitte teilen Sie uns Ihr Feedback und Ihre Kommentare mit, falls dieser Artikel dabei hilft, Pods, Dienste und Replikationscontroller bereitzustellen und zu verstehen.