テクノロジーとインフラストラクチャ→Kubernetesクラスタとヘルムチャート

Kubernetesクラスタとヘルムチャート

1） KubernetesとHelmの役割

Kubernetesはアプリケーションプラットフォームの基本です。ローリング、ネットワーキング、コンフィギュレーション、シークレット、自己修復を標準化します。Helmは、宣言マニフェストをバージョン管理と依存関係を持つ再現可能なリリースに変えるパッケージ/テンプレートマネージャです。予測可能な派遣、迅速なロールバック、単一のインフラストラクチャ言語を提供します。

2）クラスタ設計

2.1トポロジーとフォールトトレランス

マルチAZ： 制御平面とワーカープールノードがゾーニングされます。PDB/TopologySpreadConstraints （PDB/TopologySpreadConstraints）

マルチリージョン/DR：リージョンごとに独立したクラスタ；地域間の呼び出し-「コールド」パス（ディレクトリ/テレメトリー）、「ホット」（ウォレット）のみ-ローカル。
プロファイルによるワーカープール：'general'、 'compute'、 'io'、 'spot'（バックグラウンドタスク用）。nodeSelector/affinity/tainsによる割り当て。

2.2名前空間とマルチユーザモデル

ドメイン/コマンドによる名前空間分離：'payments'、 'wallet'、 'games'、 'reporting'。
ResourceQuota+LimitRange：基本的なCPU/RAM制限と最大レプリカ；「掃除機」に対するクラスタ保護。
RBAC：デフォルトでは読み取り専用のロール、書き込み-CI/CDとオンコールのみ。

2.3ネットワーク

NetworkPolicyサポート付きCNI （Calico/Cilium）： namespace/labelによるポリシーL3/L4。
Ingress→Gateway API：カナリアとマルチテナンシーの'GatewayClass/Gateway/HTTPRoute'モデルに切り替えます。
サービスメッシュ（オプション）：mTLS、再試行/ブレーカ、局所認識；サービス間の信頼性のためのポイントを回して下さい。

3）信頼性と拡張性

3.1スケーリング

CPUだけでなく、ユーザーメトリック（RPS/レイテンシ/キューの深さ）によるHPA。
バックグラウンドロードクラスのVPA；製品で-「推薦のみ」またはさまざまな指標でHPAと一緒に。

クラスターオートスケーラー： 機密サービスのための個別のノードグループ；ウォームプールからピック（トーナメント/マッチ）

3.2リソースとQoS

各Podに要求/限界があります；'：latest'と'unlimited'コンテナを避けます。
PriorityClass：重要なサービス（'wallet'、 'payments'）は、重要でないサービスを置き換えます。
PDB：ノードを更新するときは、クラスタを「足の中で自分自身を撃つ」ようにしないでください。

3.3ダウンタイムなしのアップグレード

RollingUpdate with maxUnavailable=0（クリティカルパス上）。
PodDisruptionBudget+ReadinessProbes（スタートアッププローブの準備）。
ピーク時の高速リリースのサージ容量-注意してください。

4）プラットフォームセキュリティ

名前空間レベルのPod Security（ベースライン/制限）；'privileged'許可されていない、hostPath、 root。
NetworkPolicy：ポート/ラベルによるデフォルトの拒否とホワイトリスト化。
Seccomp/AppArmor、非ルートユーザー、読み取り専用ルートfs。
秘密：KMS/Vaultプロバイダ（CSI）、'値に秘密を保持しないでください。ヤムルは開けた形で。
RBAC最小：必要な権利のみサービスアカウントを発行します。短命なトークン。
入場管理：OPA/Gatekeeper/Kyverno-ラベル、制限、ポリシー違反を強制します。

5）観測可能性

OpenTelemetry： Ingress/Gateway→service→database/cache、必須ラベル'service'、 'version'、 'region'、 'partner'、 'api_version'からのトレース。

ログ： 構造化、PII/PANなし。一元化されたストレージへのルーティング

メトリクス：RED/USE、 SLOダッシュボード、バーンレートアラート。
合成：右の国/ASNからのサンプル；周囲および内部健康点検。

6） GitOpsプログレッシブデリバリー

Argo CD/Flux：目的の状態がGitに格納されます。各名前空間には独自のリポジトリ/フォルダがあります。
アーティファクトのプロモーション：'dev→stage→prod' PR経由で、「kubectl apply」ではありません。
カナリア/ブルーグリーン：Argo ロールアウト/ゲートウェイAPI；成功指標-P95/P99、エラー率、ビジネスSLI（預金のCR）。
ロールバック：ヘルム/アルゴ-ボタンで；チャートで-バージョンが固定されています。

7）ヘルム： ベストプラクティス

7.1チャート構造

my-service/
Chart. yaml     # name, version (SemVer), appVersion values. yaml # base values (no secrets)
values-prod. yaml # prod overrides (no secrets)
templates/
_helpers. tpl # naming, common deployment templates. yaml service. yaml hpa. yaml pdb. yaml networkpolicy. yaml serviceaccount. yaml ingress_or_gateway. yaml charts/# dependencies (opcional)

• 'version'-チャートバージョン（SemVer）、 'appVersion'-アプリケーション（イメージ）バージョン。
• 強力なリソース名は'{{include' svcです。fullname。'}}'+labels 'app。 kubernetes。io/'。
• 必要なマニフェスト：展開/StatefulSet、サービス、ServiceAccount、 HPA（該当する場合）、PDB、 NetworkPolicy。

7.2バリューストラテジー

基本的な値。yaml'-デフォルト、シークレットと環境仕様なし。
上書き：'values- {stage' prod} 。yaml'+per-regionファイル。
秘密：SOPS （'values-prod。ソップス。yaml'）またはCSIによるVaultインジェクション。
リソースとサンプルのパラメータ-「合理的な」デフォルトの値。

7.3依存関係と共通コード

パターンの一般的なチャートライブラリ（プローブ、注釈、NetworkPolicy）。
依存関係（'requirements'/'チャート。yaml'）バージョンによって修正；深い「ネスティングドール」は避けてください。

7.4テンプレートとチェック

'_helpersで'required'と'fail'を使用します。tpl'は重要な値です。
値の検証-'valuesスキーム。スキーマ。json'。
ユニットチャートテスト-'helm unittest'；静的解析-kubeconform/kubeval。
ローカルデバッグ-'helm template'+'--values'+'kubeconform'。

7.5リリースとストレージ

チャートをOCIコンテナレジスタにプッシュします。タグ：SemVer。
Helmfile/' helmfile。マルチチャートシーブのオーケストレーションのため。
CIアーティファクト：生成されたマニフェスト+lockfile依存。

8）例： 展開（ヘルムテンプレートフラグメント）

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "svc. fullname". }}
labels: {{ include "svc. labels". nindent 4 }}
spec:
replicas: {{.Values. replicas      default 3 }}
strategy:
type: RollingUpdate rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{ include "svc. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{ include "svc. selectorLabels". nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}
spec:
serviceAccountName: {{ include "svc. serviceAccountName". }}
securityContext:
runAsNonRoot: true containers:
- name: app image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports:
- name: http containerPort: {{.Values. ports. http }}
resources:
requests:
cpu: {{.Values. resources. requests. cpu }}
memory: {{.Values. resources. requests. memory }}
limits:
cpu: {{.Values. resources. limits. cpu }}
memory: {{.Values. resources. limits. memory }}
readinessProbe:
httpGet:
path: /healthz port: http periodSeconds: 5 envFrom:
- secretRef:
name: {{ include "svc. secretsName". }}

9）秘密と構成

Gitリポジトリ（GPG/KMSキー；'kubectl edit'は禁止されている）。
rolling release triggerのConfigMap/Secretチェックサム注釈。
PAN/PIIを保存しないでください。トークン化を使用します。
シールされた秘密は許可されていますが、SOPSまたは直接CSIが優先されます。

10）ネットワークおよび周囲

L7ルーティング、カナリア、ブルーグリーンのゲートウェイAPI。必要なときだけ粘着性があるセッション。
メッシュ/サイドカーレス（Cilium）経由のサービス間のmTLS-決済コアのポイント。
出力：外部ノード（PSP/KYC）の制御リスト、固定NAT-IP、タイムアウト、再試行予算。

11）ステートフルサービスとデータ

OLTPデータベースでは、管理クラウドサービスまたはオペレータ（Postgres/MySQL）を個別のクラスタで使用します。
スナップショットおよびバックアップの方針のポリ塩化ビニール/CSI；レプリカのための'PodAntiAffinity'。
キュー/ストリーミング-マネージドソリューションまたは専用クラスタ；「common」アプリケーションクラスタでは、最小限の状態を保持します。

12） CI/CDのコンベヤー（参照）

1.ビルドとテスト→2） SCA/lint→3）レジスタ内のイメージ（SBOM、署名）→

2.ヘルムチャート生成+'helm unittest'+kubeconform→

3.CDでのSOPS復号化→6） GitOpsリポジトリのPRランタイム→

4.Argo/Fluxが適用される→8） Argo Rollouts canary→9） SLO Auto Verdict→10） Promotion/Rollback。

13）プラットフォーム成熟度の指標

GitOpsによるリリースのシェア（目標：100％）。
準備ができるまでの圧延時間（P95）、 MTTRのロールバック。
ネームスペースポッドセキュリティとネットワークポリシーのカバレッジ（対象：100％）。
HPAと正しいリクエスト/制限を持つサービスの％。
'valuesを持つ％グラフ。スキーマ。jsonとユニットテスト。
「手動」の変更によって引き起こされるインシデント（ターゲット：0）。

14）実装チェックリスト

1.ゾーンごとのクラスタ、プロファイルごとのノードのプール；PDB/TopologySpreadConstraints。
2.名前空間モデル、ResourceQuota/LimitRange、 RBAC最小。
3.Pod Security（制限されています）。デフォルトでNetworkPolicyを拒否します。
4.ゲートウェイAPI/Ingress；プロバイダへの排出制御とNAT固定。
5.観測性：OTelトレイル、RED/USE、 geo synthetics；SLOダッシュボード。
6.GitOps （Argo/Flux）、カナリア/ブルーグリーン、メトリックによる自動プロモーション。
7.ヘルム標準：構造、スキーマ。json、 tests、 SOPS/Vault、 OCIレジスタ。
8.HPA/VPA、クラスタオートスケーラー、ウォームプールからピークまで。
9.データ操作：CSIスナップショット、バックアップ、管理データベース・オペレータ。
10.定期的なDR/カオステストとゲームの日。

15）アンチパターン

隔離とクォータなしのすべてのための1つの「巨大な」クラスタ。
リソース制限のないコンテナ、'最新'タグ、プローブなし。

「価値観の秘密」クリアテキストではyaml、 prodでは'kubectl edit'

過去のGitOps、ライブクラスタでの手動マニフェスト編集をリリースします。
ネットワークポリシー/ポッドセキュリティの欠如-「フラット」ネットワーク。
CPU全体で共通の単一のHPA信号で、さまざまな負荷に対応します。
オペレータとバックアップのない「共通の」アプリケーションクラスタ内のOLTPデータベースのストレージ。

16） iGamingコンテキスト/フィンテック： 実用的なノート

支払のwebhook：専用の入出力/ゲートウェイとPSPへの狭出力。厳密なタイムアウト/リトレイ。個々のホストプール。
VIPトラフィック：優先順位付けと個々のルート；PDBとトポロジーは安定性のために広がります。
トーナメント/ピック：ウォームプールノード+予測HPA；キャッシュ/接続をウォームアップします。
Reporting/CDC： ETLがProdに影響を与えないように、個別のクラスタ/プール。
規制：不変ログ（WORM）、 PIIトークン化、ネットワークセグメンテーション。

合計

強力なKubernetesプラットフォームは「YAMLヒープ」ではなく、isolation、 security policy、 managed resources、 observability、 GitOpsの規律です。ヘルムチャート-サプライ契約：予測可能なリリース、テスト可能なパターン、セキュアシークレットハンドリング、シンプルキックバック。これらの原則を統合することで、ピークを生き残り、リリースを加速し、ビジネスや規制の要求に耐えるクラスターを獲得できます。