Руководства для нескольких дата-центров on Cozystack

Настройка таймаутов etcd

Mon, 01 Jan 0001 00:00:00 +0000

Возможные проблемы

etcd - надежное key-value хранилище для критически важных данных, где Kubernetes API server хранит свое состояние. Значения не считаются записанными, пока кворум узлов не подтвердит запись данных. Кроме того, etcd постоянно проверяет, что в кластере есть лидер и каждый узел знает, какой именно. Обычно кластер etcd запускается на узлах в одном дата-центре, где задержка мала, а таймауты по умолчанию настроены на максимально быстрое сообщение об ошибках. В растянутом кластере, где узлы находятся в разных дата-центрах, RTT значительно выше, и стандартные таймауты могут вызывать ложные срабатывания, как при разделении сети. В этом случае данные остаются согласованными, но etcd перейдет в readonly-режим, чтобы предотвратить split-brain. Если это происходит часто, многие другие компоненты Kubernetes начинают падать с неинформативными сообщениями об ошибках.

Конфигурация kube-scheduler

Mon, 01 Jan 0001 00:00:00 +0000

Добавьте метки на узлы

kubectl label node <nodename> topology.kubernetes.io/zone=A

Создайте глобальные topology spread constraints для приложений

apiVersion: v1
kind: ConfigMap
metadata:
 name: cozystack-scheduling
 namespace: cozy-system
data:
 globalAppTopologySpreadConstraints: |
 topologySpreadConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: DoNotSchedule

Настройте PodTopologySpread

См.: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#cluster-level-default-constraints

Для установки через Talm добавьте в templates/_helpers.tpl:

cluster:
...
 scheduler:
 config:
 apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
 - schedulerName: default-scheduler
 pluginConfig:
 - name: PodTopologySpread
 args:
 defaultConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: ScheduleAnyway
 defaultingType: List

Примените изменения:

Метки узлов

Mon, 01 Jan 0001 00:00:00 +0000

Как работают топологические метки

При запуске Kubernetes-кластера в нескольких дата-центрах важно понимать, какие workloads нужно размещать рядом друг с другом, например базу данных и backend-приложение, а какие - распределять по разным площадкам, например несколько реплик frontend, реплики базы данных или реплики томов. Первый шаг к этому - добавить метки на узлы Kubernetes. В публичных облаках обычно используются термины zone и region. В Kubernetes наиболее распространенный способ обозначить географическое расположение - использовать метки topology.kubernetes.io/zone и topology.kubernetes.io/region или только метку zone.

Конфигурация LINSTOR DRBD

Mon, 01 Jan 0001 00:00:00 +0000

Введение

В этом руководстве описана конфигурация, необходимая для использования хранилища LINSTOR в растянутом (распределенном) кластере Cozystack.

DRBD (Distributed Replicated Block Device) - система репликации блочных устройств на уровне ядра, работающая по сети. Сервер LINSTOR управляет томами DRBD, включая их создание, удаление и оркестрацию между узлами.

Сложности при использовании DRBD

DRBD считает данные записанными только после того, как они достигли кворума узлов. Но поскольку для конечного пользователя DRBD выглядит как блочное устройство, при нехватке узлов для кворума он должен вернуть ошибку в пределах заданного таймаута.

Настройка выделенной сети для распределенного хранилища с LINSTOR

Mon, 01 Jan 0001 00:00:00 +0000

Введение

В этом руководстве описано, как повысить надежность и производительность хранилища в распределенных кластерах Cozystack.

В гиперконвергентных кластерах для трафика хранилища обычно выделяют отдельную сеть. Однако не всегда возможно выделить отдельные storage-каналы между дата-центрами.

Если для хранилища нет выделенных междатацентровых каналов, есть два варианта:

изолировать storage-узлы в каждом дата-центре;
передавать storage-трафик через существующие uplink вместе с другими workloads.

В этом руководстве показано, как настроить LINSTOR на использование выделенной сети для storage-трафика внутри каждого дата-центра и при необходимости переключаться на общие каналы между дата-центрами.

Конфигурация SeaweedFS Multi-DC

Mon, 01 Jan 0001 00:00:00 +0000

В этом руководстве описано, как развернуть SeaweedFS в нескольких дата-центрах (“multi-DC”). Multi-zone конфигурация SeaweedFS доступна начиная с Cozystack v0.34.0.

Конфигурация SeaweedFS Multi-DC

Чтобы растянуть SeaweedFS на несколько DC, создайте новый кластер в режиме multi-DC.

По умолчанию SeaweedFS работает в одном дата-центре (DC), и уже запущенное single-DC-развертывание нельзя переключить в multi-DC-режим. Если нужно изменить топологию, удалите текущий экземпляр SeaweedFS и создайте новый с нужным режимом.

Удобный порядок действий:

Разверните tenant с seaweedfs: false.
Создайте новый экземпляр SeaweedFS в namespace tenant, используя нужную топологию.
Обновите tenant, установив seaweedfs: true.

1. Создайте tenant без SeaweedFS

Поле isolated, которое в ранних релизах Cozystack было доступно в объекте Tenant, удалено в v1.0. Текущая модель сетевой изоляции описана в upgrade notes: флаг isolated у Tenant удален.