Issue title: Java-client seems does not support sni.
 Issue body: Specify sni server name in kubeconfig by using tls-server-name option like below:
apiVersion: v1
clusters:
- cluster:
    server: https://xxxx:xxxx
    tls-server-name: xxxx
    insecure-skip-tls-verify: true
  name: kubernetes
contexts:
......
And I can connect to api-server by us kubectl cli with this config.

But, when I create ApiClient object to connect api-server by use Config.fromConfig(stream) with this config, I found api-server reject the request and throw error "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake".

My question is does Java-client not support sni?  And what the best practice to use sni in java client-side code.

My env is OpenJDK 1.8, java-client 7.0.0, kubernetes 16.9.

Thx

 Comments: 
 Comment 0: Full err log message like below:
io.kubernetes.client.openapi.ApiException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
  at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:898)
  at io.kubernetes.client.openapi.apis.CoreV1Api.listNodeWithHttpInfo(CoreV1Api.java:18490)
  at io.kubernetes.client.openapi.apis.CoreV1Api.listNode(CoreV1Api.java:18462)
......
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:756)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:992)
  at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
  at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
  at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
  at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:336)
  at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:300)
  at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:185)
  at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.java:224)
  at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.java:108)
  at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.java:88)
  at okhttp3.internal.connection.Transmitter.newExchange(Transmitter.java:169)
  at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:41)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
  at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:94)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
  at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
  at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:88)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
  at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:223)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
  at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:221)
  at okhttp3.RealCall.execute(RealCall.java:81)
  at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:894)
  ... 69 common frames omitted
Caused by: java.io.EOFException: SSL peer shut down incorrectly
  at sun.security.ssl.InputRecord.read(InputRecord.java:505)
  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
  ... 96 common frames omitted
 Comment 1: @baikai sadly it seems that okhttp3 lacks support for overriding SNI at clientside (https://github.com/square/okhttp/issues/3050). how do think about workaround by aligning the host name in the target URL w/ ur `tls-server-name` record?
 Comment 2: @yue9944882 thx, do you mean set sni in server url like 'server: https://{sni server name}:443'? 
 Comment 3: @baikai yea and for clarification, we dont have to hack the `server: <>` in kubeconfig, doing sth like `ApiClient#setBasePath` should also work programmatically
 Comment 4: @yue9944882 thx for clarification, I dont have dns yet,  write in /etc/hosts for testing purpose to see it can works or not .
 Comment 5: @yue9944882 I try like you said, but still not works,  err message also be "avax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake".
I try to set URL like 'https://sni_sever_name:port' by apiClient.setBasepath and set sni_sever_name/ip mapping in /etc/hosts.
 Comment 6: Does anyone have some suggestion about this issue? Does anyone tried to use sni server name to access api-server before?
 Comment 7: The error is "remote host closed connection" which I suspect means that your server is disconnecting for some reason, not that the SSL is failing. So I think the SNI concern is a red herring.

Does `kubectl ...` work correctly? If so, try running `kubectl proxy` and then connecting to localhost and see if the client works correctly. That will help narrow down the issue.
 Comment 8: @brendandburns thx, kubectl works well, I connect api-server by same kubeconfig .
 Comment 9: @brendandburns another question is, how to enable client debug info, I tried to set apiClient.setDebugging to true but client output no change. 
 Comment 10: Do you have an HTTP (or other network) proxy in the mix?
 Comment 11: @brendandburns I'm sorry, what is 'in the mix' mean? Client server have not other http proxy running.
 Comment 12: Sorry, I meant: Is there an http proxy between your client and your server?
 Comment 13: @brendandburns OK, We have an nginx between api-server and client server,  nginx have multiple upstream api-server and one sni server name route to one api-server. Actually, We hope to proxy multiple kube cluster with one nginx. Everthing works well in kubectl, but fails by java-client.
 Comment 14: Are you terminating SSL at the API server or inside nginx?
 Comment 15: @brendandburns of course not, I can access api-server by kubernetes native client kubectl, but not by java client, with same kubeconfig.
 Comment 16: Sorry, let me rephrase the question:

Are you using SNI load-balancing in Nginx? Or is NGINX acting as an HTTP(S) Reverse proxy?

Can you try adding `-Djavax.net.debug=all` to your calls and see what it prints and paste it into this issue?
 Comment 17: @brendandburns 
Q1: Are you using SNI load-balancing in Nginx? Or is NGINX acting as an HTTP(S) Reverse proxy?
A:  Yes, nginx acting as an L4 proxy, and use sni to route to upstream server. 
Our system arch like below:
<img width="676" alt="Screen Shot 2021-03-25 at 2 12 23 PM" src="https://user-images.githubusercontent.com/3839050/112427187-21ef8480-8d74-11eb-949e-375f91e9c967.png">

                                             
Q2  Can you try adding -Djavax.net.debug=all to .....
A: Debug info see below:
........
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1616120974 bytes = { 156, 51, 42, 198, 234, 170, 100, 18, 240, 187, 63, 32, 252, 38, 185, 218, 3, 236, 220, 85, 157, 57, 240, 222, 217, 51, 131, 5 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension server_name, server_name: [type=host_name (0), value=ack-joy8et.aliyuncs.com]
Extension renegotiation_info, renegotiated_connection:
.......
 Comment 18: No other output before the exception is thrown?
 Comment 19: And are there any logs in the API server or nginx?

e.g. Can we see if the communication is making it to the kubernetes API server, or if nginx is dropping it.


 Comment 20: @brendandburns no other output. 
 Comment 21: Are there any logs in either nginx or the api server? Can you connect to the API server directly?

It would be useful to understand where the connection is failing.
 Comment 22: The root cause of this problem seems beacuse okhttpclient not pass right server name to backend server, and server-side reject the handshake due to recived server name be incorrect.

May be we can reslove this issue by:
1 Add new item "tls_sever_name" in kubeconfig class to point to server name
2 Set server name in request header by method 'Request.Builder.header("host", "xxx")' during request body construction.

 Comment 23: The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:
- After 90d of inactivity, `lifecycle/stale` is applied
- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed

You can:
- Mark this issue or PR as fresh with `/remove-lifecycle stale`
- Mark this issue or PR as rotten with `/lifecycle rotten`
- Close this issue or PR with `/close`
- Offer to help out with [Issue Triage][1]

Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community).

/lifecycle stale

[1]: https://www.kubernetes.dev/docs/guide/issue-triage/
 Comment 24: The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:
- After 90d of inactivity, `lifecycle/stale` is applied
- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed

You can:
- Reopen this issue or PR with `/reopen`
- Mark this issue or PR as fresh with `/remove-lifecycle rotten`
- Offer to help out with [Issue Triage][1]

Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community).

/close

[1]: https://www.kubernetes.dev/docs/guide/issue-triage/
 Comment 25: @k8s-triage-robot: Closing this issue.

<details>

In response to [this](https://github.com/kubernetes-client/java/issues/1604#issuecomment-972959711):

>The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
>
>This bot triages issues and PRs according to the following rules:
>- After 90d of inactivity, `lifecycle/stale` is applied
>- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
>- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed
>
>You can:
>- Reopen this issue or PR with `/reopen`
>- Mark this issue or PR as fresh with `/remove-lifecycle rotten`
>- Offer to help out with [Issue Triage][1]
>
>Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community).
>
>/close
>
>[1]: https://www.kubernetes.dev/docs/guide/issue-triage/


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
</details>
{'source': 'GithubIssues', 'repo_name_with_owner': 'kubernetes-client/java', 'issue_id': 834445451, 'repo_stars': 2642.0}