Чим відрізняється стручок від розгортання?


241

Я створював стручки з, type:deploymentале я бачу, що деяка документація використовує type:pod, точніше документацію для багатоконтейнерних стручків :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Але для створення стручків я можу просто використовувати тип розгортання :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Я помітив, що в документації про струк зазначається:

Команда create може бути використана для створення стручка безпосередньо, або він може створити стручок або стручки за допомогою розгортання. Настійно рекомендується використовувати для розробки майданчики Deployment. Він спостерігає за несправними стручками і запускатиме нові стручки, як потрібно, щоб підтримувати вказану кількість. Якщо ви не хочете, щоб розгортання контролювало ваш стручок (наприклад, ваш струк записує непостійні дані, які не переживуть перезавантаження, або ваш струк призначений дуже короткочасним), ви можете створити поділ безпосередньо за допомогою команда create.

Примітка. Для створення стручків рекомендується використовувати Deployment. Скористайтеся наведеними нижче інструкціями, лише якщо ви не хочете створити розгортання.

Але це ставить питання про те, що kind:podдобре? Чи можете ви якось посилатися на стручки в розгортанні? Я не бачив способу. Схоже, те, що ви отримуєте з стручками, є додатковими метаданими, але жоден із варіантів розгортання, наприклад, replicaабо політика перезавантаження. Яка користь у стручку, який не зберігає дані, переживає перезавантаження? Я думаю, що я міг би створити струмінь з декількома контейнерами і з розгортанням.

Відповіді:


190

І Pod, і Deployment - це повноцінні об'єкти в API Kubernetes. Розгортання управляє створенням Pods за допомогою ReplicaSets. Це зводиться до того, що розгортання створить Pods із специфікацією, взятою з шаблону. Навряд чи вам колись знадобиться створювати Pods безпосередньо для виробничого використання.


7
Дякую, але коли ти коли-небудь створював би стручки безпосередньо?
Бьорн

11
Налаштування користувальницького контролера - це один випадок, коли ви, ймовірно, хочете створювати та керувати стручками безпосередньо, замість того, щоб використовувати одну з абстракцій вищого рівня.
Аніруд Рамананат

24
@BjornTipling Я створюю стручки без розгортання, коли мені не потрібні кубернети, щоб знову створити стручки при видаленні. Один із випадків використання - це перевірити речі, створивши спочатку стручок.
користувач2526795

243

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

Оскільки вам потрібен об’єкт розгортання - або інші об’єкти API Kubernetes, наприклад контролер реплікації чи репліка -, який повинен підтримувати репліки (стручки) живими (це певний сенс використання кубернетів).

Що ви використовуєте на практиці для типового застосування, це:

  1. Об'єкт розгортання (де ви вкажете ваш контейнер / контейнери додатків), який розмістить контейнер вашого додатка з деякими іншими характеристиками.

  2. Об'єкт сервісу (це як об’єкт групування і надає йому так званий віртуальний IP (кластерний IP) для тих, podsякі мають певну мітку - і тихpods в основному, контейнери додатків, які ви розгорнули з колишнім об'єктом розгортання ).

Вам потрібно мати об’єкт обслуговування, оскільки об’єкт podsрозгортання може бути вбитий, зменшений вгору і вниз, і ви не можете покладатися на їхні IP адреси, оскільки вони не будуть стійкими.

Отже, вам потрібен такий предмет, як послуга , який дає podsїм стабільний IP.

Просто хотів дати вам деякий контекст pods, щоб ви знали, як все працює разом.

Сподіваюся, що для вас очищає кілька речей, не так давно я був у ваших черевиках :)


1
Хороша відповідь, чи потрібна нам реплікаSet або ReplicationController, оскільки я торкнувся, коли об’єкт Deployment обгортає ці об'єкти, керуючи репліками?
user_mda

3
так, об’єкт Deployment обробляє реплікацію, але ви також можете використовувати об’єкт з видом: ReplicationController або kind: ReplicaSet самостійно, якщо б ви цього дуже хотіли, але я на практиці цього ще не бачив ...
Томіслав Мікулін

2
Чому саме такі приклади подають кілька кубернетів kind: Pod? Наприклад, як споживати секрети як env vars: kubernetes.io/docs/concepts/configuration/secret/…
rm.rf.etc

1
Я не зовсім впевнений, можливо, тому що простіше пояснити поняття в k8 .. без надання ваги контролерам, розгортанням тощо ...
Томіслав Мікулін

1
Бувають випадки, коли ви хочете створити pod, наприклад, якщо ви користуєтеся тестовою коляскою (приклад helm test), коли вам не потрібно запускати додаток назавжди, і нам не потрібні кілька реплік, у такому випадку струк підходить.
Balkrishna

61

Kubernetes має три типи об'єктів, про які слід знати:

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

Стручки:

  • Запускає єдиний набір контейнерів
  • Підходить для разових цілей розробки
  • Рідко використовується безпосередньо у виробництві

Розгортання:

  • Працює набір однакових стручків
  • Моніторить стан кожного стручка, оновлюючи за необхідності
  • Добре для дев
  • Добре для виробництва

І я погодився б з іншими відповідями, забути про Pods і просто використовувати Deployment. Чому? Подивіться на другу точку кулі, вона відстежує стан кожного стручка, оновлюючи за необхідності.

Тож замість того, щоб боротися із повідомленнями про помилки, такими як це:

Заборонено: оновлення стручків можуть не змінювати поля, відмінні від spec.containers[*].image

Тому просто рефактор або повністю відтворіть свій Pod в розгортання, яке створює стручок, щоб робити все, що вам потрібно зробити. За допомогою розгортання ви можете змінити будь-яку частину конфігурації, яку ви хочете, і вам не потрібно турбуватися про те, щоб побачити це повідомлення про помилку.


9

Pod - це екземпляр контейнера.

введіть тут опис зображення

Це вихід replicas: 3

Подумайте, що один deploymentможе мати безліч запущених екземплярів (репліки).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Найкраща відповідь поки що. Інші відповіді зосереджуються на тому, щоб показати, наскільки розгортання є більш важливою концепцією, і що ви рідко використовуєте Pods для виробництва, але не вистачає чіткої інформації про те, як вони співвідносяться один з одним.
Дієго Квейроз

Тож чи можемо ми назвати стручок таким, як один із реплік розгортання?
кіорія

@kioria, що ви маєте на увазі під репліками розгортання?
серкан

@serkan Я маю на увазі цю репліку: 3 від специфікації розгортання.
кіорія

@kioria, replicas: 3посилання на верхню частину зображення. Це означає "ей, коли ви запустите цей процес, створіть 3 віртуальних / реальних комп'ютера - екземпляри". як "розгортання" - це дім, а "стручки" - це люди. Один будинок і три людини всередині нього, хто виконує роботу. Що ви намагаєтесь зробити конкретним для цього?
серкан

6

Pod - це сукупність контейнерів та основний предмет Kuberntes. Всі контейнери стручка лежать в одному вузлі.

  • Не підходить для виробництва
  • Немає постійних оновлень

Розгортання - це свого роду контролер у Кубернеті.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Розгортання створює ReplicaSet, який, у свою чергу, переконайтесь, що CurrentReplicas завжди такий самий, як і бажанийReplicas.

Переваги:

  • Ви можете розгорнути та відкати зміни, використовуючи розгортання
  • Моніторить стан кожного стручка
  • Найкраще підходить для виробництва
  • Підтримує прокатні оновлення

4

Я хочу додати інформацію з книги Kubernetes In Action , щоб ви могли побачити всю картину та з'єднати зв’язок між ресурсами Kubernetes, такими як Pod, Deployment та ReplicationController (ReplicaSet)

Стручки

є базовим розгортаючим підрозділом у Кубернетах. Але у реальних випадках використання ви хочете, щоб ваші розгортання автоматично працювали та залишалися здоровими без будь-якого вручного втручання. Для цього рекомендованим підходом є використання Deployment , який під кришкою створює ReplicaSet .

ReplicaSet , як випливає з назви, являє собою набір реплік (стручки) , підтримувані з їх переглядом історією.

(ReplicaSet розширює старіший об'єкт під назвою ReplicationController - точно такий же, але без історії перегляду.)

ReplicaSet постійно відстежує список запущених стручків і гарантує, що кількість запущених стручків, що відповідає певним специфікаціям, завжди відповідає бажаному номеру.

введіть тут опис зображення

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

розгортання

це ресурс вищого рівня, призначений для розгортання програм та їх оновлення декларативно.

Коли ви створюєте Deployment , під ним створюється ресурс ReplicaSet (з часом їх більше). ReplicaSets також копіює та керує стручками. При використанні розгортання, фактичні стручки створюються і управляються Deployment «S ReplicaSets , а не в розгортанні безпосередньо введіть тут опис зображення

Поміркуймо, що сталося. Змінивши шаблон шаблону у вашому ресурсі розгортання, ви оновили додаток до нової версії - змінивши одне поле!

введіть тут опис зображення

Нарешті, відкатуйте розгортання або до попередньої редакції, або до будь-якої попередньої версії, так легко за допомогою ресурсу розгортання.

Ці зображення також із книги Kubernetes In Action .


2

Постарайтеся уникати Pods і реалізуйте Розгортання замість управління контейнерами, оскільки об'єкти типу Pod не будуть перенесені (або самолікуються) у разі відмови вузла або припинення стручка.

Розгортання, як правило, є кращим, оскільки воно визначає ReplicaSet, щоб гарантувати, що потрібна кількість Pods завжди доступна, і визначає стратегію заміни Pods, наприклад RollingUpdate.


1

У кубернетах стручки - це найменші розгорнуті одиниці. Кожен раз, коли ми створюємо об’єкт кубернетів, як-от "Розгортання", "репліки-набори", "набір станів", "демон-набори", він створює струк.

Як було сказано вище, розгортання створюють стручки на основі бажаного стану, згаданого у вашому об'єкті розгортання. Так, наприклад, ви хочете 5 реплік програми, про які ви згадали replicas: 5в маніфесті розгортання. Тепер контролер розгортання несе відповідальність за створення 5 однакових реплік (не менше, не більше) даного додатку з усіма метаданими, такими як політика RBAC, мережева політика, мітки, анотації, перевірка стану здоров’я, квоти ресурсів, талант / допуски та ін. він творить.

Бувають випадки, коли ви хочете створити стручок, наприклад, якщо ви користуєтеся пробною коляскою, де вам не потрібно запускати програму назавжди, вам не потрібно кілька реплік, і ви запускаєте додаток, коли ви хочете виконати в цьому корпус стручка підходить. Наприклад helm test, це визначення стручка, яке вказує контейнер із заданою командою для запуску.

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