Kubernetesベースのコンテナオーケストレーションシステムは、モノリシックな一枚岩システムではなく、さまざまなエコシステムツールの組み合わせと、マイクロサービスの思想で作られる。
システム全体を形成する要素として、例えばストレージやネットワークなど、様々なコンポーネントをKubernetes（またはコンテナ系システム）と組み合わせる際に、標準インターフェースを定義しておくことで、様々なプレイヤー（ベンダーやOSSプロジェクト）が柔軟に拡張機能を作り、連携/提供できるようになる。
そんな標準インターフェースや仕様、プロジェクトはたくさんあるので、備忘録としていくつかまとめる。
[1] CSI : Container Storage Interface
**永続化ストレージの拡張用標準IF**
https://kubernetes-csi.github.io/
- Kubernetesなどの**Container Orchestration Systems（CO）**上のコンテナ化されたワークロードに任意のブロックおよびファイルストレージシステムを公開するための標準仕様/API
- CSIを使用すると、サードパーティのストレージプロバイダーは、コアのKubernetesコードに触れることなく、Kubernetesで新しいストレージシステムを公開するプラグインを作成してデプロイできる
- CSI ドライバをインストールすると、Kubernetes でネイティブにサポートされないストレージ システムがサポートされるようになる
- CSI を使用すると、スナップショットやサイズ変更などの最新のストレージ機能を使用できる
- Kubernetes v1.13 でGAになった
参考）
例：Amazon EKS x Amazon EFS
Amazon EFS（マネージドファイルシステム）を Amazon EKSのKubernetesクラスタから利用する場合、GitHubで公開されているEFS用のCSIドライバーをインストール（kubectl applyまたはhelm install）すると、Kubernetesクラスタ上のPodからEFSのストレージが直接利用できる
- 参考URL
[2] CNI : Container Network Interface
**コンテナのネットワーク接続用標準IF**
https://github.com/containernetworking/cni
- CoreOSが提唱し、現在はCNCFプロジェクト
- Linuxコンテナでネットワークインターフェイスを構成するプラグインと、それを作成するための仕様とライブラリで構成されている
- CNIは、コンテナのネットワーク接続と、コンテナが削除されたときに割り当てられたリソースの削除の役割を担う
代表的なCNIプラグイン
- flannel（https://github.com/coreos/flannel）
- Calico（https://www.projectcalico.org/）
- Canal（https://github.com/projectcalico/canal）
- Weave Net（https://www.weave.works/oss/net/）
- etc.
参考URL
[3] SMI : Service Mesh Interface
**Kubernetesのサービスメッシュ用標準IF**
https://smi-spec.io/
- マイクロソフトやHashiCorpらが共同で発表したサービスメッシュソフトウェアの標準インターフェース
- 最も一般的なサービスメッシュのユースケースの基本機能例
- Traffic policy : サービス間のトラフィックに対する暗号化や認証といったポリシーの設定
- Traffic telemetry : サービス間のエラー発生率やレイテンシといったトラフィック上重要なメトリクスの取得
- Traffic management : サービスに対するトラフィックの切り替えといったトラフィック管理
- SMI対応サービスメッシュプラグイン例
参考）
https://www.publickey1.jp/blog/19/hashicorpservice_mesh_interfacesmikubernetesapi.html
[4] CRI : Container Runtime Interface
Kubernetesのコンテナランタイム接続用標準IF
https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
- CNCFが管理
- kubeletが再コンパイルせずにさまざまなコンテナランタイムを使用できるようにするプラグインインターフェイス
- CRIは、プロトコルバッファとgRPC API、およびライブラリで構成されている
- CRIをサポートするHigh-Levelコンテナランタイム例
- Docker(dockershim + containerd)（https://www.docker.com/）
- containerd（https://containerd.io/）
- CRI-O（https://cri-o.io/）
※Docker(dockershim + containerd)は Kubernetes v1.20以降非推奨に
[5] OCI : Open Container Initiative
**コンテナイメージとランタイム標準仕様のイニシアティブ**
https://opencontainers.org/
- Linux Foundationプロジェクトの１つ
- コンテナ仮想化の標準仕様策定を目的として設立された
- 主に2つの仕様を策定している
- Runtime Specification (runtime-spec) ：コンテナランタイムとライフサイクル仕様
- Image Specification (image-spec)：コンテナイメージ仕様
- High-levelランタイムとLow-levelランタイムについてはこちら
[6] Open Tracing
**分散トレーシングのための標準仕様**
https://opentracing.io/
- 分散トレーシングのためのベンダ非依存のAPI仕様とライブラリを提供する
- ライブラリ対応言語：Go, JavaScript, Java, Python, Ruby, PHP, Objective-C, C++, C#
- Open Tracing互換の分散トレーシングツール例
[7] Operator Hub
**Kubernetes Operatorの共有リポジトリ**
https://operatorhub.io/
- 検証済みのKubernetes Operatorを検索、共有できるリポジトリサービス
そもそもKubernetes Operatorとは?
- Kubernetes上で主にステートフルなアプリケーション（データベースなど）をパッケージ、デプロイ、管理するためのフレームワーク
- 例えばデータベースの場合、バックアップ、障害対応、クラスタ管理、監視などの管理タスクを実装する必要があるが、そのようなオペレーションの自動化を目的とする
- 以下のKubernetes API拡張機能をベースとしてる
- CRD [Custom Resource Definitions]：Kubernetes APIを拡張して独自のリソース[Custom Resource]を定義する
- Custom Controller：Custom Resourceをコントロールするためのdeclarative API（宣言的なAPI）
参考）
https://qiita.com/MahoTakara/items/af4ad8ab69c24102bd72
https://www.redhat.com/ja/topics/containers/what-is-a-kubernetes-operator
https://www.sraoss.co.jp/tech-blog/pgsql/kubernetes-postgres-operator/