Вопрос из чисто научного интереса: в списке узлов указана установленная версия 1.23. Надеюсь, Вы и новые разворачиваете, тут просто именно такая нужна была?
Там закон позволяет. На уровне маршрутизации Visa Interchange Center даже есть сервис обработки лимитов операций. То есть банк может в визу загрузить свой стоп-лист, прописать общие лимиты для групп карт своих клиентов и Visa Net будет сама вести учет расходования лимитов. В банк будут только поступать финансовые сообщения пакетами раз в банковский день и сводные отчеты клиринга. Облачные банковские технологии, доступные с прошлого века.
Можешь в банк вообще онлайн не покупать, все за тебя сделают Visa Net и EPSS.
Попробуй у нас такое предложить.
Помню еще время, когда у нас по закону нельзя было выпускать карты с льготным периодом
Можно представить, запускаем нагрузочное тестирование с автомасштабированием реплик, и все это держится на докере. Реально под 200 реплик приложения с максимальной нагрузкой запланировал протестировать. Боюсь, докер раньше помереть может
Кажется, я нашел еще нечто неприятное с прошлой версии: безобидный deployment чего-либо ( хоть официальный образ busybox, не важно), примененный даже без админских прав, что именно в yaml не буду раскрывать, короче, мастер узлы в панике стирают все ключи, сертификаты, доступ к api серверу прекращается, core dns тоже прекращает нормально работать. Фишка именно в параметрах деплоймента, которые попадают в api server и scheduler. Возможно, защита от атаки какая-то, я не 100% гуру, а может быть так и надо. Но все равно, кровавый энтерпрайз под ударом.
Не уверен, что разработчики сценариев быстро все учитывают. Тут еще в ubuntu последнее китайское предупреждение о депрекации apt-key.
Плюс хочется самому контролировать версии всех колесиков внутри.
Свое решение позволяет пилить и ускорять процесс деплоя кластера. Например, два, три ansible хоста, если один действительно на 100 узлов намного медленнее работает. Всегда будет 3 минуты на все. Тут была свежая публикация, как только недавно докер из кластера выкинули, и заодно перешли на версию 1.21 =) legacy оно такое
Утилита диагностики. Кластер можно создать формально работающий, в логах ошибок нет, crashloop нет. Но, например, ingress admission contoller api будет недоступен, попытка создания endpoint хотя-бы вернет ошибку. (Это я сам кластер свой шатал)
В sonobuoy 300+ тестов на мыслимые сценарии работы ресурсов, в том числе на разных рабочих узлах. Только для этого и нужен в тестах второй рабочий
Вопрос из чисто научного интереса: в списке узлов указана установленная версия 1.23. Надеюсь, Вы и новые разворачиваете, тут просто именно такая нужна была?
Во-первых поздравляю.
Во-вторых всегда есть люди, которым не пофиг.
Мой совет (совершенно искренний, ни над кем не издеваюсь): причесать «котов» в репе, вместо dkot какой-нибудь cshell написать, в cncf не поймут.
А так гордиться нам надо, что наши айтишники бороздят просторы несмотря на.
Труд в широком смысле не уважают, рекламу сразу видят. По этой же причине коньяк 5* max, памятники истории «ремонтируют» путем сноса и т.д.
Там закон позволяет. На уровне маршрутизации Visa Interchange Center даже есть сервис обработки лимитов операций. То есть банк может в визу загрузить свой стоп-лист, прописать общие лимиты для групп карт своих клиентов и Visa Net будет сама вести учет расходования лимитов. В банк будут только поступать финансовые сообщения пакетами раз в банковский день и сводные отчеты клиринга. Облачные банковские технологии, доступные с прошлого века.
Можешь в банк вообще онлайн не покупать, все за тебя сделают Visa Net и EPSS.
Попробуй у нас такое предложить.
Помню еще время, когда у нас по закону нельзя было выпускать карты с льготным периодом
Можно представить, запускаем нагрузочное тестирование с автомасштабированием реплик, и все это держится на докере. Реально под 200 реплик приложения с максимальной нагрузкой запланировал протестировать. Боюсь, докер раньше помереть может
Кажется, я нашел еще нечто неприятное с прошлой версии: безобидный deployment чего-либо ( хоть официальный образ busybox, не важно), примененный даже без админских прав, что именно в yaml не буду раскрывать, короче, мастер узлы в панике стирают все ключи, сертификаты, доступ к api серверу прекращается, core dns тоже прекращает нормально работать. Фишка именно в параметрах деплоймента, которые попадают в api server и scheduler. Возможно, защита от атаки какая-то, я не 100% гуру, а может быть так и надо. Но все равно, кровавый энтерпрайз под ударом.
В k3s нынче какая версия ?
Мы же самую свежую версию кубера рассматриваем.
Не уверен, что разработчики сценариев быстро все учитывают. Тут еще в ubuntu последнее китайское предупреждение о депрекации apt-key.
Плюс хочется самому контролировать версии всех колесиков внутри.
Свое решение позволяет пилить и ускорять процесс деплоя кластера. Например, два, три ansible хоста, если один действительно на 100 узлов намного медленнее работает. Всегда будет 3 минуты на все. Тут была свежая публикация, как только недавно докер из кластера выкинули, и заодно перешли на версию 1.21 =) legacy оно такое
Утилита диагностики. Кластер можно создать формально работающий, в логах ошибок нет, crashloop нет. Но, например, ingress admission contoller api будет недоступен, попытка создания endpoint хотя-бы вернет ошибку. (Это я сам кластер свой шатал)
В sonobuoy 300+ тестов на мыслимые сценарии работы ресурсов, в том числе на разных рабочих узлах. Только для этого и нужен в тестах второй рабочий