Open jodh-intel opened 6 years ago
/cc @sameo, @grahamwhaley, @sboeuf, @dvoytik.
Hi @jodh-intel,
Overall IMHO this makes sense.
Btw, I guess https://github.com/clearcontainers/proxy/pull/107 still could be useful with the above plan. Although the PR should be refactored a bit.
EDIT: orthography
@dvoytik yes this would still make sense, but with a lower priority. Having one proxy per VM would solve most of our issues. In case of a proxy crash we would only loose one pod.
Modify runtime to launch one proxy per VM. This will improve our HA story since there will no longer be a single point of failure on the system (the system-level instance of
cc-proxy
).Plan (ordered steps)
cc-proxy
service (https://github.com/clearcontainers/proxy/pull/167). At this point:cc-proxy
will be able to co-exist with the system-levelcc-proxy
systemd service.cc-proxy
systemd instance won't be being used (although it can continue to run without interfering with the pod-specificcc-proxy
instances).cc-proxy
because since all the proxy requests will be handled by the pod-specificcc-proxy
instances and since we don't want multiple proxies fighting over KSM kernel settings, the KSM code will never be run.cc-proxy
(https://github.com/clearcontainers/proxy/issues/168) which is now implemented by https://github.com/kata-containers/ksm-throttler.cc-proxy
instance.