Skip to content

Openstack LoadBalancer Service can potentially assign floating ip to unrelated resource instead of Neutron load balancer #43909

Closed

Description

@coreypobrien

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): openstack port


Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version): v1.5.1

Environment:

  • Cloud provider or hardware configuration: Openstack
  • OS (e.g. from /etc/os-release): Fedora 24
  • Kernel (e.g. uname -a): 4.9.12-100.fc24.x86_64
  • Install tools:
  • Others:

What happened: When creating a LoadBalancer Service with the Openstack cloud provider, Kubernetes created a Neutron load balancer and floating IP correctly, but assigned the floating ip to an unrelated Nova server instead of assigning it to the load balancer.

What you expected to happen: The floating IP should have been associated with the load balancer

How to reproduce it (as minimally and precisely as possible): Create two different private networks using 10.0.0.0/24. Create a nova server on network 1 with IP 10.0.0.10. Run Kubernetes on network 2. Create a LoadBalancer Service in Kubernetes with the VIP 10.0.0.10. The floating IP will potentially get assigned to the nova server on network 1 instead of the load balancer on network 2.

Anything else we need to know: This appears to be happening because getPortByIP does not filter IPs by network (https://github.com/kubernetes/kubernetes/blob/c077c30/pkg/cloudprovider/providers/openstack/openstack_loadbalancer.go#L82-L108). The result is that a matching IP from an unrelated network may be found when looking for the port for the load balancer by IP (https://github.com/kubernetes/kubernetes/blob/c077c30/pkg/cloudprovider/providers/openstack/openstack_loadbalancer.go#L831-L844).

Activity

  1. xsgordon commented on Apr 1, 2017

    @xsgordon

    /cc @k8s-sig-openstack-bugs

    /cc @idvoretskyi can we get the sig/openstack label on this one please :)

  2. idvoretskyi commented on Apr 19, 2017

    @idvoretskyi
    Member

    cc @kubernetes/sig-openstack-bugs

  3. anguslees commented on Apr 20, 2017

    @anguslees
    Member

    Hrm, you make a good point that getPortByIP doesn't filter by network. I predict we also have a bug in the other uses of this function: updating AllowedAddressPairs in openstack_routes.go.

    Your fix to the LB code lgtm, I'll approve that now - I'd like to keep this issue open to fix openstack_routes.go too (iow: remove getPortByIP entirely - or change it so it can be used correctly)

  4. added a commit that references this issue on Apr 24, 2017
  5. added
    sig/networkCategorizes an issue or PR as relevant to SIG Network.
    and removed
    sig/networkCategorizes an issue or PR as relevant to SIG Network.
    on May 19, 2017
  6. FengyunPan commented on Jul 12, 2017

    @FengyunPan

    @anguslees I think the following way can fix conflict about getPortByIp():
    Add interface of “nova interface-list” for gophercloud's openstack, then use the interface to get port id.
    /# nova interface-list 6589f647-6c06-47e8-aa7e-436678dee8b0
    +------------+--------------------------------------+--------------------------------------+--------------+-------------------+
    | Port State | Port ID | Net ID | IP addresses | MAC Addr |
    +------------+--------------------------------------+--------------------------------------+--------------+-------------------+
    | ACTIVE | 86a8f315-490a-4f4b-8477-728627e7cccd | 22ce08f7-144c-40df-b80c-c9d74ac89daa | 10.0.0.6 | fa:16:3e:53:65:a6 |
    +------------+--------------------------------------+--------------------------------------+--------------+-------------------+

    On the other hand, the kubernetes nodes can't come from different network and have same fixed ip. If exists, the nodes can't work fine, we should return confilct, Do you think so?

  7. added a commit that references this issue on Aug 12, 2017
    a7ce691
  8. added a commit that references this issue on Feb 8, 2018
    f031be0
  9. added 2 commits that reference this issue on Jun 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions