本文是Google Developer Advocate Sandeep Dinesh的七部分視訊和部落格系列的第二篇，介紹如何充分利用您的Kubernetes環境。
第一篇：如何構建儘可能小的容器映象？
當您開始在Kubernetes之上構建越來越多的服務時，簡單的任務開始變得更加複雜。 例如，團隊無法建立具有相同名稱的Kubernetes Service或Deployment。 如果你有成千上萬的Pod，只是列出它們都需要一些時間，更不用說實際管理它們了！當然，這些還只是冰山一角。
在本期Kubernetes最佳實踐中，讓我們來看看如何使用Kubernetes名稱空間來更輕鬆地管理您的Kubernetes資源。


什麼是名稱空間（Namespace）？

您可以將名稱空間視為Kubernetes叢集中的虛擬叢集。 您可以在單個Kubernetes叢集中擁有多個名稱空間，並且它們在邏輯上彼此隔離。 他們可以為您和您的團隊提供組織，安全甚至效能方面的幫助！
預設名稱空間（Default Namespace）

在大多數Kubernetes發行版中，叢集開箱即用，名稱空間預設為default。事實上，Kubernetes上有三個名稱空間：default、kube-system（用於Kubernetes元件）和kube-public（ 用於公共資源）。 kube-public現在並沒有真正使用過，而且通常單獨隔離一個kube-system是個好主意，尤其是在Google Kubernetes Engine這樣的託管系統中。 預設名稱空間是你建立服務和應用程式的預設位置，如果你不指定namespace引數的話。
這個名稱空間絕對沒有什麼特別之處，只是Kubernetes工具是開箱即用的設定使用這個名稱空間，而且你無法刪除它。 它很適合入門和小型生產系統，我建議不要在大型生產系統中使用它。 這是因為團隊很容易在沒有意識到的情況下，意外地覆蓋或破壞其他服務。 相反，我們應該建立多個名稱空間並使用它們來將服務劃分為可管理的塊。
建立名稱空間

不要害怕建立名稱空間。 它們不會增加效能損失，而且實際上，在許多情況下它們可以提高效能，因為這樣的話Kubernetes API使用的是較小的物件集合。
可以使用單個命令來建立名稱空間。 如果你想建立一個名為test的名稱空間，你可以執行如下命令：

kubectl create namespace test

或者您可以像建立其他任何Kubernetes資源一樣，建立一個YAML檔案並應用它。
test.yaml：

kind: Namespace
apiVersion: v1
metadata:
  name: test
  labels:
    name: test
kubectl apply -f test.yaml
 

檢視名稱空間

您可以使用以下命令檢視所有名稱空間：

kubectl get namespace

如上圖，您可以看到三個內建名稱空間，以及名為test的新名稱空間。
在名稱空間中建立資源

讓我們看一個簡單的YAML，它用來建立一個Pod：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

您可能會注意到在任何地方都沒有提到名稱空間。 如果在此檔案上執行kubectl apply，它將在當前活動的名稱空間中建立Pod。 除非您更改它，否則這將是“預設”名稱空間。
有兩種方法可以明確告訴Kubernetes您要在哪個Namespace中建立資源。
一種方法是在建立資源時設定namespace標識：

kubectl apply -f pod.yaml --namespace=test

您還可以在YAML宣告中指定名稱空間：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: test
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

如果在YAML宣告中指定名稱空間，則將始終在該名稱空間中建立資源。如果您嘗試使用namespace標誌來設定另一個名稱空間，則該命令將會失敗。
在名稱空間中檢視資源

如果你試圖找到你的Pod，你可能會注意到你不能！

$ kubectl get pods
No resources found.

這是因為所有命令都是針對當前active的名稱空間執行的。 要查詢Pod，您需要指定namespace。

$ kubectl get pods --namespace=test
NAME      READY     STATUS    RESTARTS   AGE
mypod     1/1       Running   0          10s

這可能會很快讓人覺得很煩，特別是如果您是一個開發團隊的開發人員，該團隊使用自己的名稱空間來處理所有事情，並且不希望對每個命令都指定namespace。 讓我們看看我們如何解決這個問題。
管理active名稱空間

初始狀態下，您的活動名稱空間是default。 除非在YAML中指定名稱空間，否則所有Kubernetes命令都將使用當前active名稱空間。
不幸的是，嘗試使用kubectl管理您的active名稱空間可能會很痛苦。 幸運的是，有一個非常好的工具叫做kubens（由優秀的Ahmet Alp Balkan建立）可以讓它變得輕而易舉！
執行kubens命令時，您應該看到所有名稱空間，並突出顯示active名稱空間：

要將active名稱空間切換到test名稱空間，請執行：

kubens test

現在您可以看到test名稱空間處於active狀態：

現在，如果你執行kubectl命令，名稱空間將是test而不是default！
這意味著您不需要指定名稱空間來檢視測試名稱空間中的Pod。

$ kubectl get pods
NAME      READY     STATUS    RESTARTS   AGE
mypod     1/1       Running   0          10m

跨名稱空間通訊

名稱空間彼此“隱藏”，但預設情況下它們不是完全隔離的。一個名稱空間中的服務可以與另一個名稱空間中的服務進行通訊。 這通常非常有用，例如讓您的團隊的服務（在您的名稱空間中）與另一個團隊的服務（在另一個名稱空間中）進行通訊。
當您的應用想要訪問Kubernetes Service時，您可以使用內建的DNS服務發現，只需將您的應用指向該Service的名稱即可。 但是，您可以在多個名稱空間中建立具有相同名稱的Service！值得慶幸的是，通過使用擴充套件形式的DNS地址很容易解決這個問題。
Kubernetes中的服務使用通用DNS模式公開其endpoint。 它看起來像這樣：

<Service Name>.<Namespace Name>.svc.cluster.local

通常，您只需要服務名稱，DNS將自動解析為完整地址。 但是，如果需要訪問另一個名稱空間中的服務，則需使用服務名稱加上名稱空間名稱。
例如，如果要連線到test名稱空間中的database服務，可以使用以下地址：

database.test

如果要連線到production名稱空間中的database服務，可以使用以下地址：

database.production

警告：如果您建立一個對映到“com”或“org”等TLD的名稱空間，然後建立一個與網站名稱相同的服務，例如“google”或“reddit”，Kubernetes將攔截“google.com“或”reddit.com“的請求並將其傳送到您的服務。 這通常對於測試和代理非常有用，但也可以輕鬆破壞叢集中的內容！
注意：如果確實要隔離名稱空間，則應使用網路策略（Network Policies）來完成此操作。 更多資訊請繼續關注未來劇集！
命令空間粒度

一個常見問題是要建立多少個名稱空間以及用於何種目的。 什麼是可管理的塊？ 建立太多的名稱空間，它們會讓你變得沒有效率，但是建立太少，你會錯過它們的好處。
我認為答案在於您的專案或公司處於什麼階段 ——從小團隊到成熟企業，每個階段都有自己的組織架構。 根據您的具體情況，您可以採用對應的名稱空間策略。
小團隊
在這種情況下，您是一個小團隊的一員，該團隊正在開發5-10個微服務，可以輕鬆地進行團隊溝通。 在這種情況下，將所有生產服務放到“預設”名稱空間是個不錯的選擇。 根據你的個人喜好，你可能希望有一個production和development的名稱空間，但你很有可能是在本地機器上使用類似Minikube搭建的開發環境。
快速成長的團隊
在這種情況下，您有一個快速發展的團隊，正在開發10多個微服務。 您開始將團隊分成多個子團隊，每個團隊都擁有自己的微服務。 雖然每個人都可能知道整個系統是如何工作的，但是與其他人協調每一個變化變得越來越困難。 嘗試在本地計算機上啟動整個堆疊每天都變得越來越複雜。
此時有必要使用多個叢集或名稱空間進行生產和開發。 每個團隊可以選擇擁有自己的名稱空間，以便於管理。
大公司
在一家大公司，並不是每個人都瞭解其他人。 某個團隊正致力於其他團隊可能不瞭解的功能。 團隊可能正在使用服契約（service contract）與其他微服務通訊（例如，gRPC），也有可能使用服務網格（Service Mesh）進行通訊（例如，istio）。 試圖在本地執行整個堆疊是不可能的。 強烈建議使用Kubernetes-aware Continuous Delivery系統（例如，Spinnaker）。
此時，每個團隊肯定需要自己的名稱空間。 每個團隊甚至可以選擇多個名稱空間來執行其開發和生產環境。 設定RBAC和ResourceQuotas也是一個好主意。 多個叢集開始顯得很有意義，但可能不一定是必要的。
注意：我將在後面的文章中深入研究gRPC、Istio、Spinnaker、RBAC和Resources！
企業
在這種規模下，有些群體甚至不知道其他群體的存在。 某個組也可能是外部公司，服務之間通過標準文件定義的API來通訊。 每個小組都有多個擁有一定數量微服務的團隊。 這時使用我上面提到的所有工具是必要的。 人們不應該手工部署服務，同時應該被鎖定在他們不擁有的名稱空間之外。此時，擁有多個叢集以減少配置不當的應用程式導致的爆炸半徑，以及簡化計費和資源管理可能是有意義的。
結論

名稱空間可以幫助您組織Kubernetes資源，同時可以提高團隊的開發速度。 請繼續關注未來的Kubernetes最佳實踐劇集，我將向您展示如何鎖定名稱空間中的資源併為您的群集引入更多安全性和隔離性！
原文連結：https://cloudplatform.googleblog.com/2018/04/Kubernetes-best-practices-Organizing-with-Namespaces.htmlKubernetes應用實戰培訓

Kubernetes應用實戰培訓將於2018年9月14日在上海開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選閱讀原文連結可檢視具體培訓內容。