Если вы хотите использовать Linux для предоставления услуг бизнесу, эти службы должны быть безопасными, отказоустойчивыми и масштабируемыми. Хорошие слова, но что мы подразумеваем под ними?
‘Безопасный’ означает, что пользователи могут получить доступ к нужным им данным, будь то доступ только для чтения или доступ для записи. В то же время, никакие данные не подвергаются какой-либо стороне, которая’не имеет права видеть это. Безопасность обманчива: вы можете думать, что у вас есть все, что защищено, но потом узнаете, что есть дыры. Проектирование в области безопасности с самого начала проекта гораздо проще, чем попытка его модернизации позже.
‘жизнерадостный’ означает, что ваши сервисы терпят сбои в инфраструктуре. Сбой может быть контроллером диска сервера, который больше не может получить доступ к каким-либо дискам, что делает данные недоступными. Или сбой может быть сетевым коммутатором, который больше не позволяет двум или более системам связываться. В этом контексте “единая точка отказа” или SPOF — сбой, который отрицательно влияет на доступность услуг. Отказоустойчивая инфраструктура без SPOF.
‘Масштабируемость’ описывает способность систем изящно обрабатывать пики спроса. Он также определяет, насколько легко можно вносить изменения в системы. Например, добавление нового пользователя, увеличение емкости хранилища или перенос инфраструктуры из Amazon Web Services в Google Cloud — или даже перемещение его собственными силами.
Как только ваша инфраструктура выходит за пределы одного сервера, появляется множество вариантов повышения безопасности, отказоустойчивости и масштабируемости. Мы’Посмотрим, как эти проблемы были решены традиционно, и какие новые технологии доступны, которые изменяют облик больших приложений.
Чтобы понять, что’сегодня это возможно’Полезно посмотреть, как традиционно реализуются технологические проекты. В былые времена, то есть более 10 лет назад, компании покупали или арендовали оборудование для запуска всех компонентов своих приложений. Даже относительно простые приложения, такие как веб-сайт WordPress, имеют несколько компонентов. В случае WordPress требуется база данных MySQL вместе с веб-сервером, таким как Apache, и способ обработки кода PHP. Поэтому они’создать сервер, настроить Apache, PHP и MySQL, установить WordPress и отключить их’буду идти.
По большому счету это сработало. Это сработало достаточно хорошо, что до сих пор существует огромное количество серверов, настроенных именно таким образом. Но это не было’не идеально, и две из самых больших проблем были устойчивость и масштабируемость.
Отсутствие устойчивости означало, что любая серьезная проблема на сервере может привести к потере обслуживания. Очевидно, что катастрофический сбой означал бы отсутствие веб-сайта, но также не было места для проведения планового технического обслуживания без воздействия на веб-сайт. Даже установка и активация обычного обновления безопасности для Apache потребует нескольких секунд’ отключение сайта.
Проблема устойчивости была в основном решена путем ‘кластеры высокой доступности’. Принцип состоял в том, чтобы два сервера работали на веб-сайте, настроенном таким образом, чтобы сбой одного из’В результате веб-сайт не работает. Предоставляемый сервис был устойчивым, даже если отдельные серверы не были.
Абстрактные облака
Часть власти Kubernetes — абстракция, которую это предлагает. От разработчика’В перспективе они разрабатывают приложение для запуска в контейнере Docker. Докер’не волнует ли это’работает на Windows, Linux или другой операционной системе. Тот же контейнер Docker можно взять у разработчика’MacBook и работать под Kubernetes без каких-либо изменений.
Сама установка Kubernetes может быть одной машиной. Конечно, много преимуществ выиграл Кубернетес’t быть доступным: автоматического масштабирования не будет; там’очевидная единая точка отказа и так далее. В качестве доказательства концепции в тестовой среде, тем не менее, это работает.
Как только вы’Если вы готовы к работе, вы можете запустить его самостоятельно или у поставщика облачных услуг, такого как AWS или Google Cloud. Облачные провайдеры имеют некоторые встроенные сервисы, которые помогают в работе Kubernetes, но ни одно из них не является жестким требованием. Если вы хотите перемещаться между Google, Amazon и собственной инфраструктурой, вы настраиваете Kubernetes и переходите. Ни одно из ваших приложений не должно быть изменено.
А где Linux? Kubernetes работает на Linux, но операционная система невидима для приложений. Это важный шаг в зрелости и удобстве использования ИТ-инфраструктур..
Эффект Slashdot
Проблема масштабируемости немного сложнее. Позволять’Например, ваш сайт WordPress получает 1000 посетителей в месяц. Однажды ваш бизнес упоминается по радио 4 или по телевизору за завтраком. Внезапно вы получаете больше месяца’Стоит посетителей за 20 минут. Мы’все слышали истории сайтов ‘грохот’, и это’Как правило, почему: отсутствие масштабируемости.
Два сервера, которые помогли с отказоустойчивостью, могли управлять более высокой рабочей нагрузкой, чем один сервер, но это’все еще ограничен. Вы’я буду платить за два сервера 100% времени, и большую часть времени оба будут работать отлично. Это’Скорее всего, только один может запустить ваш сайт. Тогда Джон Хамфрис упоминает ваш бизнес на сегодня, и вы’мне нужно 10 серверов, чтобы справиться с нагрузкой — но только на несколько часов.
Лучшим решением проблемы устойчивости и масштабируемости были облачные вычисления. Настройте один или два экземпляра сервера — небольшие серверы, на которых запускаются ваши приложения — в Amazon Web Services (AWS) или Google Cloud, и если по какой-либо причине один из экземпляров выйдет из строя, он будет автоматически перезапущен. Правильно настройте автоматическое масштабирование, и когда Mr Humphrys приводит к быстрому росту нагрузки на экземпляры вашего веб-сервера, автоматически запускаются дополнительные экземпляры сервера для распределения рабочей нагрузки. Позже, когда интерес исчезает, эти дополнительные экземпляры останавливаются, и вы платите только за то, что используете. Отлично… либо это?
Хотя облачное решение гораздо более гибкое, чем традиционный автономный сервер, все еще существуют проблемы. Обновление всех запущенных облачных экземпляров isn’т просто. У разработки для облака тоже есть проблемы: ноутбук, который используют ваши разработчики, может быть похож на облачный экземпляр, но это’не то же самое. Если вы переходите на AWS, миграция в Google Cloud является сложной задачей. И предположим, по какой-то причине, вы просто понимаете,’не хочу передавать свои вычисления на Amazon, Google или Microsoft?
Контейнеры появились в качестве средства для объединения приложений со всеми их зависимостями в единый пакет, который можно запускать где угодно. Контейнеры, такие как Docker, могут работать на ваших разработчиках’ ноутбуки так же, как они работают на ваших облачных экземплярах, но управление парком контейнеров становится все более сложной задачей с ростом количества контейнеров.
Ответ — контейнерная оркестровка. Это значительный сдвиг в фокусе. Раньше мы проверяли, достаточно ли у нас серверов, физических или виртуальных, для обслуживания рабочей нагрузки. Использование облачных провайдеров’ автоматическое масштабирование помогло, но мы все еще имели дело с примерами. Пришлось настраивать балансировщики нагрузки, брандмауэры, хранилище данных и многое другое вручную. С контейнерной оркестровкой все это (и многое другое) решено. Мы указываем результаты, которые нам нужны, и наши инструменты оркестровки контейнеров отвечают нашим требованиям. Мы указываем, что мы хотим сделать, а не как мы хотим это сделать.
Непрерывная интеграция и непрерывное развертывание могут хорошо работать с Kubernetes. Вот’обзор Jenkins, используемого для создания и развертывания приложения Java
(Изображение предоставлено: Будущее)
Стань Кубернетом
Kubernetes (Ku-Ber-Net-Eez) является ведущим инструментом оркестровки контейнеров сегодня, и он пришел от Google. Если кто-то знает, как управлять крупномасштабными ИТ-инфраструктурами, то Google знает. Происхождение Kubernetes — Borg, внутренний проект Google, который’S до сих пор используется для запуска большей части Google’s приложений, включая его поисковую систему, Gmail, Google Maps и многое другое. Борг был секретом до тех пор, пока Google не опубликовал статью об этом в 2015 году, но из этого документа стало ясно, что Борг был главным вдохновителем Кубернетеса..
Борг — это система, которая управляет вычислительными ресурсами в Google’центры обработки данных и хранит Google’Приложения, как производственные, так и другие, работают, несмотря на аппаратный сбой, исчерпание ресурсов или другие проблемы, которые могли бы вызвать сбой. Это делается путем тщательного мониторинга тысяч узлов, составляющих Borg. “клетка” и контейнеры, работающие на них, и запуск или остановка контейнеров по мере необходимости в ответ на проблемы или колебания нагрузки.
Сам Kubernetes родился из Google’S GIFEE (‘Google’Инфраструктура для всех остальных’), и был разработан, чтобы быть более дружественной версией Borg, которая могла бы быть полезной за пределами Google. Он был пожертвован Linux Foundation в 2015 году в результате создания Cloud Native Computing Foundation (CNCF)..
Kubernetes предоставляет систему, с помощью которой вы “DECLARE” ваши приложения и сервисы в контейнерах, и он обеспечивает работу ваших приложений в соответствии с этими декларациями. Если вашим программам требуются внешние ресурсы, такие как хранилище или балансировщик нагрузки, Kubernetes может предоставить их автоматически. Он может масштабировать ваши приложения вверх или вниз, чтобы не отставать от изменений нагрузки, и может даже масштабировать весь ваш кластер, когда это необходимо. Ваша программа’компоненты Дон’Т даже нужно знать, где они’перезапускается: Kubernetes предоставляет приложениям службы внутренних имен, чтобы они могли подключаться к “wp_mysql” и автоматически подключаться к нужному ресурсу.’
Конечным результатом является платформа, которую можно использовать для запуска ваших приложений в любой инфраструктуре, от одного компьютера до локального стеллажа систем, до облачных парков виртуальных машин, работающих на любом крупном облачном провайдере, и все они используют одни и те же контейнеры. и конфигурация. Kubernetes не зависит от провайдера: запускайте его где угодно.
Кубернетес — мощный инструмент, и он обязательно сложный. Прежде чем мы перейдем к обзору, нам нужно ввести некоторые термины, используемые в Kubernetes. Контейнеры запускают отдельные приложения, как обсуждалось выше, и группируются в пакеты. Модуль — это группа тесно связанных контейнеров, которые развернуты вместе на одном хосте и совместно используют некоторые ресурсы. Контейнеры внутри контейнера работают как команда: они’будет выполнять связанные функции, такие как контейнер приложения и контейнер регистрации с конкретными настройками для приложения.
Обзор Kubernetes, показывающий мастер, управляющий ключевыми компонентами и двумя узлами. Обратите внимание, что на практике основные компоненты могут быть разделены на несколько систем
(Изображение предоставлено: Будущее)
Четыре ключевых компонента 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 = пароль = YOUR_PASSWORD
kubectl свяжется с сервером API, который проверит команду и сохранит пароль в etcd. Наши сервисы определены в файлах YAML, и теперь нам нужно постоянное хранилище для базы данных MySQL..
apiVersion: v1kind: PersistentVolumeClaimmetadata: имя: mysql-pv-Claunlabels: приложение: wordpressspec: accessModes: — ReadWriteOnceresources: запросы: хранение: 20Gi
Спецификация должна быть в основном самоочевидной. Поля имени и метки используются для ссылки на это хранилище из других частей Kubernetes, в данном случае нашего контейнера WordPress..
Однажды мы’Определив хранилище, мы можем определить экземпляр MySQL, указав его в предопределенном хранилище. Что’с последующим определением самой базы данных. Мы даем этой базе имя и метку для удобства использования в Kubernetes.
Теперь нам нужен еще один контейнер для запуска WordPress. Часть спецификации развертывания контейнера:
вид: Deploymentmetadata: имя: wordpresslabels: приложение: wordpressspec: стратегия: тип: воссоздать
Тип стратегии “Recreate” означает, что если какой-либо код, содержащий приложение, изменится, то запущенные экземпляры будут удалены и созданы заново. Другие варианты включают возможность циклически создавать новые экземпляры и удалять существующие экземпляры один за другим, что позволяет службе продолжать работу во время развертывания обновления. Наконец, мы объявляем сервис для самого WordPress, включающий код PHP и Apache. Часть файла YAML, объявляющая это:
метаданные: имя: wordpresslabels: app: wordpressspec: ports: — порт: 80selector: app: wordpresstier: frontendtype: LoadBalancer
Обратите внимание на последнюю строку, определяющую тип сервиса как LoadBalancer. Это поручает Kubernetes сделать услугу доступной за пределами Kubernetes. Без этой линии это было бы просто внутренним “Только Кубернетес” оказание услуг. И это’сидеть. Kubernetes теперь будет использовать эти файлы YAML в качестве декларации того, что требуется, и будет настраивать модули, соединения, хранилище и т. Д., Как требуется, чтобы кластер вошел в “желательно” государство.
Используйте панель инструментов, чтобы получить краткий обзор Kubernetes в действии
(Изображение предоставлено: угробление)
Это обязательно был только общий обзор 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.
Наконец, вы можете просмотреть длинную техническую статью с отличным обзором Google.’Использование Borg и как это повлияло на дизайн Kubernetes здесь: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.
Узнайте больше о Tiger Computing.
- Лучшее облачное хранилище 2019 года онлайн: бесплатные, платные и бизнес-опции
