Uploaded image for project: 'OpenShift Installer'
  1. OpenShift Installer
  2. CORS-1874

Allow customer managed DNS solutions: Enhancement Proposal

XMLWordPrintable

    • Allow customer managed DNS solutions: Implementation
    • False
    • True
    • Yellow
    • In Progress
    • OCPSTRAT-990 - [GA] Allow customer managed DNS solutions for GCP: Implementation
    • OCPSTRAT-990[GA] Allow customer managed DNS solutions for GCP: Implementation
    • 95
    • 95% 95%
    • Hide

      20/Nov/2023

      Status: Yellow 

      Reviewers are in agreement that the Infrastructure CR is best suited to contain the LB IPs but are in disagreement about how and if Installer should be the component responsible for putting them there. So, side stepping this debate by adding a configmap that contains the LB IPs. Installer appends this configmap to ignition. This seems to be the solution that is acceptable to Installer reviewers but not for others. Path to tech preview should include a way to add the LB IPs to the Infrastructure CR.

      We are continuing to make progress with implementation with the configmap.

      02/Nov/2023

      This latest design, which is heavily based on the approach proposed in 4.13 has agreement from Installer and MS.
      With parallel effort to remove dependency on terraform for the AWS platform code in Installer, this effort has shifted focus to GCP and Azure platforms. (Installer implementation for AWS is now put on hold in 4.15 and will be added in a future release.)
      Enhancement, API changes and Installer GCP updates are all actively being reviewed. 
      Custom DNS would be tech preview in 4.15.
      MCO implementation and testing is in progress.

      09/Aug/2023

      Based on further review from staff engineers and MS, we are leaning towards the solution proposed during 4.13. This solution involves OpenShift continuing to create & program the LBs for API, API-Int and Ingress. OpenShift also self-hosts its DNS using a CoreDNS pod. Programming the customer's DNS would be a post-install step. This works well in both IPI and managed services environments. 

      04/Aug/2023

      Design with annotations is complete for AWS, Azure and GCP.  This approach does not run an in-cluster CoreDNS pod but expects the user to create A records in their DNS with static IPs for API, API-Int and Ingress LB. Awaiting feedback on that. Reworking implementation to match this design.

      31/Jul/2023

      I have been asked to redesign the Ingress part of the Custom DNS solution as of July 25th. I updated the Enhancement proposal to add the new design that does not use CoreDNS pods for Ingress DNS resolution. The new design attempts to use a variety of annotations on the LB service to achieve pre-creation of Ingress LB. Enhancement proposal today has information about possible annotations for all 3 platforms (AWS, Azure and GCP). It is up to Patrick and / or staff engineer to pick a solution for Ingress that I can go implement. If just 2460 merges, then the customer would be able to use Custom DNS for API and API-Int. It can be added as TechPreview to make customer aware that another part of the solution is expected (soon).

      28/April/2023
      Sandhya: Green for the enhancement proposal and spike, Yellow for the entire feature for 4.14
      Working on the new enhancement proposal, Can clean up old stories and add new ones for estimation next week
      Can divide work into Installer changes and MCO changes. Green for Installer changes in 4.14, Yellow for MCO changes for 4.14

      Show
      20/Nov/2023 Status:  Yellow   Reviewers are in agreement that the Infrastructure CR is best suited to contain the LB IPs but are in disagreement about how and if Installer should be the component responsible for putting them there. So, side stepping this debate by adding a configmap that contains the LB IPs. Installer appends this configmap to ignition. This seems to be the solution that is acceptable to Installer reviewers but not for others. Path to tech preview should include a way to add the LB IPs to the Infrastructure CR. We are continuing to make progress with implementation with the configmap. 02/Nov/2023 This latest design, which is heavily based on the approach proposed in 4.13 has agreement from Installer and MS. With parallel effort to remove dependency on terraform for the AWS platform code in Installer, this effort has shifted focus to GCP and Azure platforms. (Installer implementation for AWS is now put on hold in 4.15 and will be added in a future release.) Enhancement, API changes and Installer GCP updates are all actively being reviewed.  Custom DNS would be tech preview in 4.15. MCO implementation and testing is in progress. 09/Aug/2023 Based on further review from staff engineers and MS, we are leaning towards the solution proposed during 4.13. This solution involves OpenShift continuing to create & program the LBs for API, API-Int and Ingress. OpenShift also self-hosts its DNS using a CoreDNS pod. Programming the customer's DNS would be a post-install step. This works well in both IPI and managed services environments.  04/Aug/2023 Design with annotations is complete for AWS, Azure and GCP.  This approach does not run an in-cluster CoreDNS pod but expects the user to create A records in their DNS with static IPs for API, API-Int and Ingress LB. Awaiting feedback on that. Reworking implementation to match this design. 31/Jul/2023 I have been asked to redesign the Ingress part of the Custom DNS solution as of July 25th. I updated the Enhancement proposal to add the new design that does not use CoreDNS pods for Ingress DNS resolution. The new design attempts to use a variety of annotations on the LB service to achieve pre-creation of Ingress LB. Enhancement proposal today has information about possible annotations for all 3 platforms (AWS, Azure and GCP). It is up to Patrick and / or staff engineer to pick a solution for Ingress that I can go implement. If just 2460 merges, then the customer would be able to use Custom DNS for API and API-Int. It can be added as TechPreview to make customer aware that another part of the solution is expected (soon). 28/April/2023 Sandhya: Green for the enhancement proposal and spike, Yellow for the entire feature for 4.14 Working on the new enhancement proposal, Can clean up old stories and add new ones for estimation next week Can divide work into Installer changes and MCO changes. Green for Installer changes in 4.14, Yellow for MCO changes for 4.14

      The definition of done of this epic is limited to the enhancement proposal merging. The rest of the epic is split into 3 further epics - see links below

      Goal:

      As an administrator, I would like to use my own managed DNS solution instead of only specific openshift-install supported DNS services (such as AWS Route53, Google Cloud DNS, etc...) for my OpenShift deployment.

       

      Problem:

      While cloud-based DNS services provide convenient hostname management, there's a number of regulatory (ITAR) and operational constraints customers face prohibiting the use of those DNS hosting services on public cloud providers.

       

      Why is this important:

      • Provides customers with the flexibility to leverage their own custom managed ingress DNS solutions already in use within their organizations.
      • Required for regions like AWS GovCloud in which many customers may not be able to use the Route53 service (only for commercial customers) for both internal or ingress DNS.
      • OpenShift managed internal DNS solution ensures cluster operation and nothing breaks during updates.

       

      Dependencies (internal and external):

       

      Prioritized epics + deliverables (in scope / not in scope):

      • Ability to bootstrap cluster without an OpenShift managed internal DNS service running yet
      • Scalable, cluster (internal) DNS solution that’s not dependent on the operation of the control plane (in case it goes down)
      • Ability to automatically propagate DNS record updates to all nodes running the DNS service within the cluster
      • Option for connecting cluster to customers ingress DNS solution already in place within their organization

       

      Estimate (XS, S, M, L, XL, XXL):

       

      Previous Work:

       

      Open questions:

       

      Link to Epic: https://docs.google.com/document/d/1OBrfC4x81PHhpPrC5SEjixzg4eBnnxCZDr-5h3yF2QI/edit?usp=sharing

            sdasu@redhat.com Sandhya Dasu
            mak.redhat.com Marcos Entenza Garcia
            Yunfei Jiang Yunfei Jiang
            Votes:
            1 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated: