@kubernetes_ru

Страница 529 из 958
Sergey
20.04.2018
16:14:20
для подов - можно.

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

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

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

Google
bebebe
20.04.2018
16:16:43
deployment

Sergey
20.04.2018
16:17:17
например да.

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

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

Sergey
20.04.2018
16:19:33
речь о тестовом стенде.

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

Sergey
20.04.2018
16:20:41
kubectl rollout status
о, это уже неплохо.

bebebe
20.04.2018
16:20:57
вот кстати да

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

Sergey
20.04.2018
16:21:23
$ kubectl rollout status deployment/nginx deployment "nginx" successfully rolled out

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

верно?

Google
zigmund
20.04.2018
16:21:54
да

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

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

zigmund
20.04.2018
16:22:49
ояебу)

Let Eat
20.04.2018
16:23:33
а для деплойментов (если он накатился инкрементально и там поехал процесс) - уже нельзя. нельзя быть уверенным что Service аллоцировался и взлетел.
У них у всех есть кучерявые status из которых все это вытягивается. Можете в коде helm tiller посмотреть примеры

Let Eat
20.04.2018
16:24:42
У деплоймента есть даже статус "давно не было прогресса, апдейт забуксовал"

Sergey
20.04.2018
16:24:59
спасибо, да, направление копания есть.

bebebe
20.04.2018
16:26:30
@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) }

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

Sergey
20.04.2018
16:26:37
НЕТ

bebebe
20.04.2018
16:26:39
но тоже так делать не советую

Alex Milushev
20.04.2018
16:27:08
так Я скину все, что надо

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

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

Sergey
20.04.2018
16:27:27
раньше такой хуйни не было
они тупо заблокированы роскомнадзором.

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

Alex Milushev
20.04.2018
16:27:38
Я на aws разворачиваю

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

Google
Dmytro
20.04.2018
17:01:55
оттуда доступ быть должен
А что в логах? К ECR доступ через instance role делают обычно - может не настроено?

Alex Milushev
20.04.2018
18:17:01
Уже разобрались

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

Dmytro
20.04.2018
18:18:02
Сурово там у вас

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

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

Dmytro
20.04.2018
18:24:40
А что такое localhost в условиях overlay network между подами?

Alex Milushev
20.04.2018
18:25:52
это статик под, мне надо, что-бы определенный его порт слушал на 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

Dmytro
20.04.2018
18:27:26
Если host network то просто самому приложению нужно слушать на локалхосте

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

Alex Milushev
20.04.2018
18:28:47
то есть как в докере не получится :(

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

Valentin
20.04.2018
19:11:48
кто-нибудь minio устанавливал в кубике? Что-то не заводится...

Paul
20.04.2018
19:12:46
кто-нибудь minio устанавливал в кубике? Что-то не заводится...
а говорит что? а то это вопрос на уровне "у меня что-то сломалось"

Valentin
20.04.2018
19:13:07
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

Paul
20.04.2018
19:13:53
а что в логах?

кроме этого?

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

Valentin
20.04.2018
19:15:02
да больше и нет ничего

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

Paul
20.04.2018
19:15:40
можно взять пример с питонистов

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

Fike
20.04.2018
19:18:04
Konstantin
20.04.2018
21:26:52
Кто-нибудь пробовал на hyper-v на винде через vagrant поднять несколько виртуалок?
kubespray через вагрант, вагрантфайл чуть только подправить пришлось

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

Konstantin
20.04.2018
21:34:42
Semen
20.04.2018
21:37:46
А есть статьи про ip, я ещё не дошёл до самого кубика ) Или там легко гуглится?

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

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

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

Stanislav
21.04.2018
08:00:13
Устаревший урл

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

Dmitrii <freehck>
21.04.2018
08:02:51
И только по локалхосту можно заходит
Но я же запустил kubectl proxy —address=0.0.0.0 — разве это не должно было позволить мне заходить не только с локалхоста?

Konstantin
21.04.2018
08:05:55
Dmitrii <freehck>
21.04.2018
08:06:32
Это ты забиндил на все интерфейсы, а ещё авторизация нужна
Окей, а кто её производит, когда я curl-ом внутри виртуалки localhost:8001/ui делаю?

Google
Dmitrii <freehck>
21.04.2018
08:07:23
Для локалхост не нужна)
А как бы мне настроить её для того, чтобы с хост-системы достучаться до dashboard?

Stanislav
21.04.2018
08:07:24
Не

Konstantin
21.04.2018
08:07:37
В 2х словах не скажу, в вики дашборда есть всё

Stanislav
21.04.2018
08:07:46
Пробрось порт через ссш к примеру

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

Dmitrii <freehck>
21.04.2018
08:13:46
Пробрось порт через ссш к примеру
Хм. Спасибо, конечно, но вообще говоря это неправильно. Надо на самом деле авторизацию настроить, чтобы абы кто не заходил.

Stanislav
21.04.2018
08:14:15
Без токена никто ничо сделать не может

Dmitrii <freehck>
21.04.2018
08:14:53
Угу. А чтобы сделать токен — надо туннель, как я вижу.

Stanislav
21.04.2018
08:16:55
Нет

Надо консоль

Dmitrii <freehck>
21.04.2018
08:18:33
Надо консоль
https://github.com/kubernetes/dashboard/wiki/Access-control Оно?

Stanislav
21.04.2018
08:19:33
Внизу дашборд админа делаешь и его токен ющаешь

Dmitrii <freehck>
21.04.2018
08:21:26
Внизу дашборд админа делаешь и его токен ющаешь
В том-то и суть, что я в дашборд попасть не могу.

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

Stanislav
21.04.2018
08:30:08
Говорюж через консоль

Страница 529 из 958