etcd（Kubernetesのクラスタ状態を保存する分散キーバリューストア）のv3.7.0が2026年7月8日にリリースされた[1]。目玉は2つある。大容量のレンジクエリをチャンク単位で取得できるRangeStream（結果を分割ストリーミング送信する新しいgRPC方式）RPCの実装と、v2store（v3store移行後も互換性維持のため残っていた旧世代データストア関連コンポーネント）の完全撤廃だ[1][2]。この2点はKubernetesクラスタ運用者にとって無関係ではない。RangeStreamはKubernetes 1.37のEtcdRangeStreamフィーチャーゲート（ベータ、デフォルト有効）と対になり、kube-apiserverの起動時メモリ使用量やwatch cache初期化時間に直結する[2]。一方でv2store撤廃と実験的フラグの全廃は、古い設定を引きずったままアップグレードするクラスタを直撃する破壊的変更だ[1]。単なるマイナー更新ではなく、次のKubernetesアップグレード計画の前提条件が変わったと捉えるべき変更である。本稿ではv3.7の変更点を整理し、運用者が今から確認すべき事項を示す。
予備知識
- etcd：Kubernetesのクラスタ状態（Pod・Node・Secret等のすべてのオブジェクト）を保存する分散キーバリューストア。kube-apiserverの唯一の永続化先。
- v2store：etcd v2時代のデータストア形式。v3store移行後も互換性維持のためdiscovery機能やクライアントライブラリの一部として残っていた。
- RangeStream RPC：範囲取得（Range）の結果をチャンク単位でストリーミング返却する新しいgRPC方式。従来の一括返却方式（unary Range）と対比される。
- feature gate（フィーチャーゲート）：Kubernetesの機能を段階的に有効化する仕組み。alpha→beta→GAの順で既定値が変わる。
etcdが内部で使うMVCCストレージエンジンやコンセンサスの仕組みを理解する土台になる
v2store完全撤廃で何が消えたか
v2storeとは、etcd v2時代に使われていたデータストア形式を指す。v3.0以降はv3store（MVCC対応の新ストレージエンジン）が標準になったが、discovery機能やクライアントライブラリの一部はv2store由来のコードとして残存していた。
v3.7.0-rc.0では、この残存コンポーネントが一括で削除された。具体的にはv2discovery（v2形式のクラスタ発見機構）、client/v2（v2 REST APIクライアントライブラリ）、v2 requestおよびapply_v2.go（v2形式のリクエスト処理）、v2スナップショットファイルの読み込み機能が対象だ[1]。あわせて、非推奨だった実験的コマンドラインフラグ（--experimental-*）もすべて削除された[1]。
| 項目 | v3.6以前 | v3.7以降 |
|---|---|---|
| v2discovery | 残存（非推奨） | 削除 |
| client/v2 | 残存（非推奨） | 削除 |
| v2 request / apply_v2.go | 残存 | 削除 |
| v2スナップショット読み込み | 対応 | 非対応（v3storeのみからブートストラップ） |
--experimental-*フラグ | 一部稼働 | 全廃（feature gateまたは安定フラグへ移行必須） |
最も注意すべきは、v2 APIやv2スナップショットに依存する古いツール・スクリプトを残しているクラスタだ。v3.6.11以前からのアップグレードでは、こうした依存が可視化されないまま動作していた可能性がある[1]。
Raftベースの合意形成やレプリケーションなど、etcdの設計原理を支えるパターンを解説
RangeStream RPCの仕組みとKubernetes 1.37での位置づけ
RangeStreamとは、範囲取得（Range）クエリの結果をサーバーストリーミングRPCとしてチャンク単位で返す新しいAPIだ。従来のRange RPCは該当するキーバリュー全体（KVスライス・シリアライズ後のprotobuf・gRPC送信バッファ）が送信前にメモリ上へ同時展開される必要があり、大規模クラスタではetcdサーバー側のメモリスパイクの原因になっていた[2]。
RangeStreamは単一のMVCC版数（リビジョン）に結果を固定したうえで、RangeStreamResponseというラッパーメッセージでチャンクごとに順次送信する。観測された値サイズに応じてチャンクサイズを適応的に調整し、総件数もストリームされたキーから導出するため、ページネーションのたびにB-treeインデックス全体を再走査する無駄も解消される[2]。固定したリビジョンがストリーム中にコンパクションされる場合はErrCompactedエラーを返し、クライアント側で再試行する[2]。
Kubernetes側では、EtcdRangeStreamフィーチャーゲート（v1.37でベータ・既定有効）がkube-apiserverに実装され、watch cacheの初期化をRangeStream RPC 1本で行えるようになる[2]。etcd 3.7未満のクラスタでは自動的に従来のRange RPCへフォールバックするため、etcdだけ先に上げてもK8s側は動作する[2]。逆に言えば、K8s 1.37の性能改善を活かすにはetcd 3.7以降が前提になる。
コンテナランタイム（コンテナを実際に起動・管理するソフトウェア）レイヤーで、見落としがちな断絶系アップグレードが進行している。Kubernetes 1.36（2026年4月22日リリース）はcgroup v1（Linuxのリソース制[…]
アップグレード計画の勘所
etcd 3.7へのアップグレードは、クラスタを構成するメンバーを1台ずつ順番に上げるローリング方式が推奨される。アップグレード中は異なるバージョンのetcdメンバーが混在してもクラスタとして動作し、プロトコルは最も低いバージョンに合わせて動く[3]。
具体的には、アップグレード前にクラスタが健全であることをetcdctl endpoint healthで確認し、スナップショットバックアップを取得したうえで1台ずつバイナリを入れ替えて起動し、そのつどヘルスチェックを挟みながら残りのメンバーへ進める[3]。3.7では特に、--experimental-*系フラグを使い続けている設定がある場合、対応するfeature gateまたは安定版フラグへ事前に移行しておく必要がある。移行しないまま上げると起動に失敗する[1][3]。
アップグレード前の要否判断は、v2 API依存の有無と--experimental-*フラグの使用有無で切り分けられる。
マネージドKubernetesではetcdのバージョンをクラウド事業者側が管理することが多いが、オンプレや自前HA構成のコントロールプレーンなど自前でetcdクラスタを運用している場合は、この手順をそのまま社内の変更管理プロセスに組み込む必要がある。
Kubernetes（K8s、コンテナオーケストレーション基盤）上でAI・ML基盤を組んでいるプラットフォームエンジニアに向けた話をする。舞台はストレージ層、それも学習（モデルを訓練する処理）と推論（学習済みモデルで予測を返す処理）それぞ[…]
まとめ
etcd v3.7.0は、RangeStream RPCによる性能改善と、v2store・実験的フラグの完全撤廃という2つの異なる性質の変更を同時に含むリリースだ。前者はKubernetes 1.37との組み合わせで恩恵を受けられる将来投資、後者は放置すると起動失敗につながる即応課題である。読者がまず着手すべきは、自社クラスタで--experimental-*フラグやv2 APIクライアントが使われていないかの棚卸しと、アップグレード計画へのローリング手順の組み込みだ。K8s 1.37への移行時期を待たずとも、etcd単体のアップグレード計画は今から立てておく価値がある。
よくある質問（FAQ）
Q1. etcd 3.6のまま運用していても問題ありませんか。
3.6系は当面サポートが続きますが、3.7で導入された性能改善やRangeStreamの恩恵は受けられません。次のK8sアップグレードサイクルに向けて計画を立てることを推奨します。
Q2. RangeStreamを使うにはetcd側の設定変更が必要ですか。
etcd 3.7以降であればRangeStream RPC自体は利用可能です。Kubernetes側でEtcdRangeStreamフィーチャーゲートが有効なK8s 1.37以降のkube-apiserverと組み合わせることで自動的に利用されます。
Q3. v2 APIに依存したツールを使っているかどうかはどう確認しますか。
etcdctlや監視・バックアップツールの設定に--experimental-*系フラグやv2エンドポイントへの直接アクセスが残っていないか、設定ファイルとスクリプトを棚卸しすることが出発点になります。
⚠️ 結論：Sora 2（OpenAI）は提供終了しました Web版・アプリ版：2026年4月26日に提供終了（OpenAI公式ヘルプの案内）。 API：2026年9月24日に終了予定。 これ[…]
