там тоже все выливается в ENV-переменные

супер, @takama , @etkee спасибо за инфу! буду кодить тогда с использованием docker-compose последний вопрос: для связки API ендпоинтов используете nginx? например, есть 2 сервиса, которые доступны из внешнего мира по адресам: 1) /api/users 2) /api/tasks и чтобы сделать единую точку входа для клиентов (example.com/api/...), то тут нужен nginx по идее, верно? кстати, конфиг nginx в этом случае тоже будет выглядеть необычно - т.к. он не знает четких IP, на какие сервисы перенаправлять запросы или nginx тоже будет перенаправлять запросы на кластерные IP?

Мы для всего внешнего используем HAProxy

За такими вещами HAProxy и следит с помощью health check, если сервис отвалился, он исключается из балансировки, пока не будет снова доступен

а кто будет обновлять днс записи?) например: по внутреннему адресу 192.168.22.22 был доступен сервис и nginx туда корректно перенапрвлял по DNS записи: "service_users: 192.168.22.22" но сервис отвалился и рестартанул уже по адресу 192.168.22.23, а DNS запись осталась прежней получается тут должен быть кластерный IP с "умным балансировщиком", который сам обновляет DNS записи

HAProxy то все равно должен ходить к etcd узнавать, какие сервисы не умерли а каждый сервис должен сообщать о себе в etcd, что он живой, верно?)

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

зарезолвит днс еще через 10 секунд. если сервис не headless, то kube-dns обновит записи, соответствующие виртуальному айпи, там все на уровне iptables, и haproxy даже не заметит, что произошло