Closed alvin-7 closed 1 year ago
Here's the thing. HostPort Plugin allocate & deallocate hostPort for pod by webhook mechanism. When pod add event is created, plugin allocate, and when pod delete event is created, plugin deallocate.
However, there will be multiple delete events when pod is terminating, so that plugin has to use a map called isAllocated
to record whether the pod's hostPort number has been allocated to avoid repeating deallocation.
The problem is that the key of map isAllocated is {pod namespace}/{pod name}
, which cause the situation you mentioned. The whole process would be like this:
isAllocated
is set to false.isAllocated
will be changed from false to true.isAllocated
is true.We can find that old pod deallocate more than once.
This problem will be fixed in the next version.
Background
We encountered an issue while configuring Hostport network mode using OKG's GameServerSet.
First of all, the GameServerSet has been deployed in the cluster, and the pod has been started, and its status is Running. Then I deleted it by running "kubectl delete" on the GameServerSet. At this time, pod's status is Terminating. While the pod has not finished exiting, I re-applied this GameServerSet. However, the newly created pod failed to obtain the Hostport.
Later, I deleted this GameServerSet again, waited for the pod to completely exit, and then re-applied this GameServerSet. The pod was able to obtain the Hostport information correctly.
Upon investigation, I found that the Kruise-game controller panicked due to this operation, which caused a restart. I suspect that the issue was caused by this operation as a whole.
Deployment file
Controller logs