vSphere with Tanzu 環境で Pod の DHCP リース更新に失敗し、Pod の再作成が継続的に発生する
search cancel

vSphere with Tanzu 環境で Pod の DHCP リース更新に失敗し、Pod の再作成が継続的に発生する

book

Article ID: 436648

calendar_today

Updated On:

Products

VMware vSphere Kubernetes Service

Issue/Introduction

免責事項:これは英文の記事 「DHCP Lease Renewal Fails in vSphere with Tanzu Environments, Leading to Continuous Pod Recreation」の日本語訳です。
記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。
最新情報は英語版の記事で参照してください。


  • vSphere with Tanzu (VKS) 環境において、cci-ns-controller-manager などの Pod が DHCP IP アドレスのリース更新に失敗します。
  • Pod が Failed ステータスとなり、ReplicaSet による Pod の再作成が無限ループ(Pod Churn)状態に陥ります。
  • 管理コンポーネントが不安定になり、新しいワークロードクラスタ (TKC) のデプロイやコントロールプレーンの更新などの操作が阻害される場合があります。
  • Pod 内部の guest.log に、DHCP サーバからの NAK 応答を示す以下のエラーが記録されます。
    [dhcpv4] received message: DHCPv4 Message
    options:
      DHCP Message Type: NAK
      Message: [requested address not available]
    E0219 HH:MM:SS.mmm 97 dhcp.go:291] failed to perform dhcp request: server rejected request with Nak (msg: requested address not available)
    E0219 HH:MM:SS.mmm 97 dhcp.go:315] dhcp lease expired couldn't renew it: server rejected request with Nak (msg: requested address not available)
    

Environment

VMware vSphere Kubernetes Service 8.0

Cause

この問題は、PodVM で使用されている DHCP クライアントコードの既知の問題に起因しています。
初回の IP 取得時、クライアントは DHCP DISCOVER メッセージに Option 61 (Client Identifier) を正しく含めて送信します。
しかし、リース更新時(T1 タイマー経過時)に送信される DHCP REQUEST メッセージには、この Option 61 が含まれません。
この挙動は RFC 2131 (セクション 3.2.1) に違反しているため、厳格な外部 DHCP サーバはこれを不正なクライアントからの要求(IP スプーフィング等)と見なし、DHCP NAK を返却します。
その結果、リースが期限切れとなり Pod が終了します。

Resolution

現在エンジニアリングはこの問題を認識しており、修正中となります。将来のバージョン Kubernetes (Supervisor) バージョン 1.33 以降 で修正を予定しています。

回避策: 

この問題を回避するには、外部 DHCP サーバ側で Client-ID の検証を無効化し、MAC アドレスのみでクライアントを識別するように設定します。

  • ISC DHCP サーバ (dhcpd) の場合: 対象サブネットの dhcpd.conf に以下の設定を追加します。
    ignore-client-uids true;
  • dnsmasq の場合: dhcp-ignoreid オプションを使用します。

または、ワークロードネットワークで DHCP を使用せず、固定 IP 構成を使用することでも本問題を回避できます。