Kubernetes: масштабируя высоты. Продолжение

На запуск потребуется время — группа контейнеров некоторое время будет находиться в «подвешенном (pending)» состоянии по мере загрузки образов Docker из открытого хаба Docker. Когда группа контейнеров перейдет в состояние «запущено [running]», я смогу просмотреть лог-файлы, созданные контейнером Redis. Первый аргумент команды logs — это имя группы контейнеров; второй — контейнер, лог-файлы для которого я хочу просмотреть (если они есть).

$ ./cluster/kubectl.sh logs redis-master master

Я должен увидеть знакомый лог-файл запуска Redis, который означает, что сервер готов к получению трафика на порт 6379. Теперь мы можем определить сервис. Он позволит определять «стражей» Redis с помощью API Kubernetes. В приведенном примере сервис определяется файлом redis-sentinel-servioe.yaml. Запустить этот сервис можно с помощью той же команды, которая была указана выше. Также с помощью команды get можно получить список сервисов (get services). Однако сервис Redis пока не обладает отказоустойчивостью. Чтобы ее получить, надо создать контроллеры репликации, которые, как я рассказывал вам месяц назад, следят за тем, чтобы было запущено достаточно групп контейнеров. В каталоге example есть два файла, определяющих такие контроллеры — один для Redis и один для «стража»: rediscontroller.yaml и reis-sentinel-controller.yaml. После их создания (опять же с помощью команды, указанной выше) можно получить их список командой rc (запустите kubctl.sh get без аргументов, чтобы узнать, какие еще списки можно получить).

Теперь я могу масштабировать службы Redis простой командой:

$ ./cluster/kubectl.sh scale rc redis --replicas=3 
$ ./cluster/kubectl.sh scale rc redis-sentinel replicas=3

Kubernetes не слишком многословен в комментариях о завершении этой задачи (об успехе свидетельствует единственное слово «отмасштабировано [scaled]»), но команда get покажет новые запущенные группы контейнеров. Для получения дополнительной информации иногда удобно запустить команду get с параметром -o json (например, kubectl.sh get -o json pods). Снова взглянув на лог-файлы основного узла Redis, я вижу, что запросы синхронизации пришли и были завершены. При добавлении новых реплик в этих лог-файлах появятся дополнительные записи. Теперь я проверю отработку отказа, «убив» один из узлов Vagrant и установив кластер. После этого группы контейнеров Redis должны перезапуститься.

$ vagrant ssh minion-3 
$ sudo shutdown -h now 
$ ./cluster/kube-up.sh 
$ ./cluster/kubectl.sh get pods

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

Наскучила работа с Kubernetes до такой степени, что от одного только упоминания о ней, у вас моментально портится настроение. И вы, конечно же, нашли бы другую работу, но больше ничего не умеете делать. Не отчаивайтесь: у вас все еще есть выход. На сайте http://vulkan-igrat.com (http://vulkan-igrat.com/) вы можете испытать свою удачу. И кто знает, возможно, именно вам выпадет крупнейший джекпот в истории!