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

コントロールプレーンのコンポーネント、API サーバーおよびコントローラーマネージャーのコンポーネントは、kubelet で操作される 静的 Pod として実行されます。

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

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

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

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

起動シーケンスの概要

Hyperkube は、すべての Kubernetes (kube-apiserver、controller-manager、scheduler、proxy、および kubelet) を含むバイナリーです。起動時に、kubelet は kubepods.slice を作成します。次に、kubelet は kubepods.slice 内に QoS レベルのスライス burstable.slice と best-effort.slice を作成します。Pod が開始されると、kubelet は pod<UUID-of-pod>.slice 形式で Pod レベルのスライスを作成し、そのパスを Container Runtime Interface (CRI) の反対側のランタイムに渡します。次に、Docker または CRI-O は、Pod レベルのスライス内にコンテナーレベルのスライスを作成します。

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 を増やすなど、一般的な操作を実行して、問題が発生した場合により詳細なデータを参照できるようにする場合があります。コンテナー内で実行中のプロセスに渡せるように、/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: ""

ノードの設定はマスターからブートストラップされます。つまり、ノードが事前定義済みの設定、クライアントとサーバーの証明書をマスターからプルします。これにより、ノード間の相違点を減らして、より多くの設定を集約し、クラスターを必要な状態で収束させることで、ノードの起動時間を短縮することができます。 証明書のローテーションや集約された証明書の管理はデフォルトで有効にされます。

図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