為什麼容器協調流程很重要？
在本單元中，您可以在 Tailspin 小組探索從管理提供新指示詞的策略的時候跟隨他們。 小組會檢查 Kubernetes 如何協助他們轉換至微服務架構。
未來變得更小
Tailspin 的情況開始好轉。 在最近的管理階層異地會議中，Andy 簡報了其小組最近使用 Azure DevOps 獲得的成功，廣受好評。 Andy 也簡報了該小組最近使用 Docker 容器的概念證明專案示範。 這些示範會產生有關組織的技術未來的一系列生產力對話。 隔天，Andy 回來與 Space Game Web 小組分享新消息。
Andy：在我昨天的異地簡報中，一切都很順利。 管理階層對我們目前為止完成的工作印象深刻，並交給我們特殊的任務。
Tim：喔喔。 我太有經驗了，我一看就知道這是陷阱。
Andy：不是，這是我們的好機會。 管理階層喜歡我們的 Docker 容器示範，並希望我們探索採用微服務架構。
Amita：微服務？ 像是用於手機和手錶的應用程式？
Andy：不是，微服務是一般的應用程式，像是 Web 應用程式。 主要差異在於，我們不會建置及部署單一整合型應用程式，而是會重構可以以自發服務形式更妥善維護和管理的任何元件。 然後，我們會建置這些服務，以發揮其功能，並加以部署以獨立運作。
Tim：我不確定我喜歡這種作法。 我已經在處理我們環境中這麼多的服務。 我不知道我是否想要有更多服務。
Andy：我可以理解您的疑慮。 有幸的是，有一些很好的工具可以用來管理特定環境中的許多容器。 我們被要求針對使用 Kubernetes 進行協調的 Web 應用程式，推出多容器解決方案。 他們也想要知道它會如何影響我們的 DevOps 程序。
Mara：我聽說過 Kubernetes。 Azure 透過 Azure Kubernetes Service 可以很好地加以支援，而且我知道 Azure DevOps 中對其有管線支援。
Amita：這個程序聽起來很複雜。 它會如何影響測試？
Mara：其應該不會是顯著的變更。 Kubernetes 提供一個方式，讓我們部署到不同的命名空間。 這可讓我們將部署分割，使我們可以將整個環境專用於測試與實際執行。 而因為它們全都在相同的叢集中執行，並使用相同的容器，該測試體驗應能提供我們預期會在實際執行環境中看到的內容。
Amita：要持續追蹤什麼環境在何處會不會很難？
Mara：不會，我們可以使用 Azure DevOps 環境來完成。 您將可以使用入口網站來找出每個服務的所在位置，以及它如何到達該位置。 一切都會透過管線自動完成，因此我們不需要手動追蹤。 我現在的唯一疑慮是，要加以建置的話，對我們的開發體驗會有多少影響。
Andy：好消息是影響很少。 假設我們已將專案設定為建置 Docker 容器，那麼，我們只需要將描述服務及其部署的一些資訊清單檔部署至 Kubernetes。
Mara：你有沒有想過，我們要將什麼重構為第二個容器？ 我知道有幾個小組要求我們透過 Web API 提供排行榜。
Andy：我早你一步。 我昨晚將 Docker 專案派生，並將排行榜資料功能重構成其自己的微服務。 這使得我們有一個容器用於網站，有另一個用於排行榜 API。 這兩個容器都經過設定，有自己的公用端點，我們可以將其與任何想要使用網站或 API 的人共用，而不論他們的應用程式中使用的技術堆疊為何。 如果這兩個容器的負載大幅成長，那麼，我們可以個別調整其容器。
Mara：這個專案聽起來很棒！ 讓我們開始更新發行管線。
什麼是 Kubernetes？
Kubernetes 是開放原始碼容器協調流程平台，可將容器化應用程式的部署、調整和管理自動化。 它提供架構，可讓您以宣告式、回應式的方式執行分散式系統，並且可跨多個主機執行容器，讓資源的使用有效率並提升可靠性。
Tailspin 小組為此案例選取了 Kubernetes，因為它符合其所有需求：
多容器部署的複雜度：Kubernetes 的設計最重要的是可將有關部署和維護容器部署的程序自動化。
環境和階段之間的一致性：正如同容器可確保其所包含應用程式的一致部署，Kubernetes 可確保叢集所管理容器的一致部署。
Azure DevOps 支援：Azure DevOps 提供使用 Kubernetes 的第一級支援。
方便開發：來源專案上 Kubernetes 的影響相當於新增 Docker 支援，影響有限且僅限宣告式設定。
採用 Kubernetes 可大幅簡化採用使用多個 Docker 容器的微服務架構的程序。