注記翻訳： これは、同社のエンジニアリング ブログから公開された事後分析の翻訳です。 。 ここでは、Kubernetes クラスター内の conntrack の問題について説明しています。これにより、一部の実稼働サービスの部分的なダウンタイムが発生しました。
この記事は、事後検証についてもう少し詳しく知りたい人、または将来の潜在的な DNS 問題を防止したい人に役立つ可能性があります。
これはDNSではありません
DNSではありえない
DNSでした
Preply の事後分析とプロセスについて少し説明します。
事後分析では、運用上の誤動作や何らかのイベントが説明されます。 事後分析には、イベントのタイムライン、ユーザーへの影響、根本原因、実行されたアクション、得られた教訓が含まれます。
技術チーム間では毎週ピザとのミーティングでさまざまな情報を共有しています。 このような会議の最も重要な部分の XNUMX つは事後分析であり、ほとんどの場合、スライドを使用したプレゼンテーションと事件のより詳細な分析が伴います。 たとえ死後に拍手をしなかったとしても、私たちは「咎めない」文化を発展させようと努めています（）。 私たちは、事後分析を書いて提示することで、私たち (および他の人) が将来同様の事件を防ぐのに役立つと信じているため、事後分析を共有しています。
事件に巻き込まれた人は、処罰や報復を恐れることなく詳細に発言できると感じる必要があります。 お咎めなし！ 事後分析を書くことは罰則ではなく、会社全体にとって学習の機会です。
Kubernetes の DNS に関する問題。 事後分析
Дата： 28.02.2020
著者： アメット U.、アンドレイ S.、イゴール K.、アレクセイ P.
タイトル： 終了した
簡単に： Kubernetes クラスター内の一部のサービスで部分的な DNS が利用できない (26 分)
インパクト： サービス A、B、C で 15000 のイベントが失われる
根本的な原因： Kube-proxy が conntrack テーブルから古いエントリを正しく削除できなかったため、一部のサービスがまだ存在しないポッドに接続しようとしていました
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...引き金： Kubernetes クラスター内の負荷が低いため、CoreDNS-autoscaler はデプロイメント内のポッドの数を XNUMX から XNUMX に減らしました。
解決策： アプリケーションの次のデプロイメントでは新しいノードの作成が開始され、CoreDNS-autoscaler によってクラスターにサービスを提供するポッドがさらに追加され、conntrack テーブルの書き換えが発生しました。
検出： Prometheus モニタリングにより、サービス A、B、および C に対して多数の 5xx エラーが検出され、当直エンジニアへの電話が開始されました。
Kibana の 5xx エラー
活動
アクション
タイプ
責任がある
タスク
CoreDNS のオートスケーラーを無効にする
阻止された
アメット U.
DEVOPS-695
キャッシュDNSサーバーをセットアップする
減少
マックスV。
DEVOPS-665
conntrack モニタリングをセットアップする
阻止された
アメット U.
DEVOPS-674
学んだ教訓
うまくいったこと:
- モニタリングはうまくいきました。 対応は迅速かつ組織的でした
- ノードの制限に達しませんでした
何が間違っていたのか:
- 本当の根本原因はまだ不明ですが、次のようなものです コントラックで
- すべてのアクションは結果のみを修正し、根本原因 (バグ) は修正しません。
- 遅かれ早かれ DNS に問題が発生する可能性があることはわかっていましたが、タスクに優先順位を付けていませんでした
幸運だったのは：
- 次のデプロイメントは CoreDNS-autoscaler によってトリガーされ、conntrack テーブルが上書きされました。
- このバグは一部のサービスにのみ影響しました
タイムライン (EET)
時間
アクション
22:13
CoreDNS-autoscaler によりポッドの数が XNUMX つから XNUMX つに減りました
22:18
勤務中のエンジニアは監視システムからの電話を受け始めました
22:21
当直のエンジニアはエラーの原因を調べ始めました。
22:39
勤務中のエンジニアは、最新のサービスの XNUMX つを以前のバージョンにロールバックし始めました
22:40
5xx エラーが表示されなくなり、状況が安定しました
- 検出までの時間: 4分
- アクションまでの時間: 21分
- 修正する時期: 1分
追加情報
- CoreDNS ログ:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Kibana (カット)、Grafana (カット) へのリンク
CPU 使用率を最小限に抑えるために、Linux カーネルは conntrack と呼ばれるものを使用します。 つまり、これは特別なテーブルに保存されている NAT レコードのリストを含むユーティリティです。 次のパケットが以前と同じポッドから同じポッドに到着すると、最終的な IP アドレスは再計算されず、conntrack テーブルから取得されます。
conntrackの仕組み
結果
これは、いくつかの有用なリンクを備えた事後分析の一例です。 特にこの記事では、他の企業にとって役立つ可能性のある情報を共有します。 だからこそ、私たちは間違いを犯すことを恐れず、事後分析の XNUMX つを公開します。 さらに興味深い公開事後分析をいくつか紹介します。
- GitLab：
- Dropbox：
- Spotifyは：
- 他にもたくさんの方々から そしてリポジトリ
- また SRE Book による公開事後分析
出所： habr.com