kubeadm: upgrade etcd to 3.4.13-3

[pacoxu]

What type of PR is this?

/kind bug

What this PR does / why we need it:

kubernetes/cluster/images/etcd/Makefile

Lines 32 to 37 in f4801a7

	LATEST_ETCD_VERSION?=3.4.13
	# REVISION provides a version number fo this image and all it's bundled
	# artifacts. It should start at zero for each LATEST_ETCD_VERSION and increment
	# for each revision of this image at that etcd version.
	REVISION?=3

Why we still use 3.4.13-0 here? Is there a special reason?

Which issue(s) this PR fixes:

xref #45506
During investigation etcd versions matrix, I find the revision here is still 3.4.13-0.

Special notes for your reviewer:

Does this PR introduce a user-facing change?

kubeadm upgrade etcd to 3.4.13-3

[neolit123]

Why we still use 3.4.13-0 here? Is there a special reason?

i don't know why there is a -3 revision and what is included in that.

we tend to update the GCE/kube-up tests and kubeadm at the same time.
i see that kube-up is at -0 still:
https://github.com/kubernetes/kubernetes/blob/c2369d9d44ef6af1bd8443a6afe875be5b0d94c6/cluster/gce/manifests/etcd.manifest

usually by the time we move to a -X revisions there is a new etcd MINOR / PATCH version we can move to instead:

maybe this is what we want instead.
https://github.com/etcd-io/etcd/releases/tag/v3.4.15

there is also:
https://github.com/etcd-io/etcd/releases/tag/v3.5.0-alpha.0
(so maybe 3.5.0 will be out before kubernetes 1.21)

/hold

[neolit123]

/sig api-machinery

[pacoxu]

• 3.4.13-1: base-images: Update to debian-base:buster-v1.2.0 and debian-iptables:buster-v1.3.0 #94733 debian-base:buster-v1.2.0; uses iptables 1.8.5
• 3.4.13-2: update debian-base to buster-v1.3.0 for CVEs #98401 debian-base:buster-v1.3.0, upgrade apt to 1.8.2.2
• 3.4.13-3: Bump debian-base to v1.4.0 and debian-iptables to v1.5.0 #98526 debian-base to v1.4.0

It seems no special changes.

[pacoxu]

For kubernetes 1.22 release, etcd 3.5.x may be a better choice.

[neolit123]

@pacoxu can you please change the GCE scripts to -3 too?

cc @jpbetz @wenjiaswe @dims do these revisions contain security fixes that are needed for 1.21?
based on the fact that this was not discussed for 1.21, i'd assume there is nothing critical.

should we instead move to a new etcd PATCH or MINOR version?

[dims]

we should stay as close to what we use in go.mod file:
go.etcd.io/etcd => go.etcd.io/etcd v0.5.0-alpha.5.0.20200910180754-dd1b699fc489 // ae9734ed278b is the SHA for git tag v3.4.13

So the -3 looks like the best option compared to 3.4.x or 3.5.x

[fedebongio]

/assign @wenjiaswe @jingyih
/triage accepted

[wenjiaswe]

/cc @ptabor

[k8s-ci-robot]

@wenjiaswe: GitHub didn't allow me to request PR reviews from the following users: ptabor.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @ptabor

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jingyih]

All the 3.4.13-x images include the same etcd binary built from the etcd codebase with git tag v3.4.13. The incrementing revision suffix -x indicates there is a change in the image other than the etcd binary, for example, when there is change in the base image.

For consistency, let's also update the revision suffix used in tests and GCE scripts. For reference: #94287

[pacoxu]

Rebased.

Per #100612 (comment)
/hold cancel

Currently, 3.4.13-3 would be a better option.

[neolit123]

/lgtm
but we might have to update it again during the 1.22 cycle.

[neolit123]

Conflicting files
cmd/kubeadm/app/constants/constants.go

we merged https://github.com/kubernetes/kubernetes/pull/101104/files#diff-afb644eceb2c0d53027d3e3815f43f489b31b34d18f5402a626f2fbfd4b6eb52R463

[pacoxu]

rebase fixed.

/assign @wojtek-t

[neolit123]

/lgtm

[wojtek-t]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pacoxu, wojtek-t

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster/gce/OWNERS [wojtek-t]
• cmd/kubeadm/OWNERS [wojtek-t]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment