規劃應用程式部署

我可以在 IBM Cloud Kubernetes Service 中執行哪些類型的應用程式？

無狀態的應用程式

無狀態的應用程式是 Kubernetes 這類雲端本機環境的首選。 它們易於移轉及調整，因為它們會宣告相依關係、將配置與程式碼分開儲存，並將資料庫這類支援服務視為已連接的資源，而不是連結至應用程式。 應用程式 Pod 不需要持久性資料儲存或穩定的網路 IP 位址，因此 Pod 可以因應工作負載需求而終止、重新排程及擴充。 該應用程式使用「資料庫即服務」來持續保存資料，並且使用 NodePort、負載平衡器或 Ingress 服務在穩定 IP 位址上公開工作負載。

有狀態的應用程式

在設定、管理及調整方面，有狀態的應用程式比無狀態的應用程式更為複雜，因為 Pod 需要持續資料及穩定網路身分。 有狀態的應用程式通常是資料庫或其他分散式資料密集工作負載，而這些工作負載的處理更有效的接近資料本身。 如果您要部署有狀態的應用程式，則需要設定持續性儲存空間，並將持續性磁區裝載至由 StatefulSet 物件所控制的 Pod。 您可以選擇將檔案、 區塊或物件儲存空間新增為有狀態集合的持續性儲存空間。 您也可以將 Portworx 在您的裸金屬工作節點上，並使用 Portworx 作為高度可用的軟體定義儲存解決方案，為您的有狀態應用程式管理持久性儲存。 有關有狀態集如何運作的詳細資訊，請參閱 Kubernetes 文件。

開發無狀態雲端本機應用程式有哪些準則？

查看 Twelve-Factor App，這是一種語言中立的方法，可從 12 個因素考慮如何開發您的應用程式，總結如下。

1. 程式碼庫: 在版本控制系統中使用單一程式碼庫來進行部署。 當您取回容器部署的映像檔時，請指定已測試的映像檔標籤，而不是使用 latest。
2. 相依關係：明確地宣告及隔離外部相依關係。
3. 配置：將部署特定配置儲存在環境變數中，而不是程式碼。
4. 支援服務：將資料儲存或訊息佇列這類支援服務視為已連接或可更換的資源。
5. 應用程式階段：在不同的階段（例如 build、release、run）中建置，並且嚴格區隔它們。
6. 處理程序：以一個以上的無狀態處理程序執行，這些無狀態處理程序未共用任何項目，且使用持續性儲存空間來儲存資料。
7. 埠連結：埠連結為自行包含，並在明確定義的主機和埠上提供服務端點。
8. 並行：透過處理程序實例（例如抄本和水平調整）管理及調整應用程式。 設定部署的資源要求和限制。 請注意 Calico 網路政策無法限制頻寬。 請改為考慮 Istio。
9. 可移除：將您的應用程式設計為可移除的，具有最小啟動、循序關閉以及對突然處理程序終止的容錯。 請記住，容器、Pod 甚至是工作者節點都是可移除的，因此請據此規劃您的應用程式。
10. 開發到生產的同等性：為您的應用程式建立持續整合與持續交付管道，將開發中的應用程式與生產中的應用程式之間的差異降至最低。
11. 日誌：將日誌視為事件串流：外部或管理環境會處理及遞送日誌檔。 重要事項：在 IBM Cloud Kubernetes Service 中，依預設不會開啟日誌。 若要啟用，請參閱配置日誌轉遞。
12. 管理程序：將任何一次性管理腳本與您的應用程式一起保留，並作為 Kubernetes Job 物件執行，以確保管理腳本的執行環境與應用程式本身相同。 若要協調要在 Kubernetes 群集中執行的大型套件，請考慮使用套件管理員，例如 Helm.

無伺服器應用程式如何?

您可以透過服務執行無伺服器應用程式與工作。Code Engine 該 IBM Cloud Code Engine 服務亦可為您構建映像檔。Code Engine 此服務的設計理念在於，您無需與其底層技術進行互動。 然而，若您現有的工具基於 Kubernetes 或 Knative 開發，您仍可繼續在 Code Engine 環境中使用它們。 如需更多資訊，請參閱《 使用 與 Kubernetes 您的應用程式互動 》。

我已經有應用程式。 如何將它移轉至 IBM Cloud Kubernetes Service？

您可以採取一些一般步驟，如下所示將您的應用程式容器化。

1. 使用 Twelve-Factor App 作為隔離依賴關係的指南，將程序分隔為不同的服務，並盡可能降低應用程式的狀態性。
2. 尋找要使用的適當基礎映像檔。 您可以使用 Docker Hub 的公開圖片、公開的 IBM 圖片，或在您的私人 IBM Cloud Container Registry 中建立和管理您自己的圖片。
3. 只將執行應用程式所需的內容新增至 Docker 映像檔。
4. 規劃使用持續性儲存空間或雲端資料庫即服務解決方案來備份應用程式資料，而不依賴本端儲存空間。
5. 一段時間後，將應用程式處理程序重構為微服務。

我認為需要將應用程式置於容器中。 現在，要怎麼處理這些 Pod 相關項目？

Pod 是 Kubernetes 可以管理的最基本的可部署單元。 您可以將容器（或容器群組）放入 Pod 中，並使用 Pod 配置檔告知 Pod 如何執行容器以及與其他 Pod 共用資源。 您放入 Pod 的所有容器都在共用上下文中執行，這表示它們共用虛擬或實體機器。

放置在容器中的內容

當您思考應用程式的元件時，請考慮它們對 CPU 和記憶體等資源的需求是否有顯著的差異。 某些元件是否可以盡最大努力運行，在這種情況下，短暫停機以將資源轉移到其他領域是可以接受的？ 是否有另一個客戶端適用元件，因此，保持這一點至關重要？ 請將它們分割至不同的容器。 您可以隨時將它們部署至相同的 Pod，讓它們同步一起執行。

放置在 Pod 中的內容

應用程式的容器不一定必須位於相同的 Pod 中。 事實上，如果您的元件是有狀態的且難以調整（例如資料庫服務），則請將其放入可排定於工作者節點的不同 Pod 中，該工作者節點具有較多資源可以處理工作負載。 如果在不同工作者節點上執行的容器可以正常工作，請使用多個 Pod。 如果它們需要在相同的機器上並一起調整，請將容器分組到相同的 Pod 中。

所以，如果我可以使用 Pod，為什麼我還需要這些不同類型的物件呢？

建立 Pod YAML 檔案很容易。 只需要幾行就可以撰寫一個檔案，如下所示。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

然而，您不想就這樣停止。 如果關閉 Pod 執行所在的節點，則會同時關閉 Pod，且不會重新予以排定。 取而代之，使用 部署來支援 Pod 重新排程、複製集和滾動更新。 基本部署幾乎就像建立 Pod 一樣簡單。 不過，您可以在部署 spec 中指定 replicas 和 template，而非自行在 spec 中定義容器。 範本在其中具有容器的專屬 spec，如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

您可以在相同的 YAML 檔案中持續新增 Pod 反親緣性或資源限制這類特性。

如需更詳細的說明您可以加入部署的不同功能，請參閱 製作您的應用程式部署 YAML 檔案。

我可以為應用程式提供哪些類型的 Kubernetes 物件？

當您準備應用程式 YAML 檔案時，有許多選項可以增加應用程式的可用性、效能及安全。 例如，不是使用單一 Pod，而是您可以使用 Kubernetes 控制器物件來管理工作負載，例如抄本集、工作或常駐程式集。 如需 Pod 和控制器的詳細資訊，請檢視 Kubernetes 文件。 管理 Pod 的抄本集的部署是應用程式的常見使用案例。

例如，kind: Deployment 物件是部署應用程式 Pod 的良好選擇，因為搭配它，您可以針對 Pod 指定可用性更高的抄本集。

下表說明為何您可以建立不同類型的 Kubernetes 工作負載物件。

如果我希望我的應用程式組態使用變數，該怎麼辦？ 如何將這些變數加入 YAML？

若要在部署中加入變數資訊，而非將資料硬編入 YAML 檔案，您可以使用 Kubernetes ConfigMap 或 Secret 物件。

若要耗用 Configmap 或密碼，您需要將其裝載至 Pod。 Configmap 或密碼會與 Pod 結合，再執行 Pod。 您可以在許多應用程式之間重複使用部署規格和映像檔，但接著會交換自訂的 ConfigMap 或密碼。 特定密碼可能會在本端節點上佔用許多儲存空間，因此請相應地規劃。

這兩個資源都定義金鑰值配對，但您將它們用於不同的狀況。

Configmap

針對部署中指定的工作負載，提供非機密的配置資訊。 您可以採用三種主要方式來使用 Configmap。

• 檔案系統：您可以將整個檔案或變數集掛載到 Pod。 會根據設為此值的檔案金鑰名稱內容，為每一個項目建立一個檔案。
• 環境變數：動態設定容器規格的環境變數。
• 命令列選項：設定容器規格中使用的命令列選項。

密碼

將機密性資訊提供給工作負載，如下所示。 叢集的其他使用者可能有權存取密碼，因此請確保您確定可以與這些使用者共用密碼資訊。

• 個人識別資訊 (PII：儲存敏感資訊，如電子郵件地址或其他類型的資訊，這些資訊在秘密中是公司合規或政府法規所要求的。
• 憑證：將密碼、鑰匙和令牌等憑證保密，以降低意外曝光的風險。 例如，當您連結服務至叢集時，認證會儲存在密碼中。

想要讓您的密碼更加安全嗎？ 要求叢集管理者在叢集裡 啟用金鑰管理服務提供者，以加密新的及現有的密碼。

如何確保我的應用程式擁有正確的資源？

當您 指定您的應用程式 YAML 檔案 時，您可以在應用程式組態中加入 Kubernetes 功能，幫助您的應用程式取得正確的資源。 特別是，為 YAML 檔案中定義的每個容器 設定資源限制和請求。

此外，您的叢集管理者也可能設定可以影響應用程式部署的資源控制，如下所示。

• 資源配額
• Pod 優先順序

如何在我的應用程式配置中加入功能？

如需您可能包括在部署中的項目的說明，請參閱在 YAML 檔案中指定您的應用程式需求。 範例包括下列選項。

• 抄本集
• 標籤
• 親緣性
• 映像檔原則
• 埠
• 資源要求及限制
• 存活性及就緒探測
• 服務，以便在連接埠公開應用程式服務。
• Configmaps 以設定儲存器環境變數。
• 密鑰，用於設定儲存器環境變數。
• 裝載至儲存器以儲存的 持續性磁區。

如何在我的應用程式中加入 IBM 服務，例如 Watson？

請參閱將服務新增至應用程式。

如何增加應用程式的可用性?

請考量下列選項，以增加應用程式的可用性。

使用部署和抄本集來部署您的應用程式及其相依關係

部署是 Kubernetes 資源，您可以使用它來宣告應用程式的所有元件及其相依性。 透過部署，您不需要寫下所有步驟，反而可以專注於您的應用程式。 當您部署一個以上的 Pod 時，系統會自動為您的部署建立一個複製集，以監控 Pod 並確保指定數量的 Pod 正常運作。 當一個 Pod 關閉時，抄本集會以新的 Pod 來取代無回應的 Pod。 您可以使用部署來定義應用程式的更新策略，包括在漸進式更新期間要新增的 Pod 數，以及允許同時無法使用的 Pod 數。 執行滾動更新時，部署會檢查修訂版本是否正常運作，並在偵測到故障時停止滾動更新。 透過部署，您可以同時部署具有不同選項的多個版本。 例如，您可以先測試部署，然後再決定將其推送至正式作業。 藉由使用部署，您可以追蹤任何已部署的修訂。 如果發現更新無法如預期般運作時，則您可以使用此歷程來回復至舊版。

為應用程式的工作負載包含足夠的抄本，然後加兩個

若要讓您的應用程式更具高度可用性，對失敗更有彈性，請考慮在最小副本之外加入額外的副本，以處理預期的工作負載。 如果 pod 崩潰，而副本集尚未復原崩潰的 pod，則額外的副本可以處理工作負載。 若要防範兩個同時發生的故障，請包含兩個額外的複本。 此設定為 N+2 模式，其中 N 為處理傳入工作負載的副本數量，+2 為兩個額外副本。 只要您的叢集有足夠空間，就可以有任意數目的 Pod。

將 Pod 分散於多個節點（反親緣性）

當您建立部署時，可以將每一個 Pod 部署至相同的工作者節點。 這稱為親和性或同位。 為了保護您的應用程式免於工作者節點故障，您可以透過使用 podAntiAffinity 選項與標準叢集，設定您的部署，將 Pod 分散到多個工作者節點。 您可以定義兩種類型的 Pod 反親緣性：偏好或必要。 如需詳細資訊，請參閱 Kubernetes 有關為 節點指定 Pod 的說明文件。

如需應用程式部署中的親緣性範例，請參閱建立應用程式部署 YAML 檔案。

將 Pod 分散在多個區域或地區

若要保護應用程式不發生區域失敗，您可以在不同區域中建立多個叢集，或將區域新增至多區域叢集裡的工作者節點儲存區。 多區域叢集僅在特定 標準 或 VPC 多區域 (例如達拉斯) 中可用。 如果您在不同區域中建立多個叢集，則必須設定廣域負載平衡器。 當您使用抄本集並指定 Pod 反親緣性時，Kubernetes 會將應用程式 Pod 分散到各節點。 如果您的節點位於多個區域中，則會將 Pod 分散到各區域，以增加應用程式的可用性。 如果您要限制應用程式只在某個區域中執行，則可以配置 Pod 親緣性，或在某個區域中建立及標示工作者節點儲存區。

在多區群集部署中，我的應用程式 Pod 是否平均分佈在各個節點上？

Pod 會平均分散到各區域，但不一定會分散到各節點。 例如，如果叢集在 3 個區域中分別有 1 個節點，並且部署包含 6 個 Pod 的抄本集，則每個節點會獲得 2 個 Pod。 但是，如果叢集在 3 個區域中分別有 2 個節點，並且部署包含 6 個 Pod 的抄本集，則每個區域會排定 2 個 Pod，這 2 個 Pod 可能會每個節點排定 1 個 Pod，也可能 2 個 Pod 都排定在一個節點上。 若要對排程進行更多控制，您可以 設定 Pod 親和性。

如果一個區域發生故障，如何將 Pod 重新排程到其他區域的剩餘節點？

它取決於您在部署中使用的排程原則。 如果您包含 特定於節點的 pod 親和性，您的 pod 將不會重新排程。 如果您未這麼做，則會在其他區域的可用工作者節點上建立 Pod，但它們可能不平衡。 例如，這 2 個 Pod 可能分散在 2 個可用節點上，也可能都排定到 1 個具有可用容量的節點上。 同樣地，傳回無法使用區域時，不會自動刪除 Pod，也不會重新讓它在各節點之間保持平衡。 如果您希望在區域重新啟動後，重新平衡各區域的 Pod，請設定 Kubernetes descheduler。 在多區群集中，嘗試將每個區域的工作站節點容量維持在 50%，以便有足夠的容量保護群集，避免區域故障。

如果我想要將應用程式分散到不同地區，該怎麼辦？

若要保護您的應用程式免於區域故障，請在另一個區域建立第二個群集，設定全域負載平衡器 以連接您的群集，並使用部署 YAML 為您的應用程式部署具有 Pod anti-affinity的複製集。

如果我的應用程式需要持久性儲存，該怎麼辦？

請使用雲端服務（例如 IBM Cloudant 或 IBM Cloud Object Storage）。

如何擴充我的應用程式？

如果您想要動態新增及移除應用程式以回應工作負載用量，請參閱 調整應用程式，以取得啟用水平 Pod 自動調整的步驟。

如何組織部署讓它們更容易更新及管理？

既然，您已經清楚瞭解部署中要包含的項目，您可能想知道將如何管理所有這些不同的 YAML 檔案？ 更不用說在 Kubernetes 環境中建立的物件！

下列提示可協助您組織部署 YAML 檔案。

• 使用版本控制系統（例如 Git）。
• 在單一 YAML 檔案內，將緊密相關的 Kubernetes 物件進行分組。 例如，如果您要建立 deployment，則可能也會將 service 檔案新增至 YAML。 使用 --- 來區隔物件，如下列範例所示。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• 您可以使用 kubectl apply -f 指令來套用至整個目錄，而不只是套用至單一檔案。

在 YAML 檔案內，您可以使用標籤或註釋作為 meta 資料來管理部署。

標籤

標籤是 key:value 對，可以附加到 Kubernetes 物件，例如 Pod 和部署。 它們可以是您想要的任何項目，而且有助於根據標籤資訊選取物件。 標籤提供用於分組物件的基礎。 如需標籤的構想，請參閱下列範例。

• app: nginx
• version: v1
• env: dev

註釋

註解與標籤類似，也是 key:value 對。 它們適用於可供工具或程式庫運用的非識別資訊，例如保留有關物件來源、如何使用物件、相關追蹤儲存庫的指標，或物件相關原則的額外資訊。 您不能根據註釋來選取物件。

我可以使用哪些應用程式更新策略？

若要更新應用程式，可以從各種策略中進行選擇，例如下列策略。 在進行更複雜的 Canary 部署之前，您可以從漸進式部署或即時切換開始。

漸進式部署

您可以使用 Kubernetes 原生功能來建立 v2 部署，並逐步取代先前的 v1 部署。 此方法要求應用程式與早期版本相容，因此提供 v2 應用程式版本的使用者不會遇到任何破壞性變更。 如需相關資訊，請參閱管理漸進式部署以更新應用程式。

即時切換

即時切換也稱為藍綠部署，需要將運算資源加倍，才能同時執行應用程式的兩個版本。 使用此方式，您可以近乎即時地將使用者切換至較新的版本。 請務必使用服務標籤選擇器 (例如 version: green 和 version: blue)，以確保將要求傳送到正確的應用程式版本。 您可以建立新的 version: green 部署，並等待它就緒，然後刪除 version: blue 部署。 或者您可以執行 滾動更新，但將 maxUnavailable 參數設定為 0%，將 maxSurge 參數設定為 100%。

Canary 或 A/B 部署

Canary 部署是更複雜的更新策略，是指您挑選一定比例（例如 5%）的使用者並將他們傳送至新的應用程式版本。 您可以在記載及監視工具中收集下列作業的度量值：如何執行新的應用程式版本，執行 A/B 測試，然後將更新項目推出給更多使用者。 與所有部署一樣，標示應用程式（例如，version: stable 和 version: canary）至關重要。 若要管理金絲雀部署，您可能 會安裝受管理的 Istio 附加服務網狀結構， 為您的群集設定 Monitoring，然後如本部落格文章所述，使用 Istio 服務網狀結構進行 A/B 測試。

如何自動化應用程式部署？

如果您要在多個叢集、公用和專用環境或甚至多個雲端提供者中執行應用程式，您可能想知道要如何讓部署策略跨這些環境運作。 使用 IBM Cloud 及其他開放程式碼工具，您可以包裝應用程式，以協助自動化部署。

設定持續整合及交付 (CI/CD) 管線

使用您在 Git 這類來源控制管理系統中所組織的應用程式配置檔，即可建置管線，以測試程式碼並將其部署至 test 及 prod 這類不同的環境。 與群集管理員合作設定持續整合與遞送。

包裝應用程式配置檔

使用 HelmKubernetes 套件管理員，您可以在 Helm 圖表中指定應用程式所需的所有 Kubernetes 資源。 然後，您可以使用 Helm 來建立 YAML 配置檔，並在叢集裡部署這些檔案。 您也可以 整合 IBM Cloud- 提供 Helm 圖表 來擴充群集的功能，例如使用區塊儲存外掛程式。

您要建立 YAML 檔案範本嗎? 有些人使用 Helm 來做這件事，或者您也可以試試其他社群工具，例如 ytt.

我該如何確保我的服務已連接至正確的部署，並已準備就緒？

對於大部分的服務，請將選取器新增至服務 .yaml 檔案，讓它適用於透過該標籤執行應用程式的 Pod。 很多時候，當您的應用程式第一次啟動時，您不希望它立即處理請求。 將就緒探測新增至部署，讓資料流量只傳送至視為就緒的 Pod。 有關使用標籤並設定就緒探針的服務部署範例，請參閱此 NGINX YAML。

有時，您並不希望服務使用標籤。 例如，您可能有一個外部資料庫，或想要將服務指向叢集內不同名稱空間中的另一個服務。 發生此情況時，您必須手動新增 endpoints 物件，並將它鏈結至服務。

如何在網際網路上公開服務？

您可以針對外部網路建立三種類型的服務：NodePort、LoadBalancer 及 Ingress。

您有不同的選項，這些選項取決於您的群集類型。 如需相關資訊，請參閱規劃網路服務。

• 標準叢集：您可以使用 NodePort、負載平衡器或 Ingress 服務來公開應用程式。
• 使用 Calico 成為專用的叢集：您可以使用 NodePort、負載平衡器或 Ingress 服務來公開應用程式。 您也必須使用 Calico DNAT 前網路原則，來封鎖公用節點埠。
• 僅限專用 VLAN 標準叢集：您可以使用 NodePort、負載平衡器或 Ingress 服務來公開應用程式。 您也必須在防火牆中開啟服務專用 IP 位址的埠。

當您規劃叢集裡需要多少 Service 物件時，請記住，Kubernetes 使用 iptables 來處理網路及埠轉遞規則。 如果您在群集中執行許多服務，例如 5000，效能可能會受到影響。

如何控制誰可以存取我的應用程式部署？

帳戶和叢集管理者可以控制許多不同層次的存取：叢集、Kubernetes 名稱空間、Pod 及容器。

使用 IBM Cloud IAM，您可以在叢集實例層次上，將許可權指派給個別使用者、群組或服務帳戶。 您可以限制使用者只能使用叢集內的特定名稱空間，來進一步限定叢集存取範圍。 如需相關資訊，請參閱指派叢集存取。

若要在 pod 層級控制存取，您可以設定 pod 安全政策 (PSP)。

在應用程式部署 YAML 內，您可以設定 Pod 或容器的安全環境定義。 如需詳細資訊，請檢閱 Kubernetes 文件。

在我部署應用程式之後，如何監視其性能？

您可以針對叢集設定 IBM Cloud 記載和監視。 您也可以選擇與協力廠商記載或監視服務整合。