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

2023-12-13 16:49:02

简介

在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 ServiceLoadBalancer Service或者 Ingress资源,并且可能需要为它分配一个外部DNS名称。

查看Service详细信息

此外,可以通过以下命令查看Service的详细信息,包括其Cluster IP和内部DNS名称:

kubectl describe svc my-service

输出的信息中应该包含类似这样的内容:

其中,`IP: 10.96.123.456` 就是这个ServiceCluster 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 生命周期钩子在应用容器启动后执行,可以用来执行一些初始化任务。

这个例子展示了如何在一个PodYAML文件中定义对另一个Pod的依赖。请注意,这只是一个简化的示例,实际场景可能需要更复杂的配置和错误处理。

使用 `kubectl apply -f` 命令部署资源,如下所示:

kubectl apply -f db-deployment.yaml
kubectl apply -f app-deployment.yaml

这样,当`my-app` Pod启动时,它会等待`my-db` Pod的服务变得可用,然后开始运行自己的主容器。

文章来源:https://blog.csdn.net/justlpf/article/details/134974194
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。