Gateway Management
APIゲートウェイとゲートウェイ管理とは何ですか?
API Gateway は、APIトラフィックの中央管理ポイントです。クライアントのリクエストを適切なバックエンドサービスにルーティングし、必要に応じてリクエストとレスポンスを変換し、セキュリティポリシーを強制し、トラフィックを監視し、全体的なAPIの信頼性を確保します。
APIゲートウェイの主な機能
- Routing: クライアントのリクエストを適切なバックエンドサービスに指示します。
- Transformation: 必要に応じてリクエストまたはレスポンスの形式を変換します。
- Authentication & Authorization: クライアントの資格情報を検証し、アクセス権を付与します。
- Traffic Control: バックエンドの過負荷を防ぐためにAPIトラフィックを管理および制限します。
- Logging & Monitoring: トラッキングと分析のためにAPI使用データを記録します。
- Security & Protection: 悪意のある攻撃をブロックし、APIのセキュリティを強化します。
APIMでは、Kong APIゲートウェイが使用され、Kubernetes (K8s) デプロイメントとしてプロビジョニングされます。
ゲートウェイ管理メニュー
APIMの Gateway Management メニューでは、ユーザーが以下を行うことができます:
- ゲートウェイのリストを表示および管理します。
- 各ゲートウェイのステータスを監視します。
- プロジェクトごとにゲートウェイをクエリ、作成、更新、削除します。
- 複数のゲートウェイURLを管理します。
- ノードアフィニティ、トレランス、およびトポロジ設定を構成します。
- HTTPSセキュリティのためにTLS証明書を設定します。
- メタデータを注釈/ラベル(K8s Ingress 注釈/ラベル)を介して追加します。
各 Gateway URL は、APIリクエストに使用されるエンドポイントを表します。
たとえば、APIが https://api.company.com/path を介してアクセスされる場合、ゲートウェイURLは api.company.com です。
ゲートウェイリスト画面
Gateway List 画面は、プロジェクト内のすべてのゲートウェイの概要を提供し、ユーザーが以下を行えるようにします:
- 一目で全てのゲートウェイを表示します。
- CPU、メモリ、およびレプリカの構成を確認します。
- 各ゲートウェイの稼働中または待機中のステータスを監視します。
- 特定のゲートウェイを検索したり、新しいゲートウェイを作成したりします。
ゲートウェイの作成
新しいゲートウェイを作成するには、以下の手順に従ってください:
ゲートウェイ管理メニューに移動します。
"ゲートウェイを作成"をクリックします
プロジェクトを選択します
ゲートウェイが管理されるプロジェクトを選択します。プロジェクトを作成する手順については、Tenant Manager Console/Create a Project. を参照してください。
ゲートウェイ設定を構成します
Gateway Configuration セクションでは、ゲートウェイの詳細なカスタマイズが可能です。以下は主要なフィールドです:
Gateway Type- Purpose: APIゲートウェイのタイプを定義します。
- Mandatory: はい
- Input Instructions: プロジェクトのゲートウェイタイプに合わせます。変更できません。
- Purpose: ゲートウェイの一意の識別子です。
- Mandatory: はい
- Input Instructions: 英字、数字、spaces、ハイフン「-」、アンダースコア「_」、または二重コロン「:」のみ使用できます。英字で始める必要があります。
- Purpose: ゲートウェイインスタンスを識別します。
- Mandatory: はい
- Input Instructions: ゲートウェイ名に基づいて自動的に入力されます。
- Purpose: ゲートウェイに関する追加情報を提供します。
- Mandatory: いいえ
- Input Instructions: 短い説明を入力します。
- Purpose: ゲートウェイのフィルタリングと検索に役立ちます。
- Mandatory: いいえ
- Input Instructions: ゲートウェイには多くのタグを持つことができます。Enterを押してタグを入力します.
- Purpose: ゲートウェイのリソースを割り当てます。
- Mandatory: はい
- Input Instructions: スライダーを使用して調整します。値の範囲は500から16000 m/miです。
- Purpose: ゲートウェイが使用する内部データベースのリソースを割り当てます。
- Mandatory: はい
- Input Instructions: スライダーを使用して調整します。値の範囲は500から16000 m/miです。
- Purpose: デプロイ後にゲートウェイのリソース割り当てを自動スケールします。
- Mandatory: はい
- Instructions: 自動スケーリングをオンにするためのトグル。オンにしたら、最小レプリカ、最大レプリカ、CPU使用率、メモリ使用率の自動スケーリング値を設定します。
- Purpose: ゲートウェイがKubernetesで実行される場所を決定します。
- Mandatory: はい
- Input Instructions: ドロップダウンリストから名前空間を選択します。
- Purpose: ゲートウェイのストレージがどのようにプロビジョニングされるかを定義します。
- Mandatory: はい
- Input Instructions: ドロップダウンリストからストレージクラスを選択します。
- Purpose: ゲートウェイのストレージ割り当てを指定します。
- Mandatory: はい
- Input Instructions: 5から500 (Gi) の間の値を入力します。
- Purpose: Kongプロキシのサービスタイプを決定します。
- Mandatory: はい
- Input Instructions: ClusterIP、NodePort、LoadBalancerのいずれかを選択します。NodePortまたはLoadBalancerが選択された場合、KongプロキシサービスのNodePort値(30000から32767の間)を入力する必要があります。
- Purpose: アフィニティは、ノードラベルを一致させることによって、ゲートウェイポッドがスケジュールされるノードを制御するために使用されます。
- Mandatory: トグルがONの場合ははい。
- アフィニティをONに切り替えて有効にします。その後、ノードラベルのキーと値を提供します。これは、nodeAffinity ルールに変換され、Kubernetesで requiredDuringSchedulingIgnoredDuringExecution を使用します。例えば:
nodeAffinity:
- Purpose: トレランスは、特定のワークロードのためにマーク(汚染)されたノードにゲートウェイポッドをスケジュールできるようにします。
- Mandatory: トグルがONの場合ははい。
- Input Instructions: ONに切り替えた後、次の情報を入力してください:
- オペレーター: EqualまたはExistsのいずれかを選択します。Equal: キーと値は正確に一致する必要があります。Exists: キーのみが存在する必要があり、値は必須ではありません。
- キーと値: 汚染キーと値を提供します(オペレーターがExistsの場合、値はオプションです)。
tolerations:
- effect: NoSchedule
key: "tolerationKey"
operator: "Equal" または Exists
value: "tolerationValue"
- Purpose: トポロジー分散制約は、ゲートウェイポッドが障害ドメイン(ゾーンやノードなど)全体に均等に分散されることを保証し、耐障害性と可用性を向上させます。
- Mandatory: ONに切り替えた場合は「はい」。
- Input Instructions: ONに切り替えた後、次の情報を入力してください:
- Max Skew: トポロジー領域間のゲートウェイポッドの数の最大許容差(例: 1に設定した場合、ゾーンごとのポッド数は1を超えてはなりません)。
- When Unsatisfiable: 次のいずれかを選択します: ScheduleAnyway(デフォルト): 分散制約が完全に満たされなくてもスケジューリングを許可します; DoNotSchedule: 制約が失敗した場合、ポッドのスケジューリングをブロックします; DoNotScheduleIfNotSatisfied: 分散条件が満たされない場合のみスケジューリングを制限する新しい戦略です。
これに対応するKubernetesルールの例:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app.kubernetes.io/instance: test-kong
- Purpose: 内部Redisインスタンスをキャッシュ用に許可します。
- Mandatory: ONに切り替えた場合は「はい」。
- Input Instructions: ON/OFFを切り替えます。ONの場合、ゲートウェイがデプロイされるとデフォルトのRedisがインストールされます。OFFの場合、ユーザーはAPIM RedisがRedisを使用するポリシー(レート制限、JWTブラックリスト、OIDC)をサポートしていないことを通知されます。ユーザーはOFFに切り替えるためのプロンプトで確認する必要があります。
- Purpose: Fluent Bitは、ゲートウェイコンテナからログを収集、フィルタリング、転送する軽量のログプロセッサです。
- Mandatory: いいえ
- Input Instructions: 有効にすると、次のいずれかの宛先オプションを追加で選択できます:
- OpenTelemetry: OpenTelemetryエージェントを使用してログとテレメトリデータを転送します。
- Elasticsearch: Elasticsearchクラスターにログを転送してインデックス作成と検索を行います。
注意: これらのオプションのうち、同時にアクティブにできるのは1つだけです。1つを有効にすると、他のオプションがすでにアクティブな場合、現在アクティブなものを無効にするための確認プロンプトが表示されます。
- Purpose: このフィールドでは、Kong Gatewayランタイムに対して、パフォーマンスや動作を微調整する必要がある場合に、JSON形式で生の設定を提供することにより、高度な低レベルの構成を直接適用できます。
- Mandatory: ONに切り替えた場合は「はい」。
- Input Instructions: 切り替えた後、カスタムKongランタイム設定を入力できるJSONエディタが表示されます。
例:
"upstream_keepalive_idle_timeout": 60,
"upstream_keepalive_max_requests": 100000,
"nginx_http_keepalive_requests": 100000,
"upstream_keepalive_pool_size": 1024
注意: 設定ミスはゲートウェイの不安定な動作を引き起こす可能性があります。変更を適用する前にKongのドキュメントまたはプラットフォーム管理者に相談してください。
ゲートウェイ構成は、以下の表に要約されています:
Field Name | Purpose | Input Notes | Mandatory |
---|---|---|---|
ゲートウェイタイプ | APIゲートウェイのタイプを定義します。 | プロジェクトのゲートウェイタイプに合わせます。変更できません。 | はい。デフォルトはkongです。 |
ゲートウェイ名 | ゲートウェイの一意の識別子。 | 英字、数字、ハイフン「-」、アンダースコア「_」、またはコロン「:」のみ使用できます。英字で始める必要があります。 | はい |
ゲートウェイインスタンス名 | ゲートウェイインスタンスを識別します。 | ゲートウェイ名に基づいて自動的に入力されます。 | はい |
ゲートウェイの説明 | ゲートウェイに関する追加の詳細を提供します。 | 短い説明を入力してください。 | いいえ |
ゲートウェイタグ | ゲートウェイのフィルタリングと検索に役立ちます。 | ゲートウェイには多くのタグを持つことができます。Enterを押してタグを入力します. | いいえ |
ゲートウェイCPU/メモリ | ゲートウェイのリソースを割り当てます。 | スライダーを使用して調整します。値の範囲は500から16000 m/miです。 | はい |
データベースCPU/メモリ | ゲートウェイで使用される内部データベースのリソースを割り当てます。 | スライダーを使用して調整します。値の範囲は500から16000 m/miです。 | はい |
ゲートウェイオートスケーリング | デプロイ後にポッドリソースの自動スケーリングを有効にします。 | ON/OFFを切り替えます。ONの場合、次の設定を行います: 最小レプリカ、最大レプリカ、CPUしきい値(%)、メモリしきい値(%) | 切り替えた場合ははい |
Kongネームスペース | Kubernetesでゲートウェイが実行される場所を決定します。 | ドロップダウンリストからネームスペースを選択します。 | はい |
Kongストレージクラス | ゲートウェイのストレージがどのようにプロビジョニングされるかを定義します。 | ドロップダウンリストからストレージクラスを選択します。 | はい |
ストレージ容量 | ゲートウェイのストレージ割り当てを指定します。 | 5から500(Gi)の間の値を入力します。 | はい |
Kongプロキシサービスタイプ | 外部アクセスのためのKongプロキシのサービスタイプを定義します | ClusterIP、NodePort、またはLoadBalancerから選択します。デフォルトはClusterIPです。 | はい |
アフィニティ | ゲートウェイポッドをラベルが一致するノードにスケジュールします。 | ON/OFFを切り替えます。ONの場合、ノードラベルのキーと値を入力します | 切り替えた場合ははい |
トレランス | ゲートウェイポッドが汚染されたノードで実行されることを許可します。 | ON/OFFを切り替えます。ONの場合、オペレーターを選択します: EqualまたはExists。キーとオプションの値を入力します。 | 切り替えた場合ははい |
トポロジー分散 | ゾーン全体にポッドを均等に分配して可用性を向上させます。 | ON/OFFを切り替えます。ONの場合、次の情報を入力します: 最大偏差(例: 1)。満たされない場合の選択肢を選択します: ScheduleAnyway、DoNotSchedule、DoNotScheduleIfNotSatisfiedから選択します | 切り替えた場合ははい |
内部Redis | 内部Redisインスタンスをキャッシュ用に許可します。 | ON/OFFを切り替えます。ONの場合、ゲートウェイがデプロイされるとデフォルトのRedisがインストールされます。 | 切り替えた場合ははい |
Fluent Bit | メトリック収集のためのOpenTelemetryエージェントまたはログ収集のためのElasticsearchを有効にします。 | OpenTelemetryまたはElasticsearchのいずれかを選択できます | 切り替えた場合ははい |
Kong設定 | Kongの設定を手動でオーバーライドすることを可能にします。 | エディタを有効にするためにONに切り替え、有効なJSONを入力します。 | 切り替えた場合ははい |
完全な作成
CREATE A GATEWAYボタンをクリックして作成を完了し、ゲートウェイ構成を保存します。
ゲートウェイURLの追加と管理
ゲートウェイURL構成では、ユーザーがAPIゲートウェイのための1つまたは複数の公開ドメインを定義できます。また、HTTPS用のTLS証明書、APIルーティングのためのグローバルベースパス、および注釈を通じた追加のメタデータもサポートしています。各ゲートウェイは複数のゲートウェイURLを持ち、APIゲートウェイへのアクセス方法を定義します。
ゲートウェイURLを追加するには、ユーザーはゲートウェイ管理画面に表示されている作成したゲートウェイをクリックして、ゲートウェイ変更画面に入ることができます。
そこから、ユーザーはその下にあるゲートウェイURL構成セクションを見つけることができます。
以下は、Gateway URL を作成する手順です:
URL を作成する
複数の URL を作成するには、ADDITION をクリックします。URL を設定するための新しいブロックが下に作成されます。
Gateway URL を設定する
Gateway URL を設定するための主要なフィールドは以下の通りです:
Gateway URL- Purpose: Gateway にアクセス可能な公開ドメインを定義します。ユーザーが使用している Gateway URL を変更すると、既存の API が正しく呼び出されない可能性があります。
- Mandatory: はい
- Input Instructions: 有効なドメインを入力してください。
- Example:
your.domain.com
your.domain.com:8443
- Purpose: この Gateway の下にあるすべての API の共通プレフィックスを設定します。定義されている場合、この Gateway の下にあるすべての API はこのプレフィックスを継承します。使用中に Basepath が変更されると、既存の API が正しく呼び出されない可能性があります。
- Mandatory: はい
- Input Instructions: ベースパスを入力してください。/ のままにすると、ルートが使用されます。
- Example:
/ /apim
- Purpose: HTTPS 通信を有効にするために、SSL 証明書を提供する tls.crt と TLS 証明書を認証するための tls.key ファイルを含めます。Gateway URL と通信する際に HTTPS のみを許可するネットワークポリシーが適用されている場合、ユーザーは HTTPS をオンにする必要があります。ユーザーが K8s Secret で TLS 証明書を登録し、K8s Ingress を通じて TLS 認証を処理する場合、tls.crt/tls.key の値を入力する必要があります。
- Mandatory: 依存
- Input Instructions: PEM 形式で証明書の内容を貼り付けます。安全な HTTPS 接続に必要です。
- Purpose: この Gateway URL 設定に使用する Ingress コントローラーを指定します。
- Mandatory: はい
- Input Instructions: ドロップダウンから Ingress クラスを選択します。利用可能なオプションには以下が含まれる場合があります:
- nginx (デフォルト)
- alb
- appsec-kong
この設定は、選択した Ingress コントローラーを通じて Gateway URL をルーティングします。
- Purpose: この Gateway URL のために作成された Ingress リソースに Kubernetes ラベルを追加します。分類や自動化の目的に役立ちます。
- Mandatory: いいえ
- Input Instructions: 1つ以上のキー-バリュー ペアを入力します。これらのラベルは作成された Ingress オブジェクトに適用されます。プラスボタンを使用して複数のエントリを追加するか、バツボタンを使用して追加されたエントリを削除します。
- Purpose: カスタムタイムアウト、ヘッダー操作、またはコントローラー固有のオプションなど、高度な設定のために Kubernetes Ingress 注釈を追加します。
- Mandatory: いいえ
- Input Instructions: 2つのモードを使用して注釈を入力できます:
フォームモード (JSON トグルオフ): 各注釈のために手動でキーとバリューを入力します。システムの制約に応じて、一部のフィールドは編集できない場合があります。プラスボタンをクリックして複数の注釈を追加したり、バツボタンをクリックして追加された注釈を削除したりできます。少なくとも1つの注釈を保持する必要があります。
例:
キー: [nginx.ingress.kubernetes.io/proxy-connect-timeout](http://nginx.ingress.kubernetes.io/proxy-connect-timeout)
値: more_clear_headers \"server\
JSON モード (JSON トグルオン): エディタにキー-バリュー JSON オブジェクトの配列として注釈を入力します。
例:
"key": "[nginx.ingress.kubernetes.io/configuration-snippet](http://nginx.ingress.kubernetes.io/configuration-snippet)",
"value": "more_clear_headers \"server\";more_clear_headers \"via\";"
Gateway URL 設定は以下の表にまとめられています:
Field Name | Purpose | Input Notes |
---|---|---|
Gateway URL | Gateway にアクセス可能な公開ドメインを定義します。ユーザーが使用している Gateway URL を変更すると、既存の API が正しく呼び出されない可能性があります。 | 有効なドメインを入力してください (例: api.example.com)。必須フィールド。 |
グローバル BasePath | この Gateway の下にあるすべての API の共通プレフィックスを設定します。定義されている場合、この Gateway の下にあるすべての API はこのプレフィックスを継承します。 | ベースパスを入力してください (例: /api)。/ のままにすると、ルートが使用されます。 |
TLS 証明書 (tls.crt) | SSL 証明書を提供することにより、HTTPS 通信を有効にします。 | PEM 形式で証明書の内容を貼り付けます。安全な HTTPS 接続に必要です。 ユーザーが K8s Secret で TLS 証明書を登録し、K8s Ingress を通じて TLS 認証を処理する場合、tls.crt/tls.key の値を入力する必要があります。 |
TLS プライベートキー (tls.key) | TLS 証明書を認証するために使用されます。 | PEM 形式でプライベートキーの内容を貼り付けます。提供された証明書と一致する必要があります。 |
Ingress クラス | この Gateway URL 設定に使用する Ingress コントローラーを指定します。 | nginx (デフォルト)、alb または appsec-kong から Ingress クラスを選択します。 |
ラベル | この Gateway URL のために作成された Ingress リソースに Kubernetes ラベルを追加します。 | 1つ以上のキー-バリュー ペアを入力します。ペアを追加または削除できます。 |
注釈 | 高度な設定のために Kubernetes Ingress 注釈を追加します。 | 2つのモードを使用して複数の注釈を入力できます: キー-バリュー ペア (JSON モードオフ) または JSON スクリプト (JSON モードオン)。 |
もし2つの Gateway URL (api.example.com と service.example.com) が BasePath /api で設定されている場合:
https://api.example.com/api/{API-Path}
https://service.example.com/api/{API-Path}
が有効な API エンドポイントになります。
Gateway の変更
ユーザーは既存の Gateway を変更できます:
-
リストから Gateway を選択します。
-
設定可能なフィールドと入力を編集します (Gateway 説明、Gateway タグ、Gateway CPU/メモリ、データベース CPU/メモリ、トグルと値など)。
- 必要に応じて Gateway URLs を更新します。
- 変更を保存して更新を適用します。
ユーザーが Gateway URL を変更した場合、SAVE GATEWAY URL ボタンをクリックしてから SAVING A GATEWAY ボタンをクリックすることを忘れないでください。
Gateway を削除する
Gateway を削除すると、permanently remove すべての関連データが削除されます。このアクションは cannot be undone。
- Gateway Management に移動します。
- 削除する Gateway を選択します。
- "Deleting A Gateway" をクリックしてアクションを確認します。
- この Gateway に依存する API はもはやアクセスできなくなります。
- 削除する前に、アクティブな API が依存していないことを確認してください。