本文の内容は、2020年8月18日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/whats-new-kubernetes-1-19/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes 1.19がまもなくリリースされます！そして、それは目新しさが詰まっています。しかし、今回注目を集めたのは機能だけではありません。どこから始めて行きましょうか？
プロジェクトとしてのKubernetesは成熟しつつあり、サポートは9ヶ月から12ヶ月に増え、機能開発を着実に進めるための新しいプロトコルが用意されています。また、その新機能の多くは、Generic ephemeral inline volumesや構造化されたロギングのように、ユーザーの生活の質を向上させることを目的としています。
このバージョンの34の拡張機能のうち、10は完全に新しいもの、8はStableへの移行、2はKubernetesプロジェクトの管理変更、そしてその他の14は既存の機能であり、改善を続けています。
以下は、Kubernetes 1.19の新機能の詳細なリストです。
これらは、このリリース（ymmv）で私たちにとって最もエキサイティングに見える機能です。
#1498 Kubernetesのサポートウインドウを1年に増やす
メジャーなバージョンアップグレードには多くの計画が必要です。重大な変更点は何ですか？既存のツールはすべてアップデートに対応しているのか？このアップグレードを計画するために3ヶ月以上の期間を設けることで、クラスター管理者からのプレッシャーを軽減し、クラウドの安全性を高めることができます。
#1693 非推奨APIの使用に関する警告メカニズム
アップデートといえば、メジャーアップグレードを計画する際に最も苦しい部分の一つは、非推奨になるものの代替案を探すことです。この小さな変更により、開発者やクラスター管理者は、今後非推奨になるものを知ることができるようになります。うまくいけば、この変更によって開発者やクラスター管理者は先を見越した計画を立てることができ、"アップグレードのストレス "の一部を取り除くことができるようになります。
#1635 ベータ版からの移行が必要
新しい機能はいつでも歓迎されますが、一般的な利用可能性への道のりは、アーリーアダプターにとっては痛みを伴う、破滅的な変更に満ちています。そのため、機能がより早く安定性に到達すれば、ユーザーはより早くその恩恵を享受することができ、アーリーアダプターはそれほど多くの変更に苦しむ必要はありません。
だからこそ、新しいもので遊び始める前に物事を進め、機能を完成させるというKubernetesのこのコミットメントを見ることができるのは嬉しいことです。
#1698 ジェネリックなエフェメラルインラインボリューム
これもユーザーフレンドリーなアップデートです。ほとんどのコンテナは、一時的なデータを保存するためのボリュームを必要とするだけです。この汎用的でシンプルな方法でボリュームを定義することで、設定ファイルの複雑さが軽減されます。そして、これは現在のKubernetesユーザーにとってはより簡単になるだけでなく、学習曲線も柔らかくなり、新規参入者にとってはより簡単になるでしょう。
#1739 kubeadm: パッチによるカスタマイズ
各環境（prod、dev、test）の代替構成は、DevOpsの鍵となるインフラストラクチャのブートストラップを簡素化します。設定のパッチ適用は、このプロセスのメンテナンスをさらに効率化します。そして最後に、プロジェクト全体で標準的なツール（この場合はkubectlのような生パッチ）を選択することで、物事をシンプルに保ち、狂うことから一歩先を行くことができました。kubeadm チームに感謝します!
ステージ：ステーブルへのメジャー変更
機能グループ：リリース
Kubernetesのサポートは、9か月（または3リリース）から1年に増加します。
現在、マイナーアップデート（例1.18.X）はメインリリース（例：1.18）から最大9か月後にリリースされており、サポートを継続したい場合はクラスターオペレーターに9か月ごとのアップグレードを強いています。ただし、このような重要な更新に必要な計画の量を考えると、これは不定期な期間です。
LTSワーキンググループによって2019年の初めに行われた調査では、多くのKubernetesエンドユーザーがこの9か月のサポート期間内にアップグレードできないことがわかりました。下のグラフをご覧ください。それでも、バージョン1.11から1.13のみがサポートされていました。つまり、Kubernetesユーザーのほぼ3分の1が、サポートされていないバージョンを運用環境で実行していました。
このサポートウィンドウが12〜14か月に増えることは、Kubernetesユーザーの約80％がサポートされることを意味します。
テストとリリースにパッチを適用するバージョンが1つ増えると、すべてのKubernetesワーキンググループへのプレッシャーが高まるため、この変更がKubernetesプロジェクトに与える大きな影響に注意することが重要です。
ステージ：ステーブルへのメジャー変更
機能グループ：アーキテクチャ
これまで、Ingressのように、ベータ版に長時間留まる拡張機能について説明しました。拡張機能がベータ版に到達すると、それはデフォルトで有効になり、人々がそれを使い始めるように見えます。安定させるための動機は減少します。
この拡張機能は、安定版に移行する機能の量を増やすことを期待して、ベータ版の拡張機能の処理方法に関する新しいポリシーを定義します。
機能がBetaに移行すると、次の場合を除き、9か月（3つのリリース）で非推奨になります。
たとえば、1.19で導入されたベータAPIは、1.22以降に非推奨になり、1.25以降に削除されます。
これらの変更をユーザーに知らせるために、廃止されたAPI呼び出しを使用するときに新しい警告が追加されます。詳細については、次のポイントである＃1693を参照してください。
ステージ：ベータ
機能グループ： api-machinery
この機能強化は、一部は＃1635ベータ版からの移行が必要、そして一部はユーザーとクラスター管理者が非推奨のAPIの使用を認識および修正しやすくするために動機付けられています。
今後、APIサーバーには非推奨情報を含む警告ヘッダーが含まれます。これには、APIがいつ導入されたか、いつ廃止されるか、いつ削除されるかが含まれます。利用可能な新しいバージョンがあるかどうか、移行手順は何かなど、追加の修復情報を含めることができます。
kubectlなどの一部のクライアントは、この情報をユーザーに表示するように既に更新されています。
ステージ：ステーブルへグラデュエート
機能グループ： api-machinery
多くのAPIには、デバッグに役立つ.status.conditionsフィールドが用意されています。このフィールドを使用して、たとえば、ポッドのライフサイクルをクエリできます。
# kubectl -n cert-manager get pods -oyaml
kind: Pod
status:
conditions:
- lastTransitionTime: "2019-10-22T16:29:24Z"
status: "True"
type: PodScheduled
...
- lastTransitionTime: "2019-10-22T16:29:31Z"
status: "True"
type: Ready
ただし、.status.conditionsフィールドの内容はAPI間の標準ではありません。この拡張機能は、新しいAPIによって実装されるいくつかの共通フィールドと関連メソッドを定義します。
ステージ：ベータへグラデュエート
機能グループ：アーキテクチャ
使用ガイドラインに反して、一部のコアプロジェクトおよび関連プロジェクトは、node-role.kubernetes.ioネームスペースのラベルに応じて開始し、動作を変化させたため、一部のクラスターで問題が発生する可能性がありました。
この機能は、ノードロールラベルの適切な使用を明確にするために行われた作業を要約し、再度誤用されないようにし、必要に応じてそれらへの依存を取り除きます。
Kubernetesシリーズの新機能1.17のリリースで詳細をご覧ください。
ステージ：ベータへグラデュエート
機能グループ：アーキテクチャ
この拡張機能は、KubernetesコンポーネントもKubernetes準拠もベータREST APIまたは機能に依存しないようにするために行われた作業を収集します。GA以外の機能を有効にするためにk3s、Rancher、Openshiftなどの非公式ディストリビューションを必要としないため、最終目標はディストリビューション全体の一貫性を確保することです。
この機能 は当初Kubernetes 1.18で導入されましたが、現在ベータ版に移行しています。
ステージ：ベータへグラデュエート
機能グループ： Windows
ContainerDは、Kubernetesで動作するOCI準拠のランタイムであり、Windows Server 2019のホストコンテナーサービス（HCS v2）をサポートしています。この拡張機能により、ContainerD 1.3のサポートがWindowsのContainer Runtime Interface（CRI）として導入されます。
Kubernetesシリーズの新機能の 1.18のリリースで詳細をご覧ください。
ステージ：ステーブルへグラデュエート
機能グループ： auth
Kubernetes 1.7と、Kubernetes 1.8以降のベータ版で導入されたこの拡張機能は、最終的にGAに到達します。
この拡張機能は、kubelet証明書を取得し、有効期限が近づくにつれてローテーションするプロセスをカバーします。この証明書とキーのペアは、kubeletがkube-apiserverに対して認証するために使用します。このプロセスの詳細については、Kubernetesのドキュメントをご覧ください。
ステージ：ステーブルへグラデュエート
機能グループ： auth
ノードラベルは、ワークロードをスケジュールするときに非常に役立つメカニズムです。 たとえば、kubernetes.io/osを使用してホストにLinuxまたはWindowsのタグを付けることができます。これにより、スケジューラがポッドを適切なノードにデプロイしやすくなります。
ただし、ノードは独自のラベルの所有者であるため、悪意のある攻撃者がノードを特定のラベルに登録して、専用のワークロードとシークレットをキャプチャーする可能性があります。
このエンハンスメントは、Kubernetes 1.13 以降の NodeRestriction admission plugin で行われていた作業をまとめたもので、Kubeletsがk8s.ioやkubernetes.ioのようなコアのネームスペース内でラベルを自己設定しないようにするためのものです。強化案の詳細はこちらをご覧ください。
ステージ：ステーブルへグラデュエート
機能グループ： auth
各Kubernetesクラスターにはルート認証局があり、これを使用してコアコンポーネント間の通信を保護します。これは、証明書APIによって処理されます。これは便利なため、コア以外の用途に証明書をプロビジョニングするために使用されるようになりました。
この機能強化は、署名プロセスとそのセキュリティの両方を改善するためにRegistration Authorityの形態を追加して、新しい状況を受け入れることを目的としています。
詳しくは、What's new in Kubernetesシリーズの1.18のリリースをご覧ください。
ステージ：アルファ
機能グループ：クラスターライフサイクル
kubeadmはクラスタのいくつかのサービスの設定を生成、検証、デフォルト、保存します。現在の実装では、kubeletやkube-proxyのように内部コンポーネントの設定を使用していますが、これにはいくつかの問題があります。
例えば、設定にデフォルト値を含めるとメンテナンスが複雑になります。それらの値は意図的なものなのでしょうか？新しいバージョンでデフォルト値が変更された場合、古い値を維持するべきなのか、新しい値を維持するべきなのか？
また、このコードを kubeadm の中に含めることは、ベンダー間での分岐点となる可能性があります。
kubeadmがこれらの設定を管理する方法については、完全な見直しが行われています。これらの変更には、デフォルトのコンポーネント設定を停止し、設定の検証を委任することが含まれています。
ステージ：アルファ
機能グループ：クラスターライフサイクル
Kubernetes 1.16では、#1177 kubeadmを使った高度な設定(Kustomizeを使用)が導入され、基本設定をパッチ適用して設定のバリアントを取得できるようになりました。例えば、サービスの基本構成を持っていて、それをdev環境、テスト環境、prod環境ごとに異なる制限値でパッチを当てることができます。
kubeadm チームは、kubectl と同様の方法で生のパッチを使うことにしました。これにより、Kustomize のような複雑な依存関係の追加を避けることができます。
このために、既存の --experimental-kustomize をミラーリングした新しいフラグ --experimental-patches が追加されました。
このように使うことになります。
kubeadm init --experimental-patches kubeadm-dev-patches/
ステージ：アルファ
機能グループ：インストルメンテーション
現在、Kubernetesコントロールプレーンログは一般的な構造に従っていません。これにより、ログの解析、処理、保存、クエリ、分析が複雑になります。
この機能強化により、Kubernetesログメッセージの標準構造が定義されます。
E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"
そのために、InfoSやErrorSのようなメソッドがklogライブラリに追加されています。詳細はKubernetes 1.19のドキュメントに記載されています。
ステージ：ステーブルへのグラデュエート
機能グループ：インストルメンテーション
この取り組みには2つの主要な目標があります。イベントがクラスターの残りの部分に与えるパフォーマンスへの影響を減らすことと、イベントオブジェクトに構造を追加してイベント分析を可能にすることです。
詳しくは、What's new in Kubernetesシリーズの1.15のリリースをご覧ください。
ステージ：ステーブルへメジャー変更
機能グループへ：ネットワーク
Ingressリソースは、クラスター内の他のサービスからアクセス可能なサービスとして外部HTTPおよびHTTPSルートを公開します。Kubernetes 1.1で導入された後、このAPIはGAに到達するようになりました。
このバージョンでは、ServiceNameとServicePortフィールドがservice.nameとservice.portになったように、いくつかの変更が含まれています。詳細はKubernetes 1.19のドキュメントを確認してください。
Ingressについての詳細は、What's new in Kubernetesシリーズの1.18のリリースを参照してください。
＃752 EndpointSlice API
ステージ：ベータへのメジャー変更
機能グループ：ネットワーク
新しいEndpointSlice APIは、エンドポイントを複数のEndpoint Sliceリソースに分割します。これにより、現在のAPIでは大きなEndpointsオブジェクトに関連する多くの問題が解決されます。この新しいAPIは、ポッドごとの複数のIPなど、将来の他の機能もサポートするように設計されています。
1.19では、kube-proxyはLinuxではデフォルトでEndpointSliceを使用します。Windowsではアルファ状態でサポートされます。詳細はロールアウト計画をチェックしてください。
詳しくは Waht's new in Kubernetesシリーズの1.16のリリースをご覧ください。
ステージ：ベータへグラデュエート
機能グループ：ネットワーク
EndpointSlice APIでは、Kubernetes 1.17で新しいAppProtocolフィールドが追加され、ポートごとにアプリケーションプロトコルを指定できるようになりました。この機能強化により、このフィールドが ServicePort および EndpointPort リソースに導入され、ユーザーエクスペリエンスを悪化させる原因となっている非標準のアノテーションが置き換えられました。
Kubernetes 1.18で最初に導入されたこの機能拡張は、現在 Beta に移行しています。
ステージ：ベータへグラデュエート
機能グループ：ネットワーク
SCTPは、ポッド、サービス、エンドポイント、およびネットワークポリシーで、TCPおよびUDPとともに追加プロトコルとしてサポートされるようになりました。
この機能 はKubernetes 1.12で導入され、ついにベータ版に移行しました。
ステージ：アルファ
機能グループ：ノード
これでポッドのホスト名をFQDN(Fully Qualified Domain Name)に設定できるようになり、Kubernetesとレガシーアプリケーションの相互運用性が向上しました。
hostnameFQDN: true を設定した後、Pod内で uname -n を実行すると、単にfooではなく foo.test.bar.svc.cluster.local が返されます。
詳細は機能強化案に記載されています。
ステージ：アルファ
機能グループ：ノード
#606 (サードパーティのデバイス監視プラグインのサポート)とPodResources APIがGAになろうとしているため、Kubeletがメトリクスを収集することはもう期待されていません。
この機能拡張では、Kubeletがそれらのアクセラレータメトリクスを収集することを廃止するためのプロセスをまとめています。
ステージ：ベータへのメジャー変更
機能グループ：ノード
機械学習、科学計算、金融サービスは、計算集約型で超低レイテンシーを必要とするシステムの例です。これらの種類のワークロードは、コア間をジャンプしたり、他のプロセスと時間を共有したりするのではなく、1つのCPUコアに分離されたプロセスから恩恵を受けます。
ノードトポロジマネージャーは、kubeletハードウェアリソース割り当ての調整を集中化するコンポーネントです。現在のアプローチでは、このタスクをいくつかのコンポーネント（CPUマネージャー、デバイスマネージャー、CNI）に分割しているため、割り当てが最適化されない場合があります。
1.19では、この機能に2つのマイナーな機能拡張が追加されました。GetPreferredAllocation() と GetPodLevelTopologyHints() です。
詳しくは、What's new in Kubernetesシリーズの1.16のリリースをご覧ください。
ステージ：ステーブルへのグラデュエート
機能グループ：ノード
Seccompはサンドボックスを提供し、プロセスが実行できるアクションを減らし、システムの潜在的な攻撃対象を減らします。Seccompは、Kubernetesがポッドを安全に保つために使用するツールの1つです。
Alphaでのいくつかのバージョンを経て、この機能強化により、（Podのセキュリティポリシーを使用して）Podに適用されるseccompプロファイルをカスタマイズできるようになりました。
ステージ：ステーブルへのグラデュエート
機能グループ：ノード
この機能拡張は、docker/docker Golang パッケージへの依存関係を取り除き、Kubelet のメンテナンスを容易にするためにツリーの外に移動させるための努力の一部です。
特に、この拡張の唯一の目的は、Kubeletがdockerの依存関係なしにコンパイルして動作するようにすることですが、dockerのコードをツリーの外に移動させる作業はカバーしていません。
ステージ：アルファ
機能グループ：スケジュール
均等なポッドスプレッドを利用するためには、各ポッドに独自のスプレッドルールが必要であり、これは面倒な作業になります。
この機能拡張により、独自のtopologySpreadConstraintsを定義していないすべてのポッドにクラスタレベルで適用されるグローバルなdefaultConstraintsを定義できるようになりました。
ステージ：ベータへグラデュエート
機能グループ：スケジュール
topologySpreadConstraintsを使用すると、マルチゾーンクラスタに均等にポッドを分散させるルールを定義できるので、高可用性が正しく機能し、リソース利用が効率的になります。
詳しくは、What's new in Kubernetesシリーズの1.16のリリースをご覧ください。
ステージ：ベータへグラデュエート
機能グループ：スケジュール
ComponentConfigは、コンポーネントの設定をより動的にし、Kubernetes APIを介して直接到達できるようにするための継続的な取り組みです。
そのAPIはkube-scheduler一部のバージョンではAlphaで成熟しており、GAへの移行を開始する準備ができています。スケジューラの設定オプションは、Kubernetes 1.19のドキュメントで確認できます。
ステージ：ベータへグラデュエート
機能グループ：スケジュール
現在、PreemptionPolicy のデフォルトは PreemptLowerPriority で、これにより、優先度の高いポッドが優先度の低いポッドを先取りすることができます。
この機能拡張により、PreemptionPolicy が追加されました。これにより、優先度の低いポッドよりも先にスケジューリングキューにポッドを配置することはできますが、他のポッドを先取りすることはできません。
詳しくは、What's new in Kubernetesシリーズの1.15のリリースをご覧ください。
ステージ：ベータへグラデュエート
機能グループ：スケジュール
この機能拡張により、設定ごとに1つのスケジューラを実行するのではなく、異なる設定、またはプロファイルで1つのスケジューラを実行できるようになりました。
詳しくは、What's new in Kubernetesシリーズの1.18のリリースをご覧ください。
ステージ：アルファ
機能グループ：ストレージ
エフェメラルボリュームを定義する方法はいくつかあります。エフェメラルボリュームとは、特定のポッド用に作成され、ポッドが終了すると削除されるボリュームのことです。
しかし、Kubernetesに直接実装されているエフェメラルボリュームドライバー(EmptyDir, Secrets, ConfigMap)の場合、その機能はKubernetes内部で実装されているものに限られています。また、CSIエフェメラルボリュームが動作するためには、CSI ドライバーを更新する必要があります。
この拡張機能は、動的プロビジョニングをサポートするストレージドライバーで動作するインラインエフェメラルボリュームを定義するためのシンプルなAPIを提供します。これは、ジェネリックなエフェメラルボリュームを使用する方法の一例です。
apiVersion: apps/v1
kind: DaemonSet
...
spec:
...
- name: scratch
ephemeral:
metadata:
labels:
type: fluentd-elasticsearch-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1Gi
詳細は強化提案書に記載されています。
ステージ：アルファ
機能グループ：ストレージ
この機能拡張は、十分な空き容量がないCSIボリュームに接続されたノードでポッドがスケジューリングされるのを防ぐことを試みます。
これは、容量情報を収集し、その情報をAPI サーバに保存してスケジューラが利用できるようにすることで行われます。
ステージ：アルファ
機能グループ：ストレージ
CSIボリュームがコンテナ内にバインドマウントされる前に、KubernetesはfsGroupを介してボリュームの所有権を変更します。しかし、NFSのようにすべてのボリュームがこれらの操作をサポートしているわけではないため、ユーザーにエラーが報告される可能性があります。
現在、Kubernetesは、ボリュームがfsGroupベースの権限変更をサポートしているかどうかを判断するためにいくつかのヒューリスティックを使用していますが、これらのヒューリスティックが常に機能するとは限らず、一部のストレージタイプで問題が発生します。
この機能拡張では、CSIDriver.Spec.SupportsFSGroupという新しいフィールドが追加され、fsGroupを介したボリュームの所有権変更をサポートしているかどうかをドライバが定義できるようになりました。このフィールドには以下の値を設定できます。OnlyRWO は現在の動作に一致し、Never はボリューム所有権の変更を試みないように指示し、Always は定義された fsGroup の適用を常に試みるように指示します。
ステージ：ベータへのグラデュエート
機能グループ：ストレージ
SecretsとConfigMapsに新しいimmutableフィールドが追加されました。trueに設定すると、リソースキーで行われた変更はすべて拒否されます。これにより、アプリケーションが壊れてしまうような誤った更新からクラスタを保護します。
二次的な利点は、immutableリソースから得られるものです。リソースは変更されないので、Kubeletは定期的に更新をチェックする必要がなく、スケーラビリティとパフォーマンスを向上させることができます。
詳しくは、What's new in Kubernetesシリーズの1.18のリリースをご覧ください。
ステージ：ベータへのグラデュエート
機能グループ：ストレージ
この機能拡張は、#625 In-tree storage plugin to CSI Driver Migrationの取り組みの一部です。
ストレージプラグインはもともと Kubernetesコードベース内のインツリーだったため、ベースコードの複雑さが増し、拡張性の妨げになっていました。このコードをすべてロード可能なプラグインに移行することで、開発コストを削減し、よりモジュール化された拡張性の高いものにすることができます。
この機能拡張により、インツリーのAzure Disk Pluginの内部をAzure Disk CSI Driverへの呼び出しに置き換え、元のAPIを維持しながら移行を支援します。
ステージ：ベータへのグラデュエート
機能グループ：ストレージ
#625 In-tree storage plugin to CSI Driver Migrationの一部。
vSphere 用の CSI ドライバはすでにステーブルなので、インツリー コードの移行は継続して進めることができます。
以上です。皆さん！いつものように刺激的です。これらの機能を使用する場合は、クラスターをアップグレードする準備をしてください。
これが気に入った場合は、以前の'What's new in Kubernetes'エディションを確認してください。
また、Kubernetesエコシステムの最新情報をお楽しみになられている方は、クラウドネイティブエコシステムで起きている最もクールなことを毎月配信しているコンテナニュースレターを購読してください。