You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/data/markdown/docs/40 xk6-disruptor/01 Get started/04 Expose Your Application.md
+7-8Lines changed: 7 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,34 +23,33 @@ Forwarding from 127.0.0.1:8080 -> 80
23
23
24
24
To be able to inject faults, `xk6-disruptor` must [install an agent on each target](/javascript-api/xk6-disruptor/explanations/how-xk6-disruptor-works) that intercepts the requests and applies the desired disruptions. This process requires any existing connection to the targets to be redirected to the agent.
25
25
26
-
Due to a existing bug in `kubectl`, the process of installing the disruptor can potentially [break the port forwarding](https://github.com/grafana/xk6-disruptor/issues/254). Notice that this issue happens only if the faults are injected in the service that is exposed using port forward. If the faults are injected in another service not exposed by port-forwarding, there shouldn't be any issue.
26
+
Due to an existing bug in `kubectl`, the process of installing the disruptor can potentially [break the port forwarding](https://github.com/grafana/xk6-disruptor/issues/254). Notice that this issue happens only if the faults are injected in the service that is exposed using port forward. If the faults are injected in another service not exposed by port-forwarding, there shouldn't be any issue.
27
27
28
28
Until this issue is solved in `kubectl`, tests using port forwarding to access a service should ensure the agent is installed in the targets before any traffic is sent by the test.
29
29
30
-
The simplest way to accomplish this is to ensure the scenario that executes the load (2) starts after the scenario that injects the faults (1):
30
+
The simplest way to accomplish this is to ensure the scenario that executes the load (#2) starts after the scenario that injects the faults (#1):
31
31
32
32
```javascript
33
33
scenarios: {
34
-
disrupt: { (1)
34
+
disrupt: { // #1 inject faults
35
35
executor:'shared-iterations',
36
36
iterations:1,
37
37
vus:1,
38
38
exec:"disrupt",
39
39
startTime:"0s",
40
-
}
41
-
load: { (2)
40
+
},
41
+
load: { // #2 execute load
42
42
executor:'constant-arrival-rate',
43
43
rate:100,
44
44
preAllocatedVUs:10,
45
45
maxVUs:100,
46
46
exec:"default",
47
-
startTime:'20s', // give time for the agents to be installed
47
+
startTime:'20s', // give time for the agents to be installed
48
48
duration:"30s",
49
49
}
50
50
}
51
51
```
52
52
53
-
54
53
## As a LoadBalancer service
55
54
56
55
A service of type [`LoadBalancer`](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) receives an external IP from an external load-balancer provider.
@@ -102,4 +101,4 @@ It uses the cluster’s IP address as a gateway. The tunnel command exposes the
0 commit comments