Чалды это что: Чалды для кофемашины — что это такое?

Чалды это что: Чалды для кофемашины — что это такое?

Чалды для кофемашины — что это такое?

Содержание:

Чалды – новое слово в искусстве наслаждения кофе
Что это такое чалды
Особенности кофе в чалдах
Преимущества кофе в чалдах
Палитра вкусов

Чалды – новое слово в искусстве наслаждения кофе

Сначала был просто кофе – ароматный и вкусный, но требующий очень уж больших затрат на приготовление. Обжарить, размолоть, сварить – колоссальное количество усилий ради одной чашечки к завтраку. Затем были изобретены кофемашины, и жизнь кофеманов стала легче. Но совершенству нет предела: кофейные аппараты усложнялись, технологии приготовления упрощались. После появления капсул для кофе следующим этапом стали чалды.

Что это такое чалды

Чалды – относительно новый продукт, изобретенный итальянцами, которые просто жить не могут без кофе, и уже признанный многими гурманами. По сути, таким уж новым он не является – идея позаимствована у одноразовых пакетиков с чаем.

Чалда – саше-фильтр, в который запрессована одна порция молотого кофе (средний вес – 7 граммов). Каждый бумажный конвертик помещен в герметичный пакетик из фольги, предохраняющий продукт от преждевременного расставания с ароматом. Более того, в металлизированную оболочку закачан инертный газ, что продлевает срок годности кофейной таблетки аж до двух лет. Для сравнения – молотый кофе быстро окисляется, а зерно через полторы-две недели после обжарки можно выбросить – достойного напитка из него не получить.

Особенности кофе в чалдах

В отличие от чайных фильтр-пакетов, чалды предназначены для использования в специальных чалдовых кофемашинах. Чалдовая кофемашина хоть и напоминает классическую рожковую кофеварку с некоторыми изменениями в конструкции, но процесс варки кофе в ней значительно менее трудоемок и более быстр. Неизменно превосходный результат достигается за счет строго выдержанного состава каждой чалды для кофемашины, качественной упаковки и почти полного отсутствия человеческого фактора при приготовлении ароматного напитка.

Многие рожковые кофемашины, например, кофемашины Elektra рассчитаны на приготовление кофе как из молотого сырья, так и с помощью чалдов.

Преимущества кофе в чалдах

Преимущества продукта основаны на нескольких характеристиках. Это и, как говорилось выше, четкие требования производителей к составу, и индивидуальная упаковка каждой порционной «таблетки». Можно быть уверенным, что приготовленные 100 чашек эспрессо из чалдов, входящих в одну партию, будут иметь идентичный вкус. Немаловажный фактор – цена. Чалдовый кофе значительно дешевле «капсульного» собрата, а результат — превосходный.

Палитра вкусов

Теперь о различиях. Основные различия чалдов заключаются в составе, количестве пакетов в коробке (чалдовый кофе продается в коробках), и, разумеется, в производителях.

Среди последних отличные позиции занимает итальянская марка Hausbrandt, предлагающая хороший ассортимент чалдового кофе, в котором каждый гурман наверняка найдет любимый вкус и аромат.

Хочется взбодриться утром? Подойдет плотный и насыщенный Hausbrandt Espresso, приготовленный из нескольких сортов арабики, или Hausbrandt Kenya AA Gourmet – кенийский кофе с насыщенным вкусом.

Сладкоежкам и любителям шоколадно-ореховых нот понравится бразильский Santos Gourmet, а табачным ценителям, сочетающим с чашечкой кофе сигару, – Guatemala Gourmet.

Hausbrandt предлагает и мягкий «вечерний» кофе – бескофеиновый Decaffeinato.

Кофе в чалдах – что это такое и как выбрать? 5 советов от эксперта

Кофе действует на человека магически. И сколько ни говорили о вредности кофеина, придающий бодрость напиток остается самым употребляемым в мире. Огромная индустрия обеспечивает десятками сортов зерен, чтобы человек мог насладиться палитрой кофейных оттенков. Основные виды кофе – арабика и робуста. Они отличаются по содержанию кофеина, аромату, вкусовым качествам. У арабики ярко выраженный вкус и интенсивный аромат, который зависит от сорта зерен и места произрастания кофейных деревьев. Робуста ценится за дубильные веществ, придающие горчинку и большое содержание кофеина, поднимающего настроение. Вкус зависит не только от сорта зерен, но и от умения приготовить напиток. Производители придумывают новые технологии, чтобы каждый мог сварить хороший кофе. Новинка на кофейном рынке – небольшие фильтр-пакеты с обжаренными перемолотыми зернами, которые называют чалдами за круглую форму, напоминающую таблетку.

Идеальная упаковка для кофе

В перфорированном бумажном пакетике находится 7-9 граммов спрессованного кофе. Это стандартная классическая порция напитка со сбалансированным вкусом. При смешивании разных сортов арабики и робусты купажисты создают удивительные вкусовые букеты. Смесь кофейных зерен подвергается обжарке, отстаивается несколько дней. После помола кофейный порошок сразу расфасовывается и спрессовывается в автомате. Чтобы сохранить вкус и запах кофе, готовые чалды упаковываются в фольгированные сашеты. Для приверженцев здорового образа жизни выпускаются пакетики с декофеинизированным кофе.

Фильтр-пакеты различных производителей отличаются плотностью бумаги, формой, диаметром. Чалды стандарта ESE выпускаются диаметром 44 мм. Внутри пакетика находится твердый спрессованный кофе в виде таблетки, который рекомендован для приготовления эспрессо. Пакет рассчитан на 30-60 мл воды. Следует учитывать это ограничение. При большем количестве воды бумага размокает, и таблетка разрушается. Чалды стандарта Senseo отличаются большим диаметром (от 55 мм до 62 мм), состоят из рыхлого кофейного порошка. Пакеты подходят для приготовления эспрессо, американо, лунго. Получается насыщенный напиток с плотной пенкой. За счет более прочной бумаги фильтры сохраняют прочность, через них можно пропустить до 150 мл воды.

Лучший способ для приготовления эспрессо

Таблетированный кофе создавался для ресторанов, кофеен, где важна точность порции и учет. Пакетики с молотыми обжаренными зернами оценили люди, которым не хватает времени, чтобы сварить настоящий качественный напиток. В офисах тоже переходят на чалдовый кофе. Он относительно недорого стоит, не отличается по вкусу от профессионально приготовленного эспрессо. Вкусовые свойства свежемолотого кофе ухудшаются через несколько дней. Герметичные сашеты сохранят вкус и аромат обжаренных и перемолотых зерен несколько месяцев. Чашечка бодрящего напитка готовится 20-30 секунд, за это время успевают экстрагироваться ароматические вещества и вкусовые компоненты, а вредные смолы остаются в фильтр-пакете с кофейной гущей. После удаления пакетика кофеварка сразу готова для приготовления следующей порции.

Производители используют кофейные зерна среднего и мелкого помола и разной степени обжарки. Кофе приобретает различные вкусовые оттенки благодаря натуральным ароматизаторам.

Почему выбирают кофе в чалдах:

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

Администрация заведений, которые перешли на кофе в чалдах, отмечает, что напиток по качеству не уступает эспрессо, приготовленному профессиональным бариста.

Какие кофемашины подходят для приготовления кофе в чалдах

Напиток можно готовить в специальных и рожковых кофеварках, оснащенных переходником для кофейных пакетиков.

Чалдовые кофеварки компактные, бесшумно работают, просты в применении. Фильтр-пакет закладывается в холдер, выбирается параметр приготовления и через 20-30 секунд душистый бодрящий напиток готов. После приготовления чалда легко удаляется, и можно готовить следующую порцию. Есть кофемашины, готовящие одновременно две чашки кофе. Для каждой кофеварки определенной торговой марки нужно выбирать фильтр-пакеты рекомендованные производителем. Чалды стандарта ESE применяются для кофемашин, отмеченных такой же маркировкой. Для кофеварок серии Senseo подходят кофейные пакеты диаметром 55 мм.

Советы от экспертов: как выбрать кофе в чалдах

Совет №1. Обратите внимание на место произрастания

Хорошие вкусовые качества у кофе из Коста-Рики, Гватемалы, Колумбии. Зерна из Гаити и Индии отличаются сладким привкусом. Бразильские сорта кофе имеют плотный вкус с кислыми нотками и стойкий мягкий аромат. Лучшие сорта арабики выращивают в Эфиопии. Из них получается напиток приятной крепости с легким шоколадным привкусом.

Чтобы не ошибиться с выбором, отдавайте предпочтение продукции известных компаний:

Удачное сочетание мягких бразильских, цветочных эфиопских, терпковатых индийских, сортов.

Мягкие и достаточно крепкий кофе с нежным шоколадным послевкусием и стойким ароматом.

Смесь из нескольких сортов высокогорной арабики.

Глубокий тонкий вкус достигается за счет уникального метода обжарки.

Отличный вариант для приготовления эспрессо (75% бразильской арабики и 25% альпийской робусты).

Совет №2. Особое внимание к степени помола

При покупке обращайте внимание на степень помола. Отличный кофе получается из зерен среднего помола. Порошок хорошо пропускает воду, подходит для рожковых и чалдовых кофеварок.

Чалды из зерен мелкого помола идеальны для приготовления эспрессо. За 30 секунд спрессованная таблетка отдает напитку весь вкус и аромат.

Совет №3. Не экономьте на качестве

Сварить хороший кофе можно из смеси арабики и робусты в соотношении 80% к 20%. Чем больше содержание робусты, тем дешевле чалды, но выше крепость напитка. Обращайте внимание на процентное содержание и выбирайте мягкий или горьковатый напиток с бодрящим эффектом.

Совет №4. Покупайте кофе в чалдах под тип кофеварки

Под стандарт ESE ориентированы кофемашины ТМ Nuova Simonelli, Delonghi, Innova, Saeco, Lavazza, Grimac. Мягкие фильтр-пакеты стандартов Senseo адаптированы к кофеваркам Severin, Philips Senseo, Di Maestri.

Сделайте свое утро приятным с пакетиком, содержащим идеальную порцию кофе, и почувствуйте себя профессиональным бариста. Большой ассортимент чалдового кофе Вы можете найти в нашем каталоге, а не ошибиться с выбором Вам помогут приведенные выше экспертные советы.

Кофе в чалдах — секреты чалдового кофе, полезные свойства и особенности приготовления

В последнее время нередко можно услышать про чалдовый кофе. Кто-то его попробовал или где-то его продают – все это частички витающих слухов. Впрочем, давайте вместе разберемся что это и какой у него вкус.

Чалда или монодоза – это вариант исполнения типовой упаковки для молотого кофе. Страна изобретатель – Италия. Целью создания чалд для кофе было стремление облегчить приготовление эспрессо у себя дома.

В итальянском языке «Cialda» и переводится, как «таблетка». Такое название очень точно характеризует внешний вид изделия. Нельзя не согласиться с тем, что внешне кофе в чалдах напоминает именно таблетку.

На практике же это строго выверенная формула изготовления продукта:

• Порция молотого кофе 7, а иногда 9 грамм.
• Спрессованная упаковка из фильтр-бумаги.

Чаще всего кофейные чалды дополнительно помещаются в упаковочную тару из крепкой фольги. Такая упаковка необходима для того, чтобы кофейный аромат не выветривался со временем. Под фольгу вкачивается углекислый газ, чтобы предохранить кофе от контакта с кислородом и последующим окислением продукта.

Разные виды такого кофе, тем не менее, фасуются стандартно – в одной упаковке находится от 18 до 100 «таблеток». Само же изобретение кофейных чалд было необходимо с целью стандартизации процесса приготовления напитка, а потому и диметр их стандартный – 55 или 44 мм.

Приготовить таблетированный кофе вы сможете, используя специализированные кофеварки и современные кофе-машины. Соответствующее оборудование выпускают все крупнейшие заводы бытовой техники.

Кстати, для кофемашины необходимо брать чалды того диаметра, который предусмотрен заводом изготовителем. Обязательно обращайте на это внимание при покупке – соответствующая маркировка нанесена на упаковку.

Преимущества таблетированного кофе

Давайте подчеркнем плюсы приготовления кофейного напитка в чалдах. Мы выделили наиболее значимые преимущества такого варианта приготовления кофе:

• Простой учет. Этот пункт важен преимущественно для предприятий и заведений общепита. Куда проще вести общий учет кофе не в граммах, а непосредственно в чалдах.
• Удобно готовить напиток. Нет необходимости чистить кофе-машину и отмерять порцию – с процессом приготовления кофе справится даже ребенок. К тому же очень удобно использовать таблетированный кофе тогда, когда у вас нет лишнего времени стоять у плиты с туркай.
• Универсальность. Одна порция – это идеально выверенные пропорции одного напитка. Вкус будет именно таким, каким его изначально задумали при производстве. К тому же сотрудникам кафе и баров это облегчает работу – кофе всегда будет готов при соблюдении идеальных пропорций вкуса и аромата.

Минусы чалдового кофе

Приготовление напитка в «таблетках» также имеет свои недостатки:

• Необходимость приобретения специальных кофе-машин. Без покупки обязательной техники чалды так и будут лежать без дела на кухонной полке.
• Однообразный вкус. Кофе может получаться у вас и вкусный, но дело в том, что каждая порция выверена по одному единственному рецепту. А потому каждая новая кружка напитка будет напоминать предыдущую.

Тем не менее, производители пытаются разнообразить ассортимент кофе, который фасуется в чалдах. Можно испробовать разные сорта и насладиться ароматом обновленного напитка.

В последнее время отмечается тенденция к переходу от чалдового к капсульному кофе. Особенности такого приготовления кофе ничем не отличаются от таблетированного заваривания. Советуем вам испробовать капсульную систему итальянского бренда Di Maestri (Димаэстри), чтобы вкусить по-настоящему изысканный и полезный кофе.

Какая лучше капсульная или рожковая кофеварка
Какая кофемашина лучше капсульная или зерновая
Что лучше капсульный кофе или кофе в турке
Как выбрать капсульную кофемашину
Как делают капсульный кофе
Как пользоваться капсульным кофе
Как заварить кофе без турки и кофеварки
Как чистить капсульные кофемашины
Капсульные кофемашины преимущества и недостатки
Как заварить кофе из капсул без кофемашины
Как пользоваться капсульной кофемашиной
Вреден ли капсульный кофе
Какая лучше капсульная или гейзерная кофеварка
Как работают капсульные кофемашины
Как чистить капсульные кофемашины
Какая лучше капсульная или обычная кофеварка
Капсульные кофемашины за и против
Капсульные кофемашины сравнение брендов
Состав кофе в капсулах
Что это такое кофе в капсулах
Лучший способ сохранить кофе
Многоразовые капсулы
Чем отличается кофе капучино от кофе латте
Чем отличается эспрессо от американо
Рецепт Раф-кофе
Сублимированный кофе
Рейтинг растворимого кофе
Вреден ли растворимый кофе
Польза и вред кофе с молоком
Рецепт кофе Мокачино
Калорийность кофе
Какая кофемолка лучше: ручная или электрическая
Как выбрать турку для кофе
Как правильно сварить кофе дома в турке на плите
Как правильно пить кофе
Как вхбить молочную пенку для кофе
Как заваривать кофе в френч-прессе
Запчасти для чемоданов
Как пользоваться гейзерной кофеварки
Пустые капсулы для кофемашины

Что такое чалды для кофеварки

Кофе – один из самых популярных напитков. Больше половины жителей планеты не представляют своего утра без чашки этого ароматного напитка. Поэтому многие предпочитают обзаводиться личной кофемашиной. Такой прибор помогает заварить кофе за считанные секунды. Одной из разновидностей таких агрегатов являются чалдовые кофеварки.

Что такое чалды

Чалдами называют особый тип упаковки молотого натурального кофе. Внешне они похожи на небольшие бумажные пакетики, которые выступают в роли фильтра. Как правило, их диаметр колеблется в пределах от 44 до 55 миллиметров в зависимости от модели кофеварки, для которой они предназначены.

Одна чалда предназначена для приготовления одной порции напитка. В нее помещается от 7 до 9 граммов кофе. Каждая из них упакована в фольгу. Это позволяет полностью сохранить аромат. В продаже чаще всего можно найти упаковки, в которых содержится от 18 до 100 таких пакетиков.

Преимущества и недостатки

Такой тип упаковки имеет ряд существенных преимуществ по сравнению с другими:

1. Чалды изготавливаются из бумаги. Этот материал является экологически чистым.
2. При соблюдении технологии приготовления кофе всегда будет иметь одинаковый аромат и вкусовые качества.
3. Отсутствие вредных химических примесей. Нет консервантов, эмульгаторов и прочих химикатов, которые нередко используются для получения характерной пенки.
4. Экономичность. Вы всегда знаете, сколько продукта использовали для одной чашки напитка и не превысите норму.
5. Благодаря тому, что чалды заполняются инертным газом, кофе в них полностью сохраняет свои вкусовые качества и аромат.

К недостаткам можно отнести ограниченный выбор сортов. Для определенной модели кофеварки вам удастся найти не более 10 разновидностей чалд. Такое неудобство может оказаться весьма существенным. Кроме того, вы каждый раз будете получать напиток с одним и тем же вкусом. А это со временем может наскучить. К тому же большинство экспертов отмечают недостаточный уровень качества сырья.

Нередко бывают случаи, когда необходимых вам сортов кофе нет даже в фирменных магазинах. Такое обстоятельство многих удерживает от покупки чалдовой кофеварки.

Какой кофе упаковывают в чалды

Чаще всего в чалдах используются смеси из нескольких сортов кофе. Сегодня можно найти также экземпляры с добавлением шоколада, орехов, сливок или карамели. Выпускаются следующие виды такого продукта:

Способ изготовления

Современные предприятия изготавливают чалды с применением достаточно сложной технологии. Она предусматривает следующие этапы:

1. Приготовление кофейной смеси. Для нее используются исключительно отборные зерна. Их тщательно обжаривают в специальных печах.
2. Обжаренные зерна выдерживают несколько дней. При этом создаются особые условия для того, чтобы в них запустились химические реакции.  Только после этого зерна можно будет перемалывать.
3. Кофейный порошок спрессовывают в специализированном автомате. Весь процесс их прессования и упаковки в бумажные пакетики занимает не более 20 секунд. Затем чалды помещаются в индивидуальную фольгированную упаковку, куда закачивается инертный газ, позволяющий предотвратить кофе от порчи.
4. Останется только упаковать определенное количество готовых чалд в большую упаковку и запустить в продажу.

Чалдовая кофеварка — принцип работы, плюсы и минусы

Такие кофеварки полностью автоматизированы. Вам достаточно будет поместить чалду в специально предназначенный для этого отсек и включить прибор. Все оставшиеся действия машина выполнит самостоятельно.

Принцип работы чалдовой кофеварки схож с другими типами агрегатов. Нагретая до определенной температуры вода пропускается сквозь молотый кофе. При этом создается достаточно большое давление. И получается ароматный напиток, который через специальный желоб выливается в чашку. Вся процедура приготовления такого кофе занимает не больше пары минут.

Более дорогие кофеварки могут иметь несколько режимов приготовления. Благодаря этому вы сможете приготовить не только привычный эспрессо, но и другие напитки.

Явным преимуществом таких агрегатов становится высокая скорость приготовления кофе. Приготовить чашку ароматного напитка можно за минуту. При этом вам не понадобится совершать никаких особых действий. Машина все сделает самостоятельно. Вы можете быть уверены в том, что всегда будете получать одинаково вкусный кофе.

Среди недостатков таких машин можно выделить достаточно высокую стоимость прибора.

Чалдовые кофеварки появились у нас относительно недавно. Поэтому могут возникнуть проблемы с приобретением расходных материалов к ней.

Если вы не любите экспериментировать с различными сортами кофе и хотите быстро получать чашку ароматного напитка, то чалдовая коферка станет для вас идеальным вариантом.

Советуем также почитать, что представляет собой капсульный кофе.

фото: depositphotos.com/AntonioGravante, marischka

Применение чалды для кофемашины Senseo, Philips, Delonghi

Постепенно на смену стандартным методам заваривания кофе и его форматам приходят новые. Один из них – чалды. Это специальные «таблетки», в которых содержится спрессованный молотый кофе. Рассмотрим подробно, что такое чалды для кофемашины на фото, как применяются.

Что такое чалды?

Упаковка и использование

Кофе для кофемашины в чалдах – это молотые зерна разных сортов, упакованных в специальный фильтр. Как выглядят, можно посмотреть на фото. Подходят чалды для кофемашины Philips Senseo, а также Delonghi и других аппаратов «чалдового» типа.

Заваривать кофе таким образом проще простого. Может, потому данный способ получения напитка считается «ленивым». Итак, чтобы получить ароматную «чашку», в специальный отсек кладется кофе в чалдах для кофемашины Philips Senseo или другой марки. В бойлер заливается вода и устанавливается нужный режим (если это предусмотрено машиной). Буквально через 20 секунд в чашку льется ароматный и крепкий кофе. После того как чалды Senseo для кофемашины использованы, они удаляются. В принципе, данную процедуру, за исключением необходимости задействования аппарата, можно сравнить с «чайными пакетиками». Разница в формате. Чалда, как правило, круглая и имеет небольшой хвостик, чтобы ее было удобно брать после использования.

Плюсы

Теперь посмотрим, что же такое в чалдах и почему они выгоднее, чем капсулы. Все их плюсы и особенности сводятся к нюансам приготовления кофе. Вкус напитка зависит от сорта кофе или той смеси, которая входит в состав фильтр-пакета. Итак, преимуществами чалд можно назвать:

1. Ассортимент. Производители стремятся постоянно расширять границы вкусовых единиц.
2. Универсальность. Диски одной марки в большинстве случаев подходят к машине другой. Так, например, можно легко использовать чалды Senseo для кофемашины иного производителя.
3. Экономия. Цена кофе в чалдах, в сравнении с капсулами, будет значительно ниже.
4. Качество. Напиток из кофемашины с чалдами не отличается от профессионального заваривания.
5. Простота. Не нужно особых умений и навыков, чтобы приготовить с помощью Philips Senseo прекрасный кофе.
6. Гигиенично. Чистка машины займет очень мало времени и усилий. Все потому, что после использования чалда выбрасывается, а отсек всполаскивается проточной водой.

Вообще, если не учитывать необходимость наличия кофемашины, процедура приготовления в чалдах похожа с приготовлением растворимого кофе. Но это только по времени. По качеству кофе в таких кофемашинах получается на высшем уровне, не хуже, чем у профессиональных баристов.

Выбор

Что такое чалды, мы определили, теперь стоит разобраться, как их выбрать. Они, как правило, выбираются в зависимости от личных предпочтений. Например, производители предлагают на выбор:

• эспрессо;
• мокаччино;
• ванилочино;
• чокочино.

Одним словом, кофе из чалдовых кофемашин надоест не скоро. Ведь всегда можно приобрести новый пакетик и узнать новый вкус. Более того, в таких кофемашинах можно заваривать и чай.

Нестандартное использование

Самое интересное, что некоторые чалды можно использовать для рожковой кофеварки. Диаметр отсека рожка в большинстве случаев сходен с диаметром чалд, потому их можно для разнообразия взять для рожковой кофеварки. Однако нужно, чтобы действительно совпали параметры размеров рожка и чалды. Но, естественно, лучше приобрести подходящую технику. Тем более что кофемашины с чалдовой системой работают быстрее в приготовлении, чем кофеварки.

В заключение остается сказать пару слов еще раз о выборе и вкусе кофе. Лучше всего обратиться к поставщику или продавцу, взять карту вкуса, которая обычно предлагается производителям. В ней расписываются все тонкости каждой чалды, что позволяет лучше выбрать напиток по своему предпочтению.

Кофе в чалдах (таблетках): понятие, марки и приготовление

Чалды – это одноразовые пакетики из фильтровальной бумаги, содержащие молотый кофе: прессованный или рассыпной. Из одной чалды получается одна порция напитка. Для приготовления кофе используют специальные чалдовые кофеварки. Также многие производители выпускают «гибридные» рожковые кофеварки, в которые можно как засыпать свежесмолотый кофе, так и закладывать чалды.

История изобретения чалд

Порой даже у бариста, особенно при большом наплыве посетителей, возникают трудности с приготовлением эспрессо: то плохо настроена кофемолка, то стажёр никак не научится правильно утрамбовывать кофе в холдере. В 70-е годы XX века на эти проблемы обратили внимание специалисты известной итальянской компании Illycaffe.

Разработку новой технологии кофеварения возглавил лично глава фирмы, доктор Эрнесто Илли. Уже в 1974 году под торговой маркой Illy был выпущен первый кофе в чалдах. Своё название они получили из-за сходства с крохотными вафлями (по-итальянски «вафля» – cialda). У нас чалды иногда называют таблетками (не путать с капсулами). В 90-е годы XX века стандарт E. S.E. (Easy Serving Espresso), созданный компанией Illycaffe для чалд, стал межотраслевым.

Кофе в чалдах придумали в компании Илли

Производство чалд

Как известно, кофейные зёрна премиум-класса продают целыми. Содержимое чалд делают из зёрен того же качества, что и фасованный молотый кофе. Сырые зёрна заранее обжаривают, а через 1–2 дня мелют.

Измельчённый кофе расфасовывают в бумажные пакетики (если нужно, прессуют). Кофейные таблетки круглые, но пакетики могут быть квадратными или иметь форму лепестка. В одной чалде – 7–9 г кофе (в зависимости от производителя).

После измельчения контакт с воздухом длится всего 20–30 секунд, поэтому кофе не теряет аромата. Бумажные пакетики с кофе укладывают в герметичные конверты из трёхслойной плёнки, где средний слой сделан из алюминия. Чтобы не улетучились ароматические вещества, кофе консервируют при помощи углекислого газа или азота.

В упаковке из металлизированной плёнки кофе сохраняет вкус и аромат в течение 2 лет. Качественный чалдовый кофе не содержит эмульгаторов для образования пенки. Производители могут вводить в состав содержимого чалд различные добавки, к примеру, со вкусом орехов, шоколада, карамели, сливок или ванили.

Типы чалд

В продаже есть чалды 3 типов:

• ESE – самый популярный стандарт. Внутренний диаметр таблетки – 44 мм, наружный – не более 55 мм. Толщина таблетки – 10 мм, но у некоторых производителей может быть и больше. Таблетка спрессована, поэтому чалды ESE идеально подходят для приготовления эспрессо. Стандарт ESE поддерживают кофеварки Lavazza, FrancisFrancis, Innova, Nuova Simonelli, Krups, DeLonghi, Saeco, Grimac;
• 1-2-3 Spresso – чалды с квадратной манжетой и внутренним диаметром таблетки 40 мм, таблетка – прессованная. Предназначены для кофеварок и кофемашин Malongo, Melitta, Salton. Зачастую возникают трудности с покупкой чалдов этого типа;
• Senseo – мягкие чалды, содержащие рассыпчатый молотый кофе. Используются в кофеварках Philips Senseo, Severin, Di Maestri. Кофе из мягких чалдов получается менее крепким, чем из прессованных.

Как правильно выбрать чалды с кофе

Чалдовые и «гибридные» кофеварки рассчитаны на определённый внутренний диаметр таблеток. При покупке кофе нужно проверять, соответствует ли тип чалд стандарту, который поддерживает кофеварка.

На упаковке всегда указано, из каких сортов кофе (арабики или робусты) состоит содержимое пакетика, степень обжарки и помола. Чем больше в кофейной смеси робусты – тем крепче будет кофе.

Поскольку таблетки обычно используют для приготовления эспрессо, то кофе чаще всего подвергают средней обжарке и мелют тонко (но не в пыль). В чалдах, предназначенных для заваривания лунго, помол крупнее.

Приготовление чалдового кофе

Инструкция:

1. Подключить кофеварку или кофемашину к сети.
2. Положить чалду в фильтродержатель.
3. Зафиксировать фильтродержатель.
4. Поставить прогретую чашку в лоток.
5. Включить кофеварку.

Преимущества и недостатки чалд

Преимущества:

• простота приготовления;
• благодаря герметичной упаковке кофе пахнет, как свежесмолотый;
• можно покупать чалды разных производителей, главное – чтобы тип таблетки подходил для кофеварки;
• при использовании таблеток одной марки качество и вкус кофе остаются неизменными;
• кофе в чалдах стоит дешевле, чем в капсулах;
• фильтровальная бумага пакетиков более экологична, чем пластик, из которого изготавливают капсулы;
• если чалдовая кофемашина установлена в баре, гораздо проще вести учёт израсходованного кофе;
• гигиеничность: выбросить использованный пакетик удобнее, чем влажную, рассыпающуюся гущу, особенно в условиях офиса;
• фильтродержатель не нужно отмывать от гущи.

Недостатки:

• кофе в чалдах стоит дороже молотого;
• сложно изменить вкус или крепость кофе, для этого придётся подыскать другую марку;
• при производстве кофе в чалдах не используют зёрна премиум-класса, поэтому гурманам не стоит рассчитывать на особо оригинальный вкус.

Иногда чалдовую кофеварку приобретают домой только потому, что она стоит достаточно дёшево. Но следует учитывать, что таблетки дороже обычного кофе, и уже через 1–2 года экономия обернётся убытками.

Когда нет времени, можно приготовить кофе в чалдах. Но рано или поздно захочется поэкспериментировать со вкусом любимого напитка. Чтобы впоследствии не пришлось покупать вторую кофеварку, лучше сразу присмотреться к «гибридным» рожковым моделям, для которых подходит и рассыпной молотый кофе, и чалды.

Известные марки чалд

Illy – кофе в чалдах стандарта ESE. В составе блендов – качественная высокогорная арабика.

Buscaglione – большой выбор смесей, состоящих из индийских, эфиопских, бразильских сортов арабики и робусты. В ассортименте есть декофеинизированный кофе.

Lavazza – вкус кофе рассчитан на итальянских потребителей: тёмная обжарка, повышенная крепость (в смесях – 15–20% робусты), шоколадный привкус.

Bristot – крепкий кофе с высоким содержанием робусты (до 25%).

Автор статьи:

руководитель проекта, автор статей и главный редактор

что это такое, виды, достоинства и недостатки

Приготовление кофе всегда считалось искусством. Существует масса способов приготовления этого волшебного напитка. Стремление людей облегчить и упростить процесс приготовления кофе, привело к созданию кофейных аппаратов. С каждым годом приготовление напитка в кофемашинах становилось всё проще. Последней новинкой в этой области стало появление чалдов.

Используя чалды, можно быстро приготовить кофе, который по вкусу ни в чём не уступает напитку, приготовленному в турке. При этом процесс приготовления кофе сведён к двум простейшим действиям: положить чалду в машину и включить её. О том, что же всё-таки это такое: чалды для кофемашины, подробно изложено в этой статье.

Что такое чалды для кофемашины?

Появление чалдовых кофемашин

Чалды впервые появились в Италии. В переводе с итальянского «чалда» обозначает «вафля». Чалда внешне напоминает большую таблетку. По сути, это небольшое количество спрессованного натурального молотого кофе, упакованное в бумажный пакетик дискообразной формы. Из одного такого пакета получается порция эспрессо. Для изготовления чалд применяют специальную перфорированную особым образом бумагу. Несколько слоёв такой вафельной бумаги по всей видимости и дали название этим изделиям.

Изначально чалдовые кофеварки задумывались в помощь профессиональным бариста. Но затем стали применяться и в домашних условиях. Особенно популярными чалдовые кофеварки стали в офисах.

Процесс изготовления чалд

Технология изготовления чалд достаточно сложная. Прежде чем, упаковать кофейные зёрна в пакетик, они проходят несколько этапов подготовки.

• Отбирают качественные зёрна.
• Для улучшения вкуса смешивают зёрна нескольких сортов.
• Зёрна подвергают обжарке, при этом степень обжарки отличается для разных чалд.
• После обжарки зёрна должны полежать на открытом воздухе для взаимодействия с ним для получения соответствующего аромата.
• Затем зёрна пропускают через кофемолку, добиваясь получения порошкообразного состояния.
• Порцию кофейного порошка помещают в пакетик из металлической фольги, одновременно закачивая в него углекислый газ, играющего роль консерванта.

Очень важна скорость герметизации пакетика. Это нужно сделать за несколько секунд. Именно от быстроты и качества запайки по большей части зависит аромат сваренного из чалда кофе.

Размеры чалд стандартизованы для разных моделей кофемашин. Стандарт E.S.E. предполагает выпуск 7-граммовых чалд диаметром 44 мм. Чалды, изготовленные по стандарту Senseo имеют вес 9 граммов и диаметр 55 мм. В первом случае одну порцию кофе получают, используя 60 г воды. Во втором случае для приготовления напитка используют 150 г воды.

Чалды продаются в жестяных или картонных упаковках, в которых содержится до 100 чалд. В запакованном состоянии чалды хранятся до 2 лет без ущерба для вкусовых качеств.

Виды кофе в чалдах

Производители используют вкусовые добавки для получения соответствующего вкуса. Потребители могут выбрать напиток со вкусом шоколада, ванили или карамели. На вкус напитка влияет степень обжарки зёрен. Различают кофе средней или высокой степени обжарки.

Сегодня стали популярными наборы чалдов с различными комбинациями вкусовых добавок. Это даёт возможность людям продегустировать различные ароматы и выбрать наиболее подходящий.

Для определённой категории людей выпускаются чалды без кофеина. Производители в таких случаях в качестве замены предлагают потребителям различные фруктовые ароматы.

Наибольшую популярность получили чалды от следующих производителей.

• Фирма Italco Concerto выпускает чалды, из которых получается великолепный капучино с ароматом фундука.
• Компания Buscaglione Long предлагает употреблять американо с пикантной горчинкой.
• Для любителей эспрессо подойдут чалды фирмы Italco Assolo.
• Шоколадный вкус имеет кофе фирмы San Giusto.
• Красивая пенка образуется в чашке крепчайшего кофе компании ILLY Espresso.
• Знаменитый бренд Lavazza выпускает шоколадный кофе с мягким послевкусием.

Уже сейчас для каждой модели чалдовой кофемашины можно приобрести до 20 сортов кофейного напитка. Но производители продолжают экспериментировать и радуют любителей кофе всё новыми сортами этого популярного напитка.

Как правильно выбрать чалды

Качество напитка, приготовленного в чалдовой кофеварке, зависит от происхождения кофе. Кофейные зёрна, выращенные в разных странах мира, различаются по вкусовым качествам.

Специалисты считают, что самый лучше кофе делают в Эфиопии. Кофейные зёрна из Колумбии почти не отличаются от эфиопских сортов. А вот кофе, привезённое из Гаити, имеет ярко выраженный сладковатый вкус. Впрочем, мнение специалистов не имеет значения для любителей того или иного кофе.

На качество приготовленного кофе влияет степень помола кофейных зёрен. Наибольшей популярностью пользуется кофе среднего помола.

Содержание зёрен робусты в кофе является ключевым показателем качества напитка. Содержание этого сорта кофейных зёрен до 20% считается оптимальным. Более высокое содержание робусты приводит к снижению качества напитка.

Выбрать чалды для своей кофемашины просто. Надо изучить прилагаемую инструкцию и определить какие чалды можно использовать в этой модели. Не следует покупать другие чалды. Это приводит к снижению качества приготовленного напитка или к неисправности машины.

Кофемашины для чалдов

Качественные аппараты для приготовления кофе в чалдах выпускают три компании: знаменитый Philips, Severin и WMF AG.

Эксперты утверждают, что качество кофейного напитка, приготовленного в чалдовых кофеварках, ничем не отличается от кофе, приготовленного традиционным способом. Любители кофе называют единственным недостатком кофемашин невозможность вмешаться в процесс приготовления с целью регулировки крепости напитка. Но представители компаний, производящих такие устройства, считают, что крепость напитка регулируется приобретением чалда с кофе нужной крепости.

Строго говоря, крепость напитка формируется скоростью прохождения воды через чалд. Так как чалд по сути является фильтром, то имеется возможность регулировать скорость прохождения воды через него. Это достигается подбором плотности бумаги пакетика, в который помещён кофейный порошок. Очевидно, что чем плотнее бумага, тем медленнее вода будет просачиваться через неё, и тем крепче будет напиток. Если потребитель желает пить крепкий кофе, то ему следует просто покупать чалды в более плотной бумаге.

Достоинства и недостатки

Как и все механизмы, чалдовые кофемашины имеют свои отрицательные и положительные стороны. В качестве преимуществ потребители называют следующие свойства этих кофеварок.

• Напиток, приготовленный с применением чалдов, всегда отличается хорошим вкусом, так как в чалдах кофе практически не портится.
• Использовать чалды гораздо экономнее, чем заваривать традиционным способом.
• Производители гарантируют применение в чалдах только натуральных продуктов, что исключает присутствие в кофе вредных химических веществ.
• Материалы, из которых изготовлены чалды являются экологически чистыми.
• Простота и удобство эксплуатации чалдовых кофемашин.
• Кофе из чалдов получается очень быстро.

К отрицательным сторонам применения таких механизмов можно отнести следующее:

• Невозможно визуально проконтролировать качество кофе в чалдах, это приводит к злоупотреблениям со стороны производителей.
• Ассортимент чалдов с разным кофе несколько ограничен.
• Крепость напитка регулируется только в момент изготовления чалдов.
• Стоимость чалдовых машин достаточно велика по сравнению с традиционными кофеварочными агрегатами.

Технология приготовления кофе в чалдовых машинах

Принцип работы таких агрегатов очень прост и понятен любому.

Воду подогревают до соответствующей температуры. Затем она под давлением пропускается через чалд, насыщаясь вкусом и ароматом порошкообразной смеси кофейных зёрен, помещённой в этот пакетик. Уже готовый кофе наливается в чашку. Весь процесс происходит за 30 секунд. После завершения процесса использованная чалда извлекается из машины и выбрасывается. Повторное использование чалды запрещается.

Есть модели кофемашин, способные приготовить две чашки одновременно.

После извлечения использованной чалды не требуется производить какую-либо очистку. Просто закладывается новый чалд и процесс приготовления кофе повторяется вновь.

Покупать или не покупать чалдовую кофемашину – в любом случае решает потребитель. Но, то что кофе, приготовленный в таких машинах получается качественным, а процесс приготовления занимает намного меньше времени – бесспорно!

Бытовая техника Кофемашина

капсул | Kubernetes

Pods — это самые маленькие развертываемые вычислительные единицы, которые вы можете создавать и управлять в Kubernetes.

A Под (например, стая китов или стручок гороха) — это группа из одного или нескольких
контейнеры с общим хранилищем и сетевыми ресурсами, а также спецификацию того, как запускать контейнеры. Содержимое модуля всегда совмещено и
совместно запланированы и выполняются в общем контексте. Стручок моделирует
зависящий от приложения «логический хост»: он содержит одно или несколько приложений
контейнеры, которые относительно плотно соединены.В не облачных контекстах приложения, выполняемые на одной физической или виртуальной машине, аналогичны облачным приложениям, выполняемым на том же логическом хосте.

Помимо контейнеров приложений, Pod может содержать
контейнеры инициализации, которые запускаются
во время запуска Pod. Вы также можете ввести
эфемерные контейнеры
для отладки, если это есть в вашем кластере.

Что такое стручок?

Примечание: Хотя Kubernetes поддерживает больше
время выполнения контейнера
чем просто Docker, Docker является наиболее известным
runtime, и это помогает описывать поды, используя некоторую терминологию из Docker.

Общий контекст Pod — это набор пространств имен Linux, контрольных групп и
потенциально другие аспекты изоляции — то же самое, что изолирует Docker
контейнер. В контексте модуля отдельные приложения могут иметь
применена дополнительная изоляция.

С точки зрения концепции Docker, Pod похож на группу контейнеров Docker.
с общими пространствами имен и общими томами файловой системы.

Использование модулей

Обычно вам не нужно создавать модули напрямую, даже одноэлементные модули.Вместо этого создайте их, используя ресурсы рабочей нагрузки, такие как «Развертывание» или «Задание».
Если вашим модулям необходимо отслеживать состояние, рассмотрите
Ресурс StatefulSet.

Подов в кластере Kubernetes используются два основных способа:

• Подов, которые запускают один контейнер . Модель «один контейнер на контейнер» — это
  наиболее распространенный вариант использования Kubernetes; в этом случае вы можете думать о Pod как о
  обертка вокруг единого контейнера; Kubernetes управляет подами, а не управляет
  контейнеры напрямую.

• Модули, запускающие несколько контейнеров, которые должны работать вместе . Стручок может
  инкапсулировать приложение, состоящее из нескольких совместно размещенных контейнеров, которые
  тесно связаны и нуждаются в совместном использовании ресурсов. Эти совмещенные контейнеры
  сформировать единую связную единицу обслуживания — например, один контейнер, обслуживающий данные
  хранится в общем томе для публики, в то время как отдельный контейнер с коляской
  обновляет или обновляет эти файлы.
  Pod обертывает эти контейнеры, ресурсы хранения и эфемерную сеть.
  идентичность вместе как единое целое.

  Примечание. Группировка нескольких совместно размещенных и совместно управляемых контейнеров в одном модуле является
  относительно продвинутый вариант использования. Вы должны использовать этот шаблон только в определенных
  случаи, когда ваши контейнеры тесно связаны.

Каждый Pod предназначен для запуска одного экземпляра данного приложения. Если хотите
масштабируйте приложение по горизонтали (чтобы предоставить больше общих ресурсов, запустив
больше экземпляров) следует использовать несколько модулей, по одному для каждого экземпляра.В
Kubernetes, это обычно называется репликацией .
Реплицированные поды обычно создаются и управляются как группа с помощью ресурса рабочей нагрузки.
и его контроллер.

См. Модули и контроллеры для получения дополнительной информации о том, как
Kubernetes использует ресурсы рабочей нагрузки и их контроллеры для реализации приложения.
масштабирование и самовосстановление.

Как поды управляют несколькими контейнерами

Поды предназначены для поддержки нескольких взаимодействующих процессов (как контейнеров), которые образуют
сплоченная единица обслуживания.Контейнеры в Pod автоматически совмещаются и
совместное планирование на одной физической или виртуальной машине в кластере. Контейнеры
могут обмениваться ресурсами и зависимостями, общаться друг с другом и координировать
когда и как они прекращаются.

Например, у вас может быть контейнер,
выступает в качестве веб-сервера для файлов в общем томе и отдельного контейнера «sidecar»
который обновляет эти файлы из удаленного источника, как показано на следующей диаграмме:

Некоторые модули имеют контейнеры инициализации, а также контейнеры приложений.Контейнеры инициализации запускаются и завершаются до запуска контейнеров приложений.

Поды изначально предоставляют два типа общих ресурсов для составляющих их контейнеров:
сети и хранилище.

Работа с подами

Вы редко будете создавать отдельные поды непосредственно в Kubernetes — даже одноэлементные поды. Этот
потому что Pod’ы спроектированы как относительно эфемерные одноразовые объекты. Когда
под создается (непосредственно вами или косвенно
контроллер), новый Pod
запланирован для запуска на узле в вашем кластере.Pod остается на этом узле до тех пор, пока Pod не завершит выполнение, объект Pod не будет удален,
Pod выселен из-за нехватки ресурсов, или узел выходит из строя.

Примечание. Перезапуск контейнера в модуле не следует путать с перезапуском модуля. Стручок
это не процесс, а среда для запуска контейнера (ов). Стручок сохраняется до тех пор, пока
он удален.

При создании манифеста для объекта Pod убедитесь, что указанное имя является допустимым.
Имя поддомена DNS.

Модули и контроллеры

Вы можете использовать ресурсы рабочей нагрузки для создания и управления несколькими модулями за вас. Контроллер
для ресурса обрабатывает репликацию и развертывание, а также автоматическое лечение в случае
Отказ стручка. Например, если узел выходит из строя, контроллер замечает, что модули на этом
Узел перестал работать и создает замену Pod. Планировщик помещает
замена Pod на исправный Node.

Вот несколько примеров ресурсов рабочей нагрузки, которые управляют одним или несколькими модулями:

Шаблоны модулей

Контроллеры для ресурсов рабочей нагрузки создают модули
из шаблона модуля и управляйте этими модулями от вашего имени.

PodTemplates — это спецификации для создания модулей, которые включены в ресурсы рабочей нагрузки, такие как
Развертывания,
Вакансии и
DaemonSets.

Каждый контроллер для ресурса рабочей нагрузки использует PodTemplate внутри рабочей нагрузки
объект для создания настоящих стручков. PodTemplate является частью желаемого состояния любого
ресурс рабочей нагрузки, который вы использовали для запуска своего приложения.

Пример ниже представляет собой манифест для простого задания с шаблоном , который запускает его.
контейнер.Контейнер в этом модуле печатает сообщение, а затем приостанавливает его.

  apiVersion: batch / v1
вид: Работа
метаданные:
  имя: привет
спецификация:
  шаблон:
    # Это шаблон пакета
    спецификация:
      контейнеры:
      - имя: привет
        изображение: busybox
        команда: ['sh', '-c', 'echo "Привет, Kubernetes!" && спать 3600 ']
      restartPolicy: OnFailure
    # На этом шаблон пакета заканчивается
  

Изменение шаблона модуля или переключение на новый шаблон модуля не имеет прямого эффекта
на уже существующих модулях.Если вы измените шаблон модуля для рабочей нагрузки
ресурс, этот ресурс должен создать заменяющие модули, использующие обновленный шаблон.

Например, контроллер StatefulSet гарантирует, что запущенные модули соответствуют текущему
шаблон модуля для каждого объекта StatefulSet. Если вы отредактируете StatefulSet, чтобы изменить его модуль
template, StatefulSet начинает создавать новые модули на основе обновленного шаблона.
В конце концов, все старые модули заменяются новыми, и обновление завершается.

Каждый ресурс рабочей нагрузки реализует свои собственные правила для обработки изменений в шаблоне Pod.Если вы хотите узнать больше о StatefulSet, прочтите
Стратегия обновления в руководстве по основам StatefulSet.

На узлах кубелет не работает
непосредственно наблюдать или управлять любыми деталями, связанными с шаблонами и обновлениями модулей; те
детали абстрагированы. Эта абстракция и разделение проблем упрощают
семантики системы, и позволяет расширить поведение кластера без
изменение существующего кода.

Обновление и замена Pod

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

Kubernetes не мешает вам напрямую управлять подами. Возможно
обновить некоторые поля работающего модуля на месте. Однако операции обновления Pod
нравиться
патч и
заменяет
имеют некоторые ограничения:

• Большинство метаданных о Pod неизменяемо. Например, вы не можете
  измените пространство имен , name , uid или creationTimestamp полей;
  Поле поколения уникально.Он принимает только обновления, которые увеличивают
  текущее значение поля.

• Если установлен metadata.deletionTimestamp , новая запись не может быть добавлена ​​в
  metadata.finalizers list.

• Обновления модуля не могут изменять поля, кроме spec.containers [*]. Image ,
  spec.initContainers [*]. Image , spec.activeDeadlineSeconds или
  спец. Допуски . Для spec.tolerations вы можете только добавлять новые записи.

• При обновлении поля spec.activeDeadlineSeconds , два типа обновлений
  разрешены:

  1. установка неназначенного поля на положительное число;
  2. обновление поля с положительного числа на меньшее неотрицательное
     количество.

Совместное использование ресурсов и обмен данными

Модули обеспечивают совместное использование данных и обмен данными между их составляющими
контейнеры.

Хранилище в модулях

Модуль может указывать набор общего хранилища
тома.Все контейнеры
в Pod может получить доступ к общим томам, позволяя этим контейнерам
делиться данными. Тома также позволяют постоянным данным в поде выжить.
на случай, если необходимо перезапустить один из контейнеров внутри. Видеть
Хранилище для получения дополнительной информации о том, как
Kubernetes реализует общее хранилище и делает его доступным для модулей.

Сеть модулей

Каждому модулю назначается уникальный IP-адрес для каждого семейства адресов. Каждый
контейнер в Pod разделяет сетевое пространство имен, включая IP-адрес и
сетевые порты.Внутри Pod (а тогда только ) контейнеры, принадлежащие Pod
могут общаться друг с другом, используя localhost . Когда контейнеры в поде общаются
с объектами за пределами Pod ,
они должны координировать использование общих сетевых ресурсов (например, портов).
Внутри модуля контейнеры совместно используют IP-адрес и пространство портов, а также
могут найти друг друга через localhost . Контейнеры в Pod также могут обмениваться данными
друг с другом, используя стандартные межпроцессные коммуникации, такие как семафоры SystemV
или разделяемая память POSIX.Контейнеры в разных модулях имеют разные IP-адреса.
и не может общаться по IPC без
особая конфигурация.
Контейнеры, которые хотят взаимодействовать с контейнером, запущенным в другом поде, могут
использовать IP-сеть для связи.

Контейнеры в модуле видят, что имя хоста системы совпадает с настроенным
имя для Pod. Подробнее об этом в сети
раздел.

Привилегированный режим для контейнеров

Любой контейнер в Pod может включить привилегированный режим, используя флаг привилегированного в контексте безопасности спецификации контейнера.Это полезно для контейнеров, которые хотят использовать административные возможности операционной системы, такие как управление сетевым стеком или доступ к аппаратным устройствам.
Процессы в привилегированном контейнере получают почти те же привилегии, которые доступны процессам вне контейнера.

Примечание: Ваша среда выполнения контейнера должна поддерживать концепцию привилегированного контейнера, чтобы этот параметр был актуальным.

Статические модули

Статические модули управляются непосредственно демоном kubelet на определенном узле,
без сервера API
наблюдая за ними.В то время как большинство модулей управляются плоскостью управления (например,
Развертывание), для статического
Модули, кубелет непосредственно контролирует каждый статический модуль (и перезапускает его в случае сбоя).

Статические поды всегда привязаны к одному кубелету на определенном узле.
Основное использование статических модулей — запуск автономной плоскости управления: другими словами,
использование kubelet для наблюдения за отдельными компонентами плоскости управления.

Кубелет автоматически пытается создать зеркальный под
на сервере API Kubernetes для каждого статического модуля.Это означает, что модули, работающие на узле, видны на сервере API,
но оттуда им нельзя управлять.

Что дальше?

Чтобы понять контекст того, почему Kubernetes оборачивает общий API Pod в другие ресурсы (такие как StatefulSets или Deployments), вы можете прочитать об известном уровне техники, в том числе:

Pod Lifecycle | Kubernetes

На этой странице описывается жизненный цикл пода. Поды следуют определенному жизненному циклу, начиная с
в фазе Pending , переходя через Running , если хотя бы один
из его основных контейнеров начинается нормально, а затем через Succeeded или
Сбой фаз в зависимости от того, завершился ли сбой какой-либо контейнер в модуле.

Пока работает под, кубелет может перезапускать контейнеры для обработки некоторых
вид неисправностей. Внутри пода Kubernetes отслеживает разные контейнеры.
заявляет и определяет, какие действия следует предпринять, чтобы под
снова здоров.

В Kubernetes API у подов есть как спецификация, так и фактический статус. В
Статус для объекта Pod состоит из набора условий Pod.
Вы также можете ввести пользовательскую информацию о готовности в
данные о состоянии для Pod, если это полезно для вашего приложения.

Пакеты планируются только один раз в своей жизни.
После того, как Pod запланирован (назначен) для узла, Pod работает на этом узле до тех пор, пока не остановится.
или прекращено.

Срок службы подов

Как и отдельные контейнеры приложений, поды считаются относительно
эфемерные (а не долговечные) сущности. Поды созданы, им присваивается уникальный
ID (UID) и по расписанию
к узлам, где они остаются до завершения (в соответствии с политикой перезапуска) или
удаление.
Если узел умирает, модули, запланированные на этот узел
планируются для удаления по истечении периода ожидания.

Стручки сами по себе не восстанавливаются. Если Pod запланирован на
узел, который затем выходит из строя, модуль удаляется; точно так же Pod не будет
пережить выселение из-за нехватки ресурсов или обслуживания узла. Kubernetes использует
абстракция более высокого уровня, называемая
контроллер, который обрабатывает работу
управление относительно одноразовыми экземплярами Pod.

Данный Pod (как определено UID) никогда не переносится на другой узел; вместо,
этот Pod может быть заменен новым, почти идентичным Pod, даже с тем же именем, если
желательно, но с другим UID.

Когда говорят, что у чего-то такое же время жизни, как у пода, например,
объем,
это означает, что объект существует до тех пор, пока этот конкретный Pod (с этим точным UID)
существует. Если этот Pod удален по какой-либо причине, и даже если идентичная замена
создается, связанный объект (в данном примере том) также уничтожается и
создан заново.

Pod-диаграмма

Многоконтейнерный Pod, содержащий средство для удаления файлов и
веб-сервер, который использует постоянный том для общего хранилища между контейнерами.

Pod phase

Поле состояния Pod является
PodStatus
объект, имеющий поле фазы .

Фаза Pod — это простая высокоуровневая сводка того, где Pod находится в своей
жизненный цикл. Эта фаза не предназначена для полного набора наблюдений.
состояния контейнера или Pod, и при этом он не предназначен для использования в качестве всеобъемлющего конечного автомата.

Количество и значение значений фазы Pod строго охраняются.
Кроме того, что задокументировано здесь, ничего не следует предполагать о модулях, которые
иметь заданное значение фазы .

Вот возможные значения для фазы :

Примечание: Когда под удаляется, он отображается как Завершение некоторыми командами kubectl.
Этот статус Terminating не является одной из фаз Pod.
Поду предоставляется срок для корректного завершения, который по умолчанию составляет 30 секунд.
Вы можете использовать флаг --force для принудительного завершения пода.

Если узел умирает или отключается от остальной части кластера, Kubernetes
применяет политику для установки фазы всех модулей на потерянном узле в состояние «Не удалось».

Состояния контейнера

Помимо фазы Pod в целом, Kubernetes отслеживает состояние
каждый контейнер внутри контейнера. Вы можете использовать
крючки жизненного цикла контейнера для
запускать события для запуска в определенные моменты жизненного цикла контейнера.

Как только планировщик
назначает Pod узлу, кубелет начинает создавать контейнеры для этого Pod
используя среду выполнения контейнера.
Существует три возможных состояния контейнера: Ожидание , Выполняется и Завершено .

Чтобы проверить состояние контейнеров пода, вы можете использовать
kubectl description pod . Вывод показывает состояние для каждого контейнера.
внутри этого модуля.

Каждое состояние имеет определенное значение:

Ожидание

Если контейнер не находится в состоянии Выполняется или Завершено , это Ожидание .
Контейнер в состоянии Ожидание все еще выполняет операции, требуемые в
порядок завершения запуска: например, вытаскивание образа контейнера из контейнера
реестр изображений или применение секрета
данные.Когда вы используете kubectl для запроса Pod с контейнером Waiting , вы также видите
поле «Причина», поясняющее, почему контейнер находится в таком состоянии.

Выполняется

Состояние Выполняется указывает, что контейнер выполняется без проблем. Если там
был настроен хук postStart , он уже выполнен и завершен. Когда вы используете
kubectl для запроса Pod с контейнером Запуск , вы также видите информацию
о том, когда контейнер перешел в состояние Running .

Завершено

Контейнер в состоянии Завершено начал выполнение, а затем либо перешел к
завершение или не удалось по какой-либо причине. Когда вы используете kubectl для запроса Pod с
контейнер Завершено , вы видите причину, код выхода, а также начало и
время завершения для периода выполнения этого контейнера.

Если для контейнера настроен хук preStop , который запускается до входа контейнера
состояние Завершено .

Политика перезапуска контейнера

В спецификации Pod есть поле restartPolicy с возможными значениями Always, OnFailure,
и никогда. Значение по умолчанию — Всегда.

Политика перезапуска применяется ко всем контейнерам в модуле. restartPolicy только
относится к перезапуску контейнеров кубелетом на том же узле. После контейнеров
при выходе из пода кубелет перезапускает их с экспоненциальной задержкой отката (10 с, 20 с,
40 секунд,…), который ограничен пятью минутами.После того, как контейнер отработал 10 минут
без каких-либо проблем кубелет сбрасывает таймер отсрочки перезапуска для этого контейнера.

Pod conditions

Pod имеет PodStatus, который имеет массив
PodConditions
через который Pod прошел или не прошел:

• PodScheduled : Pod был запланирован для узла.
• ContainersReady : все контейнеры в Pod готовы.
• Инициализировано : все контейнеры инициализации
  начали успешно.
• Готово : Pod может обслуживать запросы и должен быть добавлен в загрузку
  балансировка пулов всех соответствующих Сервисов.

Готовность Pod

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.14 [стабильный]

Ваше приложение может вводить дополнительную обратную связь или сигналы в PodStatus:
Готовность стручка . Чтобы использовать это, установите готовность Gate в спецификации Pod на
укажите список дополнительных условий, которые kubelet оценивает на предмет готовности Pod.

Готовность ворот определяется текущим состоянием status.condition
поля для Pod.Если Kubernetes не может найти такое условие в
status.conditions поле Pod, статус условия
по умолчанию установлено значение « False ».

Вот пример:

  вид: Pod
...
спецификация:
  готовностьВорота:
    - conditionType: "www.example.com/feature-1"
статус:
  условия:
    - тип: Готовый # встроенный PodCondition
      статус: «Ложь»
      lastProbeTime: нуль
      lastTransitionTime: 2018-01-01T00: 00: 00Z
    - введите: "www.example.com/feature-1 "# дополнительный PodCondition
      статус: «Ложь»
      lastProbeTime: нуль
      lastTransitionTime: 2018-01-01T00: 00: 00Z
  containerStatuses:
    - containerID: docker: // abcd ...
      готово: правда
...
  

Добавляемые вами условия Pod должны иметь имена, соответствующие формату ключа метки Kubernetes.

Состояние готовности Pod

Команда kubectl patch не поддерживает исправление состояния объекта.
Чтобы установить эти status.conditions для модуля, приложений и
операторы должны использовать
действие PATCH .Вы можете использовать клиентскую библиотеку Kubernetes для
написать код, который устанавливает пользовательские условия Pod для готовности Pod.

Для модуля, использующего настраиваемые условия, этот модуль оценивается как готовый только
когда применяются оба следующих утверждения:

• Все контейнеры в модуле готовы.
• Все условия, указанные в готовности Ворота соответствуют Истина .

Когда контейнеры Pod готовы, но по крайней мере одно пользовательское условие отсутствует или
False , kubelet устанавливает состояние Pod на ContainersReady .

Контейнерные зонды

Зонд является диагностическим
периодически выполняется
Кубелет
на контейнере. Чтобы выполнить диагностику,
Кубелет называет
Обработчик реализован
контейнер. Есть три типа обработчиков:

• ExecAction:
  Выполняет указанную команду внутри контейнера. Диагностика
  считается успешным, если команда завершается с кодом состояния 0.

• TCPSocketAction:
  Выполняет TCP-проверку IP-адреса Pod на
  указанный порт.Диагностика считается успешной, если порт открыт.

• HTTPGetAction:
  Выполняет запрос HTTP GET против IP-адреса пода
  адрес на указанном порту и пути. Диагностика считается успешной
  если ответ имеет код состояния больше или равный 200 и меньше 400.

Каждый зонд дает один из трех результатов:

• Успех : контейнер прошел диагностику.
• Failure : Контейнер не прошел диагностику.
• Неизвестно : Диагностика завершилась неудачно, поэтому не следует предпринимать никаких действий.

Кубелет может опционально выполнять и реагировать на три типа зондов во время работы.
контейнеры:

• livenessProbe : указывает, запущен ли контейнер. Если
  зонд живучести выходит из строя, кубелет убивает контейнер, а контейнер
  подвергается политике перезапуска. Если контейнер не
  предоставить зонд живучести, состояние по умолчанию — Успех .

• readinessProbe : указывает, готов ли контейнер отвечать на запросы.
  В случае сбоя проверки готовности контроллер конечных точек удаляет IP-адрес модуля.
  адрес от конечных точек всех Сервисов, которые соответствуют Pod. По умолчанию
  состояние готовности до начальной задержки — Отказ . Если контейнер
  не предоставлять зонд готовности, состояние по умолчанию — Успех .

• startupProbe : указывает, запущено ли приложение в контейнере.Все остальные зонды отключаются, если предоставляется зонд запуска, до тех пор, пока он не завершится успешно.
  Если зонд запуска выходит из строя, кубелет убивает контейнер, а контейнер
  подвергается политике перезапуска. Если контейнер не
  предоставить зонд запуска, состояние по умолчанию — Успех .

Для получения дополнительной информации о настройке проверки работоспособности, готовности или запуска,
см. Настройка зондов работоспособности, готовности и запуска.

Когда следует использовать зонд живучести?

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.0 [стабильный]

Если процесс в вашем контейнере может аварийно завершить работу всякий раз, когда он
сталкивается с проблемой или становится нездоровым, вам не обязательно нужна жизнеспособность
зонд; кубелет автоматически выполнит правильное действие в соответствии с
с помощью Pod restartPolicy .

Если вы хотите, чтобы ваш контейнер был остановлен и перезапущен в случае сбоя зонда, тогда
укажите зонд живучести и укажите для параметра restartPolicy Always или OnFailure.

Когда следует использовать зонд готовности?

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.0 [стабильный]

Если вы хотите начать отправку трафика на Pod только при успешном прохождении проверки,
указать пробу готовности. В этом случае зонд готовности может быть таким же
как зонд живучести, но наличие зондирования готовности в спецификации означает
что Pod запустится, не получая трафика, а только начнет получать
трафик после успешного запуска зондирования.
Если ваш контейнер должен работать с загрузкой больших данных, файлов конфигурации или
миграции во время запуска, укажите тест готовности.

Если вы хотите, чтобы ваш контейнер мог самостоятельно отключаться для обслуживания, вы
может указать зонд готовности, который проверяет конечную точку, специфичную для готовности, которая
отличается от зонда живучести.

Примечание: Если вы хотите иметь возможность сливать запросы при удалении модуля, вы не
обязательно понадобится проба готовности; при удалении Pod автоматически ставит себя
в состояние неготовности независимо от того, существует ли зонд готовности.
Pod остается в неготовом состоянии, пока ожидает контейнеров в Pod.
остановиться.

Когда следует использовать пробник запуска?

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [стабильный]

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

Если ваш контейнер обычно начинается более чем через
initialDelaySeconds + failureThreshold × periodSeconds , вы должны указать
зонд запуска, который проверяет ту же конечную точку, что и зонд живучести.По умолчанию для
periodSeconds — 10 с. Затем вы должны установить для его порог сбоя достаточно высоким, чтобы
разрешить запуск контейнера без изменения значений живучести по умолчанию
зонд. Это помогает защититься от тупиковых ситуаций.

Завершение работы модулей

Поскольку модули представляют собой процессы, выполняемые на узлах в кластере, важно
позволяют этим процессам корректно завершаться, когда они больше не нужны (скорее
чем быть внезапно остановленным сигналом KILL и не иметь возможности очистить).

Цель дизайна — дать вам возможность запрашивать удаление и знать, когда процессы
завершить, но также иметь возможность гарантировать, что удаление в конечном итоге завершится.
Когда вы запрашиваете удаление модуля, кластер записывает и отслеживает предполагаемый льготный период.
до того, как капсулу позволят насильственно убить. С этим принудительным отслеживанием выключения в
место, кубелет пытается изящно
неисправность.

Обычно среда выполнения контейнера отправляет сигнал TERM основному процессу в каждом
контейнер.Многие среды выполнения контейнеров учитывают значение STOPSIGNAL , определенное в контейнере.
изображение и отправьте это вместо TERM.
По истечении льготного периода сигнал KILL отправляется всем оставшимся
процессов, а затем Pod удаляется из
Сервер API. Если кубелет или
служба управления средой выполнения контейнера перезапускается в ожидании завершения процессов,
повторные попытки кластера с самого начала, включая полный исходный льготный период.

Пример потока:

1. Инструмент kubectl используется для ручного удаления определенного модуля с льготным периодом по умолчанию.
   (30 секунд).
2. Pod на сервере API обновляется с учетом времени, по истечении которого Pod считается «мертвым»
   вместе с льготным периодом.
   Если вы используете kubectl describe для проверки удаляемого модуля, этот модуль отображается как
   «Прекращение».
   На узле, на котором запущен Pod: как только кубелет видит, что Pod отмечен
   как завершение (установлена ​​длительность плавного отключения), кубелет запускает локальный Pod
   процесс выключения.
   1. Если один из контейнеров Pod определил preStop
      крючок, кубелет
      запускает этот хук внутри контейнера.Если хук preStop все еще работает после
      льготный период истекает, кубелет запрашивает небольшое разовое продление льготного периода на 2
      секунд.

      Примечание: Если обработчику preStop требуется больше времени для завершения, чем позволяет льготный период по умолчанию,
      вы должны изменить terminationGracePeriodSeconds в соответствии с этим.

   2. Кубелет запускает среду выполнения контейнера, чтобы отправить сигнал TERM для обработки 1 внутри каждого
      контейнер.

      Примечание: Контейнеры в Pod получают сигнал TERM в разное время и в произвольном
      приказ.Если порядок отключений имеет значение, рассмотрите возможность использования обработчика preStop для синхронизации.

3. В то время как kubelet начинает постепенное завершение работы, плоскость управления удаляет это
   выключение Pod из объектов Endpoints (и, если включено, EndpointSlice), где они представляют
   Сервис с настроенным
   селектор.
   ReplicaSets и другие ресурсы рабочей нагрузки
   больше не рассматривать завершающую работу Pod как действующую действующую реплику. Поды, которые медленно отключаются
   не может продолжать обслуживать трафик в качестве балансировщиков нагрузки (например, прокси-сервер службы), удалите модуль из
   список конечных точек, как только период отсрочки завершения начинается .
4. По истечении льготного периода кубелет запускает принудительное завершение работы. Среда выполнения контейнера отправляет
   SIGKILL для любых процессов, все еще работающих в любом контейнере в Pod.
   Кубелет также очищает скрытый контейнер pause , если он используется во время выполнения контейнера.
5. Кубелет запускает принудительное удаление объекта Pod с сервера API, устанавливая льготный период
   до 0 (немедленное удаление).
6. Сервер API удаляет объект API модуля Pod, который больше не виден ни одним клиентом.

Принудительное завершение Pod

Внимание! Принудительное удаление может потенциально нарушить работу некоторых рабочих нагрузок и их модулей.

По умолчанию все удаления выполняются в течение 30 секунд. Команда kubectl delete поддерживает
параметр --grace-period = , который позволяет вам переопределить значение по умолчанию и указать свой
собственная стоимость.

Установка льготного периода на 0 принудительно и немедленно удаляет Pod из API
сервер.Если pod все еще работал на узле, это принудительное удаление запускает kubelet для
начать немедленную очистку.

Примечание: Вы должны указать дополнительный флаг --force вместе с --grace-period = 0 для выполнения принудительного удаления.

При выполнении принудительного удаления сервер API не ждет подтверждения
из кублета, что модуль был остановлен на узле, на котором он работал. Это
немедленно удаляет модуль из API, чтобы новый модуль можно было создать с тем же
имя.На узле модули, которые настроены на немедленное завершение, по-прежнему будут предоставлены
небольшой период отсрочки до насильственного убийства.

Если вам нужно принудительно удалить модули, которые являются частью StatefulSet, обратитесь к задаче
документация для
удаление подов из StatefulSet.

Сборка мусора сбойных модулей

Для сбойных модулей объекты API остаются в API кластера до тех пор, пока человек или
процесс контроллера
явно удаляет их.

Плоскость управления очищает завершенные Pod’ы (с фазой Succeeded или
Failed ), когда количество модулей превышает настроенный порог
(определяется terminated-pod-gc-threshold в kube-controller-manager).Это позволяет избежать утечки ресурсов, поскольку поды создаются и завершаются с течением времени.

Что дальше?

Последнее изменение: 11 февраля 2021 г., 15:51 по тихоокеанскому стандартному времени: очистить использование слова: just (3ff5ec1ef)

Инициативные контейнеры | Kubernetes

На этой странице представлен обзор контейнеров инициализации: специализированных контейнеров, которые запускаются.
перед контейнерами приложений в Pod.
Контейнеры инициализации могут содержать служебные программы или сценарии установки, отсутствующие в образе приложения.

Вы можете указать контейнеры инициализации в спецификации Pod вместе с контейнерами
массив (который описывает контейнеры приложений).

Общие сведения о контейнерах инициализации

Pod может иметь несколько контейнеров
запускающие приложения внутри него, но он также может иметь один или несколько контейнеров инициализации, которые запускаются
перед запуском контейнеров приложений.

Инициативные контейнеры точно такие же, как и обычные контейнеры, за исключением:

• Инициативные контейнеры всегда выполняются до завершения.
• Каждый контейнер инициализации должен успешно завершиться до запуска следующего.

Если контейнер инициализации Pod выходит из строя, кубелет повторно запускает этот контейнер инициализации до тех пор, пока не завершится успешно.Однако, если Pod имеет restartPolicy Never, и контейнер инициализации дает сбой во время запуска этого Pod’а, Kubernetes рассматривает весь Pod как сбойный.

Чтобы указать контейнер инициализации для Pod, добавьте поле initContainers в
спецификация Pod как массив объектов типа
Контейнер,
рядом с приложением контейнеров массив.
Статус контейнеров инициализации возвращается в .status.initContainerStatuses .
поле в виде массива статусов контейнеров (аналогично .status.containerStatuses
поле).

Отличия от обычных контейнеров

Инициативные контейнеры поддерживают все поля и функции контейнеров приложений,
включая лимиты ресурсов, тома и настройки безопасности. Тем не менее
запросы ресурсов и ограничения для контейнера инициализации обрабатываются по-разному,
как описано в Ресурсах.

Кроме того, контейнеры инициализации не поддерживают жизненный цикл , livenessProbe , readinessProbe или
startupProbe , потому что они должны быть выполнены до завершения, прежде чем Pod сможет быть готов.

Если вы укажете несколько контейнеров инициализации для пода, kubelet будет запускать каждый запуск
контейнер последовательно. Каждый контейнер инициализации должен быть успешным, прежде чем сможет запуститься следующий.
Когда все контейнеры инициализации завершены, kubelet инициализирует
контейнеры приложений для Pod и запускают их как обычно.

Использование контейнеров инициализации

Поскольку у контейнеров инициализации есть отдельные изображения от контейнеров приложений, они
имеют некоторые преимущества для кода, связанного с запуском:

• Контейнеры инициализации могут содержать служебные программы или настраиваемый код для настройки, которых нет в приложении
  изображение.Например, нет необходимости делать изображение ИЗ другим изображением, просто чтобы использовать такой инструмент, как
  sed , awk , python или dig во время установки.
• Роли построителя образов приложений и развертывания могут работать независимо без
  необходимость совместного создания единого образа приложения.
• Контейнеры инициализации могут работать с другим представлением файловой системы, чем контейнеры приложений в
  тот же Pod. Следовательно, им может быть предоставлен доступ к
  Секреты, к которым контейнеры приложений не могут получить доступ.
• Поскольку контейнеры инициализации выполняются до завершения до запуска любых контейнеров приложений, контейнеры инициализации предлагают
  механизм для блокировки или задержки запуска контейнера приложения до тех пор, пока не будет выполнен набор предварительных условий. Один раз
  предварительные условия выполнены, все контейнеры приложений в Pod могут запускаться параллельно.
• Контейнеры инициализации могут безопасно запускать утилиты или настраиваемый код, который в противном случае сделал бы приложение
  образ контейнера менее безопасен. Разделяя ненужные инструменты, вы можете ограничить атаку.
  поверхность изображения контейнера вашего приложения.

Примеры

Вот несколько идей, как использовать контейнеры инициализации:

• Подождите, пока служба
  может быть создан с помощью однострочной команды оболочки, например:

    для i в {1..100}; спать 1; если копать myservice; затем выйдите из 0; fi; Готово; выход 1
    

• Зарегистрируйте этот модуль на удаленном сервере из нижележащего API с помощью команды вида:

    curl -X POST http: // $ MANAGEMENT_SERVICE_HOST: $ MANAGEMENT_SERVICE_PORT / register -d 'instance = $ () & ip = $ () '
    

• Подождите некоторое время перед запуском контейнера приложения с помощью такой команды, как

• Клонировать репозиторий Git в том

• Поместите значения в файл конфигурации и запустите инструмент шаблона для динамического
  сгенерируйте файл конфигурации для основного контейнера приложения.Например,
  поместите значение POD_IP в конфигурацию и сгенерируйте основное приложение
  файл конфигурации с помощью Jinja.

Контейнеры инициализации в использовании

В этом примере определяется простой Pod с двумя контейнерами инициализации.
Первый ждет myservice , а второй — mydb . Когда-то оба
init контейнеры завершены, Pod запускает контейнер приложения из раздела spec .

  apiВерсия: v1
вид: Стручок
метаданные:
  имя: myapp-pod
  ярлыки:
    приложение: myapp
спецификация:
  контейнеры:
  - имя: myapp-container
    изображение: busybox: 1.28 год
    команда: ['sh', '-c', 'echo Приложение запущено! && спать 3600 ']
  initContainers:
  - имя: init-myservice
    изображение: busybox: 1.28
    команда: ['sh', '-c', "до nslookup myservice. $ (cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo ожидания myservice; sleep 2 ; Готово"]
  - имя: init-mydb
    изображение: busybox: 1.28
    команда: ['sh', '-c', "до nslookup mydb. $ (cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo, ожидая mydb; sleep 2 ; Готово"]
  

Вы можете запустить этот Pod, выполнив:

  kubectl apply -f myapp.ямл
  

Результат выглядит примерно так:

  pod / myapp-pod created
  

И проверьте его статус с помощью:

  kubectl get -f myapp.yaml
  

Результат выглядит примерно так:

  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ПЕРЕЗАПУСКАЕТСЯ ВОЗРАСТ
myapp-pod 0/1 Инициализация: 0/2 0 6 мес.
  

или для получения дополнительной информации:

  kubectl describe -f myapp.yaml
  

Результат выглядит примерно так:

  Имя: myapp-pod
Пространство имен: по умолчанию
[...]
Ярлыки: app = myapp
Статус: ожидание
[...]
Инициативные контейнеры:
  init-myservice:
[...]
    Состояние: Бег
[...]
  init-mydb:
[...]
    Состояние: Ожидание
      Причина: PodInitializing
    Готово: ложь
[...]
Контейнеры:
  myapp-контейнер:
[...]
    Состояние: Ожидание
      Причина: PodInitializing
    Готово: ложь
[...]
События:
  FirstSeen LastSeen Count из сообщения о причине типа SubObjectPath
  --------- -------- ----- ---- ------------- -------- --- --- -------
  16s 16s 1 {default-scheduler} Нормальный Запланировано Успешно присвоено myapp-pod 172.17.4.201
  16s 16s 1 {kubelet 172.17.4.201} spec.initContainers {init-myservice} Нормальное извлечение извлечение изображения "busybox"
  13s 13s 1 {kubelet 172.17.4.201} spec.initContainers {init-myservice} Нормальный Извлечен Успешно извлечен образ "busybox"
  13s 13s 1 {kubelet 172.17.4.201} spec.initContainers {init-myservice} Нормально Создан Создан Создан контейнер с идентификатором докера 5ced34a04634; Безопасность: [seccomp = unlimited]
  13с 13с 1 {кубелет 172.17.4.201} spec.initContainers {init-myservice} Normal Started Запущенный контейнер с идентификатором докера 5ced34a04634
  

Чтобы просмотреть журналы для контейнеров инициализации в этом модуле, выполните:

  kubectl logs myapp-pod -c init-myservice # Проверьте первый контейнер инициализации
kubectl logs myapp-pod -c init-mydb # Проверить второй контейнер инициализации
  

На этом этапе эти контейнеры инициализации будут ожидать обнаружения служб с именем
mydb и myservice .

Вот конфигурация, которую вы можете использовать для отображения этих сервисов:

  ---
apiVersion: v1
вид: Сервис
метаданные:
  имя: myservice
спецификация:
  порты:
  - протокол: TCP
    порт: 80
    targetPort: 9376
---
apiVersion: v1
вид: Сервис
метаданные:
  имя: mydb
спецификация:
  порты:
  - протокол: TCP
    порт: 80
    targetPort: 9377
  

Для создания сервисов mydb и myservice :

  kubectl apply -f services.yaml
  

Результат выглядит примерно так:

  service / myservice created
служба / mydb создана
  

Затем вы увидите, что эти контейнеры инициализации завершены, и что myapp-pod
Под переходит в состояние выполнения:

  kubectl get -f myapp.ямл
  

Результат выглядит примерно так:

  НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ПОВТОРНЫЙ ВОЗРАСТ
myapp-pod 1/1 Бег 0 9 мес.
  

Этот простой пример должен вдохновить вас на создание собственного
инициализировать контейнеры. Что дальше, содержит ссылку на более подробный пример.

Подробное поведение

Во время запуска Pod кубелет задерживает запуск контейнеров инициализации до подключения к сети.
и хранилище готовы. Затем кубелет запускает контейнеры инициализации Pod в следующем порядке:
они появляются в спецификации стручка.

Каждый контейнер инициализации должен успешно завершиться, прежде чем
запускается следующий контейнер. Если контейнер не запускается из-за времени выполнения или
завершается с ошибкой, выполняется повторная попытка в соответствии с политикой перезапуска Pod . Тем не мение,
если для Pod restartPolicy установлено значение Always, контейнеры инициализации используют
restartPolicy OnFailure.

Pod не может быть Ready до тех пор, пока все контейнеры инициализации не будут успешно выполнены. Порты на
Контейнер инициализации не объединяется с Сервисом.Pod, который инициализирует
находится в состоянии Pending , но для условия Initialized должно быть задано значение false.

Если Pod перезапускается или перезапускается, все контейнеры инициализации
должен выполнить снова.

Изменения в спецификации контейнера инициализации ограничиваются полем образа контейнера.
Изменение поля образа контейнера инициализации эквивалентно перезапуску модуля.

Поскольку контейнеры инициализации можно перезапустить, повторить или повторно запустить, контейнер инициализации
код должен быть идемпотентным.В частности, код, который записывает файлы на EmptyDirs
следует быть готовым к тому, что выходной файл уже существует.

Инициативные контейнеры содержат все поля контейнера приложения. Однако Kubernetes
запрещает использование readinessProbe , потому что контейнеры инициализации не могут
определить готовность, отличную от завершения. Это принудительно во время проверки.

Используйте activeDeadlineSeconds на модуле и livenessProbe на контейнере, чтобы
предотвратить отказ контейнеров инициализации навсегда.Активный крайний срок включает инициализацию
контейнеры.

Имя каждого приложения и контейнера инициализации в модуле должно быть уникальным; а
ошибка проверки выдается для любого контейнера, имеющего имя с другим.

Ресурсы

Учитывая порядок и выполнение для контейнеров инициализации, следующие правила
для использования ресурсов применяется:

• Наивысший из любого конкретного запроса ресурса или лимита, определенного для всех init
  контейнеров — это эффективных запросов / лимитов инициализации
• Эффективный запрос / лимит Pod для ресурса больше:
  • сумма всех запросов / лимитов контейнеров приложений для ресурса
  • эффективный запрос / лимит инициализации для ресурса
• Планирование выполняется на основе действующих запросов / лимитов, что означает
  контейнеры инициализации могут резервировать ресурсы для инициализации, которые не используются
  при жизни стручка.
• Уровень QoS (качество обслуживания) эффективного уровня QoS Pod является
  Уровень QoS как для контейнеров инициализации, так и для контейнеров приложений.

Квота и ограничения применяются в зависимости от действующего запроса Pod и
предел.

Контрольные группы уровня Pod (контрольные группы) основаны на эффективном запросе Pod и
limit, то же, что и планировщик.

Причины перезапуска Pod

Pod может перезапускаться, вызывая повторное выполнение контейнеров инициализации, для следующих
Причины:

• Контейнер инфраструктуры Pod перезапущен.Это необычно и могло бы
  должны выполняться кем-то с корневым доступом к узлам.
• Все контейнеры в Pod завершаются, а для параметра restartPolicy установлено значение Always,
  принудительный перезапуск, и запись о завершении контейнера инициализации была потеряна из-за
  на сборку мусора.

Pod не будет перезапущен при изменении образа контейнера инициализации или
Запись о завершении контейнера инициализации была потеряна из-за сборки мусора. Этот
применяется для Kubernetes v1.20 и новее.Если вы используете более раннюю версию
Kubernetes, обратитесь к документации по используемой вами версии.

Что дальше?

Последнее изменение 17 марта 2021 г., 11:34 по тихоокеанскому времени: изменение образа контейнера инициализации или сборщик мусора не перезапускает Pod с 1.20 (ed7c4e704)

Эфемерные контейнеры | Kubernetes

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.16 [альфа]

На этой странице представлен обзор эфемерных контейнеров: особый тип контейнера.
который временно работает в существующем модуле, чтобы
выполнять действия, инициированные пользователем, такие как устранение неполадок.Вы используете эфемерные
контейнеры для проверки служб, а не для создания приложений.

Предупреждение: Эфемерные контейнеры находятся в раннем альфа-состоянии и не подходят для производства
кластеры. В соответствии с Политикой устаревания Kubernetes эта альфа-функция может измениться.
значительно в будущем или полностью удалить.

Понимание эфемерных контейнеров

Стручки — это фундаментальное здание
блок приложений Kubernetes. Поскольку капсулы предназначены для одноразового использования и
заменяемый, вы не можете добавить контейнер в модуль после его создания.Вместо этого вы обычно удаляете и заменяете модули контролируемым образом, используя
развертывания.

Иногда необходимо проверить состояние существующего модуля, однако
пример для устранения трудно воспроизводимой ошибки. В этих случаях вы можете запустить
временный контейнер в существующем поде для проверки его состояния и запуска
произвольные команды.

Что такое временный контейнер?

Эфемерные контейнеры отличаются от других контейнеров отсутствием гарантий
для ресурсов или выполнения, и они никогда не будут перезапущены автоматически, поэтому
они не подходят для создания приложений.Эфемерные контейнеры
описан с использованием того же ContainerSpec , что и обычные контейнеры, но с множеством полей
несовместимы и запрещены для временных контейнеров.

• Эфемерные контейнеры могут не иметь портов, поэтому такие поля, как портов ,
  livenessProbe , readinessProbe запрещены.
• Распределение ресурсов Pod неизменяемо, поэтому установка ресурсов запрещена.
• Полный список допустимых полей см. В справке по EphemeralContainer.
  документация.

Эфемерные контейнеры создаются с помощью специального обработчика эфемерных контейнеров
в API, а не добавляя их напрямую в pod.spec , поэтому это не
можно добавить временный контейнер с помощью kubectl edit .

Как и обычные контейнеры, временные контейнеры нельзя менять или снимать.
после того, как вы добавили его в под.

Использование для эфемерных контейнеров

Эфемерные контейнеры полезны для интерактивного устранения неполадок, когда kubectl exec недостаточно из-за сбоя контейнера или образа контейнера
не включает утилиты отладки.

В частности, изображения без дистрибутива
позволяют развертывать минимальные образы контейнеров, уменьшающие поверхность атаки
и подверженность ошибкам и уязвимостям. Поскольку изображения без дистрибутива не содержат
оболочки или любых утилит отладки, трудно устранить неполадки без использования дистрибутива
изображения с использованием только kubectl exec .

При использовании эфемерных контейнеров полезно включить пространство имен процессов
делиться так
вы можете просматривать процессы в других контейнерах.

См. Отладка с помощью временного контейнера отладки
для примеров устранения неполадок с использованием временных контейнеров.

Эфемерные контейнеры API

Примечание: Для примеров в этом разделе требуется функция EphemeralContainers
ворота, чтобы быть
включен, а также версия клиента и сервера Kubernetes v1.16 или новее.

Примеры в этом разделе демонстрируют, как эфемерные контейнеры появляются в
API. Обычно вы используете kubectl debug или другой kubectl
плагин для автоматизации этих шагов
вместо прямого вызова API.

Эфемерные контейнеры создаются с использованием субресурса ephemeralcontainers
Pod, который можно продемонстрировать с помощью kubectl --raw .Сначала опишите
временный контейнер для добавления в список EphemeralContainers :

  {
    "apiVersion": "v1",
    "kind": "Эфемерные контейнеры",
    "метаданные": {
        "имя": "пример-капсула"
    },
    "ephemeralContainers": [{
        "команда": [
            "ш"
        ],
        "изображение": "занято",
        "imagePullPolicy": "IfNotPresent",
        "имя": "отладчик",
        "stdin": правда,
        "tty": правда,
        "terminationMessagePolicy": "Файл"
    }]
}
  

Чтобы обновить эфемерные контейнеры уже запущенного модуля example-pod :

  kubectl замените --raw / api / v1 / namespaces / default / pods / example-pod / ephemeralcontainers -f ec.json
  

Будет возвращен новый список временных контейнеров:

  {
   "kind": "Эфемерные контейнеры",
   "apiVersion": "v1",
   "метаданные": {
      "name": "example-pod",
      "пространство имен": "по умолчанию",
      "selfLink": "/ api / v1 / namespaces / default / pods / example-pod / ephemeralcontainers",
      "uid": "a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
      "resourceVersion": "15886",
      "creationTimestamp": "2019-08-29T06: 41: 42Z"
   },
   "ephemeralContainers": [
      {
         "имя": "отладчик",
         "изображение": "занято",
         "команда": [
            "ш"
         ],
         "Ресурсы":{

         },
         "terminationMessagePolicy": "Файл",
         "imagePullPolicy": "IfNotPresent",
         "stdin": правда,
         "tty": правда
      }
   ]
}
  

Вы можете просмотреть состояние вновь созданного временного контейнера, используя kubectl describe :

  kubectl describe pod example-pod
  

 ...
Эфемерные контейнеры:
  отладчик:
    ID контейнера: docker: // cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
    Изображение: busybox
    ID изображения: docker-pullable: // busybox @ sha256: 9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
    Порт: <нет>
    Порт хоста: <нет>
    Команда:
      ш
    Состояние: Бег
      Начат: чт, 29 авг 2019 06:42:21 +0000
    Готово: ложь
    Счетчик перезапусков: 0
    Окружающая среда: <нет>
    Средства передвижения: <нет>
...
  

Вы можете взаимодействовать с новым временным контейнером так же, как и другие
контейнеры, использующие kubectl attach , kubectl exec и kubectl logs , для
пример:

  kubectl attach -it example-pod -c debugger
  

Последнее изменение: 9 февраля 2021 г., 8:11 по тихоокеанскому стандартному времени: обновление ephemeral-containers.md (70ebc7f6e)

Ограничения распространения топологии Pod | Kubernetes

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.19 [стабильный]

Вы можете использовать ограничения распространения топологии для управления распределением модулей по кластеру между доменами отказа, такими как регионы, зоны, узлы и другие определяемые пользователем домены топологии. Это может помочь достичь высокой доступности, а также эффективного использования ресурсов.

Примечание: В версиях Kubernetes до v1.19 необходимо включить EvenPodsSpread
функция ворот на
сервер API и
планировщик для использования Pod
ограничения распространения топологии.

Предварительные требования

Метки узлов

Ограничения распространения топологии основаны на метках узлов для определения домена (ов) топологии, в котором находится каждый узел. Например, узел может иметь метки: node = node1, zone = us-east- 1a, region = us-east-1

Предположим, у вас есть кластер с 4 узлами со следующими метками:

  ИМЯ СТАТУС РОЛИ ВОЗРАСТНАЯ ВЕРСИЯ МЕТКИ
node1 Готов <нет> 4m26s v1.16.0 node = node1, zone = zoneA
node2 Готов <нет> 3m58s v1.16.0 узел = узел2, зона = зонаA
node3 Готов <нет> 3 мин. 17 сек. v1.16.0 node = node3, zone = zoneB
node4 Готов <нет> 2m43s v1.16.0 node = node4, zone = zoneB
  

Тогда кластер логически выглядит следующим образом:

граф ТБ
подграф «зонаB»
n3 (Узел 3)
n4 (узел 4)
конец
подграф «зонаA»
n1 (Узел 1)
n2 (Узел 2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4 k8s;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

Вместо того, чтобы вручную применять метки, вы также можете повторно использовать хорошо известные метки, которые создаются и заполняются автоматически в большинстве кластеров.

Ограничения распространения для модулей

API

Поле API pod.spec.topologySpreadConstraints определяется следующим образом:

  apiVersion: v1
вид: Стручок
метаданные:
  имя: mypod
спецификация:
  topologySpreadConstraints:
    - maxSkew: <целое число>
      topologyKey: <строка>
      whenUnsatisfiable: <строка>
      labelSelector: <объект>
  

Вы можете определить один или несколько topologySpreadConstraint , чтобы указать планировщику kube, как разместить каждый входящий модуль по отношению к существующим модулям в вашем кластере.Поля:

• maxSkew описывает степень, в которой поды могут быть распределены неравномерно.
  Это максимально допустимая разница между количеством подходящих модулей в
  любые две области топологии данного типа топологии. Это должно быть больше, чем
  нуль. Его семантика отличается в зависимости от значения whenUnsatisfiable :
  • когда whenUnsatisfiable равно «DoNotSchedule», maxSkew является максимальным
    допустимая разница между количеством совпадающих модулей в целевом объекте
    топология и глобальный минимум.
  • когда whenUnsatisfiable равно «ScheduleAnyway», планировщик дает больше
    приоритет топологии, который поможет уменьшить перекос.
• topologyKey — это ключ меток узлов. Если два узла помечены этим ключом и имеют одинаковые значения для этой метки, планировщик рассматривает оба узла как находящиеся в одной топологии. Планировщик пытается разместить сбалансированное количество модулей в каждом домене топологии.
• whenUnsatisfiable указывает, как работать с модулем, если он не удовлетворяет ограничению распространения:
  • DoNotSchedule (по умолчанию) сообщает планировщику не планировать его.
  • ScheduleAnyway сообщает планировщику, чтобы он продолжал планировать его, при этом отдавая приоритет узлам, которые минимизируют перекос.
• labelSelector используется для поиска подходящих модулей. Модули, соответствующие этому селектору меток, подсчитываются для определения количества модулей в соответствующем домене топологии. См. Дополнительные сведения в разделе «Селекторы меток».

Вы можете узнать больше об этом поле, запустив kubectl объяснять Pod.spec.topologySpreadConstraints .

Пример: One TopologySpreadConstraint

Предположим, у вас есть кластер с 4 узлами, где 3 модуля с меткой foo: bar расположены в node1, node2 и node3 соответственно:

graph BT
подграф «зонаB»
p3 (Pod) -> n3 (Node3)
n4 (узел 4)
конец
подграф «зонаA»
p1 (Pod) -> n1 (Узел1)
p2 (Pod) -> n2 (Узел 2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4, p1, p2, p3 k8s;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

Если мы хотим, чтобы входящий модуль равномерно распределялся с существующими модулями по зонам, спецификация может быть представлена ​​как:

  вид: модуль
apiVersion: v1
метаданные:
  имя: mypod
  ярлыки:
    foo: bar
спецификация:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: зона
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  контейнеры:
  - название: пауза
    изображение: k8s.gcr.io/pause:3.1  

topologyKey: зона подразумевает, что равномерное распределение будет применяться только к узлам, имеющим пару меток «зона: <любое значение>». whenUnsatisfiable: DoNotSchedule сообщает планировщику, чтобы он оставался в режиме ожидания, если входящий Pod не может удовлетворить ограничение.

Если планировщик поместил этот входящий модуль в «зону А», распределение модулей стало бы [3, 1], следовательно, фактический перекос равен 2 (3 — 1), что нарушает maxSkew: 1 .В этом примере входящий Pod может быть помещен только в «зонуB»:

graph BT
подграф «зонаB»
p3 (Pod) -> n3 (Node3)
p4 (mypod) -> n4 (Node4)
конец
подграф «зонаA»
p1 (Pod) -> n1 (Узел1)
p2 (Pod) -> n2 (Узел 2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4, p1, p2, p3 k8s;
класс p4 plain;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

OR

graph BT
подграф «зонаB»
p3 (Pod) -> n3 (Node3)
p4 (mypod) -> n3
n4 (узел 4)
конец
подграф «зонаA»
p1 (Pod) -> n1 (Узел1)
p2 (Pod) -> n2 (Узел 2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4, p1, p2, p3 k8s;
класс p4 plain;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

Вы можете настроить спецификацию модуля в соответствии с различными требованиями:

• Измените maxSkew на большее значение, например «2», чтобы входящий модуль можно было разместить «zoneA» тоже.
• Измените topologyKey на «узел», чтобы модули были равномерно распределены по узлам, а не по зонам. В приведенном выше примере, если maxSkew остается «1», входящий Pod может быть помещен только на «node4».
• Измените whenUnsatisfiable: DoNotSchedule на whenUnsatisfiable: ScheduleAnyway , чтобы обеспечить постоянное планирование входящего модуля Pod (предположим, что удовлетворяются другие API-интерфейсы планирования). Однако предпочтительнее размещать в домене топологии, который имеет меньше подходящих модулей.(Имейте в виду, что это предпочтение совместно нормализуется с другими внутренними приоритетами планирования, такими как коэффициент использования ресурсов и т. Д.)

Пример: множественные ограничения TopologySpreadConstraints

Это основано на предыдущем примере. Предположим, у вас есть кластер с 4 узлами, где 3 модуля с меткой foo: bar расположены в node1, node2 и node3 соответственно:

graph BT
подграф «зонаB»
p3 (Pod) -> n3 (Node3)
n4 (узел 4)
конец
подграф «зонаA»
p1 (Pod) -> n1 (Узел1)
p2 (Pod) -> n2 (Узел 2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4, p1, p2, p3 k8s;
класс p4 plain;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

Вы можете использовать 2 TopologySpreadConstraints для управления распространением модулей как в зоне, так и на узле:

  kind: Pod
apiVersion: v1
метаданные:
  имя: mypod
  ярлыки:
    foo: bar
спецификация:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: зона
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: узел
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  контейнеры:
  - название: пауза
    изображение: k8s.gcr.io/pause:3.1  

В этом случае, чтобы соответствовать первому ограничению, входящий модуль может быть помещен только в «зонуB»; в то время как с точки зрения второго ограничения, входящий Pod может быть размещен только на «node4». Затем результаты двух ограничений объединяются с помощью AND, поэтому единственный жизнеспособный вариант — разместить на «node4».

Множественные ограничения могут привести к конфликтам. Предположим, у вас есть кластер с 3 узлами в 2 зонах:

graph BT
подграф «зонаB»
p4 (Pod) -> n3 (Node3)
p5 (Pod) -> n3
конец
подграф «зонаA»
p1 (Pod) -> n1 (Узел1)
p2 (Pod) -> n1
p3 (Pod) -> n2 (Node2)
конец
classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
класс n1, n2, n3, n4, p1, p2, p3, p4, p5 k8s;
класс zoneA, кластер zoneB;

[JavaScript должен быть включен для просмотра содержимого]

Если вы применяете «два ограничения.yaml «в этот кластер, вы заметите, что» mypod «остается в состоянии Pending . Это потому, что: для удовлетворения первого ограничения» mypod «может быть помещен только в» zoneB «; в то время как с точки зрения второго ограничения» mypod «может помещать только в» node2 «. Тогда совместный результат» zoneB «и» node2 «ничего не возвращает.

Чтобы преодолеть эту ситуацию, вы можете либо увеличить maxSkew , либо изменить одно из ограничений, чтобы использовать whenUnsatisfiable : ScheduleAnyway .

Соглашения

Здесь стоит отметить некоторые неявные соглашения:

• Соответствующими кандидатами могут быть только модули, содержащие то же пространство имен, что и входящий модуль.

• Узлы без topologySpreadConstraints [*]. Наличие ключа topologyKey будет пропущено. Это означает, что:

  1. Модули, расположенные на этих узлах, не влияют на расчет maxSkew — в приведенном выше примере предположим, что «узел1» не имеет метки «зона», тогда 2 модуля будут проигнорированы, следовательно, входящий модуль будет запланировано в «зону А».
  2. входящий Pod не имеет шансов быть запланированным на такие узлы — в приведенном выше примере предположим, что «node5» с меткой {zone-typo: zoneC} присоединяется к кластеру, он будет пропущен из-за отсутствия метки ключа «зона».

• Имейте в виду, что произойдет, если topologySpreadConstraints [*]. LabelSelector входящегоPod не соответствует его собственным меткам. В приведенном выше примере, если мы удалим метки входящего модуля, он все равно может быть помещен в «зонуB», поскольку ограничения все еще выполняются. Однако после размещения степень дисбаланса кластера остается неизменной — это все еще зона A, имеющая 2 модуля с меткой {foo: bar}, и зона B, имеющая 1 модуль с меткой {foo: bar}.Так что, если это не то, что вы ожидаете, мы рекомендуем topologySpreadConstraints [*]. LabelSelector рабочей нагрузки, чтобы он соответствовал собственным меткам.

• Если для входящего модуля определено spec.nodeSelector или spec.affinity.nodeAffinity , узлы, не соответствующие им, будут пропущены.

  Предположим, у вас есть кластер с 5 узлами от zoneA до zoneC:

  graph BT
  подграф «зонаB»
  p3 (Pod) -> n3 (Node3)
  n4 (узел 4)
  конец
  подграф «зонаA»
  p1 (Pod) -> n1 (Узел1)
  p2 (Pod) -> n2 (Узел 2)
  конец
  classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
  classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
  заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
  класс n1, n2, n3, n4, p1, p2, p3 k8s;
  класс p4 plain;
  класс zoneA, кластер zoneB;

  [JavaScript должен быть включен для просмотра содержания]

  graph BT
  подграф «зонаC»
  n5 (Узел 5)
  конец
  classDef обычная заливка: # ddd, обводка: # fff, ширина обводки: 4 пикселя, цвет: # 000;
  classDef k8s fill: # 326ce5, обводка: # fff, ширина обводки: 4 пикселя, цвет: #fff;
  заливка кластера classDef: # fff, обводка: # bbb, ширина обводки: 2 пикселя, цвет: # 326ce5;
  класс н5 к8с;
  класс zoneC cluster;

  [JavaScript должен быть включен для просмотра содержимого]

  и вы знаете, что «zoneC» должна быть исключена.В этом случае вы можете составить yaml, как показано ниже, чтобы «mypod» был помещен в «zoneB» вместо «zoneC». Аналогично spec.nodeSelector также соблюдается.

    вид: Стручок
  apiVersion: v1
  метаданные:
    имя: mypod
    ярлыки:
      foo: bar
  спецификация:
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: зона
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          foo: bar
    близость:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - клавиша: зона
              оператор: NotIn
              значения:
              - зонаC
    контейнеры:
    - название: пауза
      изображение: k8s.gcr.io/pause:3.1  

Ограничения по умолчанию на уровне кластера

Можно установить ограничения распространения топологии по умолчанию для кластера. По умолчанию
Ограничения распространения топологии применяются к Pod тогда и только тогда, когда:

• Он не определяет никаких ограничений в своем .spec.topologySpreadConstraints .
• Он принадлежит службе, контроллеру репликации, набору реплик или набору с отслеживанием состояния.

Ограничения по умолчанию могут быть установлены как часть аргументов подключаемого модуля PodTopologySpread
в профиле планирования.Ограничения задаются тем же API, что и выше, за исключением того, что
labelSelector должен быть пустым. Селекторы рассчитываются из сервисов,
контроллеры репликации, наборы реплик или наборы с отслеживанием состояния, которым принадлежит Pod.

Пример конфигурации может выглядеть следующим образом:

  apiVersion: kubescheduler.config.k8s.io/v1beta1
вид: KubeSchedulerConfiguration

профили:
  - pluginConfig:
      - имя: PodTopologySpread
        аргументы:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: топология.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway
          defaultingType: List
  

Примечание: Оценка, полученная с помощью ограничений планирования по умолчанию, может конфликтовать с
оценка произведена
SelectorSpread плагин.
Рекомендуется отключить этот плагин в профиле планирования, когда
с использованием ограничений по умолчанию для PodTopologySpread .

Внутренние ограничения по умолчанию

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [бета]

С включенным по умолчанию шлюзом DefaultPodTopologySpread
устаревший плагин SelectorSpread отключен.
kube-scheduler использует следующие ограничения топологии по умолчанию для
PodTopologySpread конфигурация плагина:

  по умолчанию Ограничения:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
  

Кроме того, унаследованный плагин SelectorSpread , который обеспечивает аналогичное поведение,
выключен.

Примечание:

Если на ваших узлах не предполагается наличие как kubernetes.io/hostname , так и
topology.kubernetes.io/zone Набор ярлыков , задайте свои собственные ограничения
вместо использования настроек Kubernetes по умолчанию.

Плагин PodTopologySpread не оценивает узлы, у которых нет
ключи топологии, указанные в ограничениях распространения.

Если вы не хотите использовать ограничения распространения Pod по умолчанию для вашего кластера,
вы можете отключить эти значения по умолчанию, установив defaultingType на List и оставив
пустой defaultConstraints в PodTopologySpread Конфигурация плагина :

  apiVersion: kubescheduler.config.k8s.io/v1beta1
вид: KubeSchedulerConfiguration

профили:
  - pluginConfig:
      - имя: PodTopologySpread
        аргументы:
          defaultConstraints: []
          defaultingType: List
  

Сравнение с PodAffinity / PodAntiAffinity

В Kubernetes директивы, относящиеся к «Affinity», управляют тем, как устроены поды.
запланировано — более упаковано или более разрознено.

• Для PodAffinity вы можете попытаться упаковать любое количество модулей в квалификационные
  домен (ы) топологии
• Для PodAntiAffinity только один модуль может быть запланирован в
  домен с единой топологией.

Для более точного управления вы можете указать ограничения распространения топологии для распределения
Модули в разных доменах топологии — для достижения высокой доступности или
экономия затрат. Это также может помочь при развертывании рабочих нагрузок обновления и горизонтальном масштабировании.
реплики плавно. Видеть
Мотивация
Больше подробностей.

Известные ограничения

• Уменьшение масштаба развертывания может привести к несбалансированному распределению модулей.
• Пакеты, сопоставленные с поврежденными узлами, соблюдаются. См. Выпуск 80921

Что дальше

Последнее изменение 30 декабря 2020 г., 20:57 по тихоокеанскому стандартному времени: добавление блоков кода в ограничения-распространения топологии пода.md (053103dc4)

Что такое модули Kubernetes? | Глоссарий VMware

Что такое модули Kubernetes?

Под — самая маленькая исполнительная единица в Kubernetes. Pod инкапсулирует одно или несколько приложений. Модули по своей природе эфемерны, и если модуль (или узел, на котором он выполняется) выходит из строя, Kubernetes может автоматически создать новую реплику этого модуля для продолжения операций. Поды включают один или несколько контейнеров (например, контейнеры Docker).

vSphere с Kubernetes 101 — Введение для администраторов vSphere

Загрузить сейчас

Модули

также предоставляют зависимости от среды, включая постоянные тома хранения (постоянное хранилище, доступное для всех модулей в кластере) и данные конфигурации, необходимые для запуска контейнер (ы) внутри контейнера.

Что делает под?

Модули представляют собой процессы, выполняемые в кластере. Ограничивая поды одним процессом, Kubernetes может сообщать о работоспособности каждого процесса, запущенного в кластере. Поды имеют:

• уникальный IP-адрес (который позволяет им взаимодействовать друг с другом)
• тома постоянного хранения (при необходимости)
• информацию о конфигурации, которая определяет, как должен работать контейнер.

Хотя большинство подов содержат один контейнер, многие из них будут иметь несколько контейнеров, которые тесно взаимодействуют друг с другом для выполнения желаемой функции.

Каковы преимущества капсулы?

Когда модули содержат несколько контейнеров, обмен данными и обмен данными между ними упрощается. Поскольку все контейнеры в модуле используют одно и то же сетевое пространство имен, они могут находить друг друга и обмениваться данными через localhost. Модули могут связываться друг с другом, используя IP-адрес другого модуля или ссылаясь на ресурс, который находится в другом модуле.

Модули могут включать в себя контейнеры, которые запускаются при запуске модуля, скажем, для выполнения инициализации, необходимой перед запуском контейнеров приложений.Кроме того, модули упрощают масштабируемость, позволяя создавать и отключать реплики модулей автоматически при изменении спроса.

Как работает под?

Поды создаются ресурсами рабочей нагрузки, называемыми контроллерами, которые управляют развертыванием, репликацией и работоспособностью подов в кластере. Например, если узел в кластере выходит из строя, контроллер обнаруживает, что модули на этом узле не отвечают, и создает замену модулей на других узлах.

Три наиболее распространенных типа контроллеров:

• Задания для временных заданий пакетного типа, которые будут выполнять задачу до завершения
• Развертывания для приложений, не имеющих состояния и постоянных, таких как веб-серверы (Серверы HPPT)
• StatefulSets для приложений с сохранением состояния и постоянных, таких как базы данных

Если модуль имеет несколько контейнеров, все они планируются вместе на одном сервере в кластере, будь то виртуальная машина или физический сервер.Все контейнеры в модуле совместно используют свои ресурсы и зависимости и могут координировать их выполнение и завершение. Например, поды могут содержать контейнеры init, которые запускаются до запуска контейнеров приложений, настраивая среду для следующих приложений.

Модули почти всегда создаются контроллерами, которые затем могут автоматически управлять жизненным циклом модулей, включая замену отказавших модулей, репликацию модулей при необходимости и удаление модуля с узлов кластера, когда они завершены или больше не нужны.

Контроллеры используют информацию в шаблоне модуля для создания модулей, а контроллеры гарантируют, что запущенные модули соответствуют развертыванию, определенному в шаблоне модуля, например, путем создания реплик, соответствующих количеству, определенному в развертывании.

Как поды взаимодействуют друг с другом?

При создании модуля ему назначается собственный уникальный IP-адрес. Если в модуле есть несколько контейнеров, они могут связываться друг с другом, просто используя localhost. Связь за пределами модуля достигается за счет открытия порта.Связь между модулями в кластере использует тот факт, что Kubernetes назначает частный IP-адрес кластера каждому pid в кластере, устраняя необходимость либо явно создавать ссылки между модулями, либо сопоставлять порты контейнера с портами хоста. Таким образом, все модули в кластере могут «видеть» друг друга без использования NAT.

Каковы основные команды kubectl?

Kubectl предоставляет ряд команд, которые позволяют пользователю создавать модули, запускать их с помощью развертываний, проверять состояние запущенных модулей и останавливать модули, которые больше не нужны.Для команд кодирования допустимы команды JSON (объектная нотация JavaScript) или YAML (YAML Ain’t Markup Language).

Обычно используемые команды kubectl перечислены ниже:

Get

Команда kubectl get отображает табличную информацию об одном или нескольких ресурсах. Информация может быть отфильтрована с помощью селекторов меток. Информация может отображаться только из существующего пространства имен или для всех пространств имен в кластере.

Команда «kubectl api-resources» создаст список всех поддерживаемых ресурсов, о которых вы можете «получить» информацию.Общий формат команды kubectl get:

$ kubectl get [(-o | —output =) json | yaml | wide | custom-columns = … | custom-columns-file = … | go -template = … | go-template-file = … | jsonpath = … | jsonpath-file = …] (ТИП [.ВЕРСИЯ] [. ГРУППА] [ИМЯ | -l метка] | ТИП [.VERSION] [. GROUP] / NAME …) [flags]

Create Pods

Pods создаются с помощью команды create в формате:

$ kubectl create -f FILENAME.

Например, команда:

kubectl create -f./mypod.yaml создаст новый модуль из YAML-файла «mypod»

Удалить модули

Команда «kubectl delete -f ./mypod.yaml» удалит модуль «mypod» из кластера. Удаление стручков — изящный процесс; Поды продолжат работу в течение льготного периода (по умолчанию 30 секунд), прежде чем будут принудительно завершены. При желании значение периода отсрочки может быть перезаписано флагом –grace-period.

Продукты, решения и ресурсы для VMware Kubernetes Pods

Pod | Документация по Kubernetes Engine | Google Cloud

Эта страница описывает объект Pod Kubernetes и его использование в
Google Kubernetes Engine.

Что такое стручок?

Pods — это самые маленькие и самые простые развертываемые объекты в Kubernetes. Стручок
представляет собой единственный экземпляр запущенного процесса в вашем кластере.

Pod содержат один или несколько контейнеров , например контейнеры Docker. Когда стручок
запускает несколько контейнеров, контейнеры управляются как единое целое и
делиться ресурсами пода. Как правило, запуск нескольких контейнеров в одном
Pod — это расширенный вариант использования.

Pods также содержат общие сетевые ресурсы и ресурсы хранения для своих контейнеров:

• Сеть: Модулям автоматически назначаются уникальные IP-адреса.Стручок
  контейнеры используют одно и то же сетевое пространство имен, включая IP-адрес и
  сетевые порты. Контейнеры в поде взаимодействуют друг с другом внутри
  Под на localhost .
• Хранилище: В модулях можно указать набор общих томов хранилища, которые могут быть
  разделены между контейнерами.

Pod можно рассматривать как автономный, изолированный «логический хост», который
содержит системные потребности приложения, которое оно обслуживает.

Pod предназначен для запуска одного экземпляра вашего приложения в кластере.Однако не рекомендуется создавать отдельные поды напрямую. Вместо этого вы
обычно создают набор идентичных модулей, называемых репликами , для запуска вашего
заявление. Такой набор реплицированных модулей создается и управляется
контроллер , например Развертывание. Контроллеры управляют жизненным циклом своих
составляющих Pods, а также может выполнять горизонтальное масштабирование , изменяя число
стручков по мере необходимости.

Хотя иногда вы можете напрямую взаимодействовать с модулями для отладки,
устранять неполадки или проверять их, настоятельно рекомендуется использовать
контроллер для управления вашими модулями.

Pod работают на узлах в вашем кластере. После создания Pod остается на своем узле.
пока его процесс не будет завершен, Pod удаляется, Pod выселяется из
узел из-за нехватки ресурсов, или узел выходит из строя. Если узел выходит из строя, стручки включаются.
узел автоматически планируется удалить.

Жизненный цикл стручка

Стручки недолговечны. Они не предназначены для вечной работы, и когда стручок
прекращено, оно не может быть возвращено. В общем, стручки не исчезают до тех пор, пока
они удаляются пользователем или контроллером.

Стручки не «излечиваются» и не восстанавливаются сами по себе. Например, если запланирован Pod
на узле, который позже выходит из строя, модуль удаляется. Точно так же, если Pod
вытесненный из узла по какой-либо причине, Pod не заменяет себя.

Каждый Pod имеет объект PodStatus API, который представлен статусом Pod
поле. Поды публикуют свою фазу в поле status: phase . В
Фаза модуля — это высокоуровневое резюме модуля в его текущем состоянии.

Когда ты бежишь
модуль kubectl get pod
чтобы проверить Pod, работающий в вашем кластере, Pod может находиться в одном из следующих
возможные фазы:

• Ожидание: Pod был создан и принят кластером, но один или несколько
  из его контейнеров еще не запущены. Эта фаза включает время, потраченное на то, чтобы
  запланировано на узле и загружает изображения.
• Выполняется: Pod привязан к узлу, и все контейнеры были
  созданный. По крайней мере, один контейнер запущен, находится в процессе запуска или
  перезапускается.
• Успешно: Все контейнеры в модуле успешно завершены.
  Прерванные модули не перезапускаются.
• Ошибка: Все контейнеры в Pod остановлены, и хотя бы один
  контейнер вышел из строя. Контейнер «терпит неудачу», если он выходит с
  ненулевой статус.
• Неизвестно: Невозможно определить состояние модуля.

Кроме того, PodStatus содержит массив с именем PodConditions , который
представлен в манифесте модуля как условий .Поле имеет тип
и поле статуса . условия указывает более конкретно условия
внутри модуля, которые определяют его текущий статус.

Поле типа может содержать PodScheduled , Ready , Initialized и
Не подлежит планированию . Поле статуса соответствует полю типа и может
содержат Истинный , Ложный или Неизвестный .

Примечание: Вы можете запустить kubectl get pod [POD_NAME] -o yaml , чтобы просмотреть
весь манифест, в том числе фаза и условия полей.

Создание модулей

Поскольку модули являются эфемерными, создавать модули напрямую не требуется.
Точно так же, поскольку Pods не могут ремонтировать или заменять себя, это не
рекомендовал для непосредственного создания подов.

Вместо этого вы можете использовать контроллер , например, Deployment, которое создает и
управляет Pods за вас.Контроллеры также полезны для развертывания обновлений, таких как
как изменение версии приложения, работающего в контейнере, потому что
Контроллер управляет всем процессом обновления за вас.

Под запрос

Когда Pod запускается, он
Запросы
количество процессора и памяти. Это помогает Kubernetes запланировать Pod на
соответствующий узел для выполнения рабочей нагрузки. Pod не будет запланирован на узле
у которого нет ресурсов для выполнения запроса модуля. Запрос — это
минимум объема ЦП или памяти, которые Kubernetes гарантирует поду.

Примечание: запросы Pod отличаются от Pod и работают вместе с ним.
пределы.

Вы можете настроить запросы ЦП и памяти для модуля в зависимости от ресурсов.
ваши приложения нуждаются в. Вы также можете указать запросы для индивидуальных
контейнеры, работающие в Pod. Имейте в виду следующее:

• Запрос по умолчанию для ЦП — 100 м. Это слишком мало для многих приложений,
  и, вероятно, намного меньше, чем количество ЦП, доступное на узле.
• Нет запроса памяти по умолчанию.Модуль без запроса памяти по умолчанию
  могут быть запланированы на узле без достаточного количества памяти для запуска модуля Pod
  рабочие нагрузки.
• Установка слишком маленького значения для запросов ЦП или памяти может привести к слишком большому количеству запросов.
  Модули или субоптимальная комбинация модулей, которые должны быть запланированы на данном узле.
  и снизить производительность.
• Установка слишком большого значения для запросов ЦП или памяти может привести к тому, что под
  быть непрограммируемым и увеличивать стоимость ресурсов кластера.
• В дополнение к настройке ресурсов Pod или вместо нее вы можете указать
  ресурсы для отдельных контейнеров, работающих в Pod.Если вы укажете только
  ресурсов для контейнеров, запросы Pod — это сумма запросов
  указаны для контейнеров. Если вы укажете оба, сумма запросов для
  все контейнеры не должны превышать запросов Pod.

Настоятельно рекомендуется настраивать запросы для ваших Pods на основе
от требований фактических рабочих нагрузок. Для получения дополнительной информации см.
Лучшие практики Kubernetes: запросы и ограничения ресурсов
в блоге Google Cloud.

Пределы пода

По умолчанию Pod не имеет верхней границы максимального объема ЦП или памяти.
можно использовать на узле.Вы можете установить
пределы
для управления объемом ЦП или памяти, которые ваш Pod может использовать на узле. Предел
максимум объема ЦП или памяти, которые Kubernetes гарантирует поду.

В дополнение к установке лимитов Pod или вместо них вы можете указать лимиты
для отдельных контейнеров, работающих в Pod. Если вы укажете лимиты только для
контейнеров, лимиты Pod — это сумма лимитов, установленных для
контейнеры. Однако каждый контейнер может получить доступ к ресурсам только до предела,
поэтому, если вы решите указать ограничения только для контейнеров, вы должны указать
лимиты для каждого контейнера.Если вы укажете оба, сумма лимитов для всех
контейнеры не должны превышать лимит Pod.

Примечание: Предел всегда должен быть больше или равен запросу того же типа.
ресурса. Если вы попытаетесь установить лимит ниже запроса, модуль Pod
контейнер не может работать, и регистрируется ошибка.

Ограничения не принимаются во внимание при планировании модулей, но
может предотвратить конкуренцию за ресурсы между модулями на одном узле и может предотвратить
Pod от причинения нестабильности системы на узле из-за истощения базового
операционная система ресурсов.

Примечание: ограничения для модулей отличаются от ограничений для модулей Pod и работают вместе с ним.
Запросы.

Настоятельно рекомендуется настроить ограничения для ваших модулей Pods в зависимости от
от требований фактических рабочих нагрузок. Для получения дополнительной информации см.
Лучшие практики Kubernetes: запросы и ограничения ресурсов
в блоге Google Cloud.

Шаблоны пакетов

Объекты контроллера

, такие как Deployments и StatefulSets, содержат
Pod template field. Шаблоны подов содержат
Спецификация Pod, которая определяет, как должен работать каждый Pod,
в том числе, какие контейнеры следует запускать в модулях и какие тома
Стручки должны монтироваться.

Объекты контроллера

используют шаблоны модулей для создания модулей и управления их «желаемыми»
состояние «в вашем кластере. При изменении шаблона модуля все будущие модули
отражают новый шаблон, но не все существующие модули.

Для получения дополнительной информации о том, как работают шаблоны Pod, см.
Создание развертывания в документации Kubernetes.

Управление узлами, на которых работает Pod

По умолчанию модули запускаются на узлах в пуле узлов по умолчанию для
кластер. Вы можете настроить пул узлов, который Pod выбирает явно, или
неявно:

• Вы можете явно принудительно развернуть Pod в конкретном пуле узлов,
  установка nodeSelector
  в манифесте Pod.Это заставляет Pod работать только на узлах в этом пуле узлов.

• Вы можете указать запросы ресурсов для контейнеров
  ты бежишь. Pod будет работать только на узлах, удовлетворяющих ресурсу
  Запросы. Например, если определение Pod включает контейнер, который требует
  четыре ЦП, Служба не будет выбирать модули, работающие на Узлах с двумя ЦП.

Шаблоны использования подов

Стручки

можно использовать двумя основными способами:

• Модули, запускающие один контейнер. Самый простой и распространенный паттерн стручка
  один контейнер на под, где один контейнер представляет собой весь
  заявление. В этом случае вы можете думать о Pod как о оболочке.
• Модули, запускающие несколько контейнеров, которые должны работать вместе. Стручки с
  несколько контейнеров в основном используются для поддержки совместно размещенных, совместно управляемых
  программы, которым необходимо делиться ресурсами. Эти расположенные вместе контейнеры могут образовывать
  единая связная единица обслуживания — один контейнер, обслуживающий файлы из общей
  volume, пока другой контейнер обновляет или обновляет эти файлы.Обертывания Pod
  эти контейнеры и ресурсы хранения вместе как единый управляемый объект.

Каждый Pod предназначен для запуска одного экземпляра данного приложения. Если ты хочешь
для запуска нескольких экземпляров вы должны использовать один Pod для каждого экземпляра
заявление.