Usage

Using the Zone and Record resources.

Once you have completed the installation, you can start building out your Zones and Records, the same way you do all your other Kubernetes Resources.

apiVersion: kubi.zone/v1alpha1
kind: Zone
metadata:
  name: example-org
  namespace: my-namespace
spec:
  domainName: example.org.
  delegations:
  - namespaces: ["my-namespace"]
    records:
    - pattern: "*"

This zone will automatically adopt any Records within its own namespace (my-namespace), so let's create one.

We'll start with our website's main home page:

apiVersion: kubi.zone/v1alpha1
kind: Record
metadata:
  name: www-example-org
  namespace: my-namespace
spec:
  domainName: www.example.org.
  type: A
  rdata: "192.168.0.2"

We're relying on the Kubizone Operator's ability to discern that these two are related based solely on their fully qualified domainNames, and since our zone explicitly allows delegation of any sub-domain record to this namespace, it will be automatically adopted.

Using kubectl get zone -n my-namespace example-org -o yaml should produce something similar to this:

apiVersion: kubi.zone/v1alpha1
kind: Zone
metadata:
  name: example-org
  namespace: my-namespace
spec:
  delegations:
  - namespaces: ["my-namespace"]
    records:
    - pattern: '*.example.org.'
      types: []
    zones: []
  domainName: example.org.
  expire: 3600000
  negativeResponseCache: 360
  refresh: 86400
  retry: 7200
  ttl: 360
status:
  entries:
  - class: IN
    fqdn: www.example.org.
    rdata: 192.168.0.2
    ttl: 360
    type: A
  fqdn: example.org.
  hash: "3820432254183799767"
  serial: 2023110206

The interesting bit is the .status.entries field, which now contains our record! This is the field that the Zonefile Operator or other integrations will use to populate a text representation of the zonefile, push the configuration to a DNS provider, or whatever else they might want.