kubizone

Introduction

Quick overview of the Kubizone project

Kubizone delivers Kubernetes-native Domain Name System (DNS) primitives such as Records & Zones, and employs an Operator to condense relationships and delegations between these into easy-to-process arrays of records, which can be easily pushed to whichever DNS provider(s) you use.

Purpose

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

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

These custom resources makes Kubizone both a lot simpler and a lot more powerful. Since records are created directly, instead of via annotations on existing Service and Ingress objects, they aren't limited to A and AAAA records, but can represent the entire spectrum of possible record types.

Overview

By default, Kubizone deploys the following Custom Resources:

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

  2. Zones are collections of records, and can either be apex domains or subdomains.

  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, please read the section on Integrating and take a look at the Custom Resources as well as the example route53 integration written in bash.

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.

Route53 (example) →