Опрос по выбору контейнерной платформы Docker

Docker

[TOC]

Опрос по выбору контейнерной платформы Docker

Аранжировка и выбор

Swarm

  1. Swarm может создавать образы из Dockerfile, но созданные образы можно запускать только на одном узле и нельзя распространять на другие узлы в кластере. Поэтому приложение считается контейнером, который не является мелкозернистым.

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

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

  3. Кластер Swarm в версии докера 1.12 поддерживает автоматическое обнаружение и извлечение отказавших узлов.

  4. В настоящее время Swarm может поддерживать доступ к многоузловым контейнерным сетям через оверлейные сети, что не поддерживается в старой версии.

Месос и Марафон (последняя версия 1.4.1)

  1. Mesos предоставляет абстрактные функции управления ресурсами и структуры планирования.Для доступа к ресурсам, управляемым Mesos, сторонним приложениям необходимо реализовать API, предоставляемый платформой Mesos.

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

  2. Mesos более отказоустойчив, чем Swarm, потому что Mesos может использовать проверки мониторинга для приложения в файле JSON.

  3. Marathon имеет пользовательский интерфейс, его можно рассматривать как приложение, его можно рассматривать как фреймворк для управления контейнерами, а контейнеры могут работать с Marathon через REST API, что удобно для эксплуатации и обслуживания.

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

  4. После эластичного расширения и сжатия Mesos на хост-компьютере будет сгенерировано большое количество контейнеров Docker в состоянии Exit, что потребляет больше ресурсов при очистке и влияет на стабильность системы.

    • По умолчанию Mesos имеет только политики очистки на основе времени, например, через несколько часов или несколько дней.Нет политики очистки, основанной на указанном времени, например, очистка, когда система простаивает, и никакие политики очистки не могут быть настроены. для каждой услуги.
    • Вы можете изменить исходный код программы Marathon, добавить интерфейс очистки контейнера Docker от мусора и очистить контейнер Docker в состоянии Exit для разных сервисов в соответствии с заданной стратегией.

  5. Mesos не поддерживает вытеснение и не может устанавливать приоритет задачи.

    • В настоящее время плагин Apache Aurora уже поддерживает приоритет и вытеснение ресурсов, но он находится на том же уровне, что и marathon.

  6. Для приложений хранения с отслеживанием состояния, таких как mysql/Kafka, mesos+ Marathon в настоящее время плохо поддерживается.

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

  7. Можно разработать нужный фреймворк.Проработка плагинов.Однако сам Marathon написан на Scala, а UI написан на React, что не способствует вторичной разработке.

  8. Другие компоненты, такие как: mesos-dns и marathon-lb.

    • mesos-dns — инструмент для обнаружения сервисов
    • marathon-lb — это не только инструмент обнаружения сервисов, но и инструмент балансировки нагрузки.Чтобы использовать marathonn-lb, каждая группа приложений должна установить метку HAPROXY_GROUP и использовать haproxy для балансировки нагрузки.

  9. Компании, имеющие доступ к мезосу:мне SOS.Apache.org/document ATI…

Kubernetes (последняя версия 1.6)

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

    • Этот сервис также можно использовать, если имеется только один экземпляр, поскольку он определяет, можно ли точно перенаправить трафик на модули с динамическими IP-адресами.

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

    • AutoScale: определяет, требуется ли автоматическое масштабирование на основе собранных бизнес-метрик.
    • Последовательное развертывание: последовательное развертывание новой версии не прерывает работу служб, а старая версия закрывается после завершения развертывания новой версии.
    • Очередь работ: Расширьте отношение Сервиса с 1:1 до 1:N и добавьте уровень прокси-агента для запрашиваемого Сервиса для пересылки запросов.

  3. Kubernetes умеет автоматически устранять проблемы и может быстро перезапускать контейнеры, поэтому потребители не замечают сбоев контейнера.

    • Чтобы решить эту проблему, можно добавить централизованную систему логирования или другие средства для мониторинга.

  4. Наборы услуг с отслеживанием состояния: StatefulSets (версия 1.4 называется PetSets)

    • Для модулей в PetSet каждый модуль монтирует свое собственное независимое хранилище.Если модуль выходит из строя, запустите модуль с тем же именем с другого узла, и хранилище исходного модуля продолжит предоставлять услуги в своем состоянии. (Убедитесь, что ip/hostname не изменились)
    • Компании, подходящие для PetSet, включают службы баз данных MySQL/PostgreSQL, службы управления кластерами Zookeeper и т. д., а также другие службы с отслеживанием состояния.
    • Используя PetSet, поды могут по-прежнему обеспечивать высокую доступность, перемещаясь по разным узлам, а хранилище также может обеспечивать высокую надежность за счет внешнего хранилища.Что делает PetSet, так это связывает определенный под с определенным хранилищем, чтобы обеспечить непрерывность состояния.

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

  6. Компании, использующие kubernetes по общей статистике: eBay, Yahoo, Microsoft, IBM, Intel, Huawei, VMware, HPE, Mirantis, NetEase, Puyuan, AsiaInfo, LeTV, Tencent, JD.com

Стек контейнерных технологий

технический пункт Технические решения
Планирование ресурсов и оркестровка Mesos + marathon Swarm(Compose) Kubernetes
Зеркало и репозиторий harbor DockerHub Quay.io Artifactory
монитор cAdvisor Graphite Sysdig Datadog Prometheus ,Zabbix + pythonAgent
бревно ELK Graylog flume heka fluentd
Регистрация и обнаружение сервисов/балансировка нагрузки HAProxy Etcd consul nginx Confd/DNS (там вроде есть яма)
место хранения devicemapper, overlayfs, Volume, Ceph, Gluster, NFS, OpenStack swift, Glance, iSCSI SAN
Интернет HOST, VXLAN IPSEC . OpenFlow .Flannel. Docker Bridge, Calico, Neutron ,pipework ,weave , SocketPlane
Распределенный планировщик chronos
Безопасность Notary Vault
инструмент автоматизации ansible, salt

Архитектура промышленного использования

  1. Цзиндон

    • Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
    • При сбое контейнера автоматически запускается RC (сохраняйте IP без изменений и «мигрируйте»)
    • OVS-VLAN

  2. Знай почти

    • Git+Jenkins(CI/CD) + mesos + фреймворк собственной разработки + группа (изоляция) + Consul + haproxy + DNS + Graphite + cAdvisor
      • Выделение неисправностей по группам
      • Зеркальный склад отличается высокой доступностью благодаря hdfs и горизонтальному расширению.
      • Горизонтальное масштабирование кластера Mesos
    • докер сеть
      • bridge
      • NAT is not bad
      • iptables имеет некоторые недостатки
    • обнаружение службы
      • DNS Client
    • Автоматическая шкала
      • Быстрое реагирование и эффективное использование ресурсов
      • Отрегулируйте количество контейнеров на основе показателей ЦП
      • Быстрое расширение и медленное сокращение
      • Max & Min Hard Limit
      • Поддержка пользовательских индикаторов

  3. Cтрип

    • Openstack + Mesos + Docker + Chronos + ELK
    • Мониторинг: телеграф -> Influxdb -> Grafana
    • журнал: лось
      • мезос stdout, stderr

  4. куда

    • OpenStack + nova-docker + VLAN => Mesos + Marathon + Docker(--net=host) + случайный порт => Mesos + Marathon + Docker + Calico

  5. Облако электронной коммерции Alibaba

    • Самостоятельно разработанный EWS, основанный на компоновке, относится к дизайну Kubernetes.Поддержка нескольких регионов.
      • cAdvisor + InfuxDB + prometheus
      • etcd + consul + zk + docker overlay
        • Используйте RDS, OSS, OCS и другое сервисное хранилище
    • Правильная поза докер-контейнера
      • Перестроить образ для каждой фиксации кода
      • Не изменять работающий образ
      • Используйте объем для сохранения постоянных данных
    • Управление хранилищем
      • Используйте плагин тома докеров для поддержки различных типов хранилищ.
        • блочное хранилище, облачный диск
        • Объектное хранилище, OSSFS
        • Сетевая файловая система NFS

  6. Тот же процесс

    • swarm + агент swarm + etcd + zabbix + Jenkins + (Nginx+Lua) + центр конфигурации
    • Статус использования
      • 5000 контейнеров, а пиковая вместимость может быть увеличена до 8000
      • 600 приложений Docker, запихнутых в контейнер: Mongodb, Redis, Mysql
      • Загрузка процессора увеличена с 20% до 80%.
    • Уровень изоляции ресурсов
      • Коэффициент использования физических машин улучшен, а приложение рационально организовано.
      • Изоляция ресурсов между приложениями, чтобы избежать конфликтов между средами и ресурсами, что повышает безопасность
      • Резкий входящий трафик: быстрое расширение пропускной способности и миграция
      • Миграция приложений: сократите расходы на покупку серверов
      • Эксплуатация и техническое обслуживание: больше автоматизации, более совершенный мониторинг и сигнализация
    • оптимизация
      • Оптимизация Dockerfile, уменьшение количества слоев с 20 слоев до 5 слоев, скорость построения в 1 раз быстрее
      • Драйвер хранилища изменен с devicemapper на overlayfs, а скорость сборки в 1 раз быстрее
      • Публикация более крупного приложения занимает всего 40 секунд
      • Система автоматического тестирования напрямую вызывает среду развертывания контейнерной системы, и тест может быть повторно использован для использования другими тестами.
      • Практически нет потери производительности между измеряемой физической машиной и Контейнером.
        • Сравнение производительности Redis: redis-benchmark -h 127.0.01 -p6379 -q -d 100
    • Управление изображениями
      • Строительство основного зеркального бассейна
      • Создайте образ приложения поверх базового образа.
      • Образ приложения перестраивается каждый раз при его выпуске
      • Многоверсионное хранилище образа приложения
      • Создайте свой образ один раз, используйте его везде
      • Откат и развертывание каждого приложения основаны на образе приложения.
    • сетевое мышление
      • Сама управляемость сети относительно высока в частном облаке.
      • Многопользовательская изоляция не имеет большого смысла в частных облаках
      • Стабильность, управляемость и масштабируемость — насущная потребность
      • Высокая гарантия общей пропускной способности
      • Рекомендации по сети для контейнеров Docker
        • Собственный сетевой режим и режим OVS
          • Собственный сетевой режим: например, веб
          • Режим OVS: например, анализ данных

  7. Улей NetEase

    • openstack + K8S + etcd + OpenFlow + iscsi + Ceph + биллинг + мультирум

  8. Тенсент

    • Kubernetes + Network (Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + Blue Whale Control Platform
    • В настоящее время существует около 15 000 резидентных контейнеров Docker, а на платформе Docker запущены десятки клиентских игр, веб-игр и мобильных игр.
    • Кластеры совместимы как с приложениями Docker, так и с приложениями, отличными от Docker.
    • Gaia интегрирует сеть, такую ​​как ЦП и память, в унифицированное управление как ресурсное измерение. Предприятия указывают свои собственные требования к сетевому вводу-выводу при отправке приложений. Мы используем TC (управление трафиком) + cgroups для реализации контроля пропускной способности исходящей сети. Путем изменения ядра мы можем усилить контроль пропускной способности входящей сети.
    • Выбор конкретной сети
      • Для связи между модулем и модулем в кластере используется оверлейная сеть, поскольку для этого не требуется IP-адрес интрасети (можно использовать виртуальный IP-адрес), который реализуется компонентом flannel.
      • Связь между интрасетью компании и модулями в кластере, такими как HAProxy и некоторыми игровыми модулями, использует сеть SR-IOV и реализуется собственными настроенными компонентами sriov-cni. Этот тип модуля имеет двойную сеть, eth0 соответствует оверлейной сети, а eth1 соответствует сети SR-IOV.
      • Связь между модулями с внутренней сетью компании. В сценарии микросервиса хранилище игровых данных, периферийные системы и т. д. развернуты на физических или виртуальных машинах, поэтому модули получают доступ к этим модулям и системам через сеть NAT.
      • (Интернет) доступ, используя решение компании TGW.

  9. Диди

    • Kubernetes
    • По текущей информации Didi уже давно не использует докер, да и эталонных архитектур не так много.

  10. uber

    • Быть добавленным

  11. Грибная улица

    • Kubernetes + VLAN

  12. Семь Ниуюн

    • Mesos + собственная платформа планирования контейнеров (DoraFramework) + Bridge + NAT + Open vSwitch + Consul + Prometheus + Ansible
    • В настоящее время Qiniu достиг масштаба почти 1000 физических машин, и мезосу больше подходит для поддержки крупномасштабного планирования.
    • Вместо Marathon, основного фреймворка Mesos, выберите самостоятельно разработанную
      • Есть некоторые аспекты Marathon, которые не поддерживают ожидаемое нами состояние использования, например, он не очень хорош в беспрепятственном обнаружении сервисов.
      • Marathon использует scala для разработки, его сложно устранить в случае возникновения проблемы, и нам неудобно заниматься вторичной разработкой
      • Если мы выберем Marathon, нам все равно нужно будет сделать еще один уровень упаковки для Marathon, чтобы он служил сервисом планирования Dora, так что будет больше модулей, а развертывание, эксплуатация и обслуживание будут сложными.

  13. Облако Meizu

    • OVS & VLAN + SR-IOV +ceph (гарантия надежности хранения изображений) + собственная действующая система мониторинга
    • Контейнеры между хостами обмениваются данными через большую сеть уровня 2 и изолированы через vlan.
    • Удаленная зеркальная синхронизация
    • Идеи дизайна контейнера
      • Контейнерная виртуальная машина, созданный Контейнер должен работать в течение длительного времени.
      • Каждый Контейнер имеет независимый и уникальный IP-адрес.
      • Контейнеры между хостами обмениваются данными через большую сеть уровня 2 и изолированы через vlan.
      • Контейнер запускает службу ssh и может войти в систему через машину-бастион.
      • Контейнер открывает другие распространенные сервисы, такие как crond
    • Интернет
      • Iperf test: Bridge < OVS veth pair < OVS internal port
      • Iperf test: Native > SR-IOV > OVS > Bridge
      • Docker with DPDK
        • Опрос для обработки пакетов, чтобы избежать накладных расходов на прерывание
        • Драйвер пользовательского режима, предотвращение копирования памяти, системный вызов — привязка к ЦП, технология огромных страниц
      • Idea
        • virtio как внутренний интерфейс
        • Сокет пользовательского режима подключен к контейнеру
        • Запуск приложений DPDK в контейнере
    • Контейнерное хранение
      • Devicemapper: зрелый и стабильный, голое устройство, моментальный снимок
      • IOPS: Native в основном эквивалентен Devicemapper.
      • Дисковое хранилище данных — LVM
        • Квота по контейнерам, поддержка онлайн-изменения квоты
    • Зеркальное хранение и синхронизация
      • зеркало хранения
        • Внешняя балансировка нагрузки LVS для обеспечения высокой доступности
        • образ управления распространением
        • Серверный ceph обеспечивает надежность хранения изображений
      • Удаленная зеркальная синхронизация
        • механизм уведомления вебхуков
        • Сильный согласованный механизм синхронизации
    • Система планирования кластера контейнеров
      • Запрос планирования попадает на соответствующий узел кластера
      • Фильтровать хосты по IDC, ресурсу и зоне, а также типу контейнера.
      • Динамическое планирование на основе состояния ресурсов хоста и запрошенного размера ЦП/памяти/диска.
      • Осведомленность о шкафах, отправка одного и того же сервисного контейнера в разные шкафы

  14. ucloud

    • kubernetes + Jenkins
      • -v монтировать на хост, Flume/Logstash/rsyslog + elasticserach (журнал)
      • Сетевое решение SDN «большой двойки»: оверлей vswitch + ipvlan
    • Основные типы проблем и решения

      • Конфигурация модуля

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

      • Согласованность и зависимости

        • Несогласованность в средах разработки, тестирования и выполнения.
        • Зависит от другой базовой библиотеки

      • развертывать

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

      • решение

        • Конфигурация модуля
          • Информация об элементах дифференцированной конфигурации, такая как среда разделения, IDC, класс ресурсов и т. д.
          • Настройте шаблон и отправьте его в cedebase для управления версиями.
          • Получите разные значения конфигурации для разных развертываний, заполните шаблоны, запустите сценарии
          • Запустите в разных развертываниях, просто передайте переменную среды в контейнер
        • Согласованность и зависимости
          • Среды разработки, тестирования и онлайн-запуска используют образы, созданные докером, для обеспечения согласованности.
          • Базовая система, базовые инструменты, фреймворк, послойное построение
          • Унифицированное предварительное развертывание базовых образов в средах разработки, тестирования и онлайн-среды
        • частный зеркальный репозиторий
          • Версия V2
          • Поддержка драйвера UFile
          • Регулярно извлекайте последнее изображение

      • некоторый опыт

        • логи докера
          • Печать журнала потребляет производительность
          • Лучше закрыть logdriver и распечатать лог в фоновом режиме
        • docker daemon
          • Выйти из контейнера уничтожения, обновить демон докеров, уничтожение необязательно
        • докер сеть
          • В режиме NAT будет включен nf_conntrack, что приведет к снижению производительности, настройте параметры ядра
        • образ докера
          • Напишите спецификацию файла док-станции, уменьшите количество слоев изображения и поместите основную часть на передний план.
          • Развертывание реестра образов в разных регионах

Главная проблема

  1. В игру вступает настройка производительности одного экземпляра + производительность карты 10 Gigabit. Нужны некоторые улучшения OVS (Open vSwitch)

  2. Мультирум: поддержка мультирумов и доменов доступности

  3. Требования к контейнерной сети

    • Iptables имеет некоторые недостатки
    • Сетевой доступ между контейнерами через хосты
    • Должна ли контейнерная сеть иметь возможность переключения IP-адресов?

  4. Проблемы, с которыми сталкивается контейнерная сеть

    • В режиме Docker Host возникает конфликт портов в смешанном дистрибутиве.
    • Режим Docker NAT, службы, зависящие от IP-адреса, сильно трансформируются и не могут поддерживать обнаружение служб.
    • Оверлейная сеть, включая планирование IP-адресов, распределение MAC-адресов, коэффициент конвергенции сетевого оборудования и другие вопросы.
    • Оверлейная сетевая безопасность, ремонтопригодность, планирование пропускной способности

  5. Обновление версии (docker/mesos/k8s) само обновление

  6. Проблема Docker с контейнеризацией сервисов с отслеживанием состояния

    • kafka / mysql

Выбор сети (k8s и mesos)

Мысли и болевые точки

  1. Возможен ли межкомпьютерный доступ?

    • фланель может общаться между контейнерами
    • Взаимодействие контейнеров между хостами
    • Контейнер и внешнее соединение

  2. Поддерживает ли он статический ip, фиксированный ip?Доступ к доменному имени?

    • Если вы исправите IP-адрес, вам нужно будет сохранять этот IP-адрес каждый раз при развертывании, обновлении или перезапуске.
    • оверлейная сеть, Docker 1.6 обеспечивает межхостовое взаимодействие

  3. Днс поддерживает?

  4. Доступ уровня 4/уровня 7

  5. Сеть после контейнерного хранения

  6. IP порт, вручную лучше не планировать

  7. сетевая политика, защита, изоляция?

    • Сетевая изоляция и ограничения трафика между разными приложениями в контейнерном кластере

  8. докер сеть

    • Режим хоста: Контейнеры напрямую делят сетевое пространство хоста. Контейнер должен использовать -p для сопоставления портов. Невозможно запустить два контейнера, прослушивающих порт 80, и нет изоляции.
    • Режим контейнера: контейнер напрямую использует сетевую конфигурацию другого существующего контейнера: вся информация, связанная с сетью, такая как информация об IP-адресе и сетевых портах, является общей.
    • Режим моста: назначьте IP-адрес контейнеру из подсети docker0 и установите IP-адрес docker0 в качестве шлюза контейнера по умолчанию.
      • IP-адрес контейнера меняется при перезапуске контейнера.
      • Контейнерная связь между разными хостами должна опираться на сторонние решения, такие как: конвейер

строить планы

  1. Категория программы

    • Туннельная схема, через туннель или способ Overlay Networking:
      • Weave, широковещательная рассылка UDP, локальная машина устанавливает новый BR и обменивается данными через PCAP.
      • Open vSwitch (OVS), основанный на протоколах VxLAN и GRE, но имеющий серьезную потерю производительности.
      • Фланель, широковещательная передача UDP, VxLan.
    • схема маршрутизации
      • Calico, решение для маршрутизации, основанное на протоколе BGP, поддерживает очень подробный контроль ACL и имеет высокую совместимость с гибридными облаками.
      • Macvlan, решение с лучшей изоляцией и производительностью с точки зрения логики и уровней ядра, основано на изоляции уровня 2, поэтому ему требуется поддержка маршрутизатора уровня 2. Большинство поставщиков облачных услуг не поддерживают его, поэтому его трудно внедрить на гибридные облака.
      • Хорошая производительность, отсутствие NAT, высокая эффективность, но она ограничена таблицей маршрутизации, и каждый контейнер имеет свой IP-адрес, поэтому бизнес-IP может быть израсходован.

  2. Два лагеря сети

    • Лагерь Docker Libnetwork Container Network Model (CNM) (преимущество Docker Libnetwork заключается в том, что он нативен и тесно интегрирован с жизненным циклом контейнера Docker)

      • Docker Swarm overlay
      • Macvlan & IP network drivers
      • Calico
      • Контив (от Cisco)

    • Лагерь Container Network Interface (CNI) (преимущество CNI заключается в совместимости с другими контейнерными технологиями (например, rkt) и системами оркестровки верхнего уровня (Kuberneres & Mesos))

      • Kubernetes
      • Weave
      • Macvlan
      • Flannel
      • Calico
      • Contiv
      • Mesos CNI

  3. Общие решения:

    • фланель vxlan, режим наложения

    • calico

      • Сетевая изоляция уровня 3 между контейнерами, не нужно беспокоиться об ARP-штормах
      • Основываясь на ядре iptable/linux, эффективность пересылки пакетов высока, а потери низки.
      • В Calico нет концепции мультитенантности, все узлы контейнера должны быть маршрутизируемыми, а IP-адреса не могут повторяться.

    • ipvlan macvlan, изоляция физического уровня 2/3, в настоящее время требуется инструмент конвейера для настройки на одном узле, только изоляция vlan, не решает широковещательную рассылку arp

    • нативный vxlan swarm, похожий на flannel vxlan

    • нейтрон sdn, есть много вариантов, ml2+ovsplugin, midonet, vlan или vxlan

    • Weave

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

    • contiv

      • Cisco доминирует, решение sdn, вы можете использовать чистый программный ovs, или вы можете использовать аппаратный контроллер sdn ovs+cisco
      • Основанный на OpenvSwitch, он поддерживает контейнерную сеть доступа в виде подключаемого модуля, поддерживает VLAN, Vxlan, мультиарендность, политику управления доступом к хосту и т. д.
      • Возможности SDN, обеспечивающие более точный контроль над доступом к контейнерной сети
      • На основе того же стека технологий (OVS + VLAN) JD уже поддерживает работу контейнеров 10w+

    • Мост Linux + коммутатор уровня 3: мост Linux на хосте настроен на сетевой сегмент подсети коммутатора уровня 3, связь между контейнерами проходит через коммутатор уровня 2, а контейнер и внешняя среда проходят через шлюз коммутатора уровня 3. Коммутатор третьего уровня.

  4. Стандартный выбор сети в отрасли

    • kubernetes + flannel

      • Kubernetes использует плоскую сетевую модель, требующую, чтобы у каждого модуля был глобально уникальный IP-адрес, а модули могли взаимодействовать напрямую между хостами. В настоящее время более зрелым решением является использование фланели.
      • Flannel уже поддерживает такие режимы пересылки данных, как UDP, VxLAN, AWS VPC и маршрутизация GCE.
      • Есть flannel, openvswitch и weave под kubernetes для реализации Overlay Network
      • Решение Vipshop conv netplugin (фиксированный IP-адрес внешней сети) + фланель
      • JD.com Фланель + Нейтрон + ОВС
      • Производительность Flannel: Официально: пропускная способность не уменьшилась, а задержка значительно увеличилась

    • Mesos + Caclio

      • Mesos поддерживает стандартную спецификацию CNI
      • Один контейнер, один IP-адрес, сетевая изоляция, обнаружение службы DNS, выделение IP-адресов, виртуальная сеть L3
      • Куда пойти Месос + Каклио
      • Мост Qiniu + NAT + Open vSwitch

    • Meizu Cloud OVS и VLAN + SR-IOV

    • ucloud: сетевое решение SDN «большого второго уровня» для оверлея vswitch + ipvlan

Выбор мониторинга журнала (включая мониторинг, статистику)

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

Журналы типа stdout/stderr можно пересылать в центр syslog через logspout для сбора.

LogDriver Docker может выводить журналы на определенные конечные точки, такие как Fluentd, Syslog или Journald. Logspout может направлять журналы контейнеров в системный журнал или сторонние модули, такие как Redis, Kafka или Logstash.

  1. Введение

    • Собирать вне контейнера. Смонтируйте хост-диск в качестве каталога журнала и файлов в контейнере.
    • Перенаправляет управление журналами, применяемыми в контейнере, в каталог журналов.
    • Выполните сбор и ротацию журналов в каталоге журналов приложений и каталоге журналов Docker на хосте.

  2. Варианты мониторинга

    • cAdvisor + InfluxDB + Grafana
    • cAdvisor + Prometheus + Grafana
    • Graphite
    • Zabbix
    • Datadog

  3. Параметры журнала

    • logstash
    • ELK
    • Graylog
    • flume
    • heka
    • fluentd

  4. Отраслевые решения

    • Облако Alibaba: cAdvisor + InfuxDB + prometheus
    • Сопрограммы: ELK
    • Знаю: Graphite + cAdvisor

Управление изображениями

  1. Образы всегда генерируются из Dockerfile
  2. Следует избегать зависимости между образами.Рекомендуется использовать три уровня.Эти три слоя представляют собой базовый образ операционной системы, образ промежуточного ПО и образ приложения.
  3. Все образы должны иметь соответствующие репозитории Git для облегчения последующих обновлений.
  4. Registry
    • Единственная проблема, соответствующее решение может учитывать DRBD, распределенное хранилище и облачное хранилище.
    • Проблема производительности Regitry, доступное в настоящее время решение состоит в том, чтобы ускорить загрузку слоя через кеш обратного прокси-сервера HTTP или предоставить зеркальное зеркало.
    • Разрешения пользователя реестра, Nginx LUA может обеспечить простую и быструю реализацию

личное понимание

  1. При выборе следует смотреть не только на компоновку, но и на поддержку хранилища/сети и т. д.

    • Раньше у Swarm были некоторые недостатки, такие как невозможность обнаружения отказавших узлов и перезапуск, также реализована последняя версия.
    • k8s просто используется для планирования докера
    • mesos используется для управления кластерами машин Docker можно управлять косвенно через Marathon

  2. Соответствующая сетевая поддержка

    • Может ли это быть межхостовым/междоменным
    • Можно ли исправить разрешение ip/dns?
    • Поддержка стандарта CNI?

  3. поддержка хранения

    • Можно ли это вылечить?
    • Поддерживает ли он распределенное хранилище?

  4. Для оркестровки/планирования/эскалации

    • Поддерживается ли откат, онлайн-обновление или последовательное обновление?
    • Возможно ли мелкозернистое распределение процессора/памяти и т.д.
    • Поддерживать ли контейнеризацию и планирование сервисов с отслеживанием состояния
    • Возможность автоматического масштабирования?

  5. Механизм регистрации/обнаружения службы/балансировка нагрузки

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

  6. разное

    • Изоляция, помимо cgroups и namespaces, есть и другие изоляции, например сетевая изоляция
Категории