coredns / rfc Goto Github PK

Background

I'm trying to build a plugin that can take action depending on different conditions. For example, the following config will forward dns query to 127.0.0.1:5353 while condition domain_in_file domain_with_local_cdn.txt is satisfied.

policy {
   condition domain_in_file domain_with_local_cdn.txt
   action forward . 127.0.0.1:5353
}

However, I found it's hard to reuse existing plugin forward.

First of all, to support plugin defined config, coredns let plugin to parse config by themself. Such as forward:

func parseForward(c *caddy.Controller) (*Forward, error) {
   var (
      f   *Forward
      err error
      i   int
   )
   for c.Next() {
      if i > 0 {
         return nil, plugin.ErrOnce
      }
      i++
      f, err = parseStanza(c)
      if err != nil {
         return nil, err
      }
   }
   return f, nil
}

This function isn't exported so we can't pass the forward config to build a new forward plugin instance.

Secondly, forward doesn't provide a configurable initialization function:

// New returns a new Forward.
func New() *Forward {
   f := &Forward{maxfails: 2, tlsConfig: new(tls.Config), expire: defaultExpire, p: new(policy.Random), from: ".", hcInterval: hcInterval, opts: options{forceTCP: false, preferUDP: false, hcRecursionDesired: true}}
   return f
}

// SetProxy appends p to the proxy list and starts healthchecking.
func (f *Forward) SetProxy(p *Proxy) {
   f.proxies = append(f.proxies, p)
   p.start(f.hcInterval)
}

No arguments for New() and only SetProxy is supported. So it's harder for other plugins to reuse forward.

Motivation

Embeddable plugin allows the plugin to be reusable.

Proposal

• Export all plugin config parse function or let all plugin implement an interface Parse(*caddy.Controller) (plugin.Handler, error)
• Allow plugins to be initiated without *caddy.Controller

Relate

proxy in fallback

fallback is an external plugin allow redirecting queries to an alternate set of upstreams based on RCODE.

It's reuse proxy via proxy.NewStaticUpstream:

func setup(c *caddy.Controller) error {
   ...

   for c.Next() {
      ..

      u, err := proxy.NewStaticUpstream(&c.Dispenser)
      if err != nil {
         return plugin.Error("fallback", err)
      }

      ...
   }
    ...

   return nil
}

https://github.com/coredns/fallback/blob/master/setup.go

fanout

fanout is an external plugin that parallel proxying DNS messages to upstream resolvers.

Without embed support, they have to implement a dns client by themself:

func (c *client) Request(r *request.Request) (*dns.Msg, error) {
   start := time.Now()
   conn, err := c.transport.Dial(c.net)
   if err != nil {
      return nil, err
   }
   defer func() {
      logErrIfNotNil(conn.Close())
   }()

   logErrIfNotNil(conn.SetWriteDeadline(time.Now().Add(maxTimeout)))
   if err = conn.WriteMsg(r.Req); err != nil {
      logErrIfNotNil(err)
      return nil, err
   }
   logErrIfNotNil(conn.SetReadDeadline(time.Now().Add(readTimeout)))
   var ret *dns.Msg
   for {
      ret, err = conn.ReadMsg()
      if err != nil {
         logErrIfNotNil(err)
         return nil, err
      }
      if r.Req.Id == ret.Id {
         break
      }
   }
   rc, ok := dns.RcodeToString[ret.Rcode]
   if !ok {
      rc = fmt.Sprint(ret.Rcode)
   }
   RequestCount.WithLabelValues(c.addr).Add(1)
   RcodeCount.WithLabelValues(rc, c.addr).Add(1)
   RequestDuration.WithLabelValues(c.addr).Observe(time.Since(start).Seconds())
   return ret, nil
}

https://github.com/networkservicemesh/fanout/blob/master/client.go

kubernetai

kubernetai serves multiple Kubernetes within a Server which is another example for the embeddable plugin.

They don't need to parse kubernetes config anymore:

func Parse(c *caddy.Controller) (*Kubernetai, error) {
   ...

   for c.Next() {
      var k8s *kubernetes.Kubernetes
      k8s, err = kubernetes.ParseStanza(c)
      if err != nil {
         return nil, err
      }
      k8i.Kubernetes = append(k8i.Kubernetes, k8s)
   }

    ...

   return k8i, nil
}

https://github.com/coredns/kubernetai/blob/master/plugin/kubernetai/setup.go

Please Note: This is a tracking issue for CommunityBridge Program Q2 2020. Anyone interested in this implementation should check link there in https://github.com/cncf/mentoring/tree/master/communitybridge/2020/q2

Please Note: This is reserved for CommunityBridge Program Q2 2020, we don't accept PRs outside of CommunityBridge Program Q2 2020, or without coordination with maintainers.

CNCF is participating CommunityBridge Program by Linux Foundation in Q2 2020. See link for more details. As part of CNCF projects, CoreDNS is actively participating in CommunityBridge Program.

Below are the list of candidate CommunityBridge Program Q2 2020:

External health check and orchestration of CoreDNS in Kubernetes clusters

• Description: CoreDNS is the cluster DNS server for Kubernetes and is very much critical for the overall health of the Kubernetes cluster. It is very important to monitoring the health of CoreDNS itself and restarting or repairing any CoreDNS pods that are not behaving correctly. While CoreDNS exposes a health check itself, the health check is not UDP (DNS) based. The existing health check is also launched locally which could be very much different when accessed by other pods remotely.
  This project intends to build an application that checks CoreDNS health through UDP (DNS) externally, and, restart CoreDNS pods by interacting with Kubernetes API through golang. This is an important project that will greatly improve the overall health of Kubernetes clusters through automation.
• Recommended Skills: Go, DNS, Kubernetes
• Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)
• Implementation: The deliverable of this project is a golang program that could be deployed in a Kubernetes cluster independently while at the same time, monitoring CoreDNS pods in the same cluster and interacting Kubernetes API (server) to restart CoreDNS pods as needed.
• Reference: Please see coredns/coredns#3617 for some related discussions.

Please Note: This is a tracking issue for Summer of Code. Anyone interested in this implementation should check link there.

Please Note: This is reserved for Summer of Code, we don't accept PRs outside of Summer of Code, or without coordination with maintainers.

Below are the list of candidate CoreDNS projects for Summer of Code 2020:

External health check and orchestration of CoreDNS in Kubernetes clusters

• Description: CoreDNS is the cluster DNS server for Kubernetes and is very much critical for the overall health of the Kubernetes cluster. It is very important to monitoring the health of CoreDNS itself and restarting or repairing any CoreDNS pods that are not behaving correctly. While CoreDNS exposes a health check itself, the health check is not UDP (DNS) based. The existing health check is also launched locally which could be very much different when accessed by other pods remotely.
  This project intends to build an application that checks CoreDNS health through UDP (DNS) externally, and, restart CoreDNS pods by interacting with Kubernetes API through golang. This is an important project that will greatly improve the overall health of Kubernetes clusters through automation.
• Recommended Skills: Go, DNS, Kubernetes
• Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)
• Implementation: The deliverable of this project is a golang program that could be deployed in a Kubernetes cluster independently while at the same time, monitoring CoreDNS pods in the same cluster and interacting Kubernetes API (server) to restart CoreDNS pods as needed.
• Reference: Please see coredns/coredns#3617 for some related discussions.

Anomaly detection of CoreDNS server through machine learning

• Description: As a DNS server, CoreDNS is critical to overall devops infrastructure. Any anomaly related to CoreDNS server should be taken seriously. While altering rules (combined with monitoring tools such as Prometheus) helps in discovering issues, those rules are often crafted manually and requires human expertise. It would help a lot if machine learning could be utilized to further automate the monitoring/alerting in case of anomaly.
  This project intends to build and train a model that could be used for anomaly detection of CoreDNS server through metrics collected from Prometheus. Since the metrics pipeline to Prometheus is already available in CoreDNS, the project’s focus is mostly on model building. It is suggested to use tf.keras to build the model. A successful model should at least be able to detect a scenario that is alerting and requires further devops or security intervention.
• Recommended Skills: DNS/CoreDNS, Prometheus, Keras/TensorFlow, Python
• Mentor(s): Yong Tang (@yongtang), Paul Greenberg (@greenpau)
• Implementation: The deliverable of this project is a Keras model. The model should be trained and validated through the data collected from Prometheus server (where CoreDNS' metrics are exported).
• Reference: Please see coredns/coredns#3541 for some related discussions.

For anyone who is interested in GSoC, please follow the RFC process set forth in this repo.