ブログ

Kubernetes 1.17の新機能

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

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

Kubernetes 1.17がリリースされます! この短いサイクルのリリースは、小さな改善と大掃除に焦点を当てています。あらゆる場所に実装の最適化、有望なトポロジー認識ルーティングなどの新機能、デュアルスタックサポートの改善があります。 Kubernetes 1.17の新機能のリストを次に示します。

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

これらは、このリリース(ymmv)でよりエキサイティングに思われる機能です。

Kubernetes 1.17 コア

#1053 Kubeadm machine/structured output

Stage: Alpha

Feature group: cluster-lifecycle

kubernetesクラスターをデプロイする最も一般的な方法は、kubeadmコマンドなどの自動化ツール、またはterraformなどのそれに依存するツールを使用することです。 kubeadmの現在の出力は構造化されていないため、kubeadmを少し変更すると、他のツールとの統合が壊れる可能性があります。

このアルファ機能を使用すると、json、yaml、goテンプレートなどの機械可読構造化形式でkubeadmから出力を取得できます。

デフォルトの出力が次のように出力される場合:

$ kubeadm token list
TOKEN                     TTL         EXPIRES                     USAGES                   DESCRIPTION                                                EXTRA GROUPS
7vg8cr.pks5g06s84aisb27   <invalid>   2019-06-05T17:13:55+03:00   authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token 

-oまたは-experimental-outputフラグを使用すると、構造化バージョンを取得できます。

$ kubeadm token list -o json
{
    "kind": "BootstrapToken",
    "apiVersion": "output.kubeadm.k8s.io/v1alpha1",
    "creationTimestamp": null,
    "token": "7vg8cr.pks5g06s84aisb27",
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "expires": "2019-06-05T14:13:55Z",
    "usages": [
        "authentication",
        "signing"
    ],
    "groups": [
        "system:bootstrappers:kubeadm:default-node-token"
    ]
} 

Kubernetesのドキュメントが更新されるまで、この機能のPRおよびKEPページでいくつかの例を確認できます。

#1143 Kubernetes内のnode-role labelの使用を明確にし、古いコンポーネントをマイグレートする

Stage: Alpha

Feature group: architecture

ラベルのnode-role.kubernetes.io namespaceの最初の目標は、クラスターユーザーにグループ化規則を提供することでした。これらのラベルはオプションであり、管理ツールでのクラスター情報の表示、および同様の重要ではないユースケースのみを対象としています。

使用ガイドラインに反して、一部のコアおよび関連プロジェクトはそれらに依存して動作を変化させ始めたため、一部のクラスターで問題が発生する可能性がありました。

この機能は、ノードロールラベルの適切な使用を明確にするために行われた作業を要約しているので、再度悪用されることはなく、必要に応じてそれらへの依存関係が削除されます。

この機能は、LegacyNodeRoleBehaviorおよびNodeDisruptionExclusion機能ゲートを使用して元に戻すことができる、場合によっては動作の変更を意味します。 詳細については、Kubernetesのドキュメントをご覧ください。

#382 条件によるTaint node

Stage: Graduating to Stable

Feature group: scheduling

1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。

条件によるTaint node機能により、ノードコントローラは、観察されたノード条件に対応するTaintを動的に作成します。 ユーザーは、適切なPodトレランスを追加することにより、ノードの問題(ノード条件として表される)の一部を無視することを選択できます。

#548 kube-schedulerによるDaemonSet Podのスケジュール

Stage: Graduating to Stable

Feature group: scheduling

1.12 Kubernetesリリース以降、デフォルトで有効になったこの機能は、最終的にステーブル版になりました。

DaemonSetコントローラーによってスケジュールされる代わりに、これらのPodはデフォルトのスケジューラーによってスケジュールされます。つまり、Pending状態で作成されたポッドとデーモンセットが表示され、スケジューラーはポッドの優先度とプリエンプションを考慮します。

#495 設定可能なポッドプロセス Namespaceの共有

Stage: Graduating to Stable

Feature group: node

1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。

ユーザーは、PodSpecでオプションを設定することにより、Pod内のコンテナを構成して共通のPID namespaceを共有できます。詳細については、Kubernetesのドキュメントをご覧ください:プロセス namespaceを共有

#589 頻繁なKubeletハートビートをLease APIへ移動

Stage: Graduating to Stable

Feature group: node

node-leasesは、既存のNodeStatusを補完するもので、より軽量でスケーラブルなハートビートインジケータを導入します。

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

ネットワーク

#563 IPv4/IPv6デュアルスタックのサポート

Stage: Major Change to Alpha

Feature group: network

この機能は、クラスターでデュアルスタックモードをネイティブにサポートするために行われた作業を要約しているため、特定のPodにIPv4アドレスとIPv6アドレスの両方を割り当てることができます。

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

1.17では、この機能に関連する3つの主な改善点があります。

  • kube-proxyは、EndpointSlicesとIPVSのデュアルスタックをサポートするようになりました。
  • これで、status.podIPs環境変数を使用して、下位APIを使用してpodIPを設定できます。
  • --node-cidr-mask-size-ipv6は、IPv4の/24値をミラーリングする代わりに、デフォルトで/64になりました。

デュアルスタックは大きなプロジェクトなので、この機能がアルファステージを離れる前に、Kubernetesのリリースに続く新しい改善を期待してください。

#536 トポロジーを認識したサービスのルーティング

Stage: Graduating to Alpha

Feature group: network

複雑なKubernetesのデプロイメントでパフォーマンスを向上させる(およびコストを削減する)には、ネットワークトラフィックを最適化することが不可欠です。サービストポロジは、互いに近いポッド間でトラフィックを維持することにより、トラフィックを最適化します。

この機能は、ServiceTopology機能ゲートによって有効になります。

--feature-gates="ServiceTopology=true"

設定は、タグのリストを含むtopologyKeys設定を介してサービスレベルで行われます。Podは、一致するタグ値を持つエンドポイントとのみ通信できます。

["kubernetes.io/hostname", "topology.kubernetes.io/zone", "*"] 

この例では、トラフィックは可能であれば同じホスト名内のエンドポイントに送信され、そうでない場合は同じゾーン内のノードにフォールバックします。最後の手段として、使用可能なノードを使用します。

サービストポロジの詳細については、この総合的な投稿をご覧ください。

#752 EndpointSlice API

Stage: Graduating to Beta

Feature group: network

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

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

#980 Service LoadBalancersのFinalizer保護

Stage: Graduating to Stable

Feature group: network

関連するサービスが削除された後、クラウドリソースが孤立するさまざまなコーナケースがあります。これを防ぐために、Service LoadBalancersのFinalizer保護が導入されました。

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

Kubernetes 1.17 API

#1152 ウォッチャーごとに同じオブジェクトを個別にシリアル化することを避ける

Stage: Graduating to Stable

Feature group: api-machinery

kube-apiserverのこの最適化により、多くのウォッチが同じオブジェクトのセットを監視している場合のパフォーマンスが向上します。この問題は、エンドポイントオブジェクトの作成などの簡単な操作が完了するまでに数秒かかる場合がある、数千のノードを持つクラスターで顕在化します。

古い実装ではウォッチャーごとに各オブジェクトがシリアル化されるため、問題はオブジェクトのシリアル化の周辺にあります。新しい実装では、キャッシュを使用して、すべてのウォッチャーに対してオブジェクトを1回だけシリアル化します。

この最適化の詳細については、実装の詳細をご覧ください。

#575 カスタムリソースのデフォルト設定

Stage: Graduating to Stable

Feature group: api-machinery

CustomResourceDefinitionsに関連するJSONの処理と処理を促進することを目的とした2つの機能。

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

#956 ウォッチブックマークのサポートを追加

Stage: Graduating to Stable

Feature group: api-machinery

「ブックマーク」監視イベントはチェックポイントとして使用され、クライアントが要求した特定のresourceVersionまでのすべてのオブジェクトが既に送信されたことを示します。APIは、これらすべてのイベントの送信をスキップして、両側での不必要な処理を回避できます。

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

ストレージ

#177 Kubernetesにおけるスナップショット/復元ボリュームのサポート(CRD +外部コントローラー)

Stage: Graduating to Beta

Feature group: storage

1.12 Kubernetesリリース以降のアルファ版では、この機能は最終的にベータ版になりました。

APIリソースPersistentVolumeおよびPersistentVolumeClaimを使用してユーザーおよび管理者のボリュームをプロビジョニングする方法と同様に、VolumeSnapshotContentおよびVolumeSnapshot APIリソースを提供して、ユーザーおよび管理者のボリュームスナップショットを作成できます。ボリュームスナップショットの詳細については、こちらをご覧ください。

#554 ダイナミック最大ボリュームカウント

Stage: Graduating to Stable

Feature group: storage

1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。

ダイナミックボリューム制限機能が有効になっている場合、Kubernetesはノードタイプを自動的に決定し、ノードとベンダーの適切な数の接続可能なボリュームをサポートします。

ダイナミックボリュームリミットの詳細については、Kubernetesのドキュメントをご覧ください。

#557 Kubernetes CSIトポロジーサポート

Stage: Graduating to Stable

Feature group: storage

トポロジーにより、Kubernetesは、Pod用のボリュームをプロビジョニングする最適な場所でスケジューラー入力を取得することにより、ボリュームを動的にプロビジョニングする際にインテリジェントな決定を下すことができます。 ツリー内ストレージプラグインと同等の機能を実現するために、CSIツリー外ストレージプラグインのトポロジ機能が実装されます。

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

#559 sub path mountで環境変数の拡張を提供

Stage: Graduating to Stable

Feature group: storage

システムは、多くの場合、環境変数に応じてマウントパスを定義する必要があります。以前の回避策は、シンボリックリンクを持つサイドカーコンテナを作成することでした。 定型文を避けるために、環境変数をsubPathに追加する可能性を導入します。

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

#625 In-treeストレージプラグインからCSIドライバーへのマイグレーション

Stage: Graduating to Beta

Feature group: storage

ストレージプラグインはもともとKubernetesコードベース内のツリー内にあったため、ベースコードの複雑さが増し、拡張性が妨げられていました。このコードをすべてロード可能なプラグインに移動すると、開発コストが削減され、モジュール化と拡張性が高まります。

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

他のKubernetes 1.17の機能

#837 Promote Cloud ProviderラベルがGA

Stage: Graduating to Stable

Feature group: cloud-provider

ノードとボリュームリソースが作成されると、3つのラベルがそれらに適用され、クラウドプロバイダーに関連する情報が提供されます。しばらくの間ベータ段階にあった後、これらのラベルはステーブル版に昇格されています。 これには、名前の変更、既存のラベルが必要です。

  • beta.kubernetes.io/instance-type
  • failure-domain.beta.kubernetes.io/zone
  • failure-domain.beta.kubernetes.io/region

「ベータ」ラベルを削除するように名前が変更されます。

  • node.kubernetes.io/instance-type
  • topology.kubernetes.io/zone
  • topology.kubernetes.io/region

古い値は非推奨としてマークされ、Kubernetes 1.21では完全に削除されます。

#960 ビヘイビア-ドリブンの適合性テスト

Stage: Graduating to Stable

Feature group: architecture

この機能は、Kubernetes APIのテストスイートを改善する取り組みをまとめたものです。目標は、テストされるAPIエンドポイントだけでなく、各エンドポイントの動作がテストでカバーされる範囲までチェックすることです。

テストツールに興味がある場合は、動作の定義方法と、現在のテストを新しい形式に移行する計画を確認してください。

#714 Kubernetesテストのtarballを分解

Stage: Graduating to Stable

Feature group: testing

Kubernetesリリースアーティファクトに含まれるkubernetes-test.tar.gzファイルには、ポータブルおよびプラットフォーム固有の両方のテストリソースが含まれています。このファイルは徐々に拡大しており、最大1.5GBに達し、テストプロセスを複雑にし、速度を低下させています。

これ以降、このファイルは7つの小さなプラットフォーム固有のバージョンに分割されます。

#1043 WindowsにおけるRunAsUserName

Stage: Graduating to Beta

Feature group: windows

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

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

皆さん! これらの機能のいずれかを使用する場合は、いつものようにエキサイティングな、クラスターをアップグレードする準備をしてください。

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

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

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

最近の投稿

カテゴリー

アーカイブ

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

top