By ribbon @
2020-12-04 00:02
結論から先に書きます。Proxmox VEのLXC コンテナでX をぅこかすことは出来ませんでした。
コンソールとしてSPICEクライアントやxterm.js も指定できるので、出来るかなと思ったのですが、そうは問屋が卸しませんでした。
Xはインストール出来ます。しかし、xinit で起動してみると、 /dev/tty0 がないと言ってきて起動しません。確かに、/dev/ 配下を見ると、
ls -l
total 0
crw–w—- 1 root tty 136, 0 Nov 20 10:10 console
lrwxrwxrwx 1 root root 11 Nov 20 10:03 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Nov 20 10:03 fd -> /proc/self/fd
crw-rw-rw- 1 nobody nobody 1, 7 Nov 11 08:28 full
lrwxrwxrwx 1 root root 25 Nov 20 10:03 initctl -> /run/systemd/initctl/fifo
lrwxrwxrwx 1 root root 28 Nov 20 10:03 log -> /run/systemd/journal/dev-log
drwxrwxrwt 2 nobody nobody 40 Nov 20 10:03 mqueue
crw-rw-rw- 1 nobody nobody 1, 3 Nov 11 08:28 null
crw-rw-rw- 1 root root 5, 2 Nov 20 2020 ptmx
drwxr-xr-x 2 root root 0 Nov 20 10:03 pts
crw-rw-rw- 1 nobody nobody 1, 8 Nov 11 08:28 random
drwxrwxrwt 2 root root 40 Nov 20 10:03 shm
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdout -> /proc/self/fd/1
crw-rw-rw- 1 nobody nobody 5, 0 Nov 15 23:26 tty
crw–w—- 1 root tty 136, 0 Nov 20 10:03 tty1
crw–w—- 1 root tty 136, 1 Nov 20 10:03 tty2
crw-rw-rw- 1 nobody nobody 1, 9 Nov 11 08:28 urandom
crw-rw-rw- 1 nobody nobody 1, 5 Nov 11 08:28 zero
となっていて、/dev/tty0 がありません。そこで以下を試してみました。
/dev/console を /dev/tty0 に ln しようとしたのですが、 Invalid cross-device link エラーで駄目 ln -s でやってみたのですが、xinit を動かしたときに parse_vt_settings: Cannot find a free VT: Inappropriate ioctl for device エラーで駄目 mknod tty0 c 136 0 でデバイスファイルを作ろうとしたのですが、 operation not permitted エラーで駄目
でした。これで行き止まり。
ちなみに、他のディストリビューションも見てみましたが、結果は同じ。そもそも tty0 がないところから同じでした。
というわけで、残念ながらコンテナ内でXを動かすのには失敗しました。
Category
openSUSE ,
Tips ,
サーバ ,
デスクトップ ,
仮想化 |
受け付けていません
By ribbon @
2020-12-03 00:02
手軽な仮想化環境 Proxmox-VE は、LXC を使ったコンテナ環境も用意されています。コンテナ環境では、kernel は 仮想化環境のベースOSのものを使いますが、ユーザランドはopenSUSE のものが使われます。この記事を書いている時点で openSUSE 15.2 相当のコンテナ環境があったので使ってみることにしました。
openSUSE 15.2 のコンテナ環境は、Proxmox VE 標準で用意されていますので、それをWebインタフェースから選択するだけでダウンロード、インストールができます。
インストール完了後は、パッケージの総数は181個でした。見てみましたが、最低限の動作をするために必要なものだけしかない状態です。ssh,sshもないですし、yastも入っていませんでした。ほとんど何も出来ないと行っていいでしょう。/ ディレクトリも 213M しか使っていませんでした。必要最低限のユーザランドを一気に入れてしまうFreeBSD よりまさらにコンパクトです。さすがにzypper は入っていましたので、パッケージの追加は出来ます。
そこで、まずは zypper update を行ったのち、openssh を入れ、さらに yast (パッケージとしてはyast2) を入れてみました。
yast を入れた直後の画面は図1のようになります。
図1 yast を入れた直後の yast の画面
何もないですね。この時点では、yast2-ycp-ui-bindings, yast2-perl-bindings,yast2,yast2-core,yast2-xml,yast2-logs,yast2-ruby-bindings,yast2-hardware-detection,yast2-pkg-binding というものしか入っていません。 yast のサブメニューに対応するパッケージを何も入れていないため、何もないわけです。
そこで、他のサーバを参考にしつつ、yast パッケージを入れてみることにしました。取りあえずはSamba サーバにしたいため、yast2-samba-server を入れることにしました。すると、yast2-samba-client を含め、関連するパッケージが42個も入りました。
続いてSamba本体のパッケージ Samba を入れます。ここでも40パッケージが追加されました。
さて、Sambaをyast で設定するためには少し準備が必要です。useradd でユーザの追加、共有ディレクトリの準備とアクセス権の設定をします。また、pdbedit でSamba用ユーザの登録をします。その後に yast で Sambaの設定をします。しかし、起動すると、図2のように cups を無効にするかどうかを聞いてきます。
図2 capsは不要
今はSamba経由で印刷することはほぼ皆無なので、最初から無効にしておいてもいいんじゃないかと思うのですけどね。
さて、一通り設定が終わり、Sambaを起動しようとしたのですが、smbdがなぜか起動しません。ログを見ると、
ERROR: failed to setup guest info.
と言うエラーが出ていました。これはSambaが使うゲストユーザの定義がないということでした。調べて見ると、普通OSをインストールしたときには、nobody というユーザが作られているのですが、このLXC環境では入っていなかったのでした。そこで、uid 65534,gid 65533 の nobody を作りました。これでsmbの起動はOKとなりました。
Category
openSUSE ,
Tips ,
サーバ ,
仮想化 |
受け付けていません
By ftake @
2020-12-01 00:00
openSUSE Advent Calendar 2020 が始まりました。今年も完走できるのか!?まだ空きがありますので、みなさんご協力お願いします。
みなさん、Spotify を使っていますか? Spotify は定額サブスクリプションで音楽をストリーミングで聴けるサービスです。再生クライアントはデスクトップ、モバイル各種プラットフォームに対応しており、さらに Linux 用の公式クライアントもあります。
これまで音楽を再生するときは、PC から再生するか、PCの電源が切れているときは、スマホとオーディオアンプ(AI-301DA)を Bluetooth で接続して再生していました。ただ、スマホからの再生は電池を消費するのがちょっと難点です。
ということで、常時電源が点いているファイルサーバー(もちろん OS は openSUSE)から Spotify を再生できるようにしてみました。Spotify の公式クライアントにはちょっと便利な機能があり、自身のアカウントでログインした、他のデバイスの Spotify クライアントを使ってリモートで再生することができます(Spotify Connect)。スマホの Spotify クライアントを使って、PC や Amazon Echo から再生するというのがおそらく一般的な使い方です。
ファイルサーバーにはディスプレイが接続されておらず、デスクトップ環境も動いていませんので、公式の Spotify クライアントではなく、今回は Spotifyd という OSS の非公式クライアントを使用してみました。その名の通り、デーモンとしてバックグラウンドで動作するクライアントです。
ビルド・インストール
誰かが作ったパッケージがあるにはあるのですが、今回はソースからビルドしてインストールしました。master ブランチではなく、リリース版の 0.2.24 を使います。設定ファイルのフォーマットが違う(master では TOML 形式になっている)ので、ドキュメントのバージョンには気をつけて下さい。
https://github.com/Spotifyd/spotifyd/releases/tag/v0.2.24
Rust は openSUSE Leap 15.2 で提供されているものが使えました。
$ sudo zypper in cargo alsa -devel make gcc
ドキュメントに従ってビルドします。
ビルド結果は target/release/spotifyd
にありますので、これをファイルサーバーの /opt/spotifyd/bin
あたりに転送します。
設定
/etc/spotifyd.conf を作成します。設定例は README.md に書いてあるとおりです。 https://github.com/Spotifyd/spotifyd/blob/v0.2.24/README.md
password: Spotify の管理画面でデバイス用のパスワードを発行しておく device: 書いてあるとおり aplay -L
で使いたい出力のデバイス名を調べて下さい cache_path: /var/cache/spotifyd あたりに設定しておきましょう
自動起動に使用する service ファイル(/etc/systemd/system/spotifyd.service
)はこんな感じです。ソースコードの contrib ディレクトリ内の例からは少し変えてあります。まず、User
は spotifyd ユーザーを作成して root から落としてあります。RestartSec
は、spotifyd がときどき落ちていることがあったので、起動ループになると嫌だなと思い、長めに設定してみました。
[ Unit ]
Description =A spotify playing daemon
Documentation =https : //github .com /Spotifyd /spotifyd < br > Wants =sound .target
After =sound .target
Wants =network -online .target < br > After =network -online .target
[ Service ]
ExecStart =/opt /spotifyd /bin /spotifyd --no -daemon
Restart =always
RestartSec =300
User =spotifyd
Group =nobody
Type =simple
[ Install ]
WantedBy =default .target
あとは spotifyd を起動して、クライアントからデバイスに接続できるかを試してみて下さい。
$ systemctl enable spotifyd < br > $ systemctl start spotifyd
Category
openSUSE ,
サーバ |
受け付けていません
By ftake @
2020-04-27 00:31
最近、電源が壊れたPCを1台リプレースし、余ったマザーボード、CPU、メモリーでファイルサーバーを構築しました。その際にデータをファイルサーバーに移し、デスクトップ PC の HDD を外してしまったので、仮想マシン用の VM の仮想ディスクイメージもファイルサーバーに移す必要がありました。しかし、Hyper-V のディスクイメージは Samba サーバーに置くことができないようなので、仮想マシンのディスクイメージを iSCSI で Hyper-V に接続するようにしてみました。
今日は openSUSE Leap 15.2 (beta) で iSCSI Target(サーバー)のセットアップ方法を紹介します。今回設定する構成はディスクイメージを iSCSI で公開するファイルサーバーと、ファイルサーバーと同じネットワークにあり、そのディスクイメージを使用する Windows 10 のデスクトップ PC からなる単純なものです。
必要なパッケージは targetcli をインストールすれば揃います。YaST でも設定できるのですが、設定できる項目が少ないようなので、targetcli を使って設定します。
$ sudo zypper in targetcli
それでは targetcli を起動して設定していきます。
まずはディスクイメージファイルを作成します。targetcli の中で /backstores/fileio に移動して、create コマンドでディスクイメージを作成できますここでは /var/storage/disk1.img に 10 GB のディスクイメージ作成します。 /var/storage ディレクトリは先に作成しておく必要があります。
ls コマンドで disk1 が作成されたことが確認できます。
/> cd backstores /fileio
/backstores /fileio > create file_or_dev =/var /storage /disk1 .img name =disk1 size =10G
Created fileio disk1 with size 10737418240
/backstores /fileio > ls
o - fileio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 1 ]
o - disk1 . . . . . . . . . . . . . . . . . . . . . . . [ /var /storage /disk1 .img ( 10.0GiB ) write -back deactivated ]
o - alua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ALUA Groups : 1 ]
o - default_tg_pt_gp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ALUA state : Active /optimized ]
次に /iscsi で create コマンドを実行し、iSCSI の target を作成します。create の IQN 形式の ID を省略すると勝手に作成してくれます。
/backstores /fileio > cd /iscsi
/iscsi > create
Created target iqn . 2003 -01.org.linux -iscsi .testserver .x8664 : sn .b527a14e621a .
Created TPG 1.
Global pref auto_add_default_portal =true
Created default portal listening on all IPs ( 0.0.0.0 ) , port 3260.
/iscsi > ls
o - iscsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Targets : 1 ]
o - iqn . 2003 -01.org.linux -iscsi .testserver .x8664 : sn .b527a14e621a . . . . . . . . . . . . . . . . [ TPGs : 1 ]
o - tpg1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ no -gen -acls , no -auth ]
o - acls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ACLs : 0 ]
o - luns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ LUNs : 0 ]
o - portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Portals : 1 ]
o - 0.0.0.0 : 3260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ OK ]
この target で公開するディスク (lun0) を作成し、最初に作成したディスクイメージ(/backstores/fileio/disk1)を割り当てます。
/iscsi > cd iqn . 2003 -01.org.linux -iscsi .testserver .x8664 : sn .b527a14e621a /tpg1 /luns
/iscsi /iqn . 20...21a /tpg1 /luns > create storage_object =/backstores /fileio /disk1
Created LUN 0.
/iscsi /iqn . 20...21a /tpg1 /luns > ls
o - luns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ LUNs : 1 ]
o - lun0 . . . . . . . . . . . . . . . . . . . . . . . [ fileio /disk1 ( /var /storage /disk1 .img ) ( default_tg_pt_gp ) ]
最後に、この taget にはデスクトップPC からしかアクセスできないようにします。ここではデスクトップPCのID(Windows の iSCSI イニシエーターに設定するもの)を iqn.2020-04.example.com:desktop-pc とします。tpg1/acls 内でイニシエーター名を指定し、create コマンドを実行します。さらに、ユーザーIDとパスワードを設定し、事実上誰からもアクセスできる状態にならないようにします。
/iscsi /iqn . 20...21a /tpg1 /luns > cd . . /acls
/iscsi /iqn . 20...21a /tpg1 /acls > create iqn . 2020 -04.example.com : desktop -pc
Created Node ACL for iqn . 2020 -04.example.com : desktop -pc
Created mapped LUN 0.
/iscsi /iqn . 20...21a /tpg1 /acls > cd iqn . 2020 -04.example.com : desktop -pc /
/iscsi /iqn . 20...om : desktop -pc > set auth userid =testuser
Parameter userid is now 'testuser' .
/iscsi /iqn . 20...om : desktop -pc > set auth password =testpassword1234
Parameter password is now 'testpassword1234' .
/iscsi /iqn . 20...om : desktop -pc > ls
o - iqn . 2020 -04.example.com : desktop -pc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Mapped LUNs : 1 ]
o - mapped_lun0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ lun0 fileio /disk1 ( rw ) ]
この段階で mapped_lun0 が作成され、iqn.2020-04.example.com:desktop-pc に mapped_lun0 が作成されます。Leap 15.1 で試したときは、この mapped_lun0 が自動的に作成されず、Windows の iSCSI イニシエーターから接続してもディスクが何も表示されない状態になってしまいました。このような場合は、次のコマンドで mapped_lun を作成することができます。
create mapped_lun =0 tpg_lun_or_backstore =lun0
これまでの設定は以下の通りです。この状態で Windows の iSCSI イニシエーターでファイルサーバーに接続すると、ディスクの管理で iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a の lun0 (/backstores/fileio/disk1, /var/storage/disk1.img) がディスクとして見えるようになります。あとは Hyper-V でこのディスクを割り当てれば仮想マシンのディスクとして使用することができます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/> ls /
o - / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ . . . ]
o - backstores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ . . . ]
| o - block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 0 ]
| o - fileio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 1 ]
| | o - disk1 . . . . . . . . . . . . . . . . . . . . . [ /var /storage /disk1 .img ( 10.0GiB ) write -back activated ]
| | o - alua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ALUA Groups : 1 ]
| | o - default_tg_pt_gp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ALUA state : Active /optimized ]
| o - pscsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 0 ]
| o - ramdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 0 ]
| o - rbd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Storage Objects : 0 ]
o - iscsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Targets : 1 ]
| o - iqn . 2003 -01.org.linux -iscsi .testserver .x8664 : sn .b527a14e621a . . . . . . . . . . . . . . [ TPGs : 1 ]
| o - tpg1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ no -gen -acls , no -auth ]
| o - acls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ ACLs : 1 ]
| | o - iqn . 2020 -04.example.com : desktop -pc . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Mapped LUNs : 1 ]
| | o - mapped_lun0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ lun0 fileio /disk1 ( rw ) ]
| o - luns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ LUNs : 1 ]
| | o - lun0 . . . . . . . . . . . . . . . [ fileio /disk1 ( /var /storage /disk1 .img ) ( default_tg_pt_gp ) ]
| o - portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Portals : 1 ]
| o - 0.0.0.0 : 3260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ OK ]
o - loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Targets : 0 ]
o - vhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Targets : 0 ]
o - xen -pvscsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [ Targets : 0 ]
Category
Tips ,
サーバ ,
仮想化 |
受け付けていません
By Syuta Hashimoto @
2019-12-24 21:09
この記事はopenSUSE Advent Calendar 2019 の24日目です
※2020/01/26 追記 この設定をしてしまうと、Dockerが動かなくなってしまいます。詳細は現在調査中。まとまりましたら報告させて頂きます。※
GeekoMagazine 2019 冬号 に、仮想サーバーをさくっと建てる方法を書かせていただいております。よろしくお願いいたします。
さて、私は実際にこの方法で立てた仮想サーバーを活用しているのですが、最近、家のルーターがipv4アドレスを仮想サーバーに割り振ってくれなくなってしまいました。
結論 ホストがbridgeしたパケットをフィルタリングするのを無効にする
sysctlで以下の設定を行った所、無事、DHCPでipv4が割り振られました。
net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0
1行づつ、sysctl -w で設定してもよいですし、ファイルに記述して、sysctl -p でそのファイルを読み込んでもOKです。
ただ、/etc/sysctl.d/ にファイルを配置しても、起動時に読み込んでくれません・・・ここは追って調査して、記事にしたいと思います。
これらは、bridgeのフィルタリングを無効にする設定とのことです。
もしかしたら、最近のカーネルのアップデートなどで設定が消えてしまったのかもしれません。私が忘れているだけで、以前はこの設定をしていたかもしれず、記事から抜けてしまっていて申し訳ないです・・・
Category
openSUSE ,
サーバ ,
仮想化 |
受け付けていません
By Syuta Hashimoto @
2019-02-25 22:20
橋本修太です
Geeko Magazineに書いていたのですが、ちょっと前、確かkubernetes 1.12の時は、flannel 1.10を適応しようとすると、エラーとなって適用出来ませんでした。
それが、flannelがバージョンアップして解決したようです。今では以下のコマンドでネットからflannelを適応する事が出来ます。
kubectl apply -f https://0y.at/kubicflannel
Kubicが適応できるバージョンにショートネームをあてたようですね。
インストールの全体記事はこちら です。
それでは良いコンテナライフを。
By Syuta Hashimoto @
2019-01-05 23:16
橋本修太です。
例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。
現象
kubectlでdeploymentのyamlをapplyしても、DESIREDからCURRENTに移行しなくなった
要するに、新しいpod(Dockerで言うところのコンテナ)が動かなくなった、という事です。
原因
不明
直前に、nginx-ingress入れたりしていたんですけど、それでしょうか・・・・
解決方法
crictlで、Exitedなkube-controller-manager-****を削除したら、動き出しました。
手順
現象発生時、何かを調べたとは思うのですが、忘れてしまいました・・・とりあえずKubernetesを再起動させました。
NODEの削除(masterでの作業)
$ kubectl drain <node name> –delete-local-data –force –ignore-daemonsets
$ kubectl delete node <node name>
NODEの再起動(master含む各NODEでの作業)
$ kubeadm reset
$ reboot
いつもこの方法なんですけど、これでいいんでしょうか?
そして、いつもどおり起動していきます。
master起動
kubeadm init –cri-socket=/var/run/crio/crio.sock –pod-network-cidr=10.244.0.0/16
cp -i /etc/kubernetes/admin.conf ~/.kube/config
kubectl apply -f ./kube-flannel.yml
最後の、flannelのymlは、github から落としてきたものです。詳細はGeeko Magazineをご覧ください。ただ、README.mdに書いてある、以下のコマンドでも正しく動きそうですね。flannelかな?と思って、こちらで試してみたのですが、動作は同じようでした。masterなので、いつどういう動作をするかは、保証されないのでしょうが・・・
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
そして、同じ現象に出くわします。nodeの状態を以下のコマンドで確認するのですが、
kubectl get nodes
ずっと、STATUSはNotReadyのまま。
kube-system(というnamespaceで配置される、システム系のpod)を確認します。
kubectl get pods –all-namespace
すると、kube-controller-manager-****(****は、マスターのマシン名)のSTATUSが、CreateContainerErrorとなったまま。
ふーむ・・・ここでグーグル先生に泣き付く事小一時間。こんな感じで辿りました。
ログ確認
journalctl
Kubicは、Kubernetes関係のログはほぼここに入っています。いるはずです。いると思っています。
すると、こんな感じのログが立て続けに出力されていました。
pod_workers.go:190] Error syncing pod
****************** (“kube-controller-manager-linux-riis_kube-system(*********************)”), skipping: failed to “StartContainer” for “kube-controller-manager” with CreateContainerError: “the
container name \”k8s_kube-controller-manager_kube-controller-manager-linux-riis_kube-system_********************_**\” is already in use by \”************************************
\”. You have to remove that container to be able to reuse that name.: that name is already in use”
******はマスクです。ランダム英数字が入っています。また、linux-riisが、masterのマシン名です。
podのログも確認してみましたが、同じようなログが出力されていました。(はずです・・・もしかしたら、コンテナを生成できなかった、程度だったかもしれません・・・)
kubectl logs pods/kube-controller-manager-****(マシン名) -n kube-system
-nオプションで、namespaceを指定しないと、見つからないと言われるので注意です。
ふむふむ、どうも、IDだかがかぶってしまって、新しいkube-controller-managerを起動できないようです。
ここでイメージとコンテナの確認です。Kubicはcri-oを使っているため、コンテナ関連のコマンドはcrictl、サービスはcrioになります。crictlのホームページはこちら 。Dockerと似たような感じで使えるのではないでしょうか。ちなみに、このコマンドが入っているパッケージはcri-toolsです。
サービスステータスをチェックします。
systemctl status crio
CNIのデフォルトネットワークが見つからないよ、というエラーが見えますが、flannelを適応すれば直るでしょう・・・直ると信じたいです。(事実、直りました。)
では、コンテナの確認です。
crictl ps -a
すると、Runningとなっているものと、Exitedとなっているもの、2つのkube-controller-manager-****が。その他にも、kube-apiserver-****や、kube-scheduler-****も同じように、二種類。
Exitedとなっているものは不要なので(不要で終了したのでExitedなはずなので)、削除しましょう。
crictl rm ****(コンテナIDです。先のcrictl ps時に表示されます。)
そして、システム系のpodを確認。
kubectl get pods –all-namespaces
すると、なんと、kube-controller-manager-****が、Runningに変わっているではありませんか!
ただ、ちょっと待ってkubectl get nodesしても、NotReadyだったので、同じくExitedだった、kube-apiserver-****と、kube-scheduler-*****のコンテナも、削除しました。
そして待っていると・・・・無事、masterがReadyになりました。
後は、ワーカーNodeのkubeadm joinもすんなり動き、正常稼働に戻りました。
課題&感想
情報収集の方法をもっと知りたい
crictl知ったのは良かった
Kubicの再インストールを考えたけど、粘ってみてよかった。(いつもこうとは限らない)
正常時のログとかを認識していないと、異常時にあたりを付けにくい
ingressは、Kubic用があるっぽい
今見てみたら、kube-schedulerとか、Exitedなのがあった・・・
Category
openSUSE ,
サーバ |
受け付けていません