特表 2024-529099 コンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-01

(54)【発明の名称】コンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240725BHJP

【ＦＩ】

G06F9/50 150D

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024508076

(86)(22)【出願日】2022-08-08

(85)【翻訳文提出日】2024-03-19

(86)【国際出願番号】 CN2022110895

(87)【国際公開番号】W WO2023016415

(87)【国際公開日】2023-02-16

(31)【優先権主張番号】202110910594.X

(32)【優先日】2021-08-09

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】521486206

【氏名又は名称】ホアウェイ クラウド コンピューティング テクノロジーズ カンパニー リミテッド

【氏名又は名称原語表記】Ｈｕａｗｅｉ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ｃｌｏｕｄ Ｄａｔａ Ｃｅｎｔｅｒ，Ｊｉａｏｘｉｎｇｇｏｎｇ Ｒｏａｄ，Ｑｉａｎｚｈｏｎｇ Ａｖｅｎｕｅ， Ｇｕｉ’ａｎ Ｎｅｗ Ｄｉｓｔｒｉｃｔ， Ｇｕｉｚｈｏｕ，５５００２５，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村 進

(72)【発明者】

【氏名】▲張▼ ▲偉▼

(72)【発明者】

【氏名】姜 宇

(72)【発明者】

【氏名】黄 ▲ジアン▼

(57)【要約】

本出願は、データ処理技術の分野に関し、特に、コンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法に関する。接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが、ノード上で稼働する。サイドカークラスタは、少なくとも2つのサイドカーを含む。接続制御モジュールは、ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するように構成される。第1のサイドカーは、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するように構成される。本出願では、サービス・コンテナ・グループに対してより良好なトラフィック管理を実行するために、サービス・コンテナ・グループのためのサイドカーが選択され得る。

【特許請求の範囲】

【請求項1】

コンテナグループを実行するためのノードであって、接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが前記ノード上で稼働し、前記サイドカークラスタは少なくとも2つのサイドカーを含み、
前記接続制御モジュールは、前記ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送するように構成され、
前記第1のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するように構成される、
ノード。

【請求項2】

前記ノードが第2のサービス・コンテナ・グループをさらに含み、
前記接続制御モジュールは、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第2のサイドカーを選択し、前記第2のサービス・コンテナ・グループによって送信されたデータパケットを前記第2のサイドカーに転送するようにさらに構成され、
前記第2のサイドカーは、前記第2のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するように構成される、
請求項1に記載のノード。

【請求項3】

前記第1のサイドカーに割り当てられたハードウェアリソースの仕様が前記第2のサイドカーに割り当てられたハードウェアリソースの仕様よりも高く、前記サイドカー割り当てポリシーは第1のポリシーを含み、前記第1のポリシーは、前記第1のサービス・コンテナ・グループが前記第1のサイドカーを優先的に使用することを示し、
前記接続制御モジュールは、前記第1のポリシーに従って前記サイドカークラスタから前記第1のサイドカーを選択するように特に構成される、
請求項2に記載のノード。

【請求項4】

前記ノードが前記第2のサービス・コンテナ・グループをさらに含み、前記サイドカー割り当てポリシーは第2のポリシーをさらに含み、前記第2のポリシーは、前記第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示し、
前記接続制御モジュールは、前記第1のサイドカーによってサービスされる前記オブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が上限値を超えないとき、前記第2のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するようにさらに構成され、
前記第1のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記データパケットと前記第2のサービス・コンテナ・グループによって送信された前記データパケットとに対してトラフィック管理を同時に実行するようにさらに構成される、
請求項1から3のいずれか一項に記載のノード。

【請求項5】

前記接続制御モジュールが、前記第1のサイドカーが故障した後で、前記サイドカークラスタから第3のサイドカーを選択し、または前記ノードに前記第3のサイドカーを作成するように前記コンソールに通知し、前記第1のサービス・コンテナ・グループによって送信された別のデータパケットを前記第3のサイドカーに転送するように構成され、
前記第3のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行するように構成される、
請求項1から4のいずれか一項に記載のノード。

【請求項6】

前記第3のサイドカーが、前記第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または前記第3のサイドカーが、前記第1のサイドカーの複製バージョンである、請求項5に記載のノード。

【請求項7】

前記第1のサイドカーが、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループに前記データパケットを送信するように構成される、
請求項5または6に記載のノード。

【請求項8】

前記第1のサイドカーが、セッション識別子を生成し、前記セッション識別子を前記第1のサービス・コンテナ・グループおよび前記接続制御モジュールに送信するように構成され、
前記接続制御モジュールが、前記セッション識別子と前記バックエンド・コンテナ・グループとの間の対応関係を記録するように構成され、
前記第3のサイドカーが、前記第1のサービス・コンテナ・グループから前記セッション識別子を取得し、前記セッション識別子に基づいて、前記接続制御モジュールによって記録された前記対応関係内の前記バックエンド・コンテナ・グループを決定し、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行した後に、前記別のデータパケットを前記バックエンド・コンテナ・グループに送信するように構成される、
請求項7に記載のノード。

【請求項9】

前記サイドカー割り当てポリシーが第3のポリシーを含み、前記第3のポリシーは、前記サイドカーによってサービスされるオブジェクトの数が0であるときに、前記サイドカークラスタ内のサイドカーが優先的に使用されることを示し、
前記接続制御モジュールが、前記第1のサイドカーによってサービスされるオブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が0であるとき、前記第1のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するようにさらに構成される、
請求項1または2に記載のノード。

【請求項10】

前記接続制御モジュールが、前記サイドカークラスタ内の各サイドカーの作動状況を監視し、前記オフラインサイドカーがあることを発見すると、前記オフラインサイドカーに関する情報を前記コンソールに送信するようにさらに構成される、
請求項1から9のいずれか一項に記載のノード。

【請求項11】

前記トラフィック管理が、トラフィック制御、トラフィック保護、およびトラフィック観測を含む、請求項1から10のいずれか一項に記載のノード。

【請求項12】

前記ノードが、仮想マシン、コンピュータ、またはベアメタルサーバである、請求項1から11のいずれか一項に記載のノード。

【請求項13】

コンソールと、請求項1から11のいずれか一項に記載のノードとを備える、コンテナグループ管理システム。

【請求項14】

ノード内のコンテナグループを管理するための方法であって、接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが前記ノード上で稼働し、前記サイドカークラスタは少なくとも2つのサイドカーを含み、前記方法は、
前記接続制御モジュールによって、前記ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送するステップと、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するステップと
を含む、方法。

【請求項15】

第2のサービス・コンテナ・グループが前記ノード上でさらに稼働し、前記方法は、
前記接続制御モジュールによって、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第2のサイドカーを選択し、前記第2のサービス・コンテナ・グループによって送信されたデータパケットを前記第2のサイドカーに転送するステップと、
前記第2のサイドカーによって、前記第2のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するステップと
をさらに含む、請求項14に記載の方法。

【請求項16】

前記第1のサイドカーに割り当てられたハードウェアリソースの仕様が前記第2のサイドカーに割り当てられたハードウェアリソースの仕様よりも高く、前記サイドカー割り当てポリシーは第1のポリシーを含み、前記第1のポリシーは、前記第1のサービス・コンテナ・グループが前記第1のサイドカーを優先的に使用することを示し、
前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択する前記ステップは、前記第1のポリシーに従って前記サイドカークラスタから前記第1のサイドカーを選択するステップを含む、
請求項15に記載の方法。

【請求項17】

前記第2のサービス・コンテナ・グループが前記ノード上でさらに稼働し、前記サイドカー割り当てポリシーは第2のポリシーをさらに含み、前記第2のポリシーは、前記第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示し、前記方法は、
前記接続制御モジュールによって、前記第1のサイドカーによってサービスされる前記オブジェクトの数を決定し、前記数が上限値を超えないとき、前記第2のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するステップと、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットと前記第2のサービス・コンテナ・グループによって送信された前記データパケットとに対してトラフィック管理を同時に実行するステップと
をさらに含む、請求項14から16のいずれか一項に記載の方法。

【請求項18】

前記方法が、
前記第1のサイドカーが故障した後で、前記接続制御モジュールによって、前記サイドカークラスタから第3のサイドカーを選択し、または前記ノードに前記第3のサイドカーを作成するように前記コンソールに通知し、前記第1のサービス・コンテナ・グループによって送信された別のデータパケットを前記第3のサイドカーに転送するステップと、
前記第3のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行するステップと
をさらに含む、請求項14から17のいずれか一項に記載の方法。

【請求項19】

前記第3のサイドカーが、前記第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または前記第3のサイドカーが、前記第1のサイドカーの複製バージョンである、請求項18に記載の方法。

【請求項20】

前記方法が、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループに前記データパケットを送信するステップ
をさらに含む、請求項18または19に記載の方法。

【請求項21】

前記方法が、
前記第1のサイドカーによって、セッション識別子を生成し、前記セッション識別子を前記第1のサービス・コンテナ・グループおよび前記接続制御モジュールに送信するステップと、
前記接続制御モジュールによって、前記セッション識別子と前記バックエンド・コンテナ・グループとの間の対応関係を記録するステップと、
前記第3のサイドカーによって、前記第1のサービス・コンテナ・グループから前記セッション識別子を取得し、前記セッション識別子に基づいて、前記接続制御モジュールによって記録された前記対応関係内の前記バックエンド・コンテナ・グループを決定し、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行した後に、前記別のデータパケットを前記バックエンド・コンテナ・グループに送信するステップと
をさらに含む、請求項20に記載の方法。

【請求項22】

前記サイドカー割り当てポリシーが第3のポリシーを含み、前記第3のポリシーは、前記サイドカーによってサービスされるオブジェクトの数が0であるときに前記サイドカークラスタ内のサイドカーが優先的に使用されることを示し、
前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送する前記ステップは、
前記接続制御モジュールによって、前記第1のサイドカーによってサービスされるオブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が0であるときに、前記第1のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するステップ
を含む、
請求項14または15に記載の方法。

【請求項23】

前記方法が、
前記接続制御モジュールによって、前記サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、前記オフラインサイドカーに関する情報を前記コンソールに送信するステップ
をさらに含む、請求項14から22のいずれか一項に記載の方法。

【請求項24】

前記トラフィック管理が、トラフィック制御、トラフィック保護、およびトラフィック観測を含む、請求項14から23のいずれか一項に記載の方法。

【請求項25】

プロセッサとメモリとを備える、コンテナグループを稼働させるためのノードであって、前記プロセッサは、前記メモリに格納された命令を実行して、請求項14から24のいずれか一項に記載の方法を実行するように構成される、ノード。

【請求項26】

コンピュータプログラム命令を含むコンピュータ可読記憶媒体であって、前記コンピュータプログラム命令がコンピューティング・デバイス・クラスタによって実行されると、前記コンピューティング・デバイス・クラスタは、請求項14から24のいずれか一項に記載の方法を実行する、コンピュータ可読記憶媒体。

【請求項27】

命令を含むコンピュータプログラム製品であって、前記命令がコンピューティング・デバイス・クラスタによって稼働すると、前記コンピューティング・デバイス・クラスタは、請求項14から24のいずれか一項に記載の方法を実行することが可能になる、コンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、参照によりその全体が本明細書に組み入れられる、2021年8月9日付で中国国家知識産権局に出願された、「NODE FOR RUNNING CONTAINER GROUP，AND CONTAINER GROUP MANAGEMENT SYSTEM AND METHOD」という名称の中国特許出願第202110910594．X号の優先権を主張するものである。

【0002】

本出願は、クラウドコンピューティングの分野に関し、特に、コンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法に関する。

【背景技術】

【0003】

サービスメッシュ（service mesh）技術では、マイクロサービスアーキテクチャ（microservice architecture）の分散アプリケーションにおける非機能トラフィック指向のサービスガバナンスロジックがサービスプロセスからサイドカー（sidecar）コンテナに取り除かれ、サービス間接続、保護、フロー制御、グレーリリース、および観測能力が非侵入的に提供されて、軽量サービスおよびインフラストラクチャベースのサービスガバナンスを実現する。加えて、サービスメッシュ技術は、従来のインターネットプロトコル（internet protocol、IP）ネットワークに基づくアプリケーションネットワーク技術である。したがって、サービスメッシュ技術では、サービス間の発見およびルーティングは、IPアドレスに基づいて直接実行されるのではなく、サービスのメタデータ情報（サービス名、バージョンなどを含むが、これらに限定されない）に基づいて実行される。

【0004】

ユーザ要件の発展に伴い、マイクロサービスの規模および呼び出しの複雑さが急速に増大する。マイクロサービスを効率的に管理し、連続稼働段階における運用および保守コストを削減する方法は、サービスメッシュ技術の進化における重要な問題である。

【発明の概要】

【課題を解決するための手段】

【0005】

本出願の実施形態は、コンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法を提供し、サービス・コンテナ・グループのためのサイドカーを選択し、サービス・コンテナ・グループに対してより良好なトラフィック管理を実行する。

【0006】

第1の態様によれば、本出願の一実施形態は、コンテナグループを稼働させるためのノードを提供する。接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが、ノード上で稼働する。サイドカークラスタは、少なくとも2つのサイドカーを含む。接続制御モジュールは、ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するように構成される。第1のサイドカーは、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するように構成される。

【0007】

この解決策では、接続制御モジュールは、コンソールによって送信されたサイドカー割り当てポリシーに従って少なくとも2つのサイドカーから第1のサービス・コンテナ・グループのためのサイドカーを選択し、選択されたサイドカーを使用して、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行し得、その結果、第1のサービス・コンテナ・グループは柔軟に管理されることができ、第1のサービス・コンテナ・グループに対してより良好なトラフィック管理が実行されることができ、それにより、第1のサービス・コンテナ・グループのサービスの高可用性能力が保証される。

【0008】

可能な一実装形態では、ノードは、第2のサービス・コンテナ・グループをさらに含む。接続制御モジュールは、サイドカー割り当てポリシーに従ってサイドカークラスタから第2のサイドカーを選択し、第2のサービス・コンテナ・グループによって送信されたデータパケットを第2のサイドカーに転送するようにさらに構成される。第2のサイドカーは、第2のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するように構成される。第2のサイドカーと第1のサイドカーとは、同じサイドカーであってもよいし、異なるサイドカーであってもよい。

【0009】

言い換えれば、接続制御モジュールは、サイドカー割り当てポリシーに従って少なくとも2つのサイドカーから第2のサービス・コンテナ・グループのためのサイドカーを選択し、選択されたサイドカーを使用して、第2のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行し得、その結果、第2のサービス・コンテナ・グループは柔軟に管理されることができ、第2のサービス・コンテナ・グループに対してより良好なトラフィック管理が実行されることができ、それにより、第2のサービス・コンテナ・グループのサービスの高可用性能力が保証される。

【0010】

可能な一実装形態では、第1のサイドカーに割り当てられるハードウェアリソースの仕様は、第2のサイドカーに割り当てられるハードウェアリソースの仕様よりも高く、サイドカー割り当てポリシーは、第1のポリシーを含み、第1のポリシーは、第1のサービス・コンテナ・グループが第1のサイドカーを優先的に使用することを示す。接続制御モジュールは、第1のポリシーに従ってサイドカークラスタから第1のサイドカーを選択するように特に構成される。

【0011】

言い換えれば、この実装形態では、異なるハードウェアリソース仕様を有するハードウェアリソースが設定されてもよい。サイドカー割り当てポリシーが、第1のサービス・コンテナ・グループが高いハードウェアリソース仕様を有するサイドカーを優先的に使用することを示すとき、高いハードウェアリソース仕様を有するサイドカーは、第1のサービス・コンテナ・グループのサービスのサービス品質を保証するために、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するために使用される。

【0012】

可能な一実装形態では、ノードは、第2のサービス・コンテナ・グループをさらに含み、サイドカー割り当てポリシーは、第2のポリシーをさらに含み、第2のポリシーは、第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示す。接続制御モジュールは、第1のサイドカーによってサービスされるオブジェクトの数を決定し、第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないとき、第2のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するようにさらに構成される。第1のサイドカーは、第1のサービス・コンテナ・グループによって送信されたデータパケットと第2のサービス・コンテナ・グループによって送信されたデータパケットとに対して同時にトラフィック管理を実行するようにさらに構成される。

【0013】

言い換えれば、この実装形態では、サイドカーによってサービスされるオブジェクトの数の上限値が設定され得る。サイドカーによって現在サービスされているオブジェクトの数が上限値を超えないとき、データパケットはサイドカーに継続的に割り当てられ、その結果、サイドカーはデータパケットに対してトラフィック管理を実行して、サイドカーの過負荷を回避し、サイドカーのリソース利用率を改善する。

【0014】

可能な一実装形態では、接続制御モジュールは、第1のサイドカーが故障した後、サイドカークラスタから第3のサイドカーを選択するか、またはノードに第3のサイドカーを作成するようにコンソールに通知し、第1のサービス・コンテナ・グループによって送信された別のデータパケットを第3のサイドカーに転送するように構成される。第3のサイドカーは、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行するように構成される。

【0015】

言い換えれば、この実装形態では、第1のサイドカーが故障した後、第1のサービス・コンテナ・グループに対して第3のサイドカーが再選択されてもよく、第3のサイドカーは、第1のサービス・コンテナ・グループのサービスの高可用性能力を保証するために、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を引き続き実行してもよい。

【0016】

可能な一実装形態では、第3のサイドカーは、第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または第3のサイドカーは、第1のサイドカーの複製バージョンである。

【0017】

言い換えれば、この実装形態では、第1のサイドカーが故障した後、第1のサービス・コンテナ・グループによって送信されたデータパケットに対するトラフィック管理を引き続き実行するために、第1のサイドカーと同じ機能を有するサイドカーが第1のサービス・コンテナ・グループに対して選択されてもよいし、第1のサイドカーよりも高いレベルを有するサイドカーが選択されてもよい。このようにして、第1のサービス・コンテナ・グループのサービスの高可用性能力が保証される。

【0018】

可能な一実装形態では、第1のサイドカーは、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループにデータパケットを送信するように構成される。

【0019】

言い換えれば、この実装形態では、第1のサイドカーは、バックエンド・コンテナ・グループのサービスを呼び出し、またはバックエンド・コンテナ・グループにサービスを提供するために、トラフィック管理が実行されるデータパケットをバックエンド・コンテナ・グループに送信し得る。

【0020】

可能な一実装形態では、第1のサイドカーは、セッション識別子を生成し、セッション識別子を第1のサービス・コンテナ・グループおよび接続制御モジュールに送信するようにさらに構成される。接続制御モジュールは、セッション識別子とバックエンド・コンテナ・グループとの間の対応関係を記録するように構成される。第3のサイドカーは、第1のサービス・コンテナ・グループからセッション識別子を取得し、セッション識別子に基づいて、接続制御モジュールによって記録された対応関係内のバックエンド・コンテナ・グループを決定し、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行した後に、別のデータパケットをバックエンド・コンテナ・グループに送信するように構成される。

【0021】

言い換えれば、この実装形態では、接続制御モジュールは、第1のサイドカーによって生成されたセッション識別子とバックエンド・コンテナ・グループとの間の対応関係を記録し得る。第3のサイドカーは、対応関係に基づいて、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行し、次いで、同じコンテナグループによって送信された異なるデータパケットが異なるサイドカーによって異なるバックエンド・コンテナ・グループに送信されるという問題を回避するために、別のデータパケットをバックエンド・コンテナ・グループに送信し得る。

【0022】

可能な一実装形態では、サイドカー割り当てポリシーは第3のポリシーを含み、第3のポリシーは、サイドカーによってサービスされるオブジェクトの数が0であるとき、サイドカークラスタ内のサイドカーが優先的に使用されることを示す。接続制御モジュールは、第1のサイドカーによってサービスされるオブジェクトの数を決定し、第1のサイドカーによってサービスされるオブジェクトの数が0であるとき、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するようにさらに構成される。

【0023】

可能な一実装形態では、接続制御モジュールは、サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、オフラインサイドカーに関する情報をコンソールに送信するようにさらに構成される。

【0024】

言い換えれば、この実装形態では、コンソールが稼働中のサイドカーを更新し、これに基づいてサイドカー割り当てポリシーを策定してコンテナグループを効果的に管理するように、オフラインサイドカーがコンソールにフィードバックされ得る。

【0025】

可能な一実装形態では、トラフィック管理は、トラフィック制御、トラフィック保護、およびトラフィック観測を含む。

【0026】

可能な一実装形態では、ノードは、仮想マシン、コンピュータ、またはベアメタルサーバである。

【0027】

第2の態様によれば、本出願の一実施形態は、第1の態様で提供されるコンソールおよびノードを含むコンテナグループ管理システムを提供する。

【0028】

第3の態様によれば、本出願の一実施形態は、ノード内のコンテナグループを管理するための方法を提供する。接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが、ノード上で稼働する。サイドカークラスタは、少なくとも2つのサイドカーを含む。本方法は、接続制御モジュールが、ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップと、第1のサイドカーが、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するステップと、を含む。

【0029】

可能な一実装形態では、第2のサービス・コンテナ・グループがノード上でさらに稼働する。本方法は、接続制御モジュールが、サイドカー割り当てポリシーに従ってサイドカークラスタから第2のサイドカーを選択し、第2のサービス・コンテナ・グループによって送信されたデータパケットを第2のサイドカーに転送するステップと、第2のサイドカーが、第2のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するステップと、をさらに含む。

【0030】

可能な一実装形態では、第1のサイドカーに割り当てられるハードウェアリソースの仕様は、第2のサイドカーに割り当てられるハードウェアリソースの仕様よりも高く、サイドカー割り当てポリシーは、第1のポリシーを含み、第1のポリシーは、第1のサービス・コンテナ・グループが第1のサイドカーを優先的に使用することを示す。サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択するステップは、第1のポリシーに従ってサイドカークラスタから第1のサイドカーを選択するステップを含む。

【0031】

可能な一実装形態では、第2のサービス・コンテナ・グループは、ノード上でさらに稼働し、サイドカー割り当てポリシーは、第2のポリシーをさらに含み、第2のポリシーは、第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示す。本方法は、接続制御モジュールが、第1のサイドカーによってサービスされるオブジェクトの数を決定し、その数が上限値を超えないとき、第2のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップと、第1のサイドカーが、第1のサービス・コンテナ・グループによって送信されたデータパケットと第2のサービス・コンテナ・グループによって送信されたデータパケットとに対してトラフィック管理を同時に実行するステップと、をさらに含む。

【0032】

可能な一実装形態では、本方法は、第1のサイドカーが故障した後で、接続制御モジュールが、サイドカークラスタから第3のサイドカーを選択するか、またはノードに第3のサイドカーを作成するようにコンソールに通知し、第1のサービス・コンテナ・グループによって送信された別のデータパケットを第3のサイドカーに転送するステップと、第3のサイドカーが、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行するステップと、をさらに含む。

【0033】

可能な一実装形態では、第3のサイドカーは、第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または第3のサイドカーは、第1のサイドカーの複製バージョンである。

【0034】

可能な一実装形態では、本方法は、第1のサイドカーが、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループにデータパケットを送信するステップをさらに含む。

【0035】

可能な一実装形態では、本方法は、第1のサイドカーがセッション識別子を生成し、セッション識別子を第1のサービス・コンテナ・グループおよび接続制御モジュールに送信するステップと、接続制御モジュールが、セッション識別子とバックエンド・コンテナ・グループとの間の対応関係を記録し、第3のサイドカーが、第1のサービス・コンテナ・グループからセッション識別子を取得し、セッション識別子に基づいて、接続制御モジュールによって記録された対応関係内のバックエンド・コンテナ・グループを決定し、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行した後に、別のデータパケットをバックエンド・コンテナ・グループに送信するステップと、をさらに含む。

【0036】

可能な一実装形態では、サイドカー割り当てポリシーは第3のポリシーを含み、第3のポリシーは、サイドカーによってサービスされるオブジェクトの数が0であるとき、サイドカークラスタ内のサイドカーが優先的に使用されることを示す。サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップは、接続制御モジュールが、第1のサイドカーによってサービスされるオブジェクトの数を決定し、第1のサイドカーによってサービスされるオブジェクトの数が0であるとき、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップ、を含む。

【0037】

可能な一実装形態では、本方法は、接続制御モジュールが、サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、オフラインサイドカーに関する情報をコンソールに送信するステップ、をさらに含む。

【0038】

可能な一実装形態では、トラフィック管理は、トラフィック制御、トラフィック保護、およびトラフィック観測を含む。

【0039】

第4の態様によれば、本出願の一実施形態は、プロセッサおよびメモリを含む、コンテナグループを稼働させるためのノードを提供する。プロセッサは、第2の態様で提供される方法を実行するために、メモリに格納された命令を実行するように構成される。

【0040】

第5の態様によれば、本出願の一実施形態は、コンピュータプログラム命令を含むコンピュータ可読記憶媒体を提供する。コンピュータプログラム命令がコンピューティング・デバイス・クラスタによって実行されると、コンピューティング・デバイス・クラスタは、第1の態様で提供される方法を実行する。

【0041】

第6の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。命令がコンピューティング・デバイス・クラスタによって稼働すると、コンピューティング・デバイス・クラスタは、第1の態様で提供される方法を実行することが可能になる。

【0042】

本出願の実施形態で提供されるコンテナグループを稼働させるためのノード、ならびにコンテナグループ管理システムおよび方法によれば、サイドカーは、コンソールによって送信されたサイドカー割り当てポリシーに従って、少なくとも2つのサイドカーからサービス・コンテナ・グループのために選択されてもよく、選択されたサイドカーは、サービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するために使用され、その結果、サービス・コンテナ・グループは柔軟に管理されることができ、サービス・コンテナ・グループに対してより良好なトラフィック管理が実行されることができ、それによってサービス・コンテナ・グループのサービスの高可用性能力が保証される。

【図面の簡単な説明】

【0043】

【図1】本出願の一実施形態によるコンテナグループ管理システムの構造の概略図である。

【図2】本出願の一実施形態によるコンテナグループを稼働させるためのノードの構造の概略図である。

【図3A】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図3B】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図4A】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図4B-1】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図4B-2】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図5A】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図5B】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図5C】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図6A】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図6B】本出願の一実施形態によるコンテナグループ管理フレームワークの概略図である。

【図6C-1】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図6C-2】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図7】本出願の一実施形態によるコンテナグループ管理方法のフローチャートである。

【図8】本出願の一実施形態によるノードの概略ブロック図である。

【発明を実施するための形態】

【0044】

以下、本発明の実施形態における技術的解決策を、添付の図面を参照して説明する。説明される実施形態は、本明細書の実施形態のすべてではなく一部にすぎないことは明らかである。

【0045】

本明細書の説明において、「一実施形態」、「いくつかの実施形態」などへの言及は、本明細書の1つまたは複数の実施形態が、実施形態を参照して説明される特定の特徴、構造、または特性を含むことを示す。したがって、本明細書の異なる箇所に現れる「一実施形態では」、「いくつかの実施形態では」、「いくつかの他の実施形態では」や「他の実施形態では」などの記載は、同じ実施形態を指すことを必ずしも意味していない。代わりに、これらの記述は、別の方法で特に強調されない限り、「すべてではないが1つまたは複数の実施形態」を意味する。

【0046】

本明細書の説明では、別段に指定されない限り、「／」は「または」を意味する。例えば、A／Bは、AまたはBを表し得る。本明細書では、「および／または」は、関連付けられた対象間の関連付け関係のみを説明し、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、Aのみが存在する、AとBの両方が存在する、およびBのみが存在する、という3つの場合を表し得る。加えて、本明細書の実施形態の説明において、「複数の」は、2つまたは3つ以上を意味する。

【0047】

本明細書の説明では、「第1」および「第2」という用語は単に説明を意図しており、相対的重要性の表示または含意、あるいは示された技術的特徴の数量の暗示的な表示として理解されるべきではない。したがって、「第1の」または「第2の」によって限定される特徴は、1つまたは複数の特徴を明示的または暗示的に含む場合がある。「備える」、「含む」、「有する」という用語、およびそれらの変形はすべて、別の方法で特に強調されない限り、「含むが、限定されない」を意味する。

【0048】

マイクロサービスアーキテクチャは、複雑なシステムを複数の小さなサービスまたはアプリケーションに分割するサービス指向アーキテクチャ（service oriented architecture、SOA）である。小さなサービスまたはアプリケーションは、マイクロサービスと呼ばれ得る。各マイクロサービスは、1つの独立したサービスロジックを実装する役割を担う。マイクロサービスは、サービス機能に基づいて構築され、独立して配備されてもよい。マイクロサービスは、一連の機能を提供するために互いに依存している。マイクロサービスは理解および修正されるべきであり、これにより言語およびフレームワークの選択が柔軟になる。マイクロサービスは、コンテナ（container）内で稼働してもよい。互いに依存性の高い複数のコンテナが1つのコンテナグループを形成してもよい。例えば、K8S（kubernetes）システムでは、複数のコンテナが1つのpodにカプセル化されてもよい。すなわち、コンテナグループはpodである。

【0049】

本出願の実施形態では、マイクロサービスを稼働させるためのコンテナは、サービスコンテナと呼ばれ得る。サイドカーは、コンテナまたはプロセスを使用して実装され得る。サイドカーがコンテナを使用して実装されるとき、サイドカーはサイドカーコンテナと呼ばれることもある。

【0050】

マイクロサービスアーキテクチャでは、サービスガバナンスは、SOAガバナンス（service－oriented architecture governance、SOA governance）と呼ばれることもあり、マイクロサービスアーキテクチャの採用および実装プロセスを管理するために使用される。マイクロサービスアーキテクチャに基づくサービスメッシュでは、サイドカーによってサービスガバナンスが実行され得る。K8S（Kubernetes）システムでは、サイドカーは、サイドカー機能を有するコンテナであり、サイドカーは、サービスコンテナに対するトラフィックサービスガバナンス機能を提供する。

【0051】

解決策では、podレベルのサイドカーが配備される。具体的には、各podは1つのサイドカーに対応し、サイドカーはpodに対してサービスガバナンスを実行するように構成される。この解決策では、異なるサイドカーは異なるpodに対応する。サイドカーが故障している場合、サイドカーに対応するpodのみが影響を受け、他のポッドは影響を受けない。この解決策は、サービスの高可用性能力を保証するのに役立つと言える。しかしながら、この解決策では、大量のpodが配備され、大量のサイドカーも配備される場合、サイドカーによって占有されるコンピューティングリソースを無視することはできず、大きなリンク遅延などの問題が発生する可能性がある。

【0052】

別の解決策では、ノードレベルサイドカーが配備される。具体的には、1つのサイドカーが1つのノードに配備されて、ノード上の複数のpodに対してサービスガバナンスを実行する。この解決策では、サイドカーが故障している場合、ノード上の複数のpodが影響を受ける。その結果、サービスの高可用性能力が大きく影響される。

【0053】

前述の技術的問題に対して、本出願の実施形態は、コンテナグループ管理システムを提供する。図1に示すように、管理システムは、ノード100、ノード200などの複数のノードを含んでもよく、複数のノードに接続されたコンソール300をさらに含んでもよい。コンソール300は、複数のノードを管理してもよく、例えば、複数のノードのいずれかにサイドカー割り当てポリシーを送信してもよく、その結果、ノードは、サイドカー割り当てポリシーに従ってノード内のサービス・コンテナ・グループにサイドカーを割り当て、サービス・コンテナ・グループによって送信されたデータパケットに対してより良好なトラフィック管理を実行し、サービスの高可用性能力を実装することができる。

【0054】

いくつかの実施形態では、割り当てポリシーは、コンソール300上で、管理者またはノードが位置するデータセンターのテナントによって構成されてもよい。したがって、コンテナグループは柔軟に管理されることができる。

【0055】

以下では、本出願の実施形態における図1に示す管理システム内のノードの一例を説明するために、ノード100を例として使用する。

【0056】

いくつかの実施形態では、ノード100は、仮想マシン（Virtual Machine、VM）であってもよい。

【0057】

いくつかの実施形態では、ノード100は、複数のハードウェア構成要素、例えば、1つまたは複数のプロセッサ（例えば、中央処理装置（central processing unit、CPU））および1つまたは複数のメモリを有してもよい。ノード100のハードウェア構成要素は、ノード100にデータコンピューティングおよびデータ記憶能力を提供してもよい。一例では、ノード100はコンピュータであってもよい。別の例では、ノード100はベアメタルサーバであってもよい。

【0058】

図2を参照されたい。接続制御モジュール110、サイドカークラスタ120、およびサービス・コンテナ・グループ・クラスタ130は、ノード100上で稼働し得る。サイドカークラスタ120は、サイドカー121、サイドカー122、およびサイドカー123などの少なくとも2つのsidecarを含み得る。サービス・コンテナ・グループ・クラスタ130は、サービス・コンテナ・グループ131を含み得る。サービス・コンテナ・グループ131は、1つまたは複数のコンテナを含み得、アプリケーションまたはマイクロサービスは、コンテナ上で稼働し得る。接続制御モジュール110は、コンソール300によって送信されたサイドカー割り当てポリシーAを受信し得る。サービス・コンテナ・グループ131がトラフィック管理要件を有するとき、接続制御モジュール110は、割り当てポリシーAに従ってサイドカークラスタ120からサービス・コンテナ・グループ131のサイドカーを選択し得、例えば、サイドカー121を選択し得る。次いで、接続制御モジュール110は、サービス・コンテナ・グループ131によって送信されたデータパケットをサイドカー121に転送し得る。サイドカー121は、データパケットに対してトラフィック管理を実行し得る。

【0059】

一例では、トラフィック管理は、具体的には、トラフィック制御であり得る。トラフィック制御は、トラフィックパス、トラフィック拒否、トラフィック複製、およびトラフィック着色の任意の1つまたは任意の組み合わせを含み得る。一例では、トラフィック管理は、具体的には、トラフィック保護であり得る。トラフィック保護は、データパケットに対して暗号化、復号化などを実行することを含み得る。一例では、トラフィック管理は、具体的には、トラフィック観測であり得る。トラフィック観測は、コンソール300に呼び出しチェーンなどを描くことを含み得る。

【0060】

いくつかの実施形態では、サイドカーリストが接続制御モジュールのために構成され得る。データプレーンプロキシリストは、稼働状態のサイドカーに関する情報を含み得る。サイドカーに関する情報は、サイドカーの識別子（例えば、プロセス識別情報（identity、ID））およびサイドカーのリスニングポートを含み得る。サイドカーのリスニングポートは、サイドカーのインバウンドポートと呼ばれることもある。サービス・コンテナ・グループ131によって送信されたデータパケットは、サイドカー121がデータパケットに対してトラフィック管理を実行できるように、サイドカー121のリスニングポートを介してサイドカー121に送信され得る。

【0061】

いくつかの実施形態では、サイドカー121に割り当てられるハードウェアリソースの仕様は、サイドカー122に割り当てられるハードウェアリソースの仕様よりも高く、サイドカー割り当てポリシーAはポリシーA1を含み、ポリシーA1は、サービス・コンテナ・グループ131がサイドカー121を優先的に使用することを示す。したがって、接続制御モジュール110は、ポリシーA1に従ってサイドカークラスタ120からサイドカー121を選択し得、その結果、サイドカー121は、サービス・コンテナ・グループ131によって送信されたデータパケットに対してサービスガバナンス（すなわち、トラフィック管理）を実行する。本実施形態の具体的な実施プロセスは、以下の実施形態2で具体的に説明され、ここでは詳細は説明されない。

【0062】

いくつかの実施形態では、図2をさらに参照する。サービス・コンテナ・グループ・クラスタ130は、サービス・コンテナ・グループ132をさらに含み得る。サービス・コンテナ・グループ132がトラフィック管理要件を有するとき、接続制御モジュール110は、割り当てポリシーAに従ってサイドカークラスタ120からサイドカー122をさらに選択し、サービス・コンテナ・グループ132によって送信されたデータパケットをサイドカー122に転送し得る。次いで、サイドカー122は、データパケットに対してトラフィック管理を実行し得る。

【0063】

いくつかの実施形態では、サイドカークラスタ120内の同じサイドカーは、複数のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を同時に実行し得る。例えば、サービス・コンテナ・グループ・クラスタ130がサービス・コンテナ・グループ132をさらに含み得るように設定され得る。サイドカー割り当てポリシーAはポリシーA2をさらに含み、ポリシーA2は、サイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示し得る。サイドカーによってサービスされるオブジェクトは、サイドカーのトラフィック管理サービスを受け入れるサービス・コンテナ・グループである。言い換えれば、サイドカーがサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行する場合、サービス・コンテナ・グループはサイドカーによってサービスされるオブジェクトである。サイドカーの上限値は、サイドカーが同時にトラフィック管理を実行することができるサービス・コンテナ・グループの最大数である。接続制御モジュールは、サイドカー121によってサービスされるオブジェクトの数を決定し、サイドカー121によってサービスされるオブジェクトの数がサイドカー121の上限値を超えないとき、サービス・コンテナ・グループ132によって送信されたデータパケットをサイドカー121に転送し得る。次いで、サイドカー121は、サービス・コンテナ・グループ131によって送信されたデータパケットとサービス・コンテナ・グループ132によって送信されたデータパケットとに対してトラフィック管理を同時に実行し得る。

【0064】

いくつかの実施形態では、サイドカーが故障した後、例えば、サイドカーがクラッシュ（crash）または再起動した後、新たに選択されたサイドカーが、故障したサイドカーによってサービスされているオブジェクトに対してトラフィック管理を実行し続けるように、サイドカーによってサービスされているオブジェクトに対してサイドカーが再選択され得る。サイドカー121が引き続き一例として使用される。上述したように、サイドカー121が故障する前に、サイドカー121は、サービス・コンテナ・グループ131によって送信されたデータパケットに対してトラフィック管理を実行し得る。サイドカー121が故障した後、接続制御モジュール110は、サービス・コンテナ・グループ131のサイドカーを再決定し得る。再決定されたサイドカーは、サービス・コンテナ・グループ131によって送信されたデータパケットに対してトラフィック管理を実行し得る。例えば、サービス・コンテナ・グループ131のサイドカーを再決定することは、具体的には以下のとおりであり得る：接続制御モジュール110は、サイドカークラスタ120から、サービス・コンテナ・グループ131のデータパケットに対してトラフィック管理を実行するためのサイドカーを再選択する。例えば、サイドカークラスタ120がサイドカー123を含み、接続制御モジュール110がサイドカークラスタ120からサイドカー123を選択するように設定されてもよく、その結果、サイドカー123はサービス・コンテナ・グループ131によって送信されたデータパケットに対してトラフィック管理を実行する。具体的には、サービス・コンテナ・グループ131によって送信されたデータパケットは、サイドカー123がデータパケットに対してトラフィック管理を実行するように、サイドカー123に送信され得る。例えば、サービス・コンテナ・グループ131のサイドカーを再決定することは、具体的には以下のとおりであり得る：接続制御モジュールは、コンソール300を使用してノード100内にサイドカー123を作成し、次いで、サイドカー123がデータパケットに対してトラフィック管理を実行できるように、サービス・コンテナ・グループ131によって送信されたデータパケットをサイドカー123に送信する。ノード100にサイドカー123を作成する具体的なプロセスは、以下の実施形態1で具体的に説明され、ここでは詳細は説明されない。

【0065】

いくつかの実施形態では、サイドカー123は、サイドカー121に基づいて機能がアップグレードされた新バージョンのサイドカーであってもよい。サイドカーのバージョンアップグレードプロセスは以下で具体的に説明され、ここでは詳細は説明されない。

【0066】

いくつかの実施形態では、サイドカー123はサイドカー121の複製バージョンである。言い換えれば、コンソール300は、ノード100において、サイドカー121と同じ機能を有するサイドカーを再作成してもよい。

【0067】

いくつかの実施形態では、サービス・コンテナ・グループ131によって送信されたデータパケットに対してトラフィック管理を実行した後、サイドカー121は、データパケットをバックエンド・コンテナ・グループに送信する。一例では、バックエンド・コンテナ・グループは、別のノード、例えばノード200上のサービス・コンテナ・グループであってもよい。一例では、バックエンド・コンテナ・グループは、ノード100上のサービス・コンテナ・グループ131以外のサービス・コンテナ・グループであってもよい。

【0068】

これらの実施形態の一例では、サイドカー121は、セッション識別子をさらに生成し、セッション識別子をサービス・コンテナ・グループ131および接続制御モジュール110に送信し得る。セッション識別子は、サービス・コンテナ・グループ131とバックエンド・コンテナ・グループとの間のセッション識別子であってもよい。接続制御モジュール110は、セッション識別子とバックエンド・コンテナ・グループとの間の対応関係を記録し得る。サービス・コンテナ・グループ131によって送信されたデータパケットに対してトラフィック管理を実行するとき、サイドカー123は、サービス・コンテナ・グループ131からセッション識別子を取得し、次いで、セッション識別子とバックエンド・コンテナ・グループとの対応関係およびサービス・コンテナ・グループ131から取得されたセッション識別子に基づいてバックエンド・コンテナ・グループを決定し得、その結果、サイドカー123は、サービス・コンテナ・グループ131によって送信された新しいデータパケットに対してトラフィック管理を実行した後に、新しいデータパケットをバックエンド・コンテナ・グループに送信する。新しいデータパケットは、セッション識別子とバックエンド・コンテナ・グループとの間の対応関係、およびサービス・コンテナ・グループ131から取得されたセッション識別子に基づいて、サイドカー123がバックエンド・コンテナ・グループを決定した後にサービス・コンテナ・グループ131によって送信されたデータパケットであってもよい。以下の実施形態4では具体的な説明が具体的に提供され、ここでは詳細は説明されない。

【0069】

いくつかの実施形態では、サイドカー割り当てポリシーAはポリシーA3を含んでもよく、ポリシーA3は、サイドカーによってサービスされるオブジェクトの数が0であるときにサイドカークラスタ120内のサイドカーが優先的に使用されることを示す。接続制御モジュール110は、サイドカー121によってサービスされるオブジェクトの数を決定し、サイドカー121によってサービスされるオブジェクトの数が0であるとき、サービス・コンテナ・グループ131によって送信されたデータパケットをサイドカー121に転送し得る。サービスされるオブジェクトは、サイドカーによってサービスされるサービス・コンテナ・グループである。詳細については、以下の実施形態2で説明するコンテンツ実装を参照されたく、ここでは詳細は説明されない。

【0070】

いくつかの実施形態では、接続制御モジュール110は、サイドカークラスタ120内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、オフラインサイドカーに関する情報をコンソール300に送信するようにさらに構成される。以下の実施形態1では具体的な説明が提供され、ここでは詳細は説明されない。

【0071】

本出願の実施形態で提供されるノード上で複数のサイドカーが稼働してもよく、ノードは、割り当てポリシーに従って複数のサイドカーからサービス・コンテナ・グループ用のサイドカーを選択し、次いで、選択されたサイドカーを使用して、サービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行してもよく、その結果、サービス・コンテナ・グループのデータパケットに対してより良好なトラフィック管理が実行されることができ、サービスの高可用性能力が実装されることができる。

【0072】

以下では、特定の実施形態において、本出願の実施形態で提供されるノードおよびコンテナグループ管理解決策を具体的に説明する。

【0073】

実施形態1
図3Aを参照されたい。この実施形態は、ノード100を提供する。サービス・コンテナ・グループ・クラスタ130は、ノード100上で稼働してもよく、サービス・コンテナ・グループ131、サービス・コンテナ・グループ132などの複数のサービス・コンテナ・グループを含む。sidecarクラスタ120は、ノード100上でさらに稼働してもよく、sidecar 121、sidecar 122、sidecar 123などの複数のsidecarを含む。例えば、複数のsidecarの各々は、異なるハードウェアリソースにバインディングされてもよく、例えば、1つまたは複数の中央処理装置（central processing unit、CPU）にバインディングされてもよく、または別のコンピューティングモジュール（例えば、暗号化および復号化のために特別に使用されるハードウェア、またはグラフィックス処理装置（graphics processing unit、GPU））にバインドされてもよい。接続制御モジュール110は、ノード100上でさらに稼働する。例えば、接続制御モジュール110は、プロトコルスタック111およびsidecar起動マネージャ112を含んでもよい。

【0074】

ノード100は、ネットワークにアクセスしてもよく、ネットワークは、バックエンド・コンテナ・グループ210、バックエンド・コンテナ・グループ220などの複数のバックエンド・コンテナ・グループを含んでもよい。一例では、バックエンド・コンテナ・グループは、ネットワーク内のノード100以外のノード上で稼働してもよい。別の例では、バックエンド・コンテナ・グループは、ノード100上で稼働してもよい。ノード100内のサービス・コンテナ・グループによって送信されたデータパケットに対してsidecarによってトラフィック管理が実行された後、データパケットは、バックエンド・コンテナ・グループのサービスを呼び出すか、またはバックエンド・コンテナ・グループにサービスを提供するために、バックエンド・コンテナ・グループに送信され得る。

【0075】

ネットワークは、コンソール300をさらに含んでもよい。コンソール300は、管理担当者または運用および保守要員の操作を受信し、操作に応じてノード100およびネットワーク内の別のノードを制御し得る。例えば、コンソール300は、sidecarがサービスリストに基づいてトラフィック管理を実行できるように、サービスリストを同期させるためにsidecarにサービスリストを送信してもよい。別の例では、コンソール300は、サイドカー割り当てポリシーAを接続制御モジュール110に送信し得、その結果、接続制御モジュール110は、サイドカー割り当てポリシーAに従ってsidecarクラスタからサービス・コンテナ・グループのsidecarを選択する。選択されたsidecarは、サービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行する。

【0076】

接続制御モジュール110は、ノード100内の複数のsidecarをマルチアクティブ方式で管理してもよい。言い換えれば、複数のsidecarは、同時に稼働状態または作動状態にあってもよい。

【0077】

例えば、同じsidecarは、複数のサービス・コンテナ・グループのリンクのトラフィック管理を同時に提供し得る。一例では、図3Aに示すように、sidecar 121は、リンク1311、リンク1312、およびリンク1321のトラフィック管理を同時に提供し得る。リンク1311およびリンク1312は、サービス・コンテナ・グループ131からのリンクであり、リンク1321は、サービス・コンテナ・グループ132からのリンクである。

【0078】

例えば、異なるsidecarは、同じサービス・コンテナ・グループの異なるリンクのトラフィック管理を同時に提供し得る。一例では、図3Aに示すように、sidecar 121は、サービス・コンテナ・グループ132からのリンク1321のトラフィック管理を提供し得る。sidecar 123は、サービス・コンテナ・グループ132からのリンク1322のトラフィック管理を提供し得る。

【0079】

この実施形態では、サービス・コンテナ・グループのリンクのためのトラフィック管理を提供することは、リンクを介してサービス・コンテナ・グループによって送信されたデータパケットのためのトラフィック管理を具体的に提供することであってもよい。例えば、データパケットに対して、トラフィック制御、トラフィック保護、およびトラフィック観測が実行される。トラフィック制御は、トラフィックパス、トラフィック拒否、トラフィック複製、およびトラフィック着色の任意の1つまたは任意の組み合わせを含み得る。

【0080】

引き続き図3Aを参照されたい。ノード100は、プロトコルスタック111をさらに含んでもよく、プロトコルスタックは、サービス・コンテナ・グループが接続要求を生成するときに、サービス・コンテナ・グループと割り当てられたsidecarとの間のリンクを確立するために、sidecarクラスタ120からの接続要求にsidecarを割り当ててもよく、その結果、割り当てられたsidecarは、リンクを介してサービス・コンテナ・グループによって送信されたデータパケットのトラフィック管理を提供することができる。

【0081】

以下では、接続要求にsidecarを割り当てる解決策について説明する。

【0082】

プロトコルスタック111は、sidecarリストを呼び出してもよく、sidecarリスト読み取ってもよい。例えば、図3Aに示すように、sidecarリストがプロトコルスタック111に設定されてもよい。sidecarリストは、稼働状態にあるsidecarに関する情報を含んでもよい。sidecarに関する情報は、sidecarの識別子（例えば、プロセス識別情報（identity、ID））、sidecarのバージョン情報、およびsidecarのリスニングポートを含んでもよい。sidecarのバージョン情報は、sidecarバージョンを表す。一例では、sidecarのバージョン情報はバージョン番号であり得る。バージョン番号の値は、高バージョンまたは低バージョンを表す。sidecarのリスニングポートはまた、sidecarのインバウンドポートであってもよい。接続要求は、接続要求を生成するソース・サービス・コンテナ・グループとsidecarとの間のリンクを確立できるように、sidecarのリスニングポートを介してsidecarに送信され得る。

【0083】

例えば、sidecarに関する情報は、sidecarの現在の接続数をさらに含み得る。現在の接続数は、sidecarに現在接続されているリンクの数を表す。一例として、図3Aに示すsidecar 121が使用される。sidecar 121は、リンク1311、リンク1312、およびリンク1321に接続されているので、現在の接続数は3である。

【0084】

例えば、sidecarに関する情報は、sidecarに現在接続されているサービス・コンテナ・グループの識別子をさらに含み得る。サービス・コンテナ・グループの識別子は、サービス・コンテナ・グループを一意に識別する。したがって、プロトコルスタック111は、sidecarに現在接続されているサービス・コンテナ・グループの識別子に基づいて、sidecarに現在接続されているサービス・コンテナ・グループを決定し得る。sidecarに接続されているサービス・コンテナ・グループは、sidecarとのリンクを有するサービス・コンテナ・グループである。例えば、図3Aに示すように、サービス・コンテナ・グループ131は、sidecar 121に現在接続されているサービス・コンテナ・グループである。

【0085】

例えば、sidecarに関する情報は、sidecarにバインドされたハードウェアリソースに関する情報（例えば、CPU情報およびハードウェア加速が有効であるか否かを示す情報）をさらに含み得る。別の実施形態では、sidecarリストは、本明細書に1つずつ列挙されていない他の情報をさらに含み得る。

【0086】

サービス・コンテナ・グループPが接続要求P1を生成すると、接続要求P1はプロトコルスタック111に送信され得る。プロトコルスタック111は、sidecarリストに記録されたsidecar情報を読み出し、sidecar情報に基づいて接続要求P1にsidecarを割り当て得る。以下に具体的な説明を提供する。

【0087】

例示的な例では、プロトコルスタック111は、サービス・コンテナ・グループPがsidecarに現在接続されているサービス・コンテナ・グループであるかどうかを決定し、具体的には、サービス・コンテナ・グループPとsidecarリスト内のsidecarとの間に1つまたは複数のリンクが既に存在しているかどうかを決定し得る。

【0088】

サービス・コンテナ・グループPとsidecarリスト内のsidecarとの間に1つまたは複数のリンクが既に存在している場合、サービス・コンテナ・グループPとsidecarB1との間に1つまたは複数のリンクが既に存在していると設定され得る。この場合、sidecarB1は、接続要求P1に割り当てられ得る。さらに、プロトコルスタック111は、sidecarB1に接続要求P1を送信し得る。例えば、プロトコルスタック111は、sidecarB1のリスニングポートを介して接続要求P1を送信してもよく、その結果、接続要求P1はsidecarB1に送信されることができる。sidecarB1が接続要求P1を受信すると、接続要求P1に基づいて、sidecarB1とサービス・コンテナ・グループPとの間に別のリンクが確立され得る。サービス・コンテナ・グループPは、リンクを介してsidecarB1にデータパケットを送信し得る。データパケットを受信した後、sidecarB1はデータパケットに対してトラフィック管理を実行し得る。

【0089】

サービス・コンテナ・グループPとsidecarリスト内のsidecarとの間にリンクが存在しない場合、具体的には、サービス・コンテナ・グループPがsidecarリスト内のいずれかのsidecarに現在接続されているサービス・コンテナ・グループではない場合、sidecarリスト内の各sidecarの現在の接続数に基づいて、現在の接続数が最も少ないsidecarが決定され得る。sidecarリスト内のsidecarB2の現在の接続数が最小であると設定され得る。sidecarB2は、接続要求P1に割り当てられ得る。sidecarB2が接続要求P1を受信すると、接続要求P1に基づいて、sidecarB2とサービス・コンテナ・グループPとの間に別のリンクが確立され得る。サービス・コンテナ・グループPは、リンクを介してsidecarB2にデータパケットを送信し得る。データパケットを受信した後、sidecarB2はデータパケットに対してトラフィック管理を実行し得る。

【0090】

例示的な例では、接続要求P1を受信すると、プロトコルスタック111は、sidecarリストに新バージョンのsidecarが存在するかどうかを決定し得る。具体的には、sidecarリスト内のすべてのsidecarのバージョンが同じであるかどうかが決定され得る。sidecarリスト内の1つまたは複数のsidecarのバージョンが別のsidecarのバージョンよりも高い場合、1つまたは複数のsidecarは新バージョンのsidecarであると決定され得る。sidecarリスト内のすべてのsidecarのバージョンが同じである場合、sidecarリストに新バージョンのsidecarが存在しないと決定され得る。

【0091】

sidecarリストに新バージョンのsidecarが存在するとき、新バージョンのsidecarが接続要求P1に割り当てられ得る。新バージョンのsidecarが接続要求P1を受信すると、接続要求P1に基づいて、新バージョンのsidecarとサービス・コンテナ・グループPとの間に別のリンクが確立される。サービス・コンテナ・グループPは、リンクを介して新バージョンのsidecarにデータパケットを送信し得る。データパケットを受信した後、新バージョンsidecarはデータパケットに対してトラフィック管理を実行し得る。

【0092】

例示的な例では、ノード100内のsidecarは、ホットアップグレードされてもよい。言い換えれば、sidecarは、ユーザが意識することなくアップグレードされてもよい。

【0093】

以下では、図3Bを参照して、実施形態1で提供されるsidecar割り当て解決策およびsidecarアップグレード解決策のより詳細な説明を提供する。

【0094】

運用および保守要員は、ノード100に新しいsidecarを作成するために、コンソール300上でsidecar作成情報を構成し得る。sidecar作成情報は、バージョン情報およびハードウェアリソース情報を含み得る。

【0095】

sidecar作成情報は、置き換えられたsidecarに関する情報をさらに含み得、ノード100内のどのsidecarが新しく作成されたsidecarによって置き換えられたかを示す。交換されたsidecarは、ノード100において既に稼働状態にあるsidecarであってもよい。交換されたsidecarに関する情報は、交換されたsidecarの識別子、交換されたsidecarの残りの稼働持続時間などを含み得る。例えば、複数の交換されたsidecarがあるとき、複数の交換されたsidecarが同時にオフラインになるために接続要求の数が突然増加するという問題を防止または緩和するために、異なる交換されたsidecarに対して異なる残りの稼働持続時間が設定され得る。加えて、sidecar作成情報が交換されたsidecarに関する情報を含むとき、sidecar作成情報はsidecarアップグレード情報とも呼ばれることもあり、言い換えれば、sidecar作成情報はsidecarをアップグレードするために使用され得る。

【0096】

上記の構成が実行された後、コンソール300は、sidecar作成情報をsidecar起動マネージャ112に送信するステップ401を実行し得る。

【0097】

sidecar起動マネージャ112は、sidecar作成情報に基づいて新しいsidecarを作成し得る。sidecar作成情報がバージョン情報を含むとき、sidecar起動マネージャ112は、バージョン情報と一致するsidecarを作成する。言い換えれば、新たに作成されたsidecarのバージョンは、バージョン情報と一致する。sidecarを作成するプロセスにおいて、sidecar起動マネージャ112は、リスニングポートを新しいsidecarに割り当てるステップ402をさらに実行し得る。例えば、sidecar起動マネージャ112は、ノード100内のリスニングポート占有状態に基づいて、リスニングポートを新しいsidecarに割り当て得る。リスニングポートが割り当てられると、リスニングポート番号を新しいsidecarに割り当ててリスニングポート割り当てを完了し得る。sidecar起動マネージャ112は、新しいsidecarを起動するステップ403を実行し得る。このようにして、新しいsidecarがsidecarの側面に作成される。

【0098】

新しいsidecarは、新しいsidecarが初期化を実行し、稼働状態に入り得るステップ404を実行し得る。

【0099】

新しいsidecarがステップ404を実行した後、sidecar起動マネージャ112は、sidecarリストを更新するステップ407を実行し得、更新されたsidecarリストをプロトコルスタック111に送信し得る。sidecarリストを更新するステップは、sidecarリストに新しいsidecarに関する情報（例えば、リスニングポート、バージョン情報、現在の接続数、現在接続されているサービス・コンテナ・グループの識別子、およびハードウェアリソース情報などの情報）を追加するステップを含む。例えば、sidecar起動マネージャ112は、更新されたsidecarリストをEbpf（extended BPF）マップに含め、次いでEbpf mapをプロトコルスタック111に送信して、更新されたsidecarリストをプロトコルスタック111に送信してもよい。

【0100】

いくつかの実施形態では、新しいsidecarがステップ404を実行した後、sidecar起動マネージャ112は、sidecarの稼働状態を監視するステップ406を実行し得る。いくつかの実施形態では、sidecar起動マネージャ112は、sidecar起動マネージャ112とsidecarとの間にドメインソケット（domain socket）持続接続を確立し、ドメインソケット持続接続を介してsidecarの稼働状況を監視し、監視を通じて得られた結果に基づいてステップ407またはステップ408を実行し得る。ステップ408において、sidecar起動マネージャ112は、sidecar更新情報をコンソール300に送信し得、sidecar更新情報は、新しいsidecarの稼働状況、識別情報などを含む。

【0101】

加えて、sidecar作成情報が交換されたsidecarに関する情報を含むとき、新しいsidecarは、ステップ404でドメインソケット（domain socket）監視をさらに開始し得る。加えて、新しいsidecarは、新しいsidecarがドメインソケットを使用して交換されたsidecarに接続されるステップ405をさらに実行してもよい。新しいsidecarは、新しいsidecarと交換されたsidecarとの間のドメインソケットを使用して、交換されたsidecarの稼働状態を監視し、交換されたsidecarにオフライン命令を送信して、交換されたsidecarにオフラインになるように示し得る。交換されたsidecarに関する情報が交換されたsidecarの残りの稼働持続時間を含むとき、新しいsidecarは、初期化が完了した後にタイミングを開始する。タイミングが残りの稼働持続時間に達すると、新しいsidecarは、交換されたsidecarをオフラインにするステップ409を実行し得る。具体的には、新しいsidecarは、新しいsidecarと交換されたsidecarとの間のドメインソケットを使用して、交換されたsidecarにオフライン命令を送信し得る。交換されたsidecarは、命令に応答してオフラインになり得る。

【0102】

加えて、ノード100内の1つまたは複数のsidecarが、クラッシュ（crash）または再起動のステップ410を実行し得ることが理解されよう。説明を容易にするために、sidecarのクラッシュまたは再起動は、まとめてオフラインと呼ばれる場合がある。

【0103】

sidecarのオフラインは、sidecarとサービス・コンテナ・グループとの間のリンク切断を引き起こし、sidecarとsidecar起動マネージャ112との間のドメインソケット切断を引き起こす可能性がある。すなわち、ステップ411において、オフラインsidecarとサービス・コンテナ・グループとの間のリンクが切断される。ステップ412において、オフラインsidecarとsidecar起動マネージャ112との間のドメインソケット接続が切断される。オフラインsidecarとsidecar起動マネージャ112との間のドメインソケットが切断されると、sidecar起動マネージャ112は、sidecarがオフラインになると決定し、次いで、sidecar更新情報をコンソール300に送信するステップ413を実行してもよく、sidecar更新情報は、オフラインsidecarの識別情報などを含む。

【0104】

sidecarがオフラインになると決定すると、sidecar起動マネージャ112は、sidecarリストを更新するステップ414をさらに実行し得、更新されたsidecarリストをプロトコルスタック111に送信し得る。sidecarリストを更新することは、sidecarリストからオフラインsidecarを削除すること、またはオフラインsidecarを非稼働状態に設定することを含み得る。いくつかの実施形態では、プロトコルスタック111は、オフラインsidecarの接続情報をクリアするステップ415を実行し得る。接続情報は、オフラインsidecarに履歴的に接続されているサービス・コンテナ・グループなどの情報を含み得る。

【0105】

サービス・コンテナ・グループとsidecarとの間のリンクが切断されると（例えば、sidecarのオフラインに起因して切断されると）、サービス・コンテナ・グループは、sidecarの再接続を要求するために接続要求を生成し得る。具体的には、サービス・コンテナ・グループは、ステップ416でプロトコルスタック111に接続要求を送信し得る。説明を容易にするために、接続要求を送信するサービス・コンテナ・グループは、接続対象のサービス・コンテナ・グループと呼ばれる場合がある。接続要求を受信した後、プロトコルスタック111は、接続対象のサービス・コンテナ・グループのためのsidecarを選択するステップ417を実行し得る。

【0106】

いくつかの実施形態では、sidecarは、以下の規則を使用して選択され得る。

【0107】

まず、sidecarリストに新バージョンのsidecarが存在するかどうかが決定される。具体的には、sidecarリスト内のすべてのsidecarのバージョンが同じであるかどうかが決定され得る。sidecarリスト内の1つまたは複数のsidecarのバージョンが別のsidecarのバージョンよりも高い場合、1つまたは複数のsidecarは新バージョンのsidecarであると決定され得る。sidecarリストに新バージョンのsidecarが存在するとき、新バージョンのsidecarが選択されたsidecarとして使用され得る。

【0108】

sidecarリストに新しいバージョンのsidecarが存在しないとき、接続対象のサービス・コンテナ・グループとsidecarリスト内のsidecarとの間に1つまたは複数のリンクが既に存在するかどうかが決定され得る。接続対象のサービス・コンテナ・グループとsidecarリスト内のsidecarB1との間に1つまたは複数のリンクが既に存在する場合、sidecarB1は選択されたsidecarとして使用され得る。

【0109】

接続対象のサービス・コンテナ・グループとsidecarリスト内のsidecarとの間にリンクが存在しない場合、現在の接続数が最も少ないsidecarがsidecarリスト内で決定され得、現在の接続数が最も少ないsidecarが選択されたsidecarとして使用される。

【0110】

前述の規則によれば、sidecarが選択された後、プロトコルスタック111は、sidecarがリンクを介してサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行することができるように、sidecarと接続対象のサービス・コンテナ・グループとの間のリンクを作成するために、選択されたsidecarに接続要求を送信するステップ418を実行し得る。

【0111】

いくつかの他の実施形態では、sidecarは、図2に示す実施形態で提供される規則を使用して選択されてもよい。

【0112】

実施形態1で提供されるノードは、複数のsidecarインスタンスの稼働をサポートし得、接続数に基づいて各利用可能なsidecarインスタンスに対して負荷分散を実行し得る。ノードは、sidecarインスタンスの動的拡張および既存のインスタンスのホットアップグレードをさらにサポートし得る。ホットアップグレードされたsidecarが新しい接続に優先的に使用され、置き換えられたsidecarのオフライン時間窓が制御されて、瞬間的な接続切替えによって引き起こされる接続キュースタッキングが低減される。加えて、ノードでは、プロトコルスタックおよびsidecar起動マネージャは、各sidecarのリスニングポートを自動的に管理し得る。sidecarの問題に起因してsidecarが故障すると、sidecarに接続されたサービス・コンテナ・グループは別の利用可能なsidecarに再配置され、手動の介入は必要なく、それによってシステム全体の可用性が向上する。

【0113】

実施形態2
本出願のこの実施形態は、ノード100を提供する。sidecarクラスタ120は、ノード100上で稼働し、複数のタイプのsidecarを含み得る。異なるタイプのsidecarは、異なる性能を有する。sidecarクラスタ120がsidecar 121およびsidecar 122を含むように設定され得る。sidecar 121は高性能sidecarであり、sidecar 122は低性能sidecarである。

【0114】

高性能sidecarの性能は、一般的なsidecarの性能よりも高い。具体的には、共通sidecarと比較して、より多くのハードウェアリソースが高性能sidecarに構成され、例えば、より多くのCPUが構成されてもよいし、加速ハードウェアが構成されてもよい。すなわち、高性能sidecarに割り当てられるハードウェアリソースは、共通sidecarに割り当てられるハードウェアリソースよりも高い。したがって、高性能sidecarは、共通sidecarよりもデータ処理能力が強い。高性能sidecarがサービス・コンテナ・グループのリンクのトラフィック管理を提供するとき、サービス・コンテナ・グループのサービス品質（Quality of Service、QoS）が保証され得る。したがって、サービス品質要件を有するサービス・コンテナ・グループの場合、サービス・コンテナ・グループと高性能sidecarとの間にリンクが作成され得、その結果、高性能sidecarはリンクのトラフィック管理を提供して、サービス・コンテナ・グループのサービス品質を保証することができる。

【0115】

運用および保守要員は、コンソール300を使用して優先リストを構成し得、優先リストは、複数のタイプの接続要求を含み得る。異なるタイプの接続要求は、異なるタイプのsidecarに対応する。例えば、ノード100には、高性能sidecarおよび共通sidecarが構成される。優先リストは、第1のタイプの接続要求および第2のタイプの接続要求を含み得る。第1のタイプの接続要求は高性能sidecarに対応し、第2のタイプの接続要求は共通sidecarに対応する。

【0116】

一例では、各タイプの接続要求は、少なくとも1つのサービス・コンテナ・グループ・ラベル（label）に対応し得る。異なるタイプの接続要求は、異なるサービス・コンテナ・グループ・ラベルに対応する。言い換えれば、各タイプの接続要求は、サービス・コンテナ・グループ・ラベルによって表されてもよい。サービス・コンテナ・グループ・ラベルは、サービス・コンテナ・グループのタイプを示す。サービス・コンテナ・グループがpodであるとき、サービス・コンテナ・グループ・ラベルはpod labelである。優先リストは、接続要求に対応するサービス・コンテナ・グループ・ラベルとsidecarタイプとの間の対応関係を記録する。例えば、接続要求のタイプは、サービス・コンテナ・グループ・ラベルQ1およびサービス・コンテナ・グループ・ラベルQ2に対応し、その接続要求のタイプは、高性能sidecarに対応する。この場合、優先リストは、サービス・コンテナ・グループ・ラベルQ1と高性能sidecarとの対応関係を記録し、サービス・コンテナ・グループ・ラベルQ2と高性能sidecarとの対応関係も記録し得る。

【0117】

一例では、各タイプの接続要求は、少なくとも1つのサービスタイプに対応し得る。異なるタイプの接続要求は、異なるサービスタイプに対応する。言い換えれば、各タイプの接続要求は、サービスタイプによって表されてもよい。優先リストは、接続要求に対応するサービスタイプとsidecarタイプとの間の対応関係を記録する。例えば、接続要求のタイプはサービスタイプSに対応し、接続要求のタイプは高性能sidecarに対応する。この場合、優先リストは、サービスタイプSと高性能sidecarとの対応関係を記録してもよい。

【0118】

図4Aを参照されたい。接続制御モジュール110は、ノード100上でさらに稼働する。接続制御モジュール110は、プロトコルスタック111および制御プレーンプロキシ113を含み得る。

【0119】

図4Aを参照されたい。コンソール300は、構成された優先リストを制御プレーンプロキシ113に送信し得る。制御プレーンプロキシ113は、優先リストを格納し、優先リストをプロトコルスタック111に送信し得る。例えば、制御プレーンプロキシは、Ebpf mapを使用することによって優先リストをプロトコルスタック111に送信し得る。

【0120】

プロトコルスタック111にはsidecarリストがさらに構成され、sidecarリストは、ノード100のsidecarのsidecarタイプおよびリスニングポートなどの情報を記録する。sidecarリストを取得および更新する方法については、実施形態1の前述の説明を参照されたい。実施形態1とは異なり、実施形態2では、sidecar識別子とsidecarタイプとの間の対応関係が事前構成され得る。したがって、プロトコルスタック111は、sidecar識別子とsidecarタイプとの対応関係に基づいてsidecarリストにsidecarタイプを記録し得る。

【0121】

サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係は、プロトコルスタック111においてさらに構成され得る。一例では、サービス・コンテナ・グループ識別子は、cgroup．ns（control group namespace）であってもよい。サービス・コンテナ・グループ識別子はサービス・コンテナ・グループを示し、サービス・コンテナ・グループ・ラベルはサービス・コンテナ・グループのタイプを示す。言い換えれば、複数のサービス・コンテナ・グループは、複数のサービス・コンテナ・グループ識別子を有し、複数のサービス・コンテナ・グループは、複数のサービス・コンテナ・グループ識別子と1対1に対応する。複数のサービス・コンテナ・グループが同じタイプのサービス・コンテナ・グループであるとき、複数のサービス・コンテナ・グループのサービス・コンテナ・グループ・ラベルは同じである。サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係を決定する方法は、図4B－1および図4B－2に示す以下の実施形態で説明され、ここでは詳細は説明されない。

【0122】

例示的な例では、優先リストは、サービス・コンテナ・グループ・ラベルとsidecarタイプとの間の対応関係を記録する。プロトコルスタック111がサービス・コンテナ・グループ、例えばサービス・コンテナ・グループ131によって送信された接続要求を受信すると、プロトコルスタック111は、接続要求の送信元アドレス（例えば、送信元IPアドレス）に基づいてサービス・コンテナ・グループ131のサービス・コンテナ・グループ識別子を決定し得る。次いで、サービス・コンテナ・グループ131のサービス・コンテナ・グループ識別子と、サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係とに基づいて、サービス・コンテナ・グループ131のサービス・コンテナ・グループ・ラベルが決定され得る。サービス・コンテナ・グループ131のサービス・コンテナ・グループ・ラベルが決定された後、優先リストに基づいて、サービス・コンテナ・グループ131のサービス・コンテナ・グループ・ラベルに対応するsidecarタイプが決定され得る。次いで、プロトコルスタック111は、決定されたsidecarタイプのデータプロキシに接続要求を送信する。例えば、サービス・コンテナ・グループ131のサービス・コンテナ・グループ・ラベルに対応するsidecarタイプが高性能sidecarであると設定されてもよい。この場合、プロトコルスタック111は、サービス・コンテナ・グループ131からの接続要求を高性能sidecarに送信し得、その結果、高性能sidecarは、サービス・コンテナ・グループ131からのデータパケットのトラフィック管理を提供する。

【0123】

例示的な例では、優先リストは、サービスタイプとsidecarタイプとの間の対応関係を記録する。プロトコルスタック111が、サービス・コンテナ・グループ、例えばサービス・コンテナ・グループ132によって送信された接続要求を受信すると、プロトコルスタック111は、接続要求のターゲットサービスを決定し得る。次いで、ターゲットサービスに対応するsidecarタイプは、ターゲットサービスのサービスタイプおよび優先リストに基づいて決定され得る。次いで、プロトコルスタック111は、決定されたsidecarタイプのデータプロキシに接続要求を送信し得る。例えば、サービス・コンテナ・グループ132によって送信された接続要求のターゲットサービスに対応するsidecarタイプが共通sidecarであると設定されてもよい。この場合、プロトコルスタック111は、サービス・コンテナ・グループ132からの接続要求を共通sidecarに送信し得、その結果、共通sidecarは、サービス・コンテナ・グループ132からのデータパケットのトラフィック管理を提供する。

【0124】

以下では、図4B－1および図4B－2を参照して、実施形態2で提供される解決策のより詳細な説明を提供する。

【0125】

図4B－1および図4B－2を参照されたい。ノード100内のサービス・コンテナ・グループ監視モジュール（例えば、pod監視（monitor）モジュール）は、ステップ501を使用してサービス・コンテナ・グループ作成モジュールを監視して、サービス・コンテナ・グループ作成を監視し得る。例えば、サービス・コンテナ・グループ作成モジュールは、具体的には、kubeletであってもよい。サービス・コンテナ・グループ作成モジュールは、ステップ502においてサービス・コンテナ・グループを作成し得る。このようにして、サービス・コンテナ・グループ監視モジュールは、ステップ503を使用してサービス・コンテナ・グループ作成イベントを検出し得る。サービス・コンテナ・グループ監視モジュールは、サービス・コンテナ・グループ作成イベントに基づいて、作成されたサービス・コンテナ・グループのサービス・コンテナ・グループ識別子およびサービス・コンテナ・グループ・ラベルを取得し得る。次いで、サービス・コンテナ・グループ監視モジュールは、サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係を確立するステップ504を実行し得る。サービス・コンテナ・グループ監視モジュールは、ステップ505を使用して、サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係をプロトコルスタック111に送信し得る。例えば、サービス・コンテナ・グループ監視モジュールは、Ebpf mapを使用して、サービス・コンテナ・グループ・ラベルとサービス・コンテナ・グループ識別子との間の対応関係をプロトコルスタック111に送信し得る。

【0126】

運用および保守要員は、コンソール300上で優先リストを構成し得る。優先リストの詳細については、前述の説明を参照されたく、ここでは詳細は再び説明されない。コンソール300は、ステップ507を使用して優先リストを制御プレーンプロキシ113に送信し得る。制御プレーンプロキシ113は、ステップ508を使用して、優先リストをプロトコルスタック111に送信し得る。プロトコルスタック111は、ステップ509を使用して優先リストを格納し得る。

【0127】

プロトコルスタック111は、ステップ510を使用して、サービス・コンテナ・グループによって送信された接続要求を受信し得る。説明を容易にするために、接続要求を送信するサービス・コンテナ・グループは、接続対象のサービス・コンテナ・グループと呼ばれる場合がある。プロトコルスタック111は、接続要求の送信元アドレスを解析し、ステップ511において、接続要求の送信元アドレスに基づいてサービス・コンテナ・グループ識別子を決定し得る。次いで、プロトコルスタック111は、ステップ512において、決定されたサービス・コンテナ・グループ識別子に基づいてサービス・コンテナ・グループ・ラベルを決定し得る。さらに、プロトコルスタック111は、ステップ513において、優先リストに基づいて、サービス・コンテナ・グループ・ラベルに対応するsidecarタイプを決定して、接続対象のサービス・コンテナ・グループに対応するsidecarタイプを決定し得る。

【0128】

プロトコルスタック111は、ステップ514において、接続対象のサービス・コンテナ・グループのためのsidecarを選択し得る。

【0129】

優先リストが空である場合、具体的には、接続要求とsidecarタイプとの間の対応関係が構成されていない場合、現在の接続数が最も少ないsidecarがsidecarリストから選択される。

【0130】

高性能sidecarの現在の接続数が0であり、接続対象のサービス・コンテナ・グループが高性能sidecarに対応しない場合、現在の接続数が最も少ないsidecarがsidecarリストから選択される。言い換えれば、高性能sidecarがサービス・コンテナ・グループに接続されていないとき、接続対象のサービス・コンテナ・グループが高性能sidecarに対応していなくても、高性能sidecarが接続対象のサービス・コンテナ・グループのトラフィック管理を提供することを可能にされてもよく、その結果、高性能sidecarがアイドル状態のときにsidecarの全体的なリソース利用率を改善することができる。

【0131】

サービス・コンテナ・グループが高性能sidecarに対応する場合、高性能sidecarが選択される。

【0132】

次いで、プロトコルスタック111は、選択されたsidecarに接続要求を送信するステップ515を実行し得る。このようにして、sidecarと接続対象のサービス・コンテナ・グループとの間にリンクが作成され、その結果、sidecarは、リンクを介してサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行することができる。

【0133】

実施形態2で提供される解決策では、実施形態1でマルチアクティブ高可用性がサポートされるとき、高いサービス品質を必要とするいくつかの接続要求に独立したまたはより多くのハードウェアリソースが使用されることを保証するために、異なる性能を有するsidecarを使用することによって異なるタイプのサービス・コンテナ・グループまたはターゲットサービスに対して実行されるべきトラフィック管理がサポートされ、高性能sidecarがアイドルであるときにsidecarの全体的なリソース利用率が改善されることができる。

【0134】

実施形態3
サービスメッシュシステムでは、sidecarは、システム内のサービス変更を検知し、サービス変更のために更新されたサービスリストを取得する必要がある。サービス変更は、サービスオンライン、サービスオフラインなどを含み得る。

【0135】

解決策については、図5Aを参照されたい。サービスメッシュシステム内のノードMまたはノードNなどの各ノードのsidecarとサービスメッシュシステム内の制御プレーンとの間にソケット（socket）持続接続が確立される。バックエンド・コンテナ・グループ内でサービス変更が発生すると、制御プレーンはサービス変更メッセージを生成し得る。サービス変更メッセージは、バックエンド・コンテナ・グループで発生したサービス変更を記述するために使用されてもよく、またはサービス変更メッセージは、バックエンド・コンテナ・グループで発生したサービス変更のために更新されるサービスリストを含む。制御プレーンは、制御プレーンと各sidecarとの間の持続接続を介して各sidecarにサービス変更メッセージを送信する。バックエンド・コンテナ・グループは、ノードMまたはノードNのサービス呼び出しに応答して対応するサービスを提供することができるコンテナグループであってもよい。

【0136】

この解決策では、サービスメッシュシステム内のノードの数が増加する場合、制御プレーン上の接続数が大幅に増加する。サービスメッシュシステム内の各サービスのオンラインまたはオフラインはサービス変更を引き起こす可能性があり、その結果、制御プレーンはサービス変更メッセージを生成する。制御プレーンは、制御プレーンに接続されたすべてのsidecarをポーリングし、サービス変更メッセージを送信する必要がある。制御プレーンの接続数が多いとき、sidecarをポーリングし、サービス変更メッセージを送信すると、制御プレーンの大量のコンピューティングリソースが消費され、ネットワークに大きな圧力がかかる。さらに、制御プレーンは、ポーリングを実行し、sidecar起動シーケンスまたはランダムシーケンスでサービス変更メッセージを送信する。その結果、同じノード内の異なるsidecarがサービス変更メッセージを受信する時間の差が大きくなる。その結果、同じノード内のsidecarがサービスインスタンスの不一致を検知する時間窓が大きくなり、これがサービス例外を引き起こす可能性がある。

【0137】

加えて、制御プレーンのソケットファイル記述子の数も制限される。

【0138】

したがって、この解決策では、前述の制限により、サービスメッシュシステムをスケールアップすることが困難になる。

【0139】

この実施形態は、解決策を提供する。図5Bを参照されたい。コンソール300は、各ノードの制御プレーンプロキシへの接続（例えば、ソケット持続接続）を確立し得る。このようにして、コンソール300は、各ノードの制御プレーンプロキシにサービス変更メッセージを送信し得る。例えば、制御プレーンは、ノード100の制御プレーンプロキシ113およびノード200の制御プレーンプロキシ213にサービス変更メッセージを送信する。次いで、制御プレーンプロキシ113は、ノード100内のsidecar 121またはsidecar 122などの各sidecarにサービス変更メッセージを送信し得る。制御プレーンプロキシ213は、ノード200内のsidecar 221またはsidecar 222などの各sidecarにサービス変更メッセージを送信し得る。

【0140】

このようにして、制御プレーンの接続数が大幅に低減される。加えて、サービスメッシュでサービス変更が発生すると、制御プレーンはポーリングを実行し、ノードレベルでサービス変更メッセージを送信して、制御プレーン上のコンピューティングリソースの消費およびネットワーク上の圧力を低減する。加えて、サービス変更メッセージを受信した後、ノードの制御プレーンプロキシは、ノードの内部通信メカニズムを使用して、ノード内の各sidecarにサービス変更メッセージを送信する。このようにして、同じノード内のsidecarがサービスインスタンスの不一致を検知するための時間窓が大幅に低減される。

【0141】

加えて、この実施形態では、制御プレーンと制御プレーンプロキシとの間のネットワークで障害が発生すると、制御プレーンプロキシはオフラインサービスセンターとして使用され、sidecarと制御側との間の通信を実施するために、制御プレーンプロキシが位置するノード内のsidecarに読み取り機能を提供し得る。制御側は、制御プレーンプロキシと制御プレーンとを含む。

【0142】

以下、図5Cを参照して、実施形態3で提供される解決策のより詳細な説明を提供する。

【0143】

図5Cを参照されたい。コンソール300は、ステップ601を使用して、バックエンド・コンテナ・グループに対するサービス変更監視を実行し得る。加えて、ステップ602において、ノード100内のコンソール300と制御プレーンプロキシ113との間の接続が確立される。接続は、ソケット持続接続であってもよい。ステップ603において、制御プレーンプロキシ113は、制御プレーンプロキシ113が位置するノード内のsidecarへの接続を確立し得る。

【0144】

バックエンド・コンテナ・グループ内でサービス変更が発生したことを検知すると、コンソール300は、ステップ604でサービス変更メッセージを生成し、ステップ605を使用してサービス変更メッセージを制御プレーンプロキシに送信し得る。

【0145】

サービス変更メッセージを受信した後、制御プレーンプロキシは、ステップ606を使用してsidecarにサービス変更メッセージを送信し得る。sidecarは、ステップ607でサービス変更メッセージに基づいてルーティング情報を更新し得る。

【0146】

実施形態4
クライアントが初めてサーバからのセッション（session）を要求するとき、サーバはクライアントのためのセッションを作成し、セッションを識別するための特別なアルゴリズムを使用してセッション識別子（session identifier、session ID）を計算する。サーバは、セッション識別子をクライアントに返し得る。クライアントは、セッション識別子をローカルcookieに格納し得る。クライアントがサーバに再アクセスすると、クライアントはセッション識別子をサーバに送信し得る。サーバは、セッション識別子に対応するセッションを再使用して、クライアントに対応するサービスを提供する。

【0147】

サービスメッシュシステムでは、クライアントは、サービスを呼び出すことができるサービス・コンテナ・グループである。サーバは、バックエンド・コンテナ・グループと呼ばれることもあり、サービス・コンテナ・グループにサービスを提供し得る。サーバは、複数のサービスインスタンスを含み、クライアントにサービスを提供するために1つまたは複数のサービスインスタンスを使用し得る。

【0148】

図6Aを参照されたい。実施形態1で提供される解決策に基づいて、サービス・コンテナ・グループCは、リンクC1を介してsidecarM1に接続され、リンクC2を介してsidecarM2に接続され得る。サービス・コンテナ・グループCは、リンクC1を介してバックエンド・コンテナ・グループに対する接続要求を送信し得、接続要求はセッション識別子Eを搬送し得る。接続要求を受信した後、sidecarM1は、接続要求からセッション識別子Eを抽出し、次いで、ハッシュ（hash）アルゴリズムを使用してセッション識別子Eに基づいてルーティングポリシーを決定し、ルーティングポリシーに従って接続要求をサービスインスタンスに送信し得る。例えば、ルーティングポリシーがバックエンド・コンテナ・グループ内のサービスインスタンスD1に接続要求を送信していると設定されてもよい。

【0149】

同様に、サービス・コンテナ・グループCは、リンクC2を介してバックエンド・コンテナ・グループに対する接続要求を代替的に送信し得、接続要求はセッション識別子Eを搬送し得る。接続要求を受信した後、sidecarM2は、接続要求からセッション識別子Eを抽出し、次いで、ハッシュ（hash）アルゴリズムを使用してセッション識別子Eに基づいてルーティングポリシーを決定し、ルーティングポリシーに従って接続要求をサービスインスタンスに送信し得る。例えば、ルーティングポリシーがバックエンド・コンテナ・グループ内のサービスインスタンスD2に接続要求を送信していると設定されてもよい。

【0150】

バックエンド・コンテナ・グループがサービス変更メッセージを送信するとき、異なるsidecarは異なる時間にサービス変更メッセージを受信することが理解されよう。結果として、ハッシュ計算中に異なるsidecarによって使用されるハッシュリングのサイズは一致していない。例えば、sidecarM1はサービス変更メッセージを受信する前にハッシュ計算を実行し、sidecarM2はサービス変更メッセージを受信した後にハッシュ計算を実行する。この場合、sidecarM1とsidecarM2とが別々にハッシュ計算を実行すると、sidecarM1とsidecarM2とが使用するハッシュリングのサイズが一致せず、異なるルーティングポリシーが生成される。言い換えれば、サービス・コンテナ・グループC1によって開始された異なる接続要求は、異なるサービスインスタンスに送信され得、これはサービス例外を引き起こし得る。

【0151】

実施形態4は、解決策を提供する。異なるsidecarが同じサービス・コンテナ・グループの異なるリンクのトラフィック管理を提供するとき、異なるリンクを介してサービス・コンテナ・グループによって開始された接続要求は、同じサービスインスタンスに送信され得る。以下、図4B－1および図4B－2を参照して例を使用して解決策を説明する。

【0152】

この解決策は、図6Bに示すコンテナグループ管理システムに適用され得、コンテナグループ管理システムは、ノード100およびバックエンド・コンテナ・グループ210を含む。ノード100は、sidecar 121およびsidecar 122を含み得る。例えば、ノード100は、接続制御モジュール110をさらに含んでもよい。サービス・コンテナ・グループ131は、リンク1311を介してsidecar 121に接続されてもよく、リンク1312を介してsidecar 122に接続されてもよい。バックエンド・コンテナ・グループには、サービスインスタンスG1、サービスインスタンスG2などの複数のサービスインスタンスが構成されてもよい。

【0153】

図6Bを参照されたい。セッション識別子Fとサービスインスタンスとの間の対応関係は、ノード100において構成され得る。sidecar、例えばsidecar 121が、ルーティングポリシーに対応するサービスインスタンスを取得するためにセッション識別子Fに基づいてハッシュ計算を実行すると、sidecar 121は、セッション識別子Fとサービスインスタンスとの間の対応関係を確立し得る。sidecar 121は、sidecar 122と対応関係を共有してもよい。例えば、sidecar 121は、対応関係を接続制御モジュール110に送信してもよい。sidecar 122は、接続制御モジュール110におけるセッション識別子Fとサービスインスタンスとの対応関係を読み出してもよいし、対応関係をローカルキャッシュに格納してもよい。

【0154】

セッション識別子Fを含み、リンク1311を介してサービス・コンテナ・グループ131によって送信された接続要求を受信すると、sidecar 121は、接続要求をサービスインスタンスにルーティングするために、セッション識別子Fとサービスインスタンスとの間の対応関係に基づいてサービスインスタンスを決定し得る。セッション識別子Fを含み、リンク1312を介してサービス・コンテナ・グループ131によって送信された接続要求を受信すると、sidecar 122は、接続要求をサービスインスタンスにルーティングするために、セッション識別子Fとサービスインスタンスとの間の対応関係に基づいてサービスインスタンスを決定し得る。このようにして、異なるsidecarが同じサービス・コンテナ・グループの異なるリンクのトラフィック管理を提供するとき、異なるリンクを介してサービス・コンテナ・グループによって開始された接続要求は、同じサービスインスタンスに送信され得る。

【0155】

以下では、図6C－1および図6C－2を参照して、実施形態4で提供される解決策のより詳細な説明を提供する。

【0156】

図6C－1および図6C－2に示すように、サービス・コンテナ・グループ131は、ステップ701を使用してバックエンド・コンテナ・グループ210にセッション要求を送信し得る。バックエンド・コンテナ・グループ210は、ステップ702のセッション要求に応答してセッション識別子Fをサービス・コンテナ・グループ131に割り当て、ステップ703を使用してセッション識別子Fをサービス・コンテナ・グループ131に送信し得る。サービス・コンテナ・グループ131は、ステップ704においてセッション識別子Fを格納し得る。

【0157】

サービス・コンテナ・グループ131は、ステップ705を使用して、セッション識別子Fを含む接続要求をsidecar 121に送信し得る。

【0158】

例示的な例では、セッション識別子Fを含む接続要求を受信すると、sidecar 121は、ステップ706aを使用して、セッション識別子Fに対応するサービスインスタンスについて接続制御モジュール110を照会し得る。

【0159】

例示的な例では、セッション識別子Fを含む接続要求を受信すると、sidecar 121は、ステップ706bを使用して、セッション識別子Fに対応するサービスインスタンスについてsidecar 121のローカルキャッシュを照会し得る。言い換えれば、この例では、セッション識別子Fとサービスインスタンスとの間の対応関係は、sidecar 121のローカルキャッシュに格納され得る。

【0160】

サービス・コンテナ・グループ131は、ステップ707を使用して、セッション識別子Fを含む接続要求をsidecar 122に送信し得る。

【0161】

例示的な例では、セッション識別子Fを含む接続要求を受信すると、sidecar 122は、ステップ708aを使用して、セッション識別子Fに対応するサービスインスタンスについて接続制御モジュール110を照会し得る。

【0162】

例示的な例では、セッション識別子Fを含む接続要求を受信すると、sidecar 122は、ステップ708bを使用して、セッション識別子Fに対応するサービスインスタンスについてsidecar 122のローカルキャッシュを照会し得る。言い換えれば、この例では、セッション識別子Fとサービスインスタンスとの間の対応関係は、sidecar 122のローカルキャッシュに格納され得る。

【0163】

図6C－1および図6C－2をさらに参照されたい。sidecar 121は、ステップ709を実行し得る。サービスインスタンスが見つからない場合、sidecar 121は、セッション識別子Fに基づいてハッシュ演算を実行して、セッション識別子Fに対応するサービスインスタンスを取得する。言い換えれば、ステップ706aおよびステップ706bを使用して、セッション識別子Fに対応するサービスインスタンスが見つからない。これは、sidecar 122がステップ706aを実行するときに、接続制御モジュール110がセッション識別子Fとサービスインスタンスとの間の対応関係を格納しないことを示し、sidecar 121がステップ706bを実行するとき、sidecar 121のローカルキャッシュはセッション識別子Fとサービスインスタンスとの間の対応関係を格納しない。このようにして、sidecar 121は、セッション識別子に基づいてハッシュ演算を実行して、セッション識別子Fに対応するサービスインスタンスを取得する。

【0164】

次いで、sidecar 121は、セッション識別子Fとサービスインスタンスとの間の対応関係を作成し、セッション識別子Fとサービスインスタンスとの間の対応関係を接続制御モジュール110に送信するステップ710を実行し得る。接続制御モジュール110は、ステップ711において、セッション識別子Fとサービスインスタンスとの間の対応関係を格納し得る。例えば、sidecar 121は、セッション識別子Fとサービスインスタンスとの間の対応関係をローカルキャッシュに格納するために、ローカルキャッシュを更新するステップ712を実行し得る。

【0165】

加えて、sidecar 121は、サービスインスタンスに基づいて接続を作成するステップ713を実行し得る。具体的には、接続要求は、サービス・コンテナ・グループ131とサービスインスタンスとの間の接続を確立するために、セッション識別子Fに対応するサービスインスタンスに送信される。

【0166】

図6C－1および図6C－2をさらに参照されたい。sidecar 122は、ステップ714を実行し得る。サービスインスタンスが見つからない場合、sidecar 122は、セッション識別子Fに基づいてハッシュ演算を実行して、セッション識別子Fに対応するサービスインスタンスを取得する。言い換えれば、ステップ708aおよびステップ708bを使用して、セッション識別子Fに対応するサービスインスタンスが見つからない。これは、sidecar 122がステップ708aを実行するときに、接続制御モジュール110がセッション識別子Fとサービスインスタンスとの間の対応関係を格納しないことを示し、sidecar 122がステップ708bを実行するとき、sidecar 122のローカルキャッシュはセッション識別子Fとサービスインスタンスとの間の対応関係を格納しない。このようにして、sidecar 122は、セッション識別子に基づいてハッシュ演算を実行して、セッション識別子Fに対応するサービスインスタンスを取得する。

【0167】

次いで、sidecar 122は、セッション識別子Fとサービスインスタンスとの間の対応関係を作成し、セッション識別子Fとサービスインスタンスとの間の対応関係を接続制御モジュール110に送信するステップ715を実行し得る。

【0168】

接続制御モジュール110は、セッション識別子Fとサービスインスタンスとの間の対応関係が接続制御モジュール110に既に存在する（セッション識別子Fとサービスインスタンスとの間の対応関係が上記のステップ711で格納されている）と決定するステップ716を実行し、セッション識別子Eとサービスインスタンスとの間の、sidecar 122によって送信された対応関係に基づいて更新を実行しなくてもよい。接続制御モジュール110は、セッション識別子Fとサービスインスタンスとの間の、ステップ711で格納された対応関係をsidecar 122に送信するステップ717をさらに実行してもよい。sidecar 122は、セッション識別子Fとサービスインスタンスとの間の、接続制御モジュール110から受信した対応関係をローカルキャッシュに格納するために、ローカルキャッシュを更新するステップ718を実行し得る。

【0169】

sidecar 122は、セッション識別子Fとサービスインスタンスとの間の、接続制御モジュール110から受信した対応関係に基づいて、セッション識別子Fに対応するサービスインスタンスを決定し得る。次いで、sidecar 122は、サービスインスタンスに基づいて接続を作成するステップ719を実行し得る。具体的には、接続要求は、サービス・コンテナ・グループ131とサービスインスタンスとの間の接続を確立するために、セッション識別子Fに対応するサービスインスタンスに送信される。

【0170】

加えて、例示的な例では、セッション識別子のライフサイクルが構成されてもよい。接続制御モジュール110は、セッション識別子のライフサイクルが終了したときに、セッション識別子が期限切れであると決定し、期限切れのセッション識別子をクリアするステップ720を実行し得る。ステップ720において、期限切れのセッション識別子とサービスインスタンスとの間の対応関係が具体的にクリアされる。接続制御モジュール110は、セッション識別子クリアコマンドをsidecar 121に送信するステップ721aを実行し得る。セッション識別子クリアコマンドに応答して、sidecar 121は、キャッシュをクリアして、期限切れのセッション識別子とサービスインスタンスとの間の対応関係をローカルキャッシュからクリアするステップ722aを実行し得る。接続制御モジュール110は、セッション識別子クリアコマンドをsidecar 122に送信するステップ721bを実行し得る。セッション識別子クリアコマンドに応答して、sidecar 122は、キャッシュをクリアするステップ722bを実行して、期限切れのセッション識別子とサービスインスタンスとの間の対応関係をローカルキャッシュからクリアし得る。

【0171】

したがって、実施形態4で提供される解決策によれば、異なるsidecarが同じサービス・コンテナ・グループの異なるリンクのトラフィック管理を提供するとき、異なるリンクを介してサービス・コンテナ・グループによって開始された接続要求は、同じサービスインスタンスに送信され得、その結果、サービスインスタンスは、異なるリンクを介してサービス・コンテナ・グループにサービスを提供することができる。

【0172】

以下では、上述したコンテナグループ管理解決策に基づいて、本出願の一実施形態で提供されるノード内のコンテナグループを管理するための方法について説明する。本方法は、上述のコンテナグループ管理解決策の別の表現方法であり、2つが組み合わされることが理解されよう。本方法は、上述のコンテナグループ管理解決策に基づいて提案される。本方法の一部または全部の内容については、コンテナグループ管理の前述の説明を参照されたい。

【0173】

接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループがノード上で稼働し、サイドカークラスタは少なくとも2つのサイドカーを含む。図7を参照されたい。本方法は以下のステップを含む。

【0174】

ステップ7001：接続制御モジュールは、ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送する。

【0175】

ステップ7002：第1のサイドカーは、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行する。

【0176】

いくつかの実施形態では、第2のサービス・コンテナ・グループがノード上でさらに稼働する。本方法は、接続制御モジュールが、サイドカー割り当てポリシーに従ってサイドカークラスタから第2のサイドカーを選択し、第2のサービス・コンテナ・グループによって送信されたデータパケットを第2のサイドカーに転送するステップと、第2のサイドカーが、第2のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するステップと、をさらに含む。

【0177】

これらの実施形態の一例では、第1のサイドカーに割り当てられるハードウェアリソースの仕様は、第2のサイドカーに割り当てられるハードウェアリソースの仕様よりも高く、サイドカー割り当てポリシーは、第1のポリシーを含み、第1のポリシーは、第1のサービス・コンテナ・グループが第1のサイドカーを優先的に使用することを示す。サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択するステップは、第1のポリシーに従ってサイドカークラスタから第1のサイドカーを選択するステップを含む。

【0178】

いくつかの実施形態では、第2のサービス・コンテナ・グループは、ノード上でさらに稼働し、サイドカー割り当てポリシーは、第2のポリシーをさらに含み、第2のポリシーは、第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示す。本方法は、接続制御モジュールが、第1のサイドカーによってサービスされるオブジェクトの数を決定し、その数が上限値を超えないとき、第2のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップと、第1のサイドカーが、第1のサービス・コンテナ・グループによって送信されたデータパケットと第2のサービス・コンテナ・グループによって送信されたデータパケットとに対してトラフィック管理を同時に実行するステップと、をさらに含む。

【0179】

いくつかの実施形態では、本方法は、第1のサイドカーが故障した後で、接続制御モジュールが、サイドカークラスタから第3のサイドカーを選択するか、またはノードに第3のサイドカーを作成するようにコンソールに通知し、第1のサービス・コンテナ・グループによって送信された別のデータパケットを第3のサイドカーに転送するステップと、第3のサイドカーが、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行するステップと、をさらに含む。

【0180】

これらの実施形態の一例では、第3のサイドカーは、第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または第3のサイドカーは、第1のサイドカーの複製バージョンである。

【0181】

これらの実施形態の別の例では、本方法は、第1のサイドカーが、第1のサービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループにデータパケットを送信するステップをさらに含む。

【0182】

この例の一例では、本方法は、第1のサイドカーがセッション識別子を生成し、セッション識別子を第1のサービス・コンテナ・グループおよび接続制御モジュールに送信するステップと、接続制御モジュールが、セッション識別子とバックエンド・コンテナ・グループとの間の対応関係を記録するステップと、第3のサイドカーが、第1のサービス・コンテナ・グループからセッション識別子を取得し、セッション識別子に基づいて、接続制御モジュールによって記録された対応関係内のバックエンド・コンテナ・グループを決定し、第1のサービス・コンテナ・グループによって送信された別のデータパケットに対してトラフィック管理を実行した後に、別のデータパケットをバックエンド・コンテナ・グループに送信するステップと、をさらに含む。

【0183】

いくつかの実施形態では、サイドカー割り当てポリシーは第3のポリシーを含み、第3のポリシーは、サイドカーによってサービスされるオブジェクトの数が0であるとき、サイドカークラスタ内のサイドカーが優先的に使用されることを示す。サイドカー割り当てポリシーに従ってサイドカークラスタから第1のサイドカーを選択し、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップは、接続制御モジュールが、第1のサイドカーによってサービスされるオブジェクトの数を決定し、第1のサイドカーによってサービスされるオブジェクトの数が0であるとき、第1のサービス・コンテナ・グループによって送信されたデータパケットを第1のサイドカーに転送するステップ、を含む。

【0184】

いくつかの実施形態では、本方法は、接続制御モジュールが、サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、オフラインサイドカーに関する情報をコンソールに送信するステップ、をさらに含む。

【0185】

いくつかの実施形態では、トラフィック管理は、トラフィック制御、トラフィック保護、およびトラフィック観測を含む。

【0186】

本出願の実施形態で提供されるコンテナグループ管理方法によれば、サイドカーは、コンソールによって送信されたサイドカー割り当てポリシーに従って、少なくとも2つのサイドカーからサービス・コンテナ・グループのために選択されてもよく、選択されたサイドカーは、サービス・コンテナ・グループによって送信されたデータパケットに対してトラフィック管理を実行するために使用され、その結果、サービス・コンテナ・グループは柔軟に管理されることができ、サービス・コンテナ・グループに対してより良好なトラフィック管理が実行されることができ、それによってサービス・コンテナ・グループのサービスの高可用性能力が保証される。

【0187】

本出願のこの実施形態では、サイドカーは、ノードの外部またはノード内の別のサービス・コンテナ・グループからサイドカーにバインドされたサービス・コンテナ・グループに送信されたデータパケットに対してトラフィック処理を代替的に実行してもよいことに留意されたい。前述の方法を参照して、トラフィック処理ポリシーが設定されてもよい。これは、本出願のこの実施形態で限定されない。

【0188】

図8を参照されたい。本出願の一実施形態は、プロセッサ810およびメモリ820を含むノード800をさらに提供する。プロセッサ810は、ノード800が図7に示す方法を実行できるように、メモリ820に格納された命令を実行するように構成される。

【0189】

本出願の一実施形態は、コンピュータプログラム命令を含むコンピュータ可読記憶媒体をさらに提供する。コンピュータプログラム命令がコンピューティング・デバイス・クラスタによって実行されると、コンピューティング・デバイス・クラスタは図7に示す方法を実行する。

【0190】

本出願の一実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。命令がコンピューティング・デバイス・クラスタによって稼働すると、コンピューティング・デバイス・クラスタは、図7に示す方法を実行することが可能になる。

【0191】

本出願の実施形態におけるプロセッサは、中央処理装置（central processing unit、CPU）であってもよいし、他の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、DSP）、特定用途向け集積回路（application－specific integrated circuit、ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、他のプログラマブルロジックデバイス、トランジスタロジックデバイス、ハードウェアコンポーネント、またはそれらの組み合わせであってもよいことが理解されよう。汎用プロセッサは、マイクロプロセッサまたは任意の通常のプロセッサであってもよい。本出願の実施形態における様々な数字は、説明を容易にするための区別に使用されているにすぎず、本出願の実施形態の範囲を限定するためには使用されていないことが理解されよう。

【符号の説明】

【0192】

100 ノード
110 接続制御モジュール
111 プロトコルスタック
112 sidecar起動マネージャ
113 制御プレーンプロキシ
120 サイドカークラスタ
121 サイドカー、sidecar
122 サイドカー、sidecar
123 サイドカー、sidecar
130 サービス・コンテナ・グループ・クラスタ
131 サービス・コンテナ・グループ
132 サービス・コンテナ・グループ
200 ノード
210 バックエンド・コンテナ・グループ
213 制御プレーンプロキシ
220 バックエンド・コンテナ・グループ
221 サイドカー、sidecar
222 サイドカー、sidecar
300 コンソール
800 ノード
810 プロセッサ
820 メモリ
1311 リンク
1312 リンク
1321 リンク
1322 リンク

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B-1】

【図4B-2】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図6C-1】

【図6C-2】

【図7】

【図8】

【手続補正書】

【提出日】2024-03-19

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

コンテナグループを実行するためのノードであって、接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが前記ノード上で稼働し、前記サイドカークラスタは少なくとも2つのサイドカーを含み、
前記接続制御モジュールは、前記ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送するように構成され、
前記第1のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するように構成される、
ノード。

【請求項2】

前記ノードが第2のサービス・コンテナ・グループをさらに含み、
前記接続制御モジュールは、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第2のサイドカーを選択し、前記第2のサービス・コンテナ・グループによって送信されたデータパケットを前記第2のサイドカーに転送するようにさらに構成され、
前記第2のサイドカーは、前記第2のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するように構成される、
請求項1に記載のノード。

【請求項3】

前記第1のサイドカーに割り当てられたハードウェアリソースの仕様が前記第2のサイドカーに割り当てられたハードウェアリソースの仕様よりも高く、前記サイドカー割り当てポリシーは第1のポリシーを含み、前記第1のポリシーは、前記第1のサービス・コンテナ・グループが前記第1のサイドカーを優先的に使用することを示し、
前記接続制御モジュールは、前記第1のポリシーに従って前記サイドカークラスタから前記第1のサイドカーを選択するように構成される、
請求項2に記載のノード。

【請求項4】

前記ノードが第2のサービス・コンテナ・グループをさらに含み、前記サイドカー割り当てポリシーは第2のポリシーをさらに含み、前記第2のポリシーは、前記第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示し、
前記接続制御モジュールは、前記第1のサイドカーによってサービスされる前記オブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が上限値を超えないとき、前記第2のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するようにさらに構成され、
前記第1のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記データパケットと前記第2のサービス・コンテナ・グループによって送信された前記データパケットとに対してトラフィック管理を同時に実行するようにさらに構成される、
請求項1に記載のノード。

【請求項5】

前記接続制御モジュールが、前記第1のサイドカーが故障した後で、前記サイドカークラスタから第3のサイドカーを選択し、または前記ノードに前記第3のサイドカーを作成するように前記コンソールに通知し、前記第1のサービス・コンテナ・グループによって送信された別のデータパケットを前記第3のサイドカーに転送するように構成され、
前記第3のサイドカーは、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行するように構成される、
請求項1に記載のノード。

【請求項6】

前記第3のサイドカーが、前記第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または前記第3のサイドカーが、前記第1のサイドカーの複製バージョンである、請求項5に記載のノード。

【請求項7】

前記第1のサイドカーが、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループに前記データパケットを送信するように構成される、
請求項5に記載のノード。

【請求項8】

前記第1のサイドカーが、セッション識別子を生成し、前記セッション識別子を前記第1のサービス・コンテナ・グループおよび前記接続制御モジュールに送信するように構成され、
前記接続制御モジュールが、前記セッション識別子と前記バックエンド・コンテナ・グループとの間の対応関係を記録するように構成され、
前記第3のサイドカーが、前記第1のサービス・コンテナ・グループから前記セッション識別子を取得し、前記セッション識別子に基づいて、前記接続制御モジュールによって記録された前記対応関係内の前記バックエンド・コンテナ・グループを決定し、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行した後に、前記別のデータパケットを前記バックエンド・コンテナ・グループに送信するように構成される、
請求項7に記載のノード。

【請求項9】

前記サイドカー割り当てポリシーが第3のポリシーを含み、前記第3のポリシーは、前記サイドカーによってサービスされるオブジェクトの数が0であるときに、前記サイドカークラスタ内のサイドカーが優先的に使用されることを示し、
前記接続制御モジュールが、前記第1のサイドカーによってサービスされるオブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が0であるとき、前記第1のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するようにさらに構成される、
請求項1に記載のノード。

【請求項10】

前記接続制御モジュールが、前記サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、前記オフラインサイドカーに関する情報を前記コンソールに送信するようにさらに構成される、
請求項1に記載のノード。

【請求項11】

前記トラフィック管理が、トラフィック制御、トラフィック保護、およびトラフィック観測を含む、請求項1に記載のノード。

【請求項12】

前記ノードが、仮想マシン、コンピュータ、またはベアメタルサーバである、請求項1から11のいずれか一項に記載のノード。

【請求項13】

コンソールと、請求項1から11のいずれか一項に記載のノードとを備える、コンテナグループ管理システム。

【請求項14】

ノード内のコンテナグループを管理するための方法であって、接続制御モジュール、サイドカークラスタ、および第1のサービス・コンテナ・グループが前記ノード上で稼働し、前記サイドカークラスタは少なくとも2つのサイドカーを含み、前記方法は、
前記接続制御モジュールによって、前記ノードに接続されたコンソールによって送信されたサイドカー割り当てポリシーを受信し、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送するステップと、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するステップと
を含む、方法。

【請求項15】

第2のサービス・コンテナ・グループが前記ノード上でさらに稼働し、前記方法は、
前記接続制御モジュールによって、前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第2のサイドカーを選択し、前記第2のサービス・コンテナ・グループによって送信されたデータパケットを前記第2のサイドカーに転送するステップと、
前記第2のサイドカーによって、前記第2のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行するステップと
をさらに含む、請求項14に記載の方法。

【請求項16】

前記第1のサイドカーに割り当てられたハードウェアリソースの仕様が前記第2のサイドカーに割り当てられたハードウェアリソースの仕様よりも高く、前記サイドカー割り当てポリシーは第1のポリシーを含み、前記第1のポリシーは、前記第1のサービス・コンテナ・グループが前記第1のサイドカーを優先的に使用することを示し、
前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択する前記ステップは、前記第1のポリシーに従って前記サイドカークラスタから前記第1のサイドカーを選択するステップを含む、
請求項15に記載の方法。

【請求項17】

第2のサービス・コンテナ・グループが前記ノード上でさらに稼働し、前記サイドカー割り当てポリシーは第2のポリシーをさらに含み、前記第2のポリシーは、前記第1のサイドカーによってサービスされるオブジェクトの数が上限値を超えないことを示し、前記方法は、
前記接続制御モジュールによって、前記第1のサイドカーによってサービスされる前記オブジェクトの数を決定し、前記数が上限値を超えないとき、前記第2のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するステップと、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットと前記第2のサービス・コンテナ・グループによって送信された前記データパケットとに対してトラフィック管理を同時に実行するステップと
をさらに含む、請求項14に記載の方法。

【請求項18】

前記方法が、
前記第1のサイドカーが故障した後で、前記接続制御モジュールによって、前記サイドカークラスタから第3のサイドカーを選択し、または前記ノードに前記第3のサイドカーを作成するように前記コンソールに通知し、前記第1のサービス・コンテナ・グループによって送信された別のデータパケットを前記第3のサイドカーに転送するステップと、
前記第3のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行するステップと
をさらに含む、請求項14に記載の方法。

【請求項19】

前記第3のサイドカーが、前記第1のサイドカーに基づいて機能がアップグレードされた新バージョンであるか、または前記第3のサイドカーが、前記第1のサイドカーの複製バージョンである、請求項18に記載の方法。

【請求項20】

前記方法が、
前記第1のサイドカーによって、前記第1のサービス・コンテナ・グループによって送信された前記データパケットに対してトラフィック管理を実行した後に、バックエンド・コンテナ・グループに前記データパケットを送信するステップ
をさらに含む、請求項18に記載の方法。

【請求項21】

前記方法が、
前記第1のサイドカーによって、セッション識別子を生成し、前記セッション識別子を前記第1のサービス・コンテナ・グループおよび前記接続制御モジュールに送信するステップと、
前記接続制御モジュールによって、前記セッション識別子と前記バックエンド・コンテナ・グループとの間の対応関係を記録するステップと、
前記第3のサイドカーによって、前記第1のサービス・コンテナ・グループから前記セッション識別子を取得し、前記セッション識別子に基づいて、前記接続制御モジュールによって記録された前記対応関係内の前記バックエンド・コンテナ・グループを決定し、前記第1のサービス・コンテナ・グループによって送信された前記別のデータパケットに対してトラフィック管理を実行した後に、前記別のデータパケットを前記バックエンド・コンテナ・グループに送信するステップと
をさらに含む、請求項20に記載の方法。

【請求項22】

前記サイドカー割り当てポリシーが第3のポリシーを含み、前記第3のポリシーは、前記サイドカーによってサービスされるオブジェクトの数が0であるときに前記サイドカークラスタ内のサイドカーが優先的に使用されることを示し、
前記サイドカー割り当てポリシーに従って前記サイドカークラスタから第1のサイドカーを選択し、前記第1のサービス・コンテナ・グループによって送信されたデータパケットを前記第1のサイドカーに転送する前記ステップは、
前記接続制御モジュールによって、前記第1のサイドカーによってサービスされるオブジェクトの数を決定し、前記第1のサイドカーによってサービスされる前記オブジェクトの数が0であるときに、前記第1のサービス・コンテナ・グループによって送信された前記データパケットを前記第1のサイドカーに転送するステップ
を含む、
請求項14に記載の方法。

【請求項23】

前記方法が、
前記接続制御モジュールによって、前記サイドカークラスタ内の各サイドカーの作動状況を監視し、オフラインサイドカーがあることを発見すると、前記オフラインサイドカーに関する情報を前記コンソールに送信するステップ
をさらに含む、請求項14に記載の方法。

【請求項24】

前記トラフィック管理が、トラフィック制御、トラフィック保護、およびトラフィック観測を含む、請求項14に記載の方法。

【請求項25】

プロセッサとメモリとを備える、コンテナグループを稼働させるためのノードであって、前記プロセッサは、前記メモリに格納された命令を実行して、請求項14から24のいずれか一項に記載の方法を実行するように構成される、ノード。

【請求項26】

コンピュータプログラム命令を含むコンピュータ可読記憶媒体であって、前記コンピュータプログラム命令がコンピューティング・デバイス・クラスタによって実行されると、前記コンピューティング・デバイス・クラスタは、請求項14から24のいずれか一項に記載の方法を実行する、コンピュータ可読記憶媒体。

【請求項27】

命令を含むコンピュータプログラム製品であって、前記命令がコンピューティング・デバイス・クラスタによって稼働すると、前記コンピューティング・デバイス・クラスタは、請求項14から24のいずれか一項に記載の方法を実行することが可能になる、コンピュータプログラム製品。

【国際調査報告】