Большое спасибо за уточнение, это ценный комментарий - корректировки в статью внесены, чтобы не вводить в заблуждение возможных будущих читателей.
У меня были смутные воспоминания насчёт наличия механизма гарантированного обеспечения процессорного времени, заданного в requests. Но увы, при подготовке статьи проверка по источникам оказалась недостаточной - предложенного материала обнаружено не было. Здорово, что благодаря этому дополнению удалось исправить ошибку хотя бы сейчас.
В CRI-O, видимо, озадачились проблемой https://github.com/cri-o/cri-o/pull/9060 проверки образа непосредственно перед созданием контейнера. С учётом механики подписи образов, возможно, это первое полноценное решение.
Насколько я понимаю, тут есть тонкий момент: с точки зрения Kubelet, любое изменение хэша должно приводить к загрузке "правильного"/нового образа с registry при старте/рестарте пода. Т.е. в момент, когда собственно и производиться проверка хэша образа. Например, см. здесь ссылки на код Kuberentes https://github.com/kubernetes/kubernetes/issues/116867#issuecomment-2091119480
The container runtime will reconcile the image digest to ensure the most up-to-date image is used By “always” downloading and reconciling the image manifest against the local cache, Kubernetes guarantees it always has the latest version of the image
обеспечивать реконсиляцию хэша должен container runtime. Которым для большинства новых инсталляция является containerd, точнее говоря cri.
К сожалению, мне не удалось найти, обладает ли containerd механизмом для принудительного пересчёта хэша образа. Вероятно, что нет, если полагать, что хэш образа в нормальных условиях рассчитывается только в процессе сборки образа. А containerd встроенными средства сборки не обладает.
Спасибо за ваш труд, коллеги!
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
Идеальной для вендора была бы ситуация, когда разброс моделей устройств на руках у пользователей минимален, а производители Bluetooth чипов взаимодействуют с разработчиками решения. Насколько я понимаю, именно такая ситуация складывается с продукцией Apple и именно поэтому базой для решения был выбран iBeacon, а не Eddystone.
К сожалению, остаётся не ясным, какая именно математика работает внутри данного решения. Из общения с вендором и инженерами в community Aruba известно лишь, что ПО сканирует эфир и последовательно определяет три маячка с самыми мощными сигналами, после чего работает только с ними. Как именно происходит вычисление координат точек знают только программисты Meridian. При этом задержка при позиционировании составляет около двух секунд.
К слову, вышеописанная последовательная выборка начинает сильно усложнять планирование расположения маячков, если помещение является многоуровневым (например, ТЦ с галереями над атриумом). Вполне возможна ситуация, когда на галерее второго этажа устройство принимает сигналы с двух маячков галереи и одного-атриума, что может приводить к «телепортации» вычисленной позиции между этажами.
Большое спасибо за уточнение, это ценный комментарий - корректировки в статью внесены, чтобы не вводить в заблуждение возможных будущих читателей.
У меня были смутные воспоминания насчёт наличия механизма гарантированного обеспечения процессорного времени, заданного в requests. Но увы, при подготовке статьи проверка по источникам оказалась недостаточной - предложенного материала обнаружено не было. Здорово, что благодаря этому дополнению удалось исправить ошибку хотя бы сейчас.
В CRI-O, видимо, озадачились проблемой https://github.com/cri-o/cri-o/pull/9060 проверки образа непосредственно перед созданием контейнера.
С учётом механики подписи образов, возможно, это первое полноценное решение.
Насколько я понимаю, тут есть тонкий момент: с точки зрения Kubelet, любое изменение хэша должно приводить к загрузке "правильного"/нового образа с registry при старте/рестарте пода. Т.е. в момент, когда собственно и производиться проверка хэша образа.
Например, см. здесь ссылки на код Kuberentes https://github.com/kubernetes/kubernetes/issues/116867#issuecomment-2091119480
При этом, как справедливо отмечено здесь https://rx-m.com/kubernetes-image-pull-policy/ и, отчасти, в https://github.com/kubernetes/kubernetes/issues/116867
обеспечивать реконсиляцию хэша должен container runtime. Которым для большинства новых инсталляция является containerd, точнее говоря cri.
К сожалению, мне не удалось найти, обладает ли containerd механизмом для принудительного пересчёта хэша образа. Вероятно, что нет, если полагать, что хэш образа в нормальных условиях рассчитывается только в процессе сборки образа. А containerd встроенными средства сборки не обладает.
Возможно, для гаратированной защиты от подмены образа требуется механика подписи образов, доступная на текущий момент в CRI-O https://kubernetes.io/blog/2023/06/29/container-image-signature-verification/
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
К слову, вышеописанная последовательная выборка начинает сильно усложнять планирование расположения маячков, если помещение является многоуровневым (например, ТЦ с галереями над атриумом). Вполне возможна ситуация, когда на галерее второго этажа устройство принимает сигналы с двух маячков галереи и одного-атриума, что может приводить к «телепортации» вычисленной позиции между этажами.