Skip to content

Commit 2464395

Browse files
s3rj1ks3rj1k
committed
Add Valkey on k0rdent blog post
Signed-off-by: s3rj1k <evasive.gyron@gmail.com>
1 parent 8c8990b commit 2464395

File tree

1 file changed

+274
-0
lines changed

1 file changed

+274
-0
lines changed

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

Lines changed: 274 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,274 @@
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+
*... a few moments later ...*
85+
86+
## Installing the Valkey Service Template
87+
88+
Now we need to install the Valkey service template like this:
89+
90+
```bash
91+
helm install valkey oci://ghcr.io/k0rdent/catalog/charts/valkey-service-template --version 0.1.0 -n kcm-system
92+
kubectl wait --for=jsonpath='{.status.valid}'=true servicetemplate/valkey-0-1-0 -n kcm-system --timeout=600s
93+
```
94+
95+
## Setting Up Credentials
96+
97+
Let's now create a group of credentials-related objects that enable the CAPD provider to work:
98+
99+
```bash
100+
kubectl apply -f - <<EOF
101+
---
102+
apiVersion: v1
103+
kind: Secret
104+
metadata:
105+
name: docker-cluster-secret
106+
namespace: kcm-system
107+
labels:
108+
k0rdent.mirantis.com/component: "kcm"
109+
type: Opaque
110+
111+
---
112+
apiVersion: k0rdent.mirantis.com/v1beta1
113+
kind: Credential
114+
metadata:
115+
name: docker-stub-credential
116+
namespace: kcm-system
117+
spec:
118+
description: Docker Credentials
119+
identityRef:
120+
apiVersion: v1
121+
kind: Secret
122+
name: docker-cluster-secret
123+
namespace: kcm-system
124+
125+
---
126+
apiVersion: v1
127+
kind: ConfigMap
128+
metadata:
129+
name: docker-cluster-credential-resource-template
130+
namespace: kcm-system
131+
labels:
132+
k0rdent.mirantis.com/component: "kcm"
133+
annotations:
134+
projectsveltos.io/template: "true"
135+
EOF
136+
```
137+
138+
## Creating the Child Cluster
139+
140+
Now we are finally ready to create our new child cluster!
141+
142+
Let's do that like this:
143+
144+
```bash
145+
kubectl apply -f - <<EOF
146+
---
147+
apiVersion: k0rdent.mirantis.com/v1beta1
148+
kind: ClusterDeployment
149+
metadata:
150+
name: docker-hosted-cp
151+
namespace: kcm-system
152+
spec:
153+
template: docker-hosted-cp-1-0-0
154+
credential: docker-stub-credential
155+
config:
156+
clusterLabels: {}
157+
clusterAnnotations: {}
158+
EOF
159+
```
160+
161+
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.
162+
163+
Now we wait for the child cluster to be Ready:
164+
165+
```bash
166+
kubectl wait --for=condition=Ready clusterdeployment/docker-hosted-cp -n kcm-system --timeout=600s
167+
kubectl wait --for=jsonpath='{.status.phase}'=Provisioned cluster/docker-hosted-cp -n kcm-system --timeout=600s
168+
kubectl wait --for=condition=Ready dockercluster/docker-hosted-cp -n kcm-system --timeout=600s
169+
kubectl wait --for=jsonpath='{.status.ready}'=true k0smotroncontrolplane/docker-hosted-cp-cp -n kcm-system --timeout=600s
170+
```
171+
172+
*... a few moments later ...*
173+
174+
## Verifying the Child Cluster
175+
176+
Let's get the child cluster kubeconfig out and check if the cluster itself looks good:
177+
178+
```bash
179+
kubectl -n kcm-system get secret docker-hosted-cp-kubeconfig -o jsonpath='{.data.value}' | base64 -d > docker-hosted-cp.kubeconfig
180+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
181+
```
182+
183+
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:
184+
185+
```bash
186+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
187+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
188+
```
189+
190+
**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:
191+
192+
```bash
193+
watch KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
194+
```
195+
196+
## Deploying Valkey Using MultiClusterService
197+
198+
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!
199+
200+
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":
201+
202+
```bash
203+
kubectl label cluster docker-hosted-cp group=demo -n kcm-system
204+
```
205+
206+
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.
207+
208+
Ok, let's do this!
209+
210+
```bash
211+
kubectl apply -f - <<EOF
212+
apiVersion: k0rdent.mirantis.com/v1alpha1
213+
kind: MultiClusterService
214+
metadata:
215+
name: valkey
216+
spec:
217+
clusterSelector:
218+
matchLabels:
219+
group: demo
220+
serviceSpec:
221+
services:
222+
- template: valkey-0-1-0
223+
name: valkey
224+
namespace: valkey-system
225+
values: |
226+
valkey:
227+
spec:
228+
tls: false # when enabled, needs CertManager (and some configs) inside child-cluster
229+
EOF
230+
```
231+
232+
**Note:** In our case, 'values.valkey.spec' that are exposed inside the template are Valkey Operator Helm Chart values.
233+
234+
## Verifying the Deployment
235+
236+
Let's check the object status, we should see something similar to the example output:
237+
238+
```bash
239+
kubectl get MultiClusterService -A
240+
```
241+
242+
Expected output:
243+
```
244+
NAME SERVICES CLUSTERS AGE
245+
valkey 1/1 1/1 23s
246+
```
247+
248+
Now let's check how things look like inside the child cluster:
249+
250+
```bash
251+
KUBECONFIG="docker-hosted-cp.kubeconfig" kubectl get pods -A
252+
```
253+
254+
Expected output:
255+
```
256+
NAMESPACE NAME READY STATUS RESTARTS AGE
257+
kube-system coredns-5555f45c94-bf9mb 1/1 Running 0 23m
258+
kube-system konnectivity-agent-tfsr8 1/1 Running 0 21m
259+
kube-system kube-proxy-thx5h 1/1 Running 0 21m
260+
kube-system kube-router-6b7s8 1/1 Running 0 21m
261+
kube-system metrics-server-7778865875-s9hsz 1/1 Running 0 23m
262+
local-path-storage local-path-provisioner-74f9666bc9-5xqlf 1/1 Running 0 16m
263+
projectsveltos sveltos-agent-manager-79df48c686-8l6dk 1/1 Running 0 23m
264+
valkey-system valkey-0 1/1 Running 0 64s
265+
valkey-system valkey-operator-controller-manager-6dc5d6bf57-rbt9x 1/1 Running 0 78s
266+
```
267+
268+
See how application delivery is made very simple by k0rdent, pure magic!
269+
270+
## Conclusion
271+
272+
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.
273+
274+
This is all for today dear reader, thanks for spending this time with me!

0 commit comments

Comments
 (0)