Kubernetes 1.17の変更点: Known Issues と Urgent Upgrade Notes

はじめに

Kubernetes 1.17 の CHANGELOG から Known Issues と Urgent Upgrade Notesについてまとめます。

Known Issues(既知の問題)

• コンテナがprivilegedなとき、volumeDevicesマッピングが無視されます
• conformance testのShould recreate evicted statefulsetがPod ss-0 expected to be re-created at least onceという理由で失敗します
  • これはPredicate PodFitsHostPorts failedというスケジューリングエラーで、根本原因はホストポートの21017ポートのコンフリクトです
  • このポートはノード上で稼働している他のアプリケーションにより一時的なポートとして既に使用されています
  • この問題は1.18で検討されます
• NewDiscoveryClientForConfigまたはNewDiscoveryClientForConfigOrDieを使って作られたclient-goのdiscovery clientはデフォルトで通常のディスカバリリクエストパターンに数秒かかるレート制限を設定されます
  • これは https://issue.k8s.io/86168 で修正され、v1.17.1で解決されます
  • workaroundとして、Burstの値は、NewDiscoveryClientForConfigまたはNewDiscoveryClientForConfigOrDieに渡されるrest.Configで調整できます

Urgent Upgrade Notes(アップグレード前に確認が必要な注意点)

Cluster Lifecycle

• Kubeadm: 新しいkubelet-finalizeフェーズをinitワークフローの一部として追加され、プライマリのコントロールプレーンノード上のkubeletのクライアント証明書のローテーションを自動化するためのサブフェーズが追加されます - 1.17より前でkubeadm initにより作成された既存のノードでkubeletの証明書のローテーションを望む場合、/etc/kubernetes/kubelet.confをPEMのシンボリックリンクを指すように修正しなければなりません - client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pemおよびclient-key: /var/lib/kubelet/pki/kubelet-client-current.pemを組み込みのクライアント証明書と置き換える必要があります(#84118, @neolit123)

Network

• EndpointSlices: EndpointSlicesが既に有効かされているクラスタをアップグレードする場合、EndpointSlice controllerにより管理されるべきEndpointSlicesはhttp://endpointslice.kubernetes.io/managed-by ラベルをendpointslice-controller.k8s.ioへセットする必要があります
  • ChangeLogにはhttp://endpointslice.kubernetes.io/managed-byとありますが、おそらくendpointslice.kubernetes.io/managed-byだと思われます

Scheduling

• Kubeadm: 追加のapiserverのauthorization-modeを追加する時、デフォルトのNode, RBACは生成されるstatic Podのmanifestへ追加されなくなり、全てをオーバーライドが許可されます (#82616, @ghouscht)
  • デフォルト値が適用されなくなるため、この値を変更によりapiserverに追加のNode,RBACに加えてWebhook等を設定している場合、全て指定する必要がありそうです

Storage

• ブロックボリュームに使用されるパスがこのリリースで変更されたため、ノードのオンラインアップグレードが許可されないず、Kubernetesクラスターをアップグレードする前にすべてのノードをドレインする必要があります(#74026, @mkimuram)

Windows

• WindowsコンテナのRunAsUsername機能がベータとなりました
• Widonws ワーカーノードは既存のWindows Server 2019のサポートに加え、Windows Server version 1903をサポートするようになりました
• RuntimeClassスケジューラーにより、LinuxまたはWindows Podを適切なノードに簡単にステアリングできるようになりました
• すべてのWindowsノードは、WindowsコンテナとWindowsワーカーノードの互換性を一致させるために必要なWindowsのメジャー、マイナー、ビルド番号を反映する新しいラベル node.kubernetes.io/windows-buildを取得します