🥇Kubernetes のエンタープライズバージョンとしての OpenShift。パート1

「Kubernetes と OpenShift の違いは何ですか？」 – この疑問はうらやましいほど一貫して生じます。しかし、実際にはそれは、車とエンジンの違いは何かと尋ねるようなものです。例えを続けると、車は完成品です。文字通り、すぐに使用できます。乗り込んで走り出すだけです。一方、エンジンで目的地に到着するためには、まず他の多くのものを補って、最終的に同じ車を完成させる必要があります。

したがって、Kubernetes は、OpenShift ブランドの車 (プラットフォーム) を組み立てるエンジンであり、目標に導くものとなります。

この記事では、以下の重要なポイントについて改めて確認し、さらに詳しく説明します。

Kubernetes は OpenShift プラットフォームの中心です。また、Kubernetes は 100% 認定されており、完全にオープンソースで、独自の機能は一切ありません。要するに：
- OpenShift クラスターの API は 100% Kubernetes です。
- コンテナが他の Kubernetes システムで実行される場合、変更なしで OpenShift でも実行されます。アプリケーションに変更を加える必要はありません。
OpenShift は Kubernetes に便利な機能を追加するだけではありません。 OpenShift は自動車と同様に、すぐに使用でき、すぐに実稼働環境に導入できます。また、以下に示すように、開発者の生活を大幅に楽にします。これが、OpenShift が 2 つの顔を持つ理由です。開発者の観点から見ると、これは成功し、広く知られているエンタープライズクラスの PaaS プラットフォームです。同時に、産業運用の観点から見ても非常に信頼性の高い Container-as-a-Service ソリューションです。

OpenShiftは100% CNCF認証を取得したKubernetesです

OpenShiftは Kubernetes認定。そのため、適切なトレーニングを受けたユーザーは、kubectl の威力に驚嘆するのです。また、Kubernetes Cluster から OpenShift に移行したユーザーからは、kubeconfig を OpenShift クラスターにリダイレクトした後、既存のスクリプトがすべて問題なく動作するようになったとよく言われます。

おそらく、OC と呼ばれる OpenShift のコマンドラインユーティリティについて聞いたことがあるでしょう。 kubectl と完全にコマンド互換性があり、さまざまなタスクを実行するために使用できる便利なヘルパーもいくつか提供しています。しかし、まず、OC と kubectl の互換性についてもう少し詳しく説明します。

kubectlコマンド
OCチーム

kubectl get pod
oc ポッドを取得

kubectl 名前空間を取得する
oc 名前空間を取得する

kubectl create -f デプロイメント.yaml
oc create -f デプロイメント.yaml

OpenShift API で kubectl を使用した場合の出力は次のようになります。

• kubectl get pods – 予想どおり、ポッドを返します。

• kubectl get namespaces – 期待どおりに名前空間を返します。

kubectl create -f mydeployment.yaml コマンドは、以下のビデオに示すように、他の Kubernetes プラットフォームと同様に Kubernetes リソースを作成します。

つまり、すべての Kubernetes API は OpenShift で完全にアクセス可能であり、100% の互換性があります。それが理由です OpenShift が Cloud Native Computing Foundation (CNCF) の認定 Kubernetes プラットフォームとして認定されました.

OpenShift が Kubernetes に便利な機能をもたらす

Kubernetes API は OpenShift で 100% 利用可能ですが、標準の Kubernetes ユーティリティ kubectl には明らかに機能性と利便性が欠けています。そのため、Red Hat は Kubernetes を OC (OpenShift クライアントの略) や ODO (OpenShift DO、開発者向けのユーティリティ) などの便利な機能とコマンドラインツールで強化しました。

1. OCユーティリティ – Kubectlのより強力で便利なオプション

たとえば、kubectl とは異なり、新しい名前空間を作成してコンテキストを簡単に切り替えることができ、コンテナイメージの構築やソースコードまたはバイナリからのアプリケーションの直接デプロイ (Source-to-image、s2i) など、開発者にとって便利なコマンドが多数用意されています。

OC ユーティリティの組み込みヘルパーと拡張機能が日常業務の簡素化にどのように役立つか、例を見てみましょう。

1 番目の例は、名前空間の管理です。各 Kubernetes クラスターには常に複数の名前空間があります。これらは通常、開発環境と本番環境を作成するために使用されますが、たとえば、各開発者に個人用のサンドボックスを提供するためにも使用できます。実際には、kubectl は現在の名前空間のコンテキストで動作するため、開発者は名前空間を頻繁に切り替える必要が生じます。そのため、kubectl の場合、人々は積極的にヘルパースクリプトを使用します。しかし、OCを使用する場合、目的のスペースに切り替えるには、「oc プロジェクト名前空間」と言うだけで十分です。

必要な名前空間の名前が何なのか覚えていませんか?問題ありません。「oc get projects」と入力するだけで、完全なリストが表示されます。クラスター上の限られた名前空間のサブセットにしかアクセスできない場合、これがどのように機能するか疑問に思いますか?なぜなら、kubectl は、RBAC によってクラスター上のすべてのスペースの表示が許可されている場合にのみこれを正しく実行しますが、大規模なクラスターでは、すべてのユーザーがその権限を持っているわけではないからです。したがって、答えは次のとおりです。OC にとってこれはまったく問題ではなく、このような状況では完全なリストが簡単に提供されます。このような小さなことから、Openshift の企業としての焦点と、ユーザーとアプリケーションの観点から見たこのプラットフォームの優れたスケーラビリティが形成されます。

2. ODO – 開発者向けのkubectlの改良版

Red Hat OpenShift が Kubernetes に対して改善されたもう 1 つの例は、ODO コマンドラインユーティリティです。これは開発者向けに設計されており、開発者がローカルコードをリモートの OpenShift クラスターに迅速にデプロイできるようにします。また、再構築、レジストリへのプッシュ、イメージの再デプロイを行わずに、内部プロセスを合理化して、リモート OpenShift クラスター上のコンテナーへのすべてのコード変更を即座に同期することもできます。

OC と ODO によってコンテナと Kubernetes の操作がどのように簡単になるかを見てみましょう。

kubectl 上に構築された場合と、OC または ODO が使用された場合のいくつかのワークフローを比較してみましょう。

• YAML を知らない人のために OpenShift にコードをデプロイする:

Kubernetes / kubectl
$> gitクローン github.com/sclorg/nodejs-ex.git
1- コードからイメージを構築するDockerfileを作成する
-----
FROMノード
ワークディレクトリ/usr/src/app
パッケージ*.json ./をコピーします
index.js をコピーします。
コピー ./app ./app
npmインストールを実行します
露出3000
CMD [ “npm”, “start” ]
-----
2- イメージを構築する
$> podman ビルド …
3- レジストリにログイン
podman ログイン …
4- レジストリにイメージを配置する
ポッドマンプッシュ
5- アプリケーションをデプロイするためのyamlファイルを作成する（deployment.yaml、service.yaml、ingress.yaml） – これは最低限必要なことです
6- マニフェストファイルをデプロイします。
Kubectl を適用 -f します。

オープンシフト/oc
$> oc 新規アプリ github.com/sclorg/nodejs-ex.git – アプリケーション名

OpenShift / odo
$> gitクローン github.com/sclorg/nodejs-ex.git
$> odo コンポーネント nodejs myapp を作成する
$> オドプッシュ

• コンテキストの切り替え: 作業用名前空間または作業用クラスターの変更。

Kubernetes / kubectl
1- kubeconfigでプロジェクト「myproject」のコンテキストを作成する
2- kubectl set-context …

オープンシフト/oc
ocプロジェクト「myproject」

品質管理：「ここには興味深い機能が一つあります。まだアルファ版ですが。製品版に導入した方が良いでしょうか？」

レーシングカーに座っていて、「新しいタイプのブレーキを取り付けましたが、正直に言うと、まだ信頼性が十分ではありません…でもご心配なく、チャンピオンシップ中に積極的に改良していきます」と言われていると想像してみてください。この見通しはいかがでしょうか?私たち Red Hat は、実際にはそうは思っていません。 🙂

そのため、徹底的な戦闘テストを実施して安全に使用できると判断できるほど成熟するまで、アルファバージョンをリリースしないようにしています。通常、すべてはまず開発プレビュー段階を経て、その後技術プレビューそして、一般公開される一般提供（GA）はすでに本番環境に使用できるほど安定しています。

何故ですか？なぜなら、他のソフトウェア開発と同様に、Kubernetes における初期のアイデアのすべてが最終リリースに反映されるわけではないからです。あるいは、目標に到達し、意図した機能も保持しているものの、実装がアルファ版のものと根本的に異なる場合もあります。何千もの Red Hat のお客様が OpenShift を使用してミッションクリティカルなワークロードをサポートしているため、私たちはプラットフォームの安定性と長期サポートに非常に重点を置いています。

Red Hat は、OpenShift リリースを頻繁にリリースし、それに付属する Kubernetes のバージョンを更新することに取り組んでいます。たとえば、この記事の執筆時点での OpenShift 4.3 の現在の GA リリースには Kubernetes 1.16 が組み込まれていますが、これはアップストリームの Kubernetes バージョン 1.17 より XNUMX バージョン古いものです。このようにして、お客様にエンタープライズクラスの Kubernetes を提供し、新しい OpenShift バージョンのリリース時に追加の品質管理を提供するよう努めています。

ソフトウェア修正：「本番環境で使用しているKubernetesのバージョンに脆弱性がありました。3バージョンアップグレードしないと修復できません。他に何か方法はあるのでしょうか？」

オープンソースの Kubernetes プロジェクトでは、ソフトウェアの修正は通常、次のリリースの一部としてリリースされますが、場合によっては 6 つまたは XNUMX つの前のマイナーリリースにまたがり、最短 XNUMX か月前までカバーされます。

Red Hat は、重要な修正を他社よりも早くリリースし、より長期間のサポートを提供することに誇りを持っています。例えば、Kubernetesの権限昇格の脆弱性（CVE-2018-1002105): これは Kubernetes 1.11 で発見され、以前のリリースの修正は 1.10.11 までしかリリースされなかったため、1.x から 1.9 までのすべての以前の Kubernetes リリースにこのホールが残っていました。

ターンでは、 Red Hat、OpenShift を 3.2 にパッチ適用（Kubernetes 1.2がインストールされています）、XNUMXつのOpenShiftリリースをキャプチャし、顧客ケアを明確に示しています（詳細ここで).

OpenShiftとRed HatがKubernetesをいかに推進しているか

Red Hat は、オープンソース Kubernetes プロジェクトへの貢献度では Google に次いで 3 番目に大きく、上位 5 社のうち XNUMX 社は Red Hat の従業員です。あまり知られていないもう XNUMX つの事実: 多くの重要な機能が Red Hat の主導で Kubernetes に導入されました。特に次の機能が挙げられます。

RBAC。 Red Hat のエンジニアが OpenShift の追加機能としてではなく、プラットフォーム自体の一部として実装することを決定するまで、Kubernetes には RBAC 機能 (ClusterRole、ClusterRoleBinding) はありませんでした。 Red Hat は Kubernetes の改良を恐れているのか?もちろん違います。Red Hat はオープンソースの原則に厳密に従っており、Open Core のゲームは行いません。独自のものではなくコミュニティレベルで実装される改善と革新は、より実行可能になり、より広く採用されるようになります。これは、オープンソースソフトウェアをお客様にとってより便利なものにするという当社の全体的な目標とよく一致しています。
ポッドセキュリティポリシー。ポッド内でアプリケーションを安全に実行するというこの概念は、もともと OpenShift で SCC (Security Context Constraints) という名前で実装されていました。そして、前の例と同様に、Red Hat はこれらの開発をオープンソースの Kubernetes プロジェクトに組み込んで、誰もが使用できるようにすることを決定しました。

この一連の例はまだまだ続きますが、ここでは Red Hat が Kubernetes を進化させ、誰にとってもより良いものにすることに真剣に取り組んでいることを示したいと考えました。

はい、OpenShift は Kubernetes です。違いは何でしょうか? 🙂

ここまで読んでいただければ、Kubernetes が OpenShift のコアコンポーネントであることがおわかりいただけたかと思います。主なものですが、唯一のものではありません。つまり、Kubernetes をインストールするだけでは、エンタープライズクラスのプラットフォームは実現できません。認証、ネットワーク、セキュリティ、監視、ログ管理などを追加する必要があります。また、利用可能なツールの膨大な数の中から難しい選択を迫られることになります（エコシステムの多様性を理解するには、 CNCF図) を作成し、それらが 1 つとして機能できるように、何らかの方法で一貫性と一貫性を確保します。さらに、使用するコンポーネントの新しいバージョンがリリースされるたびに、定期的に更新と回帰テストを実行する必要があります。つまり、プラットフォーム自体の作成と維持に加えて、このソフトウェアすべてを扱う必要もあります。ビジネス上の問題を解決し、競争上の優位性を獲得するために、残された時間は多くないでしょう。

しかし、OpenShift では、Red Hat がこれらの複雑さをすべて引き受け、Kubernetes 自体だけでなく、Kubernetes を真のエンタープライズクラスのソリューションに変換し、すぐに安心して本番環境に導入できるために必要なオープンソースツールの完全なセットも含む、機能的に完全なプラットフォームを提供します。もちろん、独自のテクノロジースタックをお持ちの場合は、OpenShift を既存のソリューションに統合できます。

OpenShiftはスマートなKubernetesプラットフォームです

上の画像をご覧ください。Kubernetes の四角形の外側にある部分はすべて、Kubernetes にはない機能を Red Hat が追加した領域です (いわば設計によるものです)。それでは、これらの分野の主なものを見ていきましょう。

1. ベースとなる信頼性の高いOS: RHEL CoreOSまたはRHEL

Red Hatは20年以上にわたり、業界をリードするプロバイダーであり続けています。 Linuxミッションクリティカルなビジネスアプリケーション向けのディストリビューション。この分野における当社の広範かつ継続的に更新される経験により、産業用コンテナ展開のための真に信頼できる基盤を提供できます。RHEL CoreOS は RHEL と同じカーネルを使用しますが、コンテナの実行や Kubernetes クラスタでの実行などのタスクに最適化されています。サイズが小さく、不変性があるため、クラスタの設定、自動スケーリング、パッチの展開などが簡素化されます。これらの機能により、ベアメタルからプライベートクラウドやパブリッククラウドまで、幅広いコンピューティング環境で一貫した OpenShift ユーザーエクスペリエンスを提供するための理想的な基盤となります。

2. IT運用の自動化

インストールと Day 4 操作 (日常的な操作) の自動化は OpenShift の強みであり、これにより、コンテナプラットフォームを最高レベルで管理、更新、保守することがはるかに容易になります。これは、OpenShift XNUMX カーネルレベルでの Kubernetes オペレーターのサポートを通じて実現されます。

OpenShift 4は、Red Hat自身とサードパーティのパートナーによって開発されたKubernetesオペレーターに基づくソリューションの完全なエコシステムでもあります（オペレーターのディレクトリ Red Hat、またはオペレーターストアオペレーターハブ（Red Hat がサードパーティ開発者向けに作成したもの）

OpenShift 4の統合カタログには180以上のKubernetesオペレーターが含まれています

3. 開発者ツール

2011年以来、OpenShiftはPaaS（Platform-as-a-Service）プラットフォームとして提供されており、開発者の生活を大幅に簡素化し、コードの作成に集中できるようにし、Java、Node.js、PHP、Ruby、Python、Goなどのプログラミング言語のサポートを組み込み、継続的インテグレーションとデリバリーサービスCI/CD、データベースなどを提供しています。OpenShift 4は、豊富なカタログこれには、Red Hat とそのパートナーが開発した Kubernetes オペレーターに基づく 100 を超えるサービスが含まれます。

Kubernetesとは異なり、OpenShift 4には専用のグラフィカルインターフェース（開発者コンソール) は、開発者がさまざまなソース (git、外部レジストリ、Dockerfile など) からアプリケーションを名前空間に簡単にデプロイし、アプリケーションコンポーネント間の関係を明確に視覚化するのに役立ちます。

開発者コンソールは、アプリケーションコンポーネントを視覚的に表示し、Kubernetesでの作業を容易にします。

さらに、OpenShift は、次のような Codeready 開発ツールスイートを提供します。コードレディワークスペースは、OpenShift 上で直接実行され、IDE-as-a-Service アプローチを実装する、Web インターフェースを備えた完全にコンテナ化された IDE です。一方、厳密にローカルで作業したい人には、ラップトップに展開できる OpenShift 4 の完全機能バージョンである Codeready Containers があります。

Kubernetes/OpenShift プラットフォーム上で効率的な開発を実現する統合 IDE サービス

OpenShiftは、コンテナ化されたJenkinsとプラグインを通じて、すぐに使える完全なCI/CDシステムを提供します。 DSL パイプラインやKubernetes指向のCI/CDシステムを扱う場合 Tekton (現在はテクニカルプレビュー版です)。これら 2 つのソリューションは OpenShift コンソールと完全に統合されており、パイプライントリガーの実行、デプロイメントやログの表示などが可能になります。

4. アプリケーションツール

OpenShift は、従来のステートフルアプリケーションと、マイクロサービスやサーバーレスなどの新しいアーキテクチャに基づくクラウドネイティブソリューションの両方の導入を可能にします。 OpenShift Service Mesh ソリューションには、Istio、Kiali、Jaeger など、マイクロサービスを維持するための主要なツールがすぐに使用できます。一方、OpenShift Serverless ソリューションには、Knative だけでなく、OpenShift プラットフォーム上で Azure 機能を提供するための Keda など、Microsoft との共同イニシアチブの一環として作成されたツールも含まれています。

OpenShift ServiceMesh統合ソリューション（Istio、Kiali、Jaeger）はマイクロサービスの開発に役立ちます

レガシーアプリケーションとコンテナー間のギャップを埋めるために、OpenShift では Container Native Virtualization (現在 TechPreview 段階) を使用して仮想マシンを OpenShift プラットフォームに移行できるようになりました。これにより、ハイブリッドアプリケーションが実現し、プライベートクラウドとパブリッククラウドの両方でアプリケーションを移動しやすくなります。

仮想マシン Windows 2019 Virtual、コンテナネイティブ仮想化（現在テクニカルプレビュー版）を介してOpenShift上で動作

5. クラスターツール

あらゆるエンタープライズクラスのプラットフォームには、監視および集中ログサービス、セキュリティメカニズム、認証および承認、ネットワーク管理ツールが必要です。 OpenShift はこれらすべてをすぐに使用できる状態で提供し、ElasticSearch、Prometheus、Grafana などのソリューションを含め、すべて 100% オープンソースです。これらのソリューションにはすべて、Red Hat の広範なクラスター監視の専門知識を使用して事前構成および構成されたダッシュボード、メトリック、アラートが付属しており、最初から実稼働環境を効果的に監視および追跡できます。

OpenShift には、組み込みの OAuth プロバイダーによる認証、LDAP、ActiveDirectory、OpenID Connect などの認証情報プロバイダーとの統合など、企業顧客にとって重要な要素も備わっています。

OpenShift クラスターを監視するための事前構成済みの Grafana ダッシュボード