karmada icon indicating copy to clipboard operation
karmada copied to clipboard

karmada manage kubernetes v1.16, an remote error: tls: protocol version not supported happend.

Open lcw2 opened this issue 1 year ago • 21 comments

What happened: when karmda manage kubernetes v1.16, can't get pod successfully, but can deliver resources successfully. image

aggregated-apiserver log : image

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

lcw2 avatar Mar 18 '24 03:03 lcw2

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.

liangyuanpeng avatar Mar 18 '24 03:03 liangyuanpeng

but we has a lot clusters in kubernetes v1.16, so we must use this version v1.16

lcw2 avatar Mar 18 '24 03:03 lcw2

It's kubecon paris time and people may not reply right away.

So let's wait and see what others think.

liangyuanpeng avatar Mar 18 '24 06:03 liangyuanpeng

Hi @lcw2, thanks for your feedback.

image

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.

XiShanYongYe-Chang avatar Mar 18 '24 08:03 XiShanYongYe-Chang

  • --tls-min-version=VersionTLS13 ,I have tried to modify this configutation to - --tls-min-version=VersionTLS11, but still return same error

lcw2 avatar Mar 18 '24 09:03 lcw2

  • --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.

zhzhuang-zju avatar Mar 18 '24 11:03 zhzhuang-zju

~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?~

XiShanYongYe-Chang avatar Mar 18 '24 12:03 XiShanYongYe-Chang

I modified karmada-aggregated-apiserver && karmada-apiserver && karmada-webhook. But still happend same error

lcw2 avatar Mar 18 '24 12:03 lcw2

Have you tried to modify the member clusters?

XiShanYongYe-Chang avatar Mar 18 '24 12:03 XiShanYongYe-Chang

Hi @lcw2 is there any progress?

XiShanYongYe-Chang avatar Mar 20 '24 07:03 XiShanYongYe-Chang

I'm working others things these days

lcw2 avatar Mar 20 '24 07:03 lcw2

截屏2024-03-20 15 38 27

maybe because this ?? tls-min version is fixed value

lcw2 avatar Mar 20 '24 07:03 lcw2

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.

zhzhuang-zju avatar Mar 20 '24 08:03 zhzhuang-zju

maybe because this ?? tls-min version is fixed value

Can we change this location to a user configurable parameter? @RainbowMango @jwcesign

XiShanYongYe-Chang avatar Mar 20 '24 09:03 XiShanYongYe-Chang

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?

zhzhuang-zju avatar Mar 20 '24 09:03 zhzhuang-zju

I use tls.version12 replace tls.version13, it works well, maybe it's better to use configurable parameter

lcw2 avatar Mar 20 '24 10:03 lcw2

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?

XiShanYongYe-Chang avatar Mar 21 '24 01:03 XiShanYongYe-Chang

use GODEBUG="tls13=1". it's also useful.

lcw2 avatar Mar 21 '24 03:03 lcw2

@lcw2 ok, thanks a lot~

XiShanYongYe-Chang avatar Mar 21 '24 03:03 XiShanYongYe-Chang

/remove-kind bug /kind question

XiShanYongYe-Chang avatar Mar 21 '24 03:03 XiShanYongYe-Chang

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

RainbowMango avatar Mar 26 '24 08:03 RainbowMango