---
schema_version: "1"
id: 9a7d45141a77b7e060c80a32b2a183a3826ce83395b6b3ef4350e1c3d87e316c
title: Runtime Fabric のイングレスの設定
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/2.8/custom-ingress-configuration.md
canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 4cff96c0f1e9c5b49ed282991fa2019b01dab94cb5f74b04ada8dcdebc4072e5
description: MuleSoft Documentation Site
release: "2.8"
latest: false
---
# Runtime Fabric のイングレスの設定

<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-important" title="Important"></i>
</td>
<td class="content">
<div class="paragraph">
<p>このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。</p>
</div>
</td>
</tr>
</tbody></table>

Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。

アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-important" title="Important"></i>
</td>
<td class="content">
<div class="paragraph">
<p>デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 <a href="https://help.mulesoft.com/s/article/Default-Ingress-Controller-Behavior-with-Runtime-Fabric-on-GKE" target="_blank" rel="noopener">「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」</a>​を参照してください。</p>
</div>
<div class="paragraph">
<p>AWS アプリケーションのロードバランサーでは、​<code>group.name</code>​ アノテーションを使用しない限り同様の動作になります。詳細は、 <a href="https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html" target="_blank" rel="noopener">「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」</a>​を参照してください。</p>
</div>
</td>
</tr>
</tbody></table>

## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点

Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。

- アプリケーションごとに複数のイングレス設定
- 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー
- TLS および HTTPS 設定
- カスタム URL 名前付け
- URL パラメーターのプレースホルダー

## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作

次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。

![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ingress-diagram.png)

1. IT 管理者がイングレスコントローラーを設定します。
2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。
3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。
4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。
5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。
6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。

## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例

次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。

お使いの Kubernetes バージョンに適した API バージョンを使用してください。

- Kubernetes v1.19 以降:
    
    - networking.k8s.io/v1
    - networking.k8s.io/v1beta1
        
        Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。
- Kubernetes v1.18 以前:
    
    - networking.k8s.io/v1beta1 のみ

### [](#networking-k8s-iov1)networking.k8s.io/v1

<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-note" title="Note"></i>
</td>
<td class="content">
<div class="paragraph">
<p>このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。</p>
</div>
</td>
</tr>
</tbody></table>

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-rtf-ingress
  namespace: rtf (1)
  labels:
spec:
  ingressClassName: rtf-nginx (2)
  tls: (3)
  - hosts:
      - app-name.example.com
    secretName: example-tls
  rules:
  - host: app-name.example.com (4)
    http:
      paths: (5)
      - pathType: Prefix
        path: / (6)
        backend: (7)
          service:
            name: service-name
            port:
              name: service-port
```

この例について、次の点に注意してください。

<table>
<tbody><tr>
<td><i class="conum" data-value="1"></i><b>1</b></td>
<td>このテンプレートは ​<code>rtf</code>​ 名前空間に配置する必要があります。</td>
</tr>
<tr>
<td><i class="conum" data-value="2"></i><b>2</b></td>
<td>ingressClassName には ​<code>rtf-</code>​ のプレフィックスを付ける必要があります (たとえば、​<code>rtf-nginx</code>​)。
<div class="paragraph">
<p>Runtime Fabric では ​<code>rtf-</code>​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。
<code>spec.ingressClassName</code>​ 項目または ​<code>kubernetes.io/ingress.class</code>​ アノテーションの ​<code>rtf-</code>​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。
イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​<code>nginx</code>​ や ​<code>haproxy</code>​) を使用する ​<code>spec.ingressClassName</code>​ 値が含まれるリソースのみを検出します。</p>
</div></td>
</tr>
<tr>
<td><i class="conum" data-value="3"></i><b>3</b></td>
<td>TLS は省略可能です。
<div class="paragraph">
<p><code>secretName</code>​ 属性が含まれる TLS セクションを追加する場合、必ず ​<code>rtf</code>​ 名前空間で参照される TLS シークレットを作成する必要もあります。</p>
</div></td>
</tr>
<tr>
<td><i class="conum" data-value="4"></i><b>4</b></td>
<td>アプリケーションをデプロイすると、​<code>app-name</code>​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。</td>
</tr>
<tr>
<td><i class="conum" data-value="5"></i><b>5</b></td>
<td>テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。</td>
</tr>
<tr>
<td><i class="conum" data-value="6"></i><b>6</b></td>
<td><code>path</code>​ パラメーター値は、​<a href="#configure-ingress-for-a-mule-application">Mule アプリケーションのイングレスを設定</a>​するときに ​<strong>[Path (パス)]</strong>​ 項目に追加した値で置き換えられます。​<code>path</code>​ はプレースホルダーではありません。</td>
</tr>
<tr>
<td><i class="conum" data-value="7"></i><b>7</b></td>
<td>これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。</td>
</tr>
</tbody></table>

パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。

### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1

```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-rtf-ingress
  namespace: rtf (1)
  labels:
spec:
  ingressClassName: rtf-nginx (2)
  tls: (3)
  - hosts:
      - app-name.example.com
    secretName: example-tls
  rules:
    - host: app-name.example.com (4)
      http:
        paths: (5)
        - path: / (6)
          pathType:
          backend: (7)
            serviceName: service-name
            servicePort: 80
```

この例について、次の点に注意してください。

<table>
<tbody><tr>
<td><i class="conum" data-value="1"></i><b>1</b></td>
<td>このテンプレートは ​<code>rtf</code>​ 名前空間に配置する必要があります。</td>
</tr>
<tr>
<td><i class="conum" data-value="2"></i><b>2</b></td>
<td>ingressClassName には ​<code>rtf-</code>​ のプレフィックスを付ける必要があります (たとえば、​<code>rtf-nginx</code>​)。
<div class="paragraph">
<p>Runtime Fabric では ​<code>rtf-</code>​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。
<code>spec.ingressClassName</code>​ 項目または ​<code>kubernetes.io/ingress.class</code>​ アノテーションの ​<code>rtf-</code>​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。
イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​<code>nginx</code>​ や ​<code>haproxy</code>​) を使用する ​<code>spec.ingressClassName</code>​ 値が含まれるリソースのみを検出します。</p>
</div></td>
</tr>
<tr>
<td><i class="conum" data-value="3"></i><b>3</b></td>
<td>TLS は省略可能です。
<div class="paragraph">
<p><code>secretName</code>​ 属性が含まれる TLS セクションを追加する場合、必ず ​<code>rtf</code>​ 名前空間で参照される TLS シークレットを作成する必要もあります。</p>
</div></td>
</tr>
<tr>
<td><i class="conum" data-value="4"></i><b>4</b></td>
<td>アプリケーションをデプロイすると、​<code>app-name</code>​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。</td>
</tr>
<tr>
<td><i class="conum" data-value="5"></i><b>5</b></td>
<td>テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。</td>
</tr>
<tr>
<td><i class="conum" data-value="6"></i><b>6</b></td>
<td><code>path</code>​ パラメーター値は、​<a href="#configure-ingress-for-a-mule-application">Mule アプリケーションのイングレスを設定</a>​するときに ​<strong>[Path (パス)]</strong>​ 項目に追加した値で置き換えられます。​<code>path</code>​ はプレースホルダーではありません。</td>
</tr>
<tr>
<td><i class="conum" data-value="7"></i><b>7</b></td>
<td>これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。</td>
</tr>
</tbody></table>

パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。

### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー

次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。

<table class="tableblock frame-all grid-all fit-content spread">
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">プレースホルダーの名前</th>
<th class="tableblock halign-left valign-top">場所</th>
<th class="tableblock halign-left valign-top">値の例</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>business-group-id</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>path</code>​、​<code>host</code>​、​<code>annotation、labels</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
<div class="content">
<pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml">labels:
  business:
  business-group-id</code></pre>
</div>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>environment-id</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>path</code>​、​<code>host</code>​、​<code>annotation、labels</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
<div class="content">
<pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml">labels:
  environment:
  environment-id</code></pre>
</div>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>unique-id</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>path</code>​、​<code>annotation、labels</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
<div class="content">
<pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml">path: /app-name-unique-id.com</code></pre>
</div>
</div></div></td>
</tr>
</tbody>
</table>

`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-note" title="Note"></i>
</td>
<td class="content">
<div class="paragraph">
<p><code>unique-id</code>​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。</p>
</div>
</td>
</tr>
</tbody></table>

## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用

イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。

`rtf.mulesoft.com/synchronized: "true"`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。

```none
apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: <agent-namespace>
  labels:
    rtf.mulesoft.com/synchronized: "true"
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls
```

この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。

<table><tbody><tr><td class="icon"><i class="fa icon-note" title="Note"></i></td><td class="content">同期メカニズムを使用して、デプロイ時に Runtime Fabric エージェントの名前空間のシークレットをアプリケーションの名前空間に複製できます。</td></tr></tbody></table>

## [](#既存のイングレステンプレートを変更する)既存のイングレステンプレートを変更する

既存のイングレステンプレートは、すでにアプリケーションのデプロイで使用されている場合でも修正できます。 テンプレートを変更しても、このテンプレートに基づいてすでに作成されているイングレスオブジェクトは更新されません。

テンプレートの変更を反映して既存のイングレスを更新するには、Mule アプリケーションを再デプロイする必要があります。 たとえば、ベースドメインを更新してイングレステンプレートのエンドポイントの変更が必要になった場合は、古いエンドポイントを削除して、アプリケーションの再デプロイ時に新しいエンドポイントを追加します。

## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する

イングレスを設定するには、次のタスクを実行します。

1. イングレスリソーステンプレートを作成してクラスターで適用します。
2. Mule アプリケーションのイングレスを設定します。

### [](#始める前に)始める前に

Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。

### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する

[テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。

1. テンプレート例を新しいファイルにコピーして、コメントに変更します。
2. ファイル名に ​`.yaml`​ 拡張子を含めます。
3. イングレステンプレートを適用するには、次のコマンドを実行します。
    
    ```copy
    kubectl apply -f <TEMPLATE_FILENAME.yaml>
    ```

テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。

テンプレートを正常に適用したら、次のコマンドを使用して表示できます。

```copy
kubectl describe ingress [Ingress Name] -n rtf
```

### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する

Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。

この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-note" title="Note"></i>
</td>
<td class="content">
<div class="paragraph">
<p>次に、アプリケーションのイングレスを設定する方法の概要を示します。
完全なデプロイメント手順については、​<a href="https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric" class="xref page">「Runtime Fabric に Mule アプリケーションをデプロイする」</a>​を参照してください。
Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​<code>http</code>​ のデプロイメント設定パラメーター ​<code>publicUrl</code>​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。
詳細は、​<a href="https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf#deploymentsettings-parameters-reference" class="xref page">「deploymentSettings パラメーターリファレンス」</a>​を参照してください。</p>
</div>
</td>
</tr>
</tbody></table>

1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。
2. **\[Ingress (イングレス)\]**​ を選択します。
3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。
4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。
    
    **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。
5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。
    
    ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png)
6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。
7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。
8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。

## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換

Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。次の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。

<table class="tableblock frame-all grid-all fit-content spread">
<colgroup>
<col>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">アップグレード前の Runtime Fabric</th>
<th class="tableblock halign-left valign-top">アップグレード後の Runtime Fabric</th>
<th class="tableblock halign-left valign-top">必要なアクション</th>
<th class="tableblock halign-left valign-top">TLS サポート</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">ドメインは設定されず、ingress-ConfigMap は適用されない</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">アップグレード後にテンプレートが自動的に生成されない</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">テンプレートを作成する。​<a href="#Create an Ingress Resource Template and Apply it in the Cluster">[Create an Ingress Resource Template and Apply it in the Cluster]</a>​を参照してください。</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">-</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">ドメインは設定されないが、有効な ingress-ConfigMap が適用される</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">生成されたテンプレートにホストの ​<code>*</code>​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">生成されたテンプレートで ​<code>host</code>​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">デフォルトでは TLS セクションは追加されない</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">有効なドメインが設定されるが、ingress-ConfigMap は適用されない</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​<code>/app-name</code>​ が含まれる</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">ドメインで ​<code>https://</code>​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>https://</code>​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">有効なドメインが設定され、有効な ingress-ConfigMap が適用される</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">ドメインで ​<code>https://</code>​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>https://</code>​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる</p></td>
</tr>
</tbody>
</table>

## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング

Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。

### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない

シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。

この問題をトラブルシューティングする手順は、次のとおりです。

1. アプリケーションがポート 8081 でリスンしていることを確認します。
    
    ```copy
    kubectl port-forward -n [NAMESPACE] svc/<APP_NAME> 8081:8081
    ```
2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。
    
    ```copy
    curl -v \http://127.0.0.1:8081/
    ```
    
    これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。
3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。
    
    ```copy
    kubectl get ingress -n [NAMESPACE]
    ```
4. サービスが作成されたことを検証します。
    
    ```copy
    kubectl get svc -n [NAMESPACE]
    ```

作成されなかった場合は、Runtime Fabric エージェントのログを確認します。

+

```copy
kubectl logs -n rtf [AGENT_POD_NAME] -f
```

サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。

### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない

シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。

この問題をトラブルシューティングする手順は、次のとおりです。

1. イングレスとサービスのリソースを確認します。
    
    ```copy
    kubectl get ingress -n<APP-NAMESPACE>
    kubectl get svc -n<APP-NAMESPACE>
    ```
    
    次のような結果が返されます。
    
    \# kubectl get ingress -n<APP-NAMESPACE>
    NAME                           CLASS       HOSTS               ADDRESS       PORTS     AGE
    <INGRESS\_RESOURCE>            <INGRESS>    <HOSTNAME>.com      <HOST IP>     80, 443   7m3s
    
    # kubectl get svc -n<APP-NAMESPACE>
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
    <SERVICE-NAME>       ClusterIP   <CLUSTER IP>   <none>        8081/TCP,8082/TCP,5701/TCP   8m5s
2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。
    
    ```copy
    kubectl get ing -n<APP-NAMESPACE> <INGRESS-RESOURCE-NAME> -oyaml
    ```
    
    次のような結果が返されます。
    
    ```yaml
    # kubectl get ing -n<APP-NAMESPACE> <INGRESS-RESOURCE-NAME> -oyaml
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      labels:
        ingress.rtf.mulesoft.com/svcName: <APP_NAME>
        ingress.rtf.mulesoft.com/svcVersion: <UUID>
    …
    …
    spec:
      ingressClassName: <INGRESS-CLASS>
      rules:
      - host: myapp.example.com
        http:
          paths:
          - backend:
              serviceName: myapp
              servicePort: 8081
            path: /
            pathType: Prefix
      tls:
      - hosts: myapp.example.com
        secretName: example-tls
    status:
      loadBalancer:
        ingress:
        - hostname: <hostname>
    ```
3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。
    
    ```copy
    kubectl logs -f -n<APP-NAMESPACE> <APP-POD-NAME> -c app
    ```
    
    次のような結果が返されます。
    
    \# kubectl logs -f -n<<APP-NAMESPACE> <APP-POD> -c app
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    + Starting app '<APP\_NAME>'                                                     +
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    \[2021-07-29 21:22:37.842\] INFO  QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager
    \[2021-07-29 21:22:37.842\] INFO  QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager
    \[2021-07-29 21:22:37.846\] INFO  AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config
    \[2021-07-29 21:22:37.859\] INFO  GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081'
    \[2021-07-29 21:22:37.874\] INFO  FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow
    \[2021-07-29 21:22:38.171\] INFO  AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener
    \[2021-07-29 21:22:38.178\] INFO  LogUtil \[ArtifactDeployer.start.01\]:
4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。
5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。

### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない

シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。

イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。