WG-LTS 復活後の最初のミーティング録画
https://youtu.be/ACIwYWqWESw

• Google / MS / AWS などのベンダー以外にもエンドユーザーの企業からも参加してて、Datadog の人はステートフルなワークロード (データストアかな) 動かしてるから大変で LTS 気になってるらしい
• 現在の Kubernetes のリソースサイクルの話と Go のバージョンやライブラリ、脆弱性対応、コントロールプレーンとノードのバージョンスキュー、コントロールプレーンはマイナーバージョンを飛ばして更新できない話と EoL 過ぎたら脆弱性パッチを提供しない話のおさらい
• Kubernetes のリリースサイクルの影響で現在 Kubernetes を使えてない人は対象なのか
• Kubernetes を使ってない人にリーチするの難しいから最初は Kubernetes 使っている人にサーベイを実施したい
• これまで Kubernetes にいくつか追従を楽にする機能も組み込まれてきた (e.g. PSP みたいに GA 前に消える可能性のある Beta API がデフォルト有効じゃなくなった) が、更新の何が辛いか？
• 過去の WG-LTS の経験上サーベイも良いけど、Google Docs にミーティング参加者がいろいろと辛みなどを非同期で書いてくれると早く進められるので、過去の WG-LTS で決まった内容とかをまとめておく
• 既存のクラスタをあるバージョンに上げるとしてどういう影響があるかをユーザーはプログラム的に知ることができないので辛そう。クラスタ切り替え毎回しろは現実的じゃない。問題を教えるだけじゃなくて適用するとかその先のことも考えたい
• API サーバーのメトリクスや監査ログで次のリリースで消える API 呼び出しを行っているアプリを知ることはできるけど、クラスタ管理者次第なところはある。Pluto とか非推奨 API のチェックツールもある
• 政府関係とかお堅いとこは、まずクラウドベンダーに更新のテストとかさせて承認できたら、外部のベンダーに更新を丸投げするからマイナーバージョンの更新毎にお金を払わないといけない
• 今でもコントロールプレーンの更新は実行中のワークロードに影響しないので、コントロールプレーンを 3 マイナーバージョン上げてからノードを一気にあげるはできる
• etcd にデータは保存されていて互換性はあるので、コントロールプレーンが使えない時間が出来ても良いなら、コントロールプレーンのコンポーネントを全て停止してからバージョン飛ばしで更新することもできる
• 3 マイナーバージョン一気に上げたとして、その間に削除された API バージョンがあるとどうなるの？削除された API のデータは etcd に保存されているから api-server は読み取って conversion してくれる (storage migration)
• コントロールプレーンを 3 マイナーバージョン一気に更新した時に困るのはロールバックが辛いこと。etcd のバックアップとリストアは必須。etcd のデータはそのままで 1 マイナーバージョン戻しは実装上可能だし、テストでもカバーしてたはず。3 マイナーバージョン更新は半半で成功すると思うが、壊れたときに何が影響したかを探すのは大変。保存する前のデータのバリデーションが厳しくなって古い現バージョンだと不正なデータを更新できなくなる可能性はある

[WG-LTS] Safer Kubernetes Upgrades の日本語訳です。dev@kubernetes.io の Google Groups へ参加しないと中身を確認できません。

背景

TLDR; クラスタ更新に関する推奨事項は、理想よりも緩くし、より具体的かつある程度の制約を課すべき。

現在、Kubernetes の更新は運用者に限った作業である。OSS の Kubernetes だとバージョンスキューポリシーで更新の流れについて軽く触れている。最善を尽くしてはいるが、更新の流れは時にポリシーに違反することがある。

バージョンスキューポリシーは許容できる更新順の境界だと考えることもできる。例えば、確実な更新順 (Webhook → api-server → controller-manager / scheduler / cloud-controller-manager → kubelet → kube-proxy) を定義しているが、それぞれのステップの要件と矛盾する部分もある。例えば、controller-manager / scheduler / cloud-controller-manager の更新は順不同で良く、api-server の後に更新するべきであることを明言している。しかし、kubelet の更新順は “kubelet が通信する kube-apiserver のインスタンスは 1.28 である” という 1 つの制約しか定義していない。controller-manager や scheduler と比べて kubelet は原則として順不同で (安全に) 更新できることを示唆している。

更新に関するドキュメントの曖昧さをなくし、安全なクラスタの更新方法をより具体化かつある程度の制約を課せば、Kubernetes やクラスタの管理者はより良いサービスを提供できるだろう。

Feature Flags の再考

TLDR; 動的な Feature Flags は更新をより安全にする。

ここしばらく @lavalamp が安全な更新順に繋がる可能性のある Feature Flags に対する興味深い変更を提案してきた。彼の提案の要点は Feature Flags を動的にすることである。コントロールプレーンのバージョンを N+1 に更新する一方で、Feature Flags は N (現バージョン) と互換性のある状態を維持する。更新のライフサイクルのフックの仕組みを使って、N+1 でデフォルト有効化された Feature Flags のみを有効化する。この追加のステップが更新順の粒度を高め、(1) 問題をより簡単に特定できる (より細いステップを踏むことになるので、更新のライフサイクのどこで問題が起きたかが完全に把握できる) し、(2) 問題をより簡単に自動切り戻しできる (更新をより細かく徐々に進めていけるので、問題を大きく切り戻す必要がない)

Kubernetes をより細かいステップで更新することには別の魅力もある。Kubernetes のコントロールプレーンの更新の進め方がより厳格になり、潜在的に壊れる可能性のあるデータ (N には存在せず、N+1 にのみ存在するデータ) の導入を更新作業の後半に追いやることができる。

動的の課題

Feature Gates (Feature Flags) を完全に動的にすることについてこれまで書いてきたが、障壁がある。api-server への接続なしで、コンポーネントの起動時に有効化される Feature Gates がいくつか存在することだ。 この問題は主に kubelet に集中している。なぜなら、kubelet が static Pods (e.g. api-server) の管理に責任を持っているため、api-server は kubelet の起動時に利用できない可能性がある。更に、これらの機能は一般的に初期化を先延ばしにせず、コンポーネントの起動の中でも重要な部分である。つまり、Feature Gates がローカルの状態 (Feature Gate の処理が入っているコンポーネントのコード) からすぐに有効化される。

完全に動的なシステムに移行する場合、2 つの Source of Truth を持つことになるので問題だ。Feature Flags が起動フローの一部でないようにコンポーネントの初期化を書き換えることもできるが、非常に膨大な作業である。コントロールプレーンのコンポーネントごとに初期化ロジックを大きく書き換える必要が出てくる。

戦略的な最初の一歩 / 中間の状態の提案

TLDR; 静的な Feature Flags で動的な Feature Flags をエミュレートする。

最初の一歩としてできることは、Feature Flags の構造体に情報を追加することだ。Feature Flags が昇格したバージョンやデフォルトで有効化されるようになったバージョンを記録する。api-server への接続がなくても、どの Feature Flags を N もしくは N-1 で有効にすべきか特定できる。各コンポーネントの初期化の実装を書き換えることなく起動することができる。

これを実現するために、コンポーネントが起動時にどの Feature Flags で初期化されるべきかを指定する引数を追加する。つまり、そのコンポーネントが互換性のある Kubernetes のバージョンと互換性があるべきかを指定する。(e.g. —compatibility-version=v1.28)

ここでいう「バージョン互換性」とは、N+1 のコンポーネントが Feature Flags が N と互換性のあるモードで起動したことを意味する。コンポーネントが N+1 のバージョンで起動した時の Feature Flags と、N のバージョンで有効になった既存の Feature Flags を一致させたい。更新の残りの部分が正常に完了した後に、更新のライフサイクルのフックの仕組みの中で新しい機能を有効にして再度コンポーネントを起動する。

別の言い方をすると、バージョン N の api-server でデフォルト有効になっている機能 A, B, C があるとする。バージョン N+1 への更新時に、機能 D が N+1 でベータに昇格し、デフォルトで有効になるべきであっても、コンポーネントが A, B, C を有効にした状態で再起動したい。代わりに、更新のライフサイクルの正しい部分でフックを使用して機能 D を有効にすべきだ。

更新にもたらす利点に加えて、この分離は複数のクラスタに渡って一貫した互換性バージョンを提供しやすくする。クラスタ管理者に分離されたバージョンを提供できるため、マルチクラスタ管理がより安全になる。

影響

既存のコンポーネントのバージョン番号 (e.g. ServerVersion) が 2 つのバージョンに分割される。

• バイナリのバージョン
• 互換性バージョン

クラスタの API が互換性バージョンによって決定され、クラスタの利用者が気にかけることになる。バイナリのバージョンはクラスタの管理者が気に掛けることになる。

現在のコンポーネントのバージョンの公開方法や使い方を変えなければならない。例えば、kubectl version コマンドで表示される ServerVersion の意味は曖昧になり、バイナリのバージョンと互換性バージョンの情報をどちらも表示するように変更しないといけない。

幅広い更新方法が可能になる。

• バージョン N-1 と互換性を維持しなくて良いクラスタに対して、今よりも 1 リリース早く機能を有効化できる。(全ての N-1 のサーバが更新され、管理者が 1.N バイナリを —compatibility-version=1.N で実行した場合)
• 逆に、機能の有効化が遅れるのを許容するなら、バージョン更新のスキップ時に完全なダウングレードが可能なように維持することもできる。つまり、クラスタは N から N+3 に一気にバージョンを更新し、—compatibility-version を常に N-3 に設定する。このようなクラスタは、互換性バージョンが常にバイナリのバージョンよりも N-3 遅れている互換性バージョンになる。
• さらに、クラスタ管理者は、まずバイナリのバージョンのみを更新し、一定期間クラスタを運用してから、準備ができたら互換性バージョンを更新し、必要に応じて何段階でも更新できる。つまり、N から N+3 に一気にバイナリのバージョンを更新した後に、3 つの段階的な互換性バージョンの更新を続けることができる。

また、互換性バージョンを変更せずに、特定のバイナリのバージョンのバグを回避するために更新 / 切り戻しもできる。

Conformance テストは互換性バージョンに適用される。バイナリのバージョンは、サポートするすべての互換性バージョンに対して Conformance テストを行う必要がある。

非推奨または削除される機能は Feature Gate で制御され、削除されるバージョンをコントロールするために —compatibility-version を設定する必要がある。

なお、Golang と Rust は、ツールチェインバージョンを互換性バージョンから分離している。この提案も同様の目標、特性、利点を持っている。

変更案

• 追加の情報を追跡できるように Feature Gates の登録を拡張する。
• Feature Gates 周りのポリシーを変更する。これにより、Feature Gate を確認するコードを GA 後の 3 バージョンは残し、機能できるようにする。(Feature Gates が最も古い Kubernetes のサポートバージョンでも動作することを保証する。)
  • 可能性
    • Feature Gates が残っているかのチェックを GA, GA+1, GA+2, GA+3 のリリースまで行う
    • LockToDefault の有効化は GA+3 まで行わない
  • GA 後の 2 バージョンだと問題が起きるかも。
• それぞれのコンポーネントにフラグを追加して、互換性バージョンを指定可能に。(デフォルトの Feature Gates を制御するためのもの)
• featuregate.go に機能を追加する。バージョン N で有効な機能の一覧を計算できるようにする。
• /version エンドポイントと kubectl version でバイナリのバージョンと互換性バージョンの両方を返すようにする。
• バイナリのバージョンと互換性バージョンをコンポーネントの ID に含める (api-server の ID が現在あるが、コントロールプレーンのそれ以外のコンポーネントの ID も将来的に公開する。)
• Feature Gate の動作に互換性バージョンを使う。現在 N-1 の互換性バージョンとしてハードコードされている。網羅できていないが例えば、
  • etcd の新しい API や動作の信頼性 (e.g. etcd の互換性)
  • API 検証を 2 バージョンに渡って緩和
  • 新しい CEL の変数やライブラリの導入
• HA 構成のコントロールプレーンの更新時など異なるバージョンの api-server がいる場合のプロキシに互換性バージョンの情報を使う (Unknown Version Interoperability Proxy (UVIP) の次の改善でやる)
• Feature Gate で守られている機能の非推奨 / 削除のプロセスを導入する。互換性バージョンに非推奨 / 削除される機能を紐付ける。

考慮した代替案

• Feature Flags を静的と動的に分割することを検討した。静的な Feature Flags はコンポーネントの起動時に使われ、api-server によって動的に設定される Feature Flags もある。このやり方には以下の問題がある。
  • N と互換性を持ちながら N+1 にコンポーネントを更新が難しい。更新の間コンポーネントに引数を渡すなどする必要がある。例えば、N と互換性のある静的な Feature Flags の一覧 (N のバージョンでデフォルト有効化されている全ての Feature Flags) を引数として渡し、コンポーネントを再起動して今度は N+1 と互換性のある静的な Feature Flags を渡さないと行けない。その後で N+1 と互換性のある動的な Feature Flags を有効化する。
  • 複数の種類の Feature Flags を処理する必要があり、混乱する。
• 完全に動的なやり方も検討したが、コンポーネントの起動処理の大部分を書き換えないといけない。

Kubernetes Upgrade Friction Log

Kubernetes Upgrade Friction Log の日本語訳です。

このドキュメントは何かと書き方

Kubernetes の更新プロセスのユーザー体験についてフィードバックを収集したい。

自身の体験を追加する場合は、ズレ / 体験談のセクションを埋める、可能なら以下の点を含めること。

• 名前 / メールアドレス / Kubernetes の Slack のハンドル名 (追加の質問のため)
• 問題が起きたマイナーバージョン
• それ以降のマイナーバージョンだと良かった / ダメだった / 同じ / まだ試していない
• マネージドクラウドプロバイダなどの環境の情報があれば
• メトリクスや定量的なデータがあれば (X% 失敗、Y% 影響を受けた、Z% は N ヶ月遅れたなど)
• 他の外部的要因

部分的にでも更新の体験を良くするために直近で導入した機能強化も記載している。これらの変更によって状況がどの程度改善したかも答えてくれ。

体験を良くするためのこれまでの動き

Kubernetes プロジェクトが機能強化をまとめたものである。これらはエンドユーザーや更新の体験に良い影響を与える可能性がある。

• 2019: Kubernetes 1.17 から 12+ ヶ月のサポート開始
  • KEP-1498
  • リリースの頻度が 1 年に 4 回から 3 回に変更
  • サポート期間が 9 ヶ月から最長 14 ヶ月 (12 ヶ月 + 2 ヶ月) に変更
  • 1 年に 1 度の更新が可能に / パッチリリースを受けながら 1 年間同じマイナーバージョンに居座り続けられる
• 2020: Kubernetes 1.19 からクラスタを機能させるのに必要な API が全て GA
  • KEP-1333
  • 新しい API は GA に卒業するまで Conformance テストなどで要求されなくなった
• 2020: Kubernetes 1.19 から非推奨な API が呼び出されている場合に、Warning ヘッダー、メトリクス、監査アノテーション ("k8s.io/deprecated": "true") が記録される
  • KEP-1693
  • Warning: Helpful Warnings Ahead - Metrics
  • クラスタ管理者は削除される前の API が定期的に呼び出されているクラスタの更新を回避するために、更新前の保護としてメトリクスや監査ログを使用できる
• 2020: Kubernetes 1.19 から Production Readiness レビューが KEP の中で必須に
  • KEP-1194
  • 更新や互換性、デフォルトの挙動を変更するか、監視などの情報をまとめる必要がある
• 2022: 非推奨ポリシーを更新して安定化した API バージョンが消されないように変更
  • Modify the deprecation policy to disallow removal of stable API versions
  • 安定した API を使用するアプリケーションやクライアントは将来の全ての Kubernetes 1.x バージョンで引き続き API を呼び出せる
  • (Kubernetes は安定化した API バージョンを消すことはそれ以前もなかったが、ポリシーに明文化された)
• 2022: Kubernetes 1.24 から安定化するまで新しい API は有効化されないように
  • KEP-3136
  • 新しい不安定な API (Beta API) はデフォルトで無効化
  • 1.24 以前に導入されたデフォルト有効化の Beta API は非推奨または削除されるまでそのままだが、その数は劇的に減っていて、現在は flowcontrol の Beta API だけ
    • 1.16: 12 個の Beta API が 削除され、26 個の Beta API がデフォルト有効化
    • 1.22: 23 個の Beta API が削除され、11 個の Beta API がデフォルト有効化
    • 1.25: 7 個の Beta API が削除され、6 個の Beta API がデフォルト有効化
    • 1.26: 3 個の Beta API が削除され、5 個の Beta API がデフォルト有効化
    • 1.27: 1 個の Beta API が削除され、4 個の Beta API がデフォルト有効化
    • 1.29: 2 個の Beta API が削除され、2 個の Beta API がデフォルト有効化
    • 1.32: 2 個の Beta API が削除され、0 個の Beta API がデフォルト有効化
• 2023: Kubernetes 1.23 からリリースブランチが Go のサポートバージョンを使用するように
  • 2023/1 から Kubernetes 1.23 以降の全てのパッチリリースが最新の Go の脆弱性修正を含んだサポートバージョンを使用するように
  • KEP-3744
  • Keeping Kubernetes Secure with Updated Go Versions
• 2023: Kubernetes 1.28 からコントロールプレーンが n-3 のノードのバージョンで動作
  • KEP-3935
  • 更新されたバージョンスキューポリシー
  • 1.25 のノードが 1.28 のコントロールプレーンをサポート
  • 1 年に 1 度更新する場合にノードのバージョン一気に更新できる (ノードがバージョンをスキップできる)

ズレ / 体験談

[Scott Dodson] ケース 1

リリースが EoL に近づくにつれて、依存関係の長い連鎖や不十分な計画に苛まれる。例えば、直近だと 2023 年 5 月に、ERP ソリューションと Envoy 1.20 で問題が起きたと顧客から報告を受けた。ERP の提供元は 2023 年の 11 月に修正をリリースすると言っている。これにより、2023 年 11 月までは Istio 1.12 より上のバージョンに更新できず、Kubernetes クラスタも 1.22 (OpenShift EUS バージョン 4.8) より上のバージョンに更新できない。これはある意味、Kubernetes バージョンのサポートのライフサイクルが長くなった結果かもしれない。顧客は異なるバージョンの環境を “認証” する必要があるのは稀だと考えているからだ。顧客が継続的にやっていくこととして取り組んでいたなら、この問題に 8 ヶ月以上も前から気付いていただろう。LTS のバージョンを導入することで頻度を少なくするのであれば、トレードオフの一部としてエコシステム全体がより早くバージョン更新に備えるように動機付ける方法を見つける必要がありそうだ。

[Joe Huang] ケース 2

一部の規制業界ではバージョン更新をスキップしている。

• バージョン更新のスキップとは、コントロールプレーンとワーカーノードの両方で、Kubernetes のマイナーバージョンの更新 / 切り戻しを 1 つずつではなく飛ばして行っている。
• Kubernetes のディストリビューションが各マイナーバージョンを顧客に提供するコストは高く、各マイナーバージョンはそれぞれのリリースサイクルを辿ることになる。
  • 数週間から数ヶ月を掛けて、新しいバージョンが十分にセキュアで安定しているかを確認・テストし、ディストリビューションに組み込んでいる。
  • 本番システムで動作しているアプリケーションが新しいディストリビューションに対応しているかどうかをテストしている。テストには機能やパフォーマンス、信頼性、セキュリティ周りを含む。ディストリビューションとアプリケーションが異なるベンダーから提供されていると、互換性のテストは数週間から数ヶ月掛かり、調整が難しい。
  • 本番システムの Kubernetes のディストリビューションを更新する前に認証テストを実行する必要がある。認証は Kubernetes ディストリビューションの細部まで行う必要があり、コントロールプレーンだけとかではない。Kubernetes でスキューポリシーが守られていても、コントロールプレーンとワーカーノードのそれぞれのバージョンの組み合わせを認証のために顧客に提供する必要がある。例えば、Kubernetes 1.28+ でコントロールプレーンが n-3 のワーカーノードに対応したので、1.28 コントロールプレーン + 1.25 ワーカーノード、1.28 コントロールプレーン + 1.26 ワーカーノード、1.28 コントロールプレーン + 1.27 ワーカーノード、1.28 コントロールプレーン + 1.28 ワーカーノードの組み合わせがある。
  • 顧客は Kubernetes ディストリビューションの認証以外のアプリケーションの互換性テストを実施する。
• 本番システムで動作しているアプリケーションが新しい Kubernetes のディストリビューションと互換性がない場合、まずアプリケーションを更新しなければならない。アプリケーションが古いバージョンと新しいバージョンの両方に互換性がある状態にする必要がある。アプリケーションの準備ができてから、Kubernetes を新しいバージョンに更新する。
• 顧客にとってアプリケーションはコアバリューであり、顧客は新しい機能をエンドユーザーに届けるためにより頻繁にアプリケーションを更新することには意欲がある。エンドユーザーに新しい機能を届けない Kubernetes を更新するだけの作業を頻繁に行うことはあまり望んでいない。
• 基幹業務用のアプリケーションは、国によってはサービスの SLA が政府によって監視されており、サービスが停止すると莫大な罰金が課せられる可能性がある。そのため、全てのアプリケーション / Kubernetes を全ての場所で一晩のうちに更新することはできず、障害のリスクを考慮して分散する必要がある。
• ディストリビューションを更新するために、何百もの場所にある Kubernetes インスタンスを更新しなければならない。Kubernetes のマイナーバージョンを毎回更新するなら、ほぼ毎日更新作業に追われることになる。(リスクを避けるために、並列してそれぞれの場所にある Kubernetes インスタンスを更新はできない。) これは多くの不満を生み、通常は許容されない。

以上より、ほとんどの更新がコントロールプレーンとワーカーノードの両方のマイナーバージョンを飛ばす方法で行われる。

2023/9/12 WG-LTS ミーティング
https://www.youtube.com/watch?v=rTjbBShbMzI

• ユーザーアンケートの内容について
  • サービスで新しい機能をリリースするサイクルはどのくらいが望ましいか？
  • 新しい機能の追加も止まるような 1 ヶ月以上のコードフリーズ期間はあるか？どのくらいの間隔でコードフリーズが発動するか？
  • 本番環境に反映する前に、サービスの新しい機能をテストするのにどれくらい時間が掛かるか？
  • upstream の Kubernetes がリリースされてから、サードパーティ製品が互換性対応するまでにどれくらいの時間差があるか？
  • Kubernetes の周辺エコシステムをどうやって更新しているか？
  • クラスタの更新は全く行わないのか？
    • クラスタの更新を妨げている要因は何か？
    • 更新しないなら、脆弱性修正の反映にどう対応しているか？EOL 過ぎてもずっと同じバージョンに居続けるの？
    • クラスタを更新する時は、パッチバージョンの更新かマイナーバージョンの更新か？
    • マイナーバージョンの更新で動作上の破壊的変更が入り、それが原因で更新できなくなった経験はあるか？
  • クラスタ更新に掛かる時間は？
    • 新しいバージョンのテストに掛かる時間は？
    • dev / stg / prd 環境等へのロールアウトに掛かる時間は？
  • マイナーバージョンの更新でリグレッションも機能の非推奨化も機能の削除もなければ更新できるか？
    • それでも更新が難しい場合は、どのプロセス (e.g. 新しいバージョンの検証、新しいバージョンへの更新の承認) に時間が掛かるのか？
    • それで更新ができるなら古いバージョンに居座れるように LTS を作るのに意味があるかも
  • 更新しても何も壊れないことを事前にツールなどで知らせてくれると良いかも？
    • 更新する前に Kubernetes が「更新しても大丈夫、嘘じゃないよ」って言ってくれたら更新ボタン押せそう
    • Beta API がデフォルトで有効にならなくなったり以前より安全にはなっている
    • Safer Kubernetes Upgrade で提案している互換性モードも似たような狙い
    • 次のバージョンで破壊的変更の影響を受けることが事前に分かるメトリクスの追加も最近はやっていていい感じ
    • 非推奨 API の警告ログやメトリクスの結果を良い感じにまとめて報告してくれる何かがあると便利そう
      • e.g.) Istio がクラスタにインストールされているようなので、これとこれとこれに注意してねとか
      • e.g.) マルチクラスタ環境でこのクラスタだけ他のクラスタと設定が違うから注意してねとか
    • 簡単ではないし、難しくて無理だろうけど、更新すると壊れることを知らせてくれるツールを作るのが有用そう
  • 既にいない過去のクラスタ管理者が残したコンポーネントがクラスタ内に残っていてどう対処して良いか分からない話もよく聞く
  • マルチテナント環境だと多くのステークホルダーがいるのでちゃんと非推奨 API 対応が終わったか確認や調整に時間が掛かる
  • 銀行系の顧客で 2 年に 1 回更新しているところがあって、一気に 6 バージョン上げようとするけど、そういう場合は新しくクラスタを作成して移行することを推奨している
  • 1.28 で initContainers の起動順が保証されないリグレッションが起きていたり、完全なリリースは存在しない
  • 2 年に 1 度しか Kubernetes のバージョンを更新しない顧客がいて、マイナーバージョンを飛ばさずに順番に更新していくのが大変
• ユーザーアンケートの実施時期とアナウンス方法、質問の仕方
  • KubeCon NA に間に合うと良さそうなのと、ブログ記事も準備する予定
  • リリースノートの先頭にユーザーアンケートのリンクを貼る案
  • この機能が欲しいですか？で質問しちゃうと全部欲しいになるから、10 個のうち 3 個しか選べないとか優先度が分かる形にしたい
  • サポート期間を 1 年+ で延長するとして、その期間をユーザーがどう使うかははっきりさせたい、ユーザー側が何も変わる気がないなら延長したくない
  • クラスタ移行による更新も良い手段なので 1 年に 1 回は無理でも 2 年に 1 回はできるようにするのが良いかもしれない
  • 人間は不満を言うのが好きなので、自由記入欄で何が最悪かを書かせても良いかもしれない
    • 自由記入に記載された文章を全部読まないでも、テーマを抽出するのは以前より楽になってるはず
    • 自分たちが気付いていないことを知るのにも自由記入は良いし、俺が考えた最強の Kubernetes 更新みたいなのも書かせても良いかも