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の新機能のリストを次に示します。
これらは、このリリース（ymmv）でよりエキサイティングに思われる機能です。
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ページでいくつかの例を確認できます。
Stage: Alpha
Feature group: architecture
ラベルのnode-role.kubernetes.io namespaceの最初の目標は、クラスターユーザーにグループ化規則を提供することでした。これらのラベルはオプションであり、管理ツールでのクラスター情報の表示、および同様の重要ではないユースケースのみを対象としています。
使用ガイドラインに反して、一部のコアおよび関連プロジェクトはそれらに依存して動作を変化させ始めたため、一部のクラスターで問題が発生する可能性がありました。
この機能は、ノードロールラベルの適切な使用を明確にするために行われた作業を要約しているので、再度悪用されることはなく、必要に応じてそれらへの依存関係が削除されます。
この機能は、LegacyNodeRoleBehaviorおよびNodeDisruptionExclusion機能ゲートを使用して元に戻すことができる、場合によっては動作の変更を意味します。 詳細については、Kubernetesのドキュメントをご覧ください。
Stage: Graduating to Stable
Feature group: scheduling
1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。
条件によるTaint node機能により、ノードコントローラは、観察されたノード条件に対応するTaintを動的に作成します。 ユーザーは、適切なPodトレランスを追加することにより、ノードの問題（ノード条件として表される）の一部を無視することを選択できます。
Stage: Graduating to Stable
Feature group: scheduling
1.12 Kubernetesリリース以降、デフォルトで有効になったこの機能は、最終的にステーブル版になりました。
DaemonSetコントローラーによってスケジュールされる代わりに、これらのPodはデフォルトのスケジューラーによってスケジュールされます。つまり、Pending状態で作成されたポッドとデーモンセットが表示され、スケジューラーはポッドの優先度とプリエンプションを考慮します。
Stage: Graduating to Stable
Feature group: node
1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。
ユーザーは、PodSpecでオプションを設定することにより、Pod内のコンテナを構成して共通のPID namespaceを共有できます。詳細については、Kubernetesのドキュメントをご覧ください：プロセス namespaceを共有
Stage: Graduating to Stable
Feature group: node
node-leasesは、既存のNodeStatusを補完するもので、より軽量でスケーラブルなハートビートインジケータを導入します。
詳しくは、「Kubernetesの新機能」シリーズの1.14のリリースをご覧ください。
Stage: Major Change to Alpha
Feature group: network
この機能は、クラスターでデュアルスタックモードをネイティブにサポートするために行われた作業を要約しているため、特定のPodにIPv4アドレスとIPv6アドレスの両方を割り当てることができます。
詳しくは、「Kubernetesの新機能」シリーズの1.16のリリースをご覧ください。
1.17では、この機能に関連する3つの主な改善点があります。
デュアルスタックは大きなプロジェクトなので、この機能がアルファステージを離れる前に、Kubernetesのリリースに続く新しい改善を期待してください。
Stage: Graduating to Alpha
Feature group: network
複雑なKubernetesのデプロイメントでパフォーマンスを向上させる（およびコストを削減する）には、ネットワークトラフィックを最適化することが不可欠です。サービストポロジは、互いに近いポッド間でトラフィックを維持することにより、トラフィックを最適化します。
この機能は、ServiceTopology機能ゲートによって有効になります。
--feature-gates="ServiceTopology=true"
設定は、タグのリストを含むtopologyKeys設定を介してサービスレベルで行われます。Podは、一致するタグ値を持つエンドポイントとのみ通信できます。
["kubernetes.io/hostname", "topology.kubernetes.io/zone", "*"]
この例では、トラフィックは可能であれば同じホスト名内のエンドポイントに送信され、そうでない場合は同じゾーン内のノードにフォールバックします。最後の手段として、使用可能なノードを使用します。
サービストポロジの詳細については、この総合的な投稿をご覧ください。
Stage: Graduating to Beta
Feature group: network
新しいEndpointSlice APIは、エンドポイントを複数のエンドポイントスライスリソースに分割します。これにより、大きなエンドポイントオブジェクトに関連する現在のAPIの多くの問題が解決されます。この新しいAPIは、Podごとの複数のIPなど、他の将来の機能をサポートするようにも設計されています。
詳しくは、「Kubernetesの新機能」シリーズの1.16のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: network
関連するサービスが削除された後、クラウドリソースが孤立するさまざまなコーナケースがあります。これを防ぐために、Service LoadBalancersのFinalizer保護が導入されました。
詳しくは、「Kubernetesの新機能」シリーズの1.15のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: api-machinery
kube-apiserverのこの最適化により、多くのウォッチが同じオブジェクトのセットを監視している場合のパフォーマンスが向上します。この問題は、エンドポイントオブジェクトの作成などの簡単な操作が完了するまでに数秒かかる場合がある、数千のノードを持つクラスターで顕在化します。
古い実装ではウォッチャーごとに各オブジェクトがシリアル化されるため、問題はオブジェクトのシリアル化の周辺にあります。新しい実装では、キャッシュを使用して、すべてのウォッチャーに対してオブジェクトを1回だけシリアル化します。
この最適化の詳細については、実装の詳細をご覧ください。
Stage: Graduating to Stable
Feature group: api-machinery
CustomResourceDefinitionsに関連するJSONの処理と処理を促進することを目的とした2つの機能。
詳しくは、「Kubernetesの新機能」シリーズの1.15リリースをご覧ください。
Stage: Graduating to Stable
Feature group: api-machinery
「ブックマーク」監視イベントはチェックポイントとして使用され、クライアントが要求した特定のresourceVersionまでのすべてのオブジェクトが既に送信されたことを示します。APIは、これらすべてのイベントの送信をスキップして、両側での不必要な処理を回避できます。
詳しくは、「Kubernetesの新機能」シリーズの1.15のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: storage
1.12 Kubernetesリリース以降のアルファ版では、この機能は最終的にベータ版になりました。
APIリソースPersistentVolumeおよびPersistentVolumeClaimを使用してユーザーおよび管理者のボリュームをプロビジョニングする方法と同様に、VolumeSnapshotContentおよびVolumeSnapshot APIリソースを提供して、ユーザーおよび管理者のボリュームスナップショットを作成できます。ボリュームスナップショットの詳細については、こちらをご覧ください。
Stage: Graduating to Stable
Feature group: storage
1.12 Kubernetesリリース以降のベータでは、この機能は最終的にステーブル版になりました。
ダイナミックボリューム制限機能が有効になっている場合、Kubernetesはノードタイプを自動的に決定し、ノードとベンダーの適切な数の接続可能なボリュームをサポートします。
ダイナミックボリュームリミットの詳細については、Kubernetesのドキュメントをご覧ください。
Stage: Graduating to Stable
Feature group: storage
トポロジーにより、Kubernetesは、Pod用のボリュームをプロビジョニングする最適な場所でスケジューラー入力を取得することにより、ボリュームを動的にプロビジョニングする際にインテリジェントな決定を下すことができます。 ツリー内ストレージプラグインと同等の機能を実現するために、CSIツリー外ストレージプラグインのトポロジ機能が実装されます。
詳しくは、「Kubernetesの新機能」シリーズの1.14のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: storage
システムは、多くの場合、環境変数に応じてマウントパスを定義する必要があります。以前の回避策は、シンボリックリンクを持つサイドカーコンテナを作成することでした。 定型文を避けるために、環境変数をsubPathに追加する可能性を導入します。
詳しくは、「Kubernetesの新機能」シリーズの1.15のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: storage
ストレージプラグインはもともとKubernetesコードベース内のツリー内にあったため、ベースコードの複雑さが増し、拡張性が妨げられていました。このコードをすべてロード可能なプラグインに移動すると、開発コストが削減され、モジュール化と拡張性が高まります。
詳しくは、「Kubernetesの新機能」シリーズの1.15のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: cloud-provider
ノードとボリュームリソースが作成されると、3つのラベルがそれらに適用され、クラウドプロバイダーに関連する情報が提供されます。しばらくの間ベータ段階にあった後、これらのラベルはステーブル版に昇格されています。 これには、名前の変更、既存のラベルが必要です。
「ベータ」ラベルを削除するように名前が変更されます。
古い値は非推奨としてマークされ、Kubernetes 1.21では完全に削除されます。
Stage: Graduating to Stable
Feature group: architecture
この機能は、Kubernetes APIのテストスイートを改善する取り組みをまとめたものです。目標は、テストされるAPIエンドポイントだけでなく、各エンドポイントの動作がテストでカバーされる範囲までチェックすることです。
テストツールに興味がある場合は、動作の定義方法と、現在のテストを新しい形式に移行する計画を確認してください。
Stage: Graduating to Stable
Feature group: testing
Kubernetesリリースアーティファクトに含まれるkubernetes-test.tar.gzファイルには、ポータブルおよびプラットフォーム固有の両方のテストリソースが含まれています。このファイルは徐々に拡大しており、最大1.5GBに達し、テストプロセスを複雑にし、速度を低下させています。
これ以降、このファイルは7つの小さなプラットフォーム固有のバージョンに分割されます。
Stage: Graduating to Beta
Feature group: windows
Kubernetesがグループ管理サービスアカウントをサポートするようになったので、runAsUserName Windows固有のプロパティを使用して、コンテナーのエントリポイントを実行するユーザーを定義できます。
詳しくは、「Kubernetesの新機能」シリーズの1.16のリリースをご覧ください。
皆さん！ これらの機能のいずれかを使用する場合は、いつものようにエキサイティングな、クラスターをアップグレードする準備をしてください。
これが気に入ったら、以前のKubernetesエディションの新機能をご覧ください。
また、Kubernetesエコシステムの最新情報をお楽しみになりたい場合は、コンテナニュースレターを購読してください。これは、クラウドネイティブエコシステムで行われている最もクールな内容を毎月メールでお知らせします。