その1 Jetson TX2でk3s(枯山水)を動かしてみた
どーも、好きな世代はクラウドネイティブ世代の吉海です。今日はJetson TX2にk3s(通称: 枯山水)をインストールして動作検証をしたので、それについてまとめてみました。
k3sとは
40MBの1バイナリの軽量化されたKubernetesで、いくつかのARMのアーキテクチャをサポートしています。1バイナリなため、インストールがかなり簡単なのが個人的に気に入っています。
検証環境
- k3s v.0.2.0
- Jetson
+ head -n 1 /etc/nv_tegra_release
+ R28 (release), REVISION: 2.1
k3sのインストール方法
k3sのGithubリポジトリに下記の様な内容のインストール方法が記載されています。
- バイナリをダウンロードして自前で配置して起動する方法
- 自前でビルドする方法
- Dockerを使った方法。公式リポジトリにdocker-composeファイルが置いてある
- install.shを使った方法
ビルドする以外の方法を試して楽だったのがDockerを使う方法とinstall.shを使う方法でした。Dockerを使った方法はマシンの環境を汚さずにインストール出来るのでお試しに使うのであればこの方法がおすすめです。
自分は/sys/devices配下にあるデバイスをPodから触ってLチカをやりたかったので、Dockerを使わずinstall.shでインストールしました。コンテナ in コンテナでデバイスに触るとなるとvolumeオプションを頑張ったりなど手間が増えるためです。
ちなみにk3sのバイナリを自前で配置する方法ですが、k3sをアンインストールする場合にk3sが作ったファイルやディレクリの削除を自前でやる必要があるのが微妙でした。k3sは確かに1バイナリなんですが、動作に必要なファイルをぼちぼち作成するのでアンインストールが手動は辛いです。
install.shを使う方法
install.sh使った方法は下記のコマンドで出来るので楽ちんです。
curl -sfL https://get.k3s.io | sh -
install.shは以下の処理を自動でやってくれます。
- インストールするマシンに合致するアーキテクチャ用のk3sのダウンロード
- systemdにk3sをサービスとして登録
- k3sの起動
インストールするマシンに合致するアーキテクチャ用のk3sのダウンロード
install.sh内で、uname -mコマンドを叩いて、アーキテクチャを検出するようになっています。
setup_verify_arch() {
ARCH=`uname -m`
case $ARCH in
amd64)
ARCH=amd64
SUFFIX=
;;
x86_64)
ARCH=amd64
SUFFIX=
;;
arm64)
ARCH=arm64
SUFFIX=-${ARCH}
;;
aarch64)
ARCH=arm64
SUFFIX=-${ARCH}
;;
arm*)
ARCH=arm
SUFFIX=-${ARCH}hf
;;
*)
fatal "Unsupported architecture $ARCH"
esac
}
Jetson TX2でuname -mコマンドを叩くとaarch64と出力されるので、arm64版のk3sがダウンロードされる仕組みになっています。
k3s serverとk3s agent
k3sは下記の図のような構成になっており、k3s Serverがkubernetes masterに、k3s Agentがkubernetes nodeに相当するようになっています。
k3s Serverはk3s serverコマンドを実行することで起動されます。この時にデフォルトでagentも起動するようになっています。agentを起動させたくない場合は、–disable-agentのフラグを使います。
k3s server
k3s Agentはk3s agentコマンドで起動します。引数に–serverにk3s Serverのurlを指定、–tokenにk3s Serverのtokenを指定する作りになっています。
k3s agent --server https://myserver:6443 --token ${NODE_TOKEN}
k8s kubectl
k8s kubectlを使うことで、kubectlコマンドのインストールやkubeconfigの設定をせずにkubectlコマンドが叩けるようになっています。地味に便利です。
k3sのディレクトリ構造について
k3sバイナリとアンインストール用のシェル
k3sのバイナリの場所はinstall.shを使うと
/usr/local/bin
に配置され、アンインストール用のシェルスクリプトもそのディレクリ配置されます。
ls /usr/local/bin | grep k3s
k3s
k3s-uninstall.sh
serverやagentのデータ
/var/lib/rancher/k3s配下に配置されており、以下のような構成になっています。
/var/lib/rancher/k3s
├── agent
│ ├── client-ca.pem
│ ├── containerd
│ ├── etc
│ ├── kubeconfig.yaml
│ └── kubelet
├── data
│ └── a76eac31f2b7bd3c07a844671a9405198e33f3c29e3c2f441bc4866bf476421f
└── server
├── cred
├── db
├── manifests
├── node-token
└── tls
ちなみにdataの下にbusyboxになった各バイナリが確認が出来ます。
/var/lib/rancher/k3s/data/
└── a76eac31f2b7bd3c07a844671a9405198e33f3c29e3c2f441bc4866bf476421f
└── bin
├── addgroup -> busybox
├── adduser -> busybox
├── ar -> busybox
├── arch -> busybox
├── arp -> busybox
├── arping -> busybox
├── ash -> busybox
├── awk -> busybox
Container Network Interface
k3sで使っているCNIまわりのファイルは/var/lib/cni/配下に配置されます。ちなみにアンインストール用のシェルを実行してもこれらは削除されないので注意してください。k3sの動作がおかしい時に再インストールしても動作が治らないのはこいつらが原因だったりします。
今回起きた不具合
k3s server起動後にkube-systemのネームスペースのcorednsのPodがContainerCreatingから進まない不具合が発生しました。desribeコマンドで調べてみるとIPアドレスの確保に失敗しているようでした。
failed to allocate for range 0: no IP addresses available in range set: 10.42.0.1-10.42.0.254
使用中のIPアドレスはファイルとして/var/lib/cni/networks/cbr0/配下に書き出されるようになっているので、そのディレクリの中を確認してみると10.42.0.1から10.42.0.254のファイルが作られており、これらがfailed to allocateの原因のようだったので、/var/lib/cni/networks/cbr0の中身を全て削除後に再起動してk3s serverを実行したところ問題が解決しました。
k3sの不具合というよりはkubernetesのCNIやFlannelまわりで起こる問題のようです。似たような問題のIssueがkubernetesの方に上がっていました。
kubernetes/issues/39557 Kubernetes-cni issue with 1.9.0 – no ip address available in range
次回記事予告
次回はk3s on JetsonでLEDに明かりを灯す方法についてご紹介します。お楽しみに!!!
最後に
カブクでは工場にIoTエッジデバイスの導入および、それらをKubernetesで管理しようと検証を進めており、IoTやKubernetesをやりたいエンジニアを募集してます。ご興味ありましたら、まずはオフィスに遊びに来てください。IoTやKubernetes話をしたり、コリドール対戦しましょう。
その他の記事
Other Articles
関連職種
Recruit