Refactor nginx ssl passthrough #614
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
This change is |
|
Coverage decreased (-0.8%) to 45.507% when pulling e2fe3369a677b7a2e282d2e555eed4cca18bfccb on aledbf:refactor-passthrough into fc67b1d on kubernetes:master. |
|
Coverage decreased (-0.8%) to 45.492% when pulling e2fe3369a677b7a2e282d2e555eed4cca18bfccb on aledbf:refactor-passthrough into fc67b1d on kubernetes:master. |
| } | ||
| } | ||
| } | ||
| } | ||
| if len(isHTTPSfrom) > 0 { | ||
| if isHTTP { | ||
| for _, server := range isHTTPSfrom { | ||
| glog.Warningf("backend type mismatch on %v, assuming HTTP on ssl passthrough host %v", upstream.Name, server.Hostname) |
There was a problem hiding this comment.
This warning means the same backend is receiving http and https requests from the ingress controller. Any reason to remove it?
There was a problem hiding this comment.
@jcmoraisjr yes, the current code (with the logic to set SSLPassthrough false) break SSLPassthrough.
There was a problem hiding this comment.
@jcmoraisjr this change basically rollback #540
There was a problem hiding this comment.
@jcmoraisjr let me finish the PR and then we can test the haproxy controller.
There was a problem hiding this comment.
@jcmoraisjr we really need to start with the e2e testing to avoid this regressions (this is not the first time)
There was a problem hiding this comment.
No problem. I was only talking about the warning. I think #540 doesn't need to be rolled back, but only revert the logic?
I'll try to run e2e as well before every pr (was assuming Travis was doing it for us).
aledbf
force-pushed
the
refactor-passthrough
branch
from
e2fe336
to
7285372
Compare
aledbf
force-pushed
the
refactor-passthrough
branch
from
1abf036
to
124c91e
Compare
aledbf
force-pushed
the
refactor-passthrough
branch
from
7977364
to
590bc0d
Compare
This takes ideas from https://github.com/kubermatic/k8sniff/
Why? Using nginx for passthrough implies we loose the source IP address
TODO: