Red Hat OpenShift Container Platform アーキテクチャの概要

1. OpenShift Container Platformの特徴

• リモート管理

• マルチテナンシー

• セキュリティ強化

• アプリケーションライフサイクル管理

• 開発者向けのセルフサービスインターフェース

2. OpenShiftソフトウェアスタックの構造

3. OpenShiftが追加する機能

• Kubernetes拡張: Etcdに保存される追加リソースタイプを提供し、Kubernetesと連携してOpenShiftの内部状態や設定を管理。

• コンテナ化されたサービス: ネットワークや認証などのインフラ機能を提供。多くのサービスがコンテナとして動作。

• RuntimesとxPaaS: 開発者向けのベースコンテナイメージを提供（例：プログラミング言語やデータベース）。

• DevOpsツールとユーザー体験: Web UIやCLIツールを提供し、アプリケーションやリソースを簡単に管理可能。

4. OpenShiftのクラスター構成

• 注記: OpenShiftクラスターはKubernetesクラスターを拡張したもので、CLIやWebコンソールを活用して効率的に管理できます。

5. Kubernetesの主なリソースタイプ

6. OpenShiftが提供する独自のリソースタイプ

• 注記: KubernetesのReplication Controllerは、通常OpenShiftのDeployment Controllerによって作成されます。

• ローリングアップデートは、システムやアプリケーションの更新方法の一つで、稼働中のサービスを停止することなく段階的に新しいバージョンへ移行する手法です。主にコンテナ環境やクラウド環境で使用されます。

Service と Route の違い

1. Service

2. Route

比較表

まとめ

• Serviceは主に内部通信を担当し、Podへのルーティングや負荷分散を行います。

• Routeは外部通信を担当し、クラスタ外部からのリクエストを適切なServiceにルーティングします。

ポイントまとめ

• OpenShiftは、KubernetesとDockerのインフラを基盤として機能を拡張し、開発者や管理者の作業を効率化します。

• 高レベルなリソース管理により、継続的インテグレーション・デリバリー(CI/CD)の実現を支援します。

• 開発環境に適したツールやサービスを統合して提供します。

ネットワーキング：Docker、Kubernetes、OpenShiftの概要

Dockerのネットワーキング

1. コンテナのIPアドレス
• Dockerが管理するコンテナには、内部ネットワークからIPアドレスが割り当てられ、ホスト内部からのみアクセス可能。
• コンテナの特性上、IPアドレスは動的であり、頻繁に割り当てや解放が行われる。

2. 外部アクセス
• 外部からアクセスするには、ルーターからホスト、さらにコンテナのIPアドレスへのポートフォワーディングが必要。
詳細：

この部分は、Dockerコンテナが外部（インターネットや別のネットワーク）から直接アクセスされる方法について説明しています。具体的には以下のような仕組みです：

---

外部アクセスの詳細

1. 通常の状態
• Dockerコンテナは、内部ネットワーク（ホスト内）に隔離されており、直接外部からアクセスできない。
• コンテナの内部IPアドレスはプライベートなもので、外部のデバイスから見えない。

2. 外部アクセスを可能にする方法：ポートフォワーディング
• 外部からのアクセスを許可するためには、次のようなポートフォワーディングを設定する必要があります：
• ルーターで特定のポート（例: 8080）をホストマシンのIPアドレスに転送。
• ホストマシンでそのポートをDockerコンテナの内部ポート（例: 80）に転送。

---

具体例

1. 状況
• DockerコンテナでWebアプリケーションを実行しており、そのアプリがコンテナ内のポート80でリクエストを受け付けているとします。

2. ポートフォワーディングの設定
• ホストマシンのポート8080を、Dockerコンテナのポート80にマッピング。 これにより、ホストマシンのhttp://<ホストのIP>:8080にアクセスすると、コンテナ内のアプリケーションに到達できるようになります。

3. ルーターでの設定
• ホストが家庭用や企業用ネットワークの背後にある場合、ルーターでポートフォワーディングを設定し、インターネットからホストのポート8080にアクセス可能にします。

---

問題点

• この方法は単一ホストに依存しているため、スケーラビリティに欠けます。 （例えば、大規模なシステムで複数のホストやコンテナを扱う際、管理が煩雑になる）

• KubernetesやOpenShiftでは、このようなポートフォワーディングの代わりに、NodePortやRouteなどの仕組みで外部アクセスを簡単かつスケーラブルに提供します。

---

• この方法はスケーラビリティが低く、大規模な環境には不向き。

Kubernetesのネットワーキング

1. ソフトウェア定義ネットワーク（SDN）
• Kubernetesは、複数のノード間で内部コンテナネットワークを作成。
• クラスター内の任意のPodが、ホストを超えて他のPodにアクセス可能。

2. 安定した接続先
• コンテナ同士の直接接続は推奨されない。代わりに、サービスIPアドレスを使用することで、スケーラビリティと障害耐性を確保。

3. NodePortによる外部アクセス
• KubernetesサービスはNodePort属性を指定可能。これにより、クラスター内のすべてのノードが指定されたネットワークポートをSDNにリダイレクト可能。
• しかし、この方法も大規模な環境では限界がある。

OpenShiftのネットワーキング

1. Routeリソースの活用
• OpenShiftは、外部からのアクセスをスケーラブルかつシンプルに実現するためにRouteリソースを提供。
• HTTPやTLSアクセスは、Kubernetes SDN内のサービスアドレスに転送される。
• 必要条件：DNSホスト名をOpenShift Routerノードの外部IPアドレスにマッピング。

2. 開発者と管理者のサポート
• OpenShiftはDockerやKubernetesのコア機能を隠すことなく、独自の管理ツール（CLI、Webコンソール）を提供。
• 生のDockerコンテナやKubernetesリソースもクラスターに取り込めるため、OpenShiftの追加機能を活用可能。

3. ワークフローの自動化
• OpenShiftの主な付加価値は、開発・デプロイメントの自動化。アプリケーションのビルドとデプロイが標準プロセスとしてOpenShiftクラスター内で完了。

まとめ

1. コンテナのネットワーク（Dockerなど）

• 特徴：
• 各コンテナにはホスト内で有効な内部IPアドレスが割り当てられる。
• 同じホスト内にあるコンテナ同士はネットワークブリッジを通じて通信可能。
• ホストの外に出る場合はポートフォワーディングを利用する必要がある。

• 制限：
• 通信範囲が1台のホスト内に限定される。
• 複数のホスト間で通信する場合は、手動で設定を行うか、Docker SwarmやKubernetesのような追加ツールが必要になる。

2. Kubernetesのネットワーク（クラスタ内のPod間通信）

• 特徴：
• ソフトウェア定義ネットワーク（SDN）を提供し、異なるノード（サーバー）上にあるPod同士が通信できる。
• 各Podに独自のIPアドレスが割り当てられ、そのIPを使用して直接通信可能。
• Service（サービス）：
• Kubernetesは安定したサービスIPアドレスを提供し、Podはそのサービス名（DNS名）を通じて通信可能。
• サービスによって負荷分散や可用性向上が実現される。

• 制限：
• Kubernetesネットワークは基本的にクラスタ内通信専用で、外部アクセスはデフォルトでは許可されない。
• 外部アクセスを行うにはNodePortやLoadBalancer、Ingressなどの設定が必要。

3. OpenShiftのネットワーク（外部アクセスの管理）

• 特徴：
• OpenShiftはKubernetesのネットワークをベースに、外部アクセスの簡素化とスケーラビリティ向上を図っている。
• Route（ルート）リソース：
• 外部からのHTTPやHTTPSリクエストを、Kubernetesクラスタ内のサービスにルーティングする。
• KubernetesのNodePortやLoadBalancerを使用する場合と比べて、設定が簡素化される。
• 外部DNS名をOpenShiftルーターの外部IPアドレスにマッピングするだけで利用可能。

• メリット：
• OpenShiftのルートにより、外部からKubernetesのサービスへのアクセスがより簡単かつスケーラブルになる。
• 開発者はネットワーク設定に詳しくなくても、簡単に外部アクセスを設定可能。

要約

例

• コンテナネットワーク：
同じホスト内にある2つのコンテナ A と B が内部IPで通信する。
例：curl http://172.17.0.2:8080

• Kubernetesネットワーク：
異なるノード上にあるPod A と B が、ClusterIPやDNS名を使用して通信する。
例：curl http://service-name:8080

• OpenShiftネットワーク：
外部のDNS名（例：http://myapp.example.com）を使い、リクエストをルート経由でサービスに転送する。
例：curl <http://myapp.example.com>

OpenShiftとKubernetesの役割

1. MasterとNode
• OpenShiftクラスターは、コンテナを実行するノードサーバーと、それを管理するマスターサーバーで構成される。
• サーバーはマスターとノードを兼ねることもできるが、通常は安定性を高めるために役割を分離。

2. スケーラブルなアーキテクチャ
• OpenShiftの管理ツール（CLI、Webコンソール）を活用し、開発者は低レベルなDockerの詳細を知らなくても、効率的にアプリケーションを操作可能。
• 必要に応じて、DockerやKubernetes環境と互換性を持たせることも可能。

OpenShiftの概要とアーキテクチャ

• マスターとノード
• マスターは認証やAPIのエントリーポイントを提供し、KubernetesのマスターサービスやEtcdデーモンを実行。
• ノードはKubernetesのkubeletとkube-proxyデーモンを実行し、コンテナをポッドにグループ化してアプリケーションを動作させる。
• マスターもノードとして機能する場合がある。

• ポッドはコンテナのグループで、仮想ネットワークデバイスや内部IPアドレス、TCP/UDPポート、永続ストレージを共有。

• レプリカセットによりポッドのスケールを管理。例えば、ApacheとPHPのポッドを同じイメージで水平スケール可能。

• プロジェクトはKubernetesリソース（ポッド、サービスなど）をグループ化し、ユーザーごとにアクセス権やリソースのクオータを設定可能。

• OpenShiftでは「アプリケーション」という概念は存在せず、new-appコマンドでリソースをプロジェクト内に作成。リソースはラベル（例: app）で分類。
詳細：
一つのアプリケーションに関連する全てのリソースが一つのプロジェクト内に含まれることが推奨されます。これにより、アプリケーションの全てのリソース（ポッド、サービス、ストレージなど）を一元的に管理しやすくなります。
具体的には、以下のようなリソースが一つのプロジェクト内に含まれます：
1. アプリケーションのポッド（実行中のコンテナ）
• アプリケーションのコアとなる部分で、プロジェクト内に配置されます。
2. デプロイメント（アプリケーションの更新管理）
• アプリケーションのバージョンアップやスケーリングを管理するためのリソース。
3. サービス（通信インターフェース）
• アプリケーションのポッドへのアクセスを管理するために使用され、内部や外部との通信を制御します。
4. ConfigMapおよびシークレット（設定情報や機密情報）
• アプリケーションの設定やAPIキー、パスワードなど、機密性の高い情報もプロジェクト内で管理されます。
5. 永続ストレージリソース（PersistentVolume、PersistentVolumeClaim）
• データの永続化を必要とする場合、ストレージリソースも同じプロジェクト内で管理されます。
6. ロールとロールバインディング（アクセス権限）
• アプリケーションにアクセスするユーザーやサービスアカウントのアクセス権限を管理します。
7. リソースクオータ（リソース制限）
• プロジェクトに割り当てられるリソース（CPU、メモリ、ストレージなど）の上限を設定することができます。
8. ネットワークポリシー（通信制御）
• アプリケーション内や外部との通信を制限するための設定を行います。
利点
• 一貫した管理: アプリケーションに関連する全てのリソースが一つのプロジェクトに含まれることで、デプロイや更新、アクセス制御が一元化され、管理が容易になります。
• セキュリティ: 同じプロジェクト内でリソースを分けることで、アクセス制御やセキュリティ設定が適用しやすくなります。
• スケーラビリティ: アプリケーションに関連するリソース全体を一度にスケールアウト/インすることができます。
例外
ただし、大規模なシステムやマイクロサービスアーキテクチャの場合は、複数のプロジェクトを使ってリソースを分けることもあります。例えば、バックエンドとフロントエンドのリソースを別々のプロジェクトに配置し、必要に応じて相互に通信させる場合です。この場合でも、各サービスは独立したプロジェクトとして管理され、適切な通信やアクセス制御が必要です。
まとめ
基本的には、一つのアプリケーションに関連する全てのリソースは一つのプロジェクトにまとめることが推奨されますが、システム規模やアーキテクチャに応じてプロジェクトの分割が必要になる場合もあります。

• S2Iプロセス: SCM（ソースコード管理）からコードを取得し、ランタイムを自動検出。ベースイメージでアプリケーションを構築後、新しいイメージを生成し内部レジストリにプッシュ。

• Jenkinsなどの外部CIツールを統合可能。カスタムのパイプラインやテンプレートを作成可能。

• リソース（イメージ、コンテナ、ポッドなど）はEtcdに保存され、CLI、Webコンソール、REST APIで管理可能。
詳細
REST APIは、HTTPプロトコルを使ったリクエストとレスポンスの仕組みですが、単に「情報が来たらレスポンスする」だけではありません。以下のような特徴があります：
1. リクエスト: クライアントがHTTPメソッド（GET, POST, PUT, DELETEなど）でサーバーにリクエストを送信。
2. 処理: サーバーはリクエストに応じてリソース（データ）を操作。
3. レスポンス: サーバーは結果をHTTPレスポンスとして返す。レスポンスにはステータスコードやデータが含まれる。
特徴
• 無状態性: 各リクエストは独立しており、サーバーはリクエスト間で状態を保持しません。
• リソース駆動: URLは操作対象のリソースを表し、HTTPメソッドでリソースに対する操作を行います。
要するに、REST APIは「来た情報に応じてレスポンスする」以上に、リソース操作の規則に従って動作します。

• JSONまたはYAML形式で共有可能で、SCMシステムから直接取得することも可能。

• OpenShiftの操作は主に宣言的。例えば、新しいポッドリソースを作成すると、Kubernetesがスケジューリングしノードで実行。
詳細
OpenShiftの操作が「宣言的」というのは、システムが最終的にどうあるべきかを指定（宣言）するアプローチであり、その結果、システムが自動的に適切な状態に遷移することを意味します。
具体的には、以下のような流れです：
1. 宣言的操作: ユーザーは、リソースの最終的な状態を宣言します。例えば、「新しいポッドを作成する」という操作を宣言します。このとき、ポッドがどのように動作するか、必要なリソースや設定（例えばCPUやメモリの要件）を指定します。
2. Kubernetesのスケジューリング: 宣言されたリソースを基に、Kubernetesがどのノード（サーバ）でそのポッドを実行するかを自動的に決定します。このプロセスはユーザーが明示的に指定することなく行われます。
3. システムの自己修復: 一度設定したリソースが変更された場合、Kubernetesは自動的にその状態を最初に宣言された状態に戻そうとします（例えば、ポッドが予期しない理由で停止した場合、再起動を試みます）。
このように、OpenShiftでは「目標状態」を定義することで、システムがその状態を保つように管理されるため、ユーザーはシステムの運用を細かく指定することなく、望ましい結果が得られます。

• Kubernetesのサービスとルートを利用して、ポッド間や外部クライアントとの通信を管理。

• サービスはポッド間のロードバランシングを提供し、ルートは固定DNS名を提供。OpenShiftはOpen vSwitchを使用したSDNやHAProxyによるルーティングを提供。

• ポッドが別ノードに移動してもデータを保持するため、KubernetesのPersistentVolume（PV）とPersistentVolumeClaim（PVC）を利用。

• OpenShiftではiSCSI、Fibre Channel、GlusterFS、クラウドブロックストレージ（例: OpenStack Cinder）などをサポート。ストレージクラスで異なるバックエンドストレージを動的にプロビジョニング可能。

• OpenShiftはマスターのHA機能を提供。

• アプリケーションのHAは、ポッドやノードが失われた場合に自動的に再スケジューリングされる仕組みを備える。

• イメージストリームは関連するコンテナイメージの仮想ビューを提供。タグ（istag）を使用してイメージの履歴管理やロールバックが可能。

• 新しいイメージが追加されると、自動的にビルドやデプロイがトリガーされる。

質問7

• コンテナは非常に少ないオーバーヘッドで作成される、分離されたアプリケーション実行環境である。

• コンテナイメージは、アプリケーションとそのすべての依存関係をパッケージ化し、異なる環境でアプリケーションを実行しやすくする。

• Dockerは、標準のLinuxカーネルの機能を使用してコンテナを作成する。

• コンテナイメージレジストリは、コンテナイメージを複数のユーザーやホストに配布するための推奨メカニズムである。

• OpenShiftは、Kubernetesを使用して複数のコンテナで構成されたアプリケーションをオーケストレーションする。

• Kubernetesは、コンテナ化されたアプリケーションに対して、負荷分散、高可用性、永続ストレージを管理する。

• OpenShiftは、Kubernetesにマルチテナンシー、セキュリティ、使いやすさ、継続的インテグレーションと継続的デリバリーの機能を追加する。

• OpenShiftのルートは、コンテナ化されたアプリケーションを外部のユーザーに管理可能な方法で公開するための重要な要素である。