1. Help Center
  2. LINSTOR
  3. Kubernetes Integration

How to create a EKS Launch Template for LINSTOR.

While most of the LINSTOR® cluster’s initialization and configuration is handled by the LINSTOR Operator, we need EKS to attach additional volume(s) and install the appropriate kernel-devel packages before launching the EKS worker instance.

To create the EC2 Launch Template for EKS you'll need to login to your EC2 console. From there, follow the steps outlined below.

Navigate to the Launch Template section of the EC2 console

 

Click, "Create launch template", button

 

Give your template a meaningful name and description so you know what it is later.

You can leave the “Application and OS Images (Amazon Machine Image)” section blank, which will result in instances being created using the Amazon Linux 2.0 AMI.

NOTE: If you select an Amazon Machine Image (AMI) that LINBIT® packages kernel modules for such as
Ubuntu, RHEL, or SLES, the LINSTOR® Operator will be able to install the DRBD® kernel module without the need to install kernel-devel during the bootstrapping process. However, you would need to set the appropriate Helm values depending on your AMI, as outlined in the Deploying with the LINSTOR Operator section of the LINSTOR User’s Guide. 

Set the instance size appropriate for the applications you expect to run in EKS. LINSTOR and DRBD have very low resource requirements, so sizing your instances should be done according to your application's needs.

The volumes section of the launch template is where most of the configuration happens. LINSTOR is able to use a separate block device for DRBD’s metadata than the one used for provisioned persistent volumes. Doing so will result in better performance of your persistent volumes, but isn’t completely necessary if you’re not concerned with squeezing out every last bit of performance. We'll configure separate block devices in this KB.

In the volume configuration below you’ll see two volumes; a larger 100 GiB volume that LINSTOR will provision persistent volumes from and a smaller 4 GiB volume that LINSTOR will use for DRBD’s metadata. These devices will end up getting attached to the EC2 instances as /dev/nvme2n1 and /dev/nvme1n1, respectively.

NOTE: Set the size of the larger volume according to your deployment’s storage requirements. The smaller
volume should be sized relative to the size of your larger volume; the ratio of 32MiB (metadata) per 1TiB
(data), per peer. 4GiB is the smallest volume allowed by EBS, which will work for data volumes up to 64 TiB in size with 3 replicas of each volume. 

 

Finally, under the “Advanced details” section, add the following user data script that will be merged into the EKS bootstrapping process. This will install the appropriate kernel-devel package on the EKS instance allowing the LINSTOR Operator to compile DRBD. Using the Compile method for the DRBD kernel module injection is a more robust option than relying on the prepackaged module RPM and deb packages included in the LINSTOR Operator’s kernel module injector container images. 


Here is the plain text of the user data pictured above for copy and pasting into your own launch template: 

Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0

--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
sudo yum install kernel-devel-`uname -r` -y

--==BOUNDARY==--\

 

You can now click the “Create launch template” button to create the template. Once created, you will be able to see the “Launch template ID” listed under your EC2 launch templates. You will need this ID when you configure EKS to launch worker instances using this template.

 

For completeness, with the launch template created above, you could use the following helm options while deploying LINSTOR, and the storage class definitions below that for consuming storage from within EKS.

Helm values for LINSTOR:

operator:
  controller:
    dbConnectionURL: k8s
  satelliteSet:
    storagePools:
      lvmThinPools:
      - name: ext-meta-pool
        thinVolume: metapool
        volumeGroup: ""
        devicePaths:
        - /dev/nvme1n1
      - name: lvm-thin
        thinVolume: thinpool
        volumeGroup: ""
        devicePaths:
        - /dev/nvme2n1
    kernelModuleInjectionMode: Compile
etcd:
  enabled: false
stork:
  enabled: false
csi:
  enableTopology: true
haController:
  replicas: 3

Storage Classes for EKS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "linstor-csi-lvm-thin-r1"
provisioner: linstor.csi.linbit.com
parameters:
  allowRemoteVolumeAccess: "false"
  autoPlace: "1"
  storagePool: "lvm-thin"
  DrbdOptions/Disk/disk-flushes: "no"
  DrbdOptions/Disk/md-flushes: "no"
  DrbdOptions/Net/max-buffers: "10000"
  property.linstor.csi.linbit.com/StorPoolNameDrbdMeta: "ext-meta-pool"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "linstor-csi-lvm-thin-r2"
provisioner: linstor.csi.linbit.com
parameters:
  allowRemoteVolumeAccess: "false"
  autoPlace: "2"
  storagePool: "lvm-thin"
  DrbdOptions/Disk/disk-flushes: "no"
  DrbdOptions/Disk/md-flushes: "no"
  DrbdOptions/Net/max-buffers: "10000"
  property.linstor.csi.linbit.com/StorPoolNameDrbdMeta: "ext-meta-pool"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "linstor-csi-lvm-thin-r3"
provisioner: linstor.csi.linbit.com
parameters:
  allowRemoteVolumeAccess: "false"
  autoPlace: "3"
  storagePool: "lvm-thin"
  DrbdOptions/Disk/disk-flushes: "no"
  DrbdOptions/Disk/md-flushes: "no"
  DrbdOptions/Net/max-buffers: "10000"
  property.linstor.csi.linbit.com/StorPoolNameDrbdMeta: "ext-meta-pool"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer



Reviewed by DJV – 8/25/2022