This is a rewritten fork of TheYkk/synator.
Published to docker at jhaynie/synator
It's better, cleaner, faster, but note that the API has changed.
For example, synator/sync
is a label, not an annotation (this is important for performance).
Sometimes we want to use the same ConfigMaps and Secrets in many namespaces. Synator is a controller which automates the copying and synchronization of secrets and config across namespaces.
Synator uses kopf python framework.
NOTE: This branch is not publicly deployed. You must build the image yourself and specify it in deploy.yml
.
See the 'Build and Deploy' section.
Apply deploy.yml to Kubernetes.
Add label synator/sync=yes
to Secret or ConfigMap.
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: example
labels:
synator/sync: "yes"
data:
tt: dHQONTExMjMONTU=
Optionally add one of these annotations to include or exclude specific destination namespaces from the sync.
Copy secret only to some namespaces:
synator/include-namespaces='namespace1,namespace2'
Exclude particular namespaces:
synator/exclude-namespaces='kube-system,kube-node-lease'
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: example
labels:
synator/sync: "yes"
annotations:
synator/include-namespaces: my-fancy-namespace,my-app
data:
tt: dHOONTExMiMONTU=
When creating a copy of a Secret or ConfigMap, the only metadata that is preserved is labels and annotations excluding
"system" annotations such as last-applied-configuration
, those related to kopf, as well as prefixed with synator/
.
Optionally, the copied labels and annotations can be further restricted.
Include only specific label or annotation prefixes:
metadata:
annotations:
synator/include-labels: app.kubernetes.io/
synator/include-annotations: cert-manager.io/
Exclude specific prefixes:
metadata:
annotations:
synator/exclude-labels: app.kubernetes.io/instance
synator/exclude-annotations: cert-manager.io/issuer
Include and exclude filters can be used together, and are applied in that order.
The label app.kubernetes.io/managed-by=synator
is always set.
Object creation or update is triggered when:
- synator is started (it looks for objects without the
kopf.zalando.org/last-handled-configuration
annotation) - ConfigMap or Secret is created
- ConfigMap or Secret is labelled with
synator/sync='yes'
- ConfigMap or Secret is updated (its essential fields differ from those stored in
kopf.zalando.org/last-handled-configuration
) - A Namespace is created
Object update is not triggered when:
- A child object does not have the label
app.kubernetes.io/managed-by=synator
Object deletion is triggered when:
- The parent object is deleted
Objection deletion is not triggered when:
- The parent object's
synator/sync='yes'
label is removed - The parent object whose
synator/sync='yes'
label has been removed is deleted - A child object has had its
app.kubernetes.io/managed-by=synator
label removed
Synator is usually installed with cluster-wide permissions and watches all namespaces.
The namespaces can be restricted either through kopf
configuration
or by setting the WATCHED_NAMESPACES
environment variable.
WATCHED_NAMESPACES
restricts the source namespaces, while kopf --namespaces
restricts both source and target namespaces.
To configure either, edit deploy.yml.
WATCHED_NAMESPACES=""
will watch for resources across the entire cluster.WATCHED_NAMESPACES="foo,bar"
will watch for resources in the foo and bar namespace.
Build docker image
docker build -t <repository>/synator:<tag> .
Upload docker image
docker push <repository>/synator:<tag> .
Edit deploy.yml with your image path
Apply deploy.yml
kubectl apply -f deploy.yml