Task/dnsmaq setup #54
Conversation
| #Set upstream dns servers | ||
| server=8.8.8.8 | ||
| server=8.8.4.4 | ||
|
|
There was a problem hiding this comment.
Here would be reasonable to add default resolver provided by cloud
|
Any reason not to put dnsmasq role within setup.yml after common instead of doing it separately in the other two task groupings? |
| with_items: | ||
| - dnsmasq | ||
| - bind-utils | ||
| when: inventory_hostname in groups[master_group_name] |
There was a problem hiding this comment.
only installing on master, any reason for not putting it on workers?
There was a problem hiding this comment.
Once we will have multi master, so it would be high available
There was a problem hiding this comment.
the question was simpler, why not all hosts in the cluster?
There was a problem hiding this comment.
Does it really some reason to put dnsmasq on every node? HA? Local availability?
There was a problem hiding this comment.
I don't have a specific use case, looking to understand if there is a negative impact or reason why we would not have a component across the entire cluster vs. a subset.
There was a problem hiding this comment.
Here is my thoughts: since we separate workload from control we can guarantee that master nodes would not be overloaded, destroyed and so on. So DNS will run on master without any pressure from the real workload.
The other thing is that all hosts are in a flat network. Theoretically there is might be no any issues about network connectivity that can prevent to reach DNS server on master node.
There was a problem hiding this comment.
Sounds reasonable to me.
- Forget about DNS configuration provided by cloud - Disable /etc/resolv.conf modification by dhclient - Fix issue when kube-proxy is not started after reboot
|
Test deployment completed:
Seems like all components running fine, DNS resolution works in both directions: nodes => services, pods => nodes |
|
Either in this PR or in a new one, we need to look at refactoring the kube-proxy in the role kubernetes as now the same logic is within both master and minion, including exact copies of the templates. I had started it as part of the HA since kubelet and proxy seemed to be required on the master nodes as well. |
|
If this looks good, let's merge it. Then we can start refactoring in separate branch. I propose to create branch in this repo, so we can collaborate and push into it. Kind regards,
|
| @@ -13,6 +13,7 @@ | |||
| - flannel | |||
| - master | |||
| - addons | |||
| - dnsmasq | |||
There was a problem hiding this comment.
does the sequencing of when to install and configure dnsmasq need to be last or maybe just a simple dependency to the role kubernetes since both master and minion require it?
There was a problem hiding this comment.
Sequence if important, because until we don’t have kube-dns, dnsmasq setup is partially functional. If it’s acceptable we can make dnsmasq dependency of kubernetes or even addons.
On 21 Aug 2015, at 14:47, Kenny Jones [email protected] wrote:
In setup.yml #54 (comment):
@@ -13,6 +13,7 @@
- flannel
- master
- addons
- dnsmasq
does the sequencing of when to install and configure dnsmasq need to be last or maybe just a simple dependency to the role kubernetes since both master and minion require it?—
Reply to this email directly or view it on GitHub https://github.com/CiscoCloud/kubernetes-ansible/pull/54/files#r37627057.
There was a problem hiding this comment.
Leave it as-is for now. I see a role dependency tree coming.
|
Through a separate branch sounds good. If you can respond to the question on sequencing within the setup.yml, we are good to merge as-is. |
|
Feel free to merge as I'm remote for a while this morning. |
Adds dnsmasq role as required in #43 and #31