Поєднайте докерський рій та кубернети

Моя компанія намагається трохи наздогнати простір DevOps. Я робив багато досліджень щодо контейнерної обробки додатків та систем оркестрації, які йдуть разом із цим. Я натрапив на статтю (яку я хотів би зберегти), де вони говорили про поєднання Swarm з Kubernetes для покращення функціональності. У цій статті вони не визначилися з тим, що вони отримали, зробивши це.

Я цікавився, які б вигоди це забезпечило? Чи дійсно додавання додаткового рівня складності дасть вам велику віддачу?

РЕДАКТИРУЙТЕ: Я шукаю технічних виробників. KISS - хороший девіз, але не витримує дебатів з вашим генеральним директором чи правлінням.

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

— ЄванМ
джерело

Оперативні слова тут «мене заінтригують». Ви - частина бізнесу. Для цього має бути поважна ділова причина. Не ваша зацікавленість, не технічна майстерність, вагомий діловий привід поєднати ці два. Якщо такої ділової причини для початку немає, вигадувати це просто неетично. Те, що ви пропонуєте, призводить до того, що витрачайте бізнес-ресурси з особистих причин, і етично це схоже на розкрадання.

— Jiri Klouda

Я обговорював, реагувати на це чи ні, тому що відверто кажучи, я відчуваю, ніби ця розмова марно витрачає час. Так, я є частиною бізнесу, так, це мене заінтригує, ні, я нічого не вигадую, і ставлення, яке ви мали від початку, є невиправданим. Інтрига - це те, що рухає технологію вперед, шукаючи причини, чому / чому ні, це частина роботи, а просто задавати питання тим, хто пішов перед вами, - найкраща практика. Це питання мало на меті отримати зворотній зв'язок від людей, які фактично працювали на цих платформах та мають обґрунтовану думку з цього приводу.

— EvanM

Я не шукаю гучних слів філософських дискусій або симпатичних абревіатур. Я шукаю технічні переваги або короткі приїзди, і там, де необхідно, заповнити прогалини. Все, що було розміщено, було думкою без фактичних аргументів. Буду вдячний, якби ви могли пояснити, яку технологію ви використовуєте для розв’язання контейнерів та оркестровок, а також про короткий час, який ви знайшли. Тоді я і мій бізнес вирішують, яка найкраща дорога для нас. Дослідження не є розкраданням або крадіжкою, це називається придурливістю, і саме те, як хороші технології перетворюються на чудові рішення.

— EvanM

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

— Jiri Klouda

Відповіді:

Оновлення: Докер щойно випустив підтримку Kubernetes як планувальника, що змінює ситуацію і робить Kubernetes просто альтернативним планувальником Docker Swarm.

TL; DR: НЕ РОБИТИ. Інженери завжди намагаються створити цих свиней. Кожна непотрібна вами технологія принесе ще один цілий набір несправностей. Якщо ви можете вибрати одне, то виберіть одне і будьте щасливі, що вам не потрібно робити обох. Якщо ви любите грати з Kubernetes, просто отримайте приватний обліковий запис у Google Cloud і пограйте з ним скільки завгодно. Але не змушуйте всіх у вашій компанії страждати через зайві ускладнення.

Це дві паралельні та здебільшого еквівалентні технології . Якщо ваш бізнес мав законний бізнес привід розгорнути в декількох хмарних провайдерів для надійності , наприклад , і хотів , щоб розгорнути в обидві AWS ECS (Elastic Container Service - на основі Докер) і Google GKE (Container двигуна - на основі Kubernetes) і ви запитували , як чи ви будуєте конвеєр, який збирав би ваше програмне забезпечення та пакет у контейнери для розгортання в обох , це було б щось інше, але робити це лише тому, що ви хочете грати з новою технологією, є дуже безвідповідальним.

— Ірі Клоуда
джерело

Я б не сказав, що хочу «грати» з Kubernetes. Є ділові причини, чому я віддаю перевагу саме Рою. Одне з них - це громада, і ваше припущення, що я просто хочу щось зробити, не так Я не погоджуюся з вашим коментарем собаки-свині, що прийшов з посади системного інженера, якого я бачив / заважав багато разів, або принаймні намагався. Ви не надали жодних ознак того, що працювали ви з засвоєними уроками, або будь-яких технічних деталей щодо того, чому; Я не відчуваю, що це стосується мого питання.

— EvanM

Я використовую "грати з", а не "працювати з", іноді частково в сенсі роботи весело, а частково базуючись на улюбленому мамі: "Ви просто граєте з комп'ютерами цілий день і ніколи не займаєтесь реальною роботою". :)

— Jiri Klouda

Отож, я роблю те саме. Просто хотіли дати зрозуміти, що це була не якась половина спроби змусити Kubernetes за горло моєї компанії. Звідси питання. Почуття кишки полягає в тому, що немає жодної «доброї» причини, але я не міг просто ігнорувати цю статтю.

— EvanM

Подивіться, ми всі були там. Бізнес планує працювати з однією технологією, коли ви думаєте, що інша краща, і ви хочете якось все-таки працювати з іншою або, принаймні, з обома, і показати їм, як ваш вибір був набагато кращим. Це класика. Незалежно від того, що ви думаєте, не комбінуйте обох заради того, щоб зробити це чи щоб довести, що ви праві. Навіть якщо ви могли б це виправдати, ваша робота - розробити рішення, щоб уникнути цього. KISS. Зробіть роботу з Swarm, переконайте всіх використовувати Kubernetes або кинути роботу та працювати там, де вони будуть використовувати Kubernetes.

— Jiri Klouda

Однією з причин використання Kubernetes як планувальника, якщо ви використовуєте Azure або вважаєте, що Azure є постачальником хмар, - це їх відносно нова послуга AKS (керована кубернета). У цьому випадку ви б не поєднували кубернети з роєм докера.

Це для мене є чіткою ознакою того, куди йде громада. Я не хотів би дізнатися щось, що мені пізніше потрібно буде викинути у сміттєвий контейнер.

— Кіт у чоботях
джерело