We currently have coupled creation of LB with the creation of a k8s service.
i feel we should have kept them as separate concepts.
Your suggestion would tighten the coupling between LBs and k8 services.

An alternative would be to go down a path of creating a separate object for LBs (Ingress or something else) that can map to a service, instead of tightening this coupling.

We might want to do that (I like the idea, but it's Yet Another Step), but
no matter what we HAVE this coupling right now and it is too opaque.

On Wed, Dec 9, 2015 at 11:27 AM, Abhi Shah notifications@github.com wrote:

We currently have coupled creation of LB with the creation of a k8s
service.
i feel we should have kept them as separate concepts.
Your suggestion would tighten the coupling between LBs and k8 services.

An alternative would be to go down a path of creating a separate object
for LBs (Ingress or something else) that can map to a service, instead of
tightening this coupling.

—
Reply to this email directly or view it on GitHub
#18451 (comment)
.

@kubernetes/sig-network-misc

I'm not sure what more we would want to do. We could include a "provider id" field for the load balancer, but in practice at least on AWS it doesn't gain us a lot - the DNS name itself is a better identifier.

Here is where we are today on AWS:

> k get services -owide
NAME           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)          AGE       SELECTOR
guestbook      100.64.32.128    ad55bee634ee011e7b89102561e08ab5-168463352.us-west-2.elb.amazonaws.com   3000:32664/TCP   4m        app=guestbook
...

> k get service guestbook -oyaml
...
status:
  loadBalancer:
    ingress:
    - hostname: ad55bee634ee011e7b89102561e08ab5-168463352.us-west-2.elb.amazonaws.com

ad55bee634ee011e7b89102561e08ab5 is the name of the AWS load balancer.

> aws elb describe-load-balancers
...
             "DNSName": "abe7f60d14e5611e797370a9aefe8be7-637046823.us-east-1.elb.amazonaws.com",
            "SecurityGroups": [
                "sg-6e76971f"
            ],
            "Policies": {
                "LBCookieStickinessPolicies": [],
                "AppCookieStickinessPolicies": [],
                "OtherPolicies": [
                    "k8s-proxyprotocol-enabled"
                ]
            },
            "LoadBalancerName": "abe7f60d14e5611e797370a9aefe8be7",

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Dup of #52670 which has more details