IKO Plus: Multi-Cluster IrisClusters Propagated with Karmada
.png)
Kamino for IrisClusters
If you are in the business of building robust High Availability, Disaster Recovery, or simply stamping out multiple environments rapidly and consistently, Karmada may just be the engine powering your Cloning Facility.
I lost the clone war with KubeAdmiral but won the pod race with Karmada and want to pay it forward. This is a multi-cluster solution for Day 0 provisioning and Day 1 management of Kubernetes objects, IrisCluster included.
The Star Wars Analogy (Required)
Boba Fett’s genetics were prepared on Kamino, triggering numerous clones deployed across the galaxy—Endor, Tatooine, even the Death Star. Each clone evolved on its own but retained the base genetic footprint. This is the essence of Karmada: deploying resources to meet HA/DR, stretched, or purposeful environments with a single declaration.
Practical Use Case: Multi-Cluster Secrets
If you’re a “Kubehead” and manually sync secrets like this:
kubectl --context source get secret shhhh-secret -o yaml | kubectl --context target apply -f -
Karmada automates this across your entire fleet.
The Goal
Provision a pair of clusters, configure Karmada on one (ikofett), and join the second (ikoclone) to the control plane. We will then provision an IrisCluster on the Karmada control plane and propagate it to the member cluster, followed by a third stretched cluster on GCP.
Step 1: Provision Clusters
Create two clusters in Kind and install the Cilium CNI.
clusters.sh
cat <<EOF | kind create cluster --name ikofett --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
networking:
disableDefaultCNI: true
EOF
cat <<EOF | kind create cluster --name ikoclone --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
networking:
disableDefaultCNI: true
EOF
kind get kubeconfig --name ikoclone > ikoclone.kubeconfig
kind get kubeconfig --name ikofett > ikofett.kubeconfig
# Install Cilium
KUBECONFIGS=("ikoclone.kubeconfig" "ikofett.kubeconfig")
for cfg in "${KUBECONFIGS[@]}"; do
cilium install --version v1.18.0 --kubeconfig "$cfg"
done
Install IKO
IKO must exist on all clusters to handle the IrisCluster CRD.
for cfg in "${KUBECONFIGS[@]}"; do
helm install iko iris-operator/ --kubeconfig "$cfg"
done
Step 2: Install Karmada
Deploy Karmada via Helm on the ikofett cluster.
helm repo add karmada-charts https://raw.githubusercontent.com/karmada-io/karmada/master/charts
helm --namespace karmada-system upgrade -i karmada karmada-charts/karmada --version=1.15 --create-namespace --kubeconfig ikofett.kubeconfig
.png)
Important: Networking & Kubeconfigs
You now have 3 kubeconfigs: ikofett, ikoclone, and the newly generated ikokamino for the Karmada API.
.png)
Step 3: Join Cluster & Prep CRDs
Join the ikoclone cluster to the Karmada control plane and install the IrisCluster CRD into the Karmada API.
# Export CRDs from member to Karmada control plane
kubectl --kubeconfig ikofett.kubeconfig get crd irisclusters.intersystems.com -o yaml > ikocrds.yaml
kubectl create -f ikocrds.yaml --kubeconfig ikokamino.kubeconfig
# Join the clone
kubectl karmada --kubeconfig ikokamino.kubeconfig join ikoclone --cluster-kubeconfig=ikoclone.kubeconfig
.png)
Step 4: Propagate IrisCluster
1. The Template (DNA)
Deploy the IrisCluster to Karmada. This stores the definition but doesn’t deploy a workload yet.
federated-iris.yaml
apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
name: federated-iris
spec:
topology:
data:
image: containers.intersystems.com/intersystems/iris-community:2025.1
serviceTemplate:
spec:
type: LoadBalancer
.png)
2. The Propagation Policy
Tell Karmada where to send the “clone.”
policy.yaml
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: iriscluster-propagate
spec:
resourceSelectors:
- apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
placement:
clusterAffinity:
clusterNames:
- ikoclone
.png)
On the ikoclone cluster, the IrisCluster spins up automatically!
.png)
Joining the Galaxy (GCP)
We can now join our stretched GCP cluster (from this post) and update the policy to deploy there too.
.png)
Update the PropagationPolicy to include the GCP cluster:
.png)
🎉 Now you have another clone out on GCP!
.png)
Advanced Features to Explore:
- Overrides on resources per joined cluster
- Networking integration with Submariner
- PUSH vs PULL configuration models
Related Reading: