ブログ

What's new in Kubernetes 1.18?

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2020年3月19日にSysdigのVíctor Jiménezが投稿したブログ(https://sysdig.com/blog/whats-new-kubernetes-1-18/)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.18がリリースされます! 1.17における小さなリリースの後、1.18は強力になり、目新しさが詰まっています。 どこから始めますか?

APIサーバーのOIDCディスカバリーやWindowsノードのサポートの強化などの新機能があり、コミュニティに大きな影響を与えます。

また、IngressやAPI Server Network Proxyのように、Alpha状態が長すぎてスポットライトに備えてどのように再検討され準備されているかを見ることができてうれしいです。

さらに、Stableに移行する13の機能を祝う必要があります。すべての新しい変更の1/3あります!

Kubernetes 1.18の新機能の詳細リストは次のとおりです。

Kubernetes 1.18 -編集者のおすすめ:

これらは、このリリースで最もエキサイティングに見える機能です(ymmv):

#1393サービスアカウントトークン発行者のOIDC検出

Kubernetes APIトークンを一般的な認証メカニズムとして使用できるようになると、インフラストラクチャの編成方法が変わる可能性があります。これにより、クラスター間の通信などのサービスをさらに統合し、外部認証サービスを不要にすることでセットアップを簡素化できます。

#1513 CertificateSigningRequest API

Certificate APIは、コアコンポーネントを対象とした別の機能ですが、サードパーティサービスで使用されるようになりました。この機能強化は、Kubernetesがコミュニティのニーズにどのように適応するかを示す例であり、証明書のプロビジョニングがより簡単になるだけでなく、より安全にもなります。

#1441 kubectl debug

この新しいコマンドは、ポッドの実行に関する問題のデバッグに関して大きな違いをもたらします。デバッグコンテナを作成するか、異なる構成でポッドを再デプロイします。これらは、より高速になる一般的なタスクです。

#1301 WindowsでRuntimeClassを実装する

どのポッドをWindowsマシンで実行する必要があるかを指定できると、同じクラスター上でWindowsワークロードとLinuxワークロードを混在させることができ、可能性の新たな次元が開かれます。

#1001 WindowsでのCRI-ContainerDのサポート

これは、WindowsノードでのKubernetesの互換性を向上させるための大きなステップですが、将来のリリースで完全なメリットが得られるまで待つ必要があります。このようなわずかなアップグレードで、KubernetesはWindowsサポートに真剣であることを示しています。

Kubernetes 1.18 core

#1393 サービスアカウントトークン発行者にOIDCディスカバリを提供する

Stage: Alpha

Feature group: auth

Kubernetesサービスアカウント(KSA)は、kubectl --token <the_token_string>などを使用して、トークン(JSON WebトークンまたはJWT)を使用してKubernetes APIに対して認証できます。ただし、現在、Kubernetes APIはこれらのトークンを認証できる唯一のサービスです。

Kubernetes APIサーバーはパブリックネットワークからアクセスできないため(アクセスするべきではありません)、ワークロードによっては認証に別のシステムを使用する必要があります。この例としては、クラスター内から別の場所へなど、クラスター全体での認証があります。

この機能強化の目的は、KSAトークンの有用性を高め、クラスター外部のサービスがAPIサーバーをオーバーロードすることなく、一般的な認証方法としてそれらを使用できるようにすることです。これを実現するために、APIサーバーは、他のデータの中でも特にトークン公開キーを含むOpenID Connect(OIDC)ディスカバリドキュメントを提供します。既存のOIDC認証システムは、これらのキーを使用してKSAトークンを検証できます。

OIDCディスカバリーはServiceAccountIssuerDiscovery機能ゲートを使用して有効にでき、機能させるには設定が必要です。

#853 HPAの構成可能なスケール速度

Stage: Alpha

Feature group: autoscaling

Horizontal Pod Autoscaler(HPA)は、リソース内のポッドの数を自動的にスケーリングして、ワークロードの需要を調整できます。これまでは、クラスター全体のグローバルスケーリング速度のみを定義できました。 ただし、すべてのリソースが同等に重要というわけではありません。 コアサービスを重要度の低いサービスよりも速くスケールアップおよびスケールダウンしたい場合があります。

次に、HPA設定の振る舞いを追加します。

behavior:
   scaleUp:
     policies:
     - type: Percent
       value: 100
       periodSeconds: 15
   scaleDown:
     policies:
     - type: Pods
       value: 4
       periodSeconds: 60 

この例では、ポッドは15秒ごとに2倍にできます。 ダウンスケーリングに関しては、1分ごとに4つのポッドを取り外すことができます。 ドキュメントの完全な構文を確認してください。

#1513 CertificateSigningRequest API

Stage: Major Change to Beta

Feature group: auth

各Kubernetesクラスターには、Certificates APIによって処理されるコアコンポーネント間の通信を保護するために使用されるルート認証局があります。これは便利なため、最終的にはコア以外の使用のために証明書をプロビジョニングするために使用されるようになりました。

この機能強化は、新しい状況を受け入れ、署名プロセスとそのセキュリティの両方を改善することを目的としています。

Registration Authorityの下図にあるAPPROVERは、実際のREQUESTORによってcertificate signing request(CSR)が送信されたことを確認します。 また、REQUESTORがその要求を送信するための適切な権限を持っていることを確認します。

20200324-1.png

スケジューリング

#1451 複数のスケジューリングプロファイルを実行する

Stage: Alpha

Feature group: scheduling

Kubernetesクラスター内のすべてのワークロードが同じというわけではありません。 ほとんどの場合、Webサーバーをできるだけ多くのノードに分散することをお勧めしますが、同じノードにできるだけ多くの遅延に敏感なリソースをバンドルすることができます。 これが、同じクラスター内に複数のスケジューラーを構成し、各ポッドに使用するスケジューラーを指示できる理由です。

ただし、特定の瞬間に各スケジューラーがクラスターの異なるビューを持つことができるため、これは競合状態につながる可能性があります。

この機能強化により、それぞれが独自のschedulerNameを持つ、異なる構成またはプロファイルで1つのスケジューラーを実行できます。ポッドは、使用するプロファイルを定義するためにschedulerNameを使用し続けますが、これらの競合状態を回避して、同じスケジューラーが作業を実行します。

#895 Failureドメイン全体でのEven pod spreading

Stage: Graduating to Beta

Feature group: scheduling

topologySpreadConstraintsを使用すると、ポッドをマルチゾーンクラスター全体に均等に分散するルールを定義できるため、高可用性が正常に機能し、リソースの使用効率が向上します。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

#1258 設定可能なデフォルトのEven Pod Spreadingルールを追加

Stage: Alpha

Feature group: scheduling

ポッドの均等な分散を活用するには、各ポッドに独自の分散ルールが必要であり、これは退屈な作業になる可能性があります。

この機能強化により、独自のtopologySpreadConstraintsを定義していないすべてのポッドにクラスターレベルで適用されるグローバルなdefaultConstraintsを定義できます。

#166 TaintベースのEviction

Stage: Graduating to Stable

Feature group: scheduling

Kubernetes 1.13では、TaintベースのEvictonがアルファからベータに移行します。この機能が有効な場合(--feature-gatesのTaintBasedEvictions = true)、TaintはNodeController(またはkubelet)によって自動的に追加され、Ready NodeConditionに基づいてノードからポッドを排除するための以前のロジックは無効になります。

詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。

ノード

#1539 Hugepage機能の拡張

Stage: Major Change to Stable

Feature group: node

HugePagesは、ハードウェアの最適化によりアクセスを速くするために事前定義された大きいサイズのメモリブロックを予約するメカニズムです。 これは、メモリ内のビッグデータセットを処理するアプリケーション、またはデータベースや仮想マシンなど、メモリアクセスの遅延に敏感なアプリケーションに特に役立ちます。

Kubernetes 1.18では、この機能に2つの機能強化が追加されています。

まず、ポッドはさまざまなサイズのHugePagesを要求できるようになりました。

apiVersion: v1
kind: Pod
...
spec:
  containers:
...
    resources:
      requests:
        hugepages-2Mi: 1Gi
        hugepages-1Gi: 2Gi 

2番目に、HugePagesのコンテナ分離が導入され、ポッドが要求よりも多くのメモリを使用し、リソースが不足するという問題が解決されました。

#688 ポッドオーバーヘッド:ポッドサンドボックスに関連付けられたアカウントリソース、ただし特定のコンテナではない

Stage: Graduating to Beta

Feature group: node

要求されたリソースに加えて、ポッドにはランタイム環境を維持するための追加のリソースが必要です。

PodOverhead機能ゲートを有効にすると、Kubernetesはポッドをスケジュールするときにこのオーバーヘッドを考慮します。 ポッドオーバーヘッドは、admission時に計算および修正され、ポッドのRuntimeClassに関連付けられます。 詳細はこちらをご覧ください。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

#693 Node Topology Manager

Stage: Graduating to Beta

Feature group: node

機械学習、科学計算、および金融サービスは、計算集約型であり、超低遅延を必要とするシステムの例です。これらの種類のワークロードは、コア間をジャンプしたり、他のプロセスと時間を共有したりするのではなく、1つのCPUコアに分離されたプロセスの恩恵を受けます。

Node Topology Managerは、ハードウェアリソース割り当ての調整を集中化するkubeletコンポーネントです。現在のアプローチでは、このタスクをいくつかのコンポーネント(CPUマネージャー、デバイスマネージャー、CNI)に分割しているため、割り当てが最適化されない場合があります。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

#950 起動が遅いポッドにpod-startup liveness-probe holdoff を追加

Stage: Graduating to Beta

Feature group: node

プローブを使用すると、Kubernetesはアプリケーションのステータスを監視できます。ポッドの起動に時間がかかりすぎる場合、これらのプローブはポッドが死んでいると判断し、再起動ループを引き起こします。この機能を使用すると、ポッドが起動を完了するまで他のすべてのプローブを保留するstartupProbeを定義できます。たとえば、「特定のHTTPエンドポイントが利用可能になるまでlivenessをテストしないでください」。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

ネットワーク

#752 EndpointSlice API

Stage: Major Change to Beta

Feature group: network

新しいEndpointSlice APIは、エンドポイントを複数のエンドポイントスライスリソースに分割します。 これにより、大きなエンドポイントオブジェクトに関連する現在のAPIの多くの問題が解決されます。この新しいAPIは、ポッドごとに複数のIPなど、他の将来の機能をサポートするようにも設計されています。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

#508 IPv6 サポートの追加

Stage: Graduating to Beta

Feature group: network

IPv6専用クラスターのサポートは、Kubernetes 1.9でかなり前に導入されました。 この機能はコミュニティによって広くテストされており、現在ベータ版に移行しています。

#1024 NodeLocal DNSCacheがGAへ

Stage: Graduating to Stable

Feature group: network

NodeLocal DNSCacheは、クラスターノードでDNSキャッシングエージェントをDaemonsetとして実行することにより、クラスターDNSのパフォーマンスを向上させ、iptables DNATルールと接続追跡を回避します。ローカルキャッシングエージェントは、クラスターホスト名(デフォルトではcluster.localサフィックス)のキャッシュミスについてkube-dnsサービスを照会します。

このベータ版機能の詳細については、Kubernetes Enhancement Proposal(KEP)ドキュメントのデザインノートを参照してください。

詳しくは、Kubernetesシリーズの新機能1.15のリリースをご覧ください。

#1453 Ingress が V1へ

Stage: Graduating to Beta

Feature group: network

Ingressリソースは、外部HTTPおよびHTTPSルートをサービスとして公開し、クラスター内の他のサービスにアクセスできます。

このAPIオブジェクトはKubernetes 1.1に含まれ、事実上の安定機能になりました。この機能強化により、Ingressの実装間の不整合が解消され、一般的な可用性への道が始まります。

たとえば、パスをプレフィックスまたは完全一致として処理する必要があるかどうかを明示的に指定するpathTypeを定義できるようになりました。Ingress内の複数のパスがリクエストに一致する場合、最も長い一致パスが優先されます。

また、kubernetes.io/ingress.classアノテーションは廃止されました。従って、新しいingressClassNameフィールドとIngressClassリソースを使用する必要があります。

#1507 サービスとエンドポイントへのAppProtocolの追加

Stage: Graduating to Stable

Feature group: network

EndpointSlice APIは、Kubernetes 1.17に新しいAppProtocolフィールドを追加して、各ポートにアプリケーションプロトコルを指定できるようにしました。この拡張により、そのフィールドがServicePortおよびEndpointPortリソースに取り込まれ、ユーザーエクスペリエンスの低下を引き起こしている非標準の注釈が置き換えられます。

Kubernetes 1.18 API

#1040 APIサーバーリクエストのPriorityFairness

Stage: Alpha

Feature group: api-machinery

高負荷時には、Kubernetes APIサーバーが管理タスクとメンテナンスタスクを担当する必要があります。既存の--max-requests-inflightおよび--max-mutating-requests-inflightコマンドラインフラグを使用すると、受信要求を制限できますが、粒度が粗すぎて、トラフィックの多い期間に重要な要求も除外されます。

APIPriorityAndFairness機能ゲートは、apiserverで新しいmax-in-flight要求ハンドラーを有効にします。次に、FlowSchemaオブジェクトを使用してさまざまなタイプの要求を定義し、RequestPriorityオブジェクトを使用してリソースを割り当てることができます。

たとえば、ガベージコレクターは優先度の低いサービスです。

kind: FlowSchema
meta:
  name: system-low
spec:
  matchingPriority: 900
  requestPriority:
    name: system-low
  flowDistinguisher:
    source: user
  match:
  - and:
    - equals:
      field: user
      value: system:controller:garbage-collector 

したがって、ごく少数のリソースをそれに割り当てることができます。

kind: RequestPriority
meta:
  name: system-low
spec:
  assuredConcurrencyShares: 30
  queues: 1
  queueLengthLimit: 1000 

ただし、自己メンテナンスリクエストの方が優先度が高くなります。

kind: RequestPriority
meta:
  name: system-high
spec:
  assuredConcurrencyShares: 100
  queues: 128
  handSize: 6
  queueLengthLimit: 100 

機能強化の提案でさらに例を見つけることができます。

#1601 オプションとコンテキスト処理を標準化するclient-go signature refactor

Stage: Major Change to Stable

Feature group: api-machinery

メソッドのシグネチャーの一貫性を保つために、多くのコアバイナリがKubernetes APIに接続するために使用するライブラリであるclient-goでいくつかのコードリファクタリングが行われました。

これには、いくつかのメソッドにコンテキストオブジェクトを追加することが含まれます。このオブジェクトは、API境界を越えてプロセス間でリクエストスコープの値を運ぶオブジェクトです。 このオブジェクトにアクセスすると、タイムアウトやキャンセル後の呼び出しスレッドの解放、分散トレースのサポートの追加など、いくつかの機能の実装が容易になります。

#576 APIServer ドライラン

Stage: Graduating to Stable

Feature group: api-machinery

ドライランモードでは、実際のAPIリクエストをエミュレートし、リクエストが成功したかどうか(アドミッションコントローラーチェーン、検証、マージの競合など)および/または実際に状態を変更せずに何が起こったかを確認できます。リクエストのレスポンスボディは、非ドライランレスポンスに可能な限り近いものと想定されています。このコア機能は、kubectl diffサブコマンドなどの他のユーザーレベル機能を有効にします。

詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。

#1281 API Server Network Proxy KEP がベータへ

Stage: Graduating to Beta

Feature group: api-machinery

一部の人々(主にクラウドプロバイダー)は、クラスターAPIサーバーをクラスターネットワークではなく個別の制御ネットワークに分離することを好みます。これを達成する1つの方法は、残りのクラスターコンポーネントとの接続を維持しながら、Kubernetes APIサーバーネットワークプロキシを使用することです。

この追加レイヤーを使用すると、メタデータ監査ログや外部へのAPIサーバー接続の検証などの他の機能を有効にできます。

20200324-2.png

この機能強化は、Kubernetes APIサーバーからのSSHトンネルコードの削除や、クラスターネットワークからの制御ネットワークの分離の改善など、いくつかの問題を修正し、一般的な可用性のためにこのプロキシを準備する作業を対象としています。

Kubernetes 1.18におけるWindowsのサポート

#1001 WindowsでCRI-ContainerDをサポート

Stage: Alpha

Feature group: windows

ContainerDは、Kubernetesで動作するOCI準拠のランタイムです。Dockerとは異なり、ContainerDにはWindows Server 2019のホストコンテナサービス(HCS v2)のサポートが含まれており、コンテナの管理方法をより細かく制御でき、Kubernetes APIの互換性を向上できます。

この強化により、Container Runtime Interface(CRI)としてWindowsでContainerD 1.3がサポートされます。 このエンハンスメントページで詳細を確認してください。

#1301 WindowsでRuntimeClassを実装

Stage: Alpha

Feature group: windows

RuntimeClassを使用すると、クラスターに存在するさまざまなタイプのノードを定義できます。次に、runtimeClassNameを使用して、ポッドをデプロイできるノードを指定します。この機能はKubernetes 1.12で導入され、Kubernetes 1.14で大幅に変更されました。

この機能強化により、この機能がWindowsノードに拡張されます。これは、WindowsポッドをWindowsノードにのみデプロイするよう指示する異種クラスターで非常に役立ちます。これは、ポッドをWindows Serverバージョン1903(10.0.18362)に制限するRuntimeClassを定義する方法です。

apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: windows-1903
handler: 'docker'
scheduling:
  nodeSelector:
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.18362'
  tolerations:
  - effect: NoSchedule
    key: windows
    operator: Equal
    value: "true" 

そして、次のようにポッドでruntimeClassNameを使用します。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: windows-1903
  # ... 

拡張機能ページで詳細を確認し、この機能が#1001サポートCRI-ContainerDおよびHyper-Vとどのように相互作用するかを確認してください。

#689 WindowsワークロードのGMSAをサポート

Stage: Graduating to Stable

Feature group: windows

これにより、オペレーターはデプロイメント時にGMSAを選択し、それを使用してコンテナを実行してデータベースやAPIサーバーなどの既存のアプリケーションに組織内での認証と承認の管理方法を変更することなく接続できます。

詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。

#1043 WindowsにおけるRunAsUserName

Stage: Graduating to Stable

Feature group: windows

Kubernetesはグループ管理サービスアカウントをサポートしているため、runAsUserName Windows固有のプロパティを使用して、コンテナのエントリポイントを実行するユーザーを定義できます。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

#995 WindowsにおけるKubeadm

Stage: Graduating to Beta

Feature group: cluster-lifecycle

WindowsノードのサポートはKubernetes 1.14で導入されましたが、Windowsノードをクラスターに参加させる簡単な方法はありませんでした。

Kubernetes 1.16以降、部分的な機能を持つWindowsユーザーはkubeadm joinを使用できます。kubeadm initやkubeadm join --control-planeなどの機能がいくつか欠けています。

詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。

ストレージ

#695 ボリューム所有権の変更をスキップ

Stage: Alpha

Feature group: storage

ボリュームがコンテナ内にバインドマウントされる前に、そのファイルのアクセス許可はすべて、指定されたfsGroup値に変更されます。これは、非常に大きなボリュームでの処理が遅くなり、データベースなどのアクセス許可が重要なアプリケーションも破損します。

この動作を制御するために、新しいFSGroupChangePolicyフィールドが追加されました。Alwaysに設定すると、現在の動作が維持されます。ただし、OnRootMismatchに設定すると、最上位ディレクトリが予想されるfsGroup値と一致しない場合にのみボリュームのアクセス許可が変更されます。

#1412 Immutable SecretsとConfigMaps

Stage: Alpha

Feature group: storage

SecretsおよびConfigMapsに新しいimmutableのフィールドが追加されました。 trueに設定すると、リソースキーで行われた変更は拒否されます。これにより、アプリケーションを破壊するような誤った不正な更新からクラスターを保護します。

二次的な利点は、不変のリソースに由来します。変更されないため、Kubeletは更新を定期的に確認する必要がありません。これにより、スケーラビリティとパフォーマンスが向上します。

ImmutableEmphemeralVolumes機能ゲートを有効にすると、次のことができるようになります。

apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
immutable: true 

ただし、リソースが不変としてマークされると、この変更を元に戻すことはできません。シークレットの削除と再作成のみが可能で、削除されたシークレットを使用するポッドを再作成する必要があります。

#1495 汎用データポピュレーター

Stage: Alpha

Feature group: storage

この機能強化により、ユーザーが事前設定されたボリュームを作成できるようになる基盤が確立されます。たとえば、OSイメージを使用して仮想マシンのディスクを事前に設定したり、データのバックアップと復元を有効にしたりします。

これを実現するために、永続ボリュームのDataSourceフィールドの現在の検証が解除され、任意のオブジェクトを値として設定できるようになります。ボリュームの実装方法に関する実装の詳細は、専用のコントローラーに委任されます。

#770 接続できないCSIボリュームの接続をスキップする

Stage: Graduating to Stable

Feature group: storage

この内部最適化により、NFSや一時的なシークレットのようなボリュームなど、アタッチ/デタッチ操作を必要としないコンテナストレージインターフェイス(CSI)ドライバーのVolumeAttachmentオブジェクトの作成が簡単になります。

これらのドライバーの場合、Kubernetes Attach/Detachコントローラーは常にVolumeAttachmentオブジェクトを作成し、「attached」として報告されるまで待機します この手順をスキップするために、CSIボリュームプラグインが変更されました。

#351 永続的なボリュームソースを使用するrawブロックデバイス

Stage: Graduating to Stable

Feature group: storage

BlockVolumeは、Kubernetes 1.18で一般公開されます。volumeModeの値をblockに設定するだけで、rawブロックデバイスにアクセスできます。ファイルシステムを抽象化せずにrawブロックデバイスを使用する機能により、Kubernetesは、データベースなどの高いI/Oパフォーマンスと低遅延を必要とする高性能アプリケーションのサポートを改善できます。

詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。

#565 CSIブロックストレージのサポート

Stage: Graduating to Stable

Feature group: storage

ファイルシステムを抽象化せずにrawブロックデバイスを使用する機能により、Kubernetesは、データベースなどの高いI/Oパフォーマンスと低遅延を必要とするアプリケーションのサポートを改善できます。

詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。

#603 CSIコールでポッド情報を渡す

Stage: Graduating to Stable

Feature group: storage

CSIのツリー外ストレージドライバーは、Pod名やnamespaceなど、NodePublishリクエストでボリュームを要求したPodに関する情報を受け取ることを選択できます。

CSIドライバーは、この情報を使用して、ボリュームの使用を許可または監査したり、ポッドに合わせたボリュームのコンテンツを生成したりできます。

詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。

#989 許可されたPVCデータソースを拡張する

Stage: Graduating to Stable

Feature group: storage

この機能を使用すると、既存の永続ボリュームを「クローン」できます。 クローンを作成すると、新しい複製ボリュームが既存のボリュームからプロビジョニングされます。

詳しくは、Kubernetesシリーズの新機能の1.15リリースをご覧ください。

他のKubernetes 1.18 機能

#1441 kubectl debug

Stage: Alpha

Feature group: cli

デバッグ機能を拡張するために、新しいkubectl debugコマンドが追加されました。

このコマンドを使用すると、実行中のポッドで一時コンテナを作成し、変更されたPodSpecでポッドを再起動し、host namespaceの特権コンテナを起動して接続できます。

#1020 kubectlパッケージコードのステージングへの移動

Stage: Major Change to Stable

Feature group: cli

このkubectlコードの内部再構築は、kubectlバイナリを自分のリポジトリに移動する最初のステップです。これにより、kubectlをkubernetesコードベースから分離し、ツリー外のプロジェクトがコードを再利用しやすくなりました。

#1333 ベータREST APIまたは機能なしで適合性テストを実行できるようにします

Stage: Beta

Feature group: architecture

この拡張機能は、KubernetesコンポーネントもKubernetes準拠もベータREST APIまたは機能に依存しないようにするために行われた作業を収集します。最終目標は、非GA機能を有効にするためにk3s、Rancher、Openshiftなどの非公式ディストリビューションを必要としないため、ディストリビューション全体の一貫性を確保することです。

#491 Kubectl Diff

Stage: Graduating to Stable

Feature group: cli

kubectl diffは、kubectl applyがクラスターに加える変更のプレビューを提供します。 この機能は、簡単に説明できますが、クラスターオペレーターの日常業務には非常に便利です。このコマンドを機能させるには、APIサーバーでドライラン機能を有効にする必要があることに注意してください。

詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。

#670 Out-of-Tree vSphere Cloud Providerをサポート

Stage: Graduating to Stable

Feature group: cloud-provider

アウトオブツリーvSphereクラウドプロバイダーのサポートを構築します。 これには、kube-controller-managerと同等の機能を持つcloud-controller-managerの十分にテストされたバージョンが含まれます。

この機能は、クラウドプロバイダーのvSphereリポジトリで既に完了しているほとんど実装された作業をキャプチャします。

詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。


以上です! いつものように刺激的。 これらの機能のいずれかを使用する場合は、クラスターをアップグレードする準備をしてください。

これが気に入ったら、以前のKubernetesエディションの新機能をご覧ください。

また、Kubernetesエコシステムの最新情報を楽しみたい場合は、コンテナニュースレターを購読してください。これは、クラウドネイティブエコシステムで発生している最もクールなものを毎月メールで送信します。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top