Я управляю развертыванием Elasticsearch в Kubernetes. Я вижу, что дисковое хранилище почти заполнено,поэтому я хотел бы увеличить размер постоянных томов.
Я хочу изменить это значение в спецификации Stateful Set:
. volumeClaimTemplates [0] .spec.resources.requests.storage: "10Gi"
Но когда я делаю это с помощью панели управления Kubernetes, я получаю следующее сообщение:
Внутренняя ошибка сервера
StatefulSet.apps "es -cluster "недействителен: spec: Forbidden: обновления в statefulset> spec для полей, отличных от 'replicas', 'template' и 'updateStrategy', запрещены.
Это заставляет меня думать, что мне придется удалить мой существующий Stateful Установите и разверните новый.
Можно ли увеличить дисковое пространство для каждого модуля без прерывания обслуживания или потери данных?
У меня есть несколько модулей данных Elasticsearch, и я использую количество реплик = 1, поэтому, если я смогу снять их и обновить дисковое хранилище по одному модулю за раз, проблем быть не должно. Я просто не понимаю, как это сделать с учетом указанного выше ограничения.
Даже несмотря на то, что изменение размера постоянных томов с помощью Kubernetes из Kubernetes 1.11 , похоже, есть некоторые проблемы с этим.
Как обсуждалось в GitHub: StatefulSet: поддерживает изменение размера Хранилище pvc в K8s v1.11 # 68737
Из-за этого ограничения многие операторы баз данных для Kubernetes не поддерживают изменение размера PVC. Это критическая проблема, потому что, когда ваша база данных становится больше, чем вы ожидали - у вас нет выбора, и вам нужно сделать резервную копию БД и воссоздать новую БД из резервной копии.
Вы должны изменить ее размер, удалив Statefulset, это будет означать, что вы удалит все Pod'ы и вызовет простои.
обошел эту проблему. Я обошел это ограничение на elasticsearch из-за работы, которую мне пришлось выполнить, чтобы избежать возможности назначения томов EBS, потому что они находятся в неправильной зоне доступности, т. е. я создал набор с отслеживанием состояния для каждой зоны доступности. Если я хочу изменить некоторые характеристики хранилища, я создаю новую зону доступности, используя тот же класс хранилища, а затем переношу все данные в модули в этой новой зоне доступности, а затем уничтожаю старую зону доступности.
Надеюсь, это вам немного поможет. .
Собрал эту процедуру вместе, основываясь на других комментариях на https://github.com/kubernetes/kubernetes/issues/68737 . Я тестировал это на kubernetes 1.14:
kubectl edit pvc
для каждого PVC в StatefulSet, чтобы увеличить его емкость. kubectl delete sts --cascade = false
для удаления StatefulSet и оставьте его модули. kubectl apply -f
, чтобы воссоздать StatefulSet. kubectl rollout restart sts
, чтобы перезапустить модули по одному. Во время перезапуска размер PVC модуля будет изменен. Если вы хотите отслеживать, что происходит, запустите еще два окна оболочки с этими командами перед любой из приведенных выше команд:
kubectl get pod -w
kubectl get pvc -w
Чтобы применить этот принцип к диаграмме руля, я смог сделать следующее, основываясь на входных данных выше, а также на некоторых рекомендациях в этой теме: https://github. com/kubernetes/kubernetes/issues/68737#issuecomment-469647348
В приведенном ниже примере используются следующие значения:
Эти значения можно найти в вашей среде с помощью следующих команд:
kubectl get pvc
kubectl get sts
список helm
А вот шаги по обновлению размера PV в StatefulSet диаграммы руля:
kubectl edit storageClass standard
и установите/убедитесь, что allowVolumeExpansion: true (это уже было в моем случае)kubectl удалить sts --cascade=false rabbitmq-server
kubectl изменить pvc data-rabbitmq-server-0
и изменить размер spec на 50Gihelm upgrade --recreate-pods --reuse-values -f rabbit-values.yaml rabbitmq-server stable/rabbitmq
ПРИМЕЧАНИЕ. Последний шаг использует --recreate-pods
для принудительного перезапуска модулей, что приводит к фактическому изменению размера файловой системы. Это также приводит к простою этих модулей. Если вы хотите попытаться сделать это без простоев, вы можете попробовать удалить этот флаг и вручную убить/перезапустить один модуль за раз или что-то в этом роде.
Вот полный сценарий для изменения размера томов STS на основе других ответов. Мне не нужно было - cascade = false
при удалении STS, потому что он был бы масштабирован до 0 перед этим шагом.
kubectl get -o jsonpath='{.allowVolumeExpansion}' sc <SC-NAME>
# should return true, otherwise, patch it:
kubectl patch -p '{"allowVolumeExpansion": true}' sc <SC-NAME>
# then run the first command again
# we need the original replica count, so let's save it before scaling down
REPLICAS=`kubectl get -o jsonpath='{.spec.replicas}' sts/<STS-NAME>`
kubectl scale sts/<STS-NAME> --replicas 0
NEW_SIZE=128Gi
for i in `seq 0 $[REPLICAS-1]`; do
PVC=<PVC-NAME-PREFIX>-$i
echo "Updating PVC $PVC"
# Print the current size:
kubectl get -o jsonpath='{.spec.resources.requests.storage} ' pvc/$PVC
# Set the new size:
kubectl patch -p '{"spec": {"resources": {"requests": {"storage": "'$NEW_SIZE'"}}}}' pvc/$PVC
# Verify the PV:
echo "Waiting for 10 seconds so that the PV picks up the change..."
echo "If you still see the same size, do not worry, to see the new size just run this script again"
sleep 10
PV=`kubectl get -o jsonpath='{.spec.volumeName}' pvc/$PVC`
kubectl get -o jsonpath='{.spec.capacity.storage} ' pv/$PV
echo "Done"
done
kubectl delete sts <STS-NAME>
for i in `seq 0 $[REPLICAS-1]`; do
PVC=<PVC-NAME-PREFIX>-$i
echo "Verifying the size of PVC $PVC"
# Verify the current size:
kubectl get -o jsonpath='{.status.capacity.storage} ' pvc/$PVC
done
Вот шаги, которые помогли мне: