@sha256:abcdef по которому можно образы качать это digest или image id?

в любом случае я бы хотел избежать docker push чтобы вытаскивать digest

вытащу кусок из docker cli, который шлёт контекст =)

Приветствую. Никак не могу разобраться с процессом пересоздания CA и сертификатов компонентов Kubernetes (ETCD внешний). Есть ли какойто корректный порядок действий, которые необходимо произвести, чтоб обновить сертификаты и получить рабочий кластер после их обновления? Сейчас я делаю следующее 1) Удаляю старые сертификаты 2) Генерирую новые 3) Загружаю новые сертификаты на все ноды кластера 4) Рестарт dockerd и kubelet мастеров 5) Рестарт dockerd и kubelet воркеров Вроде все логично. Но желаемого результата нет. Даже в рамках одной ноды в логах apiserver куча unauthorized от scheduler, controller.

@vrutkovs идея делать sha1 на основе файлов без .dockerignore плоха? Или можно пробовать?

Приветствую. Никак не могу разобраться с процессом пересоздания CA и сертификатов компонентов Kubernetes (ETCD внешний). Есть ли какойто корректный порядок действий, которые необходимо произвести, чтоб обновить сертификаты и получить рабочий кластер после их обновления? Сейчас я делаю следующее 1) Удаляю старые сертификаты 2) Генерирую новые 3) Загружаю новые сертификаты на все ноды кластера 4) Рестарт dockerd и kubelet мастеров 5) Рестарт dockerd и kubelet воркеров Вроде все логично. Но желаемого результата нет. Даже в рамках одной ноды в логах apiserver куча unauthorized от scheduler, controller.

@vrutkovs идея делать sha1 на основе файлов без .dockerignore плоха? Или можно пробовать?

Приветствую. Никак не могу разобраться с процессом пересоздания CA и сертификатов компонентов Kubernetes (ETCD внешний). Есть ли какойто корректный порядок действий, которые необходимо произвести, чтоб обновить сертификаты и получить рабочий кластер после их обновления? Сейчас я делаю следующее 1) Удаляю старые сертификаты 2) Генерирую новые 3) Загружаю новые сертификаты на все ноды кластера 4) Рестарт dockerd и kubelet мастеров 5) Рестарт dockerd и kubelet воркеров Вроде все логично. Но желаемого результата нет. Даже в рамках одной ноды в логах apiserver куча unauthorized от scheduler, controller.

У тебя и так куча sha, зачем тебе еще один?

я не хочу тратить время ci/cd на пуш, чтобы узнать digest. docker build аналогично думаю можно скипать по кастомному sha

я не хочу тратить время ci/cd на пуш, чтобы узнать digest. docker build аналогично думаю можно скипать по кастомному sha

CA сертификаты надо плавно менять. Выпустить новый CA, раскидать старый и новый CA всюду и только потом можно менять сертификаты подписанные старым СА на новые

Только затегай имадж всеми его тегами - тэги меняют манифест

А можете подробнее уточнить что Вы имеете ввиду под плавным изменением?)

Процесс, который описал в остальной части сообщения :)

NodePort куб прокси слушает просто на всякий случай, чтобы на него никто не повесился. Пакеты на NodePort обрабатываются в iptables через DNAT и до порта который вы видите в netstat не долетают

Только затегай имадж всеми его тегами - тэги меняют манифест

я все делаю через Ansible. То есть мне лучше загрузить новые сертификаты и производить рестарты dockerd и kubelet по одному хосту (serial: 1)?

Вы перевыпускаете СА или нет? Если нет, то мой комент не актуален

я все делаю через Ansible. То есть мне лучше загрузить новые сертификаты и производить рестарты dockerd и kubelet по одному хосту (serial: 1)?

Вы перевыпускаете СА или нет? Если нет, то мой комент не актуален

просто мне не совсем понятно чем процесс описанный мной не подходит под определение "плавно" 😀

ещё кейс, если свой sha будет считаться в 2+ раз быстрее, есть смысл делать так. Чтобы скипать docker build

Ваш процесс тоже плавный, но вы хотите заменить все сертификаты за один проход (плавно по 1 ноде за раз), но такой процесс обрывает цепочку доверия : обновленные ноды не доверяют ещё необновленным и наоборот итого кластер разваливается , т.е. не очень то плавно всё проходит :)

Приветствую. Есть кластер куба, раскаченный кубспреем v2.6.0 месяца 2 назад, сейчас пробую обновить версией 2.7.0 и идёт ругань на устаревший калико. Ошибка такая: Your version of calico is not fresh enough for upgrade. Minimum version v2.6.5 . Сейчас раскачен калико 1.6.3. Как можно проапгрейдить калико? Или проще забить и раскатать кластер заново, он эксперементальный и ничего важного пока в нём не живёт

попробую по одной. спасибо 👍🏼 выше так же писали про токены. Я понял что их тоже необходимо пересоздать. Помимо этого так же потребуется пересоздать поды, использующие эти токены? Например weave

2.6.5 - это transitional release, надо сначала обновиться на него

"По одной" это про другое. Я вам пытаюсь объяснить, что за 1 проход по всем нодам вы не сможете обновить СА сертификаты. Надо делать два полных прохода: сначала только добавить новый СА и ничего другого не менять, потом ещё раз пройтись по всем нодам и уже разложить сертификаты выпущенные новым СА.

попробую по одной. спасибо 👍🏼 выше так же писали про токены. Я понял что их тоже необходимо пересоздать. Помимо этого так же потребуется пересоздать поды, использующие эти токены? Например weave

"сначала только добавить новый CA" - вы имеете ввиду добавление его в доверенные на нодах? Или перезапуск сервисов с новым CA? Кончено извиняюсь за тупые вопросы))

Я предлагаю забить. Выпустите СА и все сертификаты подписанные им на 20 лет. Ротация секретов процесс сложный, неблагодарный , чуть что идёт не так все нахуй разваливается и ваша жопа в огне, а если после тщательной подготовки и десятков/сотен человеко-часов проб и ошибок все прошло гладко, никто даже не узнает, что вы что-то делали. все для чего это нужно это дурацкая галочка (одна из сотен/тысяч) в каком-нибудь аудите. Есть более интересные занятия, с гораздо лучшими показателями плюшек на единицу ебли

ок, я потестирую как дойдут руки, нужно открытый proof of concept сделать.

https://github.com/Azure/brigade

оно вроде poor man's operator

Как после заведения сервисмонитора пром подхватит новый таргет?

там ещё label нужен корретный

все, prometheus должен появиться. Там не рандомные метки...уже не помню точно.

label у монитора для прометеуса

$ kubectl get ServiceMonitor kube-prometheus-exporter-node -n monitoring -o yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: creationTimestamp: 2018-10-30T14:31:31Z generation: 1 labels: app: exporter-node chart: exporter-node-0.4.6 component: node-exporter heritage: Tiller prometheus: kube-prometheus release: kube-prometheus name: kube-prometheus-exporter-node namespace: monitoring resourceVersion: "1138405" selfLink: /apis/monitoring.coreos.com/v1/namespaces/monitoring/servicemonitors/kube-prometheus-exporter-node uid: 7ed29624-dc50-11e8-8684-0050562b002b spec: endpoints: - interval: 15s port: metrics jobLabel: component namespaceSelector: matchNames: - monitoring selector: matchLabels: app: exporter-node component: node-exporter

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

А часом вот эта хрень https://docs.projectcalico.org/v3.3/reference/kube-controllers/configuration не умеет?

кто подскажет, может statefulset смотреть на pvc из другого namespace?

кто подскажет, может statefulset смотреть на pvc из другого namespace?