CNDO 2021 Track A で発表した内容になります

1. Calico のデプロイを
ミスって本番クラスタを
壊しそうになった話
2021/03/12
Cloud Native Days Online

2. WHO I AM?
- Name: Kawabe Katsuya
- Team: CyberAgent Group Infrastructure Unit
- Position: Software, Infra Engineer, 2020 New Graduate
- Hobby: Music, Comic
ABOUT US
@KKawabe108

3. 1. What Happen
2. How To Resolve
TABLE
CONTENTS
問題発覚編: calico のデプロイをミスったことに
よって発生した事象について
解決編: プロダクト側への説明、監視の見直し、
再発防止への取り組み

5. 図参照: https://docs.projectcalico.org/reference/architecture/overview
CNI: calico

6. アラートはいつも突然に

7. AKE での監視
Victoria Metrics で複数のクラスタを監視しています

8. What Happened
Ingress とノードの
BGP ピアがダウンしたというアラートが大量発生
Kubectl get po -A をすると Master ノードに乗っている
Pod がほとんど Evicted されていた 😇
Master ノードに ssh すると、どうやらディスク領域が
圧迫され、Eviction の閾値に到達していた

9. What Happened: Ingress の実装
Node
calico-node
Node
exporter
Node
calico-node
Node
calico-node
nginx ctrl nginx ctrl nginx ctrl
Node
calico-node
Node
calico-node
calico-node
exporter exporter
Big IP VS
BGP Routing

10. What Happened: Ingress の実装
Node
calico-node
Node
exporter
Node
calico-node
Node
calico-node
nginx ctrl nginx ctrl nginx ctrl
Node
calico-node
Node
calico-node
calico-node
exporter exporter
Big IP VS
BGP Routing
BGP Link is
Down

11. なぜ、Diskが圧迫されたのか

12. What Happened : ipamhandles リソースの爆発
calico-ipam が使用する Pod と IPを紐づけるリソース
通常、calico が Pod の作成と削除に合わせ
制御するリソースのはずだったが・・・

13. What Happened : ipamhandles リソースの爆発
😇
kubectl get をすると API サーバがメモリを食い潰して死ぬので etcdctl でチェックしてる
ちなみに、Pod の数はおよそ30個ぐらい

14. What Happened : ipamhandles リソースの爆発
😇
kubectl get をすると API サーバがメモリを食い潰して死ぬので etcdctl でチェックしてる
ちなみに、Pod の数はおよそ30個ぐらい
APIサーバが操作できない =
クラスタが操作不能 =
ヤバイ

15. What Happened : ipamhandles リソースの爆発
etcd backup
2GB
/var/backup/etcd
etcd backup
2GB
etcd backup
2GB
systemd
🧨
🧨 🧨
ipamhandles の爆発によって、etcd のバックアップデータが肥大化し、
20GB しかないディスクの圧迫へと繋がった

16. What Happened : まとめ
Step 1 Step 2 Step 3 Step 4
calico の ipamhandles が
爆発する
etcd のバックアップデータが
増加する (2GB)
Master のディスクが圧迫されて
calico-node とその他が Evicted
される
calico-node がダウンしたことに
より、BGPピアが切断され、
アラート発砲

17. 原因と対応

18. How To Resolve
calico-kube-controllers というコンポーネント
をデプロイしていなかった
calico-node の ClusterRole の権限が
間違っていた
図参照: https://docs.projectcalico.org/reference/architecture/overview

19. How To Resolve: 反省点
calico-node に delete の権限を渡していないせいで
GCが発生していなかった
元々、3.8 のマニフェストをベースに弄っていたので
発生したミス
新しいマニフェストを公式から落としてそれをベースにすれば
今回のようなミスは発生しなかった

20. How To Resolve : プロダクトへの対応
今回、アラートが上がったのは監視用に立てているクラスタでプロダクトが利用しているクラスタでは
Pod がそこまで頻繁に作成削除されていなかったので、肥大化はディスクに影響が出るほどではなかった
すぐに事情を説明して、マニフェストの修正を行なった
発生するリスクは抑えたということを確認して、対応終了

21. How To Resolve: 監視基盤の対応
監視基盤で全クラスタで etcd の db size
と、オブジェクト数を監視するようにした
ディスクサイズのアラートが
Eviction Policy と同等だったので、
それより低く設定し直す

22. How To Resolve: calico のアップデートについて
極力アップデートしなくていいならしない
マニフェストは基本公式のものをそのまま使うので問題はないはず (Pod CIDR や IPIP の有効化フラグぐらい)
マニフェストが大きいので修正のレビューは三重チェックで丁度いい (それぐらいCNIはクリティカル)

23. CNI のアップデートには細心の
注意を払いましょう！

24. Thank you for listening !