Нету там синхронности. Только очередность, где он сначала применяется. Синхронностью это выглядит исключительно для клиента.
Ну,если слейв подтвердил, потом мастер у себя подтвердил, потом клиенту подтвердил - синхронность
G72K
Sergei
network partition - это когда ты соседа не видишь, а почему - это не принципиально
я всё пытаюсь понять, откуда фантомные транзакции возникают
Sergei
можно ещё раз кейс по стадиям?
Etki
Мастер может сделать две вещи: закоммитить у себя и разослать по слейвам и в обратном порядке. В случае, если ему требуется подтверждение от слейвов, то он может разослать коммит, но не успеть принять его. Таким образом на N слейвах данные будут, а в остальном кластере их не будет.
Sergei
можно и вообще слейвам ничего не отсылать
Sergei
тогда всё сломается само
Sergei
не стараясь
Etki
D:
Sergei
но я бы рекомендовал попытаться прочитать, как работает 2pc/3pc и raft/paxos.
G72K
Мастер может сделать две вещи: закоммитить у себя и разослать по слейвам и в обратном порядке. В случае, если ему требуется подтверждение от слейвов, то он может разослать коммит, но не успеть принять его. Таким образом на N слейвах данные будут, а в остальном кластере их не будет.
Ну так клиенту никто и не подтвердит такую траназкцию. А значит ничего и не было. Важно же не терять данные с точки зрения клиента
Etki
Ну так клиенту никто и не подтвердит такую траназкцию. А значит ничего и не было. Важно же не терять данные с точки зрения клиента
нет, важна консистентность в кластере
Etki
потому что если у вас разошлись истории, вы рискуете столкнуться с тем, что транзакция применится на половине кластера
Etki
но я бы рекомендовал попытаться прочитать, как работает 2pc/3pc и raft/paxos.
мы же уже сталкивались на обсуждении рафта
G72K
нет, важна консистентность в кластере
Важно чтобы купив билет на самолет ты пришел и там было твое место )) а не так, что транщакцию клиенту подтвердили а потом потеряли
Sergei
потому что если у вас разошлись истории, вы рискуете столкнуться с тем, что транзакция применится на половине кластера
транзакция не может примениться на половине кластера, если реализовать этот алгоритм нормально.
G72K
потому что если у вас разошлись истории, вы рискуете столкнуться с тем, что транзакция применится на половине кластера
Всегда следующий мастер выбирать из неупавших, любого с максимальным щетчиком транзакций
Etki
Ну строго говоря в распределенной системе обязательно есть момент, когда транзакция применилась на определенной части кластера, потому что там невозможна атомарность
Etki
Если тольк омы не гоним все через одного мастера
Sergei
мы же уже сталкивались на обсуждении рафта
я не помню.
но щас эта дискуссия напоминает "Возьмём поезд, разгоним его до двух скоростей света. Следовательно скорость света не является предельной. Вуаля, теория относительности опровергнута!"
Etki
Он не знает, что такое конфликт )
Etki
я не помню.
но щас эта дискуссия напоминает "Возьмём поезд, разгоним его до двух скоростей света. Следовательно скорость света не является предельной. Вуаля, теория относительности опровергнута!"
Скорее, что 2pc/3pc никоим образом не гарантируют сами по себе синхронизированность данных в кластере, что для ACID недопустимо. И что при любой галере или аналогичном решении система меняет свои гарантии и нужно быть готовым, что при моргании сетки могут быть очень забавные результаты.
Sergei
ок, я не буду дальше спорить.
Sergei
(как галера себя ведет кстати - я хз, когда я ее пробовал, она была скорее сломана)
bebebe
(как галера себя ведет кстати - я хз, когда я ее пробовал, она была скорее сломана)
Ее обычное состояние
Anonymous
при условии ограниченности ресурсов и постановки безопасности на задний план - насколько плохим решением будет поднять мастера на датанодах?
G72K
А,стабильность?
Logan
при условии ограниченности ресурсов и постановки безопасности на задний план - насколько плохим решением будет поднять мастера на датанодах?
стабильность, безопасность, свободные ресурсы...
Anonymous
что значит “стабильность” в контексте кубера?
sherzod
руками перезапускать не придётся))
Sergei
что значит “стабильность” в контексте кубера?
это "иногда не падает в самом начале"
Anonymous
ну то есть по сути вопрос сводится к тому что "если ноды будут загружены по цпу/памяти то мастера начнут лажать"? или расшифруйте что имеете ввиду
sbog
ну то есть по сути вопрос сводится к тому что "если ноды будут загружены по цпу/памяти то мастера начнут лажать"? или расшифруйте что имеете ввиду
Сможешь при большой нагрузке получить недоступность API. А при очень большой и etcd в кластере сможешь получить failure этого кластера из-за каких-нибудь косвенных причин, например часы немного разойдутся.
В общем, удовольствие будет сильно ниже среднего.
Anonymous
понятно, спасибо
sbog
Это опять же, можно поправить с другой стороны, ограничив потребление ресурсов ворклоадами, но кмк оно того не стоит, проще мастерам выделить ноды, потом просто и разгребать проблемы удобнее в случае чего.
Logan
вы так шустро прибили, я даже в антиспам-группу отправить не успел, только зарепортить
Anonymous
Всем привет! Я только начал знакомство с kube. Сам FullStack/DevOps ruby/rails.
У меня вопрос: могу ли я на текущей своей VMWare ESXi создать 3 машины и поднять на них минмальный кластер ?
Anonymous
Помоему у меня ругалось на VX/T
Terry
Всем привет! Я только начал знакомство с kube. Сам FullStack/DevOps ruby/rails.
У меня вопрос: могу ли я на текущей своей VMWare ESXi создать 3 машины и поднять на них минмальный кластер ?
конечно, если у них будет своя внутрення сеть - а так скоерей всего и есть, то конечно
Terry
вопрос в том, как оно будет выходить за пределы VMvare
Terry
у меня например для теста поднято 1 мастер и 2 ноды на kvm под Proxmox
Anonymous
хм...
Vladislav
Помниться я когда брал VDS c VMware ESXi, то хостер выделял нам отдельные IP для вирт. машин имеющих соединение с vSwitch c хостовой сетевой картой. Обычно эти виртуалки я делал в роли proxy.
Vladislav
Если же запускать это хозяйство на серверах в локалной сети предприятия, то прокси не надо, можно сразу на эти машины docker лепить и k8s
Anonymous
ок спс
Ivan
Всем привет!
Друзья, кто нибудь сталкивался с таким?
Нормальный ямлик, задеплоился.. а удаляться не хочет )))
kubectl delete -f k8s/addons/cephtool.yml
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x627f44]
goroutine 1 [running]:
panic(0x1bcc980, 0xc4200100d0)
/usr/local/go/src/runtime/panic.go:500 +0x1a1...
https://gist.github.com/beatlejuse/37a6b9bc6c02fb7ff02e641dc718c738
Ivan
Ха! Нашёл багу в кубе 1.8 ))
Чтобы StatefulSet деплоился, надо чтобы apiVersion было = apps/v1
А чтобы он удалялся , надо чтобы apiVersion было = apps/v1beta2
и никак иначе))
если ямлик деплоится - то он не удаляется, а если удаляется - то не деплоится )))
Andrey
видимо сделано специально что бы statefulset никто не пользовал и все сидели на PVC =)
G72K
А ничего что apps/v1 оно в 1.9? :)
Igor
клиент/сервер мисматч версии?
Igor
или, возможно, включение какой-то альфа штуки все ломает
Maksim
видимо сделано специально что бы statefulset никто не пользовал и все сидели на PVC =)
А ни че что statefullset и pvc это разные вещи)
Andrey
какая разница)
Andrey
стейт он и в африке стейт
G72K
В v1 меняли правила удаления. То что раньше эмулировалось kubectl сейчас происходит на стороне сервера. Но это в v1 и в 1.9
Dmitrii
Коллеги, а кто нибудь пулит образы из глобального гитлаба? может кто втречался с ошибками вида:
Failed to pull image "registry.gitlab.com/projectx/deploy/django_web:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry.gitlab.com/v2/projectx/deploy/django_web/manifests/latest: denied: access forbiddenили
Jan 25 13:47:38 lab1 dockerd[23899]: time="2018-01-25T13:47:38.444623337Z" level=debug msg="Trying to pull registry.gitlab.com/projectx/deploy/django_web from https://registry.gitlab.com v2"
Jan 25 13:47:39 lab1 dockerd[23899]: time="2018-01-25T13:47:39.472449465Z" level=error msg="Attempting next endpoint for pull after error: Get https://registry.gitlab.com/v2/projectx/deploy/django_web/manifests/latest: denied: access forbidden"
Jan 25 13:47:42 lab1 kubelet[31489]: E0125 13:47:42.213614 31489 pod_workers.go:186] Error syncing pod 4d2c808c-01d6-11e8-bd9f-525400e2c3e2 ("test_default(4d2c808c-01d6-11e8-bd9f-525400e2c3e2)"), skipping: failed to "StartContainer" for "django-db" with ImagePullBackOff: "Back-off pulling image \"registry.gitlab.com/projectx/deploy/django_web:latest\""при этом секрет типа kubernetes.io/dockercfg создан и на каждой ноде присутсвует .docker/config.json
и вручную сам докер при логине к репозиторию успешно подключается.
в какую сторону порекомендуете посмотреть для решения ошибки?
Andrey
Sergei
StatefulSet и PersistentVolumeClaim - одинаково?
Maksim
Они по разному statefull.
Sergei
откуда, откуда вы, блядь, берете вторую l в слове stateful?
Sergei
"полный государств"
Игорь
откуда, откуда вы, блядь, берете вторую l в слове stateful?
Где, где вы теряете запятые?) Слово "блядь" выделяется запятыми!
Etki
там нет full
Sergei
Где, где вы теряете запятые?) Слово "блядь" выделяется запятыми!
согласен, исправил. торопился как мог.
Etki
full - это полный, ful - это такой суффикс, обозначающий принадлежность к префиксу (если грубо)
Sergei
больше меня бомбит, только когда pool и pull путают
Sergei
простите
twwlf
а poll и pull?
Andrey
а еще кто-то придумал сокращение k8s - у меня тоже бомбануло когда узнал как расшифровывается)
twwlf
ну, это довольно стандартный способ сокращений