Edited at

Kubernetes v1.8: 既知の問題 (Known Issues)

More than 1 year has passed since last update.

このエントリは、Kubernetes v1.8 CHANGELOG から既知の問題 (Known Issues) をまとめています。その他の項目は下記リンク先を参照してください。


v1.8.0 リリース時点での既知の問題です。ほとんどは既に v1.8.1 で修正されているため、そちらの CHANGELOG も合わせて参照してください。


kubelet TLS ブートストラップや証明書ローテーションで取得したクライアント証明書がマシンの再起動後に失われる

kubelet の TLS ブートストラップ (--bootstrap-kubeconfig) や証明書のローテーション (--rotate-certificates)で取得したクライアント証明書がマシンの再起動後に失われる問題がある。これは証明書をストアするパスを指定する --cert-dir がデフォルト /var/run/kubernetes となっており、いくつかのプラットフォームでは /var/run 配下は一時的なディレクトリとして再起動で自動的にクリーンアップが実行されるためである。クライアント証明書が失われるため、再起動後に API サーバへの接続に失敗する。

この問題は、--cert-dir を明示的にそのような扱いのないパスに変更することで対応できる。v1.8.1 で修正されておりデフォルト値は /var/lib/kubelet/pki となっている。


kubeadm initkubeadm join/var/lib/kubelet is not empty というメッセージで pre-flight チェックに失敗する

kubelet のクライアント証明書の問題で kubelet の証明書のストア先を /var/lib/kubelet/pki に設定した場合、1.8.0 時点での kubeadm initkubeadm join の pre-flight チェックでは /var/lib/kubelet が空であることを期待して /var/lib/kubelet is not empty というメッセージとともに失敗してしまう。

ワークアラウンドとして下記の対応でこの問題を回避できる。


  • pre-flight チェックでの失敗がこのエラーのみであれば、--skip-preflight-checks=true を指定すること pre-flight チェックを無効化できる

  • init または join コマンドを実行する前に kubelet サービスを停止し、/var/lib/kubelet/pki を削除する

  • init または join コマンドを実行する前に kubeadm reset を実行する

この問題は v1.8.1 で修正されている。


数百のノードから構成される大きなクラスタで数千の Pods の削除が一斉実行されると delete pod API コールのレイテンシが一時的に増大する

数百のノードから構成される大きなクラスタで数千の Pods の削除が同時に実行されると delete pod API コールのサービスレベル目標 (SLO) は1秒に設定されているがそれを超えるレイテンシに増大する。

背景として、Pod の削除はコンテナの停止、ボリュームの削除、cgroups の削除を待って実行されていたが、コンテナの削除を待っていなかったため、以下の条件のどちらかを満たしたときに Pod が削除されるように修正された。


  1. Pod .metadata.deletionTimestamp が設定されており、コンテナが実行されていない

  2. Pod が Eviction された (Phase が Failed であるかつ Reason が Evicted である)



しかし、コンテナの削除は30秒間隔の定期的なガベージコレクションとして実行されていたため、コンテナの削除を待って Pod の削除を行う上記の変更により、Pod の削除が同時に実行されることとなり、大量の Pod の一斉の削除は API サーバの負荷が一時的に増大することとなった。

この問題は v1.8.1 でコンテナの削除を定期的なガベージコレクションではなく、Pod のステータスによって動的に削除を行うように変更することによって修正されている。


Advanced Audit は、API サーバのパフォーマンスと大きなリクエストレスポンスのレイテンシに影響を与える可能性がある

Advanced Audit は、下記の条件を満たすと API サーバのパフォーマンスと大きなリクエストレスポンスのレイテンシに影響を与える可能性がある。

Advanced Audit は設定を誤るととてつもない量のログを出力、送信してしまうため、慎重に設定する必要がある。


minikube v0.22.2 またはそれ以下のバージョンで kubectl v1.8 かそれ以上からの操作で正しく動作しない

minikube の API サーバで登録されていない型が存在するために発生する。新しいバージョンの kubectl では OpenAPI スキーマで強制的にオブジェクトの検証を行うが、minikube の API サーバから配信されている OpenAPI スキーマに必要な全ての型が含まれていなかった。

これは minikube (localkube) のように k8s.io/kubernetes を vendoring している場合とそうでないときでパスが異なるために発生するようだ。この問題は minikube v0.22.3 で修正されている。


GCE デプロイスクリプトでの ENABLE_APISERVER_BASIC_AUDIT パラメータが壊れている

ENABLE_APISERVER_BASIC_AUDIT パラメータは API サーバで旧来の Legacy Audit を有効にするものだったが、1.8 でそもそも Advanced Audit がデフォルトで有効になっているのでこのパラメータは機能しなくなっている。Legacy Audit は廃止されて今後削除予定のため、代わりに Advanced Audit を使いましょう。


kubectl set コマンドが ReplicaSet と DaemonSet で時々バージョンエラーを返す

ReplicaSet と DaemonSet に対する全ての set コマンド(set image を含む set env, set resources, set serviceaccounts)に影響がある。これはパッチを送る際にバージョンを特定するだけの情報を持たない場合に時々エンコーダがバージョンエラーを返していたようだ。

この問題は v1.8.1 で読み込まれたオブジェクトと同じバージョンに最初にエンコードするように修正されている。


Object Count Quotas が他の Quotas と一貫性を持つ請求、更新を行わない

Object Count Quota はオブジェクトが初期化されているかされていないかに関わらず作成された段階で請求される。これは大量の初期化されていないオブジェクトからシステムを守るためにそうなっているが、他の Quotas はオブジェクトが初期化された際に請求されるようになっていおり、一貫性がない。

この問題は今後修正される予定になっている。