для подов - можно.

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

ну или если можно - то расскажите как. об этом собственно и вопрос.

другими словами, вопрос состоит в том, как определить что deployment ready, если его обновили инкрементально?

deployment

например да.

возможно проблема не технического плана. я знаю что большие дяди для такого рода задач на Ынтырпрайзе делают cannary upgrade и через метрики сервисов понимают что деплоймент/апгрейд деплоймента прошел успешо.

но это вряд ли стоит делать в вашем случае.

речь о тестовом стенде.

то есть костыльное решение - это sleep 60, обычно за это время всё успевает взлететь.

другими словами, вопрос состоит в том, как определить что deployment ready, если его обновили инкрементально?

kubectl rollout status

kubectl rollout status

о, это уже неплохо.

вот кстати да

Дождется окончания деплоя и ответит ок, если все хелсчеки работают

$ kubectl rollout status deployment/nginx deployment "nginx" successfully rolled out

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

верно?

да

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

(пока я не залез в гугл, может вы еще знаете как это в API реализовано с ходу?)

ояебу)

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

У них у всех есть кучерявые status из которых все это вытягивается. Можете в коде helm tiller посмотреть примеры

У них у всех есть кучерявые status из которых все это вытягивается. Можете в коде helm tiller посмотреть примеры

вот они кучерявые!

У деплоймента есть даже статус "давно не было прогресса, апдейт забуксовал"

спасибо, да, направление копания есть.

@spuzirev если хочется сделать методом восточно европейского инженера. 1. Загони все логи подов в syslog https://www.ibm.com/blogs/bluemix/2017/11/kubernetes-log-forwarding-syslog/ 2. при помощи rsyslog скидывай все логи в awk module(load="omprog") action(type="omprog" binary="/usr/bin/awk -f /usr/local/bin/parser.awk" template="RSYSLOG_TraditionalFileFormat")3. awk такой: /java:.* Service is ready for business process/ { system(curl) }

итого, разворачиваю стенд на aws, и docker нихера не может спуллить ни с quay.io ни с ecr, куда копать?

НЕТ

но тоже так делать не советую

итого, разворачиваю стенд на aws, и docker нихера не может спуллить ни с quay.io ни с ecr, куда копать?

пулково, домодедово, шереметьево...

так Я скину все, что надо

Я хз, куда смотреть

раньше такой хуйни не было

раньше такой хуйни не было

они тупо заблокированы роскомнадзором.

и quay и ECR работают.

Я на aws разворачиваю

оттуда доступ быть должен

(пока я не залез в гугл, может вы еще знаете как это в API реализовано с ходу?)

Там есть что типа wait/watch в апи

оттуда доступ быть должен

А что в логах? К ECR доступ через instance role делают обычно - может не настроено?

Уже разобрались

Инфраструктурщики намудрили что-то

Сурово там у вас

Вопрос другой, можно что то вроде докеровского --port 127.0.0.1:4001:4001 сделать для static pod?

Забиндить на все адреса не проблема, но надо только на localhost :(

А что такое localhost в условиях overlay network между подами?

это статик под, мне надо, что-бы определенный его порт слушал на localhost хостовой машинки

--- apiVersion: v1 kind: Pod metadata: name: kube-etcd namespace: kube-system spec: hostNetwork: true containers: - name: kube-etcd image: quay.io/coreos/etcd:{{ k8s_etcd_tag }} command: - /usr/local/bin/etcd - --discovery-srv={{ k8s_dns_zone_name }} - --listen-peer-urls=https://0.0.0.0:2380 - --listen-client-urls=https://0.0.0.0:2379,http://0.0.0.0:4001 - --initial-cluster-token=etcd-cluster-{{ k8s_cluster_name }} - --name={{ k8s_etcd_private[ansible_default_ipv4.address] }} - --advertise-client-urls=https://{{ k8s_etcd_private[ansible_default_ipv4.address] }}:2379 - --initial-advertise-peer-urls=https://{{ k8s_etcd_private[ansible_default_ipv4.address] }}:2380 - --cert-file=/etc/etcd/etcd.pem - --key-file=/etc/etcd/etcd-key.pem - --peer-cert-file=/etc/etcd/etcd.pem - --peer-key-file=/etc/etcd/etcd-key.pem - --peer-trusted-ca-file=/etc/etcd/ca.pem - --data-dir=/var/lib/etcd livenessProbe: httpGet: host: 127.0.0.1 port: 4001 path: /health initialDelaySeconds: 15 timeoutSeconds: 15 ports: - containerPort: 2380 hostPort: 2380 name: peer - containerPort: 2379 hostPort: 2379 name: client - containerPort: 4001 hostPort: 4001 hostIP: 127.0.0.1 name: local volumeMounts: - mountPath: /etc/etcd name: etc-etcd readOnly: true - mountPath: /var/lib/etcd name: etcd-work-dir readOnly: false - mountPath: /etc/ssl/certs name: etc-ssl-certs readOnly: true - mountPath: /usr/share/ca-certificates name: usr-share-certs readOnly: true - mountPath: /etc/machine-id name: machine-id readOnly: true volumes: - hostPath: path: /etc/etcd name: etc-etcd - hostPath: path: /var/lib/etcd name: etcd-work-dir - hostPath: path: /etc/ssl/certs name: etc-ssl-certs - hostPath: path: /usr/share/ca-certificates name: usr-share-certs - hostPath: path: /etc/machine-id name: machine-id

Если host network то просто самому приложению нужно слушать на локалхосте

А порт контейнера на хосте должен торчать уже за счёт хост нетворк, насколько я помню

то есть как в докере не получится :(

разобрался, все ок, спасибо большое

кто-нибудь minio устанавливал в кубике? Что-то не заводится...

кто-нибудь minio устанавливал в кубике? Что-то не заводится...

а говорит что? а то это вопрос на уровне "у меня что-то сломалось"

Unable to initialize new config from the provided credentials. Get http://minio-service:9000/probe-bucket-sign/?location= connection refused

сетапил как здесь: https://www.minio.io/kubernetes.html

а что в логах?

кроме этого?

Может, заведем pinned message с коротким объяснением, как выглядит вопрос, имеющий максимум шансов на быстрый ответ?

да больше и нет ничего

Может, заведем pinned message с коротким объяснением, как выглядит вопрос, имеющий максимум шансов на быстрый ответ?

а какой смысл сразу развёрнутый вопрос задавать, если с предметом возможно никто не сталкивался?

Может, заведем pinned message с коротким объяснением, как выглядит вопрос, имеющий максимум шансов на быстрый ответ?

имеет смысл думаю. Админы, вам флаг в руки

можно взять пример с питонистов

так, кажется, проблема не в самом minio. Есть такой образ minio/mc, вот с ним проблема. С minio/minio всё ок

а какой смысл сразу развёрнутый вопрос задавать, если с предметом возможно никто не сталкивался?

это обычно как раз выясняется в последующих уточнениях

и что такое split brain в кластере и ты поймешь почему должно быть не четное кол-во

и еще про кворум полезно.

Кто-нибудь пробовал на hyper-v на винде через vagrant поднять несколько виртуалок?

kubespray через вагрант, вагрантфайл чуть только подправить пришлось

Круто) Я сегодня только статью нашёл, которая мои проблемы объясняет https://blog.wizardsoftheweb.pro/sensible-ssh-with-ansible-vagrant-setup/#theseriessofar

Круто) Я сегодня только статью нашёл, которая мои проблемы объясняет https://blog.wizardsoftheweb.pro/sensible-ssh-with-ansible-vagrant-setup/#theseriessofar

ага, что-то такое, только ещё сверху c IP повозиться надо, hyperv не умеет сам(

А есть статьи про ip, я ещё не дошёл до самого кубика ) Или там легко гуглится?

кто использует grpc с кубером? какие особенности проксирования со стандартным ingress на nginx?

вот это по-факту работает? https://github.com/kubernetes/ingress-nginx/blob/4bc943a77daf3840fe9473ef24f3403718bc5551/Changelog.md#0130

Всем привет. Я наконец-то поставил кубер и сейчас иду по туториалам, как оным пользоваться. Создал Vagrant-файл, развернул виртуалку через virtualbox-provider, хочу в кубере настроить dashboard. Запустил под с dashboard, запустил kubectl proxy —address=0.0.0.0, наблюдаю следующую картину: - если curl-ом дёрнуть localhost:8001/ui из-под виртуалки, всё хорошо - если из браузера хост-системы дёрнуть <vm-ip>:8001/ui — отвечает Unauthorized Подскажите пожалуйста, в какую сторону смотреть.

Устаревший урл

И только по локалхосту можно заходит

И только по локалхосту можно заходит

Но я же запустил kubectl proxy —address=0.0.0.0 — разве это не должно было позволить мне заходить не только с локалхоста?

Но я же запустил kubectl proxy —address=0.0.0.0 — разве это не должно было позволить мне заходить не только с локалхоста?

Это ты забиндил на все интерфейсы, а ещё авторизация нужна

Это ты забиндил на все интерфейсы, а ещё авторизация нужна

Окей, а кто её производит, когда я curl-ом внутри виртуалки localhost:8001/ui делаю?

Окей, а кто её производит, когда я curl-ом внутри виртуалки localhost:8001/ui делаю?

Для локалхост не нужна)

Для локалхост не нужна)

А как бы мне настроить её для того, чтобы с хост-системы достучаться до dashboard?

Не

В 2х словах не скажу, в вики дашборда есть всё

Пробрось порт через ссш к примеру

Или через нат бокса

А как бы мне настроить её для того, чтобы с хост-системы достучаться до dashboard?

ssh -N root@172.16.0.39 -L 9000:127.0.0.1:9000

Пробрось порт через ссш к примеру

Хм. Спасибо, конечно, но вообще говоря это неправильно. Надо на самом деле авторизацию настроить, чтобы абы кто не заходил.

Без токена никто ничо сделать не может

Угу. А чтобы сделать токен — надо туннель, как я вижу.

Нет

Надо консоль

Надо консоль

https://github.com/kubernetes/dashboard/wiki/Access-control Оно?

Внизу дашборд админа делаешь и его токен ющаешь

Внизу дашборд админа делаешь и его токен ющаешь

В том-то и суть, что я в дашборд попасть не могу.

Ладно. Сейчас что-нибудь придумаю. Несколько путей по крайней мере уже видно.

Говорюж через консоль