kubizone

Introduction

Quick overview of the Kubizone project

Kubizone delivers Kubernetes-native Domain Name System (DNS) primitives such as Records and Zones, and employs an operator to ensure that associations between Records and Zones are kept up to date, and that Zones' Delegation rules are respected.

Purpose

Kubizone aims to be a more flexible and versatile replacement for projects such as external-dns.

Instead of building providers into Kubizone itself like external-dns does, Kubizone instead exposes a very simple interface in the form of Records and Zones, which custom providers in turn can use to update external DNS provider state.

These custom resources makes Kubizone a lot more powerful than external-dns, which by its design is limited to exposing Service and Ingress resources via A and AAAA records, allowing Kubizone to represent all kinds of DNS Records, including but not limited to: SRV, NS, CNAME, and so on.

Overview

By default, Kubizone deploys the following Custom Resources:

  1. Record, represents a single DNS Record entry, A, AAAA, CNAME, what have you.

  2. Zone can be a top-level domain or even a subdomain of another.

  3. ZoneFile is used by the ZoneFile Operator to produce RFC1035-compatible zonefile ConfigMaps which can be used with bind servers such as CoreDNS.

And the following Operators:

  1. Kubizone Operator monitors all Records and Zones cluster-wide, keeping track of associations between them, and enriching them with all the information necessary for downstream providers to maintain external state, such as serials, zone hashes, compiled list of child records, etc.

  2. Zonefile Operator monitors Zonefiles and Zones, compiling them into RFC1035-compatible ConfigMaps which can then either be mounted directly into a CoreDNS (or similar) container and served, or pushed to an external DNS provider.

    This operator also acts as an example of a downstream provider, whose only interaction with the rest of the Kubizone project is as a passive observer of zone changes.

Developing

If you're interested in building a custom provider integration for Kubizone, take a look at the Custom Resources and get to work!

Because of the architecture of Kubizone, your controller doesn't need to coordinate or embed itself in Kubizone to be useful.

Instead, independent providers can simply run -- inside or outside -- of the cluster, watching for zone or record changes, and acting accordingly. In fact, this design allows multiple providers to co-exist, meaning you can easily mirror your entire configuration, allowing you to easily fail over to a secondary authority in case of an outage.

Record →