Комментарии 13
А что делать если для запуска кубернетес надо настроить свитчи, а их не настроить потому что нужен кубернетес?
В статье я исхожу из того, что в рассматриваемой инфраструктуре есть сеть управления, к которой подключены свитчи, требующие настройки, и в которой развернут кубернетис. То есть добиться полной и бесповоротной автоматизации, как мне кажется, невозможно. Об этом, конечно, нужно было упомянуть.
так ZTP же
оно как раз под нулевой уровень деплоймента придумано (настройка интерфейса управления, авторизации итп)
а я как раз хотел вопрос задать где в ваших структурах поля для OOB интерфейсов :)
а оно уже задеплойменд (тоже кубернетисом?)
ну ок тогда другой вопрос:
А не думали BGP unnumbered использовать?
Насколько я знаю Sonic умеет в FRR а тот в свою очередь в BGP unnumbered
используя который отпадает необходимость возиться с пиринговыми /30 сетками
А где у вас оверлей? на лифах или дальше на хостах с куберами?
так ZTP жеоно как раз под нулевой уровень деплоймента придумано (настройка интерфейса управления, авторизации итп)
про ZTP вообще не думал, если честно. Но это все же несколько другое - как раз на случай предподготовки. А у меня уже дальнейшая настройка рассматривается. Но вообще идея мне нравится, надо будет подумать, можно ли вписать ZTP в процесс онбординга оборудования.
ну ок тогда другой вопрос:
А не думали BGP unnumbered использовать?Насколько я знаю Sonic умеет в FRR а тот в свою очередь в BGP unnumberedиспользуя который отпадает необходимость возиться с пиринговыми /30 сетками
Думал и как раз его и буду использовать. Об этом речь пойдет во второй части, когда дойду до непосредственной настройки свитча. Что касается /30 подсетей - знаю, что Cumulus на случай BGP Unnumbered имеет пул ipv6 адресов из которых назначает адреса на интерфейсы, чтобы строить соседство. Возможно SONiC действует подобным образом,но это вносит некую долю неопределенности в части адресов. А я таким образом лишаю этот момент неопределенности и в любой момент времени могу точно сказать, какой адрес на интерфейсе и у соседа.
этот пул ipv6 адресов это обычные linklocal unicast fe80::/10
поэтому никакой неопределенности
какой-то адрес там обязательно будет, но при этом настраивать его нет необходимости
ZTP - это де-факто стандарт первичной настройки в ДЦ сетях
А вот уже day0+ управление ДЦ сеткой через k8s весьма зачетный подход.
Я правильно понял, что у каждого коммутатора свой номер AS и на аплинках он использует eBGP? Это типовая практика в ЦОДах вообще или в ЦОДах Вашей организации?
Да, все верно. Не берусь утверждать насчет типичности подобного решения, но уверен, что оно достаточно распространено. Все равно существует конечное количество решений по дизайну underlay сети. Почему был выбран именно eBGP? Потому что в случае с iBGP, потребовался бы, во-первых, IGP - т.к. маршруты строим на loopback'ах и кто-то должен сообщать, как до них добраться, во-вторых, либо full-mesh топология, либо делать спайны route-reflector'ом. В случае же с eBGP в этом нет необходимости.
ну так spine-ы назначаешь RR и тоже никаких проблем.
единственно нужно чтоб они next-hop-self еще меняли на свой
есть еще компромиссная архитектура когда спайны все в одной ASN, а все лифы в другой ASN, общей для всех.
Тут тебе и eBGP без фулмешей или RR,
и при этом не нужно париться выдумывать номер ASN для каждого лифа
А лично мне и OSPF на андерлее норм (разумеется unnumbered). Но у меня не ЦОД, а так - цодик
есть еще компромиссная архитектура когда спайны все в одной ASN, а все лифы в другой ASN, общей для всех.Тут тебе и eBGP без фулмешей или RR,и при этом не нужно париться выдумывать номер ASN для каждого лифа
да, но тогда надо поддерживать список уже назначенных ASN, на случай если у меня будет два дерева свитчей
Спасибо! Уже жду продолжения
И вопрос:
>> Единственным маркером роли коммутатора – leaf или spine – выступает наличие подключенной полезной нагрузки
ну ... эээ ... но зачем же так ?
А если немного приземлиться из облаков и куберов этих ваших хипстерских. Ну ведь там же на земле еще кто-то кейблингом занимается. А значит должен отличать лиф от спайна по этикетке, модели или цвету свича. Ну и вам там высоко в облаках кто мешает заранее свич пометить? Например в имени свича роль лиф/спайн закодировать пока IP адрес управления ему задаете, ну и/или ориентироваться по железу ведь на роли лиф/спайн ставят разные по модели свичи примерно всегда. Хотя самое простое и очевидное брать роль по cерийнику из того же IPAM/DCMN
Как я автоматизировал настройку коммутаторов в дата-центре с помощью Kubernetes