为生产环境部署 Oracle Kubernetes 引擎 (OKE)：优秀实践和准则

简介

这是 Oracle Cloud Infrastructure Kubernetes Engine (OKE) 自动化系列中的第三个教程，该教程以使用高级 Terraform 模块部署 Oracle Cloud Infrastructure Kubernetes Engine (OKE) 中介绍的概念为基础。在本指南中，我们将重点介绍可用于生产的 OKE 部署，并探讨可提高集群可靠性、优化成本和简化运营的关键优秀实践。我们将展示一些使用 Terraform 的优秀实践，同时突出显示用户在构建集群时遇到的常见问题。

为什么要将 OKE 部署到现有的 VCN 事务中

构建生产级 OKE 集群需要仔细规划网络、节点放置和运行流程。通过部署到现有虚拟云网络 (Virtual Cloud Network，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，确保一个新节点在替换旧节点之前联机。下图显示了最大激增 1 和最大不可用 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 worker 节点和负载平衡器上使用 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 端点、节点、负载平衡器和云池子网（如果适用）。

OKE 中的最佳做法是正确的网络设计，因为它提高了安全性、性能和可扩展性。将 API 端点、worker 节点、云池、负载平衡器和堡垒主机隔离到单独的子网中，以隔离关键流量，允许定制路由表或网络安全组 (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）的工作负载，可使用单独的节点池。此方法可确保每个工作负载在最合适的基础设施上运行，从而提高资源利用率、调度效率和自动缩放行为。

云池使用节点标签、选择器、关联性或污染物和容差调度到正确的节点池，从而允许 Kubernetes 在具有所需体系结构或功能的节点上放置工作负载。

通过将专用节点池与显式云池放置相结合，客户可以实现可预测的性能、高效的扩展和简化的集群管理。在此示例中，为 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 中自动执行 worker 节点配置至关重要，可确保在所有节点上进行一致的操作系统设置、软件包安装和系统优化。通过将 cloud-init 与 Terraform 集成，您可以在引导时自动预配节点，使部署可重复、可审计并且可供生产环境使用。有关 cloud-init 脚本的更多信息，请查看此文档使用定制 Cloud-init 初始化脚本设置托管节点。

在提供的 Terraform 代码中，每个节点池使用 cloud_init_path 参数引用一个 cloud-init 脚本。客户可以按照上述文档中的指导，根据其要求修改 cloud-init-general.sh 的内容。在此演示中，我们使用引用的文档中提供的默认启动脚本。客户还可以通过更新 cloud_init_path 参数来更改 cloud-init 脚本的位置，如下所示：

cloud_init_path = "cloud-init-general.sh"

这样可以确保在节点置备或节点循环期间，每个新节点或替换节点都与所需的系统配置一致地初始化。Cloud-init 与 Terraform 相结合，可自动应用受版本控制的脚本，从而消除手动配置后任务。

Worker 节点的主要优势：

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 Actions）需要访问集群时，或者当集群中的工作负载必须安全地与外部服务（如 HashiCorp Vault）集成时，此方法尤其有用。通过依赖 OIDC，企业可以实施一致的身份验证策略，简化访问管理，并降低凭证轮换的运营开销，同时保持强大的安全边界。

9. 使用网络安全组而不是安全列表

保护 OKE 集群时，优先使用网络安全组 (NSG)，而不是传统安全列表。NSG 支持更加细粒度、灵活且可重用的安全规则，这些规则可以直接附加到特定资源，例如 Worker 节点、负载平衡器或云池。这使得它们更适合频繁扩展或更改资源的动态 Kubernetes 环境。相比之下，安全列表适用于子网级别，旨在涵盖整个 VCN 或子网，这在实施细粒度应用程序安全要求时提供了较少的控制。使用 NSG 可以改善安全卫生，简化规则管理，并在集群组件之间实现更紧密的隔离。

10. 利用 OCI Logging Analytics 和 OKE 指标实现可观测性

将 OKE 与 OCI Logging Analytics and Monitoring 集成，从而深入了解集群和工作负载性能。日志分析提供高级日志聚合、解析和异常检测，而监视服务则从 Kubernetes 控制层和 worker 节点收集度量。通过这些服务，团队可以可视化趋势，更快地排除问题，并配置警报以进行主动管理。此解决方案特别适合寻求 OCI 原生观测平台的客户，该平台可以抽象日志摄取、存储和分析的复杂性，同时与其他 OCI 服务无缝集成。

11. 如果云池需要访问 OCI 资源，请使用工作负载身份。

在向 OCI 进行身份验证时，通常会使用 API 密钥，但这些凭证是长期有效的，需要持久存储，因此难以大规模安全管理。虽然实例和资源主用户允许计算实例或服务采用自己的身份来改进这一点，但 OKE 工作负载身份通过允许单个 Kubernetes 云池采用自己的 OCI 身份来进一步扩展此概念。通过启用 OCI Workload Identity，云池可以使用 IAM 策略安全地访问 OCI 服务（例如对象存储或日志记录），而无需对身份证明进行硬编码或依赖节点级权限。这为生产级多租户 Kubernetes 环境提供了细粒度、可审计且安全的访问控制。

12. 为 OKE 节点和云池使用适当的子网大小。

正确规划子网 CIDR 块是最佳做法，因为每个节点都需要 pod 的主 IP 和其他辅助 IP。小型子网可以快速导致 IP 耗尽，从而防止扩展或升级。这对于保持集群稳定性和支持增长非常重要。客户可以确保集群可以实现可预测的扩展，避免运营中断，并支持未来的工作负载，而无需重新设计网络。对于生产环境，请分配较大的 CIDR 块并参阅 OKE 子网大小调整指南，以确保 VCN 可以支持当前和未来的工作负载需求。

13. 使用全栈灾难恢复服务备份 k8s 集群

优秀实践是利用 OCI Full Stack Disaster Recovery for OKE 集群，因为它通过协调的跨区域故障转移和故障恢复来保护集群配置、应用和网络。这对于发生区域中断或系统故障时的业务连续性和合规性非常重要。客户可以从更短的停机时间、快速恢复中获益，并确信即使在灾难期间，关键任务工作负载也能正常运行。

有关更多信息，请参见 Automate Switchover and Failover Plans for OCI Kubernetes Engine (Stateful) with OCI Full Stack Disaster Recovery

后续步骤：

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 帮助中心。