Kubernetes отлично подходит для приложений без учета их состояния.
Разверните свое приложение, масштабируйте его до сотен экземпляров, будьте счастливы.
Но как вы управляете хранилищем?
Как мы можем гарантировать, что каждое из наших сотен приложений получит надежное, быстрое и дешевое хранилище?
Давайте возьмем типичный кластер Kubernetes с несколькими узлами (серверами Linux), которые обеспечивают несколько копий нашего приложения:
Persistent Volume Claims
В Kubernetes мы определяем PersistentVolumeClaims, чтобы запросить нашу систему хранения.
Проще говоря, приложение «требует» немного памяти, и система отвечает настраиваемым способом:
App1 – > VolumeClaim
- Производительность и стоимость: производительность томов EBS (и других поставщиков облачных вычислений) зависит от его размера – это означает, что меньший диск – это то же самое, что и более медленный диск.
- Характеристики: поставщики облачных услуг обычно предлагают жесткие диски, SDD и опцию «подготовленного ввода-вывода». Это ограничивает системных администраторов в их системах хранения. Где находится резервная копия? А как насчет NVMe? Как диск подключен к серверу, на котором работает мой код?
- Переносимость / блокировка: EBS – это EBS, а постоянные диски Google – это постоянные диски Google. Поставщики облачных услуг настойчиво пытаются привязать вас к своим платформам и обычно прячут инструменты файловой системы, которые мы знаем и любим за облачной системой моментальных снимков.
Введите Rook.io
Облачное хранилище с открытым исходным кодом для Kubernetes» с «Хранилищем готовых файлов, блоков и объектов».
Rook и Ceph
Rook – это система, которая находится в вашем кластере и отвечает на запросы на хранение, но сама она не является системой хранения.
Хотя это немного усложняет ситуацию, вы должны чувствовать себя хорошо, потому что, хотя Rook и новичок, система хранения, которую он использует под капотом, закалена и далека от бета-тестирования.
Мы будем использовать Ceph, которому около 15 лет, который используется и разрабатывается такими компаниями, как Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat и SanDisk.
Это очень далеко от Kubernetes-Hipster, несмотря на то, как круто выглядит проект Rook!
Учитывая, что Rook версии 1.0 и Ceph поддерживают некоторые из самых важных в мире наборов данных, я бы сказал, что настало время обрести уверенность и вернуть контроль над нашим хранилищем данных!
Я буду строить RAID-массивы в 2020-х годах, и никто не сможет меня остановить!
Установка
Я не буду концентрироваться на первоначальной установке здесь, так как руководство по Rook простое.
После установки Rook мы создадим несколько компонентов:
- CephCluster, который отображает узлы и их диски в нашу новую систему хранения.
- CephBlockPool, который определяет, как хранить данные, включая количество реплик, которые мы хотим.
- StorageClass, который определяет способ использования хранилища из CephBlockPool.
Давайте начнем с CephCluster:
#?filename=ceph-cluster.yaml&mini=true&noApply=true
---
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
name: rook-ceph
namespace: rook-ceph
spec:
mon:
count: 3
allowMultiplePerNode: false
storage:
useAllNodes: false
useAllDevices: true
location:
config:
osdsPerDevice: "1"
directories:
- path: /opt/rook
nodes:
- name: "my-storage-node-1"
- name: "my-storage-node-2"
- name: "my-storage-node-3"
#?filename=ceph-blockpool.yaml&mini=true&noApply=true
---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
name: my-storage-pool
namespace: rook-ceph
spec:
failureDomain: osd
replicated:
size: 2
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: my-storage
provisioner: rook.io/block
parameters:
pool: my-storage-pool
Мы подождем, пока наш CephCluster будет установлен – а вы уже можете взглянуть на созданный вами объект CephCluster:
➜ kubectl -n rook-ceph get cephcluster rook-ceph -o json | jq .status.ceph.health
"HEALTH_OK"
#?filename=ceph-pvc.yaml&mini=true&noApply=true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-data
spec:
accessModes:
- ReadWriteOnce
# Use our new ceph storage:
storageClassName: my-storage
resources:
requests:
storage: 1000Mi
➜ kubectl get pv --watch
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS AGE
pvc-... 1000Mi RWO Delete Bound default/test-data my-storage 13m