Kubernetes パラメータシート（オンプレのコンテナ基盤）

オンプレのコンテナ基盤（Kubernetes）のパラメータシート。★核は3枚です。（1）資源設計 …「CPU使用率に余裕がある」と「要求量（requests）の合計に余裕がある」は別のものです。置き場所は要求量の合計で決まるため、使用率が20%でもPodが1つも置けないことがあります。置けないPodはエラーではなく「待ち（Pending）」として残るので、監視していないと誰も気づきません。（2）ネットワーク設計 … PodとServiceのアドレス範囲が社内の既存ネットワークと重なると、その相手にだけ繋がらないという分かりにくい壊れ方をします。しかも後から変えるにはクラスタを作り直すことになります。通信制限（NetworkPolicy）は、通信の担い手（CNI）が対応していないと書いても黙って無視されます。（3）期限管理 … クラスタの証明書には期限があり、切れるとAPIに繋がらなくなります。業務のコンテナは動いたままなので「動いているのに何も操作できない」状態になります。★既定値はディストリビューションと版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。

★資源は「使用率」だけで判断しないでください。置き場所は要求量（requests）の合計で決まります。監視項目一覧には使用率と要求量の合計の両方を入れてください。★全コンテナに要求量を書いてください。1つでも書き忘れると空きの計算が狂います。名前空間ごとに既定値を与える仕組み（LimitRange）で書き忘れを埋めてください。★CPUとメモリで、上限を超えたときに起きることが違います。CPUは遅くなるだけですが、メモリは停止させられます。★置けていないPod（Pending）の件数を毎日見る項目に入れてください。エラーとして通報されません。★Pod・Serviceのアドレス範囲は、VPNの相手先や将来使う予定まで含めて社内の全範囲と突き合わせてください。後から変えるにはクラスタを作り直すことになります。IPアドレス管理表に「予約済み」として登録してください。★通信制限は、書いた通りに効いているかを実際に通信して確かめてください。設定しただけで安心しないでください。★1ノード分が落ちた状態で全部載るかを、構築前に計算してください。落ちてから気づいても間に合いません。★退避の可否の宣言（PDB）を業務単位で設定し、退避を実測して業務が継続することを確かめてください。★証明書の期限とサポート期間を、証明書管理台帳・定期作業カレンダーへ転記してください。パスワード・接続情報・トークンは書かず「別紙参照」としてください。