Question

我正在尝试运行3节点Kubernetes集群。我已经启动并运行了足够的集群，我在不同的节点上运行服务。不幸的是，我似乎无法使基于NodePort的服务正常工作（因为我理解正确无论如何......）。我的问题是我定义的任何NodePort服务只能在其运行pod的节点上外部使用，我的理解是它们应该在集群中的任何节点上都可以在外部使用。

一个例子是本地Jira服务，它应该在端口8082（内部）和外部32760上运行。这是服务定义（只是服务部分）：

__exit__()

这是kubectl获取服务的输出--namespace wittle south

apiVersion: v1
kind: Service
metadata:
  name: jira
  namespace: wittlesouth
spec:
  ports:
  - port: 8082
  selector:
    app: jira
  type: NodePort

此服务的pod有一个HostPort设置为8082.群集中的三个节点是nuc1，nuc2，nuc3：

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                       PORT(S)          AGE
jenkins    NodePort       10.100.119.22   <none>                            8081:31377/TCP   3d
jira       NodePort       10.105.148.66   <none>                            8082:32760/TCP   9h
ws-mysql   ExternalName   <none>          mysql.default.svc.cluster.local   3306/TCP         1d

以下是尝试通过主机端口和节点端口访问Jira实例的结果：

Eric:~ eric$ kubectl get nodes
NAME      STATUS    ROLES     AGE       VERSION
nuc1      Ready     master    3d        v1.9.2
nuc2      Ready     <none>    2d        v1.9.2
nuc3      Ready     <none>    2d        v1.9.2

根据我的阅读，似乎多维数据集代理没有做到它应该做的事情。我尝试阅读有关cube-proxy故障排除的文档，它看起来有点过时了（当我在iptables-save中查找主机名时，它什么也没找到）。这是kubernetes版本信息：

Eric:~ eric$ curl https://nuc1.wittlesouth.com:8082/
curl: (7) Failed to connect to nuc1.wittlesouth.com port 8082: Connection refused
Eric:~ eric$ curl https://nuc2.wittlesouth.com:8082/
curl: (7) Failed to connect to nuc2.wittlesouth.com port 8082: Connection refused
Eric:~ eric$ curl https://nuc3.wittlesouth.com:8082/
curl: (51) SSL: no alternative certificate subject name matches target host name 'nuc3.wittlesouth.com'
Eric:~ eric$ curl https://nuc3.wittlesouth.com:32760/
curl: (51) SSL: no alternative certificate subject name matches target host name 'nuc3.wittlesouth.com'
Eric:~ eric$ curl https://nuc2.wittlesouth.com:32760/
^C
Eric:~ eric$ curl https://nuc1.wittlesouth.com:32760/
curl: (7) Failed to connect to nuc1.wittlesouth.com port 32760: Operation timed out

似乎kube-proxy正在运行：

Eric:~ eric$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T11:52:23Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

和

eric@nuc2:~$ ps waux | grep kube-proxy
root      1963  0.5  0.1  54992 37556 ?        Ssl  21:43   0:02 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf
eric      3654  0.0  0.0  14224  1028 pts/0    S+   21:52   0:00 grep --color=auto kube-proxy

似乎cube-proxy正在为我的服务创建iptables条目：

Eric:~ eric$ kubectl get pods --namespace=kube-system
NAME                                      READY     STATUS    RESTARTS   AGE
calico-etcd-6vspc                         1/1       Running   3          2d
calico-kube-controllers-d669cc78f-b67rc   1/1       Running   5          3d
calico-node-526md                         2/2       Running   9          3d
calico-node-5trgt                         2/2       Running   3          2d
calico-node-r9ww4                         2/2       Running   3          2d
etcd-nuc1                                 1/1       Running   6          3d
kube-apiserver-nuc1                       1/1       Running   7          3d
kube-controller-manager-nuc1              1/1       Running   6          3d
kube-dns-6f4fd4bdf-dt5fp                  3/3       Running   12         3d
kube-proxy-8xf4r                          1/1       Running   1          2d
kube-proxy-tq4wk                          1/1       Running   4          3d
kube-proxy-wcsxt                          1/1       Running   1          2d
kube-registry-proxy-cv8x9                 1/1       Running   4          3d
kube-registry-proxy-khpdx                 1/1       Running   1          2d
kube-registry-proxy-r5qcv                 1/1       Running   1          2d
kube-registry-v0-wcs5w                    1/1       Running   2          3d
kube-scheduler-nuc1                       1/1       Running   6          3d
kubernetes-dashboard-845747bdd4-dp7gg     1/1       Running   4          3d

不幸的是，此时我对iptables一无所知，所以我不知道这些条目是否正确。我怀疑在kubeadm init期间我的非默认网络设置可能与此有关，因为我试图将Kubernetes设置为不使用我的网络的相同IP地址范围（基于192.168）。我使用的kubeadm init语句是：

eric@nuc1:/var/lib$ sudo iptables-save | grep hostnames
eric@nuc1:/var/lib$ sudo iptables-save | grep jira
-A KUBE-NODEPORTS -p tcp -m comment --comment "wittlesouth/jira:" -m tcp --dport 32760 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "wittlesouth/jira:" -m tcp --dport 32760 -j KUBE-SVC-MO7XZ6ASHGM5BOPI
-A KUBE-SEP-LP4GHTW6PY2HYMO6 -s 192.168.124.202/32 -m comment --comment "wittlesouth/jira:" -j KUBE-MARK-MASQ
-A KUBE-SEP-LP4GHTW6PY2HYMO6 -p tcp -m comment --comment "wittlesouth/jira:" -m tcp -j DNAT --to-destination 192.168.124.202:8082
-A KUBE-SERVICES ! -s 10.5.0.0/16 -d 10.105.148.66/32 -p tcp -m comment --comment "wittlesouth/jira: cluster IP" -m tcp --dport 8082 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.105.148.66/32 -p tcp -m comment --comment "wittlesouth/jira: cluster IP" -m tcp --dport 8082 -j KUBE-SVC-MO7XZ6ASHGM5BOPI
-A KUBE-SVC-MO7XZ6ASHGM5BOPI -m comment --comment "wittlesouth/jira:" -j KUBE-SEP-LP4GHTW6PY2HYMO6

如果您注意到我使用的是默认为192.168.0.0的pod网络池的calico，我在创建calico服务时修改了calico的pod网络池设置（不确定是否相关））。

此时，我得出结论要么我不理解NodePort服务应该如何工作，要么我的群集配置有问题。关于下一步诊断的任何建议都将非常感谢！

Answer 1

定义NodePort服务时，实际上有三个端口正在运行：

容器端口：这是您的容器实际正在侦听的端口，只有当您从群集中直接命中容器时，它才可用，pod到pod（JIRA的默认端口为8080）。您将服务中的targetPort设置为此端口。
服务端口：这是服务本身在集群内部公开的负载平衡端口。使用单个pod可以在播放时没有负载平衡，但它仍然是您服务的入口点。服务定义中的port定义了这一点。如果您未指定targetPort，则会假定port和targetPort相同。
节点端口：在每个工作节点上公开的路由到您的服务的端口。这是一个通常在30000-33000范围内的端口（取决于您的群集如何配置）。这是您可以从群集外部访问的唯一端口。这是使用nodePort。

假设您在标准端口上运行JIRA，您需要一个类似的服务定义：

apiVersion: v1
kind: Service
metadata:
  name: jira
  namespace: wittlesouth
spec:
  ports:
  - port: 80          # this is the service port, can be anything
    targetPort: 8080  # this is the container port (must match the port your pod is listening on)
    nodePort: 32000   # if you don't specify this it randomly picks an available port in your NodePort range
  selector:
    app: jira
  type: NodePort

因此，如果您使用该配置，则对NodePort服务的传入请求为：NodePort（32000） - ＆gt;服务（80） - ＆gt; pod（8080）。（在内部它可能实际上绕过了服务，我对此并不是100％肯定，但你可以从概念上考虑这一点）。

您似乎也尝试使用HTTPS直接点击JIRA。您是否在JIRA pod中配置了证书？如果是这样，您需要确保它是nuc1.wittlesouth.com的有效证书，或告诉curl忽略curl -k的证书验证错误。

Answer 2

对于第一部分，使用HostPort几乎与预期完全一样，它应该仅在它运行的主机上运行，并且在此处运行。 NodePort仅在其中一个节点上工作的事实是一个问题，因为您正确地认为它应该适用于所有节点。

因为它适用于其中一个，它看起来你的API服务器和kube-proxy完成它们的工作，并且不太可能由它们中的任何一个引起。

要检查的第一件事是你的印花布工作正常，是否可以从所有节点连接到运行你的jira的实际pod。如果没有，那就是你的问题。我建议在你卷曲到的节点上以及运行pod的节点上运行tcpdump以查看数据包是否到达节点，以及它们如何离开它们（具体地说是不响应curl的接收节点）

NodePort服务并非在所有节点上都可用

2 个答案: