應用程式需求
Istio 為應用程式提供了大量功能,而對應用程式程式碼本身幾乎沒有影響。許多 Kubernetes 應用程式可以在啟用 Istio 的叢集中部署,而無需任何變更。然而,當部署啟用 Istio 的應用程式時,Istio 的 sidecar 模型有一些可能需要特別考慮的含義。本文檔描述了這些應用程式考量,以及啟用 Istio 的特定要求。
Pod 需求
要成為網格的一部分,Kubernetes Pod 必須滿足以下要求
應用程式 UID:確保您的 Pod 不要以使用者 ID (UID) 值為
1337
的使用者身分執行應用程式,因為1337
保留給 sidecar 代理使用。NET_ADMIN
和NET_RAW
功能:如果您的叢集中 Pod 安全策略是強制執行的,並且除非您使用Istio CNI 外掛程式,否則您的 Pod 必須允許NET_ADMIN
和NET_RAW
功能。Envoy 代理的初始化容器需要這些功能。要檢查您的 Pod 是否允許
NET_ADMIN
和NET_RAW
功能,您需要檢查它們的服務帳戶是否可以使用允許NET_ADMIN
和NET_RAW
功能的 Pod 安全策略。如果您沒有在 Pod 的部署中指定服務帳戶,則 Pod 將使用其部署命名空間中的default
服務帳戶執行。要列出服務帳戶的功能,請在以下命令中將
<您的命名空間>
和<您的服務帳戶>
替換為您的值$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
例如,要檢查
default
命名空間中的default
服務帳戶,請執行以下命令$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
如果您在服務帳戶的允許策略列表中看到
NET_ADMIN
和NET_RAW
或*
,則您的 Pod 有權限執行 Istio 初始化容器。否則,您需要提供權限。Pod 標籤:我們建議使用 Pod 標籤明確宣告帶有應用程式識別碼和版本的 Pod。這些標籤會為 Istio 收集的指標和遙測資料新增上下文資訊。這些值中的每一個都是從多個標籤中讀取的,並按照從最高到最低優先順序排序
- 應用程式名稱:
service.istio.io/canonical-name
、app.kubernetes.io/name
或app
。 - 應用程式版本:
service.istio.io/canonical-revision
、app.kubernetes.io/version
或version
。
- 應用程式名稱:
具名服務埠:服務埠可以選擇性地命名以明確指定協定。請參閱協定選取以瞭解更多詳細資訊。如果 Pod 屬於多個 Kubernetes 服務,則這些服務不能為不同的協定(例如 HTTP 和 TCP)使用相同的埠號。
Istio 使用的連接埠
以下埠和協定由 Istio sidecar 代理 (Envoy) 使用。
埠 | 協定 | 描述 | 僅限 Pod 內部 |
---|---|---|---|
15000 | TCP | Envoy 管理埠(命令/診斷) | 是 |
15001 | TCP | Envoy 對外 | 否 |
15004 | HTTP | 偵錯埠 | 是 |
15006 | TCP | Envoy 對內 | 否 |
15008 | HTTP2 | HBONE mTLS 通道埠 | 否 |
15020 | HTTP | 來自 Istio 代理、Envoy 和應用程式的合併 Prometheus 遙測資料 | 否 |
15021 | HTTP | 健康狀況檢查 | 否 |
15053 | DNS | 如果已啟用擷取,則為 DNS 埠 | 是 |
15090 | HTTP | Envoy Prometheus 遙測資料 | 否 |
以下埠和協定由 Istio 控制平面 (istiod) 使用。
埠 | 協定 | 描述 | 僅限本機主機 |
---|---|---|---|
443 | HTTPS | Webhooks 服務埠 | 否 |
8080 | HTTP | 偵錯介面(已棄用,僅限容器埠) | 否 |
15010 | GRPC | XDS 和 CA 服務(純文字,僅適用於安全網路) | 否 |
15012 | GRPC | XDS 和 CA 服務(TLS 和 mTLS,建議用於生產環境) | 否 |
15014 | HTTP | 控制平面監控 | 否 |
15017 | HTTPS | 從 443 轉送的 Webhook 容器埠 | 否 |
伺服器優先協定
某些協定是「伺服器優先」協定,這表示伺服器將傳送第一個位元組。這可能會對PERMISSIVE
mTLS 和自動協定選取產生影響。
這兩個功能都藉由檢查連線的初始位元組來判斷協定,這與伺服器優先協定不相容。
為了支援這些情況,請按照明確協定選取步驟將應用程式的協定宣告為 TCP
。
已知以下埠通常會攜帶伺服器優先協定,並自動假設為 TCP
協定 | 埠 |
---|---|
SMTP | 25 |
DNS | 53 |
MySQL | 3306 |
MongoDB | 27017 |
由於 TLS 通訊不是伺服器優先,因此只要您確保所有經過 TLS 嗅探的流量都已加密,TLS 加密的伺服器優先流量就可以使用自動協定偵測。
- 針對伺服器設定
mTLS
模式STRICT
。這將對所有請求強制執行 TLS 加密。 - 針對伺服器設定
mTLS
模式DISABLE
。這將停用 TLS 嗅探,允許使用伺服器優先協定。 - 設定所有用戶端傳送
TLS
流量,通常透過DestinationRule
或依賴自動 mTLS。 - 設定您的應用程式直接傳送 TLS 流量。
對外流量
為了支援 Istio 的流量路由功能,離開 Pod 的流量路由方式可能會與未部署 sidecar 時不同。
對於基於 HTTP 的流量,流量會根據 Host
標頭進行路由。如果目的地 IP 和 Host
標頭未對齊,則可能會導致非預期的行為。例如,像 curl 1.2.3.4 -H "Host: httpbin.default"
這樣的請求將會路由到 httpbin
服務,而不是 1.2.3.4
。
對於非基於 HTTP 的流量(包括 HTTPS),Istio 無法存取 Host
標頭,因此路由決策會根據服務 IP 位址做出。
其中一個含義是,對 Pod 的直接呼叫(例如,curl <POD_IP>
),而不是服務,將不會被比對。雖然流量可能會被傳遞,但它不會獲得完整的 Istio 功能,包括 mTLS 加密、流量路由和遙測。
請參閱流量路由頁面以瞭解更多資訊。