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の新機能の詳細リストは次のとおりです。
これらは、このリリースで最もエキサイティングに見える機能です（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サポートに真剣であることを示しています。
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機能ゲートを使用して有効にでき、機能させるには設定が必要です。
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つのポッドを取り外すことができます。 ドキュメントの完全な構文を確認してください。
Stage: Major Change to Beta
Feature group: auth
各Kubernetesクラスターには、Certificates APIによって処理されるコアコンポーネント間の通信を保護するために使用されるルート認証局があります。これは便利なため、最終的にはコア以外の使用のために証明書をプロビジョニングするために使用されるようになりました。
この機能強化は、新しい状況を受け入れ、署名プロセスとそのセキュリティの両方を改善することを目的としています。
Registration Authorityの下図にあるAPPROVERは、実際のREQUESTORによってcertificate signing request（CSR）が送信されたことを確認します。 また、REQUESTORがその要求を送信するための適切な権限を持っていることを確認します。
Stage: Alpha
Feature group: scheduling
Kubernetesクラスター内のすべてのワークロードが同じというわけではありません。 ほとんどの場合、Webサーバーをできるだけ多くのノードに分散することをお勧めしますが、同じノードにできるだけ多くの遅延に敏感なリソースをバンドルすることができます。 これが、同じクラスター内に複数のスケジューラーを構成し、各ポッドに使用するスケジューラーを指示できる理由です。
ただし、特定の瞬間に各スケジューラーがクラスターの異なるビューを持つことができるため、これは競合状態につながる可能性があります。
この機能強化により、それぞれが独自のschedulerNameを持つ、異なる構成またはプロファイルで1つのスケジューラーを実行できます。ポッドは、使用するプロファイルを定義するためにschedulerNameを使用し続けますが、これらの競合状態を回避して、同じスケジューラーが作業を実行します。
Stage: Graduating to Beta
Feature group: scheduling
topologySpreadConstraintsを使用すると、ポッドをマルチゾーンクラスター全体に均等に分散するルールを定義できるため、高可用性が正常に機能し、リソースの使用効率が向上します。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
Stage: Alpha
Feature group: scheduling
ポッドの均等な分散を活用するには、各ポッドに独自の分散ルールが必要であり、これは退屈な作業になる可能性があります。
この機能強化により、独自のtopologySpreadConstraintsを定義していないすべてのポッドにクラスターレベルで適用されるグローバルなdefaultConstraintsを定義できます。
Stage: Graduating to Stable
Feature group: scheduling
Kubernetes 1.13では、TaintベースのEvictonがアルファからベータに移行します。この機能が有効な場合（--feature-gatesのTaintBasedEvictions = true）、TaintはNodeController（またはkubelet）によって自動的に追加され、Ready NodeConditionに基づいてノードからポッドを排除するための以前のロジックは無効になります。
詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。
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のコンテナ分離が導入され、ポッドが要求よりも多くのメモリを使用し、リソースが不足するという問題が解決されました。
Stage: Graduating to Beta
Feature group: node
要求されたリソースに加えて、ポッドにはランタイム環境を維持するための追加のリソースが必要です。
PodOverhead機能ゲートを有効にすると、Kubernetesはポッドをスケジュールするときにこのオーバーヘッドを考慮します。 ポッドオーバーヘッドは、admission時に計算および修正され、ポッドのRuntimeClassに関連付けられます。 詳細はこちらをご覧ください。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: node
機械学習、科学計算、および金融サービスは、計算集約型であり、超低遅延を必要とするシステムの例です。これらの種類のワークロードは、コア間をジャンプしたり、他のプロセスと時間を共有したりするのではなく、1つのCPUコアに分離されたプロセスの恩恵を受けます。
Node Topology Managerは、ハードウェアリソース割り当ての調整を集中化するkubeletコンポーネントです。現在のアプローチでは、このタスクをいくつかのコンポーネント（CPUマネージャー、デバイスマネージャー、CNI）に分割しているため、割り当てが最適化されない場合があります。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: node
プローブを使用すると、Kubernetesはアプリケーションのステータスを監視できます。ポッドの起動に時間がかかりすぎる場合、これらのプローブはポッドが死んでいると判断し、再起動ループを引き起こします。この機能を使用すると、ポッドが起動を完了するまで他のすべてのプローブを保留するstartupProbeを定義できます。たとえば、「特定のHTTPエンドポイントが利用可能になるまでlivenessをテストしないでください」。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
Stage: Major Change to Beta
Feature group: network
新しいEndpointSlice APIは、エンドポイントを複数のエンドポイントスライスリソースに分割します。 これにより、大きなエンドポイントオブジェクトに関連する現在のAPIの多くの問題が解決されます。この新しいAPIは、ポッドごとに複数のIPなど、他の将来の機能をサポートするようにも設計されています。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: network
IPv6専用クラスターのサポートは、Kubernetes 1.9でかなり前に導入されました。 この機能はコミュニティによって広くテストされており、現在ベータ版に移行しています。
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のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: network
Ingressリソースは、外部HTTPおよびHTTPSルートをサービスとして公開し、クラスター内の他のサービスにアクセスできます。
このAPIオブジェクトはKubernetes 1.1に含まれ、事実上の安定機能になりました。この機能強化により、Ingressの実装間の不整合が解消され、一般的な可用性への道が始まります。
たとえば、パスをプレフィックスまたは完全一致として処理する必要があるかどうかを明示的に指定するpathTypeを定義できるようになりました。Ingress内の複数のパスがリクエストに一致する場合、最も長い一致パスが優先されます。
また、kubernetes.io/ingress.classアノテーションは廃止されました。従って、新しいingressClassNameフィールドとIngressClassリソースを使用する必要があります。
Stage: Graduating to Stable
Feature group: network
EndpointSlice APIは、Kubernetes 1.17に新しいAppProtocolフィールドを追加して、各ポートにアプリケーションプロトコルを指定できるようにしました。この拡張により、そのフィールドがServicePortおよびEndpointPortリソースに取り込まれ、ユーザーエクスペリエンスの低下を引き起こしている非標準の注釈が置き換えられます。
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
機能強化の提案でさらに例を見つけることができます。
Stage: Major Change to Stable
Feature group: api-machinery
メソッドのシグネチャーの一貫性を保つために、多くのコアバイナリがKubernetes APIに接続するために使用するライブラリであるclient-goでいくつかのコードリファクタリングが行われました。
これには、いくつかのメソッドにコンテキストオブジェクトを追加することが含まれます。このオブジェクトは、API境界を越えてプロセス間でリクエストスコープの値を運ぶオブジェクトです。 このオブジェクトにアクセスすると、タイムアウトやキャンセル後の呼び出しスレッドの解放、分散トレースのサポートの追加など、いくつかの機能の実装が容易になります。
Stage: Graduating to Stable
Feature group: api-machinery
ドライランモードでは、実際のAPIリクエストをエミュレートし、リクエストが成功したかどうか（アドミッションコントローラーチェーン、検証、マージの競合など）および/または実際に状態を変更せずに何が起こったかを確認できます。リクエストのレスポンスボディは、非ドライランレスポンスに可能な限り近いものと想定されています。このコア機能は、kubectl diffサブコマンドなどの他のユーザーレベル機能を有効にします。
詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。
Stage: Graduating to Beta
Feature group: api-machinery
一部の人々（主にクラウドプロバイダー）は、クラスターAPIサーバーをクラスターネットワークではなく個別の制御ネットワークに分離することを好みます。これを達成する1つの方法は、残りのクラスターコンポーネントとの接続を維持しながら、Kubernetes APIサーバーネットワークプロキシを使用することです。
この追加レイヤーを使用すると、メタデータ監査ログや外部へのAPIサーバー接続の検証などの他の機能を有効にできます。
この機能強化は、Kubernetes APIサーバーからのSSHトンネルコードの削除や、クラスターネットワークからの制御ネットワークの分離の改善など、いくつかの問題を修正し、一般的な可用性のためにこのプロキシを準備する作業を対象としています。
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がサポートされます。 このエンハンスメントページで詳細を確認してください。
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とどのように相互作用するかを確認してください。
Stage: Graduating to Stable
Feature group: windows
これにより、オペレーターはデプロイメント時にGMSAを選択し、それを使用してコンテナを実行してデータベースやAPIサーバーなどの既存のアプリケーションに組織内での認証と承認の管理方法を変更することなく接続できます。
詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: windows
Kubernetesはグループ管理サービスアカウントをサポートしているため、runAsUserName Windows固有のプロパティを使用して、コンテナのエントリポイントを実行するユーザーを定義できます。
詳しくは、Kubernetesシリーズの新機能の1.16のリリースをご覧ください。
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のリリースをご覧ください。
Stage: Alpha
Feature group: storage
ボリュームがコンテナ内にバインドマウントされる前に、そのファイルのアクセス許可はすべて、指定されたfsGroup値に変更されます。これは、非常に大きなボリュームでの処理が遅くなり、データベースなどのアクセス許可が重要なアプリケーションも破損します。
この動作を制御するために、新しいFSGroupChangePolicyフィールドが追加されました。Alwaysに設定すると、現在の動作が維持されます。ただし、OnRootMismatchに設定すると、最上位ディレクトリが予想されるfsGroup値と一致しない場合にのみボリュームのアクセス許可が変更されます。
Stage: Alpha
Feature group: storage
SecretsおよびConfigMapsに新しいimmutableのフィールドが追加されました。 trueに設定すると、リソースキーで行われた変更は拒否されます。これにより、アプリケーションを破壊するような誤った不正な更新からクラスターを保護します。
二次的な利点は、不変のリソースに由来します。変更されないため、Kubeletは更新を定期的に確認する必要がありません。これにより、スケーラビリティとパフォーマンスが向上します。
ImmutableEmphemeralVolumes機能ゲートを有効にすると、次のことができるようになります。
apiVersion: v1 kind: Secret metadata: ... data: ...
immutable: true
ただし、リソースが不変としてマークされると、この変更を元に戻すことはできません。シークレットの削除と再作成のみが可能で、削除されたシークレットを使用するポッドを再作成する必要があります。
Stage: Alpha
Feature group: storage
この機能強化により、ユーザーが事前設定されたボリュームを作成できるようになる基盤が確立されます。たとえば、OSイメージを使用して仮想マシンのディスクを事前に設定したり、データのバックアップと復元を有効にしたりします。
これを実現するために、永続ボリュームのDataSourceフィールドの現在の検証が解除され、任意のオブジェクトを値として設定できるようになります。ボリュームの実装方法に関する実装の詳細は、専用のコントローラーに委任されます。
Stage: Graduating to Stable
Feature group: storage
この内部最適化により、NFSや一時的なシークレットのようなボリュームなど、アタッチ/デタッチ操作を必要としないコンテナストレージインターフェイス（CSI）ドライバーのVolumeAttachmentオブジェクトの作成が簡単になります。
これらのドライバーの場合、Kubernetes Attach/Detachコントローラーは常にVolumeAttachmentオブジェクトを作成し、「attached」として報告されるまで待機します この手順をスキップするために、CSIボリュームプラグインが変更されました。
Stage: Graduating to Stable
Feature group: storage
BlockVolumeは、Kubernetes 1.18で一般公開されます。volumeModeの値をblockに設定するだけで、rawブロックデバイスにアクセスできます。ファイルシステムを抽象化せずにrawブロックデバイスを使用する機能により、Kubernetesは、データベースなどの高いI/Oパフォーマンスと低遅延を必要とする高性能アプリケーションのサポートを改善できます。
詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: storage
ファイルシステムを抽象化せずにrawブロックデバイスを使用する機能により、Kubernetesは、データベースなどの高いI/Oパフォーマンスと低遅延を必要とするアプリケーションのサポートを改善できます。
詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: storage
CSIのツリー外ストレージドライバーは、Pod名やnamespaceなど、NodePublishリクエストでボリュームを要求したPodに関する情報を受け取ることを選択できます。
CSIドライバーは、この情報を使用して、ボリュームの使用を許可または監査したり、ポッドに合わせたボリュームのコンテンツを生成したりできます。
詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: storage
この機能を使用すると、既存の永続ボリュームを「クローン」できます。 クローンを作成すると、新しい複製ボリュームが既存のボリュームからプロビジョニングされます。
詳しくは、Kubernetesシリーズの新機能の1.15リリースをご覧ください。
Stage: Alpha
Feature group: cli
デバッグ機能を拡張するために、新しいkubectl debugコマンドが追加されました。
このコマンドを使用すると、実行中のポッドで一時コンテナを作成し、変更されたPodSpecでポッドを再起動し、host namespaceの特権コンテナを起動して接続できます。
Stage: Major Change to Stable
Feature group: cli
このkubectlコードの内部再構築は、kubectlバイナリを自分のリポジトリに移動する最初のステップです。これにより、kubectlをkubernetesコードベースから分離し、ツリー外のプロジェクトがコードを再利用しやすくなりました。
Stage: Beta
Feature group: architecture
この拡張機能は、KubernetesコンポーネントもKubernetes準拠もベータREST APIまたは機能に依存しないようにするために行われた作業を収集します。最終目標は、非GA機能を有効にするためにk3s、Rancher、Openshiftなどの非公式ディストリビューションを必要としないため、ディストリビューション全体の一貫性を確保することです。
Stage: Graduating to Stable
Feature group: cli
kubectl diffは、kubectl applyがクラスターに加える変更のプレビューを提供します。 この機能は、簡単に説明できますが、クラスターオペレーターの日常業務には非常に便利です。このコマンドを機能させるには、APIサーバーでドライラン機能を有効にする必要があることに注意してください。
詳細については、Kubernetesシリーズの新機能1.13のリリースをご覧ください。
Stage: Graduating to Stable
Feature group: cloud-provider
アウトオブツリーvSphereクラウドプロバイダーのサポートを構築します。 これには、kube-controller-managerと同等の機能を持つcloud-controller-managerの十分にテストされたバージョンが含まれます。
この機能は、クラウドプロバイダーのvSphereリポジトリで既に完了しているほとんど実装された作業をキャプチャします。
詳しくは、Kubernetesシリーズの新機能1.14のリリースをご覧ください。
以上です！ いつものように刺激的。 これらの機能のいずれかを使用する場合は、クラスターをアップグレードする準備をしてください。
これが気に入ったら、以前のKubernetesエディションの新機能をご覧ください。
また、Kubernetesエコシステムの最新情報を楽しみたい場合は、コンテナニュースレターを購読してください。これは、クラウドネイティブエコシステムで発生している最もクールなものを毎月メールで送信します。