Question

首先免责声明：我只用了很短的时间就使用了Azure的Kubernetes框架，所以我很抱歉问到什么可能是一个简单的问题。

我有两个在AKS中运行的Kubernetes服务。我希望这些服务能够通过服务名称相互发现。与这些服务关联的Pod分别从我分配给集群的子网中获得IP：

$ kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP         ...
tom       1/1     Running   0          69m   10.0.2.10  ...
jerry     1/1     Running   5          67m   10.0.2.21  ...

如果我直接使用它们的Pod IP在这些服务之间进行REST调用，则这些调用将按预期工作。我当然不想使用硬编码IP。在阅读kube dns时，我的理解是在dns中创建了注册服务的条目。我所做的测试证实了这一点，但是分配给dns条目的IP地址不是Pod的IP地址。例如：

$ kubectl exec jerry -- ping -c 1 tom.default
PING tom.default (10.1.0.246): 56 data bytes

与服务tom关联的IP地址是所谓的“群集ip”：

$ kubectl get services
NAME   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
tom    ClusterIP   10.1.0.246   <none>        6010/TCP   21m
jerry  ClusterIP   10.1.0.247   <none>        6040/TCP   20m

服务杰里也是如此。这些IP地址的问题是使用这些地址的REST调用不起作用。即使是简单的ping超时。所以我的问题是我如何将为服务创建的kube-dns条目与pod IP而不是集群IP相关联？

基于发布的答案，我将“ tom”的yml文件更新如下：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: tom
spec:
  template:
    metadata:
      labels:
        app: tom
    spec:
      containers:
      - name: tom
        image: myregistry.azurecr.io/tom:latest
        imagePullPolicy: Always
        ports:
          - containerPort: 6010
---
  apiVersion: v1
  kind: Service
  metadata:
    name: tom
  spec:
    ports:
    - port: 6010
      name: "6010"
    selector:
      app: tom

，然后重新应用更新。虽然在尝试解析tom.default而不是Pod IP时，我仍然获得了群集IP。我仍然错过了难题的一部分。

更新：根据要求，这是tom的describe输出：

$ kubectl describe service tom
Name:              tom
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"tom","namespace":"default"},"spec":{"ports":[{"name":"6010","po...
Selector:          app=tom
Type:              ClusterIP
IP:                10.1.0.139
Port:              6010  6010/TCP
TargetPort:        6010/TCP
Endpoints:         10.0.2.10:6010

服务杰瑞的输出类似。如您所见，端点是我所期望的--10.0.2.10是分配给与服务tom相关联的pod的IP。尽管Kube DNS会将名称“ tom”解析为群集IP，而不是pod IP：

$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE   IP ...
tom-b4ccbfb97-wfmjp     1/1     Running   0          15h   10.0.2.10
jerry-dd8fbf98f-8jgw7   1/1     Running   0          14h   10.0.2.20

$ kubectl exec jerry-dd8fbf98f-8jgw7 nslookup tom
Name:      tom
Address 1: 10.1.0.139 tom.default.svc.cluster.local

只要REST呼叫被路由到预期的Pod IP，这当然并不重要。我今天在此方面取得了一些成功：

$ kubectl exec jerry-5554b956b-9kpj7 -- wget -O - http://tom:6010/actuator/health
{"status":"UP"}

这表明，即使名称“ tom”解析为群集IP，也会进行路由以确保呼叫到达吊舱。我已经尝试过从服务tom到服务jerry的相同呼叫，这也有效。奇怪的是，从tom到tom的环回超时：

$ kubectl exec tom-5c68d66cf9-dxlmf -- wget -O - http://tom:6010/actuator/health
Connecting to tom:6010 (10.1.0.139:6010)
wget: can't connect to remote host (10.1.0.139): Operation timed out
command terminated with exit code 1

如果我明确使用Pod IP，则该呼叫有效：

$ kubectl exec tom-5c68d66cf9-dxlmf -- wget -O - http://10.0.2.10:6010/actuator/health
{"status":"UP"}

因此由于某种原因，在环回情况下，路由不起作用。我可能可以解决这个问题，因为我认为我们不需要回拨到同一服务。虽然令人困惑。

彼得

Answer 1

这意味着您没有通过服务发布端口（或使用了错误的标签）。您要实现的目标应该完全使用服务来完成，您需要做的就是修正服务定义，以使其正常工作。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: xxx-name
spec:
  template:
    metadata:
      labels:
        app: xxx-label
    spec:
      containers:
      - name: xxx-container
        image: kmrcr.azurecr.io/image:0.7
        imagePullPolicy: Always
        ports:
          - containerPort: 7003
          - containerPort: 443

---
  apiVersion: v1
  kind: Service
  metadata:
    name: xxx-service
  spec:
    ports:
    - port: 7003
      name: "7003"
    - port: 443
      name: "443"
    selector:
      app: xxx-label < must match your pod label
    type: LoadBalancer

请注意，它如何暴露容器正在侦听的相同端口，并使用与选择器相同的标签来确定流量必须流向哪些吊舱

通过名称解析窗格的IP

1 个答案: