第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 ディレクトリー全体のバックアップを作成します。

手順

重要

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

マスターホストの設定ファイルのバックアップを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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/
```
```
$ 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 に保存されます。複数マスター環境では、設定ファイルは /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/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/`	システムに追加される証明書 (例: 外部レジストリー用)

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

Copy to Clipboard Toggle word wrap

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/

$ 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 パッケージの一覧を作成するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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 mkdir -p ${MYBACKUPDIR}
$ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
```

直前の手順を実行している場合、以下のファイルがバックアップディレクトリーに置かれます。

Copy to Clipboard Toggle word wrap

MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'

$ 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

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

Copy to Clipboard Toggle word wrap

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

$ 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 ではサポートされていませんが、リファレンスアーキテクチャーチームはコードが定義通りに動作し、安全であることを確認するテストを実施しています。

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

Copy to Clipboard Toggle word wrap

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

$ 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 設定をバックアップします。

Copy to Clipboard Toggle word wrap

ssh master-0
mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/

$ 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 サービスを停止します。

Copy to Clipboard Toggle word wrap

systemctl stop etcd.service

# systemctl stop etcd.service

etcd データバックアップを作成し、etcd db ファイルをコピーします。

Copy to Clipboard Toggle word wrap

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)

# 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 を使用する場合、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
mkdir -p /backup/etcd-$(date +%Y%m%d)
etcdctl3 snapshot save */backup/etcd-$(date +%Y%m%d)*/db
systemctl stop etcd.service
etcdctl2 backup \
    --data-dir /var/lib/etcd \
    --backup-dir /backup/etcd-$(date +%Y%m%d)
systemctl start etcd.service
```
```
# 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 という名前のマスターの使用を終了する場合、ホスト名が以下から削除されていることを確認します。

Copy to Clipboard Toggle word wrap

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

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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
sudo systemctl restart haproxy
```
```
$ sudo systemctl restart haproxy
```

マスターがロードバランサーから削除された後に、API およびコントローラーサービスを無効にします。

Copy to Clipboard Toggle word wrap

sudo systemctl disable --now atomic-openshift-master-api
sudo systemctl disable --now atomic-openshift-master-controllers

$ sudo systemctl disable --now atomic-openshift-master-api
$ sudo systemctl disable --now atomic-openshift-master-controllers

マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、「ノードホストの使用終了」のセクションの手順に従ってください。
マスターホストを /etc/ansible/hosts Ansible インベントリーファイルの [masters] および [nodes] グループから削除し、このインベントリーファイルを使用して Ansible タスクを実行する場合の問題を回避できます。
警告
Ansible インベントリーファイルに一覧表示される最初のマスターホストの使用を終了するには、とくに注意が必要になります。
/etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。
kubernetes サービスにはマスターホスト IP がエンドポイントとして含まれています。マスターの使用が適切に終了していることを確認するには、kubernetes サービスの出力を確認して、使用が終了したマスターが削除されているかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
oc describe svc kubernetes -n default
```
```
$ 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 ノードについて以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap

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>

# 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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart atomic-openshift-master-api
```
```
# systemctl restart atomic-openshift-master-api
```
または、単一マスタークラスターインストールを使用している場合は、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
＃systemctl restart atomic-openshift-master
```
```
＃systemctl restart atomic-openshift-master
```

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

手順

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

Copy to Clipboard Toggle word wrap

etcdctl2 cluster-health
etcdctl2 member remove 8372784203e11288
etcdctl2 cluster-health

# 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


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 変数の値から失敗したホストを削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
vi /etc/etcd/etcd.conf
```
```
# vi /etc/etcd/etcd.conf
```
例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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,master-2.example.com=https://192.168.55.13:2380
```
以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12: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 の再実行時の問題を防げるように変更します。

Copy to Clipboard Toggle word wrap

[OSEv3:children]
masters
nodes
etcd

... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com

[OSEv3:children]
masters
nodes
etcd

... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com

Flannel を使用している場合、すべてのホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更し、etcd ホストを削除します。

Copy to Clipboard Toggle word wrap

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379

flanneld サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart flanneld.service
```
```
# systemctl restart flanneld.service
```

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

OpenShift Container Platform ファイル

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

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

手順

重要

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

マスターホストの設定ファイルのバックアップを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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/
```
```
$ 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 に保存されます。複数マスター環境では、設定ファイルは /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/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/`	システムに追加される証明書 (例: 外部レジストリー用)

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

Copy to Clipboard Toggle word wrap

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/

$ 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 パッケージの一覧を作成するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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 mkdir -p ${MYBACKUPDIR}
$ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
```

直前の手順を実行している場合、以下のファイルがバックアップディレクトリーに置かれます。

Copy to Clipboard Toggle word wrap

MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'

$ 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

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

Copy to Clipboard Toggle word wrap

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

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

注記

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

Copy to Clipboard Toggle word wrap

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

$ 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 ファイルを復元します。

Copy to Clipboard Toggle word wrap

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
systemctl restart atomic-openshift-master-api
systemctl restart atomic-openshift-master-controllers

# 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
# systemctl restart atomic-openshift-master-api
# systemctl restart atomic-openshift-master-controllers

警告

マスターサービスの再起動によりダウンタイムが生じる場合があります。ただし、マスターホストを可用性の高いロードバランサープールから削除し、復元操作を実行することができます。サービスが適切に復元された後に、マスターホストをロードバランサープールに再び追加することができます。

注記

影響を受けるインスタンスの完全な再起動を実行し、iptables 設定を復元します。

パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。
1. 現在インストールされているパッケージの一覧を取得します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
rpm -qa | sort > /tmp/current_packages.txt
```
```
$ rpm -qa | sort > /tmp/current_packages.txt
```
2. パッケージの一覧の間に存在する差分を表示します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt
ansible-2.4.0.0-5.el7.noarch
```
```
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt

> ansible-2.4.0.0-5.el7.noarch
```
3. 足りないパッケージを再インストールします。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
yum reinstall -y <packages>
```
```
# yum reinstall -y <packages> 
```
  1
  1
  <packages> をパッケージの一覧の間で異なるパッケージに置き換えます。
システム証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーして復元し、update-ca-trust を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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
```
```
$ 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 つ以上のノードがインフラストラクチャーノードの削除後もオンライン状態である場合にのみ推奨されます。

手順

利用可能なすべてのノードを一覧表示し、使用を終了するノードを検索します。

Copy to Clipboard Toggle word wrap

oc get nodes

$ 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 インフラストラクチャーノードの使用を終了します。

ノードとその実行中のサービスを記述します。

Copy to Clipboard Toggle word wrap

oc describe node 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 をすべて退避します。

Copy to Clipboard Toggle word wrap

oc adm drain ocp-infra-node-b7pl --delete-local-data

$ 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-registry Pod のローカルストレージは空になります。

注記

上記の操作はノードで実行されている既存の Pod を削除します。次に、新規 Pod がレプリケーションコントローラーに応じて作成されます。

通常、すべてのアプリケーションは、レプリケーションコントローラーを使用して Pod を作成するデプロイメント設定でデプロイされる必要があります。

oc adm drain はベア Pod (Pod をミラーリングしない、または ReplicationController、ReplicaSet、DaemonSet、StatefulSet、またはジョブで管理されない Pod) を削除しません。この実行には --force オプションが必要です。ベア Pod は他のノードでは再作成されず、この操作中にデータが失われる可能性があることに注意してください。

以下の例は、レジストリーのレプリケーションコントローラーの出力を示しています。

Copy to Clipboard Toggle word wrap

oc describe rc/docker-registry-1

$ 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 の一覧表示では、以下のようになります。

Copy to Clipboard Toggle word wrap

oc get pods

$ 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-vzlzq Pod は使用が終了したノードになり、利用できなくなります。代わりに 2 つの新規 Pod docker-registry-1-dprp5 および router-1-2gshr が作成されています。上記のように、新規のルーター Pod は router-1-2gshr ですが Pending 状態になります。これは、すべてのノードが単一ルーターでのみ実行でき、ホストのポート 80 および 443 にバインドされるためです。
新たに作成されたレジストリー Pod で確認できますが、以下の例では Pod が使用が終了したノードとは異なる ocp-infra-node-rghb ノードで作成されていることを示しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
oc describe pod docker-registry-1-dprp5
```
```
$ 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
...
```
インフラストラクチャーノードとアプリケーションノードの使用を終了する場合の唯一の相違点として、インフラストラクチャーノードの場合、該当するインフラストラクチャーノードの退避後に、そのノードを置き換える計画がない場合はインフラストラクチャーノードで実行されるサービスを縮小できる点があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
oc scale dc/router --replicas 2
oc scale dc/docker-registry --replicas 2
```
```
$ oc scale dc/router --replicas 2
deploymentconfig "router" scaled

$ oc scale dc/docker-registry --replicas 2
deploymentconfig "docker-registry" scaled
```

ここで、すべてのインフラストラクチャーノードはそれぞれの Pod を 1 種類のみ実行しています。

Copy to Clipboard Toggle word wrap

oc get pods
oc describe po/docker-registry-1-kr8jq | grep Node:
oc describe po/docker-registry-1-ncpl2 | grep Node:

$ 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 つ以上のインフラストラクチャーノードが常に利用可能である必要がります。

ノードのスケジューリングが無効にされていることを確認するには、以下を実行します。

Copy to Clipboard Toggle word wrap

oc get nodes

$ 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 が含まれていないことを確認するには、以下を実行します。

Copy to Clipboard Toggle word wrap

oc describe node 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:		(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 セクションから削除します。

Copy to Clipboard Toggle word wrap

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

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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
sudo systemctl restart haproxy
```
```
$ sudo systemctl restart haproxy
```

このコマンドを使って、すべての Pod がエビクトされた後にノードをクラスターから削除します。

Copy to Clipboard Toggle word wrap

oc delete node ocp-infra-node-b7pl

$ oc delete node ocp-infra-node-b7pl
node "ocp-infra-node-b7pl" deleted

Copy to Clipboard Toggle word wrap

oc get nodes

$ 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 ファイル

ノードインスタンスはコンテナーをベースとする Pod の形式で実行されます。/etc/origin/ および /etc/origin/node ディレクトリーは以下のような重要なファイルを格納します。

ノードサービスの設定
インストールで生成される証明書
クラウドプロバイダー関連の設定
キーおよびその他の認証ファイル (dnsmasq 設定など)

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

手順

ノード設定ファイルのバックアップを作成します。

Copy to Clipboard Toggle word wrap

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/

$ 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/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/`	システムに追加される証明書 (例: 外部レジストリー用)

これらのファイルを作成するには、以下を実行します。

Copy to Clipboard Toggle word wrap

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/

$ 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 パッケージの一覧を作成するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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 mkdir -p ${MYBACKUPDIR}
$ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
```

以下のファイルがバックアップディレクトリーに置かれます。

Copy to Clipboard Toggle word wrap

MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'

$ 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

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

Copy to Clipboard Toggle word wrap

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

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

注記

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

Copy to Clipboard Toggle word wrap

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

$ 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 ファイルを復元します。

Copy to Clipboard Toggle word wrap

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

# 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 を再起動できない場合は、パッケージを再インストールします。
1. 現在インストールされているパッケージの一覧を取得します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
rpm -qa | sort > /tmp/current_packages.txt
```
```
$ rpm -qa | sort > /tmp/current_packages.txt
```
2. パッケージの一覧の間に存在する差分を表示します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt
ansible-2.4.0.0-5.el7.noarch
```
```
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt

> ansible-2.4.0.0-5.el7.noarch
```
3. 足りないパッケージを再インストールします。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
yum reinstall -y <packages>
```
```
# yum reinstall -y <packages> 
```
  1
  1
  <packages> をパッケージの一覧の間で異なるパッケージに置き換えます。
システム証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーして復元し、update-ca-trust を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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
```
```
$ 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 を使用できます。

Copy to Clipboard Toggle word wrap

etcdctl -v
ETCDCTL_API=3 etcdctl version

$ 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 のバックアップには現在のストレージボリュームへのすべての参照が含まれることに注意してください。etcd の復元時に、OpenShift Container Platform はノードでの以前の Pod の起動と同じストレージの再割り当てを開始します。このプロセスは、ノードをクラスターから削除し、新規ノードを代わりに追加するプロセスと変わりがありません。そのノードに割り当てられているすべてのものは、Pod のスケジュール先のノードに関係なく Pod に再び割り当てられます。

5.4.1.1. etcd のバックアップ

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

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

手順

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

Copy to Clipboard Toggle word wrap

ssh master-0
mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/

$ 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 データのバックアップ

前提条件

注記

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

etcdctl バイナリーが利用可能であるか、またはコンテナー化インストールでは rhel7/etcd コンテナーが利用可能である。
etcd クラスターとの接続を確認する (ポート 2379/tcp)。
etcd クラスターに接続するための適切な証明書があることを確認する。

手順

注記

etcd データをバックアップします。* v2 API を使用する場合、以下のアクションを実行します。すべての etcd サービスを停止します。

Copy to Clipboard Toggle word wrap

systemctl stop etcd.service

# systemctl stop etcd.service

etcd データバックアップを作成し、etcd db ファイルをコピーします。

Copy to Clipboard Toggle word wrap

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)

# 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 を使用する場合、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
mkdir -p /backup/etcd-$(date +%Y%m%d)
etcdctl3 snapshot save */backup/etcd-$(date +%Y%m%d)*/db
systemctl stop etcd.service
etcdctl2 backup \
    --data-dir /var/lib/etcd \
    --backup-dir /backup/etcd-$(date +%Y%m%d)
systemctl start etcd.service
```
```
# 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 ファイルが失われる場合は、以下を使用してこれを復元します。

Copy to Clipboard Toggle word wrap

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

$ 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 サービスを停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl stop etcd.service
```
```
# systemctl stop etcd.service
```
適切なバックアップが復元されていることを確認するには、etcd ディレクトリーを削除します。
- ディレクトリーを削除する前に現在の etcd データをバックアップするには、以下のコマンドを実行します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
mv /var/lib/etcd /var/lib/etcd.old
mkdir /var/lib/etcd
chown -R etcd.etcd /var/lib/etcd/
restorecon -Rv /var/lib/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、データを削除するには、以下のコマンドを実行します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
rm -Rf /var/lib/etcd/*
```
```
# rm -Rf /var/lib/etcd/*
```
  注記
  オールインワンクラスターの場合、etcd データディレクトリーは /var/lib/origin/openshift.local.etcd ディレクトリーに置かれます。

正常なバックアップデータファイルをそれぞれの etcd ノードに復元します。この手順を etcd と同じ場所に配置されているマスターホストを含むすべての etcd ホストで実行します。

Copy to Clipboard Toggle word wrap

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

# 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 オプションを追加して実行コマンドが上書きされます。

Copy to Clipboard Toggle word wrap

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
systemctl restart etcd

# 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
# systemctl restart etcd

エラーメッセージの有無を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
journalctl -fu etcd.service
```
```
$ journalctl -fu etcd.service
```

健全性のステータスを確認します。

Copy to Clipboard Toggle word wrap

etcdctl2 cluster-health

# etcdctl2 cluster-health
member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379
cluster is healthy

クラスターモードで etcd サービスを再起動します。

Copy to Clipboard Toggle word wrap

rm -f /etc/systemd/system/etcd.service.d/temp.conf
systemctl daemon-reload
systemctl restart etcd

# rm -f /etc/systemd/system/etcd.service.d/temp.conf
# systemctl daemon-reload
# systemctl restart etcd

健全性のステータスとメンバーの一覧を確認します。

Copy to Clipboard Toggle word wrap

etcdctl2 cluster-health
etcdctl2 member list

# 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 を示します。

Copy to Clipboard Toggle word wrap

etcdctl2 member list

# 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 を取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
`etcdctl member list`
```
```
`etcdctl member list`
```
etcd がピア通信をリッスンする IP を取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ss -l4n | grep 2380
```
```
$ ss -l4n | grep 2380
```

メンバー情報をこの IP で更新します。

Copy to Clipboard Toggle word wrap

etcdctl2 member update 5ee217d17301 https://192.168.55.8:2380

# etcdctl2 member update 5ee217d17301 https://192.168.55.8:2380
Updated member with ID 5ee217d17301 in cluster

検証するには、IP がメンバーの一覧にあることを確認します。

Copy to Clipboard Toggle word wrap

etcdctl2 member list

$ 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. v3 の etcd の復元

v3 データの復元手順は v2 データの復元プロセスと同様です。

スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save を使用して取得される場合、これには etcdctl snapshot restore でチェックされる整合性ハッシュが含まれます。スナップショットがデータディレクトリーからコピーされる場合、整合性ハッシュはなく、これは --skip-hash-check を使用して復元されます。

重要

v3 データのみを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。

手順

すべての etcd サービスを停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl stop etcd.service
```
```
# systemctl stop etcd.service
```
古いデータすべてについては、etcdctl が復元手順が実行されるノードで再作成を実行するためにこれをクリアします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
rm -Rf /var/lib/etcd
```
```
# rm -Rf /var/lib/etcd
```

snapshot restore コマンドを実行し、/etc/etcd/etcd.conf ファイルの値を置き換えます。

Copy to Clipboard Toggle word wrap

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

# 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

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 コンテキストを復元されたファイルに復元します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
chown -R etcd.etcd /var/lib/etcd/
restorecon -Rv /var/lib/etcd
```
```
# chown -R etcd.etcd /var/lib/etcd/
# restorecon -Rv /var/lib/etcd
```
etcd サービスを起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl start etcd
```
```
# systemctl start etcd
```
エラーメッセージの有無を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
journalctl -fu etcd.service
```
```
$ journalctl -fu etcd.service
```

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 を使用する場合、以下のコマンドを使用します。

Copy to Clipboard Toggle word wrap

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

# 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 healthy

v3 etcd api を使用する場合は、以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap

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"

# 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

scaleup Playbook を実行する前に、新規ホストが適切な Red Hat ソフトウェアチャンネルに登録されていることを確認します。

Copy to Clipboard Toggle word wrap

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-rpms

# 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-rpms

etcd は rhel-7-server-extras-rpms ソフトウェアチャンネルでホストされています。

現在の etcd ノードで etcd および iptables をアップグレードします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
yum update etcd iptables-services
```
```
# 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] グループの子として追加します。

Copy to Clipboard Toggle word wrap

[OSEv3:children]
masters
nodes
etcd
new_etcd 

... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com
master-2.example.com

[new_etcd] 
etcd0.example.com

[OSEv3:children]
masters
nodes
etcd
new_etcd



... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com
master-2.example.com

[new_etcd]


etcd0.example.com

1 2 3: これらの行を追加します。

OpenShift Container Platform をインストールし、Ansible インベントリーファイルをホストするホストから、etcd scaleup Playbook を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ansible-playbook  /usr/share/ansible/openshift-ansible/playbooks/byo/openshift-etcd/scaleup.yml
```
```
$ ansible-playbook  /usr/share/ansible/openshift-ansible/playbooks/byo/openshift-etcd/scaleup.yml
```

Playbook が実行された後に、新規 etcd ホストを [new_etcd] グループから [etcd] グループに移行し、現在のステータスを反映するようにインベントリーファイルを変更します。

Copy to Clipboard Toggle word wrap

[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

[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 を使用する場合、新規 etcd ホストを組み込むように、すべての OpenShift Container Platform ホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更します。

Copy to Clipboard Toggle word wrap

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

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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart flanneld.service
```
```
# systemctl restart flanneld.service
```

5.4.4.2. 新規 etcd ホストの手動による追加

手順

現在の etcd クラスターの変更

etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。

環境変数を作成します。

Copy to Clipboard Toggle word wrap

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"

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 を参照してください。

設定および証明書を保存するディレクトリーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
mkdir -p ${PREFIX}
```
```
# mkdir -p ${PREFIX}
```

サーバー証明書要求を作成し、これに署名します (server.csr および server.crt)。

Copy to Clipboard Toggle word wrap

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

# 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)。

Copy to Clipboard Toggle word wrap

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

# 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 ファイルをサンプルとして現在のノードからコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
cp /etc/etcd/etcd.conf ${PREFIX}
cp /etc/etcd/ca.crt ${PREFIX}
```
```
# cp /etc/etcd/etcd.conf ${PREFIX}
# cp /etc/etcd/ca.crt ${PREFIX}
```
存続する etcd ホストから、新規ホストをクラスターに追加します。etcd メンバーをクラスターに追加するには、まず最初のメンバーの peerURLs 値のデフォルトの localhost ピアを調整する必要があります。
1. member list コマンドを使用して最初のメンバーのメンバー ID を取得します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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 list
```
```
# 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 を指定するようにしてください。
2. etcd がクラスターピアについてリッスンする IP アドレスを取得します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ss -l4n | grep 2380
```
```
$ ss -l4n | grep 2380
```
3. 直前の手順で取得されたメンバー ID および IP アドレスを渡して、etcdctl member update コマンドを使用してpeerURLs の値を更新します。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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
```
```
# 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
```
4. member list コマンドを再実行し、ピア URL に localhost が含まれなくなるようにします。
新規ホストを etcd クラスターに追加します。新規ホストはまだ設定されていないため、新規ホストを設定するまでステータスが unstarted のままであることに注意してください。
警告
各メンバーを追加し、1 回に 1 つずつメンバーをオンライン状態にします。各メンバーをクラスターに追加する際に、現在のピアの peerURL 一覧を調整する必要があります。peerURL 一覧はメンバーが追加されるたびに拡張します。etcdctl member add コマンドは、以下に説明されているように、メンバーを追加する際に etcd.conf ファイルで設定する必要のある値を出力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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
```
```
# 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 ファイルを更新します。
1. 以下の値を直前の手順で生成された値に置き換えます。
  - ETCD_NAME
  - ETCD_INITIAL_CLUSTER
  - ETCD_INITIAL_CLUSTER_STATE
2. 以下の変数を直前の手順の出力の新規ホスト IP で変更します。${NEW_ETCD_IP} を値として使用できます。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ETCD_LISTEN_PEER_URLS
ETCD_LISTEN_CLIENT_URLS
ETCD_INITIAL_ADVERTISE_PEER_URLS
ETCD_ADVERTISE_CLIENT_URLS
```
```
ETCD_LISTEN_PEER_URLS
ETCD_LISTEN_CLIENT_URLS
ETCD_INITIAL_ADVERTISE_PEER_URLS
ETCD_ADVERTISE_CLIENT_URLS
```
3. メンバーシステムを etcd ノードとして使用していた場合には、/etc/etcd/etcd.conf ファイルの現在の値を上書きする必要があります。
4. ファイルで構文エラーや欠落している IP アドレスがあるかどうかを確認します。そうしない場合、etced サービスが必敗する可能性があります。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
vi ${PREFIX}/etcd.conf
```
```
# vi ${PREFIX}/etcd.conf
```
インストールファイルをホストするノードでは、/etc/ansible/hosts インベントリーファイルの [etcd] ホストグループを更新します。古い etcd ホストを削除し、新規ホストを追加します。

証明書、サンプル設定ファイル、および ca を含む tgz ファイルを作成し、これを新規ホストにコピーします。

Copy to Clipboard Toggle word wrap

tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} .
scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/

# tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} .
# scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/

新規 etcd ホストを変更します。

iptables-services をインストールして etcd の必要なポートを開くために iptables ユーティリティーを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
yum install -y iptables-services
```
```
# yum install -y iptables-services
```

etcd の通信を許可する OS_FIREWALL_ALLOW ファイアウォールルールを作成します。

クライアントのポート 2379/tcp

ピア通信のポート 2380/tcp

Copy to Clipboard Toggle word wrap

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

# 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 をインストールします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
yum install -y etcd
```
```
# yum install -y etcd
```
バージョン etcd-2.3.7-4.el7.x86_64 以降がインストールされていることを確認します。
etcd サービスが実行されていないことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl disable etcd --now
```
```
# systemctl disable etcd --now
```
etcd 設定およびデータを削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
rm -Rf /etc/etcd/*
rm -Rf /var/lib/etcd/*
```
```
# rm -Rf /etc/etcd/*
# rm -Rf /var/lib/etcd/*
```
証明書および設定ファイルを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
```
```
# tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
```

ファイル所有者のパーミッションを変更します。

Copy to Clipboard Toggle word wrap

chown -R etcd/etcd /etc/etcd/*
chown -R etcd/etcd /var/lib/etcd/

# chown -R etcd/etcd /etc/etcd/*
# chown -R etcd/etcd /var/lib/etcd/

新規ホストで etcd を起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl enable etcd --now
```
```
# systemctl enable etcd --now
```

ホストがクラスターの一部であることと現在のクラスターの健全性を確認します。

v2 etcd api を使用する場合は、以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap

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

# 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 healthy

v3 etcd api を使用する場合は、以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap

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

# 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 ホストを削除します。

Copy to Clipboard Toggle word wrap

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

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 サービスを再起動します。
- すべてのマスター:
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart atomic-openshift-master-api
```
```
# systemctl restart atomic-openshift-master-api
```
- または、単一マスタークラスターのインストールでは以下を実行してください。
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
＃systemctl restart atomic-openshift-master
```
```
＃systemctl restart atomic-openshift-master
```
  警告
  etcd ノードの数は奇数でなければなりません。そのため、2 つ以上のホストを追加する必要があります。

Flannel を使用する場合、新規 etcd ホストを組み込むために、すべての OpenShift Container Platform ホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更します。

Copy to Clipboard Toggle word wrap

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

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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart flanneld.service
```
```
# systemctl restart flanneld.service
```

5.4.5. etcd ホストの削除

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

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

手順

相互の etcd ホストを etcd クラスターから削除します。各 etcd ノードについて以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap

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>

# 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 サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart atomic-openshift-master-api
```
```
# systemctl restart atomic-openshift-master-api
```
または、単一マスタークラスターインストールを使用している場合は、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
＃systemctl restart atomic-openshift-master
```
```
＃systemctl restart atomic-openshift-master
```

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

手順

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

Copy to Clipboard Toggle word wrap

etcdctl2 cluster-health
etcdctl2 member remove 8372784203e11288
etcdctl2 cluster-health

# 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


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 変数の値から失敗したホストを削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
vi /etc/etcd/etcd.conf
```
```
# vi /etc/etcd/etcd.conf
```
例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
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,master-2.example.com=https://192.168.55.13:2380
```
以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12: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 の再実行時の問題を防げるように変更します。

Copy to Clipboard Toggle word wrap

[OSEv3:children]
masters
nodes
etcd

... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com

[OSEv3:children]
masters
nodes
etcd

... [OUTPUT ABBREVIATED] ...

[etcd]
master-0.example.com
master-1.example.com

Flannel を使用している場合、すべてのホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更し、etcd ホストを削除します。

Copy to Clipboard Toggle word wrap

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379

flanneld サービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
```
systemctl restart flanneld.service
```
```
# systemctl restart flanneld.service
```

トップに戻る

第5章 ホストレベルのタスク

5.1. ホストのクラスターへの追加

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

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

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

手順

5.2.1.2. etcd のバックアップ

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

手順

5.2.1.2.2. etcd データのバックアップ

前提条件

手順

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

手順

5.2.1.4. etcd ホストの削除

手順

手順

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

手順

5.2.3. マスターホストのバックアップの復元

手順

5.3. ノードホストのタスク

5.3.1. ノードホストの使用の終了

前提条件

手順

5.3.1.1. ノードホストの置き換え

5.3.2. ノードホストのバックアップの作成

手順

5.3.3. ノードホストバックアップの復元

手順

5.3.4. ノードの保守と次の手順

5.4. etcd タスク

5.4.1. etcd のバックアップ

5.4.1.1. etcd のバックアップ

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

手順

5.4.1.1.2. etcd データのバックアップ

前提条件

手順

5.4.2. etcd の復元

5.4.2.1. etcd v2 および v3 データの復元

手順

5.4.2.1.1. peerURLS パラメーターの修正

5.4.2.1.1.1. 手順

5.4.2.2. v3 の etcd の復元

手順

5.4.3. etcd ホストの置き換え

5.4.4. etcd のスケーリング

前提条件

5.4.4.1. Ansible を使用した新規 etcd ホストの追加

手順

5.4.4.2. 新規 etcd ホストの手動による追加

手順

現在の etcd クラスターの変更

新規 etcd ホストを変更します。

各 OpenShift Container Platform マスターの変更

5.4.5. etcd ホストの削除

手順

手順

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第5章ホストレベルのタスク

5.4.2.1.1. `peerURLS` パラメーターの修正