Провайдер только рад будет если абонент подключится по тарифу юрлица. Да, были такие случаи, ребята подключались. Речь идёт о 20-30 тысячах рублей в месяц за 100 мегабит скорости - или, по крайней мере, шла раньше. Сейчас может и дороже стало.
Ограничивают не качальщиков, ограничивают абонентов которые сутками напролет забивают аплинк. Когда условия позволяли (например, достаточно 2 свитча заменить) - ставили свитчи с 10г аплинками. Когда не позволяли - шейпили такого абонента сверху и снизу, что бы остальные могли пользоваться интернетом.
Так уже можно отрендерить HCL в yaml/json и положить в куб + секрет рядом. Автор изначальной статьи хотел именно HCL унести в куб. что бы kubectl get pod -o hcl возвращал hcl. И что есть бред.
Так это отдельный объект в etcd, этот secret. На сам-то кубовый обьект и взаимодействие куба с этим объектом он не влияет. А если HCL тащить в куб - то будет как, обьект deployment, состояние которого неизвестно если secret не прочитать?
yaml/json - языки описывающие объекты, конвертируются друг в друга легко и непринужденно, внешние вызовы "не умеют". Хочешь динамическое значение - рендери тот же YAML чем-то снаружи. HCL же вообще из другой области и представляет собой DSL с вызовами, для задач кубера не подходит примерно никак. Если предлагается хранить голый HCL в etcd, с его "random_string" и ко - то придется тащить аналог terraform state в тот же etcd, что бред по многим причинам. Если рендерить HCL в что-то статичное (да тот же yaml) - то это и сегодня можно сделать. Резюмируя - идея бредовая.
etcd прекрасно работает от 1й ноды and up. Скейлится мощнейще. Посмотрел на домашнем кластере из 3х нод etcd - суммарное потребление 3х инстансов = 108m cpu, 1208Mi ram. Весьма скромно. Не совсем понятно о каком lower-end k8s experience он говорит - кластер из трех Raspberry pi 4?.. Так даже они начинаются с 8гб рамы теперь... Просто так прикручивать альтернативы - классическое "решение, ищущее проблему".
Helm да, стал стандартом при этом имея тонну лютых недостатков. Заменить его было бы очень хорошо.
IPv6 "в дефолте" - зачем? Дебаг усложнить? Приведенные проблемы решены текущим дизайном куба с самого начала. 4.1) Общаться "pod-pod по внутренним айпи между кластерами" - бред, специально для этого созданы сервисы и ингрессы. IPv6 проблему "мы выдали две одинаковых серых сети двум кластерам и хотим в нарушение всех концептов k8s общаться pod-pod между кластерами, но у нас внутренние ip пересекаются" не решит никак. 4.2) NAT в кубе, в общем-то, простейший. Один на входе в сервис, если у того 'internalTrafficPolicy: Cluster' стоит. Конкретный случай он не описал, а каких-то широкоизвестных "NAT-проблем" у кубера и нет. 4.3) Так и IPv6 можно выдать /116 на весь кластер и так же внезапно "кончатся адреса". Вопрос планирования.
Вообще через весь его спич про IPv6 сквозит "я хочу роутиться к подам напрямую, мимо сервисов и ингрессов, но нормально спланировать это не могу".
Резюмируя - три откровенно бредовых идеи и одна нормальная. Meh.
Так это... Сотрудников мосводоканала уже мобилизовали. Сначала начальники уговаривали пойти добровольцами, потом неск-ко дней росгвардия и 3 автозака крутились рядом с офисом на Бауманской, раздавали повестки.
Можно, конечно, жить без автодополнения - которое предоставляют всякие ластпассы и битвардены - но это крайне неудобно. Каждый раз открываем термукс, вспоминаем магические числа... Проще уж десяток-другой паролей помнить :-)
Я так понимаю, вы сейчай про модель OSI говорите. Она концептуально-условная, служит только для для разделения "слоёв". Никаких реальных зависимостей там нет.
В реальности оказалось удобно обмениваться маршрутами через прокотокол построенный на TCP. Перенос BGP ниже - если, например, накостылять какой-нить MAC-BGP где будут только MAC-адреса в заголовках - смысла не имеет. Что так апдейты пропадут и l3 уйдёт, что так.
Киллер-фича нетплана — netplan try. Работает как commit confirmed на junos.
Сам формат конфига на порядок лучше /etc/network/interfaces (всё лучше него) и вполне сравним по читабельности с /etc/sysconfig/network-scripts. Ну и предполагается что его заадоптят остальные дистрибьютивы, добавив бекенды для своих чудоскриптов.
Каком ключе? Ключ только позволяет убедится что MITM не было, никакой подписи бинарей нет (как минимум в pacman/yum(dnf)/apt). Ставят Obsoletes: Bash в своем spec-file (PKGBUILD, whatever) и понеслась.
MSRP для того же 9400F соответствует реальной retail цене 2600 box. Только при практически тех же частотах (3.9 против 4.1 при нагрузке на 6 ядер) у 2600 есть SMT и разлочен множитель.
У остальных процессоров ситуация та же или хуже — MSRP 9600KF (6с/6t) всего на пару тысяч меньше реальной цены 2700 (8c/16t).
Для кого предназначены эти процессоры?..
Провайдер только рад будет если абонент подключится по тарифу юрлица. Да, были такие случаи, ребята подключались. Речь идёт о 20-30 тысячах рублей в месяц за 100 мегабит скорости - или, по крайней мере, шла раньше. Сейчас может и дороже стало.
Ограничивают не качальщиков, ограничивают абонентов которые сутками напролет забивают аплинк. Когда условия позволяли (например, достаточно 2 свитча заменить) - ставили свитчи с 10г аплинками. Когда не позволяли - шейпили такого абонента сверху и снизу, что бы остальные могли пользоваться интернетом.
Провайдер вправе ограничить любой трафик - хоть весь, хоть выборочно с/до одного адреса. Или один протокол. Читайте, пожалуйста, договор. Например ростелекома ( https://rt-static.rt.ru/sites/default/files/doc/Edinye_pravila_okazania_uslug_FZ.pdf ), особенно пункты 3.2.5, 3.4.11.
Так уже можно отрендерить HCL в yaml/json и положить в куб + секрет рядом. Автор изначальной статьи хотел именно HCL унести в куб. что бы kubectl get pod -o hcl возвращал hcl. И что есть бред.
Так это отдельный объект в etcd, этот secret. На сам-то кубовый обьект и взаимодействие куба с этим объектом он не влияет. А если HCL тащить в куб - то будет как, обьект deployment, состояние которого неизвестно если secret не прочитать?
По замене yaml/json на HCL
yaml/json - языки описывающие объекты, конвертируются друг в друга легко и непринужденно, внешние вызовы "не умеют". Хочешь динамическое значение - рендери тот же YAML чем-то снаружи. HCL же вообще из другой области и представляет собой DSL с вызовами, для задач кубера не подходит примерно никак. Если предлагается хранить голый HCL в etcd, с его "random_string" и ко - то придется тащить аналог terraform state в тот же etcd, что бред по многим причинам. Если рендерить HCL в что-то статичное (да тот же yaml) - то это и сегодня можно сделать. Резюмируя - идея бредовая.
etcd прекрасно работает от 1й ноды and up. Скейлится мощнейще. Посмотрел на домашнем кластере из 3х нод etcd - суммарное потребление 3х инстансов = 108m cpu, 1208Mi ram. Весьма скромно. Не совсем понятно о каком lower-end k8s experience он говорит - кластер из трех Raspberry pi 4?.. Так даже они начинаются с 8гб рамы теперь... Просто так прикручивать альтернативы - классическое "решение, ищущее проблему".
Helm да, стал стандартом при этом имея тонну лютых недостатков. Заменить его было бы очень хорошо.
IPv6 "в дефолте" - зачем? Дебаг усложнить? Приведенные проблемы решены текущим дизайном куба с самого начала.
4.1) Общаться "pod-pod по внутренним айпи между кластерами" - бред, специально для этого созданы сервисы и ингрессы. IPv6 проблему "мы выдали две одинаковых серых сети двум кластерам и хотим в нарушение всех концептов k8s общаться pod-pod между кластерами, но у нас внутренние ip пересекаются" не решит никак.
4.2) NAT в кубе, в общем-то, простейший. Один на входе в сервис, если у того 'internalTrafficPolicy: Cluster' стоит. Конкретный случай он не описал, а каких-то широкоизвестных "NAT-проблем" у кубера и нет.
4.3) Так и IPv6 можно выдать /116 на весь кластер и так же внезапно "кончатся адреса". Вопрос планирования.
Вообще через весь его спич про IPv6 сквозит "я хочу роутиться к подам напрямую, мимо сервисов и ингрессов, но нормально спланировать это не могу".
Резюмируя - три откровенно бредовых идеи и одна нормальная. Meh.
Так это... Сотрудников мосводоканала уже мобилизовали. Сначала начальники уговаривали пойти добровольцами, потом неск-ко дней росгвардия и 3 автозака крутились рядом с офисом на Бауманской, раздавали повестки.
Очень напомнило путь гугла, описанный в https://sre.google/books/ . Почитайте, там есть моменты которые вы еще не прошли и рецепты по их устранению.
На вкус и цвет. Спасибо за статью :-)
Можно, конечно, жить без автодополнения - которое предоставляют всякие ластпассы и битвардены - но это крайне неудобно. Каждый раз открываем термукс, вспоминаем магические числа... Проще уж десяток-другой паролей помнить :-)
Особенно на телефоне, да...
Я так понимаю, вы сейчай про модель OSI говорите. Она концептуально-условная, служит только для для разделения "слоёв". Никаких реальных зависимостей там нет.
В реальности оказалось удобно обмениваться маршрутами через прокотокол построенный на TCP. Перенос BGP ниже - если, например, накостылять какой-нить MAC-BGP где будут только MAC-адреса в заголовках - смысла не имеет. Что так апдейты пропадут и l3 уйдёт, что так.
Нет, интернет работает не так.
Нет keepalive = сессия падает по hold time = всё принятое из нее удаляется. Hold time обычно секунд 180.
Как сессии упадут - всем с кем есть BGP разошлются апдейты, те своим пирам разошлют и тд.
Минут 10 - и префиксов фейсбука как бы и не было никогда :-)
При наличии сертификата и ключа от него — нет. HSTS то проверяет что сертификат тот же что и был в предыдущие визиты, а он не изменится.
Сам формат конфига на порядок лучше /etc/network/interfaces (всё лучше него) и вполне сравним по читабельности с /etc/sysconfig/network-scripts. Ну и предполагается что его заадоптят остальные дистрибьютивы, добавив бекенды для своих чудоскриптов.
У остальных процессоров ситуация та же или хуже — MSRP 9600KF (6с/6t) всего на пару тысяч меньше реальной цены 2700 (8c/16t).
Для кого предназначены эти процессоры?..