はじめに
これはKubernetes Advent Calendar 2019 7日目のエントリーです。
Kubernetesのこの1年について、リリース状況などをまとめつつ振り返ってみたいと思います。
2019年のバージョン年表(一部抜粋)
| 日付 | バージョン | 備考 |
|---|---|---|
| 1/11 | 1.13.2 | 2019年最初のリリース(主にBugfix) |
| 1/15 | 1.14.0-alpha.1 | 2019年最初のAlphaリリース |
| 2/19 | 1.14.0-beta.0 / 1.15.0-alpha.0 | |
| 3/26 | 1.14.0 | 2019年最初のマイナー正式版アップデート |
| 5/14 | 1.15.0-beta.0 / 1.16.0-alpha.0 | |
| 6/20 | 1.15.0 | |
| 8/13 | 1.16.0-beta.0 / 1.17.0-alpha.0 | |
| 9/18 | 1.16.0 | |
| 11/14 | 1.16.3 | 12/1現在最新のリリース |
| 11/23 | 1.17.0-rc.1 | 12/1現在最新のRCリリース |
Notable information
- マイナーバージョンについては最新のバージョンの他、直近3バージョンについてパッチリリースが入ります。
- 2019年12月現在では1.17がUpstreamの開発バージョン、1.14-1.16がパッチリリースの対象です。
- Kubernetesの基本的なアップデートサイクルは、3ヶ月に1回のマイナーバージョンリリースなので、このまま行くと12月の半ばには1.17がリリースされる見込みです。
- Kubernetesのバージョンリリース管理については「SIG-release」によって管理されています。
2019年にあった大きなアップデート/ニュース
前提として、全部のリリース、アップデートを追ってしまうと本当にきりがないくらい大量の情報があるので、主に記事として取り上げられたか、そのくらい大きな規模の情報について取り上げていきます。
1.14.0における大きなアップデート
Windowsノードのプロダクションサポート
- Windows Server 2019向けにWindowsコンテナ及びワーカーノードのサポートが追加された
- Azure-CNI、OVN-Kubernetes及びFlannelでのネットワーキングのサポートも
- 可能な限りPod、Service、メトリクスやクオータなどをLinuxコンテナの挙動に寄せた
Persistent Local VolumeがGA(Generally Available)に
- ノードにローカルにアタッチされたストレージをPVリソースとして利用可能になった
- 多くのユースケースでは分散型(または外部)のストレージを使うのが望ましいが、パフォーマンス要件などを理由にこちらを使う選択肢もありえる
Kubectlの大きなアップデート
- kubectlのドキュメントサイトがスタンドアロンで出来た (Ref: https://kubectl.docs.kubernetes.io/)
- Kustomizeが統合された
- kubectl pluginの機構がStableになった
1.15.0における大きなアップデート
Kubernetesの拡張性を高めるための、APIのコア周りのアップデート
- Kubernetesの拡張にはCRD(Custom Resource Definition)を使うが、Golangを使ってCRDを扱うにあたって、開発者たちがCRDを意識しなくても良いようにOpenAPIベースの構造化スキーマを用いることで、CRDのAPI周りの通信における安定性や信頼性が向上した
このへんの詳しい話は@Ladicle氏のKubernetes 1.15: SIG-API Machinery の変更内容に詳しく書かれています。
Cluster Lifecycle周りの改善
-
kubeadmを使った高可用性クラスターの構築がより簡単になった - ノード間で使われる証明書のローテーションが自動化された
CSIの継続的改善における取り組み
- Kubenretesの従来のストレージ機構として使われていたin-tree volumeをより拡張性の高いCSI(Container Storage Interface)に移行するための様々な改善が行われた
1.16.0における大きなアップデート
APIの破壊的変更
- Deploymentなどで従来使われていた
extentions/v1beta1、apps/v1beta1、apps/v1beta2が全てデフォルトで利用できなくなった-
apps/v1への速やかな移行が推奨されている
-
Custom ResourceがGAに
- Kubernetesを拡張して独自のリソースを定義し利用できるようにするCRDがこのバージョンからGAになった
- Windows周りでの改善
- WindowsコンテナにおけるWorkload Identityの改善
- kubeadmを使ったクラスターセットアップの改善
- CSIの提供を開始
Volumeの拡張性が改善
- CSIのVolume specが改善され、リサイズが簡単にできるようになった
Endpoint SliceがAlphaに
- 従来、Kubernetesリソースの管理は種別ごとに全く同じAPIエンドポイントによって提供されていた。大量のNodeやPodを抱えるようなユースケースの場合、リクエスト方になりエンドポイントのパフォーマンスが劣化する
- Endpoint Sliceを使うことで、適切にリソースとエンドポイントの範囲を定義して、大量のリソースが存在していてもAPIで取得できるオブジェクトのデータが肥大化しなくなり、リクエスト量も分散できる
2019年に見つかったKubernetes周りの脆弱性
1. CVE-2019-11249, CVE-2019-1002101
kubectl cpにおける脆弱性
kubectl cpコマンドはKubernetesのコンテナと手元の環境に存在するファイルを相互にコピーできるコマンドです。
この脆弱性はややトリッキーで、cpコマンドの内部で使われるコンテナ内のtarコマンドが悪意のあるバイナリに書き換えられていた場合に、手元で悪意のあるコードが実行されたり、出力が展開される可能性があります。
ベースイメージがサードパーティのもので、なおかつ何らかの悪意のあるものに書き換えられていた場合に再現されます。
2. CVE-2019-11247
KubernetesのAPIサーバーにおける認可周りの脆弱性
ネームスペース内のスコープで完結すべきKubernetesリソースの操作が、クラスタースコープでカスタムリソースにアクセスできてしまうというもの。
ネームスペース内のすべてのリソースにアクセスできる設定が与えられていた場合、この条件下においては実際にはクラスターの全カスタムリソースに対して操作が行えてしまうというちょっと困った脆弱性です。
3. CVE-2019-11253
KubernetesのAPIサーバーにおけるYAMLパーサの脆弱性
特定の条件を満たすマニフェスト(YAML or JSON payload)を食わせるとKubernetesのマスターコンポーネントであるKubernetes API Serverが応答不能になってしまいます。
1.14.0以降のバージョンで新規に作られたクラスターの場合、デフォルトのRBACの設定が変更されており、認証済みユーザーのみがアクセス可能なため脆弱性の範囲が限定的になります。
重要なのは1.13などから1.14に上げた場合でも、「RBACの設定は前方互換性のために変わらない」ということです。
つまり、ただバージョンを1.14にあげるだけではだめで、脆弱性がパッチされたものに上げる必要がありました。
まとめの感想
リリース情報をまとめた結果、Z Labの人すごいなとなりました
この場を借りて、リリースまとめを作っていただいているZの皆様(@uesyn, @shmurata, @tkusumi, @shmurata, @Ladicle, @inajob, @superbrothers, @watawuwu, @kkohtaka, @ysakashita, @hiyosi, @yuanying 敬称略)には御礼申し上げます 
参考にしたエントリー:
https://qiita.com/shmurata/items/a796e02740b0eb7df65a
https://qiita.com/uesyn/items/3def2beb32387e58af01
https://qiita.com/uesyn/items/0246346d8958318fa1d4