New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install: Disable kube-proxy-replacement by default #15422
Conversation
@pchaigno might have some concerns regarding the complexity issue which we hit once the socket-lb is disabled on newer kernels. |
Ok. If we do that now, the default installation will likely fail for all users on 5.4+ until we fix the complexity issue. We don't have an obvious fix for the complexity issue. |
Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to block this until #14784 has been resolved.
Let's put this into draft mode until #14726 is resolved. |
7e19a95
to
b69284c
Compare
Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium/cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
We keep kube-proxy-replacement enabled in the external workload test because that test requires host-reachable services and we want to keep the same LB configuration for cluster pods and for the external VM. Related: cilium#15422 Signed-off-by: Thomas Graf <thomas@cilium.io>
The default value of "probe" is not ideal. It leads to a situation where
users are unaware who is performing the load-balancing. This can be
desirable for some and undesirable for others. A couple of
examples:
in kube-proxy replacement mode but the kernel requirement disables
the feature automatically.
Istio. Because of a the probe nature, a kernel upgrade in a cluster
can lead to sudden issues with Istio without any additional action by
the user.
It is generally preferred for users to take an explicit action to enable
kube-proxy and set it to strict so the cilium-agent fails if the mode is
not available.