Это немного теоретически, но, пожалуйста, потерпите меня.
В настоящее время у меня есть сервер с несколькими контейнерами Docker (4 или 5, в зависимости от дня и времени). Планирую добавить еще один, как и первый, а может, и третий.
Теперь у меня такой вопрос: если придет время, когда мне придется управлять 15 контейнерами вместо 5, есть ли какие-то преимущества в использовании Google Kubernetes?
Кроме того, существует ли «официальный» или, по крайней мере, «окончательный» рабочий процесс для миграции из контейнеров Docker в «поды», родную единицу Kubernetes. Прежде чем вы спросите, я знаю, что стручки состоят из контейнеров (иногда даже из одного). Моя основная проблема здесь в том, что «файлы докеров» полностью отличаются от конфигураций модулей.
Любые идеи?
Если придет время управлять 15 контейнерами вместо 5, есть ли смысл в использовании Google Kubernetes?
Если вы запускаете контейнеры на одном сервере, используя Демон докера и это Удаленный API звучит уместно.
Если вам нужно запускать контейнеры на нескольких серверах, вот где решения для оркестрации, такие как Kubernetes, Докерский рой, Флот, Mesos, Geard становится полезным.
Моя основная проблема здесь в том, что «файлы докеров» полностью отличаются от конфигураций модулей.
Потому что у них разные цели:
Dockerfile
указывает, как построить образ контейнера из дерева источниковpod.yaml
определяет, как запланировать (изображение, командная строка, тома, порт) набор совместно размещенных контейнеров (совместно использующих сетевое пространство имен и тома) на одном из узлов вашего кластера.Вы можете рассматривать поды как способ декларативного указания набора docker run --net=container:... -v ... -p ...
команды.
Кроме того, существует ли «официальный» или, по крайней мере, «окончательный» рабочий процесс для миграции из контейнеров Docker в «поды», родную единицу Kubernetes.
Есть небольшой инструмент в kubernetes / contrib называется подекс которые позволяют создавать манифест модуля из метаданных изображения, хранящихся в общедоступном реестре.
$ go get github.com/GoogleCloudPlatform/kubernetes/contrib/podex
$ podex google/nodejs-hello
id: nodejs-hello
kind: Pod
apiVersion: v1beta1
desiredState:
manifest:
version: v1beta2
containers:
- name: nodejs-hello
image: google/nodejs-hello
ports:
- name: nodejs-hello-tcp-8080
containerPort: 8080
Ответ @ proppy правильный: один работает только для одного сервера.
У меня была такая же первоначальная реакция, однако на самом деле у вас может быть несколько служб и модулей в одном файле (разделенных ---
). Таким образом, у вас все еще будет 1 сервис + 1 модуль на контейнер в целом, но это не так уж плохо.
Вы также должны назвать кучу вещей больше, чем в docker-compose (иногда я чувствую, что это более чем необходимо). После того, как вы пройдете обучение, какое имя имеет значение, с вами все будет в порядке, и обслуживание файлов будет не намного сложнее.
Развертывание намного сложнее IMO, но, опять же, оно распределено, а также приближается тип Deployment Pod, который должен упростить обновления (в настоящее время как бета-расширение в версии 1.1).