CNDO 2021、サイバーエージェントのテックリードがコンテナランタイムの最新情報を解説

CloudNative Days Spring 2021からKubernetesのPodの実行基盤となるコンテナランタイムの詳細と最新情報を解説するセッションを紹介する。このセッションは、サイバーエージェントのインフラストラクチャーを構築運用するインフラチームのテクニカルリード、長谷川誠氏によるものだ。

長谷川氏はこれまでにも、OpenStack Summitや国内のIT関連カンファレンスにも登壇しているベテランのスピーカーだ。2018年のJapan Container Daysでもコンテナランタイムのセッションに登壇し、2020年のCloudNative Days Tokyoでは、GitOpsのためのツールの比較を行うセッションを担当した。

参考：
CNDT2020シリーズ：オススメのGitOpsツールをCAのインフラエンジニアが解説
runC vs. cc-runtime vs. kata-runtime？コンテナランタイムの内部構造と性能比較

Kubernetesにおけるランタイムを解説する長谷川氏

クラウドネイティブなシステムの第一歩がコンテナの利用であることは、CNCFのトレイルマップにおいて紹介されていることからもわかる。興味深いのは、CNCFのプロジェクトとしてContainerdやCRI-Oなどがホストされているにも関わらず、このイラストの中にはこれらが登場してこない点だろう。

Dockerから始まったコンテナ化は、Docker以外にもRed HatがプッシュするCRI-OやIntelがコードを提供したマイクロVMのランタイムであるKata Container、Googleが開発したgVisor、AWSが開発したKVMベースのマイクロVMのFirecrackerなど、さまざまなランタイムが並び立つレッドオーシャンだ。しかしセキュリティの強化などそれぞれに適した用途や特徴を備えており、デベロッパーに選択の可能性を提供しているとも言える。

CNCFのクラウドネイティブなシステムを構築するための順序を示したトレイルマップ

長谷川氏のセッションは、多数存在するランタイムから特にKubernetesの中で利用する際の基礎知識や設定方法などを解説するものとなった。

今回のトピックの中心となるRuntime Classを解説

ここではランタイムに高レベルランタイム、低レベルランタイムが存在することを解説し、CRIランタイムが高レベル、OCIランタイムが低レベルという位置付けになることを説明した。

OCI（Open Container Initiative）はThe Linux Foundation配下の組織であり、そこで策定されたランタイムの仕様となる。OCIはランタイムの仕様だけではなくコンテナイメージに関する仕様も策定しており、ランタイムとイメージに関する業界標準を作ろうとしていると言える。

一方CRIはContainer Runtime Interfaceの略で、コンテナを起動するKubeletとコンテナ間の通信インターフェイスを規定するものだ。

KubeletからCRIを通じてOCIランタイムが起動される仕組み

このようにKubernetesからコンテナが起動されるメカニズムをManifestoの記述に合わせて解説できるのは、自社の中でKubernetes-as-a-Serviceを立ち上げているサイバーエージェントならではと言えるだろう。

高レベルランタイム

CRI-OはKubernetesに特化した軽量ランタイム

複数存在する高レベルのコンテナランタイムの中から、ContainerdとCRI-Oについてそれぞれの特徴を解説した。ContainerdはDockerの内部で使われていたソフトウェアがCNCFに寄贈されてプロジェクトとして採用され、2019年にGraduationとなった成熟したソフトウェアだ。もう一方のCRI-OはRed Hatが強力にプッシュするランタイムで、Red Hatが提供するKubernetesディストリビューションであるOpenShiftで使われているソフトウェアとしても知られている。

DockerはCRIに対応していないことを解説

またコンテナの代表的なソフトウェアであるDockerはCRIランタイムではないことを説明し、Runtime Classでの定義を使えないとしながらも、Dockerを利用する裏技も紹介した。

また2019年にDocker社からDocker Enterprise事業を買収したMirantisが、cri-dokcerdという新しいプロジェクトを始めたことを解説した。これはKubernetes 1.20以降でDockerSimが廃止されることを受けて、Dockerのエコシステムに慣れているユーザーを救済するための施策だろう。

低レベルランタイム

OCIランタイムの紹介

ここからは低レベルのランタイムとしてrunc、Kata Container、gVisorの3点を紹介した。runcはほぼデファクトスタンダードとして、意識していないデベロッパーも使っているランタイムと説明した。一方Kata ContainerとgVisorはそれぞれマイクロVMベース、システムコールをフックする仕組みを備えているセキュアなランタイムであることを説明した。

OCIランタイムを選択可能にすることがRuntime Classの仕事

そしてOCIランタイムを設定するためのポイントを3つ挙げて解説。ここからは実際にKubernetesのManifestoの例を見せて解説するフェーズとなった。

OCIランタイムを設定する方法を解説

Admission ControllerでRuntime Classを有効にすること、ManifestoでRuntime Classを定義すること、CRIランタイムの設定ファイルで設定するという内容を、例を挙げて解説した。

KubernetesのYAMLファイルで設定

今回の例ではContainerd、CRI-Oのそれぞれにおける設定を解説した。

CRI-O側での設定を解説

またDockerからOCIランタイムを変更する方法についても解説を行い、ここではDockerのエコシステムに慣れているユーザーに向けての裏技を紹介した形になった。新しくコンテナを始めるユーザーにとってDockerはエントリーポイントとしては良いのかもしれないが、その先にKubernetesによるプラットフォームを意識しているのであれば、なるべくKubernetesの仕様に即したコンポーネントを選択するのがベストだ。しかしすでにDockerに慣れている開発者がスムーズに移行するためのルートが用意されていることを紹介したのは、長谷川氏の良識によるものだろう。

まとめ。「1.20でGAになったRuntime Classを使っていこう」と訴求

過去のセッションではOCIランタイムの性能比較を発表したこともある長谷川氏だが、ここでは敢えて「これからランタイムを意識し始めたデベロッパー、インフラエンジニアに向けた内容」にまとめたという印象のセッションとなった。Kubernetesのランタイムが気になるエンジニアには、良いイントロダクションとなったのではないだろうか。