Kubernetesと比較したOpenShiftの特徴

OpenShift

はじめに

転職を機にOpenShiftばかり触っています。最近はだんだんと慣れてきたので、この辺でKubernetesとOpenShiftの違いについて、わかりやすそうにまとめてみます。わかりやすくするために、「違い」と言ってもあまり細かい話はしません。例えばコンテナランタイムとかCNIとかS2iとか、細かい話は今回書きません。また、記載する情報は執筆時点(2020年8月)のものであることにご注意ください。

KubernetesとOpenShiftの違い

Kubernetesは”カーネル”、OpenShiftは”ディストリビューション”

Red HatのOpenShift and Kubernetes: What’s the difference?という記事の中にある表現です。いろいろ考えましたが、この表現が一番しっくりくると思います。

「Kubernetesはクラウドネイティブ時代のLinuxだ」という言葉をよく聞きます1。これはKubernetesが、あるレイヤー以下を抽象化するソフトウェアで、開発はコミュニティ主導で行われているという点等で、Linuxと似ているからだそうです。

Linuxの例えでKubernetesは”カーネル”だとすると、OpenShiftは”ディストリビューション”です。LinuxカーネルとRHELのような関係だと考えるとすっきりするかもしれません。Kubernetesは”カーネル”として、コンテナオーケストレーションのための基本的な機能を提供します。OpenShiftは”ディストリビューション”なので、Kubernetesをベースとして、開発元(RedHat)がさまざまな機能やツールを同梱し出荷します。こんなイメージです。

当然、EKSやGKEとOpenShiftも同列には扱えません。EKSやGKEはのようなKubernetesのマネージドサービスで、UpstreamのKubernetesクラスタをホスティング・運用してくれるサービスです。Kubernetesの”ディストリビューション”であるOpenShiftのマネージドサービスとしては、例えばRed Hat OpenShift Dedicatedがあります。



OpenShiftにはOperatorがいっぱいいる

そもそもOperatorとは、Kubernetes上で運用者に代わって、アプリケーションの独自運用を自動化するソフトウェアです。その実態は、主にカスタムリソース定義(CRD)とカスタムコントローラーです。Kubernetesの他のコントローラーと同様にReconciliation loopを使って宣言的に管理されます。

Kubernetesをベースに追加したOpenShift独自の機能の多くは、Operatorとして実現されています。これはOpenShift4の大きな特徴です。実際oc get clusteroperatorとすると、OpenShift上にたくさんのOperatorが存在するのがわかるはずです。

OperatorHubから、追加でOperatorを導入することもできます。他のベンダーやコミュニティが開発したOperatorも含まれます。Red HatがサポートするOperatorの詳細は、Red Hat Operatorsに記載されています。

Operatorやカスタムコントローラーについてさらに知りたい場合は、以下の書籍がオススメです。

  • Programming Kubernetes: Developing Cloud-native Applications

カスタムコントローラーやOperatorといったKubernetesネイティブなアプリケーションを開発する手法について書いています。Kubernetes APIの仕組みや拡張方法、ツールを使ってカスタムコントローラーを自作するなど、とても楽しい本です。ただし英語版しかありません。

  • 実践入門 Kubernetesカスタムコントローラーへの道

KubernetesでCRDとカスタムコントローラーを自作するための概要、ツールの使い方が書いてあります。Kubernetesに組み込まれているコントローラーのコードを読んでいく部分もあるので、Kubernetesの実装を深く学びたい方にもオススメだと思います。日本語だし、Kindleだと価格も安いのも利点です。

インストールにおける違い

KubernetesとOpenShiftのインストールにおいては、大きく以下の2つの違いがあります。

  • クラスタのノードとなるVMのOS
  • インストール方法

もちろん他にもあります。例えば、インストールの前提となるコンピューティングリソースの要件やネットワークの要件などです。

クラスタのノードとなるVMのOS

Kubernetesは、UbuntuやRHEL、CoreOSといったLinux OSのVMをノードとして、クラスタを構成できます。Windowsコンテナを利用したいなどの特殊なケースでは、ノードのOSにWindows Server 20192を使うこともできるようです。僕はやったことありません。

一方、OpenShiftでは以下のOSのみサポートされています。

  • Masterノード: RHCOS
  • Workerノード: RHEL or RHCOS

コンテナオーケストレーションに最適化されたRHEL CoreOS(RHCOS)を利用するのが便利です。WorkerノードではRHELを使うこともできますが、クラスターインストールやアップグレードの際に一手間必要になります。3

インストール方法

Kubernetesのインストールには、さまざまなツールがあります。kubeadmを使ってクラスタを構築することが多いようです。小規模環境環境として、minikubeKindなどを利用することもできます。当然ですが、すべて無償で利用できます。

OpenShiftのインストールには、2つの種類があります。IPI(Installer Provisioned Infrastructure)とUPI(User Provisioned Infrastructure)です。

  • IPI: インストールに必要なインフラ環境(ネットワークやVMなど)を、インストーラーが自動で構築した後、OpenShiftをインストールする
  • UPI: ユーザーがインフラ環境を用意する前提で、そこにインストーラーがOpenShiftをインストールする

IPIが便利ですが、利用できる環境が限られているため、オンプレにクラスタを構築する際は、UPIが使われることが多いです。インストールするには、サブスクリプションを購入する必要があります。無償版で検証したい場合は、okdRed Hat CodeReady Containers(CRC)を利用できます。

CRCでは、minikubeのような1ノードクラスタでOpenShift4の機能を触ってみることができます。利用方法は、以前まとめましたので、是非触ってみてください。

Red Hat CodeReady Containersで、OpenShift 4をローカルでお手軽に試す
NishipyOpenShift 4 の簡易版であるCodeReady Containersを、自宅ラップトップに導入したときのメモです。はじめにOpenShiftRed Hat社が提供するコンテナオーケストレーションプ...(続く)

リソースの違い

Kubernetesでおなじみのリソース(Pod, Deployment, Service, Ingressなど)に加えて、OpenShiftでは以下のような独自のリソースが提供されています。個々の説明は、別の記事で行う予定ですので、今回は割愛します。

  • Project
  • DeploymentConfig
  • BuildConfig
  • Route
  • ImageStream
  • ImageStreamTag など



CLIの違い – kubectl と oc

Kubernetesでは、おなじみのkubectlコマンドを使って、APIリクエストを発行できます。

OpenShiftクラスタへの一般的なAPIリクエストもkubectlコマンドを使って行えます。ocコマンドでは、kubectlと同様のことが行える上、前述のOpenShift独自のリソースに関する操作やOAuth認証をサポートしています。4

さいごに

Kubernetesユーザーから見たOpenShiftとKubernetesの違いについて、ふんわりとまとめてみました。次回以降は、OpenShift固有のリソースについて、記事にする予定です。

以上.

コメント