Кассандра в Kubernetes podManagementPolicy - УпорядоченныйЧитый против Параллельного - PullRequest
2 голосов
/ 09 апреля 2019

В каждой статье, которую я видел в Интернете о работе кластера Cassandra в Kubernetes, либо пропускалось поле podManagementPolicy, либо устанавливалось значение OrderedReady, что, по сути, то же самое, поскольку это значение по умолчанию.

Мне было интересно, можно ли использовать podManagementPolicy: Parallel для ускорения процесса синхронизации при перезапуске нескольких узлов кластера Cassandra.

Ответы [ 2 ]

3 голосов
/ 01 мая 2019

Насколько я знаю, это плохая идея. Я попробовал это и получил последний узел, входящий в CrashLoopBackoff. Похоже, причина в том, что присоединяющиеся узлы терпят крах, если они видят, что другой узел пытается присоединиться одновременно.

podManagementPolicy: OrderedReady должен быть путь.

2 голосов
/ 09 апреля 2019

Да, это прекрасно работает. Мы используем podManagementPolicy: Parallel в каждом нашем наборе состояний, включая кластер кассандры. Это действительно помогло нам в сценарии перезапуска всего кластера, когда все модули запускаются одновременно и синхронизируются.

Вариант использования podManagementPolicy: Parallel в нашем кластере:

У нас есть кластер из 3-х узлов из неизолированного металла K8s и кластер из 3 узлов из кассандры, который использует local-storage узла для PV. В случае local-storage PV привязан к узлу. Таким образом, если мы установим podManagementPolicy: OrderedReady, то проблема в том, что если мы остановим 2 узла кластера с допустимыми значениями cds-pod-1 и cds-pod-2, оба они перейдут в неизвестное состояние. Теперь допустим, что мы приводим узел в положение, в котором находится cds-pod-2, тогда он не переводит этот модуль в исходное состояние, потому что ему нужно, чтобы cds-pod-1 находился в рабочем состоянии, чтобы привести cds-pod-2 в рабочее состояние. Следовательно, мы должны изменить podManagementPolicy: Parallel, и тогда вы сможете вызвать модуль любым способом, и это не зависит от порядка.

...