开源分布式存储工具longhorn部署

发表于2024-05-03|更新于2024-10-31|容器

|浏览量:

k8s 如果需要用到存储，对于云产品一般都是采用云厂商提供的存储驱动，自建机房简单一点的会采用 nfs，nfs 有以下问题：

高可用性问题，一般都是单台机器在跑，高可用完全依靠物理机器的 RAID，非常不云原生
性能问题，NFS 本身性能不算好，外加一个集群都在使用，网卡速度是个瓶颈
longhorn 是个开源的存储引擎，简单来说就是它把 k8s 每个节点的磁盘空间搜集起来，组成一个大池子，然后分配个各个 pod 使用。并通过多副本的方式做高可用。longhorn 好像是 openSUSE 家的吧，和 rancher 一个公司。

官方文档

官方安装说明：
https://longhorn.io/docs/1.6.1/deploy/install/install-with-kubectl/

官方安装要求：
https://longhorn.io/docs/1.6.1/deploy/install/#installation-requirements

官方的检查依赖项脚本：

1	curl -fsSL https://raw.githubusercontent.com/longhorn/longhorn/v1.6.1/scripts/environment_check.sh \| bash

安装依赖

# CentOS 7
yum install -y jq mktemp sort printf
yum install -y iscsi-initiator-utils
systemctl enable --now iscsid.service

yum install -y nfs-utils
yum install -y cryptsetup

使用 kubectl 安装 longhorn

1	kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.1/deploy/longhorn.yaml

文章作者: 张理坤

文章链接: https://zahui.fan/posts/scx23m/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源杂烩饭！

kubectl 存储 Kubernetes k8s

相关推荐

Kubernetes回滚应用之kubectl rollout

kubernetes 每次更新资源会记录资源的历史版本，方便我们进行回滚操作。真的 k8s 解决了很多运维的痛点问题, 想起来以前没有用 k8s 的时候,用 jenkins 和 ansible 来做的发布和回滚… 查看历史版本12345678kubectl rollout history deployment nfs-client-provisionerdeployment.apps/nfs-client-provisionerREVISION CHANGE-CAUSE1 <none>2 <none>4 <none>5 <none> 这里列出的就是版本，为什么没有 3，因为从版本 4 回滚到了版本 3，则版本 3 就变成了版本 5 查看指定版本详情1kubectl rollout history deployment nfs-client-provisioner --revision=4 回滚到指定版本1kubectl rollout undo...

使用cronjob自动重启k8s的deployment

配置权限1234567891011121314151617181920212223242526272829303132---kind: ServiceAccountapiVersion: v1metadata: name: deployment-restart namespace: default---apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: deployment-restart namespace: defaultrules: - apiGroups: ["apps", "extensions"] resources: ["deployments"] resourceNames: [] verbs: ["get", "patch", "list", "watch"] # list 和 watch 就够用了，如果需要执行...

使用kubectl进行多集群管理

平常使用跳板机来管理, 经常多个环境多套集群, 那么如何用一个 kubectl 如何管理这些集群. 使用不同的 kubeconfig 管理使用不同的 Linux 用户每个 Linux 用户的 ~/.kube/config 配置不同即可, 比如创建一个 uat 用户,一个 prod 用户, 分别配置不同的 config 文件使用环境变量config 文件放到当前目录下 1KUBECONFIG=config-uat kubectl get pod 环境变量也可以写成全局的在.bashrc 里面 1export KUBECONFIG=config-uat 使用参数同使用环境变量 1kubectl get pod --kubeconfig=config-uat 使用一个 kubeconfig准备确保每个 kubeconfig 里面部分参数唯一性,可以手动修改一下合并配置文件假设一个配置文件名为: uat, 另一个为: prod 1KUBECONFIG=uat:prod kubectl config view --flatten >...

Kubernetes使用NFS作为存储

我们玩单机的容器，如果需要持久化的话，需要将容器目录映射到主机，但是在 K8S 环境下容器是可能会被调度到任意节点的，所以需要使用远程服务存储数据。在云平台上都会提供自己的云盘存储，但是自己搭建的 Kubernetes 没有办法使用云盘做存储，所以需要用自己搭建的存储，NFS 是比较常见的一种，其他还有 glusterfs、ceph 等。关于 NFS 搭建教程，可以查看https://zahui.fan/posts/4b677f68/容器镜像开源地址https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner 安装 NFS client 工具所有的 worker 节点上都需要安装 NFS client Ubuntu 1sudo apt install nfs-common -y CentOS 1sudo yum install nfs-utils -y rbac...

Java程序被停止前自动dump内存快照

线上业务偶尔会出现重启现象，为了排查这个问题，决定在 OOM 的时候自动进行 dump 内存快照用于分析针对 JVM OOM 的情况OOM 全称 “Out Of Memory”，表示内存耗尽。当 JVM 因为没有足够的内存来为对象分配空间，并且垃圾回收器也已经没有空间可回收时，就会抛出这个错误，解决 OOM 问题的一个思路: 假设发生 OOM 了，必然说明系统中某个区域的对象太多了，塞满了那个区域，而且一定是无法回收掉那些对象，最终才会导致内存溢出的，首先就得知道到底是什么对象太多了导致 OOM ，就必须得有一份 JVM 发生 OOM 时的 dump 内存快照有了 dump 内存快照，就可以用 MAT 之类的工具，或者在线工具来分析：https://memory.console.heapdump.cn/JVM 在发生 OOM 的时候并不是直接挂掉的，而是在 OOM 之前会尽量去 GC 腾出来一些内存空间，如果 GC 后还是没有空间，放不下对象，才会触发内存溢出的。JVM 给我们提供了一些参数可以在发生 OOM 的时候进行自动 dump 内存快照。：...

Kubernetes之master高可用方案

之前一直用使用的负载方案是搭建一台负载均衡器，可以是 haproxy 或 nginx 或 lvs，来将多个 master 节点的 6443 端口做个负载均衡，但是考虑到负载均衡也需要高可用，所以会引入类似 keepalived 的方案来解决问题。偶然看到了 kubeasz 这个开源项目，宣称解决了 master 高可用问题，部署了一遍发现并没有额外搭建负载均衡器，研究了一下，发现了另一种思路。使用额外的负载均衡来做高可用这种就是比较容易想到的一种方案，比如 3 个 master 节点，前面有一台负载均衡（nginx、haproxy、lvs）等，但是负载均衡本身就是一个单点故障，所以一般来说还需要另一台负载均衡，通过 keepalived 来实现 VIP 的切换使用Keepalived来实现Nginx高可用使用Nginx做负载均衡使用HAproxy做负载均衡使用LVS做负载均衡vim nginx.conf 在文件最后添加 123stream { include stream.conf;} 然后 vim...

评论

数据加载中