|NO.Z.00155|——————————|CloudNative|——|KuberNetes&服務釋出.V06|-------------------------------------------------------|service.v02|service代理內部服務|
阿新 • • 發佈:2022-03-30
[CloudNative:KuberNetes&服務釋出.V06] [Applications.KuberNetes] [|DevOps|k8s|服務釋出|在k8s中如何釋出服務|service|使用service代理k8s內部服務|]
一、service:建立nginx-deployment
### --- 建立nginx-deployment.yaml配置檔案 [root@k8s-master01 ~]# cat nginx-deploy.yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx namespace: default spec: progressDeadlineSeconds: 600 replicas: 2 revisionHistoryLimit: 10 selector: matchLabels: app: nginx strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: creationTimestamp: null labels: app: nginx spec: containers: - image: nginx:1.15.2 imagePullPolicy: IfNotPresent name: nginx resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30
### --- 建立nginx-deployment服務
[root@k8s-master01 ~]# kubectl create -f nginx-deploy.yaml
deployment.apps/nginx created
### --- 檢視建立的pod ~~~ 起來之後會有一個IP地址,且每個nginx起來之後會暴露一個80埠; ~~~ 若是使用curl訪問地址,是可以訪問到主頁的 [root@k8s-master01 ~]# kubectl get po -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES busybox 1/1 Running 8 18h 172.25.244.211 k8s-master01 <none> <none> nginx-66bbc9fdc5-5mwvb 1/1 Running 0 49s 172.25.244.212 k8s-master01 <none> <none> nginx-66bbc9fdc5-lm5xz 1/1 Running 0 49s 172.18.195.15 k8s-master03 <none> <none>
二、為pod引入service的必要性### --- 測試pod地址是否正常解析 ~~~ 我們既然可以使用IP地址訪問到主頁,那麼我們為什麼要引入一個Pod呢? ~~~ 在傳統部署中,部署之後宿主機就固定了,一般情況下是不會發生變化的。 ~~~ 所以說宿主機的IP地址和埠是不會發生變化的。所以說可以通過宿主機和埠訪問到這個地址服務 ~~~ 但是在k8s中,沒做一次更新或者每刪除一次pod,它的IP地址都會發生一次更改, ~~~ 重新申請一個PodIP地址 [root@k8s-master01 ~]# curl 172.25.244.212 <h1>Welcome to nginx!</h1>
### --- 刪除pod後容器的地址發生變化
~~~ 檢視建立的pod
[root@k8s-master01 ~]# kubectl get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 8 19h 172.25.244.211 k8s-master01 <none> <none>
nginx-66bbc9fdc5-5mwvb 1/1 Running 0 5m1s 172.25.244.212 k8s-master01 <none> <none>
nginx-66bbc9fdc5-lm5xz 1/1 Running 0 5m1s 172.18.195.15 k8s-master03 <none> <none>
### --- 重啟pod後容器的地址發生變化
~~~ 可以看到新起的Pod的地址發生了變化
~~~ 為什麼k8s要改變這個Pod的IP地址,
~~~ 因為:k8s是隨機部署,彈性排程,而且隨時的會去保持Pod的副本數是我們期望的那個值。
~~~ 它在重建的過程中,會隨機的排程最適合自己的宿主機去部署。
~~~ 有可能會排程到之前損壞節點為宿主機。若是IP地址不發生變化,
~~~ 就會造成宿主機上這2個Pod的IP地址一致,造成網段的重複,造成網路不通的情況。
~~~ 所以說每次彈性部署的時候都會重啟建立一個新的Pod,這個Pod就會重新申請一下IP地址。
~~~ 傳統架構裡面是不會出現這種情況,因為我們是把之前的服務給停掉,在重新起來,
~~~ 但是在k8s的Pod中,是經過彈性計算的,不會去保持Pod的IP地址。
[root@k8s-master01 ~]# kubectl delete po nginx-66bbc9fdc5-5mwvb
pod "nginx-66bbc9fdc5-5mwvb" deleted
[root@k8s-master01 ~]# kubectl get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 8 19h 172.25.244.211 k8s-master01 <none> <none>
nginx-66bbc9fdc5-lm5xz 1/1 Running 0 6m29s 172.18.195.15 k8s-master03 <none> <none>
nginx-66bbc9fdc5-tq7gw 1/1 Running 0 77s 172.17.125.11 k8s-node01 <none> <none>
### --- 所以說我們不能通過Pod的IP地址去訪問服務的。
### --- 這個service可以理解為一個反向代理。
~~~ 所以k8s引出來一個理念,service:可以簡單的理解為邏輯上的一組Pod。
~~~ 一種可以訪問Pod的策略,而且其他Pod可以通過這個Service訪問到這個Service代理的Pod。
~~~ 相對於Pod而言,它會有一個固定的名稱,一旦建立就固定不變。
===============================END===============================
Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart ——W.S.Landor
來自為知筆記(Wiz)