首先免责声明:我只用了很短的时间就使用了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"}
因此由于某种原因,在环回情况下,路由不起作用。我可能可以解决这个问题,因为我认为我们不需要回拨到同一服务。虽然令人困惑。
彼得
答案 0 :(得分: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
请注意,它如何暴露容器正在侦听的相同端口,并使用与选择器相同的标签来确定流量必须流向哪些吊舱