процессов, групп и т. д.).
* CNI (Container Networking Interface) работа с сетью
Portainer
Простейшим вариантом мониторинга будет Portainer:
essh@kubernetes-master:~/microKubernetes$ cat << EOF > docker-compose.monitoring.yml
version: 2
>
services:
portainer:
image: portainer/portainer
command: H unix:///var/run/docker.sock
restart: always
ports:
9000:9000
volumes:
/var/run/docker.sock:/var/run/docker.sock
./portainer_data:/data
>
EOF
essh@kubernetes-master:~/microKubernetes$ docker-compose f docker-compose.monitoring.yml up d
Облачные системы, как источник непрерывного масштабирования: Google Cloud и Amason AWS
Кроме хостинга и аренды сервера, в частности виртуального VPS, можно воспользоваться облачными решениями (SAS, Service As Software) решениями, то есть осуществлять работу нашего Web приложения (ий) только через панель управления используя готовую инфраструктуру. Этот подход имеет как плюсы, так и минусы, которые зависит от бизнеса заказчика. Если с технической стороны сам сервер удалён, но мы можем к нему подключиться, и как бонус получаем панель администрирования, то для разработчика различия более существенны. Разделим проекты на три группы по месту развёртывания: на хостинге, в своём дата центре или использующие VPS и в облаке. Компании использующие хостинг в силу существенных ограничений налагаемых на разработку невозможность установить своё программное обеспечение и нестабильность и размер предоставляемой мощности в основном специализируются на заказной (потоковой) разработке сайтов и магазинов, которая в силу малых требований к квалификации разработчиков и нетребовательности к знаниям инфраструктуры рынок готов оплачивать их труд по минимум. Ко второй группе относятся компании реализующие состоявшиеся проекты, но разработчики отстранены от работы с инфраструктурой наличием системных администраторов, build инженеров, DevOps и других специалистов по инфраструктуре. Компании, выбирающие облачные решения, в основном оправдывают переплату за готовую инфраструктуру и мощности их расширяемостью (актуально для стартапов, когда рост нагрузки не предсказуем). Для реализации подобных проектов в основном берут высококвалифицированных специалистов широкого круга для реализации нестандартных решений, где инфраструктура уже является просто инструментом, а специалисты по ней просто отсутствуют. На разработчиков возлагаются функции по проектированию проекта в целом, как единого целого, а не программы в отрыве от инфраструктуры. В основном это зарубежные компании, готовые хорошо оплачивать труд ценных сотрудников.
Для развёртывания будем использовать Kubernetes для противодействия vender lock, когда инфраструктура проекта завязана на api конкретного облачного провайдера и не позволят перейти на другие или собственные облака без существенных изменений в самом приложении. Kubernetes поддерживается Amazon AWS, Google Cloud, Microsorft Azure, локальной установкой одного иснтанца с помощью MiniKube.
Воспользуемся Google Cloud, на текущий 2018 год он предоставляет бесплатное использование на один год ограниченных ресурсов (300 долларов США), при этом существуют лимиты, которые можно посмотреть в меню IAM и администрирование > Квоты. Важно заметить, облачные провайдеры не предоставляют тарифов в современном диапазоне, а предоставляют тарифы на использовании определённых мощностей, то есть сайт мало посещаем платим мало, сложно обрабатываем много данных платим много. По этой причине, когда потребности в вычислительных мощностях у компании предсказуемы (не стартап) может быть целесообразно использовать собственные возможности для постоянной нагрузки, что может быть экономически целесообразно, не рискую ограниченностью вычислительными мощностями.
И так заходим на cloud.google.com регистрируется, привязываем дебетовую карту с минимальным балансом и переходим в консоль console.cloud.google.com, в котором можно пройти обучение по интерфейсу для общего ознакомления. В меню нажимаем пункт Оплата: у меня нетронутые демо-деньги 300 долларов США и осталось 356 дней (средства списываются не в режиме реального времени).
Если смотреть на как основу для Back-End для мобильной разработки (MBasS, Mobile backend as a service), то его предоставляют разные провайдеры: Google Firebase, AWS Mobile, Azure Mobile
Google App Engine
Создание кластера через Web-интерфейс
Предварительно проверим ограничения (квоты) Меню > Продукты > IAM и администрирование > Квоты, а если вы находитесь на тестовом аккаунте, то Static IP addresses будет равен 1, то не сможет создаться балансировщик и придётся удалять кластер. Создадим кластер в Меню Ресурсы Kubernetes Engine в тремя репликами микромашины и последней версией Kubernetes. В левом нижнем углу в пункте Marketplace создадим 2 инстанса Nginx. После создания кластера кликнем по вкладке Сервисы и перейдём по IP-адресу.
MarketPlace: Сеть, Бесплатные, Приложения Kubernetes: Nginx Создадим кастомный кластер standard-cluster-Nginx, выбрав минимум CPU и RAM, 2 ноды вместо 3 и последнюю вер сию Kubernetes (я выбрал 1.11.3, а мой код будет совместим с не ниже 1.10). В Меню Ресурсы Kubernetes Engine во кладке Кластера нажмём кнопку Подключиться. Управлением кластером в командной строке осуществляется с помощью команды cubectl, о ней можно почитать в документации https://kubernetes.io/docs/reference/kubectl/overview/ и список по https://gist.github.com/ipedrazas/95391ffd88190bea94ca188d3d2c1cbe.
Создание виртуальной машины:
Можно создать программный проект, но пользоваться им можно будет только на платном аккаунте:
NAME_PROJECT=bitrix_12345;
NAME_CLUSTER=bitrix;
gcloud projects create $NAME_CLUSTER name $NAME_CLUSTER;
gcloud config set project $NAME_CLUSTER;
gcloud projects list;
Несколько тонкостей: ключ zone обязателен и ставится в конце, диска не должен быть меньше 10Gb, а тип машин можно взять из https://cloud.google.com/compute/docs/machine-types. Если реплика у нас одна, то по умолчанию создаётся минимальная конфигурация для тестирования:
gcloud container clusters create $NAME_CLUSTER zone europe-north1-a
Вы можете увидеть в админке, развернув выпадающий список в шапке, и открыв вкладку Все проекты.
gcloud projects delete NAME_PROJECT;
, если больше стандартная, параметры которой мы подредактируем:
$ gcloud container clusters create mycluster \
machine-type=n1-standard-1 disk-size=10GB image-type ubuntu \
scopes compute-rw,gke-default \
machine-type=custom-1-1024 \
cluster-version=1.11 enable-autoupgrade \
num-nodes=1 enable-autoscaling min-nodes=1 max-nodes=2 \
zone europe-north1-a
Ключ enable-autorepair запускаем работу мониторинга доступности ноды и в случае её падения она будет пересоздана. Ключ требует версию Kubernetes не менее 1.11, а на момент написания книги версия по умолчанию 1.10 и по этому нужно её задать ключом, например, cluster-version=1.11.4-gke.12. Но можно зафиксировать только мажорную версия cluster-version=1.11 и установить автообновление версии enable-autoupgrade. Также зададим авто уверение количества нод, если ресурсов не хватает: num-nodes=1 min-nodes=1 max-nodes=2 enable-autoscaling.
Теперь поговорим об виртуальный ядрах и оперативной памяти. По умолчанию поднимается машина n1-standart-1, имеющая одно виртуальное ядро и 3.5Gb оперативной памяти, в трёх экземплярах, что совокупно даёт три виртуальных ядра и 10.5Gb оперативной памяти. Важно, чтобы в кластере было всего не менее двух виртуальных ядер процессора, иначе их, формально по лимитам на системные контейнера Kubernetes, не хватит для полноценной работы (могут не подняться контейнера, например, системные). Я возьму две ноды по одному ядру и общее количество ядер будет два. Такая же ситуация и с оперативной памятью, для поднятия контейнера с Nginx мне вполне хватало 1Gb (1024Mb) оперативной памяти, а вот для поднятия контейнера с LAMP (Apache MySQL PHP) уже нет, у меня не поднялся системный сервис kube-dns-548976df6c-mlljx, который отвечает за DNS в поде. Не смотря не то, что он не является жизненно важным и нам не пригодится, в следующий раз может не подняться уж более важный вместо него. При этом важно заметить, что у меня нормально поднимался кластер с 1Gb и было всё нормально, я общий объём в 2Gb оказался пограничным значением. Я задал 1080Mb (1.25Gb), учтя, что минимальная планка оперативной памяти составляет 256Mb (0.25Gb) и мой объём должен быть кратен ей и быть не меньше, для одно ядра, 1Gb. В результате в кластера 2 ядра и 2.5Gb вместо 3 ядре и 10.5Gb, что является существенной оптимизацией ресурсов и цены на платном аккаунте.
Теперь нам нужно подключиться к серверу. Ключ у нас уже есть на сервере ${HOME}/.kube/config и теперь нам нужно просто авторизоваться:
$ gcloud container clusters get-credentials b zone europe-north1-a project essch
$ kubectl port-forward Nginxlamp-74c8b5b7f-d2rsg 8080:8080
Forwarding from 127.0.0.1:8080 > 8080
Forwarding from [::1]:8080 > 8080
$ google-chrome http://localhost:8080 # это не будет работать в Google Shell
$ kubectl expose Deployment Nginxlamp type="LoadBalancer" port=8080
Для локального использования kubectl Вам нужно установить gcloud и с помощью него установить kubectl используя команду gcloud components install kubectl, но пока не будем усложнять первые шаги.
В разделе Сервисы админки будет доступен под не только через сервис балансировщик frontend, но и через внутренний балансировщик Deployment. Хоть и после пересоздания и сохранится, но конфиг более поддерживаем и очевиден.
Также есть возможность дать возможность регулировать количество нод в автоматическом режиме в зависимости от нагрузки, например, количества контейнеров с установленными требованиями к ресурсам, с помощью ключей enable-autoscaling min-nodes=1 max-nodes=2.
Простой кластер в GCP
Для создания кластера можно пойти двумя путями: через графический интрефейс Google Cloud Platform или через его API командой gcloud. Посмотрим, как это можно сделать через UI. Рядом с меню кликнем на выпадающей список и создадим отдельный проект. В разделе Kuberntes Engine выбираем создать кластер. Дадим название, 2CPU, зону europe-north-1 (дата-центр в Финляндии ближе всего к СПб) и последнюю версию Kubernetes. После создания кластера кликаем на подключиться и выбираем Cloud Shell. Для создания через api по кнопке в правом верхнем углу выведем консольную панель и введём в ней: