Kubernetes 1.16: 主なイノベーションの概要

今日、水曜日、 起こる Kubernetes の次のリリース - 1.16。 私たちのブログで培ってきた伝統に従って、今回は XNUMX 周年記念の機会に、新しいバージョンの最も重要な変更点についてお話します。

この資料の作成に使用された情報は、以下から取得されています。 Kubernetes 拡張機能追跡テーブル, 変更履歴-1.16 および関連する問題、プル リクエスト、Kubernetes Enhancement Proposals (KEP)。 じゃ、行こう！..

ノード

本当に多数の注目すべきイノベーション (アルファ版ステータス) が、K8s クラスター ノード (Kubelet) 側に表示されます。

まず、いわゆる、 «一時的なコンテナ» (一時的なコンテナ)、ポッドでのデバッグプロセスを簡素化するように設計されています。。 新しいメカニズムを使用すると、既存のポッドの名前空間で開始され、短期間存続する特別なコンテナーを起動できます。 その目的は、問題を解決してデバッグするために他のポッドやコンテナと対話することです。 この機能用に新しいコマンドが実装されました kubectl debug、本質的には似ています kubectl exec: コンテナ内でプロセスを実行する代わりにのみ (次のように) exec) ポッド内のコンテナーを起動します。 たとえば、次のコマンドは新しいコンテナをポッドに接続します。

kubectl debug -c debug-shell --image=debian target-pod -- bash

一時コンテナー (およびその使用例) の詳細については、以下を参照してください。 対応KEP。 現在の実装 (K8s 1.16) はアルファ版であり、ベータ版への移行基準には「[Kubernetes] の少なくとも 2 つのリリースでエフェメラル コンテナ API をテストする」ことが含まれています。

NB: その本質およびその名前においても、この機能は既存のプラグインに似ています。 kubectl-デバッグそれについて私たちは すでに書いた。 一時的なコンテナの出現により、別個の外部プラグインの開発は中止されることが予想されます。

もう一つの革新 - PodOverhead - 提供するように設計されています ポッドのオーバーヘッドコストを計算するメカニズム、使用するランタイムによって大きく異なる可能性があります。 一例として、著者らは、 このKEP その結果、ゲスト カーネル、kata エージェント、init システムなどの実行が必要な Kata コンテナが生成されます。 オーバーヘッドが非常に大きくなると、それを無視することはできません。つまり、さらなる割り当てや計画などでオーバーヘッドを考慮する方法が必要になります。 それを実装するには PodSpec フィールドが追加されました Overhead *ResourceList (のデータと比較 RuntimeClassが使用されている場合)。

もう一つの注目すべきイノベーションは、 ノードトポロジーマネージャー (ノード トポロジ マネージャー)、Kubernetes のさまざまなコンポーネントに対するハードウェア リソースの割り当てを微調整するアプローチを統一するように設計されています。 この取り組みは、高性能の並列コンピューティングと、高度な CPU と操作の実行の遅延を最小限に抑えるためのさまざまな最新システム (電気通信、機械学習、金融サービスなどの分野から) のニーズの高まりによって推進されています。ハードウェアアクセラレーション機能。 Kubernetes におけるこのような最適化は、これまで異種コンポーネント (CPU マネージャー、デバイス マネージャー、CNI) のおかげで実現されてきましたが、今後は、アプローチを統合し、新しい同様の接続 (いわゆるトポロジー) を簡素化する単一の内部インターフェイスが追加される予定です。認識 - Kubelet 側のコンポーネント。 詳細 - で 対応KEP.

トポロジー・マネージャーのコンポーネント図

次の機能 - コンテナの実行中にチェックする (起動プローブ)。 ご存知のとおり、起動に時間がかかるコンテナの場合、最新のステータスを取得するのは困難です。コンテナは、実際に機能し始める前に「強制終了」されるか、長期間デッドロック状態に陥るかのどちらかです。 新しいチェック (機能ゲートと呼ばれる機能を通じて有効になります) StartupProbeEnabled) ポッドの実行が終了する瞬間まで他のチェックの効果をキャンセルします (つまり、延期します)。 このため、この機能は当初、 ポッドスタートアップ活性プローブホールドオフ。 ポッドの起動に時間がかかる場合は、比較的短い間隔で状態をポーリングできます。

さらに、「異種クラスター」のサポートを追加する、RuntimeClass の改良版がベータ版としてすぐに利用可能になります。 C ランタイムクラスのスケジューリング 現在、各ノードが各 RuntimeClass をサポートする必要はまったくありません。ポッドの場合、クラスター トポロジを考慮せずに RuntimeClass を選択できます。 以前は、これを実現するには (ポッドが必要なものすべてをサポートするノード上に配置されるように)、適切なルールを NodeSelector と許容範囲に割り当てる必要がありました。 で KEP 使用例と、もちろん実装の詳細について説明します。

Сеть

Kubernetes 1.16 で初めて (アルファ版で) 登場した XNUMX つの重要なネットワーク機能は次のとおりです。

• サポート デュアルネットワークスタック - IPv4/IPv6 - ポッド、ノード、サービスのレベルでのそれに対応する「理解」。 これには、ポッドから外部サービス、リファレンス実装 (ブリッジ CNI、PTP CNI、およびホストローカル IPAM プラグイン内) に至るポッド間の IPv4 対 IPv4 および IPv6 対 IPv6 の相互運用性が含まれ、実行中の Kubernetes クラスターとの逆互換性も含まれます。 IPv4 または IPv6 のみ。 実装の詳細は次のとおりです KEP.

  ポッドのリストに 4 つのタイプ (IPv6 と IPvXNUMX) の IP アドレスを表示する例:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• エンドポイント用の新しい API - エンドポイントスライス API。 これにより、コントロール プレーンのさまざまなコンポーネント (apiserver、etcd、endpoints-controller、kube-proxy) に影響を与える、既存の Endpoint API のパフォーマンス/スケーラビリティの問題が解決されます。 新しい API は Discovery API グループに追加され、数千のノードで構成されるクラスター内の各サービスで数万のバックエンド エンドポイントにサービスを提供できるようになります。 これを行うために、各サービスは N 個のオブジェクトにマッピングされます EndpointSlice、デフォルトでは、それぞれのエンドポイントは 100 個以下です (値は構成可能です)。 EndpointSlice API は、各ポッドの複数の IP アドレスのサポート、エンドポイントの新しい状態 (だけでなく) など、将来の開発の機会も提供します。 Ready и NotReady)、エンドポイントの動的サブセット化。

前回のリリースで発表されたものはベータ版になりました ファイナライザ、名前付き service.kubernetes.io/load-balancer-cleanup 各サービスに type で付加されます LoadBalancer。 このようなサービスを削除すると、関連するすべてのバランサー リソースの「クリーンアップ」が完了するまで、リソースの実際の削除が防止されます。

API機械

本当の「安定化のマイルストーン」は、Kubernetes API サーバーとそれとの対話の領域にあります。 これは主に次のおかげで起こりました 安定状態への移行 特別な紹介が必要ない方 カスタムリソース定義 （CRD）、Kubernetes 1.7 の遠い昔 (そしてこれは 2017 年 XNUMX 月です!) からベータ版のステータスを持っています。 同じ安定化が関連機能にも適用されました。

• 「サブリソース」 ととも​​に /status и /scale カスタムリソースの場合。
• 変容 外部 Webhook に基づく CRD のバージョン。
• 最近発表された (K8s 1.15 の場合) デフォルト値 (デフォルト) および自動フィールド削除 （剪定） カスタムリソースの場合。
• 機会 OpenAPI v3 スキーマを使用して、サーバー側で CRD リソースを検証するために使用される OpenAPI ドキュメントを作成および公開します。

Kubernetes 管理者にとって長い間馴染みのあるもう XNUMX つのメカニズムは次のとおりです。 入場ウェブフック - これも長い間 (K8s 1.9 以降) ベータ版のままでしたが、現在は安定版と宣言されています。

他の XNUMX つの機能がベータ版に達しました。 サーバー側適用 и 時計のブックマーク.

アルファ版における唯一の重要な革新は、 失敗 から SelfLink — 指定されたオブジェクトを表し、その一部である特別な URI ObjectMeta и ListMeta (つまり、Kubernetes 内のオブジェクトの一部)。 なぜ彼らはそれを放棄するのでしょうか？ シンプルな方法でモチベーションを高める 音 この分野が依然として存在する本当の（圧倒的な）理由がないからです。 より正式な理由は、(不要なフィールドを削除することによって) パフォーマンスを最適化することと、そのようなフィールドを特別な方法で処理することを強制されるジェネリック API サーバーの作業を簡素化することです (これは、オブジェクトの直前に設定される唯一のフィールドです)シリーズ化されています）。 真の陳腐化（ベータ版内） SelfLink Kubernetes バージョン 1.20 までに実現され、最終的には 1.21 になります。

データ保存

以前のリリースと同様に、ストレージ領域の主な作業は、次の領域で観察されます。 CSIサポート。 主な変更点は次のとおりです。

• 初めて (アルファ版で) 出現した Windows ワーカー ノードの CSI プラグインのサポート: 現在のストレージの操作方法では、Kubernetes コアのツリー内プラグインと、Powershell に基づいた Microsoft の FlexVolume プラグインも置き換えられます。

  
  Kubernetes for Windows に CSI プラグインを実装するためのスキーム

• 機会 CSI ボリュームのサイズ変更、K8s 1.12 で導入されましたが、ベータ版に成長しました。
• 同様の「プロモーション」(アルファからベータへ) は、​​CSI を使用してローカルの一時ボリュームを作成する機能によって達成されました (CSI インライン ボリュームのサポート).

以前のバージョンの Kubernetes で導入されました ボリュームクローン作成機能 (既存の PVC を使用 DataSource 新しい PVC を作成する) もベータ版ステータスを取得しました。

プラハ

スケジュールに対する XNUMX つの注目すべき変更 (両方ともアルファ版):

• EvenPodsSpreading - 機会 負荷の「公平な分散」のために論理アプリケーションユニットの代わりにポッドを使用する (Deployment や ReplicaSet のように)、この配分を (ハード要件またはソフト条件、つまり優先度として) 調整します。 この機能は、現在オプションによって制限されている、計画されているポッドの既存の配布機能を拡張します。 PodAffinity и PodAntiAffinityこれにより、管理者はこの問題に関してより細かく制御できるようになり、高可用性が向上し、リソース消費が最適化されることになります。 詳細 - で KEP.
• 使用 ベストフィットポリシー в RequestedToCapacityRatio 優先関数 ポッドの計画中に、 適用する ビンパッキング 基本リソース (プロセッサー、メモリー) と拡張リソース (GPU など) の両方をコンテナーにパッキングします。 詳細については、を参照してください。 KEP.

  
  ポッドのスケジューリング: 最適なポリシーを使用する前 (デフォルトのスケジューラーを介して直接)​​ とその使用時 (スケジューラー エクステンダーを介して)

加えて、 提示される メインの Kubernetes 開発ツリーの外側 (ツリー外) に独自のスケジューラ プラグインを作成する機能。

その他の変更

Kubernetes 1.16 リリースでも注目すべき点があります。 のためのイニシアチブ 持ってくる 利用可能なメトリクスを完全な順序で表示、より正確には、に従って 規程 K8s 計装に。 彼らは主に対応するものに依存しています プロメテウスのドキュメント。 さまざまな理由で不一致が発生し (たとえば、一部のメトリクスは、現在の指示が表示される前に単に作成されただけです)、開発者は、「他の Prometheus エコシステムに合わせて」、すべてを単一の標準に合わせる時期が来たと判断しました。 この取り組みの現在の実装はアルファ ステータスですが、Kubernetes の後続のバージョンではベータ (1.17) および安定版 (1.18) に段階的に昇格されます。

さらに、次のような変更点も確認できます。

• Windows サポート開発 с の出現 この OS 用の Kubeadm ユーティリティ (アルファ版)、 チャンス RunAsUserName Windows コンテナー (アルファ版) の場合、 改善 グループ管理サービス アカウント (gMSA) はベータ版までサポートされます。 サポート vSphere ボリュームのマウント/アタッチ。
• リサイクル API 応答のデータ圧縮メカニズム。 以前は、これらの目的で HTTP フィルターが使用されていましたが、デフォルトで有効にすることができない多くの制限が課せられていました。 「透過的なリクエスト圧縮」が機能するようになりました: クライアントが送信 Accept-Encoding: gzip ヘッダーで、サイズが 128 KB を超える場合は、GZIP 圧縮された応答を受け取ります。 Go クライアントは圧縮 (必要なヘッダーの送信) を自動的にサポートするため、トラフィックの減少にすぐに気づきます。 (他の言語では若干の変更が必要になる場合があります。)
• 可能になった 外部メトリックに基づいて HPA をゼロポッドからゼロポッドにスケーリングする。 オブジェクト/外部メトリックに基づいてスケーリングする場合、ワークロードがアイドル状態のときに自動的に 0 レプリカにスケーリングしてリソースを節約できます。 この機能は、ワーカーが GPU リソースを要求し、さまざまな種類のアイドル状態のワーカーの数が利用可能な GPU の数を超えている場合に特に役立ちます。
• 新しいクライアント - k8s.io/client-go/metadata.Client — オブジェクトへの「一般化された」アクセス用。 メタデータ (つまり、サブセクション) を簡単に取得できるように設計されています。 metadata) をクラスター リソースから取得し、それらを使用してガベージ コレクションとクォータ操作を実行します。
• Kubernetes を構築する 今できる 従来の (「組み込み」ツリー内) クラウド プロバイダー (アルファ版) なし。
• kubeadm ユーティリティへ 追加した 運用中にカスタマイズパッチを適用する実験的（アルファ版）機能 init, join и upgrade。 フラグの使用方法について詳しくは、こちらをご覧ください。 --experimental-kustomizeを参照してください。 KEP.
• apiserver の新しいエンドポイント - readyz, - 準備状況に関する情報をエクスポートできます。 API サーバーにもフラグが追加されました --maximum-startup-sequence-duration、再起動を制御できるようになります。
• 二つ Azureの機能 安定宣言: サポート アベイラビリティーゾーン (アベイラビリティーゾーン) および クロスリソースグループ (RG)。 さらに、Azure は以下を追加しました。
  • 認証サポート AAD と ADFS。
  • 注釈 service.beta.kubernetes.io/azure-pip-name ロードバランサーのパブリックIPを指定します。
  • 機会 настройки LoadBalancerName и LoadBalancerResourceGroup.
• AWS は現在、 サポート Windows 上の EBS および 最適化 EC2 API呼び出し DescribeInstances.
• Kubeadm が独立しました 移住する CoreDNS バージョンをアップグレードする場合の CoreDNS 構成。
• バイナリ etcd 対応する Docker イメージ内 完了しました world-executable により、root 権限を必要とせずにこのイメージを実行できるようになります。 また、etcd移行イメージ 停止した etcd2 バージョンのサポート。
• В クラスター オートスケーラー 1.16.0 基本イメージとして distroless の使用に切り替えられ、パフォーマンスが向上し、新しいクラウド プロバイダー (DigitalOcean、Magnum、Packet) が追加されました。
• 使用/依存ソフトウェアのアップデート: Go 1.12.9、etcd 3.3.15、CoreDNS 1.6.2。

PS

私たちのブログもお読みください:

• «Kubernetes 1.15: 主なイノベーションの概要";
• «Kubernetes 1.14: 主なイノベーションの概要";
• «Kubernetes 1.13: 主なイノベーションの概要";
• «Kubernetes 1.12: 主なイノベーションの概要'。

出所： habr.com