Так что не страшно

почему? l

Если для dev контура то можно)

Базы запихивать в кластер это дело так себе

для dev идеально, да

Пахнет пиздецом

вообще, если использовать нормальный персистенс и настроить бекапы, то в принципе не очень страшно

У нас база лежит на отдельной машине с ежесекундным бекапом и окном в 1 неделю

второй уровень это снапшот каждые сутки

с окном в полгода

и всё равно страшно

блин ребят вы смотря где что поднимаете и как настраиваете... начнем с железа?? nvme vs sas к примеру

ну при прочих равных дешевле постгрес развернуть отдельно от кубера

с хранилки или full-flash nutanix кластера

// у меня nvme был, но с openebs как pv, что всё тормозило

ну при прочих равных дешевле постгрес развернуть отдельно от кубера

вот с этим согласен на 100%

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

угу, полностью согласен

А постгрес нет

Столон - бог 21 века

Базы запихивать в кластер это дело так себе

Согласен, но если делать аккуратно.... Можно

ну при прочих равных дешевле постгрес развернуть отдельно от кубера

+100

Растолкуйте про Istio и роутинг по весам. Типа, на эту версию 20% трафика, на другую 80%

Растолкуйте про Istio и роутинг по весам. Типа, на эту версию 20% трафика, на другую 80%

А чего растолковывать

Примеры есть в офдоке

Почему не хочет работать? apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: test-frontend-rule namespace: test spec: host: test-frontend-svc subsets: - name: frontend-v3 labels: version: "3.0" - name: frontend-v4 labels: version: "4.0" — apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: test-frontend-80-20-route namespace: test spec: hosts: - test-frontend-svc http: - route: - destination: host: test-frontend-svc subset: frontend-v3 weight: 80 - destination: host: test-frontend-svc subset: frontend-v4 weight: 20

Упорно рисует по примерно 50%

Вот, собственно, проблема.

https://github.com/openstack/stackube

за что я это увидел в полвторого ночи

Это да.. скрещение ежа и ужа.

деплою VPN сервера в кубе, обнаружил побочный эффект, что если мер не принять то вся внутренняя сетка куба будет доступна если подключиться к такому VPN со своего компа (что, в общем-то, логично, но как-то до этого не задумывался). Это так, на заметку, может быть полезно для локальной разработки/дебага, чтобы не делать port-forward каждый раз. Можно со стороны VPN еще и пропушить клиенту кубовый DNS, и тогда прямо с компа можно в сервисы ходить: <service-name>.<namespace>.svc.cluster.local

деплою VPN сервера в кубе, обнаружил побочный эффект, что если мер не принять то вся внутренняя сетка куба будет доступна если подключиться к такому VPN со своего компа (что, в общем-то, логично, но как-то до этого не задумывался). Это так, на заметку, может быть полезно для локальной разработки/дебага, чтобы не делать port-forward каждый раз. Можно со стороны VPN еще и пропушить клиенту кубовый DNS, и тогда прямо с компа можно в сервисы ходить: <service-name>.<namespace>.svc.cluster.local

Интересное наблюдение. Действительно, все логично и юзкейс не очень очевиден был)

деплою VPN сервера в кубе, обнаружил побочный эффект, что если мер не принять то вся внутренняя сетка куба будет доступна если подключиться к такому VPN со своего компа (что, в общем-то, логично, но как-то до этого не задумывался). Это так, на заметку, может быть полезно для локальной разработки/дебага, чтобы не делать port-forward каждый раз. Можно со стороны VPN еще и пропушить клиенту кубовый DNS, и тогда прямо с компа можно в сервисы ходить: <service-name>.<namespace>.svc.cluster.local

Чет не понял. Так VPN на то и VPN чтобы попасть в сетку куба. Или вы его как-то иначе использовали?

Коллеги, может кто-то поделиться конфигом джобов для мониторинга kube-proxy/kube-scheduler/kube-controller-manager? В стандартном конфиге prometheus, устанавливаемого через helm, этого, похоже, нет.

Коллеги, может кто-то поделиться конфигом джобов для мониторинга kube-proxy/kube-scheduler/kube-controller-manager? В стандартном конфиге prometheus, устанавливаемого через helm, этого, похоже, нет.

Всё там есть

деплою VPN сервера в кубе, обнаружил побочный эффект, что если мер не принять то вся внутренняя сетка куба будет доступна если подключиться к такому VPN со своего компа (что, в общем-то, логично, но как-то до этого не задумывался). Это так, на заметку, может быть полезно для локальной разработки/дебага, чтобы не делать port-forward каждый раз. Можно со стороны VPN еще и пропушить клиенту кубовый DNS, и тогда прямо с компа можно в сервисы ходить: <service-name>.<namespace>.svc.cluster.local

для локальной разработки есть https://www.telepresence.io который все это делает из коробки и еще немного больше

Всё там есть

Не вижу в проме ни метрик данных компонентов. В качестве примера использую: для kube-scheduler - scheduler_volume_scheduling_duration_seconds_count для kube-controller - daemonset_adds для kube-proxy - kubeproxy_sync_proxy_rules_latency_microseconds_bucket

Чет не понял. Так VPN на то и VPN чтобы попасть в сетку куба. Или вы его как-то иначе использовали?

ну изначально нам был нужен просто VPN сервер. Его же нужно как-то установить.

ну изначально нам был нужен просто VPN сервер. Его же нужно как-то установить.

Вы имеете в виду что вам изначально нужен был не сам VPN, а гейтвей который выпустит вас в интернет с другой точки, наверное. Тогда да, но зачем такой в куб деплоить?

Вы имеете в виду что вам изначально нужен был не сам VPN, а гейтвей который выпустит вас в интернет с другой точки, наверное. Тогда да, но зачем такой в куб деплоить?

да, я имею ввиду такой гейтвей

Ребят ткните пальцем в доку, где про репликацию деплойментов почитать?

типо нагрузка большая, ебани мне 10 реплик

типо нагрузка большая, ебани мне 10 реплик

Horisantal Pod Autoscaler наверное )

Horisantal Pod Autoscaler наверное )

Точно

Пасеба

Вы имеете в виду что вам изначально нужен был не сам VPN, а гейтвей который выпустит вас в интернет с другой точки, наверное. Тогда да, но зачем такой в куб деплоить?

> но зачем такой в куб деплоить? Я рассматриваю его как любое другое приложение. А любое приложение мы деплоим в куб.

Куб в кубе. А внем openstack.

всем привет при подключении вокрека к мастеру, нужно на вокрере поставить kubeadm, kubeclt, kubelet. И выполнить kubeadm join ip:6443 --token token --discovery-token-ca-cert-hash hash ? больше ничего делать не надо?

докер тоже надо поставить

докер тоже надо поставить

а кроме докера и открытие портов в iptables?

вопрос в чем. Выполняю join, и он не проходит. В логах failed to run Kubelet: unable to load kubeconfig: stat /etc/kubernetes/kubelet.conf: no such file or directory

а если создать конфиги, то ругается на существующий ca.crt

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

вопрос в чем. Выполняю join, и он не проходит. В логах failed to run Kubelet: unable to load kubeconfig: stat /etc/kubernetes/kubelet.conf: no such file or directory

еееееее

а если создать конфиги, то ругается на существующий ca.crt

Возьмите ca.crt с мастера и замените на всех машинах

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

Чем деплоите?

Обычный yaml файл?

да

Возьмите ca.crt с мастера и замените на всех машинах

ща попробую

да

Ставьте ImagePullPolicy: Always

Для dev контура, самое то

Для dev контура, самое то

а для прода?

а для прода?

Ну для прода тут уже зависит от того как вы версионируете имеджи

Если у вас в проде все теги одинаковы то у меня для вас плохие новости

не, все сборки имеют свои версии. идея была чтоб сборку тегировать напрмиер тегов latest и чтоб кубер ее ставил, когда она появится в репе

Возьмите ca.crt с мастера и замените на всех машинах

спасибо! а можно как-то генерить kubelet.conf и admin.conf со своими параметрами? Пришлось руками менять server

спасибо! а можно как-то генерить kubelet.conf и admin.conf со своими параметрами? Пришлось руками менять server

А чем вы собираете кластер?

не, все сборки имеют свои версии. идея была чтоб сборку тегировать напрмиер тегов latest и чтоб кубер ее ставил, когда она появится в репе

Хмммм

А чем вы собираете кластер?

пока руками

А что вы используете в качестве CI/CD ?

А что вы используете в качестве CI/CD ?

jenkins

всё, разобрался

всё, разобрался

Отлично

jenkins

Ну тут надо подумать

Честно не знаю

не, все сборки имеют свои версии. идея была чтоб сборку тегировать напрмиер тегов latest и чтоб кубер ее ставил, когда она появится в репе

Дурацкая идея. Ставить надо осознано, а не по появлению тега в репозитории. Если у вас все релизы с тегом Лаетст, то куда вы откатываться будете в случае проблем? Как вы будете уверены, что везде одна и та же версия работает?

всем привет при подключении вокрека к мастеру, нужно на вокрере поставить kubeadm, kubeclt, kubelet. И выполнить kubeadm join ip:6443 --token token --discovery-token-ca-cert-hash hash ? больше ничего делать не надо?

отлаженные скрипты для установки куба kubeadm'ом. Установка как раз разделена на "скачать" и "установить". Отдельно мастеры, отдельно воркеры. Можно посмотреть, как сделано. https://github.com/travelping/cennsonic/blob/master/kube/docs/setup.md

отлаженные скрипты для установки куба kubeadm'ом. Установка как раз разделена на "скачать" и "установить". Отдельно мастеры, отдельно воркеры. Можно посмотреть, как сделано. https://github.com/travelping/cennsonic/blob/master/kube/docs/setup.md

спасибо

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

тегирование образа релизным тегом из гита + шаблонизация, например. И смена тега в деплойменте, когда вам это нужно (при деплое), после миграций, а не когда оно захочет прососаться в кубер и случайно сломаться. А голый latest это трудноотлаживаемая и почти не откатываемая дичь, хоть и сравнительно простая.