Azure Kubernetes - 如何确定可用于内部负载均衡器的 DNS 名称？

Question

我们已经定义了我们的内部负载均衡器。

apiVersion: v1
kind: Service
metadata:
  name: ads-aks-test
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 9000
  selector:
    app: ads-aks-test

它有自己的 IP 和外部 IP。我们想从另一个虚拟网络中的 VM 访问此服务。 我们需要提前知道它的 DNS 名称 - 完全限定名称，因为我们正在从部署平台部署多个应用程序，并且我们想根据它的服务名称知道在成功部署后如何访问它并且不要等待确定 IP 地址（手动或自动）。例如，这是我们的 APP1，然后我们自动安装需要访问此服务的应用程序 APP2。 因此，出于这个原因，我们希望避免使用 IP 信息。

我们如何确定我们将从第二个应用程序访问它的服务“主机名”是什么？

我在文档中找到的唯一信息是：“如果您的服务使用动态或静态公共 IP 地址，您可以使用服务注释 service.beta.kubernetes.io/azure-dns-label-name 来设置面向公众的 DNS 标签。” - 但这是用于我们不想要的公共负载均衡器！

Answer 1

在您的 K8s 集群中设置 ExternalDNS。这是Azure Private DNS 的指南。这将允许您通过 Kubernetes 资源动态更新您为服务选择的任何主机名的 DNS 记录。

示例配置如下所示（摘自 Azure Private DNS 指南）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: externaldns
spec:
  selector:
    matchLabels:
      app: externaldns
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: externaldns
    spec:
      containers:
      - name: externaldns
        image: k8s.gcr.io/external-dns/external-dns:v0.7.3
        args:
        - --source=service
        - --source=ingress
        - --domain-filter=example.com
        - --provider=azure-private-dns
        - --azure-resource-group=externaldns
        - --azure-subscription-id=<use the id of your subscription>
        volumeMounts:
        - name: azure-config-file
          mountPath: /etc/kubernetes
          readOnly: true
      volumes:
      - name: azure-config-file
        secret:
          secretName: azure-config-file

Answer 2

内部负载平衡器使 Kubernetes 服务仅可供与 Kubernetes 集群在同一虚拟网络中运行的应用程序访问。

https://docs.microsoft.com/en-us/azure/aks/internal-lb

看来你想要这个配置？有对等吗？您还需要允许在 NSG 中进行通信。

Answer 3

你可以kubectl get svc

并使用服务ads-aks-test 的External IP，如注释中您提到的“true”，因此它将是内部IP。

如果您希望在同一个集群中解析服务名称，您可以使用服务名称本身。

https://kubernetes.io/docs/concepts/services-networking/service/

你可以这样做：your-svc.your-namespace.svc.cluster.local

请注意，它仅在服务位于同一个 Kubernetes 集群中时才有效。