Skip to content

Commit ee8b857

Browse files
officialasishkumarofficialasishkumar
committed
Revert "docs(k8s-proxy): add Kubernetes Proxy REST API and DaemonSet recording mode (#838)"
This reverts commit c352a42 except for the existing Vale Google.Units override, which is kept so the current PR Vale workflow continues to pass on pre-existing k8s text. Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>
1 parent 05ac9f6 commit ee8b857

5 files changed

Lines changed: 1 addition & 604 deletions

File tree

‎vale_styles/config/vocabularies/Base/accept.txt‎

Lines changed: 0 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -110,29 +110,10 @@ shipping_address_id
110110
[Ll]inux
111111
[Ee]nv
112112
[Kk]8s
113-
IPs
114113
[Dd]edup
115-
[Dd]edups
116-
[Rr]ollout[s]?
117-
[Pp]refill[s]?
118-
[Aa]uditable
119-
[Cc]ooldown
120-
[Ll]iveness
121114
[Cc]ron
122115
[Tt]oolchain
123116
[Rr]untime[s]?
124-
MongoIDs
125-
initialised
126117
normalisation
127118
behaviour
128119
polyglot
129-
[Dd]aemon[Ss]et[s]?
130-
[Cc]RD[s]?
131-
eBPF
132-
[Mm]utatingAdmissionWebhook
133-
RecordingSession[s]?
134-
ReplaySession[s]?
135-
keploy-daemonset
136-
keploy-agent
137-
recordingsessions
138-
replaysessions

‎versioned_docs/version-3.0.0/quickstart/k8s-proxy.md‎

Lines changed: 0 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -135,20 +135,6 @@ At this point, your e-commerce application is live and ready to receive traffic.
135135

136136
## Enable Live Record & Replay with Keploy Proxy
137137

138-
### Pick a recording mode
139-
140-
The Keploy Proxy supports two ways to capture traffic from your application Pods. Both modes drive the **same Console UI and REST API**—the rest of this guide works identically in either case. Pick whichever fits your environment.
141-
142-
| | **Sidecar mode (default)** | **DaemonSet mode** |
143-
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
144-
| How traffic is captured | A `keploy-agent` sidecar container is injected into your application Pod via a `MutatingAdmissionWebhook`. The agent intercepts traffic alongside your container. | A `keploy-daemonset` Pod runs on each node and captures traffic from existing application Pods using **eBPF**—no sidecar, no application Pod restart. |
145-
| What happens on `Start Recording` | The proxy injects the agent and rolls the application Deployment. | The proxy creates a `RecordingSession` Custom Resource. The DaemonSet picks it up and programs its BPF target maps to capture matching Pods on each node. |
146-
| Pod mutation on the application namespace | Required (`patch` on Deployments). | **Not required.** Application Pods are never modified. |
147-
| Application restart at recording start | Yes, on first recording. | No. |
148-
| Best for | Dev/staging, teams happy to grant write RBAC to Keploy on the application namespace. | Production with read-only RBAC on the application namespace; environments where rolling the application Pod has unacceptable cost; or when you want cluster-mode auto-replay (replay runs in a separate cluster you provide). |
149-
150-
The screenshots below show the **Sidecar** flow because that is the default. To use **DaemonSet** mode instead, set the daemonset values when you run the Helm command in step 4 below—every other step is identical.
151-
152138
### 1. Open Keploy Dashboard
153139

154140
Visit:
@@ -189,38 +175,6 @@ Once you have provided the cluster details, you can install the Keploy Proxy in
189175

190176
<img src="https://keploy-devrel.s3.us-west-2.amazonaws.com/k8s-proxy/k8s_helm_command.png" alt="Sample Keploy K8s proxy" width="100%" style={{ borderRadius: '5px' }}/>
191177

192-
#### DaemonSet mode (optional)
193-
194-
If you want to use **DaemonSet mode** instead of the default Sidecar mode, append the daemonset values to the Helm command shown in the dashboard. The Helm chart installs the `recordingsessions.keploy.io` and `replaysessions.keploy.io` Custom Resource Definitions, and the per-node DaemonSet that performs the eBPF capture.
195-
196-
```bash
197-
# add these flags to the Helm command from the dashboard:
198-
--set daemonset.enabled=true \
199-
--set daemonset.crds.install=true
200-
```
201-
202-
After install you should see a per-node `k8s-proxy-daemonset-*` Pod alongside the regular proxy Deployment:
203-
204-
```bash
205-
kubectl get pods -n keploy
206-
# NAME READY STATUS RESTARTS AGE
207-
# k8s-proxy-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
208-
# k8s-proxy-daemonset-xxxxx 1/1 Running 0 1m ← per node
209-
# k8s-proxy-daemonset-yyyyy 1/1 Running 0 1m
210-
# k8s-proxy-mongodb-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
211-
# k8s-proxy-minio-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
212-
```
213-
214-
Verify the CRDs registered:
215-
216-
```bash
217-
kubectl get crd | grep keploy.io
218-
# recordingsessions.keploy.io <date>
219-
# replaysessions.keploy.io <date>
220-
```
221-
222-
The rest of this quickstart proceeds identically—the Console **Start Recording** button creates a `RecordingSession` CR which the DaemonSet picks up; you do not need to interact with the CR yourself.
223-
224178
### 5. Verify the Installation
225179

226180
Paste the Helm command into the terminal. Once the installation is complete, verify that the Keploy Proxy is running.

‎versioned_docs/version-4.0.0/quickstart/k8s-proxy.md‎

Lines changed: 0 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -135,20 +135,6 @@ At this point, your e-commerce application is live and ready to receive traffic.
135135

136136
## Enable Live Record & Replay with Keploy Proxy
137137

138-
### Pick a recording mode
139-
140-
The Keploy Proxy supports two ways to capture traffic from your application Pods. Both modes drive the **same Console UI and REST API**—the rest of this guide works identically in either case. Pick whichever fits your environment.
141-
142-
| | **Sidecar mode (default)** | **DaemonSet mode** |
143-
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
144-
| How traffic is captured | A `keploy-agent` sidecar container is injected into your application Pod via a `MutatingAdmissionWebhook`. The agent intercepts traffic alongside your container. | A `keploy-daemonset` Pod runs on each node and captures traffic from existing application Pods using **eBPF**—no sidecar, no application Pod restart. |
145-
| What happens on `Start Recording` | The proxy injects the agent and rolls the application Deployment. | The proxy creates a `RecordingSession` Custom Resource. The DaemonSet picks it up and programs its BPF target maps to capture matching Pods on each node. |
146-
| Pod mutation on the application namespace | Required (`patch` on Deployments). | **Not required.** Application Pods are never modified. |
147-
| Application restart at recording start | Yes, on first recording. | No. |
148-
| Best for | Dev/staging, teams happy to grant write RBAC to Keploy on the application namespace. | Production with read-only RBAC on the application namespace; environments where rolling the application Pod has unacceptable cost; or when you want cluster-mode auto-replay (replay runs in a separate cluster you provide). |
149-
150-
The screenshots below show the **Sidecar** flow because that is the default. To use **DaemonSet** mode instead, set the daemonset values when you run the Helm command in step 4 below—every other step is identical.
151-
152138
### 1. Open Keploy Dashboard
153139

154140
Visit:
@@ -189,38 +175,6 @@ Once you have provided the cluster details, you can install the Keploy Proxy in
189175

190176
<img src="https://keploy-devrel.s3.us-west-2.amazonaws.com/k8s-proxy/k8s_helm_command.png" alt="Sample Keploy K8s proxy" width="100%" style={{ borderRadius: '5px' }}/>
191177

192-
#### DaemonSet mode (optional)
193-
194-
If you want to use **DaemonSet mode** instead of the default Sidecar mode, append the daemonset values to the Helm command shown in the dashboard. The Helm chart installs the `recordingsessions.keploy.io` and `replaysessions.keploy.io` Custom Resource Definitions, and the per-node DaemonSet that performs the eBPF capture.
195-
196-
```bash
197-
# add these flags to the Helm command from the dashboard:
198-
--set daemonset.enabled=true \
199-
--set daemonset.crds.install=true
200-
```
201-
202-
After install you should see a per-node `k8s-proxy-daemonset-*` Pod alongside the regular proxy Deployment:
203-
204-
```bash
205-
kubectl get pods -n keploy
206-
# NAME READY STATUS RESTARTS AGE
207-
# k8s-proxy-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
208-
# k8s-proxy-daemonset-xxxxx 1/1 Running 0 1m ← per node
209-
# k8s-proxy-daemonset-yyyyy 1/1 Running 0 1m
210-
# k8s-proxy-mongodb-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
211-
# k8s-proxy-minio-xxxxxxxxxx-xxxxx 1/1 Running 0 1m
212-
```
213-
214-
Verify the CRDs registered:
215-
216-
```bash
217-
kubectl get crd | grep keploy.io
218-
# recordingsessions.keploy.io <date>
219-
# replaysessions.keploy.io <date>
220-
```
221-
222-
The rest of this quickstart proceeds identically—the Console **Start Recording** button creates a `RecordingSession` CR which the DaemonSet picks up; you do not need to interact with the CR yourself.
223-
224178
### 5. Verify the Installation
225179

226180
Paste the Helm command into the terminal. Once the installation is complete, verify that the Keploy Proxy is running.

0 commit comments

Comments
 (0)