専用 Kubernetes クラスターでは、デフォルトで etcd v3.3.8 が使用されます。このバージョンは最大 2 GB のストレージをサポートします。この制限に達すると、クラスターは etcd へのデータ書き込みができなくなります。本トピックでは、etcd を v3.3.8 から v3.4.3 へアップグレードする手順について説明します。これにより、ストレージ制限が 100 GB まで引き上げられます。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
etcd のバージョンが 3.4.3 より前のものであること
ストレージ要件が 2 GB を超えること（データ量が 2 GB 以内に収まる場合は、アップグレードは任意です）
etcd ストレージクォータの仕組み
etcd v3.4.3 では、バックエンドストレージの上限を 100 GB とするため、ETCD_QUOTA_BACKEND_BYTES=100000000000 が設定されます。また、ストレージの再利用性能を向上させるために、ETCD_EXPERIMENTAL_BACKEND_BBOLT_FREELIST_TYPE=map も設定されます。
etcd のバックエンドストアが設定されたクォータを超えると、クラスターは etcd へのデータ書き込みができなくなります。v3.4.3 へのアップグレードおよびより高いクォータの適用により、このような状況を防止できます。
etcd を v3.4.3 へアップグレード
ノードを 1 台ずつアップグレードします。etcd は高可用性であるため、ローリングアップグレード中もクラスターへのアクセスは継続可能です。
次のノードに進む前に、アップグレード済みのノードが Ready 状態になるまで待機してください。
ステップ 1：現在のバージョンの確認
各マスターノードに SSH 接続し、現在の etcd バージョンを確認します。
etcd --versionバージョンが 3.3.8 であることを確認してください。すでに 3.4.3 以降のバージョンがインストールされている場合は、アップグレードは不要です。
ステップ 2：v3.4.3 のバイナリのダウンロードとインストール
マスターノード上で、etcd v3.4.3 のバイナリをダウンロードし、既存のバイナリと置き換えます。
etcdbin=http://aliacs-k8s-cn-hangzhou.oss.aliyuncs.com/etcd/etcd-v3.4.3/etcd
etcdctlbin=http://aliacs-k8s-cn-hangzhou.oss.aliyuncs.com/etcd/etcd-v3.4.3/etcdctl
wget -O etcd ${etcdbin}
wget -O etcdctl ${etcdctlbin}
chmod +x {etcd,etcdctl}
mv etcd /usr/bin/etcd
mv etcdctl /usr/bin/etcdctl新しいバージョンを確認します。
etcd --versionステップ 3：etcd 構成の更新
etcd サービスファイルを更新して、100 GB のクォータおよびマップベースのフリーリストタイプを設定し、その後サービスを再起動します。
ETCD_FILE=/lib/systemd/system/etcd.service
# 重複を避けるため、既存のクォータおよびフリーリスト設定を削除
sed -i "/ETCD_EXPERIMENTAL_BACKEND_BBOLT_FREELIST_TYPE/ d" ${ETCD_FILE}
sed -i "/ETCD_QUOTA_BACKEND_BYTES/ d" ${ETCD_FILE}
# パフォーマンス向上のため、新しい 100 GB クォータおよびマップベースのフリーリストを設定
sed -i "/^\[Service\]/a\Environment=\"ETCD_EXPERIMENTAL_BACKEND_BBOLT_FREELIST_TYPE=map\"" ${ETCD_FILE}
sed -i "/^\[Service\]/a\Environment=\"ETCD_QUOTA_BACKEND_BYTES=100000000000\"" ${ETCD_FILE}
# 再参加するノードのクラスター状態を "new" から "existing" に更新
sed -i "s/initial-cluster-state new/initial-cluster-state existing/g" ${ETCD_FILE}
systemctl daemon-reload
systemctl restart etcdノードが停止・再起動中の間、残りのクラスターメンバーはそのピアに対して接続エラーをログ出力します。これは正常な挙動であり、ノードが再参加すると自動的に解消されます。
ステップ 4：ノードの再参加の確認
etcd の再起動後、ノードがクラスターメンバーリストに表示されることを確認します。
ENDPOINTS=`ps -eaf|grep etcd-servers|grep -v grep|awk -F "=" '{print $22}'|awk -F " " '{print $1}'`
ETCDCTL_API=3 etcdctl \
--endpoints=${ENDPOINTS} \
--cacert=/var/lib/etcd/cert/ca.pem \
--cert=/var/lib/etcd/cert/etcd-client.pem \
--key=/var/lib/etcd/cert/etcd-client-key.pem \
member list確認後、次のマスターノードでステップ 2～4 を繰り返します。
ステップ 5：etcd の実行状態の確認
すべてのノードのアップグレードが完了したら、各ノードで etcd プロセスが実行中であることを確認します。
ps aux | grep etcd次のステップ
マスターノードで以下のコマンドを実行し、アップグレード後のクラスターの健全性を確認します。
ENDPOINTS=`ps -eaf|grep etcd-servers|grep -v grep|awk -F "=" '{print $22}'|awk -F " " '{print $1}'`
ETCDCTL_API=3 etcdctl \
--endpoints=${ENDPOINTS} \
--cacert=/var/lib/etcd/cert/ca.pem \
--cert=/var/lib/etcd/cert/etcd-client.pem \
--key=/var/lib/etcd/cert/etcd-client-key.pem \
endpoint health期待される出力：
ENDPOINTS is healthy