名稱空間演練

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

它透過提供以下功能實現此目的:

  1. 名稱的範圍。
  2. 將授權和策略附加到叢集子部分的機制。

使用多個名稱空間是可選的。

本示例演示瞭如何使用 Kubernetes 名稱空間來細分您的叢集。

準備工作

您需要有一個 Kubernetes 叢集,並且 kubectl 命令列工具必須配置為與您的叢集通訊。建議在至少有兩個不是控制平面主機節點的叢集上執行本教程。如果您還沒有叢集,可以使用 minikube 建立一個,或者使用以下 Kubernetes 演練場之一。

要檢查版本,請輸入 kubectl version

先決條件

本示例假設以下情況:

  1. 您有一個現有 Kubernetes 叢集
  2. 您對 Kubernetes Pod服務部署有基本的瞭解。

瞭解預設名稱空間

預設情況下,Kubernetes 叢集在配置叢集時會例項化一個預設名稱空間,用於存放叢集使用的預設 Pod、服務和部署集。

假設您有一個全新的叢集,您可以透過以下方式檢查可用的名稱空間:

kubectl get namespaces
NAME      STATUS    AGE
default   Active    13m

建立新名稱空間

對於本練習,我們將建立兩個額外的 Kubernetes 名稱空間來存放我們的內容。

讓我們想象一個場景:一個組織正在使用一個共享的 Kubernetes 叢集進行開發和生產用例。

開發團隊希望在叢集中維護一個空間,以便他們可以檢視用於構建和執行應用程式的 Pod、服務和部署列表。在這個空間中,Kubernetes 資源來去自由,並且對誰可以或不能修改資源的限制也比較寬鬆,以支援敏捷開發。

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

這個組織可以遵循的一種模式是將 Kubernetes 叢集劃分為兩個名稱空間:developmentproduction

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

使用檔案namespace-dev.yaml,它描述了一個 development 名稱空間

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 名稱空間

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 名稱空間中啟動一個簡單的部署和 Pod。

我們首先檢查當前的上下文

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 客戶端在每個名稱空間中工作定義一個上下文。“cluster”和“user”欄位的值是從當前上下文複製的。

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

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

要檢視新上下文

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

您可以透過以下方式驗證當前的上下文:

kubectl config current-context
dev

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

讓我們建立一些內容。

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

應用清單以建立部署

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

生產環境喜歡執行 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 中策略支援的發展,我們將擴充套件此場景,以展示如何為每個名稱空間提供不同的授權規則。

上次修改時間為 2024 年 10 月 19 日太平洋標準時間下午 5:08:將“名稱空間演練”移動到教程部分 (af9c4c83f4)