Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第5章 ホストレベルのタスク
5.1. ホストのクラスターへの追加
マスターまたはノードホストのクラスターへの追加についての詳細は、『クラスター設定ガイド』の「ホストの既存クラスターへの追加」のセクションを参照してください。
5.2. マスターホストのタスク
5.2.1. マスターホストの使用の終了
マスターホストの使用を終了することにより、マスターホストを OpenShift Container Platform 環境から削除できます。
マスターホストの使用終了やサイズ縮小が必要になる要因には、ハードウェアのサイズ変更または基礎となるインフラストラクチャーの置き換えなどが含まれます。
可用性の高い OpenShift Container Platform 環境には、少なくとも 3 つのマスターホストと 3 つの etcd ノードが必要です。通常、マスターホストは etcd サービスと同じ場所に置かれます。マスターホストの使用を終了する場合は、そのホストの etcd サービスの使用も終了する必要があります。
マスターおよび 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 ディレクトリー全体のバックアップを作成します。
手順
各マスターノードで以下の手順を実行する必要があります。
マスターホストの設定ファイルのバックアップを作成します。
$ 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/atomic-* ${MYBACKUPDIR}/etc/sysconfig/注記設定ファイルは、
/etc/sysconfig/atomic-openshift-master-apiおよび/etc/sysconfig/atomic-openshift-master-controllersディレクトリーに保存されています。警告/etc/origin/master/ca.serial.txtファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に/etc/origin/master/ca.serial.txtファイルを残りのマスターホストにコピーします。バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。
ファイル
説明
/etc/cni/*コンテナーネットワークインターフェースの設定 (使用される場合)
/etc/sysconfig/iptablesiptablesルールが保存される場所/etc/sysconfig/docker-storage-setupcontainer-storage-setupコマンドの入力ファイル/etc/sysconfig/dockerdocker設定ファイル/etc/sysconfig/docker-networkdockerネットワーク設定 (例: MTU)/etc/sysconfig/docker-storagedockerストレージ設定 (container-storage-setupで生成される)/etc/dnsmasq.confdnsmasqの主要な設定ファイル/etc/dnsmasq.d/*異なる
dnsmasq設定ファイル/etc/sysconfig/flanneldflannel設定ファイル (使用される場合)/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/atomic-openshift-master etc/sysconfig/atomic-openshift-master-api etc/sysconfig/atomic-openshift-master-controllers etc/sysconfig/atomic-openshift-node 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 # mkdir -p /backup/etcd-config-$(date +%Y%m%d)/ # cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
各 etcd クラスターメンバーの証明書および設定ファルは一意のものです。
5.2.1.2.2. etcd データのバックアップ
前提条件
OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2 (etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。
ただし、etcdctl3 エイリアスは etcdctl コマンドの詳細なエンドポイント一覧を提供しないため、すべてのエンドポイントと共に --endpoints オプションを指定する必要があります。
etcd をバックアップする前に、以下を確認してください。
-
etcdctlバイナリーが利用可能であるか、またはコンテナー化インストールではrhel7/etcdコンテナーが利用可能であること。 - etcd クラスターとの接続を確認する (ポート 2379/tcp) こと。
- etcd クラスターに接続するための適切な証明書があることを確認すること。
手順
etcdctl backup コマンドはバックアップを実行するために使用されますが、etcd v3 には バックアップ の概念がありません。代わりに etcdctl snapshot save コマンドを使用してライブメンバーの スナップショット を取るか、または etcd データディレクトリーの member/snap/db ファイルをコピーしてください。
etcdctl backup コマンドは、ノード ID やクラスター ID などのバックアップに含まれるメタデータの一部を書き換えるので、バックアップでは、ノードの以前のアイデンティティーが失われます。バックアップからクラスターを再作成するには、新規の単一ノードクラスターを作成してから、残りのノードをクラスターに追加します。メタデータは新規ノードが既存クラスターに加わらないように再作成されます。
etcd データをバックアップします。
v2 API を使用する場合には、以下のアクションを実行してください。
すべての etcd サービスを停止します。
# systemctl stop etcd.service
etcd データバックアップを作成し、etcd
dbファイルをコピーします。# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # cp /var/lib/etcd/member/snap/db /backup/etcd-$(date +%Y%m%d)
v3 API を使用する場合、以下のコマンドを実行します。
重要OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があるので、v2 と v3 の両方のデータストアをバックアップしてください。
# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl3 snapshot save /backup/etcd-$(date +%Y%m%d)/db Snapshot saved at /backup/etcd-<date>/db # systemctl stop etcd.service # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # systemctl start etcd.service注記etcdctl snapshot saveコマンドでは etcd サービスが実行中である必要があります。これらのコマンドでは、
/backup/etcd-<date>/ディレクトリーが作成されます。ここで、<date>は現在の日付を表します。このディレクトリーは、外部 NFS 共有、S3 バケットやその他の外部ストレージの場所のいずれかでなければなりません。オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.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
マスターがロードバランサーから削除された後に、API およびコントローラーサービスを無効にします。
$ sudo systemctl disable --now atomic-openshift-master-api $ sudo systemctl disable --now atomic-openshift-master-controllers
- マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、「ノードホストの使用終了」のセクションの手順に従ってください。
マスターホストを
/etc/ansible/hostsAnsible インベントリーファイルの[masters]および[nodes]グループから削除し、このインベントリーファイルを使用して Ansible タスクを実行する場合の問題を回避できます。警告Ansible インベントリーファイルに一覧表示される最初のマスターホストの使用を終了するには、とくに注意が必要になります。
/etc/origin/master/ca.serial.txtファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に/etc/origin/master/ca.serial.txtファイルを残りのマスターホストにコピーします。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 ノードについて以下のコマンドを実行します。
# etcdctl -C https://<surviving host IP address>:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/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
5.2.2. マスターホストのバックアップの作成
システム更新やアップグレード、またはその他の大きな変更など、OpenShift Container Platform インフラストラクチャーに変更を加える前に、このバックアッププロセスを実行するようにしてください。データのバックアップは、障害発生時に最新データが利用可能になるように定期的に実行します。
OpenShift Container Platform ファイル
マスターインスタンスは API、コントローラーなどの重要なサービスを実行します。/etc/origin/master ディレクトリーには、以下のような重要なファイルが数多く格納されています。
- 設定、API コントローラー、サービスなど
- インストールで生成される証明書
- すべてのクラウドプロバイダー関連の設定
-
キーおよびその他の認証ファイル (htpasswd を使用する場合は
htpasswdなど) - その他
ログレベルの引き上げやプロキシーの使用などのカスタマイズを OpenShift Container Platform サービスに対して行うことができます。設定ファイルは /etc/sysconfig ディレクトリーに保存されます。
マスターはノードでもあるため、/etc/origin ディレクトリー全体のバックアップを作成します。
手順
各マスターノードで以下の手順を実行する必要があります。
マスターホストの設定ファイルのバックアップを作成します。
$ 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/atomic-* ${MYBACKUPDIR}/etc/sysconfig/注記設定ファイルは、
/etc/sysconfig/atomic-openshift-master-apiおよび/etc/sysconfig/atomic-openshift-master-controllersディレクトリーに保存されています。警告/etc/origin/master/ca.serial.txtファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に/etc/origin/master/ca.serial.txtファイルを残りのマスターホストにコピーします。バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。
ファイル
説明
/etc/cni/*コンテナーネットワークインターフェースの設定 (使用される場合)
/etc/sysconfig/iptablesiptablesルールが保存される場所/etc/sysconfig/docker-storage-setupcontainer-storage-setupコマンドの入力ファイル/etc/sysconfig/dockerdocker設定ファイル/etc/sysconfig/docker-networkdockerネットワーク設定 (例: MTU)/etc/sysconfig/docker-storagedockerストレージ設定 (container-storage-setupで生成される)/etc/dnsmasq.confdnsmasqの主要な設定ファイル/etc/dnsmasq.d/*異なる
dnsmasq設定ファイル/etc/sysconfig/flanneldflannel設定ファイル (使用される場合)/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/atomic-openshift-master etc/sysconfig/atomic-openshift-master-api etc/sysconfig/atomic-openshift-master-controllers etc/sysconfig/atomic-openshift-node 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.3. マスターホストのバックアップの復元
重要なマスターホストファイルのバックアップを作成した後に、それらのファイルが破損するか、または間違って削除された場合は、それらのファイルをマスターにコピーし直してファイルを復元し、それらに適切なコンテンツが含まれることを確認し、影響を受けるサービスを再起動して実行できます。
手順
/etc/origin/master/master-config.yamlファイルを復元します。# MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* # cp /etc/origin/master/master-config.yaml /etc/origin/master/master-config.yaml.old # cp /backup/$(hostname)/$(date +%Y%m%d)/origin/master/master-config.yaml /etc/origin/master/master-config.yaml # master-restart api # master-restart controllers
警告マスターサービスの再起動によりダウンタイムが生じる場合があります。ただし、マスターホストを可用性の高いロードバランサープールから削除し、復元操作を実行することができます。サービスが適切に復元された後に、マスターホストをロードバランサープールに再び追加することができます。
注記影響を受けるインスタンスを完全に再起動して、
iptables設定を復元します。パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。
現在インストールされているパッケージの一覧を取得します。
$ rpm -qa | sort > /tmp/current_packages.txt
パッケージの一覧の間に存在する差分を表示します。
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt > ansible-2.4.0.0-5.el7.noarch足りないパッケージを再インストールします。
# yum reinstall -y <packages> 1- 1
<packages>は、パッケージの一覧ごとに異なるパッケージに置き換えます。
システム証明書を
/etc/pki/ca-trust/source/anchors/ディレクトリーにコピーして復元し、update-ca-trustを実行します。$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* $ sudo cp ${MYBACKUPDIR}/external_certificates/my_company.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust注記ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、
SELinuxコンテキストも復元されていることを常に確認してください。
5.3. ノードホストのタスク
5.3.1. ノードホストの使用の終了
この使用を終了する手順は、インフラストラクチャーノードの場合でもアプリケーションノードの場合でも同じです。
前提条件
既存の Pod を削除されるノードセットから移行するために必要な容量が十分にあることを確認します。インフラストラクチャーノードの削除は、2 つ以上のノードがインフラストラクチャーノードの削除後もオンライン状態である場合にのみ推奨されます。
手順
利用可能なすべてのノードを一覧表示し、使用を終了するノードを検索します。
$ oc get nodes NAME STATUS AGE VERSION ocp-infra-node-b7pl Ready 23h v1.6.1+5115d708d7 ocp-infra-node-p5zj Ready 23h v1.6.1+5115d708d7 ocp-infra-node-rghb Ready 23h v1.6.1+5115d708d7 ocp-master-dgf8 Ready,SchedulingDisabled 23h v1.6.1+5115d708d7 ocp-master-q1v2 Ready,SchedulingDisabled 23h v1.6.1+5115d708d7 ocp-master-vq70 Ready,SchedulingDisabled 23h v1.6.1+5115d708d7 ocp-node-020m Ready 23h v1.6.1+5115d708d7 ocp-node-7t5p Ready 23h v1.6.1+5115d708d7 ocp-node-n0dd Ready 23h v1.6.1+5115d708d7
一例として、このトピックでは
ocp-infra-node-b7plインフラストラクチャーノードの使用を終了します。ノードおよび、ノードで実行中のサービスの情報を取得します。
$ oc describe node ocp-infra-node-b7pl Name: ocp-infra-node-b7pl Role: Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=n1-standard-2 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=europe-west3 failure-domain.beta.kubernetes.io/zone=europe-west3-c kubernetes.io/hostname=ocp-infra-node-b7pl role=infra Annotations: volumes.kubernetes.io/controller-managed-attach-detach=true Taints: <none> CreationTimestamp: Wed, 22 Nov 2017 09:36:36 -0500 Phase: Conditions: ... Addresses: 10.156.0.11,ocp-infra-node-b7pl Capacity: cpu: 2 memory: 7494480Ki pods: 20 Allocatable: cpu: 2 memory: 7392080Ki pods: 20 System Info: Machine ID: bc95ccf67d047f2ae42c67862c202e44 System UUID: 9762CC3D-E23C-AB13-B8C5-FA16F0BCCE4C Boot ID: ca8bf088-905d-4ec0-beec-8f89f4527ce4 Kernel Version: 3.10.0-693.5.2.el7.x86_64 OS Image: Employee SKU Operating System: linux Architecture: amd64 Container Runtime Version: docker://1.12.6 Kubelet Version: v1.6.1+5115d708d7 Kube-Proxy Version: v1.6.1+5115d708d7 ExternalID: 437740049672994824 Non-terminated Pods: (2 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits --------- ---- ------------ ---------- --------------- ------------- default docker-registry-1-5szjs 100m (5%) 0 (0%) 256Mi (3%)0 (0%) default router-1-vzlzq 100m (5%) 0 (0%) 256Mi (3%)0 (0%) Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 200m (10%) 0 (0%) 512Mi (7%) 0 (0%) Events: <none>
上記の出力ではノードが
router-1-vzlzqとdocker-registry-1-5szjsの 2 つの Pod を実行中であることを示しています。2 つ以上のインフラストラクチャーノードがこれらの 2 つの Pod を移行するために利用可能です。注記上記のクラスターは可用性の高いクラスターであり、
routerとdocker-registryの両方のサービスがすべてのインフラストラクチャーノードで実行されています。ノードにスケジュール対象外のマークを付けるか、その Pod をすべて退避します。
$ oc adm drain ocp-infra-node-b7pl --delete-local-data node "ocp-infra-node-b7pl" cordoned WARNING: Deleting pods with local storage: docker-registry-1-5szjs pod "docker-registry-1-5szjs" evicted pod "router-1-vzlzq" evicted node "ocp-infra-node-b7pl" drained
Pod に割り当て済みのローカルストレージ (
EmptyDirなど) がある場合、--delete-local-dataオプションを指定する必要があります。通常は、実稼働で実行される Pod はローカルストレージを一時的な、またはキャッシュファイルのみに使用し、重要で永続的なファイルには使用しません。通常のストレージの場合、アプリケーションはオブジェクトストレージまたは永続ボリュームを使用します。この場合、コンテナーイメージを保存するためにオブジェクトストレージが使用されるため、docker-registryPod のローカルストレージは空になります。注記上記の操作はノードで実行されている既存の Pod を削除します。次に、新規 Pod がレプリケーションコントローラーに応じて作成されます。
通常、すべてのアプリケーションは、レプリケーションコントローラーを使用して Pod を作成するデプロイメント設定でデプロイされる必要があります。
oc adm drainはベア Pod (Pod をミラーリングしない、またはReplicationController、ReplicaSet、DaemonSet、StatefulSet、またはジョブで管理されない Pod) を削除しません。この実行には--forceオプションが必要です。ベア Pod は他のノードでは再作成されず、この操作中にデータが失われる可能性があることに注意してください。以下の例は、レジストリーのレプリケーションコントローラーの出力を示しています。
$ oc describe rc/docker-registry-1 Name: docker-registry-1 Namespace: default Selector: deployment=docker-registry-1,deploymentconfig=docker-registry,docker-registry=default Labels: docker-registry=default openshift.io/deployment-config.name=docker-registry Annotations: ... Replicas: 3 current / 3 desired Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: deployment=docker-registry-1 deploymentconfig=docker-registry docker-registry=default Annotations: openshift.io/deployment-config.latest-version=1 openshift.io/deployment-config.name=docker-registry openshift.io/deployment.name=docker-registry-1 Service Account: registry Containers: registry: Image: openshift3/ose-docker-registry:v3.6.173.0.49 Port: 5000/TCP Requests: cpu: 100m memory: 256Mi Liveness: http-get https://:5000/healthz delay=10s timeout=5s period=10s #success=1 #failure=3 Readiness: http-get https://:5000/healthz delay=0s timeout=5s period=10s #success=1 #failure=3 Environment: REGISTRY_HTTP_ADDR: :5000 REGISTRY_HTTP_NET: tcp REGISTRY_HTTP_SECRET: tyGEnDZmc8dQfioP3WkNd5z+Xbdfy/JVXf/NLo3s/zE= REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA: false REGISTRY_HTTP_TLS_KEY: /etc/secrets/registry.key OPENSHIFT_DEFAULT_REGISTRY: docker-registry.default.svc:5000 REGISTRY_CONFIGURATION_PATH: /etc/registry/config.yml REGISTRY_HTTP_TLS_CERTIFICATE: /etc/secrets/registry.crt Mounts: /etc/registry from docker-config (rw) /etc/secrets from registry-certificates (rw) /registry from registry-storage (rw) Volumes: registry-storage: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: registry-certificates: Type: Secret (a volume populated by a Secret) SecretName: registry-certificates Optional: false docker-config: Type: Secret (a volume populated by a Secret) SecretName: registry-config Optional: false Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 49m 49m 1 replication-controller Normal SuccessfulCreate Created pod: docker-registry-1-dprp5出力の下部にあるイベントは新規 Pod 作成についての情報を表示しています。すべての Pod の一覧表示では、以下のようになります。
$ oc get pods NAME READY STATUS RESTARTS AGE docker-registry-1-dprp5 1/1 Running 0 52m docker-registry-1-kr8jq 1/1 Running 0 1d docker-registry-1-ncpl2 1/1 Running 0 1d registry-console-1-g4nqg 1/1 Running 0 1d router-1-2gshr 0/1 Pending 0 52m router-1-85qm4 1/1 Running 0 1d router-1-q5sr8 1/1 Running 0 1d
-
非推奨のノードで実行されていた
docker-registry-1-5szjsおよびrouter-1-vzlzqPod は、利用できなくなります。代わりに 2 つの新規 Poddocker-registry-1-dprp5およびrouter-1-2gshrが作成されています。上記のように、新規のルーター Pod はrouter-1-2gshrですがPending状態になります。これは、すべてのノードが単一ルーターでのみ実行でき、ホストのポート 80 および 443 にバインドされるためです。 新規作成されたレジストリー Pod を確認する場合に、以下の例では、Pod が、非推奨のノードではなく、
ocp-infra-node-rghbノードで作成されたことが分かります。$ oc describe pod docker-registry-1-dprp5 Name: docker-registry-1-dprp5 Namespace: default Security Policy: hostnetwork Node: ocp-infra-node-rghb/10.156.0.10 ...
アプリケーションノードとインフラストラクチャーの使用終了において、唯一の相違点は、インフラストラクチャーノードが退避された後に、そのノードを置き換える予定がない場合には、インフラストラクチャーノードで実行中のサービスをスケールダウンできる点です。
$ oc scale dc/router --replicas 2 deploymentconfig "router" scaled $ oc scale dc/docker-registry --replicas 2 deploymentconfig "docker-registry" scaled
ここで、すべてのインフラストラクチャーノードはそれぞれの Pod を 1 種類のみ実行しています。
$ oc get pods NAME READY STATUS RESTARTS AGE docker-registry-1-kr8jq 1/1 Running 0 1d docker-registry-1-ncpl2 1/1 Running 0 1d registry-console-1-g4nqg 1/1 Running 0 1d router-1-85qm4 1/1 Running 0 1d router-1-q5sr8 1/1 Running 0 1d $ oc describe po/docker-registry-1-kr8jq | grep Node: Node: ocp-infra-node-p5zj/10.156.0.9 $ oc describe po/docker-registry-1-ncpl2 | grep Node: Node: ocp-infra-node-rghb/10.156.0.10
注記完全に高可用のクラスターを提供するには、3 つ以上のインフラストラクチャーノードが常に利用可能である必要があります。
ノードのスケジューリングが無効にされていることを確認するには、以下を実行します。
$ oc get nodes NAME STATUS AGE VERSION ocp-infra-node-b7pl Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-infra-node-p5zj Ready 1d v1.6.1+5115d708d7 ocp-infra-node-rghb Ready 1d v1.6.1+5115d708d7 ocp-master-dgf8 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-master-q1v2 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-master-vq70 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-node-020m Ready 1d v1.6.1+5115d708d7 ocp-node-7t5p Ready 1d v1.6.1+5115d708d7 ocp-node-n0dd Ready 1d v1.6.1+5115d708d7
また、ノードに Pod が含まれていないことを確認するには、以下を実行します。
$ oc describe node ocp-infra-node-b7pl Name: ocp-infra-node-b7pl Role: Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=n1-standard-2 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=europe-west3 failure-domain.beta.kubernetes.io/zone=europe-west3-c kubernetes.io/hostname=ocp-infra-node-b7pl role=infra Annotations: volumes.kubernetes.io/controller-managed-attach-detach=true Taints: <none> CreationTimestamp: Wed, 22 Nov 2017 09:36:36 -0500 Phase: Conditions: ... Addresses: 10.156.0.11,ocp-infra-node-b7pl Capacity: cpu: 2 memory: 7494480Ki pods: 20 Allocatable: cpu: 2 memory: 7392080Ki pods: 20 System Info: Machine ID: bc95ccf67d047f2ae42c67862c202e44 System UUID: 9762CC3D-E23C-AB13-B8C5-FA16F0BCCE4C Boot ID: ca8bf088-905d-4ec0-beec-8f89f4527ce4 Kernel Version: 3.10.0-693.5.2.el7.x86_64 OS Image: Employee SKU Operating System: linux Architecture: amd64 Container Runtime Version: docker://1.12.6 Kubelet Version: v1.6.1+5115d708d7 Kube-Proxy Version: v1.6.1+5115d708d7 ExternalID: 437740049672994824 Non-terminated Pods: (0 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits --------- ---- ------------ ---------- --------------- ------------- Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 0 (0%) 0 (0%) 0 (0%) 0 (0%) Events: <none>
インフラストラクチャーインスタンスを
/etc/haproxy/haproxy.cfg設定ファイルのbackendセクションから削除します。backend router80 balance source mode tcp server infra-1.example.com 192.168.55.12:80 check server infra-2.example.com 192.168.55.13:80 check backend router443 balance source mode tcp server infra-1.example.com 192.168.55.12:443 check server infra-2.example.com 192.168.55.13:443 check次に、
haproxyサービスを再起動します。$ sudo systemctl restart haproxy
このコマンドで、すべての Pod をエビクトした後にクラスターからノードを削除します。
$ oc delete node ocp-infra-node-b7pl node "ocp-infra-node-b7pl" deleted
$ oc get nodes NAME STATUS AGE VERSION ocp-infra-node-p5zj Ready 1d v1.6.1+5115d708d7 ocp-infra-node-rghb Ready 1d v1.6.1+5115d708d7 ocp-master-dgf8 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-master-q1v2 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-master-vq70 Ready,SchedulingDisabled 1d v1.6.1+5115d708d7 ocp-node-020m Ready 1d v1.6.1+5115d708d7 ocp-node-7t5p Ready 1d v1.6.1+5115d708d7 ocp-node-n0dd Ready 1d v1.6.1+5115d708d7
Pod またはノードの退避またはドレイン (解放) についての詳細は、「ノードの保守」のセクションを参照してください。
5.3.1.1. ノードホストの置き換え
使用終了となったノードの代わりに、ノードを追加する必要がある場合には、「ホストの既存クラスターへの追加」のセクションを参照してください。
5.3.2. ノードホストのバックアップの作成
ノードホストのバックアップ作成と、マスターホストのバックアップはユースケースが異なります。マスターホストには数多くの重要なファイルが含まれるため、バックアップを作成することを強く推奨します。しかしノードの性質上、フェイルオーバーが発生したときのために、特殊なアイテムはノード上で複製されて、通常は環境の実行に必要なデータは含まれません。ノードのバックアップに、環境実行に必要なアイテムが含まれる場合には、バックアップを作成することを推奨します。
システム更新やアップグレード、またはその他の大きな変更など、OpenShift Container Platform インフラストラクチャーに変更を加える前に、このバックアッププロセスを実行するようにしてください。バックアップは、障害の発生時に最新データが利用可能になるように定期的に実行する必要があります。
OpenShift Container Platform ファイル
ノードインスタンスはコンテナーをベースとする Pod の形式で実行されます。/etc/origin/ および /etc/origin/node ディレクトリーは以下のような重要なファイルを格納します。
- ノードサービスの設定
- インストールで生成される証明書
- クラウドプロバイダー関連の設定
-
キーおよびその他の認証ファイル (
dnsmasq設定など)
OpenShift Container Platform サービスは、ログレベルの引き上げやプロキシーの使用などを実行するためにカスタマイズでき、設定ファイルは /etc/sysconfig ディレクトリーに保存されます。
手順
ノード設定ファイルのバックアップを作成します。
$ 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/atomic-openshift-node ${MYBACKUPDIR}/etc/sysconfig/OpenShift Container Platform では以下のような特定のファイルを使用します。バックアップポリシーの計画時には、これらのファイルを考慮する必要があります。
ファイル
説明
/etc/cni/*コンテナーネットワークインターフェースの設定 (使用される場合)
/etc/sysconfig/iptablesiptablesルールが保存される場所/etc/sysconfig/docker-storage-setupcontainer-storage-setupコマンドの入力ファイル/etc/sysconfig/dockerdocker設定ファイル/etc/sysconfig/docker-networkdockerネットワーク設定 (例: MTU)/etc/sysconfig/docker-storagedockerストレージ設定 (container-storage-setupで生成される)/etc/dnsmasq.confdnsmasqの主要な設定ファイル/etc/dnsmasq.d/*異なる
dnsmasq設定ファイル/etc/sysconfig/flanneldflannel設定ファイル (使用される場合)/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/atomic-openshift-node 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/node/system:node:app-node-0.example.com.crt etc/origin/node/system:node:app-node-0.example.com.key etc/origin/node/ca.crt etc/origin/node/system:node:app-node-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/origin/cloudprovider/openstack.conf 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.3.3. ノードホストバックアップの復元
重要なノードホストファイルのファイルのバックアップを作成した後に、それらのファイルが破損するか、または間違って削除された場合、これらのファイルをコピーし直してファイルを復元し、適切なコンテンツが含まれることを確認してから、影響を受けるサービスを再起動します。
手順
/etc/origin/node/node-config.yamlファイルを復元します。# MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d) # cp /etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml.old # cp /backup/$(hostname)/$(date +%Y%m%d)/etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml # systemctl restart atomic-openshift-node
サービスの再起動によりダウンタイムが生じる場合があります。このプロセスを容易にするためのヒントについては、「ノードの保守」を参照してください。
影響を受けるインスタンスを完全に再起動して、iptables 設定を復元します。
パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。
現在インストールされているパッケージの一覧を取得します。
$ rpm -qa | sort > /tmp/current_packages.txt
パッケージの一覧の間に存在する差分を表示します。
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt > ansible-2.4.0.0-5.el7.noarch足りないパッケージを再インストールします。
# yum reinstall -y <packages> 1- 1
<packages>は、パッケージの一覧ごとに異なるパッケージに置き換えます。
システム証明書を
/etc/pki/ca-trust/source/anchors/ディレクトリーにコピーして復元し、update-ca-trustを実行します。$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* $ sudo cp ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/my_company.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust注記ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、
SELinuxコンテキストも復元されていることを常に確認してください。
5.3.4. ノードの保守と次の手順
各種のノードの管理オプションについては、「ノードの管理」または「Pod の管理」のトピックを参照してください。ノードの管理オプションには、以下が含まれます。
ノードはそのリソースの一部を特定コンポーネントによって使用されるように予約することができます。これらには、kubelet、kube-proxy、Docker、または sshd および NetworkManager などの他の残りのシステムコンポーネントが含まれます。詳細は、「ノードリソースの割り当て」を参照してください。
5.4. etcd タスク
5.4.1. etcd のバックアップ
etcd はすべてのオブジェクト定義、および永続マスターの状態を保存するキー値のストアです。他のコンポーネントは変更の有無を監視して、それぞれ任意の状態に切り替えます。
3.5 よりも前の OpenShift Container Platform バージョンは etcd バージョン 2 (v2) を使用し、3.5 以降ではバージョン 3 (v3) を使用します。etcd のデータモデルは、この 2 つのバージョン間で異なります。etcd v3 は v2 と v3 データモデルの両方を使用できますが、etcd v2 は v2 データモデルしか使用できません。etcd v3 サーバーでは、v2 および v3 データストアは並列して存在し、それぞれ独立しています。
v2 および v3 の両方の操作については、ETCDCTL_API 環境変数を使用して適切な API を使用できます。
$ etcdctl -v etcdctl version: 3.2.5 API version: 2 $ ETCDCTL_API=3 etcdctl version etcdctl version: 3.2.5 API version: 3.2
v3 への移行方法についての詳細は、OpenShift Container Platform 3.7 ドキュメントの「Migrating etcd Data (v2 to v3)」のセクションを参照してください。
etcd のバックアッププロセスは 2 つの異なる手順で構成されています。
- 設定のバックアップ: 必要な etcd 設定および証明書が含まれます。
- データのバックアップ: v2 と v3 の両方のデータモデルが含まれます。
データのバックアッププロセスは、適切な証明書が提供され、etcdctl ツールがインストールされている etcd クラスターに接続できるホストで実行できます。
バックアップファイルは可能な場合は OpenShift Container Platform 環境外の外部システムにコピーしてから暗号化する必要があります。
etcd のバックアップには現在のストレージボリュームへのすべての参照が含まれることに注意してください。OpenShift Container Platform は、etcd の復元時に、ノードで以前の Pod を起動して同じストレージを再割当てし始めます。このプロセスは、ノードをクラスターから削除し、新規ノードを代わりに追加するプロセスと変わりがありません。対象のノードに割り当てられているものはすべて、Pod の再スケジュール先のノードに関係なく この Pod に再び割り当てられます。
5.4.1.1. etcd のバックアップ
etcd のバックアップ時に、etcd 設定ファイルと etcd データの両方をバックアップする必要があります。
5.4.1.1.1. etcd 設定ファイルのバックアップ
保持する etcd 設定ファイルはすべて etcd が実行されているインスタンスの /etc/etcd ディレクトリーに保存されます。これには、etcd 設定ファイル (/etc/etcd/etcd.conf) およびクラスターの通信の必要な証明書が含まれます。それらすべてのファイルは Ansible インストーラーによってインストール時に生成されます。
手順
クラスターの各 etcd メンバーについての etcd 設定をバックアップします。
$ ssh master-0 # mkdir -p /backup/etcd-config-$(date +%Y%m%d)/ # cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
各 etcd クラスターメンバーの証明書および設定ファルは一意のものです。
5.4.1.1.2. etcd データのバックアップ
前提条件
OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2 (etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。
ただし、etcdctl3 エイリアスは etcdctl コマンドの詳細なエンドポイント一覧を提供しないため、すべてのエンドポイントと共に --endpoints オプションを指定する必要があります。
etcd をバックアップする前に、以下を確認してください。
-
etcdctlバイナリーが利用可能であるか、またはコンテナー化インストールではrhel7/etcdコンテナーが利用可能であること。 - etcd クラスターとの接続を確認する (ポート 2379/tcp) こと。
- etcd クラスターに接続するための適切な証明書があることを確認すること。
手順
etcdctl backup コマンドはバックアップを実行するために使用されますが、etcd v3 には バックアップ の概念がありません。代わりに etcdctl snapshot save コマンドを使用してライブメンバーの スナップショット を取るか、または etcd データディレクトリーの member/snap/db ファイルをコピーしてください。
etcdctl backup コマンドは、ノード ID やクラスター ID などのバックアップに含まれるメタデータの一部を書き換えるので、バックアップでは、ノードの以前のアイデンティティーが失われます。バックアップからクラスターを再作成するには、新規の単一ノードクラスターを作成してから、残りのノードをクラスターに追加します。メタデータは新規ノードが既存クラスターに加わらないように再作成されます。
etcd データをバックアップします。
v2 API を使用する場合には、以下のアクションを実行してください。
すべての etcd サービスを停止します。
# systemctl stop etcd.service
etcd データバックアップを作成し、etcd
dbファイルをコピーします。# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # cp /var/lib/etcd/member/snap/db /backup/etcd-$(date +%Y%m%d)
v3 API を使用する場合、以下のコマンドを実行します。
重要OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があるので、v2 と v3 の両方のデータストアをバックアップしてください。
# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl3 snapshot save /backup/etcd-$(date +%Y%m%d)/db Snapshot saved at /backup/etcd-<date>/db # systemctl stop etcd.service # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # systemctl start etcd.service注記etcdctl snapshot saveコマンドでは etcd サービスが実行中である必要があります。これらのコマンドでは、
/backup/etcd-<date>/ディレクトリーが作成されます。ここで、<date>は現在の日付を表します。このディレクトリーは、外部 NFS 共有、S3 バケットやその他の外部ストレージの場所のいずれかでなければなりません。オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.etcdディレクトリーに置かれます。
5.4.2. etcd の復元
etcd 設定ファイルの復元手順では、適切なファイルを置き換えてからサービスを再起動します。
etcd ホストが破損し、/etc/etcd/etcd.conf ファイルが失われる場合は、以下を使用してこれを復元します。
$ ssh master-0 # cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf # restorecon -Rv /etc/etcd/etcd.conf # systemctl restart etcd.service
この例では、バックアップファイルは /backup/yesterday/master-0-files/etcd.conf パスに保存されており、ここでは外部 NFS 共有、S3 バケットまたはその他のストレージソリューションとして使用されます。
5.4.2.1. etcd v2 および v3 データの復元
以下のプロセスでは正常なデータファイルを復元し、etcd クラスターを単一ノードとして起動してから、etcd クラスターが必要な場合に残りのノードを追加します。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
適切なバックアップが復元されていることを確認するには、etcd ディレクトリーを削除します。
ディレクトリーを削除する前に現在の etcd データをバックアップするには、以下のコマンドを実行します。
# mv /var/lib/etcd /var/lib/etcd.old # mkdir /var/lib/etcd # chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd/
または、ディレクトリーおよび etcd、データを削除するには、以下のコマンドを実行します。
# rm -Rf /var/lib/etcd/*
注記オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.etcdディレクトリーに置かれます。
正常なバックアップデータファイルをそれぞれの etcd ノードに復元します。この手順を etcd と同じ場所に配置されているマスターホストを含むすべての etcd ホストで実行します。
# cp -R /backup/etcd-xxx/* /var/lib/etcd/ # mv /var/lib/etcd/db /var/lib/etcd/member/snap/db # chcon -R --reference /backup/etcd-xxx/* /var/lib/etcd/ # chown -R etcd:etcd /var/lib/etcd/R
各ホストで etcd サービスを実行し、新規クラスターを強制的に実行します。
これにより etcd サービスのカスタムファイルが作成されます。これにより、
--force-new-clusterオプションを追加して実行コマンドが上書きされます。# mkdir -p /etc/systemd/system/etcd.service.d/ # echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf # echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf # sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \ /usr/lib/systemd/system/etcd.service \ >> /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # master-restart etcdエラーメッセージの有無を確認します。
$ journalctl -fu etcd.service
健全性のステータスを確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy
クラスターモードで etcd サービスを再起動します。
# rm -f /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # master-restart etcd
健全性のステータスとメンバーの一覧を確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy # etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://localhost:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
- 最初のインスタンスの実行後に、etcd サーバーの残りの部分を復元できます。
5.4.2.1.1. peerURLS パラメーターの修正
データの復元および新規クラスターの作成後に、peerURLs パラメーターは、IP の代わりに etcd がピア通信をリッスンする localhost を示します。
# etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://*localhost*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
5.4.2.1.1.1. 手順
etcdctl member listを使用してメンバー ID を取得します。`etcdctl member list`
etcd がピア通信をリッスンする IP を取得します。
$ ss -l4n | grep 2380
メンバー情報をこの IP で更新します。
# etcdctl2 member update 5ee217d17301 https://192.168.55.8:2380 Updated member with ID 5ee217d17301 in cluster
検証するには、IP がメンバーの一覧にあることを確認します。
$ etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
5.4.2.2. etcd v3 スナップショットの復元
v3 データの復元手順は v2 データの復元プロセスと同様です。
スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save で作成される場合には、スナップショットに整合性ハッシュが含まれており、etcdctl snapshot restore でチェックされます。スナップショットがデータディレクトリーからコピーされる場合には、整合性ハッシュはなく、--skip-hash-check を使用しないと復元されません。
v3 データのみを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
古いデータすべてについては、
etcdctlが復元手順が実行されるノードで再作成を実行するためにこれをクリアします。# rm -Rf /var/lib/etcd
snapshot restoreコマンドを実行し、/etc/etcd/etcd.confファイルの値を置き換えます。# etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \ --data-dir /var/lib/etcd \ --name master-0.example.com \ --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \ --initial-cluster-token "etcd-cluster-1" \ --initial-advertise-peer-urls https://192.168.55.8:2380 \ --skip-hash-check=true 2017-10-03 08:55:32.440779 I | mvcc: restore compact to 1041269 2017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c
パーミッションおよび
selinuxコンテキストを復元されたファイルに復元します。# chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd
etcd サービスを起動します。
# systemctl start etcd
エラーメッセージの有無を確認します。
# master-logs etcd etcd
5.4.3. etcd ホストの置き換え
etcd ホストを置き換えるには、etcd クラスターを拡張してからホストを削除します。このプロセスでは、置き換え手順の実行時に etcd ホストが失われる場合に備えてクォーラム (定足数) を維持できるようにします。
etcd クラスターは置き換え操作時に クォーラム (定足数) を維持する必要があります。これは、常に 1 つ以上のホストが稼働している必要があることを意味します。
ホスト置き換え操作が etcd クラスターがクォーラム (定足数) を維持している状態で実行される場合、クラスター操作はこの影響を受けません。大規模な etcd データの複製が必要な場合には、一部の操作の速度が下がる可能性があります。
etcd クラスターに関係するいずれかの手順を起動する前に、etcd データと設定ファイルのバックアップを行い、手順が失敗する際にクラスターを復元できるようにします。
5.4.4. etcd のスケーリング
etcd クラスターは、リソースを etcd ホストに追加して垂直的に拡張することも、etcd ホストを追加して水平的に拡張することもできます。
etcd が使用する投票システムのために、クラスターには常に奇数のメンバーが含まれている必要があります。
奇数の etcd ホストを含むクラスターの場合、フォールトトレランスに対応できます。etcd ホストが奇数分あると、クォーラム (定足数) に必要な数は変わりませんが、障害発生時の耐性が高まります。たとえば、クラスターが 3 つのメンバーで構成される場合には、クォーラム (定足数) は 2 で、残り の 1 つが耐障害性用になります。これにより、クラスターはメンバーの 2 つが正常である限り、機能し続けます。
3 つの etcd ホストで構成される実稼働クラスターの使用が推奨されます。
新規ホストには、新規の Red Hat Enterprise Linux version 7 専用ホストが必要です。etcd ストレージは最大のパフォーマンスを達成できるように SSD ディスクおよび /var/lib/etcd でマウントされる専用ディスクに置かれる必要があります。
前提条件
- 新規 etcd ホストを追加する前に、「etcd 設定およびデータのバックアップ」を行ってデータの損失を防ぎます。
現在の etcd クラスターステータスを確認し、新規ホストを正常でないクラスターに追加することを防ぎます。
v2 etcd api を使用する場合、以下のコマンドを使用します。
# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379"\ 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 healthyv3 etcd api を使用する場合は、以下のコマンドを実行します。
# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379" endpoint health https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
scaleupPlaybook を実行する前に、新規ホストが適切な Red Hat ソフトウェアチャンネルに登録されていることを確認します。# subscription-manager register \ --username=*<username>* --password=*<password>* # subscription-manager attach --pool=*<poolid>* # subscription-manager repos --disable="*" # subscription-manager repos \ --enable=rhel-7-server-rpms \ --enable=rhel-7-server-extras-rpmsetcd は
rhel-7-server-extras-rpmsソフトウェアチャンネルでホストされています。現在の etcd ノードで etcd および iptables をアップグレードします。
# yum update etcd iptables-services
- etcd ホストの /etc/etcd 設定をバックアップします。
- 新規 etcd メンバーが OpenShift Container Platform ノードでもある場合は、「必要な数のホストをクラスターに追加」します。
- この手順の残りでは、1 つのホストを追加していることを前提としていますが、複数のホストを追加する場合は、各ホストですべての手順を実行します。
5.4.4.1. Ansible を使用した新規 etcd ホストの追加
手順
Ansible インベントリーファイルで、
[new_etcd]という名前の新規グループおよび新規ホストを作成します。次に、new_etcdグループを[OSEv3]グループの子として追加します。[OSEv3:children] masters nodes etcd new_etcd 1 ... [OUTPUT ABBREVIATED] ... [etcd] master-0.example.com master-1.example.com master-2.example.com [new_etcd] 2 etcd0.example.com 3
OpenShift Container Platform がインストールされており、Ansible インベントリーファイルをホストするホストから、etcd
scaleupPlaybook を実行します。$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/byo/openshift-etcd/scaleup.yml
Playbook が実行された後に、新規 etcd ホストを
[new_etcd]グループから[etcd]グループに移行し、現在のステータスを反映するようにインベントリーファイルを変更します。[OSEv3:children] masters nodes etcd new_etcd ... [OUTPUT ABBREVIATED] ... [etcd] master-0.example.com master-1.example.com master-2.example.com etcd0.example.com
Flannel を使用する場合には、OpenShift Container Platform のホストごとに、
/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,https://etcd0.example.com:2379
flanneldサービスを再起動します。# systemctl restart flanneld.service
5.4.4.2. 新規 etcd ホストの手動による追加
手順
現在の etcd クラスターの変更
etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。
環境変数を作成します。
export NEW_ETCD_HOSTNAME="*etcd0.example.com*" export NEW_ETCD_IP="192.168.55.21" export CN=$NEW_ETCD_HOSTNAME export SAN="IP:${NEW_ETCD_IP}" export PREFIX="/etc/etcd/generated_certs/etcd-$CN/" export OPENSSLCFG="/etc/etcd/ca/openssl.cnf"注記etcd_v3_ca_*として使用されるカスタムのopenssl拡張には、subjectAltNameとしての $SAN 環境変数が含まれます。詳細は、/etc/etcd/ca/openssl.cnfを参照してください。設定および証明書を保存するディレクトリーを作成します。
# mkdir -p ${PREFIX}サーバー証明書要求を作成し、これに署名します (server.csr および server.crt)。
# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}server.key \ -out ${PREFIX}server.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN # openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}server.crt \ -in ${PREFIX}server.csr \ -extensions etcd_v3_ca_server -batchピア証明書要求を作成し、これに署名します (peer.csr および peer.crt)。
# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}peer.key \ -out ${PREFIX}peer.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN # openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}peer.crt \ -in ${PREFIX}peer.csr \ -extensions etcd_v3_ca_peer -batch後で変更できるように、現在の etcd 設定および
ca.crtファイルをサンプルとして現在のノードからコピーします。# cp /etc/etcd/etcd.conf ${PREFIX} # cp /etc/etcd/ca.crt ${PREFIX}存続する etcd ホストから、新規ホストをクラスターに追加します。etcd メンバーをクラスターに追加するには、まず最初のメンバーの
peerURLs値のデフォルトの localhost ピアを調整する必要があります。member listコマンドを使用して最初のメンバーのメンバー ID を取得します。# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ 1 member list- 1
--peersパラメーター値でアクティブな etcd メンバーのみの URL を指定するようにしてください。
etcd がクラスターピアについてリッスンする IP アドレスを取得します。
$ ss -l4n | grep 2380
直前の手順で取得されたメンバー ID および IP アドレスを渡して、
etcdctl member updateコマンドを使用してpeerURLsの値を更新します。# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ member update 511b7fb6cc0001 https://172.18.1.18:2380-
member listコマンドを再実行し、ピア URL に localhost が含まれなくなるようにします。
新規ホストを etcd クラスターに追加します。新規ホストはまだ設定されていないため、新規ホストを設定するまでステータスが
unstartedのままであることに注意してください。警告各メンバーを追加し、1 回に 1 つずつメンバーをオンライン状態にします。各メンバーをクラスターに追加する際に、現在のピアの
peerURL一覧を調整する必要があります。peerURL一覧はメンバーが追加されるたびに拡張します。etcdctl member addコマンドは、以下に説明されているように、メンバーを追加する際に etcd.conf ファイルで設定する必要のある値を出力します。# etcdctl -C https://${CURRENT_ETCD_HOST}:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key member add ${NEW_ETCD_HOSTNAME} https://${NEW_ETCD_IP}:2380 1 Added member named 10.3.9.222 with ID 4e1db163a21d7651 to cluster ETCD_NAME="<NEW_ETCD_HOSTNAME>" ETCD_INITIAL_CLUSTER="<NEW_ETCD_HOSTNAME>=https://<NEW_HOST_IP>:2380,<CLUSTERMEMBER1_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER2_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER3_NAME>=https:/<CLUSTERMEMBER3_IP>:2380" ETCD_INITIAL_CLUSTER_STATE="existing"- 1
- この行で、
10.3.9.222は etcd メンバーのラベルです。ホスト名、IP アドレスまたは単純な名前を指定できます。
サンプル
${PREFIX}/etcd.confファイルを更新します。以下の値を直前の手順で生成された値に置き換えます。
- ETCD_NAME
- ETCD_INITIAL_CLUSTER
- ETCD_INITIAL_CLUSTER_STATE
以下の変数は、直前の手順で出力された新規ホストの IP に変更します。
${NEW_ETCD_IP}は、値として使用できます。ETCD_LISTEN_PEER_URLS ETCD_LISTEN_CLIENT_URLS ETCD_INITIAL_ADVERTISE_PEER_URLS ETCD_ADVERTISE_CLIENT_URLS
- メンバーシステムを etcd ノードとして使用していた場合には、/etc/etcd/etcd.conf ファイルの現在の値を上書きする必要があります。
ファイルで構文エラーや欠落している IP アドレスがないかを確認します。エラーや欠落がある場合には、etced サービスが失敗してしまう可能性があります。
# vi ${PREFIX}/etcd.conf
-
インストールファイルをホストするノードでは、/etc/ansible/hosts インベントリーファイルの
[etcd]ホストグループを更新します。古い etcd ホストを削除し、新規ホストを追加します。 証明書、サンプル設定ファイル、および
caを含むtgzファイルを作成し、これを新規ホストにコピーします。# tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} . # scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/
新規 etcd ホストを変更します。
iptables-servicesをインストールして etcd の必要なポートを開くために iptables ユーティリティーを指定します。# yum install -y iptables-services
etcd の通信を許可する
OS_FIREWALL_ALLOWファイアウォールルールを作成します。- クライアントのポート 2379/tcp
ピア通信のポート 2380/tcp
# systemctl enable iptables.service --now # iptables -N OS_FIREWALL_ALLOW # iptables -t filter -I INPUT -j OS_FIREWALL_ALLOW # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2379 -j ACCEPT # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2380 -j ACCEPT # iptables-save | tee /etc/sysconfig/iptables
注記この例では、新規チェーン
OS_FIREWALL_ALLOWが作成されます。これは、OpenShift Container Platform インストーラーがファイアウォールルールに使用する標準の名前になります。警告環境が IaaS 環境でホストされている場合には、インスタンスがこれらのポートに入ってくるトラフィックを許可できるように、セキュリティーグループを変更します。
etcd をインストールします。
# yum install -y etcd
バージョン
etcd-2.3.7-4.el7.x86_64以降がインストールされていることを確認します。etcd サービスが実行されていないことを確認します。
# systemctl disable etcd --now
etcd 設定およびデータを削除します。
# rm -Rf /etc/etcd/* # rm -Rf /var/lib/etcd/*
証明書および設定ファイルを展開します。
# tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
ファイル所有者のパーミッションを変更します。
# chown -R etcd/etcd /etc/etcd/* # chown -R etcd/etcd /var/lib/etcd/
新規ホストで etcd を起動します。
# systemctl enable etcd --now
ホストがクラスターの一部であることと現在のクラスターの健全性を確認します。
v2 etcd api を使用する場合は、以下のコマンドを実行します。
# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ 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 8b8904727bf526a5 is healthy: got healthy result from https://192.168.55.21:2379 member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379 cluster is healthyv3 etcd api を使用する場合は、以下のコマンドを実行します。
# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ endpoint health https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms https://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms
各 OpenShift Container Platform マスターの変更
すべてのマスターの
/etc/origin/master/master-config.yamlファイルのetcClientInfoセクションでマスター設定を変更します。新規 etcd ホストを、データを保存するために OpenShift Container Platform が使用する etcd サーバーの一覧に追加し、失敗したすべての etcd ホストを削除します。etcdClientInfo: ca: master.etcd-ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 - https://master-2.example.com:2379 - https://etcd0.example.com:2379マスター API サービスを再起動します。
全マスターのインストールに対しては、以下を実行します。
# systemctl restart atomic-openshift-master-api
または、単一マスタークラスターのインストールでは以下を実行してください。
#systemctl restart atomic-openshift-master
警告etcd ノードの数は奇数でなければなりません。そのため、2 つ以上のホストを追加する必要があります。
Flannel を使用する場合、新規 etcd ホストを組み込むために、すべての OpenShift Container Platform ホストの
/etc/sysconfig/flanneldにあるflanneldサービス設定を変更します。FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
flanneldサービスを再起動します。# systemctl restart flanneld.service
5.4.5. etcd ホストの削除
復元後に etcd ホストが失敗する場合は、クラスターから削除します。
すべてのマスターホストで実行する手順
手順
相互の etcd ホストを etcd クラスターから削除します。各 etcd ノードについて以下のコマンドを実行します。
# etcdctl -C https://<surviving host IP address>:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/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