Kubernetes 1.17 新機能と改善の紹介 #AquaSecurity #Kubernetes

本ブログは「Aqua Security」社の技術ブログで2019年12月9日に公開された「 Kubernetes 1.17 Features and Enhancements 」の日本語翻訳です。

Kubernetes 1.17 新機能と改善の紹介

---

先日リリースされた Kubernetes 1.17 には新機能の追加・修正・改善が含まれています。この投稿では、Topology Aware Service routing、Pod shared PID Namespace、新しい Endpoint API によるスケーラビリティの改善など、Kubernetes 1.17が提供するいくつかの新機能に焦点を当てています。

Pod Shared PID Namespace

Kubernetes はコンテナが Linux のネームスペースなどのリソースを共有する Pod の概念を普及させました。1つの例は、Shared Network Namespace です。これは Pod 内のすべてのコンテナがネットワークインターフェイス、構成、およびポートを共有することを意味します。しかし、各コンテナはPID 1で始まる独自のプロセスツリーを「認識」するため、Pod 内のコンテナ間でプロセスを共有することができませんでした。最近コミュニティで承認された提案により、コンテナはPID Namespaceを共有できるようになりました。PID の共有は、相互にシグナルを送信する必要があるコンテナ間でのプロセス管理(kill コマンドなど)で特に役立ちます。

Pod Shared PID Namespace はベータ機能として利用可能でしたが、現在は GA に移行しています。

Service の改善

Kubernetes の Services は複数の Pod に同じ名前とアドレスを与えることで Pod を抽象化します。Service は利用可能な Pod の Endpoint 間で単純なロードバランスを行っています。ロードバランサーは Endpoint の物理的な場所を考慮しないため、異なるノード・ゾーン・リージョンのサービス間でルーティングされる可能性があります。Topology Aware Service Routing は、ホスト名・クラウドリージョン・クラウドゾーンなどのネットワークトポロジメタデータを使用してルーティングの決定を行います。 サービス間のネットワーク使用率を最適化することでパフォーマンスが向上します。クラウドドメイン間の横断を回避することでコストを削減できます。

Topology Aware Service Routing はアルファ機能として利用できます。

新しい Endpoint API によるスケーラビリティの改善

Kubernetes は Endpoint を使用して Pod と Service を仲介します。現在 Endpoint オブジェクトはサービスの個々に割り当てられるため、Endpoint の読み取りまたは書き込みを伴うすべての操作では Endpoint のセット全体を再計算する必要があります。

Kubernetes 1.17 では新しい EndpointSlice API が現在の Endpoint を置き換え、巨大化した Endpoint オブジェクトのサポートを改善します。新しい API は大規模かつ複雑なクラスタのサポートを改善します。新しい API はこのリリースに含まれる Topology Aware Service Routing や IPv4/IPv6 Dual Stack などの他の機能も有効にします。

IPv4/IPv6 Dual Stack の改善

Kubernetes は IPv4 と IPv6 を同時にサポートしていませんでしたが、Kubernetes 1.17はその取り組みに向けて前進しました。IPv4/IPv6 Dual Stack について詳細は Kubernetes 1.17リリースノートを確認ください。

Kubernetes CSI の改善

Container Storage Interface(CSI)は Kubernetes のストレージ関連のコンポーネントを、ツリー外のプラグイン可能なモジュールアーキテクチャにリファクタリングしました。CSI は成熟しており、このリリースではプロセスが継続されます。Volume Snapshot API はベータ版に移行するとともに、既存のストレージプラグインコードを CSI ドライバーに移行しています。Kubernetes ボリュームプロビジョニングに、クラウドゾーンなどの物理的概念を認識させる重要な機能である CSI トポロジのサポートが GA になりました。

Custom Resources Definitionの改善

Custom Resource Definition (CRD)は Kubernetes を拡張し、クラウドネイティブアプリケーションを構築する一般的な方法です。 CRD を定義するとき、開発者はその種類のリソースを作成するときにエンドユーザが使用するスキーマを定義します。ユーザがスキーマに従わなかった場合、データは etcd に保持されます。これは、紛らわしい動作であるだけでなく、潜在的なセキュリティリスクももたらします。Pruning は、CRD スキーマで定義されていないユーザ定義のデータが etcd に永続化されないようにする新しい機能です。デフォルト設定により CRD 開発者は CRD フィールドのデフォルト値を OpenAPI スキーマ定義として定義でき、ユーザエクスペリエンスが向上します。

上記およびその他の機能についてはリリース情報をご参照ください。これを機会に Kubernetes 1.17の新しい機能に触れてみてください。