隨著您開始創建越來越多的 Kubernetes 服務，最初簡單的任務開始變得更加複雜。 例如，開發團隊不能以相同的名稱建立服務或部署。 如果您有數千個 Pod，只是列出它們將花費大量時間，更不用說正確管理它們了。 這只是冰山一角。
讓我們看看命名空間如何讓管理 Kubernetes 資源變得更容易。 那什麼是命名空間呢？ 命名空間可以被視為 Kubernetes 叢集中的虛擬叢集。 您可以在單一 Kubernetes 叢集中擁有多個彼此隔離的命名空間。 他們可以真正幫助您和您的團隊在組織、安全甚至系統效能方面提供協助。
在大多數 Kubernetes 發行版上，叢集開箱即用，帶有一個名為「default」的命名空間。 Kubernetes 實際上處理三個命名空間：default、kube-system 和 kube-public。 目前，Kube-public 的使用頻率並不高。
單獨保留 kube 命名空間是一個好主意，尤其是在 Google Kubernetes Engine 這樣的託管系統上。 它使用“預設”命名空間作為創建服務和應用程式的位置。 它絕對沒有什麼特別之處，除了 Kubernetes 是開箱即用配置的，而且您無法刪除它。 這對於入門和低性能係統來說非常有用，但我不建議在大型產品系統上使用預設名稱空間。 在後一種情況下，一個開發團隊可以輕鬆重寫其他人的程式碼，並在沒有意識到的情況下破壞另一個團隊的工作。
因此，您應該建立多個命名空間並使用它們將您的服務劃分為可管理的單元。 可以使用單一指令建立命名空間。 如果要建立名為 test 的命名空間，請使用命令 $ kubectl create namespace test 或簡單地建立 YAML 檔案並像任何其他 Kubernetes 資源一樣使用它。
您可以使用 $ kubectl get namespace 指令查看所有命名空間。
完成後，您將看到三個內建命名空間和一個名為「test」的新命名空間。 讓我們來看看用於建立 pod 的簡單 YAML 檔案。 您會注意到沒有提及名稱空間。
如果您使用 kubectl 執行此文件，它將在目前活動的命名空間中建立 mypod 模組。 這將是預設命名空間，直到您更改它為止。 有兩種方法可以告訴 Kubernetes 您要在哪個命名空間中建立資源。 第一種方法是在建立資源時使用命名空間標誌。
第二種方法是在 YAML 聲明中指定名稱空間。
如果您在 YAML 中指定命名空間，則資源將始終在該命名空間中建立。 如果您在使用命名空間標誌時嘗試使用不同的命名空間，則該命令將會失敗。 現在，如果您嘗試找到您的 Pod，您將無法找到。
發生這種情況是因為所有命令都在目前活動的命名空間之外執行。 要找到您的 pod，您需要使用命名空間標誌，但這很快就會變得無聊，特別是如果您是使用自己的命名空間的團隊中的開發人員，並且不想為每個命令使用該標誌。 讓我們看看如何解決這個問題。
開箱即用，您的活動名稱空間稱為預設名稱空間。 如果您未在資源 YAML 中指定命名空間，則所有 Kubernetes 指令都將使用此活動的預設命名空間。 不幸的是，嘗試使用 kubectl 管理活動命名空間可能會失敗。 然而，有一個非常好的工具叫 Kubens，可以讓這個過程變得更容易。 執行 kubens 命令時，您會看到所有命名空間，其中活動命名空間突出顯示。
要將活動命名空間切換到測試命名空間，只需執行 $kubens test 命令即可。 如果您再次執行 $kubens 命令，您將看到現在分配了一個新的活動命名空間 - test。
這表示您不需要命名空間標誌即可查看測試命名空間中的 pod。
這樣，命名空間彼此隱藏，但彼此不隔離。 一個命名空間中的服務可以很容易地與另一個命名空間中的服務進行通信，這通常非常有用。 跨不同命名空間進行通訊的能力意味著您的開發人員的服務可以與不同命名空間中的另一個開發團隊的服務進行通訊。
通常，當您的應用程式想要存取 Kubernetes 服務時，您可以使用內建的 DNS 發現服務，並只需為您的應用程式提供該服務的名稱即可。 但是，這樣做可能會在多個命名空間中建立同名的服務，這是不可接受的。
幸運的是，透過使用 DNS 位址的擴展形式可以輕鬆解決這個問題。 Kubernetes 中的服務使用通用 DNS 範本公開其端點。 它看起來像這樣：
通常，您只需要服務名稱，DNS 將自動確定完整地址。
但是，如果您需要存取不同命名空間中的服務，只需使用服務名稱加上命名空間名稱：
例如，如果要連接test命名空間中的服務資料庫，可以使用地址資料庫database.test
如果要連線到 prod 命名空間中的服務資料庫，請使用database.prod。
如果您確實想隔離和限制命名空間訪問，Kubernetes 允許您使用 Kubernetes 網路策略來實現此目的。 我將在下一集中談論這個。
我經常被問到這樣的問題：我應該創造多少個命名空間以及出於什麼目的？ 什麼是託管資料？
如果您創建太多名稱空間，它們只會妨礙您。 如果它們太少，您將失去這種解決方案的所有好處。 我認為每個公司在創建組織結構時都會經歷四個主要階段。 根據您的專案或公司所處的開發階段，您可能需要採用適當的命名空間策略。
想像一下，您是正在開發 5-10 個微服務的小團隊的一員，您可以輕鬆地將所有開發人員聚集在一個房間裡。 在這種情況下，在預設命名空間中運行所有產品服務是有意義的。 當然，為了獲得更大的靈活性，您可以使用 2 個命名空間 - 分別用於 prod 和 dev。 最有可能的是，您使用 Minikube 等工具在本機上測試您的開發。
假設情況發生了變化，您現在擁有一個快速成長的團隊，同時處理 10 多個微服務。 有時需要為生產和開發分別使用多個集群或命名空間。 您可以將團隊分成幾個子團隊，以便每個子團隊都有自己的微服務，並且每個團隊都可以選擇自己的命名空間以促進管理軟體開發和發布的過程。
隨著每個團隊成員深入了解整個系統的工作原理，與所有其他開發人員協調每項變更變得越來越困難。 嘗試在本機電腦上啟動完整的堆疊每天都變得越來越困難。
在大公司中，開發人員通常不知道誰到底在做什麼。 團隊使用服務合約或服務網格技術進行通信，這在網路上添加了一個抽象層，例如 Istio 配置工具。 嘗試在本地運行整個堆疊是根本不可能的。我強烈建議使用持續交付 (CD) 平台，例如 Kubernetes 上的 Spinnaker。 因此，到了某個時刻，每個指令肯定都需要自己的命名空間。 每個團隊甚至可以為開發環境和生產環境選擇多個命名空間。
最後，還有一些大型新創公司，其中一組開發人員甚至不知道其他組的存在。 這樣的公司通常會聘請第三方開發人員，透過記錄完善的 API 與之互動。 每個這樣的組別都包含多個團隊和多個微服務。 在這種情況下，您需要使用我之前談到的所有工具。
程式設計師不應該手動部署服務，也不應該存取與他們無關的命名空間。 在此階段，建議擁有多個集群，以減少配置不當的應用程式的“爆炸半徑”，以簡化計費流程和資源管理。
因此，組織正確使用命名空間可以使 Kubernetes 更加可管理、可控、安全和靈活。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com