Kubernetes 1.18: 変更点まとめ

このエントリは、Kubernetes 1.18 の [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md#v1180) から 各変更点についてまとめたページをまとめています。

<!-- ##  What’s New(Major Themes) -->
## 1.18 の主な変更点(What’s New)

<!-- ### Kubernetes Topology Manager Moves to Beta - Align Up! -->
### Topology Manager がベータになりました

<!-- A beta feature of Kubernetes in release 1.18, the [Topology Manager feature](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content /en/docs/tasks/administer-cluster/topology-manager.md) enables NUMA alignment of CPU and devices (such as SR-IOV VFs) that will allow your workload to run in an environment optimized for low-latency. -->
[Topology Manager](https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/) を利用すると、CPU とデバイス（SR-IOV VFs など）のリソース割り当てを調整し、低レイテンシ用に最適化された環境でワークロードが実行できます。

<!-- Prior to the introduction of the Topology Manager, the CPU and Device Manager would make resource allocation decisions independent of each other.This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications.  -->
Topology Manager が導入される前は、CPU とデバイスマネージャーのリソース割り当て方法はお互いに独立していたため、複数の CPU を搭載したマルチソケットのサーバーで望ましくないリソースの割り当てが発生し、アプリケーション性能を低下させる可能性がありました。

- :memo: [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0035-20190130-topology-manager.md) の表題は Node Topology Manager となっています。
- :memo: 現在のところ [CPU Manager](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/) が `static` なっているノード上で動作します。

<!-- ### Serverside Apply - Beta 2 -->
### Serverside Apply - ベータ 2

<!-- Server-side Apply was promoted to Beta in 1.16, but is now introducing a second Beta in 1.18. This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when.-->
Server-side Apply が v1.18 で ベータ 2 になりました。
このバージョンで、全ての Kubernetes オブジェクトのフィールドに対する変更を追跡、管理するために、リソースがいつ変更されたかを知ることができるようになりました。

<!-- ### Extending Ingress with and replacing a deprecated annotation with IngressClass -->
### Ingress が拡張され、IngressClass リソースの導入

<!-- In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. -->
Kubernetes 1.18 の Ingress には、2 つの重要な追加である `pathType` フィールドと`IngressClass` リソースの追加がありました。

<!-- The `pathType` field allows specifying how paths should be matched.In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. -->
`pathType` フィールドはパスの一致方法を指定できます。デフォルト値として使われる `ImplementationSpecific` に加えて、完全一致の `Exact` 、前方一致の `Prefix`  が `pathType` として指定できます。

- :memo: Prefix の設定例

   ```yaml
   apiVersion: networking.k8s.io/v1beta1
   kind: Ingress
   metadata:
     name: test-ingress
   spec:
     rules:
     - http:
         paths:
         - path: /v1
           pathType: Prefix
           backend:
             serviceName: test
             servicePort: 80
   ```
- :memo: [現状](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20190125-ingress-api-group.md#path-as-a-prefix)は Proxy vendors の実装方法で結構違うようです。

<!-- The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation. -->
[IngressClass](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class) リソースは、Kubernetes クラスター内の Ingress タイプを指定するために使用されます。Ingress の `ingressClassName` フィールドに、関連付けたい IngressClass を指定できます。この新しいリソースとフィールドは、非推奨となった `kubernetes.io/ingress.class` アノテーションに代わるものとして利用されます。

- :memo: `kubernetes.io/ingress.class` は複数の Ingress コントローラーが実行されている場合に、どのコントローラーを使用するかを指定できるアノテーションでした。
- :memo: IngressClass の設定例

  ```yaml
  apiVersion: networking.k8s.io/v1beta1
  kind: IngressClass
  metadata:
    name: external-lb
  spec:
    controller: example.com/ingress-controller
    parameters:
      apiGroup: k8s.example.com/v1alpha
      kind: IngressParameters
      name: external-lb
  ---
  apiVersion: networking.k8s.io/v1beta1
  kind: Ingress
  metadata:
    name: nginx
  spec:
    ingressClassName: external-lb
    rules:
    - host: nginx.test
      http:
        paths:
        - backend:
            serviceName: nginx
            servicePort: 80
  ```

### SIG CLI introduces kubectl debug

<!-- SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`.-->
SIG CLI はとても長い間、デバッグユーティリティの必要性について議論されてきましたが、[エフェメラルコンテナ](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) の開発に伴い、`kubectl exec` 上に構築されたツールで開発者をサポートする方法がより明確になりました。

<!-- The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting. -->
[kubectl debug](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) という非常に有用なコマンドの追加により、開発者はクラスタ内にある Pod のデバッグが簡単になりました。このコマンドは、調査対象の Pod 内に一時的なコンテナを作成し、そのコンテナのコンソールへ接続することで調査対象の Pod を調べることができます。

- :memo: 詳しくはこちらの [Kubernetes 1.16: Ephemeral Containers (alpha)](https://qiita.com/superbrothers/items/85edec4d0232e0bbe2c0) を参照してください

<!-- ### Introducing Windows CSI support alpha for Kubernetes -->
### Kubernetes の Windows CSI サポート（アルファ）の紹介

<!-- With the release of Kubernetes 1.18, an alpha version of CSI Proxy for Windows is getting released. CSI proxy enables non-privileged (pre-approved) containers to perform privileged storage operations on Windows. CSI drivers can now be supported in Windows by leveraging CSI proxy. -->
Kubernetes v1.18 のリリースにともない、CSI Proxy for Windows のアルファバージョンがリリースされました。CSI Proxy for Windows を使用すると 事前に承認しておくことで non-privileged なコンテナで Windows 上の privileged なストレージの操作を実行できます。また CSI Proxy for Windows を利用することで、CSI ドライバーを Windows でサポートできるようになりました。

<!-- SIG Storage made a lot of progress in the 1.18 release. In particular, the following storage features are moving to GA in Kubernetes 1.18-->
他にも SIG Storage は v1.18 のリリースで多くの進捗があり、次のストレージ機能が GA となりました。

<!-- - Raw Block Support: Allow volumes to be surfaced as block devices inside containers instead of just mounted filesystems. -->
- Raw Block のサポート: マウントされたファイルシステムだけでなく、コンテナー内のブロックデバイスとしてボリュームを表示できるようになりました。

<!-- - Volume Cloning: Duplicate a PersistentVolumeClaim and underlying storage volume using the Kubernetes API via CSI. -->
- ボリュームの複製: CSI 経由の Kubernetes API を使用し、PersistentVolumeClaim の元となるストレージボリュームを複製します。

<!-- - CSIDriver Kubernetes API Object: Simplifies CSI driver discovery and allows CSI Drivers to customize Kubernetes behavior. -->
- CSIDriver Kubernetes API オブジェクト: CSI ドライバーの検出を簡素化し、CSI ドライバーが Kubernetes の動作をカスタマイズできるようになりました。

<!-- SIG Storage is also introducing the following new storage features as alpha in Kubernetes 1.18: -->
SIG Storage は、Kubernetes v1.18 でアルファとして次の新しいストレージ機能も導入しています。

<!-- - Windows CSI Support: Enabling containerized CSI node plugins in Windows via new [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) -->
- Windows CSI のサポート: [CSI Proxy](https://github.com/kubernetes-csi/csi-proxy) を利用して、Windows 上でコンテナー化された CSI ノードプラグインを有効にする

<!-- - Recursive Volume Ownership OnRootMismatch Option: Add a new “OnRootMismatch” policy that can help shorten the mount time for volumes that require ownership change and have many directories and files. -->
- ボリューム所有権の OnRootMismatch オプション: fsGroupChangePolicy に OnRootMismatch ポリシーを利用すると、所有権の変更を必要とするたくさんのディレクトリとファイルを持つボリュームのマウント時間が短くなります。
  - :memo: fsGroupChangePolicy に Always を設定すると現在の動作が維持されます。

<!-- ### Other notable announcements -->
### その他の注目すべき機能

#### SIG Network
<!-- SIG Network is moving IPv6 to Beta in Kubernetes 1.18, after incrementing significantly the test coverage with new CI jobs. -->
SIG Network では、新しい CI ジョブでテストカバレッジを大幅に増やし、IPv6 がベータになりました。

<!-- NodeLocal DNSCache is an add-on that runs a dnsCache pod as a daemonset to improve clusterDNS performance and reliability. -->
NodeLocal DNSCache は v1.18 で GA となりました。NodeLocal DNSCache は dnsCache ポッドを DaemonSet として実行し、ClusterDNS のパフォーマンスと信頼性を向上させるアドオンです。[#1351](https://github.com/kubernetes/enhancements/pull/1351)

<!-- The feature has been in Alpha since 1.13 release. The SIG Network is announcing the GA graduation of Node Local DNSCache [#1351](https://github.com/kubernetes/enhancements/pull/1351) -->

## 既知の問題点と重大なアップグレードに関する通達
- https://qiita.com/shmurata/items/7cad41fe7c3f1768d8d9

## SIG (Special Interest Group) 毎の変更点

- [SIG API Machinery](https://qiita.com/Ladicle/private/bbe2a62aba85d083283d) @Ladicle
- [SIG Apps](https://qiita.com/inajob/items/176edcf843eb16905497) @inajob
- [SIG CLI](https://qiita.com/superbrothers/items/eef275853b0c2d14e95c) @superbrothers
- [SIG Network](https://qiita.com/tkusumi/items/e72e255363f6deee3e9b) @tksm
- [SIG Node](https://qiita.com/uesyn/items/ff4330952573e172594d) @uesyn
- [SIG Scheduling](https://qiita.com/kkohtaka/items/3c11d87ff45b5ca09292) @kkohtaka
- [SIG Storage](https://qiita.com/ysakashita/items/1afaef2b6a7e6e2303da) @ysakashita
- [SIG Auth](https://qiita.com/hiyosi/items/c95e430916c1755cffaf) @hiyosi
- [SIG Instrumentation](https://qiita.com/watawuwu/items/3e85738e5647feec4d8c) @watawuwu
- [SIG ClusterLifeCycle](https://qiita.com/yuanying/items/cc8f100b97fb8f076973) @yuanying