ry's Tech blog

Cloud Native技術などについて書いていきます。

Kubenews #33

kubenews

2021-10-01

IAM roles for Kubernetes service accounts - deep dive (click here to source)

「ServiceAccountのCredentialを用いて、Podの中からAWSのサービスにアクセスする方法」に関して、OpenID Connectの例を交えながら説明してくれている記事です。

Top Open Source CI/CD Tools for Kubernetes to Know (click here to source)

Open SourceのCI/CDツールの中で、人気なツールを選抜してPros＆Consを交えながら紹介してくれています。

  • Tekton
  • Argo
  • GitHub Actions
  • Jenkins X
  • OpenShift Pipelines
  • Spinnaker
  • Circle CI
  • GitLab CI

How Chaos Mesh helps Apache APISIX improve system stability (click here to source)

Apache APISIX (github)というAPI Gatewayを用いた環境において、Chaos mesh (github)を用いてシステムの安定性を向上させる方法が紹介されています。

課題

Apache APISIXは、1日に数百億のリクエストを処理します。

その中で気づいた課題が以下の2点でした。

  1. Apache APISIXの構成センターで、etcdとApache APISIXの間で予期しない高いネットワーク遅延が発生した場合でも、Apache APISIXはトラフィックを正常にフィルタリングして転送できるのだろうか。
  2. etcdクラスター内のノードに障害が発生し、クラスターが引き続き正常に実行できる場合においても、ノードとApache APISIX管理APIとのインタラクションに関するエラーが報告されてしまう。

Apache APISIXは、ユニット、エンドツーエンド（E2E）、および継続的インテグレーション（CI）でのテストを通じて多くのシナリオをカバーすることができました。

ただ、外部コンポーネントとの相互作用シナリオはカバーしていません。

ネットワークがジッターしたり、ハードディスクに障害が発生したり、プロセスが強制終了したりした場合など、システムが異常に動作する場合、Apache APISIXは適切なエラーメッセージを表示できますか？実行を継続することはできますか、それとも通常の操作に戻すことができますか？ということを検証しきれていませんでした。

カオスメッシュを選んだ理由

Chaos Meshは、クラウドネイティブなChaos Engineeringプラットフォームであり、Kubernetes上の複雑なシステム向けのオールラウンドなフォールトインジェクション手法を備えており、ポッド、ネットワーク、ファイルシステム、さらにはカーネルのフォールトをカバーします。

この機能によって、ユーザーがシステムの弱点を見つけるのに役立つ上に、システムが実稼働環境において制御不能な状況になった際の対応ができるようになります。

APISIX配下でカオスメッシュを使用する方法

前述の2つの課題に対する。

課題1

次の手順を使用して、カオスエンジニアリング実験を展開しました。

[1]

ApacheAPISIXが正常に実行されているかどうかを測定するためのメトリックが見つけることができました。

Grafanaを使用してApacheAPISIXの実行中のメトリックを監視した。

比較のために、CIにおいてPrometheusからデータを抽出しました。

ここでは、1秒あたりのルーティングおよび転送要求（RPS）とetcd接続を評価メトリックとして使用しました。

加えてログを分析しました。

Apache APISIXの場合、Nginxのエラーログをチェックして、エラーが発生したかどうか、およびエラーが予想どおりであったかどうかを判断しました。

[2]

Control Groupにおける試験を行いました。

私たちはcreate route と access routeの両方が成功していること、そしてetcdに接続することができるというのがわかりました。

そしてRPSを記録しました。

[3]

ネットワークカオスを使用して5秒のネットワーク遅延を追加し、再テストしました。

今回、 set routeが失敗し、 get routeが成功でき、etcdに接続でき、RPSは前の実験と比較して大きな変化はないという結果でした。

実験は私たちの期待に沿う形となった。

課題2

上の検証をした際に、ポッドキルカオスを導入して、予想されるエラーを再現しました。

クラスタ内の少数のetcdノードをランダムに削除したところ、APISIXがetcdに接続できる場合と接続できない場合があり、ログに多数の接続拒否エラーが出力されました。

etcdエンドポイントリストの最初または3番目のノードを削除すると、set route に対して正常な結果が返されたのに対し、リストの2番目のノードを削除すると、set route に対して「接続が拒否されました」というエラーが 返されました。

原因としては、Apache APISIXで使用されるetcd Lua APIが、ランダムではなく順次エンドポイントを選択していました。

結果としてetcdクライアントを作成した際に、1つのetcdエンドポイントのみにバインドされてしまい、これが継続的な失敗につながりました。

対応として、etcd Lua APIにヘルスチェックを追加して、切断されたetcdノードに多数のリクエストが送信されないようにしました。