開発者ガイド

• 1: 検出サービスのプロトコル
• 2: ローカルクラスターの構築
• 3: etcdの操作
• 4: gRPCゲートウェイを使う理由
• 5: gRPCの名前解決と検出
• 6: Goアプリケーションへのetcdの組み込み
• 7: システムの制限
• 8: etcdの機能
• 9: APIリファレンス
• 10: APIリファレンス：並行処理

1 - 検出サービスのプロトコル

検出サービスのプロトコルは、共有の検出URLを使い、クラスターの初期構築時に新しいetcdメンバーが他のすべてのメンバーを検出するためのものです。

検出サービスのプロトコルは、クラスターの初期構築時にのみ使用します。実行時の再構成やクラスターの監視には使用できません。

このプロトコルは、新しい検出トークンを使って、一意のetcdクラスターを1つ初期構築します。1つの検出トークンが表せるetcdクラスターは1つだけです。そのトークンで検出プロトコルを開始した後は、途中で失敗した場合でも、別のetcdクラスターの初期構築に再利用してはいけません。

以降では、自前でホストする検出クラスターの例を使って、検出の流れを説明します。公開検出サービスのdiscovery.etcd.ioも同じ仕組みで動作しますが、複雑なURLを隠し、UUIDを自動生成し、過剰なリクエストをある程度防ぐための層が追加されています。公開検出サービスも、内部ではこのドキュメントで説明するようにetcdクラスターをデータストアとして使用しています。

プロトコルの処理の流れ

検出プロトコルは、内部のetcdクラスターを使って、新しいクラスターの初期構築を調整します。まず、すべての新しいメンバーが検出サービスとやり取りして、予定されたメンバーの一覧を作成します。次に、各新規メンバーはこの一覧を使ってサーバーを初期構築します。これは-initial-clusterフラグと同じ役割を果たします。

以下の処理例では、理解しやすいように、プロトコルの各手順をcurl形式で示します。

慣例として、etcdの検出プロトコルはキーの接頭辞_etcd/registryを使用します。http://example.comで検出サービス用のetcdクラスターをホストしている場合、検出キー空間の完全なURLはhttp://example.com/v2/keys/_etcd/registryです。この例では、これをURLの接頭辞として使用します。

新しい検出トークンの作成

新しいクラスターを識別する一意のトークンを生成します。以降の手順では、検出キー空間内の一意の接頭辞として使用します。uuidgenを使うと簡単に生成できます。

UUID=$(uuidgen)

予定するクラスターサイズの指定

検出トークンには、予定するクラスターサイズを指定する必要があります。検出サービスはこのサイズを使い、クラスターを初期構成するすべてのメンバーが見つかったかどうかを判断します。

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size -d value=${cluster_size}

クラスターサイズは通常、3、5、7のいずれかです。詳細は最適なクラスターサイズ を参照してください。

etcdプロセスの起動

検出URLを-discoveryフラグに指定して、etcdプロセスを起動します。-discoveryフラグが指定された各etcdプロセスは、内部で以下の手順を実行します。

自身の登録

etcdプロセスは最初に、検出URLに自身をメンバーとして登録します。検出URL内にメンバーIDをキーとして作成することで登録します。

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/${member_id}?prevExist=false -d value="${member_name}=${member_peer_url_1}&${member_name}=${member_peer_url_2}"

状態の確認

検出URLから予定されたクラスターサイズと登録状態を確認し、次の動作を決めます。

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size
curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}

登録済みのメンバーがまだ足りなければ、残りのメンバーが現れるのを待ちます。

登録済みのメンバー数が予定サイズNを超える場合、最初に登録されたN個のメンバーを、そのクラスターのメンバー一覧として扱います。自分自身が一覧に含まれていれば検出は成功し、その一覧からすべてのピアを取得します。一覧に含まれていなければ、クラスターが満員であるというエラーで検出処理を終了します。

etcdの実装では、自身を登録する前にメンバーがクラスターの状態を確認することもあります。そのため、クラスターがすでに満員の場合、速やかに失敗できます。

すべてのメンバーを待機

待機処理の詳細は、etcd APIドキュメント を参照してください。

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}?wait=true&waitIndex=${current_etcd_index}

すべてのメンバーが見つかるまで待機を続けます。

公開検出サービス

CoreOS Inc.は、https://discovery.etcd.io/ で公開検出サービスをホストしています。このサービスは、使いやすさのためにいくつかの便利な機能を提供します。

キーの接頭辞の隠蔽

公開検出サービスは、https://discovery.etcd.io/${UUID}を、背後のetcdクラスターの/v2/keys/_etcd/registryにあるキーへリダイレクトします。登録キーの接頭辞を隠すことで、短く読みやすい検出URLを提供します。

新しいトークンの取得

GET /new

Sent query:
	size=${cluster_size}
Possible status codes:
	200 OK
	400 Bad Request
200 Body:
	generated discovery url

サービス内の生成処理は、新しい検出トークンの作成 から予定するクラスターサイズの指定 までの手順に従います。

検出状態の確認

GET /${UUID}

UUIDの値を要求することで、登録済みのマシンを含む、その検出トークンの状態を確認できます。

オープンソースリポジトリ

リポジトリは https://github.com/coreos/discovery.etcd.io にあります。独自の検出サービスを構築するために使用できます。

2 - ローカルクラスターの構築

テストや開発用にデプロイする場合、最も手早く簡単なのはローカルクラスターの構成です。本番環境へのデプロイについては、クラスター構成 のセクションを参照してください。

ローカルの単独クラスター

クラスターの起動

etcdを単独クラスターとしてデプロイするには、次を実行します。

$ ./etcd
...

現在の作業ディレクトリにetcdバイナリーがない場合、$GOPATH/bin/etcdまたは/usr/local/bin/etcdにある可能性があります。その場所に合わせてコマンドを実行してください。

起動したetcdメンバーは、localhost:2379でクライアントリクエストを待ち受けます。

クラスターの操作

etcdctlで実行中のクラスターを操作します。

1. 例としてキー・バリューペアをクラスターに保存します。

     $ ./etcdctl put foo bar
     OK

   OKと表示されれば、キー・バリューペアの保存は成功です。

2. fooの値を取得します。

   $ ./etcdctl get foo
   bar

   barが返れば、etcdクラスターとのやり取りは正常に動作しています。

ローカルの複数メンバークラスター

クラスターの起動

etcdのGitリポジトリのルートには、ローカルで複数メンバーのクラスターを簡単に構成するためのProcfileがあります。複数メンバーのクラスターを起動するには、etcdのソースツリーのルートに移動して、次の操作を行います。

1. Procfileに基づくアプリケーションを制御するため、goremanをインストールします。

   $ go install github.com/mattn/goreman@latest

2. etcdに付属するProcfileを使い、goremanでクラスターを起動します。

   $ goreman -f Procfile start

   メンバーが起動し、それぞれlocalhost:2379、localhost:22379、localhost:32379でクライアントリクエストを待ち受けます。

クラスターの操作

etcdctlで実行中のクラスターを操作します。

1. メンバーの一覧を表示します。

   $ etcdctl --write-out=table --endpoints=localhost:2379 member list

   etcdメンバーの一覧が次のように表示されます。

   +------------------+---------+--------+------------------------+------------------------+
   |        ID        | STATUS  |  NAME  |       PEER ADDRS       |      CLIENT ADDRS      |
   +------------------+---------+--------+------------------------+------------------------+
   | 8211f1d0f64f3269 | started | infra1 | http://127.0.0.1:2380  | http://127.0.0.1:2379  |
   | 91bc3c398fb3c146 | started | infra2 | http://127.0.0.1:22380 | http://127.0.0.1:22379 |
   | fd422379fda50e48 | started | infra3 | http://127.0.0.1:32380 | http://127.0.0.1:32379 |
   +------------------+---------+--------+------------------------+------------------------+

2. 例としてキー・バリューペアをクラスターに保存します。

   $ etcdctl put foo bar
   OK

   OKと表示されれば、キー・バリューペアの保存は成功です。

耐障害性のテスト

etcdの耐障害性を試すため、メンバーを停止してからキーを取得します。

1. 停止するメンバーのプロセス名を確認します。

   Procfileには、複数メンバーのクラスターのプロパティが記載されています。ここでは、プロセス名がetcd2のメンバーを例にします。

2. メンバーを停止します。

   # kill etcd2
   $ goreman run stop etcd2

3. キーを保存します。

   $ etcdctl put key hello
   OK

4. 前の手順で保存したキーを取得します。

   $ etcdctl get key
   hello

5. 停止したメンバーからキーを取得します。

   $ etcdctl --endpoints=localhost:22379 get key

   このコマンドでは、接続失敗によるエラーが表示されるはずです。

   2017/06/18 23:07:35 grpc: Conn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:22379: getsockopt: connection refused"; Reconnecting to "localhost:22379"
   Error:  grpc: timed out trying to connect

6. 停止したメンバーを再起動します。

   $ goreman run restart etcd2

7. 再起動したメンバーからキーを取得します。

   $ etcdctl --endpoints=localhost:22379 get key
   hello

   メンバーを再起動すると接続が再確立され、etcdctlでキーを正常に取得できるようになります。etcdの操作について詳しくは、etcdの操作 のセクションを参照してください。

3 - etcdの操作

ユーザーは主に、キーの値を書き込んだり取得したりしてetcdを操作します。このセクションでは、etcdサーバーを操作するコマンドラインツールetcdctlを使う方法を説明します。ここで説明する概念は、gRPC APIやクライアントライブラリーのAPIにも当てはまるはずです。

etcdctl v3.7はv3 APIを使用します。v2 APIとETCDCTL_APIによるバージョン選択は削除されています。

バージョンの確認

etcdctlのバージョンとサーバーAPIのバージョンを確認すると、etcdの各種操作に適したコマンドを見つけるのに役立ちます。

バージョンを確認するコマンドは、次のとおりです。

$ etcdctl version
etcdctl version: 3.1.0-alpha.0+git
API version: 3.1

キーへの書き込み

アプリケーションはキーに書き込むことで、etcdクラスターにキーを保存します。保存された各キーは、一貫性と信頼性を確保するため、Raftプロトコルによってetcdクラスターのすべてのメンバーに複製されます。

キーfooの値をbarに設定するコマンドは、次のとおりです。

$ etcdctl put foo bar
OK

リースを関連付けると、キーを指定した時間だけ有効にすることもできます。

キーfoo1の値を10sの間bar1に設定するコマンドは、次のとおりです。

$ etcdctl put foo1 bar1 --lease=1234abcd
OK

キーの読み取り

アプリケーションは、etcdクラスターからキーの値を読み取れます。クエリーは、単一のキーまたはキーの範囲を読み取ることができます。

etcdクラスターに、次のキーが保存されているとします。

foo = bar
foo1 = bar1
foo2 = bar2
foo3 = bar3

キーfooの値を読み取るコマンドは、次のとおりです。

$ etcdctl get foo
foo
bar

キーfooの値を16進数形式で読み取るコマンドは、次のとおりです。

$ etcdctl get foo --hex
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

キーfooの値だけを読み取るコマンドは、次のとおりです。

$ etcdctl get foo --print-value-only
bar

fooからfoo3までの範囲のキーを取得するコマンドは、次のとおりです。

$ etcdctl get foo foo3
foo
bar
foo1
bar1
foo2
bar2

fooを接頭辞に持つすべてのキーを取得するコマンドは、次のとおりです。

$ etcdctl get --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

fooを接頭辞に持つすべてのキーを対象とし、結果を2件までに制限するコマンドは、次のとおりです。

$ etcdctl get --prefix --limit=2 foo
foo
bar
foo1
bar1

RangeStream RPCを使って、fooを接頭辞に持つすべてのキーを取得するコマンドは、次のとおりです。結果は単項のRangeと同じです。

$ etcdctl get --stream --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

--streamは、--order、--sort-by、リビジョンフィルターをサポートしません。

キーの過去のバージョンの読み取り

アプリケーションは、更新によって古くなったキーのバージョンを読み取りたい場合があります。たとえば、キーの以前のバージョンにアクセスして、古い構成に戻したい場合です。また、キーの履歴にアクセスすることで、複数のリクエストを通じて複数のキーを一貫した状態で読み取りたい場合もあります。 etcdクラスターのキー・バリューストアを変更するたびに、クラスター全体のリビジョンが増加するため、古いetcdリビジョンを指定すれば、過去のキーを読み取れます。

etcdクラスターに、次のキーがすでに存在するとします。

foo = bar         # revision = 2
foo1 = bar1       # revision = 3
foo = bar_new     # revision = 4
foo1 = bar1_new   # revision = 5

キーの過去のバージョンにアクセスする例は、次のとおりです。

$ etcdctl get --prefix foo # access the most recent versions of keys
foo
bar_new
foo1
bar1_new

$ etcdctl get --prefix --rev=4 foo # access the versions of keys at revision 4
foo
bar_new
foo1
bar1

$ etcdctl get --prefix --rev=3 foo # access the versions of keys at revision 3
foo
bar
foo1
bar1

$ etcdctl get --prefix --rev=2 foo # access the versions of keys at revision 2
foo
bar

$ etcdctl get --prefix --rev=1 foo # access the versions of keys at revision 1

指定したキーのバイト値以上のキーの読み取り

アプリケーションは、指定したキーのバイト値以上のキーを読み取りたい場合があります。

etcdクラスターに、次のキーがすでに存在するとします。

a = 123
b = 456
z = 789

キーbのバイト値以上のキーを読み取るコマンドは、次のとおりです。

$ etcdctl get --from-key b
b
456
z
789

キーの削除

アプリケーションは、etcdクラスターから単一のキーまたはキーの範囲を削除できます。

etcdクラスターに、次のキーがすでに存在するとします。

foo = bar
foo1 = bar1
foo3 = bar3
zoo = val
zoo1 = val1
zoo2 = val2
a = 123
b = 456
z = 789

キーfooを削除するコマンドは、次のとおりです。

$ etcdctl del foo
1 # one key is deleted

fooからfoo9までの範囲のキーを削除するコマンドは、次のとおりです。

$ etcdctl del foo foo9
2 # two keys are deleted

キーzooを削除し、削除したキー・バリューペアを返すコマンドは、次のとおりです。

$ etcdctl del --prev-kv zoo
1   # one key is deleted
zoo # deleted key
val # the value of the deleted key

zooを接頭辞に持つキーを削除するコマンドは、次のとおりです。

$ etcdctl del --prefix zoo
2 # two keys are deleted

キーbのバイト値以上のキーを削除するコマンドは、次のとおりです。

$ etcdctl del --from-key b
2 # two keys are deleted

キーの変更の監視

アプリケーションは、単一のキーまたはキーの範囲を監視して、更新を検知できます。

キーfooを監視するコマンドは、次のとおりです。

$ etcdctl watch foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar

キーfooを16進数形式で監視するコマンドは、次のとおりです。

$ etcdctl watch foo --hex
# in another terminal: etcdctl put foo bar
PUT
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

fooからfoo9までの範囲のキーを監視するコマンドは、次のとおりです。

$ etcdctl watch foo foo9
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put foo1 bar1
PUT
foo1
bar1

fooを接頭辞に持つキーを監視するコマンドは、次のとおりです。

$ etcdctl watch --prefix foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put fooz1 barz1
PUT
fooz1
barz1

複数のキーfooとzooを監視するコマンドは、次のとおりです。

$ etcdctl watch -i
$ watch foo
$ watch zoo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put zoo val
PUT
zoo
val

キーの過去の変更の監視

アプリケーションは、etcd内のキーの過去の変更を監視したい場合があります。たとえば、あるキーのすべての変更を受け取りたい場合、etcdへの接続を維持していればwatchで十分です。しかし、アプリケーションやetcdに障害が起きると、その間に変更が発生しても、アプリケーションは更新をリアルタイムで受信できません。更新の配信を保証するには、アプリケーションがキーの過去の変更を監視できる必要があります。そのためには、キーの過去のバージョンを読み取るときと同様に、監視に過去のリビジョンを指定します。

次の一連の操作を終えたとします。

$ etcdctl put foo bar         # revision = 2
OK
$ etcdctl put foo1 bar1       # revision = 3
OK
$ etcdctl put foo bar_new     # revision = 4
OK
$ etcdctl put foo1 bar1_new   # revision = 5
OK

過去の変更を監視する例は、次のとおりです。

# watch for changes on key `foo` since revision 2
$ etcdctl watch --rev=2 foo
PUT
foo
bar
PUT
foo
bar_new

# watch for changes on key `foo` since revision 3
$ etcdctl watch --rev=3 foo
PUT
foo
bar_new

過去の最後の変更からだけ監視する例は、次のとおりです。

# watch for changes on key `foo` and return last revision value along with modified value
$ etcdctl watch --prev-kv foo
# in another terminal: etcdctl put foo bar_latest
PUT
foo         # key
bar_new     # last value of foo key before modification
foo         # key
bar_latest  # value of foo key after modification

監視の進捗

アプリケーションは、監視ストリームがどの程度最新の状態に追いついているかを判断するために、監視の進捗を確認したい場合があります。たとえば、監視でキャッシュを更新する場合、クォーラム読み取りで得たリビジョンと比べてキャッシュが古いかどうかを把握すると役立ちます。

対話型の監視セッションで"progress"コマンドを使用すると、進捗リクエストを発行し、監視ストリームで進捗通知を送るようetcdサーバーに要求できます。

$ etcdctl watch -i
$ watch a
$ progress
progress notify: 1
# in another terminal: etcdctl put x 0
# in another terminal: etcdctl put y 1
$ progress
progress notify: 3

コンパクション済みリビジョン

すでに説明したとおり、etcdはリビジョンを保持し、アプリケーションがキーの過去のバージョンを読み取れるようにします。ただし、履歴が無制限に蓄積するのを防ぐには、過去のリビジョンのコンパクションが重要です。コンパクション後、etcdは過去のリビジョンを削除し、今後の使用のためにリソースを解放します。コンパクションしたリビジョンより前の、更新によって古くなったデータはすべて利用できなくなります。

リビジョンをコンパクションするコマンドは、次のとおりです。

$ etcdctl compact 5
compacted revision 5

# any revisions before the compacted one are not accessible
$ etcdctl get --rev=4 foo
Error:  rpc error: code = 11 desc = etcdserver: mvcc: required revision has been compacted

$ etcdctl get mykey -w=json
{"header":{"cluster_id":14841639068965178418,"member_id":10276657743932975437,"revision":15,"raft_term":4}}

リースの付与

アプリケーションは、etcdクラスターからキー用のリースを取得できます。キーをリースに関連付けると、その有効期間はリースの有効期間に結び付けられます。リースの有効期間は生存時間（TTL）によって決まります。各リースには、アプリケーションが付与時に指定する最小TTLがあります。実際のTTLは最小TTL以上で、etcdクラスターが選択します。リースのTTLが経過すると、リースは期限切れになり、関連付けられたすべてのキーが削除されます。

リースを付与するコマンドは、次のとおりです。

# grant a lease with 60 second TTL
$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

# attach key foo to lease 32695410dcc0ca06
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

リースの取り消し

アプリケーションは、リースIDを指定してリースを取り消します。リースを取り消すと、関連付けられたすべてのキーが削除されます。

次の一連の操作を終えたとします。

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

このリースを取り消すコマンドは、次のとおりです。

$ etcdctl lease revoke 32695410dcc0ca06
lease 32695410dcc0ca06 revoked

$ etcdctl get foo
# empty response since foo is deleted due to lease revocation

リースの維持

アプリケーションは、TTLを更新することでリースの期限切れを防ぎ、維持できます。

次の一連の操作を終えたとします。

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

このリースを維持するコマンドは、次のとおりです。

$ etcdctl lease keep-alive 32695410dcc0ca06
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
...

リース情報の取得

アプリケーションは、リースを更新するため、またはリースがまだ存在するか、期限切れになったかを確認するために、リース情報を取得したい場合があります。また、特定のリースに関連付けられているキーを確認したい場合もあります。

次の一連の操作を終えたとします。

# grant a lease with 500 second TTL
$ etcdctl lease grant 500
lease 694d5765fc71500b granted with TTL(500s)

# attach key zoo1 to lease 694d5765fc71500b
$ etcdctl put zoo1 val1 --lease=694d5765fc71500b
OK

# attach key zoo2 to lease 694d5765fc71500b
$ etcdctl put zoo2 val2 --lease=694d5765fc71500b
OK

リース情報を取得するコマンドは、次のとおりです。

$ etcdctl lease timetolive 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(258s)

リースに関連付けられたキーとともにリース情報を取得するコマンドは、次のとおりです。

$ etcdctl lease timetolive --keys 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(132s), attached keys([zoo2 zoo1])

# if the lease has expired or does not exist it will give the below response:
Error:  etcdserver: requested lease not found

4 - gRPCゲートウェイを使う理由

etcd v3は、メッセージングプロトコルにgRPC を使用します。etcdプロジェクトは、gRPCでetcdクラスターと通信するための、gRPCベースのGoクライアント とコマンドラインユーティリティーetcdctl を提供しています。gRPCをサポートしない言語向けには、JSONのgRPCゲートウェイ を提供しています。このゲートウェイはRESTfulなプロキシとして動作し、HTTP/JSONリクエストをgRPCメッセージに変換します。

gRPCゲートウェイの使用

ゲートウェイは、etcdのProtocol Buffers メッセージ定義のJSONマッピング を受け付けます。keyとvalueフィールドはバイト配列として定義されているため、JSONではbase64でエンコードする必要があります。以下の例ではcurlを使いますが、どのHTTP/JSONクライアントでも同様に動作するはずです。

注意事項

gRPCゲートウェイのエンドポイントは、etcd v3.3以降で変更されています。

• etcd v3.2以前は、[CLIENT-URL]/v3alpha/*だけを使用します。
• etcd v3.3は、[CLIENT-URL]/v3alpha/*を維持しつつ、[CLIENT-URL]/v3beta/*を使用します。
• etcd v3.4は、[CLIENT-URL]/v3beta/*を維持しつつ、[CLIENT-URL]/v3/*を使用します。
  • [CLIENT-URL]/v3alpha/*は非推奨です。
• etcd v3.5以降は、[CLIENT-URL]/v3/*だけを使用します。
  • [CLIENT-URL]/v3beta/*は非推奨です。

gRPC-gatewayは、TLSのCommon Nameを使った認証をサポートしていません。

キーの書き込みと取得

/v3/kv/rangeと/v3/kv/putサービスで、キーを読み書きします。

<<COMMENT
https://www.base64encode.org/
foo is 'Zm9v' in Base64
bar is 'YmFy'
COMMENT

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"}}

curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

# get all keys prefixed with "foo"
curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v", "range_end": "Zm9w"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

キーの監視

/v3/watchサービスで、キーを監視します。

curl -N http://localhost:2379/v3/watch \
  -X POST -d '{"create_request": {"key":"Zm9v"} }' &
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"1","raft_term":"2"},"created":true}}

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}' >/dev/null 2>&1
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"2"},"events":[{"kv":{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}}]}}

トランザクション

/v3/kv/txnで、トランザクションを発行します。

# target CREATE
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"target":"CREATE","key":"Zm9v","createRevision":"2"}],"success":[{"requestPut":{"key":"Zm9v","value":"YmFy"}}]}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"3","raft_term":"2"},"succeeded":true,"responses":[{"response_put":{"header":{"revision":"3"}}}]}

# target VERSION
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"version":"4","result":"EQUAL","target":"VERSION","key":"Zm9v"}],"success":[{"requestRange":{"key":"Zm9v"}}]}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"6","raft_term":"3"},"succeeded":true,"responses":[{"response_range":{"header":{"revision":"6"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"6","version":"4","value":"YmF6"}],"count":"1"}}]}

認証

/v3/authサービスで、認証を設定します。

# create root user
curl -L http://localhost:2379/v3/auth/user/add \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# create root role
curl -L http://localhost:2379/v3/auth/role/add \
  -X POST -d '{"name": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# grant root role
curl -L http://localhost:2379/v3/auth/user/grant \
  -X POST -d '{"user": "root", "role": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# enable auth
curl -L http://localhost:2379/v3/auth/enable -X POST -d '{}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

/v3/auth/authenticateでetcdの認証を行い、認証トークンを取得します。

# get the auth token for the root user
curl -L http://localhost:2379/v3/auth/authenticate \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"},"token":"sssvIpwfnLAcWAQH.9"}

認証情報を使ってキーを取得するには、Authorizationヘッダーに認証トークンを設定します。

curl -L http://localhost:2379/v3/kv/put \
  -H 'Authorization: sssvIpwfnLAcWAQH.9' \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"2","raft_term":"2"}}

エラーレスポンス

gRPCゲートウェイは、gRPCのステータスをHTTPステータスコードとJSONのエラー本文に変換します。 etcd v3.6以降は、grpc-gateway v2へのアップグレードによってエラー処理が変わりました （v2移行ガイドのエラー処理に関する注意事項 を参照）。 現在のゲートウェイの動作は、GoogleのAPIエラーモデル で説明されている google.rpc.Status（code、message、details）に沿っています。 以前のgrpc-gatewayにはトップレベルのerrorフィールドも含まれていましたが、 etcd v3.6以降では、このフィールドはサポートされていません。

クライアントは、HTTPステータスコードを成功・失敗の主な判断材料として扱ってください。 リクエストが失敗した場合は、messageフィールドをエラー情報の主な情報源とし、 追加の詳細情報から、さらに詳しい状況を読み取ることを推奨します。

Swagger

生成されたSwagger API定義は、rpc.swagger.json にあります。

5 - gRPCの名前解決と検出

etcdは、etcdからエンドポイントを取得してgRPCサービスを検出する代替の名前システムを、gRPCリゾルバーで提供します。その仕組みは、サービス名を接頭辞に持つキーの更新の監視に基づいています。

この機能は、grpc-goでまだ実験的なgoogle.golang.org/grpc/resolver パッケージに依存しているため、実験的機能です。

go-grpcでetcdの検出機能を使う

etcdクライアントは、etcdをバックエンドとしてgRPCエンドポイントを解決するgRPCリゾルバーを提供します。リゾルバーはetcdクライアントで初期化します。

import (
	clientv3 "go.etcd.io/etcd/client/v3"
	etcdnaming "go.etcd.io/etcd/client/v3/naming/resolver"

	"google.golang.org/grpc"
)

...

cli, err := clientv3.NewFromURL("http://localhost:2379")
if err != nil {
    // ...
}
r, err := etcdnaming.NewBuilder(cli)
if err != nil {
    // ...
}
conn, gerr := grpc.NewClient("my-service", grpc.WithResolvers(r), ...)

サービスエンドポイントの管理

etcdリゾルバーは、解決対象に"/“を付けた接頭辞（例：“foo/bar/my-service/"）の下にあるすべてのキーのうち、 JSONでエンコードされた値（従来はgo-grpcのnaming.Update）を持つものを、サービスエンドポイントの候補として扱います。 新しいキーを作成するとエンドポイントがサービスに追加され、キーを削除するとサービスから削除されます。

エンドポイントの追加

etcdctlで新しいエンドポイントをサービスに追加できます。

ETCDCTL_API=3 etcdctl put foo/bar/my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'

etcdクライアントのendpoints.Managerメソッドでも、Addrに対応するキーを使って新しいエンドポイントを登録できます。

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(),"foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

複数のエンドポイントを持つサービスへの接続時にラウンドロビン負荷分散を有効にするには、grpc内蔵の ラウンドロビンロードバランサーを使用するように接続を設定します。

conn, gerr := grpc.NewClient("etcd:///foo", grpc.WithResolvers(etcdResolver),
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`))

エンドポイントの削除

etcdctlでホストをサービスから削除できます。

ETCDCTL_API=3 etcdctl del foo/bar/my-service/1.2.3.4

etcdクライアントのendpoints.Managerメソッドでも、エンドポイントを削除できます。

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.DeleteEndpoint(context.TODO(), "foo/bar/my-service/e1")

リース付きのエンドポイント登録

リース付きでエンドポイントを登録すると、ホストがキープアライブのハートビートを維持できなくなった場合（マシンの故障など）に、そのホストがサービスから確実に削除されます。

lease=`ETCDCTL_API=3 etcdctl lease grant 5 | cut -f2 -d' '`
ETCDCTL_API=3 etcdctl put --lease=$lease my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'
ETCDCTL_API=3 etcdctl lease keep-alive $lease

Goでは、次のように記述します。

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(), "foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

エンドポイントのアトミックな更新

1つのトランザクションで複数のエンドポイントを変更するには、endpoints.Managerを直接使用できます。

em := endpoints.NewManager(c, "foo")

err := em.Update(context.TODO(), []*endpoints.UpdateWithOpts{
    endpoints.NewDeleteUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.4"}),
	endpoints.NewAddUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.14"})})

6 - Goアプリケーションへのetcdの組み込み

etcdのGoパッケージembedを使用すると、etcdサーバーをアプリケーションに直接、簡単に組み込めます。

詳細はembedパッケージのドキュメント を参照してください。

7 - システムの制限

リクエストサイズの上限

etcdは、メタデータで一般的な小さなキー・バリューペアを処理するように設計されています。大きなリクエストも処理できますが、他のリクエストのレイテンシーが増加する可能性があります。デフォルトでは、各リクエストの最大サイズは1.5 MiBです。この上限は、etcdサーバーの--max-request-bytesフラグで設定できます。

ストレージサイズの上限

ストレージサイズのデフォルトの上限は2 GiBで、--quota-backend-bytesフラグで設定できます。通常の環境で推奨される最大サイズは8 GiBです。設定値がこのサイズを超えると、etcdは起動時に警告を出します。

8 - etcdの機能

このドキュメントでは、etcdの機能と、それに関連する非推奨化の手続きを理解できるよう、機能の概要を説明します。etcdで機能を開発する方法については、開発ガイドライン を参照してください。

etcdの機能には、「実験的」「安定」「安全でない」の3つの段階があります。etcd --helpを実行すると、機能の一覧を確認できます。

実験的

早期にフィードバックを得るため、新機能は通常、実験的機能として追加されます。実験的機能はフラグ名で識別でき、その名前には--experimentalという接頭辞が付くはずです。実験的機能を使うときは、次の点を考慮してください。

• ユーザーによるテストが不足しているため、バグが残っている可能性があります。有効にしても、期待どおりに動作しない場合があります。
• デフォルトでは無効です。
• 予告なく、いつでもサポートが打ち切られる可能性があります。
  • 安定した機能に昇格しない限り、機能の非推奨化 ポリシーに従わず、次のマイナーリリースまたはメジャーリリースで削除されることがあります。
  • プロジェクトチームは、実験的機能に関する問題の報告を歓迎します。ただし、安定した機能の問題より優先順位が低くなる場合があります。
• 実験的機能が安定した段階に昇格すると、その機能フラグは非推奨になります 。できるだけ早く、安定した機能のフラグに切り替えてください。

安定

etcdの機能で最も一般的な段階です。安定した機能には、次の特徴があります。

• サポート対象のetcdリリースの一部としてサポートされます。
• デフォルトで有効になっている場合があります。
• サポートを終了する際は、機能の非推奨化 ポリシーに従う必要があります。

安全でない

安全でない機能は少数で、etcdの使用法ドキュメントのUnsafe feature:セクションに記載されています。デフォルトでは無効です。ドキュメントに従い、慎重に使用してください。安全でない機能は、機能の非推奨化ポリシーに従わず、次のマイナーリリースまたはメジャーリリースで削除されることがあります。

機能の非推奨化

実験的

実験的機能は、安定した段階に昇格すると非推奨になります。

• 実験的機能のドキュメントには、関連する安定した機能のフラグを使うよう推奨する非推奨メッセージが表示されます。例：DEPRECATED. Use <feature-name> instead.
• 非推奨になった機能は、次のリリースで削除されます。

安定

プロジェクトの発展に伴い、安定した機能を非推奨にして削除する必要が生じることがあります。その場合は、次のように対応します。

• 非推奨化を予定しているリリースの前に、機能のドキュメントに警告メッセージを表示します。例：To be deprecated in <release>.。To be deprecatedとされた機能を置き換える新機能がすでに計画されている場合は、その旨もドキュメントに記載します。例：Use <feature-name> instead.。
• 予定されたリリースで機能を非推奨にします。この時点で、機能のドキュメントには、関連する安定した機能を使うよう推奨する非推奨メッセージが表示されます。例：DEPRECATED. Use <feature-name> instead.
• 非推奨になった機能は、次のリリースで削除されます。

9 - APIリファレンス

このAPIリファレンスは、各見出しに記載した.protoファイルから自動生成されています。

サービス Auth (api/etcdserverpb/rpc.proto)

サービス Cluster (api/etcdserverpb/rpc.proto)

サービス KV (api/etcdserverpb/rpc.proto)

サービス Lease (api/etcdserverpb/rpc.proto)

サービス Maintenance (api/etcdserverpb/rpc.proto)

サービス Watch (api/etcdserverpb/rpc.proto)

メッセージ AlarmMember (api/etcdserverpb/rpc.proto)

メッセージ AlarmRequest (api/etcdserverpb/rpc.proto)

メッセージ AlarmResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthDisableRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthDisableResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthEnableRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthEnableResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleAddRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleAddResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleDeleteRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleDeleteResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleGetRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleGetResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleGrantPermissionRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleGrantPermissionResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleListRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleListResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleRevokePermissionRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthRoleRevokePermissionResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthStatusRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthStatusResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserAddRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserAddResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserChangePasswordRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserChangePasswordResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserDeleteRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserDeleteResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserGetRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserGetResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserGrantRoleRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserGrantRoleResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserListRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserListResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthUserRevokeRoleRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthUserRevokeRoleResponse (api/etcdserverpb/rpc.proto)

メッセージ AuthenticateRequest (api/etcdserverpb/rpc.proto)

メッセージ AuthenticateResponse (api/etcdserverpb/rpc.proto)

メッセージ CompactionRequest (api/etcdserverpb/rpc.proto)

CompactionRequestは、指定したリビジョンまでのキー・バリューストアをコンパクションします。コンパクションリビジョンより小さいリビジョンを持つ、更新によって古くなったキーはすべて削除されます。

メッセージ CompactionResponse (api/etcdserverpb/rpc.proto)

メッセージ Compare (api/etcdserverpb/rpc.proto)

メッセージ DefragmentRequest (api/etcdserverpb/rpc.proto)

メッセージ DefragmentResponse (api/etcdserverpb/rpc.proto)

メッセージ DeleteRangeRequest (api/etcdserverpb/rpc.proto)

メッセージ DeleteRangeResponse (api/etcdserverpb/rpc.proto)

メッセージ DowngradeInfo (api/etcdserverpb/rpc.proto)

メッセージ DowngradeRequest (api/etcdserverpb/rpc.proto)

メッセージ DowngradeResponse (api/etcdserverpb/rpc.proto)

メッセージ DowngradeVersionTestRequest (api/etcdserverpb/rpc.proto)

DowngradeVersionTestRequestは、テスト専用です。このリクエストのversionは、WALレコードのバージョンとして読み取られます。ダウングレード先のバージョンがこのバージョンより小さい場合、オンラインのダウングレードやオフラインの移行は安全ではないため、許可すべきではありません。

メッセージ HashKVRequest (api/etcdserverpb/rpc.proto)

メッセージ HashKVResponse (api/etcdserverpb/rpc.proto)

メッセージ HashRequest (api/etcdserverpb/rpc.proto)

メッセージ HashResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseCheckpoint (api/etcdserverpb/rpc.proto)

メッセージ LeaseCheckpointRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseCheckpointResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseGrantRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseGrantResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseKeepAliveRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseKeepAliveResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseLeasesRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseLeasesResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseRevokeRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseRevokeResponse (api/etcdserverpb/rpc.proto)

メッセージ LeaseStatus (api/etcdserverpb/rpc.proto)

メッセージ LeaseTimeToLiveRequest (api/etcdserverpb/rpc.proto)

メッセージ LeaseTimeToLiveResponse (api/etcdserverpb/rpc.proto)

メッセージ Member (api/etcdserverpb/rpc.proto)

メッセージ MemberAddRequest (api/etcdserverpb/rpc.proto)

メッセージ MemberAddResponse (api/etcdserverpb/rpc.proto)

メッセージ MemberListRequest (api/etcdserverpb/rpc.proto)

メッセージ MemberListResponse (api/etcdserverpb/rpc.proto)

メッセージ MemberPromoteRequest (api/etcdserverpb/rpc.proto)

メッセージ MemberPromoteResponse (api/etcdserverpb/rpc.proto)

メッセージ MemberRemoveRequest (api/etcdserverpb/rpc.proto)

メッセージ MemberRemoveResponse (api/etcdserverpb/rpc.proto)

メッセージ MemberUpdateRequest (api/etcdserverpb/rpc.proto)

メッセージ MemberUpdateResponse (api/etcdserverpb/rpc.proto)

メッセージ MoveLeaderRequest (api/etcdserverpb/rpc.proto)

メッセージ MoveLeaderResponse (api/etcdserverpb/rpc.proto)

メッセージ PutRequest (api/etcdserverpb/rpc.proto)

メッセージ PutResponse (api/etcdserverpb/rpc.proto)

メッセージ RangeRequest (api/etcdserverpb/rpc.proto)

メッセージ RangeResponse (api/etcdserverpb/rpc.proto)

メッセージ RequestOp (api/etcdserverpb/rpc.proto)

メッセージ ResponseHeader (api/etcdserverpb/rpc.proto)

メッセージ ResponseOp (api/etcdserverpb/rpc.proto)

メッセージ SnapshotRequest (api/etcdserverpb/rpc.proto)

メッセージ SnapshotResponse (api/etcdserverpb/rpc.proto)

メッセージ StatusRequest (api/etcdserverpb/rpc.proto)

メッセージ StatusResponse (api/etcdserverpb/rpc.proto)

メッセージ TxnRequest (api/etcdserverpb/rpc.proto)

Googleのpaxosdb論文より：この実装の中心となるのは、MultiOpと呼ぶ強力なプリミティブです。反復処理を除くすべてのデータベース操作は、MultiOpを1回呼び出すことで実装されています。MultiOpはアトミックに適用され、3つの要素で構成されます。1. guardと呼ぶテストのリスト。guard内の各テストは、データベース内の1つのエントリーを検査します。値の有無を確認したり、指定した値と比較したりできます。guard内の異なる2つのテストは、データベース内の同じエントリーにも、異なるエントリーにも適用できます。guard内のすべてのテストが適用され、MultiOpはその結果を返します。すべてのテストがtrueの場合、MultiOpはt op（下記の項目2）を実行し、それ以外の場合はf op（下記の項目3）を実行します。2. t opと呼ぶデータベース操作のリスト。リスト内の各操作は、挿入、削除、検索のいずれかで、データベースの1つのエントリーに適用されます。リスト内の異なる2つの操作は、データベース内の同じエントリーにも、異なるエントリーにも適用できます。これらの操作は、guardの評価結果がtrueの場合に実行されます。3. f opと呼ぶデータベース操作のリスト。t opと同様ですが、guardの評価結果がfalseの場合に実行されます。

メッセージ TxnResponse (api/etcdserverpb/rpc.proto)

メッセージ WatchCancelRequest (api/etcdserverpb/rpc.proto)

メッセージ WatchCreateRequest (api/etcdserverpb/rpc.proto)

メッセージ WatchProgressRequest (api/etcdserverpb/rpc.proto)

監視ストリームの進捗状態を、監視レスポンスストリームでできるだけ早く送信するよう要求します。

メッセージ WatchRequest (api/etcdserverpb/rpc.proto)

メッセージ WatchResponse (api/etcdserverpb/rpc.proto)

メッセージ Event (api/mvccpb/kv.proto)

メッセージ KeyValue (api/mvccpb/kv.proto)

メッセージ Lease (server/lease/leasepb/lease.proto)

メッセージ LeaseInternalRequest (server/lease/leasepb/lease.proto)

メッセージ LeaseInternalResponse (server/lease/leasepb/lease.proto)

メッセージ Permission (api/authpb/auth.proto)

Permissionは、単一のエンティティーです。

メッセージ Role (api/authpb/auth.proto)

Roleは、authRolesバケット内の単一のエントリーです。

メッセージ User (api/authpb/auth.proto)

Userは、authUsersバケット内の単一のエントリーです。

メッセージ UserAddOptions (api/authpb/auth.proto)

10 - APIリファレンス：並行処理

このAPIリファレンスは、各見出しに記載した.protoファイルから自動生成されています。

サービス Lock (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

ロックサービスは、クライアント側のロック機能をgRPCインターフェースとして公開します。

メッセージ LockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

メッセージ LockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

メッセージ UnlockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

メッセージ UnlockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

サービス Election (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

選挙サービスは、クライアント側の選挙機能をgRPCインターフェースとして公開します。

メッセージ CampaignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ CampaignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ LeaderKey (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ LeaderRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ LeaderResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ ProclaimRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ ProclaimResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ ResignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ ResignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

メッセージ Event (api/mvccpb/kv.proto)

メッセージ KeyValue (api/mvccpb/kv.proto)