Kubernetes никогда не задумывали для пакетной обработки задач

[jenki]

Намешано и вместе тем перепутано многое несовместимое.

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

Это про событийно ориентированную архитектуру

Иными словами, Kubernetes изначально спроектирован под работу сервисов.

Микросервисов - это важно. Потому что есть разница между сервис ориентированной архитектурой и микросервисной архитектурой.

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

Вот сами сформулировали разницу между архитектурами.

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

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

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

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

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

Для этих целей в Kubernetes имеется сущность services.

Kubernetes - это прежде всего специализированный инструмент, а не серебрянная пуля. У него есть спектр задач, для которых он разрабатывался и предназначен. Есть для которых он совсем не предназначался. И когда в Kubernetes пхают кластер с реляционной СУБД и думают, что кубы разрулят переключение мастера базы (бывает и такое), то тут сами себе злобные буратины. Тоже самое как в случае запуска монолита с кешами (кеши они хранят в S3 хранилище, чтобы не потерять).
Поэтому стоит хорошо понимать предметную область, в которой этот инстумент работает и вашу, которую хотите реализовать. В вашем собитийно ориентированном подходе лучше всего подходят брокеры сообщений, многие их которых давно и успешно запускаются в Kubernetes, где реализуется высокая доступность и масштабируемость.

[artazar]

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

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

[Saykhan]

Kubernetes вроде как знает о таких проблемах и предложил такую вещь как CNCF Operator White Paper

Kubernetes primitives were not built to manage state by default. Relying on Kubernetes primitives alone brings difficulty managing stateful application requirements such as replication, failover automation, backup/restore and upgrades (which can occur based on events that are too specific).

The Operator Pattern can be used to solve the problem of managing state. By leveraging Kubernetes built-in capabilities such as self-healing, reconciliation and extending those along with application-specific complexities; it is possible to automate any application lifecycle, operations and turn it into a highly capable offering.

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

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