命名空間導覽

Kubernetes 命名空間 有助於不同的專案、團隊或客戶共用一個 Kubernetes 叢集。

它透過提供以下功能來實現這一點

1. 名稱的範圍。
2. 將授權與策略附加到叢集子區段的機制。

多個命名空間的使用是選用的。

此範例示範如何使用 Kubernetes 命名空間來細分您的叢集。

開始之前

您需要有一個 Kubernetes 叢集，並且必須設定 kubectl 命令列工具以與您的叢集通訊。建議在至少有兩個節點且這些節點未充當控制平面主機的叢集上執行本教學課程。如果您還沒有叢集，可以使用 minikube 建立一個，或者您可以使用以下 Kubernetes playground 之一

• Killercoda
• Play with Kubernetes

先決條件

本範例假設以下條件

1. 您有一個現有的 Kubernetes 叢集。
2. 您對 Kubernetes Pods、服務和部署有基本的了解。

了解預設命名空間

預設情況下，Kubernetes 叢集會在佈建叢集時實例化一個預設命名空間，以保存叢集使用的預設 Pods、服務和部署集。

假設您有一個全新的叢集，您可以透過執行以下操作來檢查可用的命名空間

kubectl get namespaces

NAME      STATUS    AGE
default   Active    13m

建立新的命名空間

在本練習中，我們將建立兩個額外的 Kubernetes 命名空間來保存我們的內容。

讓我們想像一個情境，其中一個組織正在使用共用的 Kubernetes 叢集進行開發和生產用例。

開發團隊希望在叢集中維護一個空間，他們可以在其中查看用於建置和執行其應用程式的 Pods、服務和部署清單。在這個空間中，Kubernetes 資源來來去去，並且放寬了對誰可以或不能修改資源的限制，以實現敏捷開發。

營運團隊希望在叢集中維護一個空間，他們可以在其中對誰可以或不能操作執行生產站點的 Pods、服務和部署集強制執行嚴格的程序。

這個組織可以遵循的一種模式是將 Kubernetes 叢集劃分為兩個命名空間：development 和 production。

讓我們建立兩個新的命名空間來保存我們的工作。

使用檔案 namespace-dev.yaml，其中描述了 development 命名空間

admin/namespace-dev.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development

使用 kubectl 建立 development 命名空間。

kubectl create -f https://k8s.io/examples/admin/namespace-dev.yaml

將以下內容儲存到檔案 namespace-prod.yaml，此檔案描述了 production 命名空間

admin/namespace-prod.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: production

接著，讓我們使用 kubectl 建立 production 命名空間。

kubectl create -f https://k8s.io/examples/admin/namespace-prod.yaml

為了確保一切正確，讓我們列出叢集中的所有命名空間。

kubectl get namespaces --show-labels

NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

在每個命名空間中建立 Pod

Kubernetes 命名空間為叢集中的 Pod、服務和部署提供範圍。

與一個命名空間互動的使用者看不到另一個命名空間中的內容。

為了示範這一點，讓我們在 development 命名空間中啟動一個簡單的 Deployment 和 Pod。

我們先檢查目前的 context 是什麼

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

kubectl config current-context

lithe-cocoa-92103_kubernetes

下一步是為 kubectl client 定義一個 context，使其在每個命名空間中工作。 "cluster" 和 "user" 欄位的值從目前的 context 複製。

kubectl config set-context dev --namespace=development \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

kubectl config set-context prod --namespace=production \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

預設情況下，上述命令會新增兩個 context，並儲存到 .kube/config 檔案中。您現在可以檢視這些 context，並根據您希望在哪個命名空間中工作，在兩個新的請求 context 之間切換。

檢視新的 context

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: development
    user: lithe-cocoa-92103_kubernetes
  name: dev
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: production
    user: lithe-cocoa-92103_kubernetes
  name: prod
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

讓我們切換到 development 命名空間中操作。

kubectl config use-context dev

您可以透過執行以下操作來驗證目前的 context

kubectl config current-context

dev

此時，我們從命令列向 Kubernetes 叢集發出的所有請求都限定在 development 命名空間的範圍內。

讓我們建立一些內容。

admin/snowflake-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: snowflake
  name: snowflake
spec:
  replicas: 2
  selector:
    matchLabels:
      app: snowflake
  template:
    metadata:
      labels:
        app: snowflake
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname
        imagePullPolicy: Always
        name: snowflake

套用 manifest 以建立 Deployment

kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml

我們建立了一個部署，其副本大小為 2，它正在執行名為 snowflake 的 pod，其中包含一個提供主機名稱的基本容器。

kubectl get deployment

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
snowflake    2/2     2            2           2m

kubectl get pods -l app=snowflake

NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

這很棒，開發人員可以做他們想做的事情，而且他們不必擔心影響 production 命名空間中的內容。

讓我們切換到 production 命名空間，並展示一個命名空間中的資源如何對另一個命名空間隱藏。

kubectl config use-context prod

production 命名空間應該是空的，以下命令應該不會傳回任何內容。

kubectl get deployment
kubectl get pods

Production 喜歡執行 cattle，所以讓我們建立一些 cattle pod。

kubectl create deployment cattle --image=registry.k8s.io/serve_hostname --replicas=5

kubectl get deployment

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
cattle       5/5     5            5           10s

kubectl get pods -l app=cattle

NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

此時，應該很清楚使用者在一個命名空間中建立的資源對另一個命名空間是隱藏的。

隨著 Kubernetes 中 policy 支援的發展，我們將擴展此情境，以展示如何為每個命名空間提供不同的授權規則。