Docs: add doc for global rate limiting #237
Conversation
Signed-off-by: Tom <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @Flying-Tom, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request adds new documentation that serves as a practical guide for setting up and testing global rate limiting functionality in kmesh. The document details the deployment of necessary components, configuration of traffic rules using an external rate limiting service, and verification of rate limiting behavior across multiple proxy instances, providing a clear path for users to implement robust traffic management.
Highlights
- New Documentation: Introduces a comprehensive guide for implementing and testing global rate limiting within the kmesh environment.
- Step-by-Step Setup: Provides detailed instructions covering the deployment of Kmesh, Istiod, sample services (sleep, httpbin), Redis for state management, and an external Envoy rate limiting service.
- EnvoyFilter Configuration: Demonstrates how to configure an EnvoyFilter to inject global rate limiting rules into a Waypoint proxy, including header-based rate limits for different quotas.
- Testing and Verification: Includes practical test cases using
curlto verify the rate limiting behavior for 'low', 'medium', and default quotas, along with steps to inspect Envoy configurations and rate limiting service logs. - Conceptual Differences: Outlines the key distinctions between global and local rate limiting, focusing on shared state, external service dependency, network impact, scalability, and configuration.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
✅ Deploy Preview for kmesh-net ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Code Review
This pull request adds comprehensive documentation for setting up and testing global rate limiting with kmesh. The guide is well-structured and covers all the necessary steps from deployment to verification. I've provided a few suggestions to improve clarity and ensure the reproducibility of the examples, such as using specific version tags for images instead of latest or master, rephrasing a heading for better readability, and refining the test commands to make the output easier to interpret.
| spec: | ||
| containers: | ||
| - name: ratelimit | ||
| image: envoyproxy/ratelimit:master |
There was a problem hiding this comment.
Using the master tag for the envoyproxy/ratelimit image is not ideal for documentation as it points to a potentially unstable version. To ensure users can reliably follow these steps, it's better to use a specific, stable version tag.
| image: envoyproxy/ratelimit:master | |
| image: envoyproxy/ratelimit:<SPECIFIC_STABLE_VERSION> |
| Next, create a dedicated Waypoint proxy for the `httpbin` service and label the service to direct its traffic through this Waypoint. | ||
|
|
||
| ```sh | ||
| kmeshctl waypoint apply -n default --name httpbin-waypoint --image ghcr.io/kmesh-net/waypoint:latest |
There was a problem hiding this comment.
Using the :latest tag for the waypoint image can lead to inconsistencies for users following this guide over time. Pinning to a specific version tag ensures that the documentation remains accurate and reproducible.
| kmeshctl waypoint apply -n default --name httpbin-waypoint --image ghcr.io/kmesh-net/waypoint:latest | |
| kmeshctl waypoint apply -n default --name httpbin-waypoint --image ghcr.io/kmesh-net/waypoint:<SPECIFIC_VERSION> |
| istioctl proxy-config all $WAYPOINT_POD -ojson | grep ratelimit -A 20 | ||
| ``` | ||
|
|
||
| ## Step 8. Find the following results, which means the configuration has been sent to waypoint |
There was a problem hiding this comment.
This heading is a bit long and awkward. A more concise title would improve readability.
| ## Step 8. Find the following results, which means the configuration has been sent to waypoint | |
| ## Step 8. Verify the Configuration |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | ||
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | ||
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | ||
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers |
There was a problem hiding this comment.
The test commands output full response headers, which makes it harder to quickly verify if rate limiting is working. Modifying the curl command to show only the HTTP status code would make the result much clearer for the user.
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:medium' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:medium' http://httpbin:8000/headers |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:low' http://httpbin:8000/headers | ||
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:low' http://httpbin:8000/headers |
There was a problem hiding this comment.
For consistency and clarity, this test case would also benefit from showing only the HTTP status code. This makes it immediately obvious when the rate limit is triggered.
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:low' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -H 'quota:low' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:low' http://httpbin:8000/headers | |
| kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' -H 'quota:low' http://httpbin:8000/headers |
| Without any quota header, requests are subject to the default limit of 10 requests per second globally. | ||
|
|
||
| ```sh | ||
| for i in {1..12}; do kubectl exec -it $SLEEP_POD -- curl http://httpbin:8000/headers; done |
There was a problem hiding this comment.
The output of this loop can be hard to parse. By changing the curl command to only output the HTTP status code, you can make it much easier for the user to see exactly when the rate limit is enforced.
| for i in {1..12}; do kubectl exec -it $SLEEP_POD -- curl http://httpbin:8000/headers; done | |
| for i in {1..12}; do kubectl exec -it $SLEEP_POD -- curl -s -o /dev/null -w '%{http_code}\n' http://httpbin:8000/headers; done |
No description provided.