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

Make host references generic (no more server1), and iterate servers in templates, rather than hardcoding them #94

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Ikariusrb
Copy link

Make all plays accessing "server1" use the first entry in "servers", rather than "server1".

In config templates which list the servers, iterate the members of the "server" group rather than hard-coding the lists.

@wbarnard81
Copy link

wbarnard81 commented Jul 8, 2024

I would like to add a suggestion:
Add:

node-taint:
  - "CriticalAddonsOnly=true:NoExecute"

to RKE2/roles/add-server/templates/rke2-server-config.j2
So that the server nodes are also not worker nodes.

and update
RKE2/roles/add-agent/templates/rke2-agent-config.js to reflect

server: https://{{ vip }}:9345

else, when your first node goes down, you will get an error:

E0708 10:49:49.837744  167802 kubelet_node_status.go:544] "Error updating node status, will retry" err="error getting node \"mgnt-worker-02\": Get \"https://192.168.10.31:6443/api/v1/nodes/mgnt-worker-02?timeout=10s\": dial tcp 192.168.10.31:6443: connect: no route to host"

on your worker nodes and they will show as not ready, when running kubectl get nodes.

@Ikariusrb
Copy link
Author

Ikariusrb commented Jul 8, 2024

@wbarnard81 - while that suggestion looks useful, I generally try to maintain single-purpose PRs; Your suggestion feels like it should be it's own PR. The entire change in this PR is making the playbooks + templates generic so if someone puts different servers, or a different number of servers in the inventory file, everything just works. I can take a look at validating your change and opening a separate PR for it unless you're up to that?

Question about the change you're proposing; is kube-vip already marked as critical addon, which would let it continue to run on the server nodes after your proposed change, or would there be an additional manifest change for kube-vip which should go along with what you're proposing?

@wbarnard81
Copy link

I added my comment here, as I wanted your changes as well and I am not sure when James is going to merge your changes, as I am sure he is a busy man. Other than that, I do not mind making my own PR.

My suggestion is to mark the servers nodes as critical addons only, which kube-vip would be, so that will stay on the server nodes, as I prefer it. The changes I suggested, I already implemented in my files and deployed/tested.

NAME             STATUS   ROLES                       AGE     VERSION
mgnt-master-01   Ready    control-plane,etcd,master   3d22h   v1.29.5+rke2r1
mgnt-master-02   Ready    control-plane,etcd,master   3d22h   v1.29.5+rke2r1
mgnt-master-03   Ready    control-plane,etcd,master   3d22h   v1.29.5+rke2r1
mgnt-worker-01   Ready    <none>                      3d22h   v1.29.5+rke2r1
mgnt-worker-02   Ready    <none>                      3d22h   v1.29.5+rke2r1
mgnt-worker-03   Ready    <none>                      3d22h   v1.29.5+rke2r1

and the kube-vip pod is on the server nodes.

kube-vip-cloud-provider-85fd9b9cf7-lnqbk               1/1     Running     0             21h     10.42.5.5       mgnt-master-02

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants