Т.е. поставили CNI, коих, помимо weave, великое множество. Я, собственно, и удивлялся, как в статье что-то работает на multi-host кластере без CNI, задача которого как раз управлять роутингом между подами на разных хостах.
Оно fixed, но реализация в alpha стадии и не видно, чтобы что-то изменилось с тех пор https://kubernetes.io/blog/2021/08/09/run-nodes-with-swap-alpha/ Плюс реализация, по сути, никакая - кублет просто запускается с включенным свапом и может позволить подам использовать свап или не использовать. Все.
А рекомендация отключать свап все так же в силе, т.к. имеем непредсказуемое поведение нагрузок с ним. Плюс кубер все так же не способен оценить использовать свапа процессами, а значит не имеет полного контроля над ситуацией.
Собственно, я всегда отключал свап на любых продовых серваках, не только кубера. От этого всегда становилось только лучше. Многий софт точно так же рекомендует это делать.
Видимо решили разделить роли. kubeadm это инструмент исключительно настройки кубера. Он не занимается настройкой ОС и ее компонентов. Для последнего есть kubespray - он предварительно все настроит, даст выбор контейнерного рантайма и много чего еще (статья, например, не коснулась вообще выбора CNI), а потом использует тот же kubeadm, чтобы настроить специфические куберовские вещи.
Не знаю, откуда вы взяли, что притворяется. Просто взяли простой знакомый язык запросов и назвали его специально CQL, чтобы люди не думали, что это как постгре SQL какой-нить.
Kafka, redis точно так же можно сказать притворяются. Их точно так же пытаются натянуть как сову на глобус с подачи компаний, стоящих за их разработкой. Ничего плохого в этом нет, просто надо понимать, что к чему. Касандра тут ничем не выделяется. По факту, это СУБД. Просто NoSQL с широкими колонками и прочими особенностям. Все как у всех.
Вот уж операциям записи вообще не больно будет. Будет больно как раз таки чтению, оно самое проблемное в касандре. При жирных партициях и частых обновлениях будет полно тамбстоунов, которые при чтении придется пропускать. Записи же вообще пофиг. В коммит лог и memtable записал и забыл.
Оно все же больше, чем просто KV хранилище. Именно за счет кластерных ключей и алгоритмов распределения данных. Не говоря уже о материализованных представлениях, вторичных индексах, транзакциях, CDC и прочих плюшках. За счет всего этого поверх нее можно сделать очень многое, если не требуется строгая консистентность между таблицами. Хоть основной OLTP сторандж, хоть OLAP, хоть data lake.
Антипаттернов полно в любой базе, это вообще ниразу не недостаток касандры. Очереди делаются вполне себе, если в дополнению к TTL правильную стратегию компакшена выбрать. А так, всему свой инструмент. Кафка тажа.
Пост конечно глупый совершенно. Во-первых, касандра не колоночная база данных и никаким местом с Clickhouse и Vertica их сравнивать и противопоставлять нельзя, ибо OLTP против OLAP получается. Из касандры OLAP делается только через Apache Spark ему подобные. Во-вторых, пример запросов действительно совершенно некорректный. Делать выборки без primary key это антипаттерн и заставит ходить за данным по всем нодам в кластере. Ну и касандра никак вообще не оптимизирована, можно сказать, для работы на высокопроизводительном оборудовании. Она его не способная утилизировать в принципе. Сцилла да, касандра нет от слова совсем.
Ничего не сделает кря. Спокойно выполнится запрос. Не очень эффективно конечно и будут проблемы, если одна из нод лежит в кластере, но выполнится. Хоть там петабайт в таблице данных.
На redis это мало похоже хотя бы потому, что оно скейлится действительно и отказоустойчиво в отличии от. Сравнивать с CH и Vertica тоже некорректно, ибо принципиально разные базы для совершенно разных нагрузок и объемов данных.
А популярность касандры сложно оспаривать. Повсюду она в применении. Читать из нее и сделать нормальную схему ничего сложного не представляет. У нее очень простые правила хранения данных и того, как выполняются запросы. Намного проще, чем в реляционных базах. Все предсказуемо и понятно. От того, не каждый тип запросов можно вообще реализовать на ней.
Это значит на трубку ставится IPA, скаченная под чужой учеткой. При скачивании из аппстор IPA привязывается к текущей учетке. И без кредов для нее не запустится. Это вполне известное поведение, связанное с DRM системой аппстора.
Добавление сертификата в доверенные это значит установка IPA, который никогда не был в аппсторе и подписан кем-то своей учеткой разработчика. Будь это корпоративная или обычная. В этом случае да, в телефон добавляется серт и его нужно одобрить в настройках трубки.
Это чистой воды фишинг, с которым бороться именно так - информирование. Ровно тоже самое, когда звонят с неизвестных телефонов и представляются сбером. Других вариантов здесь нет.
Слышали. Способов установки миллион. В том числе через самостоятельное использование тех же библиотек, через которые iMazing работает. Слова "специалиста" менее глупо от этого не звучат. Если в эпл кто-то все таки стукнется головой сильно и решит вырезать установку приложений по USB, то MDM никуда не денется и сбер тоже сможет ставить через него приложения.
По мнению специалистов, установка приложений через iMazing и аналогичные утилиты никогда не считалась надёжной, а Apple может скоро закрыть эту лазейку или начать удалённо блокировать доступ к приложениям, установленным через подобные инструменты.
Что это за "специалисты" такие? Всегда это было надежным и удобным способом установки корпоративных приложений. Убрать его это значит удалить штатный функционал iOS - iMazing и прочие полагаются на проприетарные протоколы, которые iTunes и компоненты macOS сами же и используют. Даже если это невероятным образом закроют, то всегда остается установка по сети по ссылке. Убрать все это значит нагнуть корпоративный рынок.
Единственный способ это запретить это отозвать корпоративный аккаунт, которым сбер подписывает приложения. Тут у эпл уже руки развязаны. Уже сейчас они палки в колеса вставляют и просят подтвердить, что у вас больше 100 человек в компании, иначе корпоративный аккаунт вам не подходит, и мы не дадим вам его продлить.
Также эксперты по кибербезопасности предупредили, что при использовании аналогов iMazing третьи лица могут получить доступ к данным пользователя на смартфоне, включая фотографии, сообщения, бэкапы и другую информацию
А вот это правда реальная угроза. И тут не поможет смотреть через плечо кому-то. Данные могут спокойно скачиваться в фоне. Как только пользователь подключил свой девайс к ПК и разрешил доступ, то все двери открыты.
Мы всегда развёртываем на S3. Архитектурно ложится идеально и решения намного проще, чем полноценные кластерные файловые системы. Достаточно поднять какойнить minio и отказоустойчивый регистри готов. В дефолтном registry нужно только отключить redirect, чтобы все корректно работало.
На практике деплоить и менеджить такой кластер сильно сложнее. Плюс если требуется таки какая-то надежность с репликами, то начинается гемор с распределением реплик правильным. Все таки сильно проще поднять один сервис и наблюдать, как он забирает все ресурсы из коробки.
Тогда это нифига не арбитр, а ерунда какаято. Речь о том, что в кворумных системах необязательно делать все узлы полноценными. Арбитр может давать голос свой в общее голосование, но не хранить на себе данные например. Его отказ приведет лишь к тому, что два остальных узла будут большинством и система отлично продолжит работать. Похожим образом работает vmware vsan, где арбитром может быть любая дохлая тачка с esxi. И не надо городить еще один полноценный кластер просто чтобы сделать нечетное число узлов.
Да вообще в любой надежной системе должно быть как минимум 3 узла. 2 узла это верная смерть, т.к. split-brain. Как минимум нужен арбитр, он может не быть полноценным 3 узлом.
Как правило, это заранее зарезервированный кусок флеша, который недоступен ОС. Таким же образом резервируются запасные ячейки на случай, если какие-то помрут. Так в SSD повышают ресурс на запись.
Т.е. поставили CNI, коих, помимо weave, великое множество. Я, собственно, и удивлялся, как в статье что-то работает на multi-host кластере без CNI, задача которого как раз управлять роутингом между подами на разных хостах.
Оно fixed, но реализация в alpha стадии и не видно, чтобы что-то изменилось с тех пор https://kubernetes.io/blog/2021/08/09/run-nodes-with-swap-alpha/ Плюс реализация, по сути, никакая - кублет просто запускается с включенным свапом и может позволить подам использовать свап или не использовать. Все.
А рекомендация отключать свап все так же в силе, т.к. имеем непредсказуемое поведение нагрузок с ним. Плюс кубер все так же не способен оценить использовать свапа процессами, а значит не имеет полного контроля над ситуацией.
Собственно, я всегда отключал свап на любых продовых серваках, не только кубера. От этого всегда становилось только лучше. Многий софт точно так же рекомендует это делать.
Видимо решили разделить роли. kubeadm это инструмент исключительно настройки кубера. Он не занимается настройкой ОС и ее компонентов. Для последнего есть kubespray - он предварительно все настроит, даст выбор контейнерного рантайма и много чего еще (статья, например, не коснулась вообще выбора CNI), а потом использует тот же kubeadm, чтобы настроить специфические куберовские вещи.
Не знаю, откуда вы взяли, что притворяется. Просто взяли простой знакомый язык запросов и назвали его специально CQL, чтобы люди не думали, что это как постгре SQL какой-нить.
Kafka, redis точно так же можно сказать притворяются. Их точно так же пытаются натянуть как сову на глобус с подачи компаний, стоящих за их разработкой. Ничего плохого в этом нет, просто надо понимать, что к чему. Касандра тут ничем не выделяется. По факту, это СУБД. Просто NoSQL с широкими колонками и прочими особенностям. Все как у всех.
Вот уж операциям записи вообще не больно будет. Будет больно как раз таки чтению, оно самое проблемное в касандре. При жирных партициях и частых обновлениях будет полно тамбстоунов, которые при чтении придется пропускать. Записи же вообще пофиг. В коммит лог и memtable записал и забыл.
Оно все же больше, чем просто KV хранилище. Именно за счет кластерных ключей и алгоритмов распределения данных. Не говоря уже о материализованных представлениях, вторичных индексах, транзакциях, CDC и прочих плюшках. За счет всего этого поверх нее можно сделать очень многое, если не требуется строгая консистентность между таблицами. Хоть основной OLTP сторандж, хоть OLAP, хоть data lake.
Антипаттернов полно в любой базе, это вообще ниразу не недостаток касандры. Очереди делаются вполне себе, если в дополнению к TTL правильную стратегию компакшена выбрать. А так, всему свой инструмент. Кафка тажа.
Не свалится. Это не реляционная база. Постранично запрашивайте сколько влезет и все будет ок.
Пост конечно глупый совершенно. Во-первых, касандра не колоночная база данных и никаким местом с Clickhouse и Vertica их сравнивать и противопоставлять нельзя, ибо OLTP против OLAP получается. Из касандры OLAP делается только через Apache Spark ему подобные. Во-вторых, пример запросов действительно совершенно некорректный. Делать выборки без primary key это антипаттерн и заставит ходить за данным по всем нодам в кластере. Ну и касандра никак вообще не оптимизирована, можно сказать, для работы на высокопроизводительном оборудовании. Она его не способная утилизировать в принципе. Сцилла да, касандра нет от слова совсем.
Ничего не сделает кря. Спокойно выполнится запрос. Не очень эффективно конечно и будут проблемы, если одна из нод лежит в кластере, но выполнится. Хоть там петабайт в таблице данных.
На redis это мало похоже хотя бы потому, что оно скейлится действительно и отказоустойчиво в отличии от. Сравнивать с CH и Vertica тоже некорректно, ибо принципиально разные базы для совершенно разных нагрузок и объемов данных.
А популярность касандры сложно оспаривать. Повсюду она в применении. Читать из нее и сделать нормальную схему ничего сложного не представляет. У нее очень простые правила хранения данных и того, как выполняются запросы. Намного проще, чем в реляционных базах. Все предсказуемо и понятно. От того, не каждый тип запросов можно вообще реализовать на ней.
Или просто купить муриканскую карту и через крипту оплачивать спотифай
Это значит на трубку ставится IPA, скаченная под чужой учеткой. При скачивании из аппстор IPA привязывается к текущей учетке. И без кредов для нее не запустится. Это вполне известное поведение, связанное с DRM системой аппстора.
Добавление сертификата в доверенные это значит установка IPA, который никогда не был в аппсторе и подписан кем-то своей учеткой разработчика. Будь это корпоративная или обычная. В этом случае да, в телефон добавляется серт и его нужно одобрить в настройках трубки.
Это чистой воды фишинг, с которым бороться именно так - информирование. Ровно тоже самое, когда звонят с неизвестных телефонов и представляются сбером. Других вариантов здесь нет.
Мысли не возникло, потому что ни о каком взломе речи не идет. Сбер пользуется штатными средствами установки приложений
Так а кто понимает, что это такое вообще? Простым смертным это темный лес.
Слышали. Способов установки миллион. В том числе через самостоятельное использование тех же библиотек, через которые iMazing работает. Слова "специалиста" менее глупо от этого не звучат. Если в эпл кто-то все таки стукнется головой сильно и решит вырезать установку приложений по USB, то MDM никуда не денется и сбер тоже сможет ставить через него приложения.
Что это за "специалисты" такие? Всегда это было надежным и удобным способом установки корпоративных приложений. Убрать его это значит удалить штатный функционал iOS - iMazing и прочие полагаются на проприетарные протоколы, которые iTunes и компоненты macOS сами же и используют. Даже если это невероятным образом закроют, то всегда остается установка по сети по ссылке. Убрать все это значит нагнуть корпоративный рынок.
Единственный способ это запретить это отозвать корпоративный аккаунт, которым сбер подписывает приложения. Тут у эпл уже руки развязаны. Уже сейчас они палки в колеса вставляют и просят подтвердить, что у вас больше 100 человек в компании, иначе корпоративный аккаунт вам не подходит, и мы не дадим вам его продлить.
А вот это правда реальная угроза. И тут не поможет смотреть через плечо кому-то. Данные могут спокойно скачиваться в фоне. Как только пользователь подключил свой девайс к ПК и разрешил доступ, то все двери открыты.
Мы всегда развёртываем на S3. Архитектурно ложится идеально и решения намного проще, чем полноценные кластерные файловые системы. Достаточно поднять какойнить minio и отказоустойчивый регистри готов. В дефолтном registry нужно только отключить redirect, чтобы все корректно работало.
На практике деплоить и менеджить такой кластер сильно сложнее. Плюс если требуется таки какая-то надежность с репликами, то начинается гемор с распределением реплик правильным. Все таки сильно проще поднять один сервис и наблюдать, как он забирает все ресурсы из коробки.
Тогда это нифига не арбитр, а ерунда какаято. Речь о том, что в кворумных системах необязательно делать все узлы полноценными. Арбитр может давать голос свой в общее голосование, но не хранить на себе данные например. Его отказ приведет лишь к тому, что два остальных узла будут большинством и система отлично продолжит работать. Похожим образом работает vmware vsan, где арбитром может быть любая дохлая тачка с esxi. И не надо городить еще один полноценный кластер просто чтобы сделать нечетное число узлов.
Да вообще в любой надежной системе должно быть как минимум 3 узла. 2 узла это верная смерть, т.к. split-brain. Как минимум нужен арбитр, он может не быть полноценным 3 узлом.
Как правило, это заранее зарезервированный кусок флеша, который недоступен ОС. Таким же образом резервируются запасные ячейки на случай, если какие-то помрут. Так в SSD повышают ресурс на запись.