【发布时间】:2019-02-06 00:52:21
【问题描述】:
我正在尝试在我的 EKS Kubernetes 集群 v1.10.3 上进行 dns pod 名称解析。我的理解是,创建无头服务将创建我需要的必要 pod 名称记录,但我发现这不是真的。我错过了什么吗?
也对如何使其发挥作用的其他想法持开放态度。找不到替代解决方案。
添加更新
我还不够清楚。基本上我需要这样解决: 工人 767cd94c5c-c5bq7 -> 10.0.10.10 worker-98dcd94c5d-cabq6 -> 10.0.10.11 等等……
我真的不需要循环 DNS,只是在某个地方读到这可能是一种解决方法。谢谢!
# my service
apiVersion: v1
kind: Service
metadata:
...
name: worker
namespace: airflow-dev
resourceVersion: "374341"
selfLink: /api/v1/namespaces/airflow-dev/services/worker
uid: 814251ac-acbe-11e8-995f-024f412c6390
spec:
clusterIP: None
ports:
- name: worker
port: 8793
protocol: TCP
targetPort: 8793
selector:
app: airflow
tier: worker
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
# my pod
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: 2018-08-31T01:39:37Z
generateName: worker-69887d5d59-
labels:
app: airflow
pod-template-hash: "2544381815"
tier: worker
name: worker-69887d5d59-6b6fc
namespace: airflow-dev
ownerReferences:
- apiVersion: extensions/v1beta1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: worker-69887d5d59
uid: 16019507-ac6b-11e8-995f-024f412c6390
resourceVersion: "372954"
selfLink: /api/v1/namespaces/airflow-dev/pods/worker-69887d5d59-6b6fc
uid: b8d82a6b-acbe-11e8-995f-024f412c6390
spec:
containers:
...
...
name: worker
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
...
...
dnsPolicy: ClusterFirst
nodeName: ip-10-0-1-226.us-west-2.compute.internal
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: airflow
serviceAccountName: airflow
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
...
...
status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2018-08-31T01:39:37Z
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: 2018-08-31T01:39:40Z
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: 2018-08-31T01:39:37Z
status: "True"
type: PodScheduled
containerStatuses:
...
...
lastState: {}
name: worker
ready: true
restartCount: 0
state:
running:
startedAt: 2018-08-31T01:39:39Z
hostIP: 10.0.1.226
phase: Running
podIP: 10.0.1.234
qosClass: BestEffort
startTime: 2018-08-31T01:39:37Z
# querying the service dns record works!
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker.airflow-dev.svc.cluster.local
Server: 172.20.0.10
Address: 172.20.0.10#53
Name: worker.airflow-dev.svc.cluster.local
Address: 10.0.1.234
# querying the pod name does not work :(
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local
Server: 172.20.0.10
Address: 172.20.0.10#53
** server can't find worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local: NXDOMAIN
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local
Server: 172.20.0.10
Address: 172.20.0.10#53
*** Can't find worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local: No answer
【问题讨论】:
-
是否有特定原因导致服务 DNS 不适合您?
-
@yosefrow 抱歉,我还不够清楚。基本上我需要这样解决:worker-767cd94c5c-c5bq7 -> 10.0.10.10 worker-98dcd94c5d-cabq6 -> 10.0.10.11 等等....我真的不需要循环 DNS 只是在某处读取这可能是一种解决方法。谢谢!
-
虽然服务确实支持轮询,但是否有理由为什么必须通过确切的 pod 名称而不是通过标签映射到特定 pod 的通用服务名称来引用 pod一对一的选择器?
-
@sebastian 你能让这个工作吗?即 pod 名称的 dns 解析?有一些 apache 项目试图解析 pod 名称并遇到同样的问题。
-
@sebastian 嗨,我的回答有帮助吗?我注意到你还没有接受答案。有什么方法可以改进我的答案以适应您的具体情况吗?
标签: kubernetes kube-dns