k3s(k8s)について調べてみた

ラズパイに乗っけたDockerのネットワーク周りの構築がしんどくなってきたので、k3s(k8s)について調べてみたメモ書きです(Dockerを使ったことがある人向け)。

Docker Composeとk3s

Docker(Composeを含む)、Kubernetes(k8s)、k3sのいずれも、コンテナの管理ツールです。Dockerは各人のPC上で同一の開発環境を構築する目的で使われるのに対し、k8sやk3sは複数のPCをクラスタ化して運用する本番環境に使われます。

k8sは大規模なクラスタを組むのに向いていますが、k8s自身が非常にリソースを使用します。k3sはエッジ/IoT向きに機能を削減して軽量化したものです。機能を削減したといっても使用感は基本的に同じです。

Docker Composeのメリット

• とにかく学習コストが低く導入や利用が簡単
• コンテナイメージの作成・使用・管理がシームレス
• イメージのビルドが可能

k8s/k3sのメリット

• クラスタ化や自動スケールなどの本番環境向けの機能が揃っている
• ネットワーク構成の自由度が高い
• クラウドサービスの提供者が主体となって開発した業界標準(k8s)

k3sの特徴

• シングルバイナリ
  • 動作に必要なソフト(containerdやFlannelなど)はすべて内包している
• リソース使用量がk8sより少ない
• 標準でIngress Controllerが内包済み(Traefik)
• 標準のCNIはFlannelだが、ポリシー制御用にkube-routerが導入されているためNetworkPolicyも使える

k8s/k3sの最低限の用語

他にも色々な用語が飛び出してきますが、とりあえずDockerと同じように使うのに必要な最低限の用語のみ書き出しています。

コンテナ関連

ノード(Node)

クラスタを構成するマシンの単位。例えば3台でクラスタを組む場合は3ノードとなる

名前空間(Namespace)

複数のポッドをまとめて管理する単位。公式には同一物理クラスタ上の仮想クラスタのこと。
イメージ的にはcomposeの単位に近い

ポッド(Pod)

コンテナの管理単位。同一ポッド内のコンテナは同一ネットワークスタックを共有する。
イメージ的にはDockerでいうところのコンテナに近い

コンテナ(Container)

イメージを展開したコンテナ

ストレージ関連

クラスタが前提となっている関係か、設定ファイルを含めて基本的にバインドマウントは行いません。

PV

ボリュームの実体。ローカルでもクラウドでもOK

PVC

PVの定義。PVのコントローラのようなもの

ConfigMap

設定を一元管理するための機能。ファイルとしてマウントしたり環境変数として利用することが可能

Secrets

機密情報(APIキーなど)を一元管理するための機能。ConfigMapと同様に扱える

ネットワーク関連

サービス(Service)

ポッドから別のポッドへ通信するためのインタフェース。ポート変換も可能

Ingress

クラスタ外からクラスタ内へHTTP/HTTPSアクセスを管理するコントローラ。リバースプロキシ機能を提供する

その他

manifest

ポッドやコンテナなどの構成情報を記述するファイル。イメージ的にはcomposeファイル

label

ポッドなどを識別するために任意で設定できる識別子。selectorを使用する際にlabelを指定することで、1つ以上のリソースをまとめて設定できたりする

動作イメージ

k3sのイメージです。k8sはIngressコントローラのポッドを自分で立てる必要があります。

• ポッド内にコンテナが立つ
  • 同一ポッド内にコンテナを複数立てた場合、ネットワークスタックを共有するためlocalhostで相互に接続可能
  • 個別にIPが割り当てられるが、replica(複数ポッドの並列稼働)、rollout(ポッドの更新)、restart(自動再起動)の関係上使い捨て
• ポッド外からの接続待ち受けはサービスを通して行われる
  • サービスに対してサービスディスカバリ(内部DNS)が設定される
  • サービスがポッドとは別にIPを持つためポート変換が可能
• 名前空間は各種リソース(ポッド・サービス・設定など)をまとめて管理する単位
• Dockerネットワークのような個別ネットワークの概念は無く、基本的にポリシーにて制御される
  • 上図の丸へはポリシーの制御がない限り、クラスタ内からはどこからでもアクセス可能

操作

基本的にkubectlで操作しますが、一部のポッドやコンテナそのものへの変更は、より低レベルのAPI(crictlやctr)を呼び出す必要があります。

名前空間内のリソースにkubectlコマンドでアクセスする際には、明示的に-n 名前空間名で名前空間を指定する必要があります。kubectl getで全名前空間の情報を表示するには-Aオプションを使います。

おわり

ストレージ周りは個人で扱うにはオーバーな感じがしますが、ネットワーク構成はかなり自由に構成できそうです。

といったところで、最低限はこれくらい抑えておけば大丈夫でしょう。次回、Docker Composeからk3sへの移行のメモ書きを残しておきます。