Resolve node's hostname
The name of the node registered in the kube-apiserver was also changed at some point to use the IP instead of the Nova instance name as was done originally, and this broke the Kubernetes plugin code.
After Changing the node name back to the Nova instance name in the option --hostname-override for kubelet. I get the following error:
$ kubectl logs kube-proxy-
Error from server: Get https:/
Its reason is that master nodes can not resolve the hostnames of minion nodes. The discussion about this as following:
--------------
<tonanhngo> it's trying to resolve the hostname on the public DNS 8.8.8.8, which would not have this host
<tonanhngo> An easy way to work around this without DNS is to edit the /etc/hosts file on the master node
<tonanhngo> and enter the hostname/IP for each minion
<tonanhngo> Yes, we discussed this idea on one of the previous IRC meeting
<tonanhngo> http://
<tonanhngo> but there was a concern about complication when you have multiple masters, and adding/removing minions
<tonanhngo> The best solution is still to have a DNS service as part of the cluster
<tonanhngo> we can use DNS as a service, I think there is a project for this. Or just a simple DNS service. I haven't looked but I am sure there are several good choices
<tonanhngo> Basically, install the DNS service on the cluster, then add/remove DNS entry when adding/removing minions
<tonanhngo> Generally the DNS would serve as a single source of truth, so we don't have to worry about maintaining consistency across distributed hosts
--------------
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- PanFengyun
- Direction:
- Needs approval
- Assignee:
- PanFengyun
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
strigazi on Mon Oct 10 07:44:49 UTC 2016 : {
As Ton said, this subject came up a lot of times and initially I though it was a good idea. Not the case any more.
My arguments against this option:
- The heat-agent is designed to perform stack updates, usually deploying software. The use of the heat-agent to implement a DNS-like service is a miss-use since it is designed for another purpose.
- The only case that would work is if the IPs of the nodes would never change, so at creation time we could sync all /etc/hosts.
- An option would be to sync periodically but we would increase the load on heat.
}
strigazi on Fri Oct 14 10:02:06 UTC 2016 : {
PanFengyun pinged be privately, here is my response.
The use of heat-agent is NOT GOOD to resolve hostnames.
kubernetes DNS is BETTER.
}
PanFengyun on Fri Oct 16 21:02:06 UTC 2016 : {
@strigazi Thank you for your answer.
@tonanhngo I think there is a better and easier idea:
We can using 'crontab' to run kube-sync-node.sh every 30 minutes. The kube-sync-node.sh will be write into every node by heat template. It will do that:
1. we just update it when bay.status is CREATE_COMPLETE or UPDATE_COMPLETE.
2. Using URL to get the ip and hostname of node from Magnum or Heat
Get URL token: curl -k -X POST -v AUTH_URL/tokens USERNAME PASSWORD
Get IP and hostname: heat stack-show <stack_uuid>
and so on...
3. Updating the /etc/hosts for nodes.
}
