はじめに
Openshift Container Platform(以下OCP)はご存知の方が多いと思いますが、
実態はKubernetes(以下、k8s)となっています。
そのためk8sでも様々なCNI (Container Network Interface)が使用できるように、
OCPでもデプロイ時にCNIを選択することができます。
この記事では使用できるCNIについて軽くまとめようと思います。
この記事を書くに至った背景
業務の都合でWindows ContainerをデプロイできるOCP環境を構築しようとしていたところ、
CNIの都合でデプロイしなおしになったことが何度もあったので自分の調査結果をまとめておこうと思いました。
CNIとは
公式の記事ではこちらを参照ください。
KubernetesはPod同士のネットワークを確保するため様々なSDN(Software Defined Network)ソリューションを使用することができます。
OCPで使用することができる3rd party CNI Plug-inは下記にまとまっています。
その他OCPが標準で使えるCNI は下記の２つがあります。
1 Openshift-SDN
2 OVN-Kubernetes
3rd party製のCNIについては各ベンダーの記事に任せるとして、この記事では上記２つのCNIについてまとめたいと思います。
Openshift-SDNについて
Openshift SDNはOCP環境に対してはVXLANを使用して、Pod同士の疎通を可能とするCNIです。
VXLANを使用するCNIと言えばflannelが有名ですが、じゃあflannelと何が違うんでしょう。
詳細は下記記事をご覧ください
（きちんと黒沢も読み取れていませんので後日追記いたします。）
(ところで)VXLAN とは
パケットに対してさらにカプセリングを行うことでVLANに縛られないネットワークを構成することが可能です。
一方でカプセリングするするのでネットワーク機器側のMTUを大きくするか、
もしくはサーバ側のMTUを小さくする必要があります。
Openshift-SDN、Flannel共にサーバ側のMTUを小さくしています。
OVN-Kubernetesについて
詳細はこちらで確認
OVN KubernetesはVXLANではなくGeneveというプロトコルを使用してL2ネットワークを広げるという特徴があります。
少し難しい話になりますが、VXLANでは固定長のヘッダでカプセリングをしていましたが
Geneveでは非固定長のヘッダを用いています。
非固定長になるとじゃあ何が嬉しいの？という話になるわけですが
非固定長にすることでService Chaningという技術を実現することができます。
普通の通信をするときは最低限のカプセリングを行い、
セキュアな通信を行わないといけない場合はルーティングをいじることなく
セキュリティアプライアンスを通るようにするということも可能になるわけです。
ここでポイントになるのがルーティングはいじらなくて良いということです。
Openshift側がセキュリティレベルを通信毎に確認し、フラグが上がっているかどうかで通信をどこに飛ばすかを決定してくれます。
一方で課題もあり、Geneve自体に対応しているベンダーが少なくService chainingという世界観は実現できていません。
Geneveのカプセリングについての展望に興味がある方は以下の記事をご参照ください。
前職の北アジア担当CTOである進藤さんがわかりやすく解説をしてくれているblog 記事があります。
また、OVN KubernetesをOCP環境で使用するときのメリットはRed Hat社の織さんが記事を書いてくれていますのでぜひご参照ください。
加えて、OVN KubernetesにすることでWindows Nodeを追加可能になるなど、今後の展開が非常に楽しみなCNIです。
まとめ
3rd party製も含めてOCP環境で使えるCNIについてまとめてみました。
環境に応じて適用すべきCNIは異なりますので、ぜひ詳細を確認してからご選択をお願いいたします。
例：
シンプルなKVM環境、もしくは独立のコンテナ環境を作る -> Openshift-SDN
上記に加えてWindows node を使いたい、iptablesをあまり使いたくない -> OVN-Kubernetes
VMware NSXを使用した環境でOCP環境を構築したい -> Antrea、NSX-T
Cisco ACIを使っている -> Cisco ACI CNI
以上となります。ありがとうございました！