ну можно поставить imagePullPolicy: Always и удалить поды по лейблу

когда там центос?)

Кто знает какой самый простой способ разрезолвить docker image в sha256?

Подскажите плиз, если к8 кластер на виртуалках был инициализирован с 2vCPU а потом добавили ещё 2 на кпжлую ноду, то это как то отрицательно влияет на производительность?

Подскажите плиз, если к8 кластер на виртуалках был инициализирован с 2vCPU а потом добавили ещё 2 на кпжлую ноду, то это как то отрицательно влияет на производительность?

правда как показывает практика .config.digest не совпадает с тем, что показывает skopeo, а во многих манифестах его может просто не быть

а почему это должно как-то отрицатильно повлиять на производительность?

Тогда digest будет sha256 от этого жсона - должно совпасть с показаниями скопео

Не повлияет никак - кубелет только при создании ноды читает сколько ядер доступно

А как ему рассказать, что капасити выросло? Удалять объект ноды, чтобы заново создался? Дашборд по крайней мере сразу начинает видеть увеличение процессоров

неа $ skopeo inspect docker://ubuntu:bionic | jq -r .Digest sha256:d26d529daa4d8567167181d9d569f2a85da3c5ecaf539cace2c6223355d69981 $ docker manifest inspect ubuntu:bionic | sha256sum e78c32e8f317846757d99210cd056aa3d9dd4e9c83f3ee49e579effe65e4841c -

применяешь новый манифест, а он тебе все images в digest'ы переводит по умолчанию

или даже лучше по аннотации: docker-images-resolver/resolve-image: "true"

или даже отдельный CRD объект с тегами которые привязываются к диджестам и имеют ивенты, синк и так далее - ImageStream в опеншифте

а оно именно по apply стреляет?

да, меняешь тег imagestream и оно меняет диджест внутри - и триггерит новый деплоймент если нужно

Вот ядро Которое построил Линус. А это системный процесс, Который работает без умолку, В ядре, Которое построил Линус. А это суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. Вот контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. Вот под, Что часто пинает контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. А это container engine, Который тот под создает, Что часто пинает контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. А это непрестрастнный CI, Который управляет container engine, Который тот под создает, Что часто пинает контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. А это ленивый и толстый DevOps-инженер, Который нacтраивает непрестрастнный CI, Который управляет container engine, Который тот под создает, Что часто пинает контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус. Вот два алерта, Которые будят того DevOps-инженера, Который нacтраивает непрестрастнный CI, Который управляет container engine, Который тот под создает, Что часто пинает контейнер, Который генерит суровый cgroup, Который изолирует системный процесс, Который работает без умолку, В ядре, Которое построил Линус.

Удалять, да

describe node xxx показывает актуальное количество цпу или это ничего не значит?

Коллеги, подскажите: создал pv и pvc, монтирую к поду - получаю ошибку persistentvolumeclaim not found. При этом pvc с указанным именем в выводе kubectl get pvc присутствует. В чем может быть проблема?

Да, забыл указать ns при создании. Благодарю за опертивные подсказки) Теперь ошибка при монтировании mount: wrong fs type, bad option, bad superblock on %%, missing codepage or helper program, or other error.

Да, забыл указать ns при создании. Благодарю за опертивные подсказки) Теперь ошибка при монтировании mount: wrong fs type, bad option, bad superblock on %%, missing codepage or helper program, or other error.

коллеги, а кто то может подсказать как дебажить проблемы с сетью в k8s(flannel). Есть база(cql), вне куреба, в нее не долетают запросы из пода.

коллеги, а кто то может подсказать как дебажить проблемы с сетью в k8s(flannel). Есть база(cql), вне куреба, в нее не долетают запросы из пода.

так что с правилами iptables - хотя там такой ад будет, что сразу и не разберешься

предполагаю, пошел в магаз за водкой

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

нашего русского человека этими заморскими пойлами не возьмешь, могз без водки не работает, проверено 3ех палыми фрезеровщиками с завода

так что с правилами iptables - хотя там такой ад будет, что сразу и не разберешься

я работал в телекоме, меня iptables не испугать

сегодня

http://isoredirect.centos.org/centos/8/ что-то не видно

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

там под жирный, примерно так 40-100 гб памяти потребляет. Примерно 1000 r\s в cassandra шлет, но какие то теряются и из-за этого не верно выстраивается логика приклада.

беда печаль

ну как то не не очень страшно

ipvs detected

спрей(от centos-admin) так ставит ( и да его можно поменять, но в чем это хплохо?