User
Kubernetes aka k8s — это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. В этой статье я расскажу как настроить кластер Kubernetes и развернуть на нем кластер Elasticsearch в AWS. Эти настройки также работают на GCE и Azure.
Кубернетес — тема горячая: администраторов, знающих Кубернетес, не хватает настолько, что клиенты просят Southbridge сдать спеца по k8s в бессрочную аренду. Так что поехать на интенсив — неплохой шанс толкнуть вперед карьеру, получить прибавку к зарплате или устроиться админом в крупную компанию. Оценить уровень преподавания можно на бесплатном вебинаре «Сети Kubernetes изнутри». Но обо всем по порядку.
Чтобы ничего не знать о Kubernetes, надо было последние три года прожить в пещере. В Handy инфраструктура разработки, CI/CD и продакшена построена на многокластерной экосистеме Kubernetes. Можно сказать, что мы в Handy фанаты Kubernetes, вот почему мы так удивились, когда личный кластер Kubernetes нашего коллеги в прошлые выходные взломали.
Удивились — и обрадовались, так как обнаружили в Kubernetes один малоизвестный глюк. В этой статье мы рассмотрим, как был взломан кластер коллеги и как мы подтвердили свои выводы, воссоздав эту атаку в собственном кластере. Атака была протестирована в Kubernetes 1.9, но может работать и на более старых кластерах.
ДИСКЛЕЙМЕР: эта статья о личном сервере нашего коллеги. Инфраструктура Handy Technologies не была скромпрометирована.
Недавно меня спросили, в чем разница между NodePorts, LoadBalancers и Ingress. Все это разные способы получить внешний трафик в кластер. Давайте посмотрим, чем они отличаются, и когда использовать каждый из них.
Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Я не углубляюсь в технические детали. Если хотите подробностей, обратитесь к официальной документации.
Примечание редактора: пост создан релиз-командой 1.10
Мы рады сообщить о выпуске Kubernetes 1.10, первого релиза 2018 года!
В новом релизе Kubernetes стал более зрелым, стали лучше масштабируемость и подключение модулей. Новая версия стабилизирует три ключевые области: хранение данных, безопасность и работу с сетью. Отдельно отметим такие дополнения, как внедрение внешних провайдеров учетных данных (альфа), возможность переключения DNS-сервиса на CoreDNS во время установки (бета), перемещение Container Storage Interface (CSI) и постоянных локальных томов в бета-версию.
Мы открыли исходный код всех наших продуктов, над которыми работали последний год, и в этом посте я хочу кратко рассказать о них.
Последний год Hyperpilot работал в скрытом режиме, поэтому позвольте объяснить, что мы собирались делать. Наша миссия – дать интеллект инфраструктуре, чтобы увеличить эффективность и производительность. DevOps и системные инженеры постоянно сталкиваются с необходимостью принимать множество решений, связанных с контейнерной инфраструктурой и процессами, требующими ручной работы. Эти решения включают в себя весь путь от конфигурации виртуальных машин (тип инстанса, регион и т.д.), конфигурации контейнеров (запрос ресурсов, количество экземпляров контейнера и т.д.) до вариантов конфигурации уровня приложения (jvm и т.д). Операторы и разработчики часто делают статический выбор, и эксплуатационный персонал понятия не имеет, почему было принято такое решение. Хуже всего, что операторы склонны к переусердствованию, а это приводит к неэффективному использованию инфраструктуры. Мы работали над тремя продуктами, которые могли бы помочь операторам находить инструменты для лучших решений и автоматизации рекомендаций в будущем. Далее я расскажу о высокоуровневых продуктах, находящихся в открытом доступе.
Краткое руководство по началу работы, которое вы ищете.
Если вы следовали тенденциям развития программного обеспечения в прошлом году, то, должно быть, устали слышать термин Docker. Вероятнее всего, вы ошеломлены огромным количеством разработчиков, говорящих о контейнерах, изолированных виртуальных машинах, супервизорах и другой магии Вуду, связанной с DevOps. Сегодня мы во всем разберемся. Пора наконец понять, что такое контейнеры как услуга и зачем они нужны.
Одна из особенностей мессенджера Telegram — широкие возможности API (Bot API и Telegram API). Команда Telegram пошла ещё дальше и выпустила библиотеку TDLib (Telegram Database Library), позволяющую разрабатывать альтернативные клиенты Telegram и не задумываться о низкоуровневых деталях реализации (работа с сетью, шифрование и локальное хранение данных).
TDLib работает на Android, iOS, Windows, macOS, Linux, Windows Phone, WebAssembly, watchOS, tvOS, Tizen, Cygwin и других *nix системах, а так же интегрируется с любым языком программирования, поддерживающим выполнение C-функций.
В этой статье мы рассмотрим использование TDLib в Ruby и создание gem'а для взаимодействия с JSON-интерфейсом библиотеки.
Я использую Google Cloud с Kubernetes Engine в течение 2 месяцев. На самом деле мне не понадобилось и месяца, чтобы уложить все в голове, но потребовалось еще столько же, чтобы разобраться с некоторыми неприятностями.
TL;DR: Google делает довольно хорошую работу, поэтому AWS не расслабляется. Если вы хорошо знаете AWS, я бы посоветовал протестировать Google Cloud. Возможно, из-за мышечной памяти мне было бы комфортнее с AWS, но я изучил Google Cloud и Kubernetes и уверен в них для большинства моих сценариев.
Я не эксперт, поэтому примите мои слова с долей скептицизма. Google Cloud и Kubernetes – одна из тех тем, о которых я очень хочу поговорить, но я не всегда могу подобрать правильные слова и надеюсь, что вы получите верное представление о предлагаемых решениях.
Цель статьи – сохранить некоторые фрагменты и мысли для дальнейшего использования. Поэтому имейте в виду, что это не пошаговое руководство. Сперва я намеревался написать руководство, но потом понял, что это почти как написать целую книгу, так что не в этот раз.
Недавно мы создали распределенную систему планирования cron-заданий на основе Kubernetes – захватывающей новой платформы для управления кластером контейнеров. Сейчас Kubernetes занимает лидирующие позиции и предлагает множество интересных решений. Одно из основных его достоинств – то, что инженерам не нужно знать, на каких машинах работают их приложения.
Распределенные системы по-настоящему сложны, и управление их службами – одна из самых больших проблем, с которыми сталкиваются операционные группы. Внедрить новое программное обеспечение в производство и научиться надежно управлять им – задача, к которой стоит относиться серьезно. Чтобы понять, почему обучение работе с Kubernetes важно (и почему это сложно!), мы предлагаем ознакомиться с фантастическим одночасовым переключением, вызванным ошибкой в Kubernetes.
В этой статье объясняется, почему мы решили построить архитектуру на Kubernetes. Мы расскажем, как проходила интеграция Kubernetes в существующую инфраструктуру, приведем подход к построению (и улучшению) доверия надежности кластера Kubernetes, а также рассмотрим абстракции, которые мы реализовали над Kubernetes.
В первом посте этой серии я рассмотрел, как Kubernetes использует комбинацию виртуальных сетевых устройств и правил маршрутизации. Если отправитель знает IP-адрес пода, комбинация разрешает обмен информацией между подами, запускающимися на разных кластерах. Если вы не знаете, как поды обмениваются информацией, стоит прочитать об этом, перед тем как продолжить чтение статьи.
Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.
Прошлый летом я заинтересовался вопросами информационной безопасности и взлома. Последний год я много играл в wargames, «захват флага», тестирование на проникновение, постоянно совершенствуя навыки взлома и изучая новые способы заставить компьютеры отклоняться от ожидаемого поведения.
Короче говоря, мой опыт ограничивался имитируемой средой, и, считая себя официальным хакером, я никогда не совал нос в бизнес других людей.
Это будет подробная история о том, как я взломал сервер, на котором размещалось 40 (это точное число) веб-сайтов, и о моих находках.
Azure Container Instances (ACI) позволяют запускать контейнеры, не беспокоясь об инфраструктуре. Мы можем дать образ контейнера, и ACI с радостью запустит контейнер и даже обеспечит внешним IP-адресом. Когда ручное вмешательство необходимо только при запуске контейнеров, это называется «беcсерверные контейнеры». ACI отлично подходит для пакетных рабочих нагрузок или долгосрочных контейнеров, где мы не хотим иметь дело с инфраструктурой.
PostgreSQL для хипстеров, бэкенд "Модульбанка" и другое.
14 октября в солнечном городе Уфа прошла конференция UFADEVCONF. Это первое мероприятие в Уфе такого масштаба, его организовало уфимское сообщество разработчиков Ufacoder и компания «Открытый регион». Секции докладов — Backend, Frontend, Mobile, Common.
Предлагаем обзор конференции и самых интересных докладов секции Backend.
По мере взросления и стабилизации экосистемы Docker связанные с безопасностью этого продукта темы привлекают все больше внимания. При проектировании инфраструктуры невозможно избежать вопроса обеспечения безопасности Docker.
В Docker уже встроено несколько замечательных средств обеспечения безопасности:
Docker-контейнеры минимальны: один или несколько работающих процессов, только необходимое программное обеспечение. Это снижает вероятность пострадать от уязвимостей в ПО.
Docker-контейнеры выполняют специфическую задачу. Заранее известно, что должно выполняться в контейнере, определены пути к директориям, открытые порты, конфигурации демонов, точки монтирования и т. д. В таких условиях проще обнаружить какие-либо связанные с безопасностью аномалии. Этот принцип организации систем идет рука об руку с микросервисной архитектурой, позволяя значительно уменьшить поверхность атаки.
Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).
Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.
Вы наверняка знаете, что в Postgres есть материализованные представления (materialized views) и обертки сторонних данных (foreign data wrappers, FDW). Материализованные представления позволяют материализовывать запросы и обновлять их по требованию. Обертки сторонних данных предоставляют функциональность загрузки данных из внешних источников, таких как, например, NoSQL-хранилища или другие серверы Postgres.
Вероятно, что вариант использования материализованных представлений совместно с обертками сторонних данных вы еще не рассматривали. Материализованные представления ускоряют доступ к данным: результаты запросов сохраняются и отпадает необходимость выполнять их еще раз. Доступ к сторонним данным через FDW может быть довольно медленным, поскольку они находятся в других системах. Объединив эти функции, можно в итоге получить быстрый доступ к сторонним данным.
Kubernetes — это предназначенный для контейнерной оркестровки фреймворк с открытым исходным кодом. Он был создан с учетом богатейшего опыта Google в области создания сред управления контейнерами и позволяет выполнять контейнеризованные приложения в готовом к промышленной эксплуатации кластере. В механизме Kubernetes много движущихся частей и способов их настройки — это различные системные компоненты, драйверы сетевого транспорта, утилиты командной строки, не говоря уже о приложениях и рабочих нагрузках.
По ходу этой статьи мы установим Kubernetes 1.6 на реальную (не виртуальную) машину под управлением Ubuntu 16.04 примерно за 10 минут. В результате у вас появится возможность начать изучать взаимодействие с Kubernetes посредством его CLI kubectl.