k8s~關於非常囉嗦的標籤和選擇器

张占岭發表於2024-12-04
K8S

總感覺k8s中定義的deplyment和service非常的囉嗦，尤其是在選擇器的定義上，但沒辦法，它的設計總有它的道理。

  • svc(spec.selector.app)
    • deployment(metadata.labels.app,spec.selector.matchLabels.app)
      • pods(metadata.labels.app)

nginx的部署

下面是一個 Kubernetes YAML 檔案示例，用於部署一個 Nginx 服務。該檔案包括 Deployment 和 Service 的定義，Service 型別設定為 ClusterIP。

Nginx 部署 YAML 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1  # 設定副本數為 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:stable-alpine  # 使用最新的 Nginx 映象
        ports:
        - containerPort: 80   # 容器內部的埠
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP  # 使用 ClusterIP 型別
  selector:
    app: nginx  # 根據標籤選擇 Pod
  ports:
    - port: 80          # Service 的埠
      targetPort: 80    # 轉發到容器的埠

說明

  • Deployment：

    • apiVersion: apps/v1：指定 API 版本。
    • kind: Deployment：表示這是一個 Deployment 物件。
    • metadata：包含物件的後設資料，如名稱和標籤。
    • spec：定義 Deployment 的規格，包括副本數量、選擇器和 Pod 模板。
    • replicas：設定執行的 Pod 副本數量。
    • selector：用於選擇與 Deployment 相關的 Pods。
    • template：定義 Pod 的模板，包括後設資料和容器規格。
    • containers：定義容器的名稱、映象和要暴露的埠。

  • Service：

    • apiVersion: v1：指定 API 版本。
    • kind: Service：表示這是一個 Service 物件。
    • metadata：包含物件的後設資料，如名稱。
    • spec：定義 Service 的規格，包括型別、選擇器和埠配置。
    • type: ClusterIP：指定 Service 型別為 ClusterIP，表示只在叢集內部可訪問。
    • selector：根據標籤選擇與之關聯的 Pods。
    • ports：定義 Service 的埠和目標埠。

部署步驟

  1. 將上述 YAML 內容儲存到一個檔案中，例如 nginx-deployment.yaml。

  2. 使用以下命令在 Kubernetes 叢集中應用該配置：

    kubectl apply -f nginx-deployment.yaml

  3. 檢查 Deployment 和 Service 是否成功建立：

    kubectl get deployments
kubectl get services

透過以上步驟，你將能夠在 Kubernetes 中成功部署一個 Nginx 服務，並透過 ClusterIP 型別的 Service 來訪問它。如果你有其他問題或需要進一步的幫助，請隨時告訴我！

關於特別囉嗦的labels的解釋

在 Kubernetes 中，Deployment 的定義中確實存在多個地方使用了相同的標籤（如 metadata.labels.app=nginx），這有其特定的目的和意義。下面是對這些標籤的詳細解釋及其用意：

1. Metadata Labels

  • 位置：在 metadata 部分。
  • 作用：
    • 用於為 Deployment 物件本身打標籤，這些標籤可以用於標識、選擇或組織 Kubernetes 物件。
    • 可以透過這些標籤來查詢和過濾 Deployment 物件，例如使用 kubectl get deployments -l app=nginx 來列出所有帶有 app=nginx 標籤的 Deployments。
    • 在service定義時，它的spec.selector.app會指向被關聯的deployment的.metadata.labels.app的名字

2. Spec Selector

  • 位置：在 spec.selector 部分。
  • 作用：
    • 定義了該 Deployment 控制器所管理的 Pods 的選擇標準。
    • Kubernetes 使用此選擇器來確定哪些 Pods 是由這個 Deployment 建立和管理的。
    • 選擇器中的標籤必須與 Pods 的標籤匹配，以確保 Deployment 能夠正確地找到和管理這些 Pods。

3. Template Metadata Labels

  • 位置：在 template.metadata.labels 部分。
  • 作用：
    • 定義將要建立的 Pods 的標籤。
    • 當 Deployment 建立 Pods 時，這些標籤會被附加到新建立的 Pods 上。
    • 這些標籤用於與 spec.selector 中定義的選擇器進行匹配，從而使 Deployment 能夠跟蹤並管理這些 Pods。

為什麼要重複定義？

  1. 一致性：

    • 在 Deployment 的不同部分使用相同的標籤確保了它們之間的一致性。這種一致性對於 Kubernetes 的操作至關重要，因為它依賴於這些標籤來管理物件。

  2. 可管理性：

    • 透過使用相同的標籤，可以更方便地進行篩選和管理。例如，你可以快速找到所有與特定應用程式（如 nginx）相關的 Deployments、Pods 和 Services。

  3. 避免錯誤：

    • 確保 Pods 的標籤與 Deployment 的選擇器相匹配，可以避免由於標籤不一致導致的管理問題。如果選擇器未能正確匹配 Pods，Deployment 將無法管理這些 Pods。

相關文章