Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-6207

In-cluster DNS and load balancers on more platforms

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Installer, SDN
    • None

      1. Proposed title of this feature request

      In-cluster DNS and load balancers on more platforms

      2. What is the nature and description of the request?

      https://github.com/openshift/enhancements/pull/1666/files

      Multiple on-prem platform types, including baremetal and openstack, provide in-cluster implementations of network services that are required in order to have a viable stand-alone cluster:

      • CoreDNS for in-cluster DNS resolution
      • haproxy with keepalived to provide in-cluster load balancers (ingress) for the API server and workloads

      Continuing the work from that original enhancement proposal, those services should also be available for optional inclusion when installing a cluster with the external or none platform types, which are likewise often used in environments that lack a suitable alternative for DNS and/or load balancers.

      3. Why does the customer need this? (List the business requirements here)

      Provisioning and configuring a DNS system and load balancers manually for an OpenShift cluster is a substantial burden on the user. In a cloud environment that's not already supported by the OpenShift installer, utilizing the native offerings requires additional work up-front, creates an ongoing maintenance burden, and more monetary cost for infrastructure. And not all cloud environments offer suitable options. On-prem, there may not exist sufficient DNS and/or load balancer services nor additional infrastructure on which to run them.

      Many users end up deploying a cluster with platform type baremetal when all they really want is to use the in-cluster network services. Instead, it should be possible to utilize those in-cluster network services without them being coupled to the baremetal platform type.

      For example, the assisted-installer and the agent based installer are often used to deploy clusters into “generic” environments where there is not an opportunity to utilize an external DNS or load balancer solution. Thus the assisted-installer sets the platform type as baremetal regardless of whether the systems are actually running on bare metal or whether there is any intent to use metal3 integrations. The resulting cluster has all of the appearances of being bare metal, including a BareMetalHost resource for each Node, which can be confusing to users. Even the web console’s Overview landing page shows “Infrastructure provider: BareMetal” in addition to “N Nodes” and “N Bare Metal Hosts”.

      Single Node OpenShift uses platform type none and requires the user to configure DNS records manually. When using the assisted-installer, it configures dnsmasq in new SNO clusters as a convenience. But it would be better for the internal DNS service to be a native part of platform type none so that it is easily available to all users, regardless of how they are installing SNO.

      4. List any affected packages or components.

      • Platform definitions in InstallConfig and related implementations
      • Infrastructure API
      • assisted-installer
      • agent-based-installer

              mcurry@redhat.com Marc Curry
              mhrivnak@redhat.com Michael Hrivnak
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: