кто может подсказать оффициальный контейнер с curl внутри? желательно minimal

типа alpine

нашел. docker.

в ubuntu вроде есть, но он не минимальный

По поводу сети тоже интересно

какие Pros/Cons

Flannel/Weave/VPN

weave - скорость говно. flannel на udp - скорость говно flannel на vxlan - скорость норм, но говно ввиду инкапсуляции. VPN - это общее слово, непонятно, что здесь имеется в виду. calico/custom routed - збс.

http://chunqi.li/2015/11/15/Battlefield-Calico-Flannel-Weave-and-Docker-Overlay-Network/

отличный тест. ничего о скорости сходимости. ничего о скорости передачи данных. ничего о потреблении cpu.

мне тоже не понравился поста, разве что даёт какую-то вводную

всё равно всё самим

подскажите, http://kubernetes.io/docs/getting-started-guides/scratch/#etcd дошёл до запуска etcd, kubectl у меня всё ещё ругается на The connection to the server 10.128.13.22 was refused - did you specify the right host or port?

из запущенного у меня: докер, kubelet, kube-proxy через системд

ну и соответственно что-то должно висеть Oct 7 13:37:34 by1-depl-k8s-1 kubelet: E1007 13:37:34.675115 6293 reflector.go:203] pkg/kubelet/kubelet.go:387: Failed to list *api.Service: Get https://10.128.13.22/api/v1/services?resourceVersion=0: dial tcp 10.128.13.22:443: getsockopt: connection refused

что я не доконфигурил?

kubelet/kube-proxy хотят в апи, апи поднимается подом, его ещё поднять не успел, или нет?

порт.

kubeletа порт нужно задать, да?

куда его?

Get https://10.128.13.22/api/v1/services?resourceVersion=0

ну хоть какой то тест

судя по всему идет обращение на 443-й порт. а нужно, вероятно, на какой-то другой.

судя по всему идет обращение на 443-й порт. а нужно, вероятно, на какой-то другой.

они пока обращаются непонятно к кому, ничгео ж не поднято

Вот кстати как получить последние евенты? что-то типа tail -f -1 ?

правильно я понимаю что большинство живут с calico? и это как бы сейчас recommended?

а openvswitch?

я сразу калико настраивал исходя из обзоров. но я пока только играюсь и в бою не использую

я использовал кастомную сеть с выделением /24 на хост.

они пока обращаются непонятно к кому, ничгео ж не поднято

и судя по дизайн документу https://github.com/kubernetes/kubernetes/blob/master/docs/design/architecture.md kubectl идет в апи, а чтобы поднять аписервер, нужно чтобы работал kubectl. Я сломался

насчет tail и -1: вот такое решение придумал: curl "http://localhost:8080/api/v1/watch/events?resourceVersion=$(curl -s http://localhost:8080/api/v1/events | jq -r '.metadata.resourceVersion')"

я использовал кастомную сеть с выделением /24 на хост.

кастомную это какую? есть пример?

Ну без автоматики/calico/anything else. Всё хозяйство делится на зоны. В моем случае это кусочки датацентров. N зон (до ~256 с выбранной адресацией). Каждая зона содержит до ~250 нод. Также в каждой зоне содержится 2 или более GW. На GW присутствуют внешние адреса. Они обеспечивают NAT во внешний мир и связность с остальными зонами. Внутри зоны - один L2-домен. Между всеми GW построен multipoint GRE, на него выделена /23 сеть. Между всеми GW ходит OSPF. На каждом GW исходящий в сторону внешних сетей натится в провайдерскую сеть. На каждую зону выделяется /24 сеть для хостов и /16 сеть для контейнеров. Например, 172.16.$zone.$node - адрес ноды, 10.$zone.$node.0/24 - сеть для контейнеров. Бридж создается вне докера, на него навешивается со стороны хоста адрес 10.$zone.$node.1. Докеру указано выдавать адреса из 10.$zone.$node.0/24. В каждой зоне ходит свой отдельный OSPF (связанный с backbone OSPF через GW). Каждая нода анонсирует свою подсеть для контейнеров в этот OSPF. Все остальные ноды на площадке ловят эти маршруты и прописывают их себе в таблицу маршрутизации. Также эти анонсы ловят GW и передают на остальные площадки, возможно агрегируя маршрут. voilla. В принципе, все можно построить на статической маршрутизации, но: 1) OSPF обеспечивает очень быструю сходимость сети. 2) OSPF обеспечивает ECMP-роутинг между площадками и во внешний мир. Если необходимо увеличить пропускную способность - можно поставить больше GW на площадку. 3) По сравнению с решением dumb L2, L2-домены остаются весьма небольшого размера, лишая нас стандартных L2-проблем 4) Решение потенциально хорошо дружит с сетевым железом и в других архитектурах (например, когда нет возможности иметь L2-домен на зону). Вообще, получилось что-то вроде calico, только на OSPF и без cli-tools.

👍

тут есть проблема с потенциальным недостатком адресов. ждем ipv6 в k8s.

а виртуальную подсеть для сервисов как приземляли?

а зачем ее приземлять? она существует же только в пределах хоста.

или все было в облаке?

у меня много ресурсов вне облак, я потихоньку хочу переносить по сервисам внутрь куба

пока NodePort спасает

но не гибко

а, вопрос как трафик снаружи внутрь попадает?

А есть кто на Azure? Какой конфиг? Какие подводные камни?

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

пока что сторонние сервисы засовываю в куб

А есть кто на Azure? Какой конфиг? Какие подводные камни?

Я на azure собираю, но не пользуюсь их сборками, только на виртуалках.

Из подводных камней, это сети между подписками и нет нормального распределенного хранилища.

Из подводных камней, это сети между подписками и нет нормального распределенного хранилища.

Вот смотрю у них для Azure два варианта: Azure CoreOS CoreOS Weave Azure Ignition Ubuntu Azure вы, так понял, свой какой-то сделали? Можно поподробнее? Распределенное хранилище - это имеется ввиду etcd? Но он же на мастере поднимается, или я что-то не так понял?

Распределенное хранилище имеется ввиду ceph или подобное.

Я просто поднял 3 виртуалки Ubuntu на трех подписках и уже игрался с ними

Ясно, спасибо. Вот еще в AWS можно их ELB к сервисам прикручивать. А азуровские балансеры можно так?

Да, но они TCP онли

балансерами не игрался

спасибо

ну, TCP/UDP, не L7

Вольюмы тоже работают

понял

Костыль, но зато я теперь kubernetes events не теряю https://github.com/kayrus/elk-kubernetes#forward-kubernetes-events-into-kibanaelasticsearch

Энибади с логами в ELK в кубере, как вы его чистите, чтобы он не рос бесконечно?

индексы чисть

Руками? Или есть что то по расписанию?

есть

https://github.com/elastic/curator

Да я его тоже загуглил, есть какая нить бестпрактиз как его запускать совместно с курьером?

ну либо крон

либо под с sleep

и while true

Т9 рулит

Ясно, спасибо)

https://hub.docker.com/r/lukaspronto/docker-curator-cron/

Вот еще нагуглилось, мб кому то пригодится

А вот еще вопрос что с этими логами делать ибо их доструя ) может дашборды какие

да в чем проблема? делай сам.

строишь, например, запросы только ошибочных логов. и анализируешь

Лениво, вдруг че есть )

ну с таким подходом тебе никакие kibana не нужны )

логи тогда можно в /dev/null гнать, чтобы место не занимали)

а у него есть шардинг?

У ластика точно есть

всем утро я тут думал что самый хитрожопый и смогу статику пихать в configmap чтобы потом ее nginx подхватывал но по факту выяснилось что configmap не умеет директории :) в связи с этим хочу поднять вопрос еще раз: кто как статику деплоит?