0

我已经在生产环境中部署了带有 kubeadm 的 Kubernetes 集群 v1.18.8。集群设置是 3 个主节点和 3 个工作节点，带有外部 Kube-api 负载均衡器，etcd 驻留在主节点中。在安装过程中没有看到任何问题，并且 kube- 中的所有 pod-系统正在运行。但是，当我在以下命令下运行时出现错误时，我得到错误：

  kubectl get cs
    NAME                 STATUS      MESSAGE                                                                                     ERROR
    controller-manager   Unhealthy   Get http://127.0.0.1:10252/healthz: dial tcp 127.0.0.1:10252: connect: connection refused
    scheduler            Unhealthy   Get http://127.0.0.1:10251/healthz: dial tcp 127.0.0.1:10251: connect: connection refused
    etcd-0               Healthy     {"health":"true"}

在进行故障排除时，我发现端口没有被监听。

    sudo netstat -tlpn |grep kube
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN      132584/kubelet
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      133300/kube-proxy
tcp        0      0 127.0.0.1:10257         0.0.0.0:*               LISTEN      197705/kube-control
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      213741/kube-schedul
tcp6       0      0 :::10250                :::*                    LISTEN      132584/kubelet
tcp6       0      0 :::6443                 :::*                    LISTEN      132941/kube-apiserv
tcp6       0      0 :::10256                :::*                    LISTEN      133300/kube-proxy

如果我在开发环境 kubernetes 集群（v1.17）上检查相同的内容，我认为没有问题。

kubectl get cs
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health":"true"}

sudo netstat -tlpn |grep 102
tcp        0      0 127.0.0.1:10257         0.0.0.0:*               LISTEN      2141/kube-controlle
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      2209/kube-scheduler
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN      1230/kubelet
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      2668/kube-proxy
tcp6       0      0 :::10256                :::*                    LISTEN      2668/kube-proxy
tcp6       0      0 :::10250                :::*                    LISTEN      1230/kubelet
tcp6       0      0 :::10251                :::*                    LISTEN      2209/kube-scheduler
tcp6       0      0 :::10252                :::*                    LISTEN      2141/kube-controlle

在新创建的生产集群上，我部署了 nginx 和另一个应用程序，只是为了测试 kubernetes 组件的行为方式，没有看到任何错误。这是版本 v1.18 中的预期行为吗？真的很感激这方面的任何帮助。

注意：内部通信中没有端口被阻塞

4

1 回答 1

1

该命令Kubectl get componentstatus在较新的版本（1.19）中已贬值，并且已经存在许多问题。

这里要注意的要点是 Kubernetes 已经为旧版本禁用了这些组件的不安全服务（至少从 v1.18 开始）。因此，我看不到 kube-controller 和 kube-scheduler 在 1051 和 1052 端口上列出。要恢复此功能，您可以从他们的清单文件中删除 --port=0 （不推荐，因为这会将他们的指标暴露给整个互联网），您可以在里面看到：

/etc/kubernetes/manifests/

我从清单文件中注释掉 --port=0 字段只是为了检查这一点，kubectl get componentstatus 命令有效。

于 2020-09-09T17:52:32.133 回答