Ciao Techies, nel nostro tutorial precedente abbiamo già discusso i passaggi di installazione di Kubernetes su CentOS 7 / RHEL 7. In questo tutorial discuteremo come distribuire pod, controller di replica e servizio.
Presumo che l'installazione di Kubernetes sia già attiva e funzionante. In caso contrario fare riferimento alla seguente guida:
-
Come installare Kubernetes (k8s) 1.7 su CentOS 7 / RHEL 7
Ora passiamo alla distribuzione del Pod. Pod è un multilivello o un gruppo di contenitori che viene avviato su qualsiasi nodo di lavoro o Minion. Per distribuire un pod, dobbiamo prima creare il file yml o json sul nodo master o in un sistema in cui è installato lo strumento kubectl. Kubectl utilizzerà il file yml e si collegherà a kube-apiserver sulla porta 6443 e quindi kube-apiserver si collegherà a kube-controller-manager e Kube-controller-manager si collegherà ulteriormente a Kube-Scheduler e il programma di pianificazione si connette ai nodi di lavoro utilizzando kubelet agent e quindi kubelet agent si connettono al daemon docker sul nodo e avviano un container basato sulla definizione del pod.
Prima di iniziare a creare il file pod yml, assicurati di avere un'immagine docker di prova sull'hub docker. Nel mio caso ho già eseguito il push di un'immagine docker (linuxtechi/web-server-php) sull'hub docker.
Ora creiamo un file pod.yml sul server master.
[[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
Salva ed esci dal file.
Nel file che abbiamo specificato apiversion come v1 , puoi eseguire la verifica incrociata dell'apiversion dal file "/root/.kube/config", Specificare Kind come "Pod ' mentre stiamo distribuendo pod usando questo file yml. Specifica i metadati e l'etichetta per il pod.
Oltre a questo abbiamo menzionato le specifiche per il contenitore come "Nome immagine" e la porta esposta dal contenitore ecc.
Usa sotto "kubectl ' comando per distribuire il pod.
[[email protected] techcode]# kubectl create -f pod.yml pod "web-server-pod" created [[email protected] techcode]#
Verifica lo stato del pod dal nodo master utilizzando il comando seguente
[[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] ~]#
Come per l'output sopra, il pod è stato distribuito sul nodo di lavoro 2. Non possiamo accedere all'applicazione in esecuzione all'interno del pod perché fino ad ora non abbiamo impostato alcuna regola di patting o natting per il pod.
Creiamo una regola in modo tale che se una richiesta arriva sull'indirizzo IP del nodo di lavoro 2 su una porta specifica, dovrebbe essere reindirizzata al pod (web-server-pod) sulla porta 80. Ciò può essere ottenuto con il servizio. Un servizio può essere definito sia da comando che tramite file yml.
Creazione del servizio dalla riga di comando utilizzando "kubectl expo"
[[email protected] ~]# kubectl expose pods web-server-pod --name=webpod-service --target-port=80 --type=NodePort service "webpod-service" exposed [[email protected] ~]#
Il comando sopra esporrà il pod o il contenitore al mondo esterno. Genererà la porta casuale sul nodo su cui vengono creati i pod e possiamo dire che il comando sopra eseguirà l'attività di patting per noi, gli utenti esterni possono raggiungere il mio server Web che è in esecuzione all'interno del pod con l'ip del nodo insieme alla porta casuale.
Verifica lo stato del servizio utilizzando i seguenti comandi
[[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] ~]#
Ora prova ad accedere al Web Server
~]# curl 192.168.1.50:30108
Possiamo eliminare il servizio sopra creato usando il seguente comando
[[email protected] ~]# kubectl delete svc webpod-service service "webpod-service" deleted [[email protected] ~]#
Creazione del servizio utilizzando il file yml
Crea un nuovo file yml con il nome "service.yml ' con il seguente contenuto. Questa volta il valore del parametro Kind sarà "Servizio". Nel campo Specifica è indicata la porta su cui è in esecuzione il server Web o l'applicazione all'interno del contenitore e NodePort è una porta casuale sul nodo di lavoro. Il selettore indica che questo servizio sarà applicabile al pod il cui parametro di versione è "1.1", quindi nel nostro caso questo servizio sarà applicabile al 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"
Ora crea il servizio eseguendo il seguente comando
[[email protected] techcode]# kubectl create -f service.yml service "webpod-service" created [[email protected] techcode]#
Verifichiamo lo stato del servizio utilizzando il comando sottostante
[[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]#
Ora accedi alla tua applicazione usando il comando curl:
[[email protected] ~]# curl http://192.168.1.50:30001
L'output sarebbe qualcosa come di seguito
A partire da ora abbiamo distribuito un pod e il suo servizio. Supponiamo di voler distribuire 5 pod dello stesso tipo, quindi può essere distribuito utilizzando il controller di replica. In breve si chiamava "rc '. Ogni volta che eseguiamo il provisioning di pod utilizzando rc, i pod saranno in alta disponibilità e tolleranza ai guasti, significa che se qualcosa va storto con il pod, il pod dello stesso tipo verrà distribuito automaticamente dal cluster.
Distribuzione del controller di replica
Il controller di replica viene distribuito anche con il file yml utilizzando il comando kubectl. Creiamo un file yml per rc.
[[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
Questo valore del parametro relativo al tipo di tempo è "ReplicationController ” e sotto specifica abbiamo 'replicas=5 ', significa che 5 pod verranno distribuiti tra i nodi di lavoro utilizzando l'immagine della finestra mobile "linuxtechi/web-server-php:testversion"
Esegui il comando seguente per distribuire il controller di replica
[[email protected] techcode]# kubectl create -f replication-controller.yml replicationcontroller "webserver-rc" created [[email protected] techcode]#
Verifica lo stato del pod e guarda dove è stato effettuato il provisioning
[[email protected] techcode]# kubectl get pods [[email protected] techcode]# kubectl get pods -o wide
Verifica lo stato del controller di replica utilizzando il comando kubectl
[[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]#
Definiamo il servizio per il controller di replica creato sopra.
[[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"
Crea il servizio usando il comando kubectl
[[email protected] techcode]# kubectl create -f rc-service.yml service "webserver-service" created [[email protected] techcode]#
Ottieni lo stato del servizio utilizzando il comando kubectl sottostante
[[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]#
Ora prova ad accedere al server web da entrambi i nodi
[[email protected] ~]# curl http://192.168.1.40:30002
[[email protetta] ~]# curl http://192.168.1.50:30002
Come per l'output sopra, possiamo accedere al nostro server web utilizzando l'indirizzo IP di entrambi i nodi di lavoro. Ogni volta che accediamo al server Web utilizzando l'ip dei nodi di lavoro, la richiesta viene bilanciata automaticamente tra i pod sui nodi.
Questo conclude l'articolo. Condividi il tuo feedback e i tuoi commenti nel caso in cui questo articolo aiuti a distribuire e comprendere i pod, il servizio e il controller di replica.