简介
在Kubernetes（K8s）中，每个Service都有一个内部DNS名称。这个DNS名称是基于服务的名称和命名空间构建的。例如，如果有一个名为 `my-service` 的Service位于 `default` 命名空间下，那么它的内部DNS名称将是 `my-service.default.svc.cluster.local`。
对于内部Pod之间的通信，可以通过使用这个内部DNS名称来访问其他Service。当一个Pod试图解析这个DNS名称时，Kubernetes会自动将其转换为对应的Cluster IP地址，然后将流量路由到正确的Service后端Pods。
要查询Pod的内部DNS配置，你可以在Pod中运行 `cat /etc/resolv.conf` 命令。这将显示Pod使用的DNS服务器和其他DNS相关设置。通常，你会看到一个指向Kubernetes内置DNS系统（如CoreDNS或Kube-DNS）的条目，这个条目的IP地址就是集群内部的DNS服务器地址。
注意，这个内部DNS名称仅在Kubernetes集群内部可用。如果要从外部网络访问这个Service，需要创建一个NodePort Service、LoadBalancer Service或者Ingress资源，并且可能需要为它分配一个外部DNS名称。
查看Service详细信息
此外，可以通过以下命令查看Service的详细信息，包括其Cluster IP和内部DNS名称：
kubectl describe svc my-service输出的信息中应该包含类似这样的内容：
其中，`IP: 10.96.123.456` 就是这个Service的Cluster IP，而内部DNS名称则是 `my-service.default.svc.cluster.local`。
```
Name: my-service
Namespace: default
Labels: app=my-app
Annotations: <none>
Selector: app=my-app
Type: ClusterIP
IP Families: <none>
IP: 10.96.123.456
IP: 2001:db8::abc
Port: http 80/TCP
TargetPort: 80/TCP
Endpoints: 172.17.0.2:80,172.17.0.3:80
Session Affinity: None
Events: <none>
```互相依赖pod启动
在Kubernetes（K8s）中，Pod之间的依赖可以通过多种方式来实现。其中一种常见的方式是通过定义多个Deployment，并在每个Deployment的YAML文件中使用`initContainers`或`postStart`生命周期钩子来确保先决条件得到满足。下面是一个简单的示例：
假设你有一个需要一个数据库服务的应用程序，应用程序运行在一个名为 `my-app` 的Pod中，而数据库服务运行在一个名为 `my-db` 的Pod中。
首先，为数据库创建一个Deployment YAML文件，例如 ` db-deployment.yaml`：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-db
spec:
replicas: 1
selector:
matchLabels:
app: my-db
template:
metadata:
labels:
app: my-db
spec:
containers:
- name: db-container
image: your-database-image:latest
ports:
- containerPort: 5432接下来，创建另一个Deployment YAML文件，例如 `app-deployment.yaml`：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
initContainers:
# 使用Init Container等待数据库服务可用
- name: wait-for-db
image: busybox:1.31.1
command: ['sh', '-c', 'until nslookup my-db.default.svc.cluster.local; do echo waiting for my-db; sleep 2; done;']
containers:
- name: app-container
image: your-app-image:latest
ports:
- containerPort: 80
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo The app has started"]其中：
-wait-for-db是一个Init Container，它会在应用容器启动之前运行。它会不断地尝试解析my-db.default.svc.cluster.local直到成功，这意味着数据库服务已经可用。
-postStart生命周期钩子在应用容器启动后执行，可以用来执行一些初始化任务。
这个例子展示了如何在一个Pod的YAML文件中定义对另一个Pod的依赖。请注意，这只是一个简化的示例，实际场景可能需要更复杂的配置和错误处理。
使用 `kubectl apply -f` 命令部署资源，如下所示：
kubectl apply -f db-deployment.yaml
kubectl apply -f app-deployment.yaml这样，当`my-app` Pod启动时，它会等待`my-db` Pod的服务变得可用，然后开始运行自己的主容器。