使用ISTIO或LINKERD解鎖短期環境

原创 岱军 云云众生s

Istio 和 Linkerd 不僅可以管理 Kubernetes 中的流量;它們還可以解鎖輕量級、按需的開發和測試環境。
如果您正在使用Istio或Linkerd,那麼您已經解決了在Kubernetes中管理流量最困難的部分之一。
但您是否知道您也已經完成了90%的工作,可以解鎖短暫環境[2]? 這些輕量級、按需環境可以改變您的團隊開發和測試應用程式的方式——讓您更快地迭代、更安全地部署和獲得更好的軟體品質。
為什麼短暫環境很重要短暫環境提供了巨大的好處。開發人員可以快速獲得更改回饋,而無需等待漫長的CI建置。
QA團隊可以在隔離的、類似生產的環境中驗證行為,從而顯著降低迴歸的風險。這種方法促進了持續改進和部署,幫助團隊以更高的信心更快地推進發布。
對於現代組織來說,短暫環境正變得至關重要。
它們能夠加快迭代速度,改善開發人員和QA之間的協作,並透過在開發過程的早期發現問題來降低風險。
採用它們的團隊可以避免許多與傳統的共享預發布環境相關的陷阱[3]。
為什麼服務網格改變了遊戲規則傳統的短暫環境方法涉及在單獨的Kubernetes[4]命名空間或叢集中複製整個微服務堆疊。
雖然這提供了隔離性,但它帶來了巨大的挑戰[5]。
生命週期管理變得複雜,基礎設施的複製增加了成本,啟動時間可能會阻礙徹底的測試。
這些環境也可能很快過時,尤其是在快速發展的微服務架構[6]中,如果沒有持續更新,測試結果就會變得不可靠。
更有效的方法是利用服務網格的功能來創建基於租戶的環境。
這種方法不是複製整個堆疊,而是專注於針對Kubernetes叢集中已有的共用相依性測試變更。
服務網格處理路由和流量控制,允許多個環境同時運行,而無需複製整個堆疊的成本和複雜性。

在大規模情況下,請求級租戶可以清楚分割流量,提供隔離的環境,而無需大量複製基礎設施。
Istio或Linkerd之類的服務網格提供了一種輕量級、可擴展的解決方案,簡化了管理並降低了營運成本。

現實世界的例子:擴展短暫環境像Uber和DoorDash這樣的行業領導者長期以來一直使用可擴展的、按需環境來降低部署風險並提高開發人員效率。

Uber的SLATE[7]允許大規模隔離測試,幫助開發人員儘早發現問題並加快發布速度。

DoorDash採用了類似的方法,確保每個變更在進入生產環境之前都經過隔離測試[8]。借助服務網格可觀測性和OpenTelemetry之類的工具,團隊可以深入了解多個環境中的請求流程和效能。

這使得調試更快,並防止跨環境幹擾。開發人員可以部署具有完整路由控制的隔離服務,並避免衝突,從而更容易發現共享預發布環境經常遺漏的問題。

基於租戶的短暫環境的工作原理那麼,它是如何運作的呢?想像一下,每個拉取請求都會按需啟動一個環境。

使用租戶,環境共享相同的Kubernetes集群,同時使用請求級租戶進行流量控制來隔離資源、路由和資料。

例如:

• 開發人員開啟一個拉取請求。

• 建置鏡像後,只有變更的服務才會部署到沙箱中的叢集中。

• 配置路由規則,以便具有特定標頭的請求被導向到新版本的服務-類似於金絲雀在生產環境中的工作方式。

• 開發人員和QA團隊在具有共享依賴項的類似生產環境中測試這些變更。

• 拉取要求關閉後,環境會自動清理。

請求租戶作為核心元件請求級租戶有效率地管理流量,無需完全隔離的基礎設施。 Istio 或 Linkerd 等服務網格可以使用唯一的標頭來路由和分割每個環境的請求,允許多個環境共存,同時最大限度地減少資源消耗並保持邏輯隔離。

請求租戶制的一個關鍵方面是上下文傳播,它允許特定於環境的元資料跨服務邊界傳輸。

透過利用OpenTelemetry (OTel)[9]和 baggage 傳播,此元資料會自動在服務之間傳遞。

這使得一致的環境特定行為和使用服務網格規則的無縫重新路由成為可能。

處理資料隔離和訊息佇列在共用資料庫中,資料隔離至關重要。

一種常見的方法是分區數據,透過組織 ID 或使用者 ID 等標識符隔離測試,以最大限度地減少干擾。

對於模式更改,團隊可以啟動臨時的容器化資料庫以確保完全隔離。

訊息佇列隔離可以透過使用標頭的訊息層級路由或透過動態建立臨時佇列來實現。這些策略支援並行測試,而不會中斷共享資源。

結論如果您已經在使用 Istio 或 Linkerd,那麼短暫的環境就在您的掌握之中。

透過採用基於租戶的環境,您將解鎖更快的開發週期、更安全的部署和更快樂的開發人員。

若要更深入了解技術細節,請查看「使用 OpenTelemetry 的 Kubernetes 沙箱[10]」。

像 Signadot 這樣的工具超越了自動化,提供了諸如基於本地工作站的環境、對資料庫和訊息佇列的無縫支援以及跨越單一路由上下文中的多個拉取請求的環境等功能。

它們提供分析以獲得更深入的見解,並幫助平台團隊輕鬆採用和管理這些環境。

透過支援本地和基於拉取請求的工作流程,自動化測試變得簡單明了,使推出更簡單,並使團隊能夠有效率地擴展短暫的環境。

所以,還在等什麼?立即開始探索基於租戶的短暫環境如何改變您的開發工作流程。

引用連結[1] Using Istio or Linkerd To Unlock Ephemeral Environments:https://thenewstack.io/using-istio-or-linkerd-to-unlock-ephemeral-environments/
[2]短暫環境:https://thenewstack.io/smart-ephemeral-environments-share-more-copy-less
[3]傳統的共享預發布環境相關的陷阱:https://thenewstack.io/why-staging-doesnt-scale-for-microservice-testing/
[4]Kubernetes:https://roadmap.sh/kubernetes
[5]帶來了巨大的挑戰:https://thenewstack.io/why-duplicating-environments-for-microservices-backfires/
[6]微服務架構:https://thenewstack.io/microservices-testing-cycles-are-too-slow
[7]SLATE:https://www.notion.so/Istio-or-Linkerd-Unlock-Ephemeral-Environments-Easily-19708fc654be80a4887ce5d5daa5cf8f?pvs=21
[8]隔離測驗:https://careersatdoordash.com/blog/moving-e2e-testing-into-production-with-multi-tenancy-for-increased-speed-and-reliability/
[9]OpenTelemetry (OTel):https://thenewstack.io/what-is-opentelemetry-the-ultimate-guide/
[10]使用 OpenTelemetry 的 Kubernetes 沙箱:https://www.signadot.com/blog/sandboxes-in-kubernetes-using-opentelemetry