-
Notifications
You must be signed in to change notification settings - Fork 40k
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
AWS: ELB proxy protocol support via annotation service.beta.kubernetes.io/aws-load-balancer-proxy-protocol #24569
Conversation
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
2 similar comments
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
About to look at the code, but I thought I would tackle your questions first. My viewpoints (and I emphasize that these only my opinion):
|
@@ -2218,7 +2231,15 @@ func (s *AWSCloud) EnsureLoadBalancer(apiService *api.Service, hosts []string, a | |||
} | |||
|
|||
// Build the load balancer itself | |||
loadBalancer, err := s.ensureLoadBalancer(serviceName, loadBalancerName, listeners, subnetIDs, securityGroupIDs, internalELB) | |||
loadBalancer, err := s.ensureLoadBalancer( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... probably time we did this, or thought about creating a structure for the values. This is good anyway :-)
Overall this looks really good. I agree that we should DRY the listener policy logic, and I think lazy creation of the policy would be better. Let me know if you disagree, or if you hit any snags with that and I'd be happy to take a look. But I think the big picture is spot-on. |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
ok to test |
0335ee9
to
73135b2
Compare
We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm. |
73135b2
to
6c7ec06
Compare
CLAs look good, thanks! |
Thanks @justinsb. Will I need to squash before we merge into HEAD? EDIT: Just saw your comment in Slack. I'll squash for cleanliness |
I believe so @williamsandrew - would you mind squashing and I'll re-LGTM |
57780d9
to
d718f39
Compare
Squashed and re-pushed |
@williamsandrew this is failing because of a concurrent merge that went in, that changed the signature of EnsureLoadBalancer, removing the annotations argument. Git didn't detect it as a merge conflict though. I believe this diff is sufficient:
Any chance you can apply this (or something similar), squash and repush? |
Add ELB proxy protocol support via the annotation "service.beta.kubernetes.io/aws-load-balancer-proxy-protocol". This allows servers like Nginx and Haproxy to retrieve the real IP address of a remote client.
d718f39
to
01d9cdd
Compare
Re-adding LGTM after rebase |
1 similar comment
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 01d9cdd. |
Automatic merge from submit-queue |
Has there been any work to make this feature work with specific ports only? I'd love to use this with DEIS Workflow, but can't because it forwards ports to multiple services from an ELB load balancer, but only http and https should use proxy protocol. |
I haven't done any work on it, not sure if anyone else has. I changed jobs and my new team doesn't use Kubernetes (yet). I've considered working on this for a weekend project though. I think it should be pretty straight forward to fix. |
@felixbuenemann The SSL annotations support that, so maybe you can look at their code to see how it does things. I wrote it, but it's more than two weeks since, so I don't remember anything. :-) |
cc @kubernetes/sig-federation-misc |
This is a
work in progressbranch that adds support for the Proxy Protocol with Elastic Load Balancers. The proxy protocol is documented here: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt. It allows us to pass the "real ip" address of a client to pods behind services.As it stands now, we create an ELB policy on the load balancer that enables the proxy protocol. We then enumerate each node port assigned to the load balancer and add our newly created policy to it. The manual process is documented here: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html
Right now, I’m looking to get some feedback on the approach before I dive too much deeper in the code. More precisely, I have questions regarding the following:
Right now I just check that a certain annotation exists on the service regardless of what its value is. Assuming we’re going to enable this feature via an annotation, what is the expected experience? This decision likely depends on the answers to the next questions.
Right now the implementation enables the proxy protocol on every ELB backend. The actual ELB API expects you to add the policy for each configured backend. Do we want the ability to configure the proxy protocol on a per service port basis? For example, if a service exposes TCP 80 and 443, would we want the ability to only enable the proxy protocol on port 443? Does this overcomplicate the implementation? If we wanted to go this direction we could do something like ...
cc @justinsb
This change is