Самый примитивный драйвер контроллера должен поддерживать как минимум две операции

Обновлено: 20.11.2024

Много вкусов. В общих чертах их можно разделить на: Блочные устройства Дисковые накопители, ленточные накопители, USB-накопители и т. д. На абстрактном уровне они выглядят как большая куча байтов, организованных в блоки определенного фиксированного размера. (Технически использование блоков — это оптимизация для амортизации затрат на управление многими байтами данных.) Типичные операции: чтение (блоки), запись (блоки), поиск (следующий блок для чтения/записи). Символьные устройства

Также называются потоковыми устройствами. Клавиатуры, модемы, принтеры, звуковые карты, роботы, пушки USB Nerf. Они выглядят как поток байтов без особой структуры, навязанной устройством. Типичные операции: чтение, запись. Некоторые могут предоставлять очень сложную функциональность в дополнение к тому, что предоставляется необработанным устройством; Драйверы терминала Unix являются хорошим (?) Примером. Сетевые устройства Несколько похожи на потоковые устройства, но отличаются встроенными высокоуровневыми сетевыми протоколами, которые могут добавлять дополнительную структуру (например, дейтаграммы UDP, соединения TCP).

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

>

Есть также несколько проблем, которые быстро возникают при разработке пользовательского интерфейса ввода-вывода: асинхронный и синхронный ввод-вывод

Асинхронный ввод-вывод не блокируется: программа (или ЦП) продолжает работу после запуска операции ввода-вывода и получает уведомление об окончании операции с помощью прерывания. Большинство операций ввода-вывода на аппаратном уровне асинхронны — это хорошо, потому что ввод-вывод медленный. Но программировать асинхронный ввод-вывод на уровне пользователя сложно. Таким образом, ядро ​​обычно представляет синхронный или блокирующий интерфейс, в котором низкоуровневые асинхронные операции кажутся синхронными благодаря простой возможности блокировки ожидающих их процессов. Буферизация Данные с устройств ввода-вывода часто поступают в неудобное время или в неудобных единицах измерения. Использование буферов в устройствах и в ядре может частично скрыть это от пользователя. Однако хранение данных в буферах может замедлить ввод-вывод из-за необходимости чрезмерного копирования, поэтому приходится идти на компромиссы. Совместное использование Можно ли совместно использовать или мультиплексировать устройство ввода-вывода между несколькими процессами? Если это так, ядро ​​должно взять на себя ответственность за обработку нескольких запросов. Примеры совместно используемых устройств включают дисковые накопители (обычно через высокоуровневый интерфейс файловой системы), дисплеи (через оконные системы) или аудиоустройства (если вы не используете старую версию Linux). Другие устройства, такие как ленточные накопители или модемы, могут быть недоступны для совместного использования, и ядро ​​должно обеспечить, чтобы только один процесс мог использовать каждое из них одновременно. Именование

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

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

2.1. Контроллеры

Мы можем думать о каждом устройстве как о состоящем из некоторого физического объекта (фактического устройства) и части аппаратного обеспечения, которое представляет собой абстрактный интерфейс объекта к шине. Этот последний элемент аппаратного обеспечения называется контроллером устройства, и именно с ним взаимодействует ЦП. Остается вопрос, как структурировать интерфейс между ЦП и контроллером устройства.

2.2. Инструкции ввода и вывода

Многие ЦП предоставляют инструкции IN и OUT для выполнения операций ввода-вывода. Они выглядят как инструкции MOV, используемые для доступа к памяти, и принимают адреса (порты) в качестве аргументов, которые могут даже передаваться по той же адресной шине, что и операции с памятью, но контакт на ЦП сигнализирует о том, что они должны интерпретироваться как операции ввода-вывода, а не как операции с памятью, поэтому вспомогательное оборудование направляет их на соответствующее устройство.

  • Можно использовать отдельную низкоскоростную шину для ввода-вывода и высокоскоростную шину для памяти.

2.3. Ввод/вывод с отображением памяти

Здесь вместо использования отдельного адресного пространства для ввода-вывода мы используем то же адресное пространство, что и для памяти. Аппаратное обеспечение преобразования адресов берет на себя ответственность за перенаправление адресов ввода-вывода на устройства ввода-вывода.

  • Ввод/вывод выглядит так же, как доступ к памяти, который мы уже знаем, как делать.
  • Обработка ввода-вывода как памяти может плохо взаимодействовать с системой кэширования.
  • Не допускается использование нескольких автобусов.
  • Переносит сложность с ЦП на оборудование шины.

2.4. Гибридный подход

Одним из распространенных подходов является использование как инструкций ввода-вывода, так и ввода-вывода с отображением памяти. Идея состоит в том, что инструкции ввода-вывода можно использовать для небольших значений, которые быстро изменяются (например, регистры управления), а отображение памяти можно использовать для больших фрагментов данных, которые считываются или записываются в большом количестве (например, память дисплея). Так, например, архитектура ПК выделяет диапазон памяти 0xA0000–0xFFFF0 (640K–1M) для ввода-вывода с отображением памяти, и именно здесь находится память дисплея VGA и т. д.

Этот подход по-прежнему требует, чтобы контроллер шины перенаправлял адреса ввода-вывода, отображаемые в памяти, на шину ввода-вывода.

2.5. Прямой доступ к памяти (DMA)

Для блочных устройств часто имеет смысл обойти ЦП и предоставить им прямой доступ к памяти. Обычно это делается путем создания моста между шиной ввода-вывода и шиной памяти в виде контроллера прямого доступа к памяти. Контроллер прямого доступа к памяти обращается к устройствам ввода-вывода точно так же, как ЦП: он посылает те же инструкции управления и считывает данные по той же шине. Но он гораздо более ограничен в том, что он делает с данными; все, что он может сделать, это поместить его в память по физическому адресу памяти, указанному ЦП (через управляющие регистры на контроллере DMA, доступ к которому ЦП осуществляет через шину ввода-вывода), и выдать прерывание, когда операция будет выполнена.

Обратите внимание: поскольку ЦП и контроллер прямого доступа к памяти используют одни и те же шины, необходим некоторый механизм управления параллелизмом, чтобы они не мешали друг другу. (Аналогичная проблема возникает с несколькими процессорами). Здесь есть несколько вариантов того, насколько агрессивно контроллер DMA относится к захвату шины. Вежливый DMA-контроллер может ограничиться кражей циклов, время от времени захватывая шину на несколько тактов, чтобы ЦП никогда не терял контроль над шиной более чем на несколько тактов. Менее вежливый, но более эффективный контроллер прямого доступа к памяти может использовать пакетный режим, когда он захватывает память и шины ввода-вывода на время, достаточное для завершения операции чтения или записи полного блока или, возможно, даже нескольких таких операций. Недостатком этого подхода является то, что ЦП может зависнуть, потому что в его кеше недостаточно данных для продолжения, пока операция ввода-вывода не будет завершена.

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

ЦП управляет всем сам. Контроллер устройства — это жалкая заглушка, единственная цель которой — транслировать команды шины ЦП непосредственно на оборудование ввода-вывода. Примерами являются WinModems, некоторые контроллеры принтеров, некоторые очень ранние примитивные графические контроллеры. Преимущество: позволяет использовать более дешевое оборудование; может позволить очень сложное программирование ввода-вывода (удобно с модемами). Недостаток: это как нанять механика Формулы-1 для замены масла; ЦП должен опрашивать устройство ввода-вывода, чтобы узнать, нужно ли ему что-то делать; в худшем случае устройство ввода-вывода съедает весь ЦП, блокируя все остальное, пока выполняется операция ввода-вывода. Контроллер устройств ввода-вывода, управляемый прерываниями, выполняет большую часть работы, уведомляя ЦП о завершении. CPU по-прежнему должен сам извлекать данные. Ввод-вывод на основе прямого доступа к памяти Контроллер прямого доступа к памяти берет на себя роль ЦП, прерывая ЦП, когда данные доступны в памяти. Преимущество: минимальная нагрузка на процессор, особенно в виде меньшего количества прерываний, так как DMA-контроллер может выполнять большую буферизацию. Недостаток: максимальная аппаратная сложность.

С самого начала у нас есть обработчики прерываний

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

Интерфейс более высокого уровня, который переводит видимые пользователю абстракции устройств (например, блочные устройства) в низкоуровневые заклинания, отправляемые контроллерам устройств. Обычно в ядре из-за необходимости в привилегированных инструкциях ввода-вывода. В портативных операционных системах часто разделяются на верхнюю половину, которая не зависит от машины, и нижнюю половину, которая зависит от архитектуры ЦП. Нижняя половина выполняет машинно-специфические инструкции ввода-вывода и обычно обеспечивает внутреннюю часть процедуры обслуживания прерывания. Аппаратно-независимое программное обеспечение ввода-вывода Все, что не зависит от конкретных деталей устройства, помимо его абстрактного описания, например, символ или блочное устройство. Это может включать механизмы более высокого уровня, такие как сетевые стеки или файловые системы, а также механизмы более низкого уровня, такие как управление виртуальной памятью или системы планирования ввода-вывода. Библиотеки ввода-вывода на уровне пользователя

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

4.1. Архитектура драйвера устройства

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

4.1.1. Как выглядит модуль драйвера устройства

Сначала нам нужно установить стандартный интерфейс. Для блочного устройства в стиле Unix у нас может быть что-то вроде:

Символьное устройство было бы аналогичным, за исключением того, что оно не обеспечивало бы seek.

По сути, это реализация на C таблицы методов C++ или Java. Лазейка ioctl предназначена для предоставления дополнительных методов для устройств, которые в них нуждаются (например, для установки параметров на диске, отключения автоматического огня на пушке Nerf или переключения светодиодов на клавиатуре). В реальном объектно-ориентированном языке программирования это было бы реализовано путем создания подклассов.

Поскольку разработка ядра продолжается и определенные операции начинают появляться на нескольких устройствах, они, скорее всего, переместятся из контейнера ioctl в основную структуру. Конечным результатом может быть что-то вроде структуры данных file_operations из ядра Linux 2.6 (см. /usr/src/linux/include/linux/fs.h):

Здесь аргументы struct file * являются указателями на внутреннюю структуру данных ядра, связанную с устройством (которое притворяется файлом с точки зрения файловой системы), эквивалентно self или this в объектно-ориентированном языке. Это позволяет использовать одни и те же процедуры драйвера для нескольких похожих устройств.

4.1.2. Загрузка драйвера устройства

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

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

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

4.1.3. Риски

Загружаемые модули ядра представляют наибольший риск для целостности ядра, поскольку они часто пишутся обезьянами, но запускаются с полным доступом к внутренним компонентам ядра. Эмпирическое правило гласит, что драйверы устройств содержат на 5-10 ошибок больше на тысячу строк кода, чем основной код ядра, и, в отличие от пользовательского процесса, неисправный драйвер устройства может вывести из строя всю систему. В худшем случае модули ядра могут быть злонамеренно использованы для создания руткитов и подобных вредоносных программ. Как минимум это означает, что мы не можем позволить никому загружать новые модули в ядро. В долгосрочной перспективе возникает необходимость обеспечить лучшее сдерживание драйверов устройств либо путем использования строго типизированных языков и/или подписанного кода для ограничения или, по крайней мере, проверки их поведения, либо путем вытеснения их в менее деструктивную часть системы. используя обман микроядра.

4.2. Аппаратно-независимые компоненты ввода/вывода

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

Давайте посмотрим, как можно написать драйвер для консоли (со встроенным VGA-дисплеем) и клавиатуры на ПК. Мы можем захотеть или не захотеть разделить их на отдельные устройства, но на данный момент давайте представим, что мы объединили их вместе как односимвольное устройство, где запись на устройство выводит на экран, а чтение с устройства считывает символы с клавиатура.

5.1. Вывод

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

  1. Принимает буфер символов и копирует их в экранную память в местонахождение текущего курсора.
  2. Обновляет положение курсора.
  3. При необходимости переворачивает или прокручивает экран (что может потребовать значительного копирования!)

Эта подпрограмма обычно вызывается внутри потока ядра какого-либо процесса после того, как она была отправлена ​​системным вызовом write более высокого уровня.

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

На практике стоимость выполнения нескольких системных вызовов означает, что все ОС, кроме самых ленивых, предоставляют некоторый механизм для обработки escape-последовательностей. Этот выбор аналогичен «маленькому языку», который появляется в спецификаторах формата printf (или операторах FORTRAN FORMAT перед ними), где чисто процедурный интерфейс снова заменяется обработкой строк.

5.2. Ввод

    Обработка прерывания. Как минимум, нам нужно где-то сохранить входящий скан-код.

Интересно, что у нас есть много вариантов, где выполнять эти операции. Если наша цель состоит в том, чтобы выйти из обработчика прерывания как можно быстрее, мы могли бы просто выполнить здесь шаг 1, вставив входящий код сканирования куда-нибудь в кольцевой буфер и немедленно вернувшись. Затем этапы трансляции и доставки могут выполняться любым из (а) потоком ядра, который время от времени просыпается, когда кольцевой буфер не пуст (семафор!) и выполняет трансляцию (подход монолитного ядра); (б) демон пользовательского пространства, который делает то же самое (микроядерный подход); или (c) стандартная библиотечная подпрограмма, использующая сопоставление адресного пространства, которое обеспечивает прямой доступ к буферу необработанного кода сканирования (экзоядерный подход). Чем дальше мы делаем процесс перевода и доставки от ядра ядра, тем больше контроля мы даем пользователю (например, возможность заменять различные схемы перевода, возможность вставлять поддельные события клавиатуры во входной поток, возможность создать причудливый демон диспетчеризации клавиатуры, который отправляет все гласные в процесс 1 и все согласные в процесс 2 — кто знает?), но тем больше мы накладываем затрат. Для ввода с клавиатуры затраты, вероятно, будут довольно низкими, независимо от того, что мы делаем, поэтому, вероятно, лучше всего использовать простой подход. Это, вероятно, включает в себя предоставление необработанного непереведенного ввода или выполнение перевода на уровне ядра, возможно, даже в обработчике прерываний (поскольку это не очень дорого).

У нас также есть независимый выбор когда доставлять персонажей. Многие процессы могут заботиться только о получении символов, когда пользователь нажимает ввод, и могут требовать, чтобы ОС обрабатывала такие детали, как буферизация входящих символов и обработка простых команд редактирования. Есть хороший шанс, что процесс также захочет, чтобы ОС выводила на экран каждый введенный символ (по крайней мере, некоторое время). Логичным ответом будет предоставление сложного драйвера терминала, который справляется со всеми этими задачами, доставляя предварительно обработанные строки текста в процесс с помощью системных вызовов read (если драйвер терминала находится в ядре) или Механизм IPC (если это не так — в этом случае мы можем дать механизму IPC файловый интерфейс, чтобы принимающий процесс не заметил). Чем сложнее этот драйвер терминала, тем больше стимулов для его удаления из ядра, чтобы ошибки не портили ничего другого, но тем больше стимулов для того, чтобы оставить его в ядре, чтобы он имел быстрый доступ к -данные ядра. Неясно, в пределе, когда драйвер терминала будет включать оконную систему, какой подход лучше; широко используются как внутренние оконные системы (Windows), так и внешние оконные системы (X11, используемые в Linux и OS/X).

Для блочных устройств, таких как диски, ситуация более сложная, потому что скорость передачи данных намного выше (~500 Мбит/с против ~10 байт/с для клавиатуры), а задержка представляет собой большую проблему, поскольку может ожидание следующего доступа к диску. Поэтому нам нужен драйвер диска, который может буферизовать и мультиплексировать доступ к диску, чтобы процессы (и внутренние потоки ядра, такие как пейджер виртуальной памяти) думали, что они происходят быстро, даже если это не так. Нам также приходится иметь дело с тем фактом, что дисковые операции — это длительные, многоступенчатые процессы, включающие как ввод, так и вывод (даже если мы перемещаем данные только в одном направлении), поэтому мы не можем надеяться просто похоронить все в одном месте. обработчик прерываний.

Мы можем упростить конструкцию, назначив поток ядра (или демон пользовательского пространства) для управления каждым диском.Входные данные для потока — это очередь запросов дисковых операций, которые вставляются высокоуровневыми частями подсистемы ввода-вывода, и поток работает в цикле, где он выбирает операцию для выполнения (возможно, не по порядку, чтобы оптимизировать планирование дисков). — мы поговорим об этом подробнее, когда будем говорить о файловых системах), посылает соответствующие команды контроллеру диска или контроллеру DMA, а затем приостанавливается до тех пор, пока дисковая операция не будет завершена (о чем будет сигнализировать обработчик прерываний, работа которого чтобы разбудить поток драйвера). Затем поток может доставить результаты запрашивающему процессу или потоку ядра через внутренние буферы ядра или высокоуровневый механизм IPC (первый вариант, скорее всего, будет быстрее, поскольку может потребовать меньшего количества операций копирования).

Драйвер eri Fast Ethernet — это многопоточный, загружаемый, клонируемый аппаратный драйвер на основе STREAMS, поддерживающий интерфейс провайдера канала передачи данных без установления соединения dlpi(7P) через eri Контроллер Fast-Ethernet. Несколько устройств eri, установленных в системе, поддерживаются драйвером.

Драйвер eri обеспечивает базовую поддержку оборудования eri и управляет устройством eri. Функции включают инициализацию чипа, передачу и прием кадров, многоадресную и неразборчивую поддержку, а также восстановление после ошибок и создание отчетов.

Устройство eri предоставляет сетевые интерфейсы 100Base-TX с использованием ASIC RIO SUN и внутреннего приемопередатчика. ASIC RIO обеспечивает интерфейс PCI и функции MAC. Функции физического уровня обеспечиваются внутренним приемопередатчиком, который подключается к разъему RJ-45.

Стандарт 100Base-TX определяет протокол автосогласования для автоматического выбора режима и скорости работы. Внутренний приемопередатчик способен выполнять автосогласование с использованием удаленного конца канала (партнера по каналу) и получает возможности удаленного конца. Он выбирает режим работы с наивысшим общим знаменателем на основе приоритетов. Он также поддерживает принудительный режим работы, при котором драйвер выбирает режим работы.

ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ПРИЛОЖЕНИЙ

Специальное устройство клонирования /dev/eri используется для доступа ко всем контроллерам eri, установленным в системе.

Эри и DLPI

Драйвер eri – это поставщик службы канала передачи данных "стиле 2". Все сообщения типа M_PROTO и M_PCPROTO интерпретируются как примитивы DLPI. Допустимые примитивы DLPI определены в файлах . Дополнительную информацию см. в dlpi(7P).

От пользователя требуется явное сообщение DL_ATTACH_REQ, чтобы связать открытый поток с конкретным устройством (ppa). Идентификатор ppa интерпретируется как тип данных целое число без знака и указывает номер соответствующего экземпляра устройства (модуля). Драйвер возвращает ошибку (DL_ERROR_ACK), если значение поля ppa не соответствует действительному номеру экземпляра устройства для этой системы. Устройство инициализируется при первом подключении и деинициализируется (останавливается) при последнем отключении.

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

Максимальное количество SDU – 1500 (ETHERMTU – определено в ).

Минимальный SDU – 0.

Длина адреса dlsap составляет 8.

Тип MAC: DL_ETHER.

Значения длины sap равны –2, что означает, что за компонентом физического адреса сразу следует 2-байтовый компонент sap в адресе DLSAP. .

Сервисный режим DL_CLDLS.

Дополнительное качество обслуживания (QOS) в настоящее время не поддерживается, поэтому поля QOS равны 0.

Стиль поставщика – DL_STYLE.

Версия: DL_VERSION_2.

Значением широковещательного адреса является широковещательный адрес Ethernet/IEEE (0xFFFFFF).

Находясь в состоянии DL_ATTACHED, пользователь должен отправить DL_BIND_REQ, чтобы связать определенный SAP (указатель доступа к службе) с потоком. Драйвер eri интерпретирует поле sap в DL_BIND_REQ как «тип» Ethernet, поэтому действительные значения для sap находятся в диапазоне [0-0xFFFF]. В любой момент времени к потоку может быть привязан только один тип Ethernet.

Если пользователь выбирает sap со значением 0, приемник будет работать в режиме IEEE 802.3. Предполагается, что все кадры, полученные от носителя, имеющего поле типа Ethernet в диапазоне [0-1500], являются кадрами 802.3 и направляются вверх по всем открытым потокам, которые привязаны к sap значение 0. Если более одного потока находятся в режиме 802.3, кадр будет продублирован и направлен в несколько потоков как сообщения DL_UNITDATA_IND.

При передаче драйвер проверяет поле sap в DL_BIND_REQ, чтобы определить, равно ли значение 0 или поле типа Ethernet в диапазоне [0-1500]. Если одно из этих значений истинно, драйвер вычисляет длину сообщения, не включая начальный M_PROTO mblk (блок сообщения), всех последующих сообщений DL_UNITDATA_REQ, и передает кадры 802.3, имеющие это значение в поле длины заголовка кадра MAC.

Формат адреса DLSAP драйвера eri состоит из 6-байтового компонента физического (Ethernet) адреса, за которым сразу же следует 2-байтовый компонент sap (type), образуя 8-байтовый компонент. DLSAP-адрес. Приложения не должны жестко кодировать этот конкретный формат адреса DLSAP, зависящий от реализации, а должны использовать информацию, возвращенную в примитиве DL_INFO_ACK, для составления и разложения адресов DLSAP. Длина sap, полная длина DLSAP и sap/физический порядок включены в DL_INFO_ACK. Длину физического адреса можно вычислить путем вычитания sap из полной длины адреса DLSAP или с помощью DL_PHYS_ADDR_REQ для получения текущего физического адреса, связанного с потоком.

Находясь в состоянии DL_BOUND, пользователь может передавать кадры по Ethernet, отправляя сообщения DL_UNITDATA_REQ драйверу eri. Драйвер eri направит полученные кадры Ethernet вверх по всем открытым и связанным потокам, имеющим sap, соответствующий типу Ethernet, как сообщения DL_UNITDATA_IND. Полученные кадры Ethernet дублируются и при необходимости направляются в несколько открытых потоков. Адрес DLSAP, содержащийся в сообщениях DL_UNITDATA_REQ и DL_UNITDATA_IND, состоит как из sap (тип), так и из физического (Ethernet) компонента.

Примитивы eri

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

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

Примитивы DL_PROMISCON_REQ и DL_PROMISCOFF_REQ с установленным флагом DL_PROMISC_PHYS в поле dl_level включают/выключают прием все кадры беспорядочного режима на носителе, включая кадры, сгенерированные локальным хостом. При использовании с установленным флагом DL_PROMISC_SAP включает/отключает прием всех значений sap (тип Ethernet). При использовании с установленным флагом DL_PROMISC_MULTI включает/отключает прием всех групповых адресов многоадресной рассылки. Влияние каждого из них всегда зависит от потока и не зависит от других конфигураций sap и физического уровня в этом или других потоках.

Примитив DL_PHYS_ADDR_REQ возвращает 6-октетный Ethernet-адрес, который в настоящее время связан (присоединен) к потоку в примитиве DL_PHYS_ADDR_ACK. Этот примитив действителен только в состояниях, следующих за успешным DL_ATTACH_REQ.

Примитив DL_SET_PHYS_ADDR_REQ изменяет 6-октетный адрес Ethernet, который в настоящее время связан (присоединен) к этому потоку. Учетные данные процесса, который первоначально открыл этот поток, должны быть суперпользователями, иначе EPERM возвращается в DL_ERROR_ACK. Этот примитив является деструктивным, поскольку влияет на все текущие и будущие потоки, подключенные к этому устройству. M_ERROR отправляется всем другим потокам, подключенным к этому устройству, когда этот примитив успешно работает в этом потоке. После изменения все потоки, впоследствии открытые и подключенные к этому устройству, получат этот новый физический адрес. После изменения физический адрес останется до тех пор, пока этот примитив не будет использован для повторного изменения физического адреса или система не будет перезагружена, в зависимости от того, что произойдет раньше.

Эри ДРАЙВЕР

По умолчанию драйвер eri выполняет автосогласование для выбора режима и скорости канала, который может находиться в одном из следующих режимов, как описано в стандарте 100Base-TX:

Драйвер SUNW,qfe Quad Fast-Ethernet — это многопоточный, загружаемый, клонируемый аппаратный драйвер STREAMS, поддерживающий интерфейс провайдера канала передачи данных без установления соединения, dlpi(7P), через контроллер SUNW,qfe Quad Fast-Ethernet. Несколько контроллеров SUNW,qfe, установленных в системе, поддерживаются драйвером. Драйвер qfe обеспечивает базовую поддержку оборудования SUNW,qfe. Он используется для управления устройством SUNW,qfe. Функции включают инициализацию чипа, передачу и прием кадров, многоадресную и неразборчивую поддержку, а также восстановление после ошибок и создание отчетов.

SUNW,qfe

Устройство SUNW,qfe предоставляет сетевой интерфейс 100Base-TX.Существует два типа устройств SUNW,qfe: один с поддержкой Sbus, а другой с поддержкой интерфейса шины PCI. Устройство Sbus SUNW,qfe использует FEPS ASIC от Sun, который обеспечивает интерфейс Sbus и функции MAC. Устройство PCI SUNW,qfe использует PFEX ASIC от Sun для обеспечения интерфейса PCI и функций MAC. Оба подключаются к встроенному приемопередатчику 100Base-TX, который подключается к разъему RJ45 для обеспечения функций физического уровня и внешнего подключения.

Стандарт 100Base-TX определяет протокол «автосогласования» для автоматического выбора режима и скорости работы. Внутренний приемопередатчик способен выполнять автосогласование с удаленным концом канала (партнером по каналу) и получает возможности удаленного конца. Он выбирает режим работы с наивысшим общим знаменателем на основе приоритетов. Он также поддерживает принудительный режим работы, когда драйвер может выбрать режим работы.

ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ПРИЛОЖЕНИЙ

Клонирование специального символьного устройства /dev/qfe используется для доступа ко всем контроллерам SUNW,qfe, установленным в системе.

qfe и DLPI

Драйвер qfe — это поставщик услуг канала передачи данных «стиль 2». Все сообщения типа M_PROTO и M_PCPROTO интерпретируются как примитивы DLPI. Допустимые примитивы DLPI определены в файлах . Обратитесь к dlpi(7P) для получения дополнительной информации. Явное сообщение DL_ATTACH_REQ от пользователя требуется, чтобы связать открытый поток с конкретным устройством (ppa). Идентификатор ppa интерпретируется как тип данных unsigned long и указывает номер соответствующего экземпляра устройства (модуля). Драйвер возвращает ошибку (DL_ERROR_ACK), если значение поля ppa не соответствует действительному номеру экземпляра устройства для этой системы. Устройство инициализируется при первом подключении и деинициализируется (останавливается) при последнем отключении.

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

Максимальное количество SDU – 1500 (ETHERMTU – определено в ).

Минимальный SDU – 0.

Длина адреса dlsap составляет 8.

Тип MAC: DL_ETHER.

Значения длины sap равны -2, что означает, что за компонентом физического адреса сразу следует 2-байтовый компонент sap в адресе DLSAP.

Сервисный режим DL_CLDLS.

В настоящее время дополнительная поддержка качества обслуживания (QOS) не включена, поэтому поля QOS равны 0.

Стиль поставщика – DL_STYLE2.

Версия: DL_VERSION_2.

Значением широковещательного адреса является широковещательный адрес Ethernet/IEEE (0xFFFFFF).

Находясь в состоянии DL_ATTACHED, пользователь должен отправить DL_BIND_REQ, чтобы связать конкретный указатель доступа к службе SAP с потоком. Драйвер qfe интерпретирует поле sap в DL_BIND_REQ как «тип» Ethernet, поэтому действительные значения для sap находятся в диапазоне [0-0xFFFF]. В любой момент времени к потоку может быть привязан только один тип Ethernet.

Если пользователь выбирает sap со значением 0, приемник будет находиться в «режиме 802.3». Все кадры, полученные от носителя, имеющего поле «тип» в диапазоне [0-1500], считаются кадрами 802.3 и направляются вверх по всем открытым потокам, которые связаны до значения sap 0. Если в «режиме 802.3» находится более одного потока, кадр будет продублирован и направлен вверх по нескольким потокам в виде сообщений DL_UNITDATA_IND.

При передаче драйвер проверяет поле sap в DL_BIND_REQ, если значение sap равно 0, и если поле типа назначения находится в диапазоне [0-1500]. Если любой из них верен, драйвер вычисляет длину сообщения, не включая начальный M_PROTO mblk (блок сообщения), всех последующих сообщений DL_UNITDATA_REQ и передает кадры 802.3, которые имеют это значение. значение в поле длины заголовка кадра MAC.

Формат адреса DLSAP драйвера qfe состоит из 6-байтового компонента физического (Ethernet) адреса, за которым сразу следует 2-байтовый sap (тип ) компонента, создающего 8-байтовый адрес DLSAP. Приложения не должны жестко кодировать этот конкретный формат адреса DLSAP, зависящий от реализации, а должны использовать информацию, возвращенную в примитиве DL_INFO_ACK, для составления и разбиения адресов DLSAP. Длина sap, полная длина DLSAP и sap/физический порядок включены в DL_INFO_ACK. Длина физического адреса может быть вычислена путем вычитания длины sap из полной длины адреса DLSAP или с помощью DL_PHYS_ADDR_REQ для получения текущий физический адрес, связанный с потоком.

Находясь в состоянии DL_BOUND, пользователь может передавать кадры по Ethernet, отправляя сообщения DL_UNITDATA_REQ драйверу qfe. Драйвер qfe направит полученные кадры Ethernet вверх по всем тем открытым и связанным потокам, имеющим sap, который соответствует типу Ethernet, как сообщения DL_UNITDATA_IND. Полученные кадры Ethernet дублируются и при необходимости направляются в несколько открытых потоков. Адрес DLSAP, содержащийся в сообщениях DL_UNITDATA_REQ и DL_UNITDATA_IND, состоит как из sap (тип), так и из физического (Ethernet ) компонентов.

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

qfe Примитивы

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

Примитивы DL_PROMISCON_REQ и DL_PROMISCOFF_REQ с флагом DL_PROMISC_PHYS, установленным в поле dl_level, включают или выключают прием все кадры на носителе («неразборчивый режим»), включая кадры, сгенерированные локальным хостом.

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

Примитив DL_PHYS_ADDR_REQ возвращает 6-октетный Ethernet-адрес, который в настоящее время связан (присоединен) к потоку в примитиве DL_PHYS_ADDR_ACK. Этот примитив действителен только в состояниях, следующих за успешным DL_ATTACH_REQ.

Примитив DL_SET_PHYS_ADDR_REQ изменяет 6-октетный адрес Ethernet, который в настоящее время связан (присоединен) к этому потоку. Учетные данные процесса, который первоначально открыл этот поток, должны быть root. В противном случае EPERM возвращается в сообщении DL_ERROR_ACK. Этот примитив является деструктивным, поскольку влияет на все другие текущие и будущие потоки, подключенные к этому устройству. M_ERROR отправляется всем другим потокам, подключенным к этому устройству, когда этот примитив успешно работает в этом потоке. После изменения все потоки, впоследствии открытые и подключенные к этому устройству, получат этот новый физический адрес. После изменения физический адрес останется до тех пор, пока этот примитив не будет использован для повторного изменения физического адреса или система не будет перезагружена, в зависимости от того, что произойдет раньше.

драйвер qfe

По умолчанию драйвер qfe выполняет «автосогласование» для выбора режима и скорости канала.

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

100 Мбит/с, полный дуплекс

100 Мбит/с, полудуплекс

10 Мбит/с, полный дуплекс

10 Мбит/с, полудуплекс

Эти скорости и режимы описаны в стандарте 100Base-TX.

Протокол автосогласования автоматически выбирает:

Режим работы (полудуплексный или дуплексный)

Скорость (100 Мбит/с или 10 Мбит/с)

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

Получает все режимы работы, поддерживаемые Link Partner

Сообщает о своих возможностях Link Partner

Выбирает режим работы с наивысшим общим знаменателем на основе приоритетов.

Наивысший приоритет имеет скорость 100 Мбит/с, полнодуплексный режим; наименьший приоритет имеет скорость 10 Мбит/с, полудуплекс.

Приемопередатчик 100Base-TX поддерживает все рабочие скорости и режимы, перечисленные выше. По умолчанию для выбора скорости и режима соединения, а также общего режима работы с партнером по соединению используется автосогласование.

Иногда пользователю может потребоваться выбрать скорость и режим ссылки. Устройство SUNW,qfe поддерживает программируемые параметры IPG (Inter-Packet Gap) ipg1 и ipg2. По умолчанию драйвер устанавливает ipg1 на 8 байт-раз и ipg2 на 4 байт-раз (которые стандартные значения). Иногда пользователь может захотеть изменить эти значения в зависимости от того, поддерживает ли драйвер скорость 10 Мбит/с или 100 Мбит/с, и, соответственно, IPG будет установлено на 9,6 или 0,96 микросекунды.

qfe Список параметров

Драйвер qfe позволяет устанавливать и получать различные параметры для устройства SUNW,qfe.Список параметров включает:

текущий статус трансивера

текущий статус ссылки

возможности локального трансивера

связать возможности партнеров

Локальный трансивер имеет два набора возможностей: один набор отражает возможности оборудования, которые являются параметрами только для чтения (RO), а второй набор, который отражает значения, выбранные пользователем, используется при выборе скорости. . Имеются возможности чтения/записи (RW). Во время загрузки эти два набора возможностей будут одинаковыми. Возможности Link Partner также доступны только для чтения, поскольку текущие значения этих параметров по умолчанию доступны только для чтения и не могут быть изменены.

ReplicationController обеспечивает одновременную работу определенного количества реплик pod. Другими словами, ReplicationController обеспечивает постоянную работу и доступность модуля или однородного набора модулей.

Как работает контроллер репликации

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

ReplicationController часто обозначается аббревиатурой "rc" в обсуждениях, а также в качестве ярлыка в командах kubectl.

Простым случаем является создание одного объекта ReplicationController для надежного запуска одного экземпляра Pod на неопределенный срок. Более сложный вариант использования — запуск нескольких идентичных реплик реплицируемой службы, например веб-серверов.

Запуск примера ReplicationController

В этом примере конфигурация ReplicationController запускает три копии веб-сервера nginx.

Запустите пример задания, загрузив файл примера и выполнив следующую команду:

Выход примерно такой:

Проверьте состояние ReplicationController с помощью этой команды:

Выход примерно такой:

Здесь созданы три модуля, но ни один из них еще не запущен, возможно, из-за извлечения образа. Чуть позже та же команда может показать:

Чтобы перечислить все модули, принадлежащие ReplicationController, в машиночитаемой форме, вы можете использовать следующую команду:

Выход примерно такой:

Здесь селектор такой же, как и селектор для контроллера репликации (виден в выводе описания kubectl), но в другой форме в файле replication.yaml . Параметр --output=jsonpath указывает выражение с именем каждого модуля в возвращаемом списке.

Написание спецификации контроллера репликации

Как и во всех других конфигурациях Kubernetes, ReplicationController нужны поля apiVersion , kind и метаданных. Имя объекта ReplicationController должно быть допустимым именем субдомена DNS. Общие сведения о работе с файлами конфигурации см. в разделе Управление объектами.

Для ReplicationController также требуется раздел .spec.

Шаблон модуля

Поле .spec.template является единственным обязательным полем .spec .

.spec.template — это шаблон модуля. У него точно такая же схема, как и у пода, за исключением того, что он вложен и не имеет apiVersion или kind .

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

Допускается только .spec.template.spec.restartPolicy, равное Always, которое используется по умолчанию, если не указано иное.

Для перезапуска локального контейнера контроллеры репликации делегируют полномочия агенту на узле, например Kubelet или Docker.

Ярлыки контроллера репликации

Контроллер репликации может сам иметь метки ( .metadata.labels ). Как правило, вы должны установить их так же, как .spec.template.metadata.labels ; если .metadata.labels не указан, то по умолчанию используется .spec.template.metadata.labels . Однако они могут быть разными, и метки .metadata.labels не влияют на поведение ReplicationController.

Выбор модуля

Поле .spec.selector – это селектор меток. ReplicationController управляет всеми модулями с метками, соответствующими селектору. Он не делает различий между модулями, которые он создал или удалил, и модулями, созданными или удаленными другим человеком или процессом. Это позволяет заменить ReplicationController, не затрагивая работающие модули.

Если указан, .spec.template.metadata.labels должен быть равен .spec.selector , иначе он будет отклонен API. Если .spec.selector не указан, по умолчанию будет использоваться .spec.template.metadata.labels .

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

Если у вас все же окажется несколько контроллеров с перекрывающимися селекторами, вам придется управлять удалением самостоятельно (см. ниже).

Несколько реплик

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

Если вы не укажете .spec.replicas , по умолчанию будет 1.

Работа с контроллерами репликации

Удаление ReplicationController и его модулей

Чтобы удалить ReplicationController и все его модули, используйте kubectl delete . Kubectl масштабирует ReplicationController до нуля и ждет, пока он удалит каждый модуль, прежде чем удалять сам ReplicationController. Если эта команда kubectl прервана, ее можно перезапустить.

При использовании REST API или клиентской библиотеки Go необходимо выполнить шаги явно (масштабировать реплики до 0, дождаться удаления модуля, а затем удалить ReplicationController).

Удаление только ReplicationController

Вы можете удалить ReplicationController, не затрагивая ни один из его модулей.

Используя kubectl, укажите параметр --cascade=orphan для удаления kubectl.

При использовании REST API или клиентской библиотеки Go можно удалить объект ReplicationController.

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

Изоляция модулей от ReplicationController

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

Общие шаблоны использования

Перенос

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

Масштабирование

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

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

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

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

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

Несколько выпусков

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

Например, служба может ориентироваться на все модули с уровнем в (frontend), средой в (prod) . Теперь предположим, что у вас есть 10 реплицированных модулей, составляющих этот уровень. Но вы хотите иметь возможность "канарейки" новой версии этого компонента. Вы можете настроить ReplicationController с репликами, установленными на 9 для основной части реплик, с метками tier=frontend, environment=prod, track=stable и еще один ReplicationController с репликами, установленными на 1 для канарейки, с метками tier=frontend, среда = продукт, трек = канарейка. Теперь сервис распространяется как на канарейки, так и на неканарейки. Но вы можете возиться с контроллерами репликации отдельно, чтобы проверять, отслеживать результаты и т. д.

Использование контроллеров репликации со службами

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

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

Написание программ для репликации

Поды, созданные контроллером репликации, должны быть взаимозаменяемыми и семантически идентичными, хотя их конфигурации со временем могут стать неоднородными. Это очевидно подходит для реплицированных серверов без сохранения состояния, но контроллеры репликации также можно использовать для поддержания доступности приложений, выбранных мастером, сегментированных и рабочих пулов. Такие приложения должны использовать механизмы динамического назначения работы, такие как рабочие очереди RabbitMQ, в отличие от статической/однократной настройки конфигурации каждого модуля, которая считается анти-шаблоном. Любая выполняемая настройка модуля, например вертикальное автоматическое определение размера ресурсов (например, ЦП или памяти), должна выполняться другим онлайн-процессом контроллера, мало чем отличающимся от самого контроллера репликации.

Обязанности контроллера репликации

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

Контроллер репликации предназначен для использования в качестве компонуемого примитива строительного блока. Мы ожидаем, что API и/или инструменты более высокого уровня будут построены поверх него и других дополнительных примитивов для удобства пользователей в будущем. Операции «макро», поддерживаемые в настоящее время kubectl (запуск, масштабирование), являются примерами проверки концепции. Например, мы могли бы представить что-то вроде Asgard, управляющего контроллерами репликации, автомасштабирующими устройствами, службами, политиками планирования, канареечными устройствами и т. д.

Объект API

Контроллер репликации — это ресурс верхнего уровня в Kubernetes REST API. Дополнительные сведения об объекте API можно найти по адресу: Объект API ReplicationController.

Альтернативы ReplicationController

Набор реплик

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

Развертывание (рекомендуется)

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

Голые стручки

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

Используйте задание вместо ReplicationController для модулей, которые должны завершаться самостоятельно (т. е. пакетные задания).

Набор демонов

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

Что дальше

  • Подробнее о модулях.
  • Узнайте о Deployment, замене ReplicationController.
  • ReplicationController является частью Kubernetes REST API. Прочтите определение объекта ReplicationController, чтобы понять API для контроллеров репликации.

Отзыв

Была ли эта страница полезной?

Спасибо за отзыв. Если у вас есть конкретный вопрос о том, как использовать Kubernetes, на который можно ответить, задайте его на Stack Overflow.Откройте задачу в репозитории GitHub, если хотите сообщить о проблеме или предложить улучшение.

Читайте также: