組態最佳實務

本文件重點介紹並整合了使用者指南、開始使用文件以及範例中介紹的組態最佳實務。

這是一份持續更新的文件。如果您想到此清單上沒有但可能對其他人有用的內容，請隨時提交 Issue 或 PR。

一般組態提示

• 定義組態時，請指定最新的穩定 API 版本。

• 組態檔案應在推送至叢集之前儲存在版本控制中。這可讓您在必要時快速回滾組態變更。它也有助於叢集重新建立與還原。

• 請使用 YAML 而非 JSON 撰寫組態檔案。雖然這些格式在幾乎所有情況下都可以互換使用，但 YAML 往往更方便使用者使用。

• 在合理的情況下，將相關物件分組到單一檔案中。一個檔案通常比多個檔案更容易管理。請參閱 guestbook-all-in-one.yaml 檔案，作為此語法的範例。

• 另請注意，許多 kubectl 指令可以在目錄上呼叫。例如，您可以在組態檔案目錄上呼叫 kubectl apply。

• 請勿不必要地指定預設值：簡單、最小的組態將使錯誤發生的可能性降低。

• 將物件描述放在註解中，以便更好地進行內省。

「裸機」Pod 與 ReplicaSets、Deployments 和 Jobs

• 如果可以避免，請勿使用裸機 Pod（即未繫結至 ReplicaSet 或 Deployment 的 Pod）。裸機 Pod 在節點發生故障時不會重新排程。

  Deployment 既建立 ReplicaSet 以確保始終提供所需數量的 Pod，又指定取代 Pod 的策略（例如 RollingUpdate），幾乎總是比直接建立 Pod 更可取，但某些明確的 restartPolicy: Never 情境除外。Job 也可能是合適的。

服務

• 在其對應的後端工作負載（Deployments 或 ReplicaSets）之前，以及在任何需要存取它的工作負載之前，建立 Service。當 Kubernetes 啟動容器時，它會提供指向所有在容器啟動時正在執行的服務的環境變數。例如，如果名為 foo 的服務存在，則所有容器都會在其初始環境中取得以下變數

  FOO_SERVICE_HOST=<the host the Service is running on>
  FOO_SERVICE_PORT=<the port the Service is running on>
  

  這確實暗示了排序要求 - 任何 Pod 想要存取的 Service 都必須在 Pod 本身之前建立，否則環境變數將不會被填入。DNS 沒有此限制。

• 一個可選的（但強烈建議）叢集附加元件是 DNS 伺服器。DNS 伺服器監看 Kubernetes API 中新的 Services，並為每個服務建立一組 DNS 記錄。如果叢集中已啟用 DNS，則所有 Pods 應該都能夠自動解析 Services 的名稱。

• 除非絕對必要，否則請勿為 Pod 指定 hostPort。當您將 Pod 繫結到 hostPort 時，會限制可以排程 Pod 的位置數量，因為每個 <hostIP、hostPort、protocol> 組合都必須是唯一的。如果您未明確指定 hostIP 和 protocol，Kubernetes 將使用 0.0.0.0 作為預設的 hostIP，並使用 TCP 作為預設的 protocol。

  如果您只需要為了偵錯目的而存取埠，可以使用 apiserver proxy 或 kubectl port-forward。

  如果您明確需要將 Pod 的埠公開在節點上，請考慮在使用 hostPort 之前，先使用 NodePort Service。

• 基於與 hostPort 相同的原因，請避免使用 hostNetwork。

• 當您不需要 kube-proxy 負載平衡時，請使用 Headless Services（其 ClusterIP 為 None）進行服務發現。

使用標籤

• 定義並使用 標籤，以識別您的應用程式或部署的**語意屬性**，例如 { app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }。您可以使用這些標籤為其他資源選取適當的 Pod；例如，一個 Service 選取所有 tier: frontend Pod，或 app.kubernetes.io/name: MyApp 的所有 phase: test 組件。請參閱 guestbook 應用程式，以取得此方法的範例。

  透過從其選取器中省略特定於版本的標籤，可以使 Service 跨越多個 Deployment。當您需要更新正在運行的服務而無需停機時，請使用 Deployment。

  物件的期望狀態由 Deployment 描述，如果對該規範的變更被套用，則部署控制器會以受控速率將實際狀態變更為期望狀態。

• 針對常見的使用案例，請使用 Kubernetes 常見標籤。這些標準化標籤以一種允許工具（包括 kubectl 和 dashboard）以可互通的方式運作的方式豐富了 metadata。

• 您可以操作標籤以進行偵錯。由於 Kubernetes 控制器（例如 ReplicaSet）和 Service 使用選取器標籤來匹配 Pod，因此從 Pod 中移除相關標籤將阻止控制器考慮它或阻止 Service 為其提供流量。如果您移除現有 Pod 的標籤，其控制器將建立一個新的 Pod 來取代它。這是在「隔離」環境中偵錯先前「線上」Pod 的一種有用方法。若要互動式地移除或新增標籤，請使用 kubectl label。

使用 kubectl

• 使用 kubectl apply -f <directory>。這會在 <directory> 中所有 .yaml、.yml 和 .json 檔案中尋找 Kubernetes 設定，並將其傳遞給 apply。

• 對於 get 和 delete 操作，請使用標籤選取器，而不是特定的物件名稱。請參閱關於 標籤選取器 和 有效使用標籤 的章節。

• 使用 kubectl create deployment 和 kubectl expose 快速建立單一容器 Deployment 和 Service。請參閱 使用 Service 存取叢集中的應用程式 以取得範例。