K8S のポッドがドメイン名を介してサービスにアクセスできず、不正なアドレスが表示される

開発 2023-06-21 23:40:17 訪問数: null

オリジナル

システム環境

  • CoreDNS バージョン: 1.6.7
  • Docker バージョン: 19.03.8
  • Kubernetes バージョン: 1.18.4
  • OSバージョン：CentOS 7.4
  • CentOS カーネル バージョン: 3.10.0-1062

問題の説明

Kubernetes はバージョン 1.18.4 にアップグレードされました。アップグレード後、作業ノード上の一部の Pod が起動できなくなり、メッセージはすべて接続タイムアウトに関連していました。タイムアウトしたアドレスのほとんどはクラスターの内部アドレスに接続されていました。 (ClusterIP) をドメイン名の形式で使用します。その一部は、ドメイン名の形式でクラスタの外部アドレスに接続します。IP を介したリモート接続のアプリケーション (たとえば、アプリケーションこの判断に基づいて、最初は DNS に問題があるのではないかと考えましたが、その後ゆっくりと kube- proxy

DNSデバッグツールを導入する

DNS の問題かどうかを検出するには、DNS 問題をテストするための dnsutils ミラーを事前にデプロイする必要があります。このミラーには、DNS 問題をテストするためのツールキットが含まれており、問題の分析と発見に非常に役立ちます

DNS ツール ポッド デプロイメント ファイルを作成する

[root@k8s01 ~]# cat ndsutils.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
spec:
  containers:
  - name: dnsutils
    image: mydlqclub/dnsutils:1.3
    imagePullPolicy: IfNotPresent
    command: ["sleep","3600"]
    
[root@k8s01 ~]# kubectl create -f ndsutils.yaml -n kube-system

問題を分析する

DNSツールPodのコマンドラインを入力します。

上記の DNS ツールはデプロイされていますが、Kubectl ツールを介して Pod コマンド ラインを入力し、内部のツールを使用して問題を分析することもできます。

  • exec: 指定された Pod コンテナにいくつかのコマンドを実行させます
  • -i: コンソールのコンテンツをコンテナに渡します
  • -t: bash コマンドラインを使用するコンテナーの tty を入力します。
  • -n: 上記で DNS ポッドがデプロイされる名前空間を指定します
[root@k8s01 ~]# kubectl exec -it dnsutils /bin/sh -n kube-system

Ping および Nsloopup コマンドのテスト

ping コマンドを使用して、クラスターの内部および外部のアドレスに ping を実行できるかどうかを検出および観察します。

#Ping 集群外部，例如这里 ping 一下百度
/ # ping www.baidu.com
ping: bad address 'www.baidu.com'
 
#Ping集群内部kube-apiserver的Service地址
/ # ping kubernetes.default
ping: bad address 'kubernetes.default'
 
#使用nslookup命令查询域名信息
/ # nslookup kubernetes.default
;; connection timed out; no servers could be reached
 
#直接Ping集群内部kube-apiserver的IP地址
/ # ping 10.96.0.1
PING 10.96.0.1 (10.96.0.1): 56 data bytes
64 bytes from 10.96.0.1: seq=0 ttl=64 time=0.096 ms
64 bytes from 10.96.0.1: seq=1 ttl=64 time=0.050 ms
64 bytes from 10.96.0.1: seq=2 ttl=64 time=0.068 ms
 
#退出dnsutils Pod命令行
/ # exit

nsloopup を使用してドメイン名情報を分析するときに、ドメイン名に対する ping が 2 回正常に実行できず、タイムアウトになることが確認されました。ping kube-apiserver の IP アドレス「10.96.0.1」を使用して正常に通信し、ネットワークプラグイン (flannel、calico など) の問題を除外します。暫定的な判断としては、CoreDNS のエラーによる問題が考えられます。コンポーネントがあるので、次に CoreDNS をテストします。これは正常ですか

CoreDNSの検出

CoreDNS ポッドが実行されているかどうかを確認します。READY 0 の場合は、CoreDNS コンポーネントに問題があることを示します。

[root@k8s01 ~]# kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME                       READY   STATUS    RESTARTS   AGE
coredns-669f77d7cc-8pkpw   1/1     Running   2          6h5m
coredns-669f77d7cc-jk9wk   1/1     Running   2          6h5m

CoreDNS の 2 つの Pod が正常に起動することを確認し、2 つの Pod のログ情報を確認してエラー ログがあるかどうかを確認します。

[root@k8s01 ~]# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \
  do kubectl logs --namespace=kube-system $p; done
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b

上記の情報から、ログ情報の正常起動に問題がないことが分かりますので、CoreDNSのエントリーサービス「kube-dns」が存在するか確認してください。

[root@k8s01 ~]# kubectl get service -n kube-system | grep kube-dns
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)               
kube-dns                    ClusterIP   10.96.0.2      <none>        53/UDP,53/TCP,9153/TCP

kube-dns の IP は 10.96.0.2 で、クラスター内のポッドはこの IP を介して DNS コンポーネントと対話します。DNS 情報をクエリすると、サービス「kube-dns」も存在することが示されますが、サービスはバインドされていますendpoints を介して Pod に接続するため、この CoreDNS のエンドポイントが存在するかどうか、および情報が正しいかどうかを確認してください。

[root@k8s01 ~]# kubectl get endpoints kube-dns -n kube-system
NAME       ENDPOINTS                                                          AGE
kube-dns   10.244.230.193:53,10.244.247.65:53,10.244.230.193:53 + 3 more...   26h

エンドポイント構成も正常であり、2 つの CporeDNS Pod に正しく関連付けられていることがわかります。

CoreDNS ドメイン名解決ログを観察します。

Kubernetes ConfigMap に保存されている CoreDNS 構成パラメータ情報を変更し、ログ パラメータを追加して、CoreDNS ログにドメイン名解決情報を表示させます。  CoreDNS 構成パラメータの説明:

  • エラー: エラーメッセージをコンソールに出力します。
  • health: CoreDNS が監視および検出します。検出アドレスは http://localhost:8080/health ステータスが異常な場合は、Pod を再起動します。
  • Ready: すべてのプラグインがロードされると、エンドポイントを介してポート 8081 で HTTP ステータス 200 が返されます。
  • kubernetes: CoreDNS は、Kubernetes サービスとポッドの IP に基づいて DNS クエリに応答します。
  • prometheus: CoreDNS メトリクス情報インターフェイスを有効にするかどうか (構成されている場合は有効にします)。インターフェイス アドレスは http://localhost:9153/metrics です。
  • forward: Kubernetes クラスターにないドメイン名クエリは、事前定義されたリゾルバー (/etc/resolv.conf) に転送されます。
  • キャッシュ: キャッシュを有効にする、30 秒の TTL
  • ループ: 単純な転送ループを検出し、ループが見つかった場合は CoreDNS プロセスを停止します。
  • reload: CoreDNS 設定を監視し、設定が変更された場合は設定をリロードします。
  • ロードバランス: DNS ロードバランサー、デフォルトのround_robin
#编辑 coredns 配置
[root@k8s01 ~]# kubectl edit configmap coredns -n kube-system
apiVersion: v1
data:
  Corefile: |
    .:53 {
        log            #添加log
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

変更を保存した後、CoreDNS は構成情報を自動的に再ロードしますが、これらの変更が CoreDNS ポッドに伝播されるまでに 1 ～ 2 分かかる場合があり、一定の時間が経過した後に CoreDNS ログを再度確認します。

[root@k8s01 ~]# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \
  do kubectl logs --namespace=kube-system $p; done
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete

CoreDNS が設定をリロードしたことがわかり、再度 dnsuitls Pod に入って ping コマンドを実行します。

#进入 DNSutils Pod 命令行
[root@k8s01 ~]# kubectl exec -it dnsutils /bin/sh -n kube-system
 
#执行 ping 命令
/ # ping www.baidu.com
 
#退出 dnsutils Pod 命令行
/ #  exit

CoreDNSのログ情報を再度確認する

[root@k8s01 ~]# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \
  do kubectl logs --namespace=kube-system $p; done
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete

以前に ping コマンドを実行しなかったときと同様に、DNS ドメイン名解決のログ情報が存在しないことがわかり、Pod がドメイン名解決を実行するときにリクエストが CoreDNS に入らないことがわかります。次に、Pod 内の DNS 構成情報を確認し、問題を分析します。

ポッド内の DNS 構成情報を表示する

ポッドの DNS ポリシーはデフォルトで ClusterFirst に設定されます。このパラメータの機能は、最初に Kubernetes DNS プラグイン アドレスから DNS 設定を読み取ることです。したがって、通常に作成されたポッドでは、DNS 設定の DNS サーバー アドレスを指定どおりに指定する必要がありますKubernetes クラスターの DNS プラグイン サービスによる DNS ポリシー (dnsPolicy) は、次の 4 種類の仮想 IP アドレスをサポートします。

  • デフォルト: DNS 設定は、DNS が配置されているノードから継承されます。つまり、ポッドの DNS 設定はホストの DNS 設定とまったく同じです。
  • ClusterFirst: Kubenetes の DNS プラグインで DNS 解決を事前に実行し、解決に失敗した場合はホストマシンの DNS を使用して解決します。
  • ClusterFirstWithHostNet: ポッドは HOST モード (ホストネットワーク) で起動されます。HOST モードは、ポッド内のすべてのコンテナを表すために使用されます。ホスト マシンの /etc/resolv.conf 設定は DNS 解決に使用されますが、HOST モードが使用されている場合は、 Kubernetes は引き続き DNS サービスを使用します。dnsPolicy を ClusterFirstWithHostNet に設定します。
  • なし: kubernetes システムによって提供される DNS を完全に無視し、ポッド仕様の dnsConfig 設定に焦点を当てます。

dnsutils ポッドに入り、ポッド内の DNS 設定ファイル /etc/resolv.conf の設定パラメータが正しいかどうかを確認します。  resolv.conf 設定パラメータの説明:

  • search: ドメイン名のクエリ順序を示します。
  • nameserver: DNS サーバーの IP アドレスを指定します。複数のネームサーバーを設定できます。
#进入 dnsutils Pod 内部 sh 命令行
[root@k8s01 ~]# kubectl exec -it dnsutils /bin/sh -n kube-system
 
## 查看 resolv.conf 配置文件
/ # cat /etc/resolv.conf
 
nameserver 10.96.0.2
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
 
#退出 DNSutils Pod 命令行
/ # exit

ポッド内の resolv.conf の内容が確認できます。ここで、ネームサーバーは DNS 解決サーバーの IP を「10.96.0.2」として指定しています。この IP アドレスは、まさに CoreDNS のサービス「kube-dns」のクラスターIP です。 Kubernetes クラスターは、ポッド内でドメイン名解決が実行されることを示します。このとき、クエリ リクエストは実際にドメイン名解決のためにサービス「kube-dns」によって提供される仮想 IP に送信されます。は問題なく、CoreDNS も問題ありませんが、Pod 自体のドメイン名解決が正常ではない可能性がありますか? または、サービス「kube-dns」が通常、ドメイン名解決リクエストを CoreDNS ポッドに転送できるかどうか

問題はどこにあるのか

ポッド自体のドメイン名解決に問題があると考えられ、ドメイン名が正常に解決できません。または、Pod は正常ですが、ドメイン名解決を要求するときにリクエストがサービス「kube-dns」に送信され、リクエストが CoreDNS Pod に正常に転送されません。これら 2 つの点を確認するには、/etc/ ファイルを変更します。テスト用ポッドの resolv.conf 設定 resolv.conf 内の DNS 解決リクエスト アドレスを Alibaba Cloud DNS サーバー アドレスに変更して確認し、ping コマンドを実行してポッド解決ドメイン名に問題があるかどうかを確認します。

##进入dnsutils Pod内部sh命令行
[root@k8s01 ~]# kubectl exec -it dnsutils /bin/sh -n kube-system
 
#编辑/etc/resolv.conf 文件，修改 nameserver 参数为阿里云提供的 DNS 服务器地址
/ #  vi /etc/resolv.conf
 
nameserver 223.5.5.5
#nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
 
#修改完后再进行 ping 命令测试，看看是否能够解析baidu.com网址
/ # ping baidu.com
PING baidu.com (220.181.38.148): 56 data bytes
64 bytes from 220.181.38.148: seq=0 ttl=48 time=31.029 ms
64 bytes from 220.181.38.148: seq=1 ttl=48 time=31.102 ms
64 bytes from 220.181.38.148: seq=2 ttl=48 time=31.097 ms
64 bytes from 220.181.38.148: seq=3 ttl=48 time=30.999 ms
 
#退出 DNSutils Pod 命令行
/ #  exit

Pod の DNS サーバー アドレスを変更した後、ドメイン名解決が正常であることを確認します。これは、Pod 自体のドメイン名解決に問題がないことを示しています。次に、resolv.conf 内の DNS 解決要求アドレスを、次の IP アドレスに変更します。 CoreDNS ポッドに接続して、ポッドがサービスを介して転送する代わりに CoreDNS ポッドの IP に直接接続できるようにし、ping コマンド テストを実行して、サービス kube-dns がリクエストを CoreDNS ポッドに正常に転送できるかどうかを判断します。

#查看CoreDNS Pod的IP地址
[root@k8s01 ~]# kubectl get pods -n kube-system -o wide | grep coredns
coredns-669f77d7cc-rss5f     1/1     Running   0     10.244.2.155   k8s-node-1
coredns-669f77d7cc-rt8l6     1/1     Running   0     10.244.1.163   k8s-node-2
 
#进入dnsutils Pod内部sh命令行
/ # kubectl exec -it dnsutils /bin/sh -n kube-system
 
#编辑 /etc/resolv.conf文件，修改nameserver参数为阿里云提供的DNS服务器地址
/ # vi /etc/resolv.conf
nameserver 10.244.2.155
nameserver 10.244.1.163
#nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
 
## 修改完后再进行 ping 命令测试，看看是否能够解析 www.mydlq.club 网址
/ # ping baidu.com
PING baidu.com (220.181.38.148): 56 data bytes
64 bytes from 220.181.38.148: seq=0 ttl=48 time=31.029 ms
64 bytes from 220.181.38.148: seq=1 ttl=48 time=31.102 ms
64 bytes from 220.181.38.148: seq=2 ttl=48 time=31.097 ms
64 bytes from 220.181.38.148: seq=3 ttl=48 time=30.999 ms
#退出 DNSutils Pod命令行
/ # exit
 
#观察CoreDNS日志信息，查看有无域名解析相关日志
[root@k8s01 ~]# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \
  do kubectl logs --namespace=kube-system $p; done
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.baidu.com.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000398875s
[INFO] 10.244.1.162:40261 - 20812 "A IN www.baidu.com.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000505793s
[INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.baidu.com.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000215384s
[INFO] 10.244.1.162:55066 - 53239 "A IN www.baidu.com.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000267642s
 
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.baidu.com.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000217299s
[INFO] 10.244.1.162:40261 - 20812 "A IN www.baidu.com.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000264552s
[INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.baidu.com.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000144795s
[INFO] 10.244.1.162:55066 - 53239 "A IN www.baidu.com.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.00

上記の 2 つのテストの後、Pod DNS 構成の DNS サーバー アドレスが CoreDNS Pod の IP アドレスに直接変更された場合、確かに DNS 解決に問題はなく、正常に解決できることがすでにわかります。ただし、通常の状況では、ポッド内の DNS 設定のサーバー アドレスは通常 CoreDNS のサービス アドレスであり、ポッドの IP に直接バインドされていません (ポッドが再起動されるたびに IP が変更されるため)。問題が見つかりました。「kube-dns」がドメイン名解決リクエストを転送するときに問題があります。一般に、サービスの問題は Kube-proxy コンポーネントに関連しています。次に、このコンポーネントに問題があるかどうかを観察します。

kube-proxy コンポーネントを表示する

kube-proxy ログを観察して、問題があるかどうかを確認します。

#查看kube-proxy Pod列表
[root@k8s01 ~]# kubectl get pods -n kube-system | grep kube-proxy
 
kube-proxy-6kdj2          1/1     Running   3          9h
kube-proxy-lw2q6          1/1     Running   3          9h
kube-proxy-mftlt          1/1     Running   3          9h
 
#选择一个kube-proxy Pod，查看最后5条日志内容
[root@k8s01 ~]# kubectl logs kube-proxy-6kdj2 --tail=5  -n kube-system
E0326 15:20:23.159364  1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159388  1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/UPD, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159479  1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159501  1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/TCP, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159595  1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0

kube-proxy ポッドのログから、エラーレベルのログ情報が多数あることがわかり、キーワード IPVS および parseIP Error から、IPVS モジュールが IP をフォーマットしていることが問題の原因である可能性があることがわかります。 、この問題は kubernetes 1.18 にアップグレードされるため、バージョンが現れたばかりなので、Kubernetes Github に行って関連する問題を確認したところ、Kubernetes バージョンを 1.18 にアップグレードした後に同じ問題が発生した人がいることを発見しました。問題の Kubernetes メンテナと話し合った後、その理由は、Kubernetes の新しいバージョンで使用される IPVS モジュールが比較的新しく、システムのカーネル バージョンのサポートが必要であるためである可能性があると分析されました。ここでは CentOS システムが使用されており、カーネル バージョンは 3.10 です。内部の IPVS モジュールは比較的古く、新しいバージョンの Kubernetes IPVS に必要な依存関係がありません。この問題のディスカッション結果によると、この問題の解決策は、はい、カーネルを新しいバージョンに更新します問題のアドレス: https://github .com/kubernetes/kubernetes/issues/89520

解決

システムのカーネルバージョンをアップグレードする

Kubernetes クラスター内の各ノードの CentOS システム カーネル バージョンをアップグレードする

#载入公钥
[root@k8s01 ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
 
#安装 ELRepo 最新版本
[root@k8s01 ~]# yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
 
#列出可以使用的 kernel 包版本
$ yum list available --disablerepo=* --enablerepo=elrepo-kernel
 
#安装指定的 kernel 版本：
[root@k8s01 ~]# yum install -y kernel-lt-4.4.218-1.el7.elrepo --enablerepo=elrepo-kernel
 
#查看系统可用内核
[root@k8s01 ~]# cat /boot/grub2/grub.cfg | grep menuentry
 
menuentry 'CentOS Linux (3.10.0-1062.el7.x86_64) 7 (Core)' --class centos （略）
menuentry 'CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)' --class centos ...（略）
 
#设置开机从新内核启动
[root@k8s01 ~]# grub2-set-default "CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)"
 
#查看内核启动项
[root@k8s01 ~]# grub2-editenv list
saved_entry=CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)

カーネルを有効にするためにシステムを再起動します

[root@k8s01 ~]# reboot

起動完了後、カーネルのバージョンが更新されているか確認してください

[root@k8s01 ~]# uname -r
4.4.218-1.el7.elrepo.x86_64

ポッド内のDNSが正常に解決されるかテストする

ポッドに入り、ping コマンドを使用して DNS が正常に解決できるかどうかをテストします。

#进入 dnsutils Pod 内部 sh 命令行
[root@k8s01 ~]# kubectl exec -it dnsutils /bin/sh -n kube-system
 
## Ping集群外部，例如这里ping一下百度
/ # ping www.baidu.com
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=1 ttl=127 time=7.20 ms
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=2 ttl=127 time=6.60 ms
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=3 ttl=127 time=6.38 ms
 
#Ping集群内部kube-api的Service地址
/ # ping kubernetes.default
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=2 ttl=64 time=0.051 ms
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=3 ttl=64 time=0.064 ms

ポッド内のドメイン名解決が正常に戻っていることがわかります。

おすすめ

転載: blog.csdn.net/kingu_crimson/article/details/129089906
おすすめ
大規模な言語モデルに基づくオープンソースのナレッジベースの質問と回答システムである MaxKB GitHub Star の数が 5,000 を超えました。
ランキング
短线选股的一种方法
Javaクライアントでのユーバーのリズムワークフローで睡眠時間をキャンセルし、再スケジュール
CALIPSOデータバッチダウンロード方式
LeetCode アルゴリズム再帰クラス - ソードはオファー 26 を参照します。 ツリーの部分構造
HTMLのインポート外部CSS、JavaScriptの論文
PostgreSQL 13.1、12.5、11.10、10.15、9.6.20、および9.5.24がリリースされました
アップルは、エラーメッセージがポテトに接続されていた実行する方法ポテトポテトショーをダウンロードすることができません
あなたは空腹で突然電話を切っていますか？これはテクノロジーの裏側ですか、それともテスト用の銃ですか？
VIMエディタのヒント
動的計画法の最長共通部分列（LCS）
アーカイブ
もっと
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)

コードワールド

© 2018 codetd.com