# 配置最佳實踐 本文檔旨在匯總和強調用戶指南、快速開始文檔和示例中的最佳實踐。該文檔會很活躍并持續更新中。如果你覺得很有用的最佳實踐但是本文檔中沒有包含，歡迎給我們提Pull Request。 ## 通用配置建議 - 定義配置文件的時候，指定最新的穩定API版本（目前是V1）。 - 在配置文件push到集群之前應該保存在版本控制系統中。這樣當需要的時候能夠快速回滾，必要的時候也可以快速的創建集群。 - 使用YAML格式而不是JSON格式的配置文件。在大多數場景下它們都可以作為數據交換格式，但是YAML格式比起JSON更易讀和配置。 - 盡量將相關的對象放在同一個配置文件里。這樣比分成多個文件更容易管理。 - 為了簡化和最小化配置，也為了防止錯誤發生，不要指定不必要的默認配置。例如，省略掉`ReplicationController`的selector和label，如果你希望它們跟`podTemplate`中的label一樣的話，因為那些配置默認是`podTemplate`的label產生的。 - 將資源對象的描述放在一個annotation中可以更好的內省。 ## 裸的Pods vs Replication Controllers和 Jobs - 如果有其他方式替代“裸的“ pod（如沒有綁定到[replication controller ](https://kubernetes.io/docs/user-guide/replication-controller)上的pod），那么就使用其他選擇。在node節點出現故障時，裸奔的pod不會被重新調度。Replication Controller總是會重新創建pod，除了明確指定了[`restartPolicy: Never`](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 的場景。[Job](https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/) 也許是比較合適的選擇。 ## Services - 通常最好在創建相關的[replication controllers](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/)之前先創建[service](https://kubernetes.io/docs/concepts/services-networking/service/) ，你也可以在創建Replication Controller的時候不指定replica數量（默認是1），創建service后，在通過Replication Controller來擴容。這樣可以在擴容很多個replica之前先確認pod是正常的。 - 除非十分必要的情況下（如運行一個node daemon），不要使用`hostPort`（用來指定暴露在主機上的端口號）。當你給Pod綁定了一個`hostPort`，該pod可被調度到的主機的受限了，因為端口沖突。如果是為了調試目的來通過端口訪問的話，你可以使用 [kubectl proxy and apiserver proxy](https://kubernetes.io/docs/tasks/access-kubernetes-api/http-proxy-access-api/) 或者 [kubectl port-forward](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。你可使用 [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 來對外暴露服務。如果你確實需要將pod的端口暴露到主機上，考慮使用 [NodePort](https://kubernetes.io/docs/user-guide/services/#type-nodeport) service。 - 跟`hostPort`一樣的原因，避免使用 `hostNetwork`。 - 如果你不需要kube-proxy的負載均衡的話，可以考慮使用使用[headless services](https://kubernetes.io/docs/user-guide/services/#headless-services)。 ## 使用Label - 定義 [labels](https://kubernetes.io/docs/user-guide/labels/) 來指定應用或Deployment的 **semantic attributes** 。例如，不是將label附加到一組pod來顯式表示某些服務（例如，`service:myservice`），或者顯式地表示管理pod的replication controller（例如，`controller:mycontroller`），附加label應該是標示語義屬性的標簽， 例如`{app:myapp,tier:frontend,phase:test,deployment:v3}`。 這將允許您選擇適合上下文的對象組——例如，所有的”tier:frontend“pod的服務或app是“myapp”的所有“測試”階段組件。 可以通過簡單地從其service的選擇器中省略特定于發行版本的標簽，而不是更新服務的選擇器來完全匹配replication controller的選擇器，來實現跨越多個部署的服務，例如滾動更新。 - 為了滾動升級的方便，在Replication Controller的名字中包含版本信息，例如作為名字的后綴。設置一個`version`標簽頁是很有用的。滾動更新創建一個新的controller而不是修改現有的controller。因此，version含混不清的controller名字就可能帶來問題。查看[Rolling Update Replication Controller](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/)文檔獲取更多關于滾動升級命令的信息。 注意 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 對象不需要再管理 replication controller 的版本名。Deployment 中描述了對象的期望狀態，如果對spec的更改被應用了話，Deployment controller 會以控制的速率來更改實際狀態到期望狀態。（Deployment目前是 [`extensions` API Group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)的一部分）。 - 利用label做調試。因為Kubernetes replication controller和service使用label來匹配pods，這允許你通過移除pod中的label的方式將其從一個controller或者service中移除，原來的controller會創建一個新的pod來取代移除的pod。這是一個很有用的方式，幫你在一個隔離的環境中調試之前的“活著的” pod。查看 [`kubectl label`](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) 命令。 ## 容器鏡像 - [默認容器鏡像拉取策略](https://kubernetes.io/docs/concepts/containers/images/) 是 `IfNotPresent`, 當本地已存在該鏡像的時候 [Kubelet](https://kubernetes.io/docs/admin/kubelet/) 不會再從鏡像倉庫拉取。如果你希望總是從鏡像倉庫中拉取鏡像的話，在yaml文件中指定鏡像拉取策略為`Always`（ `imagePullPolicy: Always`）或者指定鏡像的tag為 `:latest` 。 如果你沒有將鏡像標簽指定為`:latest`，例如指定為`myimage:v1`，當該標簽的鏡像進行了更新，kubelet也不會拉取該鏡像。你可以在每次鏡像更新后都生成一個新的tag（例如`myimage:v2`），在配置文件中明確指定該版本。 **注意：** 在生產環境下部署容器應該盡量避免使用`:latest`標簽，因為這樣很難追溯到底運行的是哪個版本的容器和回滾。 ## 使用kubectl - 盡量使用 `kubectl create -f <directory>` 。kubeclt會自動查找該目錄下的所有后綴名為`.yaml`、`.yml`和`.json`文件并將它們傳遞給`create`命令。 - 使用 `kubectl delete` 而不是 `stop`. `Delete` 是 `stop`的超集，`stop` 已經被棄用。 - 使用 kubectl bulk 操作（通過文件或者label）來get和delete。查看[label selectors ](https://kubernetes.io/docs/user-guide/labels/#label-selectors)和 [using labels effectively](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)。 - 使用 `kubectl run` 和 `expose` 命令快速創建只有單個容器的Deployment。查看 [quick start guide](https://kubernetes.io/docs/user-guide/quick-start/)中的示例。 ## 參考 - [Configuration Best Practices](https://kubernetes.io/docs/concepts/configuration/overview/)