1.2. OpenShift Container Platform アーキテクチャーについて
OpenShift Container Platform のアーキテクチャーは、連携する小規模な分割されたユニットからなるマイクロサービスベースとなっております。Kubernetes クラスターで実行されます。この際、オブジェクト関連のデータは、信頼できるクラスター化されたキーと値のストアである、etcdに保存されます。これらのサービスは、機能別に分類されます。
ユーザーは、REST API を呼び出してシステムの状態を変更します。コントローラーは、REST API を使用してユーザーの必要な状態を読み取り、システムの他の部分を同期しようとします。たとえば、ユーザーが「ビルド」を要求すると、ビルドオブジェクトが作成されます。ビルドコントローラーは、新規ビルドが作成されていることを確認し、クラスターでプロセスを実行してそのビルドを実行します。ビルドが完了すると、コントローラーは REST API 経由でビルドオブジェクトを更新し、ユーザーはビルドが完了していることを確認できます。
コントローラーパターンとは、OpenShift Container Platform の機能の多くが拡張可能であることを意味しています。ビルドの実行および起動方法は、イメージの管理方法や デプロイメント がどのように行われるかに関係なくカスタマイズできます。コントローラーは、システムのビジネスロジックを実行してユーザーのアクションを実行して、それを実際に実装します。これらのコントローラーをカスタマイズしたり、独自のロジックに置き換えたりすることで、各種の動作を実装できます。システム管理の視点では、これは API を使用して繰り返されるスケジュールで共通の管理アクションについてのスクリプトを作成できることを意味しています。これらのスクリプトは変更を確認し、アクションを実行するコントローラーでもあります。OpenShift Container Platform でこの方法でクラスターをカスタマイズする機能をファーストクラスの動作として使用できます。
コントローラーは、これを可能にするために、システムへの変更が含まれる、信頼できるストリームを活用して、システムのビューとユーザーの実行内容とを同期します。このイベントストリームは、変更の発生後すぐに、etcd から REST API に変更をプッシュしてから、コントローラーにプッシュするので、システムへの変更は、非常に素早くかつ効率的に伝搬できます。ただし、障害はいつでも発生する可能性があるので、コントローラーは、起動時にシステムの最新状態を取得し、すべてが適切な状態であることを確認できる必要があります。このような再同期は、問題が発生した場合でも、オペレーターが影響を受けたコンポーネントを再起動して、システムによる全体の再チェックを実行してから続行できるので重要です。コントローラーはシステムの同期をいつでも行えるので、システムは最終的に、ユーザーの意図に合わせて収束されるはずです。
