免責事項:これは英文の記事 「DHCP Lease Renewal Fails in vSphere with Tanzu Environments, Leading to Continuous Pod Recreation」の日本語訳です。
記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。
最新情報は英語版の記事で参照してください。
[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)
VMware vSphere Kubernetes Service 8.0
この問題は、PodVM で使用されている DHCP クライアントコードの既知の問題に起因しています。
初回の IP 取得時、クライアントは DHCP DISCOVER メッセージに Option 61 (Client Identifier) を正しく含めて送信します。
しかし、リース更新時(T1 タイマー経過時)に送信される DHCP REQUEST メッセージには、この Option 61 が含まれません。
この挙動は RFC 2131 (セクション 3.2.1) に違反しているため、厳格な外部 DHCP サーバはこれを不正なクライアントからの要求(IP スプーフィング等)と見なし、DHCP NAK を返却します。
その結果、リースが期限切れとなり Pod が終了します。
現在エンジニアリングはこの問題を認識しており、修正中となります。将来のバージョン Kubernetes (Supervisor) バージョン 1.33 以降 で修正を予定しています。
この問題を回避するには、外部 DHCP サーバ側で Client-ID の検証を無効化し、MAC アドレスのみでクライアントを識別するように設定します。
ignore-client-uids true;
または、ワークロードネットワークで DHCP を使用せず、固定 IP 構成を使用することでも本問題を回避できます。