タグ: linux

どこにでもある逸般の誤家庭の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回試行錯誤しながら作り直して設計をちゃんと考えないと仮想マシンを移植するのは非常に怖い。

 

By PC, taruki.com 、、、、

Network構成悩み中

Network構成をどう見直すか悩み中。
現在は、以下のIntranetとDMZの2つのVLANを運用していて、サーバーはOpenvSwitch+TagVLANにしているけど、いくつか問題あり。

問題その1:Debainのパッケージ更新でちょくちょくOpenvSwitchがちゃんと構成されなくなる

リモートからでは手も足も出なくなるので、ローカルのインターフェースは持っておきたい

問題その2:サーバー側は全部同じNICを通るので、ネットワークが切れたらDRBD+PacemakerでSplitBrainが発生する

なので物理的に別のバックアップ用LANは持っておきたいけど、10GBのSwitchを増やすお金も要件もないので、1GBにしておきたい

現状はこんな感じ。

で、色々考えた結果これで良いんじゃね？と思った。macvtapなのでホスト⇔ゲスト間は通信できないけど、非常用にホスト同士が通信できて、ゲスト同士のDRBDのバックアップネットワークになるので冗長性も確保できそう。IPv6のLinkLocalで通信できれば良いからIPアドレス割り当ても不要だしこれで良いんじゃね？

By PC 、

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

By PC 、、、

NanoPC-T4

以前から気になっていて年明けにポチったNanoPC-T4が到着したので早速お試ししてみました。

到着した佐川というかDHLのビニールを破いた直後の梱包状態はこんな感じで中国から空輸されてきたものをそのまま佐川の伝票貼って送った感じ。

付属品は、本体、ヒートシンク、アクリル板の簡易ケース、ACアダプタ。

ACアダプタは、12V/2Aにしては小型だけど当然PSEマークはなし。

組み立てたらこんな感じ。横はスカスカなので、埃とかは入りまくりになりそう。

16GBのeMMCを内蔵しているので、armbianを書き込んだSDでbootしたあと、nand-sata-install.shを実行したら良い感じでeMMCに書き込んでくれて、後はSDカードなしでも起動可能。eMMCもそこそこ速い。



[email protected]:~# hdparm -t /dev/mmcblk1p1


/dev/mmcblk1p1:

 Timing buffered disk reads: 640 MB in  3.00 seconds = 212.99 MB/sec

早速、Bitzenyをマイニングしてみた結果は以下の通り



[2019-01-23 13:33:56] accepted: 1/1 (100.00%), 0.44 khash/s (yay!!!)

[2019-01-23 13:34:00] accepted: 2/2 (100.00%), 0.44 khash/s (yay!!!)

[2019-01-23 13:34:28] accepted: 3/3 (100.00%), 0.44 khash/s (yay!!!)

[2019-01-23 13:34:42] accepted: 4/4 (100.00%), 0.45 khash/s (yay!!!)

[2019-01-23 13:34:45] accepted: 5/5 (100.00%), 0.45 khash/s (yay!!!)

[2019-01-23 13:34:48] accepted: 6/6 (100.00%), 0.45 khash/s (yay!!!)

[2019-01-23 13:34:53] Stratum requested work restart

これみるとかなり優秀やん！！なんですが、2分後ぐらいにはCPU温度が88℃になって、0.32 khash/sまで低下。真冬のこの時期でもマイニングしたらヒートシンクじゃ追いついてない。

あとは、iperfの実行結果はめっちゃ優秀でほぼワイヤレート。USB接続とは大違い。



[ ID] Interval           Transfer     Bitrate         Retr  Cwnd

[  5]   0.00-1.00   sec   111 MBytes   934 Mbits/sec  174    209 KBytes

[  5]   1.00-2.00   sec   109 MBytes   915 Mbits/sec  149    206 KBytes

[  5]   2.00-3.00   sec   110 MBytes   926 Mbits/sec   92    208 KBytes

[  5]   3.00-4.00   sec   110 MBytes   924 Mbits/sec  108    173 KBytes

[  5]   4.00-5.00   sec   110 MBytes   925 Mbits/sec  141    162 KBytes

[  5]   5.00-6.00   sec   110 MBytes   924 Mbits/sec  118    206 KBytes

[  5]   6.00-7.00   sec   110 MBytes   924 Mbits/sec  111    208 KBytes

[  5]   7.00-8.00   sec   110 MBytes   920 Mbits/sec  210    206 KBytes

[  5]   8.00-9.00   sec   110 MBytes   924 Mbits/sec  196    206 KBytes

[  5]   9.00-10.00  sec   110 MBytes   925 Mbits/sec  196    201 KBytes

– – – – – – – – – – – – – – – – – – – – – – – – –

[ ID] Interval           Transfer     Bitrate         Retr

[  5]   0.00-10.00  sec  1.08 GBytes   924 Mbits/sec  1495             sender

[  5]   0.00-10.00  sec  1.07 GBytes   923 Mbits/sec                  receiver

ARMなおもちゃとしては1.8万円と割とお高いけど、冷却をちゃんとしたら価格に見合うだけの良い性能はありそう。マイニング以外にも面白い遊び方を考えねば。

By PC, 工作 、、、

eo光でIPv6(その2)

eoサポートに、64bit以外のPrefixが使えるかどうかと、固定IPなのかどうかをダメ元で問い合わせていたのに回答があった。

予想通り、64bit固定で変更不可＆設備側都合で変更される可能性あり(いわゆる半固定IP)とのこと。

月数千円程度の家庭用プランでDMZなどの複数セグメントを用意して、しかも超絶巨大規模なサーバーを公開するという我が家の使い方を想定なんかしているわけないので、仕方が無い。

ぶっちゃけNATではなく全部がグローバルIPなのでDMZと内部LANを分離するメリットがあんまりないし、CloudFlare経由になっているので外部からのアクセスも格段に防ぎやすくなったので、DMZ辞めちゃってもいいかなぁとも思ってる。

By PC 、、、