K8S - 命名空間實戰 - 從資源隔離到多環境管理

引言

在傳統的物理機或虛擬機環境中，不同業務應用共享資源，容易導致權限沖突、資源爭用和管理混亂。Kubernetes 通過命名空間（Namespace）實現資源邏輯隔離，將集群劃分為多個虛擬子集群，從而解決以下問題：

? 資源組織：按業務、團隊或環境分類管理

? 權限控制：限制用戶/服務賬號的操作范圍

? 資源限制：分配 CPU/內存配額，防止資源搶占

? 環境隔離：支持開發、測試、生產環境獨立部署

一、核心原理

1.1 命名空間的本質

命名空間是一種邏輯隔離機制，使得集群中的資源獨立管理，但仍共享底層物理資源。

? 資源獨立：同名資源（如 Deployment、Service）可在不同命名空間共存。

? 默認網絡互通：跨命名空間訪問需指定完整域名。

1.2 命名空間分類

系統級命名空間示例：

類型	說明
系統級命令空間	由Kubernetes自動創建，存放核心組件
用戶自定義命名空間	由用戶創建，用于業務應用部署

? default：默認命名空間（未指定時資源部署至此）

? kube-system：存放集群核心組件（如 kube-proxy、CoreDNS）

? kube-public：可供所有用戶讀取（含未認證用戶）

? kube-node-lease：管理節點心跳信息

注意：業務應用請勿部署到系統命名空間，避免影響集群穩定性！

二、實戰：命名空間創建與應用部署

首先確保你已經完成如下環境準備。

2.1 環境搭建

1.安裝必要工具

確保已安裝并配置好以下環境：

? Kubernetes 集群（可使用 Minikube 或 Kind 進行本地測試）
? kubectl命令行工具
? Docker（用于構建鏡像）
如果還沒有環境，可使用如下命令安裝。

# 安裝 Docker 并驗證
brew install docker
docker --version          # 預期輸出：Docker version 20.10.x
docker run hello-world    # 驗證基礎功能
# 安裝 kubectl 并驗證
brew install kubectl
kubectl version --client  # 預期輸出：Client Version: v1.28.x
# 安裝 kind 并驗證
brew install kind
kind version              # 預期輸出：kind v0.20.x

2.創建本地 Kubernetes 集群

kind create cluster --name k8s-demo
kubectl cluster-info  # 確認集群正常運

到此k8s 集群環境已經準備完畢。

2.2 創建與刪除命名空間

空間命名規范：符合 DNS-1123 標準，
? 僅包含小寫字母、數字和 -
? 以字母開頭和結尾

方法 1：命令行創建命名空間

通過 kubectl命令行工具直接創建命名空間，適合快速操作。

# 創建命名空間
kubectl create namespace dev# 刪除命名空間（謹慎操作）
kubectl delete namespace dev
刪除命名空間是 異步過程，狀態從 Active → Terminating，其下所有資源將被清理。在同一命名空間，不能重復創建相同的命名空間。示例# 第一次創建（成功）
kubectl create namespace dev
# Output: namespace/dev created# 第二次重復創建（失敗）
kubectl create namespace dev
# Output: Error from server (AlreadyExists): namespaces "dev" already exists

方法 2：YAML文件創建命名空間

通過 YAML 文件創建命名空間，適合版本控制和自動化管理。

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:name: testing
# 將 namespace空間設置應用到集群
kubectl apply -f namespace.yaml
# 第一次應用（成功）
kubectl apply -f namespace.yaml
# Output: namespace/dev created
# 第二次重復應用（無變化）
kubectl apply -f namespace.yaml
# Output: namespace/dev unchanged

特點

冪等性：如果命名空間已存在，不會報錯，而是維持現狀。
版本控制：YAML 文件可提交至 Git，便于團隊協作和變更審計。
擴展性：支持添加標簽（labels）和注解（annotations），例如：

apiVersion: v1
kind: Namespace
metadata:name: devlabels:env: development  # 資源環境標簽annotations:owner: team-a     # 資源歸屬注解

也可通過命令為命名空間添加標簽：

為命名空間添加標簽

kubectl label ns dev env=development
# 按標簽過濾資源
kubectl get pods -n dev -l env=development

方式3：通過 Kubernetes API 編程創建

示例（Python + Kubernetes API）

from kubernetes import client, config# 加載 kubeconfig 配置
config.load_kube_config()# 創建 API 客戶端
v1 = client.CoreV1Api()# 定義命名空間對象
namespace_name = "dev"
namespace = client.V1Namespace(metadata=client.V1ObjectMeta(name=namespace_name))# 創建命名空間，異常處理
try:v1.create_namespace(body=namespace)print(f"Namespace '{namespace_name}' created successfully")
except client.exceptions.ApiException as e:if e.status == 409:print(f"Namespace '{namespace_name}' already exists.")else:print(f"Failed to create namespace '{namespace_name}': {e}")

適用場景

適用于 CI/CD，在部署流程中動態管理命名空間。

自動化集成，便于與 Python、Go、Java 編寫的 Kubernetes 管理工具結合。

對比三種創建方式
在這里插入圖片描述

2.3 在命名空間中部署應用

1.部署應用

方式 1：在 Manifest 文件中指定命名空間（可使用第4講 2.3 中示例）

# k8s/deployment.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: gitops-demo-appnamespace: dev  # 指定命名空間spec:replicas: 2selector:matchLabels:app: gitops-demo-apptemplate:metadata:labels:app: gitops-demo-appspec:containers:- name: appimage: your-dockerhub-username/gitops-demo-app:v1  # 替換為你的鏡像ports:- containerPort: 5000

# 檢查命名空間是否存在，不存在則創建
kubectl get ns dev || kubectl create ns dev
把 deployment 應用到集群kubectl apply -f deployment.yaml

方式 2：命令行指定命名空間（推薦）

kubectl apply -f deployment.yaml -n dev

2.查看命名空間資源

查看上面示例輸出：

#查看 dev 命名空間下的 deployment 
kubectl get deployment -n devNAME              READY   UP-TO-DATE   AVAILABLE   AGE
gitops-demo-app   2/2     2            2           17h# 查看dev命名空間下的所有資源 （Pod/Service等）
kubectl get all -n devNAME                                  READY   STATUS    RESTARTS   AGE
pod/gitops-demo-app-5d7b98d8d-2j6qk   1/1     Running   0          17h
pod/gitops-demo-app-5d7b98d8d-8k9xv   1/1     Running   0          17hNAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gitops-demo-app   2/2     2            2           17hNAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/gitops-demo-app-5d7b98d8d   2         2         2       17h

注：UP-TO-DATE 表示已更新的 Pod 數。

三、實戰：跨命名空間通信

3.1 基礎知識

Kubernetes 默認允許跨命名空間訪問，但需要使用完整的 DNS 名稱：

<服務名>.<命名空間>.svc.cluster.local
? 服務名：Service 資源的名稱（如 backend-service）。

? 命名空間：Service 所在的命名空間（如 dev）。

? svc.cluster.local：集群默認的 DNS 后綴（可配置）。

在同一命名空間中訪問服務時，使用服務名即可：

? 同一命名空間：backend-service:80

在跨命名空間訪問時，必須使用完整的 DNS 名稱：

? 跨命名空間：backend-service.dev.svc.cluster.local:80

3.2 實戰示例 - 跨命名空間訪問

步驟 1：在 dev 命名空間創建 Service

通過 kubectl expose命令暴露 Deployment 為 Service（ClusterIP 類型）：

kubectl expose deployment gitops-demo-app -n dev --port=80 --target-port=5000

參數說明：

? -n dev：指定命名空間為 dev。

? --port=80：Service 對外暴露的端口。

? --target-port=5000：容器內應用實際監聽的端口（需與 Deployment 中定義的 containerPort一致）。

kubectl expose默認會直接創建 Service 并將其應用到集群中。等效的 Service YAML 配置（命令生成的 Service）為：

apiVersion: v1
kind: Service
metadata:name: gitops-demo-appnamespace: dev
spec:selector:app: gitops-demo-appports:- protocol: TCPport: 80targetPort: 5000type: ClusterIP

驗證 Service

執行以下命令驗證 Service 是否創建成功：

kubectl get svc -n dev
預期輸出：NAME               TYPE        CLUSTER-IP      PORT(S)   AGE
gitops-demo-app    ClusterIP   10.96.123.456   80/TCP    5s

步驟 2：從 prod 命名空間發起跨命名空間訪問

啟動一個臨時 Pod 測試跨命名空間訪問：

kubectl run curl-test -n prod \--image=curlimages/curl \--rm -it -- \curl http://gitops-demo-app.dev.svc.cluster.local

參數說明：

? -n prod：在 prod命名空間中運行 Pod。

? --rm -it：容器退出后自動刪除此臨時容器，并分配交互式終端。

? curl ：測試訪問目標 Service。

預期結果：

? 成功：返回 gitops-demo-app服務的響應內容（例如：GitOps Demo v1，具體內容可見 Deployment 文件）。

? 失敗的可能原因：

1.目標 Service未正確暴露端口。

2.NetworkPolicy限制了跨命名空間訪問。

四、實戰：資源配額限制

創建命名空間時增加資源限制，可以通過創建一個 LimitRange對象來限制該命名空間中的資源。LimitRange是 Kubernetes 中用于定義資源限制的策略，可以限制容器的 CPU 和內存等資源。

將 LimitRange和 Namespace一起創建，確保命名空間創建后自動應用這些資源限制。

1.創建 namespace.yaml 和 limitrange.yaml

# namespace.yamlapiVersion: v1
kind: Namespace
metadata:name: testing---# limitrange.yamlapiVersion: v1
kind: LimitRange
metadata:name: default-limitnamespace: testing
spec:limits:- max: cpu: "2"memory: "4Gi"min:cpu: "200m"memory: "512Mi"default:cpu: "1"memory: "1Gi"defaultRequest:cpu: "500m"memory: "1Gi"type: Container

解析：

LimitRange資源限制了testing 命名空間中容器的資源使用：

1.max - 限制容器的最大CPU 和內存使用量，防止某個容器占用過多資源。

? CPU 最大 2 核（2），即容器最多只能申請 2 核 CPU。

? 內存最大 4Gi（4Gi），即容器最多只能申請 4GB 內存。

2.min（最小值）- 規定容器的最小資源申請量，避免某些 Pod 資源太少而影響運行。

? 最小 CPU 為 200毫核（200m），內存為 512Mi。

3.default（默認值）-如果 Pod 沒有明確指定資源限制，那么 Kubernetes 自動分配的資源值。

? 默認 CPU 為 1 核，內存為 1Gi。

4.defaultRequest（默認請求）- 如果 Pod 沒有指定請求資源，Kubernetes 自動分配的最小起始值。

? 默認請求 CPU 為 500m，內存為 1Gi。

2.應用到集群中

kubectl apply -f namespace.yaml
kubectl apply -f limitrange.yaml

兩個 YAML 文件都在同一個目錄下，也可以一次性應用：

kubectl apply -f .

這樣，testing命名空間會被創建，同時應用了資源限制策略。

五、使用場景與最佳實踐

5.1 何時使用命名空間？
在這里插入圖片描述

5.2 命名空間規劃建議

小型團隊：

? 按環境劃分：dev、testing、prod

? 按業務劃分：web、database

大型組織：

? 獨立集群 + 命名空間：每個團隊獨立集群，內部再劃分命名空間。

六、總結

6.1 核心重點

? 核心價值：命名空間通過邏輯隔離實現資源組織、權限控制和環境管理，是 Kubernetes 多租戶能力的關鍵。

? 軟隔離 vs 硬隔離：

? 軟隔離：命名空間（同一集群內邏輯隔離）

? 硬隔離：獨立集群（物理隔離）

最佳實踐：

? 避免修改系統命名空間，業務應用請用自定義命名空間

? 使用 -n 參數指定部署環境，避免誤操作

附：操作速查表

# 查看所有命名空間
kubectl get ns
# 快速切換默認命名空間（避免頻繁輸入 -n）
kubectl config set-context --current --namespace=dev
# 設置命名空間資源配額（需提前定義 ResourceQuota）
kubectl apply -f quota.yaml -n dev