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

В рамках этого я бы удалил служебные объекты из основного apiserver и облегчил использование других балансировщиков нагрузки, таких как HAProxy и nginx.

Было бы неплохо, если бы логическое определение службы (запрос и / или глобальное имя) можно было использовать / специализировать несколькими способами - как простой балансировщик нагрузки, установленный через инфраструктуру, как более функциональный балансировщик нагрузки, такой как nginx или haproxy, также предлагаемый инфраструктурой, как запрашиваемая конечная точка, которую интегратор может опрашивать / ждать (GET / services / foo -> {endpoints: [{host, port}, ...]}), или как информация, доступная для хостов чтобы выставить локальные балансировщики нагрузки. Очевидно, что это может быть несколько различных вариантов использования и, как таковые, разделенные на свои собственные ресурсы, но наличие некоторой гибкости для указания намерения (объединение под фунтом), отличного от механизма, упрощает удовлетворение широкого диапазона требований.

@smarterclayton Я согласен с разделением политики и механизма.

Примитивы нам понадобятся:

1. Возможность опроса / просмотра набора, идентифицированного селектором меток. Не уверен, есть ли еще проблема.
2. Возможность запрашивать IP-адреса пода (# 385).

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

Два примитива, описанные @ bgrant0607, стоит ли держать эту проблему открытой? Или есть более конкретные вопросы, которые мы можем подать?

Я не думаю, что zookeeper решен - поскольку вам нужен уникальный идентификатор в каждом контейнере. Я _ думаю_, что вы могли бы сделать это с 3 отдельными контроллерами репликации (по одному на экземпляр) или режимом на контроллере репликации.

Я думаю, что сервис-дизайн заслуживает некоторого обсуждения, как отмечает Брайан. В настоящее время он объединяет абстракцию инфраструктуры (локальный прокси) с механизмом раскрытия (переменные среды во всех контейнерах) с запросом метки. Также существует допустимый вариант использования пограничного прокси, который принимает хосты / пути L7 и уравновешивает их с запросом метки, а также поддерживает такие протоколы, как http (s) и веб-сокеты. Кроме того, сегодня сервисы имеют жесткое масштабное ограничение в 60 тыс. Серверных ВМ, совместно используемых для всего кластера (количество выделенных IP-адресов). Должна быть возможность запускать локальный прокси на миньоне, который проксирует только те службы, которые нужны контейнерам на этом хосте, а также, чтобы контейнеры не знали о внешнем порте. При необходимости мы можем переместить это обсуждение в # 494.

Решение проблемы одноэлементных сервисов и сервисов без автомасштабирования с фиксированной репликацией, таких как реплицированные базы данных master-slave, хранилища значений ключей с одноранговыми группами фиксированного размера (например, etcd, zookeeper) и т. Д.

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

Предложение: мы должны создать новую разновидность службы, называемую кардинальными службами, которая отображает N IP-адресов вместо одного. Кардинальные службы будут выполнять стабильное назначение этих IP-адресов N экземплярам, ​​на которые нацелен их селектор меток (т. Е. Заданному N, а не только тому, сколько целевых объектов существует). Как только у нас есть DNS (# 1261, # 146), он будет назначать предсказуемые DNS-имена на основе предоставленного префикса с суффиксами от 0 до N-1. Назначения могут быть записаны в аннотациях или ярлыках целевых модулей.

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

Некоторые дискуссии о различных типах балансировки нагрузки происходили в дизайне служб v2: # 1107.

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

/ cc @smarterclayton @thockin

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

Для примера с etcd я бы создал:

• мощность контроллера репликации 1: 1 pod, указывающий на стабильный объем хранения A
• мощность контроллера репликации 2: 1 pod, указывающий на стабильный том B
• мощность контроллера репликации 3: 1 pod, указывающий на стабильный том C
• кардинальная служба 'etcd', указывающая на стручки

Если модуль 2 умирает, контроллер репликации 2 создает его новую копию и повторно присоединяет ее к тому B. Кардинальная служба 'etcd' знает, что этот модуль новый, но откуда ему знать, что его мощность должна быть 2 (которая исходит из хранимых данных на томе B)?

Вместо трех контроллеров репликации почему бы не использовать контроллер сегментирования, который
при принятии решения смотрит на ярлык типа "kubernetes.io/ShardIndex". Если
вам нужен трехсторонний сегментирование, он создает 3 модуля с индексами 0, 1, 2. Я чувствую, что
это было сбито раньше, но я не могу восстановить проблемы, которые он вызвал в
моя голова.

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

Как вы думаете, имеет ли значение, если номинальный IP-адрес для данного модуля меняется из-за
несвязанные изменения в наборе? Например:

в момент времени 0 поды (A, B, C) составляют основную службу с IP-адресами
10.0.0. {1-3} соответственно

в момент времени 1 узел, на котором размещен под B, умирает

во время 2 контроллер репликации, управляющий B, создает новый pod D

в момент времени 3 основная услуга меняется на (A, C, D) с IP-адресом 10.0.0. {1-3}
соответственно

NB: "Стабильный IP-адрес модуля C" изменился с 10.0.0.3 на 10.0.0.2, когда установлен
членство изменилось. Я ожидаю, что это плохо скажется на беге
соединения.

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

2 октября 2014 г., в 10:17, Клейтон Коулман [email protected]
написал:

Задания должны быть выполнены в капсулах через некоторые
механизм параметризации среды (почти наверняка).

Для примера с etcd я бы создал:

• мощность контроллера репликации 1: 1 pod, указывающий на стабильную
  объем хранения A
• мощность контроллера репликации 2: 1 pod, указывающая на стабильную
  объем хранения B
• мощность контроллера репликации 3: 1 pod, указывающий на стабильную
  объем хранения C
• кардинальная служба 'etcd', указывающая на стручки

Если модуль 2 умирает, контроллер репликации 2 создает его новую копию и
повторно присоединяет его к тому B. Кардинальная служба etcd знает, что этот модуль
new, но откуда ему знать, что это должно быть количество элементов 2 (которое происходит от
данные хранятся на томе B)?

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

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

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

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

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

В-третьих, я согласен, что нам нужно подумать, как это будет взаимодействовать с предложением о надежных данных (# 1515) - @erictune .

В-четвертых, я согласен, что нам, вероятно, нужно отразить личность в капсуле. Согласно # 386, в идеале должен использоваться стандартный механизм, чтобы сделать назначения IP и DNS имен видимыми для модуля. Каким образом псевдонимы IP и хоста обычно отображаются в Linux?

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

В-шестых, проблема с «контроллером сегментирования», заменяющим контроллер репликации, заключается в том, что я хочу отделить назначение ролей от управления образом / средой. Я вижу, что контроллер репликации предоставляет последнее (см. Https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

В случае надежных данных согласно # 1515:

1. Для прочных капсул это предложение подойдет. Назначение будет стабильным для прочной капсулы.
2. Для отдельных объектов данных основная служба должна будет также назначать роли управления для объектов данных и откладывать назначение ролей модулям до тех пор, пока они не будут сопоставлены с данными. Я думаю, это было бы просто.

/ cc @erictune

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

Re: сегментирование - разве не является шардинг «набором реплик с разными идентификаторами»?

Re: 1 контроллер репликации - у нас сегодня нет контроллера репликации, назначающего индексы. Я не думаю, что мы этого хотим, не так ли?

Re: сообщать модулю его собственную идентичность - сервис - это чистый слой над модулем. Было бы беспорядочно сообщать службе о надвигающемся модуле, чтобы он мог назначить IP-адрес до того, как он существует. Я думаю, что идентификатор должен быть частью модуля, например, метка ShardIndex или что-то в этом роде. Мы можем отразить это в модуле (каким-то образом), и служба может использовать это для назначения IP. Если мы позволим сервису Cardinal делать это самостоятельно, тогда модуль уже будет запущен к тому моменту, когда он будет назначен. Мы могли бы иметь метаданные для каждого модуля, как мы это делаем с виртуальными машинами в GCE, но это более серьезное предложение.

Нет, предоставление стабильных, отличных идентификаторов не является ни необходимым, ни достаточным для сегментирования. См. # 1064 для подробностей, которые я только что добавил.

Нет, мы не хотим, чтобы контроллер репликации назначал индексы. Я намеренно предложил, чтобы это сделали Cardinal Services.

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

Возможный подход к идентификации: создайте непостоянный псевдоним IP в контейнере и обеспечьте обратный поиск DNS в реализации DNS.

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

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

2 октября 2014 г., в 20:59, bgrant0607 [email protected] написал:

Возможный подход к идентификации: создайте непостоянный псевдоним IP в
контейнер и обеспечить обратный поиск DNS в реализации DNS.

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

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Re. помня сопоставления, я согласен - см. https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Однако я не знаю, какое отношение это имеет к комментарию, на который вы ответили.

GitHub и электронная почта несовместимы. Прости

2 октября 2014 г. в 21:39 bgrant0607 [email protected] написал:

Re. помня сопоставления, согласен - см. № 260 (комментарий)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Однако я не знаю, какое отношение это имеет к комментарию, на который вы ответили.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Тим предложил «номинальный», что, я согласен, больше подходит.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

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

----- Исходное сообщение -----

Тим предложил «номинальный», что, я согласен, больше подходит.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Я вижу две проблемы:

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

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

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

Пример запуска zookeeper с одной службой для каждого экземпляра: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Итак, я знаю, что это давняя ветка, но она затрагивает близкую мне тему ;-)

Существуют ли другие ограничения при условии, что система может продвигать вперед + назад записи для «номинальных сервисов», отличных от nat'd, в skydns и использовать имена в качестве инъекции ENV в поды, которые используют эту услугу?

Это может выглядеть немного странно в случае ZK, где каждый элемент кворума будет использовать другие элементы, например:
zk1 использует: zk2, zk3
zk2 использует: zk1, zk3
zk3 использует: zk1, zk2

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

@ bgrant0607 Я что-нибудь

Это становится немного страннее, когда другие приложения хотят использовать предоставляемые им услуги в целом. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc То, что вы предлагаете, работало бы, если бы zk1, zk2 и zk3 были службами, хотя бы один раз поддерживаются многопортовые службы.

Да, здесь есть некрасивый.

Бегущий модуль не знает, какие сервисы «перед ним». Например, предоставил услугу
одного экземпляра серверной части, виртуальный IP-адрес, используемый для доступа к услуге, не известен
серверная часть (если она не ищет эту информацию, зная о службе
название). В номинальном сервисе (N) у вас будет N серверных модулей и N VIP (и
предположительно N DNS-имен или N-адресного имени), но серверные части все равно
не знаю своих VIP-персон. Они могут наблюдать за пулом DNS-имен, но
не знаю (не исследуя), кто из них сам. Это сделает ваш ZK
В этом случае сложно использовать VIP (также прямо сейчас VIP наблюдаются через прокси).

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

1) настройте 1 службу (N) и попросите каждый экземпляр проверять все VIP-адреса для себя.

2) настройте экземпляры службы N (1) и используйте метки и флаги cmdline для
вручную назначить индексы, сделать так, чтобы каждый сервер ZK знал (априори) имя DNS
друг друга ZK backend

3) Сделайте DNS для селекторов меток, назначьте DNS-имя набору реплик ZK,
надеюсь, что клиенты правильно используют DNS

4) Запустите мосты kube2zk вместе с каждым ZK, которые синхронизируют конечные точки kubernetes ->
ZK config

5) Разработайте альтернативный способ присвоения VIP-номеров или индексов, которые больше
Контроллер-репликация, а не сервис-центр. Брендан и я
некоторое время назад придумал несколько идей, но у меня не было времени следовать
на него.

Что касается обратного DNS - я не уверен, что понимаю его роль? Я не против
поддерживая его (например, попросите @bketelsen поддержать его :) но я не думаю, что это
применяется здесь. Трафик никогда не приходит «с» IP-адреса службы.

Тим

В сб, 7 марта 2015 г., в 20:56, Брайан Грант [email protected]
написал:

@timothysc https://github.com/timothysc То, что вы предлагаете, будет работать, если
zk1, zk2 и zk3 были службами, по крайней мере, однажды многопортовые службы
поддерживается.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) звучит как это предложение.

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

8 марта 2015 г. в 11:06 Тим Хокин [email protected] написал:

Да, здесь есть некрасивый.

Бегущий модуль не знает, какие сервисы «перед ним». Например, предоставил услугу
одного экземпляра серверной части, виртуальный IP-адрес, используемый для доступа к услуге, не известен
серверная часть (если она не ищет эту информацию, зная о службе
название). В номинальном сервисе (N) у вас будет N серверных модулей и N VIP (и
предположительно N DNS-имен или N-адресного имени), но серверные части все равно
не знаю своих VIP-персон. Они могут наблюдать за пулом DNS-имен, но
не знаю (не исследуя), кто из них сам. Это сделает ваш ZK
В этом случае сложно использовать VIP (также прямо сейчас VIP наблюдаются через прокси).

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

1) настройте 1 службу (N) и попросите каждый экземпляр проверять все VIP-адреса для себя.

2) настройте экземпляры службы N (1) и используйте метки и флаги cmdline для
вручную назначить индексы, сделать так, чтобы каждый сервер ZK знал (априори) имя DNS
друг друга ZK backend

3) Сделайте DNS для селекторов меток, назначьте DNS-имя набору реплик ZK,
надеюсь, что клиенты правильно используют DNS

4) Запустите мосты kube2zk вместе с каждым ZK, которые синхронизируют конечные точки kubernetes ->
ZK config

5) Разработайте альтернативный способ присвоения VIP-номеров или индексов, которые больше
Контроллер-репликация, а не сервис-центр. Брендан и я
некоторое время назад придумал несколько идей, но у меня не было времени следовать
на него.

Что касается обратного DNS - я не уверен, что понимаю его роль? Я не против
поддерживая его (например, попросите @bketelsen поддержать его :) но я не думаю, что это
применяется здесь. Трафик никогда не приходит «с» IP-адреса службы.

Тим

В сб, 7 марта 2015 г., в 20:56, Брайан Грант [email protected]
написал:

@timothysc https://github.com/timothysc То, что вы предлагаете, будет работать, если
zk1, zk2 и zk3 были службами, по крайней мере, однажды многопортовые службы
поддерживается.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Тогда мне нужно будет найти время, чтобы изложить эту идею еще немного.

В воскресенье, 8 марта 2015 г., в 10:25, Клейтон Коулман [email protected]
написал:

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

8 марта 2015 г., в 11:06, Тим Хокин [email protected]
написал:

Да, здесь есть некрасивый.

Бегущий модуль не знает, какие сервисы «перед ним». Например, учитывая
услуга
одного экземпляра серверной части, виртуальный IP-адрес, используемый для доступа к услуге, неизвестен
от
серверная часть (если она не ищет эту информацию, зная о службе
название). В номинальном сервисе (N) у вас будет N серверных модулей и N VIP.
(и
предположительно N DNS-имен или N-адресного имени), но серверы будут
все еще
не знаю своих VIP-персон. Они могут наблюдать за пулом DNS-имен, но
не знаю (не исследуя), кто из них сам. Это сделает ваш ZK
В этом случае сложно использовать VIP (также прямо сейчас VIP наблюдаются через прокси).

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

1) настройте 1 службу (N) и попросите каждый экземпляр проверять все VIP-адреса для себя.

2) настройте экземпляры службы N (1) и используйте метки и флаги cmdline для
вручную назначить индексы, сделать так, чтобы каждый сервер ZK знал (априори) DNS
название
друг друга ZK backend

3) Сделайте DNS для селекторов меток, назначьте DNS-имя набору реплик ZK,
надеюсь, что клиенты правильно используют DNS

4) Запускайте мосты kube2zk вместе с каждым ZK, которые синхронизируют конечные точки kubernetes
->
ZK config

5) Разработайте альтернативный способ присвоения VIP-номеров или индексов, которые больше
Контроллер-репликация, а не сервис-центр. Брендан и я
некоторое время назад придумал здесь несколько идей, но у меня не было времени
следить
на него.

Что касается обратного DNS - я не уверен, что понимаю его роль? Я не против
поддерживая его (например, попросите @bketelsen поддержать его :) но я не думаю, что это
применяется здесь. Трафик никогда не приходит «с» IP-адреса службы.

Тим

В сб, 7 марта 2015 г., в 20:56, Брайан Грант [email protected]
написал:

@timothysc https://github.com/timothysc То, что вы предлагаете, будет работать
если
zk1, zk2 и zk3 были службами, по крайней мере, однажды многопортовые службы
поддерживается.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: обратный DNS, давайте просто

Без него ZK сломается, как и многие другие распределенные системы.

RC, который применил уникальную метку (members = #) к каждому создаваемому модулю и пытается создать последовательность до N реплик, а затем автономную службу, которая создала имя A и CNAME для каждого значения метки «member» (# .service.namespace.local), где корень обслуживает все эти service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local кажется локальным.

Мы _could_ использовать строгие IP-адреса модулей для этих отдельных DNS-меток. Создание поддельных IP-адресов для каждого из них обходится дорого, и контейнер не сможет отправить кому-либо свой собственный IP-адрес.

----- Исходное сообщение -----

@thockin re: обратный DNS, давайте просто машем руками и считаем, что это
требование.

Без него ZK сломается, как и многие другие распределенные системы.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: обратный DNS - что такое обратный DNS? Исходный IP-адрес
связи? Ничего из этого не работает в кубе. Подключения через сервисы
проксируется, поэтому исходный ip не работает (можно исправить).

Я не знаю ZK - вы можете объяснить, что они пытаются получить обратным ходом
DNS? Это кажется очень хрупким предположением.

В понедельник, 9 марта 2015 г., в 9:05, Тимоти Сент-Клер [email protected]
написал:

@thockin https://github.com/thockin re: обратный DNS, давайте просто помашим
наши руки и считают это требованием.

Без него ZK сломается, как и многие другие распределенные системы.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Я думаю, что мой опыт (и, возможно, опыт Тима) показывает, что большая часть кластерного программного обеспечения сегодня ожидает следующего:

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

----- Исходное сообщение -----

@timothysc re: обратный DNS - что такое обратный DNS? Исходный IP-адрес
связи? Ничего из этого не работает в кубе. Подключения через сервисы
проксируется, поэтому исходный ip не работает (можно исправить).

Я не знаю ZK - вы можете объяснить, что они пытаются получить обратным ходом
DNS? Это кажется очень хрупким предположением.

В понедельник, 9 марта 2015 г., в 9:05, Тимоти Сент-Клер [email protected]
написал:

@thockin https://github.com/thockin re: обратный DNS, давайте просто помашим
наши руки и считают это требованием.

Без него ZK сломается, как и многие другие распределенные системы.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

В пн, 9 марта 2015 г., в 12:49, Clayton Coleman
[email protected] написал:

RC, который применил уникальную метку (members = #) к каждому создаваемому модулю и пытается создать последовательность до
N реплик, а затем автономная служба, которая создала имя A и CNAME для каждого значения "member"
label (# .service.namespace.local), где корень обслуживает все эти service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local кажется локальным.

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

• VIP, PD, общие индексы и т. Д. Что приятно, когда под
  умирает, токен возвращается в пул, и когда этот модуль заменяется
  этот токен используется повторно.

Проблема связана с тем, как превратить «произвольный токен» в
что-то значимое.

Мы _could_ использовать строгие IP-адреса модулей для этих отдельных DNS-меток. Создание поддельных IP-адресов для каждого из них обходится дорого, и контейнер не сможет отправить кому-либо свой собственный IP-адрес.

Я не пробовал, но держу пари, мы могли бы сделать так, чтобы номинальные сервисы выполняли полный SNAT.
и DNAT, поскольку они равны 1: 1. Это был бы способ стабилизировать
индивидуальные IP-адреса без переносимых IP-адресов.

----- Исходное сообщение -----

@thockin re: обратный DNS, давайте просто машем руками и считаем, что это
требование.

Без него ZK сломается, как и многие другие распределенные системы.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Я далек от того, чтобы плыть вверх по течению - если достаточное количество приложений действительно ожидают, что DNS
работать так, мы можем заставить его работать так.

Эскиз:

Создание контроллера репликации R создает DNS-имя «$ R.rc», которое является
пул IP-адресов подов, находящихся «под» этим RC. Каждому модулю P присваивается DNS-имя.
"$ P. $ R.rc". НО что такое P? Это могут быть простые индексы, но у них
укусил нас сильно внутренне. Это могут быть случайные строки, например GenerateName,
но они должны пережить смерть / перезапуск пода (и, возможно, имена хостов подов должны
совпадение?).

Во вторник, 10 марта 2015 г., в 7:59, Клейтон Коулман [email protected]
написал:

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

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

----- Исходное сообщение -----

@timothysc re: обратный DNS - что такое обратный DNS? Исходный IP-адрес
связи? Ничего из этого не работает в кубе. Подключения через сервисы
проксируется, поэтому исходный ip не работает (можно исправить).

Я не знаю ZK - вы можете объяснить, что они пытаются получить обратным ходом
DNS? Это кажется очень хрупким предположением.

В пн, 9 марта 2015 г., в 9:05, Тимоти Сент-Клер <
[email protected]>
написал:

@thockin https://github.com/thockin re: обратный DNS, давайте просто помашим
наши руки и считают это требованием.

Без него ZK сломается, как и многие другие распределенные системы.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

Мне нравится, что DNS привязан к номинальным службам, а не к RC.

В чем была проблема с простыми индексами внутри? P> 5000?

----- Исходное сообщение -----

Я далек от того, чтобы плыть вверх по течению - если достаточное количество приложений действительно ожидают, что DNS
работать так, мы можем заставить его работать так.

Эскиз:

Создание контроллера репликации R создает DNS-имя «$ R.rc», которое является
пул IP-адресов подов, находящихся «под» этим RC. Каждому модулю P присваивается DNS-имя.
"$ P. $ R.rc". НО что такое P? Это могут быть простые индексы, но у них
укусил нас сильно внутренне. Это могут быть случайные строки, например GenerateName,
но они должны пережить смерть / перезапуск пода (и, возможно, имена хостов подов должны
совпадение?).

Во вторник, 10 марта 2015 г., в 7:59, Клейтон Коулман [email protected]
написал:

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

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

----- Исходное сообщение -----

@timothysc re: обратный DNS - что такое обратный DNS? Исходный IP-адрес
связи? Ничего из этого не работает в кубе. Подключения через сервисы
проксируется, поэтому исходный ip не работает (можно исправить).

Я не знаю ZK - вы можете объяснить, что они пытаются получить обратным ходом
DNS? Это кажется очень хрупким предположением.

В пн, 9 марта 2015 г., в 9:05, Тимоти Сент-Клер <
[email protected]>
написал:

@thockin https://github.com/thockin re: обратный DNS, давайте просто помашим
наши руки и считают это требованием.

Без него ZK сломается, как и многие другие распределенные системы.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 к VIP-персонам в спецкорпусе 1: 1. Думаю, это будет обычным делом.

Меня все еще беспокоит динамическое изменение сопоставлений DNS. Я бы предпочел подход, который этого не требовал.

При оценке альтернатив следует иметь в виду, что я на 100% уверен, что в конечном итоге нам понадобятся 2 модуля с одинаковой ролью, которые будут сосуществовать одновременно, старый и новый. Следовательно, роль не может быть привязана ни к имени объекта, ни к чему-то еще, что должно быть уникальным и должно быть закреплено в камне во время создания пода.

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

@smarterclayton Простые индексы не вызывают проблем из-за масштаба. Это из-за модели. Смотрите мои комментарии несколько минут назад. Простые индексы - это правильный выбор, если они могут быть назначены динамически независимо от идентификатора модуля и RC.

Учитывая, что одна из проблем - это системные предположения, может ли Linux что-то сделать для нас? Например, можем ли мы создать псевдоним IP или что-то подобное в контейнере для служебного VIP?

Привет, ребята,

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

Во вторник, 10 марта 2015 г., в 15:56, Брайан Грант [email protected]
написал:

Учитывая, что одна из проблем - системные предположения, есть ли
что Linux может сделать для нас здесь? Например, можем ли мы создать IP
псевдоним или что-то подобное в контейнере для сервиса VIP?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Следующие два дня у меня нет своего кармана - на следующей неделе это будет.

10 марта 2015 г. в 23:33 Тим Хокин [email protected] написал:

Привет, ребята,

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

Во вторник, 10 марта 2015 г., в 15:56, Брайан Грант [email protected]
написал:

Учитывая, что одна из проблем - системные предположения, есть ли
что Linux может сделать для нас здесь? Например, можем ли мы создать IP
псевдоним или что-то подобное в контейнере для сервиса VIP?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

+1 на следующей неделе, возможно, тусовка.

Повторяю эту тему снова из-за всплывающих связанных тем (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, # 6393).

1. Как мы назначаем сетевые идентификаторы (DNS-имена и / или IP-адреса) отдельным модулям, которые могут быть одиночными или частью номинального набора?
2. Как передать идентичность контейнерам внутри модуля?

Следует ли нам запланировать видеовстречу или использовать еженедельную видеовстречу сообщества?

Также https://github.com/openshift/mongodb/pull/14, где мы начинаем прототипировать общий шаблон для инициализации набора членства (что-то, что мы можем поместить в контейнер, или библиотеку, или ...)

@danmcp @mfojtik

----- Исходное сообщение -----

Снова тыкаю в эту ветку из-за всплывающих связанных тем
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. Как мы назначаем сетевые идентификаторы (DNS-имена и / или IP-адреса) для
   отдельные капсулы, которые могут быть одиночками или частью номинального набора?
2. Как передать идентичность контейнерам внутри модуля?

Следует ли нам запланировать видеовстречу или использовать еженедельную видеовстречу сообщества?

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, одна из частей этой головоломки - это главные выборы № 1542.

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

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

Обратите внимание, что проблема передачи служебного IP-адреса контейнеру аналогична передаче внешнего IP-адреса виртуальной машине : http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS аналогичен: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton Я обновил PR прототипа mongo: https://github.com/openshift/mongodb/pull/17

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

Re. привязка этого механизма к контроллеру репликации / шарда:

Попытка использовать DNS-имена для контроллеров репликации и / или для имен объектов-модулей приводит к созданию модели обновления на месте. Потребуется реализовать совершенно другой вид непрерывного обновления «на месте», при этом каким-то образом поддерживая одновременно несколько шаблонов с помощью одного контроллера. Это также будет означать, что для выполнения некоторых видов обновлений (включая перемещение на новые хосты), модули необходимо будет удалить, а затем воссоздать с теми же именами, что увеличит время простоя по сравнению с подходом, когда мы добавляем новый стручок перед тем, как убрать старую.

Идея пула токенов звучит великолепно. Я просто думаю, что его нужно отвязать от ПДУ.

Это можно было бы связать с контроллером более высокого уровня, если бы мы добавили его. Прокомментируем дальше # 1743 и / или # 503.

На самом деле это не должно быть связано с DeploymentController, предложенным в # 1743. Это не сработает ни для сценария с несколькими независимыми треками выпуска, ни в случае, когда кто-то хочет контролировать свои развертывания с помощью другого механизма, такого как предлагаемое скользящее обновление с заменой имен. По тем же причинам я бы не привязывал DNS-имена к именам объектов pod / RC / DC.

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

Чтобы облегчить передачу идентификационных данных до контейнеров в модуле (например, с помощью замены env. Var., Обсуждаемой в # 2316), было бы полезно установить поле в модуле, когда роль была назначена / не назначена, через подресурс. Это также может решить проблему долговечности.

Мы должны зарезервировать место в схеме DNS для номинальных экземпляров - # 6666.

Я мог бы купить, что мы могли бы попробовать использовать IP-адреса модулей и просто переназначить DNS для номинальных экземпляров, согласно https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

Кроме того, я удалил это из этапа 1.0 в феврале (хотя и не roadmap.md), но обсуждение в # 6393 предполагает, что его можно добавить обратно.

Предложено @thockin : обратный поиск с использованием DNS (записи PTR) выглядит разумным способом перехода от IP-адресов модуля к номинальным именам DNS:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

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

10 апреля 2015 г. в 20:11 Брайан Грант [email protected] написал:

Предложено @thockin : обратный поиск с использованием DNS (записи PTR) выглядит разумным способом перехода от IP-адресов модуля к номинальным именам DNS:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

/подписываться

Я больше не уверен, что понимаю требования здесь.

Между сервисами и модулями существует неотъемлемая связь N-to-M.
дизайн системы. Такие вещи, как обратный DNS, обычно ожидают
единственный ответ: учитывая IP-адрес модуля, получить каноническое имя. Каждый документ написан
про DNS говорит «не возвращайте несколько обратных записей». Поскольку капсула может быть
в N службах этот единственный ответ на самом деле не может быть связан с сервисом. Мы
может выполнить обратный поиск канонического имени, а затем поиск в формате TXT для этого
название для того, "какие услуги вы используете", но это трудно поддерживать и
в любом случае, по сути, это собственный протокол.

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

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

Каковы поведенческие требования? Чего мы пытаемся достичь. Мы
может обеспечить простую семантику набора с помощью DNS и автономных служб. В том, что
достаточный? Если нет, то почему?

Мы могли бы пойти на крайности и настроить правила iptables для подов SNAT / DNAT в
сервис, чтобы все видели друг друга на VIP. Например, учитывая набор стручков
(P1, P2, P3) они получат VIP-персон (V1, V2, V3). Трафик от P1 к V2 будет
кажется, что они поступают из V1 и т. д. Клиенты будут обращаться к V {1,2,3}. Но что
проблема действительно ли это решает? Он дает стабильные IP-адреса, но разве это не
общая проблема для безголовых сервисов во всем?

Во вторник, 21 апреля 2015 г., в 14:17, Дэвид Оппенгеймер < [email protected]

написал:

/подписываться

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

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

Например, у zookeeper есть индивидуальная идентификация для каждого узла. Это удостоверение должно оставаться стабильным в членстве в кластере - _может быть_ два модуля, которые считают себя host1, но если host1 уходит, host435 не может его заменить. Для этого модуля может быть повторно используемый постоянный диск, который перемещается из одного места в другое, но когда это происходит, модуль должен иметь возможность определять эту идентичность. Но нам нужен способ присвоить этот #.

Я подозреваю, что я думаю о номинальных услугах всегда о включении существующего программного обеспечения с небольшим (3/5/7) членстве, а не о полностью гибком варианте использования с несколькими сотнями. Возможно, нам следует отделить этот вариант использования от этого обсуждения.

22 апреля 2015 года в 01:59 Тим Хокин [email protected] написал:

Я больше не уверен, что понимаю требования здесь.

Между сервисами и модулями существует неотъемлемая связь N-to-M.
дизайн системы. Такие вещи, как обратный DNS, обычно ожидают
единственный ответ: учитывая IP-адрес модуля, получить каноническое имя. Каждый документ написан
про DNS говорит «не возвращайте несколько обратных записей». Поскольку капсула может быть
в N службах этот единственный ответ на самом деле не может быть связан с сервисом. Мы
может выполнить обратный поиск канонического имени, а затем поиск в формате TXT для этого
название для того, "какие услуги вы используете", но это трудно поддерживать и
в любом случае, по сути, это собственный протокол.

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

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

Каковы поведенческие требования? Чего мы пытаемся достичь. Мы
может обеспечить простую семантику набора с помощью DNS и автономных служб. В том, что
достаточный? Если нет, то почему?

Мы могли бы пойти на крайности и настроить правила iptables для подов SNAT / DNAT в
сервис, чтобы все видели друг друга на VIP. Например, учитывая набор стручков
(P1, P2, P3) они получат VIP-персон (V1, V2, V3). Трафик от P1 к V2 будет
кажется, что они поступают из V1 и т. д. Клиенты будут обращаться к V {1,2,3}. Но что
проблема действительно ли это решает? Он дает стабильные IP-адреса, но разве это не
общая проблема для безголовых сервисов во всем?

Во вторник, 21 апреля 2015 г., в 14:17, Дэвид Оппенгеймер < [email protected]

написал:

/подписываться

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Какой-то контроллер может динамически устанавливать / отключать некоторые поля на подах. Это просто не может быть отождествлено ни с идентификатором pod, ни с RC. Привязка идентификатора сети к идентификатору модуля или RC полностью нарушена.

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

Есть ряд ограничений DNS, которые мы хотим продвигать в долгосрочной перспективе (недействительность кеша, поддержка длительного опроса и т. Д.). Возможно, несколько записей PTR - это просто еще один элемент, добавленный в этот список.

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

----- Исходное сообщение -----

Какой-то контроллер может динамически устанавливать / отключать некоторые поля на подах. Это
просто не может быть отождествлено ни со стручком, ни с RC-идентичностью. Связывание сетевой идентичности
к стручку или RC идентичности полностью нарушены.

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

Есть ряд ограничений DNS, которые мы хотим продвигать в долгосрочной перспективе.
(аннулирование кеша, поддержка длительного опроса и т. д.). Несколько записей PTR
возможно, просто еще один пункт, добавленный в этот список.

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

Многие из этих сервисов ожидают, что IP-адрес, который у них есть (их имя), будет соответствовать IP-адресу, к которому они подключаются, поэтому, если они подключаются к X на 172.1.1.1, то X думает, что это 172.1.1.1. Это еще не все программы, но некоторые из них. Обычно это DNS-имя, что означает, что IP-адрес может измениться под ним.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

Боюсь, для меня это все еще немного абстрактно.

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

Это не требование. Это настолько расплывчато, что невозможно реализовать.

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

Что такое личность? IP-адрес? В программу передан строковый флаг?
а env var? Как процесс zk узнает, что такое его собственная личность?

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

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

Я мог видеть что-то вроде расширения аннотаций во флаги командной строки
(как мы обсуждаем с env vars) или просто в env vars. Например
контроллер пишет аннотации ["zookeeper.com/index"] = 9, мы конвертируем
$ .metatdata ["zookeeper.com/index"] в ZK_INDEX env. Но я делаю это
вверх, я не видел никаких конкретных требований, в которых говорилось бы, что именно zookeeper (или
что угодно) нужно.

Я не считаю необоснованным навязывать максимум одну номинальную услугу
за капсулу

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

мы можем дать служебный IP-адрес каждому модулю номинальной службы

С этого мы и начали, но ...

Многие из этих сервисов ожидают, что их IP-адрес (их имя)
разрешает IP-адрес, к которому они подключаются - поэтому, если они подключаются к X на 172.1.1.1,
тогда X думает, что его 172.1.1.

Служебные IP-адреса не удовлетворяют этому, если мы не сделаем что-то более глубокое, например
Я упоминал с SNAT / DNAT. И даже у этого есть существенные недостатки.

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

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

В среду, 22 апреля 2015 г., в 10:12, Клейтон Коулман [email protected]
написал:

----- Исходное сообщение -----

Какой-то контроллер может динамически устанавливать / отключать некоторые поля на
стручки. Это
просто не может быть отождествлено ни со стручком, ни с RC-идентичностью. Связывание сети
личность
к стручку или RC идентичности полностью нарушены.

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

Есть ряд ограничений DNS, которые мы хотим продвигать в долгосрочной перспективе.
бегать
(аннулирование кеша, поддержка длительного опроса и т. д.). Множественный PTR
записи
возможно, просто еще один пункт, добавленный в этот список.

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

Многие из этих сервисов ожидают, что их IP-адрес (их имя) разрешит
к IP-адресу, к которому они подключаются - поэтому, если они подключаются к X на 172.1.1.1, то X
думает, что это 172.1.1.1. Это еще не все программы, но некоторые из них. Обычно это
имя DNS, что означает, что IP может измениться под ним.

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

Большинство примеров с
ZK : разрешаемое имя хоста или IP-адрес в файле конфигурации, плюс «id» (т. Е. Индекс: 1, 2, 3, ...) в файле

Мы также должны просмотреть некоторые БД.

Что бы мы ни делали, не для всех работает. Нам просто нужно найти золотую середину.

----- Исходное сообщение -----

Боюсь, для меня это все еще немного абстрактно.

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

Это не требование. Это настолько расплывчато, что невозможно реализовать.

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

Что такое личность? IP-адрес? В программу передан строковый флаг?
а env var? Как процесс zk узнает, что такое его собственная личность?

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

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

Я мог видеть что-то вроде расширения аннотаций во флаги командной строки
(как мы обсуждаем с env vars) или просто в env vars. Например
контроллер пишет аннотации ["zookeeper.com/index"] = 9, мы конвертируем
$ .metatdata ["zookeeper.com/index"] в ZK_INDEX env. Но я делаю это
вверх, я не видел никаких конкретных требований, в которых говорилось бы, что именно zookeeper (или
что угодно) нужно.

Я не считаю необоснованным навязывать максимум одну номинальную услугу
за капсулу

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

мы можем дать служебный IP-адрес каждому модулю номинальной службы

С этого мы и начали, но ...

Многие из этих сервисов ожидают, что их IP-адрес (их имя)
разрешает IP-адрес, к которому они подключаются - поэтому, если они подключаются к X на 172.1.1.1,
тогда X думает, что его 172.1.1.

Служебные IP-адреса не удовлетворяют этому, если мы не сделаем что-то более глубокое, например
Я упоминал с SNAT / DNAT. И даже у этого есть существенные недостатки.

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

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

Я считаю, что это разумно, мы должны уделить время решению ряда известных примеров. У нас есть 3 варианта, которые мы можем использовать для конкретных примеров (набор реплик MongoDB, Zookeeper, Mysql Master / Slave), а также существующие примеры в kube / examples. Возможно, рабочая сессия для хеширования элементов, установления границ неразрешимых проблем, определения того, что осталось.

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

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

Пример zookeeper: https://github.com/openshift/origin/pull/1965

Пример номинальной потребности в обслуживании https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Я немного сбит с толку, почему здесь до сих пор неясно направление, особенно со стороны гуглеров. Google уже много лет запускает сервисы с отслеживанием состояния под Borg, и совершенно ясно, что требуется для этого типа рабочей нагрузки:

• Стабильный идентификатор, для которого один из набора «шардов» (неидентичных реплик) представляет текущий модуль (в borg это «номер задачи» - простое целое число). Этот идентификатор должен оставаться постоянным при перепланировании / перезапуске модуля.
• Способ перечислить и связаться со всеми "одноранговыми" шардами, возможно, используя их стабильные идентификаторы каким-либо образом (в borg это полный префикс вместе с номером задачи)

.. и мы закончили.

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

Это можно подделать прямо сейчас, создав уникальную службу / порт для каждого шарда и запустив контроллер репликации с репликами: 1, но управлять большим количеством шардов «вручную», как это, немного неуклюже.

Естественный способ реализовать это в кубернетах:

• Поды получают дополнительные переменные среды, задающие собственный индекс сегментов (целое число) и общее количество сегментов (или, возможно, передают его через нисходящий API?).
• ReplicationControllers получают счетчик «сегментов» (по умолчанию: 1), а «реплики» интерпретируются как «реплики в каждом сегменте» (по умолчанию: 1). При сжатии набора реплик они должны убивать с конца (чтобы индексы сегментов оставались смежными). Обратите внимание, что для изменения «сегментов» потребуется непрерывный перезапуск управляемых модулей, чтобы обновить их env var «общее количество сегментов» (хорошо, вы не хотите, чтобы это происходило мгновенно).
• Службы получают аналогичное количество «сегментов», которое сопоставляет непрерывный диапазон портов с обычным селектором плюс неявный селектор «индекса сегментов».
• Поды могут найти другие сегменты, используя SERVICE_PORT (или какой-нибудь новый env var?) + Смещение индекса сегментов.

Обратите внимание, что приведенное выше поведение постепенно ухудшается до текущего, когда shards = 1.

Я в целом согласен с этим (и, как вы говорите, он прошел проверку временем в Borg), хотя я бы не советовал использовать «расширение экзотических функций», состоящее из нескольких реплик на сегмент (хотя нам, вероятно, понадобится что-то подобное в разделе чехлы для миграции).

Как я упоминал ранее, это тесно связано с тем, что нам нужно делать для поддержки пакетных заданий со статическим рабочим назначением (то, что я здесь называл «типом 1»: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142)

Другие функции, которые нам нужно согласовать, если мы изменили RC (или добавили что-то новое), - это то, как развертывание вписывается, а именно:

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

1. Обычный RC
2. PerNodeController
3. Шардированный RC
4. Пакетное задание?

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

----- Исходное сообщение -----

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

Как я упоминал ранее, это тесно связано с тем, что нам нужно делать, чтобы
поддержка пакетных заданий со статическим рабочим назначением (то, что я называл "типом 1"
здесь:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

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

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

Контроллер на уровне узла / демона: Хороший момент. Плотно присвоенные индексы - плохая модель для этого случая. Что вы делаете, например, когда узел навсегда уходит? Индексы становятся разреженными. Я рекомендую не поддерживать это.

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

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

Назначение не может выполняться одним контроллером репликации. Это просто не работает. Контроллеры репликации не являются надежными объектами, и мы ожидаем, что будет несколько RC для каждой службы, для канареек, скользящих обновлений, нескольких треков выпуска, нескольких кластеров и т. Д. Даже предлагаемый объект развертывания (# 1743) не имеет нужной области .

Возможны 3 варианта назначения:

1. Свяжите назначение с особым видом Службы. Сервис имеет именно то, что нужно. (В конечном итоге нам также потребуются региональные службы.) Это будет своего рода гибрид между обычными услугами и автономными службами. Это то, что я предполагал, когда изначально предлагал этот механизм. Назначение будет записано в конечных точках. Конечные точки и / или безголовый DNS были бы очевидными способами перечислить всех одноранговых узлов.
2. Создайте объект нового типа, похожий на Service, но только для номинальных услуг. Скорее всего, нам также понадобится новый объект для записи задания. Это излишне расширит поверхность нашего API, ИМО.
3. «Тянуть» вместо «толкать». Поды планируются для хостов без явного контроллера, даже с ограничениями узла (селектором) или одним из предложенных механизмов анти-сродства (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Это также похоже на назначение служебного VIP. Можно было бы сделать что-то подобное для номинальных услуг. Модуль (или шаблон модуля) должен указывать пул индексов, из которого ему нужно назначить индекс. В отличие от общих сервисов, мы не ожидаем, что подам нужно будет назначать несколько индексов из разных пулов. Назначение будет записано в спецификации модуля.
4. Плюсы: проще для пользователей. Не требует другого объекта. Разрешает назначение пользователями.
5. Минусы: отличается от других видов услуг.

Назначение ПВХ в идеале было бы использовать ту же модель.

Также стоит подумать о том, как будет организована миграция модуля №3949. Модуль замены ДОЛЖЕН быть создан до удаления заменяемого модуля, чтобы передать состояние контейнера. Это может сделать модель вытягивания немного проблематичной. В любом случае механизм распределения должен быть адаптирован к миграции.

Прочие соображения:

1. Как передать индекс / идентичность партнерам. DNS - очевидный ответ.
2. Как передать индекс / идентификатор контейнерам в модуле. Переменные среды, обратный DNS, ... Назначенный индекс не будет изменяться динамически, хотя привязка DNS может быть изменена, пока модуль все еще существует. Я хотел бы выбрать механизм, который приложения уже ожидают работать в других средах, и, как и в случае более широкого обсуждения нисходящего API (# 386), я не хочу связывать приложения с переменными среды, специфичными для Kubernetes, но с новым EnvVarSource и замена env var (# 7936) поможет этого избежать.

Я не согласен с некоторыми из того, что вы сказали, но давайте подождем, чтобы продолжить это обсуждение до версии 1.0.

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

Примером использования является балансировщик нагрузки nginx, указывающий на этот набор модулей по доменным именам. Так как поды приходят и уходят, ожидается, что доменные имена всегда будут фиксироваться с xxx-0001 до xxx-000N.

@ravigadde Прочтите мой последний комментарий по этой проблеме: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

Загляните в эту проблему при попытке настроить контейнер RabbitMQ. Настойчивость Rabbit зависит от имени хоста, поэтому наличие переменных имен хостов означает, что вы потеряете базу данных Mnesia при перезапуске контейнера.

Пытался исправить с помощью конфигурации изображения (имя хоста напрямую и Rabbit), переменных ENV и Downward API. Не удалось найти способ решить проблему - Rabbit по-прежнему воспринимает сгенерированное имя Pod. Временное решение путем переключения с использования контроллера репликации согласно предложению @mikedanese .

Если я правильно понимаю, модуль rabbitmq (созданный с помощью контроллера репликации) в примере celerey-rabbit потеряет данные при сбое модуля, даже если данные хранятся на постоянном диске. Из документа rabbitmq:

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

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

Или при запуске символическая ссылка dir имени хоста на стабильное место

11 июля 2015 г. в 17:26 Майк Данезе [email protected] написал:

Если я правильно понял, pod rabbitmq (созданный с помощью репликации
контроллер) в кролике-клери
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
пример потеряет данные при сбое модуля, даже если данные хранятся на
постоянный диск. Из документа rabbitmq:

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

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

Это пример того, почему имя хоста не должно производиться от имени модуля - # 4825

Чтобы дать этому легкий толчок:

Необходимо решить несколько фундаментальных проблем:

1. Некоторые компоненты должны иметь уникальный идентификатор для каждого модуля, привязанный к их хранилищу на диске.
   
   
   
   1. В качестве дополнительной морщинки, некоторым из них (в некоторых случаях zookeeper) требуется, чтобы имя хоста было разрешаемым и соответствовало
   
   
2. Некоторые компоненты, которые масштабируются, должны иметь постоянное хранилище, которое различается для каждого модуля (модули указывают на PVC, которые различаются для каждого модуля, с привязкой к идентичности)
   
   
   
   1. Иногда эти тома следует создавать по запросу при увеличении масштаба.
   
   
   2. Иногда эти тома следует повторно использовать из пула, а не воссоздавать.
   
   
3. Некоторые компоненты могут масштабироваться до десятков тысяч экземпляров, когда отслеживание отдельных выделенных идентификаторов становится непрактичным.
   
   
   
   1. Большинство применений для номинального, вероятно, будет между 2-7 экземплярами модуля (самые современные масштабируемые БД, большинство сегментированных настроек с несколькими мастерами)
   
   
4. Некоторым компонентам не нужно реализовывать свои собственные главные выборы, но позволить платформе управлять этим, сделав одну из идентичностей произвольной (идентичность 1 становится главной)
5. Когда мы решим эти проблемы, пользователям все равно придется вносить изменения в модули (посредством развертываний) и обеспечивать сохранение или перераспределение всех идентификационных данных.

Необязательно, чтобы все эти проблемы решались одним и тем же решением. Например, я думаю, что существует значительная разница между идентичностью кластера небольшого размера (2-7) и идентичностью кластера большого размера (> 7). Например, в большом случае это программное обеспечение меньше заботится о пробелах или имеет существующий протокол консенсуса / членства. В небольшом случае программному обеспечению требуется дополнительная помощь в установлении личности. Я бы разделил их на облачное (> 7) и существующее кластерное (2-7) программное обеспечение.

Я согласен с пунктами 1a, 1b и 2a. 2b звучит как другая проблема, хотя, возможно, решение может повторно использовать тот же шаблон.

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

Главные выборы (4) можно рассматривать отдельно.

Также согласен с (5).

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

Остающиеся вопросы по дизайну:

I. Выделить VIP-адреса или разрешить изменение IP-адресов? С этим тесно связано то, должны ли контейнеры иметь возможность обнаруживать свои собственные IP-адреса через Linux или нет, поскольку в настоящее время виртуальные IP-адреса не обнаруживаются через систему. Я предполагаю, что им действительно нужно иметь возможность обнаруживать свои IP-адреса, но они могут использовать нисходящий API, как с IP-адресом модуля (# 12595). Разрешение изменения IP-адресов (из-за использования IP-адресов модуля) подразумевает ограничение скорости изменения IP-адреса из-за TTL DNS и «ошибок» кэширования. В какой-то момент мы также намереваемся сделать IP-адреса подов переносимыми (# 3949), чтобы изменение IP-адресов не длилось вечно.

II. Толчок (к капсулам) или тяга (от капсул). Сервисы и RC намеренно слабо связаны с модулями, поэтому оба используют модель «push». Номинальные услуги будут более тесно связаны с идентичностью модуля (хотя и не навсегда - модули должны быть заменяемыми). Следовательно, я вижу меньше мотивации для модели толчка. Другие случаи распределения, такие как планирование и особенно. исключительная привязка, такая как заявки на постоянные тома на постоянные тома, использует модель запроса / подтверждения, также известную как «вытягивание». В настоящее время я предпочитаю эту модель для номинальных услуг.

У кого-нибудь есть мнение по поводу (I)?

Выбор главного администратора - # 1542, и обсуждается как часть реализации HA (например, # 12884).

Я не знаю, что вы подразумеваете под «толкать и тянуть».

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

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

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

Я просто проведу поток сознания и посмотрю, что не воняет.

Идея 1: пулы вещей и патчи.

Определите новый объект API или что-то, что позволит вам определить пул
вещи. Что есть вещь? Вещь - это строка (или, возможно, капля JSON), которая
имеет перечислимый тип. Вы можете создать пул вещей и этих вещей
вы можете использовать. Типы вещей включают VUID (имена хостов), строки, VIP.

Определите новую конструкцию API, которую можно передать для создания операций - a
пластырь. Патч - это инструкция по исправлению объекта, который
созданный. Один из вариантов исправления - «выделить из ThingPool».

Чтобы собрать их вместе:

Определите ThingPool {meatadata.name: my-quorum-hostnames, введите: VUID,
autogenerate: 5,} // создает пул из 5 допустимых VUID

Определите RC {реплики: 5 ...}

При создании (POST) RC также отправьте патч: {what:
"podTemplate.spec.containers [*]. metadata.VUID", пул: "my-quorum-hostnames"
}

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

Вы можете использовать это для создания пула строк (от «0» до «99») и вставлять
те в env var. Вы можете использовать это, чтобы выделить пул VIP и
затем назначьте эти VIP-адреса модулям (это будет новая функция - надежный модуль
IP-адреса - не уверен, как это будет масштабироваться :) Вы можете создать пул
PersistentVolumeClaim именует и исправляет том заявки, который использует каждый модуль.

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

Идея 2. Определите набор контейнеров. Не притворяйся, что это услуга. Это ближе
на работу борга. Это похоже на RC, но он присваивает порядковость стручкам.
элементы управления - номера шардов. Он контролирует пул VUID (но мы не хотим
имя хоста должно быть тем, что пользователи могут установить, хммм ...).

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

Во вторник, 18 августа 2015 г., в 19:28, Брайан Грант [email protected]
написал:

Я согласен с пунктами 1a, 1b и 2a. 2b звучит как другая проблема, хотя
возможно, решение может повторно использовать тот же шаблон.

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

Главные выборы (4) можно рассматривать отдельно.

Также согласен с (5).

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

Остающиеся вопросы по дизайну:

I. Выделить VIP-адреса или разрешить изменение IP-адресов? С этим тесно связано то,
контейнеры должны иметь возможность обнаруживать свои собственные IP-адреса через Linux или нет,
поскольку в настоящее время VIP-адреса не могут быть обнаружены через систему. Я предполагаю, что они делают
должны иметь возможность обнаруживать свои IP-адреса, но могут использовать нисходящий API, так как
с IP-адресом пода (# 12595 https://github.com/kubernetes/kubernetes/pull/12595).
Разрешение изменения IP-адресов (из-за использования IP-адресов подов) подразумевает ограничение скорости
изменения IP из-за TTL DNS и "ошибок" кеширования. В какой-то момент мы
также намереваются сделать переносимые IP-адреса модулей (# 3949
https://github.com/kubernetes/kubernetes/issues/3949), поэтому изменение IP-адресов
не будет вечно.

II. Толчок (к капсулам) или тяга (от капсул). Сервисы и RC
намеренно слабо связаны с модулями, поэтому оба используют "толкать"
модель. Номинальные услуги будут более тесно связаны с идентичностью модуля.
(хотя и не навсегда - капсулы должны быть заменяемыми). Следовательно, я вижу
меньше мотивации для модели толчка. Другие случаи распределения, такие как
планирование, и особенно исключительная привязка, например, постоянные требования тома к
постоянные тома, используйте модель запроса / подтверждения, также известную как «вытягивание». Это в настоящее время
модель, которую я предпочитаю для номинальных услуг.

У кого-нибудь есть мнение по поводу (I)?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

Я, наверное, не имел в виду главные выборы, как вы думаете об этом - более того
при построении функциональности, когда необходимо инициализировать набор экземпляров
(без явной координации) имея только экземпляр, который думает, что это
«1» разговора с другими модулями обычно достаточно для начальной загрузки кластера. An
пример - mongodb, где вам нужно инициировать набор реплик - если pods
которые думают, что они "2" или "3", вы можете получить в случаях, когда вы
инициировать раскол. Но «1» может каждый раз безопасно инициировать себя, а затем
попробуйте добавить других участников (которые имеют постоянное состояние, которое они могут использовать для
определить, входят ли они уже в кластер). В зависимости от
гарантии, предоставляемые службой идентификации, на самом деле вы можете не получить
успешный кластер, но вам не нужно создавать отдельный модуль снаружи, чтобы
инициализировать свою службу (хотя это тоже не страшно).

Во вторник, 18 августа 2015 г., в 23:59, Брайан Грант [email protected]
написал:

Выборы господина # 1542
https://github.com/kubernetes/kubernetes/issues/1542 , и в настоящее время
обсуждается как часть реализации HA (например, # 12884
https://github.com/kubernetes/kubernetes/pull/12884).

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

Клейтон Коулман | Ведущий инженер, OpenShift

@smarterclayton Это не относится к номинальным службам, но

Поскольку @thockin может иметь в

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

_Prescriptive: _ "Я хочу, чтобы работало N осколков, и если их больше или меньше, то внесите изменения, чтобы вернуть их в N."
_Описательный: _ "Я хочу просто автоматически обнаруживать все доступные осколки и позволять мне каким-то образом узнавать, когда они приходят и уходят".

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

Обсуждение также включало ограждение ресурсов и гарантии единого доступа. Afaics, _only_ случай, когда это нужно сделать в k8s, - это монтирование удаленных постоянных томов (потому что монтирование fs должно выполняться вне контейнера), и это довольно легко сделать с помощью блокировок etcd, если базовая служба удаленных томов не делает этого. t уже обеспечивают внутреннее ограждение. Все остальные случаи могут обрабатываться самими пользовательскими заданиями с использованием службы распределенной блокировки (или доступа к службам, которые обеспечивают внутреннюю блокировку). Запрос заданий на выполнение собственной блокировки открывает всевозможные шаблоны (фиксированное назначение, гибкое назначение, «горячее резервирование» и т. Д.) И стратегии недостижимости / восстановления (жесткий сбой, «продолжить с последними известными» и т. Д.).

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

Напоминаем, что за одним VIP есть много портов. Я согласен, что мы не хотим переносить IP-адреса, поскольку это сложно для базовой сети в масштабе и неудобно для сети иметь дело с временными дубликатами во время краевых случаев сбоя / восстановления. Однако я думаю, что вполне возможно назначить уникальный порт службы каждому члену шарда и данные прокси для каждого экземпляра пода - даже для очень больших заданий. (Это предложение предполагает, что прокси-серверы по-прежнему являются тем направлением, в котором мы хотим двигаться с k8s - я не следил за недавними обсуждениями в этой области)

Под push я имел в виду, что другой ресурс, такой как служба или контроллер, будет отслеживать наборы модулей с помощью селектора меток и передавать им «вещи» (разрешаемые имена DNS, VIP, PVC).

Под вытягиванием я имел в виду, что модуль будет явно запрашивать выделение «вещи», которая затем будет привязана к ней через что-то вроде / binding.

Что касается изменения работающих модулей: изменение модуля после создания отличается от изменения модуля с запущенными контейнерами. Планировщик выполняет асинхронный режим. инициализация, например. PodIP также назначается с опозданием. Обсуждается в более общем плане в # 3585.

По поводу того, действительно ли это «услуга»:

• Вещи должны быть распределены по наборам контейнеров
• Вещи (например, DNS-имена) не должны быть внутренне привязаны к имени ресурса модуля.
• Вещь должна передаваться из одной капсулы в другую.
• Поду необходимо «знать» (или иметь возможность узнать через нисходящий API), что (особенно DNS-имя и VIP) ему было назначено.
• Одна вещь, которую нам нужно поддерживать, - это разрешаемый DNS.
• Единственный мой нерешенный вопрос - нужны ли нам VIP-персоны. Я нормально не использую VIP.
• Это не идеально, но пользователь мог бы создать вторую автономную службу, нацеленную на весь набор для обнаружения одноранговых узлов через DNS и / или конечные точки.

Идея (1), ThingPools + Patches - интересная идея. Я бы назвал это подходом «вытягивания». ThingPool неплох, но я обеспокоен тем, что патчи будет сложно использовать, и я не хотел бы реконструировать семантическую информацию из патчей внутри системы, чтобы обеспечить приемлемое поведение в жизненном цикле хранилища и т. Д. Я бы предпочел что-то более специфичное для предметной области. Кроме того, независимые пулы ThingPools для DNS-имен и PVC не будут работать, поскольку их необходимо совместно распределять.

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

Re. вставка информации в env vars: Это также касается Иова. Я хочу поместить информацию в аннотацию и расширить нисходящий API, чтобы иметь возможность запрашивать определенные аннотации. Я хочу по-прежнему разрешать пользователям запрашивать только ту информацию, которая им нужна, и выбирать имена переменных env.

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

Re. предписывающий: сохранение N в рабочем состоянии - это то, что делает ReplicationController.

Re. описательный: это уже существующие безголовые сервисы.

Re. блокировка: Да, это API аренды, который сейчас в стадии разработки.

Предоставление хранилища обсуждается в # 6773 (push) и # 12450 (pull).

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

Быстрое наблюдение: безголовые сервисы не выделяют VIP

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

Также актуальны проблемы с долговечным локальным хранилищем: # 7562, # 1515, # 598.

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

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

Re. распределение / назначение: я хочу избежать добавления дополнительных типов шаблонов в ReplicationController, Deployment, Daemon и т. д., и я хочу, чтобы хранилище и имена могли переноситься между контроллерами так же легко, как и между модулями (если это то, что хочет пользователь).

19 августа 2015 г. в 01:04 Ангус Лис [email protected] написал:

@smarterclayton https://github.com/smarterclayton Это отступление от
проблема с номинальными услугами, но загружать ее небезопасно, так как вы
описание. Если «1» перезапускается на новой машине и оказывается не в состоянии
чтобы добраться до существующих узлов, он перезагрузится, и теперь у вас есть два
mongodb утверждает, что он авторитетный. Вам нужно сменить работу
определение для удаления возможности начальной загрузки после начальной загрузки
полный.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

19 августа 2015 г. в 01:35 Ангус Лис [email protected] написал:

Поскольку @thockin https://github.com/thockin может иметь в виду , я думаю
мы без надобности объединяем здесь несколько похожих, но разных функций

• и мы включаем больше, чем это строго необходимо на уровне k8s.

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

_Prescriptive: _ "Я хочу, чтобы работало N сегментов, и если их больше или меньше
чем это, затем внесите изменения, чтобы вернуть его в N. "
_Описательный: _ "Я хочу просто автоматически обнаруживать все доступные сегменты, и
позвольте мне как-нибудь узнать, как они приходят и уходят ".

Я думаю, что это разные и их нужно описывать по-другому (хотя

они могут предоставлять метаданные, аналогичные фактическим работающим модулям).

Обсуждение также включало ограждение ресурсов и единый доступ.
гарантии. Afaics, _only_ случай, когда это нужно сделать в k8s
(afaics) монтирует удаленные тома - потому что необходимо выполнить монтирование fs
вне контейнера. Все остальные случаи могут быть обработаны пользовательскими заданиями.
сами, используя службу распределенной блокировки (или обращаясь к службам, которые
обеспечить внутреннюю блокировку). Требование, чтобы рабочие места сделали свою собственную блокировку, открывается
до всевозможных шаблонов (фиксированное назначение, случайное назначение, "горячие"
запасные части "и т. д.) и стратегии недоступности / восстановления (жесткий отказ,
продолжить с последними известными и т. д.).

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

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

Напоминаем, что за одним VIP есть много портов. Я согласен мы
не хочу переносить IP-адреса, так как это звучит сложно в базовой сети
в масштабе и неудобно для сети иметь дело с временными дубликатами
в крайних случаях отказа / восстановления. Однако я думаю, что это вполне возможно.
назначить уникальный порт службы каждому члену шарда и данные прокси для каждого
pod instance - даже для очень больших работ. (Это предложение предполагает
прокси - все еще то направление, в котором мы хотим двигаться с k8s - я не успел
с любыми недавними обсуждениями в этой области)

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

Небольшой поворот к идее @thockin ThingPool + Patches:

Шаблон: список ресурсов + параметры и подстановка. См. Https://github.com/openshift/origin/blob/master/pkg/template/api/types.go для вдохновения. Реф. № 503, 1743, 4210, 6487.

TemplatePool. В основном ThingPool. Создает плотно проиндексированные экземпляры шаблона по запросу, а не по количеству реплик.

Для развлечения / согласованности: v2 ReplicationController может реплицировать произвольные шаблоны, а не только контейнеры. исх # 170 (вроде). Возможно, в этом нет необходимости, если все выделение осуществляется за счет репликации подов.

Основной альтернативой было бы что-то более специфичное для домена, ориентированное на пулы имен хостов и PVC, но отдельные пулы для каждого из них не работают. Один пул должен иметь возможность выделять кортежи имен хостов и (потенциально несколько) PVC. Одним из преимуществ TemplatePool является то, что кто-то может использовать его для выделения одной службы (возможно, внешней) для каждой реплики, автоматизируя текущий обходной путь Zookeeper. Не знаю, могут ли быть другие ресурсы, которые кто-то захочет аналогичным образом воспроизвести 1 к 1 с помощью модулей, но, учитывая скорость, с которой растет наш API, я бы не стал держать пари, что их не будет.

@smarterclayton К вашему сведению, когда вы отвечаете по электронной почте со встроенными комментариями, ваши ответы нечитаемы как в Gmail, так и в GitHub. В gmail нет разрывов строк, а в github нет префиксов для цитирования, поэтому ваш ответ сложно отделить от цитируемого текста.

Ага, что-то не так с gmail + github + iPhones.

В четверг, 20 августа 2015 г., в 14:24, Брайан Грант [email protected]
написал:

@smarterclayton https://github.com/smarterclayton К вашему сведению, когда вы отвечаете
по электронной почте со встроенными комментариями, ваши ответы нечитаемы, как в
gmail и на github. В gmail нет разрывов строк, а в github нет
не являются префиксом цитирования, поэтому ваш ответ трудно отделить от
цитируемый текст.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Клейтон Коулман | Ведущий инженер, OpenShift

У нас был быстрый чат сегодня, некоторые основные моменты:

Говорили о трех классах приложений:

• Приложения, которые являются веб-приложениями без сохранения состояния (только работают с RC)
• Приложения гигантского масштаба, использующие внешние мастера и имеющие существующую согласованность
  протоколы (Cassandra, Infiniband) для обработки консенсуса
• Небольшое кластерное программное обеспечение с отслеживанием состояния, такое как Mongodb, rethinkdb, volt, etcd,
  кластеры zookeeper, riak, redis, которым для правильной работы требуется несколько шаблонов
  
  
  
  • Уникальная личность (обычно)
  
  
  • Уникальный постоянный том для каждого экземпляра, который используется повторно (обычно)
  
  
  • Стабильный IP-адрес или DNS-имя (обычно) - DNS-имя обычно
    
    стенд для стабильного IP-адреса
  
  
  • Стабильное имя хоста (редко)
  
  

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

Мы говорили о предложениях Тима и Брайана в произвольном порядке:

• TemplatePool проблематичен, потому что репликатор должен иметь
  полномочия для создания объектов во всем кластере и должны знать
  где находится каждая конечная точка api.
  
  
  
  • У вас может быть конечная точка шаблона, но все же необходимо
    
    решить проблему делегирования полномочий (со служебными аккаунтами?)
  
  
  • Поиск объектов и ограничение разрешений - это более долгосрочные задачи
  
  
• «Идентификация стручка», известная как поле vuid, о котором мы говорили - аргумент был приведен
  и в целом согласен с тем, что он не должен быть глобально уникальным, только
  уникален в пределах домена, в котором модуль ожидает его использования.
  
  
  
  • Гипотетический назначитель индекса (разреженный или плотный) может установить это значение.
    
    создание поста, и кубелет мог ждать, чтобы запустить поды, пока у них не будет
    
    личность (может потребоваться указать, что они ее ждут)
  
  
  • Плотные индексы обычно полезны для простых вещей, но поскольку это
    
    это создание поста, отделенное от кублета, у вас могут быть разные
    
    типы алгоритмов присваивания (плотные числа, согласованное хеш-кольцо,
    
    случайный и т. д.)
  
  
• Простое создание шаблонов на модулях кажется хорошим местом для начала, но нам нужно
  чтобы он соответствовал нашей существующей цепочке инструментов таким образом, чтобы
  полностью сломать это
  
  
  
  • Используйте поле идентификации для создания шаблонов других полей
  
  
• Добавьте поле имени хоста в спецификации модуля, которое пользователи могли бы установить сами, и
  параметризовать идентичностью
• Разрешить безголовой службе отвечать на запросы DNS для конечных точек по их
  идентичность (пусть контроллер конечных точек материализует идентичность из модуля
  в конечные точки), что гарантирует некоторую стабильность
• Каким-то образом разрешить параметризацию заявлений на постоянные тома или их изменение на
  извлекать из пула (или иметь контроллер пула, чтобы на каждый
  identity, или попросите контроллер идентификации извлекать из пулов), нужно подумать
• Нужны инструменты, которые упростят превращение среды / нисходящего API в
  файлы конфигурации (ортогональные, но должно быть проще)
• Тем не менее некоторые опасения по поводу рисунка

В четверг, 20 августа 2015 г., в 15:34, Клейтон Коулман [email protected]
написал:

Ага, что-то не так с gmail + github + iPhones.

В четверг, 20 августа 2015 г., в 14:24, Брайан Грант [email protected]
написал:

@smarterclayton https://github.com/smarterclayton К вашему сведению, когда вы отвечаете
по электронной почте со встроенными комментариями, ваши ответы нечитаемы, как в
gmail и на github. В gmail нет разрывов строк, а в github нет
не являются префиксом цитирования, поэтому ваш ответ трудно отделить от
цитируемый текст.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Клейтон Коулман | Ведущий инженер, OpenShift

Клейтон Коулман | Ведущий инженер, OpenShift

Еще одна проблема: сертификаты TLS для членов номинального сервиса.

Сертификаты TLS для обслуживания в целом тоже подойдут (подписанные
кластерным ЦС автоматически по запросу).

20 августа 2015 г. в 17:19 Брайан Грант [email protected] написал:

Еще одна проблема: сертификаты TLS для членов номинального сервиса.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Клейтон Коулман | Ведущий инженер, OpenShift

Да: # 11725

Re:

• Добавьте поле имени хоста в спецификации модуля, которое пользователи могли бы установить сами, и
  параметризовать идентичностью
• Разрешить безголовой службе отвечать на запросы DNS для конечных точек по их
  идентичность (пусть контроллер конечных точек материализует идентичность из модуля
  в конечные точки), что гарантирует некоторую стабильность

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

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

Что-то типа:

Hostname string
Subdomain string

выше HostNetwork в PodSpec.

Мы доставляем DNS на основе имени хоста только в том случае, если субдомен соответствует этому для службы правильного типа. Мы также могли бы объединить их в одно поле.

Я думаю, нам следует перенаправить выпуск № 4825 для этого и заставить кого-нибудь работать над этим. Это гораздо более конкретно и требует меньше усилий, чем все остальное.

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

Я думаю, что здесь могут помочь две вещи о претензиях:

1. Измените привязку с 1: 1 на 1: N
   
   
   
   1. pvc.Spec.VolumeName к pvc.Spec.VolumeNames [] в качестве ссылки привязки
   
   
2. pvc.Spec.Singelton логическое значение, которое указывает, должно ли утверждение быть привязано ровно один раз для совместного использования или разрешить многоразовую привязку утверждения.

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

По-прежнему важно, чтобы нужный объем соответствовал правильному модулю.

У вас должна быть карта идентичностей с именами томов.

21 августа 2015 г., пятница, 15:17, Марк Туранский [email protected]
написал:

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

Я думаю, что здесь могут помочь две вещи о претензиях:

1. Измените привязку с 1: 1 на 1: N
   
   
   
   1. pvc.Spec.VolumeName к pvc.Spec.VolumeNames [] в качестве привязки
      
      ссылка
   
   
2. pvc.Spec.Singelton логическое значение, которое указывает, следует ли связывать утверждение
   ровно один раз для совместного использования или разрешить привязку претензии много раз.

При необходимости RC может связываться с новыми томами. Я выясню, как с этим справиться
в подшивке.

По-прежнему важно, чтобы нужный объем соответствовал правильному модулю.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Клейтон Коулман | Ведущий инженер, OpenShift

В пятницу, 21 августа 2015 г., в 00:56 Брайан Грант [email protected] написал:

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

Давайте проясним - если мы НЕ устанавливаем субдомен, мы не можем позволить пользователям предоставлять
свои собственные имена хостов. Если мы ДЕЙСТВИТЕЛЬНО устанавливаем поддомен, мы должны сделать это в
достаточно уникальным способом (в пространстве DNS, что в настоящее время означает
пространство имен). Сделать субдомен именем Сервиса - это
достаточно уникальный.

Учитывая некоторые ограничения нашего DNS (одного TLD), это
реально означает, что мы даем пользователям два поля DNS_LABEL - имя хоста
и номинально-набор. Для конкретного примера:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

Это приведет к тому, что модуль увидит:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

и DNS, обслуживающий записи A и PTR для foo.bar.my-app.nom.cluster.local

Это на один уровень глубже, чем наша текущая структура DNS, но я думаю
наш текущий ndots = 5 покрывает это. С другой стороны, мы могли бы сказать, что
пространство имен - это фамилия, и верните ее пользователям, чтобы назначить уникальные
имена хостов в пространстве имен. Результат DNS будет
foo.my-app.pod.cluster.local который является зеркалом Services. Мы могли даже
сделайте их более похожими, добавив необязательное поле имени хоста в Сервисы.

Мы доставляем DNS на основе имени хоста только в том случае, если субдомен соответствует этому для
услуга нужного типа. Мы также могли бы объединить их в одно поле.

Моя наименее любимая часть этого - то, что Pod объявляет: «Я - часть
of Service 'bar' »(в приведенном выше примере). Впереди. Априори.

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

Я думаю, нам следует перенаправить выпуск № 4825 для этого и заставить кого-нибудь работать над этим. Это гораздо более конкретно и требует меньше усилий, чем все остальное.

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

Пт, 21 августа 2015 г., в 15:17 Марк Туранский [email protected] написал:

Я думаю, что здесь могут помочь две вещи о претензиях:

1. Измените привязку с 1: 1 на 1: N

Я начал с этого, но ...

В пятницу, 21 августа 2015 г., в 12:38, Clayton Coleman
[email protected] написал:

У вас должна быть карта идентичностей с именами томов.

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

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

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

Что касается идентичности, каждый модуль, созданный контроллером демона, должен иметь назначенную идентичность, производную от идентификатора узла и идентификатора контроллера. Это может быть случай, когда идентичность очевидна (pod x на хосте y имеет идентификатор f (y)) и часть ответственности демонов.

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

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

Пт, 11 сентября 2015 г., в 01:13, Ангус Лис [email protected]
написал:

@smarterclayton https://github.com/smarterclayton так часто (но не
универсальный) здесь необходимо поддерживать стабильный, упорядоченный список групп
члены. Я думаю, это означает, что личность не должна быть привязана к
узел, на котором запланирован модуль.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Клейтон Коулман | Ведущий инженер, OpenShift

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

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

Может случиться так, что модули, запускаемые контроллером демона, имеют "очевидную" идентичность (контроллер демона работает с набором узлов, RC работает с набором модулей).

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

Рассмотрим RC, который выбирает контейнеры с меткой a = b. Чтобы рассчитать следующий создаваемый модуль, он должен получить модули и уменьшить их количество. Что, если мы сократим его до уникального набора имен, а затем RC попытается следовать шаблону генерации имени в этом наборе? Два RC, которые не перекрываются, но создали поды в метке службы, не смогут генерировать уникальные имена (они могут бороться за имя, но это неявно). Имена можно использовать повторно после удаления

Тогда постоянные тома в модуле могут использовать PVC на основе имени модуля. Пуллер из ПВХ может обеспечить достаточное количество заявлений для наблюдаемого пула RC. Контроллер-демон может выбирать имена, детерминированные имени узла. Мы также можем связать имена DNS с именами модулей в службе на основе некоторого шаблона.

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

Выше имелось в виду «наблюдаемый пул имен». DNS конечной точки будет иметь имя hashpodname.ept.service.namespace.svc.cluster.local. У нас уже есть имя модуля на конечной точке, поэтому нам даже не нужно ничего добавлять.

связанный с https://github.com/kubernetes/contrib/tree/master/service-loadbalancer, который предлагает решение этой проблемы в качестве возможной следующей итерации

Почему мы обсуждаем здесь DaemonSet? Это было решено # 12893, IMO.

@smarterclayton Давайте не будем возвращаться к получению идентичности из имен https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Одна из возможностей - иметь параметр RC, который позволяет вам генерировать имена так, как описано в

Кажется, что полезность чего-то вроде абстракции индекса задач Borg продолжает появляться _ для определенных случаев использования_, и мне непонятно, почему мы не можем предложить это в качестве опции.

DaemonSet, я не думаю, решает проблему хранения распределенной файловой системы
(Gluster), где каждый хост должен иметь согласованную личность для повторного присоединения
кластер. Я буду копать еще, но думаю, может еще что-то понадобится
потребности # 260 - я не знаю, достаточно ли имени хоста, если вы повторно подключите
хост-диск на новом экземпляре. Может я не понял, что такое DaemonSet
предоставлен и доставлен # 12893, но я не думаю, что это проблема
системный хост, который хочет повторно использовать диск.

В среду, 16 сентября 2015 г., в 00:22, Брайан Грант [email protected]
написал:

@smarterclayton https://github.com/smarterclayton Давайте не будем возвращаться
получение идентичности из имен модулей, а также использование RC для присвоения идентичности.
Проблемы с этими подходами обсуждались здесь: # 260 (комментарий)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Клейтон Коулман | Ведущий инженер, OpenShift

В качестве конкретного примера представьте кластер etcd. Имеет 7 экземпляров и 7
тома. Хочу (для аргументации) названия и тома etcd-1
через etcd-7 и etcd-pvc-1 через etc-pvc-7.

Скользящее развертывание имеет MaxUnavailable 90% (или эквивалент), MaxSurge 0%. Это
уменьшает масштаб старого RC и увеличивает масштаб нового RC. Старый RC изящно
удаляет etcd-5. Он моментально выходит из эффективного набора RC. Новый
RC пытается создать etcd-5 (наблюдая установленный пробел). Он получает
«AlreadyExistsException». Он рассматривает это как отсрочку и требования. Один раз
etcd-5 действительно исчез, он может работать. Как только etcd-5 будет готов, DC
переходит к следующему шагу.

В качестве альтернативы - идентификация, установленная на модуле - старый RC уменьшен в масштабе. А
новый модуль создается мгновенно с новым именем. Новый модуль не запускается
потому что ему нужна идентификация, чтобы выяснить, какой PVC установить для его
объем. Он переходит в цикл ожидания на Kubelet. Контроллер идентичности
наблюдает за набором селекторов ярлыков и наблюдает за идентичностью etcd-5 не
выделено. Он устанавливает идентификатор etcd-5 для нового модуля. Кубелет наблюдает
это изменение, а затем можно определить, какой ПВХ установить, запускает модуль
(при условии, что том был отсоединен от другого узла).

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

В среду, 16 сентября 2015 г., в 00:39 , Клейтон Коулман
написал:

DaemonSet, я не думаю, решает проблему хранения распределенной файловой системы
(Gluster), где каждый хост должен иметь согласованную личность для повторного присоединения
кластер. Я буду копать еще, но думаю, может еще что-то понадобится
потребности # 260 - я не знаю, достаточно ли имени хоста, если вы повторно подключите
хост-диск на новом экземпляре. Может я не понял, что такое DaemonSet
предоставлен и доставлен # 12893, но я не думаю, что это проблема
системный хост, который хочет повторно использовать диск.

В среду, 16 сентября 2015 г., в 00:22, Брайан Грант [email protected]
написал:

@smarterclayton https://github.com/smarterclayton Давайте не будем возвращаться
получение идентичности из имен модулей, а также использование RC для присвоения идентичности.
Проблемы с этими подходами обсуждались здесь: # 260 (комментарий)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Клейтон Коулман | Ведущий инженер, OpenShift

Клейтон Коулман | Ведущий инженер, OpenShift

Для меня эта проблема усложняется тем, что не генерирует стабильный уникальный пул имен или не использует пул PD. Проблема в том, чтобы делать ОБЕИХ одновременно. И если вы расширите это, почему почти любой идентификатор в спецификации не может быть объединен таким образом?

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

Эта проблема сохранялась и сохранялась, и я боюсь, что у нас аналитический паралич.

Хотелось бы, чтобы у нас было больше примеров других вариантов использования пулов. Я думал Gluster
было бы иначе, но это просто еще один вариант на
cassandra / etcd / mongo / zookeeper "я хочу повторно использовать том, и мне нужно
вспомни, кем я был раньше ». У нас еще не было ролей (я
хотите сделать первых N модулей координаторов и следующие M рабочих) example
использовать.

В среду, 16 сентября 2015 г., в 00:46, Тим Хокин [email protected]
написал:

Для меня эта проблема усложняется тем, что не создает стабильного
уникальный пул имен или использование пула PD. Проблема в том, что ОБА в
в то же время. И если вы расширите это, почему бы ни
идентификатор в спецификации быть объединенным таким образом?

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

Эта проблема сохранялась и сохранялась, и я боюсь, что у нас есть анализ
паралич.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Клейтон Коулман | Ведущий инженер, OpenShift

DaemonSet:

12893 задает имя хоста модуля равным имени хоста узла при использовании сети хоста, что вполне разумно использовать для DaemonSet, поскольку в противном случае они в любом случае использовали бы hostPort.

Также намерение состоит в том, чтобы интегрировать DaemonSet с контроллером узла, чтобы обеспечить неявное неопределенное прощение # 1574 и включить «планирование» до включения планирования для узлов в целом. Неявная приоритезация также может быть разумной.

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

Что касается идентичности, я не вижу здесь проблемы с предложением: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Этот вопрос задерживается в основном из-за отсутствия достаточного приоритета, ИМО.

Чтобы рифовать на Клейтона (или, может быть, просто сказать то же самое, но тупее):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

Подразумевается, что RC (или что-то в этом роде) понимает, что это набор идентификаторов, назначает индекс из identityPool, присваивает этот идентификатор имени модуля, а затем заглядывает внутрь, чтобы увидеть, установлены ли какие-либо другие поля, ориентированные на идентичность - идентификатор объем в этом случае.

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

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

Даже написание спецификации требует времени.

Что касается IdentityPool / VolumePool, мы уже давно решили, что несколько пулов не будут работать.

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

Также по теме: # 170. Предлагалось просто разделить шаблон модуля, но если мы выберем схему шаблонов (которую я предпочитаю патчу), то мы должны рассмотреть их вместе.

Ставлю хотя бы дизайн на v1.2-кандидат.

Извините, я не понял в моем эскизе - RC (или IC?) Имеет концепцию
первичный пул или индекс. После того, как поду присвоен индекс в ИС, это
index используется для индексации всех полей, ориентированных на пул.

Если мы разделим шаблон, я предполагаю, что RC не может
изменить шаблон. Это немного сложнее.

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

Во вторник, 15 сентября 2015 г., в 22:09, Брайан Грант [email protected]
написал:

Даже написание спецификации требует времени.

По поводу IdentityPool / VolumePool мы уже давно решили
назад, что несколько пулов не будут работать.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Да, были вещи, которые вызвали дискуссии с нашей стороны.
Проблемы с клиентами ждут, пока не будет выпущен релиз.

В среду, 16 сентября 2015 г., в 01:14, Тим Хокин [email protected]
написал:

Извините, я не понял в моем эскизе - RC (или IC?) Имеет концепцию
первичный пул или индекс. После того, как поду присвоен индекс в ИС, это
index используется для индексации всех полей, ориентированных на пул.

Если мы разделим шаблон, я предполагаю, что RC не может
изменить шаблон. Это немного сложнее.

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

Во вторник, 15 сентября 2015 г., в 22:09, Брайан Грант [email protected]
написал:

Даже написание спецификации требует времени.

По поводу IdentityPool / VolumePool мы уже давно решили
назад, что несколько пулов не будут работать.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Клейтон Коулман | Ведущий инженер, OpenShift

Обсуждение касается IP-адресов и модулей, но, по моему опыту работы с Mongo & Zookeeper, IP-адреса модулей должны оставаться неактуальными (не превращаться в домашних животных). Постоянному _volume_ требуется номинальный номер, поскольку этот том записывает IP-адреса других «томов». Какой бы модуль ни монтировал этот том, он должен каким-то образом использовать этот записанный IP-адрес. Объем любимчик ...

Я думаю, что DNS-имя, которое является постоянным во времени для тома и назначается модулю, который монтирует том, будет иметь большое значение.

Изменение членства в ансамбле в Mongo & ZK всегда требует запуска специального кода, и я ожидаю, что это будет таким же для большинства других ансамблей. Итак, имя «Контроллер репликации» неправильное, этим питомцам нужен еще контроллер корабля-члена. Контроллер корабля-члена должен иметь возможность обрабатывать первоначальную настройку, а затем инкрементные изменения в ансамблях и, наконец, убивать их.

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

Да, IP-адрес пода - это скорее краткосрочный взлом.

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

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

23 сентября 2015 года в 11:33 Питер Кринс [email protected] написал:

Обсуждение ведется только о IP-адресах и модулях, но по моему опыту работы с
Mongo & Zookeeper IP-адрес стручков не должен иметь значения (не становиться домашними животными).
Постоянному _volume_ требуется номинальный номер, поскольку этот том записывает
IP-адрес других «томов». Независимо от того, какой модуль устанавливает этот том
должен иметь возможность каким-то образом использовать этот записанный IP-адрес. Объем - это
домашний питомец ...

DNS-имя, которое является постоянным во времени для тома и назначается модулю, который
Я думаю, что монтирует том.

Изменение членства ансамбля в Mongo & ZK всегда требует индивидуального
код для запуска, и я ожидаю, что он будет таким же для большинства других ансамблей. Так
Контроллер репликации - неправильное имя, этим питомцам нужно больше члена
Судовой диспетчер. Контроллер судна-члена должен уметь обрабатывать
начальная настройка, затем постепенные изменения ансамблей, и, наконец,
убить его.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/пинг

Вы можете найти пример настройки ZK-кластера под Kubernetes с использованием существующих возможностей по адресу https://hub.docker.com/r/elevy/zookeeper/. Основное требование - стабильные IP-адреса и имена хостов для членов ансамбля. Это достигается с помощью отдельных Сервисов для каждого члена кластера. Единственная проблема заключается в том, что по умолчанию ZK будет пытаться привязаться к IP-адресу, к которому разрешено его имя хоста, но этого можно избежать с помощью параметра конфигурации.

@smarterclayton @thockin

Мысли, когда ехали на велосипеде в офис несколько дней назад:

В настоящее время я думаю об этом как о контроллере PetSet или, может быть, о контроллере ShardSet, если люди хотят думать об этом таким образом, как обсуждалось в начале: https://github.com/kubernetes/kubernetes/issues/260# комментарий -57671926.

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

Я все еще думаю, что привязка этого к ReplicationController не может сработать отчасти потому, что ReplicationController имеет только один шаблон. PetSet / ShardSet должен быть абстракцией более высокого уровня, больше похожей на Deployment или DaemonSet. PetSet потенциально может создать один объект PodTemplate для каждого экземпляра.

Я не думаю, что мы можем просто повторно использовать API развертывания. Среди прочего, стратегия развертывания скользящего обновления теперь в kubectl и Deployment не будет работать в этом случае. Большинство домашних животных, вероятно, захотят воссоздать обновления, а те, кому нужны скользящие обновления, не смогут справиться с любым всплеском, превышающим их количество сегментов, и будут внимательны к порядку обновления.

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

Я не хочу представлять масштаб PetSet более чем в одном месте, например, в контроллере и в пуле идентификаторов, или в контроллере и в службе, поскольку это сделало бы масштабирование сложным / неудобным.

Не думаю, что в этом случае нам нужны универсальные шаблоны. Нам просто нужно избавиться от контейнеров с соответствующим хранилищем и предсказуемыми и надежными сетевыми идентификаторами. Грубого эквивалента было достаточно в Борге. Поэтому я сильно склоняюсь к чему-то вроде # 12450, но в шаблоне модуля, а не в самих модулях. Возможно, массив persistentVolumeClaimTemplates в дополнение к podTemplate. Я не хочу добавлять причудливую замену для всех источников объема, зависящих от облачного провайдера, тем более, что мы в любом случае хотим отказаться от них. Добавление дополнительных требований и / или селекторов к PVC должно быть достаточно. В какой-то момент нам также понадобится как-то предоставлять постоянные тома.

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

И затем имя хоста и удаленная служба меняются, упомянутые выше, здесь:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

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

Предложение находится на https://github.com/kubernetes/kubernetes/pull/18016.

... так где же мы с PetSet?

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

1. служба postgres сопоставляет циклический перебор всем модулям в ReplicaSet, а служба postgres-master сопоставляется только одному модулю.
2. основная капсула умирает.
3. аварийное переключение происходит. В рамках отработки отказа новый мастер обновляет Kube-master через API, чтобы «захватить» службу postgres-master.
4. Когда он это делает, все предыдущие подключения к postgres-master разрываются.

@jberkus первоначальный альфа-код для включения PetSets либо объединен, либо ожидает слияния. @ingvagabund из моей команды собирается начать собирать примеры, в которых используется PetSet, чтобы увидеть, что работает хорошо, а что еще требует улучшения. Я бы порекомендовал вам обратиться к нему, если у вас есть какие-то конкретные варианты использования, которые вы хотите собрать и протестировать.

@ncdc Все ли для этого сделано в v1.3? Это неясно, поскольку предложение не объединено, и какое-то время другие ОР не ссылались на это.

@bprashanth ^

Мы высаживаем e2es и продолжаем работать над примерами. Это в альфе
сейчас, но предложение пройдет первый раунд альфа-обратной связи
перед слиянием.

19 мая 2016 г., в 10:25, Брэндон Филипс [email protected]
написал:

@ncdc https://github.com/ncdc Все ли для этого сделано в версии 1.3? это
неясно, так как предложение не объединено и других PR не было
ссылаясь на это некоторое время.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

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

Ага, как раз то, что нам нужен эксперт по postgres :)

см. https://github.com/kubernetes/contrib/pull/921 для примеров, я могу ответить на любые вопросы о прототипировании [db of choice] как petset. У нас есть несколько набросков под ярлыком «apps / stateful» (например: https://github.com/kubernetes/kubernetes/issues/23790, @philips пример etcd был бы отличным). Я еще не писал документов, сделаю это в последние несколько недель 1.3 (еще 5 недель до выпуска после завершения кода в пятницу).

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

Чтобы дать вам быстрый обзор, petset сегодня дает вам согласованную сетевую идентификацию (DNS, имя хоста), которая соответствует подключенному к сети тому, и гарантии заказа. Итак, если вы создадите питомец с помощью replicas: 3 , вы получите:
управляющая служба: * .galear.default.svc.cluster.local
mysql-0 - volume0
mysql-1 - volume1: не запускается, пока 0 не будет запущен и готов
mysql-2 - volume2: не запускается, пока 0, 1 не будут готовы к работе

Модули могут использовать DNS для обнаружения служб путем поиска записей SRV, вставленных в управляющую службу. Вот что делает этот простой модуль: https://github.com/kubernetes/contrib/pull/921/commit/4425930cea6f45385561313477662d6fb2ee2c62. Поэтому, если вы используете одноранговый поиск через контейнер инициализации, как в приведенных выше примерах, mysql-1 не запустится, пока контейнер инициализации не увидит (mysql-1, mysql-0) в DNS и не запишет соответствующий config.

Тома предоставляются динамическим инициатором (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), поэтому, если у вас его нет работает в вашем кластере, но вы просто хотите создать прототип, вы можете просто использовать emptyDir. Случай с «гравитацией данных» (https://github.com/kubernetes/kubernetes/issues/7562) пока не работает, но со временем будет.

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

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

Мне также нужна поддержка etcd, так что в будущем мне предстоит много тестов.

@ncdc Каков статус альфа-кода для этого? Хочу начать тестирование / внедрение. Нам очень скоро нужно развернуть здесь кластер cassandra. Я могу сделать это с существующей кодовой базой, но было бы неплохо протестировать материал для домашних животных.

Вы можете получить его, если соберете из HEAD

@bprashanth слился с основным репо? большое спасибо. Сделаю.

https://github.com/kubernetes/contrib/tree/master/pets

встроенный yaml в строки аннотации? oof, ouch :(. хотя, спасибо, займемся исследованием создания набора кассандры.

это json. Это альфа-функция, добавленная к объекту GA (контейнеры инициализации в модулях).
@chrislovecnm работает над Кассандрой, может просто подождать его.

@paralin вот над чем я работаю. Сейчас нет времени документировать и помещать это в репо k8s, но это долгосрочный план. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra У меня работает локально, на HEAD.

Последний образ C * в демонстрации работает хорошо.

У нас есть открытая проблема для получения дополнительной документации. Подмигнуть, подмигнуть, кнудж @bprashanth

Пример PetSets с etcd cluster [1].

[1] https://github.com/kubernetes/contrib/pull/1295

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

30 июня 2016 г. в 01:25 Ян Чалупка [email protected] написал:

Пример PetSets с etcd cluster [1].

[1] kubernetes / contrib # 1295
https://github.com/kubernetes/contrib/pull/1295

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
или отключить поток
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

документы для домашних животных: https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md и https://github.com/kubernetes/kubernetes.github. io / tree / release-1.3 / docs / user-guide / petset / bootstrapping , я планирую закрыть эту проблему и открыть новую, которая касается перехода petset в бета-версию, если никто не возражает

https://github.com/kubernetes/kubernetes/issues/28718