а как надо?

ну например на стейдже у нас образы registry.address/project:build_id На проде registry.address/project:release_tag

уже на третьем проекте использую project:YY.MM.DD-b<Build number>. Мне удобно, остальным вроде тоже. Номер билда в моем случае teamcity подставляет.

Как ты связываешь имадж с коммитом в коде?

вернее как - есть билды в конкретных репах, которые поставляют докер-образы. Из них потом выкатывается деплой. Соответственно при необходимости раскручиваем в обратную сторону. Из билда-деплоя смотрим какие билды в конкретных приложениях использовались. В них уже коммит виден.

ради бога. Никого ж не призываю. У меня необходимость достать коммит возникала всего пару раз. А мельком глянув понять когда последний раз выкатывалось бывает полезно минимум раз в день.

не проще ли добавлять label с коммитом в сам имадж?

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

тэг и поменять можно, а вот лейбл перезаписать сложнее

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

наверное дело в том что kind service может быть разным, от type зависит.

ClusterIP

ок, с labelSelector?

да, конкретно kube-scheduler

да, конкретно kube-scheduler

влияет так же readiness probe. в endpoints регистрируются только те, кто успешно проходит probes

livenessProbe: failureThreshold: 8 httpGet: host: 127.0.0.1 path: /healthz port: 10251 scheme: HTTP

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

{ "baseType": "storageClass", "created": "2019-01-09T09:13:20Z", "createdTS": 1547025200000, "creatorId": null, "id": "fast", "links": { "persistentVolumes": "…/v3/cluster/c-rzmww/persistentVolumes?storageClassId=fast", "remove": "…/v3/cluster/c-rzmww/storageClasses/fast", "self": "…/v3/cluster/c-rzmww/storageClasses/fast", "update": "…/v3/cluster/c-rzmww/storageClasses/fast" }, "name": "fast", "parameters": { "adminId": "admin", "adminSecretName": "ceph-secret", "adminSecretNamespace": "kube-system", "fsType": "xfs", "imageFeatures": "layering", "imageFormat": "2", "monitors": "10.xxx:6789,10.yyy:6789,10.zzz:6789,10.aaa:6789", "pool": "kube", "userId": "kube", "userSecretName": "ceph-secret-user", "userSecretNamespace": "default" }, "provisioner": "kubernetes.io/rbd", "reclaimPolicy": "Delete", "type": "storageClass", "uuid": "ce95d032-13ee-11e9-a868-6a51f11f5cd8", "volumeBindingMode": "Immediate" }

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

allowVolumeExpansion: true

Ребята, привет. Поделитесь пожалуйста, кто как в k8s доставляет статику? Например, разрабатываете виджет какой-нибудь, и его надо доставить?

можно через nginx, там вроде особой надстройки не нужно, положил в /usr/share/nginx/html и дефолтный конфиг уже сам подхватит Да и nginx гибкий сам по себе, если нужно будет чет сверху фигачить

можно через nginx, там вроде особой надстройки не нужно, положил в /usr/share/nginx/html и дефолтный конфиг уже сам подхватит Да и nginx гибкий сам по себе, если нужно будет чет сверху фигачить

Сейчас примерно так и делаем. Стало интересно, как у других - может есть какие-то best practice.

клади в цдн

Сам такой, слыш

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

У нас свой релиз и чарт для каждого компонента (сервиса).

ИНтересен опыт использования JenkinsX в связке с DigitalOcean, может кто поделится? Конкретнее с их kubernetes cluster

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

камрады - есть прометей в namespace == monitoring есть експортер в другом неймспейсе, но на том же кластере. и похоже прометей не видит его. /prometheus $ ping celery-prometheus-exporter-service ping: bad address 'celery-prometheus-exporter-service' хотя другой прометей, в том же неймспейсе, что и екппортер - все ок резолвит: λ kubectl -n sandbox exec -it prometheus-54489c4474-qdxsc /bin/sh /prometheus $ ping celery-prometheus-exporter-service PING celery-prometheus-exporter-service (10.155.34.79): 56 data bytes ping: permission denied (are you root?)

explain()

магия спасибо)

сорри немного не дошло

тут странность нарисовалась. поставил для сбора логов fluentd вот отсюда https://github.com/fluent/fluent-bit-kubernetes-logging чет криво работает. Решил зайти в контейнер и посмотреть, что там и как, а там нет на bash ни sh и толком нифига как такое дебажить?