rbd: image is locked by other nodes

Возможно это сэкономит вам время. Получил такую ошибку на ноде с кубом, а вот решение, которое я нашел на хабчике.

I ran into this issue "rbd: image is locked by other nodes", when connecting to an external ceph cluster with dynamic provisioning (storage classes) in kubernetes.

The findings is that if the rbd command is executed with the -m flag e.g. "rbd lock list -m —id ..." , and there is no configuration file (ceph.conf) under /etc/ceph .... then the rbd command will print out information that the configuration file is not used e.g. "7f27de2517c0 -1 did not load config file, using default settings." This is the normal case as the ceps-common does not install a ceph.conf file.

The rbd Volume Attach logic in kubernetes is building up a command string and execute the "raw" command "rbd lock list ..." (https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/volume/rbd/rbd_util.go).

The logic in rbdLock() function assumes the image is locked if there is a response to the "lock list" command.

As the rbd command print out "... did not load config file, using default settings." this will cause the error "rbd: image is locked by other nodes".

A work around for this is to create a ceph.conf under /etc/ceph on each kubernetes node.

cd /etc/ceph
cat > ceph.conf << EOF
[global]
mon_host = xx.xx.xx.xx:6789
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
EOF

Another cause for "rbd: image is locked by other nodes" might be if the userId (as provided in the StorageClass) does not have enough permission to list or set locks.

As the k8s kublet calls the "raw" rbd command, the sequence can be debugged by renaming the rbd command (e.g. rbdd) and create a bash wrapper (/usr/bin/rbd) that logs kubernetes commands and responses from the rbd (ceps-common) library.

#!/bin/bash
# wrapper script /usr/bin/rbd
logfile=/root/logging
# log commands from kubernetes
echo "rbdd $*" >> $logfile
# log responses from rbd binary (renamed to rbdd)
rbdd $*  > >(tee -a $logfile) 2> >(tee -a $logfile >&2)

взято из треда https://github.com/ceph/ceph-container/issues/642

#kubernetes #troubleshooting #ceph

Восстановление данных из ceph

А чем я занимался все выходные? разгребал последствия падения серверов в hetzner. У меня там наколенная инсталляция k8s+ceph в числе 3+3 vm, причем 4\6 на одном сервере. Как результат - когда у меня сгорела сетевуха, кластер развалился, поскольку 2\3 мониторов упало с повреждением базы, а третий выпал из кворума. Один из вариантов развития событий - вытащить данные и сложить их в сторону. Будет ли это новый кластер, или некоторая попытка сделать резервное копирование\достать самую новую версию, которая еще не успела скопироваться - не важно. Стало интересно как это сделать, если все упало напрочь и все что есть - только в чистом раздел с данными ceph. Наткнулся на готовое решение, в виде sh-скриптов, которые все уже сделают за вас:

https://gitlab.lbader.de/kryptur/ceph-recovery.git

все что нужно сделать - натравить скрипт на директорию с osd. скрипт изучает метаданные, заголовочные файлы и по найденному оффсету копирует указанное вами количество данных с помощью dd в образ. По сути за вас определяется информация "откуда начать", но вам надо задать информацию "где закончить" - это есть размер вашего image в пуле ceph, в байтах. Все это помещается в отдельный файл image.raw, который по сути и является тем самым диском с той самой ФС и данными, которые вы задавали при создании image. Монтируется обычным способом - mount image.raw /mnt и далее забираете свои данные. Единственное замечание - если последний скрипт отрабатывает моментально, у меня для вас плохие новости. Кол-во найденных блоков должно быть явно больше 1 =). Да, кстати, автор скрипта прекрасно отвечает на почту.

#ceph #troubleshooting

Список тегов, используемых в канале:

—-------------------------------
Лекции и материалы
—-------------------------------
#Занятие
#Лекции
Лекция
#junior

—---------
Linux
—---------
#ssh
#bash
#bash_tips_and_tricks
#awk
#tmux
#console
#utils
#troubleshooting
#nmap
#apt
#bind
#sound
#power_management

—----------
DevOps
—----------
#jenkins
#ansible
#git
#kubernetes
#deploy
#ceph
#docker
#puppet

—------------------
Virtualization
—------------------
#vmware
vagrant

—------------------
Networking
—---------------—
#networking
#proxy
#socks

—---------
InfoSec
—---------
#vulns
#security
#ctf

—-------------
Windows
—-------------
#RDTS
#windows_server2012
#RDP

—------------
Datacenters
—---------—
#ovh
#hetzner

—-------
Other
—-------
#android
#jira

—------------------------------------------------
Ссылки и сторонние материалы
—------------------------------------------------
#read
#thirdparty

Updated: 29.05.18

Получаем информацию о смонтированных rbd на нодах куба

Запускать на ноде куба. Этот скрипт полезен, если у вас дохлый мастер, иначе все это куда проще достается из апишки.

#!/bin/bash

IFS=$'\n'

for i in $(docker ps); do
  ID=$(echo $i | awk '{print $1}');
  for j in $(docker inspect $ID | grep "volumes/kubernetes.io~rbd"|grep -v "Source"); do
    NAME=$(docker inspect $ID | grep "Hostname\"")
    external_mpath=$(echo $j | awk -F\: '{print $1}' | grep -o '/var/lib.*')
    internal_mpath=$(echo $j | awk -F\: '{print $2}')
    rbd=$(mount | grep $external_mpath | awk '{print $1}')
    dnumber=$(echo $rbd | egrep -o "[0-9]+")
    image=$(cat /sys/bus/rbd/devices/${dnumber}/name)
    echo ""
    echo "name: $NAME"
    echo "rbd: $rbd"
    echo "mount path: $internal_mpath"
    echo "image: $image"
  done
done

Результат:

name:             "Hostname": "mongodb-database-865cfb8d6f-lgfnl",
rbd: /dev/rbd8
mount path: /data/db",
image: kubernetes-dynamic-pvc-af3f3636-635d-11e8-9801-0a580af4013f

т.е. отсюда можно узнать какому конкретно контейнеру какой конкретно image соответствует. Это полезно когда у вас динамический контроллер и сдохший мастер - чтобы забрать данные с запущенных подов.

#ceph #kubernetes #troubleshooting

Изменяем размер образа в ceph и применяем в k8s

1. Выяснить название image:

kubectl -n NAMESPACE get pv PV_NAME -o jsonpath="{.spec.rbd.image}"

2. выполнять с хоста, с которого настроен доступ к rbd. IMAGE_NAME взять из предыдущего шага.

export IMAGE_NAME=<image_name>
export SIZE=<size, ex. 20G>

посмотреть информацию по image

rbd info $IMAGE_NAME

выполнить изменение размера:

rbd resize $IMAGE_NAME --size $SIZE

посмотреть результат

rbd info $IMAGE_NAME

3. выяснить на какой ноде запущен под (соответственно куда смонтировано блочное устройство)

kubectl -n NAMESPACE get po -o wide

4. выполнить на ноде, полученной на предыдущем шаге

получаем номер путь к блочному устройству

mount | grep IMAGE_NAME | awk '{print $1}'
# результат: /dev/rbd0

проверяем размер фс в поде:

docker ps | grep POD_NAME
docker exec -ti CONTAINER_ID df -h | grep rbd

выполняем изменение размера:

resize2fs /dev/rbd0

проверяем результат:

docker exec -ti CONTAINER_ID df -h | grep rbd

З.Ы. тут написано без какой либо конкретики - просто направление того как с этим работать, поскольку методы получения нужной информации для ключевых шагов (имя образа, пода, rbd, ноды...) может отличаться от системы к системе. А уж проверять финальные результаты можно еще как минимум двумя способами. Строго говоря k8s тут вообще не причем =)

#kubernetes #ceph #rbd

ceph osd create

несколько заметок о проблемах при инициализации osd

1) отсутствует keyring - ceph-deploy считывает его из файлов /etc/ceph/ceph.client.bootstrap-osd.keyring,/etc/ceph/ceph.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin, а он лежит после копирования с помощью ceph-deploy admin в файле ceph.client.admin.keyring
как workaround - просто скопировать с тем именем с которым ищется
2) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 132: ordinal not in range(128)
обсуждение тут: https://tracker.ceph.com/issues/41609
я в свою очередь сильно не заморачивался и сделал как посоветовал человечек в середине обсуждения, поправив файл /usr/sbin/ceph-volume

#ceph #никогда_из_коробки

ceph enable msgr2

столкнулся с проблемой, что после включения согласно документации протокола msgr2, один из мониторов отказался его включать:

# ceph mon enable-msgr2
# ceph mon dump
.....
0: [v2:172.17.123.18:3300/0,v1:172.17.123.18:6789/0] mon.ceph-mon-0
1: [v2:172.17.123.19:3300/0,v1:172.17.123.19:6789/0] mon.ceph-mon-1
2: v1:172.17.123.20:6800/0 mon.ceph-mon-2

решил следующим способом:

# ceph mon set-addrs ceph-mon-2 [v2:172.17.123.20:3300/0,v1:172.17.123.20:6789/0]

после чего нужно ребутнуть сервис монитора на ноде и все станет ок

#ceph