This message was deleted.
# rke2a
adamant-kite-43734
08/12/2024, 1:15 PMThis message was deleted.
h
hundreds-evening-84071
08/12/2024, 1:42 PMWe had the same issue, so solution (by our windows admin) was to mount secondary drive as c:\var
r
rich-author-23234
08/12/2024, 1:43 PMYeah, not the cleanest from a Windows perspective, but it will have to get the job done I suppose. Thanks for the response!
👍 1
rich-author-23234
08/14/2024, 4:41 PM@hundreds-evening-84071 Did your team also have issues with rke2.exe randomly pegging all CPUs to 100% after some time of being idle? Like, no workload being run whatsoever on the node. Seems like each night when I start work this first node we deployed is in some endless CPU loop
h
hundreds-evening-84071
08/14/2024, 4:45 PMno so far...
r
rich-author-23234
08/14/2024, 4:45 PMOur current baseline is 1.26.13, mind sharing yours? Are you on 2019 or 2022 LTSC?
h
hundreds-evening-84071
08/14/2024, 4:50 PM2022
we decommisioned 2019
mine is 1.26.15
r
rich-author-23234
08/14/2024, 4:50 PMHmm. We are 2022 as well.
rich-author-23234
08/14/2024, 4:51 PMAre you using Calico or Flannel?
rich-author-23234
08/14/2024, 4:51 PMThe only thing I noticed is that our calico/felix.log grows rapidly
h
hundreds-evening-84071
08/14/2024, 4:52 PMcalico
r
rich-author-23234
08/14/2024, 4:57 PMYeah, same. I don't see any known issues for .13 that might explain this behavior, but it could be the wealth of various security settings on our 2K22 nodes causing the behavior as well. Thanks for the sanity check
h
hundreds-evening-84071
08/14/2024, 4:58 PMno problem - good luck
👍 1
r
rich-author-23234
08/14/2024, 5:12 PMAre you running RKE2 Windows on VMware guests?
h
hundreds-evening-84071
08/14/2024, 5:12 PMhyper-v
r
rich-author-23234
08/14/2024, 5:12 PMAh
rich-author-23234
08/14/2024, 5:12 PMThat might be the difference. I noticed something strange in the log causing the kubelet to restart
h
hundreds-evening-84071
08/14/2024, 5:13 PMcontrol plane / etcd is RHEL 9.4 on vmware
windows 2022 are on hyper-v
👍 1
r
rich-author-23234
08/14/2024, 5:13 PMIt wants to read the UUID of the disk RKE2 is using for its storage
rich-author-23234
08/14/2024, 5:13 PMAnd in VMware if you don't set the Advanced Setting "disk.EnableUUID=TRUE" these UUIDs are not populated
👍 1
rich-author-23234
08/14/2024, 5:14 PMNow, no crashing and the logs aren't filling up like they did before. I'll see how it acts tonight.
🤞 1
rich-author-23234
08/20/2024, 12:43 PMThat was definitely the issue, by the way. Node runs clean now.
Do you by chance manage your cluster(s) that have Windows-based nodes with Rancher?
h
hundreds-evening-84071
08/20/2024, 1:46 PMOnly have 1 so far (RKE2) cluster that has 1 windows server as worker node
but yes...
r
rich-author-23234
08/20/2024, 2:02 PMI'm assuming you imported that cluster? When I try to import this new cluster with the Windows node Rancher thinks it needs to be upgraded. Did that happen for you?
h
hundreds-evening-84071
08/20/2024, 3:43 PMit was not imported...
r
rich-author-23234
08/23/2024, 3:07 PMYeah, I'm seeing the behavior is different if provisioned through Rancher vs. imported. When you look at your nodes in that cluster (kubectl get nodes), is the Windows version string the same as the Linux nodes? Mine are different (1.26.13+rke2r1 on Linux nodes vs. 1.26.13 for Windows), which is what I think causes Rancher to try to upgrade it.
4 Views