Георг Гаал

Краткий ответ на вопрос в заголовке

> Можно ли позиционировать себя специалистом SRE без опыта программирования?

такой - нет, нельзя.

Любой ответ будет opinionated. Я бы сказал, что даже более того - выбор операционной системы и ядра абсолютно бессмысленен без обсуждения выбора дистрибутива. Потому что крупные игроки вроде OpenShift и Rancher тестируются только на закрытом перечне версий и вариантов. И Вы будете вынуждены использовать их, иначе отгребать и исправлять баги самостоятельно. И тот же ранчер на дебиан взрывается на установке, хотя с центос и убунту (любой разумной версией) - все отлично.
Более того - есть специальные оптимизированные под kubernetes дистрибутивы вроде CoreOS. Сейчас его активно перепиливают в Fedora CoreOS. Посмотрим, что получится. Такие же минималистичные дистрибутивы есть у Vmware, opensuse и многих других
В остальном - конечно, чем свежее - тем лучше.

Да, ингрессу без разницы где работать.

Отличный вопрос!

При прочих равных, конечно, лучше пользоваться managed инсталляций (в чьем-то облаке) - будь то Amazon, Google или Azure.
В остальном - если баре-метал, то есть варианты hard way, kubeadm, kubespray, можно раскатить через rke (будет авторская версия кубернетеса от rancher). Можно взять OKD - бесплатную версию Openshift - он раскатывается через ансибл скрипты

Касательно того КАК ДЕЛАТЬ отказоустойчивость - есть куча вариантов и все они зависят от того какие опции есть со стороны инфраструктуры. Без этого обсуждение дальше будет попросту бессмысленно. Мы от бедности остановились на MetalLB, но это далеко не универсальное решение. И, да, я не видел автоматизации, которая эту штуку устанавливала бы автоматически

Если kubernetes опубликован на внешнем адресе, то можно использовать возможность port-forward утилиты kubectl. Далее легко лазить внутри кластера и щупать сервисы в нем, как будто они доступны напрямую.
В общем - для начала нужно ответить на вопрос ЗАЧЕМ НУЖЕН доступ в кластер - для разработчиков (ad-hoc задачи вроде тестирования, настройки) или чтобы обеспечить связность сервисов в кубернетесе и в офисной сети

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

https://www.hippolab.ru/zapuskaem-systemd-v-docker...

С другой стороны, можно использовать легковесную init систему вроде tini в контейнере или использовать демон супервизора.

Касательно заббикса - так вообще возьмите штатный образ от разработчиков заббикса или с докер хаба и не изобретайте велосипед