第1章 概要

Docker サービスは、Linux ベースの軽量なコンテナーイメージをパッケージ化して作成するために抽象化を可能にします。Kubernetes はクラスター管理を行い、複数のホストでコンテナーのオーケストレーションを行います。

OpenShift Container Platform は以下を追加します。

図1.1 OpenShift Container Platform アーキテクチャーの概要

OpenShift Container Platform のアーキテクチャーは、連携する小規模な分割されたユニットからなるマイクロサービスベースとなっており、Kubernetes クラスターで実行されます。この際、オブジェクト関連のデータは、信頼できるクラスター化されたキーと値のストアである etcd に保存されます。これらのサービスは機能別に分類されています。

Users make calls to the REST API to change the state of the system. Controllers use the REST API to read the user’s desired state, and then try to bring the other parts of the system into sync. For example, when a user requests a build they create a "build" object. The build controller sees that a new build has been created, and runs a process on the cluster to perform that build. When the build completes, the controller updates the build object via the REST API and the user sees that their build is complete.

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

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

OpenShift Container Platform および Kubernetes API は、認証情報を提示するユーザーの認証を行ってから、それらのロールに基づいてユーザーの認可します。開発者および管理者はどちらも多くの方法で認証できますが、主に OAuth トークンおよび X.509 クライアント証明書が使用されます。OAuth トークンは JSON Web Algorithm RS256 を使用して署名されます。これは、SHA-256 を使用した RSA 署名アルゴリズムです。

Developers (clients of the system) typically make REST API calls from a client program like oc or to the web console via their browser, and use OAuth bearer tokens for most communications. Infrastructure components (like nodes) use client certificates generated by the system that contain their identities. Infrastructure components that run in containers use a token associated with their service account to connect to the API.

認可は、「Pod の作成」または「サービスの一覧表示」などのアクションを定義する OpenShift Container Platform ポリシーエンジンで処理され、それらをポリシードキュメントのロールにグループ化します。ロールは、ユーザーまたはグループ ID によってユーザーまたはグループにバインドされます。ユーザーまたはサービスアカウントがアクションを試行すると、ポリシーエンジンはユーザーに割り当てられた 1 つ以上のロール (例: クラスター管理者または現行プロジェクトの管理者) をチェックし、その継続を許可します。

Since every container that runs on the cluster is associated with a service account, it is also possible to associate secrets to those service accounts and have them automatically delivered into the container. This enables the infrastructure to manage secrets for pulling and pushing images, builds, and the deployment components, and also allows application code to easily leverage those secrets.