rook
zfs-localpv
Our great sponsors
rook | zfs-localpv | |
---|---|---|
51 | 12 | |
11,905 | 366 | |
1.2% | 5.2% | |
9.9 | 7.1 | |
6 days ago | 7 days ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rook
-
Ceph: A Journey to 1 TiB/s
I have some experience with Ceph, both for work, and with homelab-y stuff.
First, bear in mind that Ceph is a distributed storage system - so the idea is that you will have multiple nodes.
For learning, you can definitely virtualise it all on a single box - but you'll have a better time with discrete physical machines.
Also, Ceph does prefer physical access to disks (similar to ZFS).
And you do need decent networking connectivity - I think that's the main thing people think of, when they think of high hardware requirements for Ceph. Ideally 10Gbe at the minimum - although more if you want higher performance - there can be a lot of network traffic, particularly with things like backfill. (25Gbps if you can find that gear cheap for homelab - 50Gbps is a technological dead-end. 100Gbps works well).
But honestly, for a homelab, a cheap mini PC or NUC with 10Gbe will work fine, and you should get acceptable performance, and it'll be good for learning.
You can install Ceph directly on bare-metal, or if you want to do the homelab k8s route, you can use Rook (https://rook.io/).
Hope this helps, and good luck! Let me know if you have any other questions.
-
Running stateful workloads on Kubernetes with Rook Ceph
Another option is to leverage a Kubernetes-native distributed storage solution such as Rook Ceph as the storage backend for stateful components running on Kubernetes. This has the benefit of simplifying application configuration while addressing business requirements for data backup and recovery such as the ability to take volume snapshots at a regular interval and perform application-level data recovery in case of a disaster.
-
People who run Nextcloud in Docker: Where do you store your data/files? In a Docker volume, or on a remote server/NAS?
This is beyond your question but might help someone else: I switch from docker-compose to kubernetes for my home lab a while ago. The storage solution I've settled on is Rook. It was a bit of up-front work learning how to get it up but now that it's done my storage is automatically managed by Ceph. I can swap out drives and Ceph basically takes care of everything itself.
-
Rook/Ceph with VM nodes on research cluster?
The stumbling point I am at is I want to use rook.io(Ceph) as my storage solution for the cluster. The Ceph prerequisites are one of the following:
-
Asking for recommendation on remote Kubernetes storage for a small cluster and databases
Have you looked at Rook?
-
Want advice on planned evolution: k3os/Longhorn --> Talos/Ceph, plus Consul and Vault
I've briefly run ceph in an external mode, you can actually use a rook deployment to manage it (sort of). Here is the documentation for doing that. For me it didn't pass my testing phase because I need better networking equipment before I can try that.
-
ATARI is still alive: Atari Partition of Fear
This article explains the data corruption issue happened in Rook in 2021. The root cause lies in an unexpected place and can also occurs in all Ceph environment. It's interesting that Rook had started to encounter this problem recently even though this problem has existed for a long time. It's due to a series of coincidences. I wrote this article because the word "Atari" used in a non-historical context in 2021.
-
How to Deploy and Scale Strapi on a Kubernetes Cluster 2/2
Rook (this is a nice article for Rook NFS)
-
Running on-premise k8s with a small team: possible or potential nightmare?
Storage: Favor any distributed storage you know to start with for Persistent Volumes: Ceph maybe via rook.io, Longhorn if you go rancher etc
-
My completely automated Homelab featuring Kubernetes
I've dealt with a lot of issues that are very close to just unplugging a node. Unfortunately on node lost, my stateful workloads using rook-ceph block storage won't migrate over to another node automatically due to an issue with rook. Stateless apps (ingress nginx, etc..) not using rook-ceph block failover to another node just fine. I've kind of accepted this for now and I know Longhorn has a feature that makes this work but I find rook-ceph to be more stable for my workloads.
zfs-localpv
-
ZFS 2.2.0 (RC): Block Cloning merged
I use it in Kubernetes via https://github.com/openebs/zfs-localpv
The PersistentVolume API is a nice way to divvy up a shared resource across different teams, and using ZFS for that gives us the snapshotting, deduplication, and compression for free. For our workloads, it benchmarked faster than XFS so it was a no-brainer.
- openebs/zfs-localpv: CSI Driver for dynamic provisioning of Persistent Local Volumes for Kubernetes using ZFS.
-
OpenEBS on MicroK8S on Hetzner
Last few months I experimented more and more with all OpenEBS solutions that fit small Kubernetes cluster, using MicroK8S and Hetzner Cloud for a real experience.
- Openebs ?? Or equivalent
-
Network Storage on On-Prem Barebones Machine
I would investigate https://openebs.io/ https://portworx.com/ https://longhorn.io/ if you are forced to you can mount ISCSI on the kublet and feed it to one of those solutions. Keep in mind most of the big guys buy some sort of managed solution that you can point a CSI like trident https://netapp-trident.readthedocs.io
-
Ask HN: What are some fun projects to run on a home K8s cluster?
What are some cool projects to self hosted on a home Raspberry Pi (64 bit) Kubernetes cluster (Helm charts). arm64 support is a must. A lot of projects only build amd64 Docker containers which don't run on my cluster.
I currently run:
- obenebs (provides abstraction for using local k8s worker disks as PVC mounts when running on-prem) -- https://openebs.io/
-
Finally got around to doing that Ceph on ZFS experiment
I didn't set anything actually -- I need to look into whether OpenEBS ZFS LocalPV can facilitate passing ZVOL options (I don't think it can just yet). The only tuning I did on the storage class was the usual ZFS-level options.
-
My self-hosting infrastructure, fully automated
What do you use to provision Kubernetes persistent volumes on bare metal? I’m looking at open-ebs (https://openebs.io/).
Also, when you bump the image tag in a git commit for a given helm chart, how does that get deployed? Is it automatic, or do you manually run helm upgrade commands?
-
Jinja2 not formatting my text correctly. Any advice?
ListItem( 'Kubernetes', 'https://kubernetes.io/', 'Container Engines and Orchestration', """Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management.""" ), ListItem( 'Podman', 'https://podman.io/', 'Container Engines and Orchestration', """Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images.""" ), # Data Storage :: Block Storage ListItem( 'Amazon EBS', 'https://aws.amazon.com/ebs/', 'Data Storage :: Block Storage', """Amazon Elastic Block Store (Amazon EBS) is an easy-to-use, scalable, high-performance block-storage service designed for Amazon Elastic Compute Cloud (Amazon EC2).""" ), ListItem( 'OpenEBS', 'https://openebs.io/', 'Data Storage :: Block Storage', """OpenESB is a Java-based open-source enterprise service bus. It allows you to integrate legacy systems, external and internal partners and new development in your Business Process.""" ), # Data Storage :: Cluster Storage ListItem( 'Ceph', 'https://ceph.io/en/', 'Data Storage :: Cluster Storage', """Ceph is an open-source software storage platform, implements object storage on a single distributed computer cluster, and provides 3-in-1 interfaces for object-, block- and file-level storage.""" ), ListItem( 'Hadoop Distributed File System', 'https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html', 'Data Storage :: Cluster Storage', """The Hadoop Distributed File System ( HDFS ) is a distributed file system designed to run on commodity hardware.""" ), # Data Storage :: Object Storage ListItem( 'Amazon S3', 'https://aws.amazon.com/s3/', 'Data Storage :: Object Storage', """Amazon S3 or Amazon Simple Storage Service is a service offered by Amazon Web Services that provides scalable object storage through a web service interface.""" )
-
Building a "complete" cluster locally
Ideas from my kubernetes experience: * Cert-Manager is very popular and almost a must-have if you terminate SSL inside the cluster * Backups using velero * A dashboard/UI is actually very helpful to quickly browse resources, client tools like k9s are fine too * Secret: Management: Bitnami Sealed Secrets is the second big project in that space * I would add Loki to aggregate Logs * Never heard of ory. Usually I see (dex)[https://dexidp.io/] or keycloak used for Authentication * I like to run OpenEBS as in-cluster storage. * Istio isn't compatible with the upcomming ServiceMeshInterface (i think), so the trend seem to go toward Linkerd * Some Operator to deploy your favorite Database, is also a nice learning exercise.
What are some alternatives?
longhorn - Cloud-Native distributed storage built on and for Kubernetes
ceph-csi - CSI driver for Ceph
democratic-csi - csi storage for container orchestration systems
velero - Backup and migrate Kubernetes applications and their persistent volumes
lvm-localpv - Dynamically provision Stateful Persistent Node-Local Volumes & Filesystems for Kubernetes that is integrated with a backend LVM2 data storage stack.
Nginx Proxy Manager - Docker container for managing Nginx proxy hosts with a simple, powerful interface
k3s - Lightweight Kubernetes
Ceph - Ceph is a distributed object, block, and file storage platform
Mayastor - Dynamically provision Stateful Persistent Replicated Cluster-wide Fabric Volumes & Filesystems for Kubernetes that is provisioned from an optimized NVME SPDK backend data storage stack.
hub-feedback - Feedback and bug reports for the Docker Hub
cstor-operators - Collection of OpenEBS cStor Data Engine Operators