Skip to content

[baremetal & friends] Move api-int to /etc/hosts #2258

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.

Sign up for GitHub

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

Closed
cybertron wants to merge 2 commits into from
Closed

[baremetal & friends] Move api-int to /etc/hosts #2258

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e34807a
Move api-int to /etc/hosts
cybertron Nov 24, 2020
5ef9693
Update templates/common/on-prem/units/api-int-service.yaml
cybertron Dec 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 0 additions & 9 deletions templates/common/on-prem/files/coredns-corefile.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,13 +27,4 @@ contents:
match api.{{ .DNS.Spec.BaseDomain }}
fallthrough
}
template IN {{`{{ .Cluster.APIVIPRecordType }}`}} {{ .DNS.Spec.BaseDomain }} {
Copy link
Contributor

@yboaron yboaron Dec 1, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall idea LGTM, I have two Qs.

  1. I understand that you deleted api-int from CoreDNS to verify that we can break the Kubelet->coredns->Kubelet circular dependency and have a stable deployment without relying on CoreDNS for resolving api-int.
    I wonder if it will be safer (for 4.7) to keep also api-int in CoreDns ? in case something went wrong with /etc/hosts .

  2. IIUC, the service setting api-int in /etc/hosts supposed to run on all on-prem platforms, so this PR changes the api-int resolution also for other on-prem platforms. if that is the case, maybe you should update the PR title.

Copy link
Member Author

@cybertron cybertron Dec 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I considered that, but then we have multiple definitions of the api-int record which can get out of sync. If we're going to do this, I think I'd rather just make a clean switch over. I'm open to being convinced otherwise though.

  2. Good point. I didn't want to introduce differences between the platforms when this should work on all of them.

match api-int.{{ .DNS.Spec.BaseDomain }}
answer "{{`{{"{{ .Name }}"}}`}} 60 in {{`{{"{{ .Type }}"}}`}} {{ onPremPlatformAPIServerInternalIP . }}"
fallthrough
}
template IN {{`{{ .Cluster.APIVIPEmptyType }}`}} {{ .DNS.Spec.BaseDomain }} {
match api-int.{{ .DNS.Spec.BaseDomain }}
fallthrough
}
}
11 changes: 11 additions & 0 deletions templates/common/on-prem/units/api-int-service.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
name: api-int.service
# This service is run by a timer
enabled: false
contents: |
[Unit]
Description=Ensure api-int entry exists in /etc/hosts
Before=kubelet.service crio.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c "grep -q -e '{{ onPremPlatformAPIServerInternalIP . }} api-int api-int.{{ .DNS.Spec.BaseDomain }}' -F /etc/hosts || echo '{{ onPremPlatformAPIServerInternalIP . }} api-int api-int.{{ .DNS.Spec.BaseDomain }}' >> /etc/hosts"
12 changes: 12 additions & 0 deletions templates/common/on-prem/units/api-int-timer.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
name: api-int.timer
enabled: true
contents: |
[Unit]
Description=Run api-int service periodically

[Timer]
OnBootSec=10sec
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target