ingress-nginx: Incorrect logs and ngx variables when using canary Ingresses
BUG REPORT
NGINX Ingress controller version: nginx-0.25
Kubernetes version (use kubectl version):
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:32:14Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Environment:
- Cloud provider or hardware configuration: baremetal
- OS (e.g. from /etc/os-release): Ubuntu 16.04.6 LTS
- Kernel (e.g.
uname -a):Linux kube-a-1 4.18.0-20-generic #21~18.04.1 SMP Thu May 16 11:54:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - Install tools: kubeadm
What happened:
When request is routed to a canary backend, there isn’t any indication in ngx variables and, therefore, in logs and in a custom Lua script that I use in a log_by_lua_block.
What you expected to happen: Proper Ingress name and service name/port should be logged and set in ngx variables when request is routed to a backend that is defined by a canary Ingress.
Anything else we need to know: The solution seems simple enough: we should provide more information to Lua scripts and modify them a bit. I’ve opened a PR in which I’ve attempted a naïve solution to these problems: https://github.com/kubernetes/ingress-nginx/pull/4367.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 30 (24 by maintainers)
I think it’s becoming clear what’s the issue: by our canary documentation canary settings gets applied to the ingress only if host and path matches. But you’ve shown an edge case where that invariant is not hold.
I think fundamental issue is that canary is configured based on host and path combination but when it is actually applied to a request, we use
$proxy_upstream_name, which is based on namespace, service and port. This is the problem.Regarding to using
split_clients, I feel like that’s an implementation detail (also I think that’s not as flexible to support all the features we offer at the moment). The fundamental issue I mentioned above will probably still stay. Instead we should make sure canary configuration during controller sync and then application during request processing is based on the same invariant.