You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We start them via systemd and kata-agent is also starting them, so they'll race for socket resources. I think it's best we let kata-agent spawn the processes, as in the nested kata scenario, and deviate as little as possible in peerpods.
A possible exception is "api-server-rest" since we need to spawn this one in the podns network namespace, which kata-agent is unaware of. There will also be no port contention between those 2 processes, as they are running in different ns namespaces.
In the long run, I think kata-agent should be aware of the podns and have a respective flag, so we don't have to patch the pod spec in agent-protocol-forwarder and only need a single api-server-rest process.
The text was updated successfully, but these errors were encountered:
We start them via systemd and kata-agent is also starting them, so they'll race for socket resources. I think it's best we let kata-agent spawn the processes, as in the nested kata scenario, and deviate as little as possible in peerpods.
A possible exception is "api-server-rest" since we need to spawn this one in the
podns
network namespace, which kata-agent is unaware of. There will also be no port contention between those 2 processes, as they are running in different ns namespaces.In the long run, I think kata-agent should be aware of the podns and have a respective flag, so we don't have to patch the pod spec in agent-protocol-forwarder and only need a single api-server-rest process.
The text was updated successfully, but these errors were encountered: