kubectl get pod | grep nginx | grep ingress kubectl logs $nginx-ingress-pod | grep $hostname

Хм. А по имени workload’а нельзя?

с термином workload я не знаком) логи можно получить только от пода, не от деплоймента

подскажите способ(ы) подсоединять внешний сервер, находящийся в одной приватной сети с кластером, ко внутренним сервисам в cluster.local. На данный момент мне предлагается: а) пробросить маршрут через: ip route add 10.96.0.0/12 via <IP адрес ноды кластера> б) добавить в /etc/resolv.conf: nameserver 10.96.0.10 Это работает, но мне не нравится такой костылизм.

подскажите способ(ы) подсоединять внешний сервер, находящийся в одной приватной сети с кластером, ко внутренним сервисам в cluster.local. На данный момент мне предлагается: а) пробросить маршрут через: ip route add 10.96.0.0/12 via <IP адрес ноды кластера> б) добавить в /etc/resolv.conf: nameserver 10.96.0.10 Это работает, но мне не нравится такой костылизм.

есть два приложения, одно в кубе, другое нет. Мне их надо связать так, чтоб приложение, которое не в кубе, сразу обращалось по svc.namespace.cluster.local. Вроде же расписал выше.

hi guys у вас можно запостить предложение о контракте👍 ?

hi guys у вас можно запостить предложение о контракте👍 ?

Ceph поднимал на виртуалках. Сейчас буду пробовать в докере запускать

всем привет, а по Helm тоже сюда можно вопросы задавать?

да? опять потерянное время? ставил эту версию, не пошла ceph-deploy install --release mimic

Хм.. rook.io возможно спасёт вас)

а чем лучше minio.io, отзыв не дадите?

Rook оркестратор для кластера)

надо работать с сервисами внутри кластера и общаться с сервисом через svc.namespace.cluster.local

а чем лучше minio.io, отзыв не дадите?

https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99 посмотри во тут, может подойдет

Minio конкурент ceph’a

спс, посмотрю

https://hackernoon.com/locally-developing-kubernetes-services-without-waiting-for-a-deploy-f63995de7b99 посмотри во тут, может подойдет

Хорошая штука, telepresence - запускать часть кластера .. на локальной машине разработчика ))) бомбично)

а лол, рук для кубера я себе для петпроджектов ищу сторэдж обьектный шобы под композ поставить

вопрос такой: пробую сварить коктейль из kafka в kubernetes (локально в minikube) через Helm согласно этой инструкции https://github.com/kubernetes/charts/tree/master/incubator/kafka Версия без external access работает вполне успешно Но как только меняю в values.yaml в разделе exposed на enabled: true и стартую (в новом неймспейсе этот chart) то начинается веселье. под с кафкой уходит в Init:CrashLoopBackOff Понимаю что кейс довольно специфический, но вдруг кто-то сталкивался

вопрос такой: пробую сварить коктейль из kafka в kubernetes (локально в minikube) через Helm согласно этой инструкции https://github.com/kubernetes/charts/tree/master/incubator/kafka Версия без external access работает вполне успешно Но как только меняю в values.yaml в разделе exposed на enabled: true и стартую (в новом неймспейсе этот chart) то начинается веселье. под с кафкой уходит в Init:CrashLoopBackOff Понимаю что кейс довольно специфический, но вдруг кто-то сталкивался

1) The external access feature of this chart was tested with kops on AWS using flannel networking. 2) If you wish to enable external access to Kafka running in kops, your security groups will likely need to be adjusted to allow non-Kubernetes nodes (e.g. bastion) to access the Kafka external listener port range. Я так понимаю у вас не авс? А секгрупу сделали в кубере?

да совершенно верно. не AWS - сначала хотел оттестить все на локалхосте с миникубом (а потом уже на Google Cloud, AWS нет у нас). секгруппу не создавал

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

У меня в кубере-через-ранчер latest не цепляется. Указываю принудительно версию

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

Вручную, пока так удобнее, но думаю над вариантами.

Адище какой. У меня пока сделано так: на dev окружение автоматом выкатывается образ dev:latest, который собирается из master ветки. Далее в нужный момент я отрезаю release/* ветку и из неё автоматом собирается release:latest, который автоматом выкатывается на staging. Далее есть ручной таск, который берёт образ release:latest, перетэгивает его на prod:latest и это вручную деплоится в prod. Таким образом prod защищён от автодеплоя release:latest :)

Всем привет. Вопрос про rollback deployment'ов: скажем у меня в deployment'е постоянно указан образ app:latest и для обновления сервиса мне нужно по сути просто спулить новый образ. Если я хочу откатиться, то откуда кубер возьмёт предыдущий образ, если он точно такой же app:latest? Или принято прямо по версиям выкатывать? Плюс в самом deployment'е стоит imagePullPolicy: Always. Насколько принято так делать и в чём минус Always тут в вышеописанном сценарии? Спасибо.

простая практика - оперется на систему контроля версий. на tag, на commit hash, что там удобнее

простая практика - оперется на систему контроля версий. на tag, на commit hash, что там удобнее

Ещё вопрос по ingess'ам: есть ли возможность выставлять наружу сервис через clusterip, а не nodeport в стандартном ingress'е на GKE? Перехожу с Rancher/Cattle и там аналогичная возможность есть, т.е. микросервисы открывают только свои порты в их локальную 10.42.0.0/16 сеть и далее ingress Rancher'а выставляет их наружу, не открывая и не занимая никаких дополнительных портов на хосте/ноде. При этом на load balancer'е cloud provider'а (AWS) указаны только 80 и 443 порты.

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

Там в GCP удобство в том, что ты через именованные порты связываешь это и куда оно там в очередной раз выставится - тебя не греет

Очевидно, но не совсем. У меня и версия контейнера создается (от номера билда) и хэш. Но в том же Rancher на Cattle после deploy, остаётся висеть убитый контейнер предыдущей версии (с тем же тэгом latest). Если есть необходимость откатиться, то вместо finish upgrade делается rollback, который убивает текущий свежий контейнер и запускает остановленный предыдущий, не перекачивая его из реестра.

это уже какие то костыли снаружи. на k8s так не выйдет откатится. может быть если probe для пода скажет что он не здоров и прежний репликасет (в случае деплоймента) еще был жив целиком. но я бы на такое не надеялся

А в чем небезопасность порта? В том, что голый сервис? Я вот нжинксом внутри кластера прикрыл и балансер на него приземлял. Это позволило избежать проблемы асинхронного лага между окончанием реконфигурации GCLB и реальным эффектом от изменений. Правлю только внутрикластерный балансер часто.