Kubernetes 利用 Terraform 有效叢集資源管理

– 12 分鐘閱讀

在 Kubernetes 環境中，有效管理佈署的組態、註解和網路策略至關重要。本文將探討如何使用 Terraform 簡化這些操作，並分享我在實務中的一些心得和技巧。

動態調整 Kubernetes 佈署組態

調整 Kubernetes 佈署的組態常常需要修改容器映像版本、副本數量或環境變數。Terraform 提供了一個優雅的解決方案，允許我們使用變數來管理這些動態組態。以下是一個使用 Terraform 管理 Kubernetes 佈署的示例：

variable "replica_count" {
  type = number
  default = 5
  description = "佈署的副本數量"
}

variable "image_version" {
  type = string
  default = "v2"
  description = "要使用的映像版本"
}

provider "kubernetes" {
  #  組態你的 Kubernetes 提供者
}

resource "kubernetes_deployment" "example" {
  metadata {
    name = "my-app"
  }

  spec {
    replicas = var.replica_count

    selector {
      match_labels = {
        app = "my-app"
      }
    }

    template {
      metadata {
        labels = {
          app = "my-app"
        }
      }

      spec {
        container {
          name  = "my-app"
          image = "my-image:${var.image_version}"

          env {
            name  = "ENV_VAR_NAME"
            value = "new-value"
          }

          port {
            container_port = 8080
          }
        }
      }
    }
  }
}

這段程式碼定義了一個 Kubernetes 佈署，並使用 replica_count 和 image_version 變數來控制副本數量和容器映像版本。provider "kubernetes" 區塊用於驗證 Kubernetes 叢集，而 resource "kubernetes_deployment" 區塊則定義了佈署的規格，包括選擇器、Pod 範本和容器規格。透過使用變數，我們可以輕鬆地修改佈署組態，而無需更改核心資源定義。

  graph LR
    subgraph Terraform[Terraform Configuration]
        A[Variables] --> B(Deployment Resource);
    end
    B --> C[Kubernetes Cluster];

圖表説明：此圖表展示了 Terraform 如何透過變數控制佈署資源，並將其應用到 Kubernetes 叢集。

Kubernetes 佈署註解的巧妙運用

註解允許我們將任意中繼資料附加到佈署中，例如建置資訊、日誌記錄組態等。

resource "kubernetes_deployment" "example" {
  # ...其他組態

  metadata {
    annotations = {
      "build_info" = "commit-hash: abcdef123, release-version: v1.0"
      "monitoring_config" = "enabled: true, interval: 30s"
    }
  }

  # ...其他組態
}

這段程式碼展示瞭如何在佈署中增加註解。annotations 引數是一個字串對映，其中每個鍵值對代表一個註解。要更新註解，只需更改 annotations 引數中相應鍵的值即可。需要注意的是，註解不同於標籤，標籤用於選擇和分組物件，而註解不用於識別。

實施 Kubernetes 網路策略強化安全性

Kubernetes 網路策略定義了 Pod 組之間以及與其他網路端點之間的通訊方式。

resource "kubernetes_network_policy" "example" {
  # ... (策略設定，參考前文範例)
}

此程式碼（參考前文完整範例）定義了一個網路策略，控制 Pod 之間的網路流量。網路策略是累加的，任何策略允許的連線都會被允許。

  graph LR
    A[Frontend Pods] -->|允許| B(Database Pods);
    B -->|拒絕| C[External Network];

圖表説明：此圖表簡化説明瞭網路策略如何允許 Frontend Pods 存取 Database Pods，同時拒絕 Database Pods 存取外部網路。

Helm 與 Terraform 的整合

在 Kubernetes 環境中，Helm 和 Terraform 的結合可以大幅提升佈署效率。

provider "helm" {
  kubernetes {
    # Kubernetes 提供者設定
  }
}

resource "helm_release" "example" {
    # ... (Helm release 設定，參考前文範例)
}

這段程式碼（參考前文完整範例）示範瞭如何使用 Terraform 的 Helm provider 來管理 Helm releases。我個人在實踐中發現，結合 Helm 和 Terraform 可以更有效地管理 Kubernetes 應用程式的生命週期。

透過有效地利用 Terraform 管理 Kubernetes 佈署的組態、註解和網路策略，我們可以提高效率、增強安全性和簡化操作流程。持續學習和實踐，才能在 Kubernetes 的世界中游刃有餘。

在 HashiCorp Nomad 上排程容器

HashiCorp Nomad 是一款靈活的工作負載協調器，支援佈署微服務、批次處理、容器化和非容器化應用程式的混合環境。以下是如何使用 Terraform 在 Nomad 叢集上佈署執行 Redis 的 Docker 容器：

provider "nomad" {
  address = "http://localhost:4646"
}

resource "nomad_job" "redis" {
  jobspec = file("${path.module}/redis.nomad")
}

redis.nomad 檔案內容如下：

job "redis" {
  datacenters = ["dc1"]
  group "cache" {
    task "redis" {
      driver = "docker"
      config {
        image = "redis:latest"
        port_map {
          db = 6379
        }
      }
      resources {
        cpu    = 500 # 500 MHz
        memory = 256 # 256MB
        network {
          mbits = 10
          port "db" {}
        }
      }
      service {
        name = "redis"
        port = "db"
        check {
          type     = "tcp"
          interval = "10s"
          timeout  = "2s"
        }
      }
    }
  }
}

這個方案利用 nomad_job 資源佈署執行 Docker 容器的 Nomad 作業。provider "nomad" 區塊設定 Nomad 提供者，並指定 Nomad 伺服器的地址。resource "nomad_job" "redis" 區塊定義名為 “redis” 的 Nomad 作業，並使用 file 函式從外部檔案 (redis.nomad) 讀取作業規格。redis.nomad 檔案包含 Nomad 作業規格，定義作業名稱、資料中心、任務組和任務。任務使用 Docker 驅動程式，組態映像檔、埠對映、資源需求和服務發現。

我認為，Nomad 的彈性和資源使用效率使其成為 Kubernetes 的有力競爭者。透過 Terraform 管理 Nomad 作業，更能將基礎架構程式碼化，提升管理效率。

  graph LR
    subgraph Nomad Client
        A[Docker Container - Redis]
    end
    A --> B(Nomad Server);
    C[Terraform] --> B;

此圖表展示了 Terraform、Nomad Server 和 Nomad Client 之間的關係。Terraform 用於佈署和管理 Nomad 作業，Nomad Server 負責排程作業到 Nomad Client，Nomad Client 則執行 Docker 容器。

HCP Terraform 設定

HCP Terraform 提供集中式工作區，方便團隊協作基礎架構專案，並提供安全的狀態管理、版本控制整合和自動化執行計劃。

設定 HCP Terraform 步驟如下：

  1. 建立 HCP Terraform 帳戶。
  2. 建立組織。
  3. 建立新的工作區，選擇版本控制工作流程，並連線 VCS 提供者。
  4. 組態工作區設定，例如 Terraform 工作目錄和環境變數。
  5. 排隊一個計劃並檢閲輸出。
  6. 套用變更以佈建基礎架構。

設定 HCP Terraform 是運用其管理 IaC 潛力的關鍵步驟。建立帳戶後，即可存取使用者友善的儀錶板，用於管理工作區、組態和 Terraform 狀態。建立連結到 VCS 儲存函式庫的工作區至關重要，因為它能啟用由程式碼變更觸發的自動化流程。HCP Terraform 也簡化了機密管理，提升安全性。

HCP Terraform 與版本控制整合

將 HCP Terraform 與版本控制系統（例如 GitHub）整合，對於 IaC 實踐至關重要。

整合步驟：

  1. 設定 HCP Terraform 後端：
terraform {
  cloud {
    organization = "<您的組織名稱>"
    workspaces {
      name = "<您的工作區名稱>"
    }
  }
}

這段程式碼將 HCP Terraform 設定為遠端後端，指定組織名稱和工作區名稱，讓 Terraform 將狀態檔案儲存在 HCP Terraform 中，實作集中式狀態管理。

  1. 在 HCP Terraform UI 中設定版本控制，選擇 VCS 提供者，並驗證授權。
  2. 選擇包含 Terraform 組態的儲存函式庫。
  3. 組態其他設定，例如分支和子目錄。
  flowchart LR
    A[VCS Repository] --> B[HCP Terraform]
    B --> C[Terraform State]
    D[Terraform CLI] --> B

此圖表説明瞭 VCS 儲存函式庫、HCP Terraform 和 Terraform CLI 之間的關係。VCS 儲存函式庫儲存 Terraform 組態，HCP Terraform 儲存狀態檔案，Terraform CLI 與 HCP Terraform 互動來管理基礎架構。

我發現，這種整合能大幅提升團隊協作效率，並確保基礎架構組態的一致性。透過自動化流程，更能降低人為錯誤的風險。

import "tfplan"

# 檢查所有 AWS EC2 執行個體是否已啟用加密
main = rule {
  all tfplan.resource_changes as _, rc {
    rc.change.after is object and
    rc.change.after.type is "aws_instance" and
    rc.change.after.ebs_block_device is list and
    all rc.change.after.ebs_block_device as _, block_device {
      block_device.encrypted is true
    }
  }
}

這段 Sentinel 程式碼定義了一個規則，用於檢查所有 AWS EC2 執行個體是否已啟用 EBS 磁碟區加密。它會遍歷 Terraform 計劃中的所有資源變更，檢查每個 aws_instance 資源的 ebs_block_device 設定，確保 encrypted 屬性設定為 true。

這個範例展示瞭如何使用 Sentinel 來強制執行特定的安全策略。您可以根據組織的需求，建立各種 Sentinel 政策，例如：

  • 合規性檢查： 確保所有資源都符合相關法規和標準。
  • 安全性最佳實務： 強制執行安全組態，例如加密和存取控制。
  • 成本控制： 限制特定資源型別的使用或設定預算警示。
  • 命名慣例： 確保資源名稱符合組織的標準。

透過 Sentinel，您可以將政策嵌入到您的基礎設施即程式碼工作流程中，實作自動化的政策執行，並減少合規性和安全風險。

  graph LR
    C[C]
A[程式碼變更] --> B(Terraform Plan)
B --> C{Sentinel 政策檢查}
C -- 透過 --> D[Terraform Apply]
C -- 不透過 --> E[警示/阻止]

此流程圖説明瞭 Sentinel 如何與 Terraform 工作流程整合。當發生程式碼變更時，Terraform 會產生執行計劃。Sentinel 會檢查該計劃是否符合定義的政策。如果符合，則允許 Terraform 應用變更；如果不符合，則會發出警示或阻止變更。

Sentinel 政策管理的最佳實務

為了有效地管理 Sentinel 政策，我建議以下實務：

  • 版本控制： 將 Sentinel 政策儲存在版本控制系統中，以便追蹤變更和進行協作。
  • 模組化設計： 將政策分解成可重複使用的模組，提高可維護性和可讀性。
  • 測試： 使用 sentinel test 命令測試政策，確保其按預期工作。
  • 檔案： 為每個政策提供清晰的檔案，説明其目的和使用方法。
  • 審查： 定期審查和更新政策，以反映組織需求的變化。

透過結合 HCP Terraform、GitHub Actions 和 Sentinel，您可以建立一個強大的自動化平台，實作基礎設施即程式碼的最佳實務，並確保基礎設施的安全性和合規性。 我發現，這種方法可以顯著提高團隊的效率，並減少人為錯誤的風險。

在雲端原生時代，基礎設施即程式碼（IaC）已成為不可或缺的實踐。Terraform 作為 IaC 的翹楚，賦予我們以程式碼定義、佈署和管理基礎設施的能力。然而，隨著基礎設施規模的擴充套件，管理大量的 Terraform 佈署也帶來了新的挑戰。HCP Terraform 提供了遠端操作和進階狀態管理功能，有效地化解了這些難題。本文將探討如何利用這些功能簡化大規模佈署和狀態管理，並分享在 Terraform 中安全處理機密資料的最佳實踐。

HCP Terraform：遠端操作與進階狀態管理

遠端操作：輕鬆應對大規模佈署

管理大規模佈署時，效能、資源限制和操作複雜性是我們常常面臨的挑戰。本地機器的資源有限、執行時間冗長、缺乏集中式日誌記錄和狀態管理等問題都會影響佈署效率。HCP Terraform 的遠端操作功能，將 Terraform 的執行轉移到 HashiCorp 的基礎設施上，完美地解決了這些問題。我發現這種方式能大幅提升佈署效率，尤其在處理大規模基礎設施時，效果更加顯著。

以下是一個組態範例，展示如何在 HCP Terraform 中設定和使用遠端操作：

terraform {
  cloud {
    organization = "your-organization"
    workspaces {
      name = "large-scale-deployment"
    }
  }
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name        = "Large Scale VPC"
    Environment = "Production"
  }
}

module "ec2_cluster" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "~> 3.0"
  for_each = toset(["1", "2", "3", "4", "5"])
  name    = "instance-${each.key}"
  # ... 其他 EC2 執行個體設定 ...
}

這段程式碼展示瞭如何在 HCP Terraform 中設定遠端操作和使用模組進行佈署。terraform 區塊設定了 HCP 的組織和 workspace 名稱。aws_vpc 資源建立了一個 VPC。ec2_cluster 模組則用於建立多個 EC2 執行個體，並使用 for_each 進行迭代，有效簡化了程式碼。

  graph LR
    C[C]
    A[HCP Terraform Workspace] --> B(遠端執行)
    B --> C{AWS 資源}
    C --> D[VPC]
    C --> E[EC2 執行個體]

此圖表展示了 HCP Terraform、遠端執行和 AWS 資源之間的關係。HCP Terraform Workspace 透過遠端執行在 AWS 上建立資源。

遠端操作的優勢包括：可擴充性、集中式狀態管理、協作、版本控制整合、策略執行、可見性和稽核以及平行操作。

進階狀態管理和復原：確保基礎設施一致性

管理狀態檔案在基礎設施規模和複雜性增長的情況下變得越來越具有挑戰性。狀態鎖定衝突、狀態漂移以及在意外修改或刪除後需要狀態復原等問題時有發生。HCP Terraform 提供了進階狀態管理和復原功能，可有效處理這些複雜的狀態相關場景。

terraform {
  cloud {
    organization = "your-organization"
    workspaces {
      name = "advanced-state-management"
    }
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
  acl    = "private"
  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

這段程式碼展示瞭如何使用 HCP Terraform 作為後端。aws_s3_bucket 資源建立了一個 S3 bucket。

HCP Terraform 中的進階狀態管理提供了狀態鎖定、狀態歷史記錄和版本控制、狀態復原等優勢。使用這些功能時，請務必使用 HCP Terraform 提供的自動化和內建機制，謹慎使用手動狀態操作。

Terraform 機密資料管理：安全與便捷的平衡

在 IaC 領域中，妥善管理機密資料對於維護系統安全至關重要。API 金鑰、資料函式庫密碼等敏感資訊都需要謹慎處理，才能防止未經授權的存取和潛在的入侵。Terraform 提供了多種機制，讓您在佈署基礎設施時，安全地使用和管理機密資料。

以下列出幾種常見的機密資料管理方式：

  • 加密後端: 將狀態檔案加密儲存，保護敏感資訊。
  • 外部機密管理系統: 整合 HashiCorp Vault 等工具，集中管理和存取機密資料。
  • 安全的輸入變數: 使用 -var-file 或環境變數，避免將機密資料直接寫入程式碼。
  graph LR
    A[Terraform] --> B(加密後端)
    A --> C(外部機密管理系統)
    A --> D(安全的輸入變數)

此圖表展示了 Terraform 與三種機密資料管理方式的關係。

透過妥善管理機密資料，並結合 HCP Terraform 的遠端操作和進階狀態管理功能，我們可以更有效地管理大規模佈署，確保在複雜環境中提供一致、安全與經濟高效的基礎設施。

  graph LR
    C[C]
    A[Terraform] --> B(Vault);
    B --> C{Kubernetes Secret};
    C --> D[Kubernetes Pod];

圖表説明： 此圖表描繪了 Terraform、Vault 和 Kubernetes 之間的互動。Terraform 用於設定和管理基礎架構，包括 Vault 和 Kubernetes。Vault 作為安全的 Secret 儲存函式庫，而 Kubernetes Pod 則使用這些 Secret。

以下程式碼範例展示瞭如何使用 Terraform、Vault 和 Kubernetes Secret Provider 來管理 Kubernetes Secret：

# 設定 Kubernetes Provider
provider "kubernetes" {
  config_path = "~/.kube/config"
}

# 設定 Vault Provider
provider "vault" {
  address = "https://vault.example.com"
}

# 從 Vault 讀取 Secret
data "vault_generic_secret" "db_password" {
  path = "secret/data/database/password"
}

# 建立 Kubernetes Secret
resource "kubernetes_secret" "example" {
  metadata {
    name      = "example-secret"
    namespace = "default"
    annotations = {
      "vault.hashicorp.com/agent-inject": "true"
      "vault.hashicorp.com/agent-inject-secret-database-password": "database/password"
      "vault.hashicorp.com/role": "myapp" # Vault Role
    }
  }
  type = "Opaque"
}


# 在 Pod 中使用 Secret
resource "kubernetes_pod" "example" {
  metadata {
    name = "example-pod"
    annotations = {
        "vault.hashicorp.com/agent-inject": "true"
        "vault.hashicorp.com/agent-inject-template-database-password": |
          {{- with secret "database/password" -}}
          {{ .Data.data.password }}
          {{- end -}}
        "vault.hashicorp.com/role": "myapp"
    }
  }
  spec {
    container {
      image = "nginx:latest"
      name  = "example"

      env {
        name = "DATABASE_PASSWORD"
        value_from {
          secret_key_ref {
            key  = "database-password"
            name = "example-secret"
           }
        }
      }
    }
  }
}

此程式碼片段示範瞭如何使用 Terraform、Vault 和 Kubernetes Secret Provider 來管理 Kubernetes Secret。它利用 Vault 作為 Secret 的單一真相來源，並使用 Vault Agent Sidecar Injector 將 Secret 注入 Pod。

此方法的優點包括：

  • 集中式的 Secret 管理：所有 Secret 都儲存在 Vault 中，簡化了管理和稽核。
  • 動態 Secret：Vault 可以產生動態 Secret，提高安全性。
  • 版本控制和稽核：Vault 提供 Secret 的版本控制和稽核功能。
  • 簡化的佈署：Vault Agent Sidecar Injector 自動將 Secret 注入 Pod，無需手動設定。

最佳實務：

  • 使用 Vault 的角色和策略來控制對 Secret 的存取。
  • 定期輪換 Secret。
  • 使用 Vault 的稽核功能來追蹤 Secret 的存取。
  • 確保 Vault 和 Kubernetes 叢集之間的安全通訊。

透過結合 Vault 和 Kubernetes，您可以建立一個強大與安全的 Secret 管理解決方案，以保護您的敏感資料。

在 Kubernetes 環境中，應用程式經常需要存取敏感資料，例如資料函式庫密碼、API 金鑰等。Kubernetes 提供了 Secrets 物件來儲存這些敏感資訊，但如何安全地管理和使用 Secrets 卻是一大挑戰。我認為，妥善的 Secrets 管理策略應兼顧安全性、易用性和可維護性。本文將探討如何使用 HashiCorp Vault、環境變數以及其他密碼管理工具來有效管理 Kubernetes Secrets，並分享一些最佳實務，確保您的機密資訊安全無虞。

使用 HashiCorp Vault 保護 Secrets

HashiCorp Vault 是一款功能強大的 Secrets 管理工具，提供安全的儲存、動態生成和嚴格的存取控制。我發現，將 Vault 與 Kubernetes 整合，可以大幅提升 Secrets 的安全性。

  graph LR
    B[B]
    subgraph Terraform
        A[佈署基礎設施] --> B{設定 Vault 與 Kubernetes}
    end
    B --> C[Vault]
    C --> D[Kubernetes Secrets]
    D --> E[Kubernetes Pods]

圖表説明： 此流程圖展示了 Terraform、Vault 和 Kubernetes 如何協同運作來管理 Kubernetes Secret。Terraform 負責佈署基礎設施，並設定 Vault 和 Kubernetes。Vault 作為安全的 Secret 儲存函式庫，Kubernetes Secrets 則從 Vault 中提取 Secret 並將其注入到 Kubernetes Pods 中。

# 設定 Vault Provider
provider "vault" {
  address = "https://vault.example.com"
}

# 設定 Kubernetes Provider
provider "kubernetes" {
  config_path = "~/.kube/config"
}

# 建立 Vault Kubernetes Auth Backend
resource "vault_kubernetes_auth_backend" "kube_auth" {
  path = "kubernetes"
}

# ... (其他程式碼片段，詳見完整程式碼)

這段 Terraform 程式碼設定了 Vault 和 Kubernetes provider，為後續操作奠定了基礎。address 引數指定了 Vault 伺服器的位址，config_path 引數指定了 Kubernetes 設定檔的路徑。 接著，我們建立了一個 Vault Kubernetes Auth Backend，讓 Kubernetes 可以驗證自身並存取 Vault 中的 Secrets。

透過 Vault，我們可以動態生成 Secrets，避免將靜態 Secrets 儲存在設定檔中。此外，Vault 也提供詳細的稽核日誌，方便追蹤 Secrets 的存取情況。

利用環境變數注入 Secrets

除了 Vault，我們也可以使用環境變數將 Secrets 注入到 Kubernetes Pods 中。雖然這種方法不如 Vault 安全，但在某些場景下仍具有一定的實用性。

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

這段 YAML 程式碼定義了一個 Kubernetes Pod，並透過 secretKeyRef 將 Secret my-secret 中的 password 欄位注入到容器的 DATABASE_PASSWORD 環境變數中。

Kubernetes Secrets 管理最佳實務

除了上述工具和方法，以下是一些 Kubernetes Secrets 管理的最佳實務，我認為這些實務在提升安全性方面至關重要：

  • 最小許可權原則: 僅授予 Pod 必要的 Secrets 存取許可權。
  • 定期輪替 Secrets: 定期更新 Secrets，降低洩漏風險。
  • 使用 Secret 管理工具: 使用 Vault 或其他 Secrets 管理工具，提升安全性。
  • 加密儲存 Secrets: 確保 Secrets 在 etcd 中以加密形式儲存。
  • 監控 Secrets 存取: 監控 Secrets 的存取情況，及時發現異常行為。

透過結合 Vault、環境變數以及最佳實務，我們可以構建一個更安全、更具彈性的 Secrets 管理方案，有效保護敏感資料，並簡化佈署流程。 我相信，一套完善的 Secrets 管理策略是確保 Kubernetes 叢集安全的重要根本。

玄貓

玄貓

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