Kubernetes 服務型別與持久化儲存解析

Kubernetes 提供多種服務型別以滿足不同應用需求，同時提供持久化儲存方案確保資料持久可靠。NodePort 服務允許外部流量透過節點埠存取叢集內 Pod，適用於外部存取應用場景。ClusterIP 服務則分配內部 IP，僅供叢集內部通訊，例如前端存取後端服務。持久化儲存透過 PersistentVolume 和 PersistentVolumeClaim 實作，確保 Pod 資料不因 Pod 重啟或刪除而丟失，適用於資料持久化應用。文章也涵蓋 Deployment、StatefulSet 和 DaemonSet 的最佳實踐，以及 Helm Charts 和 Operators 的應用，最後也深入 Kubernetes 安全性，探討認證、授權、准入控制、Pod 安全和網路策略等議題。

Kubernetes 中的服務型別與持久化儲存解析

Kubernetes 提供了多種服務型別來滿足不同的應用場景需求，同時也提供了持久化儲存方案來確保資料的永續性和可靠性。本篇文章將探討 Kubernetes 中的服務型別、持久化儲存以及相關的最佳實踐。

Kubernetes 服務型別詳解

Kubernetes 中的服務（Service）是一種抽象概念，用於定義一組 Pod 的存取方式。根據不同的需求，Kubernetes 提供了多種服務型別，包括 NodePort、ClusterIP、LoadBalancer 和 ExternalName 等。

NodePort 服務型別

NodePort 服務型別允許外部流量透過特定的節點埠存取叢集內的 Pod。這種服務型別適用於需要從叢集外部存取應用的場景。

為何需要 NodePort 服務？

NodePort 服務提供了一種簡單的方式來暴露叢集內的應用，使其能夠被外部存取。透過在每個節點上開放特定的埠，外部請求可以被路由到對應的 Pod。

NodePort YAML 定義解析

apiVersion: v1
kind: Service
metadata:
  name: whoami-nodeport
spec:
  type: NodePort
  selector:
    app: whoami
  ports:
  - name: http
    port: 80
    targetPort: 8080
    nodePort: 30080
    protocol: TCP

詳解 NodePort 設定

type: 指定服務型別為 NodePort。
selector: 指定該服務關聯的 Pod 標籤。
ports: 定義服務的埠組態，包括 port、targetPort、nodePort 和 protocol。

確保 NodePort 運作正常

建立 NodePort 服務後，可以透過存取任意節點的指定埠來驗證服務是否正常運作。

ClusterIP 服務型別

ClusterIP 是 Kubernetes 中預設的服務型別，它為服務分配一個內部的 IP 地址，使其只能在叢集內部被存取。

為何需要 ClusterIP 服務？

ClusterIP 服務適用於叢集內部元件之間的通訊，例如前端應用需要存取後端服務。

ClusterIP YAML 定義解析

apiVersion: v1
kind: Service
metadata:
  name: whoami-clusterip
spec:
  type: ClusterIP
  selector:
    app: whoami
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP

詳解 ClusterIP 設定

type: 指定服務型別為 ClusterIP。
其他組態與 NodePort 相似，但不需要 nodePort。

Kubernetes 中的持久化儲存

Kubernetes 中的持久化儲存透過 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）來實作。PV 是叢集中的儲存資源，而 PVC 是對 PV 的請求。

為何需要持久化儲存？

持久化儲存確保了 Pod 中的資料不會因為 Pod 的重啟或刪除而丟失，適用於需要資料持久化的應用場景。

PersistentVolume 和 PersistentVolumeClaim 的工作流程

建立 PV: 管理員建立 PV 物件，定義儲存資源的大小和存取模式。
建立 PVC: 使用者建立 PVC 物件，請求特定的儲存資源。
繫結 PV 和 PVC: Kubernetes 自動將 PVC 繫結到合適的 PV。
使用 PVC: 在 Pod 中參照 PVC，使用持久化儲存。

PersistentVolume YAML 定義示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  local:
    path: /mnt/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-node

詳解 PersistentVolume 設定

capacity: 定義 PV 的儲存容量。
accessModes: 定義 PV 的存取模式，如 ReadWriteOnce、ReadOnlyMany 等。
persistentVolumeReclaimPolicy: 定義 PV 的回收策略，如 Retain、Delete 等。

Kubernetes 進階資源管理與應用佈署

管理 Deployment 物件的最佳實踐

在 Kubernetes 中，Deployment 物件是用於管理應用程式佈署的重要資源。正確地使用 Deployment 物件，可以確保應用程式的穩定性和可擴充套件性。以下是一些管理 Deployment 物件的最佳實踐：

使用宣告式物件管理：使用宣告式物件管理可以簡化 Deployment 物件的管理，並且可以確保應用程式的組態是一致的。
避免使用 Recreate 策略：Recreate 策略會導致應用程式的停機時間，應該避免在生產環境中使用。
避免建立與現有 Deployment 物件標籤選擇器相匹配的 Pod：這可能會導致 Deployment 物件管理不正確的 Pod，從而引起問題。
仔細設定容器探針：容器探針是用於檢查容器健康狀態的重要機制，應該仔細設定以確保容器的正常執行。
使用有意義和語義化的映像標籤：使用有意義和語義化的映像標籤可以簡化映像的管理，並且可以確保應用程式的正確性。

StatefulSet 的介紹與管理

StatefulSet 是 Kubernetes 中的一種資源，用於管理有狀態的應用程式。與 Deployment 物件不同，StatefulSet 可以確保 Pod 的身份和狀態的一致性。

StatefulSet 的特點

穩定的網路身份：StatefulSet 可以為每個 Pod 分配一個穩定的網路身份，從而確保 Pod 之間的通訊是一致的。
持久化儲存：StatefulSet 可以使用持久化儲存來儲存 Pod 的狀態，從而確保 Pod 的狀態是一致的。

管理 StatefulSet

建立 StatefulSet：可以使用 YAML 或 JSON 檔案來建立 StatefulSet。
擴充套件 StatefulSet：可以使用 kubectl scale 命令來擴充套件 StatefulSet。
刪除 StatefulSet：可以使用 kubectl delete 命令來刪除 StatefulSet。

DaemonSet 的介紹與管理

DaemonSet 是 Kubernetes 中的一種資源，用於在每個節點上執行一個 Pod。DaemonSet 通常用於執行一些後台任務，例如日誌收集或監控。

DaemonSet 的特點

每個節點執行一個 Pod：DaemonSet 可以確保每個節點上執行一個 Pod。
自動重新建立 Pod：如果 Pod 被刪除或終止，DaemonSet 可以自動重新建立一個新的 Pod。

管理 DaemonSet

建立 DaemonSet：可以使用 YAML 或 JSON 檔案來建立 DaemonSet。
修改 DaemonSet：可以使用 kubectl edit 命令來修改 DaemonSet。
刪除 DaemonSet：可以使用 kubectl delete 命令來刪除 DaemonSet。

Helm Charts 與 Operators 的介紹

Helm Charts 和 Operators 是兩種用於簡化 Kubernetes 應用程式佈署和管理的工具。

Helm Charts

簡化應用程式佈署：Helm Charts 可以簡化應用程式的佈署，並且可以確保應用程式的組態是一致的。
可重複使用的包：Helm Charts 可以被重複使用，從而簡化了應用程式的佈署和管理。

Operators

自動化應用程式管理：Operators 可以自動化應用程式的管理，並且可以確保應用程式的狀態是一致的。
自定義資源定義：Operators 可以使用自定義資源定義來擴充套件 Kubernetes 的功能。

第18章：Kubernetes中的安全性

技術需求

在探討Kubernetes中的安全性之前，請確保您具備以下條件：

對Kubernetes的基本架構和元件有一定了解。
具備使用Kubernetes命令列工具（kubectl）的基本技能。
對容器化和微服務架構有基本的認識。

認證和授權 - 使用者存取控制

認證和使用者管理

Kubernetes提供了多種認證方法，用於驗證使用者和服務帳戶的身份。主要的認證方法包括：

X509客戶端證書：使用客戶端證書進行認證。
靜態令牌檔案：使用靜態令牌檔案進行認證。
靜態密碼檔案：使用靜態密碼檔案進行認證。
服務帳戶令牌：使用服務帳戶令牌進行認證。
OpenID Connect令牌：使用OpenID Connect令牌進行認證。

Kubernetes中的認證流程

當使用者或服務帳戶向Kubernetes API傳送請求時，認證模組會首先驗證請求的身份。
如果認證成功，則將請求轉發給授權模組進行進一步的許可權檢查。

Kubernetes API的認證

Kubernetes API支援多種認證外掛，可以根據需要啟用或停用這些外掛。

apiVersion: v1
kind: Config
users:
- name: kubernetes-admin
  user:
    client-certificate: /path/to/client/cert
    client-key: /path/to/client/key

內容解密：

此YAML組態檔案定義了一個Kubernetes使用者，使用X509客戶端證書進行認證。其中：

apiVersion 和 kind 定義了組態檔案的版本和型別。
users 部分定義了使用者的名稱和認證資訊。
client-certificate 和 client-key 分別指定了客戶端證書和私鑰的路徑。

授權和RBAC介紹

RBAC模式在Kubernetes中

Kubernetes使用根據角色的存取控制（RBAC）來管理使用者和服務帳戶的許可權。RBAC透過定義角色和角色繫結來控制對Kubernetes資源的存取。

角色（Role）：定義了一組許可權，用於描述允許對哪些資源執行哪些操作。
角色繫結（RoleBinding）：將角色繫結到使用者或服務帳戶上，授予相應的許可權。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

內容解密：

此YAML組態檔案定義了一個名為pod-reader的角色，該角色允許對Pod資源執行get和list操作。其中：

apiVersion 和 kind 定義了組態檔案的版本和型別。
metadata 部分定義了角色的名稱。
rules 部分定義了角色的許可權規則，包括允許操作的資源和動詞。

准入控制 - 安全策略和檢查

兩階段准入過程

Kubernetes使用准入控制器來在建立或修改資源之前執行安全策略和檢查。准入過程分為兩個階段：

變異階段（Mutation Phase）：在這個階段，准入控制器可以修改資源物件。
驗證階段（Validation Phase）：在這個階段，准入控制器驗證資源物件是否符合安全策略。

常見的准入控制器

NamespaceLifecycle：確保資源建立在有效的名稱空間中。
LimitRanger：限制資源的使用量。
ServiceAccount：確保Pod使用有效的服務帳戶。

保護Pod和容器

使用SecurityContext保護Pod和容器

SecurityContext允許您為Pod或容器指定安全組態，例如執行時使用的使用者和組、檔案系統許可權等。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000

內容解密：

此YAML組態檔案定義了一個Pod，並為其指定了SecurityContext。其中：

runAsUser 指定了執行Pod的使用者ID。
fsGroup 指定了檔案系統的組ID。

網路策略（NetworkPolicy）

網路策略允許您控制Pod之間的網路流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

內容解密：

此YAML組態檔案定義了一個網路策略，允許來自同一名稱空間的Pod之間的入口流量。其中：

podSelector 用於選擇受此網路策略影響的Pod。
ingress 部分定義了允許的入口流量規則。

進一步閱讀

玄貓 BlackCat

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