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

OpenShift Container Platform 3.10 以降で、コアとなるコントロールプレーンのコンポーネントをインストール、操作するデプロイメントモデルが変更されました。3.10 以前は、API サーバーとコントローラーマネージャーのコンポーネントは、systemd が操作するスタンドアロンのホストプロセスとして実行されていました。3.10 では、これらのコンポーネントが kubelet が操作する 静的 Pod に移行されています。

etcd が同じホストに共存しているマスターでは、etcd も静的 Pod に移動されます。RPM ベースの etcd は依然として、マスターではない etcd ホスト上でサポートされます。

さらに、ノードコンポーネントの openshift-sdn と openvswitch が systemd サービスではなく、DaemonSet を使用して実行されます。

図2.1 コントロールプレーンホストのアーキテクチャーの変更

「マスターおよびノードの設定」のトピックに記載されているように、静的 Pod として実行中のコントロールプレーンのコンポーネントの場合でさえも、マスターホストは /etc/origin/master/master-config.yaml ファイルからの設定をソースとして使用します。

Pod のミラーリング

マスターノード上の kubelet は自動的に、コントロールプレーンの静的 Pod 毎に、API サーバー上に ミラーの Pod を作成し、kube-system プロジェクトのクラスターで表示できるようにします。これらの静的 Pod のマニフェストは、デフォルトで、マスターホスト上の /etc/origin/node/pods ディレクトリーに配置されている openshift-ansible インストーラーによりインストールされます。

これらの Pod は、以下のhostPath ボリュームを定義します。

以下など、静的 Pod で実行可能な操作には限りがあります。

$ oc logs master-api-<hostname> -n kube-system

API サーバーからの標準出力を返します。ただし、

$ oc delete pod master-api-<hostname> -n kube-system

上記のコマンドでは実際には Pod は削除されません。

別の例として、クラスター管理者は、API サーバーの loglevel を増やすなど、一般的な操作を実行して、問題が発生した場合により詳細なデータを参照できるようにする場合があります。OpenShift Container Platform 3.10 では、コンテナー内で実行中のプロセスに渡せるように、/etc/origin/master/master.env ファイルを編集して、OPTIONS 変数の --loglevel パラメーターを変更する必要があります。変更を適用するには、コンテナー内で実行中のプロセスを再起動する必要があります。

マスターサービスの再起動

コントロールプレーンの静的 Pod で実行中のコントロールプレーンサービスを再起動するには、マスターホストの master-restart コマンドを使用します。

マスター API を再起動します。

# master-restart api

コントローラーを再起動します。

# master-restart controllers

etcd を再起動します。

# master-restart etcd

マスターサービスログの表示

コントロールプレーンの静的 Pod で実行中のコントロールプレーンサービスのログを表示するには、適切なコンポーネントの master-logs コマンドを使用します。

# master-logs api api
# master-logs controllers controllers
# master-logs etcd etcd

マスターまたはそのサービスのいずれかが失敗しても、実行中のアプリケーションの可用性はそのまま維持されます。ただし、マスターサービスが失敗すると、システムのアプリケーションの失敗に対応する機能、または新規アプリケーションの作成に対応する機能が低下します。オプションで、クラスターに単一障害点をなくせるように、高可用性 (HA) のマスターを設定できます。

マスターの可用性についての懸念を少なくするために、2 つのアクティビティーを実行することが推奨されます。

native HA 方式を HAProxy で使用する際に、マスターコンポーネントには以下の可用性があります。

クラスター化された etcd では定足数を維持するためにホストの数は奇数である必要がありますが、マスターサービスには定足数やホストの数が奇数でなければならないという要件はありません。ただし、HA 用に 2 つ以上のマスターサービスが必要になるため、マスターサービスと etcd を共存させる場合には、一律奇数のホストを維持することが一般的です。

各ノードには、Pod を記述する YAML ファイルであるコンテナーマニフェストで指定されるようにノードを更新する kubelet があります。kubelet は一連のマニフェストを使用して、そのコンテナーが起動しており、継続して実行することを確認します。

コンテナーマニフェストは以下によって kubelet に提供できます。

各ノードは、ノード上で API で定義されるサービスを反映した単純なネットワークプロキシーも実行します。これにより、ノードは一連のバックエンドで単純な TCP および UDP ストリームの転送を実行できます。

以下は、Kubernetes のノードオブジェクト定義の例になります。

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 3.10 以降では、ノードの設定はマスターからブートストラップされます。つまり、ノードが事前定義済みの設定、クライアントとサーバーの証明書をマスターからプルします。これにより、ノード間の相違点を減らして、より多くの設定を集約し、希望の状態でのクラスターを収束することで、ノードの起動時間を短縮することができます。証明書の回転や集約された証明書の管理は、デフォルトで有効になっています。

図2.2 ノードブートストラップのワークフローに関する概要

ノードサービスの起動時に、ノードは /etc/origin/node/node.kubeconfig ファイルと他のノード設定ファイルが存在するかチェックしてから、クラスターに参加します。存在しない場合には、ノードはマスターから設定をプルしてから、クラスターに参加します。

ConfigMaps は、クラスターにノードの設定を保存するのに使用し、ノードホスト上の /etc/origin/node/node-config.yaml い設定ファイルを生成します。デフォルトのノードグループやその ConfigMaps の定義については、『クラスターのインストール』ガイドの「ノードグループとホストマッピングの定義」を参照してください。

ノードブートストラップのワークフロー

自動ノードブートストラップのプロセスでは、以下のワークフローを使用します。

ノード設定のワークフロー

ノードの設定を取得するには、以下のワークフローを使用します。

ノード設定の変更

ノードの設定は、openshift-node プロジェクトの適切な ConfigMap を編集して変更します。/etc/origin/node/node-config.yaml は直接変更しないでください。

たとえば、node-config-compute グループに含まれるノードの場合は、以下のコマンドを使用して ConfigMap を編集します。

$ oc edit cm node-config-compute -n openshift-node

OpenShift Container Platform はユーザーが指定する認証情報を使ってプライベートリポジトリーにアクセスするためにレジストリーと通信します。これにより、OpenShift はベートレジストリーから/へのイメージのプッシュ/プルを行うことができます。「認証」のトピックには詳細が記載されています。