Меня зовут Валера, я из Минска, работаю в компании NextSoft

Подскажите, где можно почитать как запускать nfs как ReadWriteMany и динамически маппить на statefulset в volumeClaimTemplates ?

в документации кубера?

Подскажите, где можно почитать как запускать nfs как ReadWriteMany и динамически маппить на statefulset в volumeClaimTemplates ?

А можно ли в мэни?

БД не забудь туда сложить

В смысле? Ну, я nfs и прикручиваю только для того, чтобы в many

БД не забудь туда сложить

Не оч вариант для мэни

оно же вроде умеет кластеризоваться

А какая альтернатива?

Rook glusterfs

у @kvaps вроде есть магия чтобы оба сразу

с NFS всё и правда работает, пока данные не начнет терять - ну или тормозить если включить sync чтобы не теряло данные

@cent_ru а ты чего добиться то пытаешься?

сделай пару pvc/pv для nfs

затем этот pvc можно будет использовать как обычно с readWriteMany

кстати в чарте генератор для ReadWriteOnce волумов, не для ReadWriteMany

используй kubectl describe pvc <pvc>

Есть кто настраивал alertmanager для slack-a. Я хочу чтобы в text мне отображало description моего alerta

@metrics_ru

эти три persistenVolumeClaim должны найти три подходящих persistentVolumes и забиндиться на них

Да, а как они их найдут? Будут рандомный брать по storageClass ?

искать они будут persistentVolume с таким же storageClass, таким же accessModes: [ "ReadWriteOnce" ] и подходящим size

кажется натс стриминг умеет юзать sql бд для шаред сторейжа

Умеет, я юзал

А в чем профит перед файлами?

База у всех есть, а nfs не у всех

Ну, а замеры какие-то есть? Какие нагрузки все это держит? И сколько отжирает ресурсов?

И кубер я тоже собираюсь выпилить в след году 😂

И кубер я тоже собираюсь выпилить в след году 😂

Правильно. Жизнь одна. Нужно все извращения попробовать и свой деплой на bash, в том числе)

Как-будто в куб деплоят без баша

Мы уже почти полностью распилили свой монолит на кучу мелких SPA+api. Сейчас попробовали gatsby и будет переводить на него все клиентские сайты (это статический генератор сайта, раз в пол часа просто каталог на 2к товаров пересобирается и все, ничего кроме nginx и апишки небольшой не нужно). Bashем пускать апишки неудобно, поэтому буду запускать через nomad, но с условием, что если падает кластер, то можно было поднять по минимуму за 10-20 минут, а не как сейчас падает кластер и от мысли, что нужно 20 критических и 50 остальных деплойментов поднять... становится не по себе. Схема простая. Nginx, который проксит статику с S3 и апишки, которые держит nomad + отдельный инстанс с клиентскими аpi, на которые все SPA могут переключаться, если вдруг основное API сдохло. Это скорее всего чисто наш кейс, мне крайне сильно нравилось, что раз-два и выкатили сервис + всякие le из коробки + мониторинг и в принципе куб вправляет мозг как должно быть. Но меня не радует стабильность кластера моих кривых руках, а nginx и api на го стабильней некуда (про базы не говорю, 0 проблем за 5 лет).

звучит как будто вы не хипстеры и у вас есть архитектор в команде

nomad подбирает порт, кидает в env и задача бинарника по указанному порту стартануть. Куча реплик на хосте не проблема. И fabio сверху работает как service+ingress. Consul гоняет приватный трафик через прокси мастеры, если нужно. И это на порядок проще, чем копаться в calico, хотя может и не так быстро.

Для чего consul используется?...

Для чего consul используется?...

Или это в принципе вопрос? service discovery, healthcheck, service mesh, key-value (как etcd).

Мы уже почти полностью распилили свой монолит на кучу мелких SPA+api. Сейчас попробовали gatsby и будет переводить на него все клиентские сайты (это статический генератор сайта, раз в пол часа просто каталог на 2к товаров пересобирается и все, ничего кроме nginx и апишки небольшой не нужно). Bashем пускать апишки неудобно, поэтому буду запускать через nomad, но с условием, что если падает кластер, то можно было поднять по минимуму за 10-20 минут, а не как сейчас падает кластер и от мысли, что нужно 20 критических и 50 остальных деплойментов поднять... становится не по себе. Схема простая. Nginx, который проксит статику с S3 и апишки, которые держит nomad + отдельный инстанс с клиентскими аpi, на которые все SPA могут переключаться, если вдруг основное API сдохло. Это скорее всего чисто наш кейс, мне крайне сильно нравилось, что раз-два и выкатили сервис + всякие le из коробки + мониторинг и в принципе куб вправляет мозг как должно быть. Но меня не радует стабильность кластера моих кривых руках, а nginx и api на го стабильней некуда (про базы не говорю, 0 проблем за 5 лет).