https://github.com/kelseyhightower/kubernetes-the-hard-way/commit/4ca7c4504612d55d9c42c21632ca4f4a0e9b4a52

и с бешенной скоростью закрываются все opened issues

https://github.com/kelseyhightower/kubernetes-the-hard-way/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

https://github.com/kelseyhightower/kubernetes-the-hard-way/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

супер

K8s 1.7.5 out now

о хардвейщики подтянулись

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

судя по коммиту проще заново прочитать

да не самый удачный пример коммита ))

Ребят, а кто как мониторит/алертит свободное место в pv?

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

привет)

` kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE db-data-claim-1 Bound gce-disk-1 50Gi RWO 49m `

Bound нормальный статус?

Как правильно монтировать вольюмы в контейнер запущенный не из под рута?

https://stackoverflow.com/questions/35213589/docker-container-with-non-root-user-deployed-in-google-container-engine-can-not

Трюк с fsGroup у меня почему-то не всегда работает

Bound нормальный статус?

да. это "рабочий" статус

Всем привет. Переделал сеть внутри работающего кубера на обычную, не оверлай сеть, доступность между подами разных нод есть. Почти всё работает, но внутри подов не может законектиться на api кубера через сервис. Например, на kube-dns при коннекте к api кубера таймаутит. В kube-dns установлен serviceAccountName, я вытащил токен для него - через curl на ноде с этим токеном в хедере подключается. Куда копать?

что значит "обычная сеть"

но вообще если я всё прально понял, то копать в API tables и kube-proxy

это раз и два Копать в настройки kube-dns

потому как по умолчанию он его ищет на kubernetes.default.svc

Ну просто на роутах. На каждой ноде фиксированный cidr. И каждая нода знает на какую ноду идти для каждой подсети. Как раз падает на создании kube-dns, не он там по ip пытается зайти на kube-api (в моём случае https://10.96.0.1:443). Видимо, да нужно кописать в iptables и kube-proxy. Хреново, что там нету нормальной маршрутизации, хрен попингуешь

не знаю, что было. Но поменял proxy-mode с userspace на iptables и всё заработало

Пропустил интересный момент, даже epam начал играть с Kubernetes) https://youtu.be/o4fjUkFm7NE?t=1h14m43s

Денис, раздай модерки! :)

добрый у кого была ошибка? запускаю postgres в кубе initdb: could not look up effective user ID 2000: user does not exist

Была такая ошибка при запуске в докере. Права на volume нужно проверить

добрый у кого была ошибка? запускаю postgres в кубе initdb: could not look up effective user ID 2000: user does not exist

Контейнер сами создавали

?

нет, да я уже понял все ))

выставил права на папку смонтированную 700

для постгреса

и с

все

о

к

оффтоп: кто юзает istio, они уже научились коннектить сервисы в разных неймспейсах?

оффтоп: кто юзает istio, они уже научились коннектить сервисы в разных неймспейсах?

через полторы недели отвечу

ок буду ждать :)

ок буду ждать :)

у меня переодически есть неопродолимое желание на openresty нечто похожее накалякать

PoC сделать

ты конкретно про envoy или про всю связку в целом?

да, начать с малого хочу

эти ребята из истио на мой взгляд немного "того"

в своем желании пилить свой плюснутый велосипед

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

Может кому полезно будет.

Модераторы?

@DenisIzmaylov ???

Владельцы кубернетиса в чате есть ? скажите там серисам запущеным под ним встроенный etcd доступен на почитать/пописать ?

можно конечно

ERROR: S client not available

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

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

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

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

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

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

Поднимать отдельный

ясна спасибо.

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

а почему?

а почему?

переформулируйте пожалуйста вопрос.

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

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

аргументы за - нативность. меньше адмтнистрирования. агрументы против - взаимовлияение.

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

есть вероятность завалить завалить сам куб либо просто случайной нагрузкой, либо "ну я думал там только мои значения, поэтому приложение затирает вообще всё раз в час ))))"

есть вероятность завалить завалить сам куб либо просто случайной нагрузкой, либо "ну я думал там только мои значения, поэтому приложение затирает вообще всё раз в час ))))"

"создать новый, чтобы не завалить старый" - звучит рационально и вполне себе понятно. спасибо!

ectd хранит всю инфу касательно кубер кластера, включая и секреты, вот как-то не шибко интересно что бы левый под мог воспльзоваться воими секретами, а шифрование секретов в etcd в альфа версии с 1.7 версии кубера

этот момент я специально оговорил. кубер мой и кроме меня там никого нет.

есть неилюзорный шанс, что из-за пьяных глаз можно поломать кластер кубера

тупо записав не то ни туда

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

имея тот же опенстек, вы же не пытаетесь писать в его мускуль клиентские базы)

плюсану оратора

можно писать в кубовский etcd, но шанс поломки увеличивается

давайте еще про ci/cd поговорим да

а разве, реально, кто-то умеет в настоящий ci / cd