sigs.k8s.io/external-dns@v0.14.1/docs/20190708-external-dns-incubator.md (about)

     1  # Move ExternalDNS out of Kubernetes incubator
     2  
     3  <!-- TOC depthFrom:1 depthTo:6 withLinks:1 updateOnSave:1 orderedList:0 -->
     4  
     5  - [Move ExternalDNS out of Kubernetes incubator](#move-externaldns-out-of-kubernetes-sigs)
     6  	- [Summary](#summary)
     7  	- [Motivation](#motivation)
     8  		- [Goals](#goals)
     9  	- [Proposal](#proposal)
    10  	- [Details](#details)
    11  		- [Graduation Criteria](#graduation-criteria)
    12  			- [Maintainers](#maintainers)
    13  		- [Release process, artifacts](#release-process-artifacts)
    14  		- [Risks and Mitigations](#risks-and-mitigations)
    15  
    16  <!-- /TOC -->
    17  
    18  ## Summary
    19  
    20  [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) is a project that synchronizes Kubernetes' Services, Ingresses and other Kubernetes resources to DNS backends for several DNS providers.
    21  
    22  The projects was started as a Kubernetes Incubator project in February 2017 and being the Kubernetes incubation initiative officially over, the maintainers want to propose the project to be moved to the kubernetes GitHub organization or to kubernetes-sigs, under the sponsorship of sig-network.
    23  
    24  ## Motivation
    25  
    26  ExternalDNS started as a community project with the goal of unifying several existing projects that were trying to solve the same problem: create DNS records for Kubernetes resources on several DNS backends.
    27  
    28  When the project was proposed (see the [original discussion](https://github.com/kubernetes/kubernetes/issues/28525#issuecomment-270766227)), there were at least 3 existing implementations of the same functionality:
    29  
    30  * Mate - [https://github.com/linki/mate](https://github.com/linki/mate)
    31  
    32  * DNS-controller from kops - [https://github.com/kubernetes/kops/tree/HEAD/dns-controller](https://github.com/kubernetes/kops/tree/HEAD/dns-controller)
    33  
    34  * Route53-kubernetes - [https://github.com/wearemolecule/route53-kubernetes](https://github.com/wearemolecule/route53-kubernetes)
    35  
    36  ExternalDNS' goal from the beginning was to provide an officially supported solution to those problems.
    37  
    38  After two years of development, the project is still in the kubernetes-sigs.
    39  
    40  The incubation has been officially discontinued and to quote @thockin "Incubator projects should either become real projects in Kubernetes, shut themselves down, or move elsewhere" (see original thread [here](https://groups.google.com/forum/#!topic/kubernetes-sig-network/fvpDC_nxtEM)).
    41  
    42  This KEP proposes to move ExternalDNS to the main Kubernetes organization or kubernetes-sigs. The "Proposal" section details the reasons behind it.
    43  
    44  ### Goals
    45  
    46  The only goal of this KEP is to establish consensus regarding the future of the ExternalDNS project and determine where it belongs.
    47  
    48  ## Proposal
    49  
    50  This KEP is about moving External DNS out of the Kubernetes incubator. This section will cover the reasons why External DNS is useful and what the community would miss in case the project would be discontinued or moved under another organization.
    51  
    52  External DNS...
    53  
    54  * Is the de facto solution to create DNS records for several Kubernetes resources.
    55  
    56  * Is a vital component to achieve an experience close to a PaaS that many Kubernetes users try to replicate on top of Kubernetes, by allowing to automatically create DNS records for web applications.
    57  
    58  * Supports already 18 different DNS providers including all major public clouds (AWS, Azure, GCP).
    59  
    60  Given that the kubernetes-sigs organization will eventually be shut down, the possible alternatives to moving to be an official Kubernetes project are the following:
    61  
    62  * Shut down the project
    63  
    64  * Move the project elsewhere
    65  
    66  We believe that those alternatives would result in a worse outcome for the community compared to moving the project to the any of the other official Kubernetes organizations.
    67  In fact, shutting down ExternalDNS can cause:
    68  
    69  * The community to rebuild the same solution as already happened multiple times before the project was launched. Currently ExternalDNS is easy to be found, referenced in many articles/tutorials and for that reason not exposed to that risk.
    70  
    71  * Existing users of the projects to be left without a future proof working solution.
    72  
    73  Moving the ExternalDNS project outside of Kubernetes projects would cause:
    74  
    75  * Problems (re-)establishing user trust which could eventually lead to fragmentation and duplication.
    76  
    77  * It would be hard to establish in which organization the project should be moved to. The most natural would be Zalando's organization, being the company that put most of the work on the project. While it is possible to assume Zalando's commitment to open-source, that would be a strategic mistake for the project community and for the Kubernetes ecosystem due to the obvious lack of neutrality.
    78  
    79  * Lack of resources to test, lack of issue management via automation.
    80  
    81  For those reasons, we propose to move ExternalDNS out of the Kubernetes incubator, to live either under the kubernetes or kubernetes-sigs organization to keep being a vital part of the Kubernetes ecosystem.
    82  
    83  
    84  ## Details
    85  
    86  ### Graduation Criteria
    87  
    88  ExternalDNS is a two years old project widely used in production by many companies. The implementation for the three major cloud providers (AWS, Azure, GCP) is stable, not changing its logic and the project is being used in production by many company using Kubernetes.
    89  
    90  We have evidence that many companies are using ExternalDNS in production, but it is out of scope for this proposal to collect a comprehensive list of companies.
    91  
    92  The project was quoted by a number of tutorials on the web, including the [official tutorials from AWS](https://aws.amazon.com/blogs/opensource/unified-service-discovery-ecs-kubernetes/).
    93  
    94  ExternalDNS can't be consider to be "done": while the core functionality has been implemented, there is lack of integration testing and structural changes that are needed.
    95  
    96  Those are identified in the project roadmap, which is roughly made of the following items:
    97  
    98  * Decoupling of the providers
    99  
   100      * Implementation proposal
   101  
   102      * Development
   103  
   104  * Bug fixing and performance optimization (i.e. rate limiting on cloud providers)
   105  
   106  * Integration testing suite, to be implemented at least for the "stable" providers
   107  
   108  For those reasons, we consider ExternalDNS to be in Beta state as a project. We believe that once the items mentioned above will be implemented, the project can reach a declared GA status.
   109  
   110  There are a number of other factors that need to be covered to fully describe the state of the project, including who are the maintainers, the way we release and manage the project and so on.
   111  
   112  #### Maintainers
   113  
   114  The project has the following maintainers:
   115  
   116  * hjacobs
   117  
   118  * Raffo
   119  
   120  * linki
   121  
   122  * njuettner
   123  
   124  The list of maintainers shrunk over time as people moved out of the original development team (all the team members were working at Zalando at the time of project creation) and the project required less work.
   125  
   126  The high number of providers contributed to the project pose a maintainability challenge: it is hard to bring the providers forward in terms of functionalities or even test them. The maintainers believe that the plan to transform the current Provider interface from a Go interface to an API will allow for enough decoupling and to hand over the maintenance of those plugins to the contributors themselves, see the risk and mitigations section for further details.
   127  
   128  ### Release process, artifacts
   129  
   130  The project uses the free quota of TravisCI to run tests for the project.
   131  
   132  The release pipeline for the project is currently fully owned by Zalando. It runs on the internal system of the company (closed source) which external maintainers/users can't access and that pushes images to the publicly accessible docker registry available at the URL `registry.opensource.zalan.do`.
   133  
   134  The docker registry service is provided as best effort with no sort of SLA and the maintainers team openly suggests the users to build and maintain their own docker image based on the provided Dockerfiles.
   135  
   136  Providing a vanity URL for the docker images was consider a non goal till now, but the community seems to be wanting official images from a GCR domain, similarly to what is available for other parts of official Kubernetes projects.
   137  
   138  ExternalDNS does not follow a specific release cycle. Releases are made often when there are major contributions (i.e. new providers) or important bug fixes. That said, the default branch is considered stable and can be used as well to build images.
   139  
   140  ### Risks and Mitigations
   141  
   142  The following are risks that were identified:
   143  
   144  * Low number of maintainers: we are currently facing issues keeping up with the number of pull requests and issues giving the low number of maintainers. The list of maintainers already shrunk from 8 maintainers to 4.
   145  
   146  * Issues maintaining community contributed providers: we often lack access to external providers (i.e. InfoBlox, etc.) and this means that we cannot verify the implementations and/or run regression tests that go beyond unit testing.
   147  
   148  * Somewhat low quality of releases due to lack of integration testing.
   149  
   150  We think that the following actions will constitute appropriate mitigations:
   151  
   152  * Decoupling the providers via an API will allow us to resolve the problem of the providers. Being the project already more than 2 years old and given that there are 18 providers implemented, we possess enough information to define an API that we can be stable in a short timeframe. Once this is stable, the problem of testing the providers can be deferred to be a provider's responsibility. This will also reduce the scope of External DNS core code, which means that there will be no need for a further increase of the maintaining team.
   153  
   154  * We added integration testing for the main cloud providers to the roadmap for the 1.0 release to make sure that we cover the mostly used ones. We believe that this item should be tackled independently from the decoupling of providers as it would be capable of generating value independently from the result of the decoupling efforts.
   155  
   156  * With the move to the Kubernetes incubation, we hope that we will be able to access the testing resources of the Kubernetes project. In this way, we hope to decouple the project from the dependency on Zalando's internal CI tool. This will help open up the possibility to increase the visibility on the project from external contributors, which currently would be blocked by the lack of access to the software used for the whole release pipeline.