障害対応にて
ユーザーに影響があるような障害が発生してしまった場合、やはり素早い復旧が望まれます
一方では、障害の原因を調査するために障害が起きた現場を残したい、という事情もあります
その場合、バックアップや代わりになるインスタンスを用意して、障害が起きたものと入れ替えるという流れで対応するのがまあ定石です
kubernetesで
今回、はkubernetesクラスタにおいて
- deployment（replicaset）が展開している複数のpodのうちひとつが、何らかの原因でエラーを返すようになってしまった
- readinessProbeは通っていて、問題の起きたpodへのトラフィックは止まらない
という状況で、問題の起きたpodを削除するのではなく、残したまま隔離して復旧させます
手順
これは正規の手順ではないので自己責任でお願いします
- 問題の起きたpod（以下A）の名前を取得
-
kubectl editでAを編集する- Aにトラフィックを流してるserviceの
spec.selectorに一致しなくなるようにmetadata.labelsを変更する-
app: myappをapp: myapp-brokenにするなど
-
- Aにトラフィックを流してるserviceの
- 編集を保存すると、Aはdeploymentから外れた感じになり、勝手に新しいpodが補充される
- もうAにトラフィックが流れなくなっているので、煮るなり焼くなり
- 不要になったら手動でAを削除する
- これを忘れるとゴミとして残り続ける
注意
設定次第では隔離したpodのログやメトリクスが保存できないことがあるので注意してください
podのlabelを変更すると、.metadata.ownerReferencesが消えるっぽいです
正しくやろうと思ったら、同じ内容で名前とlabelを変えたdeploymentを用意してserviceのselectorを変更して…みたいな流れになるんでしょうか
ちゃんと検証してクラスタの管理方法に合わせて手順をしっかり固めたいボリュームですね