Question

我决定在自己的机器上安装Kuberenetes，而不是使用谷歌云。我制作了一个我的hello-world web服务器的docker镜像。我设置了hello-controller.yaml：

apiversion: v1
kind: ReplicationController
metadata:
    name: hello
    labels:
        name: hello
spec:
    replicas: 1
    selector:
        name: hello
    template:
        metadata:
            labels:
                name: hello
        spec:
            containers:
            - name: hello
              image: flaggy/hello
              ports:
              - containerPort: 8888

现在我想将服务公开给全世界。我不认为流浪者提供者有负载均衡器（这似乎是最好的方法）。所以我尝试使用NodePort服务类型。但是，我尝试的任何IP上似乎都没有收听新创建的NodePort。这是hello-service.yaml：

apiversion: v1
kind: Service
metadata:
    name: hello
    labels:
        name: hello
spec:
    type: NodePort
    selector:
        name: hello
    ports:
    - port: 8888

如果我登录我的小兵，我可以访问端口8888

$ curl 10.246.1.3:8888
Hello!

当我描述我的服务时，这就是我得到的：

$ kubectl.sh describe service/hello
W0628 15:20:45.049822    1245 request.go:302] field selector: v1 - events - involvedObject.name - hello: need to check if this is versioned correctly.
W0628 15:20:45.049874    1245 request.go:302] field selector: v1 - events - involvedObject.namespace - default: need to check if this is versioned correctly.
W0628 15:20:45.049882    1245 request.go:302] field selector: v1 - events - involvedObject.kind - Service: need to check if this is versioned correctly.
W0628 15:20:45.049887    1245 request.go:302] field selector: v1 - events - involvedObject.uid - 2c0005e7-1dc2-11e5-8369-0800279dd272: need to check if this is versioned correctly.
Name:           hello
Labels:         name=hello
Selector:       name=hello
Type:           NodePort
IP:         10.247.5.87
Port:           <unnamed>   8888/TCP
NodePort:       <unnamed>   31423/TCP
Endpoints:      10.246.1.3:8888
Session Affinity:   None
No events.

我找不到任何人在端口31423上收听，我收集的端口应该是我服务的外部端口。我也对IP 10.247.5.87感到困惑。

我注意到了这个

$ kubectl.sh get nodes
NAME         LABELS                              STATUS
10.245.1.3   kubernetes.io/hostname=10.245.1.3   Ready

为什么IP与我在服务中描述的内容不同？我尝试在我的主机上访问这两个IP：

$ curl 10.245.1.3:31423
curl: (7) Failed to connect to 10.245.1.3 port 31423: Connection refused
$ curl 10.247.5.87:31423
curl: (7) Failed to connect to 10.247.5.87 port 31423: No route to host
$

所以IP 10.245.1.3是可访问的，尽管端口31423没有绑定到它。我尝试将10.247.5.87路由到vboxnet1，但它没有改变任何内容：

$ sudo route add -net 10.247.5.87 netmask 255.255.255.255 vboxnet1
$ curl 10.247.5.87:31423
curl: (7) Failed to connect to 10.247.5.87 port 31423: No route to host

如果我对小兵做sudo netstat -anp | grep 31423则没有任何事情发生。奇怪的是，如果我做sudo netstat -anp | grep 8888，也不会出现任何问题。必须有一些iptables魔法或混杂模式中的某些界面被滥用。

在裸机上工作也难吗？我也没有尝试过AWS提供商，但我很担心。

Answer 1

一些事情。

你的单个pod是10.246.1.3:8888 - 这似乎有用。

您的服务是10.247.5.87:8888 - 只要您在群集中（它是虚拟的，您就不会在netstat中看到它）。这是首先要验证的内容。

您的节点是10.245.1.3，您的服务也应该在10.245.1.3:31423上 - 这部分似乎没有正常工作。与服务IP一样，此绑定是虚拟的 - 它应该显示在iptables-save但不显示netstat。如果您登录节点（minion），可以curl localhost:31423吗？

您可能会发现此文档很有用：https://github.com/thockin/kubernetes/blob/docs-debug-svcs/docs/debugging-services.md

如何向世界公开我的服务？

1 个答案: