чей-то мертво?

Мне тоже все равно я уже 5й год на центос , вопрос не в удобстве а в том на чем лучше запускать

На любой по-моему из цента убунты или дебиана

Зафига? В принципе, в kubespray меня критически не устраивает только одна вещь - невозможность указать внутреннюю недефолтную сетку для организации связи между нодами

В общем всем компонентам можно задать вручную или через факты адреса. Для calico ip autodicovery method есть. Но они слушают один фиг на *. Глубже ещё не копал

На любой по-моему из цента убунты или дебиана

Как их обновлять? Ставит пакетики из репозитория?

Как их обновлять? Ставит пакетики из репозитория?

Систему? Кубер?

о боже! В ру регионе не популярна core os

Оба. Кубер, например, в контейнерах можно запустить и обновлять по версии контейнера.

Оба. Кубер, например, в контейнерах можно запустить и обновлять по версии контейнера.

Кубер - можно пакетами

Для системы свои пакеты

о боже! В ру регионе не популярна core os

еще и за деньги лол

Рискну предположить, что профита от корос на пустом металле не будет. А вот гемора прибавится, в сравнении с " обычно" осью

Но критика этой идеи приветствуется

Рискну предположить, что профита от корос на пустом металле не будет. А вот гемора прибавится, в сравнении с " обычно" осью

А какого именно гемора?

Ну хотя бы "контейнерной" парадигмой

профит CoreOS в 1) cloud-init/igniter 2) оно форсит переход на контейнеры

Ну второй пункт это не +. Извините

Контейнер это не религия, а всего лишь инструмент

в longterm может оказаться и +. ИМХО, конечно

А какого именно гемора?

а ты её дебажил?)

ну там хотя бы логи посмотреть

Дебажил разок, было дело

Рискну предположить, что профита от корос на пустом металле не будет. А вот гемора прибавится, в сравнении с " обычно" осью

наоборот, у coreos есть Ignition - киллер фича когда система полностью снуля конфигурится одним json

наоборот, у coreos есть Ignition - киллер фича когда система полностью снуля конфигурится одним json

К сожалению пока игнишион не тестил

Дебажил разок, было дело

понравилось?

понравилось?

Я уже забыл

Кажется, ничего особенного

Я уже забыл

а ну заебись

Кажется, ничего особенного

да да, посмотреть процессы и логи например очень удобно

Кста, была у нас пачка серверов в ovh с "новыми" сетевыми карточками. Так пришлось драйвер ручками собирать ибо ванилька эту карточку не видела. Даже и не знаю как быть вы таком случае с корос

да да, посмотреть процессы и логи например очень удобно

journalctl же

Кста, была у нас пачка серверов в ovh с "новыми" сетевыми карточками. Так пришлось драйвер ручками собирать ибо ванилька эту карточку не видела. Даже и не знаю как быть вы таком случае с корос

у них есть torcx,вот пример https://github.com/lorenz/torcx-zfs

у них есть torcx,вот пример https://github.com/lorenz/torcx-zfs

Зфс это разве не про файловые системы?

какая разница? ссылка про сборку модуля

Оу, сорян)

Глянул, ну что. На 20 строк больше))

чем что?

На какой OS правильней держать bare-metal kubernetes кластер ? Centos или coreos ?

ubuntu. на центоси много всяких багов с ядром: то не допортировали чего-то, то перепортировали. люди жалуются, что на стандартных ядрах у них поды залипают в терминате.

ubuntu. на центоси много всяких багов с ядром: то не допортировали чего-то, то перепортировали. люди жалуются, что на стандартных ядрах у них поды залипают в терминате.

Спасибо , за ответ.

Можете прислать ссылку на issue в github в котором жалуются?

http://blog.kubernetes.io/2018/03/kubernetes-1.10-stabilizing-storage-security-networking.html

как etcd поживает? не увели у вас инфу?

разве есть кто-то, кто не знает, что етсд по-умолчанию открыт, а авторизация настроена максимум на апи-сервер?

а зачем эти знания?

чтоб быть добрее

А смысл держать etcd С доступом во внешнюю сеть. Это же внутренний ресур облака

Но вообще говоря интересно почитать про плюсы и минусы тех или иных сетевых решений для сабжа

Не поймешь пока не попробуешь их все :)

А смысл держать etcd С доступом во внешнюю сеть. Это же внутренний ресур облака

а если облако только с одним внешним интерфейсом?)

а если облако только с одним внешним интерфейсом?)

А это тут причем? Или у тебя все узлы онли с внешними интерфейсами?

(не у меня, но такое к нам приходит почти ежедневно) ну да. и только с внешними!)

тот же ovh. там с vrack серверы только за овер $90

как вы сливаете кубконфиги в один файл? или добавляете ещё один контекст в существующий

не. речь не про ето) А про то, зачем выставлять наружу - для связи с другими нодами.

у них есть torcx,вот пример https://github.com/lorenz/torcx-zfs

Идея класс, но как быть в случае с загрузкой нод по pxe?

Идея класс, но как быть в случае с загрузкой нод по pxe?

править загрузочный образ?

править загрузочный образ?

по моему это против идеологии CoreOS, разве нет?

Ну конечно же. Вот только кто об этом задумывается))

по моему это против идеологии CoreOS, разве нет?

ну тут либо шашечки, либо ехать)

ну тут либо шашечки, либо ехать)

На самом деле я так и делаю: Я собираю загрузочный образ debootstrap'ом вместе с pxe/nbd-сервером через Dockerfile.

Вот просто думаю есть ли у coreos решение для этого - похоже что нету.

для впиливания кастомных модулей я имею ввиду

На самом деле я так и делаю: Я собираю загрузочный образ debootstrap'ом вместе с pxe/nbd-сервером через Dockerfile.

ничесе

хотя конечно никто не мешает раздербанить стоковый образ и делать с ним что захочу, но не вижу тогда особых преимуществ coreos перед той же убунтой

хотя конечно никто не мешает раздербанить стоковый образ и делать с ним что захочу, но не вижу тогда особых преимуществ coreos перед той же убунтой

как то мы кругами ходим) Вроде как под корос есть loud-init/igniter

вроде крутая фича. но я ее еще не юзал

а как правильно добавлять новые ноды в кластер развернутый через kubespray?

сделал через scale.yml, но на новых нодах днс отвалился

при этом ни в логах calico, ни в логах kube-dns ничего подозрительного

сеть не сконфигурилась знач

подебаж с calicoctl

видят ли соседи новую ноду

спасибо, попробую

а есть ли (наверняка есть, но я лучше тут спрошу, чем гуглить) готовая штука чтобы подселить её в под и она будет следить за конфигмапом и посылать -HUP в соседний процесс в том же поде при изменении конфигмапы?

https://github.com/jimmidyson/configmap-reload во нашёл

Всем привет, подскажите как правильно накатывать миграции на бд из кубера. База стоит с наружи. Схема бд в коде, миграции делаются через dll+bash. Сейчас основное смущение вызывает если реплик 6, тт миграция запустится 6 раз.

а по уже живущей базе процесс запуска миграций не умеет опеределять надо ли запускать миграции?

Идея класс, но как быть в случае с загрузкой нод по pxe?

Ignition скачает и положит нужный torcx на этапе initrd

По этому Ignition и мега фича, работает еще до того как сама система стартует, все файлики в нужные места раскладывает

Всем привет, подскажите как правильно накатывать миграции на бд из кубера. База стоит с наружи. Схема бд в коде, миграции делаются через dll+bash. Сейчас основное смущение вызывает если реплик 6, тт миграция запустится 6 раз.

kubernetes jobs - echo "Running migrations..." - kubectl delete job vouch-backend-db-migrate --cascade - kubectl create -f .kube/jobs/migrate.yaml -o yaml --dry-run | sed -e "s/:latest/:${CI_BUILD_REF:0:7}/" | kubectl replace --force -f - - until kubectl get pods --show-all --selector=job-name=vouch-backend-db-migrate --output=jsonpath={.items..status.phase} | grep Succeeded; do sleep 5;done - kubectl logs $(kubectl get pods --show-all --selector=job-name=vouch-backend-db-migrate --output=jsonpath={.items..metadata.name}) p.s. это было написано еще когда не было kubectl apply

а по уже живущей базе процесс запуска миграций не умеет опеределять надо ли запускать миграции?

Понимание у базы есть что нужно делать эмиграцию. Но вернется метод update столько раз сколько реплик поднято, но 1 реально обновит, а остальные вхолостую отработают