
Andrey
20.10.2018
13:14:44
и dnsPolicy, опять же

Banschikov
20.10.2018
13:16:05

Andrey
20.10.2018
13:16:16

Google

Banschikov
20.10.2018
13:16:16
ну да
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}

Andrey
20.10.2018
13:17:03

Banschikov
20.10.2018
13:18:24

Andrey
20.10.2018
13:18:44
А зайди в шелл в поде coredns и выведи /etc/resolv.conf

Banschikov
20.10.2018
13:20:00
Сейчас гляну
ну тут порядочек вроде
Вообщем добрался сейчас наткнулся на эту ссылку:
https://stackoverflow.com/questions/52645473/coredns-fails-to-run-in-kubernetes-cluster
Проблема свежая как я понял, и там решили ее выпилив из configmap loop
Я попробовал, и у меня тоже заработало.

kvaps
20.10.2018
13:32:12
я проблему с systemd-resolved решил радикально:
apt-get install -y resolvconf
systemctl disable systemd-resolved
systemctl mask systemd-resolved

Andrey
20.10.2018
13:42:07
@f545_j_43g43u_jer3tfgu32fh3333 проверь плз этот момент
чет самому интересно стало

Banschikov
20.10.2018
14:08:09

Google

Anton
20.10.2018
15:08:27
хотите холиварную тему?
https://toster.ru/q/572584

Эдуард
20.10.2018
15:08:55
Bsd vs linux?

Никита
20.10.2018
15:09:40
patroni
/thread

Эдуард
20.10.2018
15:09:48

M
20.10.2018
15:10:47

Aleksey
20.10.2018
15:11:15

Эдуард
20.10.2018
15:11:16

M
20.10.2018
15:11:41

Эдуард
20.10.2018
15:12:05
Системные индексы померли

M
20.10.2018
15:12:10
Имел убитый в оном
у меня крутится на дев не супер важная база но тоже думал перенести ее в кубер

Никита
20.10.2018
15:12:24

Эдуард
20.10.2018
15:12:34
Благо тестовый стэнд был
Пересоздали в итоге, восстановить не полуяилось

Никита
20.10.2018
15:13:01
А чего плохого в постгресе в докере (при условии, что данные хранятся в вольюме)?

Эдуард
20.10.2018
15:14:03
Та сдохшая была на 600 гб
rpc бешенный, ибо гео
3 месяца аптайма

Google

Anton
20.10.2018
15:16:55
пояснишь?
что пояснить? некоррекно вопрос написал? могу поправить

Dmytro
20.10.2018
15:24:42

Никита
20.10.2018
15:25:20
3 месяца аптайма
Я не совсем правильно сформулировал, моя цель не предъявить, а обсудить. Ну, то есть, разница в том, что процесс работает не в системных неймспейсах, а в отдельных, ну и капабилити ограничены. И я пока не очень понимаю, как это может на смерть индексов повлиять.

Dmytro
20.10.2018
15:25:59

Let Eat
20.10.2018
15:31:07

Vadim
20.10.2018
15:32:09
Я
я тут наскоком решил взять этот холм - там bootstrap нода сначала работает как мастер по тому же адресу в ДНС - а потом нужно перевести адрес на настоящий мастер?

Let Eat
20.10.2018
15:33:44

Vadim
20.10.2018
15:35:44
ага, просто не ясно отчего у меня на bootstrap контролплейн самоудалился, а ноды стучатся на старый адрес
похоже что "можа так i трэба", только странные эти танцы с днс'ом

kvaps
20.10.2018
15:51:27

Vadim
20.10.2018
15:51:57
чтобы собирать кластер из ignition конфигов

kvaps
20.10.2018
15:54:10
а он только конфиги генерит? или имаджи coreos тоже в его зоне ответственности? - что то до конца не могу понять его логику

Vadim
20.10.2018
15:59:53
из ignition/whatever генерится одна нода с описанием всего кластера, она временный мастер, который создает полноценный кластер
для будущих нод она умеет раздавать ignition/whatever конфиги, которые достаточны для поднятия ноды

kvaps
20.10.2018
16:05:06
ага, а я правильно понял что он нужен именно для деплоя нод с coreos, а не для организации живой загрузки по pxe?

Vadim
20.10.2018
16:17:24
не знаю как работает игнишен с bare metal, но думаю можно подпилить и под него, чегоб и нет

Grisha
20.10.2018
16:30:18
Ребзя, подскажите. как сервису выдать ип из общей сети нод (не кубера)? например 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
вот так ip появляется, но маршрутизации то нету

Banschikov
20.10.2018
16:31:29

Google

Никита
20.10.2018
16:32:21

Grisha
20.10.2018
16:32:28
моя не понимать, что ты имеешь ввиду?
ip хард ноды 10.2.0.1, у него есть табл маршрутизации в которой указано че как делать с пакетами из этой сети
я думал он делает алиас на интерфес хард ноды или что-то около того

Никита
20.10.2018
16:34:24

Grisha
20.10.2018
16:34:38
но по факту получает что адрес я накинул http://prntscr.com/l8co9g
он указан в ext, но как же туда попасть?))

Anton
20.10.2018
16:35:17

Никита
20.10.2018
16:37:45

Grisha
20.10.2018
16:38:08
это же nat, а я хочу выделать совсем другие ip
из сети нод

Никита
20.10.2018
16:39:50
Прямо из сети нод нельзя и NAT там будет в любом случае.

Stanislav
20.10.2018
16:40:21

Banschikov
20.10.2018
16:42:02
чет самому интересно стало
Вообщем попробовал обновить docker до 18.03, проблема осталась. Если что ось Debian 9.5. Завтра на Ubuntu протестирую

Grisha
20.10.2018
16:42:58

Anton
20.10.2018
16:44:42

Stanislav
20.10.2018
16:47:32
Я ж говорю - тема холиварная :-)
Но сейчас мне холиварить - влом, если честно. Впрочем, тут вообще всё зависит от того, нафига нужна БД. Для "поизвращаться и выбросить" - конейтенеры в самый раз. Для "чтоб 5 лет проработало" - лучше что-то менее эфемерное.

bebebe
20.10.2018
16:48:15
А вот и специальная олимпиада подъехала. Нормально же общались

Никита
20.10.2018
16:48:35
Кароч есть три сети - сеть подов, сеть сервисов, и сеть, в которой твои ноды находятся. Первые две существуют изначально только внутри кубернетеса, но их можно задать руками при создании кластера.
Соответственно, PodIP выделяется из сети подов, ClusterIP - из сети сервисов.
ClusterIP при создании с помощью kube-proxy вешается на специально созданный лупбек-интерфейс на всех нодах, также на всех нодах конфигурится балансер для приходящего на пару ClusterIP:ServicePort трафика через ipvs или iptables, в качестве бакендов будут пары PodIP:PodPort . При балансировке, очевидно, будет делаться фулл нат.
Сервисы типа ClusterIP, NodePort, LoadBalancer используют схему с ClusterIP под капотом.

Andor
20.10.2018
16:48:52
Если спросить щас кого-нибудь, у кого бд живёт уже пять лет, думаю 0 человек скажут, что они в кубере живут

Google

bebebe
20.10.2018
16:49:37

Grisha
20.10.2018
16:49:49
Кароч есть три сети - сеть подов, сеть сервисов, и сеть, в которой твои ноды находятся. Первые две существуют изначально только внутри кубернетеса, но их можно задать руками при создании кластера.
Соответственно, PodIP выделяется из сети подов, ClusterIP - из сети сервисов.
ClusterIP при создании с помощью kube-proxy вешается на специально созданный лупбек-интерфейс на всех нодах, также на всех нодах конфигурится балансер для приходящего на пару ClusterIP:ServicePort трафика через ipvs или iptables, в качестве бакендов будут пары PodIP:PodPort . При балансировке, очевидно, будет делаться фулл нат.
Сервисы типа ClusterIP, NodePort, LoadBalancer используют схему с ClusterIP под капотом.
куда не плюнь без фул ната не обойтись?

Andor
20.10.2018
16:49:52

Anton
20.10.2018
16:50:31

Andor
20.10.2018
16:51:00
Если оно работало в lxc пять лет назад, то скорее всего оно так и работает ;)

Stanislav
20.10.2018
16:51:15
Кто ж работающее ломает?
А для переезда из lxc в docker/k8s - пришлось бы

Sergey
20.10.2018
16:51:49

Andor
20.10.2018
16:51:55
Обфусцирует

Anton
20.10.2018
16:52:11

Andor
20.10.2018
16:52:32
Патрони
Или вообще на старом добром corosync/pacemaker

Banschikov
20.10.2018
16:53:05

Stanislav
20.10.2018
16:53:25
а чо не сразу keepalived? :-)

Andor
20.10.2018
16:53:28
Ну оно как пять лет назад работало, так и сейчас работает


Никита
20.10.2018
16:53:43
Кароч есть три сети - сеть подов, сеть сервисов, и сеть, в которой твои ноды находятся. Первые две существуют изначально только внутри кубернетеса, но их можно задать руками при создании кластера.
Соответственно, PodIP выделяется из сети подов, ClusterIP - из сети сервисов.
ClusterIP при создании с помощью kube-proxy вешается на специально созданный лупбек-интерфейс на всех нодах, также на всех нодах конфигурится балансер для приходящего на пару ClusterIP:ServicePort трафика через ipvs или iptables, в качестве бакендов будут пары PodIP:PodPort . При балансировке, очевидно, будет делаться фулл нат.
Сервисы типа ClusterIP, NodePort, LoadBalancer используют схему с ClusterIP под капотом.
Теперь, хорошие новости в том, что при использовании сетевых плагинов, основанных на маршрутизации, типа calico, kube-router, в сеть подов и сеть сервисов можно попасть, если знать к ним маршруты. Собственно, внутри кластера они по дефолту будут (их распространит сетевой плагин), а вот внешним хостам их можно как-нибудь сообщить, например, через BGP (что эти сетевые плагины тоже умеют). Можно хоть статические маршруты прописать, однако это не очень хороший путь, так как при изменении состава кластера их придётся обновлять вручную.


Anton
20.10.2018
16:53:46

Stanislav
20.10.2018
16:54:07
/me припомнил, что на текущей работе основная БД как была на отдельной виртуалке 10 лет назад, так и осталась

Anton
20.10.2018
16:54:27

Stanislav
20.10.2018
16:54:32
50Гб