Skip to content

Commit 9512cba

Browse files
s3rj1ks3rj1k
committed
Add Valkey on k0rdent blog post
Signed-off-by: s3rj1k <[email protected]>
1 parent 8c8990b commit 9512cba

File tree

1 file changed

+270
-0
lines changed

1 file changed

+270
-0
lines changed

‎content/blog/2025-07-21-valkey-on-k0rdent.md

Lines changed: 270 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,270 @@
1+
+++
2+
title = "Using k0rdent MultiClusterService Template for Valkey on Kubernetes"
3+
description = "Learn how to deploy and manage Valkey across multiple Kubernetes clusters using k0rdent's template-driven approach for simplified multi-cluster application delivery."
4+
date = "2025-07-21 01:01:42"
5+
authors= [ "s3rj1k"]
6+
+++
7+
8+
## Introduction
9+
10+
Managing distributed applications across multiple Kubernetes clusters can be complex and time-consuming. This guide demonstrates how to streamline Valkey deployment using k0rdent's MultiClusterService template, providing a practical example of modern multi-cluster application delivery.
11+
12+
In this tutorial, we'll walk through deploying Valkey (a high-performance Redis alternative) across Kubernetes clusters using k0rdent's template-driven approach. By the end of this guide, the reader will understand how to leverage k0rdent for simplified Valkey deployment and multi-cluster application management.
13+
14+
## Prerequisites
15+
16+
It is assumed that the reader has basic knowledge of:
17+
- Valkey and its use cases
18+
- Kubernetes clusters and core concepts
19+
- Helm charts and package management
20+
21+
The reader will also need the following tools installed:
22+
- Docker (running as a daemon)
23+
- kind CLI
24+
- kubectl CLI
25+
- helm CLI
26+
27+
## The k0* Family
28+
29+
k0rdent is part of the k0* family of tools:
30+
- **[k0s](https://k0sproject.io/)**: Zero Friction Kubernetes Distribution
31+
- **[k0smotron](https://k0smotron.io/)**: k0s specific CAPI providers
32+
- **[k0rdent](https://k0rdent.io/)**: Multi-cluster management platform
33+
34+
## What is k0rdent?
35+
36+
[k0rdent](https://k0rdent.io/) is a Kubernetes-native distributed container management platform that simplifies and automates the deployment, scaling, and lifecycle management of Kubernetes clusters across multi-cloud and hybrid environments using a template-driven approach. The reader can think of it as a super control plane for multiple child clusters that are controlled by different CAPI providers across multi-cloud environments.
37+
38+
All providers (infrastructure, cluster) are packaged as Helm templates and exposed to the consumer via an entry point object called ClusterDeployment. The ClusterDeployment object is what the consumer uses to declaratively define a new child cluster and combined with credentials-related objects, this provides the consumer with a managed Kubernetes cluster on any platform that has existing CAPI providers.
39+
40+
Check out this [CNCF blog post](https://www.cncf.io/blog/2025/02/24/introducing-k0rdent-design-deploy-and-manage-kubernetes-based-idps/) for additional information.
41+
42+
## Service Templates and Application Delivery
43+
44+
For any child cluster under k0rdent management, the consumer can control application delivery via service template objects, meaning that it is possible to install applications into the child clusters and have everything controlled from the super-control-plane (management cluster) where k0rdent itself runs.
45+
46+
The k0rdent project maintains a public repository called the "[Catalog](https://catalog.k0rdent.io/latest/)" where the consumer can find pre-built application service templates. While templates can be created locally, and there is no hard requirement to use the catalog, we'll use the catalog for a more streamlined experience with Valkey delivery to child clusters.
47+
48+
## Demo Setup Overview
49+
50+
In this practical demonstration, we'll:
51+
52+
1. Use KinD for the management cluster
53+
2. Deploy to a child cluster using Cluster API Provider Docker (CAPD)
54+
3. Use Hyperspike's Valkey Operator to manage Valkey instances
55+
56+
**Note:** While we use Docker/KinD for simplicity, k0rdent supports any CAPI provider and can run on any Kubernetes distribution for production deployments.
57+
58+
There is no better way of getting to know something than by doing it, so I encourage the reader to follow along the steps if possible.
59+
60+
## Setting Up the Management Cluster
61+
62+
Let's start by creating a new KinD cluster with a mounted docker socket:
63+
64+
```bash
65+
cat << 'EOF' | kind create cluster --name kind --config=-
66+
kind: Cluster
67+
apiVersion: kind.x-k8s.io/v1alpha4
68+
nodes:
69+
- role: control-plane
70+
extraMounts:
71+
- hostPath: /var/run/docker.sock
72+
containerPath: /var/run/docker.sock
73+
readOnly: false
74+
EOF
75+
```
76+
77+
After KinD CLI is finished with its magic, let's install k0rdent into our new cluster:
78+
79+
```bash
80+
helm install kcm oci://ghcr.io/k0rdent/kcm/charts/kcm --version 1.0.0 -n kcm-system --create-namespace
81+
kubectl wait --for=condition=Ready=True management/kcm --timeout=9000s
82+
```
83+
84+
## Installing the Valkey Service Template
85+
86+
Now we need to install the Valkey service template like this:
87+
88+
```bash
89+
helm install valkey oci://ghcr.io/k0rdent/catalog/charts/valkey-service-template --version 0.1.0 -n kcm-system
90+
kubectl wait --for=jsonpath='{.status.valid}'=true servicetemplate/valkey-0-1-0 -n kcm-system --timeout=600s
91+
```
92+
93+
## Setting Up Credentials
94+
95+
Let's now create a group of credentials-related objects that enable the CAPD provider to work:
96+
97+
```bash
98+
kubectl apply -f - <<EOF
99+
---
100+
apiVersion: v1
101+
kind: Secret
102+
metadata:
103+
name: docker-cluster-secret
104+
namespace: kcm-system
105+
labels:
106+
k0rdent.mirantis.com/component: "kcm"
107+
type: Opaque
108+
109+
---
110+
apiVersion: k0rdent.mirantis.com/v1beta1
111+
kind: Credential
112+
metadata:
113+
name: docker-stub-credential
114+
namespace: kcm-system
115+
spec:
116+
description: Docker Credentials
117+
identityRef:
118+
apiVersion: v1
119+
kind: Secret
120+
name: docker-cluster-secret
121+
namespace: kcm-system
122+
123+
---
124+
apiVersion: v1
125+
kind: ConfigMap
126+
metadata:
127+
name: docker-cluster-credential-resource-template
128+
namespace: kcm-system
129+
labels:
130+
k0rdent.mirantis.com/component: "kcm"
131+
annotations:
132+
projectsveltos.io/template: "true"
133+
EOF
134+
```
135+
136+
## Creating the Child Cluster
137+
138+
Now we are finally ready to create our new child cluster!
139+
140+
Let's do that like this:
141+
142+
```bash
143+
kubectl apply -f - <<EOF
144+
---
145+
apiVersion: k0rdent.mirantis.com/v1beta1
146+
kind: ClusterDeployment
147+
metadata:
148+
name: docker-hosted-cp
149+
namespace: kcm-system
150+
spec:
151+
template: docker-hosted-cp-1-0-0
152+
credential: docker-stub-credential
153+
config:
154+
clusterLabels: {}
155+
clusterAnnotations: {}
156+
EOF
157+
```
158+
159+
Note how we use `docker-hosted-cp-1-0-0` as the template for the new child cluster, this will give us a CAPD-based child cluster in [Hosted Control-Plane](https://docs.k0rdent.io/head/admin/hosted-control-plane/) mode.
160+
161+
Now we wait for the child cluster to be Ready:
162+
163+
```bash
164+
kubectl wait --for=condition=Ready clusterdeployment/docker-hosted-cp -n kcm-system --timeout=600s
165+
kubectl wait --for=jsonpath='{.status.phase}'=Provisioned cluster/docker-hosted-cp -n kcm-system --timeout=600s
166+
kubectl wait --for=condition=Ready dockercluster/docker-hosted-cp -n kcm-system --timeout=600s
167+
kubectl wait --for=jsonpath='{.status.ready}'=true k0smotroncontrolplane/docker-hosted-cp-cp -n kcm-system --timeout=600s
168+
```
169+
170+
## Verifying the Child Cluster
171+
172+
Let's get the child cluster kubeconfig out and check if the cluster itself looks good:
173+
174+
```bash
175+
kubectl -n kcm-system get secret docker-hosted-cp-kubeconfig -o jsonpath='{.data.value}' | base64 -d > docker-hosted-cp.kubeconfig
176+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
177+
```
178+
179+
Now we have almost everything setup for actual Valkey application delivery, we need to setup the storage provider inside our child cluster, let's use `local-path-provisioner` for simplicity:
180+
181+
```bash
182+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
183+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
184+
```
185+
186+
**Note:** We should wait until all Pods in the child cluster are Ready, let's do that interactively, feel free to exit when pods are Ready:
187+
188+
```bash
189+
watch KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
190+
```
191+
192+
## Deploying Valkey Using MultiClusterService
193+
194+
Whew, that was a lot of YAML, but we are finally here, we now can see how easy it is to deploy Valkey into the child cluster!
195+
196+
Let's first add a label to our new child cluster in the management cluster, where k0rdent is running, this label will be "group=demo":
197+
198+
```bash
199+
kubectl label cluster docker-hosted-cp group=demo -n kcm-system
200+
```
201+
202+
This label is needed because we will be using a MultiClusterService object that can reference multiple child clusters for service/application delivery. In our case, we will use our Docker-based cluster, still, we should keep in mind that we are not restricted as to which cluster we deliver new services, it can be a single child cluster or a group of them.
203+
204+
Ok, let's do this!
205+
206+
```bash
207+
kubectl apply -f - <<EOF
208+
apiVersion: k0rdent.mirantis.com/v1alpha1
209+
kind: MultiClusterService
210+
metadata:
211+
name: valkey
212+
spec:
213+
clusterSelector:
214+
matchLabels:
215+
group: demo
216+
serviceSpec:
217+
services:
218+
- template: valkey-0-1-0
219+
name: valkey
220+
namespace: valkey-system
221+
values: |
222+
valkey:
223+
spec:
224+
tls: false # when enabled, needs CertManager (and some configs) inside child-cluster
225+
EOF
226+
```
227+
228+
**Note:** In our case, 'values.valkey.spec' that are exposed inside the template are Valkey Operator Helm Chart values.
229+
230+
## Verifying the Deployment
231+
232+
Let's check the object status, we should see something similar to the example output:
233+
234+
```bash
235+
kubectl get MultiClusterService -A
236+
```
237+
238+
Expected output:
239+
```
240+
NAME SERVICES CLUSTERS AGE
241+
valkey 1/1 1/1 23s
242+
```
243+
244+
Now let's check how things look like inside the child cluster:
245+
246+
```bash
247+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
248+
```
249+
250+
Expected output:
251+
```
252+
NAMESPACE NAME READY STATUS RESTARTS AGE
253+
kube-system coredns-5555f45c94-bf9mb 1/1 Running 0 23m
254+
kube-system konnectivity-agent-tfsr8 1/1 Running 0 21m
255+
kube-system kube-proxy-thx5h 1/1 Running 0 21m
256+
kube-system kube-router-6b7s8 1/1 Running 0 21m
257+
kube-system metrics-server-7778865875-s9hsz 1/1 Running 0 23m
258+
local-path-storage local-path-provisioner-74f9666bc9-5xqlf 1/1 Running 0 16m
259+
projectsveltos sveltos-agent-manager-79df48c686-8l6dk 1/1 Running 0 23m
260+
valkey-system valkey-0 1/1 Running 0 64s
261+
valkey-system valkey-operator-controller-manager-6dc5d6bf57-rbt9x 1/1 Running 0 78s
262+
```
263+
264+
See how application delivery is made very simple by k0rdent, pure magic!
265+
266+
## Conclusion
267+
268+
Feel free to play around with Valkey Operator by leveraging the MultiClusterService object together with additional Helm Chart values and when finished, cleaning up this environment is as simple as deleting the KinD cluster.
269+
270+
This is all for today dear reader, thanks for spending this time with me!

0 commit comments

Comments
 (0)