Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-11519

EgressIPs are not available on the node but OVN assigns PODs to EgressIPs

XMLWordPrintable

    • Moderate
    • No
    • SDN Sprint 234, SDN Sprint 235
    • 2
    • Rejected
    • False
    • Hide

      None

      Show
      None
    • Customer Facing

      Description of problem:

      A number of pods on the same node do not have access to the KUBERNETES_SERVICE_HOST. In the sosreport we see traces of the EgressIPs and OVN seems to assign the PODs to the EgressIPs, even if the EgressIPs are not available on the node. Nothing in the logs shows any issue to allocate IPs to the interface. Cluster runs on machine type m6i.2xlarge, so should be able to assign up to 15 Private IPv4 addresses per interface according to the AWS documentation. The egressip output is saying that all "10.231.27.x" EgressIPs are assigned to the node, whereas "oc get nodes", only shows 1 EgressIP assigned.

      Version-Release number of selected component (if applicable):

      4.12.4

      How reproducible:

      N/A

      Steps to Reproduce:

      N/A

      Actual results:

      None of the EgressIPs seems assigned to the node

      Expected results:

      EgressIPs to be assigned to the node

      Additional info:

      Customer provided some must-gather and sosreport from the node.
      There is no trace that the `cloud-network-config-controller` POD that the IP has been assigned, but the EgressIPs 10.231.27.X are flagged as assigned in the ETCD:

      [vlours@supportshell-1 ~]$ oc get egressip.k8s.ovn.org
NAME                         EGRESSIPS                                ASSIGNED NODE                                                                                                                                       ASSIGNED EGRESSIPS
tenant-igs                   10.231.25.2 10.231.27.2 10.231.29.2      ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-24-191.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal   10.231.27.2 10.231.25.2 10.231.29.2
tenant-iom                   10.231.25.3 10.231.27.3 10.231.29.3      ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-24-191.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal   10.231.27.3 10.231.25.3 10.231.29.3
tenant-mnaasapigateway       10.231.25.5 10.231.27.5 10.231.29.5      ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal                                                    10.231.27.5 10.231.29.5
tenant-mnaasportalservices   10.231.25.1 10.231.27.1 10.231.29.1      ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-24-191.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal   10.231.27.1 10.231.25.1 10.231.29.1
tenant-platform              10.231.25.16 10.231.27.16 10.231.29.16   ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-24-191.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal   10.231.27.16 10.231.25.16 10.231.29.16
tenant-sdwan                 10.231.25.4 10.231.27.4 10.231.29.4      ip-10-231-26-206.ap-southeast-2.compute.internal ip-10-231-24-191.ap-southeast-2.compute.internal ip-10-231-28-25.ap-southeast-2.compute.internal   10.231.27.4 10.231.25.4 10.231.29.4
[vlours@supportshell-1 ~]$ oc get CloudPrivateIPConfig -o wide
NAME           AGE
10.231.25.1    2d
10.231.25.16   2d
10.231.25.2    2d
10.231.25.3    2d
10.231.25.4    2d
10.231.25.5    116d
10.231.27.5    2d
10.231.29.1    2d
10.231.29.16   2d
10.231.29.2    2d
10.231.29.3    2d
10.231.29.4    2d
10.231.29.5    2d

       

            ffernand@redhat.com Flavio Fernandes (Inactive)
            rhn-support-avanwoen AJ van Woensel
            Jean Chen Jean Chen
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: