Saboteur

можно также, как и все остальные приложения в проекте - деплоить компонент "кронджобу"

Кубер это оркестратор с достаточно широкими возможностями автоматизации.
Он не имеет смысла если у вас парочка компонентов, которые вы запускаете на одном хосте.

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

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

В третью, большое количество интеграций с внешними системами при помощи раннеров, что позволяет сделать ci/cd, разграничить его по правам и так далее, объединиться с каким-нить hashicorp vault при помощи парочки аннотаций и так далее.

Приложения приложениям рознь.
Тут основной вопрос к разработчикам, чтобы они могли написать приложение, которое требует минимум ресурсов и в случае чего легко скейлится горизонтально.
Можно вообще выделить максимум 1 cpu/4gb памяти на под и сказать разработчикам - крутитесь как хотите, но чтобы все влезало в эти лимиты. Сюда влезет 90% микросервисов, но понятно что или придется пилить много микросервисов, и вдобавок какие-то тяжелые вещи типа базы данных сюда не влезут.
НО, все ведь зависит от нагрузки и количества клиентов.

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

А рандомные ответы из интернета дадут слишком общую картинку, которая может наоборот навредить.

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

В глаза кидаются мелочи типа

В каждом сервисе подключен бутстрап конфиг, в котором подключены 4-5 конфигмапов дополнительно

А почему у вас несколько конфигмапов на одно приложение, а не один конфигмап?

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

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

По итогу можно провтыкать изменить на каком-то окружении параметр, и всё..окружения уже не одинаково настроены.

Делать статические параметры, и в конфигмапы выносить исключительно environment-related опции.

По вашему вопросу никто не скажет решения. Это нужно сесть и переделать.
У меня свыше 100 компонентов, десяток енвайрнментов. Конфигмап один на неймспейс, секрета два на неймспейс, в принципе достаточно.

Ну никак.
На какое приложение будут смотреть эти домены?

ls -1 *.yml | xargs -n1 kubectl -f apply

Заббиксом не пользовался, но юзаю InfluxDB которая идет с графаной.

Сейчас некоторые вещи кидаю напрямую в инфлюкс так:
resources,nodename=testnode-nodes-8a5qa cpu=5,ram=79

Плюс в том, что у cpu и ram в данном случае timestamp будет совпадать и графики красивее синхронизируются.
И даже интересно, Заббикс такую модель поддерживает, или у него дефолтный флоу другой?

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

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

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

MustRunAsNonRoot - можно использовать любых юзеров, кроме рута (uid 0)

RunAsAny - можно запускать контейнеры от имени любого юзера

А вообще, тут подробнее:
https://docs.openshift.com/container-platform/4.1/...

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

Ну это же просто.
Вместо этого бреда

readinessProbe:
          initialDelaySeconds: 15
          exec:
            command:
              - find
              - /var/www/public/live777.html

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

readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 30