Kubernetes的十大使用技巧

1. bash針對kubectl命令的自動補充
這多是在使用Kubernetes過程當中最容易作的事，但它也是其中一個最有用的。要添加自動補充功能，若是使用bash，只需執行如下命令：

echo "source <(kubectl completion bash)" >> ~/.bashrc

它將添加自動補全命令到你的.bashrc文件。所以每一個你打開的shell窗口都支持該功能。我發現自動補全對一些長的參數，好比--all-namespaces特別有用。
2. 給每一個namespace添加默認的內存和CPU限額
是人就會犯錯。咱們假定某人寫了個應用，他每秒就會打開一個數據庫鏈接，可是不會關閉。這樣集羣中就有了一個內存泄漏的應用。假定咱們把該應用部署到了沒有限額設置的集羣，那麼該應用就會crash掉一個節點。
爲了不這種狀況，Kubernetes容許爲每一個namespace設置默認的限額。要作到這很簡單，咱們只需建立一個limit range 的 yaml 並應用到特定namespace。如下是一個例子：

apiVersion: v1  
 kind: LimitRange  
 metadata:  
   name: mem-limit-range  
 spec:  
   limits:  
   - default:  
       memory: 512Mi  
     defaultRequest:  
       memory: 256Mi  
     type: Container

將該內容建立一個yaml文件並將它應用到任何你想應用的namespace，例如namespace limit-example。使用了限額後，任何部署到該namespace的應用，假如沒有主動設置限額，都將獲得一個默認的512Mi的內存限額。
3. kebelet能夠幫我清理掉Docker鏡像嗎
這是kubelet默認已實現的功能。若是kubelet啓動時沒有設置flag，當/var/lib/docker目錄到達90%的容量時，它就會自動進行垃圾回收。這是極好的，可是針對inode閾值它沒有默認設置（Kubernetes 1.7以前）。
你可能會遇到/var/lib/docker只使用了50%磁盤空間，可是inode所有用光的狀況。這可能會引發工做節點各類各樣的問題。若是你運行的kubelet版本在1.4到1.6之間，那你得給kubelet添加如下flag：

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

若是kubelet版本是1.7或更高，它默認就有這個配置。1.6默認不會監控inode的使用率，因此得添加那個flag來解決這個問題。
4. minikube雖然是mini，可是本地使用功能強大
minikube絕對是本地啓動Kubernetes集羣最容易的方式。你只需遵循這個[1]指南去下載全部東西。
一旦全部組件安裝完畢，你只需運行以下命令：

minikube start

待命令執行完畢，你本地就有一個運行的Kubernetes集羣了。
當你想在本地構建一個應用並在本地運行時，有一個技巧。當你在本地構建一個Docker鏡像時，若是不運行其它命令，你的鏡像將被構建在你的本地計算機。
爲了使你構建的Docker鏡像可以直接push到本地Kubernetes集羣，你須要使用以下命令告知Docker機器：

eval $(minikube docker-env)

這將使你能直接推送本地構建的應用到你的本地集羣。
5. 不要將kubectl的權限開放給全部人
這多是一個明擺着的事，可是當多個團隊部署應用到同一個集羣時，而這種場景就是Kubernetes的目標，不要開放一個通用的kubectl給每一個人。個人建議是基於namespace來隔離團隊，而後使用RBAC策略來限制能且僅能訪問那個namespace。
在權限被控制以後，你可能會變得瘋狂，好比只能基於Pod來讀取，建立和刪除Pod。可是其中一個最須要作的事是隻能訪問管理員憑證，這樣能夠隔離誰能管理集羣，而誰只能在集羣上部署應用。
這個話題我期待着後續單獨開一篇博客來進行更詳細的分析。
6. Pod中斷預算（Pod Disruption Budgets）是你的朋友
在Kubernetes集羣中咱們如何確保應用零宕機？
PodDisruptionBudgetPodDisruptionBudgetPodDisruptionBudget
集羣會更新。節點會打上drain標籤且Pod會被移除，這無法避免。因此咱們應該針對每一個deployment都設置一個PDB，保證至少有一個實例。咱們可使用一個簡單的yaml來建立一個PDB，應用到集羣裏，並使用標籤選擇器來肯定這個PDB覆蓋了哪些資源。
注意：PDB只對自願中斷的資源負責，某些如硬件失敗這種錯誤，PDB沒法起做用。
PDB例子以下：

apiVersion: policy/v1beta1  
 kind: PodDisruptionBudget  
 metadata:  
   name: app-a-pdb  
 spec:  
   minAvailable: 2  
   selector:  
       matchLabels:  
         app: app-a

兩個最須要關注的字段是matchLabels和minAvailable。
matchLabels字段用來肯定是否一個deployment能夠關聯到這個PDB。
例如，若是我有一個帶標籤app:app-a的deployment，和另外一個帶標籤app:app-b的deployment，例子中的PDB將只對第一個deployment起做用。
minAvailable字段是Kubernetes在某些場景下，好比node被打上drain標籤時，進行操做的依據。假設app-a運行在node1上，若是node1被打上了drain標籤，那麼kubernetes只會清除那些有至少2個實例的app-a。
這容許你在任什麼時候候均可控制運行的實例數。
7. 你的APP還活着且可用嗎
Kubernetes容許咱們定義探針，供kubelet確認咱們的Pod和APP是不是健康的。
Kubernetes提供了兩種類型的探針，Readiness探針和Liveness探針。
Readiness探針用來確認容器是否可接受流量。
Liveness探針用來確認容器是不是健康的，或者須要被重啓。
這些配置能夠很容易得追加到deployment的yaml，而且能夠自定義超時時間，重試次數，延時時間等。須要更進一步得了解如何使用它們的，請閱讀此文[2]。
8. 給全部事物都打上標籤
標籤是Kubernetes的其中一個基石。它使得對象和對象之間保持鬆耦合，且容許咱們根據標籤來查詢對象。你甚至可使用go client根據標籤來監控事件。
你幾乎能夠用標籤作任何事，其中一個極佳的例子是同一集羣中的多個環境。
咱們假定你在dev和qa環境使用了相同的集羣。這說明你將在dev和qa環境同時運行一個app-a應用。
爲了達到這個目的，最簡單的方式是使用service對象，其中一個選擇帶標籤app:app-a和environment:dev的Pod，而另外一個，則選擇帶標籤app:app-a和environment:qa的Pod。
這樣作的好處是，兩個相同的APP，每個有不一樣的endpoint，這樣就支持同時測試。
9. 主動清理
Kubernetes是一個很是很是強大的系統，可是和其它系統同樣，它最終也會陷入混亂。kubelet必須進行任何你告訴它的校驗，同時它也進行本身的校驗。
固然，Kubernetes有一個服務沒法鏈接了，系統是不會掛掉的，由於它支持擴縮容。可是一個服務一旦擴大到成千上萬個endpoint，那麼kubelet就會一會兒陷入癱瘓。
簡單的說，不論你由於什麼理由須要刪除一個deployment（或者其它東西），你都必須確保清理乾淨和它相關的一切東西。
10. 你熱愛GO語言嗎
最後一點是我我的以爲最重要的：持續的學習GO語言。
Kubernetes是由GO編寫的，它的全部插件也是用GO寫的，他們甚至還編寫了一個GO語言的客戶端。client-go可用來作各類有趣的事。你能夠用它根據本身的愛好擴展kubernetes。好比數據收集，部署引擎，或者一個簡單的清理應用。
學習這個GO 客戶端，並在Kubernetes中使用它，這是我給每一個使用Kubernetes的用戶的最大建議。
原文連接：

1. https://kubernetes.io/docs/tasks/tools/install-minikube/

2. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

原文連接：https://hackernoon.com/top-10-kubernetes-tips-and-tricks-27528c2d0222