k8s service 内部dns 地址介绍,互相依赖Pod启动介绍

简介

在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:       
Selector:          app=my-app
Type:              ClusterIP
IP Families:       
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:            
```

互相依赖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的服务变得可用，然后开始运行自己的主容器。