どこにでもある逸般の誤家庭のk8s

今まで仮想化といえばkvm+virshで仮想マシンを増殖させていたんですが、そろそろアプリ増える度に仮想マシン作るのも効率悪いというか仮想マシン増えすぎで管理が億劫になってきたのと、いい加減コンテナ仮想化のお勉強もしないと思い始めてきたのでk8sを導入。といっても導入しただけなメモ。

Nodeは、とりあえずMaster兼Node×3+Node×1でコンテナホストはCentOS7.6-x86。kubesprayで設定をバラ巻いたんだけどかなり色々ハマった。コンテナエンジンは、Docker嫌いなのでcri-oを採用。

ハマリどころ1:余計な物は導入しない

kubesprayで導入する場合は、コンテキストにDocker/etcd/flannel/weave/cri-o/kubeletはyumリポジトリも含めて導入しない。入っていたらアンインストールしないと、kubesrayでばら撒いた設定と思いっきり競合する。しかも競合して動かない理由やログはansibleの実行結果から読み解くのは至難の業。

ハマリどころ2:SELinux, Firewalldはオフに

SELinuxは推奨されていない&kubesprayのplaybookで無効化してくれると思いきやAnsibleが途中で止まる。Firewalldも動いているとWarningが出て途中までは導入できるけど、flannelやweaveが導入された後に設定される仮想I/FがFirewalldに止められるので事前にそれも含めて許可設定しておくか無効にしておいて後から設定のほうが良さげ。

ハマリどころ3:Pythonのバージョンが酷い

CentOSに導入されているAnsibleは2.7.5でPython2.7.5をデフォルトで使おうとするけど、hosts.iniを自動生成するinventory.pyはPython 3.xを要求する。CentOS標準の3.4とepelにある3.6のいずれかなんだけど3.6にはraumel-yamlが必要なのにsubesprayのrequiements.txtにはraumel-yamlがない。そして、公式ドキュメントにあるhosts.iniはエラーが出て生成してくれずissueを見るとhosts.yamlを生成しろと書いてる。hosts.yamlは生成できたけど、cluster.ymlのPlaybookを実行するためのAnsibleで使うraumel-yamlだとやはり動かない。結局、サンプルを参考に手動でhosts.iniを作成してkubesprayのcluster.ymlのplaybookを実行。

他にもcri-oだとkubesprayのnode追加(scale)や削除(remove)が対応していないとか制約があるとか、コンテナ内からどうも名前解決が微妙な挙動をしているとか、Storageが未構成だとか、とりあえずdashboardが動く状態までは持って行けたけど、あと2~3回試行錯誤しながら作り直して設計をちゃんと考えないと仮想マシンを移植するのは非常に怖い。

 

Gluasterfsからお引っ越し

Mastodon+ねこ卓+このBlog+オンセンを動かしていたGlusterfsのクラスターが凄まじく不安定(理由はファイル数多過ぎ)でしょっちゅうダウンして冗長化している意味なかったので、DRBD9+NFSにお引っ越し。
pcsでClusterとNodeを作成した後は、こんな感じでresourceを作成して終わり。
本当は、SplitBrain対策のためにstonishとcorosyncとdrbdのネットワークを冗長化して、DRBDを3レプリカにしてQuorumを使えるようにすればより完璧だけどそれらはおいおい考える。
(世の中の開設blogのどれもこれもが思考停止でとりあえずstonishを無効化というのはいかがな物か)

pcs resource create FsNFS Filesystem \
  device="/dev/drbd/by-res/resource0/0" \
  directory="/export" \
  fstype="btrfs" \
  --group flavorGroup

pcs resource create nfsService ocf:heartbeat:nfsserver \
  nfs_shared_infodir="/nfslibs" \
    op start timeout="10s" \
    op stop  timeout="10s" \
    op monitor interval="10s" timeout="10s" on-fail="restart" start-delay="20s" \
      --group flavorGroup

pcs resource create exportfs_NFS ocf:heartbeat:exportfs \
clientspec="xxx.xxx.xxx.xxx/24" options="async,rw,no_root_squash" directory="/export" fsid="root" \
--group flavorGroup

pcs resource create VirtualIPv6 IPv6addr ipv6addr=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx cidr_netmask=64 --group flavorGroup
pcs resource create VirtualIP IPaddr2 ip=xxx.xxx.xxx.xxx cidr_netmask=24 --group flavorGroup

pcs constraint order set FsNFS FslibNFS VirtualIP nfsService exportfs_NFS

これで、IPV6もちゃんとFailoverできるようになってたので、あとはIPv6でもNFSをExportするのとハートビートもIPV6で定義したいところ。ハートビートはLinkLocal使えば簡単だしね。
(世の中の開設blogのどれもこれもが思考停止でとりあえずIPv6を無効化というのはいかがな物か)

DRBD9とlinstorのメモ

drbdmanageがすっごく不安定なので、linsotrを試してみたメモ。
基本は、3Ware社のドキュメント通りで大丈夫だけど、ビルド部分でドハマリした。
LINBITのGitリポジトリから、drbd-9.0,linstor-server,linstor-client,linstor-api-py,drbd-utilsを取得して、dpkg-buildpackage -bでビルド。masterブランチから直接ダウンロードするとビルドエラーになるし、linbit社のDownloadページからtarballをダウンロードするとdebianディレクトリがなくパッケージが作れないので、リリースタグの付いているブランチを取得する。
(これでめっちゃハマった)
依存関係は逐次潰しながらインストールしていった時のログを残してなかったけど、busterにあるパッケージをaptするだけで基本OK。
パッケージをaptでインストールしたら、drbd.service, linstor-controller.service, linstor-satellite.serviceがsystemdに登録されるので、enable化とstartを行う。


# VG作成
vgcreate drbdpool /dev/vdb1
# LV作成
lvcreate –thin -L 15G drbdpool/thinPool
# node登録
linstor node create testvm [IPアドレス]
# Storage Pool登録
linstor storage-pool create lvmthin testvm testpool drbdpool/thinPool
# Resource登録(確認コマンドは、resource listじゃなくて、resource-definition list)
linstor resource-definition create testResource
# Volume登録(確認コマンドは、volume listじゃなくて、volume-definition list)
linstor volume-definition create testResource 2G
# 登録したResourceの作成(–auto-place 1は、冗長化なし)
linstor resource create testResource –auto-place 1

その後、snapshotを実行したらカーネルが刺さったwww
KernelのLVM周りで完全に応答がなくなるので、busterのKernelかLVM2が怪しいような気がする。
DRBDのSnapshotが不安定なら、zfsとかbtrfsのSnapshotで対応するしかないか。

使う時は、「/dev/drbd/by-res/testResource/0」もしくは、「/dev/drbd1000」だけど前者の方が分かり易そう。
実際に、マウントしたりして使用中になったら、こんな風に見える。


linstor resource list
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x ResourceName x Node x Port x Usage x State x
tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu
x testResource x testvm x 7000 x InUse x UpToDate x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
drbdadm status
testResource role:Primary
disk:UpToDate

blog鯖移行しました

blogが稼働しているサーバーを単体の仮想マシンから、3台のCluster構成に変更しました。DBMSはMariaDB galera cluster、ファイルシステムはGlusterfsでnginxのリバースプロキシでロードバランシングというどこにでもある誤自宅の標準的な構成に変えました。
PHPとDBMS接続部分などはもうちょっと改善の余地があるけどとりあえず完成。

FreeNASステ

帰宅してこの画面見て唖然。。。

これまでもパラパラとCAMErrorが出ていたのですが、HDDをLinuxにつなぎ替えてテストしても全く異常がない。どうやら、MegaRAIDとFreeNASというかFreeBSDの相性が激しく悪いようで、IO負荷が上がるとこういう状態になるみたいです。

電源構成を見直したり色々してみたけど、ESXiのデータストアとして普通にRAIDアレイを構成したりLinuxからだと何の問題もないし、他にもFreeNASの不具合らしき問題をひいているので、思い切って捨ててOpenMediaVault+btrfsにすることに決定。ZFSと安定性どうだろう?とか考えて悩んだ末のFreeNASでしたが、ハードウェアとの相性が悪すぎるのはどうしようもない。