返回文章列表
玄貓（BlackCat）

Kubernetes叢集安裝設定與安全管理

本文探討如何使用 kubeadm 安裝、設定和管理 Kubernetes 叢集，涵蓋憑證生成、etcd 設定、API 伺服器引數調整、控制平面與工作節點設定、高用性控制平面架構、叢集升級流程、以及安全性強化等導向。文章提供詳細的組態示例和程式碼解析，並說明各個步驟的注意事項，協助讀者建立安全可靠的

容器技術 系統管理
Kubernetes kubeadm 叢集管理 安全設定 憑證管理 etcd

Kubernetes 叢集的佈署和管理涵蓋許多導向，從初始化設定到安全強化都需要仔細考量。使用 kubeadm 可以簡化安裝流程，但仍需深入理解各項設定的影響。本文將逐步解析如何使用 kubeadm 建立和管理 Kubernetes 叢集，包含憑證管理、etcd 設定、API 伺服器引數調整、控制平面與工作節點的設定、高用性控制平面架構的建立、叢集升級策略，以及安全性強化等關鍵環節。透過理解這些核心概念，才能建構安全、穩定且高效的 Kubernetes 叢集。

Kubernetes 安裝與設定深入解析

Kubernetes 的安裝過程涉及多個元件的組態與啟動，其中 kubeadm 是一個重要的工具，用於簡化 Kubernetes 叢集的佈署。在使用 kubeadm 初始化叢集時，會經歷多個步驟，包括預檢查、憑證生成、etcd 設定等。

kubeadm 組態檔案詳解

在使用 kubeadm 初始化 Kubernetes 叢集時，可以透過組態檔案進行詳細的設定。組態檔案中包含了多個重要引數，例如 selfHosted、apiServerExtraArgs、controllerManagerExtraArgs、schedulerExtraArgs 等。這些引數允許管理員自定義 Kubernetes 元件的行為。

設定示例

selfHosted: true
apiServerExtraArgs:
  advertise-address: "192.168.1.100"
  feature-gates: "TTLAfterFinished=true"
controllerManagerExtraArgs:
  node-monitor-grace-period: "40s"
  node-monitor-period: "5s"
schedulerExtraArgs:
  config: "/etc/kubernetes/scheduler.conf"
apiServerCertSANs:
  - "kubernetes"
  - "kubernetes.default"
  - "kubernetes.default.svc"
  - "kubernetes.default.svc.cluster"
  - "kubernetes.default.svc.cluster.local"
certificatesDir: "/etc/kubernetes/pki"

內容解密：

  • selfHosted: 指定是否為自託管叢集。
  • apiServerExtraArgs: 為 kube-apiserver 提供額外的啟動引數，例如設定廣告位址和功能門控。
  • controllerManagerExtraArgs: 為 kube-controller-manager 提供額外的啟動引數，例如節點監控相關設定。
  • schedulerExtraArgs: 為 kube-scheduler 提供額外的啟動引數，例如指定排程器組態檔案。
  • apiServerCertSANs: 為 kube-apiserver 的憑證指定額外的 SAN（主體別名）。
  • certificatesDir: 指定存放 Kubernetes 憑證的目錄。

預檢查與憑證生成

在執行 kubeadm init 時，首先會進行一系列的預檢查，以確保系統環境符合 Kubernetes 的安裝需求。這些檢查包括檢查 kubelet 是否執行、交換空間是否已停用、基本的系統工具是否已安裝等。

完成預檢查後，kubeadm 會生成所需的憑證，包括 CA 憑證和私鑰，用於簽署其他元件的憑證。這些憑證存放在 /etc/kubernetes/pki 目錄下。

憑證目錄結構示例

$ ls -al /etc/kubernetes/pki/
total 56
drwxr-xr-x 2 root root 4096 Mar 15 02:42 .
drwxr-xr-x 4 root root 4096 Mar 15 02:42 ..
-rw-r--r-- 1 root root 1229 Mar 15 02:42 apiserver.crt
-rw
---
---
- 1 root root 1675 Mar 15 02:42 apiserver.key
-rw-r--r-- 1 root root 1099 Mar 15 02:42 apiserver-kubelet-client.crt
-rw
---
---
- 1 root root 1679 Mar 15 02:42 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1025 Mar 15 02:42 ca.crt
-rw
---
---
- 1 root root 1675 Mar 15 02:42 ca.key

程式碼解析：

# 檢視 /etc/kubernetes/pki 目錄下的檔案列表
ls -al /etc/kubernetes/pki/

內容解密：

  • /etc/kubernetes/pki 目錄下存放了 Kubernetes 所需的各種憑證和私鑰。
  • apiserver.crt 和 apiserver.key 是用於 kube-apiserver 的憑證和私鑰。
  • ca.crt 和 ca.key 是 CA 根憑證和私鑰，用於簽署其他元件的憑證。

etcd 設定與安全性

kubeadm 在初始化叢集時，預設會啟動一個本地的 etcd 例項。然而，在生產環境中，建議使用外部的、高可用性的 etcd 叢集，以確保資料的安全性和可靠性。

此外，etcd 中的資料預設是未加密的，特別是 Secret 物件。因此，建議使用 --experimental-encryption-provider-config 引數來加密 Secret 物件。

設定 etcd 示例

apiServerExtraArgs:
  experimental-encryption-provider-config: "/etc/kubernetes/pki/encryption.conf"

程式碼解析：

# 在 apiServerExtraArgs 中設定 encryption-provider-config
apiServerExtraArgs:
  experimental-encryption-provider-config: "/etc/kubernetes/pki/encryption.conf"

內容解密：

  • 使用 --experimental-encryption-provider-config 引數指定加密組態檔案的路徑。
  • 組態檔案 /etc/kubernetes/pki/encryption.conf 中定義了用於加密 Secret 物件的對稱金鑰。

Kubernetes 叢集安裝與組態詳解

Kubernetes 叢集的安裝涉及多個元件和組態步驟，包括控制平面（Control Plane）、工作節點（Worker Nodes）以及必要的附加元件（Add-Ons）。本篇將探討如何使用 kubeadm 工具來安裝和組態 Kubernetes 叢集。

使用 EncryptionConfig 加密敏感資料

在 Kubernetes 中，對於敏感資料的保護至關重要。EncryptionConfig 提供了一種加密機制，可以在資料寫入 etcd 之前對其進行加密。以下是一個 encryption.conf 檔案的示例：

kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
    - identity: {}
    - aescbc:
        keys:
        - name: encryptionkey
          secret: BHk4lSZnaMjPYtEHR/jRmLp+ymazbHirgxBHoJZqU/Y=

內容解密：

  • kind 和 apiVersion 定義了該組態檔案的型別和版本。
  • resources 指定了需要加密的資源型別，在此例中為 secrets。
  • providers 定義了加密提供者，aescbc 是一種推薦的加密型別。
  • secret 欄位需要一個隨機生成的 32 位元組金鑰。

透過在 kube-apiserver 命令列引數中新增 --experimental-encryption-provider-config=/path/to/encryption.conf，可以啟用加密功能。

kubeconfig 檔案的生成與使用

kubeadm 不僅安裝了 Kubernetes 元件，還生成了多個 kubeconfig 檔案，用於身份驗證。其中，/etc/kubernetes/admin.conf 是用於叢集管理的超級使用者組態檔案。

內容解密：

  • kubeadm 自動生成 kubeconfig 檔案，簡化了身份驗證的組態。
  • 對於生產環境，應當組態額外的身份機制，而不僅僅依賴 kubeadm 生成的憑證。

控制平面節點的隔離

在生產環境中，建議將工作負載與控制平面元件隔離。kubeadm 預設會對控制平面節點新增 node-role.kubernetes.io/master 汙點（Taint），以防止排程器將普通 Pod 排程到這些節點上。

內容解密：

  • 使用 kubectl taint nodes <node name> node-role.kubernetes.io/master- 命令可以移除汙點，允許在單節點叢集中排程 Pod。

工作節點的安裝與加入叢集

工作節點需要安裝容器執行時（Container Runtime）和 kubelet。透過 kubeadm join 命令，工作節點可以加入叢集，並透過 TLS 載入程式獲得必要的憑證。

內容解密：

  • kubeadm join 命令需要 --token 和 --discovery-token-ca-cert-hash 引數，以確保節點加入的安全性。
  • --token 可以透過 kubeadm token create 命令生成，用於臨時身份驗證。

附加元件的安裝

Kubernetes 叢集需要安裝額外的元件，如容器網路介面（CNI）外掛，以實作 Pod 之間的網路連線。

內容解密：

  • CNI 外掛透過 DaemonSet 的形式佈署，提供 Pod-to-Pod 的網路連線。
  • 不同 CNI 外掛有不同的生命週期和管理方式，kubeadm 不直接管理它們。

綜上所述，使用 kubeadm 安裝 Kubernetes 叢集涉及多個關鍵步驟，包括加密組態、kubeconfig 檔案生成、控制平面與工作節點的安裝、以及必要的附加元件佈署。每一步都需要仔細組態，以確保叢集的安全性和穩定性。

Kubernetes 叢集管理與升級

Kubernetes 叢集的管理與升級是維持系統穩定性和安全性的關鍵步驟。本文將探討使用 kubeadm 工具進行 Kubernetes 叢集的安裝、升級和管理。

kubeadm 的功能與限制

kubeadm 是一個用於佈署 Kubernetes 叢集的工具，它支援多種安裝組態，並提供了一系列的功能來簡化叢集的管理。然而，kubeadm 也有其限制，例如它不直接管理某些額外的元件，如日誌聚合、監控和服務網格等。

叢集 DNS 管理

kubeadm 支援兩種主要的叢集 DNS 解決方案：kube-dns 和 CoreDNS。預設情況下，kubeadm 使用 kube-dns，但使用者可以根據自己的需求選擇其他的 DNS 提供者。

kubeadm 的進階功能

Phases 功能

kubeadm 的 phases 功能允許使用者將安裝過程分解為多個獨立的步驟。這使得其他安裝工具可以結合 kubeadm 的特定功能，例如生成 PKI 資產或執行預檢檢查。

高用性控制平面

建立高用性的控制平面是生產環境中的關鍵需求。雖然 kubeadm 主要關注單一節點的管理，但它仍然可以用來建立高用性的叢集。建立高用性控制平面的基本步驟包括：

  1. 建立高可用性的 etcd 叢集。
  2. 使用 kubeadm 初始化主要控制平面節點，並組態 etcd 叢集。
  3. 安全地將 PKI 資產傳輸到其他控制平面節點。
  4. 使用負載平衡器前端控制平面 API 伺服器。
  5. 將所有工作節點加入叢集，並透過負載平衡端點進行連線。

升級 Kubernetes 叢集

升級 Kubernetes 叢集是獲得新功能和安全更新的必要步驟。kubeadm 支援零停機時間的升級，使得應用程式可以在底層基礎設施更新期間繼續執行。

升級流程

  1. 規劃升級：kubeadm 分析目前的叢集狀態，並確定可用的升級路徑。
  2. 套用升級：根據規劃的升級路徑，執行 kubeadm upgrade apply 命令來升級叢集。
root@control1:~# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:

內容解密：

此段落展示了使用 kubeadm upgrade plan 命令來規劃叢集升級的過程。該命令會執行預檢檢查，確保叢集狀態健康，並分析目前的組態。

  1. 手動升級元件：某些元件，如 kubelet，需要手動升級，以確保與新的 Kubernetes 版本相容。
COMPONENT            CURRENT   AVAILABLE
Kubelet              4 x v1.9.3   v1.9.8
API Server           v1.9.5   v1.9.8
Controller Manager   v1.9.5   v1.9.8
Scheduler            v1.9.5   v1.9.8
Kube Proxy           v1.9.5   v1.9.8
Kube DNS             1.14.8   1.14.8

內容解密：

此表格顯示了需要手動升級的元件及其目前版本和可用版本。管理員需要根據表格中的資訊，手動升級這些元件，以確保叢集的正常執行。

Kubernetes 升級與使用者管理

升級 Kubernetes 叢集

在決定升級策略後，按照 kubeadm 指定的順序執行升級。如果有多個版本需要升級，按照每個節點的順序進行升級。

root@control1:~# kubeadm upgrade apply v1.10.4

執行升級時，會進行預檢檢查，主要確保叢集仍然健康，並備份靜態 Pod 清單，然後進行升級。

內容解密：

  • kubeadm upgrade apply v1.10.4：此指令用於將 Kubernetes 叢集升級至指定版本（v1.10.4）。
  • 預檢檢查確保叢集狀態正常，避免升級過程中出現問題。
  • 備份靜態 Pod 清單，以防止升級失敗時能夠還原。

升級順序非常重要，需要先升級控制平面節點，然後再升級工作節點。控制平面節點應先從負載平衡器中移除，升級完成後再重新註冊，以確保客戶端體驗的一致性。

內容解密：

  • 控制平面節點升級順序至關重要，因為它們負責管理整個叢集。
  • 工作節點可以在控制平面節點升級完成後平行或滾動升級，以確保服務的連續性。

使用者管理與身份驗證

Kubernetes 的使用者管理是確保叢集安全性的基礎。使用者透過 Kubernetes API 進行身份驗證和授權，進而存取叢集資源。

Kubernetes API 請求流程

每一個到達 API 伺服器的請求都需要透過一系列挑戰，包括身份驗證、存取控制和准入控制，如圖 7-1 所示。

此圖示說明瞭 Kubernetes API 請求的處理流程，包括身份驗證、授權和准入控制三個主要階段。

內容解密：

  • 身份驗證階段確定請求者的身份。
  • 存取控制階段根據使用者的角色決定是否允許請求。
  • 准入控制階段檢查請求是否符合叢集的組態和策略。

使用者與身份驗證機制

Kubernetes 中的使用者並不是一個頂級資源，而是通常在外部身份管理系統中定義。這樣可以保持使用者管理的一致性和安全性。

Kubernetes 支援多種身份驗證機制，包括基本身份驗證、X.509 使用者端憑證和 Bearer token。

身份驗證策略

  1. 基本身份驗證：使用使用者名稱和密碼進行身份驗證。
  2. X.509 使用者端憑證：使用 SSL/TLS 憑證進行身份驗證。
  3. Bearer token：使用 token 進行身份驗證，通常與外部身份提供者整合。

內容解密：

  • 每種身份驗證機制都有其優缺點和適用場景。
  • Kubernetes 的靈活性允許管理員根據需求選擇合適的身份驗證策略。
內容解密：
  • 正確的升級和安全管理是 Kubernetes 叢集維運的關鍵。
  • 選擇合適的身份驗證機制對於確保叢集安全至關重要。

Kubernetes 驗證機制詳解

Kubernetes 提供了多種驗證機制來確保叢集的安全性與存取控制。以下將探討三種主要的驗證方式：Basic Authentication、X.509 使用者端憑證以及 OpenID Connect。

基本驗證（Basic Authentication）

基本驗證是一種簡單的驗證機制，客戶端（如 kubectl）會將使用者名稱和密碼組合成為一個 base64 編碼的字串，並將其置於 HTTP 的 Authorization 標頭中。由於 base64 僅是一種編碼方式而非加密，因此必須與 HTTPS 搭配使用以確保安全性。

設定基本驗證

  1. 建立一個靜態檔案，內容包含使用者名稱、密碼、使用者 ID 以及所屬群組，格式如下：
    password,username,uid,"group1,group2,group3"
  2. 將此檔案路徑傳遞給 Kubernetes API 伺服器的 --basic-auth-file 引數。

基本驗證的限制

  • API 伺服器不會監控此檔案的變更，因此在使用者資訊變更後需要重新啟動 API 伺服器。
  • 不建議在生產環境中使用，因為手動管理使用者資訊較為繁瑣。

X.509 使用者端憑證

X.509 使用者端憑證是一種更安全的驗證方式，許多 Kubernetes 安裝工具預設啟用此機制。它不僅能驗證使用者身份，也能確保服務間的通訊加密。

使用 cfssl 建立使用者端憑證

  1. 建立一個 CSR（Certificate Signing Request）檔案，指定使用者名稱和所屬群組：
    {
  "CN": "joesmith",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Boston",
      "O": "qa",
      "O": "infrastructure",
      "OU": "Acme Sprockets Company",
      "ST": "MA"
    }
  ]
}
  2. 使用 cfssl 工具產生憑證：
    cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  joesmith-csr.json | cfssljson -bare admin

啟用 X.509 使用者端憑證驗證

在 API 伺服器上指定 --client-ca-file 引數，指向 CA 憑證檔案。

OpenID Connect（OIDC）

OIDC 是根據 OAuth 2.0 的驗證層，使用者先與信任的身分提供者進行驗證，然後取得一個或多個 token。這些 token 以 JSON Web Token（JWT）格式表示，包含使用者宣告（如使用者名稱、ID 和所屬群組）。

JWT Token 示例

{
  "iss": "https://example.com",
  "aud": "kubernetes",
  "sub": "joesmith",
  "username": "joesmith",
  "groups": ["qa", "infrastructure"],
  "exp": 1643723900
}

OIDC 的優點

  • 提供更靈活的驗證機制。
  • 適合使用者數量較多或需要與外部身分提供者整合的場景。
此圖示
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title OIDC 的優點

rectangle "驗證請求" as node1
rectangle "支援多種驗證機制" as node2
rectangle "簡單但不安全" as node3
rectangle "安全但管理複雜" as node4
rectangle "靈活且安全" as node5

node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5

@enduml
小段落標題

在選擇 Kubernetes 驗證機制時，應根據實際需求和安全性要求進行評估和選擇。