非推奨の Kubernetes API の管理: ベスト プラクティスとツール

新しい機能が追加されると、古い API は非推奨となり、最終的には削除されます。これは Kubernetes の進化に必要な部分ですが、アプリケーションの実行にこのプラットフォームに依存している組織にとっては課題となる可能性があります。

Kubernetes API は、K8 クラスターと対話するためのインターフェースとして機能します。非推奨の API がクラスターで引き続き使用されている場合、中断や使用不可が発生する可能性があります。

このブログ記事では、非推奨の Kubernetes API とは何か、なぜ重要なのか、そしてそれらを効果的に管理する方法について説明します。

また、Kubernetes で非推奨の API を処理するために利用できるツールをいくつか紹介し、非推奨の API を管理するためのベスト プラクティスも提供します。

この記事を読むと、Kubernetes クラスターのアップグレードを処理する方法についての理解が深まり、インフラストラクチャに自信が持てるようになります。

APIライフサイクル

Kubernetes は、アルファ → ベータ → 安定という成熟度の進行に従っており、次の成熟レベルに移行せずにリソースを反復できるように、追加のバージョン管理が行われています。

アルファ リソースは v1alpha1 から始まり、v1alpha2 を反復処理するか、重大な変更がある場合は v2alpha1 を反復処理する可能性があります。ベータ API はアルファ API と同じ仕様になる場合もありますが、成熟度やユーザーとの契約は異なります。

• Alpha API は実験段階です。バグや互換性のない変更が含まれている可能性があります。これらはデフォルトでは有効になっていないため、注意して使用する必要があります。
• ベータ API は完全にテストされており、デフォルトで有効になっています。これらは将来の機能として頼りにできますが、ユーザーからのフィードバックやスケーラビリティなどの制約に基づいて実装が変更される場合があります。
• 安定した API には「ベータ」または「アルファ」という名前は付きません。これらはバージョン番号 (例: v1) で示され、バージョン番号を変更せずに実装で重大な変更を加えるべきではありません。

私が言及したライフサイクルは次のとおりです。

• API の複数のバージョンが同時に存在する場合、Kubernetes API によってそれらの一部が自動的にアップグレードされることがあります。ただし、アルファ API が成熟するにつれてバージョン間でスキーマが変更される可能性があるため、特に、正しいリソース スキーマがあることを確認する必要があります。
• 複数のバージョンの API が同時に利用可能な場合、Kubernetes API はそれらの一部をサイレントにアップグレードできます。ただし、アルファ API が成熟するにつれてバージョン間でスキームが変更される可能性があるため、特に、リソース スキームが正しいことを確認する必要があります。

ここで k8s API の概要を確認できます。たとえば、デプロイメントはアプリケーション グループに属しており、バージョンは v1 です。

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/

それらは次のようにリストされます:

 /apis/apps/v1/namespaces/{namespace}/deployments

Kubernetes API の廃止と削除

古いバージョンの Kubernetes API を実行している場合、アプリケーションが重大なダウンタイムのリスクにさらされる可能性があります。アップグレードによってダウンタイムが発生しない場合でも、Kubernetes API の小さな違いによって、潜在的な問題を調査する際に煩わしさが生じ、労力が無駄になる可能性があります。

この文脈では、非推奨とは、API コンポーネントが最終的に削除されることを決定することを意味します。現在も運用中ですが、今後のリリースでは廃止される予定です。 Kubernetes は明確に定義された非推奨ポリシーに従い、どの API が削除または変更されるかをユーザーに通知します。

Kubernetes API は、Kubernetes クラスターと対話するためのインターフェースとして機能し、ユーザーがポッド、名前空間、デプロイメントなどのさまざまな Kubernetes オブジェクトを照会および操作できるようにします。これらの API には、kubectl などのツール、REST API 経由、またはクライアント ライブラリを使用してアクセスできます。 Kubernetes が進化するにつれて、古い API は非推奨としてマークされ、最終的には廃止されます。これは、ユーザーまたはメンテナーが非推奨の Kubernetes API を認識することの重要性を強調しています。

非推奨の Kubernetes API フォーカス

Kubernetes でアプリケーションを構成する際の重要な側面は、ユーザーが YAML マニフェストまたは Helm チャート内の apiVersion フィールドで使用される Kubernetes オブジェクトの API バージョンを指定する必要があることです。これは、ユーザーとメンテナーが、廃止された Kubernetes API バージョンと、今後のリリースで予定されている削除について最新情報を把握しておくことの重要性を強調しています。

Kubernetes クラスターのアップグレード中に、非推奨の API に遭遇すると、特にアップグレードされたバージョンでこれらの API がサポートされなくなった場合は、潜在的な問題が発生する可能性があります。たとえば、クラスター内のリソースが古い API バージョンを使用している場合、そのリソースに依存するアプリケーションは、新しいクラスター バージョンで API が非推奨になっているために、正常に機能しない可能性があります。この状況は、Reddit のサイト全体の停止で起こったように、重大なダウンタイムにつながる可能性があります。

具体的な例としては、Kubernetes バージョン v1.22 の Ingress リソースの APIVersion extensions/v1beta1 が削除されたことが挙げられます。削除された API バージョンを構成で使用しようとすると、エラー メッセージが表示されます。

 Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Ingress" in version "extensions/v1beta1"

K8s APIの使い方

構成で特定の API バージョンを指定するには、Kubernetes ドキュメントから抜粋した次の例を参照してください。

 apiVersion: apps/v1 <------ API Version of the kubernetes objectapiVersion: apps/v1 <------ API Version of the kubernetes object kind: Deployment metadata: name: nginx

サポートされているすべての API グループとそのバージョンは、公式ドキュメントまたは kubectl コマンドライン ツールの api-versions コマンドを使用して確認できます。

 kubectl api-versions admissionregistration.k8s.io/v1 admissionregistration.k8s.io/v1beta1 apiextensions.k8s.io/v1 apiextensions.k8s.io/v1beta1 apiregistration.k8s.io/v1 apiregistration.k8s.io/v1beta1 apps/v1

非推奨の API を特定する際の課題

クラスター内で非推奨の API を利用するリソースを特定するのは難しい場合があります。さらに、Kubernetes は厳格な API バージョン管理プロトコルに従っているため、複数のリリースで v1beta1 および v2beta1 API が複数回廃止されました。

ポリシーでは、ベータ API バージョンは廃止後少なくとも 9 か月間または 3 リリース (いずれか長い方) はサポートされる必要があり、その後は削除される可能性があると規定されています。

場合によっては、非推奨の API が、クラスターとインターフェースするワークロード、ツール、またはその他のコンポーネントによって引き続きアクティブに使用されていると、停止が発生する可能性があります。

したがって、ユーザーと管理者は、クラスターを徹底的に評価して、使用中であり削除される予定の API を特定し、その後、影響を受けるコンポーネントを移行して、適切な新しい API バージョンを活用する必要があります。

廃止された Kubernetes API を管理するためのツール

古くなった Kubernetes API を処理する問題を解決するために使用できるツールがいくつかあります。

ツール 1: FairwindsOps の Pluto — 自動計測と GitHub 統合

FairwindsOps は、コード リポジトリと Helm リリースで非推奨の Kubernetes API を検出するための自動化ソリューションである Pluto をリリースしました。 Pluto は GitHub ワークフローとシームレスに統合することで、継続的な監視、廃止された API のタイムリーな識別、プロアクティブな管理を保証します。

ツール 2: doitintl による Kube No Trouble (kubent) — 包括的なクラスター全体のチェック

doitintl によって開発された Kube No Trouble (kubent) は、検出のためのデプロイメントに重点を置いて、廃止された API の包括的なクラスター レベルのチェックに重点を置いています。このツールでは、元のマニフェストを保存する必要があり、Kubernetes クラスター内の古い API を識別して解決するための包括的なソリューションを提供します。

ツール 3: Helm MapkubeAPIs プラグイン - グラフベースの API 識別

Helm MapkubeAPIs プラグインは、クラスターにインストールされている Helm チャート内の非推奨の API を識別するための貴重なツールです。このプラグインは、API の廃止を管理するためのターゲットを絞ったアプローチを提供し、アップグレード時の互換性とスムーズな移行を保証します。

ツール 4: Plural CD — オールインワン API 管理

複数の CD、非推奨の Kubernetes API の包括的な管理。その多面的な機能により、Kubernetes のアップグレード中の移行がスムーズになり、非推奨の API を識別して効果的に処理するための重要なコンポーネントになります。

これらのツールを組み合わせることで、ユーザーは非推奨の API を積極的に特定して解決し、Kubernetes のアップグレード中に発生する可能性のある問題を最小限に抑えることができます。これらのツールをワークフローにシームレスに統合することで、新しい API バージョンへのスムーズな移行が保証され、Kubernetes インフラストラクチャの全体的な安定性と信頼性が向上します。

結論は

Kubernetes API は柔軟性が高く、頻繁に変更できるように設計されており、これがその主な強みの 1 つです。

現在の Kubernetes API との互換性を確保するために、ユーザーはリソースが使用しているグループとバージョンを認識する必要があります。多くの場合、リソースはユーザーの操作なしに変更され、更新されたリソースとして保存されるため、段階的なスキーマ変更が可能になり、API アップグレードの信頼性が向上します。

ツールを使用してリソースを静的に検証するか、変換 Webhook を使用してリソースを自動的に変換することにより、リソースをあるバージョンから別のバージョンに安全に移行することが重要です。早期にテストを追加すると、Kubernetes を長期的に使用することに対する信頼を構築するのに役立ちます。