Replies: 13 comments 4 replies
-
|
Do you have network policies? |
Beta Was this translation helpful? Give feedback.
-
|
We don't have any customized polices. I ran the command the results are given below. Looks to me these are default. Please share your thoughts. NAMESPACE - NAME - POD-SELECTOR |
Beta Was this translation helpful? Give feedback.
-
|
It does not matter if they are default. Any creation of a pod matching those policies or any deletion of a pod matching those policies will reset the ACL object in Windows. As a consequence, any TCP Session established by any pod included in that ACL will TCP-RST |
Beta Was this translation helpful? Give feedback.
-
|
Give |
Beta Was this translation helpful? Give feedback.
-
|
But the above mentioned polices are not selecting the windows pods. It is selecting 1 pod each policy and those are running under linux nodes. Windows Air-Gap Install |
Beta Was this translation helpful? Give feedback.
-
|
Note that the docs say
Note that the endpoint that the Windows pod communicates with does not ALSO have to be on Windows; the Windows pod may experience a disruption if a pod on a completely different node is recreated and the endpoint IP changes. This is a defect in Windows's HNS subsystem, not in canal, containerd, kubernetes, or RKE2. Please try flannel as @manuelbuil suggested. |
Beta Was this translation helpful? Give feedback.
-
Due to the network policy problem, we introduced Flannel recently. I missed that line in the docs! Thanks, I'll change it :) Flannel can be used as production, yes |
Beta Was this translation helpful? Give feedback.
-
|
After changed the cni to flannel it looks promising. Thanks for the help |
Beta Was this translation helpful? Give feedback.
-
|
sometime flanneld.exe is not starting and all the calls to KubeAPIs are failing when i kill all containerd processes and restart rke2 process then flanneld.exe is starting. It is consistently happening even on machine restart |
Beta Was this translation helpful? Give feedback.
-
|
Probably you are hitting an issue that happens in windows when there is only one interface. When we create the vxlan network, the physical interface bound to that vxlan network disappears for some seconds (sometimes up to 30s). All connections going through that interface get restarted and if we try to connect to somewhere while the interface is gone, the connection will fail. In the last releases, I have added "checks" that verify that the interface is back before starting any connection, e.g. towards kube-api. If it is not ready, it waits a few seconds and tries again |
Beta Was this translation helpful? Give feedback.
-
|
The reason why it works after the restart is because the first time the network gets created. And the second time, it detects that the vxlan network is already there and it does not try creating it again, hence the interface never disappears |
Beta Was this translation helpful? Give feedback.
-
|
Try using the latest RKE2 patch versions and you should see improvements in the behaviour. For example, the latest version includes this PR that does the check before contacting kube-api flannel-io/flannel@00014d0 |
Beta Was this translation helpful? Give feedback.
-
|
Is flannel support multiple NIC cards? is there any way we can choose NIC cards? I have tried node-ip, the processes are started but kube apis are not reachable, getting http/2 handshake error and no k8s services are reachable |
Beta Was this translation helpful? Give feedback.
-
|
Kind of, we should improve it and it's in my backlog. Right now it requires some manual intervention. You need to add to the helm values https://github.com/rancher/rke2-charts/blob/main/charts/rke2-flannel/rke2-flannel/v0.25.400/values.yaml#L11 the flag |
Beta Was this translation helpful? Give feedback.
-
|
Even washout changing anything I could see --iface= parameter in flanneld process arguments. but still kube apis are not reachable, getting http/2 handshake error RKE2 Version: Windows Version: |
Beta Was this translation helpful? Give feedback.
-
|
IIUC, you start rke2+flannel in a fresh node (get-hnsnetwork is empty) and kube-api is not reachable. Could you provide the rke2 logs where you see kube-api is not reachable please? Then you restart the rke2 process, and kube-api is reachable, right? |
Beta Was this translation helpful? Give feedback.
-
Environmental Info:
RKE2 Version:
1.29.2
Node(s) CPU architecture, OS, and Version:
4 Nodes, 3 Linux (Redhat 8), 1 windows (windows server 2022)
Cluster Configuration:
3 linux servers, 1 windows agent
Describe the bug:
I have multiple deployments which have init and normal containers in each one. The init container will call the some Kube APIs to get resources information also update some annotations in the same deployment. Also each deployment has a service running on and one service can communicate with another. The Linux init container and communication between linux service works fine.
But windows init container when it is calling Kuber api get resource information it is getting connection closed by remote host issue. Then it crashing and starting again. Sometime it is starting without error. Sometime 2 or 3 times get this error then starts fine.
Same way from normal containers if it is trying to access a linux service it is getting timeout issue. After 1 or 2 retry it is successful.
It looks to me the windows rke doesn't have stable kubenetes connectivity with windows Nodes.
In linux we are using calico.
Steps To Reproduce:
Run a application to update annotations from init container for the same running deployment.
Expected behavior:
Should not see any communication failures in windows containers
Actual behavior:
Lot of communication failures in windows containers
Additional context / logs:
Beta Was this translation helpful? Give feedback.
All reactions