Недавно я размышлял о том, почему Kubernetes в конечном итоге выиграет в гонке за поддержку контейнерных платформ и микросервисов. Поскольку со многих точек зрения три контейнерные платформы практически одинаковы с функциональной точки зрения, конкретные сравнения см. в двух моих предыдущих статьях.
«Docker, Kubernetes, DCOS говорят не о вере, а о технологиях»
«Десять лучших моделей выбора контейнерной платформы: Docker, DC/OS, K8S. Кто лидирует? 》
После некоторого размышления об этом и опроса людей, которые практиковали Kubernetes с первых дней.Облако NetEaseАрхитекторы, и, таким образом, имеют сегодняшний обмен.
1. Три перспективы контейнерной платформы из трех основных архитектур миграции корпоративного облака.
Все начинается с трех основных архитектур для перехода предприятий в облако.
Как показано на рисунке, три основные архитектуры предприятия — это ИТ-архитектура, архитектура приложений и архитектура данных В разных компаниях разные люди, разные роли и разные направления деятельности.
Для большинства предприятий обращение к облаку инициируется ИТ-отделом, а инициатором часто является отдел эксплуатации и обслуживания.Они сосредотачиваются на вычислениях, сети и хранении и пытаются сократить капитальные и эксплуатационные расходы с помощью служб облачных вычислений. .
У некоторых компаний есть бизнес ToC, поэтому они накопили большой объем пользовательских данных.Операции компании должны использовать эту часть данных для анализа больших данных и цифровых операций.Поэтому этим компаниям часто нужно обращать внимание на архитектуру данных.
Предприятия, занимающиеся интернет-приложениями, часто в первую очередь сосредотачиваются на архитектуре приложения, способной ли она удовлетворить потребности конечных клиентов и обеспечить клиентам хорошее взаимодействие с пользователем. Объем бизнеса имеет тенденцию к взрывному росту за короткий период времени. параллельная архитектура приложения и надежда, что эту архитектуру можно будет быстро повторить, чтобы захватить воздух.
До появления контейнеров эти три архитектуры часто решались с помощью облачных платформ виртуальных машин. Когда появился контейнер, различные хорошие характеристики контейнера заставили людей сиять.Его легкий вес, инкапсуляция, стандартность, простота переноса и простота доставки сделали контейнерную технологию широко используемой.
Тем не менее, у тысячи людей есть тысяча Гамлетов в их сердцах.Благодаря своей оригинальной работе три типа персонажей увидели удобство, которое дают преимущества контейнеров, со своей точки зрения.
Для ИТ-специалистов по эксплуатации и обслуживанию, которые раньше управляли вычислениями, сетью и хранилищем в компьютерном зале, контейнеры больше похожи на упрощенную модель эксплуатации и обслуживания.По их мнению, самая большая разница между контейнерами и виртуальными машинами заключается в том, что они легковесны. , запускаются быстро, и они часто гордятся тем, что запускают контейнеры в режиме виртуальной машины.
Для архитектуры данных они ежедневно выполняют различные задачи по вычислению данных.По сравнению с исходной JVM контейнер представляет собой режим выполнения задач с лучшей изоляцией и высоким использованием ресурсов.
С точки зрения архитектуры приложений контейнеры — это форма доставки микросервисов.Контейнеры предназначены не только для развертывания, но и для доставки, D в CI/CD.
Следовательно, у людей с этих трех точек зрения будут разные методы использования контейнеров и выбора контейнерных платформ.
2. Kubernetes — это мост между микросервисами и DevOps
Swarm: инженер по эксплуатации ИТ
С точки зрения инженеров по эксплуатации и обслуживанию ИТ: контейнеры в основном легкие и быстро запускаются. И автоматический перезапуск, автоматическая ассоциация. Благодаря технологии эластичного масштабирования создается впечатление, что ИТ-специалистам по эксплуатации и обслуживанию не нужно работать сверхурочно.
Дизайн Swarm явно больше соответствует модели управления традиционных ИТ-инженеров.
Они хотят иметь возможность четко видеть распределение и статус контейнеров на разных машинах, и они могут легко подключиться к контейнеру по SSH, чтобы при необходимости проверить ситуацию.
Контейнер лучше перезапускать на месте, а не планировать новый контейнер случайным образом, чтобы все, что изначально было установлено в контейнере, было там.
Очень удобно сделать образ работающего контейнера, а не запускать его из Dockerfile, чтобы 100 задач, выполненных вручную в этом контейнере, в дальнейшем можно было использовать повторно.
Интеграция с контейнерной платформой лучше.Цель использования этой платформы-упростить эксплуатацию и обслуживание.Если сама контейнерная платформа очень сложная,как сам Kubernetes,так много процессов,и ее высокая доступность и эксплуатация и обслуживание нужно учитывать затраты.Он рентабельный, он не более хлопотный, чем оригинал, да и стоимость увеличилась.
Лучше всего иметь тонкий слой, например платформу управления облаком, но удобнее делать межоблачное управление, ведь образы контейнеров легко мигрировать между облаками.
Использование Swarm более знакомо ИТ-инженерам, ведь он может делать все то же, что и OpenStack, и работает быстрее.
Проблемы с Роем
Однако в качестве облегченной виртуальной машины контейнер доступен для клиентов, будь то внешний клиент или разработка компании.Когда он не используется ИТ-персоналом, они думают, что это то же самое, что и виртуальная машина, но они находят другое частей.Претензий будет много.
Например, функция самовосстановления, после перезагрузки софт, который был установлен вручную по SSH, пропал, и даже файлы на жестком диске пропали, а в Entrypoint приложение не запускается автоматически, заходим и запускаем процесс , и клиенты будут жаловаться на вас, какой смысл в этой функции самовосстановления?
Например, некоторые пользователи будут ps и найдут процесс, который они не знают, поэтому они убивают его напрямую.В результате получается процесс Entrypoint, и весь контейнер зависает напрямую.Клиент жалуется, что ваш контейнер слишком нестабилен и продолжает зависать.
Когда контейнер назначается автоматически, IP-адрес не сохраняется, поэтому исходный IP-адрес часто теряется после перезапуска. Многие пользователи будут просить его. Можно ли это сохранить? IP-адрес, настроенный в исходном файле конфигурации, изменится после перезапуска. Теперь как этим пользоваться, лучше использовать виртуальную машину, по крайней мере ее не так просто повесить.
Системный диск контейнера, то есть диск операционной системы, часто имеет фиксированный размер, хотя его можно настроить на ранней стадии, изменить на более поздней стадии сложно, и нет возможности, чтобы каждый пользователь может выбрать размер системного диска. Некоторые пользователи будут жаловаться, что многие вещи мы изначально кладем прямо на системный диск, и это нельзя настроить.В чем эластичность облачных вычислений.
Если сказать заказчику, что контейнер смонтирован с диском данных, то контейнер запустится.Некоторые заказчики хотят смонтировать другой диск, как облачный хост.Контейнер сделать сложнее и будет ругаться со стороны заказчика.
Если пользователи контейнера не знают, что они используют контейнер, им будет сложно использовать виртуальную машину, а платформа вообще не годится.
Хотя начать работу со Swarm относительно легко, когда возникает проблема, человеку, который эксплуатирует и обслуживает контейнерную платформу, будет сложно решить проблему.
В Swarm слишком много встроенных функций, и все они связаны друг с другом, и если возникает ошибка, отлаживать ее непросто. Сложно настроить, если текущий функционал не соответствует потребностям. Многие функции связаны в Менеджере, что сильно влияет на работу и перезапуск Менеджера.
Месос: инженер по работе с данными
С точки зрения эксплуатации и обслуживания платформы больших данных очень важным фактором является то, как быстрее планировать задачи обработки больших данных и быстрее выполнять больше задач в ограниченном пространстве и времени.
Поэтому, когда мы оцениваем, хороша платформа больших данных или нет, ее часто измеряют количеством задач, выполняемых в единицу времени, и объемом данных, которые можно обработать.
С точки зрения работы с данными и обслуживания, Mesos является хорошим планировщиком. Поскольку он может выполнять задачи, он также может запускать контейнеры. Spark и Mesos естественным образом интегрированы. С контейнерами можно использовать более детальные методы выполнения задач.
До детального планирования задач процесс выполнения задач выглядит следующим образом. Для выполнения задачи требуется, чтобы главный узел управлял выполнением всей задачи, а рабочий узел — для выполнения каждой подзадачи. В начале всего суммарного задания выделяются ресурсы, занятые Мастером и всеми Работами, настраивается среда и там выполняются подзадачи Когда ни одна подзадача не выполняется, там резервируются ресурсы этой среды Да, очевидно, что не каждая работа всегда заполнена, и есть много пустой траты ресурсов.
В мелкозернистом режиме в начале выполнения всей задачи Мастеру выделяются только ресурсы, а Работнику ресурсы не выделяются.Когда нужно выполнить подзадачу, Мастер временно обращается за ресурсами из Месоса, и у среды нет ресурсов, что вы готовы сделать? Благо есть Докер, запусти Докер, окружение все есть, запускай в нем подзадачи. При отсутствии задач ресурсы на всех узлах могут использоваться другими задачами, что значительно повышает эффективность использования ресурсов.
Это самое большое преимущество Mesos.В документе Mesos самым важным является улучшение использования ресурсов, а двухуровневый алгоритм планирования Mesos является ядром.
Оказывается, Mesos проще выбрать в качестве платформы управления контейнерами для тех, кто занимается эксплуатацией и обслуживанием больших данных. Просто задача получилась короткая, а с марафоном можно пробежать и длинную задачу. Но позже Spark отказался от мелкозернистого режима, потому что эффективность все еще относительно низкая.
Проблемы с Мезосом
Планирование — это основа ядра в области больших данных, и оно важно для контейнерной платформы, но не для всех. Следовательно, контейнеры также должны быть организованы, и необходимы различные периферийные компоненты, позволяющие контейнерам выполнять длительные задачи и получать доступ друг к другу. Марафон — это только первый шаг в Великом походе.
Поэтому производители, которые использовали Marathon + Mesos в первые дни, в основном использовали Marathon и Mesos nude.Из-за незавершенности окружающего пространства требовались различные упаковки, и у каждой компании они были разные. Если вы заинтересованы, вы можете пойти в сообщество, чтобы увидеть производителей Marathon и Mesos, У каждого есть свое собственное решение для балансировки нагрузки и свое собственное решение для обнаружения сервисов.
Поэтому DCOS была разработана позже, то есть помимо Marathon и Mesos было добавлено большое количество периферийных компонентов для дополнения функций, которые должна иметь контейнерная платформа, но, к сожалению, многие производители кастомизировали свои, и до сих пор используют Marathon и Месос.
Более того, хотя Mesos является хорошим агентом планирования, он решает только часть планирования, а другая часть полагается на то, что пользователь напишет структуру и планирование внутри.Иногда необходимо разработать Executor, который все еще очень сложен для развиваться, а стоимость обучения относительно высока.
Хотя более поздние функции DCOS относительно завершены, кажется, что он не использует унифицированный язык, такой как Kubernetes, а использует смешанный подход. Во всей экосистеме DCOS Marathon написан на Scala, Mesos — на C++, Admin Router — на Nginx+lua, Mesos-DNS — на Go, Marathon-lb — на Python, а Minuteman — на Erlang. самостоятельно починить сложнее.
Kubernetes
Kubernetes отличается. Люди, которые впервые видят Kubernetes, думают, что это замечательное место. Контейнер еще не создан. Есть много концепций и много документации. Я просто хочу создать контейнер для игры, зачем столько предварительных условий. Если вы поместите концепцию Kubernetes в интерфейс и позволите клиентам создавать контейнеры, клиенты вас точно будут ругать.
С точки зрения разработчика, использование Kubernetes определенно не похоже на использование виртуальной машины.Помимо написания кода, сборки и тестирования, вам также необходимо знать, что ваши приложения работают в контейнерах, а не в роли хозяина. . Разработчики должны знать, что контейнер отличается от оригинального способа развертывания, нужно различать stateful и stateless, при зависании контейнера он будет восстановлен по образу. Разработчикам нужно писать Dockerfiles, заботиться о доставке среды и знать слишком много вещей, которых они не знали раньше. Если честно, то совсем не удобно.
С точки зрения эксплуатационного и обслуживающего персонала использование Kubernetes определенно не то же самое, что эксплуатация и обслуживание виртуальных машин.Я поставил среду и то, как приложения вызывают друг друга, мне все равно, мне важно только сетевое подключение. С точки зрения эксплуатации и обслуживания, он сделал слишком много вещей, о которых ему не следует заботиться, таких как обнаружение служб, центр конфигурации, автоматический выключатель и переход на более раннюю версию, что должно быть заботой на уровне кода и должно быть заботой SpringCloud и Dubbo, почему мы должны заботиться об этом на уровне контейнерной платформы.
Kubernetes + Docker, но это мост для интеграции Dev и Ops.
Docker — это инструмент доставки микросервисов.После микросервисов существует слишком много сервисов, которыми нельзя управлять только с помощью эксплуатации и обслуживания, и легко совершать ошибки.Это требует, чтобы R&D начали заботиться о доставке среды. Например, что было изменено в конфигурации, какие каталоги созданы и как настроить разрешения, лучше знает только разработчик, с одной стороны, сложно своевременно синхронизировать эту информацию с отделом эксплуатации и обслуживания. и точный способ через документацию.Даже если это синхронизировано, операция Объем обслуживания отдела технического обслуживания также очень велик.
Поэтому с контейнерами самое большое изменение — это ранняя доставка окружения, на каждую разработку уходит на 5% больше времени в обмен на 200% труда по эксплуатации и обслуживанию, а также улучшается стабильность.
С другой стороны, изначально эксплуатация и обслуживание только доставляли ресурсы и давали вам виртуальную машину. Мне все равно, как приложения в виртуальной машине обращаются друг к другу. Что вам нравится? После Kubernetes уровень эксплуатации и обслуживания должен обратите внимание на обнаружение и настройку службы.Центр, понижение предохранителя.
Эти двое слиты воедино.
С точки зрения разработки микросервисов, хотя Kubernetes сложен, его дизайн разумен и соответствует идее микросервисов.
Три, десять точек проектирования микросервиса
В чем суть микросервисов? Первая картинка — это вся экология SpringCloud.
Вторая диаграмма — это 12 элементов микросервисов иОблако NetEaseупражняться.
На третьей картинке показаны все моменты, которые необходимо учитывать при построении высококонкурентного микросервиса. (Реклама, скоро будет курс.)
Далее мы подробно обсудим точки проектирования микросервисов.
Первая точка проектирования: API-шлюз.
В процессе внедрения микросервисов неизбежно приходится сталкиваться с агрегацией и разделением сервисов.Когда разделение серверных сервисов происходит относительно часто, например, в мобильном приложении, часто требуется унифицированная запись для маршрутизации разных запросов к разным сервисам, независимо от того, как они будут разделены и объединены позже, прозрачны для мобильного телефона.
С помощью шлюза API простая агрегация данных может выполняться на уровне шлюза, поэтому ее не нужно выполнять в мобильном приложении, чтобы мобильное приложение потребляло меньше энергии и было удобнее для пользователей.
С единым API-шлюзом также можно выполнять единую аутентификацию и аутентификацию.Хотя взаимные вызовы между сервисами сложнее и будет больше интерфейсов, API-шлюз часто предоставляет только необходимые внешние интерфейсы и выполняет унифицированную аутентификацию на интерфейсах. аутентификацию, чтобы при обращении внутренних сервисов друг к другу не было необходимости выполнять аутентификацию и аутентификацию, и эффективность была бы выше.
С помощью унифицированного шлюза API на этом уровне могут быть установлены определенные политики, A/B-тестирование, сине-зеленый выпуск, отклонение среды перед выпуском и т. д. Шлюзы API, как правило, не имеют состояния и масштабируются горизонтально, поэтому они не становятся узким местом в производительности.
Второй пункт дизайна: без сохранения состояния, различайте приложения с состоянием и без него.
Важным фактором, влияющим на миграцию и горизонтальное расширение приложений, является состояние приложения.Службы без сохранения состояния должны перемещать это состояние и хранить данные сеанса, данные файлов и структурированные данные в едином внутреннем хранилище, чтобы приложение содержит бизнес-логику.
Состояние неизбежно, такое как ZooKeeper, DB, Cache и т. д., чтобы объединить все эти вещи с состоянием в очень централизованном кластере.
Весь бизнес разделен на две части: одна часть без сохранения состояния, а другая часть с сохранением состояния.
Часть без сохранения состояния может достигать двух целей: одна — это случайное развертывание в компьютерных залах, то есть мобильность, а другая — эластичное масштабирование, которое легко расширять.
Части с отслеживанием состояния, такие как DB, Cache и ZooKeeper, имеют свои собственные механизмы высокой доступности, и им необходимо использовать свои собственные механизмы высокой доступности для достижения такого состояния кластера.
Несмотря на то, что он не имеет состояния, текущие обрабатываемые данные все еще будут в памяти. Если текущий процесс зависнет, некоторые данные должны быть потеряны. Для этого служба должна иметь механизм повторных попыток, а интерфейс должен быть идемпотентным. механизм обнаружения службы, достаточно еще раз вызвать другой экземпляр серверной службы.
Пункт третий: горизонтальное расширение базы данных.
База данных — это состояние хранения, самое важное и самое подверженное узким местам. В распределенной базе данных производительность базы данных может увеличиваться линейно с увеличением количества узлов.
Нижняя часть распределенной базы данныхRDS, является активным и резервным.Благодаря возможностям разработки ядра MySql мы можем добиться нулевой потери данных при переключении между активным и резервным, поэтому очень обнадеживает то, что данные попадают в этот RDS, даже если узел завис, после переключение завершено, ваши данные также не будут потеряны.
Далее следует вопрос о том, как поддерживать большую пропускную способность по горизонтали.Выше находится балансировка нагрузки NLB с использованием LVS, HAProxy, Keepalived и уровня Query Server ниже. Query Server можно масштабировать по горизонтали на основе отслеживаемых данных.В случае возникновения сбоя его можно заменить и отремонтировать в любое время, без какого-либо восприятия со стороны бизнес-уровня.
Другой - развертывание двухкомпьютерных залов.DDB разработала компонент NDC канала данных, который может синхронизировать разные DDB в разных компьютерных залах.В настоящее время он распределен не только в одном центре обработки данных, но и в нескольких центрах обработки данных. Также в каждом дата-центре будет резервная копия, аналогичная active-active, и высокая доступность имеет очень хорошую гарантию.
Четвертый пункт дизайна: кеш, кеш
Кэширование очень важно в сценариях с высоким параллелизмом. Должен быть иерархический кеш, чтобы данные были максимально приближены к пользователю. Чем ближе данные к пользователю, тем больший объем параллелизма может быть перенесен и тем короче время отклика.
В мобильном клиентском приложении должен быть слой кеша: не все данные постоянно берутся из бэкенда, а только важные, критичные и часто меняющиеся данные.
В частности, для статических данных вы можете получить их один раз через определенный период времени, и нет необходимости получать их в центре обработки данных.CDN, кэшировать данные на узле, ближайшем к клиенту, и загружать их поблизости.
иногдаCDNЕсли внутри нет, вам все равно придется вернуться в центр обработки данных для загрузки, что называется обратно к источнику.В самом внешнем слое центра обработки данных мы называем его уровнем доступа.Вы можете настроить слой кэша для перехвата большинства запросов, так что фон не будет влиять на нагрузку на базу данных.
Если это динамические данные, вам все равно нужно получить доступ к приложению, сгенерировать их с помощью бизнес-логики в приложении или прочитать их из базы данных.Чтобы уменьшить нагрузку на базу данных, приложение может использовать локальный кеш или распределенный кеш, напримерMemcachedилиRedis, чтобы большинство запросов можно было прочитать из кеша, не обращаясь к базе данных.
Конечно, динамические данные также можно в определенной степени сделать статическими, то есть понизить уровень до статических данных, тем самым снизив нагрузку на серверную часть.
Пять пунктов дизайна: разделение сервисов и обнаружение сервисов.
Когда система не может справиться с этим, а приложение быстро меняется, часто необходимо рассмотреть вопрос о разделении относительно большой службы на ряд небольших служб.
Первым преимуществом этого является то, что разработка относительно независима. Когда много людей поддерживают один и тот же репозиторий кода, изменения в коде часто будут влиять друг на друга, что часто происходит. Если я ничего не изменю, тест будет не получится, и код будет отправлен.Часто возникают конфликты, и требуется слияние кода, что сильно снижает эффективность разработки.
Еще одним преимуществом является то, что онлайн независим. Модуль логистики подключен к новой курьерской компании. Он должен выйти в онлайн вместе с заказом. Это очень неразумное поведение. Если вы хотите, чтобы я провел встречу, пора разделяться. вверх.
Кроме того, происходит расширение периодов высокой параллелизма.Часто только самые важные процессы заказа и оплаты являются ядром.Необходимо только расширить ключевые связи транзакций.Если в это время подключено много других сервисов,даже если расширение неэкономично, это все еще очень рискованно.
Затем есть аварийное восстановление и понижение версии.Во время большого продвижения может потребоваться пожертвовать некоторыми угловыми функциями, но если все коды связаны вместе, понизить некоторые угловые функции сложно.
Конечно, после завершения разделения отношения между приложениями становятся более сложными, поэтому необходим механизм обнаружения служб для управления отношениями между приложениями, а также для обеспечения автоматического восстановления, автоматического сопоставления, автоматической балансировки нагрузки и автоматического отказоустойчивого переключения. .
Design Point 6: Оркестрация сервисов и эластичное масштабирование
При разделении сервиса количество процессов будет очень большим, поэтому необходимоСервисная оркестровка, чтобы управлять зависимостями между службами и кодировать развертывание служб, что мы часто называем инфраструктурой как кодом. Таким образом, выпуск, обновление, откат, расширение и сокращение службы могут быть достигнуты путем изменения файла компоновки, что повышает прослеживаемость, простоту управления и возможности автоматизации.
Поскольку файлом оркестровки также может управлять репозиторий кода, можно обновить пять из ста служб, изменив конфигурацию пяти служб в файле оркестровки. сценарий автоматического развертывания обновления для обновления онлайн-среды.При обнаружении проблем в новой среде, конечно, есть надежда, что эти пять служб будут откатываться атомарно.Если нет файла компоновки, вам нужно вручную записать, какие пять служб на этот раз были обновлены службы. С файлом компоновки, если вы вернетесь в репозиторий кода, вы будете откатываться к предыдущей версии. Все операции можно увидеть в репозитории кода.
Седьмой пункт дизайна: единый центр конфигурации
После разделения службы количество служб очень велико.Если все конфигурации размещаются локально в приложении в виде конфигурационных файлов, им очень сложно управлять.Возможно, что при наличии сотен или тысяч процессов, появляется одна конфигурация.Проблема в том,что вам сложно ее найти,поэтому нужен единый центр конфигурации для управления всеми конфигурациями и выдачи единых конфигураций.
В микросервисах конфигурации часто делятся на несколько категорий: одна — это практически неизменяемая конфигурация, которую можно разместить прямо в образе контейнера, а вторая — это конфигурация, которая будет определяться при запуске и которая часто передается через среду. Переменные передаются при запуске контейнера.Третий тип-это унифицированная конфигурация,которую нужно раздать через центр конфигурации.Например в случае большой акции нужно понизить некоторые функции,какие функции можно понизить , и какие функции не могут быть понижены.Это может быть настроено единообразно в файле конфигурации.
Восьмой пункт дизайна: унифицированныйбревенчатый центр
Также, когда количество процессов очень велико, сложно зайти в сотни контейнеров один за другим для просмотра логов, поэтому для сбора логов нужен единый центр логов, чтобы собранные логи было легко анализировать , спецификация логов, Есть определенные требования Когда все сервисы соответствуют единой спецификации логов, процесс транзакции можно проследить единообразно в центре логов. Например, в последней поисковой системе журналов найдите номер транзакции, и вы увидите, в каком процессе произошла ошибка или исключение.
Девятая точка проектирования: плавление, ограничение тока, переход на более раннюю версию
Службы должны иметь возможность объединения, ограничения тока и перехода на более раннюю версию. Когда служба вызывает другую службу и происходит тайм-аут, она должна вернуться вовремя, а не блокироваться в этом месте, тем самым влияя на транзакции других пользователей. Вы можете вернуться к значениям по умолчанию. резервные данные.
Когда служба обнаруживает, что вызываемая служба слишком занята, пул потоков заполнен, пул соединений заполнен или постоянно возникает ошибка, она должна быть своевременно удалена, чтобы предотвратить ненормальную работу службы из-за ошибки или занятости. очередного сервиса.Проводится вперед, вызывая лавину всего приложения.
Когда обнаруживается, что нагрузка на всю систему действительно слишком высока, вы можете понизить некоторые функции или некоторые вызовы, чтобы обеспечить прохождение самого важного процесса транзакции, и все самые важные ресурсы используются для обеспечения самого основного процесс.
Другой метод заключается в том, чтобы ограничить ток.Когда установлены как стратегия слияния, так и стратегия понижения, через стресс-тест всей ссылки вы сможете узнать емкость поддержки всей системы.Поэтому необходимо сформулировать текущая стратегия ограничения, чтобы убедиться, что система находится в стадии тестирования.Если услуга выходит за рамки возможностей поддержки, в услуге может быть отказано. При оформлении заказа в системе выскакивает диалоговое окно с надписью "Система занята, попробуйте еще раз", что не означает, что система зависла, а означает, что система работает нормально, но текущая стратегия ограничения сыграло свою роль.
Десятый пункт проекта: комплексный мониторинг
Когда система очень сложная, необходим унифицированный мониторинг, в основном по двум аспектам: один — работоспособность, а другой — узкое место в производительности. Когда система выходит из строя, система мониторинга может взаимодействовать с системой сигнализации для своевременного обнаружения, уведомления и вмешательства, чтобы обеспечить бесперебойную работу системы.
При нагрузочном тестировании часто встречаются узкие места, и требуется всесторонний мониторинг для выявления узких мест, при этом сайт можно сохранить, чтобы можно было провести отслеживание и анализ для всесторонней оптимизации.
4. Kubernetes сам по себе является микросервисной архитектурой
Основываясь на приведенных выше десяти аспектах дизайна, когда мы оглянемся на Kubernetes, мы обнаружим, что он более приятен для глаз.
Во-первых, сам Kubernetes представляет собой микросервисную архитектуру, которая хоть и выглядит сложной, легко настраивается и масштабируется по горизонтали.
Черная часть — родная часть Kubernetes, а синяя —Облако NetEaseЧасть, настроенная для поддержки крупномасштабных приложений с высокой степенью параллелизма.
API-сервер Kubernetes больше похож на шлюз, предоставляющий унифицированный интерфейс аутентификации и доступа.
Как мы все знаем, управление арендаторами в Kubernetes относительно слабое, особенно для сценариев общедоступного облака и сложного управления отношениями с арендаторами.Нам нужно только настроить сервер API и подключиться к Keystone для управления сложными отношениями с арендаторами, независимо от других компонентов.
В Kubernetes почти все компоненты stateless, а состояние хранится в унифицированном etcd, что делает масштабируемость очень хорошей, компоненты выполняют свои задачи асинхронно, а результаты помещаются в etcd, который не связан друг с другом.
Например, в процессе создания пода на рисунке создание клиента заключается только в создании записи в etcd, и после того, как другие компоненты прослушают это событие, они также асинхронно делают свои дела и помещают результаты обработки в и т.д.. Аналогично не какой компонент удаленно вызывает kubelet и дает ему указание создать контейнер, а находит, что в etcd под привязан к себе, а его только подтягивают.
Чтобы добиться изоляции арендаторов в общедоступном облаке, наша стратегия заключается в использовании разных арендаторов и отказе от совместного использования узлов. Это требует, чтобы Kubernetes знал об уровне IaaS, поэтому нам необходимо реализовать собственный контроллер. Дизайн Kubernetes позволяет нам самостоятельно создать собственный контроллер вместо прямого изменения кода.
В качестве уровня доступа API-Server имеет собственный механизм кэширования, чтобы предотвратить прямое воздействие всех запросов на серверную базу данных. Однако, когда он по-прежнему не может выполнять большое количество одновременных запросов, узким местом остается хранилище etcd на серверной части, точно такое же, как и в приложениях электронной коммерции. Конечно, мыслимым способом является разделение etcd на базу данных и таблицу, а разные арендаторы хранятся в разных кластерах etcd.
С сервером API в качестве шлюза API внутренние службы настраиваются и прозрачны для клиента и kubelet.
На рисунке показан процесс создания кастомизированного контейнера.Из-за большой разницы между количеством узлов в период акции и в период небольшой акции невозможно заранее создать все узлы, что приведет к пустой трате ресурсов.Облако NetEaseСобственный модуль Controller и уровень управления IaaS позволяют динамически вызывать интерфейс IaaS и динамически создавать ресурсы, когда ресурсов для создания контейнеров недостаточно. Все это незаметно для клиента и кублета.
Чтобы решить проблему масштабирования более 30 000 узлов,Облако NetEaseКаждый модуль должен быть оптимизирован.Поскольку каждый подмодуль выполняет только свою собственную функцию, планировщик отвечает только за планирование, а прокси-сервер отвечает только за пересылку, а не за связывание, поэтому каждый компонент может быть оптимизирован независимо, что соответствует независимые функции в микросервисах, независимая оптимизация, не влияют друг на друга. И все компоненты Kubernetes разрабатываются на Go, что проще. Таким образом, Kubernetes медленно запускается, но как только вам нужно будет его настроить, вам будет проще.
5. Kubernetes больше подходит для проектирования микросервисов и DevOps
Хорошо, давайте поговорим о самом K8S, поговорим о концептуальном дизайне K8S и о том, почему он так подходит для микросервисов.
Один из десяти основных шаблонов проектирования микросервисов состоит в том, чтобы различать состояния без сохранения состояния и с сохранением состояния.
Развертывание в основном решает проблему горизонтального расширения за счет количества реплик.
StatefulSet, с другой стороны, может обеспечить приложения с отслеживанием состояния и эффективно использовать свой собственный механизм высокой доступности с помощью таких механизмов, как согласованный сетевой идентификатор, согласованное хранилище, последовательное обновление, расширение и откат. Из-за механизма высокой доступности большинства кластеров узел можно временно приостановить, но большинство узлов нельзя приостановить одновременно. Более того, хотя механизм high-availability может гарантировать, что узел вернется после зависания, есть определенный механизм восстановления, но необходимо знать, какой узел просто завис.Механизм StatefulSet позволяет скриптам в контейнере иметь достаточно информации, чтобы справляться с такими ситуациями.Поймите, что даже если он с отслеживанием состояния, его можно исправить как можно скорее.
Среди микросервисов рекомендуется PaaS облачной платформы, такой как база данных, шина сообщений, кеш и т. д. Но конфигурация также очень сложна, потому что разные среды должны подключать разные сервисы PaaS.
Безголовый сервис в K8S может очень хорошо решить эту проблему: просто создайте безголовый сервис для внешнего сервиса, укажите на соответствующий сервис PaaS и настройте имя сервиса в приложении. Поскольку производственная и тестовая среды разделены на Пространства имен, хотя и настроено одно и то же имя службы, к нему не будет осуществляться неправильный доступ, что упрощает настройку.
Микросервисы незаменимы для обнаружения сервисов.Помимо прикладного уровня, который может использовать SpringCloud или Dubbo для обнаружения сервисов, сервис, конечно же, используется на уровне контейнерной платформы, что может обеспечить балансировку нагрузки, самовосстановление и автоматическую ассоциацию.
Стандартом для оркестрации сервисов является K8S.Файл yml можно поместить в репозиторий кода для управления, а гибкое масштабирование можно обеспечить за счет количества копий развертывания.
Для центра конфигурации K8S предоставляет configMap, который может внедрять конфигурацию в переменные среды или Volume при запуске контейнера. Но единственный минус в том, что конфигурация, инжектированная в переменную окружения, не может быть изменена динамически, к счастью, она может быть в Volume, а пока процесс в контейнере имеет механизм перезагрузки, конфигурация может быть динамически распределена.
Унифицированное ведение журналов и мониторинг часто требует развертывания агента на узле для сбора журналов и метрик. Конечно, он есть на каждом узле. Дизайн daemonset упрощает реализацию.
Конечно, самая популярная в настоящее время Service Mesh может реализовать более точное управление услугами и реализовать такие стратегии, как слияние, маршрутизация и понижение версии. Реализация Service Mesh часто перехватывает служебный трафик и управляет им через sidecars. Это также связано с концепцией пода, у пода может быть несколько контейнеров, и если в исходном дизайне пода нет, контейнер будет запускаться напрямую, что будет очень неудобно.
Поэтому различные конструкции K8S кажутся очень избыточными и сложными, а порог входа относительно высок, но как только вы захотите реализовать настоящие микросервисы, K8S может предоставить вам различные возможные комбинации. Люди, которые практиковали микросервисы, часто имеют глубокое понимание этого.
Шестое, обычное использование Kubernetes
Давайте рассмотрим различные этапы микросервисов и то, как используется Kubernetes.
Этап 1. Использование виртуальных машин общедоступного облака
То есть, стадии микросервиса нет, в принципе с этим справляется один процесс, два процесса высокодоступны, и нет необходимости использовать контейнеры, виртуальные машины — это очень хорошо.
Этап 2: Контейнеры как инструменты непрерывной интеграции
Когда микросервисы начинают разделяться, то, как обеспечить согласованность функций после разделения, требует непрерывной интеграции в качестве гарантии.Как обсуждалось выше, контейнеры являются очень хорошими инструментами непрерывной интеграции и решают D в CI / CD, поэтому в начале вы можете использовать хост-сети, которая может гарантировать, что метод развертывания совместим с исходным.
Если вы хотите использовать частное облако для развертывания и развертывания непосредственно на физической машине, если требования к производительности не очень высоки, но вам необходимо хорошо взаимодействовать с другими физическими машинами, вы можете использовать мост для выравнивания сети. Создав мост и подключив физическую сетевую карту и сетевую карту контейнера к мосту, все контейнеры и физические машины могут находиться в одной сети уровня 2.
Если требования к производительности относительно высоки, например, для развертывания аналогичного кэша можно использовать сетевую карту sr-iov.
Если вы хотите добиться простой изоляции арендаторов, часто используются различные режимы оверлейной сети, что является наиболее распространенным методом развертывания. Данные на рисунке взяты из сети. Flannel и Calico - очень хорошие сетевые плагины. Хотя Flannel вначале использовал режим пользовательского режима, производительность была невысокой. Позже, когда использовался режим ядра, производительность значительно улучшилась. После использования режима gw, производительность была сопоставима с производительностью Calico.
Облако NetEaseПринята глубокая интеграция Kubernetes и IaaS, аналогичная модели Fargate AWS.С одной стороны, пользователи, которые изначально использовали виртуальные машины, могут плавно мигрировать на контейнеры, а с другой стороны, они могут реализовать изоляцию арендаторов публичных облаков .
это слияниеОблако NetEaseАрхитектура сервисов-контейнеров, платформа управления для управления OpenStack и Kubernetes, также использует архитектуру микросервисов, с API-шлюзами, функциями предохранителей и ограничения тока, разделенными на разные сервисы и развернутыми на K8S, поэтому микросервисы есть везде.