2023/05/23 更新: 為了避免本文章散落在不同網站,之後統一由部落格更新,再麻煩從部落格查看~
本文章同時發佈於:
文章為自己的經驗與夥伴整理的內容,設計沒有標準答案,如有可以改進的地方,請告訴我,我會盡我所能的修改,謝謝大家~
大家好,接下來要介紹 Istio DestinationRule 元件實作的部分,
以下的實作範例都在Code-Example中,
code 中以 server 的 pods 改為兩個,
並且新增了一個 DestinationRule 元件在DAY26/helm-digimon/templates/load-balancer.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: server
spec:
host: server
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
host
: 會對 server 這個 service 來做流量處理trafficPolicy.loadBalancer.simple
: 選擇流量處理的策略,其他不同的策略在此
啟動 K8s 集群,步驟不再贅述,詳細介紹可以看DAY23
$ minikube start --kubernetes-version v1.16.0
$ istioctl install --set profile=demo
$ kubectl label namespace default istio-injection=enabled
$ cd DAY26/helm-digimon
$ helm install . --generate-name
$ minikube tunnel
再來我們要觀看 pods 是不是有正確分流,使用$ kubectl get pods
拿取全部pods
,
使用$ kubectl logs
來取得 pods 的 log,以我來說我會是以下指令:
$ kubectl logs -f server-66db48686-f4xm5
$ kubectl logs -f server-66db48686-sdpfs
兩個 pods 已經成功被分流。
如果想要看看沒有 DestinationRule 元件會產生什麼狀況,可以把DAY26/helm-digimon/templates/load-balancer.yaml
刪除,再重新以上步驟創建一個 K8s 集群
我們會看到流量只有導到左邊的 pods,造成左邊很忙右邊很閒的狀況 XD。