Azure Kubernetes Service（AKS）のLong-term support（LTS）は、Kubernetesのアップグレードを永久に先送りするための機能ではありません。結論から言うと、PremiumレベルとLTSサポートプランを明示的に有効化し、最新に近いパッチを維持することで、AKSのKubernetesバージョンをより長く安全に運用するための選択肢です。
特に確認すべきポイントは、現在のKubernetesバージョン、End of Life（EOL）、supportPlan、--auto-upgrade-channel patch、利用中のアドオンです。LTSを有効にしても、サポートされないアドオンが有効なクラスターはLTSへ移行できない場合があります。既存のAKSクラスターを長期運用している管理者は、アップグレード計画だけでなく、課金・パッチ運用・アプリケーション互換性までセットで見直す必要があります。
Azure Kubernetes Service（AKS）のLong-term supportとは
Azure Kubernetes Service（AKS）のLong-term supportは、Kubernetesマイナーバージョンのサポート期間を延長し、次のバージョンへ移行するための計画・検証期間を確保しやすくする仕組みです。
Kubernetesコミュニティでは、マイナーバージョンが約4か月ごとにリリースされ、各バージョンのサポート期間はおおむね1年です。AKSではこの期間を「コミュニティサポート」と呼びます。AKSのLTSでは、1年間のコミュニティサポートに加えて、さらに1年間の長期サポートが提供され、一般提供（GA）から約2年間、アップグレード計画や検証に使える期間が広がります。(Microsoft Learn)
ただし、LTSは「そのバージョンを何年も固定してよい」という意味ではありません。LTS期間中も、サポート対象パッチの範囲、アドオンの対応状況、次のLTSバージョンへの移行準備を継続して管理する必要があります。
今回の公式情報で押さえるべき変更点
今回のAKS LTSで重要なのは、単に「サポート期間が延びる」ことではなく、LTSを受けるための条件が明確にある点です。実務では、次の表のように整理すると判断しやすくなります。
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| サポート期間 | コミュニティサポートは約1年。LTSによりGAから約2年の計画・検証期間を確保できる | 年1回ペースの大きなアップグレードが難しい組織でも、移行計画を組みやすくなる |
| 有効化条件 | クラスターをPremiumレベルに移行し、LTSサポートプランを明示的に選択する必要がある | StandardやFreeのままではLTS扱いにならない |
| 対象バージョン | 1.27以降のサポート対象KubernetesバージョンはLTS対象とされている | ただし、実際の利用可否はリージョンやリリース状況の確認が必要 |
| パッチ運用 | LTSでは最新2つのパッチバージョンのみがサポート対象 | LTSでも古いパッチに固定するとサポートを失う可能性がある |
| 課金 | LTS Premiumレベルの課金は、対象マイナーバージョンがコミュニティサポートを終了し、LTS期間に入った後に開始される | 早期にLTSへオプトインしても、コミュニティサポート期間中は既存レベルの課金が続く |
| ワークロード影響 | LTS有効化自体は構成変更であり、ノード再イメージやワークロード中断は発生しないとされている | LTS有効化とKubernetesアップグレード作業は分けて考える |
LTSでは最新2つのパッチバージョンのみがサポートされ、Microsoftはパッチ自動アップグレードチャネルの有効化を強く推奨しています。また、コミュニティサポート期間内に早期オプトインしておくと、LTS期間が始まるまで追加のPremiumレベルLTS料金なしで設定を固定できます。(Microsoft Learn)
LTSを使うべきケース、使わなくてよいケース
AKS LTSは便利ですが、すべてのクラスターで有効化すべきとは限りません。判断の軸は「アップグレードを遅らせたいか」ではなく、検証期間を確保する必要があるかです。
| 状況 | LTSの向き不向き | 判断のポイント |
|---|---|---|
| 本番環境で変更管理が厳しい | 向いている | 金融、医療、社内基幹システムなど、アップグレード前の検証・承認に時間がかかる場合 |
| アプリケーション依存関係が多い | 向いている | Helm chart、CRD、Admission Webhook、Service Meshなどの互換性確認が必要な場合 |
| 年数回のKubernetesアップグレードに追従できる | 必須ではない | コミュニティサポート内で継続的に更新できるなら、LTSなしでも運用可能 |
| 検証用・短期利用のクラスター | 基本的に不要 | 長期サポートよりも、最新バージョンで素早く作り直す運用の方が向く |
| サポート外アドオンを利用中 | 事前対応が必要 | アドオンを移行・無効化しないとLTSへ移れない可能性がある |
LTSは「アップグレードしない理由」ではなく、「安全にアップグレードするための猶予」を買う仕組みです。運用チームは、LTS有効化と同時に次のLTSまたはサポート対象バージョンへの移行日程を決めておくべきです。
管理者が最初に確認すべき設定
AKS管理者は、LTSを有効化する前に現在のクラスター状態を棚卸しします。最低限、次の5点を確認してください。
| 確認項目 | 確認する理由 | 例 |
|---|---|---|
| Kubernetesバージョン | EOLやLTS対象期間を判断するため | kubernetesVersion、currentKubernetesVersion |
| SKUレベル | PremiumでないとLTSを有効化できないため | sku.tier |
| サポートプラン | LTSか通常サポートかを確認するため | supportPlan |
| 自動アップグレードチャネル | LTSのパッチ対象から外れないようにするため | autoUpgradeProfile.upgradeChannel |
| アドオン | LTS非対応機能が有効でないか確認するため | addonProfiles |
Azure CLIでは、まず次のように現在の状態を確認します。
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query "{kubernetesVersion:kubernetesVersion,currentKubernetesVersion:currentKubernetesVersion,tier:sku.tier,supportPlan:supportPlan,autoUpgradeChannel:autoUpgradeProfile.upgradeChannel}" \
-o tableアップグレード可能なKubernetesバージョンは、AKS Release Trackerまたは次のコマンドで確認できます。公式ドキュメントでも、アップグレード先の確認方法としてaz aks get-upgradesが案内されています。(Microsoft Learn)
az aks get-upgrades \
--resource-group <resource-group-name> \
--name <cluster-name>実務では、ここで表示されるバージョンだけを見て判断しないでください。リージョンごとの提供状況、AKSのリリースカレンダー、対象バージョンの破壊的変更も確認します。AKSのサポート対象バージョンページでは、GAバージョンのEOLやLTS EOL、バージョン別の重要な変更点が掲載されています。(Microsoft Learn)
LTSを有効化する手順
既存クラスターでLTSを有効化する場合は、クラスターをPremiumレベルに移行し、AKSLongTermSupportを指定します。あわせて、パッチ自動アップグレードチャネルをpatchにするのが実務上の基本です。
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier premium \
--k8s-support-plan AKSLongTermSupport \
--auto-upgrade-channel patch新規クラスター作成時にLTSを有効化する場合は、次のようにaz aks createで指定します。
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier premium \
--k8s-support-plan AKSLongTermSupport \
--kubernetes-version <kubernetes-version> \
--auto-upgrade-channel patch \
--generate-ssh-keysPremiumレベルでAKSクラスターを作成する場合、--k8s-support-plan AKSLongTermSupportの指定が必要です。Microsoft Learnの価格レベルに関する公式情報でも、PremiumレベルとLTSは一緒に有効化・無効化する必要があると説明されています。(Microsoft Learn)
LTS有効化そのものは構成変更であり、ノードの再イメージやワークロード中断は行われないとされています。ただし、これは「LTSを有効化する操作」の話です。Kubernetesバージョンのアップグレード、ノードイメージ更新、パッチ適用では別途影響確認が必要です。(Microsoft Learn)
LTSを無効化する場合の注意点
LTSを無効化するには、FreeまたはStandardレベルに移行し、KubernetesOfficialサポートプランを明示的に選択します。
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier standard \
--k8s-support-plan KubernetesOfficialただし、コミュニティサポート終了後のバージョンでは、LTSサポートプランを有効にすることはできますが、そのバージョンのLTSを無効にすることはできません。つまり、「一時的にLTSへ入って、後から通常サポートに戻す」という運用は、タイミングによって成立しない可能性があります。(Microsoft Learn)
コスト最適化だけを目的にLTSをオン・オフするのではなく、対象バージョンのサポート状態、次のアップグレード先、業務影響を先に整理してから判断してください。
移行・展開時に失敗しやすいポイント
AKS LTSでよくある失敗は、LTSを「延命策」としてだけ捉え、移行計画を後回しにすることです。LTS期間が終われば、次のサポート対象バージョンへ移行する必要があります。
パッチを固定したままにしない
LTSでは、マイナーバージョン内のすべてのパッチがサポートされるわけではありません。最新2つのパッチバージョンのみがサポート対象です。たとえば、LTSに入ったからといって1.xx.1のような古いパッチに固定したままだと、サポート対象外になる可能性があります。(Microsoft Learn)
本番環境では、次のような運用をおすすめします。
| 運用項目 | 推奨対応 |
|---|---|
| パッチ適用 | --auto-upgrade-channel patchを有効化する |
| メンテナンス時間 | 業務影響が少ない時間帯にメンテナンスウィンドウを設計する |
| 事前検証 | ステージング環境で同じパッチ系列を先に適用する |
| 監視 | ノード、Pod再起動、Ingress、HPA、CSIドライバーの挙動を確認する |
LTS間の移行を一気に済ませようとしない
公式情報では、アップストリームのKubernetesコミュニティは2つのマイナーバージョンのアップグレードパスをサポートすると説明されています。AKSでインプレース移行する場合、コントロールプレーンを移行してからデータプレーンを移行します。(Microsoft Learn)
一方で、LTSバージョン間には約2年の間隔があるため、3つ以上のマイナーバージョン差が生じるケースがあります。この場合、非推奨APIにアプリケーションが依存している可能性が高くなるため、MicrosoftはターゲットのLTS Kubernetesバージョンでの十分なテストとブルーグリーンデプロイを推奨しています。(Microsoft Learn)
特に次の構成では、インプレースアップグレードだけに頼らず、ブルーグリーン移行を検討してください。
| 構成 | 注意点 |
|---|---|
| 複数のCRDを利用している | CRDバージョンやWebhookの互換性で詰まりやすい |
| IngressやGateway構成が複雑 | L7ルーティング、証明書、WAF連携の再検証が必要 |
| StatefulSetが多い | ストレージ、PodDisruptionBudget、フェイルオーバー時間を確認する |
| 古いAPIバージョンを使っている | apiVersionの廃止によりマニフェスト適用に失敗する可能性がある |
| 外部監視・ログ基盤と連携している | エージェントやDaemonSetの互換性確認が必要 |
LTSでサポートされないアドオンと機能
AKS LTSでは、一部のアドオンや機能がサポート対象外です。これらが有効な場合、クラスターを長期サポートに移動できません。公式情報では、Calico、KMS、Dapr、Application Gateway Ingress Controller、Open Service Mesh、AAD Pod Identityが対象として挙げられています。(Microsoft Learn)
| アドオン・機能 | 注意点 | 管理者が取るべき対応 |
|---|---|---|
| Calico | コミュニティサポート後はCalico Enterprise契約が必要とされる | ネットワークポリシーの実装方式とサポート契約を確認する |
| Key Management Service（KMS） | LTSサイクル中にKMSv2へ置き換わる | KMSv2への移行可否を事前に確認する |
| Dapr | AKS extensionsがサポートされない | Dapr依存のアプリを棚卸しし、運用形態を見直す |
| Application Gateway Ingress Controller | LTS期間中にApp Gateway for Containersへの移行が行われる | AGIC利用環境はIngress移行計画を立てる |
| Open Service Mesh | OSMは非推奨 | サービスメッシュの継続利用方針を再検討する |
| AAD Pod Identity | Workload Identityの代替として非推奨 | Microsoft Entra Workload IDへの移行を進める |
ここで重要なのは、クラスター管理者だけで判断しないことです。たとえばAAD Pod Identityは、アプリケーションの認証方式に直結します。AGICはアプリケーションの公開経路に関わります。DaprやOSMはアプリケーション設計に入り込んでいることがあります。
LTS移行前に、プラットフォームチーム、アプリ開発チーム、セキュリティ担当、ネットワーク担当で影響範囲を分担して確認してください。
開発者が確認すべきアプリケーション側のポイント
AKS LTSはインフラ側のサポートプランですが、失敗の多くはアプリケーション側の互換性で起きます。開発者は、次の観点を確認しておくと移行時の手戻りを減らせます。
Kubernetes APIの非推奨を確認する
古いapiVersionを使っているマニフェストは、アップグレード後に適用できなくなる場合があります。Deployment、Ingress、HorizontalPodAutoscaler、PodDisruptionBudget、CronJobなど、よく使うリソースほど見落としがちです。
確認例:
kubectl api-resources
kubectl get ingress,hpa,pdb,cronjob --all-namespacesHelmを使っている場合は、チャートのバージョンも確認します。アプリ本体は問題なくても、古いチャートが非推奨APIを生成していることがあります。
ステージング環境で同じAKSバージョンを先に試す
本番クラスターだけをLTSに入れて安心するのではなく、ステージング環境でも同じAKSバージョン、同じパッチ系列、同じアドオン構成を再現します。
検証では、単にPodが起動するかだけでなく、次の項目まで確認してください。
| 検証項目 | 見るべきポイント |
|---|---|
| 起動 | Pod、Init Container、Sidecarが正常に起動するか |
| 通信 | Service、Ingress、DNS、外部API接続が正常か |
| 認証 | Workload Identity、Secret参照、Key Vault連携が動くか |
| オートスケール | HPA、KEDA、Cluster Autoscalerが期待通り動くか |
| ログ・監視 | メトリック、ログ、アラートが欠落しないか |
| 障害対応 | ノード再起動、Pod退避、ローリング更新時に業務影響が出ないか |
LTS有効化前の実務チェックリスト
LTSを有効化する前に、次のチェックリストを使って状態を整理してください。
| チェック | 完了条件 |
|---|---|
| 現在のKubernetesバージョンを確認した | az aks showで現行バージョンを把握している |
| EOLとLTS EOLを確認した | AKSリリースカレンダーで対象バージョンの期限を確認している |
| Premiumレベルの課金影響を確認した | コスト見積もりと予算承認が済んでいる |
supportPlanを確認した | AKSLongTermSupportまたはKubernetesOfficialの状態を把握している |
| パッチ自動アップグレードを検討した | --auto-upgrade-channel patchの有効化可否を決めている |
| 非対応アドオンを確認した | Calico、KMS、Dapr、AGIC、OSM、AAD Pod Identityの利用有無を確認している |
| アプリ互換性を確認した | 非推奨API、Helm chart、CRD、Webhookを確認している |
| 移行方式を決めた | インプレースかブルーグリーンかを選定している |
| ロールバック方針を用意した | 切り戻し手順、DNS切替、バックアップ方針を準備している |
まとめ：AKS LTSは「延命」ではなく「移行準備の時間」を確保する仕組み
Azure Kubernetes ServiceのLong-term supportは、Kubernetesの更新頻度に追従しづらい本番環境にとって有効な選択肢です。ただし、LTSを有効にするだけで安全になるわけではありません。
管理者がまず行うべきことは、現在のAKSクラスターについて、Kubernetesバージョン、EOL、SKUレベル、サポートプラン、パッチ自動アップグレード、利用中アドオンを確認することです。そのうえで、LTSに入るクラスターと通常サポート内でアップグレードするクラスターを分けて判断します。
開発者は、非推奨API、Helm chart、CRD、認証方式、Ingress、監視エージェントなどを確認し、ステージング環境で実際に動作検証を行ってください。LTSはアップグレードを不要にする仕組みではなく、次の安全な移行に向けた準備期間です。今すぐやるべきことは、LTSの有効化コマンドを実行することではなく、対象クラスターの棚卸しと移行計画の作成です。
コメント