Kubernetes インストール (Helm)
PlantPulse プラットフォームをKubernetesで運用するためのHelmチャートがあります。
データレイクまではこのチャートでクリーンインストールして確認しました(2026-09-09、サービス 19/19、特権なし)。
しかし server · batch · warehouse · proxy はまだ実物で確認していません。
顧客先への導入にはワンラインインストール か Dockerインストール を使用してください。
概要
Docker Compose構成をKubernetesに翻訳したチャートです。置き換えたものではありません。
正本は依然としてcomposeです。両者が食い違った場合、composeが正しく、チャートが間違っています。 新しい設定が追加された場合は、まずcomposeに反映され、チャートがそれに追随します。
| チャートの場所 | plantpulse-platform-k8s リポジトリの charts/plantpulse-platform |
| イメージレジストリ | プラットフォームは docker.kopens.io/pp、サードパーティは docker.kopens.io/proxy-dockerhub |
| 実証環境 | k3s v1.32.5+k3s1 · 単一ノード |
| 対象となるcomposeサービス | 全10個 |
始める前に
Kubernetesバージョン
そのOSはcgroup v1であり、k3s v1.36(kubernetes 1.36)はcgroup v1サポートを削除しました。 アップグレードするとkubeletが次のように出力して起動しません。
kubelet is configured to not run on a host using cgroup v1
ストレージ — RWX が必要です
TLS マテリアルを格納する pp-security ボリュームに複数のPodが同時に接続します。 そのため、
ReadWriteMany をサポートするプロビジョナーが必要です — NFS · CephFS · Longhorn RWX などです。
local-path はノードが1つの場合のみ動作しますlocal-path はRWOでノードローカルです。単一ノードではすべてのPodがそのノードに配置されるため
動作しますが、2番目のノードが追加された日、静かに壊れます。 チャートの欠陥ではなく実際の制約であり、
顧客先導入中に発見されないようにここに記録しておきます。
リソース
プラットフォームのリソース要件はKubernetesだからといって減りません。 システム要件 をそのまま遵守します — 最低 16 vCPU · 128GB RAM · 1TB SSD です。
クラスタがない場合 — K3s → Rancher → Helm
Kubernetesを既に使用している場合はこのセクションをスキップしてインストールへ進んでください。 何もない状態から始める場合はK3sでクラスタを作成し、Rancherで画面を追加し、 その上にPlantPulseチャートを載せる手順が最短です。
SUSEのオープンソースKubernetes管理UIです。任意であり、kubectl だけでも
インストール・運用はすべて可能です。Pod・ログ・イベントを目視で確認したい場合に便利なので、併記しています。
1. K3sインストール
1台のクラスタです。インストールスクリプトがコンテナランタイム · kubelet · デフォルト
ストレージ(local-path)まで一緒にセットアップします。
# Oracle Linux 8.10 은 cgroup v1 이라 v1.32 라인을 고정합니다 (위 경고 참고)
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.32.5+k3s1 sh -
sudo systemctl status k3s # active (running)
sudo k3s kubectl get nodes # STATUS = Ready
kubectl を一般アカウントで使用するにはkubeconfigをコピーします。
mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown "$(id -u):$(id -g)" ~/.kube/config
kubectl get nodes
K3s は 6443(API) を使用します。他のノードを追加する予定がある場合は、ノード間の 8472/udp(flannel VXLAN) · 10250(kubelet) も必要です。 プラットフォーム自体が使用するポートはポート構成にあります。
2. Rancherインストール
Rancherは証明書が必要なため、cert-manager を先にセットアップします。
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm repo add jetstack https://charts.jetstack.io
helm repo update
# 1) cert-manager
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true
kubectl -n cert-manager rollout status deploy/cert-manager
# 2) Rancher — <호스트> 는 브라우저로 칠 주소입니다
helm install rancher rancher-stable/rancher --namespace cattle-system --create-namespace --set hostname=<호스트> --set bootstrapPassword=<초기비밀번호> --set replicas=1
kubectl -n cattle-system rollout status deploy/rancher
ブラウザで https://<호스트> にアクセスし、前述の bootstrapPassword で初回ログインし、
すぐにパスワードを変更してください。ログインすると、このK3sクラスタが local として認識されています。
Rancher は hostname で証明書を生成します。IPでアクセスする予定の場合は、そのIPをそのまま
hostname に設定し、ブラウザが自己署名証明書に対して警告することを受け入れてください。
3. PlantPulseインストール
ここからは kubectl で行うかRancher画面で行うかは同じです。以下のインストールセクションを
そのまま従ってください。Rancherを使用する場合はApps → Charts → Repositories にチャート
リポジトリを登録して画面からインストールすることもできますが、値ファイルを扱うには helm コマンドの方が適しています。
Rancherが実際に役立つのはインストール後です — PodのInit段階がどこで待機しているか、 ログが何を言っているか、イベントが何を拒否したかを1つの画面で確認できます。 起動順序を読む際に特にそうです。
インストール
1. シークレットをSecretとして作成します
チャートはパスワードを1行も保持していません。 values.yaml にもなく、デフォルト設定では
チャートがSecretを作成もしません — 既存のものを参照するだけです。
正本はcomposeと同じサイドカーファイルです。バイト単位でそのまま使用します。
kubectl -n plantpulse create secret generic plantpulse-platform-env \
--from-env-file=/etc/kopens/plantpulse-platform.env
2. インストールします
helm install pp charts/plantpulse-platform -n plantpulse --create-namespace
デフォルトレジストリ(docker.kopens.io/pp · docker.kopens.io/pd)は公開であり、外部からも取得できます。
そのため通常のインストールでは --set は不要です。
3. プライベートレジストリにミラーリングした場合
helm install pp charts/plantpulse-platform -n plantpulse --create-namespace \
--set global.image.registry=<사설 레지스트리>/pp \
--set global.image.registryDatalake=<사설 레지스트리>/pd \
--set global.image.registryThirdParty=<사설 레지스트리>/proxy-dockerhub \
--set global.imagePullSecrets[0].name=<레지스트리 시크릿>
registryThirdParty を忘れないでください前述の2つだけをカバーすると起動順序待機用のbusyboxを取得できません。 そうなると依存するPodがすべて
Init:0/1 で永遠に待機しますが、その失敗はレジストリの問題のように見えません。
起動順序 — Kubernetesが守ってくれません
プラットフォームには守るべき順序があります。
certs → datalake → server → batch
→ warehouse · opcua · aasx · ha
server → proxy
composeの depends_on に相当するものはKubernetesにはありません。代わりによく使われるとされる
セットはすべて別のことを行います。
| よく使われるもの | 実際に行うこと |
|---|---|
readinessProbe | そのPodへのトラフィックを遮断します。他のPodの起動は遅らせられません |
StatefulSet | 同じStatefulSet内のPod順序です。他のワークロードとは無関係です |
Helm hook · --wait | マニフェスト適用の順序です。生成されたものの準備状態ではありません |
そこでチャートはKubernetesが実際に遮断できる場所 — initContainer — に待機を入れました。 待機は「Podが起動したか」ではなく**「成果物があるか」**を確認します。
Init:0/2 は故障ではありませんチャートが動作しているという意味です。何を待っているか確認してください。
kubectl -n plantpulse logs <파드> -c wait-for-certs
デフォルトの待機上限は1800秒で、5秒ごとに確認します。上限を超えると待機が終了し、kubeletが 再起動します — 理由がPodイベントに残るようにするためです。永遠にブロックされていると何も 残りません。
コンテナ«内部»の順序はチャートが関与しません。 データレイク内部の起動順序は
pd がコンテナ内で強制します。チャートがそれを再実装すると正本が2つになり、分岐します。
プロキシが502を返す場合
Dockerネットワークはコンテナのすべてのポートを転送しますが、Kubernetes Serviceは«自らが宣言した ポートのみ»転送します。 composeで動作していたアップストリームがKubernetesで502になる経路がここです。
チャートにはそれを捕捉するゲートがあります — すべてのプロキシアップストリームが«このチャートが作成するServiceの、 そのServiceが宣言したポート»を指しているか検証します。
bash hack/run-gates.sh
| ゲート | 検証するもの |
|---|---|
gate-render.sh | レンダリング結果のプロキシアップストリームが実在するService · ポートかどうか |
gate-no-plaintext-secrets.sh | レンダリング結果に平文シークレットが混ざっていないか |
prove-gates-fail.sh | ゲートが«失敗すべき時に実際に失敗するか» (ゲートのゲート) |
インストール前に実行して通過させてください。502の大部分はここで先に捕捉されます。
ノードはどの程度の規模が必要か
🔴 チャートが宣言する requests の合計がそのままノード要件です。 不足するとPodが起動せず
Pending のまま残ります — 「インストールが停止したように見える」最初の原因です。
| ワークロード | CPUリクエスト | メモリリクエスト | メモリ上限 |
|---|---|---|---|
datalake | 8 | 64 Gi | 64 Gi |
server | 2 | 12 Gi | 16 Gi |
batch | 1 | 6 Gi | 8 Gi |
warehouse | 1 | 4 Gi | 8 Gi |
opcua · aasx | 各0.5 | 各2 Gi | 各4 Gi |
ha | 0.5 | 1 Gi | 4 Gi |
proxy | 0.2 | 256 Mi | 1 Gi |
certs | 0.1 | 256 Mi | 1 Gi |
| 合計(デフォルト構成) | 約14 | 約92 Gi | — |
datalake だけで CPU 8 · メモリ 64 Gi をリクエストします(リクエストと上限が同じです —
Guaranteedとして設定されています)。単一ノードに載せる場合、そのノードは余裕を持って CPU 16 ·
メモリ 128 Gi 級である必要があります。
JVMヒープはPod上限と«別に»宣言されます
Javaアプリセットはヒープサイズをチャートが直接渡します。Pod上限から導出しません — 導出すると上限を下げた際にヒープが静かに減少し、実際にはイメージ内のリテラルが優先されるため、 上限をどの方向に修正してもJVMが認識しない状態になります。
| アプリ | ヒープ | ダイレクト | 渡される変数 |
|---|---|---|---|
server | 8g | 4g | PP_SERVER_HEAP · PP_SERVER_DIRECT |
batch | 3g | — | PP_BATCH_HEAP |
warehouse | 1g | — | PP_WAREHOUSE_HEAP |
チャートはレンダリング時に以下をアサートします。違反するとインストールはその場で失敗します。
힙 + 다이렉트 + 여유(기본 2048Mi) ≤ limits.memory
힙 + 여유 ≤ requests.memory
🔴 ヒープだけ大きくしてPod上限を上げないと、プリタッチ中にOOMKillが発生します。 -Xms=-Xmx に
AlwaysPreTouchがあるためヒープは起動直後にすべて常駐しますが、このときログにはヒープを指摘する行が
残りません。両方を一緒に上げてください。
現在どこまで検証済みか
実証環境はk3s v1.32.5+k3s1 · 単一ノードであり、すべて実際のレジストリイメージです。
| コンポーネント | 状態 |
|---|---|
plantpulse-certs | ✅ Ready. TLSマテリアルが共有ボリュームに実際に生成される |
plantpulse-datalake | ✅ このチャートでクリーンインストールして 19/19 起動 (2026-09-09, 2026.09 イメージ, PVC削除後) |
| 起動順序の待機 | ✅ ブロックと解除を実物で確認 |
server · batch · warehouse · proxy | ⬜ 起動記録がまだありません — ただしチャート側の欠陥は継続的に修正されています(2026-09-09: バックアップボリューム · JVMヒープ契約 · プロキシアップストリーム) |
opcua · aasx · ha | ⬜ 待機状態までのみ確認 |
mirror-maker | デフォルト無効 (composeの mirror プロファイル対応) |
データレイクPodは現在特権なしで起動します — イメージからsystemdがPID 1から外れ、
privileged · SYS_ADMIN · cgroup:host がすべて不要になりました。
TOTAL SERVICES : 19 RUNNING / 0 STOPPED
/proc/1/comm : bash # systemd 아님
securityContext: (비어 있음) # privileged·SYS_ADMIN·cgroup 없음
server → batch → warehouse → proxy の順序が実物で守られるかはまだ誰もその地点まで到達していません。
「チャートを修正していない」という意味ではありません。2026-09-09 にアプリティアの欠陥セットを修正しました — バックアップボリュームがサーバーに接続されていなかったこと、JVMヒープがKubernetesで設定不能だったこと、プロキシアップストリーム 7つがDockerのままだったこと。ただし、いずれもレンダリング比較とコードで見つけたものであり、Podを 実際に起動して確認したものではありません。 「修正した」と「このチャートで起動する」は別の事実です。顧客先への導入にはワンラインインストール か Dockerインストール を使用してください。
詰まったとき
| 症状 | 最初に確認すること |
|---|---|
Podが Init:0/1 で動かない | busyboxを取得できない可能性があります — registryThirdParty 確認 |
Podが Init:0/2 で待機 | 正常です。 kubectl logs <파드> -c wait-for-certs で何を待っているか確認します |
| プロキシ経路が502 | bash hack/run-gates.sh — アップストリームが実在するService·ポートを指しているか |
| 2番目のノード追加後にTLS関連エラー | pp-security がRWXではありません |
| ウェアハウスコンソールのリストが常に空 | Iceberg関連の必須設定が空です。空の値はレンダリングが失敗するように設定されているので、インストールログを確認します |
関連ドキュメント
- ワンラインインストール — 現在推奨するインストール方法
- Dockerインストール — composeベースの詳細手順
- システム要件 — リソース要件は同一です
- クラスタインストール — マスター·ワーカーの水平スケーリング