я знаю как это сделать кубером, но ты всё равно делаешь какую-то странную хрень :)

https://xakep.ru/2018/12/05/kubernetes-flaw/

https://xakep.ru/2018/12/05/kubernetes-flaw/

уже трижды обсуждено в этом чяте

breaking news!

привет. извините за тупой вопрос, но можно как-то удобнее обновлять configmap, чем через ... --dry-run -o yaml | kubectl replace -f - ? гугление удобных мне способов наводит только на открытые issue на гитхабе типа этой: https://github.com/kubernetes/kubernetes/issues/24744

на хосте

А почему kubectl apply не подходит?

имеете в виду, kubectl apply отредактированного файла с configmap?

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

чуть подробнее объясню - сейчас, например, чтобы отредактировать configmap, созданные не мной (, например, конфиг coredns) приходится экспортировать текущий конфиг, удалять из него версию и createdtime, редактировать и делать apply.

может кто-нибудь объяснить, для чего нужны StatefulSet? почему-то именно такой тип объектов рекомендуется использовать для zookeeper, но в доках kubernetes как-то слишком лаконично говорится о том, что это такое. не понимаю, в чем отличие от pod или deployment

может кто-нибудь объяснить, для чего нужны StatefulSet? почему-то именно такой тип объектов рекомендуется использовать для zookeeper, но в доках kubernetes как-то слишком лаконично говорится о том, что это такое. не понимаю, в чем отличие от pod или deployment

я правильно понимаю, что ты не понимаешь разницу между под и стейтфулсет?

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

а нельзя сделать kubectl patch на конфигмапу?

может кто-нибудь объяснить, для чего нужны StatefulSet? почему-то именно такой тип объектов рекомендуется использовать для zookeeper, но в доках kubernetes как-то слишком лаконично говорится о том, что это такое. не понимаю, в чем отличие от pod или deployment

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

а что будет с обычным подом, если он что-то пишет, допустим, в лог в persistentVolume?

Аааа, тю. Ну да.

Они нужны для прилаг, у которых есть состояние. Там есть ряд фишек, типа не убивать под просто так, запускать с постоянными именами и прочие вещи для БД.

Они нужны для прилаг, у которых есть состояние. Там есть ряд фишек, типа не убивать под просто так, запускать с постоянными именами и прочие вещи для БД.

у него будет девственно чистое состояние и он не будет помнить ничего что было раньше

где ты указываешь name?

kind: Pod metadata: name: kafka2

ты руками под создаёшь что ли?

@Andorka , что-то в доке только про patch на деплоймент. а если конфигмап не относится к деплойменту?

эм, ну конфиг прописал, kubectl create и поехали

кажется можно сделать patch на любой ресурс https://kubernetes.io/docs/reference/kubectl/cheatsheet/#patching-resources

вот, это я читал, но, прошу прощения, что значит "с постоянными именами"? я же name указываю, у меня никогда это имя не менялось у подов. это возможно при каких-то обстоятельствах?

@Andorka да

ты уверен что это то что тебе надо?

Метаданные которые ты указываешь снаружи, не видны приложению внутри. Оно как правило ориентируется на hostname(который в обычном поде из деплоймента будет генерироватся типа teamcity-deployment-7f6567bbd8-9p77t), dns(который опять же будет по такому алгоритму). А теперь представь что у тебя кластер например редисов, для которых новое имя хоста и днс - новый член кластера, изменение состояния. Старый выпал, поднялся под другим именем, считает себя например мастером. Будет момент неопределенности, который не факт что кончится хорошо.

реплики тут ни при чём

контроллер - например, Deployment или StatefulSet

Вот будут менять , в токенах будет audience и для аутентификации в волте будет отдельно свой токен, который аписервер подвердит, что такой есть, но принять его для операций не сможет https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md

Привет! Никто не в курсе, как и где openshift запускает kubelet и как получить его логи? А то я на ready ноде из под рута не вижу в выхлопе ps aux его. И вообще пока не нашел, за что зацепиться, что бы его найти. P.S. Понимаю что канал не до конца соответствует вопросу. :(

journalctl -u origin-node

руками поды создают в крайне редких случаях, когда точно знают, чего хотят

Спасибо! Уже разобрался, что в моем случае мне нужны docker logs от origin контейнера

Лог драйвер какой?

В моем случае, у меня не systemd service, а контенер с origin бегущий. Соответсвенно логи хранятся в json, как обычно для докер контейнера. Честно говоря не доконца понял вопрос.

это же только пропосал =) но да, не успеешь сделать реализацию, как она уже деприкейтед..

ребят, а как вообще kubernetes распределяет поды по нодам? Вот мне нужно StatefulSet из 4х подов, и я бы хотел чтобы всегда два пода были на одной машине, и два на другой, а при краше одной из нод не происходило так, что на одной ноде окажется 4 пода. и возможно ли так, что k8s создаст 3 пода на одной машине и 1 на другой? это как-то можно контролировать?

ребят, а как вообще kubernetes распределяет поды по нодам? Вот мне нужно StatefulSet из 4х подов, и я бы хотел чтобы всегда два пода были на одной машине, и два на другой, а при краше одной из нод не происходило так, что на одной ноде окажется 4 пода. и возможно ли так, что k8s создаст 3 пода на одной машине и 1 на другой? это как-то можно контролировать?

у тебя 4 одинаковых пода и тебе надо чтобы они были 2+2?