Google Container Engine

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:46, 27 мая 2017.
Google Container Engine
Untitled-drawing.png
Создатели: Google inc.
Выпущена: 2011
Постоянный выпуск: 1.9.35 / 24 March 2015
Написана на: Python, PHP, Java, Go, Node.js
Лицензия: Proprietary
Веб-сайт https://cloud.google.com/container-engine/
Стандарт(ы) released

Google Container Engine(GKE) — мощная система управления и оркестровки для контейнеров Docker, действующих в облачном пространстве Google. Container Engine составляет контейнеры в кластеры и управляет ими автоматически, опираясь на определенные вами требования. Google Container Engine основан на системе с открытым исходным кодом Kubernetes, что дает возможность воспользоваться возможностями инфраструктуры локального, гибридного, публичного облаков.

Функциональные возможности Google Container Engine

  • Поддержка контейнеров Docker;
  • Масштабируемость приложений на основе используемых ресурсов;
  • Логирование информации о работе приложений;
  • Возможность создания гибридных сетей;
  • Управление идентификацией и доступом;
  • Конфиденциальный реестр контейнеров позволяет хранить и получать доступ к личным Docker образам.

Задачи, решаемые при использовании Google Container Engine

Как правило, организации используют Google Container Engine для решения следующих задач:

  • Создание или изменение размера кластера контейнеров Docker;
  • Создание групп контейнеров с общими разделами, запускаемых как единое целое, и балансировщиков нагрузки;
  • Изменение контроллеров доставки приложений;
  • Обновление кластеров контейнеров;
  • Отладка кластеров контейнеров.

Пользователи могут взаимодействовать с Google Container Engine с помощью интерфейса командной строки gcloud или Google Cloud Platform Console.

Google Container Engine часто используется разработчиками программного обеспечения, которые создают и тестируют новые корпоративные приложения. Контейнеры также используются администраторами для лучшей масштабируемости приложений и исполнения требований, предъявляемых к корпоративным приложениям.

Особенности Google Container Engine

Кластер контейнеров

Google Container Engine состоит из группы инстансов Google Compute, которые работают на базе Kubernetes. Управляющий узел отвечает за кластер контейнеров Docker. Он также запускает сервер API Kubernetes, который взаимодействует с кластером и выполняет такие задачи, как обслуживание запросов API и планирование контейнеров. Помимо управляющего узла кластер может также содержать в себе один или несколько узлов, каждый из которых выполняет настройки агента, запущенного на нодах, которые необходимы для управления контейнерами Docker.[Источник 1]

Использование Kubernetes

Каждый контейнерный кластер имеет единственный эндпоинт управления Container Engine. Он предоставляет унифицированное представление внутри кластера, и через свою общедоступную конечную точку является главным способом взаимодействия с кластером. Управляемый мастер также запускает сервер API Kubernetes, который обслуживает REST-запросы, планирует создание и удаление приложений на рабочих узлах и синхронизирует информацию запущенных приложений (такую как открытые порты и местоположение) с сервисной информацией. GKE также обновляется до новейших версий Kubernetes и интегрируется с другими Google Cloud Services. С компаниями CoreOS, Huawei, IBM, OpenStack, Red Hat, и VMware (их список увеличивается) возможна интеграция Kubernetes в их платформы. Таким образом, пользователи с легкостью могут перемещать рабочие нагрузки.[Источник 2]

Ноды

Кластер контейнеров может иметь одну или более нод. Они управляются централизованно и запускают службы, необходимые для поддержки контейнеров Docker. Каждый узел запускает среду выполнения Docker и размещает Kubelet, управляющий Docker-контейнерами, работающими/запланированными в этой ноде. В каждой также запущен простой сетевой прокси.[Источник 3]


Пулы нод

Пул нод - это подмножество нод в кластере, которые имеют одну и ту же конфигурацию. Хотя все ноды в контейнер-кластере по сути идентичны, пулы позволяют создавать группы машин, имеющих отличающиеся конфигурации. Например, вы можете создать пул в кластере с машинами, имеющими локальные SSD или нужную для выполнения конкретной задачи определенную вычислительную мощность. Пулы нодов полезны для кастомизации экземпляра кластера. Например, можно запускать разные пулы с разными версиями Kubernetes, обновлять каждый пул независимо и настраивать каждый для конкретных развертываний.[Источник 4]


Создание пула нод

Вызов "create" принимает NodeConfig JSON-файл и создает с ним пул машин. Каждая нода имеет метку узла Kubernetes с именем пула в ключе cloud.google.com/gke-nodepool.

Чтобы добавить пул нод в проект через Cloud Platform Console, перейдите на страницу "Сontainer clusters" и нажмите "Edit a cluster". На странице настройки вы увидите "Add node pool".

Просмотр имеющихся пулов

Чтобы просмотреть имеющиеся пулы, перейдите на страницу "Сontainer clusters" и щелкните имя любого существующего кластера в вашем проекте. Детали его пула будут перечислены под заголовком "Node Pools".

Удаление пула

Удаление пула удаляет все его ноды и маршруты к ним. Любой модуль, запущенный на этих узлах, будет удален или перенесен. Команда для удаления пула нод в консоли gcloud:

gcloud container node-pools delete NAME --zone ZONE --cluster CLUSTER

Мультизонные кластеры

Мультизонные кластеры GKE в основном используются для улучшения для улучшения доступности вашего приложения в маловероятном случае недоступности какой-то конкретной зоны. Все зоны, используемые в мультизонном кластере, должны находиться в одном регионе. При создании мультизонного кластера, либо изначально, либо путем добавления зон в существующий кластер, Container Engine делает одинаковым во всех зонах требуемый ресурс. То есть группы управляемых экземпляров одинакового размера теперь будут находиться во всех требуемых зонах. Например, предположим, что вы запрашиваете два экземпляра VM с четырьмя ядрами каждый, и вы требуете, чтобы ваш кластер был распределен по трем зонам. Вы получите 24 ядра с 8 ядрами по трем зонам. Причина равномерного распределения ресурсов между зонами состоит в том, чтобы обеспечить равномерное планирование контейнеров в разных зонах. Это улучшает доступность и восстановление после сбоев. Если вычислительные ресурсы распределялись по зонам неравномерно, планировщик не сможет равномерно распределять пакеты между зонами, даже несмотря на то, что он будет прилагать для этого максимум усилий.[Источник 5]


Настройка использования

Вы можете настроить использование нескольких зон при создании кластера. В команде "create" контейнеров в gcloud используйте флаг --additional-zones, чтобы указать дополнительные зоны:

gcloud container clusters create multi-prod --zone us-central1-f --additional-zones=us-central1-a,us-central1-b

Эта команда сгенерирует следующий выход:

NAME        ZONE           MASTER_VERSION  MASTER_IP        MACHINE_TYPE   NODE_VERSION  NUM_NODES STATUS
multi-prod  us-central1-f  1.3.2           xxx.xxx.xxx.xx   n1-standard-1  1.3.2         9        RUNNING

Если ваш кластер был создан с параметром --additional-zones, то все пулы нод будут автоматически реплицированы в эти зоны. Любой новый пул узлов, который будет создан, будет автоматически создан и в этих зонах. Аналогичным образом, любые удаления повлекут за собой удаление пулов в соответственных зонах.

Прим: обратите внимание, что из-за мультипликативного эффекта, это может потреблять больше квоты вашего проекта для определенного региона при создании пулов нод.

Автоскалирование кластеров.

Сluster Autoscaler позволяет пользователям автоматически изменять размеры кластеров, чтобы все запланированные/работающие приложения в кластерах могли иметь достаточно места для запуска/работы соответственно. Если в кластере недостаточно ресурсов для запуска недавно созданного приложения, добавляется новая нода. С другой стороны, если какой-то узел используется недостаточно, и все запущенные на нем приложения могут быть легко куда-то перемещены, то это происходит, а узел удаляется. Это позволяет пользователям платить за ресурсы только в момент необходимости и получать их автоматически при увеличении нагрузки.[Источник 6]


Маркировка кластеров

Маркировка - легкий способ группировки связанных ресурсов в Google Cloud Platform. Например, вы можете маркировать кластеры, которые вы используете для производства, тестирования или разработки, чтобы вы могли легче их отслеживать тогда, когда это нужно. Google Cloud Platform также добавляет любые ярлыки, которые вы применяли к своим проектам, по предоставлении платежной информации, чтобы вы получали наиболее детальную информацию о расходах вашего проекта. [Источник 7]


В Container Engine вы применяете ярлыки на уровне кластера. Когда мы маркируете кластер, выбранным вами ярлыком рекурсивно помечаются также все связанные с ним ресурсы. Прим: любые ярлыки, которые вы применяете к кластерам распространяются через фоновый процесс, выполняющийся ежечасно.

Ярлыки - это строки в стиле RFC1035, которые содержат пары ключ/значение. Формат может напоминать env:development или type: gpu-enabled. Применяются следующие ограничения:

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

Управление доступом

Управление доступом на основе ролей в контейнере позволяет вам осуществлять тонкое управление тем, как пользователи получают доступ к ресурсам APIKubernetes, работающем на вашем кластер-контейнере. Вы можете использовать контроль доступа на основе ролей, чтобы динамически настраивать разрешения для пользователей вашего кластера и определять виды ресурсов, с которыми они могут взаимодействовать. Вы можете создать разрешения управления на основе ролей, которые применяются ко всему вашему кластеру или к определенным пространствам имен в вашем кластере. Разрешения на уровне кластера полезны для ограничения доступа определенных пользователей к определенным ресурсам API (таким как политики безопасности или секреты). Разрешения, зависящие от пространства имен, полезны, если, например, у вас есть несколько групп пользователей, работающих в своих собственных пространствах имен. Управление доступом на основе ролей может помочь вам обеспечить доступ пользователей к ресурсам кластера только в своем собственном пространстве имен.

Чтобы ваши разрешения на основе управления доступом на основе ролей вступили в силу, вы должны создать свой кластер с параметром --no-enable-legacy-authorization. Права доступа на основе ролей являются чисто аддитивными - нет правил типа «запретить». При структурировании своих прав доступа на основе ролей вам следует подумать о том, чтобы «предоставить» пользователям доступ к ресурсам кластера. Вы определяете разрешения в пределах объекта Kubernetes Role или ClusterRole . Роль предоставляет доступ к ресурсам в пределах одного пространства имен, а ClusterRole предоставляет доступ к ресурсам всего кластера. Внутри вашего объекта Role (или ClusterRole) вы определяете разрешения как набор правил. Правила определяют пространство имен, тип ресурса и допустимые операции для этой роли. Например, вы можете создать роль, которая предоставляет доступ на чтение (такие операции, как get, watch и list) для всех ресурсов приложения в заданном пространстве имен.[Источник 8]


Ротация IP

Функция IP Rotation для контейнера позволяет вам изменить IP-адрес, который Kubernetes вашего кластера использует для обслуживания запросов API Kubernetes. Его можно использовать для обфускации местоположения вашего работающего узла управления Kubernetes. Ротация IP также изменяет сертификат SSL и полномочия сертификата кластера вместе с основным IP-адресом, поэтому между предыдущим адресом и новым адресом отсутствует видимое внешнее соединение. Ротация IP является многошаговым процессом. Когда вы инициируете ротацию, мастер кластера начинает обслуживать новый IP-адрес в дополнение к исходному IP-адресу. Затем вы должны обновить клиенты API вашего кластера (например, машины, использующие интерфейс командной строки kubectl), чтобы начать связь с мастером по новому IP-адресу. Наконец, когда вы завершаете ротацию, мастер прекращает обслуживать трафик по предыдущему IP-адресу.[Источник 9]


Прим: Если вы инициируете ротацию IP-адреса, но не завершаете её, GKE автоматически завершит ротацию через семь дней.

Пример инициализации ротации

Вы инициируете ротацию IP, используя команду обновления кластер-контейнеров и передавая параметр --start-ip-rotation следующим образом:

gcloud container clusters update CLUSTER --start-ip-rotation

Вышеупомянутая команда настраивает главный сервер кластера на обслуживание по двум IP-адресам, исходному адресу и новому адресу. Это приведет к небольшому количеству времени простоя API кластера. После перенастройки главного сервера контейнерный движок автоматически обновляет ноды кластера в фоновом режиме, указывая на новый IP-адрес. Каждый пул нод отмечен как «требует пересоздания», а GKE не позволит завершить ротацию IP до завершения автоматического повторного создания. Если вы хотите продолжить работу по мере обновления пулов узлов, вы можете найти выполняющуюся операцию автоматического обновления, запустив:

gcloud container operations list | grep "AUTO_UPGRADE_NODES.*RUNNING"

Затем вы можете подождать выполнения операции, выполнив команду:

gcloud container operations wait OPERATION_ID

Пулы узлов будут пересоздаваться один за другим, и каждый будет иметь свою собственную операцию. Если у вас несколько пулов узлов, вы можете использовать приведенные выше инструкции для ожидания каждой операции автоматического обновления.

Обновление клиентских API и завершение ротации

После запуска IP-ротации вы должны обновить все клиенты API за пределами кластера (например, kubectl на машинах разработчика), чтобы указать на новый адрес. Вы можете обновить свои API-клиенты, используя команду gcloud container clusters get-credentials на клиентской машине, как показано ниже:

gcloud container clusters get-credentials CLUSTER

Наконец, вы завершаете ротацию IP, используя gcloud container clusters update и передавая параметр --complete-ip-rotation следующим образом:

gcloud container clusters update CLUSTER --complete-ip-rotation

Вышеупомянутая команда настраивает главный сервер кластера на обслуживание только на его новом IP-адресе. Это приведет к небольшому количеству времени простоя API кластера.

Поддержка локальных SSD

Локальные SSD - это физические устройства, подключенные к экземпляру виртуальной машины. GKE добавил возможность создавать узлы с ними, вплоть до пределов машины и квоты проекта. Локальные SSD обеспечивают более высокую пропускную способность и меньшую задержку по сравнению с обычными дисками. Но они работают с серьезным ограничением: поскольку они физически присоединены к экземпляру виртуальной машины узла, то любые данные, хранящиеся в них, существуют только на этом узле. Контейнер, записывающий данные на локальный SSD, может потерять доступ к этим данным, если он будет перенесен с этого узла. Кроме того, обновление узла приводит к полной потере данных. Имейте в виду эти ограничения при использовании локальных SSD.[Источник 10]


Создание кластера/пула с SSD

Чтобы создать кластер или пул узлов с локальными SSD, используйте параметр --local-ssd-count при создании кластера или пула узлов:

gcloud container clusters create NAME --local-ssd-count=#

Создание пула нод с локальными SSD-дисками в контейнер-кластере:

gcloud container node-pools create NAME --cluster CLUSTER --local-ssd-count=#

Параметр --local-ssd-count определяет количество локальных твердотельных накопителей, которые должны быть созданы для каждого узла. Максимальное количеcnво зависит от типа и региона устройства. Когда ноды создаются, локальные SSD автоматически форматируются и монтируются на хост-системе в поддиректории /mnt/disks/, причем каждый локальный SSD монтируется в каталоге ssd #. Они доступны из вашего контейнера Kubernetes через параметр hostPath в файле pod.yaml:

apiVersion: v1
	kind: Pod
	metadata:
	  name: "test-ssd"
	spec:
	  containers:
	  - name: "shell"
	    image: "ubuntu:14.04"
	    command: ["/bin/sh", "-c"]
	    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
	    volumeMounts:
	    - mountPath: "/test-ssd/"
	      name: "test-ssd"
	  volumes:
	  - name: "test-ssd"
	    hostPath:
	      path: "/mnt/disks/ssd0"
	  nodeSelector:
	    cloud.google.com/gke-local-ssd: "true"

Прерываемые виртуальные машины

Вы можете создать кластер или пул контейнеров для контейнера, который использует "прерываемые" виртуальные машины. Preemptible VM's - это экземпляры Google Compute Engine, которые существуют максимум 24 часа, и не обеспечивают никаких гарантий доступности. Они оценены ниже стандартных экземпляров Compute Engine и предлагают одинаковые типы и параметры машин. Вы можете использовать "вытесняемые" виртуальные машины в кластерах или пулах нод контейнера для выполнения пакетных или отказоустойчивых заданий, которые менее чувствительны к негарантированному характеру виртуальных машин.[Источник 11]


Создание кластера/пула с прерываемыми VM

Чтобы создать кластер или пул узлов с "вытесняемыми" виртуальные машины, укажите опцию --preemptible при использовании команд gcloud beta container cluster create или gcloud beta container node-pools create:

  • Создание кластера с вытесняемыми экземплярами
gcloud beta container clusters create CLUSTER --zone ZONE --preemptible
  • Создание пула с вытесняемыми экземплярами
gcloud beta container node-pools create NODEPOOL --cluster CLUSTER --zone ZONE --preemptible

Когда кластер GKE или пул нод создает экземпляры Compute Engine, эти экземпляры ведут себя как единая управляемая группа. Создание или добавление новых вытесняемых экземпляров в вашем GKE или пуле нод подчинено тем же ограничениям, что и вытесняемые экземпляры в группе управляемого экземпляра. Эти вытесняемые экземпляры также получают новый ярлык kubernetes cloud.google.com/gke-preemptible=true.

Автообновление узлов GKE

Автообновления нод позволяют Вам поддерживать их в актуальном состоянии с последней версией Kubernetes. При автообновлении используется тот же механизм, что и при ручном обновлении ноды. В пулах нод с включенным автообновлением запланировано автоматическое обновление при релизе новой версии Kubernetes. Чтобы создать кластер или пул узлов с включенными автоматическими обновлениями, укажите параметр --enable-autoupgrade при использовании gcloud beta container cluster create или gcloud beta container node-pools create[Источник 12]:

Настройка кластера/пула с автообновлением

  • Создание кластера с автоматическим обновлением
gcloud beta container clusters create CLUSTER --zone ZONE --enable-autoupgrade
  • Создание пула узлов с автоматическим обновлением
gcloud beta container node-pools create NODEPOOL --cluster CLUSTER --zone ZONE --enable-autoupgrade

Авторемонт узлов GCE

Функция авторемонта нод GKE помогает поддерживать работоспособность нод в кластере. Когда этот параметр включен, GKE периодически проверяет состояние работоспособности каждого узла в кластере. Если узел не проходит последовательные проверки работоспособности в течение длительного периода времени (приблизительно 10 минут), GKE инициирует процесс восстановления для этого узла.[Источник 13]


Критерии ремонта

GKE использует состояние работоспособности ноды, чтобы определить, нужно её восстанавливать . Узел, сообщающий о состоянии "Ready", считается здоровым. CE запускает восстановлениe, если узел сообщает о последовательных отчетах о "нездоровом" состоянии для заданного порога времени (приблизительно 10 минут). Нездоровый статус может означать:

  • Узел сообщает о состоянии "NotReady" при последовательных проверках за данный порог времени.
  • Узел не сообщает о каком-либо статусе вообще в течение заданного порога времени.

Если Container Engine обнаруживает, что узел требует ремонта, этот нода сначала будет удалена, а затем GCE пересоздаст VM этой ноды. Ремонт может не произойти, если узел не отвечает или слишком "нездоров" для обработки команды. Если несколько нод требуют ремонта, GKE ремонтирует один узел за раз, причем каждый процесс длится примерно 5-10 минут. Если вы отключите авторемонт узла в процессе восстановления, текущий ремонт не будет отменен и будет по-прежнему выполнен для любой ноды, ремонтирующейся в настоящее время. Также GCE создаст запись в своих логах для каждого события автоматического восстановления. Вы можете проверить логи, используя gcloud container operations list.

Создание кластера/пула с авторемонтом

Чтобы создать кластер или пул нод с включенным авторемонтом узлов, укажите параметр --enable-autorepair при создании с помощью инструмента командной строки gcloud.

  • Создание кластера с авторемонтом
gcloud beta container clusters create CLUSTER --zone ZONE --enable-autorepair
  • Создание пула нод с авторемонтом
gcloud beta container node-pools create NODEPOOL --cluster CLUSTER --zone ZONE --enable-autorepair


Пример работы с контейнером GKE

Руководство по развертке стандартного образа контейнера Docker через Google Cloud Shell с помощью простого приложения Node.js.

  • Рарегистрируйте аккаунт в Google, перейдите на страницу Google Cloud Platform и зарегистрируйте себя как юридическое лицо.
  • Создайте в меню GCP проект Google Container Engine.
  • Дождитесь завершения инициализации Container Engine и нажмите кнопку "Создать кластер".
  • При создании укажите зону "europe-west1b" и нажмите "Создать".
  • Дождитесь запуска кластера, затем откройте панель Cloud Shell в правом верхнем углу экрана.
  • Для примера Google предоставляют образец кода "Hello world!" на Node.js в репозитории GitHub. Чтобы клонировать образец кода введите следующие команды в Cloud Shell:
TUTORIALDIR=~/src/exampleproj-168712/gke_quickstart-2017-05-27-12-50
         git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git $TUTORIALDIR 
  • Перейдите в каталог с клонированным кодом:
cd $TUTORIALDIR/containerengine/hello-world
  • Чтобы просмотреть код приложения или Dockerfile, введите следующие команды:
cat server.js
         cat Dockerfile
  • Чтобы получить учетные данные gcloud для созданного кластера, используйте команду:
gcloud container clusters get-credentials cluster-1 --zone europe-west1-b
  • Далее необходимо создать и отправить образ приложения:
docker build -t gcr.io/exampleproj-168712/hello-node:v1 $PWD
gcloud docker -- push gcr.io/exampleproj-168712/hello-node:v1
  • Запускаем приложение в контейнере:
kubectl run hello-node --image=gcr.io/exampleproj-168712/hello-node:v1 --port=8080
  • Предоставляем общий доступ к контейнеру:
kubectl expose deployment hello-node --type="LoadBalancer"
  • Выводим список сервисов и находим сервис hello-node. Дожидаемся, когда в столбце "Внешний IP-адрес" отобразится IP-адрес. Это может занять около минуты. Затем останавливаем мониторинг, нажав Ctrl+C:
kubectl get service hello-node --watch
  • Скопируем IP-адрес, указанный в столбце "Внешний IP-адрес". Открываем новую вкладку, вставляем этот IP-адрес в строку браузера, добавляем порт 8080 и переходим на страницу приложения: http://EXTERNAL-IP:8080 (вместо EXTERNAL-IP подставляем внешний IP-адрес).



Список источников

  1. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  2. Хабрахабр [Электронный ресурс]: Основы Kubernetes // Дата обращения: 27.11.2016. — Режим доступа: https://habrahabr.ru/post/258443/
  3. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  4. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  5. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  6. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  7. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  8. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  9. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  10. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  11. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  12. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine
  13. CONTAINER ENGINE One-click Kubernetes clusters, managed by Google // Дата обращения: 27.11.2016. — Режим доступа: https://cloud.google.com/container-engine