Что такое хороший вариант использования для кубернетов?

Question

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

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

Я прочитал множество учебных пособий и документов, и все они просто касаются того, что является контейнером, без убедительного варианта использования ПОЧЕМУ мы должны использовать pod ... Я что-то упустил? Что такое надежный прецедент для использования концепции Pod? Благодарю.

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

Мой первоначальный вопрос заключается в том, чтобы узнать такую ​​услугу A и службу B, для которой требуется совместное размещение и общий сетевой стек. Спасибо Джареду и Роберту за указатели, и я буду разбираться в этих случаях.

Answer 1

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

Для конкретного примера в репозитории Kubernetes вы можете посмотреть определение для DNS cluster add-on. Он использует пакет для совместного размещения DNS-сервера (skyDNS), локальное хранилище с использованием etcd и простую программу для вытягивания объектов API Kubernetes вниз, преобразования их и их размещения в локальном хранилище. Вместо того, чтобы создавать новый настраиваемый DNS-сервер, этот модуль использует существующий DNS-сервер и добавляет к нему некоторую настройку, чтобы информировать о среде кластера. Поскольку все контейнеры находятся в контейнере, они могут полагаться на локальную сеть для общения и не нуждаются в какой-либо форме сложного поиска услуг.