Oracle Kubernetes Engine (OKE)の本番へのデプロイ: ベスト・プラクティスとガイドライン

はじめに

これは、Oracle Cloud Infrastructure Kubernetes Engine (OKE)自動化シリーズの3番目のチュートリアルであり、2番目のチュートリアルであるAdvanced Terraformモジュールを使用したOracle Cloud Infrastructure Kubernetes Engine (OKE)のデプロイで導入された概念に基づいています。このガイドでは、本番対応のOKEデプロイメントに重点を置き、クラスタの信頼性を向上させ、コストを最適化し、操作を簡素化する主要なベスト・プラクティスを探ります。Terraformを使用したベスト・プラクティスのいくつかをデモンストレーションし、クラスタの構築時に発生する一般的な落とし穴も強調します。

既存のVCNへのOKEのデプロイが重要な理由

本番グレードのOKEクラスタを構築するには、ネットワーキング、ノードの配置および運用プロセス全体にわたって慎重に計画する必要があります。既存のVirtual Cloud Network (VCN)にデプロイすると、クラスタは事前構成済のサブネット、ルート表およびセキュリティ・ルールとシームレスに統合できます。これにより、運用オーバーヘッドが削減され、組織のインフラストラクチャとの整合性が保証され、複数のワークロードまたはクラスタが同じネットワーク内で効率的に共存できるようになります。

既存のVCNにデプロイする際の主要なTerraformパラメータには、次のものがあります:

または、まったく新しい環境を最初からデプロイする場合は、is_vcn_created = trueを設定して新しいネットワークをプロビジョニングします。terraform applyが成功すると、Terraformは、新しく作成されたVCNとそのサブネットのOCIDsを出力に取得します。これらの値は、is_vcn_created = falseを設定し、terraform.tfvarsファイルで保存されたOCIDsを参照することで、将来のデプロイメントで再利用できます。これにより、Terraformは、新しいネットワークを作成するのではなく、既存のネットワークを使用できます。この段階でterraform planを実行すると、現在のVCNおよびサブネットが保持され、不要なインフラストラクチャの変更が回避されます。

ネットワーク基盤を整えることで、このチュートリアルでは、OKEクラスタをより回復力があり、スケーラブルで操作しやすくすることを目的とした、本番指向のベスト・プラクティスのセットにフォーカスを移します。これらのプラクティスを適用することで、お客様は、可用性が高く、コスト効率が高く、組織のポリシー、ガバナンス基準、および本番環境に対応した運用要件に準拠したOKEクラスタをデプロイできます。oke_advanced_module.zipから最新のコードをダウンロードします。

OKEのベスト・プラクティス: 本番対応のガイドライン

1. ノード・サイクリングを使用して、OKEノード・プールをアップグレードします。

ノード・サイクリングは、ワークロードを中断することなく、ノード・イメージ、Kubernetesバージョンまたはシステム構成を更新する、安全でローリングなアップグレード戦略です。ノード・サイクリングは、クラスタを時間の経過とともに安全に進化させ、本番ワークロードに影響を与えずにパッチまたはアップグレードを適用できるため、重要です。お客様にとって、これにより運用リスクが軽減され、アップグレード中の継続的な可用性が保証され、最新バージョンを維持しながらワークロードを確実に実行できます。OKEでは、次の2つのタイプがサポートされています。

maximum_surgeやmaximum_unavailableなどのパラメータは、アップグレード速度と可用性とのバランスを調整する方法を制御します。停止時間ゼロのアップグレードの場合は、maximum_surge = 1およびmaximum_unavailable = 0を設定して、古いノードを置き換える前に1つの新しいノードがオンラインになるようにします。次の図は、最大サージ1および最大使用不可0のノード・サイクリングの例を示しています。

OKENodepoolupgraded

ノード・サイクリングにつながる既存のOKEクラスタのアップグレードをトリガーするには:

terraform.tfvarsファイル:

その後、terraform planを実行します

出力は次のようになります。

terraform applyを実行すると、OKEは、BOOT_VOLUME_REPLACE戦略を使用してノード・プールを一度に1つずつサイクリングを開始します。このモードでは、基礎となるコンピュート・インスタンスが同じままである間に、ノードのブート・ボリュームのみが置換されます。その結果、ノード・アップグレードが実施され、プライベートIPアドレスなどのネットワーク属性は、次のように変更されません。

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

INSTANCE_REPLACEオプションを使用してノードを循環させるには、OKEがノード・プールを一度に1つのノードに循環させるように、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エンドポイント、ノード、ロード・バランサおよびポッド・サブネット(該当する場合)。

OKEでは、セキュリティ、パフォーマンスおよびスケーラビリティが向上するため、適切なネットワーク設計がベスト・プラクティスです。APIエンドポイント、ワーカー・ノード、ポッド、ロード・バランサおよび要塞ホストを別々のサブネットに分離することで、クリティカルなトラフィックを分離し、カスタム・ルート表またはネットワーク・セキュリティ・グループ(NSG)を可能にし、あるタイプのトラフィックが別のトラフィックに干渉しないようにします。このアプローチは、セキュアな通信、予測可能なルーティング、および本番環境での強力なリソース分離を維持するために不可欠です。

お客様は、ワークロードに影響を与えることなく、効率的にスケーリングし、トラフィックの急増や攻撃を処理できる、より安全で管理しやすい、回復力のあるクラスタを持つことでメリットを得ることができます。次に、サブネットのCIDRブロックを定義できるterrform.tfvarsのスニペットを示します。

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.Cluster Autoscaler使用時の可用性ドメイン・アーキテクチャごとのノード・プールの使用

OCIでは、各アベイラビリティ・ドメイン(AD)に独立した容量があります。ノード・プールは複数のADにまたがって高可用性を向上させることができますが、クラスタ自動スカラーが有効な場合はお薦めしません。オートスカラーでは、選択したすべてのADで容量が必要であり、いずれかのADでリソースが不足している場合、スケーリングに失敗する可能性があります。

これを回避するには、自動スケーリングが有効な場合に単一のADを使用するようにノード・プールを構成する必要があります。1つのADで容量が使用できない場合、autoscalerは別のADで代替ノード・プールをスケーリングできます。

ノード・プール構成の例:

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

クラスタのautoscaler構成の例:

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

5. ワークロード要件が異なる個別のノード・プール(x86、ARM、GPU)

x86、ARM、GPUなど、異なるコンピュート・シェイプを必要とするワークロードには、個別のノード・プールを使用します。このアプローチにより、各ワークロードが最適なインフラストラクチャ上で実行されるようにすることで、リソース使用率、スケジューリング効率および自動スケーリングの動作が向上します。

ポッドは、ノード・ラベル、セレクタ、アフィニティ、またはTaints and Tolerationsを使用して正しいノード・プールにスケジュールされるため、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クラスタに2つの異なるノード・プールが表示されます。

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. ノードのカスタマイズにCloud-Initを使用

Cloud-initスクリプトは、OKEのワーカー・ノード構成を自動化するために不可欠であり、すべてのノードにわたって一貫したOS設定、パッケージ・インストールおよびシステム・チューニングを実現します。cloud-initをTerraformと統合することで、起動時にノードを自動的にプロビジョニングできるため、デプロイメントを繰り返し可能、監査可能、本番対応にすることができます。cloud-initスクリプトの詳細は、このドキュメントUsing Custom Cloud-init Initialization Scripts to Set Up Managed Nodesを参照してください。

提供されている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と組み合せることで、バージョン管理されたスクリプトを自動的に適用できるため、手動でのプロビジョニング後のタスクが不要になります。

ワーカー・ノードの主な利点:

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ファイルを配布することなく、一元化されたアイデンティティ管理およびフェデレーテッド・アクセスが可能になります。このアプローチは、GitHubアクションなどの外部CI/CDツールがクラスタにアクセスする必要がある場合、またはクラスタ内のワークロードがHashiCorp Vaultなどの外部サービスと安全に統合する必要がある場合に特に役立ちます。OIDCに依存することで、組織は一貫した認証ポリシーを適用し、アクセス管理を簡素化し、強力なセキュリティ境界を維持しながら資格証明のローテーションの運用オーバーヘッドを削減できます。

9。セキュリティ・リストのかわりにネットワーク・セキュリティ・グループを使用

OKEクラスタを保護する場合、ネットワーク・セキュリティ・グループ(NSG)は従来のセキュリティ・リストよりも優先されます。NSGでは、ワーカー・ノード、ロード・バランサ、ポッドなどの特定のリソースに直接アタッチできる、より粒度が高く柔軟で再利用可能なセキュリティ・ルールを使用できます。これにより、リソースのスケーリングや変更の頻度が高い動的なKubernetes環境に適しています。これに対して、セキュリティ・リストはサブネット・レベルで適用され、VCNsまたはサブネット全体を網羅するように設計されているため、きめ細かなアプリケーション・セキュリティ要件を実装する際の制御が少なくなります。NSGを使用すると、セキュリティ衛生が向上し、ルール管理が簡素化され、クラスタ・コンポーネント間の分離が強化されます。

10。OCI Logging AnalyticsおよびOKEメトリックで可観測性を実現

OKEをOCI Logging Analytics and Monitoringと統合して、クラスタとワークロードのパフォーマンスを詳細に可視化します。ログ・アナリティクスは、高度なログ集計、解析および異常検出を提供し、MonitoringはKubernetesコントロール・プレーンおよびワーカー・ノードからメトリックを収集します。これらのサービスを組み合わせることで、チームは傾向を可視化し、問題をより迅速にトラブルシューティングし、予防的な管理のためにアラートを構成できます。このソリューションは、他のOCIサービスとシームレスに統合しながら、ログの取込み、ストレージ、分析の複雑さを抽象化するOCIネイティブの可観測性プラットフォームをお探しのお客様に最適です。

11。ポッドがOCIリソースにアクセスする必要がある場合は、ワークロード・アイデンティティを使用します。

OCIへの認証では、APIキーが一般的に使用されますが、これらの資格証明は存続期間が長く、永続ストレージが必要であるため、セキュアに大規模に管理することが困難になります。インスタンス・プリンシパルとリソース・プリンシパルは、コンピュート・インスタンスまたはサービスが独自のアイデンティティを想定できるようにすることでこれを改善しますが、OKEワークロード・アイデンティティは、個々のKubernetesポッドが独自のOCIアイデンティティを想定できるようにすることで、この概念をさらに拡張します。OCIワークロード・アイデンティティを有効にすることで、ポッドはIAMポリシーを使用してオブジェクト・ストレージやロギングなどのOCIサービスに安全にアクセスでき、資格証明をハードコードしたり、ノードレベルの権限に依存したりする必要がなくなります。これにより、ファイングレインで監査可能でセキュアなアクセス制御が実現され、本番グレードのマルチテナントKubernetes環境に不可欠です。

12.OKEノードおよびポッドに適切なサブネット・サイズを使用します。

サブネットCIDRブロックを正しく計画することはベスト・プラクティスです。これは、各ノードがポッドにプライマリ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 (Stateful)のスイッチオーバーおよびフェイルオーバー計画の自動化」を参照してください

次のステップ:

Terraformは、OKEプロビジョニングの一貫性、自動化、拡張性を実現します。OCIタグ付け、サブネット分離、標準化されたノード構成などのベストプラクティスに従うことで、クラスタはセキュアで整理され、コスト透過的に維持されます。次のブログでは、これらの基盤に基づいて、AI主導の運用を探求し、Oracle AIOpsの統合、AIによる可観測性の実現、AIワークロードのエンドツーエンドのOKEブループリントの作成方法を紹介します。今後のLiveLabsセッションに注目してください。このセッションでは、これらの手法を実践し、ライブ環境でOKEデプロイメントを試すことができます。

確認

その他の学習リソース

docs.oracle.com/learnの他のラボを調べるか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、Oracle Learning Explorerになるには、education.oracle.com/learning-explorerにアクセスしてください。

製品ドキュメントについては、Oracle Help Centerを参照してください。