第2章 インフラストラクチャーコンポーネント

Within OpenShift Container Platform, Kubernetes manages containerized applications across a set of containers or hosts and provides mechanisms for deployment, maintenance, and application-scaling. The Docker service packages, instantiates, and runs containerized applications. A Kubernetes cluster consists of one or more masters and a set of nodes.

オプションとして、高可用性 (HA) のマスターを設定し、クラスターから単一障害点がなくなるようにします。

The master is the host or hosts that contain the master components, including the API server, controller manager server, and etcd. The master manages nodes in its Kubernetes cluster and schedules pods to run on nodes.

A node provides the runtime environments for containers. Each node in a Kubernetes cluster has the required services to be managed by the master. Nodes also have the required services to run pods, including the Docker service, a kubelet, and a service proxy.

OpenShift Container Platform creates nodes from a cloud provider, physical systems, or virtual systems. Kubernetes interacts with node objects that are a representation of those nodes. The master uses the information from node objects to validate nodes with health checks. A node is ignored until it passes the health checks, and the master continues checking nodes until they are valid. The Kubernetes documentation has more information on node management.

Administrators can manage nodes in an OpenShift Container Platform instance using the CLI. To define full configuration and security options when launching node servers, use dedicated node configuration files.

apiVersion: v1 1
kind: Node 2
metadata:
  creationTimestamp: null
  labels: 3
    kubernetes.io/hostname: node1.example.com
  name: node1.example.com 4
spec:
  externalID: node1.example.com 5
status:
  nodeInfo:
    bootID: ""
    containerRuntimeVersion: ""
    kernelVersion: ""
    kubeProxyVersion: ""
    kubeletVersion: ""
    machineID: ""
    osImage: ""
    systemUUID: ""

OpenShift Container Platform can utilize any server implementing the Docker registry API as a source of images, including the Docker Hub, private registries run by third parties, and the integrated OpenShift Container Platform registry.

OpenShift Container Platform provides an integrated container registry called OpenShift Container Registry (OCR) that adds the ability to automatically provision new image repositories on demand. This provides users with a built-in location for their application builds to push the resulting images.

Whenever a new image is pushed to OCR, the registry notifies OpenShift Container Platform about the new image, passing along all the information about it, such as the namespace, name, and image metadata. Different pieces of OpenShift Container Platform react to new images, creating new builds and deployments.

OCR can also be deployed as a stand-alone component that acts solely as a container registry, without the build and deployment integration. See Installing a Stand-alone Deployment of OpenShift Container Registry for details.

OpenShift Container Platform はサードパーティーのイメージを使用してコンテナーを作成できますが、これらのレジストリーは統合 OpenShift Container Platform レジストリーと同じイメージ通知のサポートがあるわけではありません。取得したタグの更新は、oc import-image <stream> の実行と同程度に簡単です。新規イメージが検出されると、前述のビルドおよびデプロイメントの応答が生じます。

OpenShift Container Platform Web コンソールは、Web ブラウザーからアクセスできるユーザーインターフェースです。開発者は Web コンソールを使用してプロジェクトのコンテンツの可視化、ブラウズ、および管理を実行できます。

The web console runs as a pod on the master. The static assets required to run the web console are served by the pod. Administrators can also customize the web console using extensions, which let you run scripts and load custom stylesheets when the web console loads.

ブラウザーから Web コンソールにアクセスする際に、まず必要な静的アセットをすべて読み込みます。次に、openshift start オプションの --public-master で定義される値、openshift-web-console namespace で定義される webconsole-config 設定マップの関連パラメーター masterPublicURL から定義される値を使用して、OpenShift Container Platform API に要求を行います。Web コンソールは WebSocket を使用して API サーバーとの永続的な接続を維持し、更新情報を利用可能になる時点で受信します。

図2.1 ｓWeb コンソール要求アーキテクチャー

The configured host names and IP addresses for the web console are whitelisted to access the API server safely even when the browser would consider the requests to be cross-origin. To access the API server from a web application using a different host name, you must whitelist that host name by specifying the --cors-allowed-origins option on openshift start or from the related master configuration file parameter corsAllowedOrigins.

corsAllowedOrigins パラメーターは設定フィールドで制御されます。値に対してピニングやエスケープは実行されません。以下は、ホスト名をピニングし、ドットをエスケープする方法の例を示しています。

corsAllowedOrigins:
- (?i)//my\.subdomain\.domain\.com(:|\z)

Web コンソールのヘルプアイコンから CLI ダウンロードにアクセスできます。

Cluster administrators can customize these links further.

OpenShift Container Platform のテスト済みの統合を確認します。

After logging in, the web console provides developers with an overview for the currently selected project:

図2.2 Web コンソールのプロジェクト概要

Java イメージをベースとする Pod の場合、Web コンソールは関連する統合コンポーネントを表示し、管理するための hawt.io ベースの JVM コンソールへのアクセスも公開します。Connect リンクは、コンテナーに jolokia という名前のポートがある場合は、Browse Pods ページの Pod の詳細に表示されます。

図2.3 JVM コンソールへのリンクを持つ Pod

JVM コンソールへの接族後に、接続されている Pod に関連するコンポーネントに応じて異なるページが表示されます。

図2.4 JVM コンソール

以下のページが利用可能になります。

StatefulSet コントローラーは Pod の一意のアイデンティティーを提供し、デプロイメントおよびスケーリングの順序を定めます。StatefulSet は一意のネットワークアイデンティティー、永続ストレージ、正常なデプロイメントおよびスケーリング、および正常な削除および停止に役立ちます。

図2.5 OpenShift Container Platform の StatefulSet