Skip to content

MS_AKSVersionSupport

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

AKSのバージョン、サポート、基盤保守について。

概要

AKS の

について。

補足（なぜこのページが重要か）: AKS を採用するときに
最も見落とされやすいのがバージョンの寿命である。
後述のとおり、サポート期間は実質 1 年程度しかなく、
「作ったら終わり」にできない。
AKSをセキュアに利用するためのテクニカルリファレンス の
「K8s は難しい」という判断の、かなりの部分がここに由来する。

詳細

バージョン

バージョン間の関連

K8s が公開されたら、ソレを利用して、
マネージド・サービスとして動く AKS を開発してリリース

  • K8s がアップストリーム（取り込み元）
  • AKS がダウンストリーム（取り込み先）

バージョン番号

  • セマンティック・バージョニングとほぼ同じ。
  • K8s では、マイナー・バージョン・アップも比較的安全らしい。
  • バージョン番号は（K8s と AKS で ≒ 取り込み元と先で）一致している。

移行メモ（補足）: 「マイナー・バージョン・アップも比較的安全」は、
K8s のマイナー バージョンは互換性を壊し得るため、留保が必要である。
実際、マイナー バージョンアップでは

  • API の非推奨・削除（例: PodSecurityPolicy の削除、Ingress の API 移行）、
  • コンポーネントの入れ替え（例: dockershim の削除）、

が起こる。アップグレード前には
非推奨 API の使用状況を確認する必要がある
（AKS には「非推奨 API の使用」を検知する診断機能がある）。

なお、セマンティック バージョニングの MAJOR.MINOR.PATCH において、
K8s は慣例的にマイナーで破壊的変更を入れる運用である点も
一般的な SemVer とは異なる。

リリース頻度

  • K8s

    • １ヶ月毎にビルド番号アップ（バグ・フィックス）
    • ３ヶ月毎にマイナー・バージョンアップ（機能追加）

  • AKS

    • AKS 自体は週次でアップデート

    • アップストリームの取り込み目標は、

      • 30 日となってる。
      • セキュリティ・パッチは即時公開

    • 取り込み元

      • メジャー・バージョン
        不明（まだ 1 系だけなので）

      • マイナー・バージョン
        初回の安定版をプレビュー公開して、その後、GA 公開する。

      • パッチ・バージョン
        必要なタイミングで取り込むので、全バージョンは取り込まれない。

    • モノによっては、GA まで 6 ヶ月を要したマイナー・バージョンもある。

補足（最新化）: K8s のリリース頻度は 年 3 回（約 4 ヶ月毎）に
変更されている（2021 年以降）。
AKS 側も、これに合わせて取り込みを行っている。

サポート

サポート・ポリシー

  • K8s

    • マイナー・バージョン n-2 までサポート（バグ・フィックス）が提供される。
    • 故に、3 つ前のマイナー・バージョンのバグ・フィックスが停止する。

  • AKS

    • マイナー・バージョンは、K8s と同じ（n-2 までサポート）
    • パッチ・バージョンは、AKS が取り込んだ最新の 2 つまでサポート。

サポート期間

  • K8s
    最近版を取得してからサポート停止まで、最長で、3 * 3 = 9 ヶ月となる。

  • AKS
    サポート期間は、K8s 公開後の取込となるので、K8s より短くなるが、
    枯れているので、K8s サポート打ち切り後も、暫くサポートが提供される。

補足（最新化 / 現在の期間）: 現在の AKS のサポートは次のとおり。

区分 期間
標準サポート GA から 12 ヶ月（n-2 の範囲）
長期サポート (LTS) 2 年間（Premium レベルの階層が必要。有償）
非サポート クラスタは動作するが、サポート・修正の対象外

つまり、標準サポートのままなら年 1 回以上のアップグレードが必須である。
それが難しい場合は LTS を選ぶという選択肢が加わった
（原文執筆時点には無かったもの）。

運用面（AKS）

サポート外の古いバージョンで新規作成不可能

  • ただし、サポート外の古いバージョンで継続動作はする。
  • AKS が AKS 上の K8s を勝手にバージョン・アップすることはない。
  • クラスタで使う K8s は、自分でアップデートする。

補足（最新化）: 現在は 自動アップグレード チャネル
（--auto-upgrade-channel）があり、
「勝手に上げない」を選ぶことも「自動で追随する」を選ぶこともできる。

チャネル 動作
none（既定） 自動アップグレードしない（原文の記述どおり）
patch 同じマイナー内で最新パッチに追随
stable n-1 の最新パッチに追随
rapid 最新マイナーの最新パッチに追随

併せて 計画メンテナンス期間（Planned Maintenance）で
適用する曜日・時間帯を指定できるため、
「自動だが業務時間中には上げない」という運用が可能。

基盤保守（AKS 基盤）

制御プレーン、ノードプール（VMSS）が対象。

概要

  • AKS 基盤はマネージド・サービス（自動）
  • K8s のバージョンアップは手動

サポートを受けるためのバージョン・アップ

  • ワーストケースで 1〜2 ヶ月と短い。

  • 手順

    • 制御プレーンのバージョン・アップ
    • ノードプール、実行ノードのバージョン・アップ

補足（順序が固定されている理由）: K8s では
制御プレーンがノードより新しい状態しか許容されない
（バージョン スキュー ポリシー）。
逆順にすると、ノードが制御プレーンより新しくなり構成が壊れる。

① 制御プレーン: 1.29 → 1.30
② ノードプール : 1.29 → 1.30

また、一度に飛ばせるのはマイナー 1 つずつである。
1.28 から 1.31 へ一気に上げることはできず、
3 回に分けて実施する必要がある。
「ワーストケースで 1〜2 ヶ月」という短さは、
この制約と合わせて計画に織り込む必要がある。

ミッションクリティカル・システム

複数ノードプールを使用したローリング・アップグレードが可能。

  • 制御プレーンだけ、インプレース・アップグレード
  • 複数ノードプールで、ノードプールは、ローリング・アップグレード

基盤保守（実行ノード）

実行ノードの Linux VM や Windows VM が対象。

概要

  • Linux ノード、Windows ノードに対して行う。
  • OS のセキュリティ・アップデートは
    • ノードプールのアップデートでも行われるが、
    • 基本は、日次で自動更新される。

リブート運用

サービスを停止させないためのリブート運用は基本的事項だが面倒。

  • VMSS のローリング・アップデート機能は、
    ノードプールが破損する可能性があるので、AKS では非サポート。

  • Kured を K8s にインストールし、ローリング・アップグレード的なリブート運用。

補足（最新化）: 現在は ノード OS 自動アップグレード チャネル
（--node-os-upgrade-channel）があり、Kured を自前で入れずに済む。

チャネル 動作
None 何もしない
Unmanaged（Linux の既定だった） OS 側の自動更新に任せる。再起動は自前（＝Kured が必要）
NodeImage（現在の推奨） AKS がノード イメージごと入れ替える（安全なローリング）
SecurityPatch セキュリティ修正のみ適用

NodeImage は「更新して再起動」ではなく
**「新しいイメージのノードを作って入れ替える」**方式なので、
原文が懸念する「VMSS のローリング アップデートでノードプールが破損する」
問題が構造的に発生しない。

冗長構成

ジオ冗長

Azure Traffic Manager を使用して、
ペアリージョンに AKS を展開して冗長化する。

補足: 現在は、HTTP アプリであれば
Azure Front Door の方が適する場面が多い
（エッジで即時に切り替わる。Traffic Manager は DNS TTL 分の遅延がある）。
また、複数リージョンの ACR は
Premium の地理レプリケーションで同期できる。

ゾーン冗長

  • az aks create の際に、--zones パラメタを付与する。

  • コレにより、単一クラスタでも、耐障害性を高めることが出来るが、

  • 以下の問題がある。

    • リージョン、K8s バージョンに制限がある。

    • 自動復旧させたい場合は、オートスケールを有効化する。

    • 永続ボリュームを利用する場合は、追加の構成設定が必要。
      （管理ディスクとノード VM を同一のゾーンに配置する必要があるため）

    ※ 制御プレーンが落ちても、ノードプールはそのまま動作。

  • 参考

移行メモ（誤字）: 原文の「対象外性」は
耐障害性の誤変換と判断し修正した。

補足（永続ボリュームの制約）: 「管理ディスクとノード VM を
同一ゾーンに配置する必要がある」というのは、
Azure マネージド ディスクがゾーンをまたげないためである。
したがって、ゾーン障害時に Pod が別ゾーンへ移動すると、
ディスクにアタッチできず起動しない。

対策としては、

  • **Azure Files（ZRS）**を使う（ゾーンをまたげる）、
  • あるいはそもそも永続化を AKS の外に出す、

のいずれかになる。後者が、次の「ポイント」節の主張である。

ポイント

補足（この結論が本ページの要）: 「永続化リソースは K8s の外に置く」
という判断は、本ページ全体の帰結として読むべきである。

  • サポート期間が短く、年 1 回以上のアップグレードが避けられない
  • アップグレードはノードの入れ替えを伴う
  • ディスクはゾーン・ノードに縛られる

したがって、ステートを持つものをクラスタ内に置くと、
アップグレードのたびにデータの可用性が問われることになる。
Azure SQL Database や
ストレージ といったマネージド サービスに
永続化を寄せておけば、クラスタは使い捨て可能になり、
保守が一気に楽になる。

参考

Microsoft Learn

Tags: 移行, クラウド, コンテナ, Azure, AKS, IaC, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally