Bump etcd to 3.3

[tylerauerbeck]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature

What happened:
It looks like there are a handful of issues waiting on a bump of etcd to v3.3. Is there any timeline on pushing this? Is there any work already being done on this?

[tylerauerbeck]

Not sure what would be most appropriate for this, so I'll start with the sigs from the issues that are already open: #48297 #45037 #46705

/sig instrumentation
/sig api-machinery
/sig scalability

If anybody has suggestions on something more appropriate, please let me know.

[jennybuckley]

/cc @jpbetz @wenjiaswe

[jpbetz]

Yes and Yes. But are you asking about the etcd server or client? Kubernetes 1.10 (slated for release tomorrow) will use the etcd 3.2 client and default to etcd 3.1 for the server (although kubernetes cluster operators can run any etcd server version they want).

Kubernetes 1.11 will be upgraded to use the etcd 3.3 client (#58551 already validated this upgrade is safe and will be cloned shortly to make the actual upgrade on master). It is likely the the default etcd server version for 1.11 will be etcd 3.2 since for downgrade reasons we can only upgrade by one minor etcd version per k8s minor version. But again, cluster operators can run whatever version they want.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[jpbetz]

/remove-lifecycle stale

We'll do this bump once 1.12 opens for PRs.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

/remove-lifecycle stale

[jpbetz]

Update: etcd 3.3 bump is now slated for Kubernetes 1.13.

[jpbetz]

PR to upgrade etcd client to 3.3: #69322

[lavalamp]

I set the milestone to 1.14; let's try to get this out as soon as master reopens so we have lots of soak time.

[timothysc]

/assign @jpbetz @wojtek-t @timothysc
/sig scalability
/sig cluster-lifecycle
/area kubeadm

/cc @kubernetes/sig-cluster-lifecycle

[lavalamp]

/assign @jpbetz @timothysc @wojtek-t

[timothysc]

/cc @gyuho

[luxas]

Just to clarify here -- etcd 3.3.x client is shipped in v1.13, and etcd 3.3.x server is targeted for v1.14?

[gyuho]

@luxas Yes, etcd v3.3 client was merged here #69322, but etcd server bump-up to v1.13 never happened (hence targted for v1.14).

[jpbetz]

Sorry for the belated response on this. Yes v1.14 is best for etcd server 3.3 bump. We don't require the etcd client and server be bumped together, and given the large volume of transitive vendoring changes pulled in by the etcd 3.3 client we went with a full Kubenetes release cycle to bake the client bump in isolation from server changes.

[timothysc]

@jpbetz @ixdy - Now that 1.14 is open could a googler please push an updated image.

/cc @kubernetes/sig-release

[jpbetz]

@timothysc Starting build/push of 3.3.10 image now

[jpbetz]

Build and staging push complete. We've requested promotion of the staging images to k8s.gcr.io. Client upgrade PR is #71615.

[luxas]

Shall we reopen this to track the scalability implications or will you create a different issue to track that @jpbetz @gyuho?

[gyuho]

@luxas Was there any scalability issue related to etcd 3.3 upgrade?

[luxas]

@gyuho I don't know, but we should track and investigate if there is 😉