本文檔旨在彙總和強調用戶指南、快速開始文檔和示例中的最佳實踐。本文已上傳到 kubernetes-handbook 中的第四章最佳實踐章節，本文僅作歸檔，更新以 kubernetes-handbook 爲準。
通用配置建議
-
定義配置文件的時候，指定最新的穩定API版本（目前是V1）。
-
在配置文件push到集羣之前應該保存在版本控制系統中。這樣當需要的時候能夠快速回滾，必要的時候也可以快速的創建集羣。
-
使用YAML格式而不是JSON格式的配置文件。在大多數場景下它們都可以作爲數據交換格式，但是YAML格式比起JSON更易讀和配置。
-
儘量將相關的對象放在同一個配置文件裏。這樣比分成多個文件更容易管理。參考 guestbook-all-in-one.yaml 文件中的配置（注意，儘管你可以在使用 kubectl 命令時指定配置文件目錄，你也可以在配置文件目錄下執行 kubectl create ——查看下面的詳細信息）。
-
爲了簡化和最小化配置，也爲了防止錯誤發生，不要指定不必要的默認配置。例如，省略掉 ReplicationController 的selector和label，如果你希望它們跟 podTemplate 中的label一樣的話，因爲那些配置默認是 podTemplate 的label產生的。更多信息請查看 guestbook app 的yaml文件和 examples 。
-
將資源對象的描述放在一個annotation中可以更好的內省。
裸奔的Pods vs Replication Controllers和 Jobs
如果有其他方式替代“裸奔的pod”（如沒有綁定到 replication controller 上的pod），那麼就使用其他選擇。在node節點出現故障時，裸奔的pod不會被重新調度。Replication Controller總是會重新創建pod，除了明確指定了 restartPolicy: Never 的場景。 Job 也許是比較合適的選擇。
Services
-
通常最好在創建相關的 replication controllers 之前先創建 service （沒有這個必要吧？）你也可以在創建Replication Controller的時候不指定replica數量（默認是1），創建service後，在通過Replication Controller來擴容。這樣可以在擴容很多個replica之前先確認pod是正常的。
-
除非時分必要的情況下（如運行一個node daemon），不要使用 hostPort （用來指定暴露在主機上的端口號）。當你給Pod綁定了一個 hostPort ，該pod可被調度到的主機的受限了，因爲端口衝突。如果是爲了調試目的來通過端口訪問的話，你可以使用 kubectl proxy and apiserver proxy 或者 kubectl port-forward 。你可使用Service 來對外暴露服務。如果你確實需要將pod的端口暴露到主機上，考慮使用 NodePort service。
-
跟 hostPort 一樣的原因，避免使用 hostNetwork 。
-
如果你不需要kube-proxy的負載均衡的話，可以考慮使用使用 headless services 。
使用Label
-
定義 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”的所有“測試”階段組件。 有關此方法的示例，請參閱 guestbook 應用程序。
可以通過簡單地從其service的選擇器中省略特定於發行版本的標籤，而不是更新服務的選擇器來完全匹配replication controller的選擇器，來實現跨越多個部署的服務，例如滾動更新。
-
爲了滾動升級的方便，在Replication Controller的名字中包含版本信息，例如作爲名字的後綴。設置一個 version 標籤頁是很有用的。滾動更新創建一個新的controller而不是修改現有的controller。因此，version含混不清的controller名字就可能帶來問題。查看 Rolling Update Replication Controller 文檔獲取更多關於滾動升級命令的信息。
注意 Deployment 對象不需要再管理 replication controller 的版本名。Deployment 中描述了對象的期望狀態，如果對spec的更改被應用了話，Deployment controller 會以控制的速率來更改實際狀態到期望狀態。（Deployment目前是 extensions API Group 的一部分）。
-
利用label做調試。因爲Kubernetes replication controller和service使用label來匹配pods，這允許你通過移除pod中的label的方式將其從一個controller或者service中移除，原來的controller會創建一個新的pod來取代移除的pod。這是一個很有用的方式，幫你在一個隔離的環境中調試之前的“活着的” pod。查看 kubectl label 命令。
容器鏡像
-
默認容器鏡像拉取策略 是 IfNotPresent , 當本地已存在該鏡像的時候 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 和 using labels effectively 。
使用 kubectl run 和 expose 命令快速創建直有耽擱容器的Deployment。查看 quick start guide 中的示例。
本文轉移K8S技術社區-新手篇 | K8S配置最佳實踐