Kubernetes 物件管理與組態

– 10 分鐘閱讀

Kubernetes 提供豐富的物件模型，用於管理叢集中的各種資源。理解這些物件的定義和使用方法，對於有效地佈署和管理應用程式至關重要。ConfigMap 和 Secret 分別用於儲存非敏感和敏感組態資料，確保應用程式的組態與程式碼分離。Service 則負責將 Pod 暴露給外部網路或叢集內部其他服務，提供穩定的網路存取入口。Deployment 則簡化了應用程式的佈署和更新流程，支援滾動更新、回復等功能，提高了應用程式的可靠性和可用性。

Kubernetes基礎物件介紹與管理

在前面的章節中，我們已經瞭解了Kubernetes的基本元件以及如何使用指令式命令與API伺服器互動。現在，我們將進一步探討Kubernetes物件（Kubernetes Objects）以及如何使用kubectl來管理它們。

Kubernetes 清單檔（Manifests）

Kubernetes 物件是透過清單檔（Manifests）來建立的。清單檔可以使用YAML或JSON格式編寫，大多數情況下我們使用YAML格式。一個基本的清單檔至少需要包含apiVersion、Kind和metadata欄位，如下所示：

apiVersion: apps/v1
Kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
  namespace: monitoring

上述範例僅展示了一個完整的佈署清單檔的一部分。可以看到，清單檔中的格式非常嚴格，YAML對空格的要求非常高，如果格式錯誤，將無法成功佈署。

何謂 Kubernetes 物件？

當您想要在叢集中新增或刪除某些東西時，您實際上是在與Kubernetes物件互動。物件代表了叢集中的一種資源，用於維護某種期望狀態（Desired State）。這種期望狀態可能是建立、刪除或擴充套件某個物件。根據物件的期望狀態，API伺服器將確保叢集的當前狀態與期望狀態保持一致。

要檢索叢集中支援的物件列表，可以使用kubectl api-resources命令。API伺服器將傳回所有支援的物件列表，包括簡稱、名稱空間支援以及所屬的API群組。

ConfigMaps

ConfigMap是一種用於儲存組態資料的物件，它以鍵值對的形式儲存資料，使得應用程式的組態可以與應用程式本身分離。ConfigMap可以包含來自文字值、檔案或目錄的資料。

以下是建立ConfigMap的指令式命令範例：

kubectl create configmap <name> <data>

例如，要從一個檔案建立ConfigMap，可以使用--from-file選項：

kubectl create configmap config-test --from-file=/apps/nginx-config/nginx.conf

這將建立一個名為config-test的ConfigMap，其中包含一個名為nginx.conf的鍵，其值為nginx.conf檔案的內容。

ConfigMap 詳細內容檢視

要檢視ConfigMap的詳細內容，可以使用kubectl get configmaps命令，並加上-o yaml選項以YAML格式輸出：

kubectl get configmaps config-test -o yaml

內容解密：

  1. ConfigMap建立：使用kubectl create configmap命令可以建立ConfigMap，可以從檔案、目錄或文字值建立。
  2. 鍵值對儲存：ConfigMap以鍵值對的形式儲存資料，鍵通常是檔案名稱或指定的名稱，值是檔案的內容或指定的文字值。
  3. 應用程式組態分離：ConfigMap使得應用程式的組態可以與應用程式本身分離，便於管理和更新組態。
  4. 名稱空間：ConfigMap通常隸屬於某個名稱空間，使用-n <namespace>選項可以指定名稱空間。

Plantuml 圖表說明

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 物件管理與組態

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

圖表翻譯：

此圖表展示了ConfigMap的基本結構和用途。ConfigMap包含鍵值對，鍵值對中儲存的是組態資料。這些組態資料可以來自檔案或文字值，最終用於應用程式的組態。

Kubernetes 基礎物件介紹

Kubernetes 提供多種基礎物件，用於管理和操作叢集資源。這些物件包括 ConfigMaps、Endpoints、Events、Namespaces、Nodes、Persistent Volume Claims (PVCs)、Persistent Volumes (PVs)、Pods、Replication Controllers 和 ResourceQuotas。

ConfigMaps

ConfigMap 用於儲存非機密的組態資料。由於 ConfigMap 中的資料以明文形式儲存，因此不應將敏感資訊（如密碼）儲存在 ConfigMap 中。Kubernetes 提供了另一種物件——Secret，用於儲存敏感資訊。

使用 ConfigMap 的注意事項

  • 資料以明文形式儲存。
  • 不應儲存敏感資訊。

Endpoints

Endpoint 將 Service 對應到一個或多個 Pod。當我們深入瞭解 Service 物件時，這一點將會更加明確。目前，你只需要知道可以使用 kubectl get endpoints 命令來檢索端點。

Endpoint 的作用

  • 對應 Service 到 Pod。
  • 可用於故障排除。

Events

Events 物件顯示特定名稱空間中的事件。要取得 kube-system 名稱空間中的事件列表，可以使用 kubectl get events -n kube-system 命令。

Events 的用途

  • 顯示名稱空間中的事件。
  • 有助於監控和故障排除。

Namespaces

Namespace 用於將叢集劃分為邏輯單元。每個名稱空間允許對資源進行細粒度管理，包括許可權、配額和報告。

Namespace 的操作

  • 可以使用 kubectl <verb> ns <namespace name> 命令進行建立、刪除、編輯和檢索等操作。
  • 有助於在多租戶叢集中進行資源管理。

Nodes

Node 物件是一個叢集級別的資源，用於與叢集中的節點進行互動。可以使用 kubectl get nodes 命令檢索叢集中的節點列表。

Node 的操作

  • 可以使用 kubectl describe node <node-name> 命令取得節點的詳細資訊。
  • 有助於監控節點狀態和資源使用情況。

Persistent Volume Claims (PVCs)

PVC 用於由 Pod 消耗持久化儲存。PVC 使用 Persistent Volume (PV) 對映儲存資源。

PVC 的特點

  • 是名稱空間級別的物件。
  • 必須在與使用 PVC 的 Pod 相同的名稱空間中建立。

Persistent Volumes (PVs)

PV 用於在 PVC 和底層儲存系統之間建立連結。在實際應用中，應避免手動維護 PV，因為 Kubernetes 提供了使用 Container Storage Interface (CSI) 管理大多數常見儲存系統的功能。

PV 的作用

  • 對映 PVC 到底層儲存系統。
  • Kubernetes 可以自動建立 PV。

Pods

Pod 物件用於與執行中的容器進行互動。可以使用 kubectl 實用程式執行諸如 get、delete 和 describe 等命令。

Pod 的特點

  • 不建議直接建立 Pod，除非用於快速故障排除。
  • 直接建立的 Pod 無法使用 Kubernetes 提供的許多功能，如擴充套件、自動重啟和滾動升級。

Replication Controllers

Replication Controller 用於管理執行中的 Pod 數量，保持指定的副本數量。如果建立了一個副本數量為 5 的 Replication Controller，它將始終保持 5 個應用程式 Pod 在執行。

Replication Controller 的替代方案

  • ReplicaSet 物件。
  • Deployment 物件。

ResourceQuotas

ResourceQuota 用於限制名稱空間中的資源使用。可以對大多數叢集物件設定限制，如 CPU、記憶體、PVCs、ConfigMaps、Deployments 和 Pods。

ResourceQuota 的作用

  • 限制名稱空間中的資源使用。
  • 當達到限制時，將阻止建立額外的物件。

以下是一個基本的 ResourceQuota 清單檔案範例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: base-memory-cpu
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "4Gi"
    limits.cpu: "4"
    limits.memory: "8Gi"

內容解密：

  1. apiVersion 和 kind：定義了 Kubernetes 資源的 API 版本和型別。在此例中，apiVersion 為 v1，kind 為 ResourceQuota，表示這是一個資源配額定義。
  2. metadata：包含了資源的中繼資料，如名稱。在此例中，ResourceQuota 名稱為 base-memory-cpu。
  3. spec：定義了 ResourceQuota 的規格，即硬體資源限制。在此例中，定義了 CPU 和記憶體的請求和限制。
  4. requests.cpu 和 requests.memory：定義了該名稱空間中所有 Pod 請求的 CPU 和記憶體總量上限。在此例中，CPU 請求總量不超過 2 個核心，記憶體請求總量不超過 4Gi。
  5. limits.cpu 和 limits.memory：定義了該名稱空間中所有 Pod 限制的 CPU 和記憶體總量上限。在此例中，CPU 使用限制總量不超過 4 個核心，記憶體使用限制總量不超過 8Gi。

透過這個 ResourceQuota，可以有效地管理名稱空間中的資源使用，避免單一名稱空間過度佔用叢集資源。

Kubernetes 物件介紹

在 Kubernetes 中，資源管理與存取控制是非常重要的議題。本章節將探討 ResourceQuota、Secrets、Service Accounts 和 Services 等 Kubernetes 物件的使用和管理。

ResourceQuota

ResourceQuota 是用於控制 Kubernetes 叢集中資源使用量的物件。透過為特定的名稱空間分配資源配額，可以確保單一租戶擁有所需的 CPU 和記憶體資源，同時限制不良應用程式對其他應用程式的影響。

以下是一個 ResourceQuota 的範例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: base-memory-cpu
spec:
  hard:
    requests.cpu: 2
    requests.memory: 8Gi
    limits.cpu: "4"
    limits.memory: 16Gi

內容解密：

  • requests.cpu 和 requests.memory 定義了名稱空間中 Pod 請求的 CPU 和記憶體資源總量。
  • limits.cpu 和 limits.memory 定義了名稱空間中 Pod 可使用的 CPU 和記憶體資源總量的上限。

使用 kubectl describe 命令可以檢視 ResourceQuota 的使用情況。

Secrets

Secrets 用於儲存敏感資訊，如密碼、OAuth token 等。與 ConfigMap 不同，Secrets 是以 Base64 編碼的字串儲存的。

建立 Secret 的方法有多種，可以使用檔案、目錄或直接從字串建立。以下是一個使用檔案建立 Secret 的範例：

kubectl create secret generic mysql-admin --from-file=./dbpwd

執行後，可以使用 kubectl get secret 命令檢視 Secret 的內容。

內容解密：

  • 使用 --from-file 選項可以從檔案建立 Secret。
  • 使用 kubectl get secret 命令可以檢視 Secret 的內容，輸出結果是以 Base64 編碼的。

值得注意的是，Secrets 儲存在 Etcd 中，如果 Etcd 被入侵，攻擊者可以輕易地取得 Secrets 的內容。因此，Kubernetes 提供了加密 Secrets 的功能，以增強安全性。

Service Accounts

Service Accounts 用於為 Pod 提供身份驗證和授權，以便存取其他 Kubernetes 物件或服務。

建立 Service Account 的過程很簡單，只需要在 manifest 檔案中定義即可。以下是一個範例：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: grafana
  namespace: monitoring

內容解密：

  • Service Account 需要與 Role 和 RoleBinding 結合使用，以實作對 Kubernetes 物件的存取控制。

Services

Services 用於將 Pod 暴露給網路，使其可以被其他 Pod 或外部使用者端存取。Service 有多種型別，包括 ClusterIP、NodePort、LoadBalancer 和 ExternalName。

以下是一個建立 Service 的範例：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-web-frontend
  name: nginx-web
spec:
  ports:
  - name: http
    port: 80

內容解密：

  • Service 的型別決定了其暴露給網路的方式。
  • ClusterIP 是預設型別，只能在叢集內部存取。
  • NodePort 和 LoadBalancer 可以將 Service 暴露給外部網路。

本章節介紹了 Kubernetes 中的 ResourceQuota、Secrets、Service Accounts 和 Services 等重要物件的使用和管理。這些物件對於確保叢集的安全性和穩定性至關重要。

Kubernetes 物件介紹

Kubernetes 提供多種物件來管理容器化應用程式的佈署、擴充套件和管理。本章節將探討 Kubernetes 中的各種物件，包括 Service、CustomResourceDefinitions、DaemonSets、Deployments、ReplicaSets、StatefulSets、HorizontalPodAutoscalers 和 CronJobs。

Service

Service 是 Kubernetes 中的一個重要物件，用於將 Pod 暴露給外部網路。以下是一個簡單的 Service 清單範例：

targetPort: 80
selector:
  app: nginx-web

在這個範例中，我們建立了一個名為 nginx-web 的 Service，將 Pod 的 80 埠暴露給外部網路。Service 會自動將流量轉發到具有 app: nginx-web 標籤的 Pod。

內容解密：

  • targetPort 指定了 Pod 的埠號。
  • selector 指定了 Service 要轉發流量的 Pod 標籤。

CustomResourceDefinitions

CustomResourceDefinitions (CRDs) 允許使用者擴充套件 Kubernetes 的功能，將自定義的資源整合到叢集中。CRDs 可以使用標準的 kubectl 命令進行操作。

DaemonSets

DaemonSets 用於在叢集中的每個節點上佈署一個 Pod。常見的應用場景是佈署日誌收集器，如 FluentD。DaemonSets 會自動在新加入叢集的節點上佈署 Pod。

Deployments

Deployments 提供了一種宣告式的方式來管理 Pod 的佈署和更新。它們可以自動進行滾動更新和回復。建立 Deployment 時，Kubernetes 會先建立一個 ReplicaSet 物件，然後由 ReplicaSet 建立 Pod。

ReplicaSets

ReplicaSets 用於建立和管理 Pod 的副本。它們可以確保指定數量的 Pod 副本始終執行。如果 Pod 的數量少於指定的數量，Kubernetes 會自動建立新的 Pod。

StatefulSets

StatefulSets 提供了一種方式來佈署有狀態的應用程式。它們可以確保 Pod 的名稱、順序和持久化儲存的一致性。以下是一個 StatefulSet 清單範例：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

內容解密：

  • replicas 指定了 Pod 的副本數量。
  • volumeClaimTemplates 指定了持久化儲存的範本。

HorizontalPodAutoscalers

HorizontalPodAutoscalers (HPAs) 提供了一種自動擴充套件 Pod 的方式，根據 CPU 使用率或其他自定義指標。以下是一個 HPA 清單範例：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-deployment
spec:
  maxReplicas: 5
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  targetCPUUtilizationPercentage: 50

內容解密：

  • maxReplicas 和 minReplicas 指定了 Pod 的最大和最小副本數量。
  • targetCPUUtilizationPercentage 指定了 CPU 使用率的目標值。

CronJobs

CronJobs 提供了一種方式來排程任務，類別似於 Linux 中的 cronjob。以下是一個 CronJob 清單範例：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule:
    - cron: */1 * * * *
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:latest
            command: ["echo", "Hello Kubernetes!"]
          restartPolicy: OnFailure

內容解密：

  • schedule 指定了任務的排程時間。
  • jobTemplate 指定了任務的範本。

本章節介紹了 Kubernetes 中的各種物件，包括 Service、CustomResourceDefinitions、DaemonSets、Deployments、ReplicaSets、StatefulSets、HorizontalPodAutoscalers 和 CronJobs。每個物件都有其特定的功能和應用場景，理解這些物件可以幫助您更好地管理和佈署容器化應用程式。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。