• k8s-merge-robot's avatar
    Merge pull request #24569 from williamsandrew/elb-proxy-protocol · 52cc96d5
    k8s-merge-robot authored
    Automatic merge from submit-queue
    
    AWS: ELB proxy protocol support via annotation service.beta.kubernetes.io/aws-load-balancer-proxy-protocol
    
    This is a ~~work in progress~~ branch 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:
    
    1) 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.
    
    2) 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 ...
    
    ```
    {
      "service.beta.kubernetes.io/aws-load-balancer-proxy-protocol": "tcp:80,tcp:443"
    }
    ```
    
    3) I avoided this because I was concerned with scope creep and our organization doesn’t need it, but could/should our implementation be adjusted to just handle ELB policies in general? I hadn’t used the ELB API until I started working on this branch so I don’t know how realistic this is. I also don't know how common this use case is as our organization has used our own load balancing setup prior to Kubernetes. This page has a couple of examples at the bottom: http://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-policy.html
    
    cc @justinsb
    
    <!-- Reviewable:start -->
    ---
    This change is [<img src="http://reviewable.k8s.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](http://reviewable.k8s.io/reviews/kubernetes/kubernetes/24569)
    <!-- Reviewable:end -->
    52cc96d5
Name
Last commit
Last update
.github Loading commit data...
Godeps Loading commit data...
api/swagger-spec Loading commit data...
build Loading commit data...
cluster Loading commit data...
cmd Loading commit data...
contrib Loading commit data...
docs Loading commit data...
examples Loading commit data...
federation Loading commit data...
hack Loading commit data...
hooks Loading commit data...
logo Loading commit data...
pkg Loading commit data...
plugin Loading commit data...
release Loading commit data...
test Loading commit data...
third_party Loading commit data...
vendor Loading commit data...
www Loading commit data...
.generated_docs Loading commit data...
.gitignore Loading commit data...
.travis.yml Loading commit data...
CHANGELOG.md Loading commit data...
CONTRIB.md Loading commit data...
CONTRIBUTING.md Loading commit data...
DESIGN.md Loading commit data...
LICENSE Loading commit data...
Makefile Loading commit data...
README.md Loading commit data...
Vagrantfile Loading commit data...
code-of-conduct.md Loading commit data...