#はじめに
Kubernetes は約3ヵ月ごとにマイナーバージョンがリリースされていますが、
それに対する各社のクラウドサービスでのサポートやメンテナンスに関する現状を確認します。
2019/01/09 時点のスナップショットをとって、明記されている、確認できたものを抜粋します。
一覧
Kubernetes のバージョンは、以下のようにカテゴリされます。
バージョンアップという意味では、マイナーバージョンのアップグレードという意図で書きました。
- Major : 1.x.x
- Minor : x.9.x
- Patch : x.x.4...
「-」は、記述が見つけられなかった部分です。
また、表の中の「最新」は、「各サービス内で直近に GA された」を意図しています。
項目 | IBM Cloud Kubernetes Service (IKS) | Google Kubernetes Engine (GKE) | Amazon Elastic Container Service for Kubernetes (EKS) | Azure Kubernetes Service (AKS) |
---|---|---|---|---|
バージョンサポートポリシー | N-2(最新から3つ)まで | N-1(最新から2つ)まで | - (現状をみると N-1 まで) |
N-3(最新から4つ)まで |
移行期間 | 最新ver導入後、30日 | - | - | 最新ver通知後、15 日 |
Master Node のマイナーバージョン更新タイミング | 手動で更新開始 | 最新ver導入のたびに順次自動更新 (手動で更新開始も可) |
最新ver導入のたびに順次自動更新 (手動で更新開始も可) |
手動で更新開始 (N-4 になると N-3 に自動更新) |
Worker Node のマイナーバージョン更新タイミング | 手動で更新開始 | ・定期的な自動更新 (ウインドウ設定が可能) Or ・手動で更新開始 (定期的な自動更新は無効化) |
手動で更新開始 | 手動で更新開始 |
Worker Node のマイナーバージョン更新処理 | ユーザーが設定したノード数内でローリングアップグレード | ユーザーが設定したノード数内でローリングアップグレード | ユーザーが設定したノード数内でローリングアップグレード | Azure 側で新しいノードを追加され、一度に 1 ノードずつ処理を実行 |
Version Support | IKS | GKE | EKS | AKS |
~v1.9 2017年12年16日 リリース |
X 2018年1年22日サポート開始 2018年12月7日サポート終了 (v1.12 サポート開始後、約30日間でサポート終了) |
O 2018年2月5日サポート開始 2019年1月中にサポート終了予定 |
- | O |
v1.10 2018年3月27日 リリース |
O 2018年5月3日サポート開始 |
O 2018年5月15日サポート開始 |
O | O |
v1.11 2018年6月28日リリース |
O 2018年8月14日サポート開始 |
O 2018年10月30日サポート開始 |
O | O |
v1.12 2018年9月28日リリース |
O 2018年11月7日サポート開始 |
- | - | - |
v1.13 2018年12月4日 リリース |
- | - | - | - |
参考リンク1 | Version information and update actions | Versioning and Upgrades | Platform Versions | Azure Kubernetes Service でサポートされている Kubernetes のバージョン |
参考リンク2 | Updating clusters, worker nodes, and add-ons | Upgrading a Cluster | Updating an Amazon EKS Cluster - Amazon EKS | Azure Kubernetes Service (AKS) クラスターのアップグレード |
参考リンク3 | Auto-upgrading nodes | Worker Node Updates - Amazon EKS | kured を使用して Azure Kubernetes Service (AKS) のノードを更新および再起動する |
#さいごに
一覧にしてみると、サポートやメンテナンスポリシーに各社の特色が顕れている気がしました。
GKE の「Worker node auto-upgrades」は便利そうですが、設定に気をつけないとアプリが落ちることになりそうです。
Kubernetes クラスタを運用していくにも、やはり最低でも本番とテストの2クラスタは用意して、稼働確認をすることは必須だと感じました。