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
ディレクトリー全体のバックアップを作成します。
手順
各マスターノードで以下の手順を実行する必要があります。
- ここでは、Pod 定義のバックアップを作成します。
マスターホストの設定ファイルのバックアップを作成します。
$ 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 ノードのスケールアップ操作に必要であり、元のマスターが完全に利用できなくなった場合には、別のマスターノードに復元する必要があります。これらのディレクトリーは、ここで説明するバックアップ手順にデフォルトで含まれています。バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。
ファイル
説明
/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/
パッケージが間違って削除されてしまう場合や、
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
これまでの手順を実行している場合、以下のファイルがバックアップディレクトリーに置かれます。
$ 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 データストアをバックアップしてください。
静的 Pod マニフェストから etcd エンドポイント IP アドレスを取得します。
$ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
$ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
管理者としてログインします。
$ oc login -u system:admin
etcd Pod 名を取得します。
$ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '^master-etcd\S*')
kube-system
プロジェクトに切り替えます。$ oc project kube-system
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
アプライアンスを使用する場合は、特定の製品ドキュメントを参照してマスターをローテーションから削除するようにしてください。
手順
/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
次に、
haproxy
サービスを再起動します。$ sudo systemctl restart haproxy
マスターがロードバランサーから削除される場合、定義ファイルを静的 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/: +
- マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、ノードホストの使用の終了 セクションの手順に従ってください。
マスターホストを
/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 ホストマスターが非推奨になっている場合は、別のマスターノードで復元する必要があります。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 ホストが失敗する場合は、クラスターから削除します。
すべてのマスターホストで実行する手順
手順
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>
すべてのマスターでマスター API サービスを再起動します。
# master-restart api restart-master controller
現在の etcd クラスターで実行する手順
手順
失敗したホストをクラスターから削除します。
# 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 が必要です。
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 サービスの再起動は不要です。Ansible インベントリーファイルをクラスターの現在のステータスを反映し、Playbook の再実行時の問題を防げるように変更します。
[OSEv3:children] masters nodes etcd ... [OUTPUT ABBREVIATED] ... [etcd] master-0.example.com master-1.example.com
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
flanneld
サービスを再起動します。# systemctl restart flanneld.service