Clever Geek Handbook

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





Kubernetes- 1.14 が今夜リリースされます。 私たちのブログのために開発した伝統によると、この素晴らしいオープンソース製品の新しいバージョンの重要な変更について話しているところです。



この資料の準備に使用される情報は、Kubernetes拡張トラッキングテーブル 、 CHANGELOG-1.14および関連する問題、プルリクエスト、Kubernetes拡張提案（KEP）から取得されます 。 更新 （3月26日）： 公式リリースの発表もK8sブログに掲載されました。



SIGクラスターライフサイクルからの重要な紹介から始めましょう：Kubernetes 動的フェールオーバークラスター （より正確には、自己ホスト型HA展開） は 、通常の（シングルノードクラスターのコンテキストで） kubeadm



（ init



およびjoin



）コマンドを使用して作成できるようになりました 。 要するに、これのために：







kubeadmで構築されたKubernetes HAクラスターアーキテクチャ



設計提案で実装の詳細を見つけることができます。 この機能は非常に待望されていました。アルファ版はK8s 1.9に戻っていましたが、今だけ登場しました。



API



apply



コマンドと一般に宣言的なオブジェクト管理は 、 kubectl



からkubectl



に移動されkubectl



た。 開発者自身が、 kubectl apply



がKubernetesの構成を扱う基本的な部分であると述べて決定を簡単に説明しkubectl apply



が、「バグがいっぱいで修正が難しい」ため、この機能を通常の形式に戻し、コントロールプレーンに転送する必要があります。 今日の問題のシンプルで説明的な例：







実装の詳細はKEPにあります。 現在入手可能なのはアルファ版です（ベータ版への昇格はKubernetesの次のリリースで計画されています）。



アルファ版では、OpenAPI v3スキームを使用して、（サーバー側の）ユーザー定義K8sリソース（CustomResourceDefinition、CRD）の検証に使用されるCustomResources （CR）でOpenAPIドキュメントを作成および公開する機能が利用可能になりました。 CRD用のOpenAPIを公開すると、クライアント（ kubectl



）がクライアント側で検証を実行し（ kubectl create



およびkubectl apply



一部として）、スキームに従ってドキュメントを発行kubectl apply



（ kubectl explain



）。 詳細はKEPにあります。



既存のログはO_APPEND



フラグ（ O_TRUNC



ではなく）でO_TRUNC



ようになり、状況によってはログの損失を回避し、外部ローテーションユーティリティでログを切り捨てられるようになりました。



また、Kubernetes APIのコンテキストでは、 PodSandbox



およびPodSandboxStatus



フィールドがruntime_handler



れ、ポッドのRuntimeClass



に関する情報を考慮することに注意できます（このクラスについては 、このクラスがアルファバージョンとして表示されたKubernetes 1.12リリースに関するテキストを参照してください ）。 Admission Webhooks は、サポートするAdmissionReview



バージョンを決定する機能を実装しました 。 最後に、Admission Webhooksルールで、アプリケーションのスコープをネームスペースとクラスターフレームに制限できるようになりました。



保管施設



K8s 1.10のリリース以降にベータステータスになっているPersistentLocalVolumes



は安定（GA）として宣言されています。この機能ゲートは無効化されなくなり、Kubernetes 1.17で削除されます。



subPath



としてマウントされたディレクトリ名に、いわゆるDownward APIの環境変数（ポッド名など）を使用するsubPath



が開発されました-新しいsubPathExpr



フィールドの形式で、これで目的のディレクトリ名が決定されます。 当初、この機能はKubernetes 1.11で登場しましたが、1.14ではアルファ版の状態のままでした。



以前のKubernetesリリースと同様に、急速に進化するCSI（Container Storage Interface）には多くの重要な変更が導入されています。



CSI



CSIボリュームのサイズ変更 サポートのサポートが利用可能になりました（アルファ版の一部として）。 これを使用するには、 ExpandCSIVolumes



と呼ばれる機能ゲートと、特定のCSIドライバーでのこの操作のサポートを有効にする必要があります。



アルファ版のCSIのもう1つの機能は、ポッド仕様の一部としてCSIボリュームを直接（つまり、PV / PVCを使用せずに）参照できることです。 これにより、CSIを排他的なリモートデータウェアハウスとして使用する際の制限がなくなり、 ローカルの一時ボリュームの世界への扉が開かれます。 （ ドキュメントの例）を使用するには、 CSIInlineVolume



機能ゲートを有効にする必要があります。



エンドユーザー（システム管理者）にはあまり目立たない、CSIに関連するKubernetesの「内部」の進歩があります...現時点では、開発者は各ストレージプラグインの2つのバージョンをサポートすることを余儀なくされています。 -tree）、および2番目-新しいCSIの一部として（たとえば、 こちらで詳細をお読みください ） 。 これにより、CSIが安定するため、対処しなければならない理解しやすい不便が生じます。 対応するKubernetesポリシーにより、ツリー内プラグインの非推奨APIを単純に非推奨にすることはできません。



これにより、アルファ版は、ツリー内に実装されたプラグインの内部コードをCSIプラグインに移行するプロセスに到達しました。これにより、開発者の懸念はプラグインの1つのバージョンをサポートすることになり、古いAPIとの互換性が維持され、いつものように廃止を宣言します。 次のKubernetesリリース（1.15）までに、すべてのクラウドプロバイダープラグインが移行され、実装はベータステータスを受け取り、デフォルトのK8sインストールでアクティブ化される予定です。 詳細については、 設計提案を参照してください。 この移行により、特定のクラウドプロバイダー（AWS、Azure、GCE、Cinder）によって定義されたボリュームの制限も拒否されました。



さらに、CSIブロックデバイス（ CSIBlockVolume



）のサポートがベータ版に変換されました。



ノード/ Kubelet



メインリソースのメトリックを返すように設計された、Kubeletの新しいエンドポイントのアルファバージョンが表示されます。 一般的に、KubeletがcAdvisorからコンテナの使用に関する統計を取得するために使用した場合、このデータはCRI（Container Runtime Interface）を介してコンテナランタイムから取得されますが、古いバージョンのDockerとの互換性は保持されます。 以前、Kubeletで収集された統計はREST APIを介して提供されていましたが、 /metrics/resource/v1alpha1



あるエンドポイントを使用するようになり/metrics/resource/v1alpha1



。 開発者の長期戦略は、Kubeletが提供する一連のメトリックを最小限にすることです。 ところで、これらのメトリック自体は現在 「コアメトリック」ではなく「リソースメトリック」と呼ばれ、「CPUやメモリなどのファーストクラスリソース」 と呼ばれています。



非常に興味深いニュアンス：プロメテウス形式を使用するさまざまなケースと比較してgRPCエンドポイントのパフォーマンスに明らかな利点があるにもかかわらず（ベンチマークの結果の1つを参照） 、著者はコミュニティのこの監視システムの明確なリーダーシップによりプロメテウステキスト形式を好みました。



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




メトリック用の新しいKubeletエンドポイントでgRPCおよびPrometheus形式を使用した比較パフォーマンステストの1つ。 その他のグラフおよびその他の詳細は、 KEPにあります。



その他の変更点：





CLI



-kフラグがkustomizeとの統合のために cli-runtimeおよびkubectlに追加されました （ところで、現在は別のリポジトリで開発されています）。 特別なkustomizationディレクトリからの追加のYAMLファイルの処理については（それらの使用の詳細については、 KEPを参照してください）：





kustomizationファイルの単純な使用例（ オーバーレイ内でのkustomizeのより複雑な使用も可能です ）



さらに：





その他



安定（GA）ステータスは、次の機能を受け取りました。





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





PS



ブログもご覧ください。





More articles:


All Articles