Еще в 2016 году мы в Buffer перешли на Kubernetes, и сейчас около 60 нод (на AWS) и 1500 контейнеров трудятся на нашем k8s-кластере под управлением kops. Тем не менее, на микросервисы мы переходили методом проб и ошибок, и даже после нескольких лет нашей работы с k8s мы до сих пор сталкиваемся с новыми для себя проблемами. В этом посте мы поговорим про процессорные ограничения: почему мы считали их хорошей практикой и почему в итоге они оказались не столь хороши.

Процессорные ограничения и троттлинг

Как и многие другие пользователи Kubernetes, Google очень рекомендует настраивать процессорные ограничения. Без такой настройки контейнеры в ноде могут занять все мощности процессора, из-за чего, в свою очередь, важные Kubernetes-процессы (например kubelet) перестанут реагировать на запросы. Таким образом, настройка процессорных ограничений это хороший способ защиты ваших нод.

Процессорные ограничения задают контейнеру максимальное процессорное время, которым он может воспользоваться за конкретный период (по умолчанию 100мс), и контейнер никогда не перешагнет этот предел. В Kubernetes для троттлинга контейнера и недопущения превышения им предела используется особый инструмент CFS Quota, однако в итоге такие искусственные процессорные ограничения занижают производительность и увеличивают время отклика ваших контейнеров.

Глобальный сбой работоспособности интернета произошел по вине американского провайдера CenturyLink. Из-за некорректной настройки межсетевого экрана у пользователей по всему миру наблюдались проблемы с доступом к Google, службам Microsoft, облачным сервисам Amazon, сервису микроблогов Twitter, Discord, сервисам Electronic Arts, Blizzard, Steam, веб-сайту Reddit и многим другим.



Причиной сбоя стало то, что CenturyLink, являясь Level3-провайдером, некорректно сформулировал правило BGP Flowspec в протоколе безопасности. BGP Flowspec используется для перенаправления трафика, так что эта ошибка привела к серьезным проблемам с маршрутизацией внутри сети провайдера, что сказалось и на стабильности глобального интернета. Конечно, сильнее всего пострадали пользователи в США, но отголоски проблем ощущались по всему миру.

Важно отметить, что CenturyLink является третьей про размерам телекоммуникационной компанией Америки, сразу после AT&T и Verizon.

Резюме: Я делюсь своими ранними экспериментами с бета-версией новой модели прогнозирования языка OpenAI (GPT-3). Я объясняю своё мнение, что GPT-3 обладает революционным потенциалом, сравнимым с блокчейн-технологией.



Некоммерческую исследовательскую ИИ-компанию OpenAI поддерживают Питер Тиль, Илон Маск, Рид Хоффман, Марк Бениофф, Сэм Альтман и другие. Недавно она выпустила модель языкового прогнозирования третьего поколения (GPT-3) с открытым исходным кодом. Языковые модели позволяют компьютерам создавать случайные предложения приблизительно той же длины и грамматической структуры, что и заданные в качестве образца.

В моих ранних экспериментах с GPT-3 я обнаружил, что предсказанные предложения GPT-3, опубликованные на форуме bitcointalk.org, привлекли много положительного внимания со стороны форумчан, включая предположения о том, что автор должен быть умным (и/или саркастичным) и что в его сообщениях есть тонкие паттерны. Полагаю, аналогичные результаты можно получить, опубликовав выдачу GPT-3 на других форумах, в блогах и социальных сетях.

Когда я редактировала страницу о возможностях контейнеров для журнала «How Containers Work», мне потребовалось объяснить, почему в Docker не работает strace. Вот что случалось при запуске strace в Docker-контейнере на моем ноутбуке:

$ docker run  -it ubuntu:18.04 /bin/bash
$ # ... install strace ...
root@e27f594da870:/# strace ls
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted

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

docker run --cap-add=SYS_PTRACE  -it ubuntu:18.04 /bin/bash

Но мне было интересно не решить проблему, а разобраться, почему эта ситуация вообще возникает. Так почему же strace не работает, а --cap-add=SYS_PTRACE все исправляет?

О том, что самоизоляция — это не только «тук-тук-тук» в крышку гроба экономики, но и новые «горизонты возможностей», уже написано немало статей. Правда, многие из них вызывают в памяти басню Крылова про лису и виноград. Но всё же в одном карантинные коучи правы: вся эта ситуация заставляет изобретать — не обязательно какие-то глобальные штуки, которые изменят новый мировой порядок. Иногда — просто небольшие продукты, которые помогли сделать самоизоляцию чуть более выносимой. Об одном из них, плеере ITSkino, мы уже вкратце писали. А сейчас хотим рассказать, как и что мы делали, чтобы наделить VLC функцией синхронного просмотра потокового или локального видео у неограниченного количества человек одновременно.

Так как нас не устраивала скорость и надежность исходной имплементации на Ruby, в последние несколько лет мы постепенно выводили критический функционал из нашего Rails-монолита GitHub.com и переписывали часть кода на Go. Например, на Github Satellite в прошлом году мы анонсировали — и имплементировали — возможность «более контролируемой авторизации» с использованием сервиса authzd.

Работа с authzd оказалась очень интересной и значимой для нас задачей, поскольку это был наш первый сервис на Go для работы с чтением данных из баз MySQL на продакшне в ходе веб-реквеста. У нас имелся опыт развертывания других работающих с базами MySQL-сервисов на Go, но при этом они были либо службами внутреннего контроля (наша кластерная поисковая система manticore), либо асинхронными пакетными заданиями (оркестратор резервного копирования Git gitbackups). Требования к производительности и надежности authzd отличаются от них повышенной строгостью, поскольку обычный реквест к Rails-монолиту вызывает этот сервис неоднократно.

Кроме того, проблемы с большими задержками при открытии TCP соединений на наших Kubernetes кластерах особенно влияли на пул соединений Go MySQL драйвера. Это добавляло работы, ведь именно на Kubernetes мы и развернули authzd. Одним из самых опасных самообманов программиста в этом отношении является вера в надежность сети, поскольку да, в большинстве случаев сеть действительно надежна… но как только она начинает тормозить или барахлить, нас настигают базовые проблемы таких же базовых библиотек, и все начинает рушиться.

Так чего нам в итоге стоила подготовка authzd к обработке всего нашего рабочего трафика через SQL, да еще и в соответствии с нашими целями доступности?

TL;DR В этот статье мы установим single sign-on для SSH от Google. За кулисами мы воспользуемся OpenID Connect (OICD), краткосрочными SSH сертификатами, несколькими хитростями конфигурации SSH, и опенсорсными пакетами step-ca и step от Smallstep. Мы настроим SSH Certificate Authority и воспользуемся им, чтобы загрузить в нашей системе нового пользователя и новый хост. Этот метод привносит много преимуществ помимо single sign-on, так как отпадает нужда в сборе, передаче и контроле файлов authorized_keys, хоть и требует больше подготовительной работы по сравнению с настройкой типичной пары открытого/секретного SSH ключей.

Как не следует пользоваться SSH

Еще в далеком 2004 году кто-то научил меня копипастить открытый ключ в файл authorized_keys. С тех пор я продолжал невинно копировать один и тот же старый публичный ключ на каждый сервер, с которым мне приходилось работать, и у меня постоянно не получалось сделать это с первого раза, потому что я забывал корректно настраивать chmod.

Перефразируя одного известного исторического деятеля, важнейшим из всех сервисов для нас является доставка. Что бы мы делали в нынешней ситуации без роллов или пиццы на дом — представлять не хочется. Так получилось, что 2 года назад мы приняли на поддержку одну из крупнейших сетей — «Тануки». Месячная аудитория сайта — порядка миллиона человек. Это теперь, в 2020 году. В 2018-м, когда «Тануки» начали сотрудничество с нами, она была в 2 раза меньше. Мы обеспечили безболезненный переезд в новый дата-центр и полностью переделали инфраструктуру — благодаря чему, собственно, сайт и приложения способны без проблем выдерживать возросшую нагрузку.

Временами мы сильно жалеем, что географически находимся далековато от ближайшего ресторана «Тануки»: иначе все свои успехи (и маленькие незадачи) заедали бы вкусными роллами.

В общем, сегодня мы хотим рассказать вам историю саппорта одного из крупнейших веб-проектов отечественной «индустрии гостеприимства».

Развертывание машинного обучения (machine learning, ML) в продакшн – задача нелегкая, а по факту, на порядок тяжелее развертывания обычного программного обеспечения. Как итог, большинство ML проектов так никогда и не увидят света — и продакшена — так как большинство организаций сдаются и бросают попытки использовать ML для продвижения своих продуктов и обслуживания клиентов.

Насколько мы можем видеть, фундаментальное препятствие на пути большинства команд к созданию и развертыванию ML в продакшн в ожидаемых масштабах заключается в том, что нам все еще не удалось привнести практики DevOps в машинное обучение. Процесс создания и развертывания моделей ML частично раскрыт уже вышедшими MLOps решениями, однако им недостает поддержки со стороны одной из самых трудных сторон ML: со стороны данных.

В этой статье собраны наши лучшие приемы для более эффективного использования SSH. Из нее вы узнаете как:

• Добавить второй фактор к логину SSH
• Безопасно пользоваться agent forwarding
• Выйти из вставшей SSH сессии
• Сохранить постоянный терминал открытым
• Поделиться удаленной сессией терминала с другом (без Zoom!)

Добавление второго фактора к своему SSH

Второй фактор аутентификации к своим SSH соединениям можно добавить пятью разными способами:

1. Обновить свой OpenSSH и использовать ключ шифрования. В феврале 2020 года в OpenSSH была добавлена поддержка ключей шифрования FIDO U2F (Universal Second Factor). Это отличная новая функция, но есть нюанс: только те клиенты и серверы, которые обновились до версии OpenSSH 8.2 и выше смогут пользоваться ключами шифрования, так как февральское обновление вводит для них новые типы ключей. Командой ssh –V можно проверить клиентскую версию SSH, а серверную — командой nc [servername] 22
   

Мы в Cloudflare объявили о поддержке HTTP/3 в сентябре прошлого года, когда отмечали девятый день рождения. Наша задача всегда состояла в улучшении интернета. Сотрудничество в области стандартов — важная часть процесса, и нам повезло участвовать в разработке HTTP/3.

Хотя HTTP/3 ещё на стадии черновика, мы заметили большой интерес к новому протоколу со стороны наших пользователей (инфраструктура Cloudflare обслуживает более 10% сайтов интернета — прим. пер.). К настоящему моменту поддержку HTTP/3 активировали более 113 000 зон, и если у вас экспериментальный браузер, то теперь вы можете получить доступ к этим зонам по новому протоколу! Здорово, что его включили так много людей: работа по HTTP/3 большого количества реальных веб-сайтов означает, что можно тестировать больше разнообразных свойств со стороны браузеров.

Здесь представлен фрагмент будущей книги «Основные инструменты и практики для начинающего разработчика программного обеспечения» Бальтазара Рубероля и Этьена Броду. Книга должна помочь образованию подрастающего поколения разработчиков. Она охватит такие темы, как освоение консоли, настройка и эффективная работа в командной оболочке, управление версиями кода с помощью git, основы SQL, инструменты вроде Make, jq и регулярные выражения, основы сетевого взаимодействия, а также лучшие практики разработки программного обеспечения и совместной работы. В настоящее время авторы упорно работают над этим проектом и приглашают всех поучаствовать в списке рассылки.

Содержание

• cat
• head
• tail
• wc
• grep
• cut
• paste
• sort
• uniq
• awk
• tr
• fold
• sed
• Реальные примеры
• Углубляемся: циклы for и xargs
• Итоги
• Что дальше

Модераторы сабреддита «PC Master race» призвали владельцев мощных игровых видеокарт присоединиться к научным облачным вычислениям Стэнфордского проекта Folding@Home, который прямо сейчас занимается расчетом моделей сразу по восьми направлениям для борьбы с COVID-19. Инициативу сообщества Reddit уже поддержала компания Nvidia, которая призвала через твиттер своих потребителей предоставить ученым вычислительные мощности своих видеокарт:


Важно отметить, что сабреддит «PC Master race» не пытается хайпануть на теме коронавируса: поддержка Folding@Home и первый систематизированный мега-тред, посвященный проекту, был опубликован еще 4 месяца назад, когда о коронавирусе даже не слышали. Кроме того, пользователи упоминали F@H в сабреддите на протяжении последних пяти лет.

Как принять участие в коллективных вычислениях, даже если вам плевать на COVID-19 и вы хотите, чтобы побыстрее нашлось лекарство от рака — под катом.

О проекте «магазинов самообслуживания» Amazon Go начали говорить в середине десятых. Даже пост на Хабре был. Но одно дело — читать описания, и другое — узнать из первых рук, как это: зайти в магазин без кассиров, набрать товаров и that's it, как пишет Amazon на своём сайте. Наш давний друг Василий Даниленко, 5 лет назад перебравшийся из небольшого города Иркутской области в Штаты, поделился личным опытом.


Фото Forbes.

«В Нью-Йорке уже немало (8, если быть точным, — прим. ред.) магазинов Amazon GO, где отсутствуют кассиры. Амазон сам тебе присылает счет и списывает деньги через пару минут после выхода.

Почти никто не пишет, что сами точки довольно небольшие (по американским стандартам можно сказать, крошечные), а ассортимент в них раз в десять меньше, чем в обычной ноу-нейм АЗС.
Но это вполне объяснимо, потому что это, скорее, пока пилот, нежели бизнес. Дальше некоторые заметки из личного опыта регулярного посещения магазинов без касс.

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

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

Процесс загрузки разделим на три этапа. Для каждого этапа сформулируем общие стратегии повышения производительности:

1. Начальная отрисовка: сколько времени требуется, чтобы пользователь увидел хоть что-то
   
   • Сократить запросы, блокирующие рендеринг
     
   • Избегать последовательных цепочек
     
   • Повторно использовать соединения с сервером
     
   • Сервис-воркеры для мгновенного рендеринга
2. Загрузка приложения: сколько времени требуется, чтобы пользователь смог использовать приложение
   
   • Разбить пакет приложения на части. Загружать только необходимые ресурсы. Максимизация попаданий в кэш
     
   • Проверить, что хэши частей пакета не меняются без необходимости
     
   • Запрашивать данные для страницы до загрузки всего приложения
     
   • Не блокировать рендеринг загрузкой второстепенных данных
     
   • Рассмотреть рендеринг на стороне сервера
3. Следующая страница: сколько времени требуется для перехода на следующую страницу
   
   • Запрашивать дополнительный код до того, как он понадобится
     
   • Кэшировать и повторно использовать данные на клиенте

В этом блоге опубликовано немало программистских баек. Мне нравится вспоминать о своих старых глупостях. Что ж, вот ещё одна такая история.

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

После школы (в возрасте около 16 лет) британские дети обычно идут в колледж, там выбирают для изучения три-четыре предмета, прежде чем поступить в университет. Учитывая свою любовь к бежевой коробке и магнитофону дома, я решил, что изучение «информатики» в колледже — правильный выбор.

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

Автор и мейнтейнер нескольких опенсорсных проектов, Эндрю Галлант пытается снять напряжённость, которая в последнее время накопилась в части опенсорсного сообщества. Крики души «Каково быть мейнтейнером свободного ПО», «Неблагодарный opensource» и другие жалобы мейнтейнеров породили дискуссию об агрессивности, грубости, неблагодарности, эмоциональном выгорании и тяжести бескорыстной поддержки проектов. Пост опубликован 19 января 2020 года, — прим. пер.

Хочу отойти от традиции говорить почти строго на технические темы — и поделюсь частью личных отношений со свободным и открытым программным обеспечением (FOSS). Хотя все люди разные, надеюсь, что обмен мнениями поможет наладить взаимопонимание, сопереживание и доверие в нашем сообществе.

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

Это ни в коем случае не призыв о помощи. Речь о понимании. Я не призываю изменить экономику FOSS или обсуждать моё психическое здоровье. Я не говорю о привлечении дополнительных мейнтейнеров. Просто хочу поделиться своей историей и попытаться увеличить эмпатию в сообществе FOSS.

Целевая аудитория: все, кто занимается опенсорсом.

Куб-на-кубе, метакластеры, соты, распределение ресурсов

Рис. 1. Экосистема Kubernetes в облаке Alibaba Cloud

С 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.

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

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

Потестируйте Backyards на собственных кластерах: curl https://getbackyards.sh | sh && backyards install -a --run-demo. Если интересно, см. детали последнего релиза.

В июне мы представили Backyards, автоматизированную «сервисную сетку» (service mesh) поверх нашего оператора Istio. Она сильно упрощает управление service mesh в многооблачной и гибридной инфраструктуре. Backyards интегрирован в платформу управления контейнерами Pipeline на Banzai Cloud, но также доступен как отдельный продукт. Конечно, интеграция с Pipeline даёт множество конкретных преимуществ (как управление приложениями на нескольких облаках), но Backyards работает на любой установке Kubernetes.

Реальность сетевого инженера (с лапшой и… солью?)

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

В этих обсуждениях неизменно возникает вопрос «первопричины». Верные читатели наверняка знают, что у меня есть несколько мыслей по этому поводу. Во многих организациях анализ инцидентов полностью основан на этой концепции. Они используют разные техники выявления причинно-следственных связей, такие как «Пять почему». Эти методы предполагают так называемую «линейность событий» как неоспоримую догму.

Когда вы подвергаете сомнению эту идею и указываете на то, что в сложных системах линейность успокаивающе обманчива, то рождается увлекательная дискуссия. Спорщики страстно настаивают, что только знание «первопричины» позволяет понять происходящее.

Я заметил интересную закономерность: разработчики и девопсы по-разному реагируют на эту идею. По моему опыту, разработчики чаще утверждают, что первопричина имеет значение и что в событиях всегда можно установить причинно-следственные связи. С другой стороны, девопсы чаще соглашаются, что сложный мир не всегда подчиняется линейности.