Если вы хотите использовать Linux для предоставления услуг бизнесу, эти услуги должны быть безопасными, отказоустойчивыми и масштабируемыми. Хорошие слова, но что мы под ними подразумеваем?
«Безопасный» означает, что пользователи могут получить доступ к требуемым данным, будь то доступ только для чтения или доступ для записи. В то же время никакие данные не передаются сторонам, не уполномоченным на их просмотр. Безопасность обманчива: вы можете думать, что у вас все защищено, а потом обнаруживаете дыры. Проектировать безопасность с самого начала проекта намного проще, чем пытаться модернизировать его позже.
«Устойчивый» означает, что ваши службы допускают сбои в инфраструктуре. Ошибка может быть связана с контроллером диска сервера, который больше не может получить доступ к дискам, что делает данные недоступными. Или отказ может быть связан с сетевым коммутатором, который больше не позволяет двум или более системам обмениваться данными. В этом контексте «единая точка отказа» или SPOF - это сбой, который отрицательно влияет на доступность службы. Устойчивая инфраструктура - это инфраструктура без SPOF.
«Масштабируемость» описывает способность систем изящно справляться с резкими скачками спроса. Это также определяет, насколько легко можно внести изменения в системы. Например, добавление нового пользователя, увеличение емкости хранилища или перемещение инфраструктуры из Amazon Web Services в Google Cloud - или даже перемещение ее внутри компании.
Как только ваша инфраструктура выходит за пределы одного сервера, появляется множество вариантов повышения безопасности, отказоустойчивости и масштабируемости. Мы рассмотрим, как эти проблемы решались традиционно и какие новые технологии меняют облик больших прикладных вычислений.
Получите больше Linux!
Нравится то, что вы читаете? Хотите больше Linux и с открытым исходным кодом? Мы можем доставить буквально! Подпишитесь на Linux Format сегодня по выгодной цене. Вы можете получить печатные издания, электронные издания или почему бы и то и другое? Мы доставляем к вашей двери по всему миру за простую годовую плату. Так что сделайте свою жизнь лучше и проще, подпишитесь сейчас!
Чтобы понять, что возможно сегодня, полезно посмотреть, как традиционно реализовывались технологические проекты. В былые времена - то есть более 10 лет назад - компании покупали или арендовали оборудование для работы всех компонентов своих приложений. Даже относительно простые приложения, такие как веб-сайт WordPress, состоят из нескольких компонентов. В случае WordPress требуется база данных MySQL вместе с веб-сервером, например Apache, и способом обработки кода PHP. Итак, они построили сервер, настроили Apache, PHP и MySQL, установили WordPress - и все готово.
По большому счету, это сработало. Он работал достаточно хорошо, и сегодня существует огромное количество серверов, настроенных именно таким образом. Но это было несовершенно, и две из самых больших проблем - это устойчивость и масштабируемость.
Отсутствие устойчивости означало, что любая серьезная проблема на сервере приведет к потере обслуживания. Очевидно, что катастрофический сбой означал бы отсутствие веб-сайта, но также не было места для проведения планового обслуживания без ущерба для веб-сайта. Даже установка и активация обычного обновления безопасности для Apache потребует отключения веб-сайта на несколько секунд.
Проблема устойчивости в значительной степени была решена за счет создания «кластеров высокой доступности». Принцип заключался в том, что веб-сайт запускался на двух серверах, настроенных таким образом, чтобы сбой любого из них не приводил к отключению веб-сайта. Предоставляемая услуга была устойчивой, даже если отдельные серверы не были.
Абстрактные облакаЧасть мощи Kubernetes - это абстракция, которую он предлагает. С точки зрения разработчика, они разрабатывают приложение для работы в контейнере Docker. Docker не волнует, работает ли он в Windows, Linux или какой-либо другой операционной системе. Тот же контейнер Docker можно взять с MacBook разработчика и запустить под Kubernetes без каких-либо изменений.
Сама установка Kubernetes может быть одной машиной. Конечно, многие преимущества Kubernetes будут недоступны: не будет автоматического масштабирования; есть очевидная единственная точка отказа и так далее. Однако в качестве доказательства концепции в тестовой среде он работает.
Когда вы будете готовы к производству, вы можете работать как внутри компании, так и через облачного провайдера, такого как AWS или Google Cloud. У облачных провайдеров есть несколько встроенных сервисов, которые помогают запускать Kubernetes, но ни один из них не является жестким. Если вы хотите переключаться между Google, Amazon и собственной инфраструктурой, вы настраиваете Kubernetes и переходите оттуда. Ни одно из ваших приложений не должно изменяться.
А где линукс? Kubernetes работает в Linux, но операционная система невидима для приложений. Это значительный шаг на пути к зрелости и удобству использования ИТ-инфраструктур.
Эффект слэшдота
Проблема масштабируемости немного сложнее. Допустим, ваш сайт WordPress получает 1000 посетителей в месяц. Однажды о вашей компании упоминают по радио 4 или по телевизору за завтраком. Внезапно за 20 минут вы получаете больше посетителей, чем месяц. Все мы слышали истории о «сбоях» веб-сайтов, и, как правило, именно поэтому: отсутствие масштабируемости.
Два сервера, которые помогли повысить устойчивость, могли справиться с более высокой нагрузкой, чем один сервер, но это все еще ограничено. Вы будете платить за два сервера 100% времени, и большую часть времени оба работали безупречно. Вполне вероятно, что один только один сможет запустить ваш сайт. Затем Джон Хамфрис упоминает ваш бизнес в Today, и вам понадобится 10 серверов, чтобы справиться с нагрузкой, но только на несколько часов.
Лучшим решением проблемы отказоустойчивости и масштабируемости были облачные вычисления. Настройте один или два экземпляра сервера - маленькие серверы, на которых запускаются ваши приложения - в Amazon Web Services (AWS) или Google Cloud, и если один из экземпляров по какой-то причине выйдет из строя, он будет автоматически перезапущен. Настройте автоматическое масштабирование правильно, и когда г-н Хамфрис заставляет рабочую нагрузку на экземплярах вашего веб-сервера быстро расти, автоматически запускаются дополнительные экземпляры сервера для разделения рабочей нагрузки. Позже, когда интерес спадет, эти дополнительные экземпляры останавливаются, и вы платите только за то, что используете. Идеально… или нет?
Хотя облачное решение намного более гибкое, чем традиционный автономный сервер, проблемы все же остаются. Обновить все запущенные облачные экземпляры непросто. При разработке для облака тоже есть проблемы: ноутбук, который используют ваши разработчики, может быть похож на облачный экземпляр, но это не то же самое. Если вы выберете AWS, переход на Google Cloud будет сложным делом. А что, если по какой-то причине вы просто не хотите передавать свои компьютеры Amazon, Google или Microsoft?
Контейнеры появились как средство объединения приложений со всеми их зависимостями в единый пакет, который можно запускать где угодно. Контейнеры, такие как Docker, могут работать на ноутбуках ваших разработчиков так же, как они работают на ваших облачных экземплярах, но управление парком контейнеров становится все более сложной задачей по мере роста количества контейнеров.
Ответ - оркестровка контейнеров. Это значительный сдвиг в фокусе. Раньше мы удостоверились, что у нас достаточно серверов, будь то физических или виртуальных, чтобы гарантировать, что мы сможем обслуживать рабочую нагрузку. Использование автомасштабирования облачных провайдеров помогло, но мы все еще имели дело с экземплярами. Нам пришлось вручную настраивать балансировщики нагрузки, брандмауэры, хранилище данных и многое другое. Обо всем этом (и многом другом) позаботится оркестровка контейнеров. Мы указываем требуемые результаты, и наши инструменты оркестровки контейнеров соответствуют нашим требованиям. Мы указываем, что мы хотим сделать, а не то, как мы хотим это сделать.
Станьте Kubernete
Kubernetes (ku-ber-net-eez) - это ведущий инструмент оркестровки контейнеров на сегодняшний день, созданный Google. Если кто и знает, как управлять крупномасштабными ИТ-инфраструктурами, так это Google. Источником Kubernetes является Borg, внутренний проект Google, который до сих пор используется для запуска большинства приложений Google, включая его поисковую систему, Gmail, Google Maps и другие. Борг был секретом до тех пор, пока Google не опубликовал статью об этом в 2015 году, но из этого документа было совершенно очевидно, что Борг был главным источником вдохновения для Kubernetes.
Borg - это система, которая управляет вычислительными ресурсами в центрах обработки данных Google и поддерживает работу приложений Google, как рабочих, так и других, несмотря на сбой оборудования, исчерпание ресурсов или другие проблемы, которые в противном случае могли бы вызвать сбой. Это достигается путем тщательного мониторинга тысяч узлов, составляющих «ячейку» Борга, и работающих на них контейнеров, а также запуска или остановки контейнеров по мере необходимости в ответ на проблемы или колебания нагрузки.
Сам Kubernetes родился в результате инициативы Google GIFEE («Инфраструктура Google для всех остальных») и был разработан как более дружественная версия Borg, которая может быть полезна за пределами Google. Он был подарен Linux Foundation в 2015 году путем создания Cloud Native Computing Foundation (CNCF).
Kubernetes предоставляет систему, с помощью которой вы «объявляете» свои контейнерные приложения и сервисы, и гарантирует, что ваши приложения работают в соответствии с этими декларациями. Если вашим программам требуются внешние ресурсы, такие как хранилище или балансировщики нагрузки, Kubernetes может предоставить их автоматически. Он может масштабировать ваши приложения вверх или вниз, чтобы не отставать от изменений нагрузки, и даже при необходимости может масштабировать весь кластер. Компонентам вашей программы даже не нужно знать, где они работают: Kubernetes предоставляет приложениям внутренние службы именования, чтобы они могли подключаться к «wp_mysql» и автоматически подключаться к нужному ресурсу ».
Конечным результатом является платформа, которую можно использовать для запуска ваших приложений в любой инфраструктуре, от одной машины через локальную стойку систем до облачных парков виртуальных машин, работающих на любом крупном облачном провайдере, используя одни и те же контейнеры. и конфигурация. Kubernetes не зависит от провайдера: запускайте его, где хотите.
Kubernetes - мощный инструмент, и он обязательно сложен. Прежде чем мы перейдем к обзору, нам нужно ввести некоторые термины, используемые в Kubernetes. Контейнеры запускают отдельные приложения, как обсуждалось выше, и сгруппированы в поды. Pod - это группа тесно связанных контейнеров, которые развернуты вместе на одном хосте и совместно используют некоторые ресурсы. Контейнеры внутри модуля работают как одна команда: они выполняют связанные функции, такие как контейнер приложения и контейнер журналирования с определенными настройками для приложения.
Четыре ключевых компонента Kubernetes - это сервер API, планировщик, диспетчер контроллеров и распределенная база данных конфигурации под названием etcd. Сервер API лежит в основе Kubernetes и выступает в качестве основной конечной точки для всех запросов управления. Они могут быть созданы различными источниками, включая другие компоненты Kubernetes, такие как планировщик, администраторы через командную строку или веб-панели мониторинга, а также сами контейнерные приложения. Он проверяет запросы и обновляет данные, хранящиеся в etcd.
Планировщик определяет, на каких узлах будут работать различные модули, принимая во внимание такие ограничения, как требования к ресурсам, любые аппаратные или программные ограничения, рабочую нагрузку, крайние сроки и многое другое.
Диспетчер контроллеров отслеживает состояние кластера и будет пытаться запустить или остановить модули, если необходимо, через сервер API, чтобы привести кластер в желаемое состояние. Он также управляет некоторыми внутренними соединениями и функциями безопасности.
Каждый узел запускает процесс Kubelet, который взаимодействует с сервером API и управляет контейнерами - обычно с помощью Docker - и Kube-Proxy, который обрабатывает сетевое проксирование и балансировку нагрузки в кластере.
Система распределенных баз данных etcd получила свое название от /так далее папка в системах Linux, которая используется для хранения информации о конфигурации системы, а также суффикс «d», часто используемый для обозначения процесса демона. Цели etcd - хранить данные ключ-значение распределенным, согласованным и отказоустойчивым способом.
Сервер API хранит все данные о своем состоянии в etcd и может одновременно запускать несколько экземпляров. Планировщик и диспетчер контроллеров могут иметь только один активный экземпляр, но используют систему аренды, чтобы определить, какой из запущенных экземпляров является главным. Все это означает, что Kubernetes может работать как высокодоступная система без единой точки отказа.
Собираем все вместе
Так как же использовать эти компоненты на практике? Ниже приводится пример настройки веб-сайта WordPress с использованием Kubernetes. Если вы хотите сделать это по-настоящему, вы, вероятно, использовали бы заранее определенный рецепт, называемый диаграммой руля. Они доступны для ряда распространенных приложений, но здесь мы рассмотрим некоторые шаги, необходимые для запуска и запуска сайта WordPress в Kubernetes.
Первая задача - определить пароль для MySQL:
kubectl создать секретный общий mysql-pass --from-literal = password = ВАШ ПАРОЛЬ
kubectl свяжется с сервером API, который проверит команду, а затем сохранит пароль в etcd. Наши службы определены в файлах YAML, и теперь нам нужно постоянное хранилище для базы данных MySQL.
apiVersion: v1 вид: метаданные PersistentVolumeClaim: имя: метки mysql-pv-заявлений: приложение: спецификация wordpress: accessModes: - ReadWriteOnce ресурсы: запросы: хранилище: 20Gi
Спецификация должна быть в основном понятной. Поля имени и меток используются для ссылки на это хранилище из других частей Kubernetes, в данном случае нашего контейнера WordPress.
После того, как мы определили хранилище, мы можем определить экземпляр MySQL, указав его на предопределенное хранилище. Затем следует определение самой базы данных. Мы даем этой базе данных имя и метку для удобства использования в Kubernetes.
Теперь нам нужен еще один контейнер для запуска WordPress. Часть спецификации развертывания контейнера:
вид: Метаданные развертывания: имя: ярлыки wordpress: приложение: спецификация wordpress: стратегия: тип: воссоздать
Тип стратегии «Повторное создание» означает, что при изменении любого кода, составляющего приложение, запущенные экземпляры будут удалены и созданы заново. Другие варианты включают возможность циклического включения новых экземпляров и удаления существующих экземпляров один за другим, что позволяет службе продолжать работу во время развертывания обновления. Наконец, мы объявляем сервис для самого WordPress, состоящий из кода PHP и Apache. Это часть файла YAML, в котором говорится:
метаданные: имя: ярлыки wordpress: приложение: спецификация wordpress: порты: - порт: 80 селектор: приложение: уровень wordpress: тип интерфейса: LoadBalancer
Обратите внимание на последнюю строку, определяющую тип службы как LoadBalancer. Это указывает Kubernetes сделать сервис доступным за пределами Kubernetes. Без этой строки это была бы просто внутренняя служба «только для Kubernetes». Вот и все. Kubernetes теперь будет использовать эти файлы YAML как декларацию того, что требуется, и настроит модули, соединения, хранилище и т. Д. По мере необходимости, чтобы привести кластер в «желаемое» состояние.
Это обязательно был только общий обзор Kubernetes, и многие детали и функции системы были опущены. Мы не упомянули автоматическое масштабирование (как поды, так и узлы, составляющие кластер), задания cron (запуск контейнеров по расписанию), Ingress (балансировка нагрузки HTTP, перезапись и разгрузка SSL), RBAC (управление доступом на основе ролей). , сетевые политики (брандмауэр) и многое другое. Kubernetes чрезвычайно гибкий и чрезвычайно мощный: для любой новой ИТ-инфраструктуры он должен быть серьезным соперником.
Ресурсы
Если вы не знакомы с Docker, начните здесь: https://docs.docker.com/get-started.
Здесь есть интерактивное руководство по развертыванию и масштабированию приложения: https://kubernetes.io/docs/tutorials/kubernetes-basics.
И смотрите https://kubernetes.io/docs/setup/scratch, чтобы узнать, как построить кластер.
Вы можете поиграть с бесплатным кластером Kubernetes на https://tryk8s.com.
Наконец, вы можете подробно изучить длинный технический документ с отличным обзором использования Borg в Google и того, как это повлияло на дизайн Kubernetes здесь: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Узнайте больше о Tiger Computing.
- Лучшее облачное хранилище 2022-2023 года онлайн: бесплатное, платное и бизнес-варианты
Нравится то, что вы читаете? Хотите больше Linux и с открытым исходным кодом? Мы можем доставить буквально! Подпишитесь на Linux Format сегодня по выгодной цене. Вы можете получить печатные издания, электронные издания или почему бы и то и другое? Мы доставляем к вашей двери по всему миру за простую годовую плату. Так что сделайте свою жизнь лучше и проще, подпишитесь сейчас!
