Forwarded from mindsellers
Про китайские стандарты
Купил я некоторое время назад себе китайскую поделку OrangePi Win Plus, одноплатный комп такой, вроде Raspberry, но мощнее. Потом оказалось, что мощь железа слихвой компенсируется отсутствием софта и дров, но не об этом речь. В целях донастройки линуха на ней, притащил я апельсинку на работу, врубил в лежавший на столе свитч и начал священнодействовать.
Прервал меня минут через 10 резкий запах горящего пластика и характерный белый дымок, исходивший от ethernet-порта платы. БП из розетки - продолжает дымить!
Все порты освободил от кабелей и приступил к вдумчивому органолептическому анализу: пощупал и понюхал. Запах и эпицентр нагрева точно прям в сетевом порту. Рядом вообще никаких микрух! Запускаю заново - все работает! Только ethernet греется... И тут до меня, не без помощи многоопытного коллеги, доходит, что сучий китайский свитч решил накормить мою игрушку PoE! Протокол, согласование - не, не слышали. Даёшь 24 вольта во все порты!
При внимательном осмотре был обнаружен истиный источник дыма - оплавлялся коннектор!!!
Что любопытно, никто из двух китайцев не пострадал! А патч-корд - да хрен с ним.
А теперь самое интересное: что ж это за волшебный свитч-пироман. https://www.gowifi.co.nz/switches/es-8-150w.html Вот эта уеба собственной персоной.
Мораль: не все то нормальное PoE, на чем написано PoE; китайцы таки умеют делать надёжные одноплатники; не надо совать свой конец куда попало.
#fuckup
Купил я некоторое время назад себе китайскую поделку OrangePi Win Plus, одноплатный комп такой, вроде Raspberry, но мощнее. Потом оказалось, что мощь железа слихвой компенсируется отсутствием софта и дров, но не об этом речь. В целях донастройки линуха на ней, притащил я апельсинку на работу, врубил в лежавший на столе свитч и начал священнодействовать.
Прервал меня минут через 10 резкий запах горящего пластика и характерный белый дымок, исходивший от ethernet-порта платы. БП из розетки - продолжает дымить!
Все порты освободил от кабелей и приступил к вдумчивому органолептическому анализу: пощупал и понюхал. Запах и эпицентр нагрева точно прям в сетевом порту. Рядом вообще никаких микрух! Запускаю заново - все работает! Только ethernet греется... И тут до меня, не без помощи многоопытного коллеги, доходит, что сучий китайский свитч решил накормить мою игрушку PoE! Протокол, согласование - не, не слышали. Даёшь 24 вольта во все порты!
При внимательном осмотре был обнаружен истиный источник дыма - оплавлялся коннектор!!!
Что любопытно, никто из двух китайцев не пострадал! А патч-корд - да хрен с ним.
А теперь самое интересное: что ж это за волшебный свитч-пироман. https://www.gowifi.co.nz/switches/es-8-150w.html Вот эта уеба собственной персоной.
Мораль: не все то нормальное PoE, на чем написано PoE; китайцы таки умеют делать надёжные одноплатники; не надо совать свой конец куда попало.
#fuckup
www.gowifi.co.nz
Ubiquiti EdgeSwitch 8 Port 150W Managed PoE Switch
Ubiquiti EdgeSwitch 8 Port 150 | Go Wireless NZ for PoE Switches
Факапы, история 2
Мы используем kubernetes в google и эта история будет про него.
У гугла с кубом довольно интересный момент, который вы не контролируете. Эти друзья могут в любой момент без предупреждения вырубить вашу ноду. Чем это для вас может грозить? Начнем с того, что окей, кубернетес умеет переподнимать убитые контейнеры, но как бы то ни было это все равно время. Хорошо, если у вас были настроены реплики и попали они на разные ноды, а гугл их вырубил в разное время. Если же нет - вас ожидает сюрприз в виде небольшого простоя. Когда умирает один контейнер и куб поднимает его на другой ноде - это все происходит быстро. Когда у вас умирает целая нода, на которой быть может 100-200-300 или больше контейнеров - это уже немножечко больно. Как минимум потому что нужно скачать образа (если их нет), а затем все это запустить. Все эти контейнеры, отправленные в свободный полет размажутся по кластеру и будут там запущены. На этом бы история закончилась, но в этот момент вылезла проблема - на нодах стала кончаться память. Как это происходит? на сервер набивается некоторое количество контейнеров, кто-то обжирается памяти, приходит OOM и прибивает обожравшийся контейнер. Верно? на самом деле нет. В реалиях ООМ убивает что под руку подвернется. Что происходит дальше? А дальше идет веселуха с Liveness, Readiness пробами. Это такой волшебный функционал, который позволяет приложению выполнять селфчек (например, доступность разнообразных бэкендов) а затем отчитываться кластеру, что приложение готово к работе. Или не готово. И тогда кластер пытается перезапустить приложение. А теперь смотрите что происходит. Перезапуск приложения по ООМ чаще всего ведет к тому что приложение мигрирует на другой сервер. Перезапуск по пробе - обычно ведет к тому что приложение локально перезапускается. Смигрировавшее на другой сервер приложение (приложения) приводят к тому, что добрый дядюшка ООМ приходит на эти сервера. И убивает их там. Или не их, а кого-то еще. Это ведет к тому, что чей-то бекенд (кого убили) может стать недоступен и из-за этого кто-то помирает по пробе. А этот кто помер по пробе снова может быть чьей-то зависимостью. И он тоже помрет по пробе. И вот такая карусель будет продолжаться пока у вас на перезапущенную ноду не приедет достаточное колиество приложений, которые с нее уехали и стали мешать другим нодам.
Вы спросите, почему не распределяется нагрузка равномерно? Всего этого можно было бы избежать, если бы были настроены лимиты. В кубернетесе существуют ограничения по ресурсам для приложения, которое можно ограничить с двух сторон - requests (сколько приложению требуется) и limits (верхний потолок сколько мы разрешаем приложению потреблять). Таким образом, вычисляется сумма всех request приложений приехавших на ноду и новые приложения, если их request < количества свободной памяти уже на ноду не приедут.
Ну и на сладкое. Гугл после перезагрузки ноды может сменить ее белый адрес. Если у вас есть какой-то внешний сервис, который по iptables ограничивает трафик и принимает его только с этого адреса ноды, вас ждет сюрприз. После ребута ноды вы можете этот трафик потерять. Придется идти и править фильтруемое значение.
З.Ы. эта история является продолжением предыдущего факапа и случилась примерно в одно и то же время с ней. Поэтому прошу не думать, что мы не учимся на своих ошибках и не ввели лимиты с прошлого раза.
#fuckup
Мы используем kubernetes в google и эта история будет про него.
У гугла с кубом довольно интересный момент, который вы не контролируете. Эти друзья могут в любой момент без предупреждения вырубить вашу ноду. Чем это для вас может грозить? Начнем с того, что окей, кубернетес умеет переподнимать убитые контейнеры, но как бы то ни было это все равно время. Хорошо, если у вас были настроены реплики и попали они на разные ноды, а гугл их вырубил в разное время. Если же нет - вас ожидает сюрприз в виде небольшого простоя. Когда умирает один контейнер и куб поднимает его на другой ноде - это все происходит быстро. Когда у вас умирает целая нода, на которой быть может 100-200-300 или больше контейнеров - это уже немножечко больно. Как минимум потому что нужно скачать образа (если их нет), а затем все это запустить. Все эти контейнеры, отправленные в свободный полет размажутся по кластеру и будут там запущены. На этом бы история закончилась, но в этот момент вылезла проблема - на нодах стала кончаться память. Как это происходит? на сервер набивается некоторое количество контейнеров, кто-то обжирается памяти, приходит OOM и прибивает обожравшийся контейнер. Верно? на самом деле нет. В реалиях ООМ убивает что под руку подвернется. Что происходит дальше? А дальше идет веселуха с Liveness, Readiness пробами. Это такой волшебный функционал, который позволяет приложению выполнять селфчек (например, доступность разнообразных бэкендов) а затем отчитываться кластеру, что приложение готово к работе. Или не готово. И тогда кластер пытается перезапустить приложение. А теперь смотрите что происходит. Перезапуск приложения по ООМ чаще всего ведет к тому что приложение мигрирует на другой сервер. Перезапуск по пробе - обычно ведет к тому что приложение локально перезапускается. Смигрировавшее на другой сервер приложение (приложения) приводят к тому, что добрый дядюшка ООМ приходит на эти сервера. И убивает их там. Или не их, а кого-то еще. Это ведет к тому, что чей-то бекенд (кого убили) может стать недоступен и из-за этого кто-то помирает по пробе. А этот кто помер по пробе снова может быть чьей-то зависимостью. И он тоже помрет по пробе. И вот такая карусель будет продолжаться пока у вас на перезапущенную ноду не приедет достаточное колиество приложений, которые с нее уехали и стали мешать другим нодам.
Вы спросите, почему не распределяется нагрузка равномерно? Всего этого можно было бы избежать, если бы были настроены лимиты. В кубернетесе существуют ограничения по ресурсам для приложения, которое можно ограничить с двух сторон - requests (сколько приложению требуется) и limits (верхний потолок сколько мы разрешаем приложению потреблять). Таким образом, вычисляется сумма всех request приложений приехавших на ноду и новые приложения, если их request < количества свободной памяти уже на ноду не приедут.
Ну и на сладкое. Гугл после перезагрузки ноды может сменить ее белый адрес. Если у вас есть какой-то внешний сервис, который по iptables ограничивает трафик и принимает его только с этого адреса ноды, вас ждет сюрприз. После ребута ноды вы можете этот трафик потерять. Придется идти и править фильтруемое значение.
З.Ы. эта история является продолжением предыдущего факапа и случилась примерно в одно и то же время с ней. Поэтому прошу не думать, что мы не учимся на своих ошибках и не ввели лимиты с прошлого раза.
#fuckup
Факапы, история 3
Очередная история про гугл и k8s. Как вы помните, у гугла существуют maintaince window, во времена которых он без предупреждения может ради обновления версии куба просто положить весь ваш кластер. Да, чтобы вы понимали, не реже раза в месяц ваши ноды будут падать. Может быть все сразу, а может по очереди. Может сегодня одна, а завтра другая. Может она поднимется за 2 минуты, а может за 25. Вы можете заплатить чуть больше денег и разнести ноды по разным регионам, но в любом случае что-то когда-то будет падать. Поэтому делать решение без репликации никак не получится, всегда должна быть реплика, которая обслужит клиента.
Эта история будет про etcd кластер. В кубе etcd можно запускать при помощи etcd-operator. И довольно-таки ошибочно думать про такой кластер, как про кубовское решение с этими всеми его шедулерами. Т.е. чтобы вы понимали, когда устанавливается оператор - он делается по всем канонам куба. Вы выкатываете helm, создается deployment, куб будет следить сам за тем чтобы оператор работал. На этом всё. Вы спросите, а откуда же тогда берется кластер? Так вот, после выкатки оператора мы должны принести в кластер один или несколько объектов под названием EtcdCluster. В котором описывается название, размер и версия etcd кластера. Оператор перехватывает событие создания такого объекта, считывает параметры и создает поды нашего кластера в указанном количестве. Что здесь кажется странным? С точки зрения k8s поды без deployment\replicaset это просто некоторый висящий в воздухе контейнер, который можно убить и никто не заплачет. Вот и получается, что всю заботу о том чтобы контейнеры кластера работали берет на себя etcd-operator.
Теперь скрестим ситуацию из первого абзаца со вторым. Если гугл кладет все ноды, то у нас падают все поды кластера. И тут самый интересный момент. Их никто не переподнимет после того как ноды рестартанут. Почему? потому что в etcd-operator заложена такая логика. Нет персистенса - нет переподнятия. В итоге, для того чтобы избежать этой попоболи в CRD нужно добавлять примерно такие строки:
Тогда для каждого пода в кластере будут созданы свои тома, и после падения все будет переподниматься. С точки зрения кластера звучит довольно логично. Ибо если упало все, кворум хрен соберешь, данные эфемерны, кто теперь реально владеет актуальной информацией - непонятно. Так что если упал один под - переподнять его логично. Если весь кластер - то только с персистенсом.
#fuckup
Очередная история про гугл и k8s. Как вы помните, у гугла существуют maintaince window, во времена которых он без предупреждения может ради обновления версии куба просто положить весь ваш кластер. Да, чтобы вы понимали, не реже раза в месяц ваши ноды будут падать. Может быть все сразу, а может по очереди. Может сегодня одна, а завтра другая. Может она поднимется за 2 минуты, а может за 25. Вы можете заплатить чуть больше денег и разнести ноды по разным регионам, но в любом случае что-то когда-то будет падать. Поэтому делать решение без репликации никак не получится, всегда должна быть реплика, которая обслужит клиента.
Эта история будет про etcd кластер. В кубе etcd можно запускать при помощи etcd-operator. И довольно-таки ошибочно думать про такой кластер, как про кубовское решение с этими всеми его шедулерами. Т.е. чтобы вы понимали, когда устанавливается оператор - он делается по всем канонам куба. Вы выкатываете helm, создается deployment, куб будет следить сам за тем чтобы оператор работал. На этом всё. Вы спросите, а откуда же тогда берется кластер? Так вот, после выкатки оператора мы должны принести в кластер один или несколько объектов под названием EtcdCluster. В котором описывается название, размер и версия etcd кластера. Оператор перехватывает событие создания такого объекта, считывает параметры и создает поды нашего кластера в указанном количестве. Что здесь кажется странным? С точки зрения k8s поды без deployment\replicaset это просто некоторый висящий в воздухе контейнер, который можно убить и никто не заплачет. Вот и получается, что всю заботу о том чтобы контейнеры кластера работали берет на себя etcd-operator.
Теперь скрестим ситуацию из первого абзаца со вторым. Если гугл кладет все ноды, то у нас падают все поды кластера. И тут самый интересный момент. Их никто не переподнимет после того как ноды рестартанут. Почему? потому что в etcd-operator заложена такая логика. Нет персистенса - нет переподнятия. В итоге, для того чтобы избежать этой попоболи в CRD нужно добавлять примерно такие строки:
kind: "EtcdCluster"
spec:
pod:
persistentVolumeClaimSpec:
storageClassName: XXXXXX
accessModes:
- ReadWriteOnce
resources:
requests:
storage: YYYYYYY
Тогда для каждого пода в кластере будут созданы свои тома, и после падения все будет переподниматься. С точки зрения кластера звучит довольно логично. Ибо если упало все, кворум хрен соберешь, данные эфемерны, кто теперь реально владеет актуальной информацией - непонятно. Так что если упал один под - переподнять его логично. Если весь кластер - то только с персистенсом.
#fuckup