ssl - kubectl 在 Linux 上回复连接被拒绝，而在另一台机器(Mac)上回复正常

Question

更新:我只是在同一台 Linux 机器的 docker 中运行该命令，它成功了。因此可能是与 Linux 发行版相关的问题。我个人怀疑与 SSL 认证有关。

我使用 MacBook 在 AWS EKS 中搭建了一个 Kubernetes 集群和一个完整的运行环境。但是，我发现自己无法在我的 Linux 机器 (ArchLinux) 中正确设置 kubectl。

我尝试运行 kubectl --v=1000 get svc (一些集群信息被屏蔽了)

I1020 11:01:44.053581    3266 loader.go:359] Config loaded from file /home/realturner/.kube/config
I1020 11:01:44.054963    3266 round_trippers.go:419] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
I1020 11:01:44.299305    3266 round_trippers.go:438] GET https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s   in 244 milliseconds
I1020 11:01:44.299331    3266 round_trippers.go:444] Response Headers:
I1020 11:01:44.299367    3266 cached_discovery.go:121] skipped caching discovery info due to Get https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s:  dial tcp: lookup XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com  on [::1]:53: read udp [::1]:34122->[::1]:53: read: connection refused

与另一台机器相比，成功的机器回复了标题和正文

I1020 11:03:44.358266    1675 loader.go:359] Config loaded from file /Users/realturner/.kube/config-tv
I1020 11:03:44.359417    1675 round_trippers.go:419] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.6 (darwin/amd64) kubernetes/96fac5c" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
I1020 11:03:46.186432    1675 round_trippers.go:438] GET https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s  200 OK in 1826 milliseconds
I1020 11:03:46.186481    1675 round_trippers.go:444] Response Headers:
I1020 11:03:46.186498    1675 round_trippers.go:447]     Content-Length: 149
I1020 11:03:46.186512    1675 round_trippers.go:447]     Date: Sun, 20 Oct 2019 03:03:46 GMT
I1020 11:03:46.186525    1675 round_trippers.go:447]     Audit-Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
I1020 11:03:46.186538    1675 round_trippers.go:447]     Content-Type: application/json
I1020 11:03:46.262841    1675 request.go:942] Response Body: {"kind":"APIVersions","versions":["v1"],"serverAddressByClientCIDRs":[{"clientCIDR":"0.0.0.0/0","serverAddress":"ip-10-xxx-xxx-xxx.ec2.internal:443"}]}

我怀疑是网络或防火墙问题，但简单地对该端点执行 curl 确实有一些响应，尽管没有权限:

$ curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying x.xxx.xxx.xx:443...
* TCP_NODELAY set
* Connected to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com (x.xxx.xxx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=kube-apiserver
*  start date: Oct 17 10:29:43 2019 GMT
*  expire date: Oct 16 10:29:44 2020 GMT
*  issuer: CN=kubernetes
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55cb670e87b0)
> GET /api?timeout=32s HTTP/2
> Host: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com
> Accept: application/json, */*
> User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 403 
< audit-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 188
< date: Sun, 20 Oct 2019 14:56:42 GMT
< 
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User \"system:anonymous\" cannot get path \"/api\"","reason":"Forbidden","details":{},"code":403}
* Connection #0 to host XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com left intact

编辑 - 这是我的 .kube/config , 与 .kube/tv-config 相同(一些项目被掩盖)。它由 aws eks update-kubeconfig --name <Cluster> 生成

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <Same as the one in `Certificate authority 
` of EKS>
    server: https://<PREFIX>.<REGION>.eks.amazonaws.com
  name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
contexts:
- context:
    cluster: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
    user: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
  name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
current-context: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
kind: Config
preferences: {}
users:
- name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - --region
      - <REGION>
      - eks
      - get-token
      - --cluster-name
      - <Cluster>
      command: aws

Answer 1

哇，原来是DNS解析的问题，尽管我用了好几天新装的系统都没注意到。

之前我只是试过getent hosts <DNS>用于DNS解析和使用curl -v <PREFIX>.<REGION>.eks.amazonaws.com>用于 DNS 解析测试。在我找到我的 /etc/resolv.conf 之前，他们都已经正确回答了实际上是空的。

我错过了配置 systemd 的 DNS 解析。如记录here :

Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable systemd-resolved and symlink /run/systemd/resolve/resolv.conf to /etc/resolv.conf

符号链接(symbolic link)后，它现在可以正常工作了!