Kubernetes 1.15: 変更点まとめ(What's new!)

# はじめに

このエントリは、Kubernetes 1.15 の CHANGELOG からWhat's new!と、各変更点についてまとめたページをまとめています。

詳細については各まとめページを参照してください。

# 変更点の詳細

- [Known Issues, Urgent Upgrade Notes](https://qiita.com/shmurata/items/06c7c7007d46508bfaeb) @shmurata 
- [Deprecations and Removals, API Changes](https://qiita.com/tkusumi/items/b87eea9c3a9634e1c415) @tkusumi 
- [SIG API Machinery](https://qiita.com/Ladicle/items/1cfee78ef0b520df1d4a) @Ladicle 
- [SIG Apps](https://qiita.com/inajob/items/3e56cf9ea5990048863d) @inajob 
- [SIG CLI](https://qiita.com/superbrothers/items/ecaf0ac5178c663c3d7e) @superbrothers 
- [SIG Instrumentation](https://qiita.com/watawuwu/items/01162b0ae3b262c32695) @watawuwu 
- [SIG Network](https://qiita.com/summerwind/items/e1c8d649ed8c7ae44b83) @summerwind 
- [SIG Node](https://qiita.com/uesyn/items/a2af58b2685b5db91895) @uesyn 
- [SIG Scheduling](https://qiita.com/kkohtaka/items/d38e799b4a8da33ca89e) @kkohtaka 
- [SIG Storage](https://qiita.com/ysakashita/items/64a50582200be7888cee) @ysakashita 
- [SIG Auth](https://qiita.com/hiyosi/items/09d40a0508f2b6673b0f) @hiyosi 
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/f9f873e27f04139cdad2) @yuanying 
- [SIG Cloud Provider](https://qiita.com/hatotaka/items/bbf4bd8441c39e3597b0) @hatotaka 

<!--
A complete changelog for the release notes is now hosted in a customizable format at [https://relnotes.k8s.io/](https://relnotes.k8s.io/?releaseVersions=1.15.0). Check it out and please give us your feedback!


Kubernetes 1.15 consists of **25 enhancements**: 2 moving to stable, 13 in beta, and 10 in alpha. The main themes of this release are:
-->

# What's new!

Kubernetes 1.15は25の機能向上を含みます

* 2の機能がstableへ
* 13の機能がbetaへ
* 10の機能がalphaとなりました。

このリリースの主なテーマは以下の通りです。

<!--
#### Continuous Improvement
- Project sustainability is not just about features. Many SIGs have been working on  improving test coverage, ensuring the basics stay reliable, and stability of the core feature set and working on maturing existing features and cleaning up the backlog.
-->

### 継続的改善(Continuous Improvement)

* プロジェクトの持続可能性は機能だけではありません。多くのSIGがテストカバレッジの向上、基本の信頼性の維持、コア機能セットの安定性の確保、既存機能の成熟化およびバックログの整理に取り組んでいます。


<!--
#### Extensibility

- The community has been asking for continuing support of extensibility, so this cycle features more work around CRDs and API Machinery. Most of the enhancements in this cycle were from SIG API Machinery and related areas.
-->

### 拡張性

* コミュニティは拡張性の継続的なサポートを求めているので、v1.15ではCRDとAPI Machinery周辺の作業にフォーカスしています。このリリースの機能追加の大部分は、SIG API Machineryおよび関連分野のものです。

<!--
### Extensibility around core Kubernetes APIs
-->

## Extensibility around core Kubernetes APIs

<!--
#### CustomResourceDefinitions Pruning
To enforce both data consistency and security, Kubernetes performs pruning, or the automatic removal of unknown fields in objects sent to a Kubernetes API. An "unknown" field is one that is not specified in the OpenAPI validation schema. This behavior is already in place for native resources and ensures only data structures specified by the CRD developer are persisted to etcd. It will be available as a beta feature in Kubernetes 1.15.

Pruning is activated by setting `spec.preserveUnknownFields: false` in the CustomResourceDefinition. A future apiextensions.k8s.io/v1 variant of CRDs will enforce pruning.

Pruning requires that CRD developer provides complete, structural validation schemas, either at the top-level or for all versions of the CRD.
-->

### CustomResourceDefinitions Pruning

Pruningとはデータの一貫性とセキュリティを強制するために、kubernetesはAPIに対して送られてきたオブジェクトのフィールドの"unknown"なフィールドを自動的に削除する機能です。この仕組みはすでにネイティブリソースは対応しています。これはv1.15ではalphaからbetaに昇格しました。"unknown"かどうかは、OpenAPI validation schemaによって判定されます(トップレベル or バージョンごとの設定が必須)

PruningはCustomResourceDefinitionへ設定することで有効化されます。GA時にはデフォルトで有効化されます。

<!--
#### CustomResourceDefinition Defaulting

CustomResourceDefinitions also have new support for defaulting, with defaults specified using the `default` keyword in the OpenAPI validation schema. Defaults are set for unspecified fields in an object sent to the API, and when reading from etcd.

Defaulting will be available as alpha in Kubernetes 1.15 and requires structural schemas.
-->

### CustomResourceDefinition Defaulting

CustomResourceDefinitionsは、デフォルティングをサポートしました。OpenAPI validation schemaの `default`キーワードを使って指定できます。

<!--
#### CustomResourceDefinition OpenAPI Publishing

OpenAPI specs for native types have long been served at /openapi/v2, and they are consumed by a number of components, notably kubectl client-side validation, kubectl explain and OpenAPI based client generators.

With Kubernetes 1.15 as beta, OpenAPI schemas are also published for CRDs, as long as their schemas are structural.

These changes are reflected in the following Kubernetes enhancements:
([#383](https://github.com/kubernetes/enhancements/issues/383)), ([#575](https://github.com/kubernetes/enhancements/issues/575) ), ([#492](https://github.com/kubernetes/enhancements/issues/492) ), ([#598](https://github.com/kubernetes/enhancements/issues/598) ), ([#692](https://github.com/kubernetes/enhancements/issues/692) ), ([#95](https://github.com/kubernetes/enhancements/issues/95) ), ([#995](https://github.com/kubernetes/enhancements/issues/995) ), ([#956](https://github.com/kubernetes/enhancements/issues/956) )
-->

### CustomResourceDefinition OpenAPI Publishing

kubernetesのネイティブリソースのOpenAPI Specは`/openapi/v2`で長い間提供されており、kubectlのclient-side validationやkubectl explain、client generatorによって利用されます。

Kubernetes 1.15を使うとbeta機能として、CRDのOpenAPI shemeも公開されます(CRDが構造的である限り)。

<!--
### Cluster Lifecycle Stability and Usability Improvements

Work on making Kubernetes installation, upgrade and configuration even more robust has been a major focus for this cycle for SIG Cluster Lifecycle (see the May 6, 2019 [Community Update](https://docs.google.com/presentation/d/1QUOsQxfEfHlMq4lPjlK2ewQHsr9peEKymDw5_XwZm8Q/edit?usp=sharing)). Bug fixes across bare metal tooling and production-ready user stories, such as the high availability use cases have been given priority for 1.15.

kubeadm, the cluster lifecycle building block, continues to receive features and stability work required for bootstrapping production clusters efficiently. kubeadm has promoted high availability (HA) capability to beta, allowing users to use the familiar `kubeadm init` and `kubeadm join` commands to [configure and deploy an HA control plane](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/). An entire new test suite has been created specifically for ensuring these features will stay stable over time.

Certificate management has become more robust in 1.15, with kubeadm now seamlessly rotating all your certificates (on upgrades) before they expire. Check the [kubeadm documentation](https://github.com/kubernetes/website/blob/dev-1.15/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md) for information on how to manage your certificates.

The kubeadm configuration file API is moving from v1beta1 to v1beta2 in 1.15.

These changes are reflected in the following Kubernetes enhancements:
([#357](https://github.com/kubernetes/enhancements/issues/357) ), ([#970](https://github.com/kubernetes/enhancements/issues/970) )
-->

### Cluster Lifecycle Stability and Usability Improvements

Kubernetesのインストール、アップグレードと設定を、より安定したものにすることが、この 1.15 リリースサイクルにおける SIG Cluster Lifecycle における一番の目標でした。(2019/05/06 の[コミュニティアップデート](https://docs.google.com/presentation/d/1QUOsQxfEfHlMq4lPjlK2ewQHsr9peEKymDw5_XwZm8Q/edit?usp=sharing)をみてください。) ベアメタルにおけるツールの提供とプロダクションレディなユーザストーリーにおけるバグの修正、例えば高可用性といったユースケースは 1.15 において優先度が与えられました。

Cluster Lifecycle のビルディングブロックの一つである kubeadm はプロダクションクラスタのブートストラップを効率化する機能や安定性に必要となるコミュニティからの働きを受け続けています。kubeadm は 高可用性 (HA) のサポートをベータに昇格しました。これらはユーザが親しんでいる `kubeadm init` や `kubeadm join` を使って [HA コントロールプレーンを設定してデプロイ](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/)することを可能にします。新しくテストスイートはこれらの機能が長期に渡って安定することを保証するために作られました。

証明書の管理は 1.15 でより安定しました。kubeadm はシームレスに証明書を期限前にローテートします。[kubeadmのドキュメント](https://github.com/kubernetes/website/blob/dev-1.15/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md)で、どのように証明書を管理しているのかチェックしてください。

1.15 では kubeadm の設定 API が v1beta1 から v1beta2 になりました。

これらの変更は以下の Kubernetes の改良を反映したものです。

- [Ability to create dynamic HA clusters with kubeadm](https://github.com/kubernetes/enhancements/issues/357)
- [kubeadm: graduate the kubeadm configuration](https://github.com/kubernetes/enhancements/issues/970)
 

<!--
### Continued improvement of CSI
In Kubernetes v1.15, SIG Storage continued work to [enable migration of in-tree volume plugins](https://github.com/kubernetes/enhancements/issues/625) to the Container Storage Interface (CSI). SIG Storage worked on bringing CSI to feature parity with in-tree functionality, including functionality like resizing, inline volumes, and more. SIG Storage introduces new alpha functionality in CSI that doesn't exist in the Kubernetes Storage subsystem yet, like volume cloning.

Volume cloning enables users to specify another PVC as a "DataSource" when provisioning a new volume. If the underlying storage system supports this functionality and implements the "CLONE_VOLUME" capability in its CSI driver, then the new volume becomes a clone of the source volume.

These changes are reflected in the following Kubernetes enhancements:
([#625](https://github.com/kubernetes/enhancements/issues/625))
-->

### Continued improvement of CSI

Kubernetes v1.15において、SIG Storageは [in-tree volume plugins](https://github.com/kubernetes/enhancements/issues/625)をContainer Storage Interface(CSI)への移行作業を継続しました。
SIG Storageはリサイジング、inline volumeなどの機能をCSIへ取り込みました。さらに、Kubernetesのstorage機能で存在していないvolume cloningのような新しいaplha機能をCSIに導入しました。
Volume cloningでは新しいボリュームのプロビジョニングを行うときに、別のPVCを"DataSource"として指定することができます。これにより、ストレージ装置が、ボリュームのクローニングをサポートし、CSIドライバで"CLONE_VOLUME"機能を実装している場合、新しいボリュームはソースボリュームのクローンになります。
これらの変更は、以下のKubernetesの機能に関連しています。
([#625](https://github.com/kubernetes/enhancements/issues/625))

<!--
#### Additional Notable Feature Updates
- Support for go modules in Kubernetes Core.
- Continued preparation for cloud provider extraction and code organization.  The cloud provider code has been moved to kubernetes/legacy-cloud-providers for easier removal later and external consumption.
- Kubectl [get and describe](https://github.com/kubernetes/enhancements/issues/515) now works with extensions
- Nodes now support [third party monitoring plugins](https://github.com/kubernetes/enhancements/issues/606).
- A new [Scheduling Framework](https://github.com/kubernetes/enhancements/issues/624) for schedule plugins is now Alpha.
- ExecutionHook API [designed to trigger hook commands](https://github.com/kubernetes/enhancements/issues/962) in containers is now Alpha.
- Continued deprecation of extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs; these extensions will be retired in 1.16!

Check the [release notes website](https://relnotes.k8s.io/?releaseVersions=1.15.0) for the complete changelog of notable features and fixes.
-->

#### Additional Notable Feature Updates

- kubernetes coreでgo moduleをサポートしました
- Cloud Providerの抽出とコード編成のための継続的な準備。後で簡単に削除、外部からの利用をしやすくするためにCloud Provicerのコードは`kubernetes/legacy-cloud-providers`へ移動しました。
- [kubectl get and describe](https://github.com/kubernetes/enhancements/issues/515) はextensionで動作するようになった
- ノードは [third party monitoring plugins](https://github.com/kubernetes/enhancements/issues/606)をサポートするようになった
- スケジュールプラグインの新しい[Scheduling Framework](https://github.com/kubernetes/enhancements/issues/624)はAlphaになりました
- [ExecutionHook API](https://github.com/kubernetes/enhancements/issues/962)がAlphaになりました
    - 参考: https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190120-execution-hook-design.md
- 引き続きextensions/v1beta1, apps/v1beta1, apps/v1beta2の非推奨であり、これらはv1.16で削除されます