I discussed your questions with Miek and Michael. Please see below.
For example, what is its interface to systems providing discovery/naming
data? Can new sources be added without modification to CoreDNS?
CoreDNS provide a middleware architecture that enables access to different data sources just by changing or adding to the configuration file. Today, Kubernetes, etcd, and files are supported.
New data sources can be added by implementing a CoreDNS middleware component. All middleware components implement a well-defined middleware plugin interface. The middleware components are compiled into the CoreDNS binary. Interfaces exist to separate the CoreDNS engine from the middleware implementations. However, middleware components are not dynamically discovered at runtime.
CoreDNS currently does need to be modified for each new middleware. Ultimately these modifications are:
• registration of the middleware with CoreDNS (this is the stuff to setup config file parsing).
• statically compiled binary — all middleware are currently statically linked in the CoreDNS binary.
Why is CoreDNS embedded in a webserver? How hard would it be to link against
Caddy without patching it, which seems like a fragile way to avoid forking?
How hard would it be to eliminate the Caddy dependency entirely?
CoreDNS is not embedded in a web server. The Caddy project started as a composition-based web server implementation. However, Caddy has evolved to be a framework intended to be used to implement arbitrary stateless request/response protocols such as HTTP and DNS. CoreDNS is one of the first projects that leverage the newly generalized Caddy framework.
CoreDNS previously existed as a fork of Caddy reusing a large part of the Caddy middleware management and invocation functionality. Now that the Caddy project has generalized the middleware management and invocation mechanisms it is preferable to utilize Caddy as runtime framework. Caddy is simply another go dependency for CoreDNS, although removing that dependency is not feasible.
On Thu, Aug 25, 2016 at 2:37 AM, Jonathan Boulle via cncf-toc
Fellow TOC members:
The CoreDNS team has iterated on their project proposal to a final version
after feedback and it's now time to vote.
Proposal is available here and also embedded below.
To kick things off, here's my +1.
Name of project: CoreDNS
CoreDNS is a fast, flexible and modern DNS server. Its performant and
flexible implementation allows CoreDNS to be easily extended to support
various data sources and to implement rich DNS service behaviors: for
example, response caching, query rewrite, load-balancing, zone transfer and
signing. CoreDNS is the successor of SkyDNS
(https://github.com/skynetservices/skydns), a DNS server that uses etcd as
its datastore backend. SkyDNS is widely used in cloud deployments, but lacks
the flexibility we envision for CoreDNS.
Sponsor / Advisor from TOC: Jonathan Boulle
Unique Identifier: coredns
License: Apache License v2.0
Source control repositories: https://github.com/miekg/coredns
Miek Gieben github: miekg
Michael Richmond github: mrichmon
Felix Cantournet github: fcantournet
Matt Layher github: mdlayher
Vasily Vailyev github: pixelbender
Infrastructure requirements (CI / CNCF Cluster): N/A
Issue tracker: https://github.com/miekg/coredns
Release methodology and mechanics: As a young project, no method for
official releases has been established, and no official releases have been
made; the current rule is that the master branch is production-ready at all
times. A more formal release process is on its way, and may introduce
semantic versioning, but a final decision has not yet been made. Precompiled
binaries will be distributed by hooking into Caddy’s download website
(https://caddyserver.com/download), where "DNS" will be a Server Type
Social media accounts: Twitter: @corednsio
Existing sponsorship: Infoblox contributing developer time to implement
CoreDNS→Kubernetes integration component.
Existing community: The community is small, but growing. Current number of
Twitter followers is 100+ (after a week of having the Twitter account). By
aligning ourselves with the Caddy community, we hope to leverage Caddy’s
popularity for CoreDNS. By positioning CoreDNS as a better SkyDNS, we hope
to entice existing users of SkyDNS to migrate to and embrace CoreDNS.
CoreDNS depends on Caddy (https://caddyserver.com/). Caddy is a framework
that CoreDNS uses in two ways:
much of the CoreDNS code plugs into the framework to add DNS behavior.
CoreDNS provides a wrapper around the framework to provide a DNS-tuned
Go package: mholt/caddy (ASLV2
Go package: beorn7/perks (MIT
Go package: coreos/etcd (ASLv2
Go package: flynn/go-shlex (ASLv2
Go package: fsnotify/fsnotify (BSD
Go package: golang/protobuf (BSD
Go package: hashicorp/go-syslog (MIT
Go package: matttproud/golang_protobuf_extensions
Go package: miekg/dns (BSD
Go package: patrickmn/go-cache (MIT
Go package: prometheus/client_golang
Go package: prometheus/client_model
Go package: prometheus/common (ASLv2
Go package: prometheus/procfs (ASLv2
Go package: ugorji/go (MIT
Go package: xenolf/lego (MIT
Go package: golang/x/crypto (BSD
Go package: golang/x/net (BSD
Go package: golang/x/sys (BSD
Go package: natefinch/lumberjack.v2 (MIT
Go package: square/go-jose.v1 (ASLv2
Kubernetes (for CoreDNS → Kubernetes integration)
Statement on alignment with CNCF mission:
CoreDNS is a focused, lightweight DNS server. A microservice philosophy
guides the internal design of CoreDNS. Individual DNS functions are provided
by discrete, composable plugins that are enabled via runtime configuration.
CoreDNS can be thought of as a DNS protocol head that can be configured to
front various backend data sources. A flexible DNS server is a necessary
component to provide “Naming and Discovery” services to containers running
in the CNCF distributed system services environment.
Comparison with KubeDNS:
The incumbent DNS service for Kubernetes, “kubedns”, consists of four
components: * etcd provides a DNS data cache, * kube2sky provides the
mechanism for updating the etcd data cache, * skydns provides the DNS
service based on the data cached in etcd, * exechealthz provides
Running CoreDNS with Kubernetes requires only the coredns component.
CoreDNS does not require a separate data cache or update service. CoreDNS
includes an optional health-check “middleware” component that can be used
for service monitoring.
CoreDNS provides a cleaner, more extensible codebase as compared to
SkyDNS. (Both SkyDNS and CoreDNS were authored primarily by Miek Gieben.)
CoreDNS is currently being extended to operate directly with Kubernetes to
access the service data. This “middleware” implementation for CoreDNS
provides the same client-facing behavior as KubeDNS. The pipeline-based
design of CoreDNS allows easy extension to use any container orchestrator as
a DNS data source.
With the Kubernetes middleware, CoreDNS can be considered as an
alternative to SkyDNS with lower runtime complexity. Performance testing to
compare against SkyDNS is pending.
cncf-toc mailing list
cncf-toc mailing list
cncf-toc mailing list