Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how to achieve persistent storage of Kubernetes clusters by Longhorn". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Overview of Longhorn function

Shared resource pool: forms a shared resource pool from local disks or network storage installed in compute or dedicated storage hosts.

Create block volumes for containers and virtual machines: you can specify the size of volume, the requirements for IOPS, and the number of synchronous replica you want across hosts (here hosts are those that provide storage resources for volume). Replica is configured thinly on the underlying disk or network storage.

Create a dedicated storage controller for each volume: this is probably the most distinctive feature of Longhorn compared to most existing distributed storage systems. Most of the existing distributed storage systems usually use complex controller software to serve hundreds to millions of volume. Unlike Longhorn, however, there is only one volume,Longhorn on each controller that turns each volume into a microservice.

Scheduling multiple replica:Longhorn across computing or storage hosts monitors the health of each replica, repairs the problem, and regenerates the replica if necessary.

Operate the storage controller and replica in the form of Docker containers: for example, a volume has three replica, which means there are four containers.

Multiple storage "front ends" are allocated for each volume: common front ends include Linux kernel devices (mapped to / dev / longhorn) and iSCSI targets. Linux kernel devices are suitable for supporting Docker volume, while iSCSI targets are more suitable for supporting QEMU / KVM and VMware volume.

Create volume snapshots and AWS EBS-style backups: you can create up to 254snapshots per volume, which can be backed up one by one to NFS or S3-compatible secondary storage. Only changed bytes are copied and stored during the backup operation.

Specify a schedule for periodic snapshot and backup operations: you can specify the frequency of these operations (hourly, daily, weekly, monthly, and yearly), the exact time when these operations are performed (for example, 3:00 every Sunday morning), and how many circular snapshots and backup sets are retained.

Support for persistent storage of any Kubernetes cluster

Longhorn v0.2 supports persistent storage for any Kubernetes cluster. Once deployed on a Kubernetes cluster, Longhorn automatically aggregates all available local storage on all nodes in the Kubernetes cluster into a cluster, resulting in replicated and distributed block storage. You can perform snapshots and backups on Longhorn volume and replicate them synchronously to multiple nodes.

We have migrated Longhorn Manager as Kubernetes Controller. All Longhorn states are stored as Custom Resource Definitions (custom resource definitions, CRD). Longhorn also does not require a separate etcd server. In addition, Longhorn Manager exposes API that performs Longhorn volume operations and snapshot / backup operations, which API will be used during operations by Longhorn UI and Kubernetes Flexvolume drivers.

Run the following command to deploy the entire Longhorn storage system on your Kubernetes cluster:

Kubectl create-f https://raw.githubusercontent.com/rancher/longhorn/v0.2/deploy/longhorn.yaml

If you are using GKE, please refer to here: https://github.com/rancher/longhorn/blob/master/README.md#google-kubernetes-engine

After deployment, you can find the appropriate IP:kubectl-n longhorn-system get svc by viewing the Kubernetes service in the UI interface

Now you can use 100.200.200.123 or visit UI at: 12345.

Longhorn provides full integration of Kubernetes.

You can create a pod with volume backups from Longhorn as follows:

ApiVersion: v1kind: Podmetadata: name: volume-test namespace: defaultspec: containers:-name: volume-test image: nginx:stable-alpine imagePullPolicy: IfNotPresent volumeMounts:-name: voll mountPath: / data ports:-containerPort: 80 volumes:-name: voll flexVolume: driver: "rancher.io/longhorn" fsType: "ext4" options: size: "2Gi" numberOfReplicas: "3" StaleReplicaTimeout: "20" fromBackup: ""

Longhorn also supports dynamic provisioner. For example, you can define a StorageClass like this in Kubernetes:

Kind: StorageClassapiVersion: storage.k8s.io/v1metadata: name: longhornprovisioner: rancher.io/longhornparameters: numberOfReplicas: "3" staleReplicaTimeout: "30" fromBackup: ""

Then create a PVC (PersistentVolumeClaim) and use it in Pod:

ApiVersion: v1kind: PersistentVolumeClaimmetadata: name: longhorn-volv-pvcspec: accessModes:-ReadWriteOnce storageClassName: longhorn resources: requests: storage: 2Gi---apiVersion: v1kind: Podmetadata: name: volume-test namespace: defaultspec: containers:-name: volume-test image: nginx:stable-alpine imagePullPolicy: IfNotPresent volumeMounts:-name: volv mountPath: / data ports:-containerPort: 80 volumes:-name: volv persistentVolumeClaim: claimName: longhorn- This is the end of volv-pvc 's "how to implement persistent storage of Kubernetes clusters by Longhorn". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.