удаляется по дефолту. вопрос как этот дефолт изменить

удаляется по дефолту. вопрос как этот дефолт изменить

прямо весь volume удаляется (скажем EBS) или только PV ресурс?

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

persistentVolumeReclaimPolicy

Volumes that were dynamically provisioned are always deleted

о как, ошибся

котаны, а кто нибудь знает как защитить PV от случайного удаления PVC?

выставить ему reclaim policy

http://contiv.github.io

есть кто делал/хочет такое сделать?

если кому то интересно такое по работе пишите в личку, обсудим

также интересны экспертные мнения по данному вопросу.

не знаю чем contiv хороши, но вот есть перцы https://www.aporeto.com/product/ , которые очень интересно внедряют информацию о приложении ( JWT токен кажется или ссылку где его найти) внутрь SYN/SYN-ACK/ACK хэндшейка :) В итоге в момент хендшейка уже ясно, кто стучится и имеет ли право, так же все проверки только вовремя этих трех пакетов происходит,после них уже никакого оверхеда - просто данные льются напрямую, как будто и не было ничего :)

вот это: https://github.com/aporeto-inc/trireme

contiv с Cisco дружит. если есть у кого ACI или CliQr

contiv и есть циско, у этих прожектов немного разные назначения

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

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

эт для ооооч больших интерпрайзов, кажется

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

вот это киска

коты, налетай

вот и я про что.

Верно понимаю, что с Docker 17.06 Kubernetes пока не поднять?

Ещё вот такую дичь обнаружил: https://github.com/coreos/tectonic-installer Кто-нибудь использовал?

выставить ему reclaim policy

reclaim как я понял только для статичных PV годится. типо как их очищать от старых данных

Volumes that were dynamically provisioned are always deleted

да вот как раз хотелось бы этот always заменить на что нибудь

в случае ceph, volume тупо удаляется без возможности восстановления. и как я понял это стандартная политика для dynamic PV provisioning

Ещё вот такую дичь обнаружил: https://github.com/coreos/tectonic-installer Кто-нибудь использовал?

глубоко знаком. не советую

Пытаюсь поднять с помощью kubeadm, упорно flannel 1/2, время от времени проскакивает "Ready". kubeadm init --pod-network-cidr=10.244.0.0/16 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml Собственно, ЧЯДНТ? В syslog пачки сообщений о том, что тот или иной контейнер не найден, вида 445 cni.go:258] CNI failed to retrieve network namespace path: Cannot find network namespace for the terminated container "5db3f6... Затем 445 cni.go:294] Error adding network: open /run/flannel/subnet.env: no such file or directory Jul 5 04:42:02 localhost kubelet[445]: E0705 04:42:02.214693 445 cni.go:243] Error while adding to cni network: open /run/flannel/subnet.env: no such file or directory И другие ошибки, связанные с subnet.env-файлом. Почему flannel его не генерирует? :(

глубоко знаком. не советую

можно подробнее?

Верно понимаю, что с Docker 17.06 Kubernetes пока не поднять?

У меня работает.

а кто нибудь прикручивал linkerd или istio? Мне очень нравится идея по максимуму делегировать инфраструктуре такие штуки как circuit breaker, retry policy, метрики L4 и L7, всякие service dicovery

Какая версия Docker?

У меня работает.

Какая версия Docker?

Docker 17.06.0-ce Kubernetes 1.7

Docker 17.06.0-ce Kubernetes 1.7

в кубере же вроде написано, что он неподдерживает такую версию докера

в кубере же вроде написано, что он неподдерживает такую версию докера

Там написан ворнинг при старте кубеадма, что он протестирован для работы с докером 1.12, а с версиями выше - на ваш страх и риск.

Там написан ворнинг при старте кубеадма, что он протестирован для работы с докером 1.12, а с версиями выше - на ваш страх и риск.

этот варнинг с версии 1.7 убрали

этот варнинг с версии 1.7 убрали

[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. [init] Using Kubernetes version: v1.7.0 [init] Using Authorization modes: [Node RBAC] [preflight] Running pre-flight checks [preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.06.0-ce. Max validated version: 1.12

хм

@tetramin, та же версия, также пробовал и на 17.05 на "чистой" машинке. Какие-то дополнительные действия при поднятии делались, кроме kubeadm init --pod-network-cidr=10.244.0.0/16 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml ? Оно секунд 20 в Ready после переезагрузки, а потом бесконечно падает в 1/2.

@tetramin, та же версия, также пробовал и на 17.05 на "чистой" машинке. Какие-то дополнительные действия при поднятии делались, кроме kubeadm init --pod-network-cidr=10.244.0.0/16 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml ? Оно секунд 20 в Ready после переезагрузки, а потом бесконечно падает в 1/2.

Да. Ещё одно действие, с которым я тоже мучился: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

А при включении rbac дополнительно придется указывать всякое там только своим подам, kubernetes с собственными разберется сам?

А при включении rbac дополнительно придется указывать всякое там только своим подам, kubernetes с собственными разберется сам?

На сколько я понял, он там с версии 1.5+ по дефолту включен. Например, дашборду тоже нужно rbac, но это в инструкции есть. И weavescope тоже. Своим подам надо будет, если ты где-то будешь это использовать.

Хм... Надо же. И действительно, теперь "running" всё. Спасибо. :З

Ребят, как лучше прокинуть docker.sock с хоста внутрь пода?

Ребят, как лучше прокинуть docker.sock с хоста внутрь пода?

маунтом?

А кто нибудь знает аналог AWS с датацентрами в России?

А кто нибудь знает аналог AWS с датацентрами в России?

selectel vpc?

Ребят, как лучше прокинуть docker.sock с хоста внутрь пода?

А зачем? не советуют использовать docker на хосте, которым управляет кубернетес. Если надо позапускать контейнеры или получить какую-нибудь инфу, лучше использовать api кубернетеса и сервисные аккаунты.

selectel vpc?

гляну спасибо

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

Ребят, а кто какие средства использует для мониторинга http запросов между сервисами внутри куба?

heapster

кто-нибудь сталкивался с этой мессагой? навскидку на что может ругаться? StatefulSet in version "v1beta1" cannot be handled as a StatefulSet: quantities must match the regular expression '^([+-]?[0-9.]+)([eEinumkKMGTP]*[-+]?[0-9]*)$' https://pastebin.com/Z6QzF7Cy

кто-нибудь сталкивался с этой мессагой? навскидку на что может ругаться? StatefulSet in version "v1beta1" cannot be handled as a StatefulSet: quantities must match the regular expression '^([+-]?[0-9.]+)([eEinumkKMGTP]*[-+]?[0-9]*)$' https://pastebin.com/Z6QzF7Cy

Может там, где args ты передаёшь в контейнер? Лишний пробел. Хотя, вроде что-то другое.

я с деплоймента переделал, деплоймент норм запускался

(это кстати не лишний пробел, просто pastebin так отрендерил %(

Да. Точно.

https://github.com/kubernetes/apimachinery/blob/master/pkg/api/resource/quantity.go вот тут ругается

не могу понять какую единицу измерения я неправильно написал / опустил

а все допер, сори :)

ERROR: S client not available

размер диска надо в Gi а не Gb, протупил

можно подробнее?

Да, сейчас расскажу

Вообщем поднял кластер на CoreOS из 8 нод. Туда пересли внутренние сервисы, типа TeamCity, YouTrack, sentry, registry и прочее. Там же крутился ceph. Все это работало до тех пор, пока не начали переносить на кластер нагрузки с прода. После этого ноды начали умирать как мухи - одна за другой. Умирала нода, на которой был запущен именно этот контейнер. После этого под скедулился на другой ноде и умирала она. Ноды умирали по жесткому - уходили в ребут. Причина пока не ясна, т.к. системный раздел при загрузке вайпится. Что вообще происходит догадались не сразу. Сейчас потихоньку даем нагрузку и ждем когда ребутнется нода, чтобы посмотреть лог. Хотя не факт, что в логе что-то будет. Возможно происходит kernel panic, тогда врятли что-то запишется в лог. Это bare-metal. OVH. На машинах этого же класса прод живет спокойно под CentOS (без кубера). Собственно сейчас недеюсь получить какой то лог, а потом буду пробовать кубер завести под CentOS.

у нас подобное было, но вроде как вылечилось (тьфу-тьфу) апдейтом ядра с 3.16 на 4.9, вертится на Debian

Вообщем поднял кластер на CoreOS из 8 нод. Туда пересли внутренние сервисы, типа TeamCity, YouTrack, sentry, registry и прочее. Там же крутился ceph. Все это работало до тех пор, пока не начали переносить на кластер нагрузки с прода. После этого ноды начали умирать как мухи - одна за другой. Умирала нода, на которой был запущен именно этот контейнер. После этого под скедулился на другой ноде и умирала она. Ноды умирали по жесткому - уходили в ребут. Причина пока не ясна, т.к. системный раздел при загрузке вайпится. Что вообще происходит догадались не сразу. Сейчас потихоньку даем нагрузку и ждем когда ребутнется нода, чтобы посмотреть лог. Хотя не факт, что в логе что-то будет. Возможно происходит kernel panic, тогда врятли что-то запишется в лог. Это bare-metal. OVH. На машинах этого же класса прод живет спокойно под CentOS (без кубера). Собственно сейчас недеюсь получить какой то лог, а потом буду пробовать кубер завести под CentOS.

если не секрет - как решили проблему бэкапа? я сейчас изучаю варианты

пока никак не решили

OVH предлагает 10TB за 64 евро кажется. Именно для бекапов. Доступ по FTP(S) и NFS. Вот думаем его и взять

а то S3 дороговато выйдет

у нас подобное было, но вроде как вылечилось (тьфу-тьфу) апдейтом ядра с 3.16 на 4.9, вертится на Debian

сейчас у нас ядро 4.9.24-coreos

причем уже успели ребутнуться все ноды из восьми)

а версия докера?

1.12.6

@nailgunster, это история про развертывание с tectonic, так?

разворачивал своим провиженером https://github.com/nailgun/seedbox

но думаю суть не в этом

сейчас эта версия на всех нодах https://coreos.com/releases/#1353.7.0

в момент разворачивания она была latest stable

пока никак не решили

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

ютрек сам себя бекапит. там используется один вольюм для данных и один для бекапов

но надежного бекапа пока нет

ютрек сам себя бекапит. там используется один вольюм для данных и один для бекапов

то есть никак не решили

я это и написал выше)

пока с ребутами не разобрался, смысл что-то бекапить

подход отличный. Я последние 2 месяца пытаюсь локализовать возможные риски, чтобы не уничтожить пользовательскую инфраструктуру случайной ошибкой (хотя кластер у меня уже 3 месяца как работает, в общем-то). :)

кроме ютрека особо терять нечего. конфигурации в teamcity меняются редко, sentry больше как лог ошибок не более того. а вообще про бекапы согласен. как раз думал как это сделать до того как все посыпалось

бакулу натравите сырые диски срезать и всё тут :) ну если денег много можно акронис

@nailgunster, тот же новоразвернутый через kubeadm. Стабильненько падает kube-dns в 1/3 2/3. Может ещё какое-нибудь дополнительное действие было там? :)

когда нода сама уходит в ребут, у меня остается только два подозреваемых - железо или ядро. железо исключаю, т.к. история повторилась на восьми нодах из восьми и на таком же железе рядом стабильно работает CentOS. остается ядро. но чтобы не быть голословным, сейчас жду пока опять крашнется чтобы увидеть лог. там либо будет что-то интересное, либо он просто оборвется в произвольном месте, что скорее всего будет значить kernel panic…

когда нода сама уходит в ребут, у меня остается только два подозреваемых - железо или ядро. железо исключаю, т.к. история повторилась на восьми нодах из восьми и на таком же железе рядом стабильно работает CentOS. остается ядро. но чтобы не быть голословным, сейчас жду пока опять крашнется чтобы увидеть лог. там либо будет что-то интересное, либо он просто оборвется в произвольном месте, что скорее всего будет значить kernel panic…

а это тебе не хостер случяаем ноды ребутит?

у них есть прикол, что если включен их мониторинг, и при этом нода недоступна, то они её ребутят

я мониторинг отключил