Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

5.2. マスターホストのタスク

5.2.1. マスターホストの使用の終了

マスターホストの使用を終了することにより、マスターホストを OpenShift Container Platform 環境から削除できます。

マスターホストの使用終了やサイズ縮小が必要になる要因には、ハードウェアのサイズ変更または基礎となるインフラストラクチャーの置き換えなどが含まれます。

可用性の高い OpenShift Container Platform 環境には、少なくとも 3 つのマスターホストと 3 つの etcd ノードが必要です。通常、マスターホストは etcd サービスと同じ場所に置かれます。マスターホストの使用を終了する場合は、そのホストから etcd の静的 Pod を削除する必要もあります。

重要

マスターおよび etcd サービスは、サービス間で実行される投票メカニズムにより常に奇数の数でデプロイするようにします。

5.2.1.1. マスターホストのバックアップの作成

バックアッププロセスは、システム更新やアップグレードまたはその他の大きな変更を含む変更を OpenShift Container Platform インフラストラクチャーに加える前に実行します。データのバックアップは、障害発生時に最新データが利用可能になるように定期的に実行します。

OpenShift Container Platform ファイル

マスターインスタンスは API、コントローラーなどの重要なサービスを実行します。/etc/origin/master ディレクトリーには、以下のような重要なファイルが数多く格納されています。

  • 設定、API コントローラー、サービスなど
  • インストールで生成される証明書
  • すべてのクラウドプロバイダー関連の設定
  • キーおよびその他の認証ファイル (htpasswd を使用する場合は htpasswd など)
  • その他

ログレベルの引き上げやプロキシーの使用などのカスタマイズを OpenShift Container Platform サービスに対して行うことができます。設定ファイルは /etc/sysconfig ディレクトリーに保存されます。

マスターはノードでもあるため、/etc/origin ディレクトリー全体のバックアップを作成します。

手順
重要

各マスターノードで以下の手順を実行する必要があります。

  1. ここでは、Pod 定義のバックアップを作成します。
  2. マスターホストの設定ファイルのバックアップを作成します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/ ${MYBACKUPDIR}/etc/sysconfig/
    注記

    マスター設定ファイルは /etc/origin/master/master-config.yaml です。

    警告

    /etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。

    重要

    複数のマスターを実行する OpenShift Container Platform 3.11 クラスターでは、マスターノードのいずれかの /etc/origin/master/etc/etcd/ca および /etc/etcd/generated_certs に追加の CA 証明書が含まれます。これらはアプリケーションノードおよび etcd ノードのスケールアップ操作に必要であり、元のマスターが完全に利用できなくなった場合には、別のマスターノードに復元する必要があります。これらのディレクトリーは、ここで説明するバックアップ手順にデフォルトで含まれています。

  3. バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。

    ファイル

    説明

    /etc/cni/*

    コンテナーネットワークインターフェイスの設定 (使用される場合)

    /etc/sysconfig/iptables

    iptables ルールが保存される場所

    /etc/sysconfig/docker-storage-setup

    container-storage-setup コマンドの入力ファイル

    /etc/sysconfig/docker

    docker 設定ファイル

    /etc/sysconfig/docker-network

    docker ネットワーク設定 (例: MTU)

    /etc/sysconfig/docker-storage

    docker ストレージ設定 (container-storage-setup で生成される)

    /etc/dnsmasq.conf

    dnsmasq の主要な設定ファイル

    /etc/dnsmasq.d/*

    異なる dnsmasq 設定ファイル

    /etc/sysconfig/flanneld

    flannel 設定ファイル (使用される場合)

    /etc/pki/ca-trust/source/anchors/

    システムに追加される証明書 (例: 外部レジストリー用)

    上記のファイルのバックアップを作成します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  4. パッケージが間違って削除されてしまう場合や、rpm パッケージに含まれるファイルを復元する必要がある場合に、システムにインストールされている rhel パッケージの一覧があると便利です。

    注記

    コンテンツビューやファクトストアなどの Red Hat Satellite 機能を使用する場合は、見つからないパッケージやシステムにインストールされているパッケージの履歴データを再インストールする適切なメカニズムを指定します。

    システムにインストールされている現在の rhel パッケージの一覧を作成するには、以下を実行します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  5. これまでの手順を実行している場合、以下のファイルがバックアップディレクトリーに置かれます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/master/ca.crt
    etc/origin/master/ca.key
    etc/origin/master/ca.serial.txt
    etc/origin/master/ca-bundle.crt
    etc/origin/master/master.proxy-client.crt
    etc/origin/master/master.proxy-client.key
    etc/origin/master/service-signer.crt
    etc/origin/master/service-signer.key
    etc/origin/master/serviceaccounts.private.key
    etc/origin/master/serviceaccounts.public.key
    etc/origin/master/openshift-master.crt
    etc/origin/master/openshift-master.key
    etc/origin/master/openshift-master.kubeconfig
    etc/origin/master/master.server.crt
    etc/origin/master/master.server.key
    etc/origin/master/master.kubelet-client.crt
    etc/origin/master/master.kubelet-client.key
    etc/origin/master/admin.crt
    etc/origin/master/admin.key
    etc/origin/master/admin.kubeconfig
    etc/origin/master/etcd.server.crt
    etc/origin/master/etcd.server.key
    etc/origin/master/master.etcd-client.key
    etc/origin/master/master.etcd-client.csr
    etc/origin/master/master.etcd-client.crt
    etc/origin/master/master.etcd-ca.crt
    etc/origin/master/policy.json
    etc/origin/master/scheduler.json
    etc/origin/master/htpasswd
    etc/origin/master/session-secrets.yaml
    etc/origin/master/openshift-router.crt
    etc/origin/master/openshift-router.key
    etc/origin/master/registry.crt
    etc/origin/master/registry.key
    etc/origin/master/master-config.yaml
    etc/origin/generated-configs/master-master-1.example.com/master.server.crt
    ...[OUTPUT OMITTED]...
    etc/origin/cloudprovider/openstack.conf
    etc/origin/node/system:node:master-0.example.com.crt
    etc/origin/node/system:node:master-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:master-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    必要な場合は、ファイルを圧縮してスペースを節約することができます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

これらのファイルのいずれかをゼロから作成するには、openshift-ansible-contrib リポジトリーに含まれる backup_master_node.sh スクリプトを使用します。このスクリプトは前述の手順を実行し、スクリプトが実行され、前述のすべてのファイルがコピーされるホスト上のディレクトリーを作成します。

注記

openshift-ansible-contrib スクリプトは Red Hat ではサポートされていませんが、リファレンスアーキテクチャーチームはコードが定義通りに動作し、安全であることを確認するテストを実施しています。

このスクリプトは、以下のコマンドを使用してすべてのマスターホストで実行することができます。

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

5.2.1.2. etcd のバックアップ

etcd のバックアップ時に、etcd 設定ファイルと etcd データの両方をバックアップする必要があります。

5.2.1.2.1. etcd 設定ファイルのバックアップ

保持する etcd 設定ファイルはすべて etcd が実行されているインスタンスの /etc/etcd ディレクトリーに保存されます。これには、etcd 設定ファイル (/etc/etcd/etcd.conf) およびクラスターの通信に必要な証明書が含まれます。それらすべてのファイルは Ansible インストーラーによってインストール時に生成されます。

手順

クラスターの各 etcd メンバーについての etcd 設定をバックアップします。

$ ssh master-0 1
# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
1
master-0 は、etcd メンバーの名前に置き換えます。
注記

各 etcd クラスターメンバーの証明書および設定ファイルは一意のものです。

5.2.1.2.2. etcd データのバックアップ
前提条件
注記

OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2 (etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。

ただし、etcdctl3 エイリアスは etcdctl コマンドに詳細なエンドポイント一覧を提供しないため、--endpoints オプションを指定し、すべてのエンドポイントを一覧表示する必要があります。

etcd をバックアップする前に、以下を確認してください。

  • etcdctl バイナリーが利用可能であるか、またはコンテナー化インストールの場合は rhel7/etcd コンテナーが利用可能でなければなりません。
  • OpenShift Container Platform API サービスが実行中であることを確認します。
  • etcd クラスターとの接続を確認します (ポート 2379/tcp)。
  • etcd クラスターに接続するために使用する適切な証明書があることを確認します。
手順
注記

etcdctl backup コマンドはバックアップを実行するために使用されますが、etcd v3 には バックアップ の概念がありません。代わりに、etcdctl snapshot save コマンドを使用してライブメンバーの snapshot を取るか、または etcd データディレクトリーの member/snap/db ファイルをコピーしてください。

etcdctl backup コマンドは、ノード ID やクラスター ID などのバックアップに含まれるメタデータの一部を書き換えるので、バックアップでは、ノードの以前のアイデンティティーが失われます。バックアップからクラスターを再作成するには、新規の単一ノードクラスターを作成してから、残りのノードをクラスターに追加します。メタデータは新規ノードが既存クラスターに加わらないように再作成されます。

etcd データをバックアップします。

重要

OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があります。すべての etcd データストアをバックアップしてください。

  1. 静的 Pod マニフェストから etcd エンドポイント IP アドレスを取得します。

    $ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
    $ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
  2. 管理者としてログインします。

    $ oc login -u system:admin
  3. etcd Pod 名を取得します。

    $ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '^master-etcd\S*')
  4. kube-system プロジェクトに切り替えます。

    $ oc project kube-system
  5. Pod の etcd データのスナップショットを作成し、これをローカルに保存します。

    $ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \
        --cert /etc/etcd/peer.crt \
        --key /etc/etcd/peer.key \
        --cacert /etc/etcd/ca.crt \
        --endpoints $ETCD_EP \
        snapshot save /var/lib/etcd/snapshot.db" 1
    1
    スナップショットは、/var/lib/etcd/ 配下のディレクトリーに記述する必要があります。

5.2.1.3. マスターホストの使用の終了

マスターホストは OpenShift Container Platform API およびコントローラーサービスなどの重要なサービスを実行します。マスターホストの使用を終了するには、これらのサービスが停止している必要があります。

OpenShift Container Platform API サービスはアクティブ/アクティブサービスであるため、サービスを停止しても、要求が別のマスターサーバーに送信される限り環境に影響はありません。ただし、OpenShift Container Platform コントローラーサービスはアクティブ/パッシブサービスであり、サービスは etcd を利用してアクティブなマスターを判別します。

複数マスターアーキテクチャーでマスターホストの使用を終了するには、新しい接続でのマスターの使用を防ぐためにマスターをロードバランサープールから削除することが関係します。このプロセスは使用されるロードバランサーによって大きく異なります。以下の手順では、マスターの haproxy からの削除についての詳しく説明しています。OpenShift Container Platform がクラウドプロバイダーで実行されている場合や、F5 アプライアンスを使用する場合は、特定の製品ドキュメントを参照してマスターをローテーションから削除するようにしてください。

手順
  1. /etc/haproxy/haproxy.cfg 設定ファイルで backend セクションを削除します。たとえば、haproxy を使用して master-0.example.com という名前のマスターの使用を終了する場合は、ホスト名が以下から削除されていることを確認します。

    backend mgmt8443
        balance source
        mode tcp
        # MASTERS 8443
        server master-1.example.com 192.168.55.12:8443 check
        server master-2.example.com 192.168.55.13:8443 check
  2. 次に、haproxy サービスを再起動します。

    $ sudo systemctl restart haproxy
  3. マスターがロードバランサーから削除される場合、定義ファイルを静的 Pod のディレクトリー /etc/origin/node/pods から移動して API およびコントローラーサービスを無効にします。

    # mkdir -p /etc/origin/node/pods/disabled
    # mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:
    +
  4. マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、ノードホストの使用の終了 セクションの手順に従ってください。
  5. マスターホストを /etc/ansible/hosts Ansible インベントリーファイルの [masters] および [nodes] グループから削除し、このインベントリーファイルを使用して Ansible タスクを実行する場合の問題を回避できます。

    警告

    Ansible インベントリーファイルに一覧表示される最初のマスターホストの使用を終了するには、とくに注意が必要になります。

    /etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。

    重要

    複数のマスターを実行する OpenShift Container Platform 3.11 クラスターでは、マスターノードのいずれかの /etc/origin/master/etc/etcd/ca および /etc/etcd/generated_certs に追加の CA 証明書が含まれます。これらは、アプリケーションノードおよび etcd ノードのスケールアップ操作に必要であり、CA ホストマスターが非推奨になっている場合は、別のマスターノードで復元する必要があります。

  6. kubernetes サービスにはマスターホスト IP がエンドポイントとして含まれています。マスターの使用が適切に終了していることを確認するには、kubernetes サービスの出力を確認して、使用が終了したマスターが削除されているかどうかを確認します。

    $ oc describe svc kubernetes -n default
    Name:			kubernetes
    Namespace:		default
    Labels:			component=apiserver
    			provider=kubernetes
    Annotations:		<none>
    Selector:		<none>
    Type:			ClusterIP
    IP:			10.111.0.1
    Port:			https	443/TCP
    Endpoints:		192.168.55.12:8443,192.168.55.13:8443
    Port:			dns	53/UDP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Port:			dns-tcp	53/TCP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Session Affinity:	ClientIP
    Events:			<none>

    マスターの使用が正常に終了している場合、マスターが以前に実行されていたホストを安全に削除できます。

5.2.1.4. etcd ホストの削除

復元後に etcd ホストが失敗する場合は、クラスターから削除します。

すべてのマスターホストで実行する手順

手順
  1. etcd クラスターから他の etcd ホストをそれぞれ削除します。それぞれの etcd ノードについて以下のコマンドを実行します。

    # etcdctl3 --endpoints=https://<surviving host IP>:2379
      --cacert=/etc/etcd/ca.crt
      --cert=/etc/etcd/peer.crt
      --key=/etc/etcd/peer.key member remove <failed member ID>
  2. すべてのマスターでマスター API サービスを再起動します。

    # master-restart api restart-master controller

現在の etcd クラスターで実行する手順

手順
  1. 失敗したホストをクラスターから削除します。

    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    failed to check the health of member 8372784203e11288 on https://192.168.55.21:2379: Get https://192.168.55.21:2379/health: dial tcp 192.168.55.21:2379: getsockopt: connection refused
    member 8372784203e11288 is unreachable: [https://192.168.55.21:2379] are all unreachable
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    
    # etcdctl2 member remove 8372784203e11288 1
    Removed member 8372784203e11288 from cluster
    
    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    1
    remove コマンドにはホスト名ではなく、etcd ID が必要です。
  2. etcd 設定で etcd サービスの再起動時に失敗したホストを使用しないようにするには、残りのすべての etcd ホストで /etc/etcd/etcd.conf ファイルを変更し、ETCD_INITIAL_CLUSTER 変数の値から失敗したホストを削除します。

    # vi /etc/etcd/etcd.conf

    以下に例を示します。

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380,master-2.example.com=https://192.168.55.13:2380

    以下のようになります。

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380
    注記

    失敗したホストは etcdctl を使用して削除されているので、etcd サービスの再起動は不要です。

  3. Ansible インベントリーファイルをクラスターの現在のステータスを反映し、Playbook の再実行時の問題を防げるように変更します。

    [OSEv3:children]
    masters
    nodes
    etcd
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
  4. Flannel を使用している場合、すべてのホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更し、etcd ホストを削除します。

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379
  5. flanneld サービスを再起動します。

    # systemctl restart flanneld.service