Kubernetes 1.27 is deprecated
Using local storage in bare metal
Local storage keeps data on the node, so it is faster than network storage, and on bare-metal machines it is cheap too. Syself Autopilot handles the lifecycle: data persists through cluster updates and machine re-provisioning, which suits storage-intensive workloads such as databases. This one-time setup configures your cluster and machines to use local storage with TopoLVM.
Warning
Most of the procedure described in this guide will be automated in the upcoming release of Syself Autopilot. Please stick to the configuration options described here to guarantee compatibility.
1. Deploy cert-manager
You need to have cert-manager version v1.7.0 or higher installed on your cluster as a dependency of TopoLVM. Install it with the following command:
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm template --namespace=kube-system cert-manager jetstack/cert-manager --set installCRDs=true | kubectl apply -n kube-system -f -
You can follow the official guide on installing helm if you don't have it.
Warning
To guarantee compatibility with future Syself Autopilot releases, don't use helm install, as our automation will create the resources directly instead of installing charts.
2. Deploy TopoLVM
We use the TopoLVM CSI driver for local storage on bare-metal. You can follow the steps below to deploy it to your workload cluster.
Add the Syself helm repository:
$ helm repo add syself https://charts.syself.com $ helm repo updateTemplate the TopoLVM chart and apply it to the cluster:
Warning
Do not use
helm install. This chart will be added as a base feature in later versions of Syself Autopilot, so stick to the installation steps shown here to guarantee compatibility. Use the command below to install it withhelm templateandkubectl applyto thekube-systemnamespace.$ helm template --namespace=kube-system csi-local syself/topolvm | kubectl apply -n kube-system -f -Now the storage space in your bare-metal server is exposed to your cluster via the
local-nvmeStorage Class:$ kubectl get storageclasses NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION local-hdd topolvm.io Retain WaitForFirstConsumer true local-nvme topolvm.io Retain WaitForFirstConsumer true local-ssd topolvm.io Retain WaitForFirstConsumer true standard (default) csi.hetzner.cloud Retain WaitForFirstConsumer true
3. Configure your servers
In this step, you'll define the physical volumes and volume groups in your disks to be used by TopoLVM.
Note
We support all three types of disks: HDD, SATA SSD, and NVMe SSD. If your server, for example, only has NVMe, you should only follow the steps for NVMe and cannot use the storage classes local-ssd or local-hdd.
If your server has NVMe, SSD, and HDD, you can use all three storage classes.
Access your server via ssh:
$ ssh -i path-to-your/ssh-key -p 100 root@<machine-ip>List your disks with
lsblk:$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme1n1 259:0 0 476.9G 0 disk nvme0n1 259:1 0 476.9G 0 disk |-nvme0n1p1 259:2 0 512M 0 part /boot/efi |-nvme0n1p2 259:3 0 1G 0 part /boot `-nvme0n1p3 259:4 0 475.4G 0 part /Identify if the disk(s) you want to use is an HDD, SATA SSD, or NVMe SSD.
Warning
Don't use your OS disk (
nvme0n1in the above output), as this can lead to data loss.Tip
To identify the type of disk you have, you can look at the first column
NAMEand third columnRMof thelsblkoutput.- An NVMe disk will have
nvmeat the beginning of its name, otherwise: - A SATA SSD disk will have the value 0 in the
RMcolumn. - A HDD disk will have the value 1 in the
RMcolumn.
- An NVMe disk will have
Create a physical volume (point to every disk in your server where you want to store data) with
pvcreate /dev/[disk-name]. For example:$ pvcreate /dev/nvme1n1Map the disks to the appropriate volume group type with
vgcreate vg-[type] /dev/[disk-name] /dev/[other-disk]. For example:$ vgcreate vg-nvme /dev/nvme1n1If you missed a disk and want to add it later, extend the volume group with
vgextend vg-[type] /dev/[new-disk]. For example:$ vgextend vg-nvme /dev/nvme2n1Available volume group types
- For NVMe disks you use: `vg-nvme` - For SATA SSD disks you use: `vg-ssd` - For HDD disks you use: `vg-hdd`Repeat the previous steps for every disk you want to use.
After adding all disks to their respective volume groups, create a thin provisioned logical volume for each volume group. This step is done once per volume group, not per disk: Create a thin provisioned logical volume with
lvcreate --thinpool pool-[type] --extents 100%FREE vg-[type].
$ lvcreate --thinpool pool-nvme --extents 100%FREE vg-nvme
$ lvcreate --thinpool pool-ssd --extents 100%FREE vg-ssd
$ lvcreate --thinpool pool-hdd --extents 100%FREE vg-hdd
4. Use it!
You can use the newly created Storage Classes in the same way you would use any other.
Available storage classes
By default, you have Storage Classes for all three disk types available in your cluster:
- For NVMe disks:
local-nvme - For SATA SSD disks:
local-ssd - For HDD disks:
local-hdd
If you use a Storage Class for a disk type unavailable in your machine volume groups, your workload will be stuck at provisioning. We include all three to make your cluster ready for any new disks you might add in the future.
If you want to test your new setup:
Create a
pv-claim.yamlfile with the following content:pv-claim.yamlyaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pv-claim spec: storageClassName: local-nvme accessModes: - ReadWriteOnce resources: requests: storage: 1GiAnd apply it with
kubectl apply -f pv-claim.yaml.Create a
pod.yamlfile with the following content:yaml apiVersion: v1 kind: Pod metadata: name: pv-pod spec: volumes: - name: pv-storage persistentVolumeClaim: claimName: pv-claim containers: - name: pv-container image: nginx ports: - containerPort: 80 name: http-server volumeMounts: - mountPath: /usr/share/nginx/html name: pv-storageAnd apply it with
kubectl apply -f pod.yaml.Now, all the data stored in the container under
/usr/share/nginx/htmlwill be in/mnt/dataon your machine.Note
In this example, we used the
local-nvmeclass, but you can also uselocal-hddandlocal-ssdtoo if your servers have disks of those types attached.Create a test file in your pod:
$ kubectl exec -it pv-pod -- /bin/sh $ echo 'Hi from Kubernetes to bare metal!' > /usr/share/nginx/html/hi.txtNow delete the pod, so we are sure the storage is persistent, and not ephemeral:
kubectl delete pod pv-podApply the pod again with
kubectl apply -f pod.yaml. Show the content of thehi.txtfile:$ cat /mnt/data/hi.txt Hi from Kubernetes to bare metal!