Size: a a a

Kubernetes — русскоговорящее сообщество

2020 September 30

GG

George Gaál in Kubernetes — русскоговорящее сообщество
Sergey Monakhov
В чем проблема современных облаков, они все "старые", не в том смысле что там железо древнее, хотя не без этого, а в том, что вся их модель построена, на вм. У авс есть отличный костыль https://github.com/firecracker-microvm/firecracker, квм внутри квм, в 2018  году. Помоему они лямбды через него гоняют, forgate возможно хз, gcp вообще рекоменудет прогревать лямбды, а то они могут стартовать до 30сек. В итоге вам предлагают менеджет кубер, который вы сами же должны описать в терраформ или еще где, потратить на описания это кластера время, потом это поделие будет пердеть 25 минут, чтобы развернуться, потом окажется что вы забыли включить автоскейл, а для этого надо переподнять все мастера... ну ок, подождем еще 25 минут, в итоге они зарезервируют под кубер 700мб памяти и чуть ли не ядро на каждой вм, хотя вы там не собирались запускать 100500 подов и провадить космические нагрузки на кластер, но им удобно - возьмете инстанс пожирнее. А если вы развернулись в мультирегион, то простите оставить мастер в одном уже не выйдет. Это если оставить еще старые версии, csi и cni реалзиции и прочие... С этим я столкнулся в gke. Я не говорю, что терраформ это плохо, я не говорю что менеджет это плохо, просто, то как сейчас это провайдят выглядит ужасно, в моей утопии я бы хотел просто получить доступ в кластер, создавать там ресурсы и платить только за их использование вот это был бы менеджед, так менеджед

IMHO
Файркрекер это не квм в квм
источник

A

Anatoliy in Kubernetes — русскоговорящее сообщество
А можно вот с этого места: "gcp вообще рекоменудет прогревать лямбды, а то они могут стартовать до 30сек" попродробней? Где вы нашли такую рекомендацию? В холивар вступать не собираюсь, реально интересно, есть ли там такое или нет.
источник

EP

Eugene Petrovich in Kubernetes — русскоговорящее сообщество
Sergey Monakhov
В чем проблема современных облаков, они все "старые", не в том смысле что там железо древнее, хотя не без этого, а в том, что вся их модель построена, на вм. У авс есть отличный костыль https://github.com/firecracker-microvm/firecracker, квм внутри квм, в 2018  году. Помоему они лямбды через него гоняют, forgate возможно хз, gcp вообще рекоменудет прогревать лямбды, а то они могут стартовать до 30сек. В итоге вам предлагают менеджет кубер, который вы сами же должны описать в терраформ или еще где, потратить на описания это кластера время, потом это поделие будет пердеть 25 минут, чтобы развернуться, потом окажется что вы забыли включить автоскейл, а для этого надо переподнять все мастера... ну ок, подождем еще 25 минут, в итоге они зарезервируют под кубер 700мб памяти и чуть ли не ядро на каждой вм, хотя вы там не собирались запускать 100500 подов и провадить космические нагрузки на кластер, но им удобно - возьмете инстанс пожирнее. А если вы развернулись в мультирегион, то простите оставить мастер в одном уже не выйдет. Это если оставить еще старые версии, csi и cni реалзиции и прочие... С этим я столкнулся в gke. Я не говорю, что терраформ это плохо, я не говорю что менеджет это плохо, просто, то как сейчас это провайдят выглядит ужасно, в моей утопии я бы хотел просто получить доступ в кластер, создавать там ресурсы и платить только за их использование вот это был бы менеджед, так менеджед

IMHO
автоскейл можно донастроить после бутстрапа, это всего-лишь сервис
источник

GG

George Gaál in Kubernetes — русскоговорящее сообщество
Новичкам привет
источник

ЛА

Лекс АйТиБорода... in Kubernetes — русскоговорящее сообщество
George Gaál
Новичкам привет
ку
источник

U

Ugly in Kubernetes — русскоговорящее сообщество
конфа была какая то? чёт народу пришло неплохо)
источник

ЛА

Лекс АйТиБорода... in Kubernetes — русскоговорящее сообщество
нет) было упоминание в одном видосике на ютубчике
источник

ЛА

Лекс АйТиБорода... in Kubernetes — русскоговорящее сообщество
еще придут, я думаю
источник

ЛА

Лекс АйТиБорода... in Kubernetes — русскоговорящее сообщество
завтра раздуплятся, видос посмотрят, и подгребут)
источник

АЦ

Андрей Царев... in Kubernetes — русскоговорящее сообщество
Возможно ли чтобы каждый под из StatefulSet писал в свой инстанс PersistentVolume?
источник

AS

Artem Silenkov in Kubernetes — русскоговорящее сообщество
Надо заканчивать материться
источник

rd

rus dacent in Kubernetes — русскоговорящее сообщество
Ничо се. А я твои интервью поглядываю переодически. Слежу за каналом так сказтб =)
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Andru Cherny
Ребят. Вопрос по openebs. Юзаю в некоторых местах openebs-hostpath. и одну ноду из кластера нужно было слить, для утилизации. Так вот, контейнеры попытались переподнятся на другой ноде но не смогли так-как там они зависят от данных с ноды которая сливается. Есть ли какое-то решение чтобы.
1. Если пода пересоздаётся на другой ноде чтоб она сетапила себе новую pvs-шку
2. Чотб при пересоздании пода тянула за собой данные
https://github.com/kvaps/kube-fencing должно помочь
источник

ЛА

Лекс АйТиБорода... in Kubernetes — русскоговорящее сообщество
rus dacent
Ничо се. А я твои интервью поглядываю переодически. Слежу за каналом так сказтб =)
Ценю, спасибо :)
источник

rd

rus dacent in Kubernetes — русскоговорящее сообщество
Лекс АйТиБорода
Ценю, спасибо :)
👍
источник

AC

Andru Cherny in Kubernetes — русскоговорящее сообщество
крутая тема. Засторю, потом как востановлю кластер - юзну.
А может как-то так настроить openebs чтоб он это шарил. А то он у себя даже волюмы не поудалял
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Andru Cherny
крутая тема. Засторю, потом как востановлю кластер - юзну.
А может как-то так настроить openebs чтоб он это шарил. А то он у себя даже волюмы не поудалял
Ну или что-то что будет делать
 kubectl delete node

при её отвале
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Andru Cherny
крутая тема. Засторю, потом как востановлю кластер - юзну.
А может как-то так настроить openebs чтоб он это шарил. А то он у себя даже волюмы не поудалял
Шарил волумы между нодами?
источник

AC

Andru Cherny in Kubernetes — русскоговорящее сообщество
если дрейнед нода то либо отвязывать поду от pvc-шки либо перетаскивать pvc-шку на другую ноду
источник

k

kvaps in Kubernetes — русскоговорящее сообщество
Andru Cherny
если дрейнед нода то либо отвязывать поду от pvc-шки либо перетаскивать pvc-шку на другую ноду
Ну смотри в кубе у тебя есть две сущности: pvc и pv
Под каждый pvc провиженер создаёт pv и вешает на него nodeAffinity. Как только твоя нода выходит из строя тебе нужно удалить все связанные с ней ресурсы, а это: pod, volumeattachment и твой pv, который привязан к ней с nodeAffinity.

Первые две сущности удалит сам куб, как только ты сделаешь kubectl delete node. С pv сложнее, так как по логике куба, даже не смотря на то что твой pv имеет nodeAffinity, он считается cluster-wide и не заатаччен к какой-то конкретной ноде, другими словами такой механизм для них не предусмотрен.  В любом случае прежде чем сносить ноду тебе нужно на 100% удостовериться что она мертва, для этого и нужен fencing, который предоставляет тебе такую гарантию.
Чтобы снести pv, можно воспользоваться after-hook'ом, или дополнить функционал fencing-controller'а.

Ещё один момент:
Снести PV просто так нельзя, нужно так же удалить finalizer для него. Как только PV исчезнет твой PVC перейдёт в состояние Lost. Что с этим делать решать тебе,  возможно снести PVC вместе с PV было бы логичным решением, но кто создаст новый PVC?
источник