Kubernetes を実行する人のための Kubernetes

Kubernetes のチュートリアルはポッドをデプロイする方法を教えます。午前3時にノードが静かに Ready 状態から外れて、オンコール電話が鳴り続けるときにどうするのかは誰も教えてくれません。これはその次の部分についてです。

リソースリクエストと制限は必須です

コンテナの resources.requests と resources.limits をスキップすると、スケジューラは推測で動き、ノードのメモリが少なくなったときに kubelet は何を削除すべきか判断できません。リクエストは、コンテナが実際に使用する値を設定してください。使えばいいなと期待する値ではなく、通常の負荷での実使用量に設定します。メモリ制限は OOM-killed されたポッドが綺麗に再起動するため、リクエストに近い値に設定してください。CPU 制限は、ノイジーネイバーと戦っていない限り、一般的には緩いか存在しない方が良いです。ハードリミットの下での CPU スロットリングはデバッグするのが辛いレイテンシスパイクを引き起こします。kubectl top pods -n your-namespace を定期的に実行して、宣言された値と比較してください。複数のサービスを持つクラスタでは、不一致がすぐに積み重なります。

etcd はクラスタ全体です。そのように扱いましょう

Kubernetes が知っていることはすべて etcd に存在します。これを失うと、単なるメタデータではなく、クラスタの状態全体を失います。etcdctl snapshot save /backup/etcd-snapshot.db をスケジュールで実行し、実際にスクラッチクラスタで少なくとも1回は復元をテストしてください。夜間バックアップを取っていたが、3か月間誰も検証していなかったため破損していたというチームを見てきました。EKS、GKE、AKS などのマネージドコントロールプレーンを使っている場合、etcd を直接管理する必要はありませんが、インシデント中ではなく、その前にプロバイダのバックアップと復元の話を知っておく必要があります。

Liveness プローブと readiness プローブは時々異なる必要があります

よくある間違いは、liveness と readiness の両方のプローブに同じエンドポイントを使うことです。Liveness は