(почему не nginx/haproxy/любой другой юзерспейс-прокси)

мы имели проблемы на том что ELB, стоящий над apiserver'ами менял адреса, а кубелеты не перерезолвливали. из-за этого периодически кубелеты нахер отваливались от аписервера

У NLB адреса не меняются больше , может поможет

У NLB адреса не меняются больше , может поможет

мы иначе решили сделать (временно). домен отказа - AZ, в каждой AZ свой apiserver, кубелеты из AZ подключаются к apiserver'у в своей AZ.

NLB может и решит проблему, да.

(почему не nginx/haproxy/любой другой юзерспейс-прокси)

Потому что хочу магии: в ipvs запихну service ip внутренний от Kubernetes.svc.cluster.local, пока kubelet один, пойдет через ipvs, потом появится kube-proxy, он тоже через ipvs дойдет до apiserver, но затем установит iptables DNAT на тот же самый service ip. В итоге и кублет и сам kube-proxy начнут ходить через этот DNAT

кубернетес при запуске пода копирует данные из конейнера в новые пустые волюмы?

Потому что хочу магии: в ipvs запихну service ip внутренний от Kubernetes.svc.cluster.local, пока kubelet один, пойдет через ipvs, потом появится kube-proxy, он тоже через ipvs дойдет до apiserver, но затем установит iptables DNAT на тот же самый service ip. В итоге и кублет и сам kube-proxy начнут ходить через этот DNAT

до запуска кубелета вы не знаете адрес svc.cluster.local

до запуска кубелета вы не знаете адрес svc.cluster.local

Знаю, он стандартный

Как serviceCIDR +1

Навроде того, как в амазоне DNS сидит по vpcCIDR + 2

ну просто тот же самый kube-proxy в ipvs режиме поведет себя непредсказуемо с ручным ipvs для apiserver. и kube-router например тоже будет заводиться в непредсказуемом режиме. я о том, что это потенциально мохнатое решение, которое имеет побочные эффекты, которых при этом юзерспейс-прокси не имеет.

ну просто тот же самый kube-proxy в ipvs режиме поведет себя непредсказуемо с ручным ipvs для apiserver. и kube-router например тоже будет заводиться в непредсказуемом режиме. я о том, что это потенциально мохнатое решение, которое имеет побочные эффекты, которых при этом юзерспейс-прокси не имеет.

по этому у меня не будет kube-proxy в ipvs режиме :))

(если будет то ручной ipvs переведу на fwmark например)

Или откажусь от ipvs и руками DNAT пропишу

До того как kube-proxy поднимется. Решение мохнатое, может на что то напорюсь нехорошее, но пока как вы сказали, client-go не умеет нативно множество аписерверов приходится так :)

Или отказываться от HA

HA для apiserver ?

HA для apiserver ?

Да

а apiserver подом, вагон к кублету?

До того как kube-proxy поднимется. Решение мохнатое, может на что то напорюсь нехорошее, но пока как вы сказали, client-go не умеет нативно множество аписерверов приходится так :)

ну кмк haproxy на петле с актив-чеками аписерверов гораздо менее мохнато смотрится

ну просто тот же самый kube-proxy в ipvs режиме поведет себя непредсказуемо с ручным ipvs для apiserver. и kube-router например тоже будет заводиться в непредсказуемом режиме. я о том, что это потенциально мохнатое решение, которое имеет побочные эффекты, которых при этом юзерспейс-прокси не имеет.

Я не хочу за еще одним демоном вне куба следить. Если не бужет получатся, то буду haproxy из systemd поднимать, что поделать

Я не хочу за еще одним демоном вне куба следить. Если не бужет получатся, то буду haproxy из systemd поднимать, что поделать

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

а apiserver подом, вагон к кублету?

Речь про воркер ноды

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

А мне и не надо, его роль чтобы kubelet поднялся и запустил kube-proxy, дальше он не работает до след перезагрузки

а, вот почему ты спрашивал про -t nat PREROUTING и ipvs

С haproxy оно всегда в цепочке, а значит требования,выше

кубе-прокси, если мне память не изменяет, с аписервером общается НЕ через сервисный адрес, а напрямую

а, вот почему ты спрашивал про -t nat PREROUTING и ipvs

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

кубе-прокси, если мне память не изменяет, с аписервером общается НЕ через сервисный адрес, а напрямую

Ему можно сказать куда ходить

Я хочу ipvs вперед ручного DNAT попробывать потому что не надо разбираться как написать правила так, чтобы kube-proxy их не затер и чтобы имели меньший приоритет когда kube-proxy установит свои

вообще какой рекомендованный подход для деплоя многоконтейнерного приложения с общими файлами? запускать всё из одного образа?

что за общие файлы?

есть три основных пути

Volume / ConfigMap / Same Pod

например приложение + нжинкс который отдаёт статику из контейнера приложения

Они на разных портах что ли?

Господа, а насколько адекватно содержать в одном k8s кластере stage и testing?

testing == тот, на котором интеграционные тесты бегают (с CI)

да, нжинкс проксирует приложение

Ну такое я бы один подом делал.

это да. при создании emptyDir волюма в него копируется файлы из контейнера?

как в докере

или у меня просто будет пустая директория?

Есть мнение, что ты чуток путаешься

Зачем тебе emtyDir ? emtyDir это уже Volume и она всегда будет пустой

а если ты два контейнера сливаешь в один под, то у них будет общая Ы

fs

даже если они из разных образов поднимаются?

да

В этом суть пода

а где это в документации написано? https://kubernetes.io/docs/concepts/workloads/pods/pod/ тут только пишут что можно примаунтить общие волюмы

вообще какой рекомендованный подход для деплоя многоконтейнерного приложения с общими файлами? запускать всё из одного образа?

helm chart?

вот даже тут используют волюмы для доступа к файлам https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

Мммм... Данные в volume. Неткопируется. Volume монтируется в fs. Как любой маунт

Народ, кубер умеет в своих сценариях yaml подставлять системные переменные? Вроде kind: Service metadata: name: ${SERVICE_NAME} ? Чтобы на основе 1го типового сценария нагенерить кучу ресурсов

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

Видимо так и будет. Мало ли думал из коробки есть

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

пошел строгать буратин =)

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

Спасибо!

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

не надо можно ставить jinja в докер котнейрене и там рендерить темплейт docker run -v`pwd`:/data --rm vikingco/jinja2cli --format=yaml /data/k8s/slave_docker.yml /data/k8s/env_slave_docker.yml > slave_docker_rendered.yml && docker run -v`pwd`:/root/.tmuxinator --rm stevenaldinger/tmuxinator:latest debug slave_docker_rendered вот такую грязь можно

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

Helm

да, или helm

Народ, а кто чем запускает все на кубере? Вот есть допустим собрал образ, пихнул в registry, дальше надо запустить его в кубере, вопрос - чем?

я пока что ручками...но это временно

буду helm наверно юзать

Народ, а кто чем запускает все на кубере? Вот есть допустим собрал образ, пихнул в registry, дальше надо запустить его в кубере, вопрос - чем?

gitlab-ci/jenkins/helm

Можно helm, но его в любом случае надо чем то дергать, так?

gitlab-ci/jenkins/helm

Спасибо, а чем helm дергаете?

ручками

Спасибо, а чем helm дергаете?

башем

башем

а баш дергается с дженкинса?

а баш дергается с дженкинса?

с jenkins и с рабочего места админа

Понятно, я просто думаю над тем как лучше будет сделать автовыкладку всего этого дела. В итоге получается пока примерно так: gogs->teamcity->registry-> ? -> kubernetes

но судя по всему придется все же писать действительно что-то свое

в teamcity после пуша в регистри - helm upgrade

в teamcity после пуша в регистри - helm upgrade

Просто helm пока вообще не трогал, не очень понимаю как он работает еще, вот смотрю. Плюс - в итоге выходит что оно должно быть на той же машине на которой teamcity?

Хотя что это я, там же можно скрипты запускать, чет туплю(

не обязательно

Вопрос в том как работает helm upgrade и не должно ли для того что бы он так все обновил у него быть куча файликов на всех?