--- title: "ステップ 1: クラスターを準備する" description: OpenLM Platform 用に Kubernetes クラスターを準備します。namespace を作成し、ストレージと Ingress コントローラーを確認して、DNS 名を作成します。 product: OpenLM Platform --- OpenLM Platform 用にクラスターを準備します。namespace を作成し、ストレージと Ingress を確認し、DNS 名を作成して、Pod からその名前に到達できることを確認します。最初に、[インストールワークシート](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/worksheet) から作成したファイル `openlm-install.env` から変数を読み込みます。 ```bash source ./openlm-install.env ``` ## 1.1 namespace を作成する ```bash kubectl create namespace "$NS" ``` OpenShift では、namespace にセキュリティ設定が適用されるよう、代わりにプロジェクトを作成します。 ```bash oc new-project "$NS" ``` ## 1.2 ストレージクラスを確認する ```bash kubectl get storageclass "$STORAGE_CLASS" ``` 1 行が表示される必要があります。`NotFound` と表示された場合は、`kubectl get storageclass` でクラスの一覧を表示し、ワークシートの `STORAGE_CLASS` を修正してください。 ## 1.3 Ingress コントローラーを確認する Web トラフィックを処理するコントローラーがクラスターにあることを確認します。OpenLM Platform は、1 つの Ingress オブジェクト（OpenShift ではルート）を通じて Web トラフィックを受け入れます。 ```bash kubectl get ingressclass ``` お客様の `INGRESS_CLASS` が一覧に含まれている必要があります。一覧が空の場合は、先に Ingress コントローラーをインストールしてください。使用するコントローラーは、ご利用の [プラットフォームのページ](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/platforms/index) に記載されています。OpenShift では組み込みのルーターがこの役割を担うため、この確認は省略できます。 次に、コントローラーの**外部アドレス**を確認します。DNS 名はこのアドレスを指します。 ```bash kubectl get service -A | grep -iE "LoadBalancer" ``` Ingress コントローラーのサービスの `EXTERNAL-IP` を控えておきます。EKS ではホスト名、AKS では IP アドレス、K3s ではノードの IP アドレスです。 ## 1.4 DNS 名を作成する ネットワークチームに、`$DOMAIN` の DNS レコードの作成を依頼します。 | クラスター | レコード | |---|---| | EKS | `CNAME` → 1.3 で確認したロードバランサーのホスト名 | | AKS、K3s | `A` → 1.3 で確認した IP アドレス | | OpenShift | `CNAME` → クラスターのルーターアドレス（`*.apps.` のワイルドカード）。または、すでにワイルドカードでカバーされています | ## 1.5 ノードのファイル監視の上限を引き上げる すべてのノードで `fs.inotify.max_user_instances` を 8192 に設定します。約 85 個のサービスが同時に起動するため、多くの Linux の既定値（128）では `fs.inotify.max_user_instances` を使い切り、Pod が `too many open files` で失敗します。設定方法はプラットフォームによって異なります。ご利用の [プラットフォームのページ](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/platforms/index) の「ノード設定」セクションを参照してください。 ## 1.6 クラスター内部からアドレスに到達できるようにする 他の作業がこのアドレスに依存する前に、Pod から Web アドレスに到達できることを今のうちにテストします。サービスはクラスター内部から `https://$DOMAIN/identity` を呼び出します。ほとんどのクラウドクラスターでは、変更なしで動作します。それ以外のクラスターでは、Pod がクラスター自身のロードバランサーに到達できないことがあります（「ヘアピン」トラフィック）。テスト用 Pod を実行します。 ```bash kubectl -n "$NS" run nettest --rm -it --restart=Never \ --image=public.ecr.aws/docker/library/busybox:stable -- \ sh -c "nslookup $DOMAIN && wget -qO- --no-check-certificate -T 5 https://$DOMAIN/ >/dev/null; echo exit=\$?" ``` 結果を次のように読み取ります。 - `nslookup` がアドレスを返す必要があります。 - `exit=0`、または "404"、"503"、"TLS error"、"Connection reset by peer" を伴う `exit=1` は、接続できたことを示します。プラットフォームはまだインストールされていないため、Ingress はエラーページまたは自身の既定の証明書で応答します。 - "timed out" または "can't connect" を伴う `exit=1` は、Pod がアドレスに到達できないことを示します。今のうちに修正してください: [ネットワーク: クラスター内部からプラットフォームのアドレスに到達する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/networking#クラスター内からプラットフォームのアドレスに到達する)。 :::tip[確認] 次の結果を確認します。 - `kubectl get namespace $NS` で `Active` と表示されます。 - ワークステーションから `nslookup $DOMAIN` を実行すると、1.3 で確認したアドレスが返されます。 - 1.6 のテスト用 Pod が接続できました。 :::