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
There's an incredible variation of different cases for gateways and addresses across different distros of Kubernetes.
The most common case for users doing a tutorial is using a local installation of Kubernetes (not a cloud hosted distro). In this case Radius is going to report the gateway URL as "unknown".
The tutorial doesn't address this at all.
Describe the solution you'd like
The how-to needs to explain the cases where unknown can be returned by Radius, and how to find the right address.
Where should the new material be placed?
As part of this page, or in an FAQ about gateways/networking and linked form this page.
For a locally installation of Kubernetes, the user is working through multiple levels of virtualization:
Host -> VM -> Nodes (VMs or Containers) -> Containers
At each of these layers the networking environment and IPs that can be routed are different.
We need to know the IP address that can be used by the Host to talk to one of the Nodes. Kubernetes is running on the Nodes and has no way to reason about the outer layers of configuration.
What content needs to be created or modified?
https://docs.radapp.io/guides/author-apps/networking/gateways/
There's an incredible variation of different cases for gateways and addresses across different distros of Kubernetes.
The most common case for users doing a tutorial is using a local installation of Kubernetes (not a cloud hosted distro). In this case Radius is going to report the gateway URL as "unknown".
The tutorial doesn't address this at all.
Describe the solution you'd like
The how-to needs to explain the cases where
unknown
can be returned by Radius, and how to find the right address.Where should the new material be placed?
As part of this page, or in an FAQ about gateways/networking and linked form this page.
Additional context
Originally reported via Discord here: https://discord.com/channels/1113519723347456110/1167683397909479474
For a locally installation of Kubernetes, the user is working through multiple levels of virtualization:
Host -> VM -> Nodes (VMs or Containers) -> Containers
At each of these layers the networking environment and IPs that can be routed are different.
We need to know the IP address that can be used by the Host to talk to one of the Nodes. Kubernetes is running on the Nodes and has no way to reason about the outer layers of configuration.
AB#9969
The text was updated successfully, but these errors were encountered: