Да падение мастера это на случай падения виртуалки на хостере.Не приятный хостер.
Насколько безопасно делать все взаимосвязи куба через внешние IP адреса или лучше заморочиться и туннели поднять?Да, правильным решением будет своя оверлейная сеть на базе туннелей с контролируемыми точками входа.
что если я буду использовать 1 мастер и он отвалится?У мастера основная задача проверять чтобы текущее состояние соответствовало желаемому (декларативный подход) и выполнять изменения по этому поводу в кластере. Поэтому если он отвалится, то просто не будут выполняться эти проверки . С другой стороны, а чего ему вдруг падать? Если на мастере, кроме основных процессов ничего левого не стоит, падать ему особенно не от чего.
Хочется без ингресс напрямую под выпустить по 443 порту.Не вопрос. Поднимаешь сервис в режиме node-ip и готово.
А досконально въехать в его работу это я пол году ухайдохаю.И заметно поднимешь свою стоимость как специалиста на рынке труда.
А вот если решение это по каким то причинам будет работать не так как надо, то тут придется на горячую руку как то все понять.Есть куча мануалов (лучше смотреть свежие) и minikube, где все довольно просто делается.
докер сварм и уперся что он сетку свою виртуальную не может больше 100 мегабит раскочегаритьнет у него никакой своей сетки и в помине не было. Используются нативные механизмы ОС.
Я мониторю память с помощью прометея и нод экспортераКрайне честные системы для решения проблем с утечкой памяти. А что по этому поводу имеют сказать аппликухи операционной системы?
пробежался по самым большим процессамПроцесс это запрос приложения к операционной системе на выделение аппаратных ресурсов. Каких, откуда и сколько выделить уже на усмотрение ОС, которая будет выделять и наделять по ситуации. Твои 1.5Гб в состоянии idle (не так уж и много) могут быть почти все на диске. Анонимные страницы памяти ОС обычно складирует с разделе подкачки. У тебя же он есть? Всё-таки сервер базы данных. Сами производители постгреса жалуют, чтобы он был.
горутины вам не подойдутМиллион соединений и более "одновременно" далеко не всякий сервер потянет, тем более реальных. Тут уже проблемы с самой операционкой. Момент следующий - держать прод даже тысячу активных соединений без резерва та ещё лотерея. По уму будет тот или иной балансировщик, раскидывающий трафик по куче серверов. То бишь по памяти можно что-то придумать.
Просто ответ такой воодушевительный, но хотелось бы узнать подробнееМускуль уже неплохо доведён до ума и многое может. Поэтому раскрытие потенциала Мускуля это уже удел умения обращения с этим инструментом.
Какие могут быть ещё оптимизации?Начиная с настроек операционной системы, которые часто никак по умолчанию не годятся для работы с базой данных. Затем настройка сервера Мускула в зависимости от имеющегося железа, возможностей операционки, профиля работы базы. Потом оптимизация твоих запросов. В оснастке, которая идёт к Мускулу довольно годный планировщик запросов. Заканчивая организацией операций для поддержки данных в базе в актуальном состоянии: индексы надо обновлять (без них не получишь приемлемой производительности); бэкапы наше всё; со временем оптимизировать саму базу.
Судя по многим иным вещам, там нужен грамотный девопс. Именно девопс, а не человек, который всюду распихает кубы и непонятный мониторинг.