Русский
Русский
English
Статистика
Реклама

Ingress

Обзор возможностей Kubespray Отличие оригинальной версии и нашего форка

20.09.2020 14:22:27 | Автор: admin

23 сентября 20.00 МСК Сергей Бондарев проведёт бесплатный вебинар Обзор возможностей Kubespray, где расскажет, как готовят kubespray, чтобы получилось быстро, эффективно и отказоустойчиво.


Сергей Бондарев расскажет отличие оригинальной версии и нашего форка:



Отличие оригинальной версии и нашего форка.


Те, кто с кубспреем уже сталкивался, наверное сейчас недоумевают, почему я kubeadm противопоставляю кубспрею, ведь кубспрей для создания кластера, как раз и вызывает кубадм и на первый взгляд выглядит, как скрипт установки пакетов и автоматизированного запуска.


Но так было не всегда, изначально кубспрей устанавливал все компоненты самостоятельно:


  • собирал кластер etcd;
  • устанавливал кублеты, генерил сертификаты, конфиги и токены доступа для статик подов контролплейна и прочих служебных компонентов;
  • создавал сервис аккаунты для рабочих узлов и подключал их в кластер.

Но в позапрошлом году они этот функционал выпилили, оставив только кубадм. Который в то время был не очень. Мне стало обидно и я сделал свой форк, в котором сохранил классический режим установки, и собственно теперь поддерживаю этот форк в актуальном состоянии, черри-пикая коммиты из оригинального кубспрея к себе. Попутно допиливая классический режим под новые изменения.


В итоге разница между кластерами, созданными моим форком и оригинальным это kube-proxy и сроки действия сертификатов.


В моем форке все осталось, как было раньше куб-прокси запускается, как статик под, сертификаты выписываются на 100 лет.


В Kubeadm куб-прокси запускается, как daemonset, а сертификаты выписываются на 1 год, и их надо периодически продлевать. kubeadm наконец-то научился это делать одной командой.


Разница небольшая, и на сегодня мы используем оба варианта.


Особенности (недостатки) при промышленной эксплуатации:


Сценарий универсальный, поэтому не очень быстрый. Собственный можно значительно ускорить, выкинув проверки, запускаясь из готового образа.


Сценарий сложный, есть нелогичные места, тяжелое наследие legacy. Установка доп. контроллеров и софта через кубспрей хороша для обучения и тестов. В пром. эксплуатации зависеть от кубспрея не очень здравая идея, плюс обновление софта реализовано методом "убил-сделал новый" значит перерыв в обслуживании.


Может добавлять только рабочие узлы, с мастерами есть некоторые нюансы с сертификатами, и сценарий не отрабатывает всех возможных проблем, которые могут возникнуть.


Например у меня была проблема с кубадмом, когда он падал в момент добавления второго и третьего мастера, и после этого кубспрей делал kubeadm reset на узле, и пробовал добавить мастер еще раз.


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


Opensource как он есть.


Всё это и многое другое на бесплатном вебинаре Обзор возможностей Kubespray 23 сентября 20.00 МСК.


Присоединяйтесь!

Подробнее..

Микросервисы на монолите

15.12.2020 12:20:26 | Автор: admin

Всем привет!

Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта?

В нашем проекте есть несколько систем, которые писались в те времена, когда преимущества микросервисного подхода были не столь очевидны, а инструментов, позволяющих использовать такой подход, было очень мало, и переписывать системы полностью просто нецелесообразно. Для адаптации к новой архитектуре мы решили в части задач использовать асинхронный подход, а также перейти к хранению части данных на общих сервисах. Само приложение при этом осталось на Django (API для SPA). При переходе на k8s деплой приложения был разбит на несколько команд: HTTP-часть (API), Celery-воркеры и RabbitMQ-консьюмеры. Причем было именно три развёртывания, то есть все воркеры, как и консьюмеры, крутились в одном контейнере. Быстрое и простое решение. Но этого оказалось недостаточно, так как это решение не обеспечивало нужный уровень надежности.

Начнем с RabbitMQ-консьюмеров. Основная проблема была в том, что внутри контейнера стартовал воркер, который запускал много потоков на каждый консьюмер, и пока их было пару штук, всё было хорошо, но сейчас их уже десятки. Решение нашли простое: каждый консьюмер вывели в отдельную команду manage.py и деплоим отдельно. Таким образом, у нас несколько десятков k8s-развёртываний на одном образе, с разными параметрами запуска. Ресурсы мы тоже выставляем для каждого консьюмера отдельно, и реальное потребление у консьюмеров достаточно невысокое. В результате для одного репозитория у нас десятки реальных отдельных сервисов в k8s, которые можно масштабировать, и при этом разработчикам намного удобнее работать только с одним репозиторием. То же самое и для развёртываний Сelery.

Если решение с воркерами достаточно простое и очевидное, то с HTTP-частью было немного сложнее. В нашей системе внешний межсервисный API и внутренний для фронтенда были в одном развёртывании с большим лимитом ресурсов и большим количеством инстансов.

Вроде бы рабочее решение? Да, но ДомКлик большой сложный механизм с сотнями сервисов, и иногда выход одного стороннего (вне конкретной системы) сервиса, который используется в одном единственном API-методе, может привести к пробке на сервере uwsgi. К чему это приводит, надеюсь, объяснять не нужно, всё встает или тормозит. В такие моменты должен приходить Кэп и говорить что-то вроде: Нужно было делать отдельные микросервисы и тогда упал бы только тот, что связан с отказавшим внешним сервисом. Но у нас-то монолит.

В Kubernetes есть такой сервис, как Ingress Controller, его основная задача распределять нагрузку между репликами. Но он, по сути, nginx, а значит Ingress Controller можно использовать для того, чтобы роутить запросы на разные сервисы.

Примерно вот так выглядит схема:

Проанализировав наш API, мы разбили его на несколько групп:

  • Внешний API (методы для других сервисов).

  • Внутренний API (методы для фронтенда).

  • Некритичные API-методы, которые зависимы от внешних сервисов, но не влияют на работу системы (статистика, счетчики и т. п.)

Таким образом можно легко создавать новые сервисы. Управлять ресурсами для каждого из них, масштабировать те методы, которые несут большую нагрузку, и получать другие преимущества. Если один из методов перестанет отвечать из-за каких-то внешних причин, то его можно изолировать в отдельное развёртывание и снизить нагрузку на другие части системы.

В конечном итоге наша система, имея один репозиторий и Django под капотом, раздроблена благодаря Kubernetes на 42 сервиса, 5 из которых делят HTTP-трафик, а остальные 37 консьюмеры и Celery-задачи. И в таком виде она может быть актуальна еще пару лет, несмотря на использование относительно старого стека технологий.

Подробнее..

Что такое IP и как защищает наши смартфоны?

03.07.2020 16:05:03 | Автор: admin
Все мы уже привыкли к буквенно-циферным IP67 или IP68. Казалось бы, все просто: одна циферка отвечает за защиту от пыли, другая от влаги.Но есть куча вопросов

Почему у Apple при одинаковых цифрах указываются другие глубины погружения? Сколько стоит сертификацияи кто получает за неё деньги?

Почему не все флагманы имеют IP в характеристиках? И почему вы не получите гарантию, если утопили свой iPhone!!! Причём тут ГОСТ и армия США?А может быть все это чистый маркетинг?

В общем, попробуем разобраться от чего и как защищают наши смартфоны и чего всё же стоит бояться.


Начнём с того, что означает аббревиатура IP. Здесь вроде бы ничего сложного Ingress Protection Marking, то есть кодировка защиты от проникновения.

Первая цифра отвечает за проникновения твердых объектов: грязь, песчинки, камушки, пыль.

Вторая за воду.



Стандарт называется IEC 60529 (в России ГОСТ 14254-2015). Чем больше каждая отдельная цифра, тем круче защита. При этом большинство смартфонов первый балл получают наивысший 6. То есть пыль (частицы до 75 микрометров) проникнуть не может.

Угадайте, какое устройство не получило такой сертификат. Подсказываем оно складывается и раскладывается и даже было отложено на полгода...

Что ж, с пылью понятно. Что там с водой? Первое, что нужно знать речь идет о ПРЕСНОЙ воде.

В морской и даже хлорированной воде бассейна может постепенно разрушаться оболочка гаджета: всякие резиновые вставки и прочее!

Правда, если быстро сполоснуть устройство пресной водой, скорее всего ничего не будет.

Вернемся к цифре. 1 означает защиту от вертикально падающих капель воды.А высшие 9 баллов воздействие струй воды высокой температуры под давлением. Что-то вроде мойки Karcher. Вряд ли обычные смартфоны получат одно из этих значений

Есть ещё один интересный момент. Устройство может проходить сертификацию лишь по одному из пунктов, тогда пишут, например, IPX7 или IPX8.

Не утонет. Но про пыль мы ХЗ

В чем же отличие между IP67, который например у iPhone SE,от IP68, который появляется в большинстве флагманов?

Если по-простому, то 67 это временное погружение. Упал в ведро поднял. А 68 это продолжительное нахождение. Но не более получаса. И не глубже 1 метра.

Какие же смартфоны имеют рейтинг?

[widget id=2096 type=table]

IP68: почти у всех актуальных iPhone, топовых Samsung, HUAWEI P40 Pro и Mate 30 Pro, Google Pixel 4 и 4 XL, флагманов Sony (помните, были такие). С недавних пор- OnePlus 8

Пыле и влагодиссиденты, в основном, китайцы: vivo, realme, Xiaomi вместе с подразделением redmi, HONOR, Motorola (ух, снова откопали стюардессу).



Ещё есть MIL-STD-810 (но о нём чуть позже) это что-то типа IP, но на ещё более серьёзных щах: LG V60 ThinQ 5G, LG G8 ThinQ, CAT S42, Ulefone Armor 7E, Samsung Galaxy X Cover Pro.

Более того. Оказывается, что у разных брендов разный подход к стандартам.

iPhone 11 Pro вроде бы сертифицированы по IP68, но есть странный момент.Вместо стандартного 1 метра тут используют формулировку до 4 метров (такого нет в документации), впрочем как мы выяснили из ряда документов условия испытаний являются предметом согласования между изготовителем и потребителем.

Ну и плохая новость, повреждение в результате контакта с жидкостью не покрывается гарантией. Речь идёт о годовой гарантии Apple, да и всех остальных. Плак-плак!!!

То есть вы можете купать телефон,но в случае чего, мы его не починим.

Похоже, что аналогичная практика распространяется и на другие бренды. Понятно почему вряд ли получится доказать, где и как долго вы купали смартфон.

Отдельный вопрос: как бренды узнают, что смартфон был в воде?

[caption id=attachment_143179 align=aligncenter width=640] Так можно увидеть стикер в iPhone[/caption]

Оказывается, внутри смартфона есть специальные маркеры-индикаторы: белые с одной стороны, красные с другой. Если промокнет он весь окрасится в красный. И сервис-центр будет в курсе. Их ставят возле разъёма Lightning или USB Type-C и на материнской плате. На iPhone они под слотом SIM-карты и ихможно увидеть невооружённым глазом.

Более интересная история с OnePlus. Почти всю дорогу компания игнорировала сертификацию. Хвалилась, что экономит деньги на бессмысленной сертификации и тем, что купила ведро для тестов! Но каждый раз тихонечко говорила, что купать не страшно.

И вот в 2020 году OnePlus 8 Pro получает IP68, а заодно и цена возрастает до 1000 евро. Совпадение? Не думаю!

Кстати Xiaomi тоже цены подняли, асертификат не завезли.



Но самое занятное, знаете что?

Сертификат распространяется только на американскую версию OnePlus 8, в Европе с защитой только прошка. Знаете почему?

И это отличный повод перейти к тому, как получается сертификат. Кому же и сколько надо платить?

Основным регулятором здесь выступает международная электротехническая комиссия IEC, чей головной офис находится в Женеве.

Но Сертификаты выдает не сама IEC, а агентства. Например, вот CSA Group из Северного Уэльса. На сайте организации написано какого рода документы они могут выдавать.

youtu.be/0wdosxcdZ_c

Для того, чтобы получить сертификат защиты, нужно пройти испытания. И тут начинается бюрократия. Бренд предоставляет устройство и его мучают.

По сути, основное требование это гарантия, что серийные смартфоны будут идентичны представленному на тест.

А сами тесты выглядят достаточно уморительно.

Так вот, возвращаясь к OnePlus, фишка в том, что на разные рынки выходят немного разные модели под разным артикулом. И не для всех из них провели испытания. Но пользователь то в итоге уверен, что у всех IP68. Так сколько стоит удовольствие?

Тут данные разнятся.

В одном из старых интервью Карл Пей из OnePlus сказал, что тестирование на IP будет стоить +30 долларов к цене смартфона.



Сколько стоит эта процедура: не разглашается в открытых источниках.

Где-то пишут о 10-20 тысячях долларов под ключ. Правда это за IP65. Но скорее все-таки лицензия платится за каждое устройство отдельно.

Но есть два вероятных пути тестирование на заводах: для этого надо приобрести нужное оборудование и производить его регулярную поверку ну как со счётчиками воды.

Кстати вот она на Али по 7-10 тысяч долларов за штуку.





Второй вариант это предоставление сэмплов на тесты в одно из агентств и последующее получение сертификата с возможным допиливанием устройств!

Кстати особняком стоит еще один стандарт Армии США. MIL-STD-810. Ключевое отличие в том, что там еще куча факторов воздействия учитывается. Тряска, заморозка, солнечное излучение и тд. И фактически смартфоны, получившие такой стандарт защиты неубиваемыми, но На самом деле устройство с IP68 практически наверняка пройдёт большинство тестом армейского стандарта.

Но зато в спецификациях выглядит как будто бы круче.

Итого


Сертификат IP судя по всему стоитне слишком дорого для крупной компании, но помимо прохождения сертификата, надо же саму влагозащиту сделать.

Зачем бренды платят за сертификат? Чтобы завоевать доверие аудитории. Но при этом держат фигу в кармане, не собираясь чинить утопленников.

Но если IP не написано это не значит, что смартфон в опасности. Надо проверять что говорит сам производитель. Как, например Xiaomi.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru