Kubernetes Headless Service解析为多接口Pod的特定接口 [英] Kubernetes Headless Service resolves to specific interface of a multi-interface Pod

问题描述

我有一个Deployment，其中有多个使用CNI-Genie的接口:

I have a Deployment with multiple interfaces using CNI-Genie:

apiVersion: "apps/v1"
kind: Deployment
metadata:
  name: my-shiny-app
  labels:
    app: shiny-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: shiny-app
  template:
    metadata:
      labels:
        app: shiny-app
      annotations:
        cni: "weave, flannel"
    spec:
      containers:
<---snip--->

我可以看到在pod中确实创建了两个接口，并为其分配了IP地址.

I can see that two interfaces are indeed created in the pod and IP addresses are assigned to it.

$ kubectl describe pod my-shiny-app-65c97dfdb9-crl7q
<---snip--->
Annotations:    cni: weave, flannel
                multi-ip-preferences: {"multi_entry":2,"ips":{"ip1":{"ip":"10.36.0.12","interface":"eth0"},"ip2":{"ip":"10.244.1.53","interface":"eth1"}}}
Status:         Running
IP:             10.36.0.12
<---snip--->

现在，我想将两个接口用于不同类型的流量.例如，用于HTTP流量的eth0接口和eth1将是UDP流量.我的应用程序将绑定并侦听这些接口上的相应类型的流量.

Now I would like to use the two interfaces for different type of traffic. For example, the eth0 interface for HTTP traffic and eth1 will be UDP traffic. My application would bind and listen for the respective kind of traffic on these interfaces.

到目前为止，太好了！

现在，我想使用两个Headless Services来向我的应用程序发送流量.像这样:

Now I would like to use two Headless Services for sending traffic to my application. Like this:

apiVersion: v1
kind: Service
metadata:
  name: shiny-app-http-service
spec:
  selector:
    app: shiny-app
  ports:
  - protocol: TCP
    port: 8080
    name: shiny-app-http
  clusterIP: None
---
apiVersion: v1
kind: Service
metadata:
  name: shiny-app-udp-service
spec:
  selector:
    app: shiny-app
  ports:
  - protocol: UDP
    port: 8805
    name: shiny-app-udp
  clusterIP: None

但是，这两个服务都解析为应用程序eth0接口的IP地址. 是否有任何可能的机制可以使Headless Service可靠地解析为多接口Pod的特定接口?

However, both these services resolve to the IP address of the eth0 interface of the application. Is there any possible mechanism with which a Headless Service can reliably resolve to a specific interface of multi-interface pods?

推荐答案

部署定义正确.您能告诉我以下输出吗?

Deployment definition is correct. Could you show me the output of:

kubectl exec -it my-shiny-app -- ip addr

它将显示是否在每个接口的CNI子网内正确创建了接口.

It will shows if the interfaces were created correctly, each within the subnet of its CNI.

我正在考虑的是创建没有任何选择器的服务:

What I am thinking about is creating a service without any selectors:

apiVersion: v1
kind: Service
metadata:
  name: shiny-app-http-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

因为此服务没有选择器，所以不会自动创建相应的Endpoint对象.您可以通过手动添加Endpoint对象将服务手动映射到运行该服务的网络地址和端口:

Because this Service has no selector, the corresponding Endpoint object is not created automatically. You can manually map the Service to the network address and port where it’s running, by adding an Endpoint object manually:

apiVersion: v1
kind: Endpoints
metadata:
  name: shiny-app-http-service
subsets:
  - addresses:
      - ip: 10.36.0.12
    ports:
      - port: 9376

在没有选择器的情况下访问服务，就如同具有选择器一样.在上面的示例中，流量被路由到YAML中定义的单个端点:10.36.0.12:9376(TCP).

Accessing a Service without a selector works the same as if it had a selector. In the example above, traffic is routed to the single endpoint defined in the YAML: 10.36.0.12:9376 (TCP).

因此，您可以使用两个IP地址创建两个服务和两个端点文件，第一个来自Weave(10.36.0.12)，第二个来自Flannel(10.244.1.53).

So you can create two services and two endpoints files with two IP addresses, first IP from Weave (10.36.0.12) and second from Flannel (10.244.1.53).

有关没有选择器的服务的更多信息，您可以在此处.

More about services without selectors you can find here.

这篇关于Kubernetes Headless Service解析为多接口Pod的特定接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！