Feature/issue #47

README.md

@@ -4,22 +4,32 @@ This is a mock server used to verify the operation of service mesh tools. Servic
 
 ## Usage
 
+> [!NOTE]
+> To create a cluster, please see the documentation here
+
 * Clsuter build and pure mockserver install
  * [Usage README](./sample_manifest/README.md)
  * Please click here to see the install for clusters.
 Click here to use Open Telemetry
 
+> [!NOTE]
+> When checking the operation of OpenTelemetry + ServiceMesh, it is recommended to start with progressive delivery.
+
 * OpenTelemetry + ServiceMesh
  * progressive delivery DEMO
  * flagger
- * [Usage README](./docs/flagger/README.md)
+ * [Usage README](./docs/servicemesh/flagger/README.md)
  * istio DEMO
- * [Usage README](./docs/istio/README.md)
+ * [Usage README](./docs/servicemesh/istio/README.md)
 
 > [!NOTE]
-> When checking the operation of OpenTelemetry + ServiceMesh, it is recommended to start with progressive delivery.
+> For chaos engineering to work like a real application, it is recommended to build OpenTelemetry + ServiceMesh first.
+
+* khaos engineering
+ * litmus
+ * [Usage README](./docs/khaos/litmus/README.md)
 
-## Example
+## FlexibleMockServer Example
 
 Here are the environment variables for changing the port and endpoint of a Flask application:
 

docs/khaos/litmus/README.md

@@ -0,0 +1,84 @@
+# introduction
+
+## install
+
+インストール方法
+
+```:terminal
+❯ kubectl apply -k sample_manifest/kubernetes/litmus
+```
+
+## litmusとは？
+
+TBU
+
+## 使い方
+
+初期パスワードは、`id:admin` `pass:litmus` になります。
+(画像を載せる)
+
+### 事前準備
+
+![トップページ](../../image/20.png)
+
+![環境構築](../../image/21.png)
+
+![環境構築](../../image/22.png)
+
+![環境構築](../../image/23.png)
+
+![環境構築](../../image/24.png)
+
+![環境構築](../../image/25.png)
+
+```:terminal
+[kind-sandbox-test|default] :ctx
+[arm64]⚡️
+❯ kubectl apply -f test-litmus-chaos-enable.yml
+```
+
+## 実際に使ってみる
+
+### control-planeに障害を起こしてみる
+
+#### aaa
+
+TBU
+
+#### aaa1
+
+TBU
+
+#### aaa2
+
+TBU
+
+#### aaa3
+
+TBU
+
+### aaa4
+
+TBU
+
+### worker-nodeに障害を起こしてみる
+
+#### aaa5
+
+TBU
+
+#### aaa6
+
+TBU
+
+#### aaa7
+
+TBU
+
+#### aaa8
+
+TBU
+
+### aaa9
+
+TBU

docs/README.md → docs/servicemesh/README.md

@@ -31,17 +31,17 @@ REDHADのドキュメントによると、サービスメッシュとは以下
 
 マイクロサービス導入前は、すべての通信が一つのアプリケーションサーバーを通じて行われ、単一障害点が存在するシンプルな構成です。
 
-![マイクロサービス導入前](./image/1.png)
+![マイクロサービス導入前](../image/1.png)
 
 * マイクロサービス導入後の通信
 
-![マイクロサービス導入後](./image/2.png)
+![マイクロサービス導入後](../image/2.png)
 
 図のように、アプリケーションAはB、C、Dに対して通信を行い、BはC、Dに対して、CはB、Dに対して、DはB、Cに対して通信を行います。各アプリケーション間の通信に対して、タイムアウト値などの設定を個別に行う必要がありますが、これは非常に手間がかかります。
 
 * サービスメッシュの導入
 
-![サービスメッシュ導入後](./image/3.png)
+![サービスメッシュ導入後](../image/3.png)
 
 この問題を解決するために、サービスメッシュの概念が登場しました。サービスメッシュを導入することで、メッシュサーバーを介したアプリケーション間の通信が実現します。
 

docs/flagger/README.md → docs/servicemesh/flagger/README.md

@@ -16,7 +16,7 @@ Flaggerの動作確認はistioをベースに動作させます。
 
 > [!NOTE]
 > このドキュメントで負荷試験ツールを利用する場合には、locustをinstallする必要があります。
-> <br> ref: [link](../locust/README.md)
+> <br> ref: [link](../../loadtest/locust/README.md)
 
 ## そもそもFlaggerをどう理解すれば良いのか？
 
@@ -51,7 +51,7 @@ ref: [schema](https://github.com/fluxcd/flagger/blob/b6ac5e19aa7fa2949bbc8bf37a0
 
 構成を簡略化させた図
 
-![image](../image/19.png)
+![image](../../image/19.png)
 
 ## Flaggerにおけるprogressive deliveryとは？
 
@@ -61,7 +61,7 @@ ref: [schema](https://github.com/fluxcd/flagger/blob/b6ac5e19aa7fa2949bbc8bf37a0
 
 図で書くとこんな感じ
 
-![image](../image/18.png)
+![image](../../image/18.png)
 
 ref: [link](https://docs.flagger.app/usage/deployment-strategies#canary-release)
 
@@ -109,7 +109,7 @@ TBU
 
 #### 実行中
 
-![image](../image/14.png)
+![image](../../image/14.png)
 
 実行されると、weightがあがります。
 
@@ -152,7 +152,7 @@ spec:
 
 #### Progressive Delivery完了
 
-![image](../image/15.png)
+![image](../../image/15.png)
 
 ```yaml:yaml
 apiVersion: networking.istio.io/v1beta1
@@ -193,7 +193,7 @@ promoteフェイズになると、VirtualServiceをcanary:primaryを50:5050に
 
 #### 完了後の動き
 
-![image](../image/16.png)
+![image](../../image/16.png)
 
 ```yaml:yaml
 apiVersion: networking.istio.io/v1beta1
@@ -254,7 +254,7 @@ Events:
 
 #### 参考値としてdashboard
 
-![image](../image/17.png)
+![image](../../image/17.png)
 
 ### 失敗パターン
 
@@ -276,14 +276,14 @@ TBU
 
 #### 実行中
 
-![image](../image/11.png)
+![image](../../image/11.png)
 
 今回はk9sの画面を表示していますが、`SUSPENDED`の数が増えていることがわかります。
 これは、metric_templateで定義した値がcanaryで設定してる閾値を満たしていないまたは、超えているためです。
 
 #### 失敗
 
-![image](../image/12.png)
+![image](../../image/12.png)
 
 今回はk9sの画面を表示していますが、`SUSPENDED`の数が設定している数を超えたため失敗したことがわかります。
 
@@ -309,7 +309,7 @@ TBU
 
 #### 参考値としてdashboard
 
-![image](../image/13.png)
+![image](../../image/13.png)
 
 ### tips
 

docs/istio/README.md → docs/servicemesh/istio/README.md

@@ -12,7 +12,7 @@ istioとは、ざっくり説明すると数あるサービスメッシュツー
 
 ref: [The Istio service mesh](https://istio.io/latest/about/service-mesh/#what-is-istio)
 
-![Istioの構成](../image/4.svg)
+![Istioの構成](../../image/4.svg)
 
 ref: [The Istio service mesh](https://istio.io/latest/about/service-mesh/)
 
@@ -27,15 +27,15 @@ Istioは、Istio Control Planeによって通信の設定が追加、更新、
 
 #### Discovery
 
-![Discovery](../image/5.png)
+![Discovery](../../image/5.png)
 
 Istioが有効化された状態でかつ、proxyがServiceに導入されることが有効化された状態で新規サービスをKubernetes上に構築すると、Istio Control Planeによって新しいサービスに自動的にProxyが注入されます。
 
 ref: [Use discovery selectors to configure namespaces for your Istio service mesh](https://istio.io/latest/blog/2021/discovery-selectors/)
 
 #### Configuration
 
-![Configuration](../image/6.png)
+![Configuration](../../image/6.png)
 
 開発者がサービスメッシュに関係する設定をapplyすると、Istio Control Planeがクラスター内に無数にあるproxyに対して、設定を追加、更新、削除を行います。
 
@@ -132,7 +132,7 @@ ref: [Sidecar](https://istio.io/latest/docs/reference/config/networking/sidecar/
 
 ###### サイドカーモードを図にすると
 
-![Istioの構成](../image/7.png)
+![Istioの構成](../../image/7.png)
 
 > [!TIP]
 > アンビエントモード紹介ドキュメントの下記でも解説されていますが、現状サイドカーモードがサポートされなくなるわけではありません。(2024/06/30現在)