本セッションの登壇者
セッション動画
「明日から使えるかもしれない逆引きKubernetes」ということで、自分のターミナル履歴を元に、よく使うコマンドなどを紹介していきたいと思います。
突然ですが、みなさんはKubernetesとどうたわむれていますか? 私はなんだかんだいってkubectlで操作していることが多いです。Kubernetesが生まれて8年、今ではいろんな支援ツールが充実してきました。
今回はこんな流れでざっくりとコマンドを紹介していきたいと思います。
本題に入る前に軽く自己紹介させてください。CloudNatixという会社でソフトウェアエンジニアをやっているLadicleです。CloudNatixはマルチクラウドのコストを最適化とか、運用の自動化サービスを提供しているUSの会社です。日本から一緒に働いてくれる人も募集中なので、気になる方はお声がけください。最近、左手デバイスにハマっていまして、とくにStreamDeckめっちゃ便利なのでおすすめです!
では本題に戻ります。
リソース編
任意のフィールドをwatchする
1つ目は任意フィールドのwatchです。単にgetしたいだけであれば、JSONで出力してそれを成形してもいいですが、watchしたい場合はcustom columnを使うと便利です。このcustum column、ヘルプページには書かれてないんですけど、値はJsonPathで定義できます。なので、こんな感じに複雑なフォーマットも指定できます。
ファイルからも読み込めるので、よく使うcustom columnはファイルに保存しておくのがおすすめです。
指定したバージョンのリソースをgetする
続いて2つ目、バージョンを指定してgetする方法です。
普段は気にしてないかもしれませんが、単にgetコマンドを叩くと、内部的にはこのAPI resourcesで見えるデフォルトのバージョンでgetしています。
ただ、この例のautoscalingのように、複数バージョンが提供されていることがあります。
なので、v2 HPAを作成したとしても、Etcdに保存されるリソースは1つですが、APIサーバにコンバージョン機能があるので、デフォルトのv2でGetするだけじゃなくて、リソース名 > バージョングループ と指定することで、該当のバージョンフォーマットでgetすることもできます。
この例だと、1つ目のリソースに対して、左がデフォルトのv2、右はv1フォーマットでGetしてます。
リソースを連続して操作する
3つ目です。単に1回リソースを確認するぐらいだったら、kubectlを使ったほうが早いですが、連続してリソースの状態を確認したいときにはk9sが便利です。定番ツールになってきたので、もう使っている方も多いと思いますが、リソース名をフィルタしたり、切り替えたり、デリートしたりといった連続した操作をスムーズに実行できます。
ほかにもいろいろな機能があるので、気になる方は公式ドキュメントをご参照ください。プラグインも使えたりします。
クラスタ編
検証用クラスタを用意する
では続いてクラスタ編です。Minikubeやランチャーのk3sなど、簡単に用意する方法は最近いろいろあるのですが、私はkindを使うことが多いです。
kindはイメージフラグでクラスタバージョンを指定したり、クラスタ構成を定義したconfigファイルを持たせられるので、デフォルトの1node構成以外にもいろいろと設定を変えられます。私がよく使うのは、新機能を検証とかするために、FeatureGateを有効化したりする場合です。このサンプルみたいな感じですね。
ただ、1点注意があります。node imageのサイズがそれなりにサイズが大きいのでストレージ容量には注意してください。
操作するクラスタを切り替える
先ほどのように、kindなどでいくつもクラスタを常備しておくと、クラスタの切り替えも楽にやりたくなってきます。そんなときはkubectxが便利です。ちなみに、同じようにネームスペースを切り替えるkubensというのもあります。
あと、オペレーションミスを防ぐため、今どのクラスタを使っているのかを右下に表示させています。
Prometheus形式のmetricsをJSONとして扱う
続いては、Prometheus形式のmetricsです。やはり、人間が読める形には作られてないので、手軽に中身を確認したいときにはJSON形式に変換してくれるprom2jsonが便利です。JSONも読みやすいとは言えませんが、ツールが揃っていて操作しやすいので、個人的には好みです。
開発編
ラストは開発編です。
kindで手元のGoコードの挙動を確認する
まずは手元のGoのコードをkind clusterで検証する方法です。ここでは、koというツールでGoのコンテナから直接コンテナを生成して、それをリモート経由せずにそのままローカルのkind clusterのnodeに読み込む方法を紹介します。
こんな感じにイメージの生成と保存はko publishコマンドを実行するだけです。
ローカルのDockerレジストリに保存されたイメージは、kindのloadコマンドを使うと、指定したkindクラスタに直接ロードされます。これだけでイメージのセットアップは完了です。
あとは、Deploymentsなり、リソースを作成して動作確認するだけです。 注意点としては
- イメージを直接nodeにロードしているので、ダウンロードできない
- ImagePullPolicyがAlwaysだと動かない
という点です。
コンテナをデバッグする
次はデバッグです。ここでは、v1.23の目玉機能であるエフェメラルコンテナ(Ephemeral Containers)によるコマンドを紹介します。
最近はDistrolessをベースイメージにしている人が多いと思いますが、先ほどkoで作成したpingコンテナもベースがDistrolessになっています。なので、execコマンドだとshが見つからず、こんな感じで失敗します。
そんな現代の軽量コンテナのデバッグに便利なのがdebugコマンドです。デバッグ用のコンテナイメージをエフェメラルコンテナとして、指定したPodに追加できます。Pod外のエフェメラルコンテナも、通常のコンテナと同じようにネットワークなど共有されているので、こんな感じで、pingコンテナの中のサーバもlocalhost経由で直接叩けます。
ほかにも、ターゲットフラグっていうのがあって、これでコンテナを指定するとそのコンテナとpidネームスペースも共有できます。先ほどと違って、psコマンドを叩くと、pingのプロセスも見えているのがわかるかと思います。ただし、この機能はランタイムに依存している点はご注意ください。
次に --copy-to オプションです。このオプションを使うと、指定したPod内にコンテナを追加するのではなく、対象のPodをコピーしてその中に通常コンテナとしてデバッグ用のコンテナを立ち上げられます。今動いているPodそのものをデバッグしたいわけではないのであればクリーンに確認できるのでおすすめです。
コンテナイメージの中身を確認する
最後に、コンテナイメージの中身を確認するにはdiveが便利です。普段はDistrolessが多いのであまり入れる機会はないと言えばないのですが、外部のイメージを使っていて挙動がおかしいときや、ちょっと確認したい場合に便利です。
まとめ
今回はこれらのコマンドを紹介してきました。
時間の都合上紹介しきれなかったものがたくさんあるのですが、みなさんもいろいろお試ししつつ、快適なKubernetesライフをお送りください！
以上、ありがとうございました。
