🙌🏻 🅾️ 🌶️ Kubernetes 1.19：主なイノベーションの概要 👨🏾‍✈️ 👏🏼 🍣

本日、8月25日、Kubernetesの新しいリリースが行われます（合計で約2か月遅れました） -1.19。私たちのブログの伝統に従い、新しいバージョンでの最も重要な変更について話します。

この物質を調製するために使用される情報をから取得され、テーブルを追跡Kubernetesの強化、CHANGELOG-1.19、Sysdigの概要、ならびに関連する問題、プル要求、Kubernetes拡張提案（KEP）。

かなり一般的な性質のいくつかの主要な革新から始めましょう...

Kubernetes 1.19のリリースにより、Kubernetesバージョンの「サポートウィンドウ」が9か月（つまり、過去3回のリリース）から1年（つまり、4回のリリース）に延長されました。どうして？

プロジェクト開発が高速であるため（頻繁にメジャーリリースされる）、Kubernetesクラスター管理者はインストールを更新する時間がないことが判明しました。対応するKEPの作成者は、昨年初めにワーキンググループが実施した調査を参照し、Kubernetesユーザーの約3分の1が本番環境で実行されている廃止されたK8sリリースを扱っていることを示しました:(

調査の時点で、Kubernetesの現在のバージョンは1.13、つまりすべてのK8sユーザーでした1.9および1.10は、その時点でサポートされなくなったリリースで機能しました。）

したがって、Kubernetesリリース（コードで見つかった問題を修正するパッチのリリース）のサポート期間を3か月延長すると、80％以上のユーザーがサポートされているバージョンのK8で作業できるようになると想定されます（現時点で想定されている50〜60％ではありません）。）。

もう1つの大きな開発：構造化ログの標準が開発されました..。コントロールプレーンの現在のロギングシステムは、Kubernetesでのメッセージとオブジェクト参照の均一な構造を保証しないため、このようなログの処理が複雑になります。この問題を解決するために、ログ内のメッセージの新しい構造が導入されました。この構造では、ログを生成するための構造化インターフェイスを提供する新しいメソッドと、ログ内のK8sオブジェクトを識別するための補助メソッドでklogライブラリが拡張されています。

klog v2への移行と同時に、JSONでログを出力するための新しい形式への移行が実行されます。これにより、ログへの要求の実行とその処理が簡素化されます。このために、--logging-formatデフォルトで古いテキスト形式を使用するフラグが表示されます。

Kubernetesリポジトリは巨大であり、著者は構造化ロギングKEPは現実主義者であり、最も一般的なメッセージに新しいアイデアを実現するための努力を集中させます。

klogの新しいメソッドを使用したロギングの図：

klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kubedns"

klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

klog.ErrorS(err, "Failed to update pod status")

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"

JSON形式の使用：

pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")

{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}

もう1つの重要な（そして非常に関連性のある）イノベーションは、廃止されたAPIについて通知するメカニズムであり、ベータ版としてすぐに実装されます（つまり、デフォルトでインストールでアクティブになります）。によって説明異なる状態にし、異なる時間に滞在、多くのKubernetes常に時代遅れの容量で、作者のマイル見通し。すべてのリリースノートを注意深く読み、構成/設定を手動でクリーンアップして、それらを追跡することはほとんど不可能です。

この問題を解決するために、非推奨のAPIを使用すると、応答にヘッダーが追加Warningされ、クライアント側で認識されます（client-go）異なる応答の可能性がある：無視、重複排除、ログ。 kubectlユーティリティでは、これらのメッセージをstderrに出力する方法、コンソールでメッセージを色で強調表示する方法、およびわかりやすい--warnings-as-errors名前のフラグを追加する方法を教えました。

これに加えて、非推奨のAPIと監査注釈の使用を報告するための特別なメトリックが追加されました。

最後に、開発者は ベータ版からのKubernetes機能の進歩に参加しました。プロジェクトの経験が示すように、APIのいくつかの新機能と変更は、すでに自動的に（デフォルトで）アクティブ化されており、ユーザーによる追加のアクションを必要としないため、ベータステータスで「スタック」していました。

これを防ぐために、それがされた提案します 6か月間（2つのリリース）ベータ版であり、次の条件のいずれも満たさない機能を非推奨リストに自動的に送信します。

GA基準を満たし、安定したステータスに昇格します。
以前のベータ版を廃止する新しいベータ版があります。

そして今、それぞれのSIGによって分類されたKubernetes1.19の他の変更について。

ボールト

新しいCSIStorageCapacity オブジェクトは、CSIボリュームを使用するポッドのスケジューリングプロセスを改善することを目的としています。ストレージスペースが不足しているノードには配置されません。このため、使用可能なディスク領域に関する情報はAPIサーバーに保存され、CSIドライバーとスケジューラーが使用できます。現在の実装状況はアルファ版です。詳細については、KEPを参照してください。

アルファ版のもう1つの革新は、ポッド仕様でエフェメラルボリュームを直接定義する機能、一般的なエフェメラルインラインボリューム（KEP）です。）。エフェメラルボリュームは、特定のポッドがスポーンするときに作成され、終了すると削除されます。それらは以前に定義されている可能性がありますが（仕様に直接、つまりインライン方式を含む）、機能自体の一貫性が証明された既存のアプローチは、その使用のすべてのケースを網羅していませんでした。

新しいメカニズムは、動的プロビジョニングをサポートする任意のドライバーのエフェメラルボリュームを定義するためのシンプルなAPIを提供します（以前は、これにはドライバーの変更が必要でした）。これにより、任意のエフェメラルボリューム（CSIとツリー内の両方EmptyDir）を操作でき、使用可能なストレージスペースの追跡という別の新機能（上記で説明）のサポートも提供されます。

新しいエフェメラルボリューム（汎用インライン）を使用した高レベルのKubernetesオブジェクトの例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: scratch
          mountPath: /scratch
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: scratch
        ephemeral:
          metadata:
            labels:
              type: fluentd-elasticsearch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

ここで、DaemonSetコントローラーは、ビュー名を使用してポッドを作成しますfluentd-elasticsearch-b96sd。その後、そのようなポッドにPersistentVolumeClaimが追加されfluentd-elasticsearch-b96sd-scratchます。

また、アルファバージョンとして導入された最後の完全に新しいストレージ機能は、FSGroupベースのアクセス許可（KEP）のサポートをcsidriver.spec.SupportsFSGroup示すCSIドライバーの新しいフィールドです。動機：CSIボリュームの所有権の変更は、コンテナーにマウントされる前に実行されますが、すべてのタイプのストレージがそのような操作（NFSなど）をサポートしているわけではないため、エラーが発生する可能性があります。ベータ版まで（つまり、デフォルトのインクルージョン）：

CSI- Azure vSphere ( , Kubernetes);
Secrets ConfigMaps.

/ Kubelet

Seccompは安定（GA）と宣言されています。特に、この作業により、廃止されたと宣言された注釈ではなく、APIのseccompのフィールドに移行し（新しいKubeletsは注釈を無視します）、PodSecurityPolicyに影響を与えました。

PodSpecに新しいフィールドが追加され、ポッドホストのFQDN（完全修飾ドメイン名）を設定fqdnInHostnameできるようになりました。目標は、Kubernetesのレガシーアプリケーションのサポートを改善することです。著者が彼らの意図を説明する方法は次のとおりです。

« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».

デフォルトではfalse、古い（Kubernetesの場合）動作が保持されます。機能ステータス-アルファバージョン。次のリリース（1.20）で安定していると宣言される予定です。Kubeletによって収集されたアクセラレータメトリック

を放棄することが決定されました。 PodResources APIを介して、外部の監視エージェントによってこのようなメトリックを収集することが提案されています。このAPI自体は、メインのKubernetesリポジトリからすべてのデバイス固有のメトリックを取得し、ベンダーがKubernetesコアに変更を加えることなくそれらを実装できるようにすることを目的として、正確に作成されました。 PodResources APIはベータ版であり（機能ゲートが責任を負いますKubeletPodResources）、まもなく安定します。現在のリリースでは、放棄プロセスはアルファステータスであり、詳細はKEPにあります。

今後、KubeletはDockerなしで構築できます。これにより、作成者はDocker固有のコードがなく、Golangパッケージに依存しないことを意味しますdocker/docker。このイニシアチブの最終的な目標は、完全に「ドッカーレス」（つまり、Dockerに依存しない）Kubeletに到達することです。いつものように、KEPで動機についてもっと読むことができます。この機会はすぐにGAステータスを受け取りました。

前回のK8sリリースでベータ版に到達したNodeTopology Managerに、ポッドレベルでリソースを平準化する機能が追加されました。

スケジューラー

Kubernetes 1.18に戻って、偶数ポッド配布 （Even Pod Spreading）のグローバル構成について記述しましたが、パフォーマンステストの結果に基づいて、この機能を延期することが決定されました。彼女は現在Kubernetesにいます（アルファステータス）。

イノベーションの本質は、これまでのようDefaultConstraintsにPodSpec（からtopologySpreadConstraints）だけでなく、クラスターレベルで、より高いレベルでポッドを配布するためのルールを規制できるようにするグローバル制約（）の追加です。デフォルトの構成は、現在のプラグインと同様になりますDefaultPodTopologySpread。

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

詳細はKEPにあります。

偶数ポッド拡散に関連する別の機能：障害ドメイン（リージョン、ゾーン、ノードなど）によるポッドのグループの配布がアルファからベータに移動されました（デフォルトで有効）。

スケジューラの他の3つの機能は、同様の「増加」を実現しました。

1.18に示されている計画プロファイル（プロファイルのスケジューリング）。
PriorityClassesでポッドプリエンプションを有効/無効にするオプション。
構成ファイルkube-schedulerComponentConfig。

ネットワーク

Ingressリソースは最終的に安定していると宣言さv1れ、APIにバージョンがあります。この点で、かなりの数の更新が関連するドキュメントに示されています。このPRからユーザーに気付く変更には、特に注意を払う必要があります。たとえば、spec.backend→ spec.defaultBackend、serviceName→ service.name、servicePort→ service.port.number...などの名前変更があります

。サービスとエンドポイントのAppProtocolフィールド、およびEndpointSlice API （Linuxのkube-proxyが起動します）デフォルトではEndpointSlicesを使用しますが、Windowsの場合はアルファ版のままです）およびSCTPサポート。

kubeadm

kubeadmユーティリティに2つの新機能（アルファ版）が導入されました。

1つ目は、パッチを使用してkubeadmによって生成されたマニフェストを変更することです。Kustomize（アルファ版）を使用してそれらを変更することはすでに可能でしたが、kubeadm開発者は、通常のパッチを使用することが好ましい方法であると判断しました（Kustomizeは不要な依存関係になるため、歓迎されません）。

今では（フラグを経由して生のパッチを適用することが可能である--experimental-patcheskubeadmコマンドのため）init、joinおよびupgrade、並びにこれらの段階。 Kustomizeベースの実装（フラグ--experimental-kustomize）は非推奨になり、削除されます。

2番目の機能は、コンポーネント構成を操作するための新しいアプローチです。そのkubeadmは動作します。このユーティリティは、デフォルト値を生成、検証、設定し、Kubeletやkube-proxyなどのKubernetesクラスターコンポーネントの構成を（ConfigMapsの形式で）保存します。時間の経過とともに、これには多くの問題が生じることが明らかになりました。kubeadmによって生成された構成とユーザーによって送信された構成を区別する方法（そうでない場合は、構成の移行をどうするか）。デフォルト値のどのフィールドが自動的に生成され、どのフィールドが意図的に設定されましたか？..

これらの問題を解決するために、デフォルト値の設定の拒否（これはコンポーネント自体が行う必要があります）、構成検証自体の委任など、多数の変更が提示されます。コンポーネント、生成された各ConfigMapへの署名など。

また、kubeadmのもう1つの重要性の低い機能は、と呼ばれる機能ゲートですPublicKeysECDSA。これには、kubeadm init ECDSA証明書を使用してクラスターを作成する機能が含まれています。（を介してkubeadm alpha certs renew）既存の証明書を更新することもできますが、RSAとECDSAを簡単に切り替えるメカニズムはありません。

その他の変更

：GAステータスは、認証の分野に3つの機能を受信証明書署名要求API、ノードへのアクセス制限（入場プラグインを介して特定のAPIにNodeRestriction）、ブートストラップの自動更新Kubeletクライアント証明書。
新しいEventAPIも、重複排除へのアプローチが変更されて安定していると宣言されました（イベントによるクラスターの過負荷を回避するため）。
(kube-apiserver, kube-scheduler, etcd ) debian distroless. : , ( — KEP).
Kubelet Docker runtime target-, TargetContainerName EphemeralContainer ( ).
« » .status.conditions, API .
kube-proxy IPv6DualStack Windows ( feature gate).
わかりやすい名前の機能ゲートCSIMigrationvSphere（vSphereの組み込み-ツリー内-プラグインからCSIドライバーへの移行）がベータ版に移行しました。
以下のためのkubectl run 追加フラグ--privileged。
フェーズの後に開始する新しい拡張ポイントがスケジューラーに追加されました- PostFilter、- Filter。
WindowsでのCri-containerdサポートはベータ版に達しました。

依存関係の変更：

kubeadmに含まれるCoreDNSのバージョン-1.7.0;
cri-tools 1.18.0;
CNI（コンテナネットワーキングインターフェイス）0.8.6;
etcd 3.4.9;
使用されるGoのバージョンは1.15.0-rc.1です。

PS

私たちのブログも読んでください：

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