概要

2022年11月からRaspberrypiで稼働している「にりらみすきー部」ではユーザー数の急増から実用に耐えられなくなってきている為、Raspberrypiを増やしてKubernetes運用するぞ！という方向になりました。

Kubernetesを採用した理由として

・misskey.ioで使用されている情報が散見される
・Kubernetesに関連する情報が比較的存在する
・負荷分散で使用するときに定番なイメージ

が挙げられます。

今回はmisskeyの移行について記事を書いていきたいと思います。

あくまで参考としてご参照ください。
DBなどが関係するため、損害が発生した場合、筆者は責任を負いかねます。

前提条件

筆者はネットワーク経験が一切なく、仮想化についてもDockerをちょこっと開発に用いている程度で何もできません。
あと2023年の2月頭くらいにTwitterのFFの人がIX2215を買っているのを見て乗りでヤフオクで落札しました(6台届いた)。根元につないでいます。

ハードウェア

Raspberry pi 8GB ×4
Anker PowerPort 6
- https://www.amazon.co.jp/gp/product/B00PK27K5Q
電源ケーブル
- https://www.amazon.co.jp/gp/product/B01GGKYKQM
SSD
- silicon power
- KIOXIA
クラスタケース
LANケーブル https://www.amazon.co.jp/gp/product/B09MY5HVNM/
SATA to USB 3
- たくさんあるので変なものに注意！
- 私はこれを買いました
  - https://www.amazon.co.jp/gp/product/B08X6NCHF5
ラズパイケース
- https://www.amazon.co.jp/gp/product/B07TJ15YL1/

~~※なおMicroSDは使用しません。MicroSD+SSDの場合一部手順が不要になるかも...?~~
➡私の環境では出来ませんでした。ただ、簡単にしかしていないのでもしかしたら出来るかもしれません。

環境構築～前提及びOS編～

まずRaspberrypiにOSをインストールしていきます。
例のごとくRaspberry Pi ImagerをWindows上にインストールします。

Raspberry piにOSをインストールしていくわけですが、ここで重要なのがOSはUbuntuを選ぶです。

いろいろ流派がありますが、今回はRaspberry Pi OSではなくUbuntuです。
Ubuntu選択の理由としては後ほどインストールする「Rook / Ceph」と呼ばれるストレージ関連の構築を行うソフトウェアがRaspberry Piだとインストールできないからですね...

Rook/Cephとは何ぞやという人はこの記事のRook/Cephセクションまで読み飛ばして確認してみてください。

という事で買ったSSDをパソコンに接続してRaspberry Pi Imagerで最低限パスワードやローカルドメイン(なおsshアクセスでは使えない模様)を設定したりした後にインターネットへ接続！電源投入！

ルーターや何らかのソフトウェアでRaspberry PiのIPを確認します。

とりあえず全台にUbuntuを入れます。
インストール終了後、次のステップに進みます。

Ubuntu 環境構築

まずはパーティションの設定をします。
Rook / Cephでは前提条件として以下の4つのいずれかに当てはまらなければいけません。

・Raw devices (no partitions or formatted filesystems)
・Raw partitions (no formatted filesystem)
・LVM Logical Volumes (no formatted filesystem)
・Persistent Volumes available from a storage class in block mode

要は何もないパーティションとか必要ってことですね！

ちなみにMicroSD+SSDの方はフォーマットされていないSSDがあれば特段この手順はいらないはず...?
現在昔稼働していたRaspberrypiを新たに追加する予定なので確認次第追記します。

追記

実施した結果上手く稼働できなかったため、SSDにたいしてOSのインストールを行いました。

SSDのパーティション作成

以下の記事を参考にさせていただきました！

ということでやっていきます。
前述のとおり、Raspberry pi にはmicroSDは刺さっていないので、ほかのRaspberry pi にSSDを差し込んでフォーマットします。

以下にコマンドを記載しておきます。
ファイルが消える可能性があります！！！！
あくまで自己責任で実行してください

出力については一部省略しています。

// コマンドまとめ
$ lsblk -f
$ sudo e2fsck -f /dev/sdb2
$ sudo resize2fs /dev/sdb2 75G
$ sudo fdisk /dev/sdb
Command (m for help): p
Command (m for help): d
Partition number (1,2, default 2): 2
Command (m for help): n
Select (default p): p
Partition number (2-4, default 2):
First sector (526336-500118191, default 526336):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (526336-500118191, default 500118191): +75G
Do you want to remove the signature? [Y]es/[N]o: y
Command (m for help): w

$ sudo partprobe
$ sudo e2fsck -f /dev/sdb2
$ sudo fdisk /dev/sdb
Command (m for help): n
Select (default p):
Using default response p.
Partition number (3,4, default 3):
First sector (157812736-500118191, default 157812736): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (157812736-500118191, default 500118191): 
Command (m for help): t
Partition number (1-3, default 3): 3
Hex code or alias (type L to list all): 8e
Command (m for help):w

$ sudo partprobe
$ sudo fdisk -l /dev/sdb

// 接続デバイスを確認
$ lsblk -f
NAME   FSTYPE   FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squashfs 4.0                                                          0   100% /snap/core20/1856    
loop1  squashfs 4.0                                                          0   100% /snap/lxd/24326      
loop2  squashfs 4.0                                                          0   100% /snap/snapd/18363    
loop3  squashfs 4.0                                                          0   100% /snap/snapd/18600    
loop4  squashfs 4.0                                                          0   100% /snap/core20/1826
// OSが入っているSSD (既にフォーマットしているので表示される内容が異なると思います)
sda
├─sda1 vfat     FAT32 system-boot B1C2-332F                             178.6M    29% /boot/firmware       
├─sda2 ext4     1.0   writable    3b687fda-fd50-40d7-9407-5f6103485cda   68.2G     3% /
└─sda3
// フォーマット対象のSSD
sdb
├─sdb1 vfat     FAT32 system-boot B1C2-332F
└─sdb2 ext4     1.0   writable    3b687fda-fd50-40d7-9407-5f6103485cda

// sdb2を対象に行います。
// ファイルシステムチェック 途中何か聞かれるので対応します。(私はとりあえずyにしました)
$ sudo e2fsck -f /dev/sdb2

// 75GBにリサイズします。サイズは適当です。
$ sudo resize2fs /dev/sdb2 75G
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/sdb2 to 19660800 (4k) blocks.
The filesystem on /dev/sdb2 is now 19660800 (4k) blocks long.

// fdiskでsdbのパーティション編集画面に入ります
$ sudo fdisk /dev/sdb

// pでパーティションの情報を表示
Command (m for help): p
Device     Boot  Start       End   Sectors   Size Id Type
/dev/sdb1  *      2048    526335    524288   256M  c W95 FAT32 (LBA)
/dev/sdb2       526336 500118158 499591823 238.2G 83 Linux

// パーティションの削除 /dev/sdb2/
Command (m for help): d
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Command (m for help): n
Select (default p): p
// enter押すだけ
Partition number (2-4, default 2):
First sector (526336-500118191, default 526336):
// 75GB
Last sector, +/-sectors or +/-size{K,M,G,T,P} (526336-500118191, default 500118191): +75G

Created a new partition 2 of type 'Linux' and of size 75 GiB.
Partition #2 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: y

The signature will be removed by a write command.
// 保存して終了
Command (m for help): w

$ sudo partprobe

// ファイルチェック
$ sudo e2fsck -f /dev/sdb2

// またfdiskで入る
$ sudo fdisk /dev/sdb

// 残りの要領でLVMのパーティションを作ります
Command (m for help): n

// 全部default
Select (default p):
Using default response p.
Partition number (3,4, default 3):
First sector (157812736-500118191, default 157812736): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (157812736-500118191, default 500118191): 

Created a new partition 3 of type 'Linux' and of size 163.2 GiB.

// パーティション種別変更
Command (m for help): t
Partition number (1-3, default 3): 3
// 8e: Linux LVMを指定 (変更されている可能性もある為、「L」で確認を行ってください)
Hex code or alias (type L to list all): 8e
Changed type of partition 'Linux' to 'Linux LVM'.

Command (m for help):w

$ sudo partprobe
$ sudo fdisk -l /dev/sdb
Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *         2048    526335    524288   256M  c W95 FAT32 (LBA)
/dev/sdb2          526336 157812735 157286400    75G 83 Linux
/dev/sdb3       157812736 500118191 342305456 163.2G 8e Linux LVM

いい感じですね。これをすべてのデバイスに行います。
各Raspberry piにSSDを接続後にパーティションが反映されているか確認します。

$ sudo fdisk -l /dev/sda
Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048    526335    524288   256M  c W95 FAT32 (LBA)
/dev/sda2          526336 157812735 157286400    75G 83 Linux
/dev/sda3       157812736 500118191 342305456 163.2G 8e Linux LVM

続いてKubernetesを導入していきます。

Kubernetes導入

Kubernetesの情報が様々ありますが、比較的年代が古いものから新しいものが存在しています。
その結果記事毎に書いてある内容が違う？！という事が多々あり、よくわからなくなりました。
本記事ではGoogle検索より直近の物を選択し、使用させていただきました。

~~環境構築についてはこのままなので割愛します！~~
色々進めていったらそうはいかなくなったのでこちらに記載しておきます。
こちらのkubernetesの記事をもとに環境構築を行います。

多少階層が違うので読み替えて行います。

私の場合はスワップは最初から無効になっているみたいだったので省略しました。

バージョンは以下の通りです。

kubernetes 1.25.1

// 更新
$ sudo apt update
$ sudo apt dist-upgrade

// raspberry pi osでは動かない
$ sudo apt install linux-modules-extra-raspi

// reboot
$ sudo reboot

//cmdline.txtの編集
$ sudo nano /boot/firmware/cmdline.txt

--- // 末尾に追記
cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1
---

// rebootで反映
$ sudo reboot

稀に「 missing optional cgroups: blkio」とかで起動に失敗するので、そういう時はcmdlineについて再度確認しておくといい感じになると思います。

ということで起動後に各nodeをつなげてあげてRook/Cephの環境を構築します。

ここでIPの固定もしてあげます。

参考：

$ cd /etc/netplan/
$ sudo cp 50-cloud-init.yaml 54-cloud-init.yaml
$ sudo mv 50-cloud-init.yaml default.yaml.disable
$ sudo nano 54-cloud-init.yaml
$ sudo netplan apply

54-cloud-init.yaml

network:
    ethernets:
        eth0:
            addresses: [192.168.13.20/24]
            routes:
              - to: default
                via: 192.168.13.1
            nameservers:
                addresses: [192.168.13.1] 
            optional: true
    version: 2

Rook / Ceph構築

ここまで来たらあとは公式ページ通りに構築します！

前提は既にパーティションを区切って満たしている為、そのまま実行できると思います。

// 念のためコマンドを示しますが、今後変更の可能性もあるため、公式ページを見て構築する事をお勧めします。
$ git clone --single-branch --branch v1.11.2 https://github.com/rook/rook.git
$ cd rook/deploy/examples
// create operator...
$ kubectl create -f crds.yaml -f common.yaml -f operator.yaml
// check
$ kubectl -n rook-ceph get pod -w
NAME                                 READY   STATUS              RESTARTS   AGE
rook-ceph-operator-c489cccb5-5jvnb   0/1     ContainerCreating   0          52s
rook-ceph-operator-c489cccb5-5jvnb   1/1     Running   

// OperatorがRunningになったら実行
$ kubectl create -f cluster.yaml
// しばらく待つ...


$ kubectl -n rook-ceph get pod
NAME                                                  READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-5rrxb                                2/2     Running     0          6m
csi-cephfsplugin-7bnn7                                2/2     Running     0          5m59s
csi-cephfsplugin-provisioner-9f7449fc9-27v2j          5/5     Running     0          5m59s
csi-cephfsplugin-provisioner-9f7449fc9-64lgr          5/5     Running     0          5m59s
csi-cephfsplugin-snvxl                                2/2     Running     0          5m59s
csi-rbdplugin-b9hcx                                   2/2     Running     0          6m
csi-rbdplugin-bhspk                                   2/2     Running     0          6m
csi-rbdplugin-nrm8z                                   2/2     Running     0          6m
csi-rbdplugin-provisioner-649c57b978-6rjw9            5/5     Running     0          6m
csi-rbdplugin-provisioner-649c57b978-mvdpx            5/5     Running     0          6m
rook-ceph-crashcollector-nirilab02-59c867c6c-7fns8    1/1     Running     0          4m3s
rook-ceph-crashcollector-nirilab03-5c64555858-695sk   1/1     Running     0          3m29s
rook-ceph-crashcollector-nirilab04-cbf6f5ff7-5l59z    1/1     Running     0          2m50s
rook-ceph-mgr-a-6558d694f9-knhxs                      3/3     Running     0          4m14s
rook-ceph-mgr-b-7ff7c7ff56-9wdgf                      3/3     Running     0          4m13s
rook-ceph-mon-a-6dbb575c59-8nhmk                      2/2     Running     0          6m4s
rook-ceph-mon-b-6747ccf947-9crz5                      2/2     Running     0          5m34s
rook-ceph-mon-c-bf984fb49-m8sx4                       2/2     Running     0          4m43s
rook-ceph-operator-c489cccb5-5jvnb                    1/1     Running     0          10m
rook-ceph-osd-0-7bf9bfcb79-zdrqd                      2/2     Running     0          3m32s
rook-ceph-osd-1-766bdddf4-m6vcg                       2/2     Running     0          3m29s
rook-ceph-osd-2-5d49cf6d55-dtkdm                      2/2     Running     0          2m50s
rook-ceph-osd-prepare-nirilab02-vzb7v                 0/1     Completed   0          3m48s
rook-ceph-osd-prepare-nirilab03-2tp6h                 0/1     Completed   0          3m48s
rook-ceph-osd-prepare-nirilab04-2d9wg                 0/1     Completed   0          3m48s

ここまで簡単にいくとあの時間は何だったんだってなりますね...

ツールもインストールしてみます。

$ kubectl create -f deploy/examples/toolbox.yaml
$ kubectl -n rook-ceph rollout status deploy/rook-ceph-tools
$ kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
// bashでstatus確認
bash-4.4$ ceph status
  cluster:
    id:     c2b40178-2a5d-420d-899e-70666c854e5d
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum a,b,c (age 19m)
    mgr: b(active, since 16m), standbys: a
    osd: 3 osds: 3 up (since 17m), 3 in (since 17m)
 
  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 705 KiB
    usage:   67 MiB used, 490 GiB / 490 GiB avail
    pgs:     1 active+clean

health: HEALTH_OKで終わりです！

metalbのインストール

オンプレ環境なのでLoadBalancerを使えるように

よくわからないですがこちらを参考に以下のコマンドをworkerで実行しました。
よくよくみたらページの下のほうにhelmがあったのでそちらを使えばよかった...

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.9/config/manifests/metallb-native.yaml

applyしてしまったものを元に戻すのは面倒そうなのでそのままconfigを書いて適用します。

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.13.200-192.168.13.250

内容については公式ページのL2レイヤを参考にしました

レイヤーってなんぞや

L2、L7などなんか聞いたことあるけど一体どれを指しているのかと調べてみたらOSI参照モデルの七階層のことを指していたんですね。

なので今回はデータリンク層でのロードバランサの設定という事になります。

引っかかったところ

Metallbを適当に設定後に案の定workerノードにアクセスできなくなる問題が発生して再インストールしたのですが、ワーカー以外のノードでkubeadm resetを実行してもクラスタにjoinできませんでした。
- 原因は権限的な問題で完全にリセットできていないだけだったのでsudoを付け足してリセットした後にjoinしたら動きました。

helmのインストール

helmはパッケージをインストールする際に簡単に操作できるパッケージマネージャー的なものです。便利。

インストールは公式の自動インストーラーを使用しました。

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Ingress, Ingressコントローラーのインストール

クラスタ内サービスへの外部アクセスを管理するAPI オブジェクトとのこと。別途コントローラが必要なのでNGINXが元のIngressコントローラーをインストールします。

正直よくわからないのですが、L7(アプリケーション層)でのロードバランシングを提供するとのこと。

とりあえず以下のURL先の文書を呼んで構築してみます。

ここでhelmの出番という事で早速ドキュメント通りに以下のコマンドを実行。

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

ちょっと時間がかかるのでドキドキします。
インストール後に以下のようなメッセージが。

Release "ingress-nginx" does not exist. Installing it now.
NAME: ingress-nginx
LAST DEPLOYED: Mon Mar 20 08:22:57 2023
NAMESPACE: ingress-nginx
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace ingress-nginx get services -o wide -w ingress-nginx-controller'

An example Ingress that makes use of the controller:
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 80
              path: /
    # This section is only required if TLS is to be enabled for the Ingress
    tls:
      - hosts:
        - www.example.com
        secretName: example-tls

If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
    tls.crt: <base64 encoded cert>
    tls.key: <base64 encoded key>
  type: kubernetes.io/tls

コンフィグについて出力してくれました。親切ですね。

起動中のpodの確認

以下のコマンドを実行して起動中のPodを確認してみます。

kubectl get pod -A

helmとngix-controllerを使ってサービスを公開して動作確認をしてみる

helmとnginx-controllerのそれぞれの機能については分かりました。
しかしそれぞれが組み合わさった時にどのようにインストールするのかよくわからなかったので実際に動かして確認してみます。

Giteaの公開

githubライクなgitソフトのGiteaを使用して構築してみます。
必要がない方は次のセクションへ。
ちなみになぜGitlabではなくGiteaかというと、別件のチーム開発でGithubではなく他のローカルGitホストを使うという話が持ち上がり、チームメンバーがGiteaに詳しかったからですね。
調べてみたところhelm用のpackageが存在するらしいのでそちらを利用します。

Installation with Helm (on Kubernetes)に書いてある通り実行してもいいのですが、Ingress nginx-controllerとの組み合わせがよくわからなかったのでhelm pull gitea-charts/giteaを使用してローカルに圧縮ファイルをダウンロードします。
その後解凍を行って内部ファイルを見てみます。

tar xvzf gitea-<任意のバージョン>
cd gitea/
tree -L 2 . (command not foundなど言われる場合はapt install treeなどしてあげてください)
.
├── Chart.lock
├── charts
│   ├── mariadb
│   ├── memcached
│   ├── mysql
│   └── postgresql
├── Chart.yaml
├── LICENSE
├── README.md
├── templates
│   ├── gitea
│   ├── _helpers.tpl
│   ├── NOTES.txt
│   └── tests
└── values.yaml

helmのファイル構造についてよくわからなかったため以下を参考にしました。

上記によると

templatesディレクトリ内にはDeploymentを使ってコンテナをデプロイしたり、ルーティングを行うためのServiceリソースを定義したり、外部からサービスにアクセスするためのIngressリソースを定義するための設定ファイルが一通り用意されている。これらはパラメータ設定ファイル（values.yaml）内で定義されているパラメータを参照するようになっており、シンプルなサービスであればこのvalues.yamlファイルを編集するだけで動作するChartが完成する。

「事実上の標準ツールとなっているKubernetes向けデプロイツール「Helm」入門」より引用

との事。という事でvalues.yamlを編集してingress-nginxと接続してみます。

今回httpsで接続してほしいので公式ページを参考に設定してみます。

Automated Certificate Management with cert-managerセクションの所にLet's Encryptを用いた自動証明書発行のための記述があるので、その設定をそのまま記述します。
ついでにgiteaのadminに関する部分も編集します。

# Replace this with a production issuer once you've tested it
# (テストが終わったら本番環境用に置き換える by deepl)

なんかちょっと怖いこと書いてありますけど証明書はこのままです...!

結果ingressの部分はこんな感じに

ingress:
  enabled: true
  # className: nginx
  className: nginx
  annotations: 
    cert-manager.io/issuer: "letsencrypt-staging"
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: git.example.com
      paths:
        - path: /
          pathType: Prefix
  tls: 
   - hosts:
       -  git.example.com
     secretName: git.example.com

...

gitea:
  admin:
    #existingSecret: gitea-admin-secret
    existingSecret:
    username: tekisetuna_name
    password: pasuwadodayo
    email: "hoge@hoehoge"

git.example.comは適時自身のドメインに置き換えてください。またgiteaのadminの設定は適切に設定してあげてください。

あらかじめ書いておくと、この設定では動かないので次のセクションで更に変更します！！！！

起動

以下のコマンドで起動します。

helm install gitea .

エラー発生

エラーが発生して永遠に起動できなくなったのでログを解析してみたところ、PVCなるものが必要とのこと。

Podは一時的な物で消したらデータも消えるのですが、消えてほしくないデータが存在する場合にPVCなるものを利用するとのこと。

今回は一切設定をしていなかったので、いろいろ調べてみます。
調べたところ「Rook/Ceph」を利用した永続化が簡単そうでしたのでそちらを利用します。
(これは一か月前の私のコメントです。本来であればKubernetesの再構築がこの後に来てました。)
(既にみなさんはRook/Cephをインストールするための環境は整っています。)

Rook/Cephインストール(Old)

(このセクション前半は後からインストールする人(いるかわかりませんが)の為に残しておきます。)
(既にUbuntuをインストールしている方は次のセクションへ進んでください。)

公式ドキュメントよりインストールしてみます。

がエラーが発生。

Still connect to...が大量に発生。

どうやらmodprobeというモジュールが必要とのこと。
インストールします。が、

前提に戻っちゃいますが、「rbd」というkernelモジュールが必要です。
そして、Raspberry Pi OS 64bit(Beta)ではそもそも「rbd」モジュールがコンパイルされていません。
つまり、kernelのコンパイルをしなければなりません。

なんだってー！公式ページも確認したら同様に書いてありました。

ということで記事のKernelビルド編よりお借りしてコンパイルとインストールしました。が、ここで問題が発生。

カーネルをビルドしてもrbdカーネルが含まれていない...!

module rbd not found in directory /lib/modules/<ver>

この辺りを4日くらいずっと探していたのですが、同じ状況にあるものの具体的な解決策がなく諦め。
どうしようもないのでOSの問題もあるのかと思い、Ubuntu系で調べてみたらそれらしきコマンドがありました。
なのでOS毎変えてしまおうとMasterをUbuntuに変更。
以下環境構築を行います。

（ここで前述のUbuntuをインストールにつながるんですね。ちなみにRaspberry Pi OSでした。）

Rook/Cephインストール new

基本的に公式ドキュメント通りで動くと思います。

StorageClassの設定

インストール時にgitをCloneしたと思いますが、その中のフォルダにExampleがあるのでそちらを利用します。

rook$ cd deploy/examples/csi/rbd/

rook/deploy/examples/csi/rbd/$ kubectl apply -f storageclass.yaml

これでPVCを用意する準備が整いました。

Giteaのインストール(再)

という事で前述のとおり、再度設定します。
PVCの利用のために一部ファイルを変更しました。

value.yaml

# Persistanceのみ
persistence:
  enabled: true
#  existingClaim:
  size: 10Gi
  accessModes:
    - ReadWriteOnce
  labels: {}
  annotations: {}
  storageClass: rook-ceph-block

そして起動してみたらなぜかgitea-0が動かない...!

:~/Programs/gitea$ kubectl get pod 
NAME                               READY   STATUS                  RESTARTS        AGE
gitea-0                            0/1     Init:CrashLoopBackOff   6 (3m15s ago)   10m
gitea-memcached-6d5b5d4bfd-lfpfh   1/1     Running                 0               10m
gitea-postgresql-0                 1/1     Running                 0               10m
:~/Programs/gitea$ kubectl logs gitea-0 -c configure-gitea 
==== BEGIN GITEA CONFIGURATION ====
2023/04/04 05:03:07 cmd/migrate.go:33:runMigrate() [I] AppPath: /usr/local/bin/gitea
2023/04/04 05:03:07 cmd/migrate.go:34:runMigrate() [I] AppWorkPath: /data
2023/04/04 05:03:07 cmd/migrate.go:35:runMigrate() [I] Custom path: /data/gitea
2023/04/04 05:03:07 cmd/migrate.go:36:runMigrate() [I] Log path: /data/log
2023/04/04 05:03:07 cmd/migrate.go:37:runMigrate() [I] Configuration file: /data/gitea/conf/app.ini
2023/04/04 05:03:07 .../cli@v1.22.10/app.go:277:Run() [I] PING DATABASE postgres
2023/04/04 05:03:12 cmd/migrate.go:40:runMigrate() [F] Failed to initialize ORM engine: dial tcp: lookup gitea-postgresql.default.svc.cluster.local: Try again
Gitea migrate might fail due to database connection...This init-container will try again in a few seconds

なぜかpostgresqlにアクセスできないという問題が発生。

調べてみるとこんなものが。

あんまり関係なさそうですが、とりあえず試してみることに。

こちらに書いてあるとおりにvalues.yamlに追記します。

values.yaml

// ctrl+wで検索して追記
dnsConfig:
  options:
    - name: ndots
      value: "1"

これで何回か実行したのですが治らず...

ダメ元でRaspberry Pi を再起動したら上手くいきました！！！どういうこと？！

:~/Programs/gitea$ kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
gitea-0                            1/1     Running   0          37m
gitea-memcached-6d5b5d4bfd-lfpfh   1/1     Running   0          37m
gitea-postgresql-0                 1/1     Running   0          37m

curl -H "Host: git.example.com" 192.168.13.20

これを打って、それっぽいのが出て来たので大丈夫そう。

sshを外部公開する (動作未確認)

※CloudFlareを使用する為、私の環境では動作確認を行っていません。あくまで参考という事で...

Ingress-nginxにssh接続できるように設定します。

Ingressのmanifestをコピー

helm get manifest  ingress-nginx  -n ingress-nginx > custom-values.yaml

以下の記事のように編集

既にingressはInstallされているので以下のコマンドを打って適用します。

helm upgrade ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx -f custom-values.yaml

なお、helmでインストールした際にrepoを直接指定している為ingress-nginxがないといわれます。
その際以下のコマンドでrepoを追加してあげました。

helm repo add ingress-nginx  https://kubernetes.github.io/ingress-nginx

Upgraede後のREVISIONが2となっていたので無事適用されたと思います。

misskeyを構築する

DBの構築 : Postgresql

Misskeyではpostgresqlが使われていますが、これを踏襲する形で実行していきたいと思います。

折角Kubernetesを使用するのでDBもいい感じにしたい！
という事で色々調べてみるとPostgresql operatorなるものが存在するとのこと。

詳しい内容については割愛しますが、いい感じになりそうです。

HA クラスタとは

調べてみるとたびたび出てくる「HAクラスタ」ですが、どうやら上記であるとの事。

ただちょっと調べてみるとPGPool-Ⅱなるものも発見。

Misskey.ioはこちらを使っているみたい。

Operatorと組み合わせて運用できるのか調べてみたところ出来そうな予感。

という事でZalandoのPostgresql Operatorを使ってみます。と思っていたのですが、どうやらARM系は対応してなさそうな雰囲気があるためCloudNativePGを使用します。

(Issueなどを探したところRepositoryがARMなどのマルチプラットフォームに対応してない...らしい? Pull-reqなどもありますがCloseされているなど、現状公式でのサポートされているのを見つけられませんでした。2023年6月)

CloudNativePGとは

CloudNativePGとはKubernetes上でPostgresqlのクラスターを作成し、始まりから終わりまで全体のライフサイクルを管理してくれるKubernetesのOperatorです。

microk8sなどでも使用できます。

基本的な設定が可能な点とバックアップやリカバリが簡単に設定できます！

構築

こちらに書いてある通りに実行します。

versionは以下の通り。

cloudnative-pg 1.19.1

2025年10月時点でv1.27.1まで出ています。

$ kubectl apply -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.19/releases/cnpg-1.19.1.yaml

$ kubectl get deploy -n cnpg-system cnpg-controller-manager
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cnpg-controller-manager   1/1     1            1           85m

以下のconfigについて、ドキュメントを元に記載していますが、不十分な可能性がありますので注意して使用してください。

幾つかの設定が組み合わさりreplicaの起動やpostgresの設定が反映されるのでドキュメントを確認してください。
2025年現在の設定にアップデート

pg-cluster.yaml

# postgresql cluster
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: misskey-postgres-cluster
spec:
  instances: 1 # 起動するinstance数。
  primaryUpdateStrategy: unsupervised
  imageName: ghcr.io/cloudnative-pg/postgresql:15

  storage:
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      storageClassName: rook-ceph-block # storageClassを自身の合ったものに変更する
      resources:
        requests:
          storage: 70Gi

  # ここでPostgresqlの設定
  postgresql:
    #synchronous: # instancesを1にする場合は削除する。replica設定 https://cloudnative-pg.io/documentation/1.27/replication/#synchronous-replication
    #  method: any
    #  number: 1
    #  dataDurability: required
    
    pg_hba:
      - host all all all password
    parameters: 
      # 任意で調整
      max_connections: "128"
      shared_buffers: "4GB"
      effective_cache_size: "8GB"
      maintenance_work_mem: "1024MB"
      checkpoint_completion_target: "0.8"
      wal_buffers: "16MB"
      wal_keep_size: "1024MB"
      default_statistics_target: "100"
      random_page_cost: "1.1"
      effective_io_concurrency: "300"
      work_mem: "16MB"
      min_wal_size: "2GB"
      max_wal_size: "8GB"
      checkpoint_timeout: "15min"
      max_worker_processes: "8"
      max_parallel_workers_per_gather: "4"
      max_parallel_workers: "8"
      max_parallel_maintenance_workers: "4"
      wal_compression: "on"

  # superUserのパスワードとIDを設定 Userは固定されていたはずなのでconfigを確認してください(後述)
  superuserSecret: 
    name: postgres-superuser-secret

  # 起動時の設定
  bootstrap:
    initdb:
      database: misskey # misskeyのコンフィグとの対応を確認する
      owner: misskey # misskeyのコンフィグとの対応を確認する
      secret:
        name: postgres-local-user-secret # 上記ownerのパスワードについて。kubernetesの公式を参照

  # backupの構築
  backup:
    barmanObjectStore:
      destinationPath: "s3://misskey-backup/backup/" # ストレージ内の階層
      endpointURL: "" # 各クラウドのエンドポイント
      
      # S3のパスワード設定。これはKubernetesのsecretを利用している。
      # https://kubernetes.io/ja/docs/concepts/configuration/secret/
      s3Credentials:
        accessKeyId:
          name: creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: creds
          key: ACCESS_SECRET_KEY
      wal:
        compression: gzip
    retentionPolicy: "30d" # 30日で削除

  # Prometheusを使用する場合に設定。CloudNativePGの設定ページに記載されているので参照。本サービスでは紹介しません。
  monitoring:
    enablePodMonitor: true
---
# backupサイクル設定 CloudNativePGのページを参照
# https://cloudnative-pg.io/documentation/1.16/backup_recovery/
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *" # goの時間表記だった気がする...
  backupOwnerReference: self
  cluster:
    name: misskey-postgres-cluster # ここはClusterの方のmetadata.nameを設定する

superuserについては別途configを作成し設定します

pg-superuser.yaml

apiVersion: v1
kind: Secret
metadata:
  name: postgres-superuser-secret
type: kubernetes.io/basic-auth
data:
  username: # required field for kubernetes.io/basic-auth (base64でのエンコードが必要)
  password: # required field for kubernetes.io/basic-auth (base64でのエンコードが必要)

なお、念のため1つでの起動としています。

$ kubectl apply -f pg-superuser.yaml 
$ kubectl apply -f pg-cluster.yaml 
$ kubectl get all
NAME                             READY   STATUS    RESTARTS   AGE
pod/misskey-postgres-cluster-1   1/1     Running   0          5m53s
pod/misskey-postgres-cluster-2   1/1     Running   0          4m29s
pod/misskey-postgres-cluster-3   1/1     Running   0          3m14s

NAME                                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/kubernetes                     ClusterIP   10.96.0.1       <none>        443/TCP    3d23h
service/misskey-postgres-cluster-any   ClusterIP   10.102.53.251   <none>        5432/TCP   6m27s
service/misskey-postgres-cluster-r     ClusterIP   10.99.36.216    <none>        5432/TCP   6m26s
service/misskey-postgres-cluster-ro    ClusterIP   10.110.27.45    <none>        5432/TCP   6m26s
service/misskey-postgres-cluster-rw    ClusterIP   10.98.194.46    <none>        5432/TCP   6m26s

デプロイされたサービスのsuffixは以下の通り

rw: primaryからのread/write
ro: replicaからの読み取りonly
r : いずれかのインスタンスから読み取り

とりあえず動いたので設定をしていきます。

実は既にmisskey.niri.laにて動いているPostgreSQLからデータを持ってこようとして.sqlファイルを指定しようとしたのですが、どうやらReferenceを見てみたところCloudNativePGは外部のPostgresqlに直接アクセスしてPG_dumpを実行するようで、既に出力したsqlファイルは受け付けてくれないようです。
流石にDocker内にあるPostgresqlを公開してさらにアクセスするのはそれはそれで面倒なので、一旦起動してからデータを突っ込みます。

2025年10月現在ではpg_dumpを利用したリストアが可能です。
https://cloudnative-pg.io/documentation/1.27/troubleshooting/#emergency-backup

# -Uではpostgresを指定してあげないと権限エラーで色々言われました。-dは使用していたmisskeyのデータベース名を設定してください。
cat backup.sql | kubectl exec -i misskey-postgres-cluster-1 -- psql -U postgres -d misskey

PGPoolインストール

PGPool-2を使っているMisskey.ioが4/9あたりのメンテナンスで直接レプリケーションを行う方式に変更したとのことでPGPool-2の使用は中止しました。

Misskey本体

ついにMisskey本体側に入ります。

移行するために色々調べていたところ、つい最近KubernetesでMisskeyを起動していた方がいらっしゃいました。

こちらで使用していた設定を元に色々設定を変更します。
こちらの記事ではストレージにRook/Cephは使用していないため、こちらの記述を削除しつつRook/Cephに対応させます。

例の如くMisskeyの設定についてはGithubにアップロードしてありますので適時参照ください。

Misskeyに必要な設定ファイルですが、Dockerでの例で使用している.config内のdocker_example.yamlが必要です。
これをどうにかしてMisskeyのPVCにマウントします。
マウントにはConfigMapが有効そうでしたのでこちらを使います。

config-misskey-default.yaml

# 基本的に内容については同じなのでgithubを参照してください。
apiVersion: v1
data:
  default.yml: |-
    ...

    db:
      host: <service-name>.<namespace-name>.svc.cluster.local
      port: 5432

      # Database name
      db: misskey

      # Auth
      user: example-misskey-user # ここは先ほどImportしたデータベースのユーザーを指定してください
      pass: example-misskey-pass # ここは先ほどImportしたデータベース名を指定してください
   ...

kind: ConfigMap
metadata:
  name: misskey-default-config

適用します。

$　kubectl apply -f niril/config/config-misskey-default.yaml -n misskey

Kubernetes側が見つけられない為、ネームスペースは後述のyaml関連と同じものにしてください。
今回はnamespaceを設定せずに保存してしまいましたが、configのmetadataで設定するのが忘れなくていいと思います。

次にMisskey及びRedisの設定構築をします。
各Yamlについては以下のようになります。基本的にgithubに載せてあります。

stateful-web.yaml

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: misskey
spec:
#  type: ClusterIP
  selector:
    app: web #-deployment ここで名前解決できずに失敗したので名前を変更する際は気を付けてください。
  clusterIP: None
  ports:
  - name: http
    port: 80
    targetPort: 3000

---

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: web-deployment
  namespace: misskey
  labels:
    deploy: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: # ここは私のGithub上のmisskeyのパッケージを指定しました。
        imagePullPolicy: Always
        volumeMounts:
        - mountPath: /misskey/files
          name: misskey-files
        - mountPath: /misskey/.config
          name: misskey-default-conf-file
        ports:
        - containerPort: 3000

        # Podの準備が出来ているか確認用
        readinessProbe:
          httpGet:
            path: /
            port: 3000
            scheme: HTTP
      volumes:
      - name: misskey-default-conf-file
        configMap:
          name: misskey-default-config
  volumeClaimTemplates:
  - metadata:
      name: misskey-files
      namespace: misskey
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: rook-ceph-block # 自身で設定した名前 
      resources:
        requests:
          storage: 5Gi

---
# ingress の設定
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: misskey
  annotations:
     nginx.ingress.kubernetes.io/proxy-body-size: 200m

spec:
  ingressClassName: nginx
  rules:
    - host: misskey.example.com # 任意のホスト (configと同じにしたほうが良いと思われ)
      http:
        paths:
          - pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80
            path: /

redisについては基本参考記事とほとんど同じの為、githubを参考にしてください。
なお、起動前に次セクションのRedis移行を確認した後に以下コマンドを実行してください。

この状態で起動を行います。

# 最初にredisを起動
$ kubectl apply -f redis.yaml
# misskeyを起動
$ kubectl apply -f stateful-web.yaml

Redis移行 (失敗)

Redisのデータを一切移行せずに起動したら通知が全部消えたので移行しようとしました。
ただどうしてもデータベースの適用が出来なかった点と、v13.11.xにアップデートすると強制的に通知が消えてしまうそうでしたので消し飛ばしました。

※通知およびアンテナのデータも消えるため、現在のサーバー人数やアンテナ使用人数を加味して決定してください。

原因

使用しているRedisをbitnamiのリポジトリに移行した後、backupで出てきたrbdを適用してあげると上手く復元することが出来ました。

ここでは省略させていただきます。

動作確認

コマンドを実行して確認します。

$ kubectl get pod -n misskey
NAME                                       READY   STATUS    RESTARTS        AGE
redis                                      1/1     Running   0               2d1h
wasabi-proxy-deployment-7f4f64c6d9-fw97t   1/1     Running   1               5d8h
wasabi-proxy-deployment-7f4f64c6d9-mzgd9   1/1     Running   4 (2d22h ago)   5d1h
web-deployment-0                           1/1     Running   0               25h
web-deployment-1                           1/1     Running   0               25h

上記コマンドは既に運用してから大分経つのでAGEが大きめです。最終的に上記のようになると思われます。

運用で発生した事象

データ消失

Rook/Cephは比較的不安定なのかわかりませんが、よくNode3が落ちます。データベースがNode3に入っていた為そのままミスキーインスタンスも落ちました。
この時焦ってKubeadm resetをしてしまったためにPVCのデータが消えてしまい、約半日分のデータが損失しました。
また、この事象が原因かはわかりませんがデータベースが規定数起動しなくなりました。(厳密に言うと2個までは起動し、それ以上は起動しなくなる。)
どれか一つでもDeleteすると二個までは起動するのでよくわかりません。とりあえず障害が発生した時は何とかなりそうです。

GTLが見れない

何とか安定したと思ったのですが、今度はGTLが見れなくなる不具合が発生しました。
ログを確認するとどうやらMisskey側で一定以上の時間が経過するとTimeoutしてCancelするとの事。
分散型SNSの情報交換場所であるDiscordグループ「鯖缶工場」にて質問させていただいた所、Misskeyのタイムアウト設定をしたらどうかという回答が得られました。

config-misskey-default.yaml

# dbセクション
      extra:
      #  ssl: true
        statement_timeout: 300000 # ここを追記

結果として時間はかかりますが無事に見ることが出来るようになりました。
最初はDBに何か不具合があるのでは...?と思いましたが、しばらく使用しているとGTLが通常の速度で見えるようになったので本当に不思議。。。

Misskey側のDB Replicationsで設定すると画像やお知らせなどのサービスが利用できなくなる。

タイトル通りですが、複数DBがある状態でReplicationsの設定を行うと画像などの投稿が出来なくなります。
厳密には画像のアップロード時にInternalErrorが発生します。ただし、ストレージ上にはアップロードできており、ドライブから選択する事でノートをすることが出来ます。
この現象はアップロード以外にお知らせでも発生しました。

原因の特定はできていませんが、予想としてはprimaryへのデータ書き込みに加えてレプリケーションされているDBへの同期が間に合っておらず、データが存在しないままMisskey側がレプリケーションDBにアクセスすることによって発生しているのではないかと考えています。
この辺りはよくわからないので現在情報待ちです。
有識者の方いらっしゃいませんか...!!!

2025年現在、レプリケーションは成功しリードレプリカから読み込むことができます。しかしjobが稼働しないためレプリカを活用できない状況です。情報求ム...!

結局PostgresqlはRaspberrypi Clusterから性能の良いデスクトップコンピュータに移行したお話

当初RaspberrypiのKubernetes上で動かしていましたが、性能的な面でMisskeyの運用は難しいと判断し、Intelのデスクトップコンピュータに移行しました。
ネットワーク経由での通信となりましたが、Raspberrypi上で動かすよりは大分快適になりました。

前述のCloudNativePGは引き続きmicrok8s上で動かしています。(リカバリが凄い簡単でした。)

負荷の増加で全てをIntel製のサーバーへ移行したお話

7月頃に発生したTwitter(現X)の障害に関連してmisskey.niri.laのユーザー数が大幅に増加しました。
この時RaspberryPi 5台体制(4Node)で運用していたのですが、Misskeyの負荷が大きくなり、全NodeでCPU使用率が100%を超えた為、既に構築していたmicrok8sへ移行しました。

microk8sでも同じ設定で動いたので移行が大変簡単でした。

注意

S3Wasabiについて

どうやら3/3からWasabiは新規アカウントでのPublicアクセスが使えなくなるそうです。
https://blog.noellabo.jp/entry/wasabi-public-access

ローカルテストについて

既にデータが存在する場合、configも併せて変更しないと連合の不整合が発生する可能性があります。

ローカルテストの際はProxyを設定して連合を行わない設定にしてください

おわりに

色々調べてみると一部前提を省いて書いている点があったり、そもそも情報が無かったりと色々翻弄されました。
本来であれば2日程度で終わらせるつもりだったのですが、安定するまでにひと月掛かりました。