部署 Oracle Kubernetes 引擎 (OKE) 以進行生產：最佳做法和準則

簡介

這是 Oracle Cloud Infrastructure Kubernetes Engine (OKE) 自動化系列中的第三個教學課程，以第二堂教學課程使用進階 Terraform 模組部署 Oracle Cloud Infrastructure Kubernetes Engine (OKE) 所介紹的概念為基礎。在本指南中，我們專注於可投入生產的 OKE 部署，並探索可提高叢集可靠性、最佳化成本及簡化作業的關鍵最佳實務。我們將使用 Terraform 示範一些最佳實務，同時強調使用者在建置叢集時遇到的常見陷阱。

將 OKE 部署到現有 VCN 的重要性

建立生產級 OKE 叢集需要仔細規劃網路、節點位置和作業流程。部署到現有的虛擬雲端網路 (VCN) 中，可讓您的叢集與預先設定的子網路、路由表和安全規則緊密整合。這可降低營運負荷、確保組織基礎架構的一致性，並讓多個工作負載或叢集在同一個網路中有效率地共存。

部署至現有 VCN 時的主要 Terraform 參數包括：

或者，從頭開始部署全新的環境時，請設定 is_vcn_created = true 以佈建新的網路。成功的 terraform apply 之後，Terraform 會擷取輸出中新建立之 VCN 及其子網路的 OCID。這些值可在未來的部署中重複使用，方法是設定 is_vcn_created = false 並參照您 terraform.tfvars 檔案中儲存的 OCID，讓 Terraform 使用現有的網路，而不是建立新的網路。在此階段執行 terraform plan 確認會保留目前的 VCN 和子網路，避免發生任何不必要的基礎架構變更。

本教學課程奠定了網路基礎，將焦點放在一組以生產為導向的最佳做法，讓 OKE 叢集更具復原能力、可擴展性且更容易操作。透過套用這些實務，客戶可以部署高可用性、符合成本效益且符合組織政策、治理標準和符合生產就緒營運需求的 OKE 叢集。請從此處下載最新的程式碼 oke_advanced_module.zip 。

OKE 最佳實務：符合生產需求的準則

1. 使用節點循環升級 OKE 節點集區。

節點循環是一種安全的滾動升級策略，可在不中斷工作負載的情況下更新節點映像檔、Kubernetes 版本或系統組態。節點循環很重要，因為它可讓叢集在一段時間內安全地發展、套用修補程式或升級，而不會影響生產環境工作負載。對於客戶而言，這可降低營運風險、確保升級期間的持續可用性，並讓工作負載能夠可靠地執行，同時維護最新版本。OKE 支援兩種類型：

maximum_surge 和 maximum_unavailable 等參數可控制升級如何以可用性平衡速度。若為零停機升級，請設定 maximum_surge = 1 且 maximum_unavailable = 0，確保一個新節點在線上，再取代舊節點。以下說明具有 Max surge 1 和 Max unavailable 0 的節點循環範例。

OKENodepoolupgraded

若要觸發導致節點循環的現有 OKE 叢集升級：

在您的 terraform.tfvars 檔案中：

然後執行 terraform plan

您應該會看到如下的執行結果：

當您執行 terraform apply 時，OKE 會開始使用 BOOT_VOLUME_REPLACE 策略一次循環一個節點的節點集區。在此模式中，只有節點的開機磁碟區會被取代，而基礎運算執行處理則維持不變。因此，會就地執行節點升級，而專用 IP 位址之類的網路屬性則維持不變，如下所示：

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

若要使用 INSTANCE_REPLACE 選項循環節點，請將 OKE 的 cycle_modes 設為 INSTANCE_REPLACE，以一次循環一個節點的節點集區。在此模式下，系統會從頭開始刪除並重新建立每個節點，包括運算執行處理及其開機磁碟區。因此，節點升級會套用所有更新的屬性，例如新的 Kubernetes 版本或資源配置變更，但像專用 IP 這樣的網路屬性可能會變更。此方法可確保具有最新組態的完全重新整理節點，提供最大更新涵蓋範圍，同時透過輪流取代維持叢集可用性，如下所示：

OKEclusterUpgrading OKEclusterUpgrading

2. 在 OKE 工作節點和負載平衡器上使用 OCI 標記功能追蹤成本

在 Oracle Cloud Infrastructure (OCI) 中執行 Kubernetes 工作負載時，必須瞭解成本來自何處。標記是關鍵。OCI 可讓您將定義的標記和自由格式標記套用至每個資源，包括 OKE 叢集、工作節點、負載平衡器和永久磁碟區。這一點非常重要，因為它可以提供詳細的成本報告、更輕鬆的稽核，以及雲端消費的問責制。對於客戶而言，標記功能提供洞察分析，瞭解哪些工作負載消耗最多資源、提高成本透明度，以及支援最佳化決策來控制雲端支出。

為什麼標記很重要：

# Cluster-level tagging
cluster_freeform_tag_key   = "Environment"
cluster_freeform_tag_value = "Development"

# Node pool-level tagging
node_pool_freeform_tag_key   = "LOB"
node_pool_freeform_tag_value = "DevOps Tech"

# Bastion host tagging
freeform_tags = {
  project     = "devops"
  environment = "production"}

# Defined tagging
defined_tags = { 
  “Corporate_Standard.CostCenter”  = “Finance-123"
  “Corporate_Standard.Environment” = “Production” }

有了這些標記，您可以在 OCI 成本分析中產生詳細的成本報表、識別哪些工作負載使用最多的資源，以及針對擴展或最佳化做出明智的決策。

3. 分離 API 端點、節點、負載平衡器和 Pod 子網路 (如果適用)。

適當的網路設計是 OKE 的最佳做法，因為可改善安全性、效能及擴展性。將 API 端點、工作節點、Pod、負載平衡器和堡壘主機隔離到個別的子網路中，可隔離關鍵流量、允許自訂路由表或網路安全群組 (NSG)，並防止某種類型的流量干擾另一類流量。此方法對於在生產環境中維護安全通訊、可預測的路由，以及強大的資源隔離至關重要。

客戶可以利用更安全、可管理且具有彈性的叢集，在不影響工作負載的情況下，有效率地擴展並處理流量激增或攻擊。以下是 terrform.tfvars 中的程式碼片段，可讓您定義子網路的 CIDR 區塊。

k8apiendpoint_private_subnet_cidr_block       = "REPLACE_WITH_YOUR_CIDR"   # API endpoint subnet
workernodes_private_subnet_cidr_block         = "REPLACE_WITH_YOUR_CIDR"   # Worker nodes subnet
pods_private_subnet_cidr_block                = "REPLACE_WITH_YOUR_CIDR"   # Pod subnet (CNI)
serviceloadbalancers_public_subnet_cidr_block = "REPLACE_WITH_YOUR_CIDR"   # Load balancer subnet
bastion_public_subnet_cidr_block              = "REPLACE_WITH_YOUR_CIDR"   # Bastion host subnet

藉由遵循本課堂練習，您可以改善安全性、簡化網路管理，以及讓您的叢集更具彈性地抵禦流量激增或攻擊。

4. 使用叢集自動調整器時，使用每個可用性網域架構的節點集區

在 OCI 中，每個可用性網域 (AD) 都有獨立的容量。雖然節點集區可以跨多個 AD 來提升高可用性，但若啟用叢集自動調整工具，則不建議使用此選項。自動調整器需要所有所選 AD 的容量，如果 AD 資源用盡，便無法調整。

為避免此情況發生，啟用自動調整功能時，應將節點集區設定為使用單一 AD。如果一個 AD 中沒有容量，則自動調整器可以在另一個 AD 中調整替代節點集區。

節點集區組態範例：

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

範例叢集自動調整器組態：

cluster_autoscaler_config = {
  node_mapping = {
    key = "nodes"
    value = "1:5:ocid1.nodepool....."
  }
}

5. 不同工作負載需求的個別節點集區 (x86、ARM、GPU)

針對需要不同運算型態 (例如 x86、ARM 或 GPU) 的工作負載，使用個別的節點集區。此方法可確保每個工作負載在最合適的基礎架構上執行，以改善資源使用率、排程效率及自動調整行為。

Pod 會使用節點標籤、選取器、實體或污點 (taint) 和允差排定至正確的節點集區，讓 Kubernetes 能夠在具有所需架構或功能的節點上放置工作負載。

透過將專用節點集區與明確的 Pod 位置結合，客戶可以實現可預測的效能、高效擴展以及簡化的叢集管理。在此範例中，會為 Intel 和 AMD 資源配置建立個別的節點集區，以確保最佳的工作負載位置和彈性的叢集作業。

worker_node_pools = {
  AMD_node_pool = {
    name               = "node_pool_one"                # Node pool name
    shape              = "VM.Standard.E5.Flex"          # Compute shape
    shape_config = {
      memory = 16                                       # Memory (GB)
      ocpus  = 1                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }
  Intel_node_pool = {
    name               = "node_pool_two"                # Node pool name
    shape              = "VM.Standard2.8"      	        # Compute shape
    shape_config = {
      memory = 120                                      # Memory (GB)
      ocpus  = 8                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"  
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }

}

執行 terraform apply 之後，您的 OKE 叢集會顯示兩個不同的節點集區：

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. 使用 Cloud-Init 自訂節點

Cloud-init 命令檔對於 OKE 中的工作節點組態自動化至關重要，可確保所有節點的作業系統設定、套裝程式安裝及系統調整一致。整合 cloud-init 與 Terraform 可讓您在開機時自動佈建節點，讓部署可重複、可稽核且符合生產環境需求。請參閱此文件 Using Custom Cloud-init Initialization Scripts to Set Up Managed Nodes，瞭解有關 cloud-init Script 的詳細資訊。

在提供的 Terraform 程式碼中，每個節點集區都會使用 cloud_init_path 參數參照一個 cloud-init 命令檔。客戶可以根據其需求修改 cloud-init-general.sh 的內容，遵循上述文件中的指引。在此示範中，我們使用參考文件中提供的預設啟動程序檔。客戶也可以透過更新 cloud_init_path 參數來變更 cloud-init 命令檔的位置，如下所示：

cloud_init_path = "cloud-init-general.sh"

這可確保在節點佈建或節點循環期間，每個新的或取代的節點都會以所需的系統組態一致地初始化。與 Terraform 結合後，Cloud-init 可自動套用版本控制的指令碼，減少手動佈建後的工作。

工作節點的主要優點：

7. 使用附加元件增強 OKE 功能

OKE 附加元件可擴充叢集功能，以進行可觀察性、規模調整、安全性及流量管理。您可以使用 Terraform 根據工作負載需求選擇性啟用或停用附加元件，並將資源使用量降到最低：

kubernetes_dashboard_enabled       = false
metrics_server_enabled             = false
cluster_autoscaler_enabled         = false
certificate_manager_enabled        = false
istio_enabled                      = false
native_ingress_controller_enabled  = false

常用的附加元件及其好處：

附加元件的最佳做法：

8. 如果外部資源需要存取 k8s 叢集，請使用 OIDC 認證 / 尋找。

如果 OCI 以外的開發人員或自動化工具需要向您的 Kubernetes 叢集進行認證，則將 OIDC 尋找與外部身分識別提供者 (例如 Okta 或 Azure AD) 整合。這可讓集中式身分識別管理和聯合存取，而不需要管理本機 Kubernetes 使用者或分送 kubeconfig 檔案。當外部 CI/CD 工具 (例如 GitHub 動作) 需要存取叢集，或當叢集內的工作負載必須安全地與外部服務 (例如 HashiCorp Vault) 整合時，此方法特別有用。組織可以依靠 OIDC 強制執行一致的認證原則、簡化存取管理，以及降低證明資料輪替的作業負荷，同時維持強大的安全界限。

9. 使用網路安全群組取代安全清單

保護 OKE 叢集時，網路安全群組 (NSG) 優先於傳統安全清單。NSG 允許更精細、彈性且可重複使用的安全規則，可直接附加至特定資源，例如工作者節點、負載平衡器或 Pod。這使它們更適合經常擴展或變更資源的動態 Kubernetes 環境。相反地，安全列表在子網路層級應用，旨在涵蓋整個 VCN 或子網路，從而減少實施微點應用程式安全要求時的控制。使用 NSG 可改善安全衛生、簡化規則管理，並在叢集元件之間實現更嚴格的隔離。

10. 使用 OCI 日誌記錄分析和 OKE 度量啟用可觀察性

將 OKE 與 OCI 日誌記錄分析和監控整合，以深入瞭解叢集和工作負載效能。日誌記錄分析提供進階日誌聚總、剖析及異常偵測，而監控則從 Kubernetes 控制層和工作節點收集度量。這些服務讓團隊能夠將趨勢視覺化、更快地解決問題，以及設定主動管理警示。此解決方案特別適合尋求 OCI 原生可觀察性平台的客戶，該平台抽象化了日誌擷取、儲存和分析的複雜性，同時與其他 OCI 服務緊密整合。

11. 如果 Pod 需要存取 OCI 資源，請使用工作負載識別。

對 OCI 進行認證時，會經常使用 API 金鑰，但這些證明資料是長期且需要永久儲存，因此難以大規模安全地管理。雖然執行處理和資源主體允許運算執行處理或服務使用自己的身分識別來改善此概念，但 OKE 工作負載識別則允許個別 Kubernetes Pod 使用自己的 OCI 識別來進一步擴充此概念。藉由啟用 OCI Workload Identity，Pod 可使用 IAM 原則安全地存取 OCI 服務 (例如物件儲存或記錄日誌)，而無須使用硬式編碼證明資料或依賴節點層級權限。這對生產級、多租用戶的 Kubernetes 環境而言至關重要，提供精細、可稽核且安全的存取控制。

12. 請為 OKE 節點和 Pod 使用適當的子網路大小。

正確地規劃子網路 CIDR 區塊是最佳做法，因為每個節點都需要 Pod 的主要 IP 和其他次要 IP。小型子網路可能會快速導致 IP 耗盡，防止擴展或升級。這對於維持叢集穩定性和支援成長至關重要。客戶可以透過確保叢集能夠以可預測的方式擴展、避免營運中斷，並在無需重新設計網路的情況下支援未來的工作負載。對於生產環境，請配置較大的 CIDR 區塊，並參閱 OKE 子網路大小設定指南，以確保您的 VCN 可支援目前和未來的工作負載需求。

13. 使用 Full Stack Disaster Recovery 服務備份 k8s 叢集

運用 OCI Full Stack Disaster Recovery for OKE 叢集是最佳做法，因為它保護叢集組態、應用程式和網路，以及跨區域協調容錯移轉和容錯移轉。這對於發生區域中斷或系統故障時的業務連續性和合規性至關重要。客戶可以減少停機時間、快速復原，以及即使在災害期間，關鍵任務工作負載仍可維持運作的信心。

如需詳細資訊，請參閱使用 OCI Full Stack Disaster Recovery 自動切換和容錯移轉 OCI Kubernetes Engine (狀態) 的容錯移轉計畫

後續步驟：

Terraform 讓 OKE 佈建保持一致、自動化且可擴展。藉由遵循 OCI 標籤、子網路分離和標準化節點組態等最佳實務，您的叢集保持安全、組織性且符合成本效益。在下一個部落格中，我們將根據這些基礎來探索 AI 驅動的營運，展示如何整合 Oracle AIOps、實現 AI 可觀察性，並為 AI 工作負載建立端對端 OKE 藍圖。敬請留意我們即將舉行的 LiveLabs 場次，您可在此獲得這些技術的實作體驗，並實驗現場環境中的 OKE 部署。

確認

其他學習資源

在 docs.oracle.com/learn 上探索其他實驗室，或在 Oracle Learning YouTube 頻道上存取更多免費學習內容。此外，請造訪 education.oracle.com/learning-explorer 以成為 Oracle Learning Explorer。

如需產品文件，請造訪 Oracle Help Center 。