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

「Kubernetes と OpenShift の違いは何ですか?」 – この質問は、うらやましいほどの一貫性を持って生じます。 しかし実際には、これは車とエンジンがどう違うのかを問うようなものです。 たとえを続けると、車は完成品であり、文字通りすぐに使用できます。乗ってすぐに使えます。 一方で、エンジンがあなたをどこかに連れて行ってくれるには、最終的に同じ車を得るために、まず他の多くのものを補わなければなりません。

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

この記事では、次の重要な点を思い出していただき、もう少し詳しく検討していきたいと思います。

• Kubernetes は OpenShift プラットフォームの中心であり、100% 認定された Kubernetes であり、完全にオープンソースであり、独占的な性質はまったくありません。 簡単に言うと:
  • OpenShift クラスター API は XNUMX% Kubernetes です。
  • コンテナーが他の Kubernetes システム上で実行される場合、コンテナーは何も変更せずに OpenShift 上で実行されます。 アプリケーションを変更する必要はありません。
• OpenShift は、便利な機能を Kubernetes に追加するだけではありません。 車と同じように、OpenShift は箱から出してすぐに実稼働環境に導入でき、以下に示すように、開発者の作業を大幅に楽にします。 OpenShift が XNUMX 人のメンバーで団結しているのはそのためです。 これは、開発者の観点からは成功しており、よく知られているエンタープライズ クラスの PaaS プラットフォームでもあります。 同時に、これは産業運用の観点から非常に信頼性の高い Container-as-a-Service ソリューションです。

OpenShift は 100% CNCF 認定を受けた Kubernetes です

OpenShift は以下に基づいています Kubernetes 認定済み。 したがって、適切なトレーニングを終えると、ユーザーは kubectl のパワーに驚きます。 また、Kubernetes クラスターから 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 は 100% の互換性を維持しながら OpenShift で完全に利用可能です。 それが理由です OpenShift は、Cloud Native Computing Foundation (CNCF) によって認定された Kubernetes プラットフォームとして認められています. 

OpenShift は Kubernetes に便利な機能を追加します

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

1. OC ユーティリティ - Kubectl のより強力で便利なバージョン

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

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

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

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

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

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

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

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

• YAML を理解できない人のための OpenShift へのコードのデプロイメント:

Kubernetes/kubectl
$>git クローン github.com/sclorg/nodejs-ex.git
1- コードからイメージを構築する Dockerfile を作成する
-----
FROMノード
WORKDIR /usr/src/app
パッケージ*.json ./をコピーします
Index.js ./ をコピーします。
コピー ./app ./app
npmインストールを実行します
露出3000
CMD [「npm」、「開始」] ————–
2- イメージを構築します
$>ポッドマン ビルド...
3- レジストリにログインします
ポッドマンログイン...
4- イメージをレジストリに配置します
ポッドマンプッシュ
5- アプリケーションのデプロイメント用の yaml ファイル (deployment.yaml、service.yaml、ingress.yaml) を作成します。これは絶対的な最小限です。
6- マニフェスト ファイルを展開します。
Kubectl apply -f 。

OpenShift/oc
$> oc 新しいアプリ github.com/sclorg/nodejs-ex.git – 私たちのアプリケーション名

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

• コンテキストスイッチ: 作業ネームスペースまたは作業クラスタを変更します。

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

OpenShift/oc
ocプロジェクト「マイプロジェクト」

品質管理: 「興味深い機能が XNUMX つありますが、まだアルファ版です。 もしかしたら製品化できるかも？」

レーシングカーに座っていて、次のように言われたと想像してみてください。「新しいタイプのブレーキを導入しましたが、正直に言うと、その信頼性はまだ十分ではありません...しかし、心配しないでください。レース中に積極的に改良していきます」チャンピオンシップ。" この見通しはいかがですか？ 私たち 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 のバージョンにホールがありました。 そして、XNUMX つのバージョンを更新することによってのみそれを閉じることができます。 それとも何か選択肢があるのでしょうか？

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 はオープンソースの原則に従っており、オープンコア ゲームをプレイしていないからです。 プロプライエタリなものではなく、開発コミュニティによって推進される改善とイノベーションは、より実行可能であり、より広く採用されており、これは、オープンソース ソフトウェアをお客様にとってより役立つものにするという当社の中核目標とよく一致しています。
• ポッドのセキュリティ ポリシー (ポッド セキュリティ ポリシー)。 ポッド内でアプリケーションを安全に実行するというこの概念は、もともと SCC (Security Context Constraints) という名前で OpenShift に実装されました。 そして、前の例と同様に、Red Hat はこれらの開発をオープンな Kubernetes プロジェクトに導入し、誰もが使用できるようにすることにしました。

この一連の例を続けることもできますが、私たちは Red Hat が Kubernetes の開発とそれをすべての人にとってより良いものにすることに真剣に取り組んでいることを示したかっただけです。

OpenShift が Kubernetes であることは明らかです。 違いは何ですか? 🙂

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

しかし、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運用の自動化

インストール プロセスと 4 日目の操作 (つまり、日常的な操作) の自動化は OpenShift の強みであり、コンテナ プラットフォームの管理、更新、パフォーマンスを最高レベルで維持することがはるかに簡単になります。 これは、OpenShift XNUMX カーネル レベルでの Kubernetes オペレーターのサポートによって実現されます。

OpenShift 4 は、Red Hat 自体とサードパーティ パートナーの両方によって開発された、Kubernetes オペレーターに基づくソリューションのエコシステム全体でもあります (「OpenShift XNUMX」を参照)。 オペレーターディレクトリ Red Hat、またはオペレーターストア オペレーターハブ.io、サードパーティ開発者向けに 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 には専用の GUI (開発者コンソール) を使用すると、開発者はさまざまなソース (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 (現在は技術プレビュー版です)。 これらのソリューションはどちらも OpenShift コンソールと完全に統合されており、パイプライン トリガーの実行、デプロイメント、ログなどの表示が可能です。

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

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

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

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

コンテナ ネイティブ仮想化を介して OpenShift 上で実行される Windows 2019 仮想仮想マシン (現在はテクニカル プレビュー バージョン)

5. クラスター用ツール

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

OpenShift には、組み込みの oauth プロバイダーによる認証、LDAP、ActiveDirectory、OpenID Connect などの資格情報プロバイダーとの統合など、企業顧客にとって重要な機能も標準装備されています。

OpenShift クラスター監視用に事前設定された Grafana ダッシュボード

OpenShift クラスター監視用の 150 を超える事前構成された Prometheus メトリクスとアラート

つづきます

以下の図に示すように、ソリューションの豊富な機能と Red Hat の Kubernetes 分野での豊富な経験が、OpenShift が市場で支配的な地位を獲得した理由です (詳細を読む) ここで).

「Red Hat は現在、44% のシェアで市場をリードしています。
同社は顧客中心の販売戦略の恩恵を享受しており、最初にエンタープライズ開発者にコンサルティングとトレーニングを行ってから、企業がコンテナを実稼働環境に導入し始めるにつれて収益化に移行します。」

（出典： www.lightreading.com/nfv/containers/ihs-red-hat-c​​ontainer-strategy-is-paying-off/d/d-id/753863)

この記事をお楽しみいただければ幸いです。 このシリーズの今後の投稿では、ここで説明する各カテゴリにおける Kubernetes に対する OpenShift の利点を詳しく見ていきます。

出所： habr.com