[Proposal] Use kube_image_repo as default for etcd when using etcd_kubeadm_enabled

[anthr76]

Environment:

• Cloud provider or hardware configuration: Arm64

• OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"): Ubuntu 20.04

Kubespray version (commit) (git rev-parse --short HEAD): 9c1e082

Network plugin used: Calico

I would like to propose we use the k8s.gcr.io(kube_image_repo) repo as default for etcd. By default Google's image of etcd has multi-arch support, and will pass ETCD_UNSUPPORTED_IMAGE environment variable on arm/unsupported platforms. The efforts for finding this was inspired from #6921.

I would like to create a PR for this, but would like some input from the maintainers first.

Google's/Kubernetes image tag for etcd is 3.4.13-0 regardless of the architecture is k8s.gcr.io/3.4.13-0 compared to v3.4.14 v3.4.14-arm64 respectively. Some logic would need to be created if the kube_image_repo is in use. Would we be okay doing something like this?

Currently for testing purposes I have set in roles/download/defaults/main.yml

etcd_image_repo: "{{ kube_image_repo }}/etcd"
etcd_image_tag: "{{ etcd_version.lstrip('v') }}-0"

On top of this

kubespray/roles/kubernetes/master/templates/kubeadm-config.v1beta2.yaml.j2

Line 67 in aeaa876

{% if host_architecture != "amd64" -%}

will need logic to not be set when kube_image_repo is in use.

etcd logs show:

root@master-01:/etc/kubernetes# crictl logs 56e02fae0ecd7
running etcd on unsupported architecture "arm64" since ETCD_UNSUPPORTED_ARCH is set
flag provided but not defined: -etcd-unsupported-arch
Usage:

  etcd [flags]
    Start an etcd server.

  etcd --version
    Show the version of etcd.

  etcd -h | --help
    Show the help information about etcd.

  etcd --config-file
    Path to the server configuration file. Note that if a configuration file is provided, other command line flags and environment variables will be ignored.

  etcd gateway
    Run the stateless pass-through etcd TCP connection forwarding proxy.

  etcd grpc-proxy
    Run the stateless etcd v3 gRPC L7 reverse proxy.

Since it seems it's a requirement to pass ETCD_UNSUPPORTED_ARCH as a environment variable instead of a flag even using the correct syntax ETCD_UNSUPPORTED_ARCH=arm64 likely won't succeed. Regardless we have set currently

kubespray/roles/kubernetes/master/templates/kubeadm-config.v1beta2.yaml.j2

Line 68 in aeaa876

etcd-unsupported-arch: {{host_architecture}}

which doesn't seem correct in the first place and should instead be

{% if host_architecture != "amd64" -%}
      ETCD_UNSUPPORTED_ARCH : {{host_architecture}}
{% endif %}

It's likely we can't even use this or need it

In my opinion etcd should be passing this environment variable by default in there images or at least have a binary flag to support it. Currently an upstream issue is opened etcd-io/etcd#12543.

It seems it's not possible to pass ETCD_UNSUPPORTED_ARCH as a binary flag https://github.com/etcd-io/etcd/blob/fdb3f897308be59bd132fcf2585d46108a778a5a/Documentation/op-guide/supported-platform.md#32-bit-and-other-unsupported-systems

Considering for the control plane we're using kube_image_repo for images would it make sense to default etcd to it?

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[anthr76]

/remove-lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[anthr76]

/remove-lifecycle rotten

[k8s-triage-robot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[anthr76]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.