Kubernetes+Docker+Istio практика работы в облаке контейнеров

С прогрессом общества и развитием технологий у людей появляется более острая потребность в эффективном использовании ресурсов. В последние годы, с быстрым развитием и зрелостью Интернета и мобильного Интернета, микросервисы крупных приложений также привлекли к себе восторженное внимание предприятий, а контейнерное облачное решение на основе Kubernetes+Docker также попало в поле зрения общественности. Kepler Cloud — это решение для управления микросервисами, основанное на Kubernetes+Docker+Istio.

1. Микросервисы

1.1 Решение проблем микросервисов крупных приложений

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

1.2 О чем мы говорим, когда говорим о микросервисах?

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

1.2.1 Проблема микросервиса

Как разделить микросервисы
Правила бизнес-API
Гарантия согласованности данных
Поздние соображения масштабируемости

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

1.2.2 Проблемы, создаваемые микросервисами

Экологическая совместимость
Как быстро распределить ресурсы
Как быстро развернуть
Как сделать базовый мониторинг
Регистрация и обнаружение службы
Как сделать балансировку нагрузки

Выше перечислены основные проблемы, которые необходимо решать при микросервисе больших приложений, при традиционном использовании виртуальной машины затраты ресурсов будут очень большими. Итак, как решить эти проблемы? Например:

Управление движением
понижение уровня обслуживания
проверенный

Конечно, перед лицом вышеперечисленных проблем у наших друзей-обезьян должны быть решения.

1.3 Service governance

1.3.1 Архитектура Java

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

Eureka
Hystrix
Zuul
Spring-cloud
Spring-boot
ZipKin

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

Давайте посмотрим, как вообще сочетаются базовые языки программирования для решения основных задач.

1.3.2 Другие системы

Consul
Kong
Go-kit
Jaeger/Zipkin

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

Не по теме ~ Мы также можем использовать вышеуказанные инструменты для формирования хорошей микросервисной архитектуры.

Consul: использование в качестве центра обнаружения и настройки служб
Kong: как сервисный шлюз
Jaeger: используется как трассировщик ссылок
Go-kit: компоненты для разработки

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

2. Докер и Кубернетес

Практичное решение для создания платформы на базе Docker+k8s.

2.1 Docker

Docker — очень мощный контейнер.

Улучшенное использование ресурсов
Совместимость с окружающей средой, портативность
Быстрое расширение и расширение
контроль версий

После использования Docker мы обнаружили, что есть больше вещей, с которыми можно поиграть, и больше гибкости. Мало того, что улучшено использование ресурсов и гарантирована согласованность среды, управление версиями также стало более удобным.

В прошлом мы использовали Jenkins для сборки, и когда нам нужно было откатиться, нам нужно было снова пройти процесс сборки jenkins, что было очень хлопотно. Если это Java-приложение, время его сборки будет очень большим.

После использования Docker все это становится просто, достаточно стянуть образ определенной версии и запустить его (если есть локальный кеш для запуска определенной версии напрямую), это улучшение очень эффективно.

(сеть источника изображения)

Теперь, когда мы используем контейнеры Docker в качестве основы для сервисов, нам определенно нужно организовать контейнеры, и было бы ужасно, если бы мы этого не сделали. Для оркестрации контейнеров Docker у нас есть множество вариантов: Docker Swarm, Apache Mesos и Kubernetes Среди этих инструментов оркестрации мы выбрали Kubernetes, короля оркестрации сервисов.

2.1.1 Docker VS VM

ВМ: создание виртуальной машины занимает 1 минуту, развертывание среды — 3 минуты, а развертывание кода — 2 минуты.
Docker: Запустите контейнер в течение 30 секунд.

2.2 Why choose Kubernetes

Давайте сравним эти три инструмента оркестрации контейнеров.

2.2.1 Apache Mesos

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

Но его базовый язык — не Golang, он не входит в наш стек технологий, стоимость его обслуживания увеличится, поэтому мы сначала исключаем его.

2.2.2 Docker Swarm

Docker Swarm — это среда планирования, разработанная Docker. Одним из преимуществ разработки самого Docker является использование стандартного Docker API. Архитектура Swarm состоит из двух частей:

(сеть источника изображения)

Его использование не будет здесь подробно описываться.

2.2.3 Kubernetes

Kubernetes — это система оркестрации контейнеров Docker, которая использует концепции меток и модулей для разделения контейнеров на логические единицы. Поды — это наборы совместно расположенных контейнеров, которые развертываются и планируются вместе для формирования сервиса, что является основным отличием Kubernetes от двух других фреймворков. По сравнению с методами планирования контейнеров на основе подобия (такими как Swarm и Mesos) этот подход упрощает управление кластером.

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

Конкретное использование Kubernetes не будет здесь подробно описываться, на веб-сайте есть много информации для справки.

2.3 Kubernetes in kubernetes

Kubernetes (k8s) — это платформа с открытым исходным кодом для автоматизации операций с контейнерами, включая развертывание, планирование и масштабирование в кластерах узлов.

Автоматическое развертывание и репликация контейнеров
Увеличение или уменьшение контейнеров в любое время
Организуйте контейнеры в группы и обеспечьте балансировку нагрузки между контейнерами.
Легко обновляйте новые версии контейнеров приложений
Обеспечивает отказоустойчивость контейнера, заменяет контейнер в случае сбоя и т. д.

2.4 Kubernetes is not enough either

На данный момент мы решили следующие проблемы:

Docker: согласованная среда, быстрое развертывание.
Kubernetes: регистрация и обнаружение сервисов, балансировка нагрузки и быстрое выделение ресурсов.

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

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

Очень популярное решение за последние два года: Service Mesh.

3. Сервисная сетка

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

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

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

На рынке существует множество фреймворков ServiceMesh, и мы выбрали Istio, который находится в авангарде.

3.1 Istio

Открытая платформа для подключения, управления и защиты микросервисов.

Поддержка платформ: Kubernetes, Mesos, Cloud Foundry.
Наблюдаемость: метрики, журналы, трассировки, зависимости. визуализация.
Идентификация и безопасность службы: обеспечивает проверяемую идентификацию для службы, аутентификацию между службами.
Управление трафиком: динамический контроль связи между службами, маршрутизация входящего и исходящего трафика, внесение ошибок.
Применение политик: проверка предпосылок, управление квотами между службами.

3.2 Почему мы выбрали Istio?

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

Хотя он достиг только версии 1.0, мы начали с версии 0.6, чтобы попробовать опыт, запустить тестовую среду, а затем вышла версия 0.7.1, мы обновились до версии 0.7.1 для запуска, а затем вышла 0.8.0LTS, и мы начали официально использовать версию 0.8.0 и составили план обновления.

В настоящее время последняя версия достигла 1.0.4, но мы не готовы к обновлению.Я хочу подождать, пока она не будет обновлена до 1.2, прежде чем ее можно будет официально применять в больших масштабах. 0.8.0LTS по-прежнему подходит для небольших масштабов.

3.3 Архитектура Истио

Давайте сначала посмотрим на архитектуру Istio.

Панель управления Istio в основном разделена на три части: Pilot, Mixer и Istio-Auth.

Пилот: в основном используется для обнаружения сервисов и правил маршрутизации, а также для управления всеми посланниками, он потребляет много ресурсов.
Mixer: в основном отвечает за запросы политики и управление квотами, а также за отслеживание, все запросы будут передаваться Mixer.
Istio-Auth: Модернизация трафика, аутентификации и др. На данный момент мы не включили эту функцию, да и спрос не особо большой, т.к. сам кластер изолирован от внешнего мира.

В каждый под будет внедрен Sidecar, и весь трафик в контейнере будет передаваться в Envoy через iptables для обработки.

4. Кубернетес и Истио

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

4.1 Kubernetes Cluster

На что похож наш кластер k8s, когда ресурсов мало?

4.1.1 Главный кластер

Master Cluster:
- ETCD, Kube-apiserver, kubelet, Docker, kube-proxy, kube-scheduler, kube-controller-manager, Calico, keepalived, IPVS.

4.1.2 Узел узел

Node:
- Kubelet, kube-proxy, Docker, Calico, IPVS.

(сеть источника изображения)

API мастеров, которые мы вызываем, управляются через keepalived.Если мастер выходит из строя, он может плавно перейти к API других мастеров, не влияя на работу всего кластера.

Конечно, мы также настроили два граничных узла.

4.1.3 Edge Node

краевой узел
вход потока

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

4.2 Процесс запроса внешней услуги

Самый внешний уровень — это DNS.Через пан-разрешение в Nginx, Nginx передает трафик на виртуальный IP-адрес кластера, а затем виртуальный IP-адрес на HAproxy кластера и отправляет внешний трафик на шлюз нашего граничного узла.

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

Это процесс без Mixer и обнаружения политик, и используется только Istio-IngressGateway. Это изменится, если будут использоваться все компоненты Istio, но основной поток останется прежним.

4.3 Logging

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

Node Filebeat собирает журналы хоста.
Каждый модуль внедряется в контейнер Filebeat для сбора бизнес-журналов.

Filebeat будет развернут вместе с контейнером приложения, и приложению не нужно знать о его существовании, достаточно лишь указать каталог ввода лога. Конфигурация, используемая Filebeat, считывается из ConfigMap, и вам нужно только поддерживать правила сбора логов.

На картинке выше показан лог, который мы видим из Kibana.

4.4 Prometheus + Kubernetes

Система мониторинга на основе временных рядов.
Легко интегрируйте инфраструктуру и уровень приложений с kubernetes.
Модель данных "ключ-значение" с мощными функциями.
Заводская поддержка.

4.4.1 Grafana

4.4.2 Alarm

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

4.4.3 Общая архитектура

Вся архитектура состоит из периферийных служб и базовых служб в кластере.К периферийным службам относятся:

Консул используется как центр конфигурации.
Prometheus+Grafana используется для мониторинга кластера K8s.
Zipkin предлагает собственное определение отслеживания ссылок.
Сбор и анализ журналов ELK, все журналы в нашем кластере будут помещены сюда.
Репозиторий кода Gitlab.
Jenkins используется для сборки кода, его упаковки в образ Docker и загрузки в репозиторий.
Репозиторий зеркальный репозиторий.

Кластеры:

HAProxy+keeprlived отвечает за переадресацию трафика.
Сеть называется Calico, и Calico имеет бета-уровень поддержки режима прокси-сервера ipvs kube-proxy. Поддержка Calico ipvs включается автоматически, если Calico обнаруживает, что kube-proxy работает в этом режиме, поэтому включаем IPVS.
DNS внутри кластера — CoreDNS.
Мы развернули два шлюза, в основном используя Istio IngressGateway и TraefikIngress в качестве резервного. Когда IngressGateway не работает, мы можем быстро переключиться на TraefikIngress.
Выше приведены соответствующие компоненты Istio.
Последний наш сервис APP.
Кластер собирает логи через Filebeat и отправляет их на внешнюю ES.
Мониторинг внутри кластера включает в себя:
- State-Metrics в основном используется для автоматического масштабирования компонентов мониторинга.
- Mail&Wechat — служба оповещения собственной разработки
- Внутренний мониторинг кластера Prometheus+Grafana+AlertManager, в основном мониторинг сервисов и сопутствующих базовых компонентов
- Потоковая база данных InfluxDB+Heapster хранит информацию мониторинга всех сервисов.

4.5 Как развертывать приложения в Kubernetes?

4.5.1 НИОКР упаковываются в зеркальные копии, передаются на склады и управляемые версии

Изучайте Докер.
Сложно научиться настраивать хранилище и вручную упаковывать и загружать.
Изучите знания, связанные с k8s.

4.5.2 Использование Jenkins для упаковки, передачи образов и обновления версий

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

Существует ли надежное и простое в использовании решение, не требующее особых технических знаний?

5. Облачная платформа Kpl

5.1 Облачная платформа Kepler

Kepler Cloud Platform — это легкая платформа PaaS.

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

5.2 Развертывание сервисов на платформе Kepler

Чтобы снизить стоимость обучения и сложность развертывания, очень просто развернуть приложения на платформе Kepler, просто добавив Dockerfile.

Ссылка на докерфайл:

Выше приведен обычный режим, сборка кода Jenkins и сборка Docker.

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

5.2.1 Почему бы не создать файл Dockerfile автоматически?

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

5.3 Интеграция инструментов

Облачная платформа Kepler интегрирует такие API, как gitlab, Jenkins, repo, k8s, istio, promtheus, электронная почта, WeChat и т. д.
Реализовать управление всем жизненным циклом услуги.
Обеспечьте управление услугами, создание, выпуск, версию, мониторинг, сигнализацию, журнал и некоторые периферийные дополнительные функции, центр сообщений, центр конфигурации, вход в контейнер, сервис в автономном режиме и т. д.
Для служб может быть выполнена настройка режима службы, типа службы, расширение и расширение одним ключом, откат управления API службы и управление хранилищем.

5.4 Процесс публикации

Пользователи отправляют свой собственный Dockerfile и код в Gitlab, а затем заполняют некоторые параметры на облачной платформе Kepler для создания собственных приложений.

После того, как приложение будет создано, в Jenkins будет создан Job, код будет сброшен и будет выполнена сборка Docker (если многоэтапная сборка не выбрана, сначала будет выполняться go build или mvn), затем запакованный Docker изображение будет отправлено на зеркальное хранилище, и, наконец, вызовите API платформы или вызовите уведомление k8s, чтобы получить последнюю версию.

Пользователям нужно только управлять своими приложениями на облачной платформе Kepler, а все остальное выполняется автоматически.

5.5 Начните с создания службы

Знакомство с платформой мы начинаем с создания сервиса.

Основной интерфейс платформы:

Нажмите «Создать услугу», чтобы перейти на страницу создания.

Заполните основную информацию:

Заполните детали:

Базовая информация взята на примере Golang, при выборе других языков параметры, которые необходимо заполнить, будут немного отличаться.

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

5.5.1 Сведения об услуге

Сборка для обновления версии приложения:

Режим обслуживания вызовов, который можно настроить между обычным и сеткой обслуживания.

Предоставляет ли сервис возможность предоставления внешних сервисов:

Расширение и настройка процессора и памяти:

Отрегулируйте количество подов для запуска:

Веб-версия терминала:

5.5.2 Запланированные задачи

5.5.3 Постоянное хранилище

Администратор создает StorageClass и PersistentVolumeClaim, а пользователям нужно только выбрать соответствующий PVC для своей собственной службы для привязки и записи.

Хранилище использует NFS.

5.5.4 Tracing

5.5.5 Consul

Консул используется как центр конфигурации, и мы предоставляем клиент Golang.

$ go get github.com/lattecake/consul-kv-client

Он автоматически синхронизирует конфигурацию каталога консула в памяти, и вам нужно только получить конфигурацию непосредственно из памяти.

5.5.6 Repository

Github: GitHub.com/Боюсь даже облако/Боюсь…
Document: docs.nsini.com
Demo: kplcloud.nsini.com

Автор: Ван Цун

Стартер: Мастер Йиджи