年に1回の openSUSE ユーザーが集まるイベント、 openSUSE mini Summit を 7月20日に開催しました。近年は Open Source Summit Japan の翌日に開催しています。今回の参加者は26名でした。

今回の会場はサイバートラスト株式会社の会議室を使わせて頂きました。ありがとうございました。

オープニング

オープニングでは、昨年の mini Summit から今日までの活動を振り返りました。参加した OSC などのイベントと開催したイベントは17回ありました。また昨年末には Advent Calendar に参加し、7人で25日分のブログ投稿を行って完走することができました。

次にアイスブレイクで、参加者全員に自己紹介をしてもらいました。 1人持ち時間30秒で 、読んで欲しいお名前と、興味のあること、お仕事、関係するコミュニティなどを話してもらいました。

openSUSE Leap 15.1 リリース!

発表者: ftake

15.1 のカーネル、Snapper の容量表示、YaST の改良点を中心に説明しました。会場には Debian や Ubuntu のコミュニティからも参加者がいたため、SLE とパッケージはバイナリレベルで同一なのか？といった質問が出ました。（ソースレベルで同一で、バイナリは異なる）

openSUSE Conference 参加報告

発表者: ftake, hashimotosyuta, masayukig

openSUSE Conference の参加者が前に出て、写真を見ながら当日の様子を紹介しました。ソーセージとビールの写真が多めだったかもしれません。

openSUSE with OpenSDS

発表者: hashimotosyuta

様々なストレージエンジンをコントロールして、ストレージを作成できる OpenSDS を openSUSE で使う話です。残念ながら今のところ openSUSE 向けのパッケージは用意されていないようです。

Kubernetes the hard way on openSUSE OpenStack cloud

発表者: masayukig

GCP に手作業で Kubernetes をインストールする Kubernetes the hard way の紹介、新しいお家 Open Stack クラスタの紹介と、この Open Stack 上に Kubernetes クラスタを構築する話でした。
資料: https://github.com/masayukig/k8s-the-hard-way

openQAを使ってテストケースを作成してみる

発表者: nagayasu

openQA は openSUSE の自動テストで使用されている GUI テストツールです。openQA をローカル PC にインストールし、Live 起動のディストリビューションのテストのデモが行われました。

ショートトーク

emaxer さんと鹿さんによる飛び入り発表。XDP のパケット処理の話は OSC 京都で聞けます。

じゃんけん大会・クロージング

中サイズのカメレオンのぬいぐるみや、Tシャツなどがもらえるじゃんけん大会を行いました。プレゼントの数は十分にあったため、みなさん何かしら持って帰れたのではないかと思います。

リリースパーティ

すぐ隣のラウンジに移動し、少し遅めの Leap 15.1 のリリースパーティを開催しました。スパークリングワインで乾杯！

今回は初めての方も多くいました、じっくり交流して頂けたのではないかと思います。

橋本修太です

5/24 – 26、ドイツのニュルンベルク（SUSEの本社がある街）で開催された openSUSE Conference 2019 に参加してきましたので、レポートしたいと思います。

会場 Z-Bau

ライブハウスのようですね。大きな大学が無いので、ニュルンベルクで開催する時は、こういった所なのだとか。中央奥の入り口から入るメインホールは、200〜300人くらいは入れそうでした。

向かって左側はオープンテラスになっていて、ランチが振る舞われたり、二日目の夜は15.1のリリースパーティーをしたりしました。

フレンズ

日本からは、武山さん、井川さん、私、の三名で参加させて頂きました。

しかし、現地にもう１人、日本人の方が・・・・

そう、SUSEのカーネルメンテナーである、岩井さんにご挨拶させて頂きました。ずっとお会いしたかったので、めっちゃうれしかったです。岩井さんは、そんなはしゃぐ私に良く接してくださる、ナイスガイな方でした。

台湾からは、Joshsi、Kimlin, Iceの三名が参加されてました。去年のopenSUSE.Asia Summitで一緒だったらしいのですが、私は面識がなく・・・申し訳ない。しかし、そんな私にもとても仲良くしてくださいました。

今年のopenSUSE.Asia Summit開催国、インドネシアからはEdwinとSaputroが参加していて、Asia Summitに付いて皆と色々と議論していました。

インドからはAsia Summitのslackでお話しているAmey、それと、モーリシャスからパワフルなIshなど、各国の面白い方達と知り合うことが出来ました。

boardの方達も、良い方達ばかりで、私の挨拶に気軽に答えてくださいました。

私の英語力が拙く、あまりテクニカルな会話で盛り上がれなかったのが残念でしたが、世界中のopenSUSE熱を感じる事が出来ました。

セッション

色々と面白いセッションが続きました。そんな中からいくつかをピックアップしてみたいと思います。

YaST – Yet another SUSE Talk? by Thomas Di Giacomo

基調講演は、SUSEのCTO、Thomasの、SUSEとopenSUSEの協調関係に付いてでした。

Thinking About openSUSE HCL by Joshsi

台湾のJoshsiから、HCLの現在と提案についてのセッションでした。Joshsiはハードウェア屋らしく、自然と興味がこういう方向に向くのだとか。

”Kubernetes The Hard Way” on openSUSE Cloud environment by Masayuki Igawa

井川さんの発表は、”Hard Way”チュートリアルの紹介と、それを自分で構築したOpenStackでやってみた、という話でした。

Geeko Magazine: A Technical Magazine on openSUSE, edited on openSUSE by Fuminobu Takeyama

武山さんの発表は、Geeko Magazineについてでした。色々な国の方が興味津々に聞いていて、「翻訳用のデータは、いつ、どうやってアップするんだ？」とか、「なんでグローバルでやらないの？」といった、めっちゃポジティブな質問が飛び交いました。Geeko Magazine、世界に注目されてます。

openSUSE MicroOS in Production by Ish Sookun

モーリシャスのIshは、Kubicのプロダクションユースケースの紹介でした。タイトルはMicroOSになってますが、これは直前にRichardがKubicメインでは無く、MicroOSメインのリリースを行ったため。Ishは全面的にこの方針に賛成みたいですね。

Kubic with OpenSDS by hashimotosyuta

不肖、私も発表させて頂きました。統一的なストレージ管理プロジェクトであるOpenSDSと、Kubicからのストレージ利用の話をさせて頂きました。

しかし、ビデオがYouTubeにあがってるのですが、英語があんまりだねといった感じのコメントを頂いてしまいました。真剣に練習して、きちんと伝えたい事を伝えられるようになりたいです。

あと、ユースケースの話も聞きたい、という意見もあって、そういう話をした方がこういうカンファレンスでは良いのかも、と思いました。

Why you should choose openSUSE Kubic? by kimlin

台湾のkimlinによる、Kubicの紹介とインストール方法の案内でした。インストール方法の案内、私が前にOSCで発表したり、GeekoMagazineに書いたりした内容に似ていて、びっくりです。Kubicの入りやすさは、世界共通のようです。

openSUSE Leap 15.x Kernels: Status Quo by Takashi Iwai

岩井さんの発表は、15.1のカーネルについてでした。バックポートの8割方はドライバで、ドライバはユースケースが限られるのでユーザーによるテストもあまり進んでいない現実があるのだとか。カーネルメンテナの苦労の片鱗を窺い知れるお話でした。

印象的だったのは、openSUSEとSLESとで、カーネルのソースは一緒だよ、バイナリは違うけどね、という表現でした。

まだまだありましたが・・・・

以上、かいつまんで紹介させて頂きました。openSUSE Conferenec 2019のセッションは、YouTubeにあがってますので、是非みなさんも興味のあるものを聞いてみて下さい。

観光

ドイツについた日に、フランクフルトを少し観光し、帰る日に、ニュルンベルクを少し観光させて頂きました。あと、カンファレンスの終了後も、時間があればニュルンベルクの名所を回らせて頂きました。

SUSE本社にもお邪魔させて頂きました（外側からだけですが・・・）

ニュルンベルクはパンもソーセージも美味しく、街並みもきれいでとても印象に残る街でした。

来年はどこ開催かは決まってませんが、英語を練習して、また参加したいと思います。

その前に、秋のopenSUSE.Asia Summitですね。特にアジアの方達は、このイベントでお会いしましょう。

openSUSE、参加された皆さん、愉しいイベントをありがとう！

橋本修太です

Geeko Magazineに書いていたのですが、ちょっと前、確かkubernetes 1.12の時は、flannel 1.10を適応しようとすると、エラーとなって適用出来ませんでした。

それが、flannelがバージョンアップして解決したようです。今では以下のコマンドでネットからflannelを適応する事が出来ます。

kubectl apply -f https://0y.at/kubicflannel

Kubicが適応できるバージョンにショートネームをあてたようですね。

インストールの全体記事はこちらです。

それでは良いコンテナライフを。

橋本修太です

2019/02/22(金)と、23(土)に開催された、OSC 2019 Tokyo/Springに行ってきましたのでレポートしたいと思います。

OSC Tokyo

オープンソースカンファレンスは全国で開催されるオープンソースをテーマにしたカンファレンスです。東京では年に二回、春と秋に開催されていて、今回も場所は日野にある明星大学さんに提供頂きました。来場者は両日で1000人越え、と、ブースルームは常に人が沢山な印象でした。

明星大学さん、いつもありがとうございます。「コンピューターと学び」のセッションも聞きにいきますね。

ブース

ぎーこ君たちとブースでopenSUSEやKubic、Geeko Magazineをアピールしました。

金曜日は武山さん、太田さん、橋本（鹿）さん、井川さん、土曜日は武山さん、橋本（鹿）さん、名古屋から来てくださった安藤さん、と、ブース担当者は結構多めでまわすことが出来ました。これなら、ブースまわったりセミナー聞きに行ったりと、皆で協力してできそうですね。

橋本（鹿）さんは別のブースの担当者だったりもしましたが・・・近辺で協力しあってブースを回すのも、OSCではよくある光景ですよね。

openSUSE知ってるよー、と言ってくださる方も増えてきている印象で、OSCでのアピール効果も出てきてるなぁ、と思っています。それに、今回はユーザー会に興味あります、という方も来て下さいました。ML、IRC、slack、とありますので、皆でopenSUSEを楽しんでいきましょう

セミナー

金曜日に武山さんと私で、Kubernetesの入門レベルのセミナーを行ってきました。

参加者は60人程で、セミナールームは満杯。やはりKubernetesは注目されているなぁ、といった印象でした。

武山さんから、openSUSEの説明を5分ちょっと、それから私がKubicのインストールとKubernetesの起動を説明し、その後で再び武山さんがKubernetesの実践例を解説しました。

講演でKubernetes、Kubicに興味を持ってくれた方も少なからずいらっしゃって、講演後に詳細記事を書いているGeeko Magazineを求めにブースに来てくださる方もいらっしゃいました。

Kubic関連の情報はGeeko Blogでも常時発信していきますので、是非チェックしてみてください。

Kubic

ついこの間、CNCFに認定された事も受けて、是非どうですか？と、IaaSサービスさんにアピールさせて頂きました。前向きなお答えを頂けた所もありましたので、クラウドでKubernetes On Kubicな日も近いかもです。期待していますよー!

SUSE ソフトウェアソリューションズ　ジャパン

今回もSUSEさんから景品提供頂きました。ロゴの入ったかわいいタンブラーですね。私も一つ欲しい・・・

大きいぎーこ君の保管、いつもありがとうございます。

打ち上げ

土曜日の終了後、Debianの方と打ち上げへ。なぜそうなったかといいますと・・・GNOME WaylandでCJKのInput Methodに問題がある、との事で、ディストリビューションを横断しての検討会話をしていたのです（私はその方面は明るくなく、主に武山さんが）。

その中で、ディストリビューションを横断しての企画、例えばハック合宿とか出来たらおもしろいね、という話も出てきました。関西では谷口さんが合同LTに参加されたりもしてますし、関東でもいろいろできたら面白そうですよね。イベントに参加することがあればレポートしますし、興味のある方は参加も検討してみてください。

なんかめっちゃ有意義でした

Kubicのアピールも上々で、安藤さんのように、名前は聞いているけれどお会いしたことは無かった方達と何人かお会いできたり、商業誌の方とお知り合いになれたり、昔の同じ職場の方がきてくださったりと、非常に有意義な二日間でした。

皆さん、ありがとうございました。次は2019 Tokyo/Fallでお会いしましょう。

その前に、7月開催予定のopenSUSE mini Summitですね。ぎーこ君プレゼント予定ですので、欲しい方は是非チェックしてみてください。

写真

オープンソースカンファレンス 2019 Osaka

1 月 26 日に開催されたオープンソースカンファレンス 2019 Osaka に参加しました。

会場は大阪市にある大阪産業創造館 3F / 4F でした。3F はセミナーや企業系ブースが、4F はコミュニティ系ブースが並んでいました。

今回はセミナーを行わなかったので、ブースで openSUSE の紹介を行いました。
KOF 2018 から新たに関西在住となった中ギーコくんとちびギーコくんがブースを飾りました。

ブースでは openSUSE の紹介のような一般的な話から Transactional Update の話といったコアな話まで、多くの方とお話をすることができました。
元がビジネス向けだったためか、パーソナルな用途よりもビジネス向けの話（コンテナとか YaST での設定の容易さとか）に興味を持たれる方が多かったように思います。

openSUSE の紹介をするとよく聞かれるのが「openSUSE の特徴って何ですか？」という質問です。
この質問に対して、私は「YaST という設定ツールで GUI / CUI(ncurses) どちらからでも同じように設定が行えることです」と答えています。実際、家で使っているデスクトップでは設定ファイルを編集する機会がかなり減っているように感じています。

 

OSS 系コミュニティ合同 LT 大会 in 関西

翌 27 日は関西 Debian 勉強会、LILO、東海道らぐさんと合同の LT 大会に参加しました。

私は openSUSE の紹介と、KOF の東海道らぐ ＬＴ で発表した「SKK のススメ」を編集して発表しました。

SKK の利用による小指の酷使については、いくつか改善方法を教えていただいて、現在検討&お試し中です。

 

今後の予定

今後は、8 月 2 日(金)・3日(土)に開催するオープンソースカンファレンス 2019 Kyoto にブース出展する予定です（セミナーは未定）。
OSC 2019 Kyoto は会場となる京都リサーチパークが開催する KRP Week のひとつとして開催されます。
KRP Week では他にも様々なイベントが開催されるので、ぜひお越しください。

その前に、Leap 15.1 のリリースパーティ@京都サテライトを5月ごろに開催するかも知れません。
開催する場合は connpass にてイベント登録しますので、ぜひご参加ください。

橋本修太です

さて、突然ですが、今私のKubernetes環境はこんな感じになっています。

KVMは仮想マシン、KubicはopenSUSEのKubernetes専用ディストリビューション、masterやnodeはKubernetesクラスタでの役割を表しています。

ルーターに有線でデスクトップが繋がっていて、そこに３つKubicを走らせています。

また、ルーターはWiFiルーターに繋がっていて、WiFiでノートパソコンと通信、そのノートパソコンの上にも３つKubicが走っています。

それをですね、こうしたいのです。

デスクトップのnodeを、ノートパソコンのKubernetesクラスタに組み込みたいのです。

ノートパソコンは、メモリは16G積んでいて少し余裕はあるものの、CPUはcore i5で、KVMをこれ以上増やすのは難しいです。

そこで、クラスタの利点を活かして、デスクトップからnodeを引っ張ってくるわけです。

とりあえずこれでできました

KVMはデフォルトで閉じたネットワーク（ホストの外側からは中にアクセス出来ないネットワーク）を作成します。ただ、これはNATなので、ゲストからホストの外側にはアクセス出来ますが・・・

そこで、色々とやってみた結果、次のような方法でホストの外からのアクセスが出来ました。

• 【ノートPC】KVMでバーチャルネットワークを作成、マスカレードで接続
• 【デスクトップPC】ブリッジを作成

検証や調査等はおいおいやっていくとして、それぞれの設定を書いてみたいと思います。

今回は【ノートPC】編、次回は【デスクトップPC編】です

WiFi接続しているノートPCにブリッジを作成することに挫折

グーグル先生に教えてもらって、いくつかの方法を試したりしたのですが、どれも挫折してしまいました・・・

どうやら、ブリッジはレイヤー2で転送するものらしいのですが、WiFiはレイヤー2転送に対応していないというのが、WiFiでのブリッジ作成が難しい理由の大きなところらしいです。・・・いまいちピンとこないので、後ほど詳しく調べてみたいと思います。

parproutedやebtablesなどでレイヤー2転送を設定する

parproutedはarpをプロキシするものとの事です。また、etablesはEthernetフレーム用iptablesとの事です。parproutedはopenSUSE Leap15で上手く動かせられなかったり、ebtablesが意図した通り設定出来なかったりして、挫折してしまいました。

バーチャルネットワークを作成

Facebookでそんな事をなげいていたら、Saputro Aryuliant氏より、「KVMのバーチャルネットワーク設定して、iptablesでマスカレード設定すればいけるよ」とのお助けが。

「ホストPCの外から、ゲストPCにアクセスできる？」と聞くと、「iptables設定すればいけるよ」とのことでしたので、早速試してみることに。

KVMの設定

ルーティングでネットワークを作成します。

設定はvirt-managerでこんな感じです。

編集 > 接続の詳細

から、「仮想ネットワーク」タブを選んで、左下のプラスのアイコンをクリックして追加します。

デバイスにwlan0（WiFi）、方法にルーティングを指定している所がポイントです。

これ、デフォルトのNATネットワークだとだめなのかな？

iptablesの設定

まず、ノートPCでipv4のフォワードを有効にします。

sudo sysctl -w net.ipv4.ip_forward=1

これは再起動するとクリアされてしまいますので、常に設定したい場合は /etc/sysctl.d/の中に、{好きな名前}.confという名前で設定ファイルを作成して、その中に記述しておけばOKです。

確認は以下のコマンドで。

sudo sysctl -a

設定項目が表示されますので、grep -i forwardとかで絞ると楽に確認できます。

それから、同じくノートPCにマスカレードを設定します。

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

• -t nat パケット中のIPアドレスを書き換える用のテーブルを編集
• -A POSTROUTING 転送でパケットが出ていく時に処理を行う
• -s ここで指定した所から来た（Source）パケットに対する処理
• -j 指定した処理を行う　今回はマスカレード

これで、ノートPCの上で走らせているKVM上のKubicが、自由に外にアクセスできるようになりました。

ノートPCの上で走らせているKVMにデスクトップPCからアクセスする

とりあえず、アクセスしたいマシンやKVM上のKubicで、以下の設定を行いました。

ip -4 route add 192.168.100.0/24 via 192.168.0.12

192.168.100.0/24行きのパケットは、192.168.0.12（ノートPCのIPアドレス）をデフォルトゲートウェイにしてね、という設定です。

これで、デスクトップや、そこで走っているKVM上のKubicから、ノートPC上のKubicにアクセスできるようになりました。

・・・もちろん、デスクトップ上のKVMも、ブリッジ設定して、ホストの外へアクセスできるようにすれば、です。その様子はまた次回に。

感想＆課題

• ネットワークの基礎が無いのでちょっときつい
• レイヤー2ルーティングでブリッジ作成は可能？
• そもそもルーティングによる接続ってなんだろう
• ホスト外からアクセスする方法がスマートでない
• この辺りをもうちょっとまとめたい

橋本修太です。

例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。

現象

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となっているもの、２つの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なのがあった・・・