企業におけるコンテナ技術の導入に関する 9 つの重要な課題

[51CTO.com からのオリジナル記事] コンテナ テクノロジーは現在、幅広い注目を集めており、独自のクラウド インフラストラクチャを構築するためにコンテナ テクノロジーを導入または採用し始めている企業がますます増えています。

[[213946]]

コンテナを使用して新しいマイクロサービス アプリケーション アーキテクチャを設計する場合、または既存のアプリケーションを変換する場合は、コンテナ プラットフォームを実装するときに考慮する必要がある要素と関連機能について理解する必要があります。

多くの伝統産業やインターネット企業と比較すると、多くの伝統産業はコンテナ技術の面で後からスタートしました。しかし、過去2年間でコンテナへの注目が高まるにつれ、企業は急速な進歩を遂げ、コンテナ関連の機能の構築を積極的に推進してきました。

Docker ベースのコンテナは、より軽量な形式の仮想化であり、CaaS (コンテナ レベル サービス) と呼ばれます。 IaaSとPaaSの両方の利点をカバーし、アプリケーションの導入、開発と運用、マイクロサービスなどの問題を解決し、ビジネスデリバリーをより迅速に加速することができます。

コンテナを導入して有効活用するには、企業はコンテナ テクノロジーを適用する前に、次の 9 つの重要な問題を考慮する必要があります。

• エンタープライズ コンテナ クラウド ソリューションを設計する際には、どのような原則に従う必要がありますか?
• コンテナクラウドテクノロジー製品を選択するには？
• コンテナ クラウド ネットワークはどのように設計すればよいでしょうか?
• コンテナ用の永続ストレージ ソリューションを選択して設計するにはどうすればよいでしょうか?
• コンテナ クラウド上で集中ログ管理を設計するにはどうすればよいでしょうか?
• コンテナ アプリケーションの監視ソリューションを設計するにはどうすればよいですか?
• コンテナ クラウドのマルチテナントと権限を設計するにはどうすればよいでしょうか?
• コンテナを OpenStack および Kubernetes と統合する機能はありますか?
• コンテナ クラウドはどのようにして高可用性とリージョン間展開を実現するのでしょうか?

エンタープライズ コンテナ クラウド ソリューションを設計する際には、どのような原則に従う必要がありますか?

新世代のクラウド コンピューティング テクノロジーとして、Docker は間違いなく仮想化の開発と運用、マイクロサービス、継続的インテグレーションと継続的デリバリー、従来のミドルウェアとアプリケーション全体に大きな変化をもたらし、より高いパフォーマンスと効率を実現します。では、エンタープライズ コンテナ ソリューションの設計ではどのような原則に従うべきでしょうか?

まず、企業がコンテナクラウドを利用する目的を明確にする必要があります。コンテナはビジネスに役立ち、あらゆるテクノロジーはビジネスにさらに役立つように設計されています。これが私たちの出発点です。

次に、ビジネスの特性に基づいて適切なコンテナ フレームワークを選択します。たとえば、新しいマイクロサービス アーキテクチャに基づいてビジネス自体を変革できるかどうか、また、ビジネスが迅速な変更、高い柔軟性、迅速な更新と反復という特性を備えているかどうかなどです。

既存のシステムとの統合を強化することも必要です。コンテナを使用する前に、企業は通常、ネットワーク システム、集中監視システム、セキュリティ保護システムなど、比較的成熟した安定した IT システムをすでに持っています。

構築の重複を避け、コンテナ プラットフォームをより受け入れやすく、より使いやすくするために、コンテナ プラットフォームをゼロから構築するのではなく、会社の既存の IT システム全体に統合する必要があります。

実稼働ビジネスを実行するには、コンテナ プラットフォームは、セキュリティ レベルの異なるアプリケーションの分離、アプリケーション コンテナのセキュリティ脆弱性スキャンのサポート、安全で効果的なファイアウォール ポリシー管理など、セキュリティ規制のコンプライアンス要件も満たす必要があります。

実稼働環境のビジネス要件は高可用性と継続性であり、コンテナ アプリケーション層全体の高可用性、データ継続性、セキュリティ、信頼性も考慮する必要があります。

コンテナ プラットフォームを構築する目的は、アプリケーションに柔軟性、弾力性、リソースの節約などの利点をもたらすことです。これらの利点をより有効に活用するには、アプリケーションにマイクロサービス アーキテクチャやステートレスなどの特性が備わっている必要があります。

ただし、コンテナ化に適さないアプリケーションを強制すべきではありません。そうしないと、コンテナ プラットフォームが構築後にアプリケーションやビジネスに期待された価値をもたらさなかった場合、多くの企業投資が無駄になるだけでなく、コンテナ プラットフォームの価値が認識されないことにもなります。これは、コンテナ プラットフォームの構築に多大なエネルギーと熱意を注いできたすべての人にとって、最も見たくない結果です。

コンテナクラウドテクノロジー製品を選択するには？

テクノロジの選択の問題には、技術的および非技術的な多くの複雑な影響要因があり、組織によって異なります。

企業は、新しいテクノロジーを適用する前に、開発能力や運用・保守能力などのIT部門の技術力、開発プラットフォーム、開発プロセス、開発仕様などから自社の業務システムに関する意思決定能力も考慮する必要があります。

自社の開発力や運用保守力が十分でない場合は、PCF や OpenShift などの成熟したソリューションを採用するのが良い選択です。

監視、ネットワーク、セキュリティ要件など、既存のシステムに接続するための要件を考慮する場合、特に既存のネットワーク アーキテクチャがコンテナーのネットワーク ソリューションに大きな影響を与える場合は、カスタマイズが容易で、既存の IT システムとの統合が容易な Kubernetes、Mesos、Swarm などのオープン ソース ソリューションの使用を検討する必要があります。

Kubernetes、Mesos、Swarm は、リソース オーケストレーションの業界で人気のある 3 つのオープン ソース ソリューションですが、それぞれに独自の利点があります。

アプリケーションのリリースという観点から、Docker の Swarm 機能、Kubenetes のオーケストレーション、Mesos のスケジュール管理のどれが優れているかを直接判断することは困難です。

つまり、コンテナ テクノロジの選択を支援するために、エンタープライズ レベルのアプリケーション シナリオを追加する方が意味があるということです。

企業は大きくなく、アプリケーションもそれほど複雑ではない

現時点では、Docker Swarm Mode はまだ比較的使いやすいです。クラスターのメンテナンスには Zookeeper は必要ありません。 Etcd が組み込まれており、コマンドラインは Docker と同じくらい使いやすく、サービス検出と DNS が組み込まれており、オーバーレイ ネットワークが組み込まれています。

企業はより大規模になり、アプリケーションは十分に複雑になります

現時点では、クラスターの規模は数百のノードに及び、Docker Swarm Mode の使用を望まず、代わりに Mesos や Marathon を使用する人が多くいます。

Mesos は非常に優れたスケジューラであるため、2 層のスケジューリング メカニズムにより、クラスターの規模を大幅に拡大できます。 Mesos の利点は、第 1 層のスケジューリングで最初にノード全体がフレームワークに割り当てられることです。 Framework スケジューラが直面するクラスターの規模ははるかに小さいため、その中で二次スケジューリングが実行されます。

複数のマラソンなど、複数のフレームワークがある場合、競合することなく並行してスケジュールできます。同時に、Mesos は従来のデータコンピューティングにおける導入事例も多く、企業が選択する際に考慮する要素の 1 つでもあると考えられます。

大規模な企業規模、複雑なビジネス、より細かいアプリケーションの粒度

現時点では、Kubernetes モジュールは Marathon や Mesos よりも細かく多くのモジュールに分かれており、機能も豊富で、モジュールは完全に疎結合されているため、非常に便利にカスタマイズできるため、Kubenetes の方が適しています。

さらに、Kubernetes は強力な自動化メカニズムを提供するため、その後のシステム運用と保守の難易度とコストが大幅に削減されます。さらに、Kubernetes コミュニティの人気により、Kubernetes を使用する企業は迅速にサポートを受けることができ、問題やバグの解決が容易になります。

新しいテクノロジーにはそれぞれ適用可能なシナリオがあります。実践のテストに耐え、新しいテクノロジーを生産性に変える方法が最優先事項です。

コンテナ クラウド ネットワークはどのように設計すればよいでしょうか?

Docker の哲学は常に「シンプルさは美しさ」です。 Linux ネットワーク プロトコル スタック上での Docker の動作から、Docker は当初、マルチホスト相互接続のネットワーク ソリューションを考慮していなかったことがわかります。

Docker が有名になった後、ネットワーク ソリューション企業である Socketplane を買収し、元のネットワーク部分を別の Docker ネットワーク ライブラリである libnetwork に分離しました。

libnetwork は 5 つのドライバーを実装しており、ユーザーはプラグインの形式でニーズに応じてネットワーク ドライバーを実装できます。ただし、libnetwork コンポーネントは、Docker プラットフォームのネットワーク サブシステムを独立したライブラリにモジュール化する単純な試みにすぎず、成熟度と完成度にはまだ程遠い状態です。

コンテナ技術が企業の生産システムに徐々に実装されるにつれて、コンテナ クラウドのネットワーク特性に対するユーザーの要件はますます高くなり、ホスト間のコンテナ間のネットワーク相互運用性が最も基本的な要件になりました。

クロスホスト コンテナ ネットワーク ソリューションは、次の 3 つのカテゴリに分類されます。

トンネルソリューション

たとえば、Flannel の VxLan では、基盤となるネットワークに対する要件はそれほど高くありません。一般的に言えば、レイヤー 3 で到達可能であれば、レイヤー 3 到達可能ネットワーク内にトンネルベースのコンテナ ネットワークを構築できます。

しかし、問題も明らかです。誰もが同意する点の 1 つは、ノードのサイズが大きくなるにつれて複雑さが増し、ネットワークの問題を追跡することがより困難になるということです。大規模クラスターの場合、この点は考慮する必要がある。

ルーティングソリューション

ルーティング技術により、NAT を使用せずに第 3 層でホスト間のコンテナ相互通信を高効率で実現し、現在のネットワークと統合できます。各コンテナには、仮想マシンのようにビジネス IP を割り当てることができます。

ただし、ルーティング ネットワークにも問題があります。ルーティング ネットワークは、既存のネットワーク機器に比較的大きな影響を与えます。ルーターのルーティング テーブルにはスペース制限があり、通常は 20,000 ～ 30,000 エントリです。コンテナのほとんどのアプリケーション シナリオでは、多数のセットを持つマイクロサービスが実行されます。

数万の新しいコンテナ IP アドレスがルーティング テーブルに追加されると、基盤となる物理デバイスは負荷を処理できなくなります。さらに、各コンテナにはビジネス IP アドレスが割り当てられますが、これはすぐに消費されます。

仮想LAN

すべてのコンテナと物理マシンは同じ VLAN 内にあります。以下はネットユーザーからのテストレポートです。

図では、Calico のソリューションと HOST ベースのネットワーク ソリューションの方がパフォーマンスが優れていることがわかります。

HOST に基づくポートの競合やネットワーク リソースの競合はさらに厄介です。相対的に言えば、Calico は純粋な 3 層 SDN 実装です。これは、BPG プロトコルと Linux 独自のルーティングおよび転送メカニズムに基づいています。特別なハードウェアに依存せず、NAT やトンネルなどのテクノロジーも使用しません。

物理サーバー、仮想マシン (OpenStack など)、またはコンテナ環境に簡単に導入できます。同時に、組み込みの Iptables ベースの ACL 管理コンポーネントは非常に柔軟で、より複雑なエンタープライズ セキュリティ分離のニーズを満たすことができます。

コンテナ アプリケーションのネットワーク分離には多くのソリューションがあります。基本的に、異なるアプリケーション コンテナーは異なる VLAN/VXLAN に配置され、異なる VLAN/VXLAN が相互にアクセスできないようにすることで分離が実現されます。

簡単な解決策としては、docker overlay を使用して解決してみることです。まず、異なるネットワークを作成し、次に異なるアプリケーションのコンテナを起動するときに、--net パラメータを使用して、コンテナが配置されている対応する vxlan を指定します。

その結果、同じネットワーク内のコンテナは相互運用可能ですが、異なるネットワーク内のコンテナは相互運用できません。現在、企業では OVS/Linux ブリッジ + VLAN ソリューションがより一般的に使用されていますが、長期的には Calico ソリューションの見通しは良好です。

コンテナ用の永続ストレージ ソリューションを選択して設計するにはどうすればよいでしょうか?

永続ストレージについて説明する前に、コンテナを実行することはデータの永続性を完全に放棄することを意味するわけではないことをまず述べておきます。コンテナ内で実行されるアプリケーションの場合、アプリケーションが実際に保存する必要があるデータは、永続ボリューム データ ボリュームに書き込むこともできます。

このシナリオでは、永続化レイヤーは弾力性ではなく、適切に設計された API によるストレージの拡張など、柔軟なプログラミング可能性を通じて価値を生み出します。現在は主にDockerまたはKubernetes Volumeをサポートしています。

Docker 用コンテナボリュームプラグイン

Docker はコンテナ ボリューム プラグイン仕様をリリースしました。これにより、サードパーティ ベンダーのデータ ボリュームが Docker エンジンでデータ サービスを提供できるようになります。

この仕組みにより、外部ストレージはコンテナのライフサイクルを超えて独立して存在することができ、インターフェース API 標準を満たしていれば、さまざまなストレージ デバイスを Docker コンテナの動作プラットフォームに接続できるようになります。

さまざまな既存のストレージをシンプルなドライバーを通じてカプセル化し、Docker コンテナとのドッキングを実現できます。ドライバーはコンテナ エンジンとのノースバウンド インターフェイスを実装し、基礎レイヤーはバックエンド ストレージ関数を呼び出してデータ アクセスなどのタスクを完了すると言えます。

現在実装されている DockerVolume プラグインでは、バックエンド ストレージに一般的な NFS、CIFS、GlusterFS、ブロック デバイスが含まれます。

K8Sデータ量

K8S の各ポッドには 1 つ以上のコンテナが含まれます。ポッドはクラスター内の任意のノードにデプロイでき、ストレージ デバイスはデータ ボリュームを通じてポッド コンテナーに提供できます。

特定のコンテナ技術に縛られないようにするために、K8S は Docker のボリューム メカニズムを使用せず、代わりにさまざまなコンテナ操作 (Docker や rkt など) で使用される独自の一般的なデータ ボリューム プラグイン仕様を開発します。

データ ボリュームは、共有と非共有の 2 つのタイプに分けられます。非共有タイプは、特定のノード (iSCSI、AWS EBS、その他のネットワーク ブロック デバイスなど) によってのみマウントおよび使用できます。共有タイプは、異なるノード上の複数の Pod で同時に使用できます (NFS、GlusterFS などのネットワーク ファイル システム、およびマルチパーティの読み取りと書き込みをサポートできるブロック デバイスなど)。

ステートフル アプリケーションの場合、共有ボリューム ストレージは、クラスター内のノード間でのコンテナーの移行を簡単にサポートできます。

コンテナのよりきめ細かいボリューム管理を提供するために、K8s では、外部ストレージをリソース プールとして扱い、プラットフォームによって管理され、クラスター全体に提供される永続ボリューム機能が追加されました。

K8S のボリューム管理アーキテクチャは、標準のストレージ アクセス メソッドを使用し、インターフェイスを通じてストレージ デバイスでサポートされる機能を公開し、コンテナー タスクのスケジュール設定などの面での自動管理を実現します。

コンテナ クラウド上で集中ログ管理を設計するにはどうすればよいでしょうか?

コンテナは、高速な障害移行と柔軟なスケーリングを必要とするアプリケーションやマイクロサービスを実行するためによく使用されます。したがって、コンテナ内で実行されているアプリケーションが移行され、弾力的にスケーリングされると、実行中のさまざまなノードでアプリケーション ログが生成される可能性が高くなり、コンテナ アプリケーションのログ監視と問題のトラブルシューティングに大きな問題が生じます。

相対的に言えば、ローカル ファイル システムにログを書き込む従来のアプリケーションのほとんどとは異なり、コンテナー アプリケーションでは、ログを集中的に収集してから、外部の集中ログ管理システムに書き込むことを検討する必要があります。

従来のログ集約および収集ソリューションには、主に商用ソフトウェアの Splunk、オープンソース ソフトウェア スタックの ELK、Facebook のオープンソースの Scribe などがあり、その中で ELK が最も広く使用されています。

典型的な ELK アーキテクチャには、構築が簡単で使いやすいという利点があります。欠点は、Logstash が多くのリソースを消費し、実行時に多くの CPU とメモリを占有し、メッセージ キュー キャッシュがないため、データ損失のリスクがあることです。小規模なクラスターでの使用をお勧めします。

大規模に使用する場合は、Kafka（またはRedis）を導入し、メッセージキューのキャッシュを増やしてネットワーク転送のバランスを取り、LogstashとElasticsearchをクラスターモードで構成して負荷を軽減することができます。

Logstash はシステム リソースを大量に占有します。その後、Logstash の代わりに Fluentd が開発されました。コミュニティソリューションではEFKと呼ばれます。 Logstash などの従来のログ収集ツールと比較すると、Fluentd のログ収集機能はコンテナをより完全にサポートしています。

コンテナログを収集する場合は、次の 2 つの点に注意してください。

ログ書き込みの競合を回避する

最も簡単な方法は、実行時にコンテナが外部共有ストレージ ボリュームをアプリケーションのログ ディレクトリとしてマウントし、アプリケーションのログが後続の処理のためにリアルタイムで外部共有ストレージに書き込まれるようにすることです。

この方法には適切な制御が必要です。異なるコンテナは同じ外部ボリュームをマウントできません。そうしないと、ログ書き込みの競合が発生します。コンテナを移行するときにボリュームを再マウントする必要があります。

ログの標準化を無視しない

ログの集中収集に加えて、アプリケーション変換中のコンテナ アプリケーションのログ標準化にも注意を払う必要があります。

コンテナを使用してマイクロサービス アーキテクチャ アプリケーションを実行する場合、ビジネス呼び出しは複数のマイクロサービスの呼び出しチェーンを経由する必要があり、ビジネス処理プロセス全体のログ レコードが異なるマイクロサービス ログに分散されるため、ログによる問題診断に大きな不便が生じます。

ログに固有のID情報を付加するなど、ログを標準化することで、異なるマイクロサービスにおける同一業務の処理を関連付けることが可能です。

標準化されたアプリケーション ログを通じて、トランザクション レート、成功率、応答時間などの主要なビジネス指標に関する統一された相関分析を実行できます。これは、問題の警告、診断分析、容量の拡張と縮小の科学的根拠として役立ちます。

コンテナ アプリケーションの監視ソリューションを設計するにはどうすればよいですか?

仮想マシンの運用と保守の時代において、Nagios と Zabbix は非常に古典的なパフォーマンス監視ソフトウェアです。しかし、コンテナ時代においては、かつては馴染み深かったソフトウェアのほとんどは、コンテナ化されたサービスに対して便利な監視エクスペリエンスを提供できず、コミュニティはそのようなプラグインやデータ収集クライアントの開発に積極的ではありません。

それどころか、多くの新しいオープンソース監視プロジェクトでは、コンテナのサポートを主要な機能として位置付けています。新しい世代が古い世代に取って代わるにつれて、コンテナのアプリケーションが監視ソフトウェアの新しい時代を定義したと言えます。

これらの新しい監視ツールの中には、cAdvisor、cAdvisor + InfluxDB + Grafana、Prometheus という 3 つの人気があり成熟した特定のソリューションがあります。

InfluxDB に基づくソリューションは複数のオープンソース コンポーネントの組み合わせですが、Prometheus に基づくソリューションは全体的なソリューションです。

コンテナ情報を収集してグラフを表示する機能は、他の専用オープンソース コンポーネントに比べて劣ります。通常、実際の実装では、cAdvisor + Prometheus または cAdvisor + Prometheus + Grafana の組み合わせで使用されます。ただし、多次元データ モデルにより、データのフィルタリングと集約が容易になります。

コンテナ アプリケーションの監視設計に関しては、監視が階層化されていることに注意することが重要です。具体的には、システムレベル、アプリケーションレベル、サービスレベルに分けられます。各レベルには独自の監視焦点があります。

システムレベル

主にリソースの使用状況、ネットワーク接続、ノードの健全性を監視します。この点に関しては、従来の監視システムはすでに非常に完成されています。従来の監視システムを直接使用して、コンテナ プラットフォームのホスト マシンをシステム レベルで監視し、大規模な監視画面に接続できます。

ホスト マシン上の単一コンテナーのパフォーマンスとリソース使用量は、外部リソース監視にとってはあまり重要ではなく、それらを外部の従来の監視に送信する必要はほとんどありません。

アプリケーションレベル

コンテナ プラットフォーム自体には通常、サービスの実行インスタンス数を維持するための K8S のレプリケーション制御に似たメカニズムがあるため、通常の状況では、コンテナ プラットフォームはアプリケーションとアプリケーション下の各マイクロサービスの正常な動作を保証できます。

アプリケーション レベルでのヘルス モニタリングに関しては、従来のモニタリング システムに接続し、適切なアラームを出力する必要があります。たとえば、アプリケーション ロジックのエラーによって起動が繰り返し失敗したり、リソース不足によって起動が常に失敗したりする場合、コンテナ プラットフォーム自体のレプリケーション制御メカニズムでは問題を解決できません。

この場合、アプリケーションの障害情報を外部監視に渡し、問題の重大度に応じて異なるレベルのアラーム通知を発行し、パッチのアップグレードやロールバックなど、関連するアプリケーション担当者が介入して問題を解決する必要があります。

サービスレベル

サービス レベルは、アプリケーションによって提供されるサービスが正常に実行されているかどうかを監視します。たとえば、Web サービスを提供するアプリケーションでは、アプリケーションとそのマイクロサービスの実行中のインスタンスの数が正常であっても、Web サービスが応答を失ったり、エラー ステータスを返したりすることがあります。この状況は、ほとんどのコンテナ プラットフォームでは検出できません。

従来の方法はプローブ エージェントを使用することですが、コンテナー環境ではこれが実行できない可能性があります。これには、コンテナ障害の監視方法を充実させるか、独自のサービス アクセス + 検出ロジックを記述して判断を行い、検出で見つかった問題を外部監視に報告し、監視で対応するアラーム戦略とアラーム レベルを確立する必要があります。

コンテナ クラウドのマルチテナントと権限を設計するにはどうすればよいでしょうか?

マルチテナントとは、その名前が示すように、多くの人がコンテナ クラウド プラットフォームのリソースをレンタルして、独自のアプリケーション ホスティングおよび運用ニーズを満たすことを意味します。これには主に、マルチテナント、リソースの管理と割り当て、セキュリティ権限管理という 3 つの問題が関係します。

マルチテナントの問題

マルチテナントの観点から見ると、テナントはコンテナ クラウド プラットフォームのリソースをレンタルして、独自のアプリケーションとサービスをホスト、開発、展開、保守します。

コンテナ クラウド プラットフォームは、テナントがこれらのリソースを正常に使用できるようにリソースを提供および維持する必要があり、同時に、テナントによってホストされるアプリケーションに対して、サービス登録、サービス検出、サービス構成、ログ記録、監視、早期警告、弾性スケーリング、負荷分散、セキュリティなどの機能を提供する必要があります。

テナントはこれらの機能をレンタルするだけであり、これらの機能を運用および保守するわけではないことを理解する必要があります。テナントはホストされたアプリケーションとサービスに重点を置いており、プラットフォームによって提供される機能を使用して、アプリケーションとサービスをシームレスに運用および保守する必要があります。

一言でまとめると、テナントはリソースを使用/レンタルするだけで、コンテナ クラウド プラットフォームがこれらのリソースを管理および運用します。テナントは、独自のアプリケーションまたはサービスの運用と保守に重点を置きます。リソースはテナントによって申請され、コンテナ クラウド プラットフォームがリソースを割り当てて管理します。

リソースの管理と割り当て

この機能部分は、運用保守チームまたはシステム チームによって管理されることをお勧めします。アプリケーション システムをクラウドに配置する前に、通常はストレス テストが実行され、容量の見積りプロセスが行われます。

容量の見積もりと傾向分析を通じて、システム担当者は関連アプリケーションの大まかなリソース プールを計画できます。これは通常、基盤となるリソース プールを分割することで実現できます。

K8S を使用する場合は、コンピューティング ノード上のラベルを通じて計画を立てることができます。さらに、アプリケーションを弾力的に拡張できるように、オーケストレーション ファイルで最小リソースと最大リソースを設定する必要があります。

セキュリティ権限管理

マルチテナント セキュリティ権限設計には、コンテナ クラウド プラットフォームの全体的な権限制御アーキテクチャが含まれます。最初のステップは、さまざまなシナリオの柔軟なニーズを満たすために、コンテナ クラウドのコンポーネントと機能を動的に制御する許可センターを実装することです。

具体的には：

• 組織構造は階層構造で実装できます。レイヤーやレベルの数に関係なく、親ノード ID のみがマークされます。ツリー構造をトラバースすることですべてのノードを取得できます。これは、以下の権限アクセス制御の実装の基礎でもあります。
• ロール定義は、ユーザーとユーザーの組織構造、権限、および Container Cloud がテナントに提供する機能のリストに基づいて実装する必要があります。 Oracle データベースのユーザー ロール権限定義方式を使用して定義できます。

たとえば、コンテナ クラウド プラットフォームを初期化するときに、テナント管理者ロール、アプリケーション管理者ロールなどのロールを事前定義し、定義されたロール権限に基づいてさまざまなユーザー ビューを表示できます。

権限アクセス制御が抽出され、統合権限センター コンポーネントとして実装される理由は、コンテナ クラウド プラットフォーム全体と各コンポーネントが権限アクセス制御の必要性に直面しているためです。

クラウド コンピューティングの観点から見ると、疎結合のプラグイン コンポーネントまたはモジュール設計の方が柔軟性が高く、急速に変化するニーズに適応できます。

顧客にとって、コンポーネントは必要な場合もあれば、そうでない場合もあります。各コンポーネントは、プラグアンドアンプラグ方式で制御できます。顧客のニーズに応じて対応するコンポーネントを展開し、対応する権限アクセス制御を実装すると、より柔軟かつ便利になります。

コンテナを OpenStack および Kubernetes と統合する機能はありますか?

オープンソースのクラウド コンピューティング テクノロジーが急成長を遂げてきたここ数年、OpenStack、Kubernetes、コンテナーは間違いなくクラウド コンピューティングの状況を変えた 3 つの主要テクノロジーになりました。

しかし、3つの間には依然として技術的なギャップが存在します。コンパクトなサイズと軽量性を維持しながら、実行時に強力なセキュリティ分離を維持する方法と、OpenStackとKubernetesの2つの主要プラットフォームと簡単に統合して、マルチテナントや統合ネットワークとストレージなどのメリットを得る方法です。このギャップにより、ユーザーはそこからより大きな価値を得ることができなくなります。

この問題を解決するために、OpenStack Foundation は今年 12 月 5 日の KubeCon Summit で新しいオープンソース プロジェクト Kata Containers をリリースしました。

Kata を使用すると、ユーザーは仮想マシンのセキュリティとコンテナ テクノロジの速度と管理性の両方を実現できます。このプロジェクトはハードウェアの違いを遮断し、OCI 仕様および Kubernetes コンテナ ランタイム標準と互換性があります。強力な分離性、軽量、高速起動機能を備えながら、標準の画像形式をサポートします。

さらに重要なのは、Kata プロジェクトの元の設計では、OpenStack および Kubernetes とシームレスかつ便利に統合できることが重視されていたことです。

間違いなく、Kata プロジェクトの立ち上げは、OpenStack、Kubernetes、コンテナのより優れた統合を強力にサポートし、ユーザーがその恩恵を受ける道を開きます。

コンテナの本当に素晴らしい時代の到来を楽しみにしています。しかし、未来にはまだ長い道のりがあります。

コンテナ クラウドはどのようにして高可用性とリージョン間展開を実現するのでしょうか?

コンテナ クラウドでは、プラットフォーム自体の高可用性を考慮し、複数の可用性ゾーンとデータ センターへの展開を実装する必要があります。

コンテナ上のアプリケーションの高可用性は、アプリケーション アーキテクチャと組み合わせて実現する必要があります。現在、マイクロサービス アーキテクチャは、クラウド インフラストラクチャに最も適したアプリケーション アーキテクチャの 1 つです。

マイクロサービス アプリケーションは、サービス登録と検出、グローバル構成管理、回路遮断、サービス追跡などのフォールト トレラント設計を通じて、アプリケーションの高可用性を保証します。

弾力的な容量拡張により、マイクロサービスの実行インスタンスの数が増加し、負荷分散戦略の使用と連携して、過度の負荷による実行インスタンスのダウンタイムが短縮されます。

要約する

企業におけるコンテナ テクノロジの実装は一夜にして達成されるものではなく、段階的かつ付加価値の高いプロセスです。テクノロジーの変化は、微妙で平和的な進化となる場合もあれば、激しい武力革命となる場合もあります。コンテナ技術は前者に属するはずです。

コンテナ化技術がコンピューティング モデルの進化の始まりになったことがわかります。より効率的で軽量なプラットフォームの実践を経て、コンテナ技術はIT分野全体にさらなる新鮮さと活力を注入し、将来も生き残り、成長し、世界的なトレンドの決定的な力となることが予測されます。

[[213947]]

シニア システム アーキテクトの Sun Jie は、システム、データベース、クラウド コンピューティング、データ センター管理に重点を置いています。外資系企業、インターネット、電子商取引、大企業で勤務し、データセンター構築、プライベートクラウドアーキテクチャの計画と運用保守管理、ビッグデータマイニングなどの関連業務の実装に参加しました。彼は、アーキテクチャ設計、プロジェクト実装、およびいくつかの大規模および中規模プロジェクトの構築、展開、運用における最前線の経験を豊富に積んでいます。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]