「車輪の再実装」って言葉が好き(実践はできてない)

Weekly Log 2 -- Kubernetesについて今知っていること・知らないこと --

はじめに

Kubernetesをやるぞ!と言いながら、実はこれまでまともにk8sを使ったことがない。 とはいえ、大学院でコンテナ関連の研究をしていたり、バイトでOCIランタイムの改良をしていたりしたので、 偏ってはいるもののそれなりに知識はある。

今後効率よく勉強を進めるためにも、 あえて知らないことを明示して心理的安全性を高めるためにも? 僕がkubernetesについて今知っていること、知らないことを整理してみようと思う。

ところで、この「知っていること、知らないこと」というまとめ方は、下記記事をちょっとだけ意識していたりする。

overreacted.io

知っていること、知らないこと

概要
  • O k8sはコンテナオーケストレーターだということは知っている
  • X Docker Swarm, Apache Mesos等と比べてなぜk8sが勝ち残ったかは説明できない
  • O"マニフェストファイル"というyaml/jsonを書いて宣言的にリソースを管理することは知っている
  • O各リソースは対応するコントローラに管理される
    • X カスタムコントローラは作ったことがない
Pod関連
  • O マニフェストにはPodを定義できることは知っている
    • O Pod単位でデプロイ等が管理されることは知っている*1
    • Pod作成時には特殊なコンテナを作るらしい事は知っているが、どんな名前でどんな役割かは忘れた・知らない
    • X Podとコンテナの厳密な区別ができていない(少なくともnetnsは共通というぐらいの認識)
  • Podを管理するリソースとしてReplicaSet, StatefulSet, DaemonSet, Deploymentが定義できる事は知っているが、他にあるかどうかは知らない
    • O ReplicaSetはPodのレプリカ数を維持するために使える事は知っている
    • O StatefulSetは順番にPodを一つづつ作る事は知っている
    • X StatefulSetはDB等に使うイメージだが、何がどう嬉しいかは知らない
    • O DaemonSetは各ノードに1つずつPodを配置するという認識
    • X Deploymentが何かは忘れた
NW
  • O PodをつなぐネットワークはCNIに準拠したプラグインによって作られる事は知っている。
    • CNIは多分L3担当?
    • O CNIプラグインには、デフォルトの例の他にflannelとかcalicoとかがあるらしいことは知っている
    • X CNIプラグインを意識して動かしたことはない
    • CNIはRPCやRESTのAPIというよりはコマンドのインターフェースだったはず
  • O Ingress(L7)とService(L4)というリソースが提供されていることは知っている
    • X Ingress、Serviceの細かい機能は知らない
    • X Ingress、Serviceの実現方法も知らない
Storage
  • O docker -v の様なボリュームは CSI準拠のプラグインによって作られることは知っている
    • X PVやPVCの詳細は知らない
    • CSIプラグインの例はtopolvmぐらいしか知らない
    • X CSIの実装方法は何も知らない
  • X Rookについては名前ぐらいしか知らない
Image
  • X k8s内部でイメージビルドする仕組み、方法を知らない
  • X 内部レジストリ的なものがあるかもしれないと予想(つまり何も知らない)
その他リソース
  • O シークレットを提供する仕組みを持っている事は知っている
    • X シークレットの仕組みや実体を知らない
  • X その他のリソースに何があるか知らない
    • 内部DNS的なものはありそう
拡張
  • OCNI, CSI, ランタイム, 以外にも選択・拡張を許す仕組みがあるらしい事は知っている
  • Oカスタムコントローラというワードを聞いたことがある
  • X 上記以外の拡張の存在や、カスタムコントローラ含めどんなインターフェースかは知らない
アーキテクチャ、高位ランタイム
  • O k8s環境を準備・構築する方法として、クラウドサービス, Ranchar, k8s the hard way, minikube, kind, k3s等複数の選択肢がある事は知っている。
    • X 上記各実装の差はあまり知らない
  • O 高可用な構成を取ることができるらしいことは知っている
    • X どの部分をどの様に冗長化できるのかわかっていない
  • O 全体の構造は大まかにkubelet(CLI) <--> コントロールプレーン <-->>> kubelet <->高位ランタイム ->低位ランタイム(コンテナ)の様な構造になっている事は知っている
  • X コントロールプレーンの実体がよくわかっていない
  • X kubeletの役割をあまり知らない
    • O ノード単位の管理はしているというのは分かる
    • X 1ノードに複数kubeletが置かれる場合はあるのか?
    • X 1kubelet辺り複数のCRIランタイムが置かれる場合はあるのか?
    • X なぜマスターとコンテナランタイムを直接通信させなかったのか?
サンドボックス、低位ランタイム
  • O containerdは多少ソースコードを読んだ
    • O containerdは1バイナリ中に複数のサービスを詰め込んだ構成となっている o
      • O サービスは部分的にgRPC経由で外部に切り出す事もできる
    • O containerd-shim経由でOCIランタイム・コンテナを制御する
  • O runcはLinux名前空間、cgroups、chroot/pivot_root、seccomp等で実現
  • O gvisorは、ptrace or kvmシステムコールをフックしてエミュレートすることでサンドボックスを実現
  • O Firecrackerは軽量なQEMU相当物だということは知っている
    • O kata-containerがQEMUの代わりにfirecrackerを使えるという認識はある
    • X firecracker単体で使えるか、高位ランタイムとのインターフェースはどうなってるか等は知らない。
    • X もちろん細かい実装も知らない
  • X shimの周りの事はあまりわかっていない
その他
  • X サービスメッシュやIstioについてはほとんど知らない
  • X HelmやKustomize等は、YAML補助ツール?についてもその詳細をほとんど知らない
  • X Ops系の知識もない

最後に

こうして列挙してみると、知らないことがかなり多いなぁという気持ちになる。 unknown unknown(知らないことすら知らないこと)は更にその数倍多いはず さらに言うと知っているつもりで知らないこともきっとある気がする。

全て知り尽くすのは不可能なので、方向性をある程度定める必要はあるものの、 まずは深く考えず、known known, known unknownを増やして少しずつk8sに関するunkonwn unknownを減らしていきたい。

余談: known unknown辺りを端的に表せる日本語が欲しい

*1:「コンテナ単位ではなく」と書いている文献もみるが、何をしてコンテナとするかは微妙なのでこの表現は好きではないのでお茶を濁す