You can convert some, but not all NGINX location+proxy_pass configuration into Kong service and route configuration. Your configuration is simple and should convert fine–more complex configuration that rearranges part of the client-facing path into different locations in the upstream path is where you can encounter issues.
In Kubernetes, you’ll need to create Service and Ingress resources. Since S3 doesn’t actually run in your K8S cluster, you’ll use an ExternalName Service. That only provides the hostname portion of the upstream service, but that should be sufficient for your configuration–if you wanted to append additional path components after, e.g. something like
/foo/bar/$1, you’d also include a path annotation.
For the client-facing configuration, you’ll create an Ingress resource. Its rules will include a path, e.g.
/media/xyz and typically a hostname (from the
server_name of the
server block that contains your
location block). Since you don’t want to include the
/media/xyz path in your upstream requests, you’ll include a strip-path annotation set to
Note that the latest K8S Ingress documentation covers v1 of the Ingress resource. While our controller supports both, you K8S cluster may only support the older v1beta format. K8S 1.18 supports v1 as a beta feature, and 1.19 supports it by default. If you’re on 1.17 or older, use the “Versions” menu at the top to switch to your version.