Fix markdown linting issues in circuit breaker documentation

Signed-off-by: Anya <[email protected]>

Author: Anya

docs/transpot-layer/circuit-breaker.md

@@ -22,13 +22,15 @@ Circuit breaking is an important pattern for creating resilient microservice app
   Please refer to [quickstart](https://kmesh.net/en/docs/setup/quick-start/) and change into ads mode
 - Ensure proper RBAC permissions are configured for KMesh and Istio CNI
 - Make sure the following RBAC permissions are set up for Istio CNI:
+
   ```bash
   kubectl create clusterrolebinding istio-cni-cluster-admin --clusterrole=cluster-admin --serviceaccount=istio-system:istio-cni
   ```
 
 ## Deploy the test applications
 
 1. Create the test service:
+
 ```yaml
 # sample-app.yaml
 apiVersion: apps/v1
@@ -71,6 +73,7 @@ spec:
 ```
 
 2. Deploy Fortio load tester:
+
 ```yaml
 # fortio.yaml
 apiVersion: apps/v1
@@ -108,23 +111,27 @@ spec:
 ```
 
 3. Enable Istio sidecar injection in the default namespace:
+
 ```bash
 kubectl label namespace default istio-injection=enabled --overwrite
 ```
 
 4. Apply the test service and Fortio deployment:
+
 ```bash
 kubectl apply -f sample-app.yaml
 kubectl apply -f fortio.yaml
 ```
 
 5. Verify the pods are running with Istio sidecars (should show 2/2 READY):
+
 ```bash
 kubectl get pods
 ```
 
 You should see output similar to:
-```
+
+```text
 NAME                            READY   STATUS    RESTARTS   AGE
 fortio-demo-57459944b-kk8c9     2/2     Running   0          72s
 httpbin-demo-54bcd57df4-hxqhn   2/2     Running   0          6s
@@ -133,6 +140,7 @@ httpbin-demo-54bcd57df4-hxqhn   2/2     Running   0          6s
 ## Configure circuit breaker
 
 Apply the circuit breaker configuration:
+
 ```yaml
 # circuit-breaker.yaml
 apiVersion: networking.istio.io/v1alpha3
@@ -155,16 +163,19 @@ spec:
 ```
 
 Apply the configuration:
+
 ```bash
 kubectl apply -f circuit-breaker.yaml
 ```
 
 Verify the destination rule was created correctly:
+
 ```bash
 kubectl get destinationrule httpbin-demo-cb -o yaml
 ```
 
 You should see output similar to:
+
 ```yaml
 apiVersion: networking.istio.io/v1
 kind: DestinationRule
@@ -204,7 +215,8 @@ kubectl exec -it $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].met
 ```
 
 You should see output similar to:
-```
+
+```text
 Fortio 1.69.5 running at 0 queries per second, 12->12 procs, for 50 calls: http://httpbin-demo:8000/get
 Starting at max qps with 20 thread(s) [gomax 12] for exactly 50 calls (2 per thread + 10)
 Ended after 410.534881ms : 50 calls. qps=121.79
@@ -240,7 +252,8 @@ kubectl exec -it $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].met
 ```
 
 You should see output similar to:
-```
+
+```text
 Fortio 1.69.5 running at 0 queries per second, 12->12 procs, for 50 calls: http://httpbin-demo:8000/get
 Starting at max qps with 20 thread(s) [gomax 12] for exactly 50 calls (2 per thread + 10)
 05:36:14.160 r109 [WRN] http_client.go:1151> Non ok http code, code=503, status="HTTP/1.1 503", thread=19, run=0
@@ -266,6 +279,7 @@ All done 50 calls (plus 0 warmup) 9.869 ms avg, 383.4 qps
 ```
 
 Now you can see the circuit breaker in action:
+
 - Only 24% of requests succeeded with HTTP 200 responses
 - 76% of requests failed with HTTP 503 responses
 - The circuit breaker effectively rejected excess connections
@@ -280,7 +294,7 @@ kubectl exec $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].metadat
 
 You should see output that includes metrics related to the httpbin service. Look for entries with response codes and UO (Upstream Overflow) flags:
 
-```
+```text
 istiocustom.istio_requests_total.reporter.source.source_workload.fortio-demo.source_canonical_service.fortio-demo.source_canonical_revision.latest.source_workload_namespace.default.source_principal.spiffe://cluster.local/ns/default/sa/default.source_app.fortio-demo.source_version.source_cluster.Kubernetes.destination_workload.httpbin-demo.destination_workload_namespace.default.destination_principal.spiffe://cluster.local/ns/default/sa/default.destination_app.httpbin-demo.destination_version.latest.destination_service.httpbin-demo.default.svc.cluster.local.destination_canonical_service.httpbin-demo.destination_canonical_revision.latest.destination_service_name.httpbin-demo.destination_service_namespace.default.destination_cluster.Kubernetes.request_protocol.http.response_code.200.grpc_response_status.response_flags.-.connection_security_policy.unknown: 12
 istiocustom.istio_requests_total.reporter.source.source_workload.fortio-demo.source_canonical_service.fortio-demo.source_canonical_revision.latest.source_workload_namespace.default.source_principal.unknown.source_app.fortio-demo.source_version.source_cluster.Kubernetes.destination_workload.unknown.destination_workload_namespace.unknown.destination_principal.unknown.destination_app.unknown.destination_version.unknown.destination_service.httpbin-demo.default.svc.cluster.local.destination_canonical_service.unknown.destination_canonical_revision.latest.destination_service_name.httpbin-demo.destination_service_namespace.default.destination_cluster.unknown.request_protocol.http.response_code.503.grpc_response_status.response_flags.UO.connection_security_policy.unknown: 38
 ```
@@ -306,20 +320,23 @@ kubectl get pods -w
 ```
 
 Output:
-```
+
+```text
 NAME                            READY   STATUS    RESTARTS   AGE
 fortio-demo-57459944b-kk8c9     2/2     Running   0          72s
 httpbin-demo-54bcd57df4-hxqhn   2/2     Running   0          6s
 ```
 
 Now test the recovery:
+
 ```bash
 kubectl exec -it $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].metadata.name}) \
   -c fortio -- fortio load -c 5 -qps 10 -n 50 -loglevel Warning http://httpbin-demo:8000/get
 ```
 
 Output:
-```
+
+```text
 Fortio 1.69.5 running at 10 queries per second, 12->12 procs, for 50 calls: http://httpbin-demo:8000/get
 Starting at 10 qps with 5 thread(s) [gomax 12] : exactly 50, 10 calls each (total 50 + 0)
 05:37:00.310 r73 [WRN] http_client.go:1151> Non ok http code, code=503, status="HTTP/1.1 503", thread=2, run=0
@@ -352,7 +369,8 @@ kubectl logs $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].metadat
 ```
 
 Example output:
-```
+
+```text
 {"ts":1749274539.796037,"level":"info","r":1,"file":"updater.go","line":50,"msg":"Configmap flag value watching on /etc/fortio"}
 {"ts":1749274539.796072,"level":"crit","r":1,"file":"scli.go","line":83,"msg":"Unable to watch config/flag changes in /etc/fortio: dflag: error initializing fsnotify watcher"}
 {"ts":1749274539.796122,"level":"info","r":1,"file":"scli.go","line":122,"msg":"Starting","command":"Φορτίο","version":"1.69.5 h1:h+42fJ1HF61Jj+WgPmC+C2wPtM5Ct8JLHSLDyEgGID4= go1.23.9 amd64 linux","go-max-procs":12}
@@ -386,26 +404,30 @@ kubectl get destinationrule httpbin-demo-cb -o yaml
 ## Understanding what happened
 
 The circuit breaker configuration:
+
 - Limits concurrent HTTP connections to 1 (`maxConnections: 1`)
 - Limits pending HTTP requests to 1 (`http1MaxPendingRequests: 1`)
 - Limits requests per connection to 1 (`maxRequestsPerConnection: 1`)
 - Configures outlier detection to eject hosts after 1 consecutive error
 
 When the service is overloaded:
+
 1. Circuit breaker trips when connection thresholds are exceeded
 2. Subsequent requests are rejected with HTTP 503 errors
 3. The service continues to handle requests within its configured capacity
 4. Only a small percentage of requests succeed (20-28% in our tests)
 5. After the `baseEjectionTime` (3s), the circuit will attempt to close and allow traffic again
 
 Our test results clearly show the circuit breaker in action:
+
 - Without circuit breaker: 100% success rate (all HTTP 200)
 - With circuit breaker: ~24% success rate (24% HTTP 200, 76% HTTP 503)
 - After recovery test: ~28% success rate (28% HTTP 200, 72% HTTP 503)
 
 ## Clean up
 
 Remove test components:
+
 ```bash
 kubectl delete -f circuit-breaker.yaml
 kubectl delete -f sample-app.yaml
@@ -417,35 +439,41 @@ kubectl delete -f fortio.yaml
 If you encounter issues:
 
 1. Check pod status:
+
 ```bash
 kubectl get pods
 kubectl describe pod <pod-name>
 ```
 
 2. Verify Istio sidecar injection:
+
 ```bash
 # Pods should show 2/2 READY if sidecar is properly injected
 kubectl get pods
 ```
 
 3. Check circuit breaker configuration:
+
 ```bash
 kubectl get destinationrule
 kubectl describe destinationrule httpbin-demo-cb
 ```
 
 4. Check for CNI issues:
+
 ```bash
 kubectl get pods -n istio-system
 kubectl logs -n istio-system $(kubectl get pod -n istio-system -l app=istio-cni-node -o jsonpath='{.items[0].metadata.name}')
 ```
 
 5. Ensure proper RBAC permissions:
+
 ```bash
 kubectl create clusterrolebinding istio-cni-cluster-admin --clusterrole=cluster-admin --serviceaccount=istio-system:istio-cni
 ```
 
 6. Check file descriptor limits in Istio CNI pods:
+
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: v1
@@ -469,7 +497,8 @@ EOF
 ```
 
 7. View application logs:
+
 ```bash
 kubectl logs deploy/httpbin-demo
 kubectl logs $(kubectl get pod -l app=fortio-demo -o jsonpath={.items[0].metadata.name})
-```
+```