Kubernetes, здається, стосується розгортання контейнерів у хмару кластерів. Те, що, схоже, не торкається середовища розробки та інсценування (або такого).

Під час розвитку ви хочете бути максимально наближеними до виробничого середовища з деякими важливими змінами:

• Розгорнуто локально (або принаймні десь там, де ви та лише ви можете отримати доступ )
• Використовуйте останній вихідний код на оновлення сторінки (припустимо, що його веб-сайт; в ідеалі автоматично оновити сторінку на локальному файлі, зберегти яку можна зробити, якщо встановити вихідний код і використовувати деякі речі, такі як Yeoman ).

Аналогічно, можна, щоб непублічне середовище здійснювало постійну інтеграцію .

Чи підтримує Kubernetes таке середовище розвитку, чи це щось, що треба будувати, сподіваючись, що під час виробництва воно все одно спрацює?

Оновлення (2016-07-15)

З випуском Kubernetes 1.3, Minikube став рекомендованим способом запуску Kubernetes на вашій локальній машині для розвитку.

Ви можете запускати Kubernetes локально через Docker . Як тільки у вас працює вузол, ви можете запустити стручок, який має простий веб-сервер і змонтує обсяг з вашого хост-машини. При натисканні на веб-сервер він зчитується з тома, і якщо ви змінили файл на локальному диску, він може обслуговувати останню версію.

Ми працювали над інструментом для цього. Основна ідея полягає у тому, що у вас є віддалений кластер Kubernetes, ефективно інсценуюче середовище, а потім ви запускаєте код локально, і він стає проксі-сервісом до віддаленого кластеру. Ви отримуєте прозорий доступ до мережі, копіювані змінні середовища, доступ до томів ... максимально наближений до віддаленого середовища, але ваш код працює локально та під вашим повним контролем.

Так що ви можете зайнятися розвитком у прямому ефірі. Документи на сайті http://telepresence.io

Таке "гаряче перезавантаження" - це те, що ми плануємо додати, але це не так просто, як це могло б бути сьогодні. Однак, якщо ви відчуваєте пригоди, ви можете використовувати rsync з docker exec, kubectl exec або osc exec (усі роблять те ж саме приблизно), щоб синхронізувати локальний каталог у контейнер щоразу, коли він змінюється. Ви можете використовувати rsync з kubectl або osc exec так:

# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder

Інший чудовий вихідний пункт - це налаштування Vagrant , esp. якщо вашою операційною ОС є Windows. Очевидними перевагами є

• швидке і безболісне налаштування
• легко зруйнувати / відтворити машину
• неявна обмеженість ресурсів
• можливість перевірити горизонтальне масштабування шляхом створення декількох вузлів

Недоліки - вам потрібно багато оперативної пам'яті, а VirtualBox - це VirtualBox ... для кращого або гіршого.

Змішана перевага / недолік - це відображення файлів через NFS. Під час налаштування ми створили два набори визначення RC - той, який просто завантажує зображення докера наших серверів прикладних програм; інший із 7 додатковими рядками, які налаштовують відображення файлів з HostOS -> Vagrant -> VirtualBox -> CoreOS -> pod Kubernetes; перезапис вихідного коду із зображення Докера.

Недоліком цього є кеш файлів NFS - з ним проблематично, без нього проблематично повільно. Навіть налаштування mount_options: 'nolock,vers=3,udp,noac'не позбавляється проблем кешування повністю, але воно працює більшу частину часу. Деякі завдання Gulp, що виконуються в контейнері, можуть зайняти 5 хвилин, якщо вони знаходяться на 8-й секунді в хост-ОС. Здається, хороший компроміс mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15'.

Що стосується автоматичного перезавантаження коду, це специфічно для мови, але ми задоволені розробником Django для Python та Nodemon для Node.js. Для проектів на передній панелі ви, звичайно, можете багато зробити з чимось на кшталт gulp + browserSync + watch, але для багатьох розробників не важко обслуговувати Apache і просто робити традиційне жорстке оновлення.

Ми зберігаємо 4 набори файлів yaml для Kubernetes. Dev, "побожний", етап, прод. Відмінності між ними є

• env змінні явно встановлюють середовище (dev / stage / prod)
• кількість реплік
• руйнівний, сценічний, prod використовує зображення докера
• dev використовує зображення докера та відображає папку NFS із вихідним кодом над ними.

Дуже корисно створити безліч псевдонімів bash і автозавершити - я просто можу набрати, rec usersі це буде робити kubectl delete -f ... ; kubectl create -f .... Якщо я хочу, щоб весь настрій почався, я набираю recfo, і він відтворює десяток сервісів, витягуючи останні зображення докера, імпортуючи останню db-дамп із Staging env та прибираючи старі файли Docker для економії місця.

Я щойно почав зі Скеффолдом

Дійсно корисно автоматично застосовувати зміни коду до локального кластеру.

Для розгортання локального кластера найкращим способом є Minikube або просто Docker для Mac і Windows, обидва включає інтерфейс Kubernetes.

Див. Https://github.com/kubernetes/kubernetes/isissue/12278 про те, як встановити гучність з хост-машини, еквівалент:

docker run -v hostPath:ContainerPath

Приємний цикл зворотного зв'язку з місцевим розвитком - тема швидкого розвитку в екосистемі Кубернета.

Розбиваючи це питання, є кілька інструментів, які, на мою думку, добре підтримують цю мету.

Докер для Mac Kubernetes

Docker для Mac Kubernetes ( Docker Desktop - загальна назва крос-платформи) - це відмінний варіант для місцевого розвитку. Для віртуалізації він використовує HyperKit, який побудований на рідній основі Hypervisor в macOS замість VirtualBox.

Функція Kubernetes була вперше випущена як бета-версія на крайньому каналі в січні 2018 року і пройшла довгий шлях з того часу, ставши сертифікованим Kubernetes у квітні 2018 року та закінчивши стабільний канал у липні 2018 року .

На мій досвід, працювати з Minikube набагато простіше, особливо з macOS, і особливо це стосується таких питань, як RBAC, Helm, гіпервізор, приватний реєстр тощо.

Шлем

Що стосується розповсюдження коду та перенесення оновлень на місцевому рівні, Helm - це один із найпопулярніших варіантів. Ви можете публікувати свої програми за допомогою CI / CD у вигляді графіків Helm (а також основних зображень Docker, на які вони посилаються). Потім ви можете витягнути ці діаграми з реєстру Helm chart локально та оновити на локальному кластері.

Проект Лазурний

Ви також можете використовувати такий інструмент, як Azure Draft, щоб робити прості локальні розгортання та генерувати основні графіки Helm із шаблонів загальної мови, на зразок збірних пакетів, для автоматизації цього фрагмента головоломки.

Скефи

Скеффолд схожий на проект Azure, але більш зрілий, набагато ширший за обсягом і створений Google. Він має дуже підключувану архітектуру. Я думаю, що в майбутньому більше людей використовуватимуть його для локальної розробки додатків для Kubernetes.

Якщо ви використовували React, я вважаю, що Скаффолд є " Створити додаток React для Кубернетів".

Складати або складати на Кубернетах

Docker Compose , не пов'язаний з Kubernetes, є однією з альтернатив, яку деякі компанії використовують, щоб забезпечити просту, легку та портативну локальну середовище розвитку, аналогічну середовищу Kubernetes, яку вони використовують у виробництві. Однак йти цим маршрутом означає розходити виробничі та місцеві налаштування розвитку.

Kompose - перетворювач Docker Compose to Kubernetes. Це може бути корисним шляхом для тих, хто вже виконує свої програми як локальні колекції контейнерів.

Compose on Kubernetes - це нещодавно відкрите джерело (грудень 2018 року) від Docker, яке дозволяє розгортати файли Docker Compose безпосередньо в кластер Kubernetes через користувальницький контролер.

Kubespary - це корисна настройка локальних кластерів. Здебільшого я використовував кластер на базі бродяж на локальній машині.

Конфігурація Kubespray Ви можете налаштувати ці змінні, щоб мати потрібну версію кубернетів.

Недоліком використання minkubeє те, що він породжує іншу віртуальну машину над вашою машиною. Крім того, для останньої minikubeверсії мінімум вимагає, щоб у вашій системі було 2 процесора та 2 Гб оперативної пам’яті, що робить його досить важким, якщо у вас немає системи з достатньою кількістю ресурсів.

Це причина, що я перейшов на microk8sрозробку в кубернетах і мені це подобається. microk8sпідтримує DNS, локальну пам’ять, інформаційну панель, istio, вхід та багато іншого, все, що потрібно для тестування ваших мікросервісів.

Він призначений для швидкої та легкої установки Kubernetes вгорі за течією, ізольованої від вашого місцевого оточення. Така ізоляція досягається шляхом упаковки всіх бінарних файлів для Kubernetes, Docker.io, iptables та CNI в єдиний оснащений пакет.

Один кластерний кластер кубернетів може бути встановлений протягом хвилини за допомогою однієї команди:

snap install microk8s --classic

Переконайтесь, що у вашій системі не працює жодна послуга докера чи кубелета. Microk8sвстановить усі необхідні послуги автоматично.

Перегляньте наступне посилання, щоб увімкнути інші додатки microk8s.

https://github.com/ubuntu/microk8s

Ви можете перевірити стан за допомогою:

velotio@velotio-ThinkPad-E470:~/PycharmProjects/k8sClient$ microk8s.status
microk8s is running
addons:
ingress: disabled
dns: disabled
metrics-server: disabled
istio: disabled
gpu: disabled
storage: disabled
dashboard: disabled
registry: disabled

Погляньте на https://github.com/okteto/okteto та Okteto Cloud . Ціннісна пропозиція полягає в тому, щоб мати класичний досвід розробки, ніж працювати локально, перед докером, де ви можете мати гарячі перезавантаження, інкрементальні побудови, налагоджувачі ..., але всі ваші локальні зміни негайно синхронізуються з віддаленим контейнером. Віддалені контейнери дають вам доступ до швидкості хмари, дозволяють новий рівень співпраці та інтегрують розвиток у виробниче середовище. Також це усуває тягар місцевих установок.

Як зазначав раніше Роберт, мінібуб - це шлях.

Ось короткий посібник для початку роботи з minikube. Загальні кроки:

• Встановіть minikube

• Створіть кластер minikube (у віртуальній машині, яка може бути VirtualBox або Docker для Mac чи HyperV для Windows)

• Створіть зображення Docker у файлі програми (за допомогою Dockerfile)

• Запустіть зображення, створивши Розгортання

• Створіть службу, яка відкриває вашу програму, щоб мати доступ до неї.

Ось як я зробив локальну настройку для Kubernetes в Windows 10: -

• Використовуйте Docker Desktop

• Увімкніть Kubernetes у налаштуваннях Docker Desktop

• У Docker Desktop за замовчуванням виділений ресурс пам’яті становить 2 Гб, тому використання Kubernetes з Docker Desktop збільшує пам’ять.

• Встановіть kubectl як клієнта, щоб поговорити з кластером Kubernetes

• Запустіть команду kubectl config get-контексти, щоб отримати доступний кластер

• Виконайте команду kubectl config use use-context docker-desktop для використання робочого столу docker

• Створіть зображення докера своєї програми

• Напишіть файл YAML (описовий метод для створення вашого розгортання в Kubernetes), вказуючи на зображення, створене в кластері вище

• Розкрийте послугу порту вузла типу для кожного вашого розгортання, щоб зробити його доступним для зовнішнього світу