1.2. OpenShift Online アーキテクチャーとは

OpenShift Online には、それぞれ連携する小規模な切り離されたユニットから構成されるマイクロサービスベースのアーキテクチャーがあります。これは、Kubernetes クラスターの上部で、信頼できるクラスター化されたキーと値のストアである etcd に保存されるオブジェクトについてのデータを使用して実行されます。これらのサービスは、機能別に分類されます。

ユーザーは、REST API を呼び出してシステムの状態を変更します。コントローラーは、REST API を使用してユーザーの必要な状態を読み取り、システムの他の部分を同期しようとします。たとえば、ユーザーがビルドを要求すると、「ビルド」オブジェクトが作成されます。ビルドコントローラーは、新規ビルドが作成されていることを確認し、クラスターでプロセスを実行してそのビルドを実行します。ビルドが完了すると、コントローラーは REST API 経由でビルドオブジェクトを更新し、ユーザーはビルドが完了していることを確認できます。

コントローラーパターンは、OpenShift Online の機能の大半が拡張可能であることを意味します。ビルドの実行および起動方法は、イメージの管理方法や デプロイメントがどのように行われるかに関係なくカスタマイズできます。コントローラーは、システムの「ビジネスロジック」を実行してユーザーのアクションを実行して、それを実際に実装します。これらのコントローラーをカスタマイズしたり、独自のロジックに置き換えたりすることで、各種の動作を実装できます。システム管理の視点では、これは API を使用して繰り返されるスケジュールで共通の管理アクションについてのスクリプトを作成できることを意味しています。これらのスクリプトは変更を確認し、アクションを実行するコントローラーでもあります。OpenShift Container Platform でこの方法でクラスターをカスタマイズする機能をファーストクラスの動作として使用できます。

コントローラーは、これを可能にするために、システムへの変更が含まれる、信頼できるストリームを活用して、システムのビューとユーザーの実行内容とを同期します。このイベントストリームは、変更の発生後すぐに、etcd から REST API に変更をプッシュしてから、コントローラーにプッシュするので、システムへの変更は、非常に素早くかつ効率的に伝搬できます。ただし、障害はいつでも発生する可能性があるので、コントローラーは、起動時にシステムの最新状態を取得し、すべてが適切な状態であることを確認できる必要があります。このような再同期は、問題が発生した場合でも、オペレーターが影響を受けたコンポーネントを再起動して、システムによる全体の再チェックを実行してから続行できるので重要です。コントローラーはシステムの同期をいつでも行えるので、システムは最終的に、ユーザーの意図に合わせて収束されるはずです。