※ 本記事は、Kay Singhによる”Cookie-based session persistence now available with OKE Managed Load Balancers“を翻訳したものです。

2026年7月8日

OCI Native Ingress Controllerでは、OCIロード・バランサのCookieベースのセッション永続性がサポートされるようになりました。また、OKEでは、LoadBalancerタイプのKubernetesサービス用にプロビジョニングされたOCIロード・バランサのCookieベースのセッション永続性もサポートされるようになり、チームはアプリケーション・トラフィックの公開方法に応じてスティッキー・セッションを有効にする2つの方法を提供します。どちらの場合も、アプリケーションCookieの永続性とロード・バランサのCookieの永続性のいずれかを選択できます。

Kubernetesで実行されるアプリケーションは、ステートレスになるように設計されることがよくありますが、実際には必ずしもそうではありません。一部のワークロードは、引き続きリクエスト間のセッション継続性に依存します。例としては、バックエンド・インスタンスのセッション状態をメモリーに保持する従来のWebアプリケーション、サインインやチェックアウトなどの認証されたユーザー・フロー、セッション処理が完全に外部化される前にKubernetesに移行されるアプリケーションなどがあります。

このようなタイプのアプリケーションでは、同じクライアントから同じバックエンドにリクエストをルーティングすることで、セッションの継続性を維持し、アプリケーション・レイヤーに必要なセッション処理ロジックの量を削減できます。このリリースでは、OKEで実行されているチームが、ワークロードをLoadBalancerタイプのサービスを介して直接公開するか、OCIネイティブ・イングレス・コントローラを介して公開するかに関係なく、その動作を有効にできるようになりました。

cookier persistence example with load balancers

2つの永続性モデル

LoadBalancerタイプのサービスまたはOCIネイティブ・イングレス・コントローラのいずれかを使用して構成されたOKEロード・バランサは、K8sバージョン1.32以上の2つのCookieベースの永続性モデルをサポートしています。

アプリケーションCookieの永続性によって、バックエンド・アプリケーションはCookieを設定および管理します。これは、アプリケーションが独自のセッションCookieをすでに発行し、セッション・アフィニティがその既存の動作に従う場合に適しています。このモードでは、スティッキネスは、バックエンドが構成されたCookie名と一致するSet-Cookieヘッダーを返すときに開始されます。

ロード・バランサのCookie永続性では、ロード・バランサがお客様にかわって永続性Cookieを設定および管理します。これは、アプリケーションの動作を変更せずにスティッキー・セッションが必要な場合や、インフラストラクチャ・レイヤーでセッション・アフィニティを管理する場合に、より簡単なオプションです。

OKEでCookieベースのセッション永続性を使用する2つの方法

前述の永続性モデルの両方を、LoadBalancerタイプのKubernetesサービスとOCI Native Ingress Controllerの両方で使用できます。これにより、チームは、アプリケーション・トラフィックの公開方法に応じて、サービス上でスティッキー・セッションを直接構成するか、イングレスを介して構成するかを選択できます。

Kubernetesサービスを直接公開し、サービス・アノテーションを介してOCIロード・バランサを構成する場合は、LoadBalancerタイプのサービスを使用します。これは、イングレス固有のルーティングが不要な、より単純な外部エクスポージャ・パターンに適しています。

ホストベースおよびパスベースのルーティングなどのイングレスベースのトラフィック管理が必要で、イングレス注釈を使用してセッション永続性を構成する場合は、OCIネイティブ・イングレス・コントローラを使用します。NICは、Kubernetesイングレス・リソースからOCIフレキシブル・ロード・バランサを作成および管理し、同じCookieベースの永続性機能もサポートするようになりました。

クイック構成の例

LoadBalancerタイプのサービスを介してアプリケーションを公開する場合は、KubernetesマニフェストでServiceアノテーションを使用してCookieベースのセッション永続性を構成できます。サービスは、サービス注釈を介して、アプリケーションCookieの永続性およびロード・バランサのCookieの永続性の両方をサポートします。次の例は、ロード・バランサCookieの永続性を示しています:

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci-load-balancer.oraclecloud.com/lb-cookie-session-persistence-config: |
      {
        "cookieName": "X-Oracle-OCI-Route",
        "disableFallback": true,
        "path": "/",
        "isHttpOnly": true
      }
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080

OCIネイティブ・イングレス・コントローラを使用している場合は、イングレス注釈を使用してCookieベースのセッション永続性を構成できます。NICでは、イングレス注釈を介して両方の永続性モデルもサポートされます。次の例は、アプリケーションCookieの永続性を示しています: 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-cookie-ingress
  annotations:
    oci-native-ingress.oraclecloud.com/session-persistence-config: |
      {
        "cookieName": "APPSESS"
      }
spec:
  ingressClassName: oci-native-ingress
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 8080

これら2つのパスは、LoadBalancerタイプのサービスとOCIネイティブ・イングレス・コントローラの両方が、アプリケーションCookieの永続性とロード・バランサのCookieの永続性をサポートし、サービスまたはイングレス・リソースで機能を構成するかどうかは異なります。

いくつかの留意事項

  • バックエンド・セットに対して一度に1つの永続性モードのみを構成します。両方の永続性注釈が指定された構成パスで指定されている場合、リコンシリエーションは失敗します。
  • 注釈値が有効なJSONであることを確認してください。JSONの形式が正しくないと、構成が失敗します。
  • アプリケーションCookieモードでは、バックエンドがSet-Cookieヘッダーで必要なCookieを返した後にのみ、永続性が開始されます。
  • ロード・バランサのCookieモードでは、使用している構成パスに応じて、オプションでcookieName、disableFallback、domain、path、maxAgeInSeconds、isSecureおよびisHttpOnlyなどのフィールドを構成できます。
  • isSecureがtrueに設定されている場合、HTTPSまたはTLSリスナーを使用します。セキュアなCookieは、HTTPのみのリスナーでは受け入れられません。

詳細

さらに詳しく学ぶには、まず