chaostoolkit/chaostoolkit-kubernetesKubernetesドライバー拡張 of the Chaos Toolkit probes and actions API
このプロジェクトには、Kubernetes APIに対してカオスエンジニアリングを実行するために、Chaos Toolkitを介して実験から呼び出すことができるプローブやアクションなどのアクティビティが含まれています:ポッドの強制終了、ステートフルセットやノードの削除など...
実験から使用するには、このパッケージはchaostoolkitが既に存在するPython環境にインストールされている必要があります。
$ pip install chaostoolkit-kubernetes
このパッケージのプローブとアクションを使用するには、実験ファイルに以下を追加します:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
これだけです!このアクションがランダムに1つのポッドを強制終了する方法を提供していることに注目してください。
既存のプローブとアクションについては、ドキュメントをご覧ください。
ネットワーク、CPU、メモリーのストレッサーについては、これらのフォールトを注入するための優れたインターフェースを提供する素晴らしいChaos Meshプロジェクトに依存していることに注意してください。
これらを使用するには、まずクラスターにChaos Meshをインストールする必要があります。
ターゲットとするクラスターの有効なエントリが~/.kube/configファイルにある場合は、何もする必要はありません。
別の場所を指定するには、KUBECONFIGを指定できます。
$ export KUBECONFIG=/tmp/my-config
Kubernetesの設定には複数のエントリが含まれることがよくあり、明示的に指定されていない場合にデフォルトのコンテキストとして使用するものを定義する必要があります。
もちろん、kubectl config use-context KUBERNETES_CONTEXTを使用してデフォルトを変更することもできますが、実験内で以下のように明示的に指定することもできます:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"secrets": {
"k8s": {
"KUBERNETES_CONTEXT": "..."
}
},
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
実験で使用するコンテキストの名前をKUBERNETES_CONTEXTシークレットキーに指定する必要があります。アクションとプローブに、渡すべきシークレットエントリ"secrets": ["k8s"]も必ず通知してください。
ポッドから実行する場合(たとえば、ローカルマシンやCIからではなく)、./.kube/configファイルは存在しません。代わりに、資格情報は/var/run/secrets/kubernetes.io/serviceaccount/tokenにあります。
このことを拡張機能に認識させるには、ポッド仕様の環境変数にCHAOSTOOLKIT_IN_PODを設定するだけです:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
この環境変数を使用する場合、実験は実験が実行されているのと同じクラスターをターゲットとすることが前提となります。実験が別のクラスターをターゲットとする場合は、この変数を設定しないでください。代わりに、ターゲットクラスター用のKubernetes設定を含むボリュームをマウントし、KUBECONFIGをその場所に設定することができます。
最後に、必要なすべての資格情報を以下のように実験に明示的に渡すことができます:
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_API_KEY": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_USERNAME": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_PASSWORD": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_CERT_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_KEY_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
一部のマネージドKubernetesクラスターでは、Kubernetesの認証がプラットフォームに委任されているため、プラットフォーム自体に対する認証も必要です。
Kubernetesの資格情報(~/.kube/configファイル経由)に加えて、Google Cloud Platform自体に対する認証も必要です。通常これはgcloud経由で行います:
$ gcloud auth login
ただし、GOOGLE_APPLICATION_CREDENTIALS環境変数を定義することによっても実現できます。
このパッケージにさらに機能をコントリビュートしたい場合は、大歓迎です。このプロジェクトをフォークし、提案された変更をカバーする単体テストを作成し、変更を実装し、フォーマット標準を満たしていることを確認してから、レビューのためにリポジトリにPRを提出してください。
フォーマット標準の詳細については、フォーマットセクションを参照してください。
Chaos Toolkitプロジェクトでは、すべてのコントリビューターが、リポジトリのmasterブランチにマージしたい各コミットでDeveloper Certificate of Originに署名する必要があります。PRを提出する前に、DCOの規則を遵守できることを確認してください。
このプロジェクトで開発したい場合は、開発用依存関係をインストールしてください。ただし、最初にPDMをインストールしてから、依存関係をインストールします。
$ pdm install
これで、ファイルを編集できます。ローカルでchaosコマンドから実行している場合でも、変更は環境に自動的に反映されます。
プロジェクトのテストを実行するには、次のコマンドを実行します:
$ pdm run tests
このリポジトリのコードのリンティングとフォーマットの両方にruffを使用しています。
プルリクエストを提出する前に、以下のコマンドでコードに対してフォーマットを実行することをお勧めします:
$ pdm run format
これにより、フォーマット標準に準拠していないコードが自動的にフォーマットされます。
フォーマットでは検出されないものもあるため、以下も実行することをお勧めします:
$ pdm run lint
未使用のインポート文や長すぎる文字列なども検出されるようにするためです。