Cloud Native Computing Foundation (CNCF) コンテナー ランタイムの一部である 2 つのコンポーネントは次のとおりです。containerd:containerd は、コンテナー イメージの管理、コンテナーの実行、コンテナーのライフサイクル イベントの処理など、コンテナーのランタイム環境を提供するオープンソースのコンテナー ランタイムです。 。軽量で拡張性があるように設計されており、コンテナーを効率的に実行するために必要な機能を提供します。runc: runc は、Open Container Initiative (OCI) ランタイム仕様の参照実装として機能する軽量コンテナ ランタイムです。これには、コンテナの分離、名前空間、cgroup、およびその他の低レベルのコンテナ操作の処理を含む、OCI 仕様に基づいたコンテナの起動と管理が含まれます。これら 2 つのコンポーネント、containerd と runc はコンテナ エコシステムで広く使用されており、クラウド ネイティブ コンピューティングのオープンソース テクノロジを促進および開発する CNCF の取り組みの一環です。

説明
OCI Container Engine for Kubernetes (OKE) サービスに関する有効なステートメントは次のとおりです。 OKE は、新しいクラスター用に新しいネットワーク リソースを自動的に作成して構成します。新しいOKEクラスターを作成すると、サービスはクラスターをサポートするために必要なネットワーク・リソース(VCN、サブネット、ルート表、セキュリティ・リスト、ロード・バランサなど)を自動的にプロビジョニングおよび構成します。テナントには、さまざまな種類のリソースに対して十分なクォータが必要です。OKEクラスタを作成する前に、Oracle Cloud Infrastructure (OCI)テナンシに、コンピューティング・インスタンス、ブロック・ストレージ、ネットワーキング・リソース、ロード・バランサなどの必要なリソースに対して十分なクォータがあることを確認する必要があります。Oracle Cloud Infrastructureテナンシにアクセスできる必要があります。OKE サービスを使用するには、OCI テナントにアクセスする必要があります。つまり、有効な OCI アカウントと、テナンシ内でリソースを作成および管理するために必要な権限が必要です。次のステートメントは無効です。OKE は、新しいクラスターの作成に既存のネットワーク リソースを使用できません。OKE はクラスター専用の新しいネットワーク リソースを作成しますが、既存のネットワーク リソースの使用はサポートされていません。各リージョン内のクラスターは 3 つまでという制限がありますが、各クラスター内に作成できるノードとポッドの数に制限はありません。この記述は正しくありません。OKE のリージョン内に作成できるクラスターの数に特別な制限はありません。ただし、リソースには特定の制限またはクォータがあり、作成できるクラスターの数に影響を与える可能性があります。

説明
サーバーレス アーキテクチャを選択する主な理由は次の 2 つです。 自動水平スケーリング: サーバーレス アーキテクチャでは、需要に基づいてリソースを自動スケーリングできます。インフラストラクチャは、必要に応じてリソースを自動的にプロビジョニングおよびスケールし、アプリケーションがさまざまなワークロードを効率的に処理できるようにします。
これにより、手動でスケーリングする必要がなくなり、リソースの使用率が最適化されます。運用コストの削減:
サーバーレス アーキテクチャは従量課金モデルに従っており、実際の実行時間と関数によって消費されたリソースに対してのみ料金が請求されます。これにより、アイドル状態のリソースに料金を支払う必要がなくなるため、コストの削減につながります。さらに、サーバーレス アーキテクチャでは、サーバーの管理と保守の必要性がなくなり、運用上のオーバーヘッドと関連コストが削減されます。説明: 統合テストは不要: 機能が他のコンポーネントやサービスと正しく統合されていることを確認するために、サーバーレス アーキテクチャでも統合テストが必要です。サーバーレス関数はさまざまなイベント ソース、データベース、API と対話でき、統合ポイントを検証するにはテストが必要です。関数内状態管理の改善: サーバーレス アーキテクチャでは、通常、有効期間の短いリクエストまたはイベントで動作するステートレス関数が推奨されます。関数内で状態を管理するメカニズムはありますが、サーバーレス アーキテクチャはデフォルトでステートレスになるように設計されており、スケーラビリティとフォールト トレランスを促進します。長時間実行オペレーションの実行が容易になる: サーバーレス関数は通常、長時間実行タスクではなく、短期間のオペレーション向けに設計されています。長時間実行する操作が必要な場合、サーバーレス アーキテクチャには実行時間の制限があり、長時間の実行に必要なリソースが提供されない可能性があるため、サーバーレス アーキテクチャは理想的な選択ではない可能性があります。

説明
正解は、「単一または小さなタスクの集合を実行する、細かく調整されたソフトウェア」です。マイクロサービスは、システムを、特定の一連のタスクの実行を担当する小さな独立したサービスに分解するソフトウェア アーキテクチャ アプローチです。各マイクロサービスは、単一または小規模な関連タスクのコレクションを処理するように、焦点を合わせ、細かく調整され、高度に結合するように設計されています。この粒度により、複雑なアプリケーションを構築する際の拡張性、保守性、および柔軟性が向上します。提供されている他のオプションは、マイクロサービスを正確に定義していません。コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソース システムとは、Kubernetes などのコンテナ オーケストレーション ツールを指します。これは、マイクロサービスの管理に使用できますが、マイクロサービス自体の定義ではありません。 。静的に型付けされコンパイルされた言語は、プログラミング言語の特性の一種を記述するものであり、マイクロサービスの概念に固有のものではありません。通常、コンピュータ システムに電子的に保存される、構造化された情報またはデータの組織化されたコレクションは、データベースまたはデータ ストレージ システムの定義であり、マイクロサービスとは無関係です。

Oracle Cloud Infrastructure (OCI) Object Storageに依存するアプリケーションのKubernetesデプロイメント・プロセスの一部としてストレージ・バケットをプロビジョニングするには、OCI Service Broker for Kubernetesを利用する必要があります。OCI Service Broker for Kubernetes を使用すると、Object Storage バケットを含む OCI リソースを Kubernetes から直接プロビジョニングおよび管理できます。OCI サービスを管理するための Kubernetes ネイティブ エクスペリエンスを提供し、アプリケーション デプロイメント プロセスの一部として OCI リソースを定義および管理できるようにします。OCI Service Broker for Kubernetes を使用すると、Kubernetes マニフェストで必要な Object Storage バケットを定義でき、サービス ブローカーが OCI でそれらのバケットのプロビジョニングと管理を処理し、アプリケーションが実行されている場所に関係なくバケットを利用できるようにします。 。