Introducing PowerDNS Operator 🚀
PowerDNS Operator is a Kubernetes operator that bridges the gap between PowerDNS (a self-hosted, open-source DNS server) and cloud-native infrastructure. It allows you to manage DNS zones and records as Kubernetes Custom Resources, enabling declarative DNS management that fits perfectly into your existing GitOps workflows.
Github: https://github.com/powerdns-operator/PowerDNS-Operator
Key Features
- Kubernetes-native - Manage DNS through Custom Resources
- GitOps ready - Version control your DNS configuration
- Multi-tenancy support - Namespace isolation for teams
- Official API integration - Uses PowerDNS's API
- Flexible deployment - PowerDNS can be inside or outside Kubernetes
- Prometheus metrics - Built-in monitoring and observability
- RBAC integration - Fine-grained permissions for different teams
Architecture Overview
The PowerDNS Operator introduces four Custom Resources that enable different levels of DNS management:
- ClusterZone: Cluster-wide DNS zones
- ClusterRRset: Cluster-wide DNS records
- Zone: Namespace-scoped DNS zones
- RRset: Namespace-scoped DNS records
This flexible architecture lets you structure DNS resources to match your organization's needs. For instance, platform teams can establish shared ClusterZones while developers self-manage their application DNS through namespace-scoped RRsets.
Quick Start
Prerequisites: Ensure you have a PowerDNS service operational and accessible from the PowerDNS Operator. The PowerDNS API must be enabled.
1. Install the Operator
# Add the Helm repository
helm repo add powerdns-operator https://powerdns-operator.github.io/PowerDNS-Operator-helm-chart
helm repo update
# Install the operator
helm install powerdns-operator powerdns-operator/powerdns-operator \
--namespace powerdns-operator-system \
--create-namespace \
--set api.url=https://your-powerdns-server:8081 \
--set credentials.data.PDNS_API_KEY=your-api-key
2. Create DNS Resources
ClusterZone (cluster-wide)
apiVersion: dns.cav.enablers.ob/v1alpha2
kind: ClusterZone
metadata:
name: example.org
spec:
kind: Native
nameservers:
- ns1.example.org
- ns2.example.org
Zone (namespace-scoped)
apiVersion: dns.cav.enablers.ob/v1alpha2
kind: Zone
metadata:
name: team-a.example.org
namespace: team-a
spec:
kind: Native
nameservers:
- ns1.example.org
- ns2.example.org
RRset (namespace-scoped)
apiVersion: dns.cav.enablers.ob/v1alpha2
kind: RRset
metadata:
name: api.team-a.example.org
namespace: team-a
spec:
type: A
ttl: 300
records:
- 10.0.1.100
- 10.0.1.101
zoneRef:
name: team-a.example.org
kind: Zone
3. Verify and Test
# Check resources
kubectl get clusterzones,zones,rrsets -o wide -A
# Test DNS resolution
dig @your-resolver api.team-a.example.org +short
Operational Benefits
Team Separation
- Platform team: Manages ClusterZones and infrastructure DNS
- Development teams: Manage their own Zones and RRsets
- RBAC controls: Granular permissions per namespace
GitOps Integration
- Version control: All DNS configuration in Git
- Automated deployments: DNS changes deploy alongside applications
- Rollback capability: Easy to revert DNS changes
How do you manage the lifecycle of your DNS resources? Terraform, Ansible or... Jira?! Share your experiences in the comments below! 👇
Top comments (0)