おうちで Flatcar Linux 使って Kubernetes クラスタをやっていく

KOBA789

最終的には Kuberenetes クラスタにしたい。
k8s distro は無難に kubeadm かなぁ。

KOBA789

ストレージ戦略

USB Flash Drive: OS
SSD: LVM で LV 切る
- /var/lib/containerd/
- あとは TopoLVM で PV 用

KOBA789

マシン構成

TX1320 M1(Xeon E3-1220 v3 3.1GHz, 16GB RAM)が3台ある。
ヘタに HA 組むと LB もめんどいので、素朴に

control-plane (single node)
worker node (1)
worker node (2)

でいいかなぁと諦めている。

KOBA789

まずはディスクの構成をやっていく。

LVM の LV を / にマウントしたい（上記では /var/lib/containerd/ と書いたが、よく考えたらすべての stateful data は全部 SSD に書きたい）。
以下のマニュアルは RAID 用だが、予め SSD に VG と LV 作っておいて ROOT ってラベル付けておいたらいけるんではないか。やってみる。

KOBA789

そうそう、USB メモリの方にある ROOT ラベルは剥がしておかないといけない。

KOBA789

下準備

まずは ./flatcar-install -D でイメージを落としておく。
このあと何度も USB メモリを書きまくるので都度ダウンロードしていると時間がもったいない。

KOBA789

このように焼く。

sudo ./flatcar-install -f flatcar_production_image.bin.bz2 -d /dev/disk/by-id/usb-SanDisk_SanDisk_3.2_Gen1_A200175378701A36-0:0 -i ignition.json

Ignition の試行錯誤なら flatcar-install スクリプトの write_ignition だけ呼べばそこだけ上書きできる説ある。

KOBA789

part-9 に ROOT ってラベルが付いちゃってるので剥がす。

$ sudo e2label /dev/disk/by-id/usb-SanDisk_SanDisk_3.2_Gen1_A200175378701A36-0:0-part9
ROOT

KOBA789

ためしに part-9 (旧 ROOT) をマウントしてみたらいろいろ入ってるけどラベル剥がして大丈夫なのかな。
ROOT ラベル付きのパーティションに fs がいなかったら勝手にフォーマットしてこれらのファイルを作るのかもしれない。
わからんのでやってみる。

KOBA789

SSD に PV(LVM の Physical Volume のほう) 作ろうとしたら ddf_raid_member signature があると言われた。そういえば TX1320 M1 には RAID コントローラが乗っているのだった。
SSD は1枚しか刺していないので事実上 RAID コントローラーは使っていないのだが、RAID のメンバーシップ情報だけは焼かれてしまっているらしい。
ひとまず ddf_raid_member を wipe せずに PV を作ればいい気がする。
この SSD はかつてこの RAID コントローラーに接続されて使われていたものなのでメンバーシップ情報が既に書いてあって便利だが、新品の SSD をプロビジョニングするときはめんどいなぁ。
RAID コントローラーをバイパスできないものか。

KOBA789

pvcreate でこのように言われる。

WARNING: ddf_raid_member signature detected on /dev/disk/by-id/ata-SanDisk_SDSSDA480G_172378450006 at offset 480103980544. Wipe it? [y/n]:

KOBA789

wipe しないと pv 作れないのかぁ。どうしたものかな

KOBA789

USB メモリが速すぎて bz2 の decompress が flatcar-install のボトルネックになってたので予め decompress しておくことにした

KOBA789

e2label で名前変えても GPT の名前は変わらないので parted で name 9 unused した

KOBA789

ddf_raid_member signature を wipe してしまったので OS からディスクが見えないねぇ。
手作業で SSD を初期化するのは諦めて、Ignition 内で PV, VG, LV を作るようにしないとダメかも。できるのかな。

KOBA789

Flatcar Linux のブートシーケンス的に、Ignition が走る段階だと LVM のボリュームは見えてないっぽい。

困ったなぁ。

KOBA789

initramfs に LVM が入ってないのが悪い気がする。これ簡単に自前で作れるのかな

KOBA789

いや、LVM は入ってるのか。vgchange -ay 相当の操作が必要なのかもしれない。
Ignition の前に入り込む余地はあるのだろうか

KOBA789

OEM パーティションに grub.cfg を作り、次の値を書き込んだ

set linux_append="rd.lvm.vg=flatcar-vg"

BOOT の grub.cfg が OEM パーティションの grub.cfg を読んでくれるっぽい雰囲気なので、これでいけるかもしれない。

KOBA789

あ、悲しい……

KOBA789

rootfs を LV にするのを諦め、/var/lib/containerd などは別途丁寧に LV に逃がすこととし（これは真の rootfs がマウントされたあとの世界でやるので簡単）、rootfs は物理パーティションで10GBくらいくれてやることにする……敗北……

KOBA789

パーティションは手積みするとして、その他 kubeadm 入れるとか containerd 動かすとかは Ignition で書ける気がする

KOBA789

rootfs を物理パーティションにしたところ、何事もなかったかのように起動した。そりゃそうだ。

Kubernetes までの道のり

長い。

KOBA789

このようなわけで、無事別マシンで flatcar-install を実行して SSD を焼けるようになった。

USB メモリは不要になったし、自動化もしやすくなった。

KOBA789

flatcar-install した直後のディスクの GPT はディスクの容量を使い切れていない（=backup table が末尾にない）ので、これを直さないとディスク容量を活用できない。
これを parted で直すと GRUB がパーティションを見失う。
そのため、gdisk を用いて直す。
直すついでに LVM のパーティションを作る。

直し方 & LVM パーティション追加

x extra functionality (experts only)
e relocate backup data structures to the end of the disk
v verify disk
- 念のため確認しておく。No problems found. なら OK
m return to main menu
n add a new partition
- Partition number: 10
- First sector: (default)
- Last sector: (default)
- Hex code or GUID: 8e00 (LVM)
w write table to disk and exit

VG 作成

sudo vgcreate flatcar-vg /dev/disk/by-id/<blahblah>-part10

ディスク取り外し

deactivate VG

sudo vgchange -an flatcar-vg

detach disk

sudo bash -c 'echo 1 > /sys/block/sdN/device/delete'

KOBA789

GPT を編集してもブートするようになったので、次は /var/lib/containerd 用の LV を作って mount するようにやってみる。

KOBA789

そもそも containerd はデフォルトだと動いてない（入ってはいる）

core@localhost ~ $ sudo systemctl status containerd
○ containerd.service - containerd container runtime
     Loaded: loaded (8;;file://localhost/run/systemd/system/containerd.service^G/run/systemd/system/containerd.service8;;^G; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: 8;;https://containerd.io^Ghttps://containerd.io8;;^G

KOBA789

Container Linux Config の config.yaml にこんな感じで追記

systemd:
  units:
    - name: var-lib-containerd.mount
      enable: true
      contents: |
        [Unit]
        Description=Mount LV containerd to /var/lib/containerd
        Before=local-fs.target
        [Mount]
        What=/dev/flatcar-vg/containerd
        Where=/var/lib/containerd
        Type=ext4
        [Install]
        WantedBy=local-fs.target
    - name: containerd.service
      enabled: true
      dropins:
        - name: 10-wait-containerd.conf
          contents: |
            [Unit]
            After=var-lib-containerd.mount
            Requires=var-lib-containerd.mount

KOBA789

gdisk でパーティションを作ったあと、LV を作る。

sudo lvcreate -n containerd -L 20g flatcar-vg

KOBA789

mkfs 忘れてた。

sudo mkfs.ext4 /dev/flatcar-vg/containerd

KOBA789

containerd は動くようになった。

kubeadm の要件を満たすべく、いろいろな設定ファイルを焼いていく作業に移る。

KOBA789

br_netfilter をロードする
- https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#letting-iptables-see-bridged-traffic
containerd で systemd cgroup driver を使う
- https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd-systemd

これらの設定ファイルは Ingnition で焼く。

KOBA789

アップグレード作業のことを考えると、kubectl/kubelet/kubeadm のインストールは Ignition ではなく Itamae でやるべきな気がしてきた。