нет - аминь

могу ошибаться, конечно, сам изучаю тему и в проде кубера нет

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

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

Вот я как раз на логическом и хочу. На уровне сети это ведь именно жесткое ограничение на уровне фаервола?

С практической точки зрения нэймспэйсы используются в ResourceQuota, NetworkPolicy и для упрощения RBAC. Можно начать проектирование с этого.

Netsil Visualizes the Performance of Microservices - The New Stack https://thenewstack.io/netsil-visualizes-performance-microservices/

Спам пришел по куберу

С практической точки зрения нэймспэйсы используются в ResourceQuota, NetworkPolicy и для упрощения RBAC. Можно начать проектирование с этого.

спасибо, посмотрю подробнее в эту сторону

Мне тоже спам пришел

Мне тоже спам пришел

всмысле? что за спам?

Netsil

Netsil

А есть нечто подобное но бесплатное?

хз

Жаль( Ребят, если кто пользует нечто подобное но бесплатное - поделитесь названием пожалуйста)

Кто ставил на 1.8.x Prometheus+Grafana?

все понимаю. Вы читали их описание этой фичи? Можете указать где они врут?

У них типичная модель транзакций, которая ничто иное как at-least-once delivery. Особенно радует вот это: > On the consumer side, the guarantees are a bit weaker. In particular, we cannot guarantee that all the messages of a committed transaction will be consumed all together. Другими словами, на стороне клиента/потребителя (которого обычно и имеют в виду, когда говорят про режим доставки), никаких гарантий никто предоставлять и не собирался (и все равно они по-прежнему невозможны). Подробнее читать к сожалению нет времени, поэтому на самом деле в протокол я не вник.

https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0 очень клевый gist

Кто ставил на 1.8.x Prometheus+Grafana?

че там опять? =)

https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0 очень клевый gist

как мало я еще про секурити знаю

как мало я еще про секурити знаю

жалко только что 90% приложений не заведется с таким сетапом

по большей части изза требования не стартовать под рутом

че там опять? =)

https://github.com/giantswarm/kubernetes-prometheus не завелось, джоба подвисла, думаю с rbac nhf,ks

# Allow core volume types. volumes: а интересно, эти пермишны только к поду относятся? то есть если я запрещу тут юзать configmap но деплоймент получает к нему доступ - все норм будет? просто из пода нельзя будет по api обратиться к configmap?

https://github.com/giantswarm/kubernetes-prometheus не завелось, джоба подвисла, думаю с rbac nhf,ks

не смотрел в сторону https://github.com/coreos/prometheus-operator ? имхо удобнее

https://github.com/giantswarm/kubernetes-prometheus не завелось, джоба подвисла, думаю с rbac nhf,ks

я как обычно из helm накатыал и включил создание rbac сущностей

Комрады, был ли у кого-то из вас опыт развёртывания тайфуна в baremetal? https://typhoon.psdn.io/ Как оно по сравнению с kubespray?

А есть где-нибудь нормальное описание уязвимостей при запуске из-под рута? А то я что ни погуглю, так там очередной умелец монтирует хостовую систему целиком и говорит "вот, видите, я могу в bin записать что угодно с любым setuid"

ну вот

https://www.oreilly.com/ideas/five-security-concerns-when-using-docker

ну там так, общие фразы

спасибо, но общие фразы я читал не раз

ну а как иначе, это тоже самое что, зачем приложение запускать не из под рута

а иначе можно описать реальную атаку, а не просто стращать соответствием айдишников

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

да как его взламывают-то

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

так вы эксплоит хотите или понять риски?

под рутом сервис как правило может писать сколько угодно куда угодно

порождать процессов сколько угодно

итд итп

риски сто лет назад описаны

и я это все знаю

ну тогда вопрос не должен возникать

ну например

https://www.cvedetails.com/cve/CVE-2016-9962/

между "запуск бинарника в контейнере из-под рута" и "захват рутового процесса на хосте" есть огромная белая пропасть, которую никто не стремится объяснить

https://www.cvedetails.com/cve/CVE-2016-9962/

спасибо

https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html

Как минимум зачем людям давать возможность внутри контеинера, что-то ставить?

господи, инфосек мечты

господи, инфосек мечты

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

Можно кстати и без монтирования, если твой бинарь имеет закладку и запущен под рутом внутри контейнера, можно им спокойно ставить всякую херню. К примеру, если нету cfs, то можно помайнить или поддосить кого-нибудь

У них типичная модель транзакций, которая ничто иное как at-least-once delivery. Особенно радует вот это: > On the consumer side, the guarantees are a bit weaker. In particular, we cannot guarantee that all the messages of a committed transaction will be consumed all together. Другими словами, на стороне клиента/потребителя (которого обычно и имеют в виду, когда говорят про режим доставки), никаких гарантий никто предоставлять и не собирался (и все равно они по-прежнему невозможны). Подробнее читать к сожалению нет времени, поэтому на самом деле в протокол я не вник.

Ну это вы придираетесь. Они говорят примерно: вот в файл мы записали, но поскольку читатель может сам выбирать откуда читать, он не обязательно прочтет это сообщение. Так можно про все сказать :) самое главное там то, что если ты читаешь сообщение, другого такого (его дупликата) точно не будет. Это и есть exactly once.

Комрады, был ли у кого-то из вас опыт развёртывания тайфуна в baremetal? https://typhoon.psdn.io/ Как оно по сравнению с kubespray?

Я его за основу взял для своего велосипеда. Могу ответит на вопросы

Я его за основу взял для своего велосипеда. Могу ответит на вопросы

в разрезе развёртывания и масштабирования по сравнению с kubespray удобнее?

https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0 очень клевый gist

Спасибо.еще в папке clusters/gce сокровищницу недавно нашел по допишу куба под прод

Я его за основу взял для своего велосипеда. Могу ответит на вопросы

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

в разрезе развёртывания и масштабирования по сравнению с kubespray удобнее?

Я кубспрей не смотрел, но осуждаю :) так что предвзят. из хорошего в посейдоне: все на CoreOS, все по iPXE, кластер получается self hosterd, так что при некоторой аккуратности можно директорию со всеми ресурами bootkube/assets/manifests подцеплять из отдельной git репы, в итоге деплой обновлений кластера становится очень похожим на деплой приложений в кластер, т.е. все плюшки ci/cd но для инфраструктуры

Еще из хорошего: Использует bootkube, а там сертиикаты очень удобно разложены (и вообще все по сертификатам включая etcd), можно очень легко сделать чтобы на etcd была отдельная ca chain, а значит на нодах просто физически не будет лежат сертификата по которому можно пойти в etcd и слить все данные. Насколько я знаю все куб инсталлеры эту проблему не решают вообще никак

Ну это вы придираетесь. Они говорят примерно: вот в файл мы записали, но поскольку читатель может сам выбирать откуда читать, он не обязательно прочтет это сообщение. Так можно про все сказать :) самое главное там то, что если ты читаешь сообщение, другого такого (его дупликата) точно не будет. Это и есть exactly once.

Нет, они не это там говорят. И exactly once - это ровно однократное чтение сообщения, а читатель может закрашиться до того, как сохранит состояние о прочтении.

Из того что надо допилить: Kube proxy ходит на один apiserver, решил пока созаднием ipvs на каждой ноде, в ipvs ходит kube proxy , а оттуда уходит на один из нескольких apiserver

Еще манифесты в bootkube простенькие, например не разнесены по service accounts, но это решается как раз созданием репы и ветки там, в ветке можно все запатчить как надо, при этом подтягивать обновления из будущих версий bootkube не теряя своих правок. Я как освобожусь доделки может в bootkube отошлю

Нет, они не это там говорят. И exactly once - это ровно однократное чтение сообщения, а читатель может закрашиться до того, как сохранит состояние о прочтении.

У кафки была проблема, что при отправке сообщение может задублироваться, они это решали. Про чтение надо уж быть реалистом, в классическом. SQL тоже коммит транзакции может недолететь до сервера :)

День добрый товарищи! Подскажите: запустил приложение shock-shop в кластере: sock-shop carts-794f6cc876-v5m5d 1/1 Running 0 1d 10.233.65.4 kz-k8snd02 sock-shop carts-db-787f4b7896-hj7fz 1/1 Running 0 1d 10.233.66.6 kz-k8snd01 sock-shop catalogue-845484987d-9s5f7 1/1 Running 0 1d 10.233.65.5 kz-k8snd02 sock-shop catalogue-db-67dffd76dc-vg6r4 1/1 Running 0 1d 10.233.66.7 kz-k8snd01 sock-shop front-end-6786c5b4b9-k68kh 1/1 Running 0 1d 10.233.66.8 kz-k8snd01 sock-shop orders-5568884f5-dbn4r 1/1 Running 0 1d 10.233.66.9 kz-k8snd01 sock-shop orders-db-66f56c7d6d-lq42h 1/1 Running 0 1d 10.233.65.6 kz-k8snd02 sock-shop payment-9f56ff4d-mnnds 1/1 Running 0 1d 10.233.65.7 kz-k8snd02 sock-shop queue-master-75987c9876-9jkps 1/1 Running 0 1d 10.233.65.8 kz-k8snd02 sock-shop rabbitmq-55998c84cd-twp5j 1/1 Running 0 1d 10.233.65.9 kz-k8snd02 sock-shop shipping-6b7599657-jw4tl 1/1 Running 0 1d 10.233.65.10 kz-k8snd02 sock-shop user-7dd55b89b6-n5lmv 1/1 Running 0 1d 10.233.66.10 kz-k8snd01 sock-shop user-db-57689444f9-clsk2 1/1 Running 0 1d 10.233.65.11 kz-k8snd02 НО curl -v https://kz-k8smst01:30001 * About to connect() to 172.28.9.200 port 30001 (#0) * Trying 172.28.9.200... * Connected to 172.28.9.200 (172.28.9.200) port 30001 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5938 (PR_END_OF_FILE_ERROR) * Encountered end of file * Closing connection 0 curl: (35) Encountered end of file Соответсвенно и в браузере не грузит Что не так делаю?

между "запуск бинарника в контейнере из-под рута" и "захват рутового процесса на хосте" есть огромная белая пропасть, которую никто не стремится объяснить

В ядрах локальные уязвимости то и дело находят. Если есть рут в контейнере, то больше возможностей создать какой нибудь raw socket с экзотическими опциями, послать пакет самому себе, вызвать завихрение мозгов у ядра и выполнить код ядром. Зачем испытывать судьбу? Рут в контейнерах крайне редко нужен, по это его надо запрещать на уровне podcsecurity policy и спать спокойнее

Спасибо.еще в папке clusters/gce сокровищницу недавно нашел по допишу куба под прод

в паблик? :)

да, в самом коде kubernetes

Подскажите куда копать хоть: curl -v https://172.28.9.200:30001 * About to connect() to 172.28.9.200 port 30001 (#0) * Trying 172.28.9.200... * Connected to 172.28.9.200 (172.28.9.200) port 30001 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5938 (PR_END_OF_FILE_ERROR) * Encountered end of file * Closing connection 0 curl: (35) Encountered end of file Не хочет отвечать приложение

В самом кубернетесе может где подкрутить надо?

Я его за основу взял для своего велосипеда. Могу ответит на вопросы

а как у typhon происходит апгрейд на новые версии кубера? они вроде даже заявляли что он такую фичу не поддерживает, но сейчас в описании не нашел ничего.

Бодрого дня! Подскажите пожалуйста про установку кубера. Если делаю cubeadm init до запуска cubelet.service, то получаю кучу ошибок про невозможность получить даннные с разных /healthz, а запустить cubelet не получается т.к. "error: unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory", который быть создан командой cubeadm init. Как такое можно разрезолвить?

а как у typhon происходит апгрейд на новые версии кубера? они вроде даже заявляли что он такую фичу не поддерживает, но сейчас в описании не нашел ничего.

kubelet - надо редеплоить ноды. Все остальное - просто kubectl apply ибо оно self hosted

понятно, обновление через ж. т.е. руками

понятно, обновление через ж. т.е. руками

kubectl apply как раз самый прямой способ :)

ab -t 20 -c 20 http://echo.example.com/doku.php 3x node k8s with ingress: 6250 reqs 3x node k8s with nodePort: 806 reqs (each node) 2x node k8s with ingress: 4250 reqs Результаты какие-то удивительные, но приятные, может кто-нибудь на своем/тестовом кластере прогнать, для сравнения ?

Привет всем! Подскажите, а как правильно деплоить код в kube? Т.е. как правильно ложить сами сорцы приложения в контейнеры? Нужно ложить в отдельный обычный volume? Или лучше брать gitrepo volume? Или быть может есть какие-то более удобные инструменты?

правильно собрать код в контейнер и потом его деплоить

правильно собрать код в контейнер и потом его деплоить

Если каждый раз код ложить в контейнер, то будет уходить туча времени на это. Есть более быстрый способ? На данный момент докер контейнеры поднимаются локально и код просто монтируется туда. Т.о. на каждый чих с любым файлом, он уже новый лежит в контейнере. Есть какой-нибудь инструмент для аналогичного поведения?

Если каждый раз код ложить в контейнер, то будет уходить туча времени на это. Есть более быстрый способ? На данный момент докер контейнеры поднимаются локально и код просто монтируется туда. Т.о. на каждый чих с любым файлом, он уже новый лежит в контейнере. Есть какой-нибудь инструмент для аналогичного поведения?

есть. CI.

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