NodePort服务并非在所有节点上都可用-Java 学习之路

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

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

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

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

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

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

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

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

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

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

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"}

似乎kube-proxy正在运行：

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

和

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

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

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

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

kubeadm init --pod-network-cidr=10.5.0.0/16 --apiserver-cert-extra-sans ['kubemaster.wittlesouth.com','192.168.5.10'

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

在这一点上，我得出结论要么我不理解NodePort服务应该如何工作，要么我的集群配置有问题 . 任何有关诊断的后续步骤的建议将不胜感激！

2 回答

4
定义NodePort服务时，实际上有三个端口正在运行：
- 容器端口：这是您的pod实际侦听的端口，'s only available when directly hitting your container from within the cluster, pod to pod (JIRA'的默认端口为8080） . 您将服务中的 targetPort 设置为此端口 .
- 服务端口：这是服务本身在集群内部公开的负载 balancer 端口 . 使用单个吊舱，'s no load balancing at play, but it'仍然是您服务的切入点 . 服务定义中的 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） - > service（80） - > pod（8080） . （在内部它可能实际上绕过了服务，我对此并不是100％肯定，但你可以从概念上考虑这种方式） .

您似乎're trying to hit JIRA directly with HTTPS. Did you configure a certificate in your JIRA pod? If so you need to make sure it'是 nuc1.wittlesouth.com 的有效证书，或者告诉curl忽略 curl -k 的证书验证错误 .
回复于 2024-04-27T23:00:23+08:00
0

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

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

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

回复于 2024-04-27T23:00:23+08:00

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

2 回答

相关问题