Skip to content
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

figure out why create is broken after https://github.com/kubernetes/kubernetes/pull/68890 #43

Closed
BenTheElder opened this issue Sep 27, 2018 · 6 comments
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.

Comments

@BenTheElder
Copy link
Member

/priority critical-urgent
/assign

I've pinned down CI failures to after kubernetes/kubernetes#68890 merged and I can replicate this locally, but I'm not sure why this broke kind just yet. This reliably breaks cluster up.

This changed how some of the static pods are handling DNS, before this they would have used host DNS instead of cluster DNS. I'm not actually sure how this is supposed to bootstrap properly.

FYI @spiffxp :(

cc @MrHohn who I suspect is familiar with DNS policy 😉 and may be able to lend a hand

@k8s-ci-robot k8s-ci-robot added the priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. label Sep 27, 2018
@BenTheElder BenTheElder added the kind/bug Categorizes issue or PR as related to a bug. label Sep 27, 2018
@BenTheElder
Copy link
Member Author

As far as I can tell this change means if there is a cluster DNS configured on the kubelet, critical static system pods will now use it.

  • kubeadm does set a cluster dns
  • it's obviously not actually running initially since everything is just starting to boot ..?
  • there won't be any fallback servers as far as I can tell

https://github.com/kubernetes/kubernetes/blob/e9fe3f77e9b1810dea6a0918feb1f503ae02fcd7/pkg/kubelet/network/dns/dns.go#L346-L360

Not sure how this is supposed to work correctly...

@BenTheElder
Copy link
Member Author

Specifically the api server talks to itself via localhost rather than an IP, per the logs. My suspicion is that it's not using /etc/hosts and is doing a lookup, which fails since it's pointed at a DNS service that doesn't exist yet...

@BenTheElder
Copy link
Member Author

update:

$ git log
commit 1e4edac01237471910b1b9579cdaed242335178b (HEAD)
Merge: 08ed1631ac b9942796db
Author: k8s-ci-robot <k8s-ci-robot@users.noreply.github.com>
Date:   Wed Sep 26 20:37:47 2018 -0700

    Merge pull request #68886 from mgdevstack/master-emptydir-wrapper
    
    Promote emptyDir wrapper volumes tests to Conformanc

works fine.

moving one commit forward to:

commit e9fe3f77e9b1810dea6a0918feb1f503ae02fcd7 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Merge: 1e4edac012 8f6ec989e0
Author: k8s-ci-robot <k8s-ci-robot@users.noreply.github.com>
Date:   Wed Sep 26 20:37:57 2018 -0700

    Merge pull request #68890 from andrewrynhard/dnspolicy
    
    kubeadm: Create control plane with ClusterFirstWithHostNet dns policy

breaks kind create.

This seems to confirm that it's related to the DNS policy change.

@BenTheElder
Copy link
Member Author

found it here: kubernetes/kubernetes#69195

work around is here: #45

@BenTheElder
Copy link
Member Author

well we know why, and have a work around. upstreaming improvements now...

@BenTheElder
Copy link
Member Author

Filed kubernetes/kubernetes#69238

stg-0 pushed a commit to stg-0/kind that referenced this issue Feb 20, 2023
[EOS-10849] Integrar GCP en cloud-provisioner (Part II): Add gcp support to keos.yaml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Development

No branches or pull requests

2 participants