一些 Kubernetes pod 始终无法仅在一个节点上解析内部 DNS答案

【问题标题】：Some Kubernetes pods consistently not able to resolve internal DNS on only one node一些 Kubernetes pod 始终无法仅在一个节点上解析内部 DNS
【发布时间】：2020-02-11 22:22:02
【问题描述】：

我刚刚将我的第一个集群从 minikube 移到了 AWS EKS。到目前为止，一切都很顺利，除了我认为遇到了一些 DNS 问题，但只是在一个集群节点上。

我在运行 v1.14 的集群中有两个节点，一种类型的 4 个 Pod，另一种类型的 4 个，每个工作 3 个，但每个工作 1 个 - 都在同一个节点上 - 启动然后错误 (CrashLoopBackOff)容器内的脚本出错，因为它无法解析数据库的主机名。删除出错的 pod，甚至删除所有 pod，每次都会导致同一节点上的一个 pod 失败。

数据库在自己的 pod 中并分配了服务，相同类型的其他 pod 没有解析名称或连接问题。数据库 pod 与无法解析主机名的 pod 位于同一节点上。我不确定如何将 pod 迁移到不同的节点，但这可能值得尝试看看问题是否随之而来。 coredns pod 中没有错误。我不确定从哪里开始寻找从这里发现问题的方法，如果有任何帮助或建议，我们将不胜感激。

提供以下配置。如前所述，它们都在 Minikube 上运行，并且它们都在一个节点上运行。

kubectl get pods - 注意年龄，同时删除所有 pod1 并重新创建自己，3 工作正常，4 没有。

NAME                          READY   STATUS             RESTARTS   AGE
pod1-85f7968f7-2cjwt         1/1     Running            0          34h
pod1-85f7968f7-cbqn6         1/1     Running            0          34h
pod1-85f7968f7-k9xv2         0/1     CrashLoopBackOff   399        34h
pod1-85f7968f7-qwcrz         1/1     Running            0          34h
postgresql-865db94687-cpptb   1/1     Running            0          3d14h
rabbitmq-667cfc4cc-t92pl      1/1     Running            0          34h
pod2-94b9bc6b6-6bzf7     1/1     Running            0          34h
pod2-94b9bc6b6-6nvkr     1/1     Running            0          34h
pod2-94b9bc6b6-jcjtb     0/1     CrashLoopBackOff   140        11h
pod2-94b9bc6b6-t4gfq     1/1     Running            0          34h

postgresql 服务

apiVersion: v1
kind: Service
metadata: 
    name: postgresql
spec:
    ports:
        - port: 5432
    selector:
        app: postgresql

pod1 部署：

apiVersion: apps/v1
kind: Deployment
metadata:
    name: pod1
spec:
    replicas: 4
    selector:
        matchLabels:
            app: pod1
    template:
        metadata:
            labels:
                app: pod1
        spec:
            containers:
                - name: pod1
                  image: us.gcr.io/gcp-project-8888888/pod1:latest
                  env:
                      - name: rabbitmquser
                        valueFrom:
                            secretKeyRef:
                                name: rabbitmq-secrets
                                key: rmquser
                  volumeMounts:
                      - mountPath: /data/files
                        name: datafiles
            volumes:
                - name: datafiles
                  persistentVolumeClaim:
                      claimName: datafiles-pv-claim
            imagePullSecrets:
                - name: container-readonly

pod2 部署：

apiVersion: apps/v1
kind: Deployment
metadata:
    name: pod2
spec:
    replicas: 4
    selector:
        matchLabels:
            app: pod2
    template:
        metadata:
            labels:
                app: pod2
        spec:
            containers:
                - name: pod2
                  image: us.gcr.io/gcp-project-8888888/pod2:latest
                  env:
                      - name: rabbitmquser
                        valueFrom:
                            secretKeyRef:
                                name: rabbitmq-secrets
                                key: rmquser
                  volumeMounts:
                      - mountPath: /data/files
                        name: datafiles
            volumes:
                - name: datafiles
                  persistentVolumeClaim:
                      claimName: datafiles-pv-claim
            imagePullSecrets:
                - name: container-readonly

CoreDNS 配置映射以将 DNS 转发到外部服务（如果它没有在内部解析）。这是我认为会导致问题的唯一地方 - 但正如所说，它适用于一个节点。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . 8.8.8.8
        cache 30
        loop
        reload
        loadbalance
    }

错误的 Pod 输出。两个 pod 都一样，因为它出现在两者共有的库代码中。如前所述，并非所有 pod 都会出现这种情况，因此问题可能不在于代码。

Error connecting to database (psycopg2.OperationalError) could not translate host name "postgresql" to address: Try again

错误的 Pod1 描述：

Name:           xyz-94b9bc6b6-jcjtb
Namespace:      default
Priority:       0
Node:           ip-192-168-87-230.us-east-2.compute.internal/192.168.87.230
Start Time:     Tue, 15 Oct 2019 19:43:11 +1030
Labels:         app=pod1
                pod-template-hash=94b9bc6b6
Annotations:    kubernetes.io/psp: eks.privileged
Status:         Running
IP:             192.168.70.63
Controlled By:  ReplicaSet/xyz-94b9bc6b6
Containers:
  pod1:
    Container ID:   docker://f7dc735111bd94b7c7b698e69ad302ca19ece6c72b654057627626620b67d6de
    Image:          us.gcr.io/xyz/xyz:latest
    Image ID:       docker-pullable://us.gcr.io/xyz/xyz@sha256:20110cf126b35773ef3a8656512c023b1e8fe5c81dd88f19a64c5bfbde89f07e
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 16 Oct 2019 07:21:40 +1030
      Finished:     Wed, 16 Oct 2019 07:21:46 +1030
    Ready:          False
    Restart Count:  139
    Environment:
      xyz:    <set to the key 'xyz' in secret 'xyz-secrets'>           Optional: false
    Mounts:
      /data/xyz from xyz (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-m72kz (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  xyz:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  xyz-pv-claim
    ReadOnly:   false
  default-token-m72kz:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-m72kz
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason   Age                     From                                                   Message
  ----     ------   ----                    ----                                                   -------
  Warning  BackOff  2m22s (x3143 over 11h)  kubelet, ip-192-168-87-230.us-east-2.compute.internal  Back-off restarting failed container

错误的 Pod 2 描述：

Name:           xyz-85f7968f7-k9xv2
Namespace:      default
Priority:       0
Node:           ip-192-168-87-230.us-east-2.compute.internal/192.168.87.230
Start Time:     Mon, 14 Oct 2019 21:19:42 +1030
Labels:         app=pod2
                pod-template-hash=85f7968f7
Annotations:    kubernetes.io/psp: eks.privileged
Status:         Running
IP:             192.168.84.69
Controlled By:  ReplicaSet/pod2-85f7968f7
Containers:
  pod2:
    Container ID:   docker://f7c7379f92f57ea7d381ae189b964527e02218dc64337177d6d7cd6b70990143
    Image:          us.gcr.io/xyz-217300/xyz:latest
    Image ID:       docker-pullable://us.gcr.io/xyz-217300/xyz@sha256:b9cecdbc90c5c5f7ff6170ee1eccac83163ac670d9df5febd573c2d84a4d628d
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 16 Oct 2019 07:23:35 +1030
      Finished:     Wed, 16 Oct 2019 07:23:41 +1030
    Ready:          False
    Restart Count:  398
    Environment:
      xyz:    <set to the key 'xyz' in secret 'xyz-secrets'>     Optional: false
    Mounts:
      /data/xyz from xyz (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-m72kz (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  xyz:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  xyz-pv-claim
    ReadOnly:   false
  default-token-m72kz:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-m72kz
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason   Age                     From                                                   Message
  ----     ------   ----                    ----                                                   -------
  Warning  BackOff  3m28s (x9208 over 34h)  kubelet, ip-192-168-87-230.us-east-2.compute.internal  Back-off restarting failed container

【问题讨论】：

您必须提供有关您当前配置的更多信息，一些服务，部署 YAML 会非常有帮助。您可以将其添加到您的问题中。也请提供kubectl describe pod <pod-name> -n <namespace> 的错误输出。
谢谢@PjoterS - 尽我所能。

标签： kubernetes dns

【解决方案1】：

在一位 k8s 社区成员的建议下，我对我的 coredns 配置进行了以下更改，以更符合最佳实践：

线路：proxy . 8.8.8.8改为forward . /etc/resolv.conf 8.8.8.8

然后我删除了这些pod，经过k8s重新创建后，问题没有再次出现。

编辑：

事实证明，这根本不是问题，因为不久之后问题再次发生并持续存在。最后是这样的：https://github.com/aws/amazon-vpc-cni-k8s/issues/641 按照亚马逊的建议回滚到1.5.3，重启集群，问题解决。

【讨论】：