连接到 Kubernetes、GKE 上的 Splash 服务
Connection to Splash service on Kubernetes, GKE
我有一个 Python 控制器,它使用 scrapy-splash
库将 SplashRequest
发送到 Splash 服务。
在本地,我 运行 两个不同的 Docker 中的控制器和启动服务。
yield SplashRequest(url=response.url, callback=parse, splash_url=<URL> endpoint='execute', args=<SPLASH_ARGS>)
当我使用 splash_url="http://127.0.0.1:8050
在本地发送请求时,一切正常。
现在,我想使用 Splash 部署 Kubernetes 并在云上处理启动请求。我已经在 Google Cloud Kubernetes 上使用 type=LoadBalancer
创建了 Splash Deployment 和服务。
并将启动请求发送到启动服务的 External Ip
。
但是 splash 没有收到任何请求...在 python 脚本中我得到
twisted.python.failure.Failure twisted.internet.error.TCPTimedOutError: TCP connection timed out: 60: Operation timed out.
它在过去使用 pod 的 Internal endpoint
时有效,但我开始出现 Missing schema
异常,因为我没有在 url 中使用 http://
.
- 启动画面docker图片scrapinghub/splash:3.2
- Kubernetes 版本 1.7,(也在 1.9 上试过)
飞溅-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-app
name: splash
namespace: ns-app
spec:
replicas: 1
strategy: {}
template:
metadata:
labels:
app: splash
spec:
containers:
- image: scrapinghub/splash:3.2
name: splash
ports:
- containerPort: 8050
resources: {}
restartPolicy: Always
status: {}
飞溅-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: app
name: splash
namespace: ns-app
spec:
type: LoadBalancer
ports:
- name: "8050"
port: 8050
targetPort: 8050
protocol: TCP
selector:
app: app
status:
loadBalancer: {}
更新
我注意到,当我进入 http://localhost:8050/
时,我在本地看到了 Splash UI,而通过 Kubernetes IP 进入时,我看到了
refused to connect
如何解决??
谢谢
问题是 splash-service.yaml
选择器是错误的。它应该指向 Deployment 名称。
apiVersion: v1
kind: Service
metadata:
labels:
app: app
name: splash
namespace: ns-app
spec:
type: LoadBalancer
ports:
- name: "8050"
port: 8050
targetPort: 8050
protocol: TCP
selector:
app: splash
status:
loadBalancer: {}
更新 我现在注意到你发现了这个问题,我的错。
我相信 Ami Hollander 是对的,这是标签选择器的问题,但我想向您解释原因。
考虑到每次使用选择器创建 service 时,也会创建端点资源,其中填充了具有与标签匹配的 pod 的节点的所有地址,您可以添加为以及手动任何 IP 或域指向外部资源。
Kubernetes 服务可以暴露在路由到一个或多个集群节点的外部 IP 上。在服务端口上使用外部 IP(作为目标 IP)进入集群的流量将被路由到服务端点之一。
因此,正如他们指出的那样,您的选择器不匹配任何 pod,端点资源可能不包含任何后端,因此以任何方式路由请求。你可以仔细检查一下 运行ning:
$ kubectl get endpoints
$ Kubectl describe endpoints endpointname
这可能会产生误导,因为另一方面,如果您 运行
$ kubectl get services
您会注意到该服务已正确创建,显示了一个私有 IP 和一个 public IP,这将是一个死胡同。
- 您能够正确地看到它,因为一切正常,但请求没有以正确的方式路由。
我有一个 Python 控制器,它使用 scrapy-splash
库将 SplashRequest
发送到 Splash 服务。
在本地,我 运行 两个不同的 Docker 中的控制器和启动服务。
yield SplashRequest(url=response.url, callback=parse, splash_url=<URL> endpoint='execute', args=<SPLASH_ARGS>)
当我使用 splash_url="http://127.0.0.1:8050
在本地发送请求时,一切正常。
现在,我想使用 Splash 部署 Kubernetes 并在云上处理启动请求。我已经在 Google Cloud Kubernetes 上使用 type=LoadBalancer
创建了 Splash Deployment 和服务。
并将启动请求发送到启动服务的 External Ip
。
但是 splash 没有收到任何请求...在 python 脚本中我得到
twisted.python.failure.Failure twisted.internet.error.TCPTimedOutError: TCP connection timed out: 60: Operation timed out.
它在过去使用 pod 的 Internal endpoint
时有效,但我开始出现 Missing schema
异常,因为我没有在 url 中使用 http://
.
- 启动画面docker图片scrapinghub/splash:3.2
- Kubernetes 版本 1.7,(也在 1.9 上试过)
飞溅-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-app
name: splash
namespace: ns-app
spec:
replicas: 1
strategy: {}
template:
metadata:
labels:
app: splash
spec:
containers:
- image: scrapinghub/splash:3.2
name: splash
ports:
- containerPort: 8050
resources: {}
restartPolicy: Always
status: {}
飞溅-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: app
name: splash
namespace: ns-app
spec:
type: LoadBalancer
ports:
- name: "8050"
port: 8050
targetPort: 8050
protocol: TCP
selector:
app: app
status:
loadBalancer: {}
更新
我注意到,当我进入 http://localhost:8050/
时,我在本地看到了 Splash UI,而通过 Kubernetes IP 进入时,我看到了
refused to connect
如何解决?? 谢谢
问题是 splash-service.yaml
选择器是错误的。它应该指向 Deployment 名称。
apiVersion: v1
kind: Service
metadata:
labels:
app: app
name: splash
namespace: ns-app
spec:
type: LoadBalancer
ports:
- name: "8050"
port: 8050
targetPort: 8050
protocol: TCP
selector:
app: splash
status:
loadBalancer: {}
更新 我现在注意到你发现了这个问题,我的错。
我相信 Ami Hollander 是对的,这是标签选择器的问题,但我想向您解释原因。
考虑到每次使用选择器创建 service 时,也会创建端点资源,其中填充了具有与标签匹配的 pod 的节点的所有地址,您可以添加为以及手动任何 IP 或域指向外部资源。
Kubernetes 服务可以暴露在路由到一个或多个集群节点的外部 IP 上。在服务端口上使用外部 IP(作为目标 IP)进入集群的流量将被路由到服务端点之一。
因此,正如他们指出的那样,您的选择器不匹配任何 pod,端点资源可能不包含任何后端,因此以任何方式路由请求。你可以仔细检查一下 运行ning:
$ kubectl get endpoints
$ Kubectl describe endpoints endpointname
这可能会产生误导,因为另一方面,如果您 运行
$ kubectl get services
您会注意到该服务已正确创建,显示了一个私有 IP 和一个 public IP,这将是一个死胡同。
- 您能够正确地看到它,因为一切正常,但请求没有以正确的方式路由。