Kubernetes 安全與服務網格最佳實踐

– 11 分鐘閱讀

Kubernetes 作為容器協調的事實標準，其安全性與高效能的服務網格至關重要。本文探討如何利用 Pod Security Admission、AppArmor 和 Seccomp 等機制強化 Pod 安全性，並詳細說明 RBAC 和 ABAC 等授權機制的組態與管理。同時，也將探討 Istio 服務網格的應用，涵蓋 Gateway 資源組態及流量管理等導向，以提升微服務架構的安全性與可觀察性。此外，本文也將探討 Kubernetes 的最佳實踐，例如使用宣告式組態管理資源、利用名稱空間組織資源、實施最小許可權原則以及使用資源配額和限制等，以確保叢集的穩定性和資源利用效率。最後，將結合健康檢查、映像檔管理和多階段建構等實務案例，提供更全面的 Kubernetes 管理和應用。

第11章：Kubernetes 安全與服務網格

本章將探討 Kubernetes 的安全機制與服務網格的相關技術，包括 Pod Security Admission、AppArmor、Seccomp、授權機制以及 Istio 服務網格的組態與應用。

11.2 建立原生 Sidecar 容器

問題描述

在 Kubernetes 中，Sidecar 容器是一種常見的設計模式，用於為主要容器提供額外的功能，如日誌收集、網路代理等。然而，原生的 Sidecar 容器支援在某些版本中可能未被完全啟用。

解決方案

要在 Kubernetes 中建立原生 Sidecar 容器，首先需要確保 Kubernetes 版本支援該功能。然後，可以透過在 Pod 定義中適當組態 Sidecar 容器來實作。

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: main-container
    image: main-image
    ports:
    - containerPort: 80
  - name: sidecar-container
    image: sidecar-image
    ports:
    - containerPort: 8080

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的型別。
  • metadata 部分包含了 Pod 的名稱。
  • spec 部分定義了 Pod 中的容器列表。
  • containers 下定義了兩個容器：main-container 和 sidecar-container，每個容器都有其特定的映像和埠組態。

11.3 組態名稱空間的 Pod Security Admission

問題描述

Pod Security Admission 是 Kubernetes 的一個安全特性，用於控制 Pod 的安全組態。如何在名稱空間級別組態 Pod Security Admission 成為了一個重要的問題。

解決方案

可以透過在名稱空間上應用特定的標籤來啟用或組態 Pod Security Admission。

kubectl label namespace my-namespace pod-security.kubernetes.io/enforce=baseline

內容解密：

  • kubectl label 命令用於為 Kubernetes 資源新增或更新標籤。
  • namespace my-namespace 指定了要操作的名稱空間。
  • pod-security.kubernetes.io/enforce=baseline 標籤啟用了 Pod Security Admission 的強制執行級別為 baseline。

11.6 授權機制（API 存取控制、X.509 證書、JSON Web Tokens、屬性基礎存取控制、角色基礎存取控制和 OpenID 身份提供者聯合）

問題描述

Kubernetes 中的授權機制是確保叢集安全的關鍵。如何有效地組態和管理這些機制是一個重要的問題。

解決方案

Kubernetes 支援多種授權機制，包括根據角色的存取控制（RBAC）、屬性基礎存取控制（ABAC）等。可以根據具體需求選擇和組態適當的授權機制。

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

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的型別為 RBAC 的 Role。
  • metadata 部分包含了 Role 的名稱。
  • rules 部分定義了 Role 的許可權規則，包括允許的操作（verbs）和資源（resources）。

11.8 為什麼選擇 Istio 服務網格

問題描述

在微服務架構中，服務網格成為了管理和監控服務間通訊的重要工具。Istio 是目前流行的服務網格解決方案之一。

解決方案

Istio 提供了一系列功能，如流量管理、安全性和可觀察性，可以有效地管理和監控微服務之間的通訊。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: example-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - '*'

內容解密：

  • apiVersion 和 kind 定義了 Istio 的 Gateway 資源型別。
  • metadata 部分包含了 Gateway 的名稱。
  • spec 部分定義了 Gateway 的組態，包括選擇器（selector）和伺服器（servers）組態。

Kubernetes 最佳實踐：宣告式組態與資源管理

使用宣告式組態

問題描述

在 Kubernetes 中，手動管理資源組態容易導致錯誤和不一致性。開發人員和維運團隊需要一種方法來確保組態的一致性和可重複性。

解決方案

使用宣告式組態（Declarative Configuration）來管理 Kubernetes 資源。宣告式組態允許使用者定義所需的最終狀態，而 Kubernetes 系統負責達成該狀態。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example-container
        image: nginx:latest
        ports:
        - containerPort: 80

內容解密：

  1. apiVersion 和 kind 定義了資源的 API 版本和型別。
  2. metadata 提供了資源的中繼資料，如名稱。
  3. spec 描述了資源的期望狀態，包括副本數量和容器組態。
  4. replicas: 3 指定了 Deployment 應維持的副本數量。
  5. selector 和 template 定義瞭如何選擇和建立 Pod。

結果

使用宣告式組態可以提高組態的一致性和可重複性，簡化了資源管理。

使用名稱空間組織資源

問題描述

在大型叢集中，資源管理變得複雜，需要一種方法來組織和隔離資源。

解決方案

使用 Kubernetes 的名稱空間（Namespaces）來組織資源。名稱空間提供了一種將叢集資源劃分為多個邏輯分割槽的方法。

kubectl create namespace development
kubectl create namespace production

內容解密：

  1. kubectl create namespace 命令用於建立新的名稱空間。
  2. development 和 production 是兩個不同的名稱空間，用於隔離不同環境的資源。

結果

使用名稱空間可以提高資源管理的效率和安全性，方便不同團隊或專案的資源隔離。

安全增強

實施最小許可權原則

問題描述

過度的許可權可能導致安全風險，需要一種方法來限制使用者和服務帳戶的許可權。

解決方案

實施最小許可權原則（Principle of Least Privilege），為使用者和服務帳戶分配最少的必要許可權。

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

內容解密：

  1. apiVersion 和 kind 定義了 RBAC Role 的 API 版本和型別。
  2. metadata 提供了 Role 的中繼資料，如名稱。
  3. rules 定義了 Role 的許可權規則，包括可存取的資源和可執行的操作。

資源最佳化

使用資源配額和限制

問題描述

無限制的資源使用可能導致叢集資源耗盡，需要一種方法來管理和限制資源使用。

解決方案

使用資源配額（Resource Quotas）和限制（Limits）來管理和限制名稱空間中的資源使用。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota
spec:
  hard:
    cpu: "4"
    memory: "8Gi"

內容解密：

  1. apiVersion 和 kind 定義了 ResourceQuota 的 API 版本和型別。
  2. metadata 提供了 ResourceQuota 的中繼資料，如名稱。
  3. spec.hard 定義了資源的硬性限制，包括 CPU 和記憶體的使用量。

Kubernetes 管理與最佳實踐

13.4 高效能的映像檔管理

在現代化的軟體開發與佈署流程中，容器技術已經成為不可或缺的一部分。Kubernetes 作為容器協調的佼佼者，其高效運作與映像檔管理息息相關。高效的映像檔管理不僅能夠提升佈署速度，還能有效減少資源浪費。

13.4.2 高效映像檔管理

為了實作高效的映像檔管理，我們需要關注以下幾個關鍵點：

  1. 最小化映像檔大小：較小的映像檔能夠減少儲存需求，加快下載與佈署速度。要實作這一點，可以透過選擇適當的基礎映像檔、移除不必要的檔案和使用多階段建構來達成。

    # 使用多階段建構減少映像檔大小
FROM golang:alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:latest  
RUN apk add --no-cache ca-certificates
WORKDIR /root/
COPY --from=builder /app/main .
CMD ["./main"]

    內容解密：

    • 這段 Dockerfile 使用多階段建構來編譯 Go 程式。首先，使用 golang:alpine 作為編譯環境，將原始碼複製到容器中並編譯。
    • 然後，使用 alpine:latest 作為執行環境，將編譯好的二進位制檔案複製到新的環境中。
    • 這種做法能夠有效減少最終映像檔的大小，因為它避免了將整個 Go 編譯環境包含在最終的映像檔中。

  2. 使用私有映像檔倉函式庫：對於企業級應用，使用私有映像檔倉函式庫能夠提高安全性和存取控制。常見的私有倉函式庫解決方案包括 Harbor 和 Artifactory。

  3. 自動化映像檔建構與更新：透過 CI/CD 流程自動建構和更新映像檔，可以確保應用程式始終執行在最新的程式碼和依賴函式庫上。

13.5 維運卓越

在 Kubernetes 環境中，維運卓越是確保系統穩定性和可靠性的關鍵。

13.5.1 健康檢查的實施

健康檢查是監控應用程式健康狀態的重要手段。Kubernetes 提供了兩種健康檢查機制：liveness probe 和 readiness probe。

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

內容解密：

  • livenessProbe 用於檢查容器是否執行正常。如果探針失敗，Kubernetes 將重啟容器。
  • httpGet 指定了探針使用的 HTTP 請求路徑和埠號。
  • initialDelaySeconds 設定了第一次探測前的等待時間，避免在容器啟動初期誤判。
  • periodSeconds 設定了探針執行的頻率。

圖表翻譯：Kubernetes 健康檢查流程圖

@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

圖表翻譯： 此圖示展示了 Kubernetes 中容器的健康檢查流程。當容器啟動後，Kubernetes 會進行 livenessProbe 和 readinessProbe。如果 livenessProbe 失敗，容器將被重啟；如果 readinessProbe 失敗，容器將被標記為未就緒，不會接收流量。

Kubernetes 實戰：容器協調的最佳實踐

前言

Kubernetes 已成為容器協調的事實標準，提供了一個強大、可擴充套件且具彈性的平台，用於佈署和管理容器化應用程式。隨著雲原生技術的不斷演進，掌握 Kubernetes 對於開發人員、系統管理員、DevOps 專業人員以及任何參與現代應用程式佈署的人員來說至關重要。

本文目標與物件

本文旨在為讀者提供一個實用的問題解決，針對 Kubernetes 環境中的常見及進階挑戰提供即時、可行的解決方案。無論您是首次設定 Kubernetes、管理複雜的工作負載，還是最佳化效能和安全，本文都提供了一個結構化、易於遵循的方法，並附有真實世界的範例和最佳實踐。

本文適合開發人員、系統管理員、DevOps 工程師和 IT 專業人員，希望提升他們在 Kubernetes 方面的技能。讀者應具備 Linux 和容器概念的基本理解，但不需具備 Kubernetes 的豐富經驗。本文同時滿足初學者對基礎知識的需求和經驗豐富的使用者對進階技術的追求。

作者介紹

Grzegorz Stencel

Grzegorz Stencel 是一位多才多藝的技術專家和 JPMorgan Chase 的資深工程師，持有兩項專利。Greg 設計和開發新的系統、產品和功能，同時提供技術指導和培訓。他的經驗涵蓋了諸如愛立信、ING 和牛津大學出版社等知名組織，在網路、網路安全和程式設計方面擁有豐富的專業知識。作為一名電子愛好者，Greg 為家庭自動化和警示系統設計 PCB，並探索與 AI 結合的機器人技術，使用 Jetson Nano。擁有 17 年的 Linux 管理經驗，Greg 還持有 Certified Kubernetes Application Developer (CKAD) 證書。他曾使用筆記型電腦主機板搭建 Kubernetes 叢集，透過教學和長官力為雲端社群做出貢獻。

Luca Berton

Luca Berton 是一位 IT 基礎設施專家，曾在 JPMorgan Chase & Co. 工作兩年，並在 Red Hat 工作三年。Luca 是《Ansible for VMware by Examples》和《Ansible for Kubernetes by Example》的作者，也是 Ansible Pilot 專案的創始人。擁有超過 18 年的 IT 行業經驗，Luca 專攻基礎設施硬化和自動化。作為一名開源愛好者，他透過在公開活動中分享知識來積極支援社群。

Nikhil Kumar

Nikhil Kumar 是 HPE 的資深軟體工程師，專攻 Kubernetes、AI、DevOps 和 MLOps。憑藉跨足開發、架構和諮詢的多樣技能，Nikhil 為眾多客戶和組織在不同領域做出了重大貢獻。他的專業知識包括設計可擴充套件的 Kubernetes 架構、實施 AI 驅動的 DevOps 管道，以及推進 MLOps 實踐以簡化機器學習工作流程。Nikhil 是該領域的公認權威，持有諸如 Red Hat Certified Engineer (EX294) 和 Red Hat Certified OpenShift Administrator (EX280) 等知名認證。作為知識分享的熱心倡導者，他透過技術部落格、YouTube 教學影片以及擔任 Kubernetes、DevOps、Cloud 和 MLOps 相關書籍的技術審閱者來積極貢獻軟體工程社群。

致謝

撰寫一本文絕非一人之力，《Kubernetes Recipes》也不例外。本文是多年經驗、合作以及來自許多個人和社群支援的成果。我們要對所有為本文做出貢獻的人表示衷心的感謝。

首先，我們要深深感謝我們的家人和親人，在整個旅程中給予我們的耐心、鼓勵和堅定支援。在漫漫長夜、無盡的研究和無數的寫作時間裡，你們的理解是無價的。

我們要感謝 Kubernetes、雲原生和 DevOps 社群中的導師、同事和朋友，他們的專業知識和見解幫助塑造了我們的知識和觀點。開源社群一直是我們的靈感來源，我們感謝所有繼續推動 Kubernetes 向前的貢獻者、維護者和開發者。

特別感謝 Kubernetes 和 CNCF（雲原生計算基金會）社群，他們的貢獻使 Kubernetes 成為今天這樣強大、靈活的平台。如果沒有全球開發者、工程師和倡導者的共同努力，Kubernetes 不會取得今天的成就。

我們還要感謝 Apress 的編輯和出版團隊，在整個寫作過程中給予我們的指導、回饋和耐心。你們的見解幫助我們完善了自己的想法，並使本文變得易於閱讀和實用。

對於我們的讀者，我們感謝您選擇了本文。我們希望《Kubernetes Recipes》能夠成為您旅途中的寶貴資源。無論您是剛剛開始還是尋找快速解決方案的經驗豐富的專業人士，我們都感謝您信任我們作為您的指引。

最後，我們要感謝我們的專業網路，包括 JPMorgan Chase、Dell Technologies、Red Hat 以及多年來與我們合作的各個組織的工作夥伴。你們的討論、挑戰和真實世界的場景為本文的內容提供了寶貴的見解。

撰寫這本文是一種榮幸，我們希望它能夠為全球的 Kubernetes 從業人員提供實用、真實世界的解決方案。 —Grzegorz Stencel 和 Luca Berton

本文架構

本文分為多個章節，每章節針對 Kubernetes 中的特定主題或挑戰，提供詳細的解決方案和最佳實踐。第14章節涵蓋了 KubeTrain 和 Kubernetes Efficient Power Level Exporter (Kepler) 等主題，以下是這些章節的詳細內容：

KubeTrain

  • 問題：介紹了使用 KubeTrain 的背景和挑戰。
  • 解決方案：提供瞭如何實施 KubeTrain 的詳細步驟。
  • 討論：探討了 KubeTrain 的技術細節和使用場景。
  • 參見：提供了進一步閱讀和相關資源。

Kubernetes Efficient Power Level Exporter (Kepler)

  • 問題：闡述了在 Kubernetes 環境中監控能耗的重要性。
  • 解決方案：展示瞭如何使用 Kepler 來匯出 Kubernetes 叢集的能耗資料。
  • 討論：分析了 Kepler 的工作原理及其在最佳化能耗方面的潛力。
  • 參見：給出了相關檔案和進一步研究的資源。
玄貓 BlackCat

玄貓 BlackCat

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