Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Routes entity page, router expressions, proxying #168

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

cloudjumpercat
Copy link
Contributor

@cloudjumpercat cloudjumpercat commented Dec 10, 2024

TODO

  • Revise proxy entity page
  • this proxy examples section and below, how tos? example references? Proxy Reference - Kong Gateway | Kong Docs (I made sure they were in the content strategy spreadsheet, most were already there as how tos)
  • Revisit routing section and revise
  • Determine if I can axe the existing routing standalone page or make it an include, etc.
  • Expressions router pages? Which do I need? Mark myself down for them and write
  • The following ones are what I think I'll need. things will be clearer once I finish revising the docs above ⬆️
  • load balance how to with upstream
  • Load balance conceptual/ref
  • health check how to
  • circuit break how to
  • health check/circuit break overview conceptual page

Preview Links

Checklist

  • Every page is page one
  • Tested how-to docs. If not, note why here.
  • All pages contain metadata
  • Updated sources.yaml. For more info review track docs changes
  • Any new docs link to existing docs.

Copy link

netlify bot commented Dec 10, 2024

Deploy Preview for kongdeveloper ready!

Name Link
🔨 Latest commit 1def049
🔍 Latest deploy log https://app.netlify.com/sites/kongdeveloper/deploys/676458bac664ce0008bc80cf
😎 Deploy Preview https://deploy-preview-168--kongdeveloper.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Contributor

@lena-larionova lena-larionova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor adjustments - I was working on the "Services" page and realized this section moved to "Routes", so just adding my edits from that.

app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
@cloudjumpercat cloudjumpercat changed the title Routes entity page (and supporting pages) Routes, Targets, Upstream entity pages/ router expressions/ proxying/ load balancing Dec 13, 2024
When the external application tries to access the Service via {{site.base_gateway}} using `/external`, they're rate limited.
But when the internal application accesses the Service using {{site.base_gateway}} using `/internal`, the internal application isn't limited.

## How routing works
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: I added routing here and removed the existing routing standalone page. My thinking, routing made the most sense in context with routes. I think it would be difficult to create something more than a very basic route without understanding routing, so in the spirit of every page is page one, I added it here.

But I did wonder if it should be a standalone page still and this section could be an include.

* In `expressions` mode, we recommend putting more likely matched Routes before (as in, higher priority) those that are less frequently matched.
* Regular expressions in Routes use more resources to evaluate than simple prefixes. In installations with thousands of Routes, replacing regular expression with simple prefix can improve throughput and latency of {{site.base_gateway}}. If regex must be used because an exact path match must be performed, using the [expressions router](/gateway/routing/expressions/) will significantly improve {{site.base_gateway}}’s performance in this case.

## Route use cases
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: should this be bumped up the page?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say yes


{{ page.description }} This page details information about how {{site.base_gateway}} handles proxying. The following diagram shows how proxying is handled by {{site.base_gateway}}:

{% mermaid %}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: I used ChatGPT help on this diagram, but I revised everything and the input I provided it was the ordered list below this diagram. Still, I'd like a review for tech accuracy, especially the parts about the load balancer. I think ChatGPT got it wrong, so I made some changes to that part and wanted to confirm that I did them correctly.

@@ -0,0 +1,191 @@
---
title: Proxying with {{site.base_gateway}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: Is this too much info for the proxying page? Should proxying just contain info about proxying and the connective parts (ex. listeners, routing, plugins, etc) should go on a traffic control landing page with proxying as another card/section instead? This is similar to what we had in the offsite proxy branch: main...proxy-reference#diff-8922116eb8441698da97efe2beeb185fb024118f8add77981f8eeb930867bbc6

I thought listeners, etc. could be helpful on this page to understanding proxying, but wasn't sure if others felt it was out of place.

Kong's configuration capabilities: the **Admin API** (`8001` by default).
{:.important}
> **Important**: If you need to expose the `admin_listen` port to the internet in a production environment,
> {% if_version lte:2.8.x %}[secure it with authentication](/gateway/{{include.release}}/admin-api/secure-admin-api/).{% endif_version %}{% if_version gte:3.0.x %}[secure it with authentication](/gateway/{{include.release}}/production/running-kong/secure-admin-api/).{% endif_version %}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: I couldn't find the Admin API in the dev site, does anyone have a link to it?

1. If multiple Routes match, the {{site.base_gateway}} router then orders all defined Routes by their priority and uses the highest priority matching Route to handle a request.
1. If a given request matches the rules of a specific route, {{site.base_gateway}} will
run any global, Route, or Service [plugins]() before it proxies the request. They are run in the following order: Route, Service <!--when does the global config get run?--> These configured plugins will run their `access` phase, which you can find more
information about in the [Plugin development guide][plugin-development-guide].
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: I don't think we added the autogenerated PDK yet. How do we want to handle links to autogenerated pages?

products:
- gateway

works_on:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it works on both can the platform be agnostic?

@Guaris Guaris mentioned this pull request Dec 16, 2024
5 tasks
Comment on lines 74 to 75
Now you can create a Route with your new path, `/new-path`, that points to the new Upstream.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds a second route and associates it to the service. So by this point you have:
1 service pointing to the upstream url http://httpbin.konghq.com/anything
2. routes proxying to it, one at /anything, and one at /new-path.
3. And an optional stray route from the prereq

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, i left this undone, you should remove the original /anything route

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the original route.

To validate that the URL was successfully rewritten and the request is now being matched to the new Upstream instead of the old one, run the following:

```bash
curl -i http://localhost:8000/new-path
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a better test would be seeing what URL you are getting from the old path, and from the new one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Guaris I like this idea. I think the idea is that traffic is routed away from the old path to the new one, like a redirect (let me know if this is wrong), so if you go to the old path, should it redirect you to the new path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Guaris I think this is working correctly with http://localhost:8000/new-path as this is the response I get:


HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 486
Connection: keep-alive
Server: gunicorn/19.9.0
Date: Wed, 18 Dec 2024 21:14:18 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Kong-Upstream-Latency: 352
X-Kong-Proxy-Latency: 488
Via: 1.1 kong/3.9.0.0-enterprise-edition
X-Kong-Request-Id: 0bfd8c4c54274e4ffbbfcd2c5c939c65

{
  "args": {}, 
  "data": "", 
  "files": {}, 
  "form": {}, 
  "headers": {
    "Accept": "*/*", 
    "Connection": "keep-alive", 
    "Host": "httpbin.konghq.com", 
    "User-Agent": "curl/8.4.0", 
    "X-Forwarded-Host": "localhost", 
    "X-Forwarded-Path": "/new-path", 
    "X-Forwarded-Prefix": "/new-path", 
    "X-Kong-Request-Id": "0bfd8c4c54274e4ffbbfcd2c5c939c65"
  }, 
  "json": null, 
  "method": "GET", 
  "origin": "172.27.0.1", 
  "url": "http://localhost/anything"
}


tldr:
q: How can I divert traffic from an old URL to a new one with {{site.base_gateway}}?
a: Set up a Gateway Service with the old URL path and create a new a Route with new path.For example, your legacy upstream endpoint may have a base URI like `/api/old/`. However, you want your publicly accessible API endpoint to now be named `/new/api`. To route the Service’s upstream endpoint to the new URL, you can set up a Service with the path `/api/old/` and a Route with the path `/new/api`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thinjk the /api/new and /api/old are good examples of what you are trying to do but because the deck file and steps dont reflect that I got thrown off. I think that the api/old and api/new can be illustrated through the steps better than as the answer int he tld;r

Copy link
Contributor

@lena-larionova lena-larionova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partial review of the entity pages, ran out of time for the rest.

app/_gateway_entities/target.md Outdated Show resolved Hide resolved
app/_gateway_entities/target.md Outdated Show resolved Hide resolved
app/_gateway_entities/target.md Outdated Show resolved Hide resolved
app/_gateway_entities/target.md Outdated Show resolved Hide resolved
app/_gateway_entities/target.md Outdated Show resolved Hide resolved
Comment on lines 37 to 45
* Hosts: Lists of domains that match a route
* Methods: HTTP methods that match a route
* Headers: Lists of values that are expected in the header of a request
* Redirect status codes: HTTPS status codes
* Tags: Optional set of strings to group routes with
When you configure Routes, you can also specify the following:

## Route and service interaction
* **Protocols:** The protocol used to communicate with the [Upstream](/gateway/entities/upstream/) application.
* **Hosts:** Lists of domains that match a Route
* **Methods:** HTTP methods that match a Route
* **Headers:** Lists of values that are expected in the header of a request
* **Redirect status codes:** HTTPS status codes
* **Tags:** Optional set of strings to group Routes with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this list still useful? We have the Route schema on the page now, so this info is already here. Plus, there are almost definitely more options than this now.

app/_gateway_entities/route.md Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
@lena-larionova
Copy link
Contributor

For the Routes entity page: I'm having a hard time seeing the big picture right now. It's a hefty page, and I wonder if all of the content that's been migrated over needs to be there. Is there anything here that's actually covered by having the schema on the page now?

I don't have the answer to this at all - but I am curious if there's a better way to organize this content.

```
tls.sni =^ ".example.com"
```
![Router matching flow](https://docs.konghq.com/assets/images/products/gateway/reference/expressions-language/router-matching-flow.png)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reviewers: I wrote this down to convert to Mermaid, but I'm just doing a 1:1 copy pretty much and wanted to get this reviewed. I'm going to need to learn how to escape some characters in Mermaid, so this might take me a bit.

app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved
app/_gateway_entities/route.md Outdated Show resolved Hide resolved

Routing a request based on its Host header is the most straightforward way to proxy traffic through Kong Gateway, especially since this is the intended usage of the HTTP Host header. `hosts` accepts multiple values, which must be comma-separated when specifying them via the Admin API, and is represented in a JSON payload. You can also use wildcards in hostnames. Wildcard hostnames must contain only one asterisk at the leftmost or rightmost label of the domain.

When proxying, Kong Gateway’s default behavior is to set the Upstream request’s Host header to the hostname specified in the Service’s `host`. The `preserve_host` field accepts a boolean flag instructing Kong Gateway not to do so.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When proxying, Kong Gateway’s default behavior is to set the Upstream request’s Host header to the hostname specified in the Service’s `host`. The `preserve_host` field accepts a boolean flag instructing Kong Gateway not to do so.
When proxying, {{site.base_gateway}}’s default behavior is to set the Upstream request’s Host header to the hostname specified in the Service’s `host`. The `preserve_host` field accepts a boolean flag instructing Kong Gateway not to do so.

app/gateway/routing/expressions-router-reference.md Outdated Show resolved Hide resolved

## Allowed type and operator combinations

Here are the allowed combination of field types and constant types with each operator.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Here are the allowed combination of field types and constant types with each operator.
Here are the allowed combinations of field types and constant types with each operator.

app/gateway/routing/expressions-router-reference.md Outdated Show resolved Hide resolved
app/gateway/traffic-control/proxy.md Outdated Show resolved Hide resolved
app/gateway/traffic-control/proxy.md Outdated Show resolved Hide resolved
cloudjumpercat and others added 2 commits December 18, 2024 15:55
This was referenced Dec 18, 2024
@cloudjumpercat
Copy link
Contributor Author

The Request Transformer broken link will be resolved with updating the branch

@cloudjumpercat cloudjumpercat marked this pull request as ready for review December 19, 2024 14:06
@cloudjumpercat cloudjumpercat requested a review from a team as a code owner December 19, 2024 14:06
@cloudjumpercat cloudjumpercat changed the title Routes, Targets, Upstream entity pages/ router expressions/ proxying/ load balancing Routes entity page, router expressions, proxying Dec 19, 2024
| `X-Forwarded-Port: <port>` | `<port>` is the port of the server which accepted a request. If `$realip_remote_addr` is one of the **trusted** addresses, the request header with the same name gets forwarded if provided. Otherwise, the value of the `$server_port` variable provided by [ngx_http_core_module](https://nginx.org/docs/http/ngx_http_core_module.html#var_server_port) will be used. |
| `X-Forwarded-Prefix: <path>` | `<path>` is the path of the request which was accepted by {{site.base_gateway}}. If `$realip_remote_addr` is one of the **trusted** addresses, the request header with the same name gets forwarded if provided. Otherwise, the value of the `$request_uri` variable (with the query string stripped) provided by [ngx_http_core_module](https://nginx.org/docs/http/ngx_http_core_module.html#var_server_port) will be used. **Note**: {{site.base_gateway}} returns `"/"` for an empty path, but it doesn't do any other normalization on the request path. |
| All other headers | Forwarded as-is by {{site.base_gateway}} |
<!--vale on-->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<!--vale on-->
<!--vale on-->

@cloudjumpercat for some reason adding a new line here fixes the rendering issue 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants