[TOC]
Примеры манифестов - https://github.com/luksa/kubernetes-in-action
# Глава 1. Знакомство с Kubernetes
Kubernetes позволяет разработчикам развертывать свои приложения самостоятельно и так часто, как они хотят, не требуя какой-либо помощи от системных администраторов. Но Kubernetes приносит пользу не только разработчикам. Эта платформа также помогает системным администраторам, автоматически отслеживая и перемещая эти приложения в случае аварийного сбоя оборудования.
Kubernetes абстрагирует аппаратную инфраструктуру и обеспечивает доступ ко всему вашему центру обработки данных (дата-центру) как одному огромному вычислительному ресурсу. Это позволяет развертывать и запускать программные компоненты без необходимости знать о фактических серверах, находящихся в основании. При развертывании многокомпонентного приложения с помощью Kubernetes он выбирает сервер для каждого компонента, развертывает его и позволяет легко находить и взаимодействовать со всеми другими компонентами приложения.
## Изоляция контейнеров
Для изоляции контейнеров используется два механизма:
* *пространства имен Linux*, гарантирует, что каждый процесс видит свое персональное представление о системе (файлы, процессы, сетевые интерфейсы, hostname и т. д.);
* *контрольные группы Linux* (cgroups), ограничивающие объем ресурсов, которые может потреблять процесс (ЦП, оперативная память, пропускная способность сети и т. д.).
### Пространство имен Linux
По умолчанию каждая система Linux изначально имеет одно пространство имен. Все системные ресурсы, такие как файловые системы, идентификаторы процессов, идентификаторы пользователей, сетевые интерфейсы и др., принадлежат одному пространству имен. Но вы можете создавать дополнительные пространства имен и организовывать ресурсы между ними. При запуске процесса вы запускаете его внутри одного из этих пространств имен. Процесс будет видеть только ресурсы, находящиеся внутри одного пространства имен. Существует несколько типов пространств имен, поэтому процесс принадлежит не одному пространству имен, а одному пространству имен
каждого типа.
Существуют следующие виды пространств имен:
* файловая система (mnt);
* ид-р процессов (pid);
* сеть (net);
* межпроцессное взаимодействие (ipc);
* UTS;
* пользовательские идентификаторы.
Каждый вид пространства имен используется для изоляции определенной группы ресурсов. Например, пространство имен UTS определяет, какой хостнейм и доменное имя видит процесс, запущенный внутри этого пространства имен. Назначив двум процессам два разных пространства имен UTS, можно заставить их видеть разные локальные хостнеймы. Другими словами, для двух процессов это будет выглядеть так, как будто они выполняются на двух разных машинах (по крайней мере, в том, что касается хостнеймов).
Точно так же то, к какому сетевому пространству имен принадлежит процесс, определяет, какие сетевые интерфейсы видит приложение, запущенное внутри процесса. Каждый сетевой интерфейс принадлежит только одному пространству имен, но он может быть перемещен из одного пространства имен в другое. Каждый контейнер использует свое собственное сетевое пространство имен, и по-этому каждый контейнер видит свой собственный набор сетевых интерфейсов.
### Контрольные группы
Другая половина изоляции контейнеров связана с ограничением объема системных ресурсов, которые может потреблять контейнер. Это достигается с помощью cgroups, функционального средства ядра Linux, которое ограничивает использование ресурсов процессом (или группой процессов). Процесс не может использовать больше, чем настроенный объем ЦП, оперативной памяти, пропускной способности сети и т. д. Благодаря этому процессы не могут перехватывать ресурсы, зарезервированные для других процессов, что аналогично тому, когда каждый процесс выполняется на отдельной машине.
## Первое знакомство с Kubernetes
Kubernetes – это программная система, которая позволяет легко развертывать контейнеризированные приложения и управлять ими. Она использует возможности контейнеров Linux для запуска разнородных приложений без необходимости знать какие-либо внутренние детали этих приложений и без необходимости вручную развертывать эти приложения на каждом хосте.
Система состоит из ведущего узла (мастера) и любого количества рабочих узлов. Когда разработчик отправляет список приложений ведущему узлу, Kubernetes развертывает их в кластере рабочих узлов. То, на какой узел приземляется компонент, не имеет (и не должно иметь) значения ни для разработчика, ни для системного администратора.
Kubernetes можно рассматривать как операционную систему для кластера. Она избавляет разработчиков приложений от необходимости внедрять в свои приложения определенные службы, связанные с инфраструктурой;
### Архитектура Kubernetes
На аппаратном уровне кластер Kubernetes состоит из множества узлов, которые можно разделить на два типа:
* *ведущий узел (мастер)*, на котором размещена плоскость управления (Control Plane) Kubernetes, контролирующая и управляющая всей системой Kubernetes;
* *рабочие узлы*, на которых выполняются развертываемые приложения.
Плоскость управления – это то, что управляет кластером и заставляет его функционировать. Она состоит из нескольких компонентов, которые могут работать на одном ведущем узле либо быть распределены по нескольким узлам и реплицированы для обеспечения высокой доступности. Эти компоненты следующие:
* *сервер Kubernetes API*, с которым взаимодействуете вы и другие компоненты плоскости управления;
* *планировщик*, который распределяет приложения (назначает рабочий узел каждому развертываемому компоненту приложения);
* *менеджер контроллеров*, выполняющий функции кластерного уровня, такие как репликация компонентов, отслеживание рабочих узлов, обработка аварийных сбоев узлов и т. д.;
* *etcd*, надежное распределенное хранилище данных, которое непрерывно сохраняет конфигурацию кластера.
Рабочие узлы – это машины, на которых выполняются контейнеризированные приложения. Задача выполнения, мониторинга и предоставления служб приложениям выполняется следующими компонентами:
* Docker, rkt или другая среда выполнения контейнеров, в которой выполняются контейнеры;
* Kubelet, агент, который обменивается с сервером API и управляет контейнерами на своем узле;
* служебный прокси Kubernetes (kube-proxy), который балансирует нагрузку сетевого трафика между компонентами приложения.
