чет самому интересно стало
Чекнул. У меня такого нет
Denis
Denis
@f545_j_43g43u_jer3tfgu32fh3333 проверь плз этот момент
Заметил что данная беда случается с k8s 1.12 и версией докера 17.03. Завтра дома попробую с более новой версией докера проверить
Anton
хотите холиварную тему?
Anton
https://toster.ru/q/572584
Eduard
Bsd vs linux?
Никита
patroni
/thread
V
да, это я
Eduard
Системные индексы померли
Eduard
Благо тестовый стэнд был
Eduard
Пересоздали в итоге, восстановить не полуяилось
Никита
А чего плохого в постгресе в докере (при условии, что данные хранятся в вольюме)?
Eduard
А чего плохого в постгресе в докере (при условии, что данные хранятся в вольюме)?
Вот сколько у тебя рпс на базе в докере, и сколько оно живёт?
Eduard
Та сдохшая была на 600 гб
Eduard
rpc бешенный, ибо гео
Eduard
3 месяца аптайма
Dmytro
Гайс, привет.
Вопрос по поводу коннекта к 2м кластерам.
Читал про контексты, вроде сделал все по доке. Но не работает. И судя по всему проблема в том что имя юзера у меня в обоих кластерах одинаковое.
Это можно как-то порешать на клиентской стороне или все же переименовывать/пересоздавать юзера?
Даа отдельных файла .kubeconfig и передавать имя файла параметром kubectl
Никита
3 месяца аптайма
Я не совсем правильно сформулировал, моя цель не предъявить, а обсудить. Ну, то есть, разница в том, что процесс работает не в системных неймспейсах, а в отдельных, ну и капабилити ограничены. И я пока не очень понимаю, как это может на смерть индексов повлиять.
Dmytro
Пока перелопачиваешь kubespray, полностью понимаешь, как именно он сетапит кластер. В случае с kubeadm/kops это совсем не так. Если заюзать в сочетании с пакером, то и новые ноды можно штамповать быстро.
Копсу можно указать как AMI юзать, kubeadm подозреваю тоже
Vadim
Я
я тут наскоком решил взять этот холм - там bootstrap нода сначала работает как мастер по тому же адресу в ДНС - а потом нужно перевести адрес на настоящий мастер?
G72K
Хмм зависит от RBAC же прописанного для SA используемого конкретным подом?
Нет, если есть права запустить под, то этот под может использовать любой secret и любой pvc из namespace, даже если service account в самом поде не может
G72K
я тут наскоком решил взять этот холм - там bootstrap нода сначала работает как мастер по тому же адресу в ДНС - а потом нужно перевести адрес на настоящий мастер?
Там запускается полный control plane как Статик поды и но что как слушает не помню
Vadim
ага, просто не ясно отчего у меня на bootstrap контролплейн самоудалился, а ноды стучатся на старый адрес
Vadim
похоже что "можа так i трэба", только странные эти танцы с днс'ом
Vadim
чтобы собирать кластер из ignition конфигов
𝚔𝚟𝚊𝚙𝚜
а он только конфиги генерит? или имаджи coreos тоже в его зоне ответственности? - что то до конца не могу понять его логику
Vadim
из ignition/whatever генерится одна нода с описанием всего кластера, она временный мастер, который создает полноценный кластер
Vadim
для будущих нод она умеет раздавать ignition/whatever конфиги, которые достаточны для поднятия ноды
𝚔𝚟𝚊𝚙𝚜
ага, а я правильно понял что он нужен именно для деплоя нод с coreos, а не для организации живой загрузки по pxe?
Vadim
не знаю как работает игнишен с bare metal, но думаю можно подпилить и под него, чегоб и нет
Grisha
Ребзя, подскажите. как сервису выдать ип из общей сети нод (не кубера)? например 10.2.0.84
spec:
externalName: 10.2.0.84
ports:
- name: http
port: 1935
protocol: TCP
targetPort: 1935
selector:
app.kubernetes.io/instance: git
app.kubernetes.io/name: depl
sessionAffinity: None
type: ExternalName
Grisha
вот так ip появляется, но маршрутизации то нету
Grisha
моя не понимать, что ты имеешь ввиду?
Grisha
ip хард ноды 10.2.0.1, у него есть табл маршрутизации в которой указано че как делать с пакетами из этой сети
Grisha
я думал он делает алиас на интерфес хард ноды или что-то около того
Grisha
но по факту получает что адрес я накинул http://prntscr.com/l8co9g
Grisha
он указан в ext, но как же туда попасть?))
Никита
он указан в ext, но как же туда попасть?))
tldr используй NodePort, так у тебя на всех нодах трафик с определённого порта будет проксироваться на поды.
Grisha
это же nat, а я хочу выделать совсем другие ip
Grisha
из сети нод
Никита
Прямо из сети нод нельзя и NAT там будет в любом случае.
Stanislav
Пипец холиварная, пара отзывов)
Вообще - да, холиварная. Только не на тему "как развернуть", а "нефиг БД высокой доступности пихать в контейнеры"
Denis
чет самому интересно стало
Вообщем попробовал обновить docker до 18.03, проблема осталась. Если что ось Debian 9.5. Завтра на Ubuntu протестирую
Grisha
Прямо из сети нод нельзя и NAT там будет в любом случае.
при использовании ингриз тоже натить прийдется?
Anton
Stanislav
Я ж говорю - тема холиварная :-)
Но сейчас мне холиварить - влом, если честно. Впрочем, тут вообще всё зависит от того, нафига нужна БД. Для "поизвращаться и выбросить" - конейтенеры в самый раз. Для "чтоб 5 лет проработало" - лучше что-то менее эфемерное.
bebebe
А вот и специальная олимпиада подъехала. Нормально же общались
Никита
Кароч есть три сети - сеть подов, сеть сервисов, и сеть, в которой твои ноды находятся. Первые две существуют изначально только внутри кубернетеса, но их можно задать руками при создании кластера.
Соответственно, PodIP выделяется из сети подов, ClusterIP - из сети сервисов.
ClusterIP при создании с помощью kube-proxy вешается на специально созданный лупбек-интерфейс на всех нодах, также на всех нодах конфигурится балансер для приходящего на пару ClusterIP:ServicePort трафика через ipvs или iptables, в качестве бакендов будут пары PodIP:PodPort . При балансировке, очевидно, будет делаться фулл нат.
Сервисы типа ClusterIP, NodePort, LoadBalancer используют схему с ClusterIP под капотом.
Andor
Если спросить щас кого-нибудь, у кого бд живёт уже пять лет, думаю 0 человек скажут, что они в кубере живут
bebebe
Anton
Если спросить щас кого-нибудь, у кого бд живёт уже пять лет, думаю 0 человек скажут, что они в кубере живут
а если оно работало в lxc -> docker -> k8s ?
Andor
Если оно работало в lxc пять лет назад, то скорее всего оно так и работает ;)
Stanislav
Кто ж работающее ломает?
Stanislav
А для переезда из lxc в docker/k8s - пришлось бы
Sergei
Andor
Обфусцирует
Anton
Кто ж работающее ломает?
ну там не совсем читый кейс при переезде добавился stolon и апнулась версия =)
Andor
Патрони
Andor
Или вообще на старом добром corosync/pacemaker
Stanislav
а чо не сразу keepalived? :-)
Andor
Ну оно как пять лет назад работало, так и сейчас работает
Никита
Кароч есть три сети - сеть подов, сеть сервисов, и сеть, в которой твои ноды находятся. Первые две существуют изначально только внутри кубернетеса, но их можно задать руками при создании кластера.
Соответственно, PodIP выделяется из сети подов, ClusterIP - из сети сервисов.
ClusterIP при создании с помощью kube-proxy вешается на специально созданный лупбек-интерфейс на всех нодах, также на всех нодах конфигурится балансер для приходящего на пару ClusterIP:ServicePort трафика через ipvs или iptables, в качестве бакендов будут пары PodIP:PodPort . При балансировке, очевидно, будет делаться фулл нат.
Сервисы типа ClusterIP, NodePort, LoadBalancer используют схему с ClusterIP под капотом.
Теперь, хорошие новости в том, что при использовании сетевых плагинов, основанных на маршрутизации, типа calico, kube-router, в сеть подов и сеть сервисов можно попасть, если знать к ним маршруты. Собственно, внутри кластера они по дефолту будут (их распространит сетевой плагин), а вот внешним хостам их можно как-нибудь сообщить, например, через BGP (что эти сетевые плагины тоже умеют). Можно хоть статические маршруты прописать, однако это не очень хороший путь, так как при изменении состава кластера их придётся обновлять вручную.