2019/08/08〜11 Release Note

雑感

  • 日報書けるほどの出力が出なくなったので週報に切り替える。

Done

mornin plus導入

朝起きれるように・・・ これ、1個でカーテン片側しか開けられないのね。
無理矢理ぎみに両方開けるようにしているけれども、びもー感ちょっとある。
左右どちらかにしか動けない、開閉それぞれ何秒動かすかという設定しかないので、
カーテンの端っこに設置して動作時間を長めにすると全空け可能っちゃ可能。でも引っかかる。

kubernetes

[失敗] NFSバックエンドでmariadbのpodがlock failure的なエラーでコケた為 iSCSIバックエンドに

https://github.com/kubernetes-incubator/external-storage/tree/master/iscsi/targetd

導入手順が古いのか何なのか、上手く動かせなかった。認証があるとなんかのファイルが必要だけどそれがない。
っていうエラーだった記憶。 github上にissueがあって、しかも放置されているような状態なので諦めた。
このプロジェクト自体が割と放置なのかもしれない。

GlusterFS導入

ついにディスク容量効率を捨てて分散ストレージに手を出すことに。
GlusterFSは3台がミニマムなので、この際えいやとk8sのワーカーノードを3台に。

https://github.com/gluster/gluster-kubernetes
・・・ここからがまた色々と・・・

作業覚書

master(ストレージノードにはしない)
worker1~3(ストレージノード)

  • Debian 9 の場合、apt install glusterfs-client
  • その他、モジュールのロードも必要なので /etc/modules.d/ に書いておく
  • GlusterFSに供給するディスクを新規にVMにアタッチしておく。とりあえず MBRで。パーティションは不要。
  • 上記githubリポジトリをmasterでcloneしておく。

GO

GOの前に、 gk-deploy スクリプトを修正する必要がある。 スクリプト内の -show-all というオプションが
削除されているので、スクリプト内から削除する。(1箇所だったはず)
https://github.com/gluster/gluster-kubernetes/issues/582

gk-deploy -gv --admin-key <パスワード的なの> --user-key <パスワード的なの> で実行。

あとは祈るだけ。まおーはこれで色々ハマって3日くらい費やしました。
やり直しは、 gk-deploy --abort -gv --admin-key <パスワード的なの> --user-key <パスワード的なの>
で可能だが、heketiがディスクを確保するところまで言ってしまった場合( /dev/sdb がどうの・・・みたいなの)
ディスクにLVM情報が書き込まれてしまうので、すべてのストレージノードのディスクを初期化しなおす必要がある。
正直実行前にVMのスナップショットを取っておくことをおすすめします(すべてのストレージノードで)
なお、スナップショットを戻す前に、上記 abortを実行してk8s上のpodとかserviceは消しておくこと。

で、storage classのyamlと complete 的な表示が出たらとりあえずおめでとう!

storageclass

表示されたstorageclassのサンプルに以下の修正をした。

  • heketiのpodのIPアドレスが指定されているが、heketi のservice ip に変更。(しないとheketi podが落ちた時に繋がらなくなる)
  • userkey が指定されているが、 adminkeyでないとprovisioningに失敗したのでuser: admin , password: adminkey (gk-deployに指定したやつ)に変更
  • allowVolumeExpansion: true を追加

で、storageclassを登録。 登録後に

1
kubectl patch storageclass glusterfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

を実行して、defaultにしておく。
とりあえずこれで使えるようにはなった。

失敗記録

  • 初回デプロイなのに gk-deploy-g をつけ忘れた。→中途半端な状態になる
  • gk-deploy -v があるのにスクリプトに echo を挟みまくった→無駄な努力
  • heketi-copy-job みたいな名前のjobが ContainerCreationで止まった。→glusterfsをmountできてない。glusterfs-client入れ忘れ
  • complete!したのにpvcがpending… なぜかコントロールプレーンからheketi(Pod, Service)へのアクセスがufwで遮断されていた

8/9

ufwの設定不足の件

よく考えたら、dmesgにBLOCKのログが出るのだからそこを見ながら裏付けを取って
ポート開放していけば良いことに気がついた。
抜けていたのは、 8285/udp 8472/udp の二つ。これはflannelのポートとvxlanのポートだった。
10.244.0.0/16 から control-planeへのアクセスは全許可とした。(多分、53のDNSだけあれば良さそうな気がするが・・・)
これで、UFW有効な状態で動作できるようになった。

8/10

朝起きると、全ノードが応答を停止していた。
コンソールを見ると、OOM Killerが発動しているようだ。
とりあえず、メモリを2GB -> 4GB にして再起動したものの、GlusterFSのpodが起動しない。
起動中にOOMが発生してしまう。8GBにしても同じ状況になったため、手詰まり。
諦めてノードを全台再構築することにした。と同時に、うちのメモリ量では分散ストレージは無理と判断して、
NFSを再度試すことにする。

worker再構築

なんとなく、カーネルのバージョンの問題ありそうだなぁという事で(根拠まったくなし)
※ 昔、CentOS5でdockerを使うとkernel panicが起きまくった経験があった
Debian10でやってみることにした。 といっても、kubeadmを入れて kubeadm join するだけなので
別に9 (stretch) でも 10 (buster) でも変わらない・・・はずだった。

nfsのprovisionerを入れてテストpvcを作ってみると成功しない。おかしい。
nfs-provisionerのpodを見てみると・・・ containercreating で止まっている。
kubectl get pod --all-namespaces してみると、flannelのpodがworker上で
動いている所だけErrorになって落ちている。
問題は Debian 10 では iptablesがiptables-nft という新しいものに変わっているらしい。
update-alternatives --config iptables して、 iptables-legacy を選択すればおっけー

前の環境のゴミ掃除

GlusterFSの時に作ったpvcとpvが残ってしまっているので、地道に削除した。
pvcを削除する際に、 kubectl delete pvc/pvcname --force --grace-period=0 しても
消えてくれなくて困ったが、 kubectl edit pvc/pvcname して、 finalizer: を削除することで
消せた。 editは削除中でもOK。反映されると即消える。
finalizerは、pre-deleteのフックらしく、pvcが誤って消されてデータロストするのを防いでいるらしい。

8/11

今日の学び

  • mysqldump –all-databases にはユーザー情報は含まれない

NFSバージョン

ver 3までは色々と複雑な実装だったが、ver 4以降は割とスッキリしてるっぽい。
NFSを供給する為にOpenMediaVaultを使用していたが、色々とこの用途には無駄なものが多いのと
なんとなくArch Linuxのサーバーを一台持っておきたかったのでArch Linuxで再構築した。
(最初、btrfsで組んだらGRUBが上手く設定できなくてハマったが)
で、NFSを設定して、k8sのワーカーからマウントを試してみたら、なんとver 4.2で繋がった。
OMVのときは毎度Ver3にしかならなかったのに。。
速度に関しても、DBのダンプを取り込んだ範囲では実用の範囲内っぽい。(早いとは言わない)

writefreely k8s 移行

もう3回くらいやってるのでさすがに余裕。DB移行すればOK

fastladder k8s 移行

mysqlで運用しているので、それを移行すればOK。
ただし、 mysqldump ではユーザーのバックアップが取れないので、ユーザーだけは再作成した。
(正確にはパスワードが別ものになっていた?ような感じ)

graylog k8s 移行

作業中。なにやらあちこちにファイルばらまいてるような感じ。
・・・というより、journalの権限エラーが直らなくてつらい。その他いろいろありそう。
正直、elasticsearchにダイレクト取込で良いのではないかと思い始めてきた。
(それならkibanaかgrafana + grafana Lokiを動かすことになるけども)

k8sワーカーノード No.3

やはり3台のワーカーを用意することにした。2台だと1台を止めるときに負荷が寄りすぎる。
3台あれば、1台止めてもなんとかなるだろう。という感じ。
SSDの台数が3台なのでそれに合わせているとも言う。

TODO

k8sへの移行

  • elasticHQ
  • writefreely
  • fastladder
  • mastodonテストインスタンス
  • misskey

writefreely への文書コピー

職務経歴書

  • 外枠(プロジェクト名と日付)
  • フォーマット統一
  • プロジェクトの中身 (2018)
  • プロジェクトの中身 (2017)
  • プロジェクトの中身 (2016)
  • プロジェクトの中身 (2015)
  • プロジェクトの中身 (2014)
  • プロジェクトの中身 (2013)
  • プロジェクトの中身 (2012)
  • プロジェクトの中身 (2011)
  • プロジェクトの中身 (2011より前)
  • 自己PR

進捗ありません!

痩せる

  • プールに行って泳ぐ