應用程式需求

Istio 為應用程式提供了大量功能,而對應用程式程式碼本身幾乎沒有影響。許多 Kubernetes 應用程式可以在啟用 Istio 的叢集中部署,而無需任何變更。然而,當部署啟用 Istio 的應用程式時,Istio 的 sidecar 模型有一些可能需要特別考慮的含義。本文檔描述了這些應用程式考量,以及啟用 Istio 的特定要求。

Pod 需求

要成為網格的一部分,Kubernetes Pod 必須滿足以下要求

  • 應用程式 UID:確保您的 Pod 不要以使用者 ID (UID) 值為 1337 的使用者身分執行應用程式,因為 1337 保留給 sidecar 代理使用。

  • NET_ADMINNET_RAW 功能:如果您的叢集中 Pod 安全策略強制執行的,並且除非您使用Istio CNI 外掛程式,否則您的 Pod 必須允許 NET_ADMINNET_RAW 功能。Envoy 代理的初始化容器需要這些功能。

    要檢查您的 Pod 是否允許 NET_ADMINNET_RAW 功能,您需要檢查它們的服務帳戶是否可以使用允許 NET_ADMINNET_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_ADMINNET_RAW*,則您的 Pod 有權限執行 Istio 初始化容器。否則,您需要提供權限

  • Pod 標籤:我們建議使用 Pod 標籤明確宣告帶有應用程式識別碼和版本的 Pod。這些標籤會為 Istio 收集的指標和遙測資料新增上下文資訊。這些值中的每一個都是從多個標籤中讀取的,並按照從最高到最低優先順序排序

    • 應用程式名稱:service.istio.io/canonical-nameapp.kubernetes.io/nameapp
    • 應用程式版本:service.istio.io/canonical-revisionapp.kubernetes.io/versionversion
  • 具名服務埠:服務埠可以選擇性地命名以明確指定協定。請參閱協定選取以瞭解更多詳細資訊。如果 Pod 屬於多個 Kubernetes 服務,則這些服務不能為不同的協定(例如 HTTP 和 TCP)使用相同的埠號。

Istio 使用的連接埠

以下埠和協定由 Istio sidecar 代理 (Envoy) 使用。

協定描述僅限 Pod 內部
15000TCPEnvoy 管理埠(命令/診斷)
15001TCPEnvoy 對外
15004HTTP偵錯埠
15006TCPEnvoy 對內
15008HTTP2HBONE mTLS 通道埠
15020HTTP來自 Istio 代理、Envoy 和應用程式的合併 Prometheus 遙測資料
15021HTTP健康狀況檢查
15053DNS如果已啟用擷取,則為 DNS 埠
15090HTTPEnvoy Prometheus 遙測資料

以下埠和協定由 Istio 控制平面 (istiod) 使用。

協定描述僅限本機主機
443HTTPSWebhooks 服務埠
8080HTTP偵錯介面(已棄用,僅限容器埠)
15010GRPCXDS 和 CA 服務(純文字,僅適用於安全網路)
15012GRPCXDS 和 CA 服務(TLS 和 mTLS,建議用於生產環境)
15014HTTP控制平面監控
15017HTTPS從 443 轉送的 Webhook 容器埠

伺服器優先協定

某些協定是「伺服器優先」協定,這表示伺服器將傳送第一個位元組。這可能會對PERMISSIVE mTLS 和自動協定選取產生影響。

這兩個功能都藉由檢查連線的初始位元組來判斷協定,這與伺服器優先協定不相容。

為了支援這些情況,請按照明確協定選取步驟將應用程式的協定宣告為 TCP

已知以下埠通常會攜帶伺服器優先協定,並自動假設為 TCP

協定
SMTP25
DNS53
MySQL3306
MongoDB27017

由於 TLS 通訊不是伺服器優先,因此只要您確保所有經過 TLS 嗅探的流量都已加密,TLS 加密的伺服器優先流量就可以使用自動協定偵測。

  1. 針對伺服器設定 mTLS 模式 STRICT。這將對所有請求強制執行 TLS 加密。
  2. 針對伺服器設定 mTLS 模式 DISABLE。這將停用 TLS 嗅探,允許使用伺服器優先協定。
  3. 設定所有用戶端傳送 TLS 流量,通常透過DestinationRule或依賴自動 mTLS。
  4. 設定您的應用程式直接傳送 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 加密、流量路由和遙測。

請參閱流量路由頁面以瞭解更多資訊。

此資訊是否有用?
您是否有任何改進建議?

感謝您的回饋!