-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change kubeadm coredns addon images name to coredns/coredns
#7570
change kubeadm coredns addon images name to coredns/coredns
#7570
Conversation
Welcome @MRoci! |
Hi @MRoci. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/assign @mirwan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ok-to-test
I was the one that switch this one to k8s.gcr.io when we had everything in dockerhub and they added a limit.. but you're right as it's not even up to date with 1.21 default (1.8.0) 😢
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, MRoci 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:
Approvers can indicate their approval by writing |
This PR sets kubeadm 1.20 config pointing to docker.io/coredns:1.7.0 which is wrong. Kubeadm switched to coredns/coredns in 1.21, for coredns v1.8.0 (note the "v", you can also pull "k8s.gcr.io/coredns/coredns:v1.7.0"). No need to switch to docker.io |
You are right, should use These are coredns's tag in different image repo :
root@debian:/root # skopeo list-tags docker://k8s.gcr.io/coredns/coredns
{
"Repository": "k8s.gcr.io/coredns/coredns",
"Tags": [
"v1.6.6",
"v1.6.7",
"v1.6.9",
"v1.7.0",
"v1.7.1",
"v1.8.0",
"v1.8.3"
]
}
root@debian:/root # skopeo list-tags docker://k8s.gcr.io/coredns
{
"Repository": "k8s.gcr.io/coredns",
"Tags": [
"1.0.1",
"1.0.1__amd64_linux",
"1.0.1__arm64_linux",
"1.0.1__arm_linux",
"1.0.1__ppc64le_linux",
"1.0.1__s390x_linux",
"1.0.6",
"1.0.6__amd64_linux",
"1.0.6__arm64_linux",
"1.0.6__arm_linux",
"1.0.6__ppc64le_linux",
"1.0.6__s390x_linux",
"1.1.3",
"1.1.3__amd64_linux",
"1.1.3__arm64_linux",
"1.1.3__arm_linux",
"1.1.3__ppc64le_linux",
"1.1.3__s390x_linux",
"1.2.2",
"1.2.3",
"1.2.4",
"1.2.6",
"1.3.0",
"1.3.1",
"1.5.0",
"1.6.2",
"1.6.5",
"1.6.6",
"1.6.7",
"1.7.0"
]
}
root@debian:/root # skopeo list-tags docker://docker.io/coredns/coredns
{
"Repository": "docker.io/coredns/coredns",
"Tags": [
"0.9.10",
"0.9.9",
"006",
"007",
"008",
"009",
"010",
"011",
"1.0.0",
"1.0.1",
"1.0.2",
"1.0.3",
"1.0.4",
"1.0.5",
"1.0.6",
"1.1.0",
"1.1.1",
"1.1.2",
"1.1.3",
"1.1.4",
"1.2.0",
"1.2.1",
"1.2.2",
"1.2.3",
"1.2.4",
"1.2.5",
"1.2.6",
"1.3.0",
"1.3.1",
"1.4.0",
"1.5.0",
"1.5.1",
"1.5.2",
"1.6.0",
"1.6.1",
"1.6.2",
"1.6.3",
"1.6.4",
"1.6.5",
"1.6.6",
"1.6.7",
"1.6.9",
"1.7.0",
"1.7.1",
"1.8.0",
"1.8.3",
"coredns-amd64",
"coredns-arm",
"coredns-arm64",
"coredns-ppc64le",
"coredns-s390x",
"latest"
]
} |
de83100
to
f628dee
Compare
Then let's switch to this |
coredns/coredns
f628dee
to
feec8ce
Compare
@floryut updated the PR in order to use new gcr naming conventions, but maybe doing so using kubeadm 1.20 this will lead in trying to pull |
Hum I'll let reviewers provide their input but I would say that a warning in the release note will be enough to warn users. |
I really like to be able to use latest kubespray release but the previous k8s version, can we just add a if depending on kubeadm / k8s version ? |
|
feec8ce
to
94cb583
Compare
@floryut ok, now it should be able to handle both cases: with kubeadm >=1.21 it uses |
follow new naming conventions for gcr's coredns image. starting from 1.21 kubeadm assumes it to be `coredns/coredns`: this causes the kubeadm deployment being unable to pull image, beacuse `v` was also added in image tag, until the role `kubernetes-apps` ovverides it with the old name, which is only compatible with <=1.7. Backward comptability with kubeadm <=1.20 is mantained checking kubernetes version and falling back to old names (`coredns:1.xx`) when the version is less than 1.21
94cb583
to
f4ae844
Compare
/lgtm |
Fix coredns image repo and tag typo for #7570
…ubernetes-sigs#7570) follow new naming conventions for gcr's coredns image. starting from 1.21 kubeadm assumes it to be `coredns/coredns`: this causes the kubeadm deployment being unable to pull image, beacuse `v` was also added in image tag, until the role `kubernetes-apps` ovverides it with the old name, which is only compatible with <=1.7. Backward comptability with kubeadm <=1.20 is mantained checking kubernetes version and falling back to old names (`coredns:1.xx`) when the version is less than 1.21
…gs#7561) Fix coredns image repo and tag typo for kubernetes-sigs#7570
…ubernetes-sigs#7570) follow new naming conventions for gcr's coredns image. starting from 1.21 kubeadm assumes it to be `coredns/coredns`: this causes the kubeadm deployment being unable to pull image, beacuse `v` was also added in image tag, until the role `kubernetes-apps` ovverides it with the old name, which is only compatible with <=1.7. Backward comptability with kubeadm <=1.20 is mantained checking kubernetes version and falling back to old names (`coredns:1.xx`) when the version is less than 1.21
…gs#7561) Fix coredns image repo and tag typo for kubernetes-sigs#7570
What type of PR is this?
/kind bug
What this PR does / why we need it:
at the moment kubeadm has hardcoded that the name of the coreDNS image
is
coredns/coredns
.When using
k8s.gcr.io
as image repository this is false for versions<=1.7.0 which are located at
k8s.gcr.io/coredns:${VERSION}
.This causes the deployment to be unable to pull images until the
kubernetes-apps
role ovverrides it with the correct image locationdocker.io fullfills the assumptions made by kubeadm that the image is
found under the name
coredns/coredns
Also on gcr.io newest tags such as +1.8.0 seems not to be available at
the moment, making impossible to upgrade the coredns component
Does this PR introduce a user-facing change?: