Kubernetes には LTS がありますか?

興味深い質問は、多くの人が懸念している Kubernetes LTS の問題につながります。

興味深い質問ですね

2019年には、「apiserver LoopbackClient Server cert expired after 1 year[1]」という問題が提起され、興味深い問題が指摘されました。 kube-apiserver が 1 年間再起動されていない場合、kube-apiserver は正常に動作しなくなります。

問題の作成者は、自分の場所の理由を次のように説明しました: kube-apiserver は自己署名された LoopbackClient 証明書を更新しませんでした。以下のコードから、証明書の有効期限が 1 年に設定されていることがわかります。

 // create self-signed cert+key with the fake server.LoopbackClientServerNameOverride and // let the server return it when the loopback client connects. certPem, keyPem, err := certutil.GenerateSelfSignedCertKey(server.LoopbackClientServerNameOverride, nil, nil) if err != nil { return fmt.Errorf("failed to generate self-signed certificate for loopback connection: %v", err) } certProvider, err := dynamiccertificates.NewStaticSNICertKeyContent("self-signed loopback", certPem, keyPem, server.LoopbackClientServerNameOverride) if err != nil { return fmt.Errorf("failed to generate self-signed certificate for loopback connection: %v", err) } --- // GenerateSelfSignedCertKeyWithFixtures creates a self-signed certificate and key for the given host. // Host may be an IP or a DNS name. You may also specify additional subject alt names (either ip or dns names) // for the certificate. // // If fixtureDirectory is non-empty, it is a directory path which can contain pre-generated certs. The format is: // <host>_<ip>-<ip>_<alternateDNS>-<alternateDNS>.crt // <host>_<ip>-<ip>_<alternateDNS>-<alternateDNS>.key // Certs/keys not existing in that directory are created. func GenerateSelfSignedCertKeyWithFixtures(host string, alternateIPs []net.IP, alternateDNS []string, fixtureDirectory string) ([]byte, []byte, error) { validFrom := time.Now().Add(-time.Hour) // valid an hour earlier to avoid flakes due to clock skew maxAge := time.Hour * 24 * 365 // one year self-signed certs

注: LoopbackClient は、kube-apiserver が自身にアクセスするために使用されます。例えば、kube-apiserver を起動する際には Service や EndPoint (AA で使用) などの情報を取得する必要があるため、この LoopbackClient が使用されます。

また、クラスターに関連する証明書の有効期限を確認する方法も提供します。 kube-apiserver を再起動すると、この問題を一時的に解決できます。

 # replace {Master_IP} with your master IP and 6443 with your apiserver port curl --resolve apiserver-loopback-client:6443:{Master_IP} -k -v https://apiserver-loopback-client:6443/healthz root@kind-control-plane:/# curl --resolve apiserver-loopback-client:6443:172.17.0.2 -k -v https://apiserver-loopback-client:6443/healthz * Added apiserver-loopback-client:6443:172.17.0.2 to DNS cache * Hostname apiserver-loopback-client was found in DNS cache * Trying 172.17.0.2:6443... * TCP_NODELAY set * Connected to apiserver-loopback-client (172.17.0.2) port 6443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Request CERT (13): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=apiserver-loopback-client@1577103676 * start date: Dec 23 11:21:16 2019 GMT * expire date: Dec 22 11:21:16 2020 GMT * issuer: CN=apiserver-loopback-client-ca@1577103676 * SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x55d565d9c1d0) > GET /healthz HTTP/2 > Host: apiserver-loopback-client:6443 > User-Agent: curl/7.65.3 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 250)! < HTTP/2 200 < cache-control: no-cache, private < content-type: text/plain; charset=utf-8 < x-content-type-options: nosniff < content-length: 2 < date: Wed, 23 Dec 2020 14:29:30 GMT < * Connection #0 to host apiserver-loopback-client left intact

機能かバグか?

この問題が発生する可能性は比較的低いです。 kube-apiserver は、トリガーされる前に 1 年間継続的に実行する必要があります。もちろん、サーバーの時間を 1 年後に設定することで、すぐに再発させることもできます。

コミュニティのリーダーたちも反応した。当時、k8s は 3 か月ごとにマイナー バージョンをリリースし、「N-2 サポート ポリシー」に従っていました。つまり、最新の 3 つのマイナー バージョン (N、N-1、N-2) のみがセキュリティとバグの修正を受けることになります。つまり、クラスター管理者がコミュニティの仕様に従って k8s クラスターを管理する場合、1 年以上実行される k8s コンポーネントは存在せず、この問題は発生しません。

写真

また、サポート対象期間を9か月から12～14か月に延長する新たな提案が議論されているとも言及されましたが、当時は単なる提案に過ぎませんでした。最終的に、この問題はバグとはみなされず、今日に至るまでコミュニティ バージョンには 1 年の有効期限がハードコードされたままになっています。

驚くべきことに、この問題が上で言及されてから4年が経った今日、この問題をオンラインで検索すると、この問題がAlibaba Cloudの公式ウェブサイトのドキュメントにも言及されていることがわかります[2]

APIサーバーはACKクラスターコントロールプレーンの中核コンポーネントであり、内部LoopbackClient[3]サーバー用の証明書が組み込まれています。コミュニティバージョン[4]では証明書の有効期間は1年間で、自動的にローテーションすることはできません。 API サーバー ポッドが再起動された場合にのみ、自動的にローテーションおよび更新されます。コミュニティでは、この証明書の有効期間を延長する予定はありません。詳細については、#86552 を参照してください。

Container Service for Kubernetes は、さまざまなユーザーの操作およびメンテナンスの習慣を考慮して、最近、組み込み証明書のデフォルトの有効期限を調整し、変更後の有効期間は 10 年になりました。

インパクト

API サーバーの組み込み LoopbackClient 証明書の有効期間は、ACK 管理クラスターおよび ACK 専用クラスターの場合 1 年です。

• 2023 年 3 月 15 日より前に作成された ACK クラスターの場合、API サーバーの組み込み LoopbackClient 証明書の有効期間は 1 年です。
• 2023 年 3 月 15 日以降に新規作成された、またはバージョン 1.20.11 以上にアップグレードされた ACK クラスターの場合、API サーバーの組み込み LoopbackClient 証明書の有効期間は 10 年であり、影響を受けません。

Alibaba Cloud のドキュメントには、2023 年 3 月 15 日以降のバージョンでは証明書の有効期間が 10 年に設定されていると記載されており、これは Alibaba Cloud が実際にソースコードのこの部分を変更したことを意味します。そして最後に彼はこんな一文を付け加えた。

重要: 短期間でアップグレードできない ACK プライベート クラスターの場合は、クラスターのすべてのマスター ノードにログインし、API サーバーを手動で再起動してください。

中国最大のパブリッククラウドベンダーである Alibaba Cloud は、この問題を解決するために最終的にコードを修正する必要がありました。これは間接的に別の問題も示しています。すでに2023年（当時）であるにもかかわらず、多くの企業は依然として、公式にサポートされているバージョンから大きく遅れたk8sバージョンを使用しています。 1 年以上稼働しているクラスターや、もうすぐ 1 年を超えそうなクラスターもあります。 Alibaba Cloud の安定性 (再起動せずに 1 年間 k8s を実行できるほど) を喜ぶべきか、それとも 4 年前の問題が 4 年経ってようやく皆の注目を集めるようになったと感じるべきか、私にはわかりません。素晴らしいし面白い〜

Kubernetes の最新バージョン

このような複雑なシステムでは、初期サポート期間は 1 年未満であり、ユーザーは毎年アップグレードする必要があります。各アップグレードの作業負荷は膨大であり、ユーザーの精神的苦痛となることは間違いありません。結果から判断すると、使用中にコミュニティの規範を完全に遵守していないユーザーが確かに多く存在します。

提案1498-kubernetes-yearly-support-period[5]が承認された後、k8sバージョンのサポート期間は9か月から14か月に調整され、12か月のサポート期間と2か月のアップグレードサイクルが含まれます。 v1.19 はこの処理を享受する最初のバージョンです。提案KEP-2572: Kubernetesリリースケイデンスの定義[6]が承認された後、2020年には（COVID-19パンデミックの影響もあり）、リリース（マイナー）サイクルが年4回から年3回に調整されました。 v1.22 はこのペースでリリースされる最初のバージョンです。

写真

• 最初の 12 か月間のサポート ポリシー。

現在の 9 か月ポリシーと同じです。

• 最終の+2 か月間のサポート ポリシー。

• 製品セキュリティ委員会によって割り当てられた CVE は、製品セキュリティ委員会によってリリース ブランチに開始されます。

• アップグレードシナリオのバグ修正の厳選が、所有SIGとパッチリリースチームによって承認されました

• 重要なセキュリティ パッチとアップグレードをブロックする修正のみ。例:

しかし、結果から判断すると、9であろうと14であろうと、この時間はまだユーザーにとって十分な長さではありません（そうでなければ、Alibaba Cloudは2023年に上記の質問を具体的に提起する必要はなかったでしょう）。多くの Linux ディストリビューションの LTS と比較すると、この時間はかなり短いです。

人々はオンラインで意見を述べています。「KubernetesにLTSが必要なのはなぜですか？」[7]

理由は次のとおりです。

まず、Kubernetes はさまざまなコンポーネントとモジュールで構成される複雑なコンテナ オーケストレーション システムです。これらのコンポーネントとモジュールは、セキュリティと安定性を確保するために継続的なメンテナンスと更新が必要です。 LTS バージョンを提供することで、ユーザーに安定した基盤を提供し、頻繁にアップグレードすることなく Kubernetes を長期的に使用できるようになります。

2 番目に、多くの組織は Kubernetes を使用する際に複雑なアプリケーションとインフラストラクチャを構築します。これらのアプリケーションとインフラストラクチャは、Kubernetes の特定のバージョンに依存している可能性があり、新しいバージョンで実行するには広範なテストと検証が必要になる場合があります。 LTS リリースを提供することで、これらの組織は、新しいバージョンへのアップグレードによって生じる非互換性や障害を心配することなく、アプリケーションとインフラストラクチャの安定性を長期にわたって維持できることが保証されます。

さらに、多くの組織はコンプライアンスや規制の要件に直面する可能性があります。これらの要件により、ソフトウェアの特定のバージョンを使用し、そのバージョンを一定期間サポートし続けることが求められる場合があります。 LTS リリースを提供することで、Kubernetes はこれらのコンプライアンスと規制の要件を満たすことができ、組織は規制違反を心配することなく、自社の環境で Kubernetes を使用できるようになります。

最後に、大規模なアップグレードや移行を行う余裕のない組織の場合、LTS リリースにより、より長い期間のサポートと安定性を提供できます。これらの組織には、アプリケーションとインフラストラクチャを頻繁にアップグレードおよび移行するためのリソースと時間がない可能性があります。 Kubernetes は LTS リリースを提供することで、頻繁なアップグレードのリスクとコストを負担することなく、これらの組織がシステムの安定性と信頼性を維持するのに役立ちます。

コミュニティは 2019 年 2 月に LTS ワーキング グループを設立し、上記の最初の提案が関連する成果物となりました。ワーキンググループは最終的に 2020 年 10 月に終了しました。LTS の必要性は 2023 年 4 月まで再評価されず、LTS ワーキンググループは 7 月に正式に再開されました。これまでのところ、実質的な進展はありません。詳細についてはSlack[8]またはGoogleセッション[9]を参照してください。

拡大する

公式のLTSワーキンググループは大きな進展を遂げていませんが、DaoCloudには歴史的なk8sバージョンの維持に特化したプロジェクトがあり、klts[10]を参照。これは主にCVEと重大な問題に焦点を当てています。

• プルリクエスト後にチェリーピック承認されマージされたCVE[10]
• 最近発見され修正されたCVE[11]
• 最近cve.orgで発見されリストされたKubernetes関連のCVE[12]

要約する

k8s の 14 か月のメンテナンス サイクルでは、明らかに多くのユーザーのニーズを満たすことはできません。コミュニティもこの問題を認識しており、専用の LTS ワーキング グループがフォローアップを行っています。近い将来、Kubernetes LTS の実装が見られるかもしれません。

最後にもう少しだけ言わせていただきます。どのバージョンを使用するか、アップグレードするかどうか、いつアップグレードするかを選択する際に絶対的な正解や不正解はありません。あなたに合うものが一番です。役割が逆転して、プレーヤーからプレーヤーに変わることに注意しましょう。しかし、何があっても、自分が責任を負っている事柄については絶対的なコントロールを持たなければなりません。特定の技術的概念をめぐる、いくつかの公開アカウント間の論争（相互攻撃）についても同様です。純粋にイデオロギー的な議論は、具体的な作業を導く上であまり意味を持ちません。そこに含まれる概念のいくつかは非常に優れており、人々に受け入れられやすいことは否定できませんが、重要なことは、それらを自分の実際のシナリオと組み合わせて、さらに考えることです。読んだり聞いたりすることはできますが、それに執着しないでください。たとえ社会主義であっても、その前には中国の特徴がある。

参考文献

[1]問題#86552: https://github.com/kubernetes/kubernetes/issues/86552

[2] Alibaba Cloudドキュメント: https://www.alibabacloud.com/help/zh/ack/product-overview/validity-period-change-for-api-server-internal-certificates

[3]コード1: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/server/options/serving_with_loopback.go#L52-L61

[4]コード2: https://github.com/kubernetes/kubernetes/blob/69c3b23abdbda53d14e14afc2af2bdfef23ac7b0/staging/src/k8s.io/client-go/util/cert/cert.go#L40C7-L40C19

[5]1498-kubernetes-yearly-support-period: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/1498-kubernetes-yearly-support-period

[6]2572リリースケイデンス: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence

[7]KubernetesにLTSが必要な理由: https://matduggan.com/why-kubernetes-needs-an-lts/

[8]slack#lts: https://kubernetes.slack.com/messages/wg-lts

[9]google#lts: https://groups.google.com/a/kubernetes.io/g/wg-lts

[10]ktls: https://github.com/klts-io/kubernetes-lts

[11]cve pr: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Amerged+label%3Acherry-pick-approved+CVE

[12]CVE修正: https://www.cvedetails.com/vulnerability-list/vendor_id-15867/product_id-34016/Kubernetes-Kubernetes.html

[13]cve k8s: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Kubernetes