Istio學習

學習參考鏈接

https://www.bilibili.com/video/BV1zU411U7y1?spm_id_from=333.788.videopod.sections&vd_source=0372d3f32c3f19a6a2676a7529d6698a

https://istio.io/latest/docs/setup/getting-started/

https://github.com/istio/istio

安裝

Helm方式安裝

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
# 在istio-system命名空間安裝（自動創建）
helm install istio-base istio/base -n istio-system
helm install istiod istio/istiod -n istio-system

istioctl方式安裝

這里直接從GitHub里下載release包安裝

wget https://github.com/istio/istio/releases/download/1.25.2/istio-1.25.2-linux-amd64.tar.gz

tar -zxvf istio-1.25.2-linux-amd64.tar.gz

cd istio-1.25.2

# copy istioctl to an environment path
cp bin/istioctl /usr/local/bin/istioctl  
 
# demo方式安裝
istioctl install --set profile=demo -y

istioctl install --help

Examples:
  # Apply a default Istio installation
  istioctl install

  # Enable Tracing
  istioctl install --set meshConfig.enableTracing=true

  # Generate the demo profile and don't wait for confirmation
  istioctl install --set profile=demo --skip-confirmation

  # To override a setting that includes dots, escape them with a backslash (\).  Your shell may require enclosing quotes.
  istioctl install --set "values.sidecarInjectorWebhook.injectedAnnotations.container\.apparmor\.security\.beta\.kubernetes\.io/istio-proxy=runtime/default"

安裝samples 文件夾下 addons 里面的各種插件

kubectl apply -f samples/addons

注入方式

其核心功能之一是通過注入 Sidecar 代理（如 Envoy）來實現服務間通信的管理和監控

通過kubectl label為特定namespace指定注入sidecar

kubectl label namespace <namespace-name> istio-injection=enabled

通過istioctl kube-inject 命令注入

istioctl kube-inject -f original.yaml > injected.yaml
kubectl apply -f injected.yaml

或

kubectl apply -f <(istioctl kube-inject -f original.yaml)

主要組件

Gateway, VirtualService 和 DestinationRule

Gateway: 功能類似ingress controller, 接收外部流量并轉發到內部服務.

VirtualService: 定義路由規則，流量鏡像，等

DestinationRule: 定義版本信息，配置熔斷，等

sample project bookinfo (https://github.com/woodhead66/istio/tree/master/samples/bookinfo)

Gateway yaml file from sample project bookinfo

kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:      
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "bookinfo.example.com"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/credentials/cert.pem
      privateKey: /etc/istio/credentials/key.pem

VirtualService yaml file from sample project bookinfo

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

DestinationRule yaml file from sample project bookinfo

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

接入外部服務組件

ServiceEntry：用于在istio中接入訪問管理外部第三方服務

sample project external（https://github.com/woodhead66/istio/tree/master/samples/external）

# This ServiceEntry exposes the hosts needed for installing packages with apt-get.
# After applying this file, Istio-enabled pods (configured apt-get) be able to execute
# `apt-get upgrade` and `apt-get install`.  If this is not installed you may get
# "404  Not Found"

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: make-aptget-work
spec:
  hosts:
  - deb.debian.org
  - cdn-fastly.deb.debian.org
  - security.debian.org
  - archive.ubuntu.com
  - security.ubuntu.com
  ports:
  - number: 80
    name: http
    protocol: HTTP

基于istio的金絲雀（canary）發布的幾種策略

1. 百分比

核心原理：通過配置 VirtualService 中的 weight 字段，按比例將流量分發到不同版本，再逐步放量

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
      weight: 90  # 90% 流量到穩定版本 v1
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v2
      weight: 10  # 10% 流量到新版本 v2

2. 特征

核心原理：根據請求的 Header、Cookie、URI 等特征，將特定用戶（內部用戶，區域用戶等）或流量導向新版本，再逐步放量

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - match:  # 匹配特定用戶到新版本 v2
    - headers:
        user-agent:
          regex: ".*Chrome.*"  # Chrome 用戶
    - headers:
        cookie:
          regex: ".*user=test.*"  # 特定 Cookie
    route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v2
  - route:  # 其他用戶到穩定版本 v1
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1

3. 流量鏡像

核心原理：現將流量鏡像到新版本，同時監控新版本上的情況，再分發一定比例將流量到新版本，再逐步放量。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
      weight: 90  # 90% 流量到穩定版 v1

   - destination:
       host: my-service.default.svc.cluster.local
       subset: v2
     weight: 10  # 10% 實際流量到 v2

   mirror: # 鏡像到新版 v2 
     host: my-service.default.svc.cluster.local 
     subset: v2 
   mirrorPercentage: 
     value: 100 # 100% 鏡像到 V2（可調整為 10%、50% 等）

istio的可視化

Kiali

kubectl get svc -n istio-system kiali

jaeger 追蹤

kubectl get svc -n istio-system -l app=jaeger

問題一：在有istio 的k8s集群中，假設有20個微服務，其中5個是對外網的服務，另外15個是內部服務，這種情況下，我需要怎么配置 Gateway，virtualService，destinationRule? 分別配置多少個？

回答一：

在 Istio 服務網格中配置 5 個外部服務和 15 個內部服務時，通常采用 "邊緣網關 + 內部路由" 的分層設計。以下是配置策略和數量建議：

一、核心配置組件與數量規劃

組件	數量	作用
Gateway	1-2 個	定義集群入口點（通常一個 HTTP 網關 + 一個 HTTPS 網關）
VirtualService	20 個（至少）	為每個服務定義路由規則（外部服務需綁定 Gateway，內部服務僅需網格內路由）
DestinationRule	按需（建議 20 個）	為每個服務定義負載均衡、熔斷、TLS 等策略（可按服務或子集分組）

二、具體配置方案

1. Gateway 配置（邊緣入口）

yaml
 
 

# 外部 HTTP 網關（端口 80，可重定向到 HTTPS）
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: external-http-gateway
spec:
  selector:
    istio: ingressgateway  # Istio 默認入口網關
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.example.com"  # 替換為實際域名或通配符

# 外部 HTTPS 網關（端口 443，啟用 TLS）
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: external-https-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*.example.com"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key

 

關鍵點：

通常只需 1 個 Gateway 處理所有外部流量（除非有特殊協議需求）。
通過 hosts 字段限制可訪問的域名（生產環境避免使用通配符）。

2. VirtualService 配置（路由規則）

外部服務（綁定 Gateway）

每個外部服務需配置一個 綁定 Gateway 的 VirtualService，示例：

yaml
 
 

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: external-service-vs  # 替換為實際服務名
spec:
  hosts:
  - "service1.example.com"  # 外部訪問域名
  gateways:
  - external-https-gateway  # 綁定到上面定義的 Gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: external-service  # 集群內服務名
        port:
          number: 8080

 

內部服務（僅網格內訪問）

每個內部服務需配置一個 僅用于網格內路由的 VirtualService，示例：

yaml
 
 

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: internal-service-vs  # 替換為實際服務名
spec:
  hosts:
  - "internal-service"  # 集群內服務名（無需域名）
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: internal-service
        port:
          number: 8080

 

關鍵點：

外部服務：必須通過 gateways 字段綁定到 Gateway，并使用域名作為 hosts。
內部服務：無需綁定 Gateway，直接使用服務名作為 hosts，僅網格內可見。

3. DestinationRule 配置（流量策略）

每個服務建議配置一個 DestinationRule，定義負載均衡、熔斷等策略：

yaml
 
 

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: service-dr  # 替換為實際服務名
spec:
  host: service-name  # 目標服務名
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 負載均衡策略
    connectionPool:
      http:
        http2MaxRequests: 1000  # HTTP2 最大請求數
        maxRequestsPerConnection: 100  # 每個連接的最大請求數
    outlierDetection:  # 熔斷配置
      consecutive5xxErrors: 5  # 連續5次5xx錯誤
      interval: 10s  # 檢測間隔
      baseEjectionTime: 30s  # 熔斷時間

 

關鍵點：

負載均衡：可選擇 ROUND_ROBIN、LEAST_CONN、RANDOM 等策略。
熔斷：通過 outlierDetection 防止故障實例影響整體服務。

三、配置數量總結

組件	外部服務（5 個）	內部服務（15 個）	總計
Gateway	1-2 個（共享）	0	1-2
VirtualService	5 個（綁定 Gateway）	15 個（僅網格內）	20
DestinationRule	5 個	15 個	20

四、最佳實踐

分層設計：
- 外部流量通過 Gateway → VirtualService → DestinationRule 處理。
- 內部流量直接通過 VirtualService → DestinationRule 處理。
簡化管理：
- 使用標簽和選擇器批量配置相似服務（如所有 API 服務共用一組策略）。
- 利用 Kustomize 或 Helm 模板減少重復配置。
安全加固：
- 為外部服務啟用 HTTPS（通過 Gateway 的 TLS 配置）。
- 為內部服務啟用 mTLS（通過 DestinationRule 的 TLS 配置）。
監控與可觀測性：
- 結合 Prometheus 和 Grafana 監控流量指標。
- 配置 Jaeger 追蹤跨服務調用路徑。

五、示例：完整配置模板

以下是一個外部服務的完整配置示例（包含 Gateway、VirtualService、DestinationRule）：

yaml
 
 

# 1. Gateway（共享，略，見前文）

# 2. VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productpage-vs
spec:
  hosts:
  - "productpage.example.com"
  gateways:
  - external-https-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: productpage
        port:
          number: 9080

# 3. DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: productpage-dr
spec:
  host: productpage
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # 啟用 mTLS
    loadBalancer:
      simple: ROUND_ROBIN

 

通過這種配置模式，可清晰區分外部和內部服務，同時保持 Istio 網格的統一管理能力。

問題二：根據上面的答案，所以 service 和 virtual Service 必須一一對應起來才能被 istio 管理起來？

回答二：

不是的，Service 和 VirtualService 并非必須一一對應。Istio 的 VirtualService 主要用于定義流量路由規則，它可以關聯一個或多個 Service，也可以一個 Service 被多個 VirtualService 關聯，具體取決于你的流量管理需求。

更詳細的說明：

一個 VirtualService 可以關聯多個 Service
例如，當你需要將流量按規則分發到不同的服務（如 A 服務和 B 服務）時，可以在一個 VirtualService 中通過 hosts 指定多個 Service，再通過 http.route 定義不同的路由規則（如按路徑、權重分發）。
示例：

yaml
 
 

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: multi-service-vs
spec:
  hosts:
  - service-a  # 關聯 service-a
  - service-b  # 關聯 service-b
  http:
  - match:
    - uri:
        prefix: /api/a
    route:
    - destination:
        host: service-a
  - match:
    - uri:
        prefix: /api/b
    route:
    - destination:
        host: service-b

 

一個 Service 可以被多個 VirtualService 關聯
例如，同一個 Service（如 user-service）可能需要通過不同的入口（如不同的 Gateway）暴露，或針對不同場景（如內部調用、外部訪問）定義不同的路由規則，此時可以創建多個 VirtualService 分別關聯它。
示例：
- 外部訪問的 VirtualService：通過公網 Gateway 路由到 user-service，并添加認證規則；
- 內部訪問的 VirtualService：通過內部 Gateway 路由到 user-service，無需認證。
VirtualService 也可以不直接關聯 Service，而是通過 “服務別名” 路由
Istio 支持通過 hosts 指定 “服務別名”（如自定義域名 api.example.com），再通過路由規則指向實際的 Service，此時 VirtualService 與 Service 是 “間接關聯” 的。

核心邏輯：

Service 是 K8s 中服務發現的基礎，定義了 Pod 集群的訪問入口；
VirtualService 是 Istio 中流量路由的配置，它的作用是 “告訴 Istio 如何將流量轉發到目標服務（Service）”，但兩者的關聯關系是靈活的，并非一一綁定。

是否需要一一對應，完全取決于你的流量管理復雜度：簡單場景下可以一一對應（一個 Service 配一個 VirtualService），復雜場景下可以靈活組合。

問題三：如果我的20個service分布在不同的namespace里，我要如何創建 Gateway，virtual service， destination Rule 來實現跨namespace的調用？

回答三：

在 Istio 中，跨 namespace 調用服務的核心是通過服務的完整域名（FQDN） 進行路由，并結合 VirtualService、DestinationRule 的配置實現流量管理。以下是具體的配置方法和注意事項，分場景說明：

一、前提：確保基礎環境就緒

在配置前，需先滿足兩個基礎條件：

所有 namespace 已啟用 Istio 注入：通過為 namespace 添加標簽 istio-injection=enabled，確保 Pod 自動注入 Sidecar，否則流量無法被 Istio 管理。
bash
kubectl label namespace <ns-name> istio-injection=enabled --overwrite
服務間網絡可達：K8s 默認允許跨 namespace 訪問 Service（通過 FQDN），Istio 僅在此基礎上增加流量管控，無需額外配置網絡策略（除非有特殊隔離需求）。

二、Gateway：僅用于 “外部流量入站”，與 namespace 無關

Gateway 的作用是定義 “外部流量如何進入集群”，通常不需要為每個 namespace 創建單獨的 Gateway，而是集中管理（推薦在 istio-system 或專用網關 namespace，如 istio-gateways 中創建）。

配置要點：

Gateway 綁定的是 Istio IngressGateway 的 Service（通常在 istio-system 中），通過 selector 指定（如 istio: ingressgateway）。
僅需為 “對外暴露的 5 個服務” 配置 Gateway（內部服務跨 namespace 調用不需要 Gateway）。

示例（全局共享的 Gateway）：

yaml
 
 

# 在 istio-system 命名空間創建
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: global-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway  # 綁定Istio默認的IngressGateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.example.com"  # 外部訪問的域名（覆蓋所有對外服務的域名）

 

三、VirtualService：跨 namespace 路由的核心，靈活關聯多 namespace 服務

VirtualService 用于定義流量路由規則，可以在任意 namespace 創建，但需通過服務的完整域名（FQDN） 指向目標服務（格式：service-name.namespace.svc.cluster.local，簡寫可省略 .svc.cluster.local，即 service-name.namespace）。

場景 1：外部流量通過 Gateway 訪問不同 namespace 的對外服務

需創建 VirtualService 關聯 Gateway，并路由到目標 namespace 的服務（用 FQDN）。

示例：
假設對外服務 service-a 在 ns-a namespace，service-b 在 ns-b namespace，外部域名分別為 a.example.com 和 b.example.com：

yaml
 
 

# 在 istio-system 或與服務同namespace創建均可
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: external-vs
  namespace: istio-system  # 建議與Gateway同namespace，方便管理
spec:
  hosts:
  - "a.example.com"  # 外部域名
  - "b.example.com"
  gateways:
  - global-gateway  # 關聯上面創建的Gateway
  http:
  - match:
    - host: "a.example.com"  # 匹配a的域名
    route:
    - destination:
        host: service-a.ns-a  # 目標服務的FQDN（簡寫）
  - match:
    - host: "b.example.com"  # 匹配b的域名
    route:
    - destination:
        host: service-b.ns-b  # 目標服務的FQDN（簡寫）

 

場景 2：內部服務跨 namespace 調用（如 `ns-1` 的 `service-x` 調用 `ns-2` 的 `service-y`）

如果需要對內部跨 namespace 調用添加路由規則（如版本分流、超時重試），需創建 VirtualService；若無需規則，直接通過 FQDN 調用即可（Istio 自動處理）。

示例（帶路由規則的內部跨 namespace 調用）：

yaml
 
 

# 在調用方namespace（ns-1）或目標方namespace（ns-2）創建均可
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: internal-vs
  namespace: ns-1  # 在調用方namespace創建，更貼近業務
spec:
  hosts:
  - service-y.ns-2  # 目標服務的FQDN（作為路由的“入口”）
  http:
  - route:
    - destination:
        host: service-y.ns-2  # 路由到目標服務
        subset: v1  # 若有版本，需結合DestinationRule
      weight: 90
    - destination:
        host: service-y.ns-2
        subset: v2
      weight: 10

 

四、DestinationRule：定義服務的 “出口規則”，建議與服務同 namespace

DestinationRule 用于定義服務的負載均衡策略、版本子集（subset）、連接池等，推薦在 “目標服務所在的 namespace” 創建，原因是：

規則與服務生命周期綁定，便于管理（服務刪除時可同步刪除規則）；
Istio 默認優先查找 “與目標服務同 namespace” 的 DestinationRule，避免跨 namespace 引用沖突。

示例（為 `ns-2` 的 `service-y` 定義規則）：

yaml
 
 

# 在目標服務所在的namespace（ns-2）創建
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: service-y-dr
  namespace: ns-2
spec:
  host: service-y  # 直接用服務名（同namespace內可省略FQDN）
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 負載均衡策略
  subsets:
  - name: v1  # 版本子集v1
    labels:
      version: v1
  - name: v2  # 版本子集v2
    labels:
      version: v2

 

此時，其他 namespace 的 VirtualService（如上面的 internal-vs）可以通過 host: service-y.ns-2 + subset: v1 引用該規則。

五、總結：配置數量與原則

資源類型	配置數量原則
Gateway	1-2 個全局共享（如 HTTP、HTTPS 各一個），與對外服務的 namespace 無關。
VirtualService	按需創建： - 外部流量：1 個或多個（按域名 / 功能分組），關聯 Gateway，覆蓋所有對外服務的 FQDN； - 內部跨 namespace 調用：僅在需要路由規則時創建，每個規則可覆蓋多個服務。
DestinationRule	為需要自定義策略（負載均衡、版本）的服務創建，每個服務 1 個，且與服務同 namespace。

關鍵注意事項

服務 FQDN 必須正確：跨 namespace 調用時，VirtualService 的 destination.host 必須寫全 service-name.namespace（或完整 FQDN），否則 Istio 會默認在當前 namespace 查找服務。
權限與可見性：Istio 資源（VirtualService、DestinationRule）默認在所有 namespace 可見，無需額外授權，但建議按服務所屬 namespace 隔離管理。
簡化內部調用：若內部服務跨 namespace 調用無需復雜路由（如僅需默認轉發），可直接通過 service-name.namespace 調用，無需創建 VirtualService（Istio Sidecar 會自動處理流量）。

通過以上配置，即可實現不同 namespace 服務的跨域調用和流量管理。

問題四：我看到virtual service 里面有按百分比分發流量的配置，又看到destination rule里有round_robin 這樣的規則，這兩者是否沖突？

回答四：

VirtualService 的按百分比分發流量與 DestinationRule 的round_robin等負載均衡規則不沖突，因為它們作用于流量路由的不同階段，職責完全不同。

1. 核心區別：作用階段與職責

資源	作用階段	核心職責	舉例
VirtualService	流量路由決策階段	決定 “流量往哪里去”（比如路由到哪個服務版本、哪個子集、哪個命名空間的服務）。	按權重分發：80% 流量到服務 v1 版本，20% 到 v2 版本；或按路徑路由到不同服務。
DestinationRule	流量到達目標后的負載均衡階段	決定 “流量在目標服務內部如何分配到具體實例”（比如 Pod 級別的負載均衡策略）。	對 v1 版本的 Pod 使用`round_robin`（輪詢），對 v2 版本使用`random`（隨機）。

2. 協同工作示例

假設一個服務user-service有兩個版本（v1、v2），部署在同一命名空間：

VirtualService 負責 “宏觀路由”：將 70% 流量路由到 v1，30% 路由到 v2。
DestinationRule 負責 “微觀負載均衡”：在 v1 的所有 Pod 間用round_robin，在 v2 的所有 Pod 間用least_request（最少請求優先）。

配置示例：

yaml
 
 

# VirtualService：按權重分發到不同版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service-vs
spec:
  hosts:
  - user-service  # 目標服務名
  http:
  - route:
    - destination:
        host: user-service
        subset: v1  # 對應DestinationRule的v1子集
      weight: 70
    - destination:
        host: user-service
        subset: v2  # 對應DestinationRule的v2子集
      weight: 30
---
# DestinationRule：定義每個子集的負載均衡策略
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user-service-dr
spec:
  host: user-service
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN  # v1內部Pod輪詢
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: LEAST_REQUEST  # v2內部Pod優先分配給請求少的實例

 

流程說明：

流量先經過 VirtualService，70% 被路由到v1子集，30% 到v2子集。
到達v1子集的流量，由 DestinationRule 的ROUND_ROBIN策略分配到 v1 的各個 Pod；
到達v2子集的流量，由LEAST_REQUEST策略分配到 v2 的各個 Pod。

3. 總結

不沖突：VirtualService 管 “路由到哪個目標”，DestinationRule 管 “目標內部如何分發給實例”，兩者是 “先后順序” 的協同關系，而非競爭關系。
靈活組合：可以根據需求自由搭配（比如 VirtualService 按權重路由，DestinationRule 按 Pod 負載分配），實現更精細的流量控制。

posted @ 2025-06-05 11:43 呆瓜小賊66 閱讀(40) 評論(0) 收藏舉報

刷新頁面返回頂部

呆瓜小賊66

Istio學習

安裝

注入方式

主要組件

接入外部服務組件

基于istio的 金絲雀（canary）發布的幾種策略

1. 百分比

2. 特征

3. 流量鏡像

istio的可視化

Kiali

jaeger 追蹤

問題一：在有istio 的k8s集群中，假設有20個微服務，其中5個是對外網的服務，另外15個是內部服務，這種情況下，我需要怎么配置 Gateway，virtualService，destinationRule? 分別配置多少個？

回答一：

一、核心配置組件與數量規劃

二、具體配置方案

1. Gateway 配置（邊緣入口）

2. VirtualService 配置（路由規則）

外部服務（綁定 Gateway）

內部服務（僅網格內訪問）

3. DestinationRule 配置（流量策略）

三、配置數量總結

四、最佳實踐

五、示例：完整配置模板

問題二：根據上面的答案，所以 service 和 virtual Service 必須一一對應起來才能被 istio 管理起來？

回答二：

更詳細的說明：

核心邏輯：

問題三：如果我的20個service分布在不同的namespace里，我要如何創建 Gateway，virtual service， destination Rule 來實現跨namespace的調用？

回答三：

一、前提：確保基礎環境就緒

二、Gateway：僅用于 “外部流量入站”，與 namespace 無關

配置要點：

三、VirtualService：跨 namespace 路由的核心，靈活關聯多 namespace 服務

場景 1：外部流量通過 Gateway 訪問不同 namespace 的對外服務

場景 2：內部服務跨 namespace 調用（如 ns-1 的 service-x 調用 ns-2 的 service-y）

四、DestinationRule：定義服務的 “出口規則”，建議與服務同 namespace

示例（為 ns-2 的 service-y 定義規則）：

五、總結：配置數量與原則

關鍵注意事項

問題四：我看到virtual service 里面有按百分比分發流量的配置，又看到destination rule里有round_robin 這樣的規則，這兩者是否沖突？

回答四：

1. 核心區別：作用階段與職責

2. 協同工作示例

3. 總結

公告

基于istio的金絲雀（canary）發布的幾種策略

場景 2：內部服務跨 namespace 調用（如 `ns-1` 的 `service-x` 調用 `ns-2` 的 `service-y`）

示例（為 `ns-2` 的 `service-y` 定義規則）：