Докер у розгортанні Кубернетеса


13

Я використовую сторонню бібліотеку, яка створює контейнери для одночасних докерів через:

docker run -d /var/run/docker.sock:/var/run/docker.sock ...

Я намагаюся створити розгортання Kubernetes з вищевказаного контейнера, але наразі отримую:

Не вдається підключитися до демона Docker на unix: ///var/run/docker.sock. Чи працює дакерський демон?

Це очікується, оскільки я не декларую /var/run/docker.sockяк об'єм у ямлі розгортання.

Проблема в тому, що я не знаю, як це зробити. Чи можливий монтаж /var/run/docker.sockяк том в ямлі розгортання?

Якщо ні, то який найкращий підхід для запуску докерних контейнерів-синглів зсередини Kubernetes розгортання / стручка?

Відповіді:


19

Неперевірене, як мені здається крихким, щоб запустити контейнер поза наглядом k8s, але ви повинні мати змогу монтуватися /var/run/docker.sockз томом hostPath .

Приклад варіації з документації:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock-volume
  volumes:
  - name: docker-sock-volume
    hostPath:
      # location on host
      path: /var/run/docker.sock
      # this field is optional
      type: File

Я думаю, що простого монтування повинно бути достатньо, щоб дозволити спілкування від докер-клієнта всередині контейнера до демон-докера на хості, але якщо ви отримаєте помилку дозволу на запис, це означає, що вам потрібно запустити контейнер як привілейований контейнер, використовуючи такий об'єкт securityContext, як такий (просто витяг зверху, щоб показати додавання, значення, взяті з документації ):

spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    securityContext:
      privileged: true
    name: test-container

Це спрацювало, дякую. Так, це сторонній інструмент, тому він не є ідеальним. Але я, принаймні, хочу, щоб головний контейнер у Kubernetes зробив його більш надійним. Контейнер скачує тимчасові контейнери з браузерами для автоматичного тестування інтерфейсу користувача, після чого контейнер браузера знищується.
rys

@rys так, це був випадок, про який я думав, ви все ще можете зіткнутися з проблемами, якщо навантаження вузла буде занадто великою, оскільки k8s може перемістити ваш контейнер "запуск" Але я припускаю, що в цьому випадку відмова тестового набору є чимось прийнятним
Tensibai

2

Хоча це робоче рішення (я сам його використовую), є деякі недоліки для запуску Docker у стручці Kubernetes шляхом монтажу. /var/run/docker.sock

Переважно той факт, що ви працюєте з контейнерами Docker поза контролем Kubernetes.

Ще одне запропоноване нами рішення - це використання контейнера для бокових автомобілів у вашому стручку. Дивіться Випадок "Докер-в-Докер" на Kubernetes . Є дві частини, де пропоноване рішення знаходиться в частині 2 .

Я сподіваюся, що це допомагає.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.