План по прочтению книг 1. Docker. Готово 2. Базы данных. В процессе 3. Алгоритмы

### otThreadDiscoveryRequestInfo https://openthread.io/reference/struct/ot-thread-discovery-request-info ```

При чтении новостей о Docker может сложиться впечатление, что Docker по своей природе небезопасен и не готов к промышленной эксплуатации. А о проблемах, связанных с безопасным применением контейнеров, скажу лишь, что при правильном использовании контейнеры могут обеспечить более безопасную и эффективную работу, чем виртуальные машины или аппаратные решения. ### На что следует обратить особое внимание * уязвимости в ядре – в отличие от виртуальной машины, ядро совместно используется всеми контейнерами и самим хостом, что увеличивает степень влияния любых уязвимостей, имеющихся в ядре. Если контейнер способен привести ядро в аварийное состояние (kernel panic), это выведет из строя весь хост. В виртуальных машинах ситуация намного лучше: атакующий должен сначала пройти через ядро виртуальной машины и гипервизор, прежде чем получит доступ к ядру хоста;

Kubernetes поддерживает и продвигает несколько концепций: * pods – группы контейнеров, которые развертываются и планируются совместно. В Kubernetes такие группы образуют неделимую единицу планирования в противоположность отдельным контейнерам в других системах. Группа обычно содержит от 1 до 5 контейнеров, совместно обеспечивающих работу некоторого сервиса. В дополнение к этим пользовательским контейнерам Kubernetes запускает вспомогательные контейнеры для сервисов ведения журналов и контроля. В Kubernetes такие группы считаются непостоянными – в процессе развития системы они могут создаваться и уничтожаться * flat networking space – в Kubernetes функционирование сетевой среды значительно отличается от работы сети с Docker-шлюзом, принимаемой по умолчанию. В сетевой среде Docker по умолчанию контейнеры существуют в закрытой подсети и не могут напрямую обмениваться данными с контейнерами на других хостах без перенаправления портов на хосте или без использования механизма прокси. В Kubernetes контейнеры в одной группе (pod) совместно используют один IP-адрес, но все адресное пространство является «плоским» для всех групп (pods), таким образом, все группы (pods) могут обмениваться информацией друг с другом без какого-либо преобразования сетевых адресов (NAT). Это существенно упрощает управление многохостовыми кластерами, но при этом не поддерживаются внутренние каналы связи, а организация сетевой среды для одного хоста (или, более точно, для одной группы) становится чуть более сложной. Поскольку контейнеры одной группы (pod) совместно используют общий IP-адрес, они могут обмениваться данными, используя порты по адресу localhost (это означает, что вы сами должны управлять использованием портов внутри группы (pod)). * labels – ярлыки представляют собой пары ключ-значение, закрепленные за объектами в Kubernetes, в основном за группами (pods), и используемые для определения идентификационных характеристик объекта (например, version:devилиtier:frontend). Обычно ярлыки могут быть повторяющимися, предполагается, что они идентифицируют группы контейнеров. Селекторы ярлыков (label selectors) могут использоваться для определения объектов или групп объектов (например, все группы внешних сервисов системы с окружением, предназначенным для промышленной эксплуатации). Использование ярлыков упрощает объединение однотипных задач, таких как распределение групп контейнеров (pods), по более крупным группам, созданным для балансировки нагрузки, или динамическое перемещение групп контейнеров;

* кластеризация (clustering) – объединение в группы «хостов» – виртуальных машин или аппаратных – и создание для них общей сетевой среды. Кластер следует воспринимать как единый ресурс, а не как группу отдельных компьютеров; * оркестрация (orchestration) – обеспечение совместной работы всех элементов системы. Запуск контейнеров на соответствующих хостах и установление соединений между ними. Организационная система также может включать поддержку масштабирования, автоматического восстановления после критических сбоев и инструменты изменения балансировки нагрузки на узлы; * управление (management) – обеспечение общего контроля и наблюдения за системой и поддержка различных административных задач. Основные средства оркестрации и кластеризации в экосистеме Docker: Swarm, fleet, Kubernetes и Mesos. Swarm – это собственное решение кластеризации компании Docker, в котором большое внимание уделяется проблемам оркестрации, в частности при использовании совместно с Docker Compose. Fleet – это низкоуровневая система кластеризации и планирования, используемая CoreOS. Kubernetes – это высокоуровневое решение оркестровки, в которое по умолчанию встроены функции восстановления после критических сбоев и масштабирования и которое может работать поверх других решений кластеризации. Mesos – низкоуровневая система кластеризации, способная работать с «программными средами» более высокого уровня, обеспечивая надежное, полноценное решение кластеризации и оркестрации.