---
title: クラスターの種類の比較
description: Amazon EKS、Azure Kubernetes Service (AKS)、Red Hat OpenShift、K3s のいずれかに OpenLM Platform をインストールする前に、それぞれを比較します。
product: OpenLM Platform
---

OpenLM Platform は、どの種類のクラスターでも同じ方法でインストールします。チャート、イメージ、手順はすべて同じです。異なるのはそれを取り巻くクラスターの部分で、トラフィックの受け入れ方、使用するストレージクラス、ノードの設定方法、利用できるマネージドデータサービスが変わります。

## 一覧で比較

次の表で、4 種類のクラスターを比較します。

| | Amazon EKS | AKS | Red Hat OpenShift | K3s |
|---|---|---|---|---|
| **Ingress** | NLB の背後の Traefik または ingress-nginx | Azure LB の背後の ingress-nginx または Traefik | OpenShift のルート（ルーター） | 組み込みの Traefik |
| **`INGRESS_CLASS`** | `traefik` / `nginx` | `nginx` / `traefik` | （使用しない） | `traefik` |
| **`STORAGE_CLASS`** | `gp3`（EBS CSI） | `managed-csi`（Azure Disk） | クラスターのブロックストレージクラス。例: `gp3-csi`、`managed-csi`、`thin-csi` | `local-path` |
| **TLS の終端** | Ingress コントローラー | Ingress コントローラー | ルーター（エッジ） | Traefik |
| **Pod のユーザー ID** | チャートが設定 | チャートが設定 | **OpenShift が割り当て**（`useOpenShift: true`） | チャートが設定 |
| **ノード配置** | 任意（ノードグループのラベル） | 任意（ノードプールのラベル） | 通常は無効（ノードにラベルを付けられないため） | 通常は無効（ノードが 1 台または少数のため） |
| **SQL Server** | RDS for SQL Server、または独自のもの | Azure SQL Database / Elastic Pool、または独自のもの | 到達可能な任意の SQL Server | 独自のもの |
| **Redis** | ElastiCache（Redis/Valkey） | Azure Managed Redis / Azure Cache | 任意 | 独自のもの |
| **Kafka** | Amazon MSK または独自のもの | 独自のものまたは Confluent Cloud | 独自のもの（オペレーター。例: Strimzi） | 独自のもの |
| **MongoDB** | MongoDB Atlas または独自のもの（DocumentDB は不可） | MongoDB Atlas または独自のもの（Cosmos DB は不可） | Atlas または独自のもの | 独自のもの |
| **追加の手順** | NLB、ノードのファイル監視の上限 | NAT IP のファイアウォールルール | OpenShift 用の values ファイル、追加のルート、証明書 | リダイレクト、DNS の書き換え |

各プラットフォームのページは、同じトピックを同じ順序で扱います。始める前に、Ingress、ストレージ、ノード設定、values、データサービス、プラットフォーム固有の確認です。お使いのクラスターの種類のページを開いてください。

- [Amazon EKS](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/eks)
- [Azure Kubernetes Service (AKS)](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/aks)
- [Red Hat OpenShift](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/openshift)（ROSA と ARO を含む）
- [K3s](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/k3s)

## すべてのノードに適用するノード設定

OpenLM Platform は約 100 個の .NET サービスを起動します。そのため、これらを実行するすべてのノードで、Linux のファイル監視の上限を 2 つ設定します。

| 設定 | 最小値 | 理由 |
|---|---|---|
| `fs.inotify.max_user_instances` | 8192 | 各サービスは自身の構成ファイルを監視します。一般的な既定値の 128 では足りなくなり、Pod が `too many open files` で失敗します。 |
| `fs.inotify.max_user_watches` | 524288 | 同じ理由 |

ノードを管理している場合は、`/etc/sysctl.d/` で上限を設定します。管理していない場合は、小さな DaemonSet ですべてのノードに設定します。この DaemonSet は特権モードで実行されるため、クラスターのポリシーで禁止されている場合があります。

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata: { name: openlm-node-sysctl, namespace: kube-system }
spec:
  selector: { matchLabels: { app: openlm-node-sysctl } }
  template:
    metadata: { labels: { app: openlm-node-sysctl } }
    spec:
      initContainers:
        - name: sysctl
          image: public.ecr.aws/docker/library/busybox:stable
          securityContext: { privileged: true }
          command: ["sh", "-c", "sysctl -w fs.inotify.max_user_instances=8192 fs.inotify.max_user_watches=524288"]
      containers:
        - name: wait
          image: public.ecr.aws/docker/library/busybox:stable
          command: ["sleep", "2147483647"]
          resources: { requests: { cpu: 1m, memory: 8Mi }, limits: { memory: 16Mi } }
      tolerations: [{ operator: Exists }]
```

値を確認するには、ノード上またはデバッグ用の Pod から次のコマンドを実行します。

```bash
kubectl debug node/<node> -it --image=public.ecr.aws/docker/library/busybox:stable -- cat /proc/sys/fs/inotify/max_user_instances
```