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

今夜 起こる Kubernetes の次のリリース - 1.14。 私たちのブログで培われてきた伝統に従って、この素晴らしいオープンソース製品の新バージョンにおける重要な変更点について話します。

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

SIG クラスターのライフサイクルからの重要な紹介から始めましょう。 動的フェイルオーバークラスター Kubernetes (より正確に言えば、セルフホスト型 HA デプロイメント) は現在、 作成することができます (単一ノードクラスターのコンテキストで) 使い慣れたコマンドを使用する kubeadm (init и join）。 つまり、これについては次のようになります。

• クラスターによって使用される証明書はシークレットに転送されます。
• K8s クラスター内で etcd クラスターを使用できるようにする (つまり、以前に存在していた外部依存関係を取り除く) etcd オペレーター;
• フォールト トレラント構成を提供する外部ロード バランサーの推奨設定を文書化します (将来的にはこの依存関係を排除する予定ですが、現段階ではそうではありません)。

kubeadm で作成された Kubernetes HA クラスターのアーキテクチャ

実装の詳細については、以下を参照してください。 デザイン提案。 この機能は本当に待望されていました。アルファ版は K8s 1.9 の時点で期待されていましたが、今になってようやく登場しました。

API

チーム apply 一般的に 宣言型オブジェクト管理 合格した の kubectl アピサーバーで。 開発者自身が自分たちの決定を次のように簡単に説明しています。 kubectl apply - これは Kubernetes で構成を操作する基本的な部分ですが、「バグが多く修正が難しい」ため、この機能を通常の状態に戻してコントロール プレーンに転送する必要があります。 現在存在する問題の単純かつ明確な例:

実装の詳細については、 KEP。 現在の準備はアルファ版です (ベータ版への昇格は次の Kubernetes リリースで予定されています)。

アルファ版で利用可能になりました 機会 OpenAPI v3 スキームを使用して、 CustomResources の OpenAPI ドキュメントの作成と公開 (CR) K8s ユーザー定義リソース (CustomResourceDefinition、CRD) を (サーバー側で) 検証するために使用されます。 CRD 用の OpenAPI を公開すると、クライアント (例: kubectl）あなたの側で検証を実行します（内で） kubectl create и kubectl apply) スキームに従って文書を発行します (kubectl explain）。 詳細 - で KEP.

既存のログ 今オープンしています 旗付き O_APPEND （ではない O_TRUNC) 状況によってはログの損失を回避し、ローテーションのために外部ユーティリティを使用してログを切り詰める際に便利です。

また、Kubernetes API のコンテキストでは、次のことに注意してください。 PodSandbox и PodSandboxStatus 追加した フィールド runtime_handler ～に関する情報を記録する RuntimeClass ポッド内 (詳細については本文を参照してください) Kubernetes 1.12 リリース、このクラスはアルファ版として登場しました)、およびアドミッション Webhook で 実装されました どのバージョンを決定する機能 AdmissionReview 彼らはサポートします。 最後に、アドミッション Webhook ルールが追加されました。 制限できる 名前空間とクラスター フレームワークによる使用の範囲。

保管

PersistentLocalVolumes、リリース以来ベータ版の状態でした K8s 1.10, 発表した 安定版 (GA): この機能ゲートは無効ではなくなり、Kubernetes 1.17 で削除される予定です。

機会 という環境変数を使用します 下向きAPI (ポッド名など) としてマウントされたディレクトリの名前 subPath、新しい分野の形で開発されました subPathExpr、これは目的のディレクトリ名を決定するために使用されるようになりました。 この機能は最初に Kubernetes 1.11 で登場しましたが、1.14 ではアルファ版のままでした。

以前の Kubernetes リリースと同様に、現在開発中の CSI (Container Storage Interface) に対して多くの重要な変更が導入されています。

CSI

利用可能になりました（アルファ版の一部として） サポート CSI ボリュームのサイズ変更。 これを使用するには、と呼ばれる機能ゲートを有効にする必要があります。 ExpandCSIVolumes、および特定の CSI ドライバーでのこの操作のサポートの存在。

アルファ版の CSI のもう XNUMX つの機能 - 機会 ポッド仕様内の CSI ボリュームを直接 (つまり、PV/PVC を使用せずに) 参照します。 これ 排他的なリモート データ ストレージとしての CSI の使用に関する制限を削除します。、彼らに世界への扉を開く ローカル一時ボリューム。 使用する場合（ドキュメントからの例) を有効にする必要があります CSIInlineVolume 特徴的なゲート。

CSI に関連する Kubernetes の「内部」でも進歩がありましたが、エンド ユーザー (システム管理者) にはあまり見えません... 現在、開発者は各ストレージ プラグインの 8 つのバージョンをサポートする必要があります。古い方法」、KXNUMXs コードベース内 (ツリー内)、および XNUMX 番目 - 新しい CSI の一部として (詳細については、たとえば、 ここで)。 これにより、当然の不都合が生じますが、CSI 自体が安定するにつれて対処する必要があります。 内部 (ツリー内) プラグインの API を単純に非推奨にすることはできません。 関連する Kubernetes ポリシー.

これらすべてが、アルファ版が到達したという事実につながりました。 移行プロセス 内部プラグインコード、CSI プラグインのツリー内として実装されます。これにより、開発者の心配はプラグインの 1.15 つのバージョンをサポートすることで軽減され、古い API との互換性は維持され、通常のシナリオでは古い API であると宣言できます。 Kubernetes の次のリリース (8) までに、すべてのクラウド プロバイダー プラグインが移行され、実装はベータ ステータスを取得し、KXNUMXs インストールでデフォルトでアクティブ化されることが予想されます。 詳細については、を参照してください。 デザイン提案。 この移行により、次のような結果も得られました。 失敗 特定のクラウドプロバイダー (AWS、Azure、GCE、Cinder) によって定義されたボリューム制限から。

さらに、CSI によるブロック デバイスのサポート (CSIBlockVolume) 転送された ベータ版へ。

ノード/Kubelet

アルファ版が発表されました 新しいエンドポイント Kubelet で、のために設計されています 主要なリソースのメトリクスを返す。 一般的に言えば、以前 Kubelet が cAdvisor からコンテナの使用状況に関する統計を受け取っていた場合、現在ではこのデータは CRI (Container Runtime Interface) を介してコンテナ ランタイム環境から取得されますが、古いバージョンの Docker と連携するための互換性も維持されます。 以前は、Kubelet で収集された統計は REST API 経由で送信されていましたが、現在はエンドポイントが次の場所にあります。 /metrics/resource/v1alpha1。 開発者の長期戦略 から成る Kubelet によって提供されるメトリクスのセットを最小限に抑えることです。 ちなみに、これらの指標自体は 今彼らは電話をかけます 「コアメトリクス」ではなく「リソースメトリクス」であり、「CPUやメモリなどの第一級のリソース」として説明されます。

非常に興味深いニュアンス: Prometheus 形式を使用するさまざまなケースと比較して、gRPC エンドポイントのパフォーマンス上の明らかな利点にもかかわらず (以下のいずれかのベンチマークの結果を参照してください)、コミュニティにおけるこの監視システムの明確なリーダーシップにより、著者らは Prometheus のテキスト形式を好みました。

「gRPC は主要な監視パイプラインと互換性がありません。 エンドポイントは、メトリクスを Metrics Server に配信する場合、または Metrics Server と直接統合するコンポーネントを監視する場合にのみ役立ちます。 Metrics Server でキャッシュを使用する場合の Prometheus テキスト形式のパフォーマンス 十分です コミュニティで Prometheus が広く採用されているため、私たちは gRPC よりも Prometheus を優先します。 OpenMetrics 形式がより安定すると、プロトベースの形式で gRPC のパフォーマンスにアプローチできるようになります。」

メトリクス用の新しい Kubelet エンドポイントで gRPC と Prometheus 形式を使用した場合の比較パフォーマンス テストの XNUMX つ。 その他のグラフやその他の詳細については、次のサイトを参照してください。 KEP.

その他の変更点は次のとおりです。

• Kubelet の現在 (XNUMX 回) 止めようとしている 再起動および削除操作の前に、コンテナーは不明な状態にあります。
• 使用している場合 PodPresets 今度は初期化コンテナに移動します 追加されます 通常のコンテナと同じ情報です。
• クベレット 使い始めた usageNanoCores CRI 統計プロバイダーから、および Windows 上のノードとコンテナーから 追加した ネットワーク統計。
• オペレーティング システムとアーキテクチャの情報がラベルに記録されるようになりました kubernetes.io/os и kubernetes.io/arch ノード オブジェクト (ベータ版から GA に転送)。
• ポッド内のコンテナーに特定のシステム ユーザー グループを指定する機能 (RunAsGroup、 に登場 K8s 1.11) 高度 ベータ版の前 (デフォルトで有効)。
• cAdvisor で使用される du と find、 と取り換える Go の実装。

CLI

cli-runtime と kubectl の場合 追加されました との統合のための -k フラグ カスタマイズする (ちなみに、その開発は現在別のリポジトリで実行されています)、つまり特別な kustomization ディレクトリから追加の YAML ファイルを処理します (使用方法の詳細については、「 KEP):

簡単なファイルの使用例 カスタマイズ (kusTOMize のより複雑なアプリケーションは、 オーバーレイ)

さらに：

• 追加した 新しいチーム kubectl create cronjob、その名前自体が物語っています。
• В kubectl logs 今できる 組み合わせる フラグ -f (--follow ストリーミング ログの場合）および -l (--selector ラベルクエリの場合)。
• キューブクル 教えた ワイルドカードで選択したファイルをコピーします。
• チームに kubectl wait 追加した フラグ --all 指定したリソース タイプの名前空間内のすべてのリソースを選択します。

他人

次の機能は安定版 (GA) ステータスを取得しています。

• ReadinessGate、ポッドの準備状態で考慮される追加の条件を定義するためにポッド仕様で使用されます。
• 大きなページのサポート (機能ゲートと呼ばれる) HugePages);
• カスタムポッドDNS;
• PriorityClass API ポッドの優先順位とプリエンプション.

Kubernetes 1.14 で導入されたその他の変更:

• デフォルトの RBAC ポリシーでは API アクセスが許可されなくなりました discovery и access-review 認証のないユーザー (未認証).
• 公式 CoreDNS サポート によって提供された Linux のみ。そのため、kubeadm を使用してクラスター内にデプロイ (CoreDNS) する場合、ノードは Linux 上でのみ実行する必要があります (この制限のために nodeSelector が使用されます)。
• デフォルトの CoreDNS 構成は次のとおりです 使用する フォワードプラグイン プロキシの代わりに。 また、CoreDNSでは 追加した readinessProbe。適切な (サービスの準備ができていない) ポッドでのロード バランシングを防ぎます。
• kubeadm では、フェーズについて init または upload-certs, 可能になった 新しいコントロールプレーンを kubeadm-certs シークレットに接続するために必要な証明書をロードします (フラグを使用します) --experimental-upload-certs).
• Windows インストール用のアルファ版が登場しました サポート gMSA (グループ管理サービス アカウント) - コンテナーでも使用できる Active Directory の特別なアカウント。
• G.C.Eの場合 アクティブ化された etcd と kube-apiserver 間の mTLS 暗号化。
• 使用/依存ソフトウェアの更新: Go 1.12.1、CSI 1.1、CoreDNS 1.3.1、kubeadm での Docker 18.09 のサポート。サポートされる Docker API の最小バージョンは 1.26 になりました。

PS

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

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

出所： habr.com