Коллеги, подскажите, никто не встречался с периодическими проблемами резолва внешних и внутренних доменов через kube-dns? Как-то диагностировали? Ошибки сопровождаются стандартным django.db.utils.OperationalError: could not translate host name "postgres" to address: Temporary failure in name resolution.

Спасибо!) Что-то там мало пока народу, продублирую еще здесь) Подскажите можно ли дать машинке compute engine доступ к GCR, чтобы docker на машинке без запросов аутентификации мог качать образы?

Да, можно. Используйте сервисвный аккаунт с доступом к gcr для инстанса. Внутри инстанса используйте gcloud docker pull

Да, можно. Используйте сервисвный аккаунт с доступом к gcr для инстанса. Внутри инстанса используйте gcloud docker pull

я просто использую drone.io и нет возможности кастомизировать аутентификацию и комманды pull

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

А это зачем? Они работают по отдельности

Мало ли, мож код для externalTrafficPolicy включается только для уровня NodePort и выше

Залили вторую версию, сам еще не прочитал https://docs.google.com/document/d/1q1UGAIfmOkLSxKhVg7mKknplq3OTDWAIQGWMJandHzg/mobilebasic

ребят расскажите что за сервис тип loadbalancer в k8s

я как понял это не касается локального кластера если я его сам поднял

я как понял это не касается локального кластера если я его сам поднял

Type LoadBalancer On cloud providers which support external load balancers, setting the type field to "LoadBalancer" will provision a load balancer for your Service. вроде ты все правильно понял, но я не настоящий доктор. я дальше локального minikube не сильно продвинулся, но в процессе..

Type LoadBalancer On cloud providers which support external load balancers, setting the type field to "LoadBalancer" will provision a load balancer for your Service. вроде ты все правильно понял, но я не настоящий доктор. я дальше локального minikube не сильно продвинулся, но в процессе..

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

читает /etc/kubectl/cloudprovider/*.conf (или как там правильный путь), оттуда получает тип, нужные credentials - и готово

читает /etc/kubectl/cloudprovider/*.conf (или как там правильный путь), оттуда получает тип, нужные credentials - и готово

тоесть aws и Google предоставляют одинаковое апи для создание этого Loadbalancer

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

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

у тебя minikube?

тоесть aws и Google предоставляют одинаковое апи для создание этого Loadbalancer

нет - https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/

у тебя minikube?

нет у меня Google kubernetes

кажется будто kubernetes спасёт мир

кажется будто kubernetes спасёт мир

очередной хайп просто

очередной хайп просто

ты опять тролишь

ты опять тролишь

1)А что, нельзя? 2)нет, смотрю на всю эту истерику вокруг куба и мне грустно

1)А что, нельзя? 2)нет, смотрю на всю эту истерику вокруг куба и мне грустно

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

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

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

и косяки в приложениях

ок, не истерика Вижу хайп. DevOps конфа куб куб куб

Хм, куб упрощает многие вещи но закрывать им косяки? Не думаю.

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

Так говоришь, как будто это - неправда.

ок, не истерика Вижу хайп. DevOps конфа куб куб куб

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

>Production-Grade Container Orchestration А я вот решил пару месяцев назад кубер в проде пощупать, и сегодня сразу два issue из багтрекера докера словил, в итоге две ноды их трех штормило. И к самому куберу нареканий нету, и все равно осадочек остался.

Так говоришь, как будто это - неправда.

что именно не правда?

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

не все понимают?) многие и не хотят

>Production-Grade Container Orchestration А я вот решил пару месяцев назад кубер в проде пощупать, и сегодня сразу два issue из багтрекера докера словил, в итоге две ноды их трех штормило. И к самому куберу нареканий нету, и все равно осадочек остался.

а чего за issues, если не секрет? а то тоже подумываю с этим жизнь связать :)

что именно не правда?

https://t.me/kubernetes_ru/43725 Наоборот - правда же.

Первая связана с meltdown-патчем ядра, выше тут кидали ссылку, выражалось в том что ноду штормило/контейнеры рестаровали. Сдрейнил плохую, поды уехали на другую и она словила это: https://github.com/moby/moby/issues/32827 - кронджобы запускались и зависали, инит-контейнеры не могли завершиться.

Я правда неподдерживаемый докер 17.12/17.09 юзаю, но вроде и в 1.13/17.03 багов полно

https://t.me/kubernetes_ru/43725 Наоборот - правда же.

ты про то что не серебряная пуля?

в 1.12/1.13 еще терпимо

коллеги, а подскажите пожалуйста начинающему.. сделал я statefulset, прикрутил к нему persistent volume и вроде бы все хорошо, но кое-что меня тревожит.. правильным ли будет в этот сторадж положить какой-нибудь файлик и под livenessProbe проверять его наличие? тогда в ситуации, пропажи стораджа можно будет попробовать передеплоить под? или существует какой-то другой способ? цель - не дать поду крутиться без стораджа...

коллеги, а подскажите пожалуйста начинающему.. сделал я statefulset, прикрутил к нему persistent volume и вроде бы все хорошо, но кое-что меня тревожит.. правильным ли будет в этот сторадж положить какой-нибудь файлик и под livenessProbe проверять его наличие? тогда в ситуации, пропажи стораджа можно будет попробовать передеплоить под? или существует какой-то другой способ? цель - не дать поду крутиться без стораджа...

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

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

хорошо если так, просто на локальном minikube такого поведения я не получил (делал kubectl delete pv и руками через minikube ssh лез и удалял каталоги), вот начал переживать и пока не смог найти информации о поведении в реальном окружении

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

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

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

это сторадж

коллеги, а подскажите пожалуйста начинающему.. сделал я statefulset, прикрутил к нему persistent volume и вроде бы все хорошо, но кое-что меня тревожит.. правильным ли будет в этот сторадж положить какой-нибудь файлик и под livenessProbe проверять его наличие? тогда в ситуации, пропажи стораджа можно будет попробовать передеплоить под? или существует какой-то другой способ? цель - не дать поду крутиться без стораджа...

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

коллеги, а подскажите пожалуйста начинающему.. сделал я statefulset, прикрутил к нему persistent volume и вроде бы все хорошо, но кое-что меня тревожит.. правильным ли будет в этот сторадж положить какой-нибудь файлик и под livenessProbe проверять его наличие? тогда в ситуации, пропажи стораджа можно будет попробовать передеплоить под? или существует какой-то другой способ? цель - не дать поду крутиться без стораджа...

k8s не знает что там с вольюмом дальше - отвалился он или это просто медленно всё. Пусть твое приложение само решает что там со стораджем (в sidecar контейнере, например) и проверяй через livenessProbe

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

но ведь ты знаешь какой размер вольюма который ты прикрутил? можно например через df/du проверять что там сейчас примаунчено, но это какой-то странный кейс. Если сторадж отвалился то и само приложение упадет ведь оно не сможет ни читать ни писать и какой бы там не был healthcheck у этого приложения - он должен упасть в таком случае тоже

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

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

Коллеги, подскажите, никто не встречался с периодическими проблемами резолва внешних и внутренних доменов через kube-dns? Как-то диагностировали? Ошибки сопровождаются стандартным django.db.utils.OperationalError: could not translate host name "postgres" to address: Temporary failure in name resolution.

Встречался, вынес etcd на отдельные сервера с ssd. И поставил на каждой ноде куба coredns

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

А ему пофиг. Это задача облака мониторить сервисы....

http://itmithran.com/monitoring-docker-containers-using-built-commands/

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

Кубелету опцию можно передать

я даже представить не могу а как этот kubectl знает о тот в каком он облаке

В параметрах задаётся cloud driver

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

Вы же знаете куда в контейнере монтируется сторадж :) так что можете сказать где файлик

k8s не знает что там с вольюмом дальше - отвалился он или это просто медленно всё. Пусть твое приложение само решает что там со стораджем (в sidecar контейнере, например) и проверяй через livenessProbe

Удивительно, что оно дает PV удалить нв лету

Удивительно, что оно дает PV удалить нв лету

ну да, сейчас сторадж еще пилить-неперепилить

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

ну да, сейчас сторадж еще пилить-неперепилить

Я тут недавно удивился, чего это нетривиальный performance fix (для альфа фичи правда) в 1.9 вдруг бэкпортнули и заглянул в код schedule_queue там мрак

Вы же знаете куда в контейнере монтируется сторадж :) так что можете сказать где файлик

не совсем знаю, ведь если у меня точка монтирования какая-нибудь /mnt/datadir и делаю там файлик через touch healthy, я изначально не знаю, оно создаст его в фс контейнера или в примонтированный сторадж (вдруг он не примонтировался) предыстория такая: есть брокер VerneMQ, который сохраняет сообщения и подписки в LevelDB. мне хочется это положить в PV, что бы не потерять при решедулинге пода. но обратил внимание, если оторвать PV, процесс VerneMQ внутри контейнера продолжает себе жить, срыгивая ошибки в лог... поэтому думаю над способом как прибить под, у которого отвалился PV, без модификации сорцов. я только начал этот тернистый путь, и думал может есть какие-то стандартные способы решения, но пока не нагуглил.

не совсем знаю, ведь если у меня точка монтирования какая-нибудь /mnt/datadir и делаю там файлик через touch healthy, я изначально не знаю, оно создаст его в фс контейнера или в примонтированный сторадж (вдруг он не примонтировался) предыстория такая: есть брокер VerneMQ, который сохраняет сообщения и подписки в LevelDB. мне хочется это положить в PV, что бы не потерять при решедулинге пода. но обратил внимание, если оторвать PV, процесс VerneMQ внутри контейнера продолжает себе жить, срыгивая ошибки в лог... поэтому думаю над способом как прибить под, у которого отвалился PV, без модификации сорцов. я только начал этот тернистый путь, и думал может есть какие-то стандартные способы решения, но пока не нагуглил.

К моменту запуска пода оно точно примонтировано. И я очень сильно сомневаюсь, что вообще возможно отмонтировать из контейнера вольюм на лету. Я пока на телефоне, но удаление PV видится мне чем то нереальным. Почти 100% уверен, что если оно реально удаляется, то под пересоздается. Пока на телефоне, но сегодня проверю

не совсем знаю, ведь если у меня точка монтирования какая-нибудь /mnt/datadir и делаю там файлик через touch healthy, я изначально не знаю, оно создаст его в фс контейнера или в примонтированный сторадж (вдруг он не примонтировался) предыстория такая: есть брокер VerneMQ, который сохраняет сообщения и подписки в LevelDB. мне хочется это положить в PV, что бы не потерять при решедулинге пода. но обратил внимание, если оторвать PV, процесс VerneMQ внутри контейнера продолжает себе жить, срыгивая ошибки в лог... поэтому думаю над способом как прибить под, у которого отвалился PV, без модификации сорцов. я только начал этот тернистый путь, и думал может есть какие-то стандартные способы решения, но пока не нагуглил.

Если PV удаляется, под не пересоздается и контейнер продолжает жить, то это мега бага

К моменту запуска пода оно точно примонтировано. И я очень сильно сомневаюсь, что вообще возможно отмонтировать из контейнера вольюм на лету. Я пока на телефоне, но удаление PV видится мне чем то нереальным. Почти 100% уверен, что если оно реально удаляется, то под пересоздается. Пока на телефоне, но сегодня проверю

Вы правы, на момент запуска оно точно будет примонтировано, иначе PVC будет ждать появления подходящего PV. Я тоже очень хочу это все попробовать на живом кубе, но пока балуюсь локально с minikube и там заметил такое странное поведение. Вечером однозначно проведу эксперимент еще раз и поделюсь результатами. Интересует два сценария: 1. удаление PV который используется подом 2. удаление физического стораджа, на который смотрит PV (не средствами kubectl)

Вы правы, на момент запуска оно точно будет примонтировано, иначе PVC будет ждать появления подходящего PV. Я тоже очень хочу это все попробовать на живом кубе, но пока балуюсь локально с minikube и там заметил такое странное поведение. Вечером однозначно проведу эксперимент еще раз и поделюсь результатами. Интересует два сценария: 1. удаление PV который используется подом 2. удаление физического стораджа, на который смотрит PV (не средствами kubectl)

Ну с 2. тут просто: в клаудах "физический" сторадж не дадут удалить. В датацентре скажем в iSCSI под перестанет писать/читать в вольюм

оффтоп: ммм, а не напомните как решается проблема с "Permission denied" при монтировании volume в контейнер так как разные uid у юзеров? я как-то раньше решал а сейчас не могу вспомнить, нужна какая-нибудь отправная точка :)

не совсем знаю, ведь если у меня точка монтирования какая-нибудь /mnt/datadir и делаю там файлик через touch healthy, я изначально не знаю, оно создаст его в фс контейнера или в примонтированный сторадж (вдруг он не примонтировался) предыстория такая: есть брокер VerneMQ, который сохраняет сообщения и подписки в LevelDB. мне хочется это положить в PV, что бы не потерять при решедулинге пода. но обратил внимание, если оторвать PV, процесс VerneMQ внутри контейнера продолжает себе жить, срыгивая ошибки в лог... поэтому думаю над способом как прибить под, у которого отвалился PV, без модификации сорцов. я только начал этот тернистый путь, и думал может есть какие-то стандартные способы решения, но пока не нагуглил.

а нельзя этот vernemq запатчить?

оффтоп: ммм, а не напомните как решается проблема с "Permission denied" при монтировании volume в контейнер так как разные uid у юзеров? я как-то раньше решал а сейчас не могу вспомнить, нужна какая-нибудь отправная точка :)

fSGroup на вольюм

оффтоп: ммм, а не напомните как решается проблема с "Permission denied" при монтировании volume в контейнер так как разные uid у юзеров? я как-то раньше решал а сейчас не могу вспомнить, нужна какая-нибудь отправная точка :)

каких юзеров?

спасиб

а нельзя этот vernemq запатчить?

можно конечно, но думалось отделаться малой кровью :)

ну это знаешь "малой кровью" ака "костыли и подпорки" vs "правильное решение"

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

очень старнный вывод

я, кстати, покопался в исходниках

https://github.com/kubernetes/minikube/blob/5661ba0b5e2402e45a8cb766495cd34411139ca6/pkg/localkube/proxy.go

теперь понятно, откуда берется адрес 0 в записи лога о попытке пингануть /healthz

ребята а расскажите как expose порт если это не cloud

я немного запутался

service type: nodePort

или hostnetwork в pod

service externalIP

и еще наверное варианты есть

service type: nodePort

а node port что означает ?

ну ты чего, опять ленишься загуглить kubernetes service type: nodeport?

ну ты чего, опять ленишься загуглить kubernetes service type: nodeport?

((( а вот что делать если кластер в google cloud и у него его кластер IP это private IP. Может ты знаешь как без использования loadBalancer достучаться до приложения ?