Option to automatically assign externally managed ELBs to the worker autoscaling group

[pieterlange]

This is useful for operators that have special ELB requirements like the proxyprotocol or where loadbalancer/network asset management is delegated to a different team.

[codecov-io]

Current coverage is 55.66% (diff: 100%)

Merging #93 into master will increase coverage by 0.12%

@@             master        #93   diff @@
==========================================
  Files             4          4          
  Lines          1057       1060     +3   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            587        590     +3   
  Misses          388        388          
  Partials         82         82          

Powered by Codecov. Last update faadb70...b4b1eba

[mumoshu]

@pieterlange I believe this is what everyone(of course including me 😄) can benefit from when one wants to use ELB(s) to proxy or loadbalance requests to specific nodePorts, which might be a very common use-case 👍

IMHO, it is also a fairly common use-case that multiple services to be load-balanced are hosted on a single group of nodes hence it needs to be attached to multiple ELBs.
To support such case, would you mind making it accepts one or more ELB names via a YAML list, instead of just one name?

[pieterlange]

No problem..! Comin' up.

[pieterlange]

May i ask why you wouldn't simply use the type: LoadBalancer in the service for this usecase? :-) That automatically sets up an ELB.

This is really only for the 'odd' setups where you need to manually/externally configure the ELB with some settings that can't be configured from kubernetes itself.

[pieterlange]

Also be aware that updating the loadbalancer names replaces the entire autoscaling group.

[pieterlange]

To use this feature correctly the operator must currently create a manual "glue" securitygroup with inbound rules allowing for every ELB port routed to a nodePort.

It might be more intuitive to actually reference the ELB securitygroup and simply add a new SecurityGroupIngress object allowing blanket access from said ELB to all nodePort (30000 - 32767). At that point it's up to the ELB administrator to route ports from the ELB to the appropriate nodePort

[mumoshu]

@pieterlange Thanks for your effort!

My use-case is #93 (comment) plus a downtime-less kubernetes cluster replacement with less scripting/manual work. I've never considered using type: LoadBalancer for exposing/load-balancing my services because of those two reqs.

I'd like ELBs to survive between multiple recreations of associated kubernetes clusters so that there's no need of manual work/additional scripting like:

• run kube-aws up to bring up the new cluster
• deploy your app and then wait until up
• then modify Route53 recordsets to start routing requests to ELBs created by type: LoadBalancer services in the new kubernetes cluster,
• then run kube-aws destroy the old cluster

instead we can now do:

• run kube-aws up to bring up the new cluster and attach all the preconfigured ELBs to its workers
• deploy your app and then wait until up
• then run kube-aws destroy the old cluster

I even assume this is not very odd but occasionally needed setup 😄

[mumoshu]

@pieterlange Would you mind rebasing this?
It is conflicting too often these days 😭

[pieterlange]

Rebased and alphabetically sorted the Experimental struct while i'm at it to help with conflicts

[mumoshu]

Thanks for rebasing and the good idea 👍