1) Флаг--enable-admission-plugins=NodeRestriction никакого отношения к Validating Admission Policy не имеет.
2) Версия API admissionregistration.k8s.io/v1alpha1 уже очень сильно устарела. В документации написано использовать как минимум admissionregistration.k8s.io/v1beta1 , но на самом деле начиная с 1.22 по дефолту используется admissionregistration.k8s.io/v1 .
3) "повысить доступность веб-хуков, задеплоив несколько инстансов webhook server в некий отдельный webhook-namespace". О каких вебхуках вообще идет речь? Validating Admission Policy - это фича самого аписервера, вебхуки тут не используются.
По самой статье - нужно больше примеров, хотя бы даже из документации.
По самой фиче - интересная и полезная штука, но мы используем Kyverno. Гораздо более мощный функционал и огромное количество готовых политик.
Я не программист, просто Девопс и сисадмин, и я совершенно не боюсь, что ИИ заберет мою работу. Если хотя бы часть работы заберет, то я руку пожму такому ИИ.
С одной стороны, чтобы ИИ смог помочь, нужно четко написать ТЗ. Тут сразу минус 99% заказчиков. Обычно то, что люди говорят в начале это не то, что они имеют ввиду на самом деле. Всегда потом всплывает миллион нюансов. ИИ полезен, когда человек точно знает, что он хочет, и способен это сформулировать. Но в большинстве случаев это не так.
Потом дикий зоопарк из технологий и железа. Скрестить все это и заставить работать вместе в отсутствии нормальной документации - не думаю, что это возможно для ИИ. Если ИИ сможет разработать единые стандарты и убедить всех людей им следовать, то это будет сродни чуду.
Если ИИ поможет мне автоматизировать рутину, то это будет круто и полезно. Но в остальном на мой век точно работы хватит.
Особенность Kubernetes — в отсутствии своей системы аутентификации: каждый пользователь кластера по умолчанию имеет права суперадминистратора и может делать что угодно.
Вы говорите конкретно про VK cloud или в целом про Kubernetes? Если в целом, то это не так.
Отсутствие собственной системы аутентификации создает определенные опасности: любой пользователь облака может получить доступ к kubeconfig и сделать с ним что угодно.
Опять же, возможно нужно уточнить, что речь идет только про ваше решение. В других облаках все по-другому.
Пересоздать, валидировать и отозвать kubeconfig сложно, поэтому любые действия злоумышленников с ним могут причинить значительный ущерб.
В Kubernetes нет такой сущности как kubeconfig. Вы наверное имеете ввиду клиентские сертификаты?
По умолчанию пользователю надо вводить пароль раз в час, это самый безопасный режим взаимодействия. Но если надо, в kubeconfig можно внести правки, чтобы пароль запрашивался только однажды.
Вы снова так говорите, словно kubeconfig это часть Kubernetes. Это не так.
Я давно понял, что "платят деньги, да и ладно". И еще как ни странно, но "клиент всегда прав". Раньше я пытался изменить мир и открыть людям глаза на "фатальные недостатки". Спустя многие годы понял, что главное в работе - это деньги. Смысл там искать бесполезно. И стало намного легче жить и работать.
Можно просто не использовать liveness probes, а только readiness probes. Тогда под не будет убит под нагрузкой из-за таймаута пробы. И вообще liveness пробы в большинстве случаев только мешают.
Dante здесь лишний. Zapret сам умеет быть сокс прокси, для этого нужно запустить tpws с параметром --socks.
Насколько я понимаю, на микротиках нельзя исполнять кастомные бинарники.
А на микротике такое можно сделать, интересно?
В статье ряд неточностей:
1) Флаг
--enable-admission-plugins=NodeRestrictionникакого отношения к Validating Admission Policy не имеет.2) Версия API
admissionregistration.k8s.io/v1alpha1уже очень сильно устарела. В документации написано использовать как минимумadmissionregistration.k8s.io/v1beta1, но на самом деле начиная с 1.22 по дефолту используетсяadmissionregistration.k8s.io/v1.3) "повысить доступность веб-хуков, задеплоив несколько инстансов webhook server в некий отдельный webhook-namespace". О каких вебхуках вообще идет речь? Validating Admission Policy - это фича самого аписервера, вебхуки тут не используются.
По самой статье - нужно больше примеров, хотя бы даже из документации.
По самой фиче - интересная и полезная штука, но мы используем Kyverno. Гораздо более мощный функционал и огромное количество готовых политик.
Я не программист, просто Девопс и сисадмин, и я совершенно не боюсь, что ИИ заберет мою работу. Если хотя бы часть работы заберет, то я руку пожму такому ИИ.
С одной стороны, чтобы ИИ смог помочь, нужно четко написать ТЗ. Тут сразу минус 99% заказчиков. Обычно то, что люди говорят в начале это не то, что они имеют ввиду на самом деле. Всегда потом всплывает миллион нюансов. ИИ полезен, когда человек точно знает, что он хочет, и способен это сформулировать. Но в большинстве случаев это не так.
Потом дикий зоопарк из технологий и железа. Скрестить все это и заставить работать вместе в отсутствии нормальной документации - не думаю, что это возможно для ИИ. Если ИИ сможет разработать единые стандарты и убедить всех людей им следовать, то это будет сродни чуду.
Если ИИ поможет мне автоматизировать рутину, то это будет круто и полезно. Но в остальном на мой век точно работы хватит.
Очень интересно, что из этого получится. @aigoncharovможешь потом написать результаты своего эксперимента?
У "нас" разве не так же?
Вы говорите конкретно про VK cloud или в целом про Kubernetes? Если в целом, то это не так.
Опять же, возможно нужно уточнить, что речь идет только про ваше решение. В других облаках все по-другому.
В Kubernetes нет такой сущности как kubeconfig. Вы наверное имеете ввиду клиентские сертификаты?
Вы снова так говорите, словно kubeconfig это часть Kubernetes. Это не так.
Стандартный разговор с техподдержкой оператора, где они предлагают тебе перезагрузить телефон.
Gitlab CI уже сто лет как yaml и всегда был бесплатным. Вы что-то с чем-то путаете.
"И чтоб все выглядело как несчастный случай!" (с) анекдот
Почему не kubespray?
Это вы цены на жилье в Турции не видели )
Я давно понял, что "платят деньги, да и ладно". И еще как ни странно, но "клиент всегда прав". Раньше я пытался изменить мир и открыть людям глаза на "фатальные недостатки". Спустя многие годы понял, что главное в работе - это деньги. Смысл там искать бесполезно. И стало намного легче жить и работать.
Кудрявого уже кстати повязали на Багамах.
А глохнуть на перекрестках, если рано бросить сцепление, такая машина тоже будет? Также, я считаю, не хватает эмуляции залития свечей.
Можно просто не использовать liveness probes, а только readiness probes. Тогда под не будет убит под нагрузкой из-за таймаута пробы. И вообще liveness пробы в большинстве случаев только мешают.
Дальше видимо будут NFT-аватарки и VIP-эмодзи.
Толковые люди с хорошим опытом везде нужны. И не только в айти.
Хотелось бы всем управлять из одного места.