Ошибка HPA в k8s

После развертывания CronJob в кластере kubernetes столкнулся с проблемой. Перестал работать Horisontal Pod Autoscaler.

Ошибка при этом была следующей:

horizontal-pod-autoscaler missing request for cpu

Есть даже issue на GitHub, которое до сих пор открыто. Но решается эта проблема добавлением лимитов в контейнер CronJob:

              resources:
                requests:
                  memory: "32Mi"
                  cpu: "100m"
                limits:
                  memory: "32Mi"
                  cpu: "100m"

В результате манифест CronJob из предыдущей заметки будет выглядеть так:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: test-restart
  namespace: test-ns
spec:
  concurrencyPolicy: Forbid
  schedule: '0 8 * * *' # cron spec of time, here, 8 o'clock
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 600
      template:
        spec:
          serviceAccountName: test-restart
          restartPolicy: Never
          containers:
            - name: kubectl
              image: bitnami/kubectl
              command:
                - 'kubectl'
                - 'rollout'
                - 'restart'
                - 'deployment/your-deployment-name'
              resources:
                requests:
                  memory: "32Mi"
                  cpu: "100m"
                limits:
                  memory: "32Mi"
                  cpu: "100m"

После этого HPA начинает работать нормально.

Периодический перезапуск pod'ов в k8s

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

Диспозиция

  1. Приложение надо периодически перезапускать
  2. Приложение задеплоено в kubernetes

Реализация

RBAC

Создаем сервисный аккаунт, роль и привязку:

---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: test-restart
  namespace: test-ns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-restart
  namespace: test-ns
rules:
  - apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    resourceNames: ["your-deployment-name"]
    verbs: ["get", "patch", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-restart
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: test-restart
subjects:
  - kind: ServiceAccount
    name: test-restart
    namespace: test-ns

CronJob

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: test-restart
  namespace: test-ns
spec:
  concurrencyPolicy: Forbid
  schedule: '0 8 * * *' # cron spec of time, here, 8 o'clock
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 600
      template:
        spec:
          serviceAccountName: test-restart
          restartPolicy: Never
          containers:
            - name: kubectl
              image: bitnami/kubectl
              command:
                - 'kubectl'
                - 'rollout'
                - 'restart'
                - 'deployment/your-deployment-name'

Не забудьте проверить и поменять все имена в этом шаблоне.

Далее применяем это и у вас будет кронджоба, которая будет по расписанию плавно перезапускать весь деплоймент. Такой метод оставляет доступным ваш сервис даже в момент рестарта.

NVM не может установить нужную версию NodeJS

В MacOS обнаружил, что Node Version Manager не может поставить нужную мне версию NodeJS. Как это было.

Ставлю NVM:

brew install nvm

И пытаюсь поставить ноду:

nvm install 12.16.1

Она начинает устанавливаться и падает с такой ошибкой:

nvm install 12.16.1
Downloading and installing node v12.16.1...
Downloading https://nodejs.org/dist/v12.16.1/node-v12.16.1-darwin-arm64.tar.xz...

curl: (22) The requested URL returned error: 404
Binary download from https://nodejs.org/dist/v12.16.1/node-v12.16.1-darwin-arm64.tar.xz failed, trying source.
grep: /Users/silver/.nvm/.cache/bin/node-v12.16.1-darwin-arm64/node-v12.16.1-darwin-arm64.tar.xz: No such file or directory
Provided file to checksum does not exist.
Binary download failed, trying source.
Clang v3.5+ detected! CC or CXX not specified, will use Clang as C/C++ compiler!
Local cache found: ${NVM_DIR}/.cache/src/node-v12.16.1/node-v12.16.1.tar.xz
Checksums match! Using existing downloaded archive ${NVM_DIR}/.cache/src/node-v12.16.1/node-v12.16.1.tar.xz
$>./configure --prefix=/Users/silver/.nvm/versions/node/v12.16.1 <
INFO: Using floating patch "tools/icu/patches/64/source/common/putil.cpp" from "tools/icu"
INFO: Using floating patch "tools/icu/patches/64/source/i18n/dtptngen.cpp" from "tools/icu"
No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.

No receipt for 'com.apple.pkg.DeveloperToolsCLILeo' found at '/'.

No receipt for 'com.apple.pkg.DeveloperToolsCLI' found at '/'.

gyp: No Xcode or CLT version detected!
Error running GYP
nvm: install v12.16.1 failed!

Т.е. не видит Command Line Tools для Xсode. Хотя они установлены и все было хорошо до этого. Решение проблемы банально - переустановить CLT:

xcode-select --print-path
sudo rm -rf $(xcode-select --print-path)
xcode-select --install

После этого у меня все завелось и полетело.

Как расширить root раздел под LVM

Для начала надо расширить сам раздел

growpart /dev/sda 3

Смотрим, что у нас получилось

fdisk -l

Если все прошло успешно, то увеличиваем место в физическом томе

pvresize /dev/sda3
pvdisplay

Дальше увеличиваем логический том

lvextend -l 100%FREE --resizefs /dev/ubuntu-vg/ubuntu-lv
vgdisplay

Иногда может понадобиться расширить файловую систему

resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Проверяем свободное место

df -h

Домашний сервер - продолжение

Обновился мой домашний сервер и пора бы уже рассказать, что изменилось по железу и софту, который задеплоен на него. Из Китая был заказан комплект мать + проц + память.

Железо

  • Процессор - Intel(R) Xeon(R) CPU E5-2689 0 @ 2.60GHz
  • Материнская плата - Kllisre X79
  • Операционная система установлена на SSD Intel 120GB
  • Хранилище - 3x3TB WD Blue/Red собранный в RAID-5
  • Память - 32ГБ

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

Изменения в софте

  • Добавлен minio в kubernetes
  • Добавлен plik для шаринга файлов в kubernetes
  • Добавлен paperless-ng в kubernetes
  • haproxy был заменен на MetalLB
  • piwigo был заменен на Photoprism
  • qbittorrent заменен на transmission
  • searx удален за ненадобностью. Просто не прижился

В итоге вышла достаточно мощная машинка, с хранилищем фотографий, возможностью делать бекапы в S3 хранилище и т.п.

Домашний сервер и его обитатели

Вероятно пора рассказать о своем домашнем сервачке, а то часто спрашивают как и что. Краткая версия этой заметки была в твиттере, тут же дам немного больше инфы и ссылок на то, как все устроено.

Железо

  • Процессор - Intel(R) Pentium(R) CPU G3260 @ 3.30GHz
  • Материнская плата - AsRock H81M-VG4 R4.0
  • Операционная система установлена на SSD Intel 120GB
  • Хранилище - 3x3TB WD Blue/Red собранный в RAID-5
  • Память - 16ГБ

Операционная система

В качестве операционки я использую на данный момент Ubuntu 18.04.4 с планом мигрировать на 20.04. Раньше была 16.04 и я переехал простым апгрейдом без особых проблем.

Софт, установленный прямо в системе

  • Minidlna раздает скачанное медиа на телевизоры (хотя в нем нет уже особого смысла, почти полностью его заменил Plex)
  • rsnapshot делает бэкапы удаленных серверов
  • haproxy выступает лоадбалансером для проброса портов в k8s
  • openvpn в качестве клиента для обхода некоторых блокировок

Итого по софту, установленному в системе: уже можно отказаться от minidlna и заменить haproxy на MetalLB. Останется только две простые утилиты и чистая система. Потом можно упаковать rsnapshot в docker и вообще будет огонь. Все остальное развернуто в docker или kubernetes.

Софт, развернутый с docker-compose

  • timecapsule для бэкапов маков
  • qbittorrent для автоматического скачивания торрентов
  • jackett для поиска по треккерам
  • radarr для отслеживания появившихся релизов и добавления в закачки
  • plex для просмотра сериальчиков и фильмов
  • zoneminder пишет видеопотоки с камер наблюдения на даче
  • несколько баз данных для проектов и тестов

Kubernetes

k8s развернут с помощью kubeadm этим способом. Список того, что там крутится:

  • несколько простых проектов
  • drone agent для DroneCI
  • librespeed для тестирования канала в интернет
  • piwigo для просмотра архива фоточек
  • registry для хранения образов билдов
  • smokeping для отслеживания состояния каналов связи
  • searx персональная поисковая система

Пока это все, что задеплоено. Но есть еще идеи, что добавить. Например, paperless-ng.

В планах обновить железо до AMD Ryzen и 32 гигов оперативки.

У сертификата AddTrust истек срок действия

30 мая истёк 20-летний срок действия корневого сертификата AddTrust, который применялся для формирования перекрёстной подписи (cross-signed) в сертификатах одного из крупнейших удостоверяющих центров Sectigo (Comodo). Перекрёстная подпись позволяла обеспечить совместимость с устаревшими устройствами, в хранилище корневых сертификатов которых не был добавлен новый корневой сертификат Sectigo.

В теории это не должно было привести к катастрофическим последствиям, но реальность оказалась жестокой. Очень многие сервисы перестали работать.

Что нужно сделать

На веб-серверах перевыпустите ваши сертификаты. С 90% долей вероятности вам будет выдан новый бандл с корректным сертификатом.

Для Ubuntu-сервер нужно сделать следующее:

$ sudo sed -i 's/mozilla\/AddTrust_External_Root.crt/\#\ mozilla\/AddTrust_External_Root.crt/' /etc/ca-certificates.conf 
$ sudo update-ca-certificates -v -f

После этого все начинает работать как положено.

Запускаем скрипт при старте и выключении Ubuntu

Довольно часто надо сделать так, чтоб при старте сервера запустился какой-либо скрипт. Это довольно просто и очень многие это знают. Просто добавляем запуск этого скрипта в /etc/rc.local и он будет запущен. Но что делать, если надо запустить скрипт при выключении сервера? Например, загрузить логи перед уничтожением облачного сервера.

Решение простое, если знаешь, как устроена система запуска Linux.

Надо всего-то положить скрипт в /etc/rc6.d.

Имя скрипта должно начинаться с K99 и дальше само имя.

Так же надо установить execute права на скрипт:

$ chmod +x /etc/rc6.d/K99example

При выключении этот скрипт отработает.

Расширяем раздел в EC2

Иногда, так случается, что надо расширить диск для какого-то EC2 инстанса. Это можно сделать не останавливая сам инстанс, чтоб не прерывать работу сервиса.

Для этого заходим в веб-консоль AWS, находим нужный volume и увеличиваем его размер.

Потом нужно увеличить раздел и саму файловую систему на этом разделе. Заходим по ssh на инстанс и расширяем раздел:

$ sudo growpart /dev/xvda 1

Получаем что-то типа:

CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=41940959,end=41943007

Теперь даем понять ядру, что надо перечитать новую таблицу разделов:

$ sudo partprobe

И расширяем файловую систему:

$ sudo resize2fs /dev/xvda1

Результат:

resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242619 (4k) blocks long.

on-line resizing required говорит о том, что файловая система была расширена.

Python3 на MacOS Catalina: фиксим «Abort trap»

Иногда на бетах MacOS Catalina ломается python3 и все, что с ним связано. Просто показывается ошибка «Abort trap: 6» и все. Тот же pip3 не запускается совсем.

Я довольно не мало перерыл статей в поисках причины и нашел, что это связано с библиотеками OpenSSL. Фикс довольно простой:

ln -s /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libcrypto.dylib /usr/local/lib/libcrypto.dylib
ln -s /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libssl.dylib /usr/local/lib/libssl.dylib

Эта заметка скорее для себя самого, чтоб не забыть, если оно опять сломается.