Kubernetesの2019年についてまとめてみた

# はじめに
これは[Kubernetes Advent Calendar 2019](https://qiita.com/advent-calendar/2019/kubernetes) 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](https://github.com/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](https://github.com/kubernetes-sigs/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 の変更内容](https://qiita.com/Ladicle/items/1cfee78ef0b520df1d4a)に詳しく書かれています。

#### 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の人すごいなとなりました:innocent: 
この場を借りて、リリースまとめを作っていただいているZの皆様(@uesyn, @shmurata, @tkusumi, @shmurata, @Ladicle, @inajob, @superbrothers, @watawuwu, @kkohtaka, @ysakashita, @hiyosi, @yuanying 敬称略)には御礼申し上げます :bow:

参考にしたエントリー:
https://qiita.com/shmurata/items/a796e02740b0eb7df65a
https://qiita.com/uesyn/items/3def2beb32387e58af01
https://qiita.com/uesyn/items/0246346d8958318fa1d4