この記事は openSUSE Advent Calendar 2019 の二日目です。

Kubicでは、コンテナを制御するコマンドに、dockerでなくてpodmanが採用されています。Podmanは、デーモンレス、ルートレスなコンテナ制御ソリューションで、主にRed Hatで開発されています。せっかくなので、podmanを使ってみました。

インストール

KubicやTumbleweedが新しいバージョンをパッケージングしているのに対し、Leap 15.1用は若干バージョンが古いようです。Podman は日進月歩で成長してますので、極力なら新しいバージョンを使いたい所。私はTumbleweedの派生であるMicroOSを使って、新しいバージョンを使っています。

ネットワーク設定ファイルパッケージ podman-cni-config も同時にインストールする必要がありますが、podmanの推奨に設定されていて、podmanのインストールだけで自動的に入ってくれるかもしれません。

zypper in podman podman-cni-config

MicroOSはトランザクショナルサーバーのため、私はtransactional-updateコマンドでインストールしました。（このあたりの詳細はGeekoMagazineに書いています。）

デーモンレス

Dockerを動かす時、Dockerのサーバーを起動させますよね。podmanはサーバーを使わない設計なので、サーバーを起動させる必要はありません。また、サーバー型であることに起因する脆弱性も回避しているとのことです。

ルートレス

Dockerはルート権限で実行するか、Dockerグループに追加したユーザーで実行する必要があり、これが脆弱性に結びつくのでは、と言われています。podmanは一般ユーザー権限でも動作するように設計されていて、この問題を回避しています。

ただ、私が使ってみた感じですと、一般ユーザーでボリュームマウントがうまくいかないんですよね・・・おいおい調査したいと思います。

Docker互換

もちろん、Dockerイメージをそのままrunすることができます。また、コマンドもDockerと同じように設計されていて、dockerの部分をpodmanに置き換えるだけでほとんどのコマンドを実行できます。実際に、dockerコマンドをpodmanのエイリアスにする、という代替方法も紹介されています。

• コンテナ実行 podman run 【イメージ名】
• コンテナ一覧 podman ps
• コンテナ停止 podman stop 【コンテナIDやコンテナ名】
• コンテナ削除 podman rm 【コンテナIDやコンテナ名】

などなど。

使ってみて

コマンドがDockerと同じなので、同じように使えて、違和感とかは全くありませんでした。サーバー起動に気を使わなくていいのは、素直に楽ですね。調査すればDockerとPodmanの差みたいなところもでてくると思うのですが、そこまで使い込むのはもうちょっと先になりそうです。（通常の使用では差がわかりませんでした。）

イメージ作成

Podmanは、Dockerのコンテナ制御、イメージ作成、の機能のうち、コンテナ制御を受け持っています。イメージの作成はbuildahというソリューションで行うことができます。アドベントカレンダーの中で、buildahについても紹介できればと思っています。

明日は ftakeさんによる、OSC Tokyo/Fallのイベントレポートです。・・・そういえば、私も参加させて頂いていました。 ftakeさんの後にイベントレポート書きますね！

この記事は openSUSE Advent Calendar 2019 一日目の記事です。

openSUSEには安定版のLeap、ローリング・リリース（最新バージョンを追いかける感じ）のTumbleweedがありますが、その他にもKubernetes用OSのKubicなどもリリースされています。Leapにしても、ライブ用があったりしたので、ダウンロードサイトを覗いて何があるのか見てみました。

ダウンロードサイトへの導線はメインページにあります。ここを見ると、左側にTumbleweed、右側にLeapの見出しがまず目に入ると思います。マウスオーバーすると「Tumbleweedのインストール」「Leapのインストール」という、ダウンロードサイトへのリンクボタンが表示されます。

前はダウンロードサイトへのリンクがどこかわかりづらかったのですが、大分見やすくわかりやすいデザインにかわりましたね。

Leapのダウンロードサイト

選べるのは以下の４つです。

インストール x86_64

通常のLeapです。

JeOS x86_64

JeOSってなんだろう？と思って調べてみると、openSUSEのwikiがありました。仮想環境やクラウドで利用するための、LeapをスリムにしたOSのようです。JeOSを元に自分なりのカスタマイズをしたイメージをKiwiで作成する、みたいな使い方もあるようですね。表示されている容量を通常のLeapと比較すると、スリムさがよくわかります。

ライブ x86_64

CDやUSBなどから起動できるライブイメージですね。

移植版 aarch64 ppc64le

説明に、「openSUSE Leap の PC 以外のアーキテクチャへの移植版は、本体とは異なる少人数のコミュニティチームでメンテナンスされております。」とありました。メンテナの方たちに感謝です。

Tumbleweedのダウンロードサイト

こちらも4種類ありました。

インストール x86_64 i586 aarch64 ppc64le

通常のTumbleweedです。

Kubic x86_64 aarch64

Kubernetesをすぐ動かせるOSです。MicroOSという、Tumbleweedから派生した、スリムでコンテナを動かすことを目的としたOSを元にしています。・・・このあたりの関係性や定義はちょっとずつかわるらしく（あるいは私が正確に把握していなくて）、サイトを久しぶりに見ると表現が変わっていたりします。

私がGeekoMagazineに構築記事を書いたり、OSC東京のセミナーで紹介させて頂いたのが、このOSです。

JeOS x86_64

TumbleweedのJeOSですね。今度使ってみようと思います。やはり、こちらも通常版とのサイズの差がはっきりしてます。

ライブ x86_64 i686 aarch64

Tumbleweedのライブイメージです。

所感

JeOS、Kubicあたりが、目新しい単語でしょうか。私はKubernetes構築をKubicでしているのでKubicには馴染みがありましたが、JeOSは単語だけ聞いたことがある程度でした。今度使ってみようと思います。

何気に、ライブイメージも使ったこと無いので、どんな感じなのか使ってみたいですね。

さて、次は・・・・次？みなさん、Advent Calendar に登録がありません！！是非登録してください！

橋本修太です

私が、では無く、ユーザ会で、なのですが、「日経Linux 9月号」に「openSUSE Leap 15.1がリリース　会議では今後の方針も明らかに」と題してレポートを書かせて頂きました。（文責は私でございます。）

内容は、「GeekoMagaze 2019 夏」号で武山さんが記事にされているLeap15.1の紹介から要点と、５月にニュルンベルグで開催されたopenSUSE Conference 2019のレポートです。

Leap 15.1は、マイナーバージョンアップリリースなので目玉機能とかよりは15.0からのスムーズな移行に重点が置かれているのですが、それでも細かい所は結構かわっていて（YaSTやカーネルへのパッチなど）、openSUSEユーザはもちろん、ユーザで無くとも興味を持って頂ける記事となっています。

是非、この記事で状況を把握していただいて、openSUSE Leap 15.1 を使ってみましょう

日経Linux 9月号 オフィシャルはこちら

この夏もGeeko Magazine を発行します。2014年冬から始まった Geeko Magazine Special Edition はついに10巻目となりました。

最初の頒布は8月12日（月）コミックマーケットC96 南 ラ-03a です。今回から入場時にカタログに付属のリストバンドが必要になりますのでご注意下さい。コミケの後は技術書典や OSC 東京で頒布予定です。

今回の内容はこんな感じです。ちょっと難しめかもしれません。

• openSUSE Leap 15.1 リリース!
• 仮想マシンは遅いのか？仮想マシンと物理マシンのディスク I/O 速度比較
• Docker Compose とは何が違う？Rails アプリを Kubernetes にデプロイしてみた
• Docker・Kubernetes の永続化ボリューム攻略
• eBPF を用いた PostgreSQL のクエリショル時間の計測
• 鏡の向こう第5話: 放課後
  openSUSE Leap + CUDA で TensorFlow を動かすよ～！

それでは、日本 openSUSE ユーザ会のスペースでお待ちしております。

年に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 のリリースパーティを開催しました。スパークリングワインで乾杯！

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

橋本修太です

さて、突然ですが、今私の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なのがあった・・・