起動するkubeletのバージョンを上げる

By Syuta Hashimoto @ 2020-12-17 01:00

私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。

結論

/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する

調査

パッケージを確認

まず、パッケージがなんのバージョンが入っているかを確認します。

kubic1-host:~ # zypper se kubelet

S  | Name                          | Summary                   | Type
—+——————————-+—————————+——–
i  | kubernetes-kubelet            | Kubernetes kubelet daemon | package
i  | kubernetes1.17-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.17-kubelet-common | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet        | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet-common | Kubernetes kubelet daemon | package
i+ | kubernetes1.19-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.19-kubelet-common | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet-common | Kubernetes kubelet daemon | package

 どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。

今見たら、1.20も入ってますね。

使ってるバイナリを確認

kubic1-host:~ # type kubelet

kubelet is hashed (/usr/bin/kubelet)

ふむふむ。/usr/bin/kubelet、ですね。

こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。

kubic1-host:~ # file /usr/bin/kubelet
/usr/bin/kubelet: POSIX shell script, ASCII text executable

なるほど、スクリプトっぽいですね。

中身を確認します。

kubic1-host:~ # cat /usr/bin/kubelet
#!/bin/sh
# Loader Script for Multi-Version Kubelet arrangement introduced to openSUSE in March 2020
source /etc/sysconfig/kubelet

if [ -z “$KUBELET_VER” ]       
then
  echo “ERROR: KUBELET_VER= not defined in /etc/sysconfig/kubelet”
  exit 1
else
  /usr/bin/kubelet$KUBELET_VER “$@”
fi

どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。

kubic1-host:~ # cat /etc/sysconfig/kubelet
KUBELET_VER=1.19
KUBELET_EXTRA_ARGS=”–container-runtime=remote –container-runtime-endpoint=unix:///var/run/crio/crio.sock –runtime-request-timeout=15m –c
group-driver=systemd -v=2 –runtime-cgroups=/systemd/system.slice –kubelet-cgroups=/systemd/system.slice”

なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。

それからKubernetesを起動すると、見事バージョンが1.19にあがってました。

今なら1.20に上がる予感・・・・

メーリングリスト

最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。

そもそもの使い方

アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・

Geeko Blog » マニュアルのみのRPMファイルを作ってみた で、Sambaの日本語マニュアルパッケージを作成した時に参照したLinuxの日本語マニュアルページですが、2017年12月15日バージョンでした。これは openSUSE 15.0 から変わっていません。ちょっと古いですね。そこで、他のディストリビューションなどと比較して見ることにしました。結果は以下の通りです。なお、各ディストリビューションとも、各種コマンドでパッケージの最新化をして確認するか、配布サイトのパッケージ情報を見ています(※のもの)。

  • CentOS 7 20130615版
  • Debian10 20180315版
  • openSUSE 15.2 20171215版
  • openSUSE Thumbleweed 20191215版(※)
  • Fedora 20200315版(※)
  • Oracle Linux 20130615版(※)
  • Arch Linux なし(※)
  • Gentoo Linux 20180315版(※)

CentOS(=RedHat=Oracle Linux)はちょと古すぎますね。Fedora はやはりというか新しいです。しかし、Thumbleweed も結構新しい方でしょう。とりあえず15.2で使うのであれば、Thumbleweed版を持ってきて入れてしまうと言うのも手かもしれません。rpmファイルの中身はテキストだけなので、バイナリの互換性で引っかかることはないですから。

ちなみに、日本語マニュアルについては、Open Build Service で20201115版を作成し、更新をお願いしておきましたので、そのうちopenSUSE用の最新版が提供されるようになるのではないかと思います。

ただ、ls コマンドのマニュアルを見てみると、openSUSE 15.2 での日本語マニュアルはは GNU Fileutils のバージョンが4.1であると表示されますが、英語版は バージョン8.29 となっています。となると、日本語マニュアルに頼りすぎるのは少々危険かもしれません。

openSUSE Advent Calendar の14日目です。

オンラインイベント続きで Zoom が欠かせない今日この頃ですね。openSUSE 用のクライアントアプリの RPM パッケージは公開されていますが、なぜかリポジトリからの配信ではありません。そのため、アップデートが簡単にできなく不便です。

ということで、1コマンドで更新する小ネタです。単に zypper で URL を指定するだけです。自動更新がよければ、Systemd Timer で定期実行してもいいかもしれませんね。

sudo zypper in https://zoom.us/client/latest/zoom_openSUSE_x86_64.rpm

Samba には日本語マニュアルがあるのにパッケージ化されていません。ですので、日本語マニュアルのtar.gz ファイルを持ってきて展開することになります。このままですと管理が不便なので、RPMファイルを作ってみることにしました。ただ、一から作るのも大変なので、Linuxのコマンド日本語マニュアルのRPMファイルをベースにして作ってみることにしました。

まず、openSUSE 15.2 のSRPMファイルを入手し、rpm コマンドでインストールします。すると ホームディレクトリ配下のrpmbuild/SPECS ファイルにspecファイルが展開されます。これをベースに修正することにしました。…. が単にマニュアルファイルを所定のディレクトリにコピーするだけ、という単純なものかと思いきや、ちょっとしたテクニックが使われていました。

細かなことをやっているのは install セクション。ここでは、既存のディレクトリにインストールしようとするファイルと同じものがある場合、RPMファイルに含めないようにしています。また、複数のパッケージの日本語マニュアルをまとめているため(たとえば sudo とか tcpdump とか)、各パッケージ毎のサブディレクトリがあり、その中にさらにmanのカテゴリ毎(man1とかman8とか)に分けて日本語マニュアルが格納されています。このままではSambaの日本語訳ファイルアーカイブとは合わないため調整しました。そうして各ファイルをインストールする部分は以下のようになりました。

%install
mkdir -p %{buildroot}%{_mandir}/ja
for i in find output/manpages/ -name *.*
do
SUBDIR=man${i##*.}
mkdir -p %{buildroot}%{_mandir}/ja/$SUBDIR
install -m 644 $i %{buildroot}%{_mandir}/ja/$SUBDIR
done

#find の所、バッククォートがうまく入力できないのですが実際にはあります。

Samba日本語マニュアルのアーカイブはmanpages というディレクトリ配下にすべてのカテゴリ(man1からman8まで)が含まれています。そこで、カテゴリ毎に振り分けが必要です。そのため、

  • findでファイル一覧を作って do ループに渡す
  • ${i##*.} で、拡張子のみを抜き出し、振り分け先のディレクトリ名を作る
  • そこにinstall する

という形になります。拡張子のみをどうやって抜き出すかが大変なのですが、bash の変数名の後に ## を付けると、変数展開時に前方一致した部分を削除することが出来るのですね。そこで、ピリオドより前の部分を全部そぎ落としてしまえば、拡張子のみが残るというしくみです。この辺はbashシェル職人じゃないと思いつかないところですね。

後は多少調整して無事RPMファイルを作成できました。これで、openSUSE でも簡単にSamba の日本語マニュアルを参照できます。出来上がったものは
Samba翻訳プロジェクト のダウンロードの所に置いておきました。
….なのですが、openSUSE 15.2のSambaはバージョン4.11.x なので、作成したものとはバージョンが違ってました…. まあだいたいの所は同じですけれど。

参考URL
https://qiita.com/t_nakayama0714/items/80b4c94de43643f4be51
https://qiita.com/mriho/items/b30b3a33e8d2e25e94a8

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

今日は Open Build Service(動画配信ソフトと紛らわしいですが、以下 OBS)をセルフホストする話です。

Open Build Service

ご存知の人も多いかと思いますが、まずは OBS についておさらいしておきたいと思います。OBS は openSUSE で使用しているパッケージの開発のためのシステムです。openSUSE で使用している OBS の Web UI には次のページからアクセスすることができます。
https://build.opensuse.org

OBS が提供する主な機能は以下のとおりです:

  • パッケージソースのバージョン管理
  • Pull request スタイルのパッケージ開発のコラボレーション
  • CI 環境(オンラインビルド、ビルド結果の配信)
    • rpm はもちろん、deb パッケージも扱えます!

OBS のセルフホスト

OBS 自体もオープンソースソフトウェアであり、openSUSE で使うインスタンスを SaaS として使うだけではなく、自身のサーバーにインストールして使うことができます。これにより、会社内で使用するビルドサーバーをローカルに構築することも可能です。

今回は openSUSE Leap 15.2 上にパッケージから OBS をセットアップする方法を紹介します。公式ウェブサイトのダウンロードページの目立つところには(2020年12月現在) 15.1 ベースの ISO イメージからインストールする簡単な方法が書かれていますが、15.1 のサポート期間もそろそろ終わることですし、この方法は今回は使わないことにします。
https://openbuildservice.org/download/

パッケージから OBS をインストール

それでは始めましょう。openSUSE Leap 15.2 はいつものようにセットアップしてください。私が今回実験する上では VirtManager で KVM の VM を作って試しました。

セットアップした後、Web アプリサーバーですので、OBS サーバーにアクセスするときに使用するホスト名の設定をしておいてください。この後の設定スクリプトでがこのホスト名でオレオレ証明書を作ってくれます(設定されていないと止まります)。ちゃんとしたドメインのホスト名でも良いですし、LAN 内の /etc/hosts に設定して回っても OK です。私はルーター (RTX810) の DNS で、LAN 内でのみ有効なホスト名を割り当ててます。

OBS サーバーのパッケージをインストールしましょう。リポジトリを追加して OBS_Server パターンをインストールするだけです。実際は機能ごとにサーバーを分けることもできますが、今回は全部入れてしまいます。

zypper ar -f https://download.opensuse.org/repositories/OBS:/Server:/2.10/openSUSE_15.2/OBS:Server:2.10.repo
zypper in -t pattern OBS_Server

※OBS を構成するサービスについては、ユーザーガイドに解説があります。今回はビルドも含めて一緒に動かします。
https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.architecture.html

OBS サーバーを起動するために色々設定しましょう。ここでも手を抜いて設定スクリプトを使います。/usr/share/doc/packages/obs-server/README.md に書かれている通り、次のスクリプトを実行して、あとは待つだけです。

/usr/lib/obs/server/setup-appliance.sh

OBS アプリケーションの設定

セットアップが終わったら、https://設定したホスト名/ にアクセスしてみましょう。オレオレ証明書の警告は出ると思いますので、続行するか信頼済みの証明書に登録するかはおまかせします。

まずは Admin アカウントでログインしてみてください。初期パスワードは opensuse です。そうすると、いつもの OBS の Web UI に見たことのない管理用のアイコンが並んでいます。(画像はプロジェクトとパッケージをいくつか追加した後の状態)

あとは、ユーザーを追加したり、プロジェクトとパッケージを追加したり、好きなようにできます。1つやっておいたほうがよいことは、openSUSE の OBS との連携設定です。というのも、セットアップした状態では、ビルドターゲットのディストリビューションの定義(パッケージ類)がない状態です。これを1から作る(パッケージをアップロードしたり)のは大変です。そこで、openSUSE の OBS とリンクします。これにより、openSUSE をはじめとしたディストリビューションの定義やパッケージを必要に応じて、自動的に openSUSE の OBS から取ってこられるようにできます。設定自体は簡単で、設定画面から「Interconnect」にあるボタンを1回クリックするだけで終わります。

詳しい情報

ユーザーガイドとアドミニストレータガイドがあるので、見ておくと良いでしょう。 https://openbuildservice.org/help/

Proxmox VE 6.3 が出ています

By ribbon @ 2020-12-08 00:02

仮想環境プラットフォームとしてとても便利なProxmox VEですが、バージョン6.3が出ています。

変更点は https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.3 にありますが、順当に少しずつ機能が強化されてるという所でしょうか。あと今回は、Proxmox Backup Server との統合機能がメインかな。

地味にモダンなインタフェースになっているところもあります。例えば、今までプルダウンメニューで選択していたブート順の指定が、GUIのドラッグ&度ラップで出来るようになっていたりします。

日本語訳については最新版が反映されていないようです(画面ではテスト環境なので最新版になってますが、まだバグがありますね)。

そのほか、クラスタ回りとかストレージ回りで少しずつ改良がされているようです。ただ、openSUSE をゲストOSにしてテストするような場合にはあまり影響はないようです。

Kubernetesのメモリ使用量を測ってみる

By Syuta Hashimoto @ 2020-12-07 00:10

某LUGで、Kubernetesのメモリ使用量を気にされていたので、測ってみました。

結論

masterノードはKubernetes起動後、1.3G前後のメモリを使用。workerは、コンテナを動かせば動かしただけメモリを使用。15pod程度では、2つのworkerでそれぞれ1G使わない程度でした。

方針

KVM上にKubicを展開して、そこでKubernetesを動かします。

VMの起動のみの状態、Kubernetesを起動した状態、いくつかのpodを動かした状態、で、freeや、topのメモリ使用量上位10のプロセスを拾ってみます。

また、Kubernetes起動後はcrictl statsの結果も見てみます。今回、IDを名前で置き換えていますのでご注意下さい。(通常のcrictl statsですと、IDのみの表示となり名前は表示されません。)

環境

  • Kubernetes
    • master 1 worker 2 構成
    • KVM上で動かす
    • OSはKubic
    • CPU数 master 2 worker 1
    • メモリ それぞれ 3G
    • Kubernetes 1.19.4
  • ホスト
    • openSUSE 15.2
    • CPU Ryzen 3900
    • メモリ 32G

Kubic・・・openSUSEプロジェクトで開発している、Kubernetes専用OSです。Tumbleweedをベースにしていて、Kubernetesを動かすことに焦点を絞ったパッケージ構成&システム設定。プリビルドなイメージが毎日のように公開されるため、ignitionなどの初期設定ツールを使って手早く最新Kubernetesを展開できます。

Ryzen 3900・・・コア数12なので、VMは結構たてられます。目指せおうちクラウド。

ちなみに、saltstackのマスター用VMを別途立てていて、各ゲストは基本的にそこから制御しています。(今回のコマンド実行は直接各ゲストで行いました。)

VMの起動のみ

起動のみの状態

master

worker1

worker2

利用可能メモリが、3台とも2.5G程度であることがわかります。

Kubernetes起動後

Kubernetesとネットワークアドオンのweaveを起動します。

master

worker1

worker2

masterがさらに1G程使用しました。workerは数百程度の使用にとどまっています。

podを幾つか起動した後

15個程podを走らせてみます。

走らせたサービスは、Promeheus、Grafana、DokuWiki、Nextcloud、Harborなどです。

master

worker1

worker2

masterの使用量はほとんどかわりませんが、動いたpod分、両workerのメモリが使用された感じです。

参考までに、pod一覧です。

感想

色々と検証しているときは、clairが1G以上メモリを使ったりしていましたが、今回計測しているときは100Mいかないぐらいでした。当然ですが、podの起動だけでなく、実際に使ってみた時のメモリ使用量なんかが実運用上では参照値になると思います。

まだ、プロセスやコンテナの動作と使用メモリとの関連を掴みきれてないので、追って調査してみたいと思います。コンテナのメモリとディスクの関連も。

なお、今回動かしたサービスの殆どはiscsiのPersistentVolumeに接続しています。このあたりの方法も消費リソースと関わっていそうですね。

Kubernetesってメモリ使うんだよなー、よし、各ノードに6G割り当てるか、とかやっていたのですが、今回の計測で今の所3Gでも大丈夫なことがわかったので、設定を変更しました。やはり適切な設定は適切な計測から、ですね。ちなみに、Kubernetesでpodを動かす時に、CPU使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。