RKSを知る！連載第15回目 :マネージドKubernetesサービス比較調査 –CRI/CNI編

1 はじめに
2 CRIとは？
3 CNIとは？
4 各クラウドベンダのCRI/CNI
5 CRI/CNI比較結果
6 あとがき

はじめに

「RKSを知る！」の連載第15回目の記事としまして、各クラウドベンダ別のマネージドkubernetesサービスにてクラスタを構築した際に、どのようなCRI(Container Runtime Interface)とCNI(Container Network Interface)が設定されるかを比較し、それぞれの違いを解説したいと思います。

本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る！概要＆連載リンク集

CRIとは？

CRI(Container Runtime Interface)とは、WorkerNode上でPodの管理を行うKubernetesコンポーネントのkubeletとコンテナを実際に作成・実行・削除を行っているコンテナランタイムとの通信規約を指します。

実際のところ、CRIは通信規約なのですが、対象のコンテナランタイムと紐づいて導入されるケースがほとんどであるため、今回はコンテナランタイムと統合し、CRIとして紹介したいと思います。

CRIの詳しい説明については、過去に本ブログにてdocker非推奨化の影響について取り扱った際、内容を説明しておりますため、より詳しく知りたい方は以下の記事の参照をお願いいたします。

Kubernetes1.20から始まったdocker非推奨化の影響について

CNIとは？

CNI(Container Network Interface)とは、クラスタ内でのコンテナ間ネットワークを定義するAPIインターフェイスです。
CNIを導入することでクラスタ内のコンテナはコンテナ同士と通信することができ、コンテナ同士の連携を行うことが出来ます。

CNIはKuberneteクラスタをオンプレミス環境で構築した段階ではデフォルトでは導入されておらず、CNIを選定し手動で導入する必要があります。

Kubernete側で決まったCNIがないため、各クラウドベンダが提供しているマネージドKuberneteサービスにてクラスタを構築した際も、各ベンダそれぞれで導入されるCNIもそれぞれの特色にあったCNIが導入されています。

各クラウドベンダのCRI/CNI

各クラウドベンダ別のマネージドkubernetesサービスにてクラスタを構築した際に導入されるCRI/CNIについて、調査してみました。

今回もRKS以外のマネージドKuberneteサービスとしてAWSのEKSとAzureのAKSを対象としています。

RKS
- CRI
  2021年5月現在、RKSではDockershimを用いたDocker上のContainerdを使用する形態を取っているため、CRIを別途導入はしていません。
  Dockershimが廃止となるKubernete v1.23前にContainerdをコンテナランタイムと共に別途導入する予定とのことです。
- CNI
  RKSにて構築されたクラスタではCNIはWeaveNetを使用しています。
  Weaveは導入時にクラスタに対し、IPの指定などが不要なシンプルなCNIであり、柔軟で使用しやすいCNIです。
EKS
- CRI
  202105現在、EKSで使用できるAMIはDockershimを用いたDocker上のContainerdを使用する形態にて構成されており、CRIを指定して導入していません。
  Dockershimが廃止となるKubernete v1.23前に、今後のAMIのアップデートにて対応を予定しています。
  なお、AWSが提供しているコンテナ実行に特化したOSであるBottlerRokcetをWorkerNodeのOSに設定し構築した場合は、CRIとしてContainerdを使用する形で構成されているため、WorkerNodeのAMIが最適化されていない現在もCRIの導入としては可能となっています。
- CNI
  EKSのCNIはAWS独自のAmazon VPC Container Network Interface (CNI) プラグインを使用し、コンテナ間ネットワークを確立しています。
  Amazon VPC Container Network Interfaceを使用することで、クラスタ上のPodはVPC ネットワーク上と同じ IP アドレスをポッド内に持つことができます。
AKS
- CRI
  AKSではkubernetesv1.19以降のクラスタではContainerdがCRIとして導入されており、Docker上のコンテナランタイムは使用していません。
  そのため、kubernetesの将来的なアップデートにて予定されているDockershim廃止についてはすでに対応済みとなっています。
- CNI
  AKSのCNIはAzure独自のAzure Container Networking Interfaceを使用し、コンテナ間ネットワークを確立しています。
  Azure CNIを使用することで、クラスタ上のすべてのPodはクラスタが所属するサブネット上よりIPアドレスを取得し、Azure Virtual Networkと通信することが出来ます。

CRI/CNI比較結果

各マネージドKuberneteサービスにてクラスタを構築した際に設定されるCRIとCNIについて、以下の表にまとめてみました。

並べて比較してみますと、CRIは現状AKSのみ別途導入しており、対応としては進んでいることが分かります。
RKS、EKSともにまだDocker上のコンテナランタイムを使用する形で構成されており、2021年内にWorkerNodeの更新が予定されていることが分かります。

CNIは各ベンダばらばらで、仮想ネットワークサービスを提供しているAWS、Azureはそれぞれの仮想ネットワークサービスとクラスタ上のPodが連携が取れるように、独自のCNIを導入していることが分かります。
RKSはオンプレミス環境でも導入可能なWeaveNetを採用しており、何かしらのCNIエラーの調査は他の２つに比べ、しやすいと考えられます。

あとがき

今回は連載第15回目としまして、各クラウドベンダ別のマネージドkubernetesサービスにてクラスタを構築した際に設定されるCRI/CNIについて調査し、比較・解説をしました！
RKSにて構築されるKuberneteクラスタはオンプレミス環境でのクラスタに近く、他のクラウドベンダに比べ構成が分かりやすいことが分かったと思います。

次回更新もRKSと他のマネージドKubernetesサービスとの比較から、RKSのユニークな点に迫りたいと思います！

ここまでお読みいただき、ありがとうございました！

ご覧いただきありがとうございます！この投稿はお役に立ちましたか？

役に立った役に立たなかった

0人がこの投稿は役に立ったと言っています。