karmada manage kubernetes v1.16, an remote error: tls: protocol version not supported happend.
What happened:
when karmda manage kubernetes v1.16, can't get pod successfully, but can deliver resources successfully.
aggregated-apiserver log :
karmadactl get pods works well in kubernetes 1.28 kubectl get cluster works well in kubernetes v1.16
Anything else we need to know?:
Environment:
- Karmada version: v1.9
IMO, kubernetes v1.16 is clearly too old and the doc https://github.com/karmada-io/karmada?tab=readme-ov-file#kubernetes-compatibility maybe outdated.
but we has a lot clusters in kubernetes v1.16, so we must use this version v1.16
It's kubecon paris time and people may not reply right away.
So let's wait and see what others think.
Hi @lcw2, thanks for your feedback.
According to the error message, the problem is related to the TLS version.
We incremented the tls version setting in the v1.8 release for karmada-aggregated-apiserver:
https://github.com/karmada-io/karmada/blob/aa8994719400fb325b2094b04daf302c973c3c37/artifacts/deploy/karmada-aggregated-apiserver.yaml#L49
This is to ensure the use of secure algorithms for processing. Maybe you need to check whether the TLS version is set for the 1.16 cluster in your environment. If no encryption algorithm is set, the default encryption algorithm in the Go is used by default.
1.16 cluster uses go version 1.12.
Go 1.12 adds opt-in support for TLS 1.3 in the crypto/tls package as specified by RFC 8446. It can be enabled by adding the value tls13=1 to the GODEBUG environment variable. It will be enabled by default in Go 1.13.
ref https://tip.golang.org/doc/go1.12#library
You can check your configuration and change the tls-min-version in karmada-aggregated-apiserver to a lower version, or follow the instructions in https://tip.golang.org/doc/go1.12#library. Looking forward to your feedback.
but we has a lot clusters in kubernetes v1.16, so we must use this version v1.16
On this point, I personally feel that it is recommended to upgrade the Kubernetes version.
Hi @zhzhuang-zju, can you help check if there is anything wrong with my reply, please feel free to point it out.
- --tls-min-version=VersionTLS13 ,I have tried to modify this configutation to - --tls-min-version=VersionTLS11, but still return same error
- --tls-min-version=VersionTLS13 ,I have tried to modify this configutation to - --tls-min-version=VersionTLS11, but still return same error
Hi, @lcw2 which component did you modify this configutation? If you only modify the tls-min-version in karmada-aggregated-apiserver, you can try to modify it in karmada-apiserver as well.
~Glad to hear you fixed the problem.~ ~Would like to hear more details from you about the problem fixing. Is it necessary to modify the components of the webhook?~
I modified karmada-aggregated-apiserver && karmada-apiserver && karmada-webhook. But still happend same error
Have you tried to modify the member clusters?
Hi @lcw2 is there any progress?
I'm working others things these days
maybe because this ?? tls-min version is fixed value
Quite possibly. I checked that this code was added for security reasons, so you may need to upgrade your K8s version, or use an earlier version of Karmada, such as v1.7, or add the value tls13=1 to the GODEBUG environment variable to enable TLS 1.3.
maybe because this ?? tls-min version is fixed value
Can we change this location to a user configurable parameter? @RainbowMango @jwcesign
Can we change this location to a user configurable parameter? @RainbowMango @jwcesign
And another question is: can this configurable parameter vary from different member clusters or is it set uniformly?
I use tls.version12 replace tls.version13, it works well, maybe it's better to use configurable parameter
I use tls.version12 replace tls.version13, it works well, maybe it's better to use configurable parameter
Have you tried to change the tls version supported by the member cluster?
use GODEBUG="tls13=1". it's also useful.
@lcw2 ok, thanks a lot~
/remove-kind bug /kind question
I use tls.version12 replace tls.version13, it works well, maybe it's better to use configurable parameter
That's the key point, actually I guess the client don't need to force the remote server to enable TLS1.3.
@jwcesign Is there a specific reason to use the tls.VersionTLS13 here?
https://github.com/karmada-io/karmada/blame/8592cad2b35a01a719bc506159e2af17bbd44fc8/pkg/util/proxy/proxy.go#L148