これは、このセクションの複数ページの印刷可能なビューです。印刷するには、ここをクリックしてください.

Kubernetesブログ

Kubernetes v1.33: 思い描いていたとおりに動作するようになったImage Pull Policy！
Kubernetes v1.33: HorizontalPodAutoscalerの設定可能な許容値
Kubernetes v1.33: Octarine
kube-scheduler-simulatorの紹介
Kubernetes v1.33の先行紹介
Kubernetes v1.32: Penelope
Kubernetes Upstream Training in Japanの取り組みの紹介
Kubernetes 1.31: Fine-grained SupplementalGroups control
Kubernetes 1.31: SPDYからWebSocketへのストリーミングの移行
Kubernetes v1.31: キャッシュからの整合性のある読み込みによるクラスターパフォーマンスの向上
Kubernetes v1.31: Elli
Client-Goへのフィーチャーゲートの導入: 柔軟性と管理性を強化するために
SIG Nodeの紹介
Kubernetesの10年間の歴史
Kubernetes史上最大の移行作業を完了
Gateway API v1.1: サービスメッシュ、GRPCRoute、そして更なる進化
DIY: Kubernetesで自分だけのクラウドを構築しよう(パート3)
DIY: Kubernetesで自分だけのクラウドを構築しよう(パート2)
DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)
Kubernetes v1.30をそっと覗く
CRI-O: OCIレジストリからのseccompプロファイルの適用
SIG Cloud Providerの取り組みの紹介
Kubernetesブッククラブを覗く
Kubernetesでコンテナを別ファイルシステムに格納する設定方法
SIG Releaseスポットライト(リリース・チーム・サブプロジェクト)
フォレンジックコンテナ分析
Kubernetes 1.26: PodDisruptionBudgetによって保護された不健全なPodに対する退避ポリシー
Kubernetesにおけるフォレンジックコンテナチェックポイント処理
更新: dockershimの削除に関するFAQ
Don't Panic: Kubernetes and Docker

Kubernetes v1.33: 思い描いていたとおりに動作するようになったImage Pull Policy！

By Ben Petersen (Microsoft), Stanislav Láznička (Microsoft) | 2025.05.12

思い描いていたとおりに動作するようになったImage Pull Policy！

Kubernetesには意外な挙動がいくつか存在しますが、imagePullPolicyの挙動もその一つかもしれません。 KubernetesがPodの実行を本質とするものであることを踏まえると、認証が必要なイメージに対してPodのアクセスを制限しようとする際に、10年以上前からissue 18787という形で注意点が存在していたことを知ると、意外に思うかもしれません。この10年越しの問題が解決されるリリースは、非常に興奮すべきものです。

備考:

このブログ記事全体を通して「Podの認証情報」という用語が頻繁に使われます。この文脈においては、この用語は、一般的にコンテナイメージのプルを認証するためにPodが利用できる認証情報全体を指します。

IfNotPresent、たとえ本来持つべきでないとしても

この問題の要点は、imagePullPolicy: IfNotPresentという設定が、まさに文字通りの意味でしか動作せず、それ以上のことは一切行ってこなかったという点です。ここで、とあるシナリオを考えてみましょう。まず、Namespace X内のPod AがNode 1にスケジュールされ、プライベートリポジトリからimage Fooを必要とする状況を考えます。イメージプル時の認証情報として、このPodはimagePullSecretsのSecret 1を参照しています。 Secret 1には、プライベートリポジトリからイメージをプルするために必要な認証情報が含まれています。 KubeletはPod Aから提供されたSecret 1の認証情報を使用し、レジストリからcontainer image Fooをプルすることになります。これが意図した(かつ安全な)動作です。

しかし、ここからが興味深いところです。 Namespace Y内のPod Bも、たまたまNode 1にスケジュールされたとします。このとき、予期しない(かつ潜在的に安全でない)事態が発生します。 Pod BはIfNotPresentのイメージプルポリシーを指定し、同じプライベートイメージを参照しているかもしれません。しかし、Pod BはimagePullSecretsでSecret 1(あるいは本例では、いかなるSecretも)を指定していません。 KubeletがこのPodを実行しようとすると、IfNotPresentのポリシーが尊重されます。 Kubeletは、image Fooがすでにローカルに存在していることを確認し、そのimage FooをPod Bに提供します。つまり、Pod Bはそもそも、そのイメージをプルする権限を示す認証情報を一切提供していないにもかかわらず、そのイメージを実行できてしまうのです。

プライベートイメージへアクセスしようとする2つのPodの処理の図。1つ目のPodはpull secretを持ち、2つ目のPodは持たない。 — 異なるPodによってプルされたプライベートイメージを使用する

IfNotPresentは、イメージがノード上にすでに存在している場合にはimage Fooをプルすべきではありませんが、ノードにスケジュールされたすべてのPodが、過去にプルされたプライベートイメージへアクセスできてしまうというのは、セキュリティ上不適切な構成です。これらのPodはそもそも、そのイメージをプルする権限を全く与えられていなかったのです。

IfNotPresent、ただし本来アクセス権がある場合に限る

Kubernetes v1.33では、SIG AuthとSIG Nodeがついにこの(非常に古くからある)問題への対応を開始し、適切な検証が行われるようになりました！基本的な期待される挙動は変更されていません。イメージが存在しない場合、Kubeletはそのイメージをプルしようとします。その際には、各Podが提供する認証情報が使用されます。この挙動は1.33以前と同様です。

イメージがすでに存在している場合、Kubeletの挙動は変化します。これからは、KubeletはPodにそのイメージの使用を許可する前に、そのPodの認証情報を検証するようになります。

この機能の改修にあたっては、パフォーマンスとサービスの安定性も考慮されています。同じ認証情報を使用するPodは、再認証を要求されることはありません。これは、Podが同じKubernetesのSecretオブジェクトから認証情報を取得している場合には、たとえその認証情報がローテーションされていたとしても、当てはまります。

Never pull、ただし認証されている場合に限る

imagePullPolicy: Neverオプションは、イメージを取得しません。ただし、コンテナイメージがすでにノード上に存在する場合、そのプライベートイメージを使用しようとするすべてのPodは、認証情報の提示が求められ、その認証情報は検証されます。

同じ認証情報を使用するPodは、再認証を要求されることはありません。一方で、以前にそのイメージのプルに成功した認証情報を提示しないPodには、プライベートイメージの使用が許可されません。

Always pull、ただし認証されている場合に限る

imagePullPolicy: Alwaysは、これまでも意図おりに動作してきました。イメージが要求されるたびに、そのリクエストはレジストリに送られ、レジストリ側で認証チェックが実行されます。

以前は、プライベートなコンテナイメージが、すでにイメージをプル済みのノード上で他のPodに再利用されないようにする唯一の手段は、Podのアドミッション時に強制的にAlwaysのイメージプルポリシーを適用することでした。

幸いにも、この方法はある程度パフォーマンスに優れていました。プルされるのはイメージそのものではなく、イメージマニフェストだけだったからです。しかしながら、それでもコストとリスクは存在していました。新しいロールアウト、スケールアップ、またはPodの再起動の際には、イメージを提供するレジストリが認証チェックのために必ず利用可能でなければならず、その結果、クラスター内で稼働するサービスの安定性において、イメージレジストリがクリティカルパスに置かれることになります。

仕組みについて

この機能は、各ノードに存在する永続的なファイルベースのキャッシュに基づいて動作します。以下は、この機能がどのように動作するかの簡略化された説明です。完全な仕様については、KEP-2535をご参照ください。

初めてイメージをリクエストする際の処理の流れは、以下のとおりです:

プライベートレジストリからイメージを要求するPodが、ノードにスケジュールされる。
要求されたイメージが、当該ノード上に存在しない。
Kubeletは、そのイメージをプルしようとしている状態であることを示す記録を作成する。
Kubeletは、Podにimage pull secretとして指定されたKubernetesのSecretから認証情報を抽出し、それを使用してプライベートレジストリからイメージを取得します。。
イメージのプルに成功すると、Kubeletはその成功を記録する。この記録には、使用された認証情報(ハッシュ形式)および、それらの認証情報を取得するために使われたSecretの情報も含まれる。
Kubeletは、元のプルしようとしている状態であることを示す記録を削除する。
Kubeletは、プルに成功したことを示す記録を後の利用のために保持する。

後に、同じノードにスケジュールされた別のPodが、以前にプルされたプライベートイメージを要求した場合の処理は次のとおりです:

Kubeletは、その新しいPodがプルのために提供した認証情報を確認する。
その認証情報のハッシュ、またはその認証情報の元となったSecretが、以前のプル成功時に記録されたハッシュまたはSecretと一致する場合、そのPodには以前にプルされたイメージの使用が許可される。
認証情報またはその認証情報の元となるSecretが、そのイメージに関するプル成功記録の中に存在しない場合、Kubeletはその新しい認証情報を使ってリモートレジストリからの再プルを試み、認証フローを開始する。

試してみよう

Kubernetes v1.33では、この機能のアルファ版がリリースされました。実際に試してみるには、バージョン1.33のKubeletにおいて、KubeletEnsureSecretPulledImagesフィーチャーゲートを有効にしてください。

この機能や追加のオプション設定の詳細については、Kubernetes公式ドキュメントのイメージの概要ページをご覧ください。

今後の予定

今後のリリースにおいて、以下の対応を予定しています:

Kubeletイメージ認証プロバイダ用の投影サービスアカウントトークンとの連携を実現します。これにより、ワークロードに特化した新しいイメージプル認証情報の供給元が追加されます。
この機能のパフォーマンスを計測し、将来的な変更の影響を評価するためのベンチマークスイートを作成します。
各イメージプル要求のたびにファイルを読み込む必要がなくなるように、インメモリキャッシュ層を実装します。
認証情報の有効期限をサポートし、以前に検証済みの認証情報でも強制的に再認証するようにします。

参加するには

これらの変更について詳しく理解するには、KEP-2535を読むのが最適です。

さらに関わりたい方は、Kubernetes Slackの#sig-auth-authenticators-devチャンネルで私たちにご連絡ください(招待を受けるにはhttps://slack.k8s.io/をご確認ください)。また、隔週水曜日に開催されているSIG Authのミーティングへの参加も歓迎です。

Kubernetes v1.33: HorizontalPodAutoscalerの設定可能な許容値

By Jean-Marc François (Google) | 2025.04.28

この投稿では、Kubernetes 1.33で初めて利用可能になった新しいアルファ機能である、HorizontalPodAutoscalerの設定可能な許容値 について説明します。

これは何ですか？

水平Pod自動スケーリングは、Kubernetesのよく知られた機能であり、リソース使用率に基づいてレプリカを追加または削除することで、ワークロードのサイズを自動的に調整できます。

たとえば、Kubernetesクラスターで50個のレプリカを持つWebアプリケーションが稼働しているとします。 HorizontalPodAutoscaler(HPA)をCPU使用率に基づいてスケーリングするように構成し、目標使用率を75%に設定します。現在の全レプリカにおけるCPU使用率が目標の75%を上回る90%であると仮定します。このとき、HPAは次の式を使用して必要なレプリカ数を計算します。

$$desiredReplicas = ceil\left\lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \right\rceil$$

この例の場合では、下記のようになります。

$$50 \times (90/75) = 60$$

そのため、HPAは各Podの負荷を軽減するために、レプリカ数を50から60に増やします。同様に、CPU使用率が75%を下回った場合は、HPAがそれに応じてレプリカ数を縮小します。 Kubernetesのドキュメントでは、スケーリングアルゴリズムの詳細な説明が提供されています。

小さなメトリクスの変動があるたびにレプリカが作成または削除されるのを防ぐために、Kubernetesはヒステリシスの仕組みを適用しています。現在の値と目標値の差が10%を超えた場合にのみ、レプリカ数を変更します。上記の例では、現在値と目標値の比率は$90/75$、すなわち目標を20%上回っており、10%の許容値を超えているため、スケールアップが実行されます。

この10%というデフォルトの許容値はクラスター全体に適用されるものであり、これまでのKubernetesのリリースでは細かく調整することができませんでした。多くの用途には適していますが、10%の許容値が数十個のPodに相当するような大規模なデプロイメントには粗すぎます。その結果、コミュニティでは、この値を調整可能にしてほしいという要望が以前から寄せられてきました。

Kubernetes v1.33では、これが可能になりました。

どうやって使うのか？

Kubernetes v1.33クラスターでHPAConfigurableToleranceフィーチャーゲートを有効にした後、HorizontalPodAutoscalerオブジェクトに対して希望する許容値を設定できます。

許容値はspec.behavior.scaleDownおよびspec.behavior.scaleUpフィールドの下に指定され、スケールアップとスケールダウンで異なる値を設定することが可能です。典型的な使い方としては、スケールアップには小さな許容範囲(スパイクに素早く反応するため)、スケールダウンには大きな許容範囲(メトリクスの小さな変動に対してレプリカを過剰に追加・削除しないようにするため)を指定することが挙げられます。

たとえば、スケールダウンに対して5%の許容値を、スケールアップに対して許容値を指定しないHPAは、次のようになります。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  ...
  behavior:
    scaleDown:
      tolerance: 0.05
    scaleUp:
      tolerance: 0

すべての詳細を知りたい！

すべての技術的な詳細については、KEP-4951を参照してください。また、issue 4951をフォローすることで、この機能の安定版への移行についての通知を受け取ることができます。

Kubernetes v1.33: Octarine

By Kubernetes v1.33 Release Team | 2025.04.23

編集者: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav

前回のリリースと同様に、Kubernetes v1.33リリースでは新しいGA、ベータ、アルファの機能が導入されています。高品質なリリースの継続的な提供は、私たちの開発サイクルの強さとコミュニティからの活発なサポートを示しています。

このリリースには64個の機能改善が含まれています。それらのうち、GAへの昇格が18個、ベータへの移行が20個、アルファとしての導入が24個、機能の非推奨化及び撤回が2個となっています。

また、このリリースにはいくつかの注目すべき非推奨化と削除があります。まだ古いバージョンのKubernetesを実行している場合は、これらに必ず目を通してください。

リリースのテーマとロゴ

Kubernetes v1.33のテーマはOctarine: 魔法の色¹で、テリー・プラチェットの ディスクワールド シリーズに着想を得ています。

このリリースは、Kubernetesがエコシステム全体で可能にするオープンソースの魔法²を強調しています。

ディスクワールドの世界に詳しい方なら、"見えざる大学"の塔の上に止まった小さな沼ドラゴンが、アンク・モルポークの街の上に64の星³と共に浮かぶKubernetesの月を見上げる様子を思い浮かべていることでしょう。

Kubernetesが10年の節目を迎え新たな10年へ踏み出すにあたり、私たちはメンテナーの魔術、新しいコントリビューターの好奇心、そしてプロジェクトを推進する協力的な精神を祝福します。 v1.33リリースは、プラチェットが書いたように、「やり方を知っていても、それはまだ魔法だ」 ということを思い出させてくれます。 Kubernetesのコードベースの詳細をすべて知っていたとしても、リリースサイクルの終わりに立ち止まってみると、Kubernetesはまだ魔法のままであることがわかるでしょう。

Kubernetes v1.33は、真に卓越したものを生み出すために世界中の何百人ものコントリビューター⁴が協力する、オープンソースイノベーションの持続的な力の証です。あらゆる新機能の背後には、プロジェクトを維持・改善したり、安全性や信頼性を担保したり、計画通りにリリースしたりといったKubernetesコミュニティの働きがあります。

_{1. Octarineはディスクワールド世界の神話上の8番目の色で、「蛍光の緑がかった黄紫色」と表現される架空の色です。
秘術に調律された人々—魔法使い、魔女、そしてもちろん猫にのみ見えます。
一般人は目を閉じた時のみこの色を感じることができるとされています。
そして時々、IPテーブルのルールを長時間見つめてきた人にも見えるようになります。}
_{2. 「十分に発達した技術は魔法と区別がつかない」ですよね…？}
_{3. v1.33にも64のKEP(Kubernetes Enhancement Proposals)が含まれていますが、これは偶然ではありません。}
_{4. v1.33のプロジェクト活動状況セクションをご覧ください 🚀}

主なアップデート情報

Kubernetes v1.33は新機能と改善点が満載です。このセクションでは、リリースチームが特に注目して欲しい、選りすぐりのアップデート内容をご紹介します！

GA: サイドカーコンテナ

サイドカーパターンでは、ネットワーキング、ロギング、メトリクス収集などの分野における追加機能を処理するために、別途補助的なコンテナをデプロイする必要があります。サイドカーコンテナはv1.33でGAに昇格しました。

Kubernetesでは、restartPolicy: Alwaysが設定された、特別な種類のinitコンテナとしてサイドカーを実装しています。サイドカーは、アプリケーションコンテナより先に起動し、Podのライフサイクル全体を通じて実行され続け、アプリケーションコンテナの終了を待ってから自動的に終了することが保証されます。

さらに、サイドカーはprobe(startup、readiness、liveness)を使用して動作状態を通知できる他、メモリ不足時の早期終了を防ぐため、Out-Of-Memory(OOM)スコア調整がプライマリコンテナと揃えられています。

詳細については、サイドカーコンテナをお読みください。

この作業はSIG Nodeが主導したKEP-753: Sidecar Containersの一環として行われました。

ベータ: Podの垂直スケーリングのためのインプレースなリソースリサイズ

ワークロードはDeployment、StatefulSetなどのAPIを使用して定義できます。これらはメモリやCPUリソース、また実行すべきPodの数(レプリカ数)を含む、実行されるべきPodのテンプレートを示しています。ワークロードはPodのレプリカ数を更新することで水平方向にスケールしたり、Podのコンテナに必要なリソースを更新することで垂直方向にスケールしたりできます。この機能改善が入る前、Podのspecで定義されたコンテナリソースは不変であり、これらの詳細をPodテンプレート内で更新するにはPodの置き換えが必要でした。

しかし、再起動無しで既存のPodのリソース設定を動的に更新できるとしたらどうでしょうか？

KEP-1287は、まさにそのようなインプレースPod更新を可能にするためのものです。これはv1.27でアルファとしてリリースされ、v1.33でベータに昇格しました。これにより、ステートフルなプロセスをダウンタイムなしで垂直方向にスケールアップしたり、トラフィックが少ない時シームレスにスケールダウンすることができます。さらには起動時に大きなリソースを割り当てて、初期設定が完了したら削減したりするなど、さまざまな可能性が開かれます。

この作業はSIG NodeとSIG Autoscalingが主導したKEP-1287: In-Place Update of Pod Resourcesの一環として行われました。

アルファ: `.kuberc`によるkubectl向けユーザー設定の新しい記述オプション

v1.33にて、kubectlは新しいアルファ機能として、ユーザー設定をクラスター設定と分けて明示的に記述するファイル、.kubercを導入します。このファイルにはkubectlのエイリアスや上書き設定(例えばServer-Side Applyをデフォルトで使用するなど)を含めることができますが、クラスター認証情報やホスト情報はkubeconfigに残しておく必要があります。

この分離によって、対象クラスターや使用するkubeconfigに関わらず、kubectlの操作に関わるユーザー設定は同じ物を使い回せるようになります。

このアルファ機能を有効にするためには、環境変数KUBECTL_KUBERC=trueを設定し、.kuberc設定ファイルを作成して下さい。デフォルトの状態では、kubectlは~/.kube/kubercにこのファイルが無いか探します。 --kubercフラグを使用すると、代わりの場所を指定することもできます。

例: kubectl --kuberc /var/kube/rc

この作業はSIG CLIが主導したKEP-3104: Separate kubectl user preferences from cluster configsの一環として行われました。

GAに昇格した機能

これはv1.33リリース後にGAとなった改善点の一部です。

インデックス付きJobのインデックスごとのバックオフ制限

このリリースでは、インデックス付きJobのインデックスごとにバックオフ制限を設定できる機能がGAに昇格しました。従来、Kubernetes JobのbackoffLimitパラメーターは、Job全体が失敗とみなされる前の再試行回数を指定していました。この機能強化により、インデックス付きJob内の各インデックスが独自のバックオフ制限を持つことができるようになり、個々のタスクの再試行動作をより細かく制御できるようになりました。これにより、特定のインデックスの失敗がJob全体を早期に終了させることなく、他のインデックスが独立して処理を継続できるようになります。

この作業はSIG Appsが主導したKEP-3850: Backoff Limit Per Index For Indexed Jobsの一環として行われました。

Job成功ポリシー

.spec.successPolicyを使用してユーザーはどのPodインデックスが成功する必要があるか(succeededIndexes)、何個のPodが成功する必要があるか(succeededCount)、またはその両方の組み合わせを指定できます。この機能は、部分的な完了で十分なシミュレーションやリーダーの成功だけがJobの全体的な結果を決定するリーダー・ワーカーパターンなど、さまざまなワークロードに利点をもたらします。

この作業はSIG Appsが主導したKEP-3998: Job success/completion policyの一環として行われました。

バインドされたServiceAccountトークンのセキュリティ改善

この機能強化では一意のトークン識別子(すなわちJWT IDクレーム、JTIとも呼ばれる)やノード情報をトークン内に含めることで、より正確な検証と監査を可能にする機能などが導入されました。さらに、ノード固有の制限をサポートし、トークンが指定されたノードでのみ使用可能であることを保証することで、トークンの不正使用や潜在的なセキュリティ侵害のリスクを低減します。これらの改善は現在一般提供され、Kubernetesクラスター内のサービスアカウントトークンの全体的なセキュリティ態勢を強化することを目的としています。

この作業はSIG Authが主導したKEP-4193: Bound service account token improvementsの一環として行われました。

kubectlでのサブリソースサポート

--subresource引数が現在kubectlのサブコマンド(get、patch、edit、apply、replaceなど)で一般提供されるようになり、ユーザーはそれらをサポートするすべてのリソースのサブリソースを取得および更新できるようになりました。サポートされているサブリソースの詳細については、Subresourcesをご覧ください。

この作業はSIG CLIが主導したKEP-2590: Add subresource support to kubectlの一環として行われました。

複数のサービスCIDR

この機能強化では、サービスIPの割り当てロジックの新しい実装が導入されました。クラスター全体で、type: ClusterIPの各サービスには一意のIPアドレスが割り当てられる必要があります。既に割り当てられている特定のClusterIPでサービスを作成しようとすると、エラーが返されます。更新されたIPアドレス割り当てロジックは、ServiceCIDRとIPAddressという2つの新しく安定化したAPIオブジェクトを使用します。現在一般提供されているこれらのAPIにより、クラスター管理者は(新しいServiceCIDRオブジェクトを作成することで)type: ClusterIPサービスに利用可能なIPアドレスの数を動的に増やすことができます。

この作業はSIG Networkが主導したKEP-1880: Multiple Service CIDRsの一環として行われました。

kube-proxyの`nftables`バックエンド

kube-proxyのnftablesバックエンドがGAになり、Kubernetesクラスター内のサービス実装のパフォーマンスとスケーラビリティを大幅に向上させる新しい実装が追加されました。互換性の理由から、Linuxノードではデフォルトでiptablesのままです。試してみたい場合はMigrating from iptables mode to nftablesをご確認ください。

この作業はSIG Networkが主導したKEP-3866: nftables kube-proxy backendの一環として行われました。

`trafficDistribution: PreferClose`によるTopology Aware Routing

このリリースでは、Topology Aware Routingとトラフィック分散がGAに昇格し、マルチゾーンクラスターでのサービストラフィックを最適化できるようになりました。 EndpointSliceのTopology Aware Hintによりkube-proxyなどのコンポーネントは同じゾーン内のエンドポイントへのトラフィックルーティングを優先できるようになり、レイテンシーとクロスゾーンデータ転送コストが削減されます。これを基に、Serviceの仕様にtrafficDistributionフィールドが追加され、PreferCloseオプションによりネットワークトポロジーに基づいて最も近い利用可能なエンドポイントにトラフィックが誘導されます。この構成はゾーン間通信を最小限に抑えることでパフォーマンスとコスト効率を向上させます。

この作業はSIG Networkが主導したKEP-4444: Traffic Distribution for ServicesとKEP-2433: Topology Aware Routingの一環として行われました。

SMT非対応ワークロードを拒否するオプション

この機能はCPUマネージャーにポリシーオプションを追加し、Simultaneous Multithreading(SMT)構成に適合しないワークロードを拒否できるようにしました。現在一般提供されているこの機能強化により、PodがCPUコアの排他的使用を要求する場合、CPUマネージャーはSMT対応システムで完全なコアペア(プライマリスレッドと兄弟スレッド両方を含む)の割り当てを強制できるようになり、ワークロードが意図しない方法でCPUリソースを共有するシナリオを防止します。

この作業はSIG Nodeが主導したKEP-2625: node: cpumanager: add options to reject non SMT-aligned workloadの一環として行われました。

`matchLabelKeys`と`mismatchLabelKeys`を使用したPodアフィニティまたはアンチアフィニティの定義

matchLabelKeysとmismatchLabelKeysフィールドがPodアフィニティ条件で利用可能になり、ユーザーはPodが共存する(アフィニティ)または共存しない(アンチアフィニティ)べき範囲を細かく制御できるようになりました。これらの新しく安定化したオプションは、既存のlabelSelectorメカニズムを補完します。 affinityフィールドは、多用途なローリングアップデートの強化されたスケジューリングや、グローバル構成に基づいてツールやコントローラーによって管理されるサービスの分離を容易にします。

この作業はSIG Schedulingが主導したKEP-3633: Introduce MatchLabelKeys to Pod Affinity and Pod Anti Affinityの一環として行われました。

Podトポロジー分散制約スキューの計算時にtaintとtolerationを考慮する

この機能強化はPodTopologySpreadにnodeAffinityPolicyとnodeTaintsPolicyという2つのフィールドを導入しました。これらのフィールドにより、ユーザーはノード間のPod分散のスキュー(偏り)を計算する際にノードアフィニティルールとノードテイントを考慮すべきかどうかを指定できます。デフォルトでは、nodeAffinityPolicyはHonorに設定されており、Podのノードアフィニティまたはセレクターに一致するノードのみが分散計算に含まれることを意味します。 nodeTaintsPolicyはデフォルトでIgnoreに設定されており、指定されない限りノードテイントは考慮されないことを示します。この機能強化によりPod配置のより細かい制御が可能になり、Podがアフィニティとテイント許容の両方の要件を満たすノードにスケジュールされることを保証し、制約を満たさないためにPodが保留状態のままになるシナリオを防止します。

この作業はSIG Schedulingが主導したKEP-3094: Take taints/tolerations into consideration when calculating PodTopologySpread skewの一環として行われました。

Volume Populators

v1.24でベータとしてリリースされた後、Volume Populators はv1.33でGAに昇格しました。この新しく安定化した機能は、ユーザーがPersistentVolumeClaim(PVC)クローンやボリュームスナップショットだけでなく、様々なソースからのデータでボリュームを事前に準備する方法を提供します。このメカニズムはPersistentVolumeClaim内のdataSourceRefフィールドに依存しています。このフィールドは既存のdataSourceフィールドよりも柔軟性が高く、カスタムリソースをデータソースとして使用することができます。

特別なコントローラーであるvolume-data-source-validatorは、VolumePopulatorという名前のAPI種別のための新しく安定化したCustomResourceDefinition(CRD)と共に、これらのデータソース参照を検証します。 VolumePopulator APIにより、ボリュームポピュレーターコントローラーはサポートするデータソースのタイプを登録できます。ボリュームポピュレーターを使用するには、適切なCRDでクラスターをセットアップする必要があります。

この作業はSIG Storageが主導したKEP-1495: Generic data populatorsの一環として行われました。

PersistentVolumeの再利用ポリシーを常に尊重する

この機能強化はPersistent Volume(PV)の再利用ポリシーが一貫して尊重されない問題に対処したもので、ストレージリソースのリークを防ぎます。具体的にはPVがその関連するPersistent Volume Claim(PVC)より先に削除された場合、再利用ポリシー(Delete)が実行されず、基盤となるストレージアセットがそのまま残ってしまう可能性がありました。これを緩和するために、Kubernetesは関連するPVにファイナライザーを設定し、削除順序に関係なく再利用ポリシーが適用されるようになりました。この機能強化により、ストレージリソースの意図しない保持を防ぎ、PVライフサイクル管理の一貫性を維持します。

この作業はSIG Storageが主導したKEP-2644: Always Honor PersistentVolume Reclaim Policyの一環として行われました。

ベータの新機能

これはv1.33リリース後にベータとなった改善点の一部です。

Windowsのkube-proxyにおけるDirect Service Return (DSR)のサポート

DSRは、ロードバランサーを経由するリターントラフィックがロードバランサーをバイパスしてクライアントに直接応答できるようにすることでパフォーマンスを最適化します。これによりロードバランサーの負荷が軽減され、全体的なレイテンシーも低減されます。 Windows上のDSRに関する情報は、Direct Server Return (DSR) in a nutshellをお読みください。

v1.14で最初に導入されたDSRのサポートは、KEP-5100: Support for Direct Service Return (DSR) and overlay networking in Windows kube-proxyの一環としてSIG Windowsによりベータに昇格しました。

構造化パラメーターのサポート

構造化パラメーターのサポートはKubernetes v1.33でベータ機能として継続される中、Dynamic Resource Allocation(DRA)のこの中核部分に大幅な改善が見られました。新しいv1beta2バージョンはresource.k8s.io APIを簡素化し、名前空間クラスターのeditロールを持つ一般ユーザーが現在DRAを使用できるようになりました。

kubeletは現在シームレスなアップグレードサポートを含み、DaemonSetとしてデプロイされたドライバーがローリングアップデートメカニズムを使用できるようになっています。 DRA実装では、これによりResourceSliceの削除と再作成が防止され、アップグレード中も変更されないままにすることができます。さらに、ドライバーの登録解除後にkubeletがクリーンアップを行う前に30秒の猶予期間が導入され、ローリングアップデートを使用しないドライバーのサポートが向上しました。

この作業はSIG Node、SIG Scheduling、SIG Autoscalingを含む機能横断チームであるWG Device ManagementによるKEP-4381: DRA: structured parametersの一環として行われました。

ネットワークインターフェース向けDynamic Resource Allocation(DRA)

v1.32で導入されたDRAによるネットワークインターフェースデータの標準化された報告がv1.33でベータに昇格しました。これにより、よりネイティブなKubernetesネットワークの統合が可能になり、ネットワークデバイスの開発と管理が簡素化されます。これについては以前にv1.32リリース発表ブログで説明されています。

この作業はSIG Network、SIG Node、およびWG Device Managementが主導したKEP-4817: DRA: Resource Claim Status with possible standardized network interface dataの一環として行われました。

スケジューラーが`activeQ`にPodを持たない場合に、スケジュールされていないPodを早期に処理

この機能はキュースケジューリングの動作を改善します。裏側では、スケジューラーはactiveQが空の場合に、エラーによってバックオフされていないPodをbackoffQからポップすることでこれを実現しています。以前は、activeQが空の場合でもスケジューラーはアイドル状態になってしまいましたが、この機能強化はそれを防止することでスケジューリング効率を向上させます。

この作業はSIG Schedulingが主導したKEP-5142: Pop pod from backoffQ when activeQ is emptyの一環として行われました。

Kubernetesスケジューラーにおける非同期プリエンプション

プリエンプションは、優先度の低いPodを退避させることで、優先度の高いPodが必要なリソースを確保できるようにします。 v1.32でアルファとして導入された非同期プリエンプションがv1.33でベータに昇格しました。この機能強化により、Podを削除するためのAPIコールなどの重い操作が並行して処理されるようになり、スケジューラーは遅延なく他のPodのスケジューリングを継続できます。この改善は特にPodの入れ替わりが激しいクラスターやスケジューリングの失敗が頻繁に発生するクラスターで有益であり、より効率的で回復力のあるスケジューリングプロセスを確保します。

この作業はSIG Schedulingが主導したKEP-4832: Asynchronous preemption in the schedulerの一環として行われました。

ClusterTrustBundle

X.509トラストアンカー(ルート証明書)を保持するために設計されたクラスタースコープリソースであるClusterTrustBundleがv1.33でベータに昇格しました。このAPIにより、クラスター内の証明書署名者がX.509トラストアンカーをクラスターワークロードに公開および通信することが容易になります。

この作業はSIG Authが主導したKEP-3257: ClusterTrustBundles (previously Trust Anchor Sets)の一環として行われました。

きめ細かいSupplementalGroupsの制御

v1.31で導入されたこの機能はv1.33でベータに昇格し、現在はデフォルトで有効になっています。クラスターでフィーチャーゲートのSupplementalGroupsPolicyが有効になっている場合、PodのsecurityContext内のsupplementalGroupsPolicyフィールドは2つのポリシーをサポートします: デフォルトのMergeポリシーはコンテナイメージの/etc/groupファイルからのグループと指定されたグループを結合することで後方互換性を維持し、新しいStrictポリシーは明示的に定義されたグループのみを適用します。

この機能強化は、コンテナイメージからの暗黙的なグループメンバーシップが意図しないファイルアクセス権限につながり、ポリシー制御をバイパスする可能性があるセキュリティ上の懸念に対処するのに役立ちます。

この作業はSIG Nodeが主導したKEP-3619: Fine-grained SupplementalGroups controlの一環として行われました。

イメージをボリュームとしてマウントする機能をサポート

v1.31で導入されたPodでOpen Container Initiative(OCI)イメージをボリュームとして使用する機能のサポートがベータに昇格しました。この機能により、ユーザーはPod内でイメージ参照をボリュームとして指定し、コンテナ内でボリュームマウントとして再利用できるようになります。これにより、ボリュームデータを別々にパッケージ化し、メインイメージに含めることなくPod内のコンテナ間で共有する可能性が開かれ、脆弱性を減らしイメージ作成を簡素化します。

この作業はSIG NodeとSIG Storageが主導したKEP-4639: VolumeSource: OCI Artifact and/or Imageの一環として行われました。

Linux Podにおけるユーザー名前空間のサポート

執筆時点で最も古いオープンなKEPの1つであるKEP-127は、Pod用のLinuxユーザー名前空間を使用したPodセキュリティの改善です。このKEPは2016年後半に最初に提案され、複数の改訂を経て、v1.25でアルファリリース、v1.30で初期ベータ(デフォルトでは無効)となり、v1.33の一部としてデフォルトで有効なベータに移行しました。

このサポートは、手動でpod.spec.hostUsersを指定してオプトインしない限り、既存のPodに影響を与えません。 v1.30の先行紹介ブログで強調されているように、これは脆弱性を軽減するための重要なマイルストーンです。

この作業はSIG Nodeが主導したKEP-127: Support User Namespaces in podsの一環として行われました。

Podの`procMount`オプション

v1.12でアルファとして導入され、v1.31でデフォルト無効のベータだったprocMountオプションが、v1.33でデフォルト有効のベータに移行しました。この機能強化はユーザーが/procファイルシステムへのアクセスを細かく調整できるようにすることでPod分離を改善します。具体的には、PodのsecurityContextにフィールドを追加し、特定の/procパスをマスクしたり読み取り専用としてマークするデフォルトの動作をオーバーライドできるようにします。これは特に、ユーザーがユーザー名前空間を使用してKubernetes Pod内で非特権コンテナを実行したい場合に便利です。通常、コンテナランタイム(CRI実装を介して)は厳格な/procマウント設定で外部コンテナを起動します。しかし、非特権Pod内でネストされたコンテナを正常に実行するには、ユーザーはそれらのデフォルト設定を緩和するメカニズムが必要であり、この機能はまさにそれを提供します。

この作業はSIG Nodeが主導したKEP-4265: add ProcMount optionの一環として行われました。

NUMAノード間でCPUを分散させるCPUManagerポリシー

この機能はCPUManagerに、単一ノードに集中させるのではなく非一様メモリアクセス(NUMA)ノード間でCPUを分散させる新しいポリシーオプションを追加します。これにより複数のNUMAノード間でワークロードのバランスを取ることでCPUリソースの割り当てを最適化し、マルチNUMAシステムにおけるパフォーマンスとリソース使用率を向上させます。

この作業はSIG Nodeが主導したKEP-2902: Add CPUManager policy option to distribute CPUs across NUMA nodes instead of packing themの一環として行われました。

コンテナのPreStopフックのゼロ秒スリープ

Kubernetes 1.29ではPodのpreStopライフサイクルフックにSleepアクションが導入され、コンテナが終了する前に指定された時間だけ一時停止できるようになりました。これにより、接続のドレイン(排出)やクリーンアップ操作などのタスクを容易にするコンテナのシャットダウンを遅らせるための簡単な方法が提供されます。

preStopフックのSleepアクションは、現在ベータ機能としてゼロ秒の時間を受け付けることができます。これにより、preStopフックが必要だが遅延が不要な場合に便利な、無操作(no-op)のpreStopフックを定義できるようになります。

この作業はSIG Nodeが主導したKEP-3960: Introducing Sleep Action for PreStop HookおよびKEP-4818: Allow zero value for Sleep Action of PreStop Hookの一環として行われました。

Kubernetesネイティブ型の宣言的検証のための内部ツール

ひそかに、Kubernetesの内部はオブジェクトとオブジェクトへの変更を検証するための新しいメカニズムの使用を開始しています。 Kubernetes v1.33では、Kubernetesコントリビューターが宣言的な検証ルールを生成するために使用する内部ツールvalidation-genを導入しています。全体的な目標は、開発者が検証制約を宣言的に指定できるようにすることでAPI検証の堅牢性と保守性を向上させ、手動コーディングエラーを減らし、コードベース全体での一貫性を確保することです。

この作業はSIG API Machineryが主導したKEP-5073: Declarative Validation Of Kubernetes Native Types With validation-genの一環として行われました。

アルファの新機能

これはv1.33リリース後にアルファとなった改善点の一部です。

HorizontalPodAutoscalerの設定可能な許容値

この機能は、HorizontalPodAutoscaler設定可能な許容値を導入し、小さなメトリクス変動に対するスケーリング反応を抑制します。

この作業はSIG Autoscalingが主導したKEP-4951: Configurable tolerance for Horizontal Pod Autoscalersの一環として行われました。

設定可能なコンテナの再起動遅延

CrashLoopBackOffの処理方法を微調整できる機能です。

この作業はSIG Nodeが主導したKEP-4603: Tune CrashLoopBackOffの一環として行われました。

カスタムコンテナの停止シグナル

Kubernetes v1.33より前では、停止シグナルはコンテナイメージ定義内でのみ設定可能でした(例えば、イメージメタデータのStopSignalフィールドを介して)。終了動作を変更したい場合は、カスタムコンテナイメージをビルドする必要がありました。 Kubernetes v1.33で(アルファの)フィーチャーゲートであるContainerStopSignalsを有効にすることで、Pod仕様内で直接カスタム停止シグナルを定義できるようになりました。これはコンテナのlifecycle.stopSignalフィールドで定義され、Podのspec.os.nameフィールドが存在する必要があります。指定されない場合、コンテナはイメージで定義された停止シグナル(存在する場合)、またはコンテナランタイムのデフォルト(通常Linuxの場合はSIGTERM)にフォールバックします。

この作業はSIG Nodeが主導したKEP-4960: Container Stop Signalsの一環として行われました。

豊富なDRA機能強化

Kubernetes v1.33は、今日の複雑なインフラストラクチャ向けに設計された機能を備えたDynamic Resource Allocation (DRA)の開発を継続しています。 DRAはPod間およびPod内のコンテナ間でリソースを要求および共有するためのAPIです。通常、それらのリソースはGPU、FPGA、ネットワークアダプターなどのデバイスです。

以下はv1.33で導入されたすべてのアルファのDRAのフィーチャーゲートです:

ノードテイントと同様に、フィーチャーゲートのDRADeviceTaintsを有効にすることで、デバイスはTaintとTolerationをサポートします。管理者またはコントロールプレーンコンポーネントはデバイスにテイントを付けて使用を制限できます。テイントが存在する間、それらのデバイスに依存するPodのスケジューリングを一時停止したり、テイントされたデバイスを使用するPodを退避させたりすることができます。
フィーチャーゲートのDRAPrioritizedListを有効にすることで、DeviceRequestsはfirstAvailableという新しいフィールドを取得します。このフィールドは順序付けられたリストで、ユーザーが特定のハードウェアが利用できない場合に何も割り当てないことを含め、リクエストが異なる方法で満たされる可能性を指定できるようにします。
フィーチャーゲートのDRAAdminAccessを有効にすると、resource.k8s.io/admin-access: "true"でラベル付けされた名前空間内でResourceClaimまたはResourceClaimTemplateオブジェクトを作成する権限を持つユーザーのみがadminAccessフィールドを使用できます。これにより、管理者以外のユーザーがadminAccess機能を誤用できないようになります。
v1.31以降、デバイスパーティションの使用が可能でしたが、ベンダーはデバイスを事前にパーティション分割し、それに応じて通知する必要がありました。 v1.33でフィーチャーゲートのDRAPartitionableDevicesを有効にすることで、デバイスベンダーは重複するものを含む複数のパーティションを通知できます。 Kubernetesスケジューラーはワークロード要求に基づいてパーティションを選択し、競合するパーティションの同時割り当てを防止します。この機能により、ベンダーは割り当て時に動的にパーティションを作成する機能を持ちます。割り当てと動的パーティショニングは自動的かつユーザーに透過的に行われ、リソース使用率の向上を可能にします。

これらのフィーチャーゲートは、フィーチャーゲートのDynamicResourceAllocationも有効にしない限り効果がありません。

この作業はSIG Node、SIG Scheduling、SIG Authが主導した KEP-5055: DRA: device taints and tolerations、 KEP-4816: DRA: Prioritized Alternatives in Device Requests、 KEP-5018: DRA: AdminAccess for ResourceClaims and ResourceClaimTemplates、およびKEP-4815: DRA: Add support for partitionable devicesの一環として行われました。

`IfNotPresent`と`Never`のイメージに対する認証を行う堅牢なimagePullPolicy

この機能により、ユーザーはイメージがノード上に既に存在するかどうかに関わらず、新しい資格情報セットごとにkubeletがイメージプル認証チェックを要求することを確実にできます。

この作業はSIG Authが主導したKEP-2535: Ensure secret pulled imagesの一環として行われました。

Downward APIを通じて利用可能なノードトポロジーラベル

この機能により、ノードトポロジーラベルがダウンワードAPIを通じて公開されるようになります。 Kubernetes v1.33より前では、基盤となるノードについてKubernetes APIに問い合わせるために初期化コンテナを使用する回避策が必要でした。このアルファ機能により、ワークロードがノードトポロジー情報にアクセスする方法が簡素化されます。

この作業はSIG Nodeが主導したKEP-4742: Expose Node labels via downward APIの一環として行われました。

生成番号と観測された生成番号によるより良いPodステータス

この変更以前は、metadata.generationフィールドはPodでは使用されていませんでした。 metadata.generationをサポートするための拡張に加えて、この機能はstatus.observedGenerationを導入し、より明確なPodステータスを提供します。

この作業はSIG Nodeが主導したKEP-5067: Pod Generationの一環として行われました。

kubeletのCPU Managerによる分割レベル3キャッシュアーキテクチャのサポート

これまでのkubeletのCPU Managerは分割L3キャッシュアーキテクチャ(Last Level Cache、またはLLCとも呼ばれる)を認識せず、分割L3キャッシュを考慮せずにCPU割り当てを分散させる可能性があり、ノイジーネイバー問題を引き起こす可能性がありました。このアルファ機能はCPU Managerを改善し、より良いパフォーマンスのためにCPUコアをより適切に割り当てます。

この作業はSIG Nodeが主導したKEP-5109: Split L3 Cache Topology Awareness in CPU Managerの一環として行われました。

スケジューリング改善のためのPSI(Pressure Stall Information)メトリクス

この機能は、Linuxノードにcgroupv2を使用してPSI統計とメトリクスを提供するサポートを追加します。これによりリソース不足を検出し、Podスケジューリングのためのより細かい制御をノードに提供できます。

この作業はSIG Nodeが主導したKEP-4205: Support PSI based on cgroupv2の一環として行われました。

kubeletによるシークレットレスイメージPull

kubeletのオンディスク認証情報プロバイダーが、オプションでKubernetes ServiceAccount(SA)トークンの取得をサポートするようになりました。これにより、クラウドプロバイダーはOIDC互換のアイデンティティソリューションとより適切に統合でき、イメージレジストリとの認証が簡素化されます。

この作業はSIG Authが主導したKEP-4412: Projected service account tokens for Kubelet image credential providersの一環として行われました。

v1.33での昇格、非推奨化、および削除

GAへの昇格

これは安定版(一般提供、GAとも呼ばれる)に昇格したすべての機能を一覧にしたものです。アルファからベータへの昇格や新機能を含む更新の完全なリストについては、リリースノートをご覧ください。

このリリースには、GAに昇格した合計18の機能強化が含まれています:

非推奨化と削除

Kubernetesの開発と成熟に伴い、プロジェクト全体の健全性を向上させるために機能が非推奨化されたり、削除されたり、より良い機能に置き換えられたりすることがあります。このプロセスに関する詳細は、Kubernetes非推奨ポリシーを参照してください。これらの非推奨化や削除の多くは、Kubernetes v1.33の先行紹介ブログで告知されました。

Endpoints APIの非推奨化

v1.21以降GAされたEndpointSlice APIは、元のEndpoint APIを事実上置き換えました。元のEndpoint APIはシンプルで分かりやすかったものの、多数のネットワークエンドポイントへスケーリングする際にいくつかの課題がありました。 EndpointSlice APIにはデュアルスタックネットワーキングなどの新機能が導入され、これにより元のEndpoint APIは非推奨化されることになりました。

この非推奨化は、ワークロードやスクリプトからEndpoint APIを直接使用しているユーザーにのみ影響します。これらのユーザーは代わりにEndpointSliceを使用するように移行する必要があります。非推奨化による影響と移行計画に関する詳細を記載した専用のブログ記事が公開される予定です。

詳細はKEP-4974: Deprecate v1.Endpointsで確認できます。

Nodeステータスにおけるkube-proxyバージョン情報の削除

v1.31の「Deprecation of status.nodeInfo.kubeProxyVersion field for Nodes」で強調されているように、v1.31での非推奨化に続き、Nodeの.status.nodeInfo.kubeProxyVersionフィールドがv1.33で削除されました。

このフィールドはkubeletによって設定されていましたが、その値は一貫して正確ではありませんでした。 v1.31以降デフォルトで無効化されていたため、このフィールドはv1.33で完全に削除されました。

詳細はKEP-4004: Deprecate status.nodeInfo.kubeProxyVersion fieldで確認できます。

インツリーのgitRepoボリュームドライバーの削除

gitRepoボリュームタイプは、約7年前のv1.11から非推奨化されていました。非推奨化されて以降、gitRepoボリュームタイプがノード上でrootとしてリモートコード実行を得るためにどのように悪用されうるかといった、セキュリティ上の懸念がありました。 v1.33では、インツリーのドライバーコードが削除されます。

代替手段としてgit-syncやinitコンテナがあります。 Kubernetes APIのgitVolumesは削除されないため、gitRepoボリュームを持つPodはkube-apiserverによって受け入れられます。しかし、フィーチャーゲートのGitRepoVolumeDriverがfalseに設定されているkubeletはそれらを実行せず、ユーザーに適切なエラーを返します。これにより、ユーザーはワークロードを修正するための十分な時間を確保するために、3バージョン分の期間、ドライバーの再有効化をオプトインできます。

kubeletのフィーチャーゲートとインツリーのプラグインコードは、v1.39リリースで削除される予定です。

詳細はKEP-5040: Remove gitRepo volume driverで確認できます。

Windows Podにおけるホストネットワークサポートの削除

Windows Podのネットワーキングは、コンテナがNodeのネットワーク名前空間を使用できるようにすることでLinuxとの機能パリティを達成し、クラスター密度を向上させることを目指していました。元の実装はv1.26でアルファとして導入されましたが、予期せぬcontainerdの挙動に直面し、代替ソリューションが存在したため、Kubernetesプロジェクトは関連するKEPを取り下げることを決定しました。サポートはv1.33で完全に削除されました。

これは、ホストネットワークおよびホストレベルのアクセスを提供するHostProcessコンテナには影響しないことに注意してください。 v1.33で取り下げられたKEPは、ホストネットワークのみを提供することに関するものでしたが、Windowsのネットワーキングロジックにおける技術的な制限のため、安定することはありませんでした。

詳細はKEP-3503: Host network support for Windows podsで確認できます。

リリースノート

Kubernetes v1.33リリースの詳細については、リリースノートをご覧ください。

入手方法

Kubernetes v1.33はGitHubまたはKubernetes公式サイトのダウンロードページからダウンロードできます。

Kubernetesを始めるには、チュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスターを実行してください。また、kubeadmを使用して簡単にv1.33をインストールすることもできます。

リリースチーム

Kubernetesはそのコミュニティのサポート、コミットメント、そして懸命な働きによってのみ実現可能です。リリースチームは、ユーザーが依存するKubernetesリリースを構成する多くの部分を構築するために協力する、献身的なコミュニティボランティアによって構成されています。これには、コード自体からドキュメンテーションやプロジェクト管理まで、コミュニティのあらゆる分野の人々の専門的なスキルが必要です。

私たちは、Kubernetes v1.33リリースをコミュニティに提供するために熱心に取り組んだ時間について、リリースチーム全体に感謝します。リリースチームのメンバーは、初めてのShadow(見習い)から、複数のリリースサイクルで培われた経験を持ち、復帰をしたチームリードまで幅広く存在します。このリリースサイクルでは、リリースノートとDocsのサブチームを統合し、Docsサブチームに統一するという新しいチーム構造が採用されました。新しいDocsチームから関連情報とリソースを整理する綿密な努力のおかげで、リリースノートとDocsの追跡は円滑かつ成功した移行を実現しました。最後に、成功したリリースサイクルを通してのサポート、支援、誰もが効果的に貢献できるようにする取り組み、そしてリリースプロセスを改善するための課題に対して、リリースリードのNina Polshakovaに心より感謝します。

プロジェクトの活動状況

CNCF K8sのDevStatsプロジェクトは、Kubernetesおよび様々なサブプロジェクトの活動状況に関する興味深いデータポイントを集計しています。これには個人の貢献から貢献企業数まで含まれ、このエコシステムの発展に費やされる努力の深さと広さを示しています。

v1.33リリースサイクル(2025年1月13日から4月23日までの15週間)において、Kubernetesには最大121の異なる企業と570人の個人から貢献がありました(執筆時点では、リリース日の数週間前の数値です)。より広範なクラウドネイティブエコシステムでは、この数字は435社、合計2400人のコントリビューターに達しています。データソースはこのダッシュボードで確認できます。前回のリリースv1.32の活動データと比較すると、企業や個人からの貢献レベルは同様であり、コミュニティの関心と参加が引き続き強いことを示しています。

なお、「貢献」とはコミットの作成、コードレビュー、コメント、IssueやPRの作成、PRのレビュー(ブログやドキュメントを含む)、またはIssueやPRへのコメントを行うことを指します。貢献に興味がある場合は、公式ドキュメントのコントリビューター向けのはじめにをご覧ください。

Kubernetesプロジェクトとコミュニティの全体的な活動状況についてさらに詳しく知るには、DevStatsをチェックしてください。

イベント情報

今後開催予定のKubernetesおよびクラウドネイティブイベント(KubeCon + CloudNativeCon、KCDなど)や、世界各地で開催される主要なカンファレンスについて紹介します。 Kubernetesコミュニティの最新情報を入手し、参加しましょう！

2025年5月

KCD - Kubernetes Community Days: Costa Rica: 2025年5月3日 | コスタリカ、エレディア
KCD - Kubernetes Community Days: Helsinki: 2025年5月6日 | フィンランド、ヘルシンキ
KCD - Kubernetes Community Days: Texas Austin: 2025年5月15日 | アメリカ、オースティン
KCD - Kubernetes Community Days: Seoul: 2025年5月22日 | 韓国、ソウル
KCD - Kubernetes Community Days: Istanbul, Turkey: 2025年5月23日 | トルコ、イスタンブール
KCD - Kubernetes Community Days: San Francisco Bay Area: 2025年5月28日 | アメリカ、サンフランシスコ

2025年6月

KCD - Kubernetes Community Days: New York: 2025年6月4日 | アメリカ、ニューヨーク
KCD - Kubernetes Community Days: Czech & Slovak: 2025年6月5日 | スロバキア、ブラチスラバ
KCD - Kubernetes Community Days: Bengaluru: 2025年6月6日 | インド、バンガロール
KubeCon + CloudNativeCon China 2025: 2025年6月10日-11日 | 香港
KCD - Kubernetes Community Days: Antigua Guatemala: 2025年6月14日 | グアテマラ、アンティグア・グアテマラ
KubeCon + CloudNativeCon Japan 2025: 2025年6月16日-17日 | 日本、東京
KCD - Kubernetes Community Days: Nigeria, Africa: 2025年6月19日 | アフリカ、ナイジェリア

2025年7月

KCD - Kubernetes Community Days: Utrecht: 2025年7月4日 | オランダ、ユトレヒト
KCD - Kubernetes Community Days: Taipei: 2025年7月5日 | 台湾、台北
KCD - Kubernetes Community Days: Lima, Peru: 2025年7月19日 | ペルー、リマ

2025年8月

KubeCon + CloudNativeCon India 2025: 2025年8月6日-7日 | インド、ハイデラバード
KCD - Kubernetes Community Days: Colombia: 2025年8月29日 | コロンビア、ボゴタ

最新のKCD情報はこちらでご確認いただけます。

ウェビナーのご案内

Kubernetes v1.33リリースチームのメンバーと一緒に 2025年5月16日(金)午後4時(UTC) から、このリリースのハイライトやアップグレードの計画に役立つ非推奨事項や削除事項について学びましょう。詳細および参加登録は、CNCFオンラインプログラム・サイトのイベントページをご覧ください。

参加方法

Kubernetesに関わる最も簡単な方法は、あなたの興味に合ったSpecial Interest Groups (SIGs)のいずれかに参加することです。 Kubernetesコミュニティに向けて何か発信したいことはありますか？毎週のコミュニティミーティングや、以下のチャンネルであなたの声を共有してください。継続的なフィードバックとサポートに感謝いたします。

最新情報はBlueSkyの@kubernetes.ioをフォローしてください
Discussでコミュニティディスカッションに参加してください
Slackでコミュニティに参加してください
Server FaultかStack Overflowで質問したり、回答したりしてください
あなたのKubernetesに関するストーリーを共有してください
Kubernetesの最新情報はブログでさらに詳しく読むことができます
Kubernetes Release Teamについての詳細はこちらをご覧ください

kube-scheduler-simulatorの紹介

By Kensei Nakada (Tetrate) | 2025.04.07

Kubernetesスケジューラーは、Podがどのノードで実行されるかを決定する、非常に重要なコントロールプレーンコンポーネントです。そのため、Kubernetesを利用するすべてのユーザーは、スケジューラーに依存しています。

kube-scheduler-simulatorは、Kubernetesスケジューラーの シミュレーター であり、Google Summer of Code 2021において私(Kensei Nakada)が開発を開始し、その後多くのコントリビューションを受けてきたプロジェクトです。このツールを使用すると、スケジューラーの動作や意思決定を詳細に観察することができます。

このシミュレーターは、スケジューリング制約(たとえば、Pod間のアフィニティ)を利用する一般ユーザーにとっても有用ですし、カスタムプラグインによってスケジューラーを拡張するエキスパートにとっても有用です。

動機

スケジューラーは、多くのプラグインで構成されており、それぞれが独自の観点でスケジューリングの意思決定に寄与しているため、しばしばブラックボックスのように見えます。その動作を理解することは、考慮される要素が非常に多いため困難です。

たとえシンプルなテストクラスターにおいてPodが正しくスケジューリングされているように見えても、想定とは異なる計算に基づいてスケジューリングされている可能性があります。このようなずれは、本番の大規模な環境において、予期しないスケジューリング結果を引き起こすことにつながりかねません。

また、スケジューラーをテストすることは非常に複雑な課題です。実際のクラスター内では無数の操作パターンが存在し、有限な数のテストであらゆるシナリオを予測することは現実的ではありません。多くの場合、スケジューラーを実際のクラスターにデプロイして初めてバグが発見されます。実際、アップストリームのkube-schedulerであっても、リリース後にユーザーによって多くのバグが発見されています。

スケジューラー、あるいはどんなKubernetesコントローラーであっても、それらをテストするための開発環境やサンドボックス環境を用意することは、一般的なプラクティスです。しかし、この方法では、本番クラスターで発生し得るすべてのシナリオを網羅するには不十分です。というのも、開発クラスターは通常、本番に比べてはるかに小規模であり、ワークロードの規模やスケーリングの特性にも大きな違いがあるためです。開発クラスターは本番環境とまったく同じ使われ方をすることはなく、同じ挙動を示すこともありません。

kube-scheduler-simulatorは、これらの問題を解決することを目的としています。ユーザーは、このツールを用いてスケジューリング制約やスケジューラーの設定、カスタムプラグインをテストしつつ、スケジューリングの意思決定におけるあらゆる詳細な部分を確認することができます。また、ユーザーは本番クラスターと同じリソースを使いながら、実際のワークロードに影響を与えることなく、スケジューラーをテストできるシミュレートされたクラスター環境を作成することも可能です。

kube-scheduler-simulatorの機能

kube-scheduler-simulatorのコア機能は、スケジューラーの内部的な意思決定を可視化できる点にあります。スケジューラーはスケジューリングフレームワークに基づいて動作しており、さまざまな拡張ポイントで複数のプラグインを利用し、ノードのフィルタリング(Filterフェーズ)、スコア付け(Scoreフェーズ)を経て、最終的にPodに最適なノードを決定します。

このシミュレーターを用いることで、ユーザーはKubernetesリソースを作成し、各プラグインがPodのスケジューリングにどのように影響を与えているかを観察できます。これにより、スケジューラーの仕組みを理解し、適切なスケジューリング制約を定義する助けとなります。

ノードごとおよび拡張ポイントごとの詳細なスケジューリング結果を表示する、シミュレーターのWebフロントエンドのスクリーンショット — シミュレーターのwebフロントエンド

このシミュレーターの内部では、通常のスケジューラー(vanilla scheduler)ではなく、Debuggable Schedulerと呼ばれるデバッグを容易にするスケジューラーが動作します。このDebuggable Schedulerは、各拡張ポイントにおける各スケジューラープラグインの結果を、以下のマニフェストに示すようにPodのアノテーションとして出力します。 webフロントエンドはこれらのアノテーションに基づいてスケジューリング結果を整形・可視化します。

kind: Pod
apiVersion: v1
metadata:
  # このブログ投稿では、アノテーション内のJSONは見やすさのために手動で整形されています。
  annotations:
    kube-scheduler-simulator.sigs.k8s.io/bind-result: '{"DefaultBinder":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/filter-result: >-
      {
        "node-jjfg5":{
            "NodeName":"passed",
            "NodeResourcesFit":"passed",
            "NodeUnschedulable":"passed",
            "TaintToleration":"passed"
        },
        "node-mtb5x":{
            "NodeName":"passed",
            "NodeResourcesFit":"passed",
            "NodeUnschedulable":"passed",
            "TaintToleration":"passed"
        }
      }      
    kube-scheduler-simulator.sigs.k8s.io/finalscore-result: >-
      {
        "node-jjfg5":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"52",
            "NodeResourcesFit":"47",
            "TaintToleration":"300",
            "VolumeBinding":"0"
        },
        "node-mtb5x":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"76",
            "NodeResourcesFit":"73",
            "TaintToleration":"300",
            "VolumeBinding":"0"
        }
      }      
    kube-scheduler-simulator.sigs.k8s.io/permit-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/permit-result-timeout: '{}'
    kube-scheduler-simulator.sigs.k8s.io/postfilter-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/prebind-result: '{"VolumeBinding":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/prefilter-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/prefilter-result-status: >-
      {
        "AzureDiskLimits":"",
        "EBSLimits":"",
        "GCEPDLimits":"",
        "InterPodAffinity":"",
        "NodeAffinity":"",
        "NodePorts":"",
        "NodeResourcesFit":"success",
        "NodeVolumeLimits":"",
        "PodTopologySpread":"",
        "VolumeBinding":"",
        "VolumeRestrictions":"",
        "VolumeZone":""
      }      
    kube-scheduler-simulator.sigs.k8s.io/prescore-result: >-
      {
        "InterPodAffinity":"",
        "NodeAffinity":"success",
        "NodeResourcesBalancedAllocation":"success",
        "NodeResourcesFit":"success",
        "PodTopologySpread":"",
        "TaintToleration":"success"
      }      
    kube-scheduler-simulator.sigs.k8s.io/reserve-result: '{"VolumeBinding":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/result-history: >-
      [
        {
            "kube-scheduler-simulator.sigs.k8s.io/bind-result":"{\"DefaultBinder\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/filter-result":"{\"node-jjfg5\":{\"NodeName\":\"passed\",\"NodeResourcesFit\":\"passed\",\"NodeUnschedulable\":\"passed\",\"TaintToleration\":\"passed\"},\"node-mtb5x\":{\"NodeName\":\"passed\",\"NodeResourcesFit\":\"passed\",\"NodeUnschedulable\":\"passed\",\"TaintToleration\":\"passed\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/finalscore-result":"{\"node-jjfg5\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"52\",\"NodeResourcesFit\":\"47\",\"TaintToleration\":\"300\",\"VolumeBinding\":\"0\"},\"node-mtb5x\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"76\",\"NodeResourcesFit\":\"73\",\"TaintToleration\":\"300\",\"VolumeBinding\":\"0\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/permit-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/permit-result-timeout":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/postfilter-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/prebind-result":"{\"VolumeBinding\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/prefilter-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/prefilter-result-status":"{\"AzureDiskLimits\":\"\",\"EBSLimits\":\"\",\"GCEPDLimits\":\"\",\"InterPodAffinity\":\"\",\"NodeAffinity\":\"\",\"NodePorts\":\"\",\"NodeResourcesFit\":\"success\",\"NodeVolumeLimits\":\"\",\"PodTopologySpread\":\"\",\"VolumeBinding\":\"\",\"VolumeRestrictions\":\"\",\"VolumeZone\":\"\"}",
            "kube-scheduler-simulator.sigs.k8s.io/prescore-result":"{\"InterPodAffinity\":\"\",\"NodeAffinity\":\"success\",\"NodeResourcesBalancedAllocation\":\"success\",\"NodeResourcesFit\":\"success\",\"PodTopologySpread\":\"\",\"TaintToleration\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/reserve-result":"{\"VolumeBinding\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/score-result":"{\"node-jjfg5\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"52\",\"NodeResourcesFit\":\"47\",\"TaintToleration\":\"0\",\"VolumeBinding\":\"0\"},\"node-mtb5x\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"76\",\"NodeResourcesFit\":\"73\",\"TaintToleration\":\"0\",\"VolumeBinding\":\"0\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/selected-node":"node-mtb5x"
        }
      ]      
    kube-scheduler-simulator.sigs.k8s.io/score-result: >-
      {
        "node-jjfg5":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"52",
            "NodeResourcesFit":"47",
            "TaintToleration":"0",
            "VolumeBinding":"0"
        },
        "node-mtb5x":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"76",
            "NodeResourcesFit":"73",
            "TaintToleration":"0",
            "VolumeBinding":"0"
        }
      }      
    kube-scheduler-simulator.sigs.k8s.io/selected-node: node-mtb5x

ユーザーはまた、自身のカスタムプラグインやextenderをこのDebuggable Schedulerに統合し、その結果を可視化することもできます。

このDebuggable Schedulerは、たとえば任意のKubernetesクラスター上や統合テスト内など、スタンドアローンで実行することも可能です。これは、自身のプラグインをテストしたり、実クラスター上でカスタムスケジューラーをよりデバッグしやすくしたいと考えるカスタムプラグイン開発者にとって有用です。

より優れた開発クラスターとしてのシミュレーター

前述のとおり、限られたテストだけでは実世界のクラスターで起こり得るすべてのシナリオを予測することは不可能です。ユーザーはスケジューラーを本番環境にデプロイする前に、小規模な開発クラスターでテストし、問題が発生しないことを願うことしかできません。

そこで、シミュレーターのインポート機能を使うことで、本番環境に近い環境で、稼働中のワークロードに影響を与えることなくスケジューラーのシミュレーションをすることができます。

本番クラスターとシミュレーターの間で継続的に同期を行うことで、ユーザーは本番クラスターが対応するリソースと同じリソースを用いて、新しいバージョンのスケジューラーを安全にテストすることができます。その動作に確信が持てた段階で本番環境へのデプロイに進むことができ、予期しない問題のリスクを低減できます。

ユースケースは？

クラスターユーザー: スケジューリング制約(たとえば、PodAffinityやPodTopologySpreadなど)が意図した通りに機能しているかを検証する。
クラスター管理者: スケジューラーの設定を変更した場合に、クラスターがどのように動作するかを評価する。
スケジューラープラグイン開発者: カスタムスケジューラープラグインやスケジューラー拡張をテストする。Debuggable Schedulerを統合テストや開発クラスターで使用したり、本番環境に近い環境でのテストのために同期機能を活用したりする。

利用開始の手順

このシミュレーターを使用するには、マシンにDockerがインストールされていれば十分で、Kubernetesクラスターは必要ありません。

git clone git@github.com:kubernetes-sigs/kube-scheduler-simulator.git
cd kube-scheduler-simulator
make docker_up

http://localhost:3000でシミュレーターのweb UIにアクセスできます。

詳しくは、kube-scheduler-simulatorのリポジトリをご覧ください！

貢献するには

このシミュレーターは、Kubernetes SIG Schedulingによって開発されています。フィードバックやコントリビューションは大歓迎です！

問題の報告やプルリクエストは、kube-scheduler-simulatorのリポジトリで行ってください。また、Slackの#sig-schedulingチャンネルにもぜひご参加ください。

謝辞

このシミュレーターのプロジェクトは、熱意あるボランティアのエンジニアたちによってメンテナンスされ、多くの課題を乗り越えて現在の形に至りました。

素晴らしいコントリビューターの皆さんに心より感謝いたします！

Kubernetes v1.33の先行紹介

By Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav | 2025.03.26

Kubernetes v1.33のリリースが近づく中で、Kubernetesプロジェクトは進化を続けています。プロジェクト全体の健全性を高めるために、一部の機能が非推奨となったり、削除または置き換えられたりする可能性があります。本ブログ記事では、v1.33リリースに向けて計画されている変更の一部を紹介します。これらは、Kubernetes環境を安定して運用し、最新の開発動向を把握し続けるために、リリースチームが特に知っておくべきであると考えている情報です。以下の情報は、v1.33リリースの現時点の状況に基づいており、正式リリースまでに変更される可能性があります。

Kubernetes APIの削除および非推奨プロセス

Kubernetesプロジェクトでは、機能の非推奨ポリシーが明確に文書化されています。このポリシーでは、安定版のAPIを非推奨とするには同じAPIの新たな安定版が存在していることが条件とされています。また、APIの安定性レベルごとに最低限のサポート期間が定められています。非推奨となったAPIは、将来のKubernetesリリースで削除される予定であることを示しています。削除までは引き続き動作しますが(非推奨から少なくとも1年間は利用可能です)、利用時には警告メッセージが表示されます。削除されたAPIは現在のバージョンでは利用できなくなり、その時点で代替手段への移行が必須となります。

一般公開版(GA)または安定版のAPIバージョンが非推奨となる可能性はありますが、Kubernetesの同一のメジャーバージョン内で削除されてはなりません。
ベータ版やプレリリースのAPIバージョンは、非推奨となってから3つのリリース分はサポートされなければなりません。
アルファ版または実験的なAPIバージョンは、事前の非推奨通知なしに任意のリリースで削除される可能性があります。すでに同一の機能に対して別の実装が存在する場合、このプロセスは「撤回」と見なされることがあります。

機能がベータ版から安定版へ昇格した結果としてAPIが削除される場合でも、単にそのAPIが定着しなかった場合でも、すべての削除はこの非推奨ポリシーに準拠して実施されます。 APIが削除される際には、移行手段が非推奨ガイド内で案内されます。

Kubernetes v1.33における非推奨と削除

安定版Endpoints APIの非推奨化

EndpointSlices APIはv1.21から安定版となっており、実質的に従来のEndpoints APIを置き換える存在となっています。元のEndpoints APIはシンプルで分かりやすい設計でしたが、大規模なネットワークエンドポイントにスケールする際に課題がありました。 EndpointSlices APIはデュアルスタックネットワーク対応などの新機能を導入しており、これにより従来のEndpoints APIは非推奨とする準備が整いました。

今回の非推奨は、ワークロードやスクリプトからEndpoints APIを直接使用しているユーザーのみに影響します。これらのユーザーは、代わりにEndpointSliceの使用へ移行する必要があります。非推奨による影響と移行計画の詳細については、今後数週間以内に専用のブログ記事が公開される予定です。

詳細はKEP-4974: Deprecate v1.Endpointsをご覧ください。

ノードステータスからのkube-proxyバージョン情報の削除

リリースアナウンスで示されたとおり、v1.31で非推奨となったstatus.nodeInfo.kubeProxyVersionフィールドは、v1.33で削除されます。このフィールドはkubeletによって設定されていましたが、その値は一貫して正確とは限りませんでした。 v1.31以降、このフィールドはデフォルトで無効化されているため、v1.33では完全に削除されます。

詳細はKEP-4004: Deprecate status.nodeInfo.kubeProxyVersion fieldをご覧ください。

Windows Podにおけるホストネットワーク対応の削除

Windows Podのネットワーク機能は、Linuxと同等の機能を提供し、コンテナがノードのネットワーク名前空間を使用できるようにすることで、クラスター密度の向上を目指していました。この機能の初期実装はv1.26でアルファ版として導入されましたが、containerdに関する予期せぬ挙動が確認され、また代替手段も存在していたことから、Kubernetesプロジェクトは関連するKEPの撤回を決定しました。 v1.33において、この機能のサポートは完全に削除される見込みです。

詳細はKEP-3503: Host network support for Windows podsをご覧ください。

Kubernetes v1.33の注目すべき変更点

本記事の執筆者として、私たちは特に注目すべき重要な改善点を1つ選びました！

Linux Podにおけるユーザー名前空間のサポート

現在もオープンなKEPの中で最も古いものの一つが、KEP-127「Podに対してLinuxユーザー名前空間を使用することによるセキュリティの改善」です。このKEPは2016年後半に初めて提案され、複数回の改訂を経てv1.25でアルファ版として登場し、v1.30で初めてベータ版が提供されました(この時点ではデフォルトで無効)。そしてv1.33では、この機能がデフォルトで有効な状態で提供される予定です。

この機能は、明示的にpod.spec.hostUsersを指定して有効化しない限り、既存のPodには影響しません。 Kubernetes v1.30をそっと覗くでも触れられているように、この機能は脆弱性の軽減に向けた重要なマイルストーンとなります。

詳細はKEP-127: Support User Namespaces in podsをご覧ください。

その他の注目すべきKubernetes v1.33の改善点

以下に挙げる改善項目は、今後リリース予定のv1.33に含まれる見込みのものです。ただし、これらは確定事項ではなく、リリース内容は変更される可能性があります。

Podの垂直スケーリングに対応したリソースの動的リサイズ

Podをプロビジョニングする際には、DeploymentやStatefulSetなど、さまざまなリソースを利用できます。スケーラビリティの要件によっては、Podのレプリカ数を更新する水平スケーリング、あるいはPod内のコンテナに割り当てるリソースを更新する垂直スケーリングが必要になる場合があります。この改善が導入される以前は、Podのspecに定義されたコンテナリソースは変更できず、Podテンプレート内のリソースを更新するとPodの置き換えが発生していました。

しかし、既存のPodを再起動せずに、動的にリソース設定を更新できたらどうでしょうか？

KEP-1287は、まさにこのようなPodのインプレース更新を可能にするためのものです。これにより、ステートフルなプロセスに対してダウンタイムなしでの垂直スケールアップや、トラフィックが少ないときのシームレスなスケールダウン、さらには起動時に一時的に大きなリソースを割り当て、初期処理が完了した後にそれを縮小するといったことも可能になります。この機能はv1.27でアルファ版としてリリースされており、v1.33ではベータ版として提供される予定です。

詳細はKEP-1287: In-Place Update of Pod Resourcesをご覧ください。

DRAのResourceClaimにおけるデバイスステータスがベータに昇格

ResourceClaimのstatus内にあるdevicesフィールドは、v1.32リリースで導入された機能であり、v1.33でベータに昇格する見込みです。このフィールドは、ドライバーがデバイスの状態情報を報告できるようにするもので、可観測性とトラブルシューティング能力の向上に貢献します。

例えば、ResourceClaimのステータスにネットワークインターフェースの名前、MACアドレス、IPアドレスを報告することは、ネットワークサービスの設定や管理、ならびにネットワーク関連の問題のデバッグに大いに役立ちます。この機能の詳細は、動的リソース割り当てのドキュメントをご覧ください。

また、計画中の拡張についてはKEP-4817: DRA: Resource Claim Status with possible standardized network interface dataに記載されています。

名前空間の順序付き削除

このKEPは、Kubernetesの名前空間に対して、より構造化された削除プロセスを導入することで、リソースの安全かつ決定論的な削除を実現することを目的としています。現在の削除処理はほぼランダムな順序で行われるため、たとえばNetworkPolicyが先に削除されてPodが残るといった、セキュリティ上の問題や意図しない動作を引き起こす可能性があります。論理的およびセキュリティ上の依存関係を考慮した構造化された削除順序を強制することで、このアプローチはPodが他のリソースより先に削除されることを保証します。この設計は、非決定的な削除に関連するリスクを軽減することで、Kubernetesのセキュリティと信頼性を向上させます。

詳細はKEP-5080: Ordered namespace deletionをご覧ください。

Indexed Job管理の強化

これら2つのKEPは、ジョブの処理、特にIndexed Jobの信頼性を向上させるためにGAに昇格する予定です。 KEP-3850では、Indexed Jobに対してインデックスごとのバックオフ制限を提供しており、各インデックスが他のインデックスと完全に独立して動作できるようになります。また、KEP-3998はJob APIを拡張し、すべてのインデックスが成功していない場合でもIndexed Jobを成功と見なすための条件を定義できるようにします。

詳細は、KEP-3850: Backoff Limit Per Index For Indexed JobsおよびKEP-3998: Job success/completion policyをご覧ください。

さらに詳しく知りたい方へ

新機能や非推奨の項目については、Kubernetesのリリースノートでもアナウンスされています。 Kubernetes v1.33の新機能については、該当リリースのCHANGELOGにて正式に発表される予定です。

Kubernetes v1.33のリリースは 2025年4月23日(水) を予定しています。今後の更新情報にもぜひご注目ください！

以下のリリースノートでも、各バージョンにおける変更点のアナウンスを確認できます。

コミュニティへの参加方法

Kubernetesに関わるための最も簡単な方法は、関心のある分野に関連するSpecial Interest Groups(SIGs)のいずれかに参加することです。 Kubernetesコミュニティに向けて発信したい内容がありますか？もしあれば、毎週開催されているコミュニティミーティングや、下記の各種チャネルを通じて、ぜひ声を届けてください。皆さまからの継続的なご意見とご支援に、心より感謝申し上げます。

最新情報はBlueskyの@kubernetes.ioでご確認ください
Discussでコミュニティのディスカッションに参加しましょう
Slackのコミュニティに参加しましょう
Server FaultやStack Overflowに質問を投稿したり、他の質問に回答したりしましょう
あなたのKubernetesストーリーを共有しましょう
Kubernetesに関する最新情報はブログをご覧ください
Kubernetesリリースチームについて学びましょう

Kubernetes v1.32: Penelope

By Kubernetes v1.32 Release Team | 2024.12.11

編集者: Matteo Bianchi, Edith Puclla, William Rizzo, Ryota Sawada, Rashan Smith

Kubernetes v1.32: Penelopeのリリースを発表します！

これまでのリリースと同様に、Kubernetes v1.32では新たなGA、ベータ、アルファの機能が導入されています。継続的に高品質なリリースを提供できていることは、私たちの開発サイクルの強さと、活発なコミュニティのサポートを示すものです。今回のリリースでは、44の機能強化が行われました。そのうち、13の機能がGAに昇格し、12の機能がベータに移行し、19の機能がアルファとして導入されています。

リリースのテーマとロゴ

Kubernetes v1.32のリリーステーマは"Penelope"です。

Kubernetesが古代ギリシャ語で「パイロット」または「舵取り」を意味することから始め、このリリースではKubernetesの10年間とその成果を振り返ります。各リリースサイクルは一つの旅路であり、「オデュッセイア」のペーネロペーが10年の間、昼に織ったものを夜になると解いていったように、各リリースでは新機能の追加と既存機能の削除を行います。ただしここでは、Kubernetesを継続的に改善するというより明確な目的を持って行われています。 v1.32はKubernetesが10周年を迎える年の最後のリリースとなることから、クラウドネイティブの海の試練や課題を航海してきたグローバルなKubernetesクルーの一員として貢献してくださった全ての方々に敬意を表したいと思います。これからも共にKubernetesの未来を紡いでいけることを願っています。

最近の主要な機能の更新

DRAの機能強化に関する注記

今回のリリースでは、前回のリリースと同様に、KubernetesプロジェクトはDynamic Resource Allocation(DRA)に対して多くの機能強化を提案し続けています。 DRAはKubernetesのリソース管理システムの主要なコンポーネントです。これらの機能強化は、GPU、FPGA、ネットワークアダプターなどの特殊なハードウェアを必要とするワークロードに対するリソース割り当ての柔軟性と効率性を向上させることを目的としています。

これらの機能は、機械学習や高性能コンピューティングアプリケーションなどのユースケースで特に有用です。DRAのStructured parameterサポートを可能にするコア部分はベータに昇格しました。

ノードとサイドカーコンテナの更新における振る舞いの改善

SIG Nodeでは、KEPの範囲を超えて以下のような改善が行われています:

kubeletのヘルスチェックが失敗した際にkubeletを再起動するために、systemdのwatchdog機能が使用されるようになりました。また、一定時間内の最大再起動回数も制限されます。これによりkubeletの信頼性が向上します。詳細についてはPull Requestの#127566をご覧ください。
イメージプルのバックオフエラーが発生した場合、Podのステータスに表示されるメッセージが改善され、より分かりやすくなり、Podがこの状態にある理由の詳細が示されるようになりました。イメージプルのバックオフが発生すると、エラーはPod仕様のstatus.containerStatuses[*].state.waiting.messageフィールドに追加され、reasonフィールドにはImagePullBackOffの値が設定されます。この変更により、より多くのコンテキストが提供され、問題の根本原因を特定するのに役立ちます。詳細については、Pull Requestの#127918をご覧ください。
サイドカーコンテナ機能は、v1.33でStableへの昇格を目指しています。残りの作業項目とユーザーからのフィードバックについては、Issueの#753のコメントをご覧ください。

GAに昇格した機能のハイライト

これは、v1.32のリリースに伴いGAとなった改善点の一部です。

カスタムリソースのフィールドセレクター

カスタムリソースのフィールドセレクターにより、開発者は組み込みのKubernetesオブジェクトで利用できる機能と同様に、カスタムリソースにフィールドセレクターを追加できるようになりました。これにより、カスタムリソースのより効率的で正確なフィルタリングが可能になり、より良いAPI設計の実践を促進します。

この作業は、SIG API MachineryによりKEP #4358の一部として実施されました。

SizeMemoryBackedVolumesのサポート

この機能により、Podのリソース制限に基づいてメモリバックアップボリュームを動的にサイズ設定できるようになり、ワークロードの移植性とノードのリソース使用率の全体的な向上を実現します。

この作業は、SIG NodeによりKEP #1967の一部として実施されました。

バインドされたサービスアカウントトークンの改善

サービスアカウントトークンのクレームにノード名を含めることで、認可と認証(ValidatingAdmissionPolicy)の過程でこの情報を使用できるようになりました。さらに、この改善によりサービスアカウントの認証情報がノードの権限昇格パスとなることを防ぎます。

この作業は、SIG AuthによりKEP #4193の一部として実施されました。

構造化された認可設定

APIサーバーに複数の認可機能を設定できるようになり、webhookでのCELマッチ条件をサポートすることで、構造化された認可の判断が可能になりました。

この作業は、SIG AuthによりKEP #3221の一部として実施されました。

StatefulSetによって作成されたPVCの自動削除

StatefulSetが作成したPersistentVolumeClaim(PVC)は、不要になると自動的に削除されるようになりました。これはStatefulSetの更新やノードのメンテナンス時にもデータを確実に保持したまま削除処理を行います。この機能により、StatefulSetのストレージ管理が容易になり、PVCが残されたままになるリスクも減少します。

この作業は、SIG AppsによりKEP #1847の一部として実施されました。

ベータに昇格した機能のハイライト

これは、v1.32のリリースに伴いベータとなった改善点の一部です。

JobのAPI管理メカニズム

JobのmanagedByフィールドがv1.32でベータに昇格しました。この機能により、外部コントローラー(Kueueなど)がJobの同期を管理できるようになり、高度なワークロード管理システムとのより柔軟な統合が可能になります。

この作業は、SIG AppsによりKEP #4368の一部として実施されました。

設定されたエンドポイントのみの匿名認証を許可

この機能により、管理者は匿名リクエストを許可するエンドポイントを指定できるようになりました。例えば、管理者は/healthz、/livez、/readyzなどのヘルスエンドポイントへの匿名アクセスのみを許可し、ユーザーがRBACを誤設定した場合でも、他のクラスターエンドポイントやリソースへの匿名アクセスを確実に防止できます。

この作業は、SIG AuthによりKEP #4633の一部として実施されました。

kube-schedulerにおけるプラグインごとの再スケジュール判断機能の改善

この機能は、プラグインごとのコールバック関数(QueueingHint)によってスケジューリングの再試行の判断をより効率的にすることで、スケジューリングのスループットを向上させます。すべてのプラグインがQueueingHintsを持つようになりました。

この作業は、SIG SchedulingによりKEP #4247の一部として実施されました。

ボリューム拡張の失敗からのリカバリー

この機能により、ユーザーは小さいサイズで再試行することでボリューム拡張の失敗から回復できるようになりました。この改善により、ボリューム拡張がより堅牢で信頼性の高いものとなり、プロセス中のデータ損失や破損のリスクが軽減されます。

この作業は、SIG StorageによりKEP #1790の一部として実施されました。

ボリュームグループスナップショット

この機能は、VolumeGroupSnapshot APIを導入し、ユーザーが複数のボリュームを同時にスナップショット取得できるようにすることで、ボリューム間のデータ整合性を確保します。

この作業は、SIG StorageによりKEP #3476の一部として実施されました。

構造化パラメーターのサポート

Dynamic Resource Allocation(DRA)のコア部分である構造化パラメーターのサポートがベータに昇格しました。これにより、kube-schedulerとCluster Autoscalerはサードパーティドライバーを必要とせずに、直接クレームの割り当てをシミュレーションできるようになりました。

これらのコンポーネントは、実際に割り当てを確定することなく、クラスターの現在の状態に基づいてリソース要求が満たされるかどうかを予測できるようになりました。サードパーティドライバーによる割り当ての検証やテストが不要になったことで、この機能はリソース分配の計画と意思決定を改善し、スケジューリングとスケーリングのプロセスをより効率的にします。

この作業は、WG Device Management(SIG Node、SIG Scheduling、SIG Autoscalingを含む機能横断チーム)によりKEP #4381の一部として実施されました。

ラベルとフィールドセレクターの認可

認可の判断にラベルとフィールドセレクターを使用できるようになりました。ノードの認可機能は、これを自動的に活用してノードが自身のPodのみをリストやウォッチできるように制限します。 Webhookの認可機能は、使用されるラベルやフィールドセレクターに基づいてリクエストを制限するように更新できます。

この作業は、SIG AuthによりKEP #4601の一部として実施されました。

アルファとして導入された新機能

これは、v1.32のリリースでアルファとして導入された主な改善点の一部です。

Kubernetesスケジューラーにおける非同期プリエンプション

Kubernetesスケジューラーは、プリエンプション操作を非同期で処理することでスケジューリングのスループットを向上させる、非同期プリエンプション機能が強化されました。プリエンプションは、優先度の低いPodを退避させることで、優先度の高いPodに必要なリソースを確保します。しかし、これまでこのプロセスではPodを削除するためのAPIコールなどの重い操作が必要で、スケジューラーの速度低下を引き起こしていました。この強化により、そのような処理が並列で実行されるようになり、スケジューラーは他のPodのスケジューリングを遅延なく継続できるようになりました。この改善は、特にPodの入れ替わりが頻繁なクラスターや、スケジューリングの失敗が頻発するクラスターで有効で、より効率的で堅牢なスケジューリングプロセスを実現します。

この作業は、SIG SchedulingによりKEP #4832の一部として実施されました。

CEL式を使用したMutating Admission Policy

この機能は、CELのオブジェクトインスタンス化とJSONパッチ戦略を、Server Side Applyのマージアルゴリズムと組み合わせて活用します。これにより、ポリシー定義が簡素化され、変更の競合が削減され、アドミッション制御のパフォーマンスが向上すると同時に、Kubernetesにおけるより堅牢で拡張可能なポリシーフレームワークの基盤が構築されます。

KubernetesのAPIサーバーは、Common Expression Language(CEL)ベースのMutating Admission Policyをサポートするようになり、Mutating Admission Webhookの軽量で効率的な代替手段を提供します。この強化により、管理者はCELを使用して、ラベルの設定、フィールドのデフォルト値設定、サイドカーの注入といった変更を、シンプルな宣言的な式で定義できるようになりました。このアプローチにより、運用の複雑さが軽減され、webhookの必要性が排除され、kube-apiserverと直接統合されることで、より高速で信頼性の高いプロセス内変更処理を実現します。

この作業は、SIG API MachineryによりKEP #3962の一部として実施されました。

Podレベルのリソース指定

この機能強化により、Podレベルでリソースの要求と制限を設定できるようになり、Pod内のすべてのコンテナが動的に使用できる共有プールを作成することで、Kubernetesのリソース管理が簡素化されます。これは特に、リソース需要が変動的またはバースト的なコンテナを持つワークロードにとって有用で、過剰なプロビジョニングを最小限に抑え、全体的なリソース効率を向上させます。

KubernetesはPodレベルでLinuxのcgroup設定を活用することで、これらのリソース制限を確実に適用しながら、密結合したコンテナが人為的な制約に縛られることなく、より効果的に連携できるようにします。重要なことに、この機能は既存のコンテナレベルのリソース設定との後方互換性を維持しており、ユーザーは現在のワークフローや既存の設定を中断することなく、段階的に採用できます。

これは、コンテナ間のリソース割り当て管理の運用複雑性を軽減するため、マルチコンテナPodにとって重要な改善となります。また、コンテナがワークロードを共有したり、最適なパフォーマンスを発揮するために互いの可用性に依存したりするサイドカーアーキテクチャなどの密接に統合されたアプリケーションにおいて、パフォーマンスの向上をもたらします。

この作業は、SIG NodeによりKEP #2837の一部として実施されました。

PreStopフックのスリープアクションでゼロ値を許可

この機能強化により、KubernetesのPreStopライフサイクルフックで0秒のスリープ時間を設定できるようになり、リソースの検証とカスタマイズのためのより柔軟な無操作オプションを提供します。これまでは、スリープアクションにゼロ値を設定しようとするとバリデーションエラーが発生し、その使用が制限されていました。この更新により、ユーザーはゼロ秒の時間を有効なスリープ設定として設定でき、必要に応じて即時実行と終了の動作が可能になります。

この機能強化は後方互換性があり、PodLifecycleSleepActionAllowZeroフィーチャーゲートによって制御されるオプトイン機能として導入されています。この変更は、実際のスリープ時間を必要とせずに、検証やAdmission Webhook処理のためにPreStopフックを必要とするシナリオで特に有効です。 Goのtime.After関数の機能に合わせることで、この更新はKubernetesワークロードの設定を簡素化し、使いやすさを向上させます。

この作業は、SIG NodeによりKEP #4818の一部として実施されました。

DRA：ResourceClaimステータスのための標準化されたネットワークインターフェースデータ

この機能強化により、ドライバーがResourceClaimの各割り当てオブジェクトに対して特定のデバイスステータスデータを報告できる新しいフィールドが追加されました。また、ネットワークデバイス情報を表現するための標準的な方法も確立されました。

この作業は、SIG NetworkによりKEP #4817の一部として実施されました。

コアコンポーネントの新しいstatuszとflagzエンドポイント

コアコンポーネントに対して、2つの新しいHTTPエンドポイント(/statuszと/flagz)を有効にできるようになりました。これらのエンドポイントは、コンポーネントが実行されているバージョン(Golangのバージョンなど)や、稼働時間、そのコンポーネントが実行された際のコマンドラインフラグの詳細を把握することで、クラスターのデバッグ性を向上させます。これにより、実行時および設定の問題の診断が容易になります。

この作業は、SIG InstrumentationによりKEP #4827とKEP #4828の一部として実施されました。

Windowsの逆襲

Kubernetesクラスターにおいて、Windowsノードの正常なシャットダウンのサポートが追加されました。このリリース以前、KubernetesはLinuxノードに対して正常なノードシャットダウン機能を提供していましたが、Windowsに対する同等のサポートは欠けていました。この機能強化により、Windowsノード上のkubeletがシステムのシャットダウンイベントを適切に処理できるようになりました。これにより、Windowsノード上で実行されているPodが正常に終了され、ワークロードの中断なしでの再スケジュールが可能になります。この改善により、特に計画的なメンテナンスやシステム更新時において、Windowsノードを含むクラスターの信頼性と安定性が向上します。

さらに、CPUマネージャー、メモリマネージャー、トポロジーマネージャーの改善により、Windowsノードに対するCPUとメモリのアフィニティサポートが追加されました。

この作業は、SIG WindowsによりKEP #4802とKEP #4885の一部として実施されました。

1.32における機能の昇格、非推奨化、および削除

GAへの昇格

ここでは、GA(一般提供 とも呼ばれる)に昇格したすべての機能を紹介します。新機能やアルファからベータへの昇格を含む完全な更新リストについては、リリースノートをご覧ください。

このリリースでは、以下の13個の機能強化がGAに昇格しました:

非推奨化と削除

Kubernetesの開発と成熟に伴い、プロジェクト全体の健全性のために、機能が非推奨化、削除、またはより良いものに置き換えられる場合があります。このプロセスの詳細については、Kubernetesの非推奨化と削除のポリシーをご覧ください。

古いDRA実装の廃止

KEP #3063により、Kubernetes 1.26でDynamic Resource Allocation(DRA)が導入されました。

しかし、Kubernetes v1.32では、このDRAのアプローチが大幅に変更されます。元の実装に関連するコードは削除され、KEP #4381が「新しい」基本機能として残ります。

既存のアプローチを変更する決定は、リソースの可用性が不透明であったことによるクラスターオートスケーリングとの非互換性に起因しており、これによりCluster Autoscalerとコントローラーの両方の意思決定が複雑化していました。新しく追加されたStructured Parameterモデルがその機能を置き換えます。

この削除により、Kubernetesはkube-apiserverとの双方向のAPIコールの複雑さを回避し、新しいハードウェア要件とリソースクレームをより予測可能な方法で処理できるようになります。

詳細については、KEP #3063をご覧ください。

API削除

Kubernetes v1.32では、以下のAPIが削除されます：

FlowSchemaとPriorityLevelConfigurationのflowcontrol.apiserver.k8s.io/v1beta3 APIバージョンが削除されます。これに備えるため、既存のマニフェストを編集し、v1.29以降で利用可能なflowcontrol.apiserver.k8s.io/v1 APIバージョンを使用するようにクライアントソフトウェアを書き換えることができます。既存の永続化されたオブジェクトはすべて新しいAPIを通じてアクセス可能です。 flowcontrol.apiserver.k8s.io/v1beta3における主な変更点として、PriorityLevelConfigurationのspec.limited.nominalConcurrencySharesフィールドは未指定の場合にのみデフォルトで30となり、明示的に0が指定された場合は30に変更されないようになりました。

詳細については、API廃止に関する移行ガイドを参照してください。

リリースノートとアップグレードに必要なアクション

Kubernetes v1.32リリースの詳細については、リリースノートをご確認ください。

入手方法

Kubernetes v1.32は、GitHubまたはKubernetesダウンロードページからダウンロードできます。

Kubernetesを始めるには、対話式のチュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスタを実行してください。また、kubeadmを使用して簡単にv1.32をインストールすることもできます。

リリースチーム

Kubernetesは、そのコミュニティのサポート、献身、そして懸命な努力に支えられて実現しています。各リリースチームは、皆様が頼りにしているKubernetesリリースを構成する多くの要素を構築するために協力して働く、献身的なコミュニティボランティアで構成されています。これには、コード自体からドキュメンテーション、プロジェクト管理に至るまで、コミュニティのあらゆる分野から専門的なスキルを持つ人々が必要です。

私たちは、Kubernetes v1.32リリースをコミュニティに提供するために多くの時間を費やしてくださったリリースチーム全体に感謝の意を表します。リリースチームのメンバーは、初めてShadowとして参加する人から、複数のリリースサイクルを経験したベテランのチームリーダーまで多岐にわたります。リリースリードのFrederico Muñozには、リリースチームを見事に率いて、あらゆる事柄を細心の注意を払って処理し、このリリースを円滑かつ効率的に実行してくれたことに、特別な感謝の意を表します。最後になりましたが、すべてのリリースメンバー(リードとShadowの双方)、そして14週間のリリース作業期間中に素晴らしい仕事と成果を上げてくれた以下のSIGsに、大きな感謝の意を表します：

SIG Docs - ドキュメントとブログのレビューにおける基本的なサポートを提供し、リリースのコミュニケーションとドキュメントチームとの継続的な協力を行ってくれました。
SIG K8s InfraとSIG Testing - 必要なすべてのインフラコンポーネントと共に、テストフレームワークを確実に維持するための素晴らしい仕事を行ってくれました。
SIG Releaseとすべてのリリースマネージャー - リリース全体の調整を通じて素晴らしいサポートを提供し、最も困難な課題でも適切かつタイムリーに対応してくれました。

プロジェクトの進捗速度

CNCFのK8s DevStatsプロジェクトは、Kubernetesと様々なサブプロジェクトの進捗に関する興味深いデータポイントを集計しています。これには、個人の貢献から貢献している企業の数まで、このエコシステムの進化に関わる取り組みの深さと広さを示す様々な情報が含まれています。

14週間(9月9日から12月11日まで)続いたv1.32リリースサイクルでは、125の異なる企業と559の個人がKubernetesに貢献しました。

クラウドネイティブエコシステム全体では、433の企業から合計2441人の貢献者がいます。これは前回のリリースサイクルと比較して、全体の貢献が7%増加し、参加企業数も14%増加したことを示しており、クラウドネイティブプロジェクトに対する強い関心とコミュニティの支持が表れています。

このデータの出典:

ここでの貢献とは、コミットの作成、コードレビュー、コメント、IssueやPRの作成、PR(ブログやドキュメントを含む)のレビュー、もしくはIssueやPRへのコメントを指します。

コントリビューターウェブサイトのGetting Startedから、貢献を始める方法をご確認ください。

Kubernetesプロジェクトとコミュニティの全体的な活動状況の詳細については、DevStatsをご確認ください。

イベント情報

2025年3月から6月にかけて開催予定のKubernetesとクラウドネイティブ関連のイベントをご紹介します。 KubeCon、KCD、その他世界各地で開催される注目のカンファレンスが含まれています。 Kubernetesコミュニティの最新情報を入手し、交流を深めましょう。

2025年3月

KCD - Kubernetes Community Days: Beijing, China: 3月 | 北京(中国)
KCD - Kubernetes Community Days: Guadalajara, Mexico: 2025年3月16日 | グアダラハラ(メキシコ)
KCD - Kubernetes Community Days: Rio de Janeiro, Brazil: 2025年3月22日 | リオデジャネイロ(ブラジル)

2025年4月

KubeCon + CloudNativeCon Europe 2025: 2025年4月1日-4日 | ロンドン(イギリス)
KCD - Kubernetes Community Days: Budapest, Hungary: 2025年4月23日 | ブダペスト(ハンガリー)
KCD - Kubernetes Community Days: Chennai, India: 2025年4月26日 | チェンナイ(インド)
KCD - Kubernetes Community Days: Auckland, New Zealand: 2025年4月28日 | オークランド(ニュージーランド)

2025年5月

KCD - Kubernetes Community Days: Helsinki, Finland: 2025年5月6日 | ヘルシンキ(フィンランド)
KCD - Kubernetes Community Days: San Francisco, USA: 2025年5月8日 | サンフランシスコ(アメリカ)
KCD - Kubernetes Community Days: Austin, USA: 2025年5月15日 | オースティン(アメリカ)
KCD - Kubernetes Community Days: Seoul, South Korea: 2025年5月22日 | ソウル(韓国)
KCD - Kubernetes Community Days: Istanbul, Turkey: 2025年5月23日 | イスタンブール(トルコ)
KCD - Kubernetes Community Days: Heredia, Costa Rica: 2025年5月31日 | エレディア(コスタリカ)
KCD - Kubernetes Community Days: New York, USA: 2025年5月 | ニューヨーク(アメリカ)

2025年6月

KCD - Kubernetes Community Days: Bratislava, Slovakia: 2025年6月5日 | ブラチスラバ(スロバキア)
KCD - Kubernetes Community Days: Bangalore, India: 2025年6月6日 | バンガロール(インド)
KubeCon + CloudNativeCon China 2025: 2025年6月10日-11日 | 香港
KCD - Kubernetes Community Days: Antigua Guatemala, Guatemala: 2025年6月14日 | アンティグアグアテマラ(グアテマラ)
KubeCon + CloudNativeCon Japan 2025: 2025年6月16日-17日 | 東京(日本)
KCD - Kubernetes Community Days: Nigeria, Africa: 2025年6月19日 | ナイジェリア

次期リリースに関するウェビナーのお知らせ

2025年1月9日(木)午後5時(太平洋時間) に開催されるKubernetes v1.32リリースチームメンバーによるウェビナーにご参加ください。このリリースの主要な機能や、アップグレード計画に役立つ非推奨化および削除された機能について学ぶことができます。詳細および参加登録については、CNCFオンラインプログラムサイトのイベントページをご覧ください。

参加方法

Kubernetesに関わる最も簡単な方法は、あなたの興味に合ったSpecial Interest Groups(SIG)のいずれかに参加することです。 Kubernetesコミュニティに向けて何か発信したいことはありますか？毎週のコミュニティミーティングや、以下のチャンネルであなたの声を共有してください。継続的なフィードバックとサポートに感謝いたします。

最新情報はBlueskyの@Kubernetes.ioをフォローしてください
Discussでコミュニティディスカッションに参加してください
Slackでコミュニティに参加してください
Stack Overflowで質問したり、回答したりしてください
あなたのKubernetesに関するストーリーを共有してください
Kubernetesの最新情報はブログでさらに詳しく読むことができます
Kubernetesリリースチームについてもっと学んでください

Kubernetes Upstream Training in Japanの取り組みの紹介

By Junya Okabe (筑波大学) / Organizing team of Kubernetes Upstream Training in Japan | 2024.10.28

私たちは、Kubernetes Upstream Training in Japanのオーガナイザーチームです。チームは、Kubernetesへのコントリビューションを続けるメンバーで構成され、その中にはReviewerやApprover、Chairといった役割を担う人々も含まれています。

私たちの目標は、Kubernetesのコントリビューターを増やし、コミュニティの成長を促進することです。Kubernetesコミュニティは親切で協力的ですが、初めての貢献はややハードルが高いと感じる方もいます。私たちのトレーニングプログラムは、そのハードルを下げ、初心者でもスムーズに参加できる環境を提供することを目的としています。

Kubernetes Upstream Training in Japanとは？

Kubernetes Upstream Training in Japanは2019年から始まり、年に1〜2回のペースで開催されています。当初、Kubernetes Upstream TrainingはKubeConのco-locatedイベント(Kubernetes Contributor Summit)の中で実施されていましたが、同様のイベントを日本でも行って日本人のコントリビューターを増やしたいという思いから、私たちはKubernetes Upstream Training in Japanを立ち上げました。

パンデミック以前は対面形式で行われていましたが、2020年以降はオンラインで開催しています。トレーニングでは、Kubernetesにまだコントリビューションをしたことがない方々に向けて、以下のような内容を提供しています。

Kubernetesコミュニティの紹介
Kubernetesのコードベースの紹介と、PRの作成方法
言語など参加障壁を低減するための工夫や勇気付け
開発環境のセットアップ方法
kubernetes-sigs/contributor-playgroundを使用したハンズオン

プログラムの最初に、なぜKubernetesにコントリビューションするのか、だれがKubernetesにコントリビューションできるのかを伝えます。 Kubernetesに貢献することは、世界中にインパクトのある貢献ができること、そしてKuberenetesコミュニティはみなさんからのコントリビューションを楽しみにしていることを伝えます！

KubernetesコミュニティやSIG、Working Groupについて説明します。また、私たちが主にコミュニケーションのために用いるSlackやGitHub、メーリングリストについて説明します。日本語を話す人の中には、英語によるコミュニケーションに障壁を感じる人もいます。また、コミュニティに初めて参加する人は、どこでどのようなコミュニケーションが行われているのか知る必要があります。もちろん、私たちがトレーニングの中で最も大切にしていることは第一歩を踏み出すことです！

次に、Member、Reviewer、Approver、Tech leadやChairといった役割や責任について説明します。

その後、Kubernetesのコードベースの構成、主要なリポジトリ、PRの作成方法、Prowを使ったCI/CDの仕組みなどを解説します。 PRが作成されてからマージされるまでのプロセスについて詳しく説明します。

いくつかの講義を行った後、実際に参加者には、kubernetes-sigs/contributor-playgroundを使用したハンズオンを行い、簡単なPRの作成を体験してもらいます。これにより、Kubernetesへのコントリビューションの流れを実感してもらうことが目的です。

プログラムの最後には、ローカルでのクラスター構築、コードのビルド、効率的なテスト実行方法など、kubernetes/kubernetesリポジトリに貢献するための具体的な開発環境のセットアップについても解説します。

参加者へのインタビュー

私たちのトレーニングプログラムに参加した方々にインタビューを行いました。参加した理由や感想、そして今後の目標について伺いました。

Keita Mochizukiさん（NTT DATA Group Corporation）

Keita Mochizukiさんは、Kubernetesや周辺のプロジェクトへ継続的に貢献しているコントリビューターです。 Keitaさんは、コンテナセキュリティのプロフェッショナルでもあり、最近は書籍の出版を行いました。また、新規コントリビューターのためのロードマップを公開しており、これは新たなコントリビューターにとって非常に役立つものです。

Junya: なぜKubernetes Upstream Trainingに参加しようと思いましたか？

Keita: 実は私は2020年と2022年の2回参加しました。2020年はk8sに触れ始めたばかりで、社外活動に参加してみようと思い、偶然Twitterで見かけて申し込みました。しかし、当時は知識も浅く、OSSにPRを送ること自体が雲の上の存在のように感じていました。そのため、受講後の理解度は浅く、なんとなく「ふーん」という感覚でした。

2回目の2022年は、具体的にコントリビューションを始めようとしていたタイミングで、再度参加しました。この時は事前調査も行い、疑問点を講義中に解決できたので、非常に実りある時間を過ごせました。

Junya: 参加してみて、どのような感想を持ちましたか？

Keita: このトレーニングは参加者のスタンス次第でその意義が大きく変わるものだと感じました。トレーニング自体は一般的な解説と簡単なハンズオンで構成されていますが、このトレーニングに参加したからといって、すぐにコントリビューションができるかというと、そう簡単ではありません。しかし、もし事前に自分が今後コントリビューションを行うイメージをなんとなくでも持っていたり、具体的な疑問や課題を明確にしておくことができれば、講師の方々が実際にコミュニティで培った貴重なノウハウを活かして、それらに対して丁寧に応えてくれるため、大変有意義なトレーニングになると思います。

Junya: コントリビューションの目的は何ですか？

Keita: 最初のモチベーションは「Kubernetesの深い理解と実績の獲得」で、つまり「コントリビューションそのものが目的」でした。現在はこれに加え、業務で発見したバグや制約への対応を目的にコントリビューションを行うこともあります。また、コントリビューション活動を通じて、ドキュメント化されていない仕様をソースコードから解析することへの抵抗が以前よりも少なくなりました。

Junya: コントリビューションをする中で、難しかったことは何ですか？

Keita: 最も難しかったのは、最初の一歩を踏み出すことでした。OSSへのコントリビューションには一定の知識やノウハウが必要となるため、本トレーニングをはじめ、さまざまなリソースの活用や人からのサポートが不可欠でした。その中で、「最初の一歩を踏み出すと、あとはどんどん前に進める」という言葉が強く印象に残っています。また、業務としてコントリビューションを続ける上で一番難しいのは、その成果を業績として示すことです。継続的に取り組むためには事業目標や戦略と関連付ける必要がありますが、UpstreamへのContributionは必ずしも短期的に業績に繋がるケースばかりではないため、そのことをマネージャーと十分に認識を合わせ、理解を得ることが重要であると考えています。

Junya: 今後の目標は何ですか？

Keita: よりインパクトのある領域にコントリビューションすることです。これまでは実績を得ることを主目的としていたため比較的小さな個々のバグ等を中心にコントリビューションを行うことが多かったのですが、今後はKubernetesのユーザーに対して影響度の高いものや、業務上の課題解決に繋がるものに挑戦の幅を広げたいと思っています。最近は自身がコードベースの開発や修正に携わった内容を公式ドキュメントに反映すると言うことも行っていますが、これも目標に向けての1歩だと考えています。

Junya: ありがとうございました！

Yoshiki Fujikaneさん（CyberAgent, Inc.）

Yoshiki Fujikaneさんは、CNCFのSandboxプロジェクトのひとりであるPipeCDのメンテナのひとりです。 PipeCDのKubernetesサポートに関する新機能の開発の他に、コミュニティ運営や、各種技術カンファレンスへの登壇も積極的に行っています。

Junya: なぜKubernetes Upstream Trainingに参加しようと思いましたか？

Yoshiki: 参加した当時はまだ学生時代でした。その時はEKSを軽く触っていただけでしたが、なんか難しいけどかっこいいな！とk8s自体に興味をふんわりと持っている状態でした。当時は本当にOSSは雲の上の存在で、ましてやk8sのupstreamの開発なんてすごすぎて手の届かない存在だと思ってました。OSSにはもともと興味があったのですが、何から始めればいいのかわからなかったです。そんな時にkubernetes upstream trainingの存在を知って、k8sへのコントリビューションに挑戦してみようと思いました。

Junya: 参加してみて、どのような感想を持ちましたか？

Yoshiki: OSSに関わるコミュニティがどんなものかを知るキッカケとしてとてもありがたいなと感じました。当時は英語力もそこまで高くなく、一次情報を見に行くことは自分にとって大きなハードルでした。 k8sは非常に大きなプロジェクトなので、コントリビューションに必要なことだけでなく、全体像があまりわかっていない状態でした。upstream trainingでは、コミュニティの構造を日本語で説明していただいたうえで、コントリビューションを実際に行うところまで一通り経験することができました。そこで、一次情報に関する情報を共有してくださったおかげで、その後自分なりにエントリーポイントとして利用しつつ追加で調査するキッカケづくりになって非常にありがたかったです。この経験から、一次情報を整理しつつ見る習慣を身につける必要があるなと思い、気になったものはGitHubのissueやdocsを漁りに見に行くようになりました。結果として、今はk8sのコントリビューション自体は行っていませんが、ここでの経験が別プロジェクトにコントリビューションするための素地となって役立っています。

Junya: 現在はどのような領域でコントリビューションを行っていますか？別のプロジェクトとはどのようなものでしょうか？

Yoshiki: 現在はk8sからは少し離れていて、CNCFのSandbox ProjectであるPipeCDのメンテナをやっています。PipeCDはCDツールの一つで、様々なアプリケーションプラットフォームに対してGitOpsスタイルでデプロイする機能を持っています。このツールは、元々サイバーエージェント内部で開発が始まりました。大小様々なチームが異なるプラットフォームを採用していた中で、統一的なUXで共通で利用できるCD基盤を実現するために開発が進められた背景があります。現在はk8s、AWS ECS、Lambda、Cloud Run、Terraformといったプラットフォームに対応しています。

Junya: PipeCDチームの中ではどのような役割ですか？

Yoshiki: 私はチーム内ではk8s周りの機能改善、開発をフルタイムの仕事として行っています。社内向けにPipeCDをSaaSとして提供しているため、そのサポートの一環として、新規機能の追加や既存機能の改善などを行うことが主な目的です。さらに、コード以外のコントリビューションとしては、PipeCD自体のコミュニティ拡大に向けて各種登壇であったり、コミュニティミーティングの運営を行っているところです。

Junya: Kubernetes周りの機能改善や開発とは具体的にどのようなものですか？

Yoshiki: PipeCDはKubernetesのGitOpsやProgressive Deliveryをサポートしていて、それらの機能開発などです。直近だと、マルチクラスタ上へのデプロイを効率化するための機能開発を進めているところです。

Junya: OSSコントリビューションを行うなかで、難しかったことはありますか？

Yoshiki: 機能の汎用性を維持しつつ、ユーザのユースケースを満たすように開発を進めることです。社内SaaSを運用する中で機能要望をいただいた際には、もちろん課題を解決するためにまずは機能追加を検討します。一方で、PipeCDはOSSとしてより多くのユーザに使ってもらうことも考えて行きたいです。なので、あるユースケースをもとに別のユースケースとしても使えるかどうかを考え、ソフトウェアとして汎用性をもたせるように意識しています。

Junya: 今後の目標を教えてください！

Yoshiki: PipeCDの機能拡張に力を入れていきたいと考えています。PipeCDは現在One CD for All のスローガンのもと開発を進めています。先程お伝えした通り、k8s、AWS ECS、Lambda、Cloud Run、Terraform の5種類に対応していますが、これ以外にもプラットフォームは存在しますし、今後も新たなプラットフォームが台頭してくるかもしれません。そこで、PipeCDは現在ユーザが独自に拡張できるようにプラグイン機構の開発を進めています。それに力を入れていきたいですね。また、k8sのマルチクラスタデプロイ向けの機能開発も進めているところで、これからもよりインパクトのあるコントリビューションをしていきたいと考えてます。

Junya: ありがとうございました！

Kubernetes Upstream Training の未来

私たちは、これからもKubernetes Upstream Training in Japanを継続して開催し、多くの新しいコントリビューターを迎えたいと考えています。次回の開催は11月末のCloudNative Days Winter 2024の中での開催を予定しています。

また、私たちの目標は、これらのトレーニングプログラムを日本だけでなく、世界中に広げていくことです。 Kubernetesは今年で10周年を迎えましたが、コミュニティがこれまで以上に活発になるためには、世界中の人々が貢献し続けることが重要です。現在、Upstream Trainingはいくつかの地域で開催されていますが、私たちはさらに多くの地域での開催を目指しています。

多くの人々がKubernetesコミュニティに参加し、貢献することで、私たちのコミュニティがますます活気づくことを楽しみにしています！

Kubernetes 1.31: Fine-grained SupplementalGroups control

By Shingo Omura (Woven By Toyota) | 2024.08.22

この記事ではKubernetes 1.31の新機能である、Pod内のコンテナにおける補助グループ制御の改善機能について説明します。

動機: コンテナイメージ内の`/etc/group`に定義される暗黙的なグループ情報

この挙動は多くのKubernetesクラスターのユーザー、管理者にとってあまり知られていないかもしれませんが、Kubernetesは、デフォルトでは、Podで定義された情報に加えて、コンテナイメージ内の/etc/groupのグループ情報を マージ します。

例を見てみましょう。このPodはsecurityContextでrunAsUser=1000、runAsGroup=3000、supplementalGroups=4000を指定しています。

implicit-groups.yaml

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

ctrコンテナでidコマンドを実行すると何が出力されるでしょうか？

# Podを作成してみましょう。
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/implicit-groups.yaml

# Podのコンテナが実行されていることを確認します。
$ kubectl get pod implicit-groups

# idコマンドを確認します。
$ kubectl exec implicit-groups -- id

出力は次のようになるでしょう。

uid=1000 gid=3000 groups=3000,4000,50000

Podマニフェストには50000は一切定義されていないにもかかわらず、補助グループ(groupsフィールド)に含まれているグループID50000は一体どこから来るのでしょうか? 答えはコンテナイメージの/etc/groupファイルです。

コンテナイメージの/etc/groupの内容が下記のようになっていることが確認できるでしょう。

$ kubectl exec implicit-groups -- cat /etc/group
...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

なるほど！コンテナのプライマリユーザーであるユーザー(1000)がグループ(50000)に属していることが最後のエントリから確認出来ました。

このように、コンテナイメージ上の/etc/groupで定義される、コンテナのプライマリユーザーのグループ情報は、Podからの情報に加えて 暗黙的にマージ されます。ただし、この挙動は、現在のCRI実装がDockerから引き継いだ設計上の決定であり、コミュニティはこれまでこの挙動について再検討することはほとんどありませんでした。

何が悪いのか？

コンテナイメージの/etc/groupから 暗黙的にマージ されるグループ情報は、特にボリュームアクセスを行う際に、セキュリティ上の懸念を引き起こすことがあります(詳細はkubernetes/kubernetes#112879を参照してください)。なぜなら、Linuxにおいて、ファイルパーミッションはuid/gidで制御されているからです。更に悪いことに、/etc/groupに由来する暗黙的なgidは、マニフェストにグループ情報の手がかりが無いため、ポリシーエンジン等でチェック・検知をすることが出来ません。これはKubernetesセキュリティの観点からも懸念となります。

PodにおけるFine-grained(きめ細かい) SupplementalGroups control: `SupplementaryGroupsPolicy`

この課題を解決するために、Kubernetes 1.31はPodの.spec.securityContextに、新しくsupplementalGroupsPolicyフィールドを追加します。

このフィールドは、Pod内のコンテナプロセスに付与される補助グループを決定するを方法を制御できるようにします。有効なポリシーは次の2つです。

Merge: /etc/groupで定義されている、コンテナのプライマリユーザーが所属するグループ情報をマージします。指定されていない場合、このポリシーがデフォルトです(後方互換性を考慮して既存の挙動と同様)。
Strict: fsGroup、supplementalGroups、runAsGroupフィールドで指定されたグループIDのみ補助グループに指定されます。つまり、/etc/groupで定義された、コンテナのプライマリユーザーのグループ情報はマージされません。

では、どのようにStrictポリシーが動作するか見てみましょう。

strict-supplementalgroups-policy.yaml

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

# Podを作成してみましょう。
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/strict-supplementalgroups-policy.yaml

# Podのコンテナが実行されていることを確認します。
$ kubectl get pod strict-supplementalgroups-policy

# プロセスのユーザー、グループ情報を確認します。
kubectl exec -it strict-supplementalgroups-policy -- id

出力はこのようになります。

uid=1000 gid=3000 groups=3000,4000

Strictポリシーによってグループ50000がgroupsから除外されているのが確認できました！

このように、確実にsupplementalGroupsPolicy: Strictを設定する(ポリシーエンジン等によって強制する)ことで、暗黙的な補助グループを回避することが可能になります。

備考:

このフィールドの値を強制するだけでは不十分な場合もあります。なぜなら、プロセスが自分自身のユーザー、グループ情報を変更できる権限/ケーパビリティを持っている場合があるからです。詳細は次のセクションを参照してください。

Podステータスにおける付与されたユーザー、グループ情報の確認

この機能は、Podのstatus.containerStatuses[].user.linuxフィールドでコンテナの最初のプロセスに付与されたユーザー、グループ情報を公開しています。暗黙的なグループIDが付与されているかどうかを確認するのに便利でしょう。

...
status:
  containerStatuses:
  - name: ctr
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

備考:

status.containerStatuses[].user.linuxフィールドで公開されているユーザー、グループ情報は、コンテナの最初のプロセスに、最初に付与された 情報であることに注意してください。もしそのプロセスが、自身のユーザー、グループ情報を変更できるシステムコール(例えば setuid(2), setgid(2), setgroups(2)等)を実行する権限を持っている場合、プロセス自身で動的に変更が可能なためです。つまり、実際にプロセスに付与されているユーザー、グループ情報は動的に変化します。

この機能を利用するには

supplementalGroupsPolicyフィールドを有効化するには、下記のコンポーネントを利用する必要があります。

Kubernetes: v1.31以降、かつ、SupplementalGroupsPolicyフィーチャーゲートが有効化されていること。v1.31現在、このフィーチャーゲートはアルファです。
CRI実装:
- containerd: v2.0以降
- CRI-O: v1.31以降

ノードの.status.features.supplementalGroupsPolicyフィールドでこの機能が利用可能かどうか確認出来ます。

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

将来の展望

Kubernetes SIG Nodeは、この機能が将来的なKubernetesのリリースでベータ版に昇格し、最終的には一般提供(GA)されることを望んでおり、期待しています。そうなれば、ユーザーはもはや機能ゲートを手動で有効にする必要がなくなります。

supplementalGroupsPolicyが指定されていない場合は、後方互換性のためにMergeポリシーが適用されます。

より学ぶには？

Podとコンテナにセキュリティコンテキストを設定する(supplementalGroupsPolicyの詳細)
KEP-3619: Fine-grained SupplementalGroups control

参加するには？

この機能はSIG Nodeコミュニティによって推進されています。コミュニティに参加して、上記の機能やそれ以外のアイデアやフィードバックを共有してください。皆さんからのご意見をお待ちしています！

Kubernetes 1.31: SPDYからWebSocketへのストリーミングの移行

By Sean Sullivan (Google) Shannon Kularathna (Google) | 2024.08.20

Kubernetes 1.31では、kubectlがストリーミングする際に、SPDYに代わりWebSocketプロトコルをデフォルトで使用するようになりました。

この記事では、この変更が意味するところと、なぜこれらのストリーミングAPIが重要なのかについて説明します。

KubernetesのストリーミングAPI

Kubernetesでは、HTTPまたはRESTfulインターフェースとして公開される特定のエンドポイントが、ストリーミングプロトコルが必要な、ストリーミング接続にアップグレードされます。リクエスト・レスポンス型プロトコルであるHTTPとは異なり、ストリーミングプロトコルは双方向・低遅延の永続的な接続を提供し、リアルタイムでの対話を可能にします。ストリーミングプロトコルは、クライアントとサーバー間で同一の接続を介して、双方向でのデータの読み書きをサポートします。このタイプの接続は、例えば、ローカルワークステーションから実行中のコンテナ内にシェルを作成し、そのコンテナ内でコマンドを実行する場合などに役立ちます。

なぜストリーミングプロトコルを変更するのか？

v1.31リリース以前は、Kubernetesはストリーミング接続をアップグレードする際に、デフォルトでSPDY/3.1プロトコルを使用していました。 SPDY/3.1は8年前に非推奨となっており、標準化されることはありませんでした。多くの最新のプロキシ、ゲートウェイ、ロードバランサーは、このプロトコルをサポートしていません。その結果、プロキシやゲートウェイを介してクラスターにアクセスしようとすると、kubectl cp、kubectl attach、kubectl exec、kubectl port-forwardなどのコマンドが機能しなくなることがあります。

Kubernetes v1.31以降、SIG API Machineryは、Kubernetesクライアント(kubectlなど)がこれらのコマンドに使用するストリーミングプロトコルを、よりモダンなWebSocketストリーミングプロトコルに変更しました。 WebSocketプロトコルは、現在サポートされている標準化されたストリーミングプロトコルであり、様々なコンポーネントやプログラミング言語間の互換性と相互運用性を保証します。 WebSocketプロトコルは、SPDYよりも最新のプロキシやゲートウェイで広くサポートされています。

ストリーミングAPIの仕組み

Kubernetesは、発信元のHTTPリクエストに特定のアップグレードヘッダーを追加することで、HTTP接続をストリーミング通信が可能な接続へと切り替えます。例えば、クラスター内のnginxコンテナでdateコマンドを実行するためのHTTPアップグレードリクエストは、以下のようになります:

$ kubectl exec -v=8 nginx -- date
GET https://127.0.0.1:43251/api/v1/namespaces/default/pods/nginx/exec?command=date…
Request Headers:
    Connection: Upgrade
    Upgrade: websocket
    Sec-Websocket-Protocol: v5.channel.k8s.io
    User-Agent: kubectl/v1.31.0 (linux/amd64) kubernetes/6911225

コンテナランタイムがWebSocketストリーミングプロトコルと、少なくとも1つのサブプロトコルバージョン(例:v5.channel.k8s.io)をサポートしている場合、サーバーは成功を示す101 Switching Protocolsステータスと、ネゴシエートされたサブプロトコルバージョンを含めて応答します:

Response Status: 101 Switching Protocols in 3 milliseconds
Response Headers:
    Upgrade: websocket
    Connection: Upgrade
    Sec-Websocket-Accept: j0/jHW9RpaUoGsUAv97EcKw8jFM=
    Sec-Websocket-Protocol: v5.channel.k8s.io

この時点で、HTTPプロトコルに使用されていたTCP接続はストリーミング接続に変更されています。この対話型シェルでのSTDIN、STDOUT、STDERR(ターミナルのリサイズ情報やプロセス終了コードも含む)データは、このアップグレードされた接続を通じてストリーミングされます。

新しいWebSocketストリーミングプロトコルの使用方法

クラスターとkubectlがバージョン1.29以降の場合、SPDYではなくWebSocketの使用を制御するための、2つのコントロールプレーンフィーチャーゲートと2つのkubectl環境変数があります。 Kubernetes 1.31では、以下のすべてのフィーチャーゲートがベータ版であり、デフォルトで有効になっています:

フィーチャーゲート
- TranslateStreamCloseWebsocketRequests
  - .../exec
  - .../attach
- PortForwardWebsockets
  - .../port-forward
kubectlの機能を制御する環境変数
- KUBECTL_REMOTE_COMMAND_WEBSOCKETS
  - kubectl exec
  - kubectl cp
  - kubectl attach
- KUBECTL_PORT_FORWARD_WEBSOCKETS
  - kubectl port-forward

古いバージョンのクラスターにおいても、フィーチャーゲート設定を管理できる場合であれば、TranslateStreamCloseWebsocketRequests(Kubernetes v1.29で追加)とPortForwardWebsockets(Kubernetes v1.30で追加)の両方を有効にして、この新しい動作を試すことができます。バージョン1.31のkubectlは自動的に新しい動作を使用できますが、サーバー側の機能が明示的に有効になっているクラスターに接続する必要があります。

ストリーミングAPIについてさらに学ぶ

Kubernetes v1.31: キャッシュからの整合性のある読み込みによるクラスターパフォーマンスの向上

By Marek Siarkowicz (Google) | 2024.08.15

Kubernetesはコンテナ化されたアプリケーションの堅牢なオーケストレーションで知られていますが、クラスターの規模が拡大するにつれて、コントロールプレーンへの負荷がボトルネックとなる可能性があります。特に大きな課題となっていたのは、etcdデータストアからのデータ読み込みの厳密な整合性を保証することです。これを実現するには、リソースを大量に消費するクォーラム読み込みが必要でした。

本日、Kubernetesコミュニティは、大きな改善を発表できることを嬉しく思います。 Kubernetes v1.31において、「キャッシュからの整合性のある読み込み」がベータ版に移行しました。

なぜ整合性のある読み込みが重要なのか

Kubernetes コンポーネントがクラスターの最新状態を正確に把握するためには、整合性のある読み込みが不可欠です。整合性のある読み込みを保証することで、Kubernetesの操作の正確性と信頼性が維持され、各コンポーネントは最新の情報に基づいて適切な判断を下すことができます。しかし、大規模なクラスターでは、そのためのデータの取得と処理がパフォーマンスのボトルネックとなるおそれがあります。特に、結果のフィルタリングを伴うリクエストでこの問題が顕著になります。 Kubernetesはetcd内で名前空間ごとにデータを直接フィルタリングできますが、ラベルやフィールドセレクタによるその他のフィルタリングでは、データセット全体をetcdから取得し、Kubernetes APIサーバーがメモリ上でフィルタリングを行う必要があります。この問題は、特にkubeletなどのコンポーネントに大きな影響を与えます。 kubeletは自身のノードにスケジュールされたPodのみをリストするだけで足りるところを、これまでの仕組みでは、APIサーバーとetcdがクラスター内のすべてのPodを処理する必要がありました。

ブレイクスルー: 信頼性の高いキャッシング

Kubernetesは、読み込み操作を最適化するために、以前からWatchキャッシュを使用してきました。 Watchキャッシュはクラスターの状態のスナップショットを保存し、etcdのWatchを通じて更新情報を受け取ります。しかし、これまではキャッシュが完全に最新の状態であることを保証できなかったため、整合性のある読み込みを直接提供することができませんでした。

「キャッシュからの整合性のある読み込み」機能は、etcdの進捗通知のメカニズムを活用してこの問題に対処します。この通知により、Watchキャッシュは自身とetcdを比較し、データが最新かどうかを把握できます。整合性のある読み込みが要求されると、システムはまずWatchキャッシュの内容が最新かどうかを確認します。キャッシュが最新でない場合、システムはキャッシュの内容が完全に更新されたと確認できるまで、etcdに進捗通知を問い合わせ続けます。そして準備が整うと、要求されたデータはキャッシュから直接読み取られ効率的に提供されます。このため、特にetcdから大量のデータを取得する必要があるような場面で、パフォーマンスを大幅に向上させることができます。以上のようにして、データをフィルタリングするリクエストをキャッシュから処理できるようになり、etcdから読み取る必要のあるメタデータは最小限に抑えられます。

重要な注意点: この機能を利用するには、Kubernetesクラスタでetcdバージョン3.4.31以降または3.5.13以降を実行している必要があります。古いバージョンのetcdを使用している場合、etcdから直接整合性のある読み込みを行う方式に自動で切り替わります。

体感できるパフォーマンスの向上

この一見単純な変更は、Kubernetesのパフォーマンスとスケーラビリティに大きな影響を与えます。

etcdの負荷軽減: Kubernetes v1.31では、etcdの作業負荷を軽減し、他の重要な操作のためにリソースを解放できます。
レイテンシの短縮: キャッシュからの読み込みは、etcdからデータを取得して処理するよりもはるかに高速です。これはコンポーネントへの応答が迅速になり、クラスター全体の応答性が向上することを意味します。
スケーラビリティの向上: etcdの負荷軽減により、コントロールプレーンはパフォーマンスを犠牲にすることなくより多くのリクエストを処理できるようになるため、数千ものノードとPodを持つような大規模なクラスターでは、最も大きなメリットが得られます。

5,000ノードのスケーラビリティテスト結果: 5,000ノードのクラスタで行われた最近のスケーラビリティテストでは、キャッシュからの整合性のある読み込みを有効にすることで、以下のような目覚ましい改善が見られました。

kube-apiserverのCPU使用率が 30%削減
etcdのCPU使用率が 25%削減
PodのLISTリクエストの99パーセンタイルレイテンシが最大 3分の1に短縮 (5秒から1.5秒)

今後の予定

ベータ版への移行により、キャッシュからの整合性のある読み込みはデフォルトで有効になり、サポートされているetcdバージョンを実行しているすべてのKubernetesユーザーにシームレスなパフォーマンス向上を提供します。

私たちの旅はこれで終わりではありません。 Kubernetesコミュニティは、将来的にさらにパフォーマンスを最適化するために、Watchキャッシュでのページネーションのサポートを積極的に検討しています。

はじめ方

Kubernetes v1.31にアップグレードし、etcdバージョン3.4.31以降または3.5.13以降を使用していることを確認するのが、キャッシュからの整合性のある読み込みのメリットを体験する最も簡単な方法です。ご質問やフィードバックがある場合は、Kubernetesコミュニティまでお気軽にお問い合わせください。

キャッシュからの整合性のある読み込みによって、あなたのKubernetes体験がどう変わったか、ぜひ教えてください！

この機能への貢献に対して、@ah8ad3 と @p0lyn0mial に特別な感謝を捧げます。

Kubernetes v1.31: Elli

By Kubernetes v1.31 Release Team | 2024.08.13

編集者: Matteo Bianchi, Yigit Demirbas, Abigail McCarthy, Edith Puclla, Rashan Smith

Kubernetes v1.31: Elliのリリースを発表します！

これまでのリリースと同様に、Kubernetes v1.31では新たなGA、ベータ、アルファの機能が導入されています。継続的に高品質なリリースを提供できていることは、私たちの開発サイクルの強さと、活発なコミュニティのサポートを示すものです。今回のリリースでは、45の機能強化が行われました。そのうち、11の機能がGAに昇格し、22の機能がベータに移行し、12の機能がアルファとして導入されています。

リリースのテーマとロゴ

Kubernetes v1.31のリリーステーマは"Elli"です。

Kubernetes v1.31のElliは、優しい心を持つ愛らしい犬で、かわいらしい船乗りの帽子をかぶっています。これは、多様で大きなKubernetesコントリビューターファミリーへの遊び心あふれる敬意を表しています。

Kubernetes v1.31は、プロジェクトが10周年を祝った後の初めてのリリースです。 Kubernetesは誕生以来、長い道のりを歩んできました。そして今もなお、各リリースで新たな方向に進化し続けています。 10年という節目を迎え、これを実現させた数え切れないほどのKubernetesコントリビューターたちの努力、献身、技術、知恵、そして地道な作業を振り返ると、深い感銘を受けずにはいられません。

プロジェクトの運営には膨大な労力が必要ですが、それにもかかわらず、熱意と笑顔を持って何度も貢献し、コミュニティの一員であることに誇りを感じる人々が絶えません。新旧問わずコントリビューターから見られるこの「魂」こそが、活気に満ちた、まさに「喜びにあふれた」コミュニティの証なのです。

Kubernetes v1.31のElliは、まさにこの素晴らしい精神を祝福する存在なのです！ Kubernetesの輝かしい次の10年に、みんなで乾杯しましょう！

GAに昇格した機能のハイライト

これは、v1.31のリリースに伴いGAとなった改善点の一部です。

AppArmorのサポートがGAに

KubernetesのAppArmorサポートがGAになりました。コンテナのsecurityContext内のappArmorProfile.typeフィールドを設定することで、AppArmorを使用してコンテナを保護できます。 Kubernetes v1.30より前では、AppArmorはアノテーションで制御されていましたが、v1.30からはフィールドを使用して制御されるようになりました。そのためアノテーションの使用をやめ、appArmorProfile.typeフィールドの使用に移行することをお勧めします。

詳細については、AppArmorのチュートリアルをご覧ください。この機能は、SIG NodeによってKEP #24の一環として開発しました。

kube-proxyによる外部からの接続の安定性改善

kube-proxyを使用した外部からの接続の安定性が、v1.31で大きく改善されました。 Kubernetesのロードバランサーに関する一般的な課題の1つに、トラフィックの損失を防ぐための各コンポーネント間の連携があります。この機能では、kube-proxyに新たな仕組みを導入し、type: LoadBalancerとexternalTrafficPolicy: Clusterを設定したサービスで公開される終了予定のNodeに対して、ロードバランサーが接続をスムーズに切り替えられるようにしています。また、クラウドプロバイダーとKubernetesのロードバランサー実装における推奨プラクティスも確立しました。

この機能を利用するには、kube-proxyがクラスタ上でデフォルトのサービスプロキシとして動作し、ロードバランサーが接続の切り替えをサポートしている必要があります。特別な設定は不要で、v1.30からkube-proxyにデフォルトで組み込まれており、v1.31で正式にGAとなりました。

詳しくは、仮想IPとサービスプロキシのドキュメントをご覧ください。

この機能は、SIG NetworkがKEP #3836の一環として開発しました。

永続ボリュームの状態変化時刻の記録機能が正式リリース

永続ボリュームの状態変化時刻を記録する機能が、v1.31で正式にリリースされました。この機能により、PersistentVolumeの状態が最後に変わった時刻を保存するPersistentVolumeStatusフィールドが追加されます。機能が有効になると、すべてのPersistentVolumeオブジェクトに.status.lastTransitionTimeという新しいフィールドが設けられ、ボリュームの状態が最後に変わった時刻が記録されます。ただし、この変更はすぐには反映されません。 Kubernetes v1.31にアップグレードした後、PersistentVolumeが更新され、状態(Pending、Bound、Released)が初めて変わったときに、新しいフィールドに時刻が記録されます。この機能により、PersistentVolumeがPendingからBoundに変わるまでの時間を測定できるようになります。また、様々な指標やSLOの設定にも活用できます。

詳しくは、永続ボリュームのドキュメントをご覧ください。

この機能は、SIG StorageがKEP #3762の一環として開発しました。

ベータに昇格した機能のハイライト

これは、v1.31のリリースに伴いベータとなった改善点の一部です。

kube-proxyでのnftablesバックエンドの導入

v1.31では、nftablesバックエンドがベータとして登場しました。この機能はNFTablesProxyModeという設定で制御され、現在はデフォルトで有効になっています。

nftables APIは、iptables APIの次世代版として開発され、より高いパフォーマンスと拡張性を提供します。 nftablesプロキシモードは、iptablesモードと比べてサービスエンドポイントの変更をより迅速かつ効率的に処理できます。また、カーネル内でのパケット処理も効率化されています(ただし、この効果は数万のサービスを持つ大規模クラスタでより顕著になります)。

Kubernetes v1.31の時点では、nftablesモードはまだ新しい機能のため、すべてのネットワークプラグインとの互換性が確認されているわけではありません。お使いのネットワークプラグインのドキュメントで対応状況を確認してください。このプロキシモードはLinux Nodeのみで利用可能で、カーネル5.13以降が必要です。移行を検討する際は、特にNodePortサービスに関連する一部の機能が、iptablesモードとnftablesモードで完全に同じように動作しない点に注意が必要です。デフォルト設定の変更が必要かどうかは、移行ガイドで確認してください。

この機能は、SIG NetworkがKEP #3866の一環として開発しました。

永続ボリュームのreclaimポリシーに関する変更

Kubernetes v1.31では、PersistentVolumeのreclaimポリシーを常に尊重する機能がベータになりました。この機能強化により、関連するPersistentVolumeClaim(PVC)が削除された後でも、PersistentVolume(PV)のreclaimポリシーが確実に適用されるようになり、ボリュームの漏洩を防止します。

これまでは、PVとPVCのどちらが先に削除されたかによって、特定の条件下でPVに設定されたreclaimポリシーが無視されることがありました。その結果、reclaimポリシーが"Delete"に設定されていても、外部インフラの対応するストレージリソースが削除されないケースがありました。これにより、一貫性の欠如やリソースのリークが発生する可能性がありました。

この機能の導入により、PVとPVCの削除順序に関係なく、reclaimポリシーの"Delete"が確実に実行され、バックエンドインフラから基盤となるストレージオブジェクトが削除されることがKubernetesによって保証されるようになりました。

この機能は、SIG StorageがKEP #2644の一環として開発しました。

バインドされたサービスアカウントトークンの改善

ServiceAccountTokenNodeBinding機能が、v1.31でベータに昇格しました。この機能により、PodではなくNodeにのみバインドされたトークンを要求できるようになりました。このトークンには、Node情報が含まれており、トークンが使用される際にNodeの存在を検証します。詳しくは、バインドされたサービスアカウントトークンのドキュメントをご覧ください。

この機能は、SIG AuthがKEP #4193の一環として開発しました。

複数のサービスCIDRのサポート

v1.31では、複数のサービスCIDRを持つクラスターのサポートがベータになりました(デフォルトでは無効)。

Kubernetesクラスターには、IPアドレスを使用する複数のコンポーネントがあります: Node、Pod、そしてServiceです。 NodeとPodのIP範囲は、それぞれインフラストラクチャやネットワークプラグインに依存するため、動的に変更できます。しかし、サービスのIP範囲は、クラスター作成時にkube-apiserverのハードコードされたフラグとして定義されていました。長期間運用されているクラスターや大規模なクラスターでは、管理者が割り当てられたサービスCIDR範囲を拡張、縮小、あるいは完全に置き換える必要があり、IPアドレスの枯渇が問題となっていました。これらの操作は正式にサポートされておらず、複雑で繊細なメンテナンス作業を通じて行われ、しばしばクラスタのダウンタイムを引き起こしていました。この新機能により、ユーザーとクラスター管理者はダウンタイムなしでサービスCIDR範囲を動的に変更できるようになります。

この機能の詳細については、仮想IPとサービスプロキシのドキュメントページをご覧ください。

この機能は、SIG NetworkがKEP #1880の一環として開発しました。

サービスのトラフィック分散機能

サービスのトラフィック分散機能が、v1.31でベータとなり、デフォルトで有効になりました。

SIG Networkingは、サービスネットワーキングにおける最適なユーザー体験とトラフィック制御機能を見出すため、何度も改良を重ねてきました。その結果、サービス仕様にtrafficDistributionフィールドを実装しました。このフィールドは、ルーティングの決定を行う際に、基盤となる実装が考慮すべき指針として機能します。

この機能の詳細については、1.30リリースブログをお読みいただくか、サービスのドキュメントページをご覧ください。

この機能は、SIG NetworkがKEP #4444の一環として開発しました。

Kubernetes VolumeAttributesClassによるボリューム修正機能

VolumeAttributesClass APIが、v1.31でベータになります。 VolumeAttributesClassは、プロビジョニングされたIOのような動的なボリュームパラメータを修正するための、Kubernetes独自の汎用APIを提供します。これにより、プロバイダーがサポートしている場合、ワークロードはコストとパフォーマンスのバランスを取るために、オンラインでボリュームを垂直スケーリングできるようになります。この機能は、Kubernetes 1.29からアルファとして提供されていました。

この機能は、SIG Storageが主導し、KEP #3751の一環として開発しました。

アルファとして導入された新機能

これは、v1.31のリリースでアルファとして導入された主な改善点の一部です。

アクセラレータなどのハードウェア管理を改善する新しいDRA API

Kubernetes v1.31では、動的リソース割り当て(DRA)APIとその設計が更新されました。この更新の主な焦点は構造化パラメータにあります。これにより、リソース情報とリクエストがKubernetesとクライアントに対して透明になり、クラスタのオートスケーリングなどの機能の実装が可能になります。 kubeletのDRAサポートも更新され、kubeletとコントロールプレーン間のバージョンの違いに対応できるようになりました。構造化パラメータにより、スケジューラはPodのスケジューリング時にResourceClaimを割り当てます。 DRAドライバコントローラによる割り当ては、現在「クラシックDRA」と呼ばれる方法でも引き続きサポートされています。

Kubernetes v1.31では、クラシックDRAにDRAControlPlaneControllerという別のフィーチャーゲートが用意されており、これを明示的に有効にする必要があります。このコントロールプレーンコントローラーを使用することで、DRAドライバは構造化パラメータではまだサポートされていない割り当てポリシーを実装できます。

この機能は、SIG NodeがKEP #3063の一環として開発しました。

イメージボリュームのサポート

Kubernetesコミュニティは、将来的に人工知能(AI)や機械学習(ML)のユースケースをより多く実現することを目指しています。

これらのユースケースを実現するための要件の1つは、Open Container Initiative(OCI)互換のイメージやアーティファクト(OCIオブジェクトと呼ばれる)を、ネイティブのボリュームソースとして直接サポートすることです。これにより、ユーザーはOCI標準に集中でき、OCIレジストリを使用してあらゆるコンテンツを保存・配布できるようになります。

そこで、v1.31では、OCIイメージをPod内のボリュームとして使用できる新しいアルファ機能が追加されました。この機能により、ユーザーはPod内でイメージ参照をボリュームとして指定し、それをコンテナ内のボリュームマウントとして再利用できます。この機能を試すには、ImageVolumeフィーチャーゲートを有効にする必要があります。

この機能は、SIG NodeとSIG StorageがKEP #4639の一環として開発しました。

Podステータスを通じたデバイスの健全性情報の公開

Podステータスを通じてデバイスの健全性情報を公開する機能が、v1.31で新しいアルファ機能として追加されました。デフォルトでは無効になっています。

Kubernetes v1.31以前では、Podが故障したデバイスと関連付けられているかどうかを知る方法は、PodResources APIを使用することでした。

この機能を有効にすると、各Pod の.status内の各コンテナステータスにallocatedResourcesStatusフィールドが追加されます。 allocatedResourcesStatusフィールドは、コンテナに割り当てられた各デバイスの健全性情報を報告します。

この機能は、SIG NodeがKEP #4680の一環として開発しました。

セレクターに基づいたより細かな認可

この機能により、Webhookオーソライザーや将来の(現在は設計されていない)ツリー内オーソライザーが、ラベルやフィールドセレクターを使用するリクエストに限り、listとwatchリクエストを許可できるようになります。例えば、オーソライザーは次のような表現が可能になります: このユーザーはすべてのPodをリストできないが、.spec.nodeNameが特定の値に一致するPodはリストできる。あるいは、ユーザーが名前空間内のconfidential: trueとラベル付けされていないすべてのSecretを監視することを許可する。 CRDフィールドセレクター(これもv1.31でベータに移行)と組み合わせることで、より安全なNodeごとの拡張機能を作成することが可能になります。

この機能は、SIG AuthがKEP #4601の一環として開発しました。

匿名APIアクセスへの制限

AnonymousAuthConfigurableEndpointsフィーチャーゲートを有効にすることで、ユーザーは認証設定ファイルを使用して、匿名リクエストがアクセスできるエンドポイントを設定できるようになりました。これにより、匿名ユーザーにクラスタへの広範なアクセスを与えてしまうようなRBAC設定ミスから、ユーザー自身を守ることができます。

この機能は、SIG AuthがKEP #4633の一環として開発しました。

1.31における機能の昇格、非推奨化、および削除

GAへの昇格

ここでは、GA(一般提供とも呼ばれる)に昇格したすべての機能を紹介します。新機能やアルファからベータへの昇格を含む完全な更新リストについては、リリースノートをご覧ください。

このリリースでは、以下の11個の機能強化がGAに昇格しました:

非推奨化と削除

cgroup v1のメンテナンスモードへの移行

Kubernetesがコンテナオーケストレーションの変化に適応し続ける中、コミュニティはv1.31でcgroup v1のサポートをメンテナンスモードに移行することを決定しました。この変更は、業界全体のcgroup v2への移行と歩調を合わせており、機能性、拡張性、そしてより一貫性のあるインターフェースの向上を提供します。 Kubernetesのメンテナンスモードとは、cgroup v1サポートに新機能が追加されないことを意味します。重要なセキュリティ修正は引き続き提供されますが、バグ修正はベストエフォートとなり、重大なバグは可能な場合修正されますが、一部の問題は未解決のままとなる可能性があります。

できるだけ早くcgroup v2への移行を開始することをお勧めします。この移行はアーキテクチャに依存し、基盤となるオペレーティングシステムとコンテナランタイムがcgroup v2をサポートしていることを確認し、ワークロードとアプリケーションがcgroup v2で正しく機能することを検証するためのテストを含みます。

問題が発生した場合は、issueを作成して報告してください。

この機能は、SIG NodeがKEP #4569の一環として開発しました。

SHA-1署名サポートに関する注意事項

go1.18(2022年3月リリース)以降、crypto/x509ライブラリはSHA-1ハッシュ関数で署名された証明書を拒否するようになりました。 SHA-1は安全でないことが確立されており、公的に信頼された認証局は2015年以降SHA-1証明書を発行していません。 Kubernetesのコンテキストでは、アグリケーションAPIサーバーやWebhookに使用される私的な認証局を通じてSHA-1ハッシュ関数で署名されたユーザー提供の証明書が依然として存在する可能性があります。 SHA-1ベースの証明書を使用している場合は、環境にGODEBUG=x509sha1=1を設定することで、明示的にそのサポートを有効にする必要があります。

GoのGODEBUGの互換性ポリシーに基づき、x509sha1 GODEBUGとSHA-1証明書のサポートは、go1.24で完全に削除される予定です。 go1.24は2025年前半にリリースされる予定です。 SHA-1証明書に依存している場合は、できるだけ早く移行を開始してください。

SHA-1サポートの終了時期、Kubernetesリリースがgo1.24を採用する計画、およびメトリクスと監査ログを通じてSHA-1証明書の使用を検出する方法の詳細については、Kubernetes issue #125689をご覧ください。

Nodeの`status.nodeInfo.kubeProxyVersion`フィールドの非推奨化(KEP 4004)

Kubernetes v1.31では、Nodeの.status.nodeInfo.kubeProxyVersionフィールドが非推奨となり、将来のリリースで削除される予定です。このフィールドの値が正確ではなかった(そして現在も正確ではない)ため、非推奨化されています。このフィールドはkubeletによって設定されますが、kubeletはkube-proxyのバージョンやkube-proxyが実行されているかどうかについて信頼できる情報を持っていません。

v1.31では、DisableNodeKubeProxyVersionフィーチャーゲートがデフォルトでtrueに設定され、kubeletは関連するNodeの.status.kubeProxyVersionフィールドを設定しなくなります。

クラウドプロバイダーとの全てのインツリー統合の削除

以前の記事で強調したように、クラウドプロバイダー統合の最後に残っていたインツリーサポートがv1.31リリースの一部として削除されました。これは、クラウドプロバイダーと統合できなくなったという意味ではありません。ただし、外部統合を使用する推奨アプローチを必ず使用する必要があります。一部の統合はKubernetesプロジェクトの一部であり、他はサードパーティのソフトウェアです。

この節目は、Kubernetes v1.26から始まった、全てのクラウドプロバイダー統合のKubernetesコアからの外部化プロセスの完了を示しています(KEP-2395)。この変更により、Kubernetesは真にベンダー中立なプラットフォームに近づきます。

クラウドプロバイダー統合の詳細については、v1.29 クラウドプロバイダー統合機能のブログ記事をお読みください。インツリーのコード削除に関する追加の背景については、(v1.29 非推奨化ブログ)をご確認ください。

後者のブログには、v1.29以降のバージョンに移行する必要があるユーザーにとって有用な情報も含まれています。

インツリープロバイダーのフィーチャーゲートの削除

Kubernetes v1.31では、以下のアルファフィーチャーゲートが削除されました: InTreePluginAWSUnregister、InTreePluginAzureDiskUnregister、InTreePluginAzureFileUnregister、InTreePluginGCEUnregister、InTreePluginOpenStackUnregister、およびInTreePluginvSphereUnregister。これらのフィーチャーゲートは、実際にコードベースから削除することなく、インツリーのボリュームプラグインが削除されたシナリオのテストを容易にするために導入されました。 Kubernetes 1.30でこれらのインツリーのボリュームプラグインが非推奨となったため、これらのフィーチャーゲートは冗長となり、もはや目的を果たさなくなりました。唯一残っているCSIの移行ゲートはInTreePluginPortworxUnregisterで、これはPortworxのCSI移行が完了し、そのツリー内ボリュームプラグインの削除準備が整うまでアルファのままとなります。

kubeletの`--keep-terminated-pod-volumes`コマンドラインフラグの削除

2017年に非推奨となったkubeletのフラグ--keep-terminated-pod-volumesが、v1.31リリースの一部として削除されました。

詳細については、Pull Request #122082をご覧ください。

CephFSボリュームプラグインの削除

CephFSボリュームプラグインがこのリリースで削除され、cephfsボリュームタイプは機能しなくなりました。

代わりに、サードパーティのストレージドライバーとしてCephFS CSIドライバーを使用することをお勧めします。クラスターバージョンをv1.31にアップグレードする前にCephFSボリュームプラグインを使用していた場合は、新しいドライバーを使用するようにアプリケーションを再デプロイする必要があります。

CephFSボリュームプラグインは、v1.28で正式に非推奨とマークされていました。

Ceph RBDボリュームプラグインの削除

v1.31リリースでは、Ceph RBDボリュームプラグインとそのCSI移行サポートが削除され、rbdボリュームタイプは機能しなくなりました。

代わりに、クラスターでRBD CSIドライバーを使用することをお勧めします。クラスターバージョンをv1.31にアップグレードする前にCeph RBDボリュームプラグインを使用していた場合は、新しいドライバーを使用するようにアプリケーションを再デプロイする必要があります。

Ceph RBDボリュームプラグインは、v1.28で正式に非推奨とマークされていました。

kube-schedulerにおける非CSIボリューム制限プラグインの非推奨化

v1.31リリースでは、すべての非CSIボリューム制限スケジューラープラグインが非推奨となり、デフォルトプラグインから既に非推奨となっているいくつかのプラグインが削除されます。これには以下が含まれます：

AzureDiskLimits
CinderLimits
EBSLimits
GCEPDLimits

これらのボリュームタイプはCSIに移行されているため、代わりにNodeVolumeLimitsプラグインを使用することをお勧めします。 NodeVolumeLimitsプラグインは、削除されたプラグインと同じ機能を処理できます。スケジューラーの設定で明示的にこれらのプラグインを使用している場合は、非推奨のプラグインをNodeVolumeLimitsプラグインに置き換えてください。 AzureDiskLimits、CinderLimits、EBSLimits、GCEPDLimitsプラグインは将来のリリースで削除される予定です。

これらのプラグインは、Kubernetes v1.14以降非推奨となっていたため、デフォルトのスケジューラープラグインリストから削除されます。

リリースノートとアップグレードに必要なアクション

Kubernetes v1.31リリースの詳細については、リリースノートをご確認ください。

`SchedulerQueueingHints`が有効な場合、スケジューラーはQueueingHintを使用するようになりました

スケジューラーに、Pod/Updatedイベントに登録されたQueueingHintを使用して、以前スケジュール不可能だったPodの更新がそれらをスケジュール可能にしたかどうかを判断するサポートが追加されました。この新機能は、フィーチャーゲートSchedulerQueueingHintsが有効な場合に動作します。

これまで、スケジュール不可能なPodが更新された場合、スケジューラは常にPodをキュー(activeQ / backoffQ)に戻していました。しかし、Podへのすべての更新がPodをスケジュール可能にするわけではありません。特に、現在の多くのスケジューリング制約が不変であることを考慮すると、そうではありません。新しい動作では、スケジュール不可能なPodが更新されると、スケジューリングキューはQueueingHint(s)を使用して、その更新がPodをスケジュール可能にする可能性があるかどうかをチェックします。少なくとも1つのQueueingHintがQueueを返した場合にのみ、それらをactiveQまたはbackoffQに再度キューイングします。

カスタムスケジューラープラグイン開発者向けの必要なアクション: プラグインからの拒否が、スケジュールされていないPod自体の更新によって解決される可能性がある場合、プラグインはPod/Updateイベントに対するQueueingHintを実装する必要があります。例えばschedulable=falseラベルを持つPodを拒否するカスタムプラグインを開発したとします。 schedulable=falseラベルを持つPodは、schedulable=falseラベルが削除されるとスケジュール可能になります。このプラグインはPod/Updateイベントに対するQueueingHintを実装し、スケジュールされていないPodでそのようなラベルの変更が行われた場合にQueueを返すようにします。詳細については、Pull Request #122234をご覧ください。

kubeletの`--keep-terminated-pod-volumes`コマンドラインフラグの削除

2017年に非推奨となったkubeletのフラグ--keep-terminated-pod-volumesが、v1.31リリースの一部として削除されました。

詳細については、Pull Request #122082をご覧ください。

入手方法

Kubernetes v1.31は、GitHubまたはKubernetesダウンロードページからダウンロードできます。

Kubernetesを始めるには、対話式のチュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスタを実行してください。また、kubeadmを使用して簡単にv1.31をインストールすることもできます。

リリースチーム

私たちは、Kubernetes v1.31リリースをコミュニティに提供するために多くの時間を費やしてくださったリリースチーム全体に感謝の意を表します。リリースチームのメンバーは、初めてShadowとして参加する人から、複数のリリースサイクルを経験したベテランのチームリーダーまで多岐にわたります。特に、リリースリーダーのAngelos Kolaitisには特別な感謝の意を表します。リリースサイクルを成功に導き、チーム全体をサポートし、各メンバーが最大限に貢献できる環境を整えると同時に、リリースプロセスの改善にも取り組んでくれました。

プロジェクトの進捗速度

CNCF K8s DevStatsプロジェクトは、Kubernetesと様々なサブプロジェクトの進捗に関する興味深いデータポイントを集計しています。これには、個人の貢献から貢献している企業の数まで、このエコシステムの進化に関わる取り組みの深さと広さを示す様々な情報が含まれています。

14週間(5月7日から8月13日まで)続いたv1.31リリースサイクルでは、113の異なる企業と528の個人がKubernetesに貢献しました。

クラウドネイティブエコシステム全体では、379の企業から合計2268人の貢献者がいます。これは、前回のリリースサイクルと比較して、貢献者数が驚異の63%増加しました！

このデータの出典:

ここでいう貢献とは、コミットの作成、コードレビュー、コメント、IssueやPRの作成、PRのレビュー(ブログやドキュメントを含む)、またはIssueやPRへのコメントを指します。

貢献に興味がある方は、このページを訪れて始めてください。

Kubernetesプロジェクトとコミュニティ全体の進捗速度についてもっと知りたい方は、DevStatsをチェックしてください。

イベント情報

2024年8月から11月にかけて開催予定のKubernetesとクラウドネイティブ関連のイベントをご紹介します。KubeCon、KCD、その他世界各地で開催される注目のカンファレンスが含まれています。Kubernetesコミュニティの最新情報を入手し、交流を深めましょう。

2024年8月

KubeCon + CloudNativeCon + Open Source Summit China 2024: 2024年8月21日-23日 | 香港
KubeDay Japan: 2024年8月27日 | 東京、日本

2024年9月

KCD Lahore - Pakistan 2024: 2024年9月1日 | ラホール、パキスタン
KuberTENes Birthday Bash Stockholm: 2024年9月5日 | ストックホルム、スウェーデン
KCD Sydney '24: 2024年9月5日-6日 | シドニー、オーストラリア
KCD Washington DC 2024: 2024年9月24日 | ワシントンDC、アメリカ合衆国
KCD Porto 2024: 2024年9月27日-28日 | ポルト、ポルトガル

2024年10月

KubeDay Australia: 2024年10月1日 | メルボルン、オーストラリア
KCD Austria 2024: 2024年10月8日-10日 | ウィーン、オーストリア
KCD UK - London 2024: 2024年10月22日-23日 | グレーターロンドン、イギリス

2024年11月

KubeCon + CloudNativeCon North America 2024: 2024年11月12日-15日 | ソルトレイクシティ、アメリカ合衆国
Kubernetes on EDGE Day North America: 2024年11月12日 | ソルトレイクシティ、アメリカ合衆国

次期リリースに関するウェビナーのお知らせ

2024年9月12日(木)午前10時(太平洋時間)に開催されるKubernetes v1.31リリースチームメンバーによるウェビナーにご参加ください。このリリースの主要な機能や、アップグレード計画に役立つ非推奨化および削除された機能について学ぶことができます。詳細および登録については、CNCFオンラインプログラムサイトのイベントページをご覧ください。

参加方法

最新情報はX(旧Twitter)の@Kubernetesioをフォローしてください
Discussでコミュニティディスカッションに参加してください
Slackでコミュニティに参加してください
Stack Overflowで質問したり、回答したりしてください
あなたのKubernetesに関するストーリーを共有してください
Kubernetesの最新情報はブログでさらに詳しく読むことができます
Kubernetesリリースチームについてもっと学んでください

Client-Goへのフィーチャーゲートの導入: 柔軟性と管理性を強化するために

By Ben Luddy (Red Hat), Lukasz Szaszkiewicz (Red Hat) | 2024.08.12

Kubernetesコンポーネントは フィーチャーゲート というオン/オフのスイッチを使うことで、新機能を追加する際のリスクを管理しています。 フィーチャーゲート の仕組みは、Alpha、Beta、GAといった各ステージを通じて、新機能の継続的な品質認定を可能にします。

kube-controller-managerやkube-schedulerのようなKubernetesコンポーネントは、client-goライブラリを使ってAPIとやりとりします。 Kubernetesエコシステムは、このライブラリをコントローラーやツール、Webhookなどをビルドするために利用しています。最新のclient-goにはそれ自体にフィーチャーゲート機構があり、開発者やクラスター管理者は新たなクライアントの機能を採用するかどうかを制御することができます。

Kubernetesにおけるフィーチャーゲートについて深く知るには、フィーチャーゲートを参照してください。

動機

client-goのフィーチャーゲートが登場するまでは、それぞれの機能が独自のやり方で、利用できる機能とその機能の有効化のための仕組みを区別していました。 client-goの新バージョンにアップデートすることで有効化できる機能もありました。その他の機能については、利用するプログラムからいつでも設定できる状態にしておく必要がありました。ごく一部の機能には環境変数を使って実行時に設定可能なものがありました。 kube-apiserverが提供するフィーチャーゲート機能を利用する場合、(設定や機能実装の時期が原因で)そうした機能をサポートしないクライアントサイドのフォールバック機構がしばしば必要になりました。これらのフォールバック機構で明らかになった問題があれば、問題の影響を緩和するためにclient-goのバージョンを固定したり、ロールバックしたりする必要がありました。

これらのいずれのアプローチも、client-goを利用するいくつかのプログラムに対してのみデフォルトで機能を有効化する場合には、よい効果をもたらすものではありませんでした。

単一のコンポーネントに対して新機能を有効化するだけでも、標準設定の変更が直ちにすべてのKubernetesコンポーネントに伝搬し、影響範囲は甚大なものとなっていました。

client-goにおけるフィーチャーゲート

こうした課題に対処するため、client-goの個別機能は新しいフィーチャーゲート機構を使うフェーズに移行します。 Kubernetesコンポーネントのフィーチャーゲート使用経験があるなら、開発者やユーザーは誰もが慣れ親しんだやり方で機能を有効化/無効化できるようになります。

client-goの最近のバージョンを使うだけで、client-goを用いてビルドしたソフトウェアを利用する方々にとってはいくつかの利益があります。

アーリーアダプターはデフォルトでは無効化されているclient-goの機能について、プロセス単位で有効化できます。
挙動がおかしな機能については、新たなバイナリをビルドせずに無効化できます。
client-goのすべての既知のフィーチャーゲートは状態が記録されており、ユーザーは機能の挙動を調査することができます。

client-goを用いてビルドするソフトウェアを開発している方々にとっては、次のような利益があります。

環境変数から client-goのフィーチャーゲートのオーバーライドを指定することができます。 client-goの機能にバグが見つかった場合は、新しいリリースを待たずに機能を無効化できます。
プログラムのデフォルトの挙動を変更する目的で、開発者は環境変数ベースのオーバーライドを他のソースからの読み込みで置き換えたり、実行時のオーバーライドを完全に無効化したりすることができます。このカスタマイズ可能な振る舞いは、Kubernetesコンポーネントの既存の--feature-gatesコマンドラインフラグや機能有効化メトリクス、ロギングを統合するのに利用します。

client-goのフィーチャーゲートをオーバーライドする

補足: ここではclient-goのフィーチャーゲートを実行時に上書きするデフォルトの方法について説明します。 client-goのフィーチャーゲートは、個々のプログラムの開発者がカスタマイズしたり、無効化したりすることができます。 Kubernetesコンポーネントではclient-goフィーチャーゲートの上書きを--feature-gatesフラグで制御します。

client-goの機能はKUBE_FEATUREから始まる名前の環境変数を設定することによって、有効化したり無効化したりすることができます。例えば、MyFeatureという名前の機能を有効化するには、次のような環境変数を設定します。

 KUBE_FEATURE_MyFeature=true

この機能を無効化したいときには、環境変数をfalseに設定します。

 KUBE_FEATURE_MyFeature=false

補足: いくつかのオペレーティングシステムでは、環境変数は大文字小文字が区別されます。したがってKUBE_FEATURE_MyFeatureとKUBE_FEATURE_MYFEATUREは異なる２つの変数として認識される場合があります。

client-goのフィーチャーゲートをカスタマイズする

標準のフィーチャーゲート上書き機能である環境変数ベースの仕組みは、Kubernetesエコシステムの多くのプログラムにとって十分なものと言え、特殊なインテグレーションが不要なやり方です。異なる挙動を必要とするプログラムのために、この仕組みを独自のフィーチャーゲートプロバイダーで置き換えることもできます。これにより、うまく動かないことが分かっている機能を強制的に無効化したり、フィーチャーゲートを直接外部の設定サービスから読み込んだり、コマンドラインオプションからフィーチャーゲートの上書きを指定したりすることができるようになります。

Kubernetesコンポーネントはclient-goの標準のフィーチャーゲートプロバイダーを、既存のKubernetesフィーチャーゲートプロバイダーに対する接ぎ木(shim)を使って置き換えます。

実用的な理由から、client-goのフィーチャーゲートは他のKubernetesのフィーチャーゲートと同様に取り扱われています。 (--feature-gatesコマンドラインフラグに落とし込まれた上で、機能有効化メトリクスに登録され、プログラム開始時にログがなされます)。

標準のフィーチャーゲートプロバイダーを置き換えるには、Gatesインターフェースを実装し、パッケージ初期化の際にReplaceFeatureGatesを呼ぶ必要があります。以下は簡単な例です。

import (
 “k8s.io/client-go/features”
)

type AlwaysEnabledGates struct{}

func (AlwaysEnabledGates) Enabled(features.Feature) bool {
 return true
}

func init() {
 features.ReplaceFeatureGates(AlwaysEnabledGates{})
}

定義済みのclient-goの機能の完全な一覧が必要な場合は、Registryインターフェースを実装してAddFeaturesToExistingFeatureGatesを呼ぶことで取得できます。完全な例としてはKubernetesにおける使用方法を参考にしてください。

まとめ

client-go v1.30のフィーチャーゲートの導入により、client-goの新機能のロールアウトを安全かつ簡単に実施できるようになりました。ユーザーや開発者はclient-goの新機能を採用するペースを管理できます。

Kubernetes APIの両側にまたがる機能の品質認定に関する共通のメカニズムができたことによって、Kubernetesコントリビューターの作業は効率化されつつあります。

SIG Nodeの紹介

By Arpit Agrawal | 2024.06.20

コンテナオーケストレーションの世界で、Kubernetesは圧倒的な存在感を示しており、世界中で最も複雑で動的なアプリケーションの一部を動かしています。その裏では、Special Interest Groups(SIG)のネットワークがKubernetesの革新と安定性を牽引しています。

今日は、SIG NodeのメンバーであるMatthias Bertschy、Gunju Kim、Sergey Kanzhelevにお話を伺い、彼らの役割、課題、そしてSIG Node内の注目すべき取り組みについて光を当てていきます。

複数の回答者による共同回答の場合は、回答者全員のイニシャルで表記します。

自己紹介

Arpit: 本日はお時間をいただき、ありがとうございます。まず、自己紹介とSIG Node内での役割について簡単に教えていただけますか？

Matthias: Matthias Bertschyと申します。フランス人で、フランスアルプスの近く、ジュネーブ湖のそばに住んでいます。2017年からKubernetesのコントリビューターとして活動し、SIG Nodeのレビュアー、そしてProwのメンテナーを務めています。現在は、ARMOというセキュリティスタートアップでシニアKubernetes開発者として働いています。ARMOは、KubescapeというプロジェクトをCNCFに寄贈しました。

ジュネーブ湖とアルプス

Gunju: Gunju Kimと申します。NAVERでソフトウェアエンジニアとして働いており、検索サービス用のクラウドプラットフォームの開発に注力しています。2021年から空き時間を使ってKubernetesプロジェクトにコントリビュートしています。

Sergey: Sergey Kanzhelevと申します。3年間KubernetesとGoogle Kubernetes Engineに携わり、長年オープンソースプロジェクトに取り組んできました。現在はSIG Nodeの議長を務めています。

SIG Nodeについて

Arpit: ありがとうございます！Kubernetesエコシステム内でのSIG Nodeの責任について、読者の方々に概要を説明していただけますか？

M/G/S: SIG NodeはKubernetesで最初に、あるいは最初期に設立されたSIGの1つです。このSIGは、KubernetesとNodeリソースとのすべてのやり取り、そしてNode自体のメンテナンスに責任を持っています。これはかなり広範囲に及び、SIGはKubernetesのコードベースの大部分を所有しています。この広範な所有権のため、SIG NodeはSIG Network、SIG Storage、SIG Securityなど他のSIGと常に連絡を取り合っており、Kubernetesの新機能や開発のほとんどが何らかの形でSIG Nodeに関わっています。

Arpit: SIG NodeはKubernetesのパフォーマンスと安定性にどのように貢献していますか？

M/G/S: Kubernetesは、安価なハードウェアを搭載した小型の物理VMから、大規模なAI/ML最適化されたGPU搭載Nodeまで、さまざまなサイズと形状のNodeで動作します。Nodeは数か月オンラインのままの場合もあれば、クラウドプロバイダーの余剰コンピューティングで実行されているため、短命で任意のタイミングでプリエンプトされる可能性もあります。

Node上のKubernetesエージェントであるkubeletは、これらすべての環境で確実に動作する必要があります。近年、kubeletの操作パフォーマンスの重要性が増しています。その理由は二つあります。一つは、Kubernetesが通信や小売業などの分野で、より小規模なNodeで使用されるようになってきており、可能な限り小さなリソース消費(フットプリント)で動作することが求められているからです。もう一つは、AI/MLワークロードでは各Nodeが非常に高価なため、操作の遅延がわずか1秒でも計算コストに大きな影響を与える可能性があるからです。

課題と機会

Arpit: SIG Nodeが今後直面すると予想される課題や可能性について、どのようなものがあるでしょうか？

M/G/S: Kubernetesが誕生から10年を迎え、次の10年に向かう中で、新しい種類のワークロードへの対応が強く求められています。SIG Nodeはこの取り組みで重要な役割を果たすことになるでしょう。後ほど詳しく説明しますが、サイドカーのKEPは、こうした新しいタイプのワークロードをサポートするための取り組みの一例です。

今後数年間の主な課題は、既存の機能の品質と後方互換性を維持しつつ、いかに革新を続けていくかということです。 SIG Nodeは、これからもKubernetesの開発において中心的な役割を担い続けるでしょう。

Arpit: SIG Nodeで現在取り組んでいる研究や開発分野の中で、特に注目しているものはありますか？

M/G/S: 新しいタイプのワークロードへの対応は、私たちにとって非常に興味深い分野です。最近取り組んでいるサイドカーコンテナの研究はその好例といえるでしょう。サイドカーは、アプリケーションの中核となるコードを変更することなく、その機能を拡張できる柔軟なソリューションを提供します。

Arpit: SIG Nodeを維持する上で直面した課題と、それをどのように克服したかを教えてください。

M/G/S: SIG Nodeが直面する最大の課題は、その広範な責任範囲と数多くの機能要望への対応です。この課題に取り組むため、私たちは新たなレビュアーの参加を積極的に呼びかけています。また、常にプロセスの改善に努め、フィードバックに迅速に対応できる体制を整えています。さらに、各リリースの後にはSIG Nodeのミーティングでフィードバックセッションを開催し、問題点や改善が必要な分野を特定し、具体的な行動計画を立てています。

Arpit: SIG Nodeが現在注目している技術や、Kubernetesへの導入を検討している新しい機能などはありますか？

M/G/S: SIG Nodeは、Kubernetesが依存しているさまざまなコンポーネントの開発に積極的に関与し、その進展を注意深く見守っています。これには、コンテナランタイム(containerdやCRI-Oなど)やOSの機能が含まれます。例えば、現在 cgroup v1 の廃止と削除が迫っていますが、これに対してKubernetesユーザーが円滑に移行できるよう、SIG NodeとKubernetesプロジェクト全体で取り組んでいます。また、containerdがバージョン2.0をリリースする予定ですが、これには非推奨機能の削除が含まれており、Kubernetesユーザーにも影響が及ぶと考えられます。

Arpit: SIG Nodeのメンテナーとしての経験の中で、特に誇りに思う思い出深い経験や成果を共有していただけますか？

Mathias: 最高の瞬間は、私の最初のKEP(startupProbeの導入)がついにGA(General Availability)に昇格したときだと思います。また、私の貢献がコントリビューターによって日々使用されているのを見るのも楽しいです。例えば、スカッシュコミットにもかかわらずLGTMを保持するために使用されるGitHubツリーハッシュを含むコメントなどです。

サイドカーコンテナ

Arpit: Kubernetesの文脈におけるサイドカーコンテナの概念とその進化について、もう少し詳しく教えていただけますか？

M/G/S: サイドカーコンテナの概念は、Kubernetesが複合コンテナのアイデアを導入した2015年にさかのぼります。同じPod内でメインのアプリケーションコンテナと並行して実行されるこれらの追加コンテナは、コアのコードベースを変更することなくアプリケーションの機能を拡張・強化する方法として見られていました。サイドカーの初期の採用者はカスタムスクリプトと設定を使用して管理していましたが、このアプローチは一貫性とスケーラビリティの面で課題がありました。

Arpit: サイドカーコンテナが特に有益な具体的なユースケースや例を共有していただけますか？

M/G/S: サイドカーコンテナは、さまざまな方法でアプリケーションの機能を強化するために使用できる多用途なツールです:

ロギングとモニタリング: サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナからログとメトリクスを収集し、中央のロギングおよびモニタリングシステムに送信できます。
トラフィックのフィルタリングとルーティング: サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナとの間のトラフィックをフィルタリングおよびルーティングできます。
暗号化と復号化: サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナと外部サービスの間で流れるデータを暗号化および復号化できます。
データ同期: サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナと外部データベースやサービスの間でデータを同期できます。
フォールトインジェクション: サイドカーコンテナを使用して、Pod内の主要アプリケーションコンテナに障害を注入し、障害に対する耐性をテストできます。

Arpit: 提案によると、一部の企業がサイドカー機能を追加したKubernetesのフォークを使用しているそうです。この機能の採用状況やコミュニティの関心度について、何か見解をお聞かせいただけますか？

M/G/S: 採用率を測定する具体的な指標はありませんが、KEPはコミュニティから大きな関心を集めています。特にIstioのようなサービスメッシュベンダーは、アルファテストフェーズに積極的に参加しました。KEPの可視性は、多数のブログ投稿、インタビュー、講演、ワークショップを通じてさらに実証されています。KEPは、ネットワークプロキシ、ロギングシステム、セキュリティ対策など、KubernetesのPod内のメインコンテナと並行して追加機能を提供する需要の増加に対応しています。コミュニティは、この機能の広範な採用を促進するために、既存のワークロードに対する容易な移行パスを提供することの重要性を認識しています。

Arpit: 本番環境でサイドカーコンテナを使用している企業の注目すべき例や成功事例はありますか？

M/G/S: 本番環境での広範な採用を期待するにはまだ早すぎます。1.29リリースは2024年1月11日からGoogle Kubernetes Engine(GKE)で利用可能になったばかりで、ユニバーサルインジェクターを介して効果的に有効化し使用する方法に関する包括的なドキュメントがまだ必要です。人気のあるサービスメッシュプラットフォームであるIstioも、ネイティブサイドカーを有効にするための適切なドキュメントが不足しているため、開発者がこの新機能を使い始めるのが難しくなっています。しかし、ネイティブサイドカーのサポートが成熟し、ドキュメントが改善されるにつれて、本番環境でのこの技術のより広範な採用が期待できます。

Arpit: 提案では、サイドカー機能を実現するために初期化したコンテナにrestartPolicyフィールドを導入することが示されています。この方法で、先ほど挙げられた課題をどのように解決できるのか、詳しく教えていただけますか？

M/G/S: 初期化したコンテナにrestartPolicyフィールドを導入する提案は、既存のインフラストラクチャを活用し、サイドカーの管理を簡素化することで、概説された課題に対処します。このアプローチは、Podの仕様に新しいフィールドを追加することを避け、管理しやすさを保ちつつ、さらなる複雑さを回避します。既存の初期化したコンテナのメカニズムを利用することで、サイドカーはPodの起動時に通常の初期化コンテナと並行して実行でき、一貫した初期化の順序を確保します。ささらに、サイドカー用の初期化コンテナの再起動ポリシーをAlwaysに設定することで、メインアプリケーションコンテナが終了した後も、ロギングやモニタリングなどの継続的なサービスをワークロードの終了まで維持できます。

Arpit: 初期化したコンテナにrestartPolicyフィールドを導入することは、既存のKubernetes設定との後方互換性にどのような影響を与えますか？

M/G/S: 初期化したコンテナにrestartPolicyフィールドを導入しても、既存のKubernetes設定との後方互換性は維持されます。既存の初期化したコンテナは従来通りに機能し続け、新しいrestartPolicyフィールドは、明示的にサイドカーとして指定された初期化したコンテナにのみ適用されます。このアプローチにより、既存のアプリケーションやデプロイメントが新機能によって中断されることはなく、同時にサイドカーをより効果的に定義および管理する方法が提供されます。

SIG Nodeへの貢献

Arpit: 新しいメンバー、特に初心者が貢献するのに最適な方法は何でしょうか？

M/G/S: 新しいメンバーや初心者は、サイドカーに関するKEP(Kubernetes Enhancement Proposal)に対して、以下の方法で貢献できます:

認知度の向上: サイドカーの利点と使用例を紹介するコンテンツを作成します。これにより、他の人々にこの機能の理解を深めてもらい、採用を促すことができます。
フィードバックの提供: サイドカーの使用経験(良い点も悪い点も)を共有してください。このフィードバックは、機能の改善や使いやすさの向上に役立ちます。
ユースケースの共有: 本番環境でサイドカーを使用している場合は、その経験を他の人と共有してください。実際の使用例を示すことで、この機能の価値を実証し、他の人々の採用を促進できます。
ドキュメントの改善: この機能のドキュメントの明確化や拡充にご協力ください。より分かりやすいドキュメントは、他の人々がサイドカーを理解し、活用する助けになります。

サイドカーに関するKEP以外にも、SIG Nodeではより多くの貢献者を必要としている分野があります:

テストカバレッジの向上: SIG Nodeでは、Kubernetesコンポーネントのテストカバレッジを継続的に改善する方法を模索しています。
CI(継続的インテグレーション)の維持: SIG Nodeは、Kubernetesコンポーネントが様々な状況下で期待通りに動作することを確認するため、一連のエンドツーエンド(e2e)テストを管理しています。

結論

SIG Nodeは、Kubernetesの発展において重要な役割を果たしています。クラウドネイティブ・コンピューティングの絶えず変化する環境の中で、Kubernetesの信頼性と適応性を確保し続けています。 Matthias、Gunju、Sergeyといった献身的なメンバーが先頭に立ち、SIG Nodeは革新の最前線に立ち続けています。彼らの努力により、Kubernetesは新たな地平を目指して前進し続けているのです。

Kubernetesの10年間の歴史

By Bob Killen (CNCF), Chris Short (AWS), Frederico Muñoz (SAS), Kaslin Fields (Google), Tim Bannister (The Scale Factory), and every contributor across the globe | 2024.06.06

KCSEU 2024 group photo

10年前の2014年6月6日、Kubernetesの最初のコミットがGitHubにプッシュされました。 Go、Bash、Markdownで書かれた250のファイルと47,501行のコードを含むその最初のコミットが、今日のKubernetesプロジェクトの始まりでした。それから10年後の今日、Kubernetesが44か国から8,000社以上の企業、88,000人以上のコントリビューターを有する、これまでで最大のオープンソースプロジェクトの一つに成長するとは誰が予想したでしょうか。

このマイルストーンはKubernetesだけでなく、そこから生まれたクラウドネイティブエコシステムにとっても重要なものです。 CNCFには約200のプロジェクトがあり、240,000人以上のコントリビューターからのコントリビューションがあります。また、より広いエコシステムの中でも数千人のコントリビューターがいます。 Kubernetesが今日の姿になれたのは、彼らや700万人以上の開発者、さらに多くのユーザーコミュニティがエコシステムを形作る手助けをしてくれたおかげです。

Kubernetesの始まり - 技術の収束

Kubernetesの元となるアイディアは、(2013年に登場した)最初のコミットや最初のプロトタイプの前から存在していました。 2000年代初頭、ムーアの法則が有効に機能していました。コンピューティングハードウェアは非常に速い速度でますます強力になり、それに対応してアプリケーションもますます複雑化していきました。このハードウェアのコモディティ化とアプリケーションの複雑化の組み合わせにより、ソフトウェアをハードウェアからさらに抽象化する必要が生じ、解決策が現れ始めました。

当時の多くの企業と同様にGoogleも急速に拡大しており、同社のエンジニアたちはLinuxカーネル内での隔離の形態を作り出すというアイデアに興味を持っていました。 Googleのエンジニア、Rohit Sethはそのコンセプトを2006年のメールで説明しました。

ワークロードのメモリやタスクなどのシステムリソースの使用を追跡し、課金する構造を示すためにコンテナという用語を使用します。

2013年3月、PyConでSolomon Hykesが行った5分間のライトニングトークThe future of Linux Containersでは、Linuxコンテナを作成および使用するためのオープンソースツールである「Docker」が紹介されました。 DockerはLinuxコンテナに使いやすさをもたらし、これまで以上に多くのユーザーが利用できるようになりました。 Dockerの人気が急上昇し、Linuxコンテナの抽象化を誰もが利用できるようにしたことで、アプリケーションをより移植性が高く、再現性のある方法で実行できるようになりました。しかし、依然としてスケールの問題は残っていました。

Googleのアプリケーションオーケストレーションをスケールで管理するBorgシステムは、2000年代半ばにLinuxコンテナを採用しました。その後、GoogleはOmegaと呼ばれるシステムの新バージョンの開発も開始しました。 BorgとOmegaシステムに精通していたGoogleのエンジニアたちは、Dockerによって駆動するコンテナ化の人気を目の当たりにしました。そしてBrendan Burnsのブログで説明されているように、オープンソースのコンテナオーケストレーションシステムの必要性だけでなく、その「必然性」を認識しました。この認識は2013年秋にJoe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant、Daniel Smithを含む小さなチームにKubernetesのプロジェクトを始めるインスピレーションを与えました。

Kubernetesの10年間

Kubernetesの歴史は2014年6月6日のその歴史的なコミットと、2014年6月10日のDockerCon 2014でのGoogleエンジニアEric Brewerによる基調講演(およびそれに対応するGoogleブログ)でのプロジェクト発表から始まります。

その後の1年間で、主にGoogleとRed Hatからのコントリビューターによる小さなコミュニティがプロジェクトに取り組み、2015年7月21日にバージョン1.0のリリースに至りました。 1.0と同時に、GoogleはKubernetesをLinux Foundationの新たに設立された部門であるCloud Native Computing Foundation (CNCF)に寄贈することを発表しました。

1.0に到達したものの、Kubernetesプロジェクトは依然として使いにくく理解しにくいものでした。 KubernetesのコントリビューターであるKelsey Hightowerはプロジェクトの使いやすさの欠点に特に注目し、2016年7月7日に彼の有名な"Kubernetes the Hard Way"ガイドの最初のコミットをプッシュしました。

プロジェクトは最初の1.0リリース以来大きく変わり、いくつかの大きな成果を経験しました。たとえば、1.16でのCustom Resource Definition (CRD)のGAや、1.23での完全なデュアルスタックサポートの開始などです。また、1.22での広く使用されているベータ版APIの削除や、Dockershimの廃止から学んだコミュニティの「教訓」もあります。

1.0以降の注目すべきアップデート、マイルストーン、およびイベントには以下のものがあります。

2016年12月 - Kubernetes 1.5でCRIの最初のサポートとアルファ版Windowsノードサポートによるランタイムプラグイン機能が導入されました。また、OpenAPIが初めて登場し、クライアントが拡張されたAPIを認識できるようになりました。
- このリリースでは、StatefulSetとPodDisruptionBudgetがベータ版で導入されました。
2017年4月 - ロールベースアクセス制御(RBAC)の導入。
2017年6月 - Kubernetes 1.7でThirdPartyResource (TPR)がCustomResourceDefinition (CRD)に置き換えられました。
2017年12月 - Kubernetes 1.9ではWorkload APIがGA(一般提供)となりました。リリースブログには「Kubernetesで最もよく使用されるオブジェクトの一つであるDeploymentとReplicaSetは、1年以上の実際の使用とフィードバックを経て安定しました」と書かれています。
2018年12月 - Kubernetes 1.13でContainer Storage Interface (CSI)がGAに達しました。また最小限のクラスターをブートストラップするためのkubeadmツールがGAに達し、CoreDNSがデフォルトのDNSサーバーとなりました。
2019年9月 - Kubernetes 1.16でCustom Resource DefinitionがGAに達しました。
2020年8月 - Kubernetes 1.19でリリースのサポート期間が1年に延長されました。
2020年12月 - Kubernetes 1.20でDockershimが廃止されました。
2021年4月 - Kubernetesのリリース頻度が変更され、年間4回から3回に減少されました。
2021年7月 - 広く使用されているベータ版APIがKubernetes 1.22で削除されました。
2022年5月 - Kubernetes 1.24でベータ版APIがデフォルトで無効にされ、アップグレードの競合を減らすとともにDockershimが削除されました。その結果、多くのユーザーの混乱を引き起こしました(その後、コミュニケーションを改善しました)。
2022年12月 - Kubernetes 1.26ではAI/ML/バッチワークロードのサポートを強化するための大規模なバッチおよびJob APIのオーバーホールが行われました。

PS: プロジェクトがどれだけ進化したか自分で見てみたいですか？コミュニティメンバーのCarlos Santana、Amim Moises Salum Knabben、James Spurinが作成したKubernetes 1.0クラスターを立ち上げるためのチュートリアルをチェックしてみてください。

Kubernetesには数え切れないほどの拡張するポイントがあります。もともとはDocker専用に設計されていましたが、現在ではCRI標準に準拠する任意のコンテナランタイムをプラグインできます。他にもストレージ用のCSIやネットワーキング用のCNIなどのインターフェースがあります。そしてこれはできることのほんの一部に過ぎません。過去10年間で新しいパターンがいくつも登場しました。例えば、Custom Resource Definition (CRD)を使用してサードパーティのコントローラーをサポートすることができます。これは現在Kubernetesエコシステムの大きな一部となっています。

このプロジェクトを構築するコミュニティも、この10年間で非常に大きくなりました。 DevStatsを使用すると、この10年間でKubernetesを世界で2番目に大きなオープンソースプロジェクトにした驚異的なコントリビューションの量を確認できます。

88,474人のコントリビューター
15,121人のコードコミッター
4,228,347件のコントリビューション
158,530件のIssue
311,787件のPull Request

今日のKubernetes

初期の頃からこのプロジェクトは技術的能力、利用状況、およびコントリビューションの面で驚異的な成長を遂げてきました。プロジェクトは今もなおユーザーにより良いサービスを提供するために積極的に改善に取り組んでいます。

次回の1.31リリースでは、長期にわたる重要なプロジェクトの完成を祝います。それはインツリークラウドプロバイダーのコードの削除です。このKubernetesの歴史上最大のマイグレーションでは、約150万行のコードが削除され、コアコンポーネントのバイナリサイズが約40%削減されました。プロジェクトの初期には、拡張性が成功の鍵であることは明らかでした。しかし、その拡張性をどのように実現するかは常に明確ではありませんでした。このマイグレーションにより、Kubernetesの核となるコードベースからさまざまなベンダー固有の機能が削除されました。ベンダー固有の機能は、今後はCustom Resource Definition (CRD)やGateway APIなどの他のプラグイン拡張機能やパターンによってよりよく提供されるようになります。

Kubernetesは、膨大なユーザーベースにサービスを提供する上で新たな課題にも直面しており、コミュニティはそれに適応しています。その一例が、新しいコミュニティ所有のregistry.k8s.ioへのイメージホスティングの移行です。ユーザーに事前コンパイル済みのバイナリイメージを提供するためのエグレスの帯域幅とコストは非常に大きなものとなっています。この新しいレジストリの変更により、コミュニティはこれらの便利なイメージをよりコスト効率およびパフォーマンス効率の高い方法で提供し続けることができます。必ずブログ記事をチェックし、registry.k8s.ioを使用するように更新してください！

Kubernetesの未来

10年が経ち、Kubernetesの未来は依然として明るく見えます。コミュニティはユーザー体験の改善とプロジェクトの持続可能性を向上させる変更を優先しています。アプリケーション開発の世界は進化し続けており、Kubernetesもそれに合わせて変化していく準備ができています。

2024年にはAIの登場がかつてニッチなワークロードタイプを重要なものへと変えました。分散コンピューティングとワークロードスケジューリングは常に人工知能(AI)、機械学習(ML)、および高性能コンピューティング(HPC)ワークロードのリソース集約的なニーズと密接に関連してきました。コントリビューターは、新しく開発されたワークロードのニーズとそれらにKubernetesがどのように最適に対応できるかに注目しています。新しいServing Working Groupは、コミュニティがこれらのワークロードのニーズに対処するためにどのように組織化されているかの一例です。今後数年でKubernetesがさまざまな種類のハードウェアを管理する能力や、ハードウェア全体でチャンクごとに実行される大規模なバッチスタイルのワークロードのスケジューリング能力に関して改善が見られるでしょう。

Kubernetesを取り巻くエコシステムは成長し続け、進化していきます。将来的にはインツリーベンダーコードのマイグレーションやレジストリの変更など、プロジェクトの持続可能性を維持するための取り組みがますます重要になるでしょう。

Kubernetesの次の10年は、ユーザーとエコシステム、そして何よりもそれに貢献する人々によって導かれるでしょう。コミュニティは新しいコントリビューターを歓迎しています。コントリビューションに関する詳細は、新しいコントリビューター向けのガイドで確認できます。

Kubernetesの未来を一緒に築いていくことを楽しみにしています！

Kubernetes史上最大の移行作業を完了

By Andrew Sy Kim (Google), Michelle Au (Google), Walter Fender (Google), Michael McCune (Red Hat) | 2024.05.20

Kubernetes v1.7以降、Kubernetesプロジェクトは、クラウドプロバイダーとの統合機能をKubernetesのコアコンポーネントから分離するという野心的な目標を追求してきました(KEP-2395)。この統合機能はKubernetesの初期の開発と成長に重要な役割を果たしつつも、２つの重要な要因によってその分離が推進されました。 1つは、何百万行ものGoコードにわたってすべてのクラウドプロバイダーのネイティブサポートを維持することの複雑さが増大していたこと、もう1つは、Kubernetesを真にベンダーニュートラルなプラットフォームとして確立したいという願望です。

多くのリリースを経て、すべてのクラウドプロバイダー統合が、Kubernetesのコアリポジトリから外部プラグインに正常に移行されたことを喜ばしく思います。当初の目的を達成したことに加えて、約150万行のコードを削除し、コアコンポーネントのバイナリサイズを約40%削減することで、Kubernetesを大幅に合理化しました。

この移行は、影響を受けるコンポーネントが多数あり、Google Cloud、AWS、Azure、OpenStack、vSphereの5つの初期クラウドプロバイダーの組み込み統合に依存していた重要なコードパスがあったため、複雑で長期にわたる作業となりました。この移行を成功させるために、私たちは4つの新しいサブシステムを一から構築する必要がありました。

クラウドコントローラーマネージャー (KEP-2392)
APIサーバーネットワークプロキシ (KEP-1281)
kubeletクレデンシャルプロバイダープラグイン (KEP-2133)
CSIを使用するストレージの移行 (KEP-625)

各サブシステムは、組み込み機能と同等の機能を実現するために不可欠であり、安全で信頼できる移行パスを使用して各サブシステムをGAレベルの成熟度にするために、いくつかのリリースが必要でした。以下に、各サブシステムの詳細を説明します。

クラウドコントローラーマネージャー

クラウドコントローラーマネージャーは、この取り組みで導入された最初の外部コンポーネントであり、kube-controller-managerとkubeletのうち、クラウドAPIと直接やり取りする機能を置き換えるものです。この重要なコンポーネントは、ノードが実行されているクラウドのリージョンとゾーンを示すメタデータラベルや、クラウドプロバイダーのみが知っているIPアドレスを適用することにより、ノードを初期化する役割を担っています。さらに、LoadBalancerタイプのServiceに対してクラウドロードバランサーをプロビジョニングするサービスコントローラーも実行します。

Kubernetesのコンポーネント

詳細については、Kubernetesドキュメントのクラウドコントローラーマネージャーを参照してください。

APIサーバーネットワークプロキシ

2018年にSIG API Machineryと共同で開始されたAPIサーバーネットワークプロキシプロジェクトは、kube-apiserver内のSSHトンネラー機能を置き換えることを目的としていました。このトンネラーは、Kubernetesのコントロールプレーンとノードとのトラフィックを安全にプロキシするために使用されていましたが、これらのSSHトンネルを確立するために、kube-apiserver内に組み込まれたプロバイダー固有の実装の詳細に大きく依存していました。

現在、APIサーバーネットワークプロキシは、kube-apiserver内のGAレベルの拡張ポイントとなっています。これは、APIサーバーからノードへのトラフィックを安全なプロキシを介してルーティングできる汎用的なプロキシメカニズムを提供し、APIサーバーが実行されているクラウドプロバイダーを認識する必要がなくなりました。このプロジェクトでは、本番環境での採用が進んでいるKonnectivityプロジェクトも導入されました。

APIサーバーネットワークプロキシの詳細については、READMEを参照してください。

kubeletのクレデンシャルプロバイダープラグイン

kubeletのクレデンシャルプロバイダープラグインは、Google Cloud、AWS、またはAzureでホストされているイメージレジストリのクレデンシャルを動的に取得するkubeletの組み込み機能を置き換えるために開発されました。従来の機能は便利で、kubeletがGCR、ECR、またはACRからイメージを取得するための短期間のトークンをシームレスに取得できるようにしていました。しかし、Kubernetesの他の領域と同様に、これをサポートするには、kubeletが異なるクラウド環境とAPIについて特定の知識を持つ必要がありました。

2019年に導入されたクレデンシャルプロバイダープラグインメカニズムは、kubeletが様々なクラウドでホストされているイメージのクレデンシャルを動的に提供するプラグインバイナリを実行するための汎用的な拡張ポイントを提供します。この拡張性により、kubeletの短期間のトークンを取得する機能が、最初の3つのクラウドプロバイダーを超えて拡張されました。

詳細については、認証されたイメージプルのためのkubeletクレデンシャルプロバイダーを参照してください。

ストレージプラグインのKubernetesコアからCSIへの移行

Container Storage Interface(CSI)は、Kubernetesやそのほかのコンテナオーケストレーターにおいてブロックおよびファイルストレージシステムを管理するためのコントロールプレーン標準であり、1.13でGAになりました。これは、Kubernetesに直接組み込まれていたボリュームプラグインを、Kubernetesクラスター内のPodとして実行できるドライバーに置き換えるために設計されました。これらのドライバーは、Kubernetes APIを介してkube-controller-managerストレージコントローラーと通信し、ローカルのgRPCエンドポイントを介してkubeletと通信します。現在、すべての主要なクラウドとストレージベンダーにわたって100以上のCSIドライバーが利用可能であり、Kubernetesでステートフルなワークロードが現実のものとなっています。

ただし、KubernetesコアのボリュームAPIの既存のすべてのユーザーをどのように扱うかという大きな課題が残っていました。 APIの後方互換性を維持するために、Kubernetesコアのボリューム APIを同等のCSI APIに変換するAPIトランスレーション層をコントローラーに組み込みました。これにより、すべてのストレージ操作をCSIドライバーにリダイレクトすることができ、APIを削除せずにKubernetesコアのボリュームプラグインのコードを削除する道が開けました。

Kubernetesコアのストレージの移行の詳細については、Kubernetes In-Tree to CSI Volume Migration Moves to Betaを参照してください。

今後の展望

この移行は、ここ数年のSIG Cloud Providerがもっとも注力してきたことでした。この重要なマイルストーンを達成したことで、これまでに構築してきた外部サブシステムを活用して、Kubernetesとクラウドプロバイダーをより良く統合するための新しい革新的な方法を模索する取り組みにシフトしていきます。これには、クラスター内のノードがパブリッククラウドとプライベートクラウドの両方で実行できるハイブリッド環境でKubernetesをより賢くすることや、外部プロバイダーの開発者が統合の取り組みを簡素化・合理化するためのより良いツールとフレームワークを提供することが含まれます。

新機能やツール、フレームワークの開発が進む一方で、SIG Cloud Providerはテストの重要性も忘れてはいません。 SIGの将来の活動のもう1つの重点分野は、より多くのプロバイダーを含めるためのクラウドコントローラーテストの改善です。この取り組みの最終目標は、できるだけ多くのプロバイダーを含むテストフレームワークを作成し、Kubernetesコミュニティに対して、Kubernetes環境に関する最高レベルの信頼性を提供することです。

v1.29より前のバージョンのKubernetesを使用していて、まだ外部クラウドプロバイダーに移行していない場合は、以前のブログ記事Kubernetes 1.29: Cloud Provider Integrations Are Now Separate Componentsを確認することをおすすめします。この記事では、私たちが行った変更について詳細な情報を提供し、外部プロバイダーへの移行方法についてガイダンスを提供しています。 v1.31以降、Kubernetesコアのクラウドプロバイダーは永続的に無効化され、Kubernetesのコアコンポーネントから削除されます。

貢献に興味がある方は、隔週のSIGミーティングにぜひご参加ください！

Gateway API v1.1: サービスメッシュ、GRPCRoute、そして更なる進化

By Richard Belleville (Google), Frank Budinsky (IBM), Arko Dasgupta (Tetrate), Flynn (Buoyant), Candace Holman (Red Hat), John Howard (Solo.io), Christine Kim (Isovalent), Mattia Lavacca (Kong), Keith Mattix (Microsoft), Mike Morris (Microsoft), Rob Scott (Google), Grant Spence (Red Hat), Shane Utt (Kong), Gina Yeh (Google), and other review and release note contributors | 2024.05.09

昨年10月のGateway APIの正式リリース後、Kubernetes SIG NetworkはGateway APIのv1.1リリースを発表しました。このリリースでは、いくつかの機能が 標準機能 (GA)に昇格しています。特にサービスメッシュとGRPCRouteのサポートが含まれます。また、セッション維持とクライアント証明書の検証を含む新しい実験的機能も導入しています。

新機能

GAへの昇格

このリリースでは、4つの待望の機能が標準機能に昇格しました。これにより、これらの機能は実験的な段階を卒業したことになります。 GAへの昇格が行われたということは、APIの設計に対する高い信頼性を示すとともに、後方互換性を保証するものです。他のKubernetes APIと同様に、GAへ昇格した機能も時間とともに後方互換性を保ちながら進化していきます。今後もこれらの新機能のさらなる改良と改善が行われることを期待しています。これらの仕組みについて詳しくは、Gateway APIのバージョニングポリシーをご覧ください。

サービスメッシュのサポート

Gateway APIのサービスメッシュサポートにより、サービスメッシュユーザーは同じAPIを使用してIngressトラフィックとメッシュトラフィックを管理することが可能になります。これにより同じポリシーとルーティングインターフェースを再利用することができます。また、Gateway API v1.1では、HTTPRouteなどのルートがServiceをparentRefとして持つことができるようになり、特定のサービスへのトラフィックの動作を制御できます。詳細については、Gateway APIのサービスメッシュドキュメントをお読みいただくか、Gateway APIの実装リストをご覧ください。

例えば、アプリケーションのコールグラフの深部にあるワークロードに対して、HTTPRouteを使用してカナリアデプロイメントを行うことができます。以下はその例です：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

これにより、名前空間faces内のcolorサービスに送信されるトラフィックが、元のcolorサービスとcolor2サービスの間で50対50に分割されます。この設定は移植性が高く、あるメッシュから別のメッシュへ簡単に移行できます。

GRPCRoute

すでにGRPCRouteの実験的機能バージョンを使用している場合、使用しているコントローラーがGRPCRoute v1をサポートするようアップデートされるまで、標準バージョンのGRPCRouteへのアップグレードは控えることをお勧めします。それまでは、v1alpha2とv1の両方のAPIバージョンを含むv1.1の実験的チャンネルバージョンのGRPCRouteにアップグレードしても問題ありません。

ParentReference Port

ParentReferenceにportフィールドが追加されました。これにより、リソースをGatewayのリスナー、Service、あるいは他の親リソース(実装によって異なります)に関連付けることができるようになりました。ポートにバインドすることで、複数のリスナーに一度に関連付けることも可能です。

例えば、HTTPRouteをGatewayの特定のリスナーに関連付ける際、リスナー名ではなくリスナーのポートを指定できるようになりました。これにより、一つまたは複数の特定のリスナーに関連付けることができます。

詳細については、Gatewayへの関連付けを参照してください。

適合性プロファイルとレポート

適合性レポートのAPIが拡張され、実装の動作モードを指定するmodeフィールドと、Gateway APIのチャネル(標準版または実験的機能版)をしめすgatewayAPIChannelが追加されました。 gatewayAPIVersionとgatewayAPIChannelは、テスト結果の簡単な説明とともに、テストスイートの仕組みによって自動的に入力されるようになりました。レポートの構成がより体系的に整理され、実装者はテストの実行方法に関する情報を追加し、再現手順を提供できるようになりました。

実験的機能版チャンネルへの新機能追加

Gatewayのクライアント証明書の検証

Gatewayの各リスナーでクライアント証明書の検証が設定できるようになりました。これは、tls内に新しく追加されたfrontendValidationフィールドによって実現されています。このフィールドでは、クライアントが提示する証明書を検証するための信頼アンカーとして使用できるCA証明書のリストを設定できます。

以下の例は、ConfigMapのfoo-example-com-ca-certに保存されているCA証明書を使用して、Gatewayリスナーのfoo-httpsに接続するクライアントの証明書を検証する方法を示しています。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

セッション維持とBackendLBPolicy

Gateway APIにセッション維持機能が導入されました。これは新しいポリシー(BackendLBPolicy)によってサービスレベルで設定でき、さらにHTTPRouteとGRPCRoute内のフィールドを使用してルートレベルでも設定可能です。 BackendLBPolicyとルートレベルのAPIは、セッションのタイムアウト、セッション名、セッションタイプ、クッキーの有効期間タイプなど、同じセッション維持の設定を提供します。

以下は、fooサービスにクッキーベースのセッション維持を有効にするBackendLBPolicyの設定例です。セッション名をfoo-sessionに設定し、絶対タイムアウトとアイドルタイムアウトを定義し、クッキーをセッションクッキーとして設定しています：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

その他の変更点

TLS関連用語の明確化

API全体でTLS関連の用語を統一する取り組みの一環として、BackendTLSPolicyに互換性のない変更を加えました。これにより、新しいAPIバージョン(v1alpha3)が導入されました。既存のv1alpha2を使用している場合は、データのバックアップや古いバージョンのアンインストールなど、適切な対応が必要です。

v1alpha2のBackendTLSPolicyフィールドへの参照は、v1alpha3に更新する必要があります。主な変更点は以下の通りです：

targetRefがtargetRefsに変更(複数のターゲットへの適用が可能に)
tlsがvalidationに変更
tls.caCertRefsがvalidation.caCertificateRefsに変更
tls.wellKnownCACertsがvalidation.wellKnownCACertificatesに変更

このリリースに含まれるすべての変更点については、v1.1.0リリースノートをご覧ください。

Gateway APIの背景

Gateway APIのアイデアは、2019年のKubeCon San Diegoで次世代のIngress APIとして最初に提案されました。それ以来、すばらしいコミュニティが形成され、おそらくKubernetes史上最も協力的なAPIを開発してきました。これまでに200人以上がこのAPIに貢献しており、その数は今も増え続けています。

メンテナーは、リポジトリへのコミット、議論、アイデア、あるいは一般的なサポートなど、あらゆる形でGateway APIに貢献してくださった 全ての方々 に感謝の意を表します。このように献身的で活発なコミュニティのサポートなしでは、ここまで到達することはできませんでした。

実際に使ってみましょう

Gateway APIの特徴として、最新版を使用するためにKubernetesそのものを最新にする必要がありません。 Kubernetes 1.26以降であれば、このバージョンのGateway APIをすぐに利用開始できます。

APIを試すには、スタートガイドをご覧ください。

開発に参加しませんか

Ingressやサービスメッシュ向けのKubernetesルーティングAPIの未来を形作るチャンスがたくさんあります。

ユーザーガイドで、対応可能なユースケースをチェックしてみてください。
既存のGatewayコントローラーを実際に試してみるのもおすすめです。
さらに、コミュニティへの参加もお待ちしています。一緒にGateway APIの未来を築いていきましょう！

DIY: Kubernetesで自分だけのクラウドを構築しよう(パート3)

By Andrei Kvapil (Ænix) | 2024.04.05

Kubernetesの中でKubernetesを実行するという最も興味深いフェーズに近づいています。この記事では、KamajiやCluster APIなどのテクノロジーとそれらのKubeVirtとの統合について説明します。

以前の議論では、ベアメタル上でのKubernetesの準備と、Kubernetesを仮想マシン管理システムに変える方法について説明しました。この記事では、上記のすべてを使用して、本格的な管理対象のKubernetesを構築し、ワンクリックで仮想Kubernetesクラスターを実行する方法を説明して、シリーズを締めくくります。

まず、Cluster APIについて詳しく見ていきましょう。

Cluster API

Cluster APIは、Kubernetesの拡張機能で、別のKubernetesクラスター内でカスタムリソースとしてKubernetesクラスターを管理できるようにするものです。

Cluster APIの主な目的は、Kubernetesクラスターの基本的なエンティティを記述し、そのライフサイクルを管理するための統一されたインターフェースを提供することです。これにより、クラスターの作成、更新、削除のプロセスを自動化し、スケーリングとインフラストラクチャの管理を簡素化できます。

Cluster APIのコンテキストでは、管理クラスターとテナントクラスターの2つの用語があります。

管理クラスターは、他のクラスターのデプロイと管理に使用されるKubernetesクラスターです。このクラスターには、必要なすべてのCluster APIコンポーネントが含まれており、テナントクラスターの記述、作成、更新を担当します。多くの場合、この目的でのみ使用されます。
テナントクラスターは、ユーザークラスターまたはCluster APIを使用してデプロイされたクラスターです。これらは、管理クラスターで関連するリソースを記述することで作成されます。その後、エンドユーザーがアプリケーションとサービスをデプロイするために使用されます。

テナントクラスターは、物理的に管理クラスターと同じインフラストラクチャ上で実行する必要は必ずしもないことを理解することが重要です。むしろ多くの場合、それらは別の場所で実行されています。

Cluster APIを使用した管理KubernetesクラスターとテナントKubernetesクラスターの相互作用を示す図

Cluster APIは、その動作のために プロバイダー の概念を利用します。プロバイダーは、作成されるクラスターの特定のコンポーネントを担当する個別のコントローラーです。 Cluster API内にはいくつかの種類のプロバイダーがあります。主なものは次のとおりです。

インフラストラクチャプロバイダー: 仮想マシンや物理サーバーなどのコンピューティングインフラストラクチャを提供する役割を担います。
コントロールプレーンプロバイダー: kube-apiserver、kube-scheduler、kube-controller-managerなどのKubernetesコントロールプレーンを提供します。
ブートストラッププロバイダー: 作成される仮想マシンやサーバー用のcloud-init設定の生成に使用されます。

始めるには、Cluster API自体と各種プロバイダーを1つずつインストールする必要があります。サポートされているプロバイダーの完全なリストはプロジェクトのドキュメントで確認できます。

インストールにはclusterctlユーティリティや、より宣言的な方法としてCluster API Operatorを使用できます。

プロバイダーの選択

インフラストラクチャプロバイダー

KubeVirtを使用してKubernetesクラスターを実行するにはKubeVirt Infrastructure Providerをインストールする必要があります。これにより、Cluster APIが動作する管理クラスターと同じ場所で、ワーカーノード用の仮想マシンをデプロイできるようになります。

コントロールプレーンプロバイダー

Kamajiプロジェクトは、管理クラスター内のコンテナとしてテナントクラスターのKubernetesコントロールプレーンを実行するためのソリューションを提供しています。このアプローチには、いくつかの重要な利点があります。

費用対効果: コントロールプレーンをコンテナで実行することで、クラスターごとに個別のコントロールプレーンノードを使用する必要がなくなり、インフラストラクチャのコストを大幅に削減できます。
安定性: 複雑な多層デプロイメント方式を排除することでアーキテクチャを簡素化できます。仮想マシンを順次起動してからその中にetcdとKubernetesコンポーネントをインストールするのではなく、Kubernetes内で通常のアプリケーションとしてデプロイおよび実行され、オペレーターによって管理されるシンプルなコントロールプレーンがあります。
セキュリティ: クラスターのコントロールプレーンはエンドユーザーから隠されており、そのコンポーネントが侵害される可能性を減らし、クラスターの証明書ストアへのユーザーアクセスを排除します。ユーザーに見えないコントロールプレーンを構成するこのアプローチは、クラウドプロバイダーによって頻繁に使用されています。

ブートストラッププロバイダー

Kubeadmをブートストラッププロバイダーとして使用します。これは、Cluster APIでクラスターを準備するための標準的な方法です。このプロバイダーは、Cluster API自体の一部として開発されています。kubeletとkubeadmがインストールされた準備済みのシステムイメージのみが必要で、cloud-initとignitionの形式でコンフィグを生成できます。

Talos LinuxもCluster API経由でのプロビジョニングをサポートしており、そのためのプロバイダーが用意されていることは注目に値します。前回の記事では、ベアメタルノードで管理クラスターをセットアップするためにTalos Linuxを使用する方法について説明しましたが、テナントクラスターをプロビジョニングするには、Kamaji+Kubeadmのアプローチの方が優れています。コンテナへのKubernetesコントロールプレーンのデプロイを容易にするため、コントロールプレーンインスタンス用に個別の仮想マシンを用意する必要無くなります。これにより、管理が簡素化され、コストが削減されます。

動作の仕組み

Cluster APIの主要なオブジェクトはClusterリソースで、他のすべてのリソースの親となります。通常、このリソースは他の2つのリソースを参照します。 コントロールプレーンを記述するリソースとインフラストラクチャを記述するリソースです。それぞれが個別のプロバイダーによって管理されます。

Clusterとは異なり、これら2つのリソースは標準化されておらず、そのリソースの種類は使用している特定のプロバイダーに依存します。

Cluster APIにおけるClusterリソースとそれがリンクするリソースの関係を示す図

Cluster APIには、MachineDeploymentという名前のリソースもあります。これは物理サーバーか仮想マシンかにかかわらずノードのグループを記述するものです。このリソースは、Deployment、ReplicaSet、Podなどの標準のKubernetesリソースと同様に機能し、ノードのグループを宣言的に記述し、自動的にスケーリングするためのメカニズムを提供します。

つまり、MachineDeploymentリソースを使用すると、クラスターのノードを宣言的に記述でき、指定されたパラメーターと要求されたレプリカ数に応じて、ノードの作成、削除、更新を自動化できます。

Cluster APIにおけるClusterリソースとその子リソースの関係を示す図 — Cluster APIにおけるMachineDeploymentリソースとその子リソースの関係を示す図

マシンを作成するために、MachineDeploymentは、マシン自体を生成するためのテンプレートと、そのcloud-init設定を生成するためのテンプレートを参照します。

Cluster APIを使用して新しいKubernetesクラスターをデプロイするには、以下のリソースのセットを準備する必要があります。

一般的なClusterリソース
Kamajiが運用するコントロールプレーンを担当するKamajiControlPlaneリソース
KubeVirt内のクラスター設定を記述するKubevirtClusterリソース
仮想マシンテンプレートを担当するKubevirtMachineTemplateリソース
トークンとcloud-initの生成を担当するKubeadmConfigTemplateリソース
いくつかのワーカーを作成するための少なくとも1つのMachineDeployment

クラスターの仕上げ

ほとんどの場合これで十分ですが、使用するプロバイダーによっては、他のリソースも必要になる場合があります。プロバイダーの種類ごとに作成されるリソースの例は、Kamajiプロジェクトのドキュメントで確認できます。

この段階ですでに使用可能なテナントKubernetesクラスターができていますが、これまでのところ、APIワーカーとあらゆるKubernetesクラスターのインストールに標準で含まれるいくつかのコアプラグイン(kube-proxyとCoreDNS)しか含まれていません。完全に統合するには、さらにいくつかのコンポーネントをインストールする必要があります。

追加のコンポーネントをインストールするには、個別のCluster API Add-on Provider for Helmや、前の記事で説明したFluxCDを使用できます。

FluxCDでリソースを作成する際、Cluster APIによって生成されたkubeconfigを参照することでターゲットクラスターを指定できます。そうするとインストールは直接そのクラスターに対して実行されます。このように、FluxCDは管理クラスターとユーザーテナントクラスターの両方でリソースを管理するための汎用ツールになります。

管理クラスターとテナントKubernetesクラスターの両方にコンポーネントをインストールできるfluxcdの相互作用スキームを示す図

ここで議論されているコンポーネントとは何でしょうか？一般的に、そのセットには以下が含まれます。

CNIプラグイン

テナントKubernetesクラスター内のPod間の通信を確保するには、CNIプラグインをデプロイする必要があります。このプラグインは、Pod同士が相互に通信できるようにする仮想ネットワークを作成し、従来はクラスターのワーカーノード上にDaemonsetとしてデプロイされます。適切だと思うCNIプラグインを選んでインストールできます。

クラウドコントローラーマネージャー

この一部レスポンスについては、以下のようにMarkdown記法を修正するのが良いと思います。

クラウドコントローラーマネージャー(CCM)の主な役割は、Kubernetes をクラウドインフラストラクチャプロバイダーの環境(この場合は、テナントKubernetesのすべてのワーカーがプロビジョニングされている管理Kubernetesクラスター)と統合することです。 CCMが実行するタスクは次のとおりです。

LoadBalancer タイプのサービスが作成されると、CCM はクラウドロードバランサーの作成プロセスを開始します。これにより、トラフィックが Kubernetes クラスターに誘導されます。
クラウドインフラストラクチャからノードが削除された場合、CCM はクラスターからもそのノードを確実に削除し、クラスターの現在の状態を維持します。
CCM を使用する場合、ノードは特別な taint (node.cloudprovider.kubernetes.io/uninitialized) を付けてクラスターに追加されます。これにより、必要に応じて追加のビジネスロジックを処理できます。初期化が正常に完了すると、この taint がノードから削除されます。

クラウドプロバイダーによっては、CCM がテナントクラスターの内部と外部の両方で動作する場合があります。

KubeVirt Cloud Providerは、外部の親管理クラスターにインストールするように設計されています。したがって、テナントクラスターでLoadBalancerタイプのサービスを作成すると親クラスターでLoadBalancerサービスの作成が開始され、トラフィックがテナントクラスターに誘導されます。

ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCloud Controller Managerと、それが管理する親から子へのKubernetesクラスター間のサービスのマッピングを示す図

CSIドライバー

Container Storage Interface(CSI)は、Kubernetesでストレージを操作するために、2つの主要な部分に分かれています。

csi-controller: このコンポーネントは、クラウドプロバイダーのAPIと対話して、ボリュームの作成、削除、アタッチ、デタッチ、およびサイズ変更を行う責任があります。
csi-node: このコンポーネントは各ノードで実行され、kubeletから要求されたPodへのボリュームのマウントを容易にします。

KubeVirt CSI Driverを使用するコンテキストでは、ユニークな機会が生まれます。 KubeVirtの仮想マシンは管理KubernetesクラスターでKubernetesのフル機能のAPIが利用できる環境で実行されるため、ユーザーのテナントクラスターの外部でcsi-controllerを実行する道が開かれます。このアプローチはKubeVirtコミュニティで人気があり、いくつかの重要な利点があります。

セキュリティ: この方法では、エンドユーザーからクラウドの内部APIを隠し、Kubernetesインターフェースを介してのみリソースへのアクセスを提供します。これにより、ユーザークラスターから管理クラスターへの直接アクセスのリスクが軽減されます。
シンプルさと利便性: ユーザーは自分のクラスターで追加のコントローラーを管理する必要がないため、アーキテクチャが簡素化され、管理の負担が軽減されます。

ただし、csi-nodeは、各ノードのkubeletと直接やり取りするため、必然的にテナントクラスター内で実行する必要があります。このコンポーネントは、Podへのボリュームのマウントとマウント解除を担当し、クラスターノードで直接発生するプロセスとの緊密な統合が必要です。

KubeVirt CSIドライバーは、ボリュームの要求のためのプロキシとして機能します。テナントクラスター内でPVCが作成されると、管理クラスターにPVCが作成され、作成されたPVが仮想マシンに接続されます。

ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの内部と外部の両方にインストールされたCSIプラグインのコンポーネントと、それが管理する親から子へのKubernetesクラスター間の永続ボリュームのマッピングを示す図

クラスターオートスケーラー

クラスターオートスケーラーは、さまざまなクラウドAPIと連携できる汎用的なコンポーネントであり、Cluster APIとの統合は利用可能な機能の1つに過ぎません。適切に設定するには、2つのクラスターへのアクセスが必要です。テナントクラスターではPodを追跡し、新しいノードを追加する必要性を判断し、管理するKubernetesクラスター(管理Kubernetesクラスター)ではMachineDeploymentリソースと対話し、レプリカ数を調整します。

Cluster Autoscalerは通常テナントKubernetesクラスター内で実行されますが、今回のケースでは、前述と同じ理由からクラスター外にインストールすることをお勧めします。このアプローチは、テナントクラスターのユーザーが管理クラスターの管理APIにアクセスできないようにするため、メンテナンスがより簡単で、より安全です。

ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCloud Controller Managerを示す図 — ネストされたKubernetesクラスターのスキームにおいて、テナントKubernetesクラスターの外部にインストールされたCluster Autoscalerを示す図

Konnectivity

もう1つ追加のコンポーネントについて言及したいと思います。 Konnectivityです。後でテナントKubernetesクラスターでwebhookとAPIアグリゲーションレイヤーを動作させるために、おそらくこれが必要になるでしょう。このトピックについては、私の以前の記事で詳しく説明しています。

上記のコンポーネントとは異なり、Kamajiでは、Konnectivityを簡単に有効にし、kube-proxyやCoreDNSと並んで、テナントクラスターのコアコンポーネントの1つとして管理できます。

まとめ

これで、動的スケーリング、ボリュームの自動プロビジョニング、ロードバランサーの機能を備えた、完全に機能するKubernetesクラスターができました。

今後は、テナントクラスターからのメトリクスやログの収集を検討するとよいでしょうが、それはこの記事の範囲を超えています。

もちろん、Kubernetesクラスターをデプロイするために必要なコンポーネントはすべて、1つのHelmチャートにパッケージ化し、統一されたアプリケーションとしてデプロイできます。これは、オープンなPaaSプラットフォームであるCozystackで、ボタンをクリックするだけで管理対象のKubernetesクラスターのデプロイを整理する方法そのものです。 Cozystackでは、記事で説明したすべてのテクノロジーを無料で試すことができます。

DIY: Kubernetesで自分だけのクラウドを構築しよう(パート2)

By Andrei Kvapil (Ænix) | 2024.04.05

Kubernetesエコシステムだけを使って自分だけのクラウドを構築する方法について、一連の記事を続けています。前回の記事では、Talos LinuxとFlux CDをベースにした基本的なKubernetes ディストリビューションの準備方法を説明しました。この記事では、Kubernetesにおけるさまざまな仮想化テクノロジーをいくつか紹介し、主にストレージとネットワークを中心に、Kubernetes内で仮想マシンを実行するために必要な環境を整えます。

KubeVirt、LINSTOR、Kube-OVNなどのテクノロジーについて取り上げる予定です。

しかし最初に、仮想マシンが必要な理由と、クラウドの構築にDockerコンテナを使用するだけでは不十分である理由を説明しましょう。その理由は、コンテナが十分なレベルの分離を提供していないことにあります。状況は年々改善されていますが、コンテナのサンドボックスから脱出してシステムの特権を昇格させる脆弱性が見つかることがよくあります。

一方、Kubernetesはもともとマルチテナントシステムとして設計されていなかったため、基本的な使用パターンでは、独立したプロジェクトや開発チームごとに別々のKubernetesクラスターを作成することが一般的です。

仮想マシンは、クラウド環境でテナント同士を分離するための主要な手段です。仮想マシン内では、ユーザーは管理者権限でコードやプログラムを実行できますが、これは他のテナントや環境自体に影響を与えません。つまり、仮想マシンはハードマルチテナンシー分離を実現し、テナント間で信頼関係がない環境でも安全に実行できます。

Kubernetes における仮想化テクノロジー

Kubernetesの世界に仮想化をもたらすテクノロジーはいくつかありますが、KubeVirtとKata Containersが最も一般的です。ただし、これらの動作方式は異なることを理解しておく必要があります。

Kata Containersは、CRI(Container Runtime Interface)を実装しており、標準のコンテナを仮想マシン内で実行することで、追加の分離レベルを提供します。ただし、これらは同一のKubernetesクラスター内で動作します。

コンテナを仮想マシン内で実行することにより、Kata Containersがコンテナの分離を確保する方法を示す図

KubeVirtは、Kubernetes APIを使用して従来の仮想マシンを実行できます。 KubeVirtの仮想マシンは、コンテナ内の通常のLinuxプロセスとして実行されます。つまり、KubeVirtでは、コンテナが仮想マシン(QEMU)プロセスを実行するためのサンドボックスとして使用されます。これは、以下の図で、KubeVirtにおける仮想マシンのライブマイグレーションの実装方法を見ると明らかです。マイグレーションが必要な場合、仮想マシンはあるコンテナから別のコンテナに移動します。

KubeVirtにおいて、仮想マシンがあるコンテナから別のコンテナへライブマイグレーションする様子を示す図

Cloud-Hypervisorを使用した軽量な仮想化を実装し、初期からCluster APIを使用した仮想Kubernetesクラスターの実行に重点を置いている代替プロジェクトVirtinkもあります。

私たちの目標を考慮して、この分野で最も一般的なプロジェクトであるKubeVirtを使用することに決めました。さらに、私たちはKubeVirtに関する豊富な専門知識を持ち、すでに多くの貢献をしています。

KubeVirtはインストールが簡単で、containerDisk機能を使用してすぐに仮想マシンを実行できます。この機能により、VMイメージをコンテナイメージレジストリから直接OCIイメージとして保存および配布できます。 containerDiskを使用した仮想マシンは、Kubernetesワーカーノードやその他の状態の永続化を必要としない仮想マシンの作成に適しています。

永続データを管理するために、KubeVirtは別のツールであるContainerized Data Importer(CDI)を提供しています。 CDIを使用すると、PVCのクローンを作成し、ベースイメージからデータを取り込むことができます。 CDIは、仮想マシンの永続ボリュームを自動的にプロビジョニングする場合や、テナントKubernetesクラスターからの永続ボリューム要求を処理するために使用されるKubeVirt CSIドライバーにも必要となります。

しかし最初に、これらのデータをどこにどのように保存するかを決める必要があります。

Kubernetes上の仮想マシン用ストレージ

CSI(Container Storage Interface)の導入により、Kubernetesと統合できる幅広いテクノロジーが利用可能になりました。実際、KubeVirtはCSIインターフェースを完全に活用しており、仮想化のためのストレージの選択肢はKubernetes自体のストレージの選択肢と密接に連携しています。しかし、考慮すべき細かな差異があります。通常、標準のファイルシステムを使用するコンテナとは異なり、仮想マシンにはブロックデバイスの方が効率的です。

KubernetesのCSIインターフェースでは、ファイルシステムとブロックデバイスの両方のタイプのボリュームを要求できますが、使用しているストレージバックエンドがこれをサポートしていることを確認することが重要です。

仮想マシンにブロックデバイスを使用すると、ファイルシステムなどの追加の抽象化レイヤーが不要になるため、パフォーマンスが向上し、ほとんどの場合で ReadWriteMany モードの使用が可能になります。このモードでは、複数のノードから同時にボリュームにアクセスできるため、KubeVirtにおける仮想マシンのライブマイグレーションを有効にするための重要な機能です。

ストレージシステムは、外部または内部(ハイパーコンバージドインフラストラクチャの場合)にすることができます。多くの場合、外部ストレージを使用するとデータが計算ノードから分離して保存されるため、システム全体の安定性が向上します。

外部ストレージソリューションは、エンタープライズシステムでよく使用されています。このようなストレージは、多くの場合運用を担当する外部ベンダーによって提供されるためです。 Kubernetesとの統合には、クラスターにインストールされる小さなコンポーネントであるCSIドライバーのみが関与します。このドライバーは、このストレージにボリュームをプロビジョニングし、Kubernetesによって実行されるPodにそれらをアタッチする役割を担います。ただし、このようなストレージソリューションは、純粋にオープンソースのテクノロジーを使用して実装することもできます。人気のあるソリューションの1つは、democratic-csiドライバーを使用したTrueNASです。

一方、ハイパーコンバージドシステムは、多くの場合、ローカルストレージ(レプリケーションが不要な場合)と、Rook/Ceph、OpenEBS、Longhorn、LINSTORなどのソフトウェアデファインドストレージを使用して実装されます。これらは、多くの場合、Kubernetesに直接インストールされます。

ハイパーコンバージドシステムには利点があります。たとえば、データの局所性です。データがローカルに保存されている場合、そのデータへのアクセスは高速になります。しかし、このようなシステムは通常、管理と保守がより難しいという欠点があります。

Ænixでは、追加の外部ストレージを購入してセットアップする必要なく使用でき、速度とリソースの利用の点で最適な、すぐに使える解決策を提供したいと考えていました。 LINSTORがその解決策となりました。バックエンドとして業界で人気のある実績あるテクノロジーであるLVMやZFSを使用していることで、データが安全に保存されていることに自信が持てます。 DRDBベースのレプリケーションは信じられないほど高速で、少ない計算リソースしか消費しません。

Kubernetes上でLINSTORをインストールするには、PiraeusプロジェクトがKubeVirtで使用できる既製のブロックストレージをすでに提供しています。

備考:

前回の記事で説明したように、Talos Linuxを使用している場合は、必要なカーネルモジュールを事前に有効にし、手順に従ってPiraeusを設定する必要があります。

Kubernetes上の仮想マシン用ネットワーク

Kubernetesのネットワークアーキテクチャは同じようなインターフェースであるCNIを持っているにもかかわらず、実際にはより複雑で、通常、互いに直接接続されていない多くの独立したコンポーネントで構成されています。実際、Kubernetesのネットワークは以下に説明する4つのレイヤーに分割できます。

ノードネットワーク (データセンターネットワーク)

ノードが相互に接続されるネットワークです。このネットワークは通常、Kubernetesによって管理されませんが、これがないと何も機能しないため、重要なネットワークです。実際には、ベアメタルインフラストラクチャには通常、複数のこのようなネットワークがあります。例えば、ノード間通信用の1つ、ストレージレプリケーション用の2つ目、外部アクセス用の3つ目などです。

ノード間の物理ネットワークの相互作用の設定は、ほとんどの状況でKubernetesが既存のネットワークインフラストラクチャを利用するため、この記事の範囲を超えています。

Podネットワーク

これは、CNIプラグインによって提供されるネットワークです。 CNIプラグインの役割は、クラスター内のすべてのコンテナとノード間の透過的な接続を確保することです。ほとんどのCNIプラグインは、各ノードで使用するためにIPアドレスの個別のブロックが割り当てられるフラットネットワークを実装しています。

実際には、クラスターにはMultusによって管理される複数のCNIプラグインを持つことができます。このアプローチは、RancherやOpenShiftなどのKubeVirtベースの仮想化ソリューションでよく使用されます。プライマリCNIプラグインはKubernetesサービスとの統合に使用され、追加のCNIプラグインはプライベートネットワーク(VPC)の実装やデータセンターの物理ネットワークとの統合に使用されます。

デフォルトのCNIプラグインは、ブリッジまたは物理インターフェースの接続に使用できます。さらに、パフォーマンスを向上させるために設計されたmacvtap-cniなどの専用プラグインもあります。

Kubernetes内で仮想マシンを実行する際に注意すべきもう1つの側面は、特にMultusによって提供されるセカンダリインターフェースに対するIPAM(IPアドレス管理)の必要性です。これは通常、インフラストラクチャ内で動作するDHCPサーバーによって管理されます。さらに、仮想マシンのMACアドレスの割り当ては、Kubemacpoolによって管理できます。

私たちのプラットフォームでは、別の方法を選択し、Kube-OVNに完全に頼ることにしました。このCNIプラグインは、もともとOpenStack用に開発されたOVN(Open Virtual Network)をベースにしています。 Kube-OVNはKubernetes内の仮想マシン用の完全なネットワークソリューションを提供します。 IPとMACアドレスを管理するためのカスタムリソースを備え、ノード間でIPアドレスを保持したままライブマイグレーションをサポートし、テナント間の物理ネットワーク分離用のVPCの作成を可能にします。

Kube-OVNでは、名前空間全体に個別のサブネットを割り当てたり、Multusを使用して追加のネットワークインターフェースとして接続したりできます。

サービスネットワーク

CNIプラグインに加えて、Kubernetesにはサービスネットワークもあります。これは主にサービスディスカバリーに必要です。従来の仮想マシンとは異なり、KubernetesはもともとランダムなアドレスでPodを実行するように設計されています。そして、サービスネットワークは、トラフィックを常に正しいPodに誘導する便利な抽象化(安定したIPアドレスとDNS名)を提供します。仮想マシンのIPは通常静的であるにもかかわらず、このアプローチはクラウド内の仮想マシンでも一般的に使用されています。

Kubernetesでのサービスネットワークの実装は、サービスネットワークプラグインによって処理されます。標準の実装はkube-proxyと呼ばれ、ほとんどのクラスターで使用されています。しかし最近では、この機能はCNIプラグインの一部として提供されることがあります。最も先進的な実装は、Ciliumプロジェクトによって提供されており、kube-proxyの代替モードで実行できます。

CiliumはeBPFテクノロジーに基づいており、Linuxネットワークスタックを効率的にオフロードできるため、iptablesベースの従来の方法と比較してパフォーマンスとセキュリティが向上します。

実際には、CiliumとKube-OVNを簡単に統合することが可能です。これにより、仮想マシン向けにシームレスでマルチテナントのネットワーキングを提供する統合ソリューションを実現することができます。また、高度なネットワークポリシーと統合されたサービスネットワーク機能も提供されます。

外部トラフィックのロードバランサー

この段階で、Kubernetes内で仮想マシンを実行するために必要なものはすべて揃っています。しかし、実際にはもう1つ必要なものがあります。クラスターの外部からサービスにアクセスする必要がまだあり、外部ロードバランサーがこれを整理するのに役立ちます。

ベアメタルのKubernetesクラスターには、いくつかの利用可能なロードバランサーがあります。 MetalLB、kube-vip、LoxiLBがあり、またCiliumとKube-OVNにはビルトインの実装が提供されています。

外部ロードバランサーの役割は、外部から利用可能な安定したアドレスを提供し、外部トラフィックをサービスネットワークに誘導することです。サービスネットワークプラグインは、通常どおりそれをPodと仮想マシンに誘導します。

Kubernetesのネットワーク構成における外部ロードバランサーの役割を示す図

ほとんどの場合、ベアメタル上でのロードバランサーの設定は、クラスター内のノードにフローティングIPアドレスを作成し、ARP/NDPまたはBGPプロトコルを使用してそれを外部にアナウンスすることによって実現されます。

さまざまなオプションを検討した結果、MetalLBが最もシンプルで信頼性の高いソリューションであると判断しましたが、MetalLBの使用のみを厳密に強制しているわけではありません。

もう1つの利点は、L2モードでは、MetalLBスピーカーがメンバーリストプロトコルを使用してライブネスチェックを実行することにより、ネイバーの状態を継続的にチェックすることです。これにより、Kubernetesコントロールプレーンとは独立して機能するフェイルオーバーが可能になります。

まとめ

ここまでが、Kubernetesにおける仮想化、ストレージ、ネットワークの概要になります。ここで取り上げたテクノロジーは、Cozystackプラットフォームで利用可能であり、制限なくお試しいただけるよう事前に設定されています。

次の記事では、この上にボタンをクリックするだけで、完全に機能するKubernetesクラスターのプロビジョニングをどのように実装できるかを詳しく説明します。

DIY: Kubernetesで自分だけのクラウドを構築しよう(パート1)

By Andrei Kvapil (Ænix) | 2024.04.05

Ænixでは、Kubernetesに対する深い愛着があり、近いうちにすべての最新テクノロジーがKubernetesの驚くべきパターンを活用し始めることを夢見ています。自分だけのクラウドを構築することを考えたことはありませんか？きっと考えたことがあるでしょう。しかし、快適なKubernetesエコシステムを離れることなく、最新のテクノロジーとアプローチのみを使ってそれを実現することは可能でしょうか？ Cozystackの開発における私たちの経験は、その点を深く掘り下げる必要がありました。自分だけのクラウドを構築することを考えたことはありませんか？

Kubernetesはこの目的のために設計されたものではなく、ベアメタルサーバー用にOpenStackを使用し、意図したとおりにその内部でKubernetesを実行すればよいのではないかと主張する人もいるかもしれません。しかし、そうすることで、単に責任があなたの手からOpenStack管理者の手に移っただけです。これにより、少なくとも1つの巨大で複雑なシステムがエコシステムに追加されることになります。

なぜ物事を複雑にするのでしょうか？結局のところ、Kubernetesにはテナント用のKubernetesクラスターを実行するために必要なものがすべて揃っています。

Kubernetesをベースにしたクラウドプラットフォームの開発における私たちの経験を共有したいと思います。私たち自身が使用しており、あなたの注目に値すると信じているオープンソースプロジェクトを紹介します。

この一連の記事では、オープンソースのテクノロジーのみを使用して、ベアメタルから管理されたKubernetesを準備する方法についての私たちの物語をお伝えします。データセンターの準備、仮想マシンの実行、ネットワークの分離、フォールトトレラントなストレージのセットアップといった基本的なレベルから、動的なボリュームのプロビジョニング、ロードバランサー、オートスケーリングを備えた本格的なKubernetesクラスターのプロビジョニングまでを扱います。

この記事から、いくつかのパートで構成されるシリーズを開始します:

パート1: 自分のクラウドの基礎を準備する。ベアメタル上でのKubernetesの準備と運用における課題、およびインフラストラクチャをプロビジョニングするための既成のレシピ。
パート2: ネットワーク、ストレージ、仮想化。Kubernetesを仮想マシン起動のためのツールにする方法とそのために必要なもの。
パート3: Cluster APIと、ボタンを押すだけでKubernetesクラスターのプロビジョニングを開始する方法。オートスケーリング、ボリュームの動的プロビジョニング、ロードバランサーの仕組み。

さまざまなテクノロジーをできるだけ独立して説明しようと思いますが、同時に、私たちの経験と、なぜある解決策に至ったのかを共有します。

まず、Kubernetesの主な利点と、それがクラウドリソースの使用へのアプローチをどのように変えたかを理解しましょう。

クラウドとベアメタルでは、Kubernetesの使い方が異なることを理解することが重要です。

クラウド上のKubernetes

クラウド上でKubernetesを運用する場合、永続ボリューム、クラウドロードバランサー、ノードのプロビジョニングプロセスを気にする必要はありません。これらはすべて、Kubernetesオブジェクトの形式であなたのリクエストを受け入れるクラウドプロバイダーによって処理されます。つまり、サーバー側は完全にあなたから隠されており、クラウドプロバイダーがどのように正確に実装しているかを知る必要はありません。それはあなたの責任範囲ではないからです。

Kubernetesは、どこでも同じように機能する便利な抽象化を提供しているため、あらゆるクラウドのKubernetes上にアプリケーションをデプロイできます。

クラウドでは、Kubernetesコントロールプレーン、仮想マシン、永続ボリューム、ロードバランサーなど、いくつかの個別のエンティティを持つことが非常に一般的です。これらのエンティティを使用することで、高度に動的な環境を作成できます。

Kubernetesのおかげで、仮想マシンは今やクラウドリソースを利用するための単なるユーティリティエンティティとしてのみ見られるようになりました。もはや仮想マシンの中にデータを保存することはありません。仮想マシンをすべて削除して、アプリケーションを壊すことなく再作成できます。 Kubernetesコントロールプレーンは、クラスター内で何が実行されるべきかについての情報を保持し続けます。ロードバランサーは、新しいノードにトラフィックを送信するためにエンドポイントを変更するだけで、ワークロードにトラフィックを送信し続けます。そして、データはクラウドが提供する外部の永続ボリュームに安全に保存されます。

このアプローチは、クラウドでKubernetesを使用する際の基本です。その理由はかなり明白です。システムが単純であるほど安定性が高くなり、このシンプルさのためにクラウドでKubernetesを選択するのです。

ベアメタル上のKubernetes

クラウドでKubernetesを使用することは本当に簡単で便利ですが、ベアメタルへのインストールについては同じことが言えません。ベアメタルの世界では、Kubernetesは逆に非常に複雑になります。まず、ネットワーク全体、バックエンドストレージ、クラウドバランサーなどは、通常、クラスターの外部ではなく内部で実行されるためです。その結果、このようなシステムは更新と保守がはるかに難しくなります。

ご自身で判断してみてください。クラウドでは、通常、ノードを更新するために仮想マシンを削除する(またはkubectl delete nodeを使用する)だけで、イミュータブルなイメージに基づいて新しいノードを作成することをノード管理ツールに任せることができます。新しいノードはクラスターに参加し、Kubernetesの世界で非常にシンプルでよく使われるパターンに従って、ノードとして「そのまま動作」します。多くのクラスターでは、安価なスポットインスタンスを利用できるため、数分ごとに新しい仮想マシンをオーダーしています。しかし、物理サーバーを使用している場合は、簡単に削除して再作成することはできません。まず、物理サーバーはクラスターサービスを実行していたり、データを保存していたりすることが多いため、その更新プロセスははるかに複雑になるからです。

この問題を解決するアプローチはさまざまです。 kubeadm、kubespray、k3sが行うようなインプレースアップデートから、Cluster APIとMetal3を通じた物理ノードのプロビジョニングの完全な自動化まで幅広くあります。

私は、Talos Linuxが提供するハイブリッドアプローチが気に入っています。このアプローチでは、システム全体が単一の設定ファイルで記述されます。このファイルのほとんどのパラメーターは、Kubernetesコントロールプレーンコンポーネントのバージョンを含め、ノードを再起動または再作成することなく適用できます。それでも、Kubernetesの宣言的な性質を最大限に保持しています。このアプローチは、ベアメタルノードを更新する際のクラスターサービスへの不要な影響を最小限に抑えます。ほとんどの場合、マイナーアップデートの際に仮想マシンを移行したり、クラスターファイルシステムを再構築したりする必要はありません。

将来のクラウドの基盤を準備する

さて、自分だけのクラウドを構築することに決めたとしましょう。まずは基盤となるレイヤーが必要です。サーバーにKubernetesをインストールする方法だけでなく、それをどのように更新し、維持していくかについても考える必要があります。カーネルの更新、必要なモジュールのインストール、パッケージやセキュリティパッチなどについても考えなければならないことを考慮してください。クラウド上の既製のKubernetesを使用する際に気にする必要のないことをはるかに多く考えなければなりません。

もちろん、UbuntuやDebianのような標準的なディストリビューションを使用できますし、Flatcar Container Linux、Fedora Core、Talos Linuxのような特殊なディストリビューションを検討することもできます。それぞれに長所と短所があります。

私たちのことですか？ Ænixでは、ZFS、DRBD、OpenvSwitchなどのかなり特殊なカーネルモジュールを使用しているので、必要なモジュールをすべて事前に含んだシステムイメージを形成する方法を選びました。この場合、Talos Linuxが私たちにとって最も便利であることがわかりました。たとえば、次のような設定で、必要なカーネルモジュールをすべて含むシステムイメージを構築するのに十分です:

arch: amd64
platform: metal
secureboot: false
version: v1.6.4
input:
  kernel:
    path: /usr/install/amd64/vmlinuz
  initramfs:
    path: /usr/install/amd64/initramfs.xz
  baseInstaller:
    imageRef: ghcr.io/siderolabs/installer:v1.6.4
  systemExtensions:
    - imageRef: ghcr.io/siderolabs/amd-ucode:20240115
    - imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115
    - imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115
    - imageRef: ghcr.io/siderolabs/i915-ucode:20240115
    - imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115
    - imageRef: ghcr.io/siderolabs/intel-ucode:20231114
    - imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115
    - imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4
    - imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4
output:
  kind: installer
  outFormat: raw

dockerコマンドラインツールを使用して、OSイメージをビルドします:

cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" -

その結果、必要なものがすべて含まれたDockerコンテナイメージが得られます。このイメージを使用して、サーバーにTalos Linuxをインストールできます。同じことができます。このイメージには、必要なすべてのファームウェアとカーネルモジュールが含まれます。

しかし、新しく形成されたイメージをノードにどのように配信するかという問題が発生します。

しばらくの間、PXEブートのアイデアについて考えていました。たとえば、2年前に記事を書いたKubefarmプロジェクトは、完全にこのアプローチを使用して構築されました。しかし残念ながら、他のクラスターを保持する最初の親クラスターをデプロイするのに役立つわけではありません。そこで今回、PXEアプローチを使用して同じことを行うのに役立つソリューションを用意しました。

基本的に必要なのは、コンテナ内で一時的なDHCPとPXEサーバーを実行することだけです。そうすれば、ノードはあなたのイメージから起動し、Debianベースの簡単なスクリプトを使用して、ノードのブートストラップに役立てることができます。

talos-bootstrapスクリプトのソースコードはGitHubで入手できます。

このスクリプトを使用すると、ベアメタル上に5分でKubernetesをデプロイし、それにアクセスするためのkubeconfigを取得できます。しかし、まだ多くの未解決の問題が残っています。

システムコンポーネントの配信

この段階では、さまざまなワークロードを実行できるKubernetesクラスターがすでに手に入っています。しかし、まだ完全に機能しているわけではありません。つまり、ネットワークとストレージを設定する必要があるだけでなく、仮想マシンを実行するためのKubeVirtや、監視スタックやその他のシステム全体のコンポーネントなど、必要なクラスター拡張機能をインストールする必要があります。

従来、これはHelmチャートをクラスターにインストールすることで解決されています。ローカルでhelm installコマンドを実行することで実現できますが、アップデートを追跡したい場合や、複数のクラスターを持っていてそれらを均一に保ちたい場合、このアプローチは不便になります。実際には、これを宣言的に行う方法はたくさんあります。これを解決するには、最高のGitOpsプラクティスを使用することをお勧めします。つまり、ArgoCDやFluxCDのようなツールを指します。

ArgoCDはグラフィカルインターフェースと中央コントロールプレーンを備えているため開発目的には便利ですが、一方でFluxCDはKubernetesディストリビューションの作成により適しています。 FluxCDを使用すると、どのチャートをどのパラメーターで起動すべきかを指定し、依存関係を記述できます。そうすれば、FluxCDがすべてを処理してくれます。

新しく作成したクラスターにFluxCDを1回インストールし、適切に設定することをお勧めします。これにより、FluxCDは必要不可欠なコンポーネントをすべて自動的にデプロイできるようになり、クラスターを目的の状態にアップグレードできます。たとえば、私たちのプラットフォームをインストールすると、システムコンポーネントとともに次の事前設定されたHelmチャートが表示されます:

NAMESPACE                        NAME                        AGE    READY   STATUS
cozy-cert-manager                cert-manager                4m1s   True    Release reconciliation succeeded
cozy-cert-manager                cert-manager-issuers        4m1s   True    Release reconciliation succeeded
cozy-cilium                      cilium                      4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-operator               4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-providers              4m1s   True    Release reconciliation succeeded
cozy-dashboard                   dashboard                   4m1s   True    Release reconciliation succeeded
cozy-fluxcd                      cozy-fluxcd                 4m1s   True    Release reconciliation succeeded
cozy-grafana-operator            grafana-operator            4m1s   True    Release reconciliation succeeded
cozy-kamaji                      kamaji                      4m1s   True    Release reconciliation succeeded
cozy-kubeovn                     kubeovn                     4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi                4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi-operator       4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt                    4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt-operator           4m1s   True    Release reconciliation succeeded
cozy-linstor                     linstor                     4m1s   True    Release reconciliation succeeded
cozy-linstor                     piraeus-operator            4m1s   True    Release reconciliation succeeded
cozy-mariadb-operator            mariadb-operator            4m1s   True    Release reconciliation succeeded
cozy-metallb                     metallb                     4m1s   True    Release reconciliation succeeded
cozy-monitoring                  monitoring                  4m1s   True    Release reconciliation succeeded
cozy-postgres-operator           postgres-operator           4m1s   True    Release reconciliation succeeded
cozy-rabbitmq-operator           rabbitmq-operator           4m1s   True    Release reconciliation succeeded
cozy-redis-operator              redis-operator              4m1s   True    Release reconciliation succeeded
cozy-telepresence                telepresence                4m1s   True    Release reconciliation succeeded
cozy-victoria-metrics-operator   victoria-metrics-operator   4m1s   True    Release reconciliation succeeded

まとめ

結果として、誰にでも提供できる高い再現性を持つ環境を実現でき、意図したとおりに動作することがわかります。これは、実際にCozystackプロジェクトが行っていることであり、あなた自身が無料で試すことができます。

次の記事では、仮想マシンを実行するためのKubernetesの準備方法とボタンをクリックするだけでKubernetesクラスターを実行する方法について説明します。ご期待ください。きっと面白いはずです！

Kubernetes v1.30をそっと覗く

By Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko | 2024.03.12

Kubernetes v1.30のおもしろい変更点をざっと見る

新しい年であり、新しいKubernetesのリリースです。リリースサイクルの半分が終了し、v1.30ではかなりの数の興味深くおもしろい機能強化が行われます。アルファ版の真新しい機能から、安定版へと進む既存の機能、そして待望の改良まで、このリリースには誰もが注目するものがあります！

正式リリースまでのつなぎとして、このリリースで我々がもっとも期待している機能強化をそっと覗いてみましょう！

Kubernetes v1.30の主な変更点

動的なリソース割り当てのための構造化パラメーター (KEP-4381)

動的なリソース割り当て(DRA)はv1.26でアルファ機能としてKubernetesに追加されました。これは、サードパーティリソースへのアクセスを要求するための従来のデバイスプラグインAPIに代わるものを定義しています。設計上、動的なリソース割り当て(DRA)では、Kubernetesの中心部に完全に不透明なリソースのパラメーターが使用されます。このアプローチは、クラスターオートスケーラーや、Podのグループ(Jobスケジューラーなど)に対して決定を下す必要がある上位コントローラーにとって問題となります。時間経過に伴う要求(claim)の割り当てや割り当て解除の効果をシミュレートできないのです。これを行うための情報は、サードパーティのDRAドライバーのみが保有しています。

動的なリソース割り当て(DRA)の構造化パラメーターは、これらの要求(claim)パラメーターの不透明さがより少ないフレームワークを構築することによって、この問題に対処するための従来の実装の拡張になります。すべての要求(claim)パラメーターのセマンティクスを自分で処理する代わりに、ドライバーはKubernetesによって事前定義された特定の"構造化モデル"を使用してリソースを記述し、管理できます。これにより、この"構造化モデル"を認識しているコンポーネントは、サードパーティのコントローラーに委託することなく、これらのリソースに関する意思決定を行えます。たとえば、スケジューラーは動的なリソース割り当て(DRA)ドライバーとやり取りを行うことなく、要求(claim)を迅速に割り当てることができます。今回のリリースでは、さまざまな"構造化モデル"を実現するために必要なフレームワークの定義と"名前付きリソース"モデルの実装を中心に作業が行われました。このモデルでは、個々のリソース・インスタンスをリストアップすることができ、従来のデバイスプラグインAPIと比較して、属性によってそれらのインスタンスを個別に選択する機能が追加されています。

Nodeのメモリスワップのサポート (KEP-2400)

Kubernetes v1.30では、Linux Nodeにおけるメモリスワップのサポートが、システムの安定性を向上させることに重点を置いて、その動作方法に大きな変更が加えられました。以前のKubernetesバージョンでは、NodeSwapフィーチャーゲートはデフォルトで無効化されており、有効化された場合、デフォルトの動作としてUnlimitedSwap動作が使用されていました。より良い安定性を達成するために、(Nodeの安定性を損なう可能性のある)UnlimitedSwap動作はv1.30で削除されます。

更新された、まだベータ版のLinux Nodeでのスワップのサポートは、デフォルトで利用できるようになります。ただし、デフォルトの動作は、NoSwap(UnlimitedSwapではない)モードに設定されたNodeを実行することになります。 NoSwapモードでは、kubeletはスワップ領域が有効化されたNodeでの実行をサポートしますが、Podはページファイルを一切使用しません。そのNodeでkubeletを実行するには、--fail-swap-on=falseを設定する必要があります。ただ、大きな変更とはこのことではなく、もう1つのモードであるLimitedSwapです。このモードでは、kubeletは実際にそのNodeのページファイルを使用し、Podが仮想メモリの一部をページアウトできるようにします。コンテナ(およびその親Pod)はメモリ制限を超えてスワップにアクセスすることはできませんが、利用可能な場合はスワップ領域を使用できます。

KubernetesのNode Special Interest Group (SIG Node)は、エンドユーザー、貢献者、およびより広いKubernetesコミュニティからのフィードバックに基づいて、改訂された実装の使用方法を理解できるようにドキュメントも更新します。

KubernetesにおけるLinux Nodeのスワップ・サポートの詳細については、前回のブログ記事またはNodeのスワップ・ドキュメントを読んでください。

Podでユーザー名前空間のサポート (KEP-127)

ユーザー名前空間は、2024年1月に公開されたCVE-2024-21626を含むHigh/Criticalと評価された複数のCVEを防止、または緩和するために、Podをより適切に分離するLinux専用の機能です。 Kubernetes 1.30では、ユーザー名前空間のサポートがベータ版に移行し、ボリュームのあるPodとないPod、カスタムUID/GID範囲などがサポートされるようになりました！

構造化された認可設定 (KEP-3221)

構造化された認可設定のサポートはベータ版に移行し、デフォルトで有効になります。この機能は、失敗時に明示的に拒否するなどのきめ細かな制御を可能にしたり、特定の順序でリクエストを検証する明確に定義されたパラメーターを持つ複数のWebhookによる認可チェーンの作成を可能にします。設定ファイルのアプローチでは、リクエストがWebhookへ渡される前にCELルールを指定して事前にフィルタリングすることも可能で、不要なリクエストを防ぐのに役立ちます。また、設定ファイルが変更されると、APIサーバーは自動的に認可チェーンを再読み込みします。

--authorization-configコマンドライン引数を使用して、その認可設定へのパスを指定する必要があります。設定ファイルの代わりにコマンドラインフラグを使い続けたい場合、そのまま機能し続けます。複数のWebhook、失敗ポリシー、事前フィルタールールなどの新しい認可Webhook機能にアクセスするには、--authorization-configファイルにオプションを記述するように切り替えます。 Kubernetes 1.30からは、設定ファイルのフォーマットがベータ段階であり、フィーチャーゲートがデフォルトで有効になっているため、--authorization-configを指定する必要があるだけです。すべての可能な値を含む設定例は、認可ドキュメントで提供されています。詳細については、認可ドキュメントを読んでください。

コンテナリソースをもとにしたPodの自動スケーリング (KEP-1610)

ContainerResourceメトリクスに基づく水平Pod自動スケーリングは、v1.30で安定版に移行します。 HorizontalPodAutoscalerのこの新しい動作により、Pod全体のリソース使用量ではなく、個々のコンテナのリソース使用量に基づいて自動スケーリングを設定できるようになります。詳細については以前の記事を参照するか、コンテナリソースメトリクスを読んでください。

アドミッション・コントロールに対するCEL (KEP-3488)

Kubernetesのアドミッション・コントロールにCommon Expression Language (CEL)を統合することで、アドミッション・リクエストを評価するよりダイナミックで表現力豊かな方法が導入されます。この機能により、複雑できめ細かなポリシーがKubernetes APIを通じて直接定義・適用できるようになり、パフォーマンスや柔軟性を損なうことなく、セキュリティとガバナンスの機能が強化されます。

CELがKubernetesのアドミッション・コントロールに追加されたことで、クラスター管理者はWebhookベースのアクセス・コントローラーに頼ることなく、クラスターの望ましい状態やポリシーに対してAPIリクエストの内容を評価できる複雑なルールを作成できます。このレベルの制御は、クラスター運用の効率性、セキュリティ、整合性を維持するために極めて重要であり、Kubernetes環境をより堅牢にし、さまざまなユースケースや要件へ適応できるようにします。アドミッション・コントロールにCELを使用する詳細については、ValidatingAdmissionPolicyのAPIドキュメントを参照してください。

私たちと同じようにこのリリースを楽しみにしていただければ幸いです。数週間後の公式のリリース記事で、さらなるハイライトをお見逃しなく！

CRI-O: OCIレジストリからのseccompプロファイルの適用

By Sascha Grunert | 2024.03.07

seccompはセキュアなコンピューティングモードを意味し、Linuxカーネルのバージョン2.6.12以降の機能として提供されました。これは、プロセスの特権をサンドボックス化し、ユーザースペースからカーネルへの呼び出しを制限するために使用できます。 Kubernetesでは、ノードに読み込まれたseccompプロファイルをPodやコンテナに自動的に適用することができます。

しかし、Kubernetesでseccompプロファイルを配布することは大きな課題です。なぜなら、JSONファイルがワークロードが実行可能なすべてのノードで利用可能でなければならないからです。 Security Profiles Operatorなどのプロジェクトは、クラスター内でデーモンとして実行することでこの問題を解決しています。この設定から、コンテナランタイムがこの配布プロセスの一部を担当できるかどうかが興味深い点です。

通常、ランタイムはローカルパスからプロファイルを適用します。たとえば：

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: container
      image: nginx:1.25.3
      securityContext:
        seccompProfile:
          type: Localhost
          localhostProfile: nginx-1.25.3.json

プロファイルnginx-1.25.3.jsonはkubeletのルートディレクトリ内にseccompディレクトリを追加して利用可能でなければなりません。これは、ディスク上のプロファイルのデフォルトの場所が/var/lib/kubelet/seccomp/nginx-1.25.3.jsonになることを指しています。プロファイルが利用できない場合、ランタイムは次のようにコンテナの作成に失敗します。

kubectl get pods

NAME   READY   STATUS                 RESTARTS   AGE
pod    0/1     CreateContainerError   0          38s

kubectl describe pod/pod | tail

Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  117s                default-scheduler  Successfully assigned default/pod to 127.0.0.1
  Normal   Pulling    117s                kubelet            Pulling image "nginx:1.25.3"
  Normal   Pulled     111s                kubelet            Successfully pulled image "nginx:1.25.3" in 5.948s (5.948s including waiting)
  Warning  Failed     7s (x10 over 111s)  kubelet            Error: setup seccomp: unable to load local profile "/var/lib/kubelet/seccomp/nginx-1.25.3.json": open /var/lib/kubelet/seccomp/nginx-1.25.3.json: no such file or directory
  Normal   Pulled     7s (x9 over 111s)   kubelet            Container image "nginx:1.25.3" already present on machine

Localhostプロファイルを手動で配布する必要があるという大きな障害は、多くのエンドユーザーがRuntimeDefaultに戻るか、さらにはUnconfined(seccompが無効になっている)でワークロードを実行することになる可能性が高いということです。

CRI-Oが救世主

KubernetesのコンテナランタイムCRI-Oは、カスタムアノテーションを使用してさまざまな機能を提供しています。 v1.30のリリースでは、アノテーションの新しい集合であるseccomp-profile.kubernetes.cri-o.io/PODとseccomp-profile.kubernetes.cri-o.io/<CONTAINER>のサポートが追加されました。これらのアノテーションを使用すると、以下を指定することができます：

特定のコンテナ用のseccompプロファイルは、次のように使用されます:seccomp-profile.kubernetes.cri-o.io/<CONTAINER> (例:seccomp-profile.kubernetes.cri-o.io/webserver: 'registry.example/example/webserver:v1')
Pod内のすべてのコンテナに対するseccompプロファイルは、コンテナ名の接尾辞を使用せず、予約された名前PODを使用して次のように使用されます:seccomp-profile.kubernetes.cri-o.io/POD
イメージ全体のseccompプロファイルは、イメージ自体がアノテーションseccomp-profile.kubernetes.cri-o.io/PODまたはseccomp-profile.kubernetes.cri-o.io/<CONTAINER>を含んでいる場合に使用されます

CRI-Oは、ランタイムがそれを許可するように構成されている場合、およびUnconfinedとして実行されるワークロードに対してのみ、そのアノテーションを尊重します。それ以外のすべてのワークロードは、引き続きsecurityContextからの値を優先して使用します。

アノテーション単体では、プロファイルの配布にはあまり役立ちませんが、それらの参照方法が役立ちます！たとえば、OCIアーティファクトを使用して、通常のコンテナイメージのようにseccompプロファイルを指定できるようになりました。

apiVersion: v1
kind: Pod
metadata:
  name: pod
  annotations:
    seccomp-profile.kubernetes.cri-o.io/POD: quay.io/crio/seccomp:v2
spec: …

イメージquay.io/crio/seccomp:v2には、実際のプロファイル内容を含むseccomp.jsonファイルが含まれています。 ORASやSkopeoなどのツールを使用して、イメージの内容を検査できます。

oras pull quay.io/crio/seccomp:v2

Downloading 92d8ebfa89aa seccomp.json
Downloaded  92d8ebfa89aa seccomp.json
Pulled [registry] quay.io/crio/seccomp:v2
Digest: sha256:f0205dac8a24394d9ddf4e48c7ac201ca7dcfea4c554f7ca27777a7f8c43ec1b

jq . seccomp.json | head

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "defaultErrno": "ENOSYS",
  "archMap": [
    {
      "architecture": "SCMP_ARCH_X86_64",
      "subArchitectures": [
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"

# イメージのプレーンマニフェストを調べる
skopeo inspect --raw docker://quay.io/crio/seccomp:v2 | jq .

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config":
    {
      "mediaType": "application/vnd.cncf.seccomp-profile.config.v1+json",
      "digest": "sha256:ca3d163bab055381827226140568f3bef7eaac187cebd76878e0b63e9e442356",
      "size": 3,
    },
  "layers":
    [
      {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "digest": "sha256:92d8ebfa89aa6dd752c6443c27e412df1b568d62b4af129494d7364802b2d476",
        "size": 18853,
        "annotations": { "org.opencontainers.image.title": "seccomp.json" },
      },
    ],
  "annotations": { "org.opencontainers.image.created": "2024-02-26T09:03:30Z" },
}

イメージマニフェストには、特定の必要な構成メディアタイプ(application/vnd.cncf.seccomp-profile.config.v1+json)への参照と、seccomp.jsonファイルを指す単一のレイヤー(application/vnd.oci.image.layer.v1.tar)が含まれています。それでは、この新機能を試してみましょう！

特定のコンテナやPod全体に対してアノテーションを使用する

CRI-Oは、アノテーションを利用する前に適切に構成する必要があります。これを行うには、ランタイムの allowed_annotations配列にアノテーションを追加します。これは、次のようなドロップイン構成/etc/crio/crio.conf.d/10-crun.confを使用して行うことができます：

[crio.runtime]
default_runtime = "crun"

[crio.runtime.runtimes.crun]
allowed_annotations = [
    "seccomp-profile.kubernetes.cri-o.io",
]

それでは、CRI-Oを最新のmainコミットから実行します。これは、ソースからビルドするか、静的バイナリバンドルを使用するか、プレリリースパッケージを使用することで行うことができます。

これを実証するために、local-up-cluster.shを使って単一ノードのKubernetesクラスターをセットアップし、コマンドラインからcrioバイナリを実行しました。クラスターが起動して実行されているので、seccomp Unconfinedとして実行されているアノテーションのないPodを試してみましょう:

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: container
      image: nginx:1.25.3
      securityContext:
        seccompProfile:
          type: Unconfined

kubectl apply -f pod.yaml

ワークロードが起動して実行中です:

kubectl get pods

NAME   READY   STATUS    RESTARTS   AGE
pod    1/1     Running   0          15s

crictlを使用してコンテナを検査しても、seccompプロファイルが適用されていないことがわかります:

export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp

null

では、Podを変更して、コンテナにプロファイルquay.io/crio/seccomp:v2を適用します:

apiVersion: v1
kind: Pod
metadata:
  name: pod
  annotations:
    seccomp-profile.kubernetes.cri-o.io/container: quay.io/crio/seccomp:v2
spec:
  containers:
    - name: container
      image: nginx:1.25.3

新しいseccompプロファイルを適用するには、Podを削除して再作成する必要があります。再作成のみが新しいseccompプロファイルを適用するためです:

kubectl delete pod/pod

pod "pod" deleted

kubectl apply -f pod.yaml

pod/pod created

CRI-Oのログには、ランタイムがアーティファクトを取得したことが示されます:

WARN[…] Allowed annotations are specified for workload [seccomp-profile.kubernetes.cri-o.io]
INFO[…] Found container specific seccomp profile annotation: seccomp-profile.kubernetes.cri-o.io/container=quay.io/crio/seccomp:v2  id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Pulling OCI artifact from ref: quay.io/crio/seccomp:v2  id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Retrieved OCI artifact seccomp profile of len: 18853  id=26ddcbe6-6efe-414a-88fd-b1ca91979e93 name=/runtime.v1.RuntimeService/CreateContainer

And the container is finally using the profile:

そして、コンテナは最終的にプロファイルを使用しています:

export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp | head

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {

ユーザーが接尾辞/containerを予約名/PODに置き換えると、Pod内のすべてのコンテナに対して同じことが機能します。たとえば:

apiVersion: v1
kind: Pod
metadata:
  name: pod
  annotations:
    seccomp-profile.kubernetes.cri-o.io/POD: quay.io/crio/seccomp:v2
spec:
  containers:
    - name: container
      image: nginx:1.25.3

コンテナイメージにアノテーションを使用する

特定のワークロードにOCIアーティファクトとしてseccompプロファイルを指定する機能は素晴らしいですが、ほとんどのユーザーはseccompプロファイルを公開されたコンテナイメージに関連付けたいと考えています。これは、コンテナイメージ自体に適用されるメタデータであるコンテナイメージアノテーションを使用して行うことができます。たとえば、Podmanを使用して、イメージのビルド中に直接イメージアノテーションを追加することができます:

podman build \
    --annotation seccomp-profile.kubernetes.cri-o.io=quay.io/crio/seccomp:v2 \
    -t quay.io/crio/nginx-seccomp:v2 .

プッシュされたイメージには、そのアノテーションが含まれます:

skopeo inspect --raw docker://quay.io/crio/nginx-seccomp:v2 |
    jq '.annotations."seccomp-profile.kubernetes.cri-o.io"'

"quay.io/crio/seccomp:v2"

そのイメージを使用して、CRI-OのテストPod定義に組み込む場合：

apiVersion: v1
kind: Pod
metadata:
  name: pod
  # Podのアノテーションが設定されていません
spec:
  containers:
    - name: container
      image: quay.io/crio/nginx-seccomp:v2

その後、CRI-Oのログには、イメージのアノテーションが評価され、プロファイルが適用されたことが示されます:

kubectl delete pod/pod

pod "pod" deleted

kubectl apply -f pod.yaml

pod/pod created

INFO[…] Found image specific seccomp profile annotation: seccomp-profile.kubernetes.cri-o.io=quay.io/crio/seccomp:v2  id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Pulling OCI artifact from ref: quay.io/crio/seccomp:v2  id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Retrieved OCI artifact seccomp profile of len: 18853  id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer
INFO[…] Created container 116a316cd9a11fe861dd04c43b94f45046d1ff37e2ed05a4e4194fcaab29ee63: default/pod/container  id=c1f22c59-e30e-4046-931d-a0c0fdc2c8b7 name=/runtime.v1.RuntimeService/CreateContainer

export CONTAINER_ID=$(sudo crictl ps --name container -q)
sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp | head

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {

コンテナイメージの場合、アノテーションseccomp-profile.kubernetes.cri-o.ioはseccomp-profile.kubernetes.cri-o.io/PODと同様に扱われ、Pod全体に適用されます。さらに、この機能は、イメージにコンテナ固有のアノテーションを使用する場合にも機能します。たとえば、コンテナの名前がcontainer1の場合：

skopeo inspect --raw docker://quay.io/crio/nginx-seccomp:v2-container |
    jq '.annotations."seccomp-profile.kubernetes.cri-o.io/container1"'

"quay.io/crio/seccomp:v2"

この機能の素晴らしい点は、ユーザーが特定のコンテナイメージ用のseccompプロファイルを作成し、同じレジストリ内に並べて保存できることです。イメージをプロファイルにリンクすることで、アプリケーション全体のライフサイクルを通じてそれらを維持する柔軟性が提供されます。

ORASを使用してプロファイルをプッシュする

OCIオブジェクトを作成してseccompプロファイルを含めるには、ORASを使用する場合、もう少し作業が必要です。将来的には、Podmanなどのツールが全体のプロセスをより簡略化することを期待しています。現時点では、コンテナレジストリがOCI互換である必要があります。これはQuay.ioの場合も同様です。 CRI-Oは、seccompプロファイルオブジェクトがコンテナイメージメディアタイプ(application/vnd.cncf.seccomp-profile.config.v1+json)を持っていることを期待していますが、ORASはデフォルトでapplication/vnd.oci.empty.v1+jsonを使用します。これを実現するために、次のコマンドを実行できます：

echo "{}" > config.json
oras push \
    --config config.json:application/vnd.cncf.seccomp-profile.config.v1+json \
     quay.io/crio/seccomp:v2 seccomp.json

結果として得られるイメージには、CRI-Oが期待するmediaTypeが含まれています。 ORASは単一のレイヤーseccomp.json をレジストリにプッシュします。プロファイルの名前はあまり重要ではありません。 CRI-Oは最初のレイヤーを選択し、それがseccompプロファイルとして機能するかどうかを確認します。

将来の作業

CRI-OはOCIアーティファクトを通常のファイルと同様に内部で管理しています。これにより、それらを移動したり、使用されなくなった場合に削除したり、seccompプロファイル以外のデータを利用したりする利点が得られます。これにより、OCIアーティファクトをベースにしたCRI-Oの将来の拡張が可能になります。また、OCIアーティファクトの中に複数のレイヤーを持つことを考える上で、seccompプロファイルの積層も可能になります。 v1.30.xリリースではUnconfinedワークロードのみがサポートされているという制限は、将来CRI-Oが解決したい課題です。セキュリティを損なうことなく、全体的なユーザーエクスペリエンスを簡素化することが、コンテナワークロードにおけるseccompの成功の鍵となるようです。

CRI-Oのメンテナーは、新機能に関するフィードバックや提案を歓迎します！このブログ投稿を読んでいただき、ぜひKubernetesのSlackチャンネル#crioを通じてメンテナーに連絡したり、GitHubリポジトリでIssueを作成したりしてください。

SIG Cloud Providerの取り組みの紹介

By Arujjwal Negi | 2024.03.01

Kubernetes関連のサービスは、開発者にとってクラウドプロバイダー経由で利用するのが最も人気な方法の一つです。では、クラウドプロバイダーがどのようにしてKubernetesと連携しているのか、不思議に思ったことはありませんか？Kubernetesがさまざまなクラウドプロバイダーと統合される過程は、どのように実現されているのでしょうか？この疑問に答えるために、SIG Cloud Providerにスポットライトを当ててみましょう。

SIG Cloud Providerは、Kubernetesとさまざまなクラウドプロバイダーとのシームレスな統合を実現するために活動しています。彼らの使命は、Kubernetesエコシステムを誰にとっても公平かつオープンなものに保つことです。明確な基準と要件を定めることで、どのクラウドプロバイダーもKubernetesと適切に連携できるようにしています。クラウドプロバイダーとの連携を可能にするために、クラスター内の各コンポーネントを適切に構成することも彼らの重要な責務です。

SIG Spotlightシリーズの本記事では、Arujjwal NegiがMichael McCune(Red Hat)にインタビューを行いました。McCune氏は elmiko の名でも知られており、SIG Cloud Providerの共同チェアを務めています。このインタビューを通じて、本SIGの活動の実態に迫ります。

はじめに

Arujjwal: まずは、あなた自身について知るところから始めたいと思います。簡単に自己紹介をしていただけますか？また、どのようにしてKubernetesに関わるようになったのかも教えてください。

Michael:こんにちは、Michael McCuneです。コミュニティでは、多くの人が私のハンドルネームである elmiko と呼んでいます。私は長年ソフトウェア開発に携わっており(私が開発を始めた頃は、Windows 3.1が流行していました！)、キャリアのほとんどをオープンソースソフトウェアとともに歩んできました。Kubernetesに関わるようになったのは、機械学習やデータサイエンスのアプリケーション開発に取り組んでいたときです。当時所属していたチームでは、Apache Sparkなどの技術をKubernetes上で活用するチュートリアルやサンプルを作成していました。それとは別に、私は以前から分散システム全般に強い関心を持っており、Kubernetesの開発に直接取り組むチームに参加できるチャンスが訪れたときには、すぐに飛び込みました！

活動内容と運営体制

Arujjwal: SIG Cloud Providerがどのような活動を行っていて、どのように機能しているのか教えていただけますか？

Michael: SIG Cloud Providerは、Kubernetesがすべてのインフラプロバイダーに対して中立的な統合ポイントを提供できるようにすることを目的として設立されました。これまでで最大の取り組みは、Kubernetes本体(in-tree)に組み込まれていたクラウドコントローラーを、外部コンポーネント(out-of-tree)として切り出し、移行する作業です。SIGでは定期的にミーティングを行い、進捗状況や今後の作業について議論しています。あわせて、報告された質問やバグへの対応も行っています。さらに、クラウドプロバイダー向けのフレームワークや各種クラウドコントローラーの実装、Konnectivity proxy projectなど、クラウド関連サブプロジェクトの調整窓口としての役割も担っています。

Arujjwal: プロジェクトのREADMEを拝見し、SIG Cloud ProviderがKubernetesとクラウドプロバイダーとの統合に関わっていることを知りました。この統合プロセスは、具体的にどのように進められているのでしょうか？

Michael: Kubernetesを実行する最も一般的な方法の一つは、クラウド環境(AWS、Azure、GCPなど)にデプロイすることです。これらのクラウドインフラには、Kubernetesのパフォーマンスを高めるための機能が備わっていることがよくあります。例えば、Serviceオブジェクト向けのエラスティックロードバランシングを提供する機能などです。Kubernetesからクラウド固有のサービスを一貫して利用できるようにするために、Kubernetesコミュニティではクラウドコントローラーという仕組みを導入し、これらの統合ポイントに対応しています。クラウドプロバイダーは、SIGが管理しているフレームワークを利用するか、あるいはKubernetesのコードやドキュメントで定義されているAPIガイドラインに従うことで、独自のコントローラーを作成できます。ここでひとつ強調しておきたいのは、SIG Cloud ProviderはKubernetesクラスター内のノードのライフサイクル管理は担当していないという点です。このようなトピックについては、SIG Cluster Lifecycleや Cluster APIプロジェクトが適切な議論の場となります。

重要なサブプロジェクト

Arujjwal:このSIGには多くのサブプロジェクトが存在しています。その中でも特に重要なものと、それぞれが担っている役割について教えていただけますか？

Michael: 現在、最も重要だと考えているサブプロジェクトはcloud provider frameworkと、extraction/migration projectの2つです。cloud provider framework は、インフラ統合を担当する開発者が、自身のインフラ環境に対応したクラウドコントローラーを構築する際に役立つ共通ライブラリです。このプロジェクトは、新しくSIGに参加する人たちが最初に触れることの多い入り口でもあります。もう一つのextraction and migration projectは、このフレームワークの存在理由にも関わる、非常に大きなサブプロジェクトです。少し背景を説明すると、Kubernetesでは長い間、基盤となるインフラとの統合が必要とされてきました。その目的は、必ずしも機能を追加することではなく、たとえばインスタンスの終了といったクラウド上のイベントを把握するためでした。当初、クラウドプロバイダーとの統合機能はKubernetes本体のコードツリー内に直接組み込まれていました。これがいわゆる"in-tree"と呼ばれる形式の由来です(詳しくはこちらの記事をご覧ください)。しかし、プロバイダー固有のコードを Kubernetesのメインソースツリーで管理することは、コミュニティにとって望ましくないと見なされていました。そのため、"in-tree"のクラウドコントローラーを取り除き、"out-of-tree"で管理可能な独立コンポーネントへと移行するために、このextraction and migration projectが立ち上げられました。

Arujjwal: [cloud provider framework]が、新しく関わる人にとって良い出発点になるのはなぜでしょうか？初心者向けのタスクが継続的に用意されているのですか？あるとすれば、どのような内容ですか？

Michael: cloud provider frameworkは、クラウドコントローラーマネージャーに関するコミュニティの推奨される実装方法を反映しているため、新しく参加する人にとっては良い出発点だと思います。このフレームワークに取り組むことで、マネージャーが何を、どのように行っているのかをしっかりと理解できるはずです。ただ残念ながら、このコンポーネントに関しては、初心者向けのタスクが常に継続的に用意されているわけではありません。その理由の一つは、フレームワーク自体がすでに成熟していること、また各クラウドプロバイダー側の実装も同様に安定していることです。この分野にもっと関わってみたいという方には、Go言語の基本的な知識があると良いと思います。加えて、少なくとも1つのクラウドAPI(AWS、Azure、GCPなど)についての理解があると、なお良いです。個人的な意見ですが、SIG Cloud Providerに新しく参加することは簡単ではないと思います。というのも、このプロジェクトに関わるコードの多くは、特定のクラウドプロバイダーとの統合処理を直接扱っているからです。クラウドプロバイダー周りでより積極的に活動したいと考えている方への私のアドバイスは、まず1つか2つのクラウドAPIに慣れ親しむことです。その上で、該当するクラウド向けのコントローラーマネージャーにあるopen issueを探し、他のコントリビューターとできるだけ多くコミュニケーションを取るようにするのが良いでしょう。

成果

Arujjwal: SIG Cloud Providerの活動の中で、特に誇りに思っている成果があれば教えてくれますか？

Michael: 私がSIGに参加してから1年以上が経ちますが、その間にextraction and migrationサブプロジェクトを大きく前進させることができました。当初は、定義されたKEPはアルファ版の段階でしたが、現在ではベータ版へと進み、Kubernetesのソースツリーから古いプロバイダーコードを削除するところまで近づいています。コミュニティのメンバーが積極的に関与してくれている様子を見ることができ、とても誇らしく感じています。クラウドコントローラーの切り出しに向けて、私たちが着実に前進してきたことを実感しています。おそらく、あと数回のリリースのうちに、in-treeのクラウドコントローラーは完全に削除され、このサブプロジェクトも完了するだろうと感じています。

新しいコントリビューターへのアドバイス

Arujjwal: SIG Cloud Providerに参加したいと考えている新しいコントリビューターに向けて、何か提案やアドバイスはありますか？

Michael: 個人的には、これは難しい質問だと思います。SIG Cloud Providerは、Kubernetesと基盤インフラとの間を統合するコード部分に焦点を当てたグループです。SIGのメンバーは、クラウドプロバイダーの公式な立場を代表していることが多いですが、必ずしもそうである必要はありません。Kubernetesのこの分野に関心がある方には、まずSIGのミーティングに参加して、私たちがどのように活動しているかを見てみることをおすすめします。あわせて、cloud provider frameworkプロジェクトを学ぶのも良いスタートになります。また、今後に向けた興味深いアイデアもいくつかあります。たとえば、すべてのクラウドプロバイダーに共通するテストフレームワークの構想です。これは、Kubernetesへの関与を広げたい方にとって、大きなチャンスになるでしょう。

Arujjwal: 現在、SIG Cloud Providerとして求めているスキルの中で、私たちが特に強調すべきものはありますか？私たちが所属するSIG ContribExから例を挙げると、たとえばHugoの専門知識がある方であれば、k8s.devの改善で常に力をお借りしたいと考えています！

Michael: 現在、SIGはextraction and migrationプロセスの最終段階に取り組んでいます。一方で、今後に向けた計画もすでに始めており、次に何を進めていくかを検討しています。その中でも大きな話題の一つがテストです。現時点では、各クラウドプロバイダーが自分たちのコントローラーマネージャーの動作を確認するために使える、汎用的で共通なテスト群は存在していません。もし、GinkgoやKubetestフレームワークに詳しい方がいれば、新しいテストの設計や実装にあたって、ぜひ力をお借りしたいと思います。

これでインタビューは終了です。SIG Cloud Providerの目的や活動内容について、少しでも理解を深めていただけたなら幸いです。今回ご紹介したのは、あくまでその一端に過ぎません。より詳しく知りたい方や実際に関わってみたい方は、こちらのミーティングに参加してみてください。

Kubernetesブッククラブを覗く

By Frederico Muñoz (SAS Institute) | 2024.02.22

Kubernetesとそれを取り巻く技術のエコシステム全体を学ぶことは、課題がないわけではありません。このインタビューでは、AWSのCarlos Santanaさんに、コミュニティベースの学習体験を利用するために、彼がどのようにしてKubernetesブッククラブを作ったのか、その会がどのような活動をするのか、そしてどのようにして参加するのかについて伺います。

KubeCon NA 2023で話すCarlos Santanaさん

Frederico Muñoz (FSM): こんにちはCarlosさん、時間をとってくれてありがとう。まずはじめに、ご自身のことを少し教えていただけますか？

Carlos Santana (CS): もちろんです。 6年前に本番環境でKubernetesをデプロイした経験が、Knativeに参加するきっかけとなり、その後リリースチームを通じてKubernetesに貢献しました。アップストリームのKubernetesでの作業は、私がオープンソースで得た最高の経験のひとつです。過去2年間、AWSのシニア・スペシャリスト・ソリューション・アーキテクトとしての役割で、私は大企業がKubernetes上に内部開発者プラットフォーム(IDP)を構築することを支援してきました。今後、私のオープンソースへの貢献は、ArgoやCrossplane、BackstageのようなCNCFのプロジェクトやCNOEを対象にしています。

ブッククラブの創設

FSM: それであなたがKubernetesに辿り着いたわけですが、その時点でブッククラブを始めた動機は何だったのでしょうか？

CS: Kubernetesブッククラブのアイデアは、TGIKのライブ配信での何気ない提案から生まれました。私にとって、それは単に本を読むということ以上に、学習コミュニティを作るということでした。このプラットフォームは知識の源であるだけでなく、特にパンデミックの困難な時期にはサポートシステムでもありました。この取り組みが、メンバーたちの対処と成長に役立っていることを目の当たりにして、喜ばしいと思っています。最初の本Production Kubernetesは、2021年3月5日に始めて36週間かかりました。現在は、1冊の本をカバーするのにそれほど時間はかからず、1週間に1章か2章です。

FSM: Kubernetesブッククラブの仕組みについて教えてください。どのように本を選び、どのように読み進めるのですか？

CS: 私たちは、グループの関心とニーズに基づいて本を共同で選んでいます。この実践的なアプローチは、メンバー、とくに初心者が複雑な概念をより簡単に理解するのに役立ちます。毎週2つのシリーズがあり、EMEAのタイムゾーンのものと、私がUSで組織しているものです。各オーガナイザーは共同ホストと協力してSlack上で本を選び、各章の議論するために、数週間に渡りホストのラインナップを整えます。

FSM: 私の記憶が間違っていなければ、Kubernetesブッククラブは17冊目に突入しています。物事を活発に保つための秘密のレシピがあるのですか？

CS: ブッククラブを活発で魅力的なものに保つ秘訣は、いくつかの重要な要素にあります。

まず、一貫性が重要です。休みの日やKubeConのような大きなイベントの時だけミーティングをキャンセルして、定期的なスケジュールを維持するよう努力しています。この規則性は、メンバーの参加を維持し、信頼できるコミュニティを築くのに役立っています。

次に、セッションを面白く、対話式のものにすることが重要です。たとえば、ミートアップ中にポップアップ・クイズを頻繁に導入します。これはメンバーの理解度をテストするだけでなく、楽しみの要素も加えています。このアプローチによって内容の関連性が維持され、理論的な概念が実社会のシナリオでどのように適用されるかをメンバーが理解するのに役立ちます。

ブッククラブで扱うトピック

FSM: 書籍の主なトピックは、Kubernetes、GitOps、セキュリティ、SRE、オブザーバビリティになっています。これはとくに人気という観点で、Cloud Native Landscapeの反映でしょうか？

CS: 私たちの旅は『Production Kubernetes』から始まり、実用的な本番環境向けのソリューションに焦点を当てる方向性を設定しました。それ以来、私たちはCNCF Landscapeのさまざまな側面を掘り下げ、異なるテーマに沿って本を揃えています。各テーマは、それがセキュリティであれ、オブザーバビリティであれ、サービスメッシュであれ、コミュニティ内の関連性と需要にもとづいて選択されています。たとえば、Kubernetes認定に関する最近のテーマでは、書籍の著者を積極的なホストとして参加させ、彼らの専門知識で議論を充実させました。

FSM: プロジェクトに最近変化があったことは知っています。Cloud Native Community GroupとしてCNCFに統合されたことです。この変更について少しお話いただけますか？

CS: CNCFはブッククラブをCloud Native Community Groupとして快く受け入れてくれました。これは私たちの運営を合理化し、影響範囲を拡大する重要な進展です。この連携はKubernetes Community Days (KCD)のミートアップで使用されているものと同様に、管理機能の強化に役立っています。現在では、メンバーシップ、イベントのスケジューリング、メーリングリスト、Webカンファレンスの開催、セッションの記録など、より強固な体制が整っています。

FSM: CNCFとの関わりは、この半年間のKubernetesブッククラブの成長やエンゲージメントにどのような影響を与えましたか？

CS: 半年前にCNCFコミュニティの一員になって以来、Kubernetesブッククラブでは大きな定量的な変化を目の当たりにしてきました。会員数は600人以上に急増し、この間に40以上のイベントを企画・実施することに成功しました。さらに期待されるのは、1回のイベントに平均30人が参加するという安定した動員数です。この成長とエンゲージメントは、コミュニティにおける影響やKubernetesブッククラブの影響範囲に関して、私たちのCNCF加盟が肯定的な影響である明確な指標です。

ブッククラブに参加する

FSM: 参加を希望する人は、どうすればいいのでしょうか？

CS: 参加するためには3つの段階があります。

まず、Kubernetesブッククラブコミュニティに参加します
次に、コミュニティページ上のイベントに出欠連絡をします
最後に、CNCFのSlackチャンネル#kubernetes-book-clubに参加します

FSM: 素晴らしい、ありがとうございます！最後に何かコメントをお願いします。

CS: Kubernetesブッククラブは、単に本について議論する専門家のグループというだけではなく、それ以上です。それは、Neependra Khareさん、Eric Smallingさん、Sevi Karakulakさん、Chad M. Crowellさん、そしてWalid (CNJ) Shaariさんの主催と企画を手伝ってくれる素晴らしいボランティアであり、活気のあるコミュニティです。 KubeConで私たちを見て、Kubernetesブッククラブのステッカーをゲットしてください！

Kubernetesでコンテナを別ファイルシステムに格納する設定方法

By Kevin Hannon (Red Hat) | 2024.01.23

Kubernetesクラスターの稼働、運用する上でよくある問題は、ディスク容量が不足することです。ノードがプロビジョニングされる際には、コンテナイメージと実行中のコンテナのために十分なストレージスペースを確保することが重要です。通常、コンテナランタイムは/varに書き込みます。これは別のパーティションとして、ルートファイルシステム上に配置できます。 CRI-Oはデフォルトで、コンテナとイメージを/var/lib/containersに書き込みますが、containerdはコンテナとイメージを/var/lib/containerdに書き込みます。

このブログ記事では、コンテナランタイムがデフォルトのパーティションとは別にコンテンツを保存する方法に注目したいと思います。これにより、Kubernetesの設定をより柔軟に行うことができ、デフォルトのファイルシステムはそのままに、コンテナストレージ用に大きなディスクを追加する方法が提供されます。

もう少し説明が必要な領域は、Kubernetesがディスクに書き込む場所/内容です。

Kubernetesディスク使用状況を理解する

Kubernetesには永続(persistent)データと一時(ephemeral)データがあります。 kubeletとローカルのKubernetes固有ストレージのベースパスは設定可能ですが、通常は/var/lib/kubeletと想定されています。 Kubernetesのドキュメントでは、これは時々ルートファイルシステムまたはノードファイルシステムと呼ばれます。このデータの大部分は、次のようにカテゴリー分けされます。

エフェメラルストレージ
ログ
コンテナランタイム

ルート/ノード・ファイルシステムは/ではなく、/var/lib/kubeletがあるディスクのため、ほとんどのPOSIXシステムとは異なります。

エフェメラルストレージ

Podやコンテナは、動作に一時的または短期的なローカルストレージを必要とする場合があります。エフェメラルストレージの寿命は個々のPodの寿命を超えず、エフェメラルストレージはPod間で共有することはできません。

ログ

デフォルトでは、Kubernetesは各実行中のコンテナのログを/var/log内のファイルとして保存します。これらのログは一時的であり、ポッドが実行されている間に大きくなりすぎないようにkubeletによって監視されます。

各ノードのログローテーション設定をカスタマイズしてこれらのログのサイズを管理し、ノードローカルストレージに依存しないためにログの配信を設定することができます(サードパーティーのソリューションを使用)。

コンテナランタイム

コンテナランタイムには、コンテナとイメージのための2つの異なるストレージ領域があります。

読み取り専用レイヤー:イメージは通常、コンテナが実行されている間に変更されないため、読み取り専用レイヤーとして表されます。読み取り専用レイヤーには、複数のレイヤーが組み合わされて単一の読み取り専用レイヤーになることがあります。コンテナがファイルシステムに書き込んでいる場合、コンテナの上にはエフェメラルストレージを提供する薄いレイヤーがあります。
書き込み可能レイヤー:コンテナランタイムによっては、ローカルの書き込みがレイヤー化された書き込みメカニズム(たとえば、Linux上のoverlayfsやWindows上のCimFS)として実装されることがあります。これは書き込み可能レイヤーと呼ばれます。ローカルの書き込みは、コンテナイメージの完全なクローンで初期化された書き込み可能なファイルシステムを使用する場合もあります。これは、ハイパーバイザ仮想化に基づく一部のランタイムで使用されます。

コンテナランタイムのファイルシステムには、読み取り専用レイヤーと書き込み可能レイヤーの両方が含まれます。これはKubernetesドキュメントではimagefsと見なされています。

コンテナランタイムの構成

CRI-O

CRI-Oは、コンテナランタイムが永続データと一時データをどのように保存するかを制御するためのTOML形式のストレージ構成ファイルを使用します。 CRI-Oはストレージライブラリを利用します。一部のLinuxディストリビューションには、ストレージに関するマニュアルエントリ(man 5 containers-storage.conf)があります。ストレージの主な設定は、/etc/containers/storage.confにあり、一時データの場所やルートディレクトリを制御することができます。ルートディレクトリは、CRI-Oが永続データを保存する場所です。

[storage]
# Default storage driver
driver = "overlay"
# Temporary storage location
runroot = "/var/run/containers/storage"
# Primary read/write location of container storage
graphroot = "/var/lib/containers/storage"

graphroot
- コンテナランタイムから保存される永続データを指します
- SELinuxが有効になっている場合、これは/var/lib/containers/storageと一致させる必要があります
runroot
- コンテナに対する一時的な読み書きアクセスを提供します
- これは一時ファイルシステムに配置することを推奨します

ここでは、/var/lib/containers/storageに合うようにgraphrootディレクトリのラベルを変更する簡単な方法を紹介します:

semanage fcontext -a -e /var/lib/containers/storage <YOUR-STORAGE-PATH>
restorecon -R -v <YOUR-STORAGE-PATH>

containerd

コンテナランタイムであるcontainerdは、永続データと一時データの保存先を制御するためのTOML形式の構成ファイルを使用します。構成ファイルのデフォルトパスは、/etc/containerd/config.tomlにあります。

containerdストレージの関連フィールドは、rootとstateです。

root
- containerdのメタデータのルートディレクトリ
- デフォルトは/var/lib/containerdです
- また、OSがそれを要求する場合は、ルートにSELinuxラベルも必要です
state
- containerdの一時データ
- デフォルトは、/run/containerdです

Kubernetesノードの圧迫による退避

Kubernetesは、コンテナファイルシステムがノードファイルシステムと分離されているかどうかを自動的に検出します。ファイルシステムを分離する場合、Kubernetesはノードファイルシステムとコンテナランタイムファイルシステムの両方を監視する責任があります。 Kubernetesドキュメントでは、ノードファイルシステムとコンテナランタイムファイルシステムをそれぞれnodefsとimagefsと呼んでいます。 nodefsまたはimagefsのいずれかがディスク容量不足になると、ノード全体がディスク圧迫があると見なされます。 Kubernetesは、まず未使用のコンテナやイメージを削除してスペースを回収し、その後にポッドを追い出すことでスペースを再利用します。 nodefsとimagefsの両方を持つノードでは、kubeletはimagefs上の未使用のコンテナイメージをガベージコレクトし、nodefsからは終了したポッドとそれらのコンテナを削除します。 nodefsのみが存在する場合、Kubernetesのガベージコレクションには、終了したコンテナ、ポッド、そして未使用のイメージが含まれます。

Kubernetesでは、ディスクがいっぱいかどうかを判断するためのより多くの構成が可能です。 kubelet内の退避マネージャーには、関連する閾値を制御するいくつかの構成設定があります。ファイルシステムの場合、関連する測定値はnodefs.available、nodefs.inodesfree、imagefs.available、およびimagefs.inodesfreeです。コンテナランタイム用に専用のディスクがない場合、imagefsは無視されます。

ユーザーは、既存のデフォルト値を使用できます:

memory.available < 100MiB
nodefs.available < 10%
imagefs.available < 15%
nodefs.inodesFree < 5% (Linuxノード)

Kubernetesでは、kubeletの構成ファイル内のEvictionHardとEvictionSoftにユーザー定義の値を設定することができます。

EvictionHard 限界値を定義します。これらの限界値を超えると、Grace Periodなしでポッドが追い出されます。

EvictionSoft 限界値を定義します。これらの限界値を超えると、Grace Periodが設定されたシグナルごとにポッドが追い出されます。

EvictionHardの値を指定すると、デフォルト値が置き換えられます。したがって、すべてのシグナルを設定することが重要です。

たとえば、次に示すkubeletの設定は、退避シグナルと猶予期間オプションを設定するために使用できます。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoft:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoftGracePeriod:
    memory.available:  "1m30s"
    nodefs.available:  "2m"
    nodefs.inodesFree: "2m"
    imagefs.available: "2m"
    imagefs.inodesFree: "2m"
evictionMaxPodGracePeriod: 60s

問題点

Kubernetesプロジェクトでは、退避のデフォルト設定を使用するか、退避に関連するすべてのフィールドを設定することをお勧めしています。デフォルト設定を使用するか、独自のevictionHard設定を指定できます。シグナルの設定を忘れると、Kubernetesはそのリソースを監視しません。管理者やユーザーが遭遇する可能性のある一般的な設定ミスの1つは、新しいファイルシステムを/var/lib/containers/storageまたは/var/lib/containerdにマウントすることです。 Kubernetesは別のファイルシステムを検出するため、これを行った場合はimagefs.inodesfreeとimagefs.availableが必要に応じて設定に一致していることを確認する必要があります。

もう一つの混乱の領域は、イメージファイルシステムをノードに定義した場合でも、エフェメラルストレージの報告が変わらないことです。イメージファイルシステム(imagefs)は、コンテナイメージのレイヤーを保存するために使用されます。コンテナが自分自身のルートファイルシステムに書き込む場合、そのローカルな書き込みはコンテナイメージのサイズには含まれません。コンテナランタイムがこれらのローカルな変更を保存する場所は、ランタイムによって定義されますが、通常はイメージファイルシステムです。 Pod内のコンテナがファイルシステムをバックエンドとするemptyDirボリュームに書き込んでいる場合、これはノードファイルシステムからスペースを使用します。 kubeletは常に、nodefsで表されるファイルシステムに基づいてエフェメラルストレージの容量と割り当てを報告します。これは、実際には一時的な書き込みがイメージファイルシステムに行われている場合に混乱の原因となる可能性があります。

今後の課題

KEP-4191に取り組むことで、エフェメラルの報告の制限を解消し、コンテナランタイムにより多くの構成オプションを提供することが期待されています。この提案では、Kubernetesは書き込み可能なレイヤーが読み取り専用のレイヤー(イメージ)と分離されているかどうかを検出します。これにより、書き込み可能なレイヤーを含むすべてのエフェメラルストレージを同じディスクに配置することが可能になります。また、イメージ用に別のディスクを使用することも可能になります。

参加するためにはどうすればよいですか？

参加したい場合は、KubernetesのSIG Nodeに参加することができます。

フィードバックを共有したい場合は、Slackチャンネルの#sig-nodeで行うことができます。まだそのSlackワークスペースに参加していない場合は、https://slack.k8s.io/から招待状を取得できます。

素晴らしいレビューを提供し、貴重な洞察を共有し、トピックのアイデアを提案してくれたすべてのコントリビューターに特別な感謝を捧げます。

Peter Hunt
Mrunal Patel
Ryan Phillips
Gaurav Singh

SIG Releaseスポットライト(リリース・チーム・サブプロジェクト)

By Nitish Kumar | 2024.01.15

リリース・スペシャル・インタレスト・グループ(SIG Release)は、Kubernetesが4ヶ月ごとに最先端の機能とバグ修正でその刃を研ぐ場所です。Kubernetesのような大きなプロジェクトが、新バージョンをリリースするまでのタイムラインをどのように効率的に管理しているのか、またリリースチームの内部はどのようになっているのか、考えたことはありますか？このような疑問に興味がある方、もっと知りたい方、SIG Releaseの仕事に関わりたい方は、ぜひ読んでみてください！

SIG ReleaseはKubernetesの開発と進化において重要な役割を担っています。その主な責任は、Kubernetesの新バージョンのリリースプロセスを管理することです。通常3〜4ヶ月ごとの定期的なリリースサイクルで運営されています。このサイクルの間、Kubernetesリリースチームは他のSIGやコントリビューターと密接に連携し、円滑でうまく調整されたリリースを保証します。これには、リリーススケジュールの計画、コードフリーズとテストフェーズの期限の設定、バイナリ、ドキュメント、リリースノートなどのリリース成果物の作成が含まれます。

さらに読み進める前に、SIG Releaseにはリリース・エンジニアリングとリリース・チームという2つのサブプロジェクトがあることに注意してください。

このブログ記事では、Nitish KumarがSIG Releaseのテクニカル・リーダーであるVerónica López (PlanetScale)にインタビューし、Release Teamサブプロジェクトにスポットライトを当て、リリース・プロセスがどのように見えるか、そして参加する方法について説明します。

最初の計画から最終的なリリースまで、Kubernetesの新バージョンの典型的なリリースプロセスはどのようなものですか？スムーズなリリースを保証するために使用している特定の方法論やツールはありますか？

Kubernetesの新バージョンのリリースプロセスは、十分に構造化されたコミュニティ主導の取り組みです。私たちが従う特定の方法論やツールはありませんが、物事を整理しておくための一連の手順を記載したカレンダーはあります。完全なリリースプロセスは次のようになります：

リリースチームの立ち上げ：新しいリリースのさまざまなコンポーネントの管理を担当するKubernetesコミュニティのボランティアを含むリリースチームの結成から始めます。これは通常、前のリリースが終了する前に行われます。チームが結成されると、リリースチームリーダーとブランチマネージャーが通常の成果物のカレンダーを提案する間に、新しいメンバーがオンボードされます。例として、SIG Releaseのリポジトリに作成されたv1.29チーム結成のissueを見てください。コントリビューターがリリースチームの一員になるには、通常リリースシャドウプログラムを通りますが、それがSIG Releaseに参加する唯一の方法というわけではありません。
初期段階：各リリースサイクルの最初の数週間で、SIG ReleaseはKubernetes機能強化提案(KEPs)で概説された新機能や機能強化の進捗を熱心に追跡します。これらの機能のすべてがまったく新しいものではありませんが、多くの場合、アルファ段階から始まり、その後ベータ段階に進み、最終的には安定したステータスに到達します。
機能の成熟段階：通常、コミュニティからのフィードバックを集めるため、実験的な新機能を含むアルファ・リリースを2、3回行い、その後、機能がより安定し、バグの修正が中心となるベータ・リリースを2、3回行います。この段階でのユーザーからのフィードバックは非常に重要で、この段階で発生する可能性のあるバグやその他の懸念に対処するために、追加のベータ・リリースを作成しなければならないこともあります。これがクリアされると、実際のリリースの前にリリース候補(RC)を作成します。このサイクルを通じて、リリースノートやユーザーガイドなどのドキュメントの更新や改善に努めます。
安定化段階：新リリースの数週間前にコードフリーズを実施し、この時点以降は新機能の追加を禁止します。メインリリースと並行して、私たちはKubernetesの古い公式サポートバージョンのパッチを毎月作成し続けているので、Kubernetesバージョンのライフサイクルはその後数ヶ月に及ぶと言えます。完全なリリースサイクル全体を通して、リリースノートやユーザーガイドを含むドキュメントの更新と改善に努めます。

各リリースで安定性と新機能の導入のバランスをどのように扱っていますか？どのような基準で、どの機能をリリースに含めるかを決定するのですか？

終わりのないミッションですが、重要なのは私たちのプロセスとガイドラインを尊重することだと考えています。私たちのガイドラインは、このプロジェクトに豊富な知識と経験をもたらしてくれるコミュニティの何十人ものメンバーから、何時間にもわたって議論とフィードバックを重ねた結果です。もし厳格なガイドラインがなかったら、私たちの注意を必要とするもっと生産的な議題に時間を使う代わりに、同じ議論を何度も繰り返してしまうでしょう。すべての重要な例外は、チームメンバーの大半の合意を必要とするため、品質を確保することができます。

何がリリースになるかを決定するプロセスは、リリースチームがワークフローを引き継ぐずっと前から始まっています。各SIGと経験豊富なコントリビューターが、機能や変更を含めるかどうかを決定します。その後、リリースチームが、それらの貢献がドキュメント、テスト、後方互換性などの要件を満たしていることを確認し、正式に許可します。同様のプロセスは月例パッチリリースのチェリーピックでも行われ、完全なKEPを必要とするPRや、影響を受けるすべてのブランチを含まない修正は受け入れないという厳しいポリシーがあります。
Kubernetesの開発とリリース中に遭遇した最も大きな課題は何ですか？これらの課題をどのように克服しましたか？

リリースのサイクルごとに、さまざまな課題が発生します。新たに発見されたCVE(Common Vulnerabilities and Exposures)のような土壇場の問題に取り組んだり、内部ツール内のバグを解決したり、以前のリリースの機能によって引き起こされた予期せぬリグレッションに対処したりすることもあります。私たちがしばしば直面するもう1つの障害は、私たちのチームは大規模ですが、私たちのほとんどがボランティアベースで貢献していることです。時には人手が足りないと感じることもありますが、私たちは常に組織化し、うまくやりくりしています。
新しい貢献者として、SIG Releaseに参加するための理想的な道はどのようなものでしょうか？誰もが自分のタスクに忙殺されているコミュニティで、効果的に貢献するために適切なタスクを見つけるにはどうすればいいのでしょうか？

オープンソースコミュニティへの関わり方は人それぞれです。SIG Releaseは、リリースを出荷できるように自分たちでツールを書くという、自分勝手なチームです。SIG K8s Infraのような他のSIGとのコラボレーションも多いのですが、私たちが使用するツールはすべて、コストを削減しつつ、私たちの大規模な技術的ニーズに合わせて作られたものでなければなりません。このため、「単に」リリースを作成するだけでなく、さまざまなタイプのプロジェクトを手伝ってくれるボランティアを常に探しています。

私たちの現在のプロジェクトでは、Goプログラミング、Kubernetes内部の理解、Linuxパッケージング、サプライチェーンセキュリティ、テクニカルライティング、一般的なオープンソースプロジェクトのメンテナンスなどのスキルが必要です。このスキルセットは、プロジェクトの成長とともに常に進化しています。

理想的な道筋として、私たちはこう提案します:
- どのように機能が管理されているか、リリースカレンダー、リリースチームの全体的な構造など、コードに慣れる。
- Slack(#sig-release)などのKubernetesコミュニティのコミュニケーションチャンネルに参加する。
- コミュニティ全員が参加できるSIG Releaseウィークリーミーティングに参加する。これらのミーティングに参加することは、あなたのスキルセットや興味に関連すると思われる進行中のプロジェクトや将来のプロジェクトについて学ぶ素晴らしい方法です。
経験豊富な貢献者は皆、かつてあなたのような立場にあったことを忘れないでください。遠慮せずに質問し、議論に参加し、貢献するための小さな一歩を踏み出しましょう。
リリースシャドウプログラムとは何ですか？また、他の様々なSIGに含まれるシャドウプログラムとの違いは何ですか？

リリースシャドウプログラムは、Kubernetesのリリースサイクルを通して、リリースチームの経験豊富なメンバーをシャドウイングする機会を提供します。これは、Kubernetesのリリースに必要な、サブチームにまたがるすべての困難な仕事を見るまたとないチャンスです。多くの人は、私たちの仕事は3ヶ月ごとにリリースを切ることだけだと思っていますが、それは氷山の一角にすぎません。

私たちのプログラムは通常、特定のKubernetesリリースサイクルに沿っており、それは約3ヶ月の予測可能なタイムラインを持っています。このプログラムではKubernetesの新機能を書くことはありませんが、リリースチームは新リリースと何千人ものコントリビューターとの最後のステップであるため、高い責任感が求められます。
一般的に、次のKubernetesリリースのリリースシャドウ/リリースリードとしてボランティアに参加する人に求める資格は何ですか？

どの役割もある程度の技術的能力を必要としますが、Goの実践的な経験やKubernetes APIに精通していることを必要とするものもあれば、技術的な内容を明確かつ簡潔に伝えるのが得意な人を必要とするものもあります。技術的な専門知識よりも、熱意とコミットメントを重視しています。もしあなたが正しい姿勢を持っていて、Kubernetesやリリース・エンジニアリングの仕事を楽しんでいることが伝われば、たとえそれがあなたが余暇を利用して立ち上げた個人的なプロジェクトであったとしても、チームは必ずあなたを指導します。セルフスターターであること、そして質問をすることを恐れないことは、私たちのチームであなたを大きく前進させます。
リリースシャドープログラムに何度も不合格になった人に何を勧めますか？

応募し続けることです。

リリースサイクルごとに応募者数が飛躍的に増えているため、選ばれるのが難しくなり、落胆することもありますが、不採用になったからといって、あなたに才能がないというわけではないことを知っておいてください。すべての応募者を受け入れることは現実的に不可能です、しかし、ここに私たちが提案する代替案があります。:

毎週開催されるKubernetes SIGのリリースミーティングに参加して、自己紹介をし、チームや私たちが取り組んでいるプロジェクトに慣れてください。

リリースチームはSIG Releaseに参加する方法の1つですが、私たちは常に手伝ってくれる人を探しています。繰り返しになりますが、一定の技術的な能力に加えて、私たちが最も求めている特性は、信頼できる人であり、それには時間が必要です。
リリースチームがKubernetes v1.28に特に期待している進行中の取り組みや今後の機能について教えてください。これらの進歩は、Kubernetesの長期的なビジョンとどのように整合しているのでしょうか？

Kubernetesのパッケージをコミュニティインフラ上でついに公開できることに興奮しています。数年前からやりたいと思っていたことですが、移行する前に整えなければならない技術的な意味合いが多いプロジェクトです。それが終われば、生産性を向上させ、ワークフロー全体をコントロールできるようになります。

最後に

さて、この対談はここで終わりですが、学習はこれで終わりではありません。このインタビューが、SIG Releaseが何をしているのか、そしてどのように手助けを始めたらいいのか、ある程度わかっていただけたと思います。重要なこととして、この記事はSIG Releaseの最初のサブプロジェクトであるリリース・チームを取り上げています。次回のSIG Releaseのスポットライトブログでは、Release Engineeringサブプロジェクトにスポットライトを当て、その活動内容や参加方法について紹介します。最後に、SIG Releaseの運営方法についてより深く理解するために、SIG Release憲章をご覧ください。

フォレンジックコンテナ分析

By Adrian Reber (Red Hat) | 2023.03.10

前回投稿したKubernetesにおけるフォレンジックコンテナチェックポイント処理では、Kubernetesでのチェックポイントの作成や、それがどのようにセットアップされ、どのように使用されるのかを紹介しました。機能の名前はフォレンジックコンテナチェックポイントですが、Kubernetesによって作成されたチェックポイントの実際の分析方法については、詳細を説明しませんでした。この記事では、チェックポイントがどのように分析されるのかについての詳細を提供します。

チェックポイントの作成はまだKubernetesでalpha機能であり、この記事ではその機能が将来どのように動作するのかについてのプレビューを提供します。

準備

チェックポイント作成のサポートを有効にするためのKubernetesの設定方法や、基盤となるCRI実装方法についての詳細はKubernetesにおけるフォレンジックコンテナチェックポイント処理を参照してください。

一例として、この記事内でチェックポイントを作成し分析するコンテナイメージ(quay.io/adrianreber/counter:blog)を準備しました。このコンテナはコンテナ内でファイルを作成することができ、後でチェックポイント内で探したい情報をメモリーに格納しておくこともできます。

コンテナを実行するためにはPodが必要であり、この例では下記のPodマニフェストを使用します。

apiVersion: v1
kind: Pod
metadata:
  name: counters
spec:
  containers:
  - name: counter
    image: quay.io/adrianreber/counter:blog

この結果、counterと呼ばれるコンテナがcountersと呼ばれるPod内で実行されます。

一度コンテナが実行されると、コンテナで下記アクションが行えます。

$ kubectl get pod counters --template '{{.status.podIP}}'
10.88.0.25
$ curl 10.88.0.25:8088/create?test-file
$ curl 10.88.0.25:8088/secret?RANDOM_1432_KEY
$ curl 10.88.0.25:8088

最初のアクセスはコンテナ内でtest-fileという内容でtest-fileと呼ばれるファイルを作成します。次のアクセスで、コンテナのメモリー内のどこかにシークレット情報(RANDOM_1432_KEY)を記憶します。最後のアクセスは内部のログファイルに1行追加するだけです。

チェックポイントを分析する前の最後のステップは、チェックポイントを作成することをKubernetesに指示することです。前回の記事で説明したように、これにはkubelet限定のチェックポイントAPIエンドポイントへのアクセスを必要とします。

default名前空間内のcountersという名前のPod内のcounterという名前のコンテナに対して、kubelet APIエンドポイントが次の場所で到達可能です。

# Podが実行されているNode上で実行する
curl -X POST "https://localhost:10250/checkpoint/default/counters/counter"

厳密には、kubeletの自己署名証明書を許容しkubelet チェックポイントAPIの使用を認可するために、下記のcurlコマンドのオプションが必要です。

--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key

チェックポイントの作成が終了すると、/var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tarでチェックポイントが利用可能になります。

この記事の後述のステップでは、チェックポイントアーカイブを分析する際にcheckpoint.tarという名前を使用します。

`checkpointctl`を使用したチェックポイントアーカイブの分析

チェックポイントが作成したコンテナに関するいくつかの初期情報を得るためには、このようにcheckpointctlを使用します。

$ checkpointctl show checkpoint.tar --print-stats
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
| CONTAINER |              IMAGE               |      ID      | RUNTIME |       CREATED       | ENGINE |     IP     | CHKPT SIZE | ROOT FS DIFF SIZE |
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
| counter   | quay.io/adrianreber/counter:blog | 059a219a22e5 | runc    | 2023-03-02T06:06:49 | CRI-O  | 10.88.0.23 | 8.6 MiB    | 3.0 KiB           |
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
CRIU dump statistics
+---------------+-------------+--------------+---------------+---------------+---------------+
| FREEZING TIME | FROZEN TIME | MEMDUMP TIME | MEMWRITE TIME | PAGES SCANNED | PAGES WRITTEN |
+---------------+-------------+--------------+---------------+---------------+---------------+
| 100809 us     | 119627 us   | 11602 us     | 7379 us       |          7800 |          2198 |
+---------------+-------------+--------------+---------------+---------------+---------------+

これによって、チェックポイントアーカイブ内のチェックポイントについてのいくつかの情報が、すでに取得できています。コンテナの名前やコンテナランタイムやコンテナエンジンについての情報を見ることができます。チェックポイントのサイズ(CHKPT SIZE)もリスト化されます。これは大部分がチェックポイントに含まれるメモリーページのサイズですが、コンテナ内の全ての変更されたファイルのサイズ(ROOT FS DIFF SIZE)についての情報もあります。

追加のパラメーター--print-statsはチェックポイントアーカイブ内の情報を復号化し、2番目のテーブル(CRIU dump statistics)で表示します。この情報はチェックポイント作成中に収集され、CRIUがコンテナ内のプロセスをチェックポイントするために必要な時間と、チェックポイント作成中に分析され書き込まれたメモリーページ数の概要を示します。

より深く掘り下げる

checkpointctlの助けを借りて、チェックポイントアーカイブについてのハイレベルな情報を得ることができます。チェックポイントアーカイブをさらに分析するには、それを展開する必要があります。チェックポイントアーカイブはtarアーカイブであり、tar xf checkpoint.tarの助けを借りて展開可能です。

チェックポイントアーカイブを展開すると、下記のファイルやディレクトリが作成されます。

bind.mounts - このファイルにはバインドマウントについての情報が含まれており、復元中に全ての外部ファイルとディレクトリを正しい場所にマウントするために必要になります。
checkpoint/ - このディレクトリにはCRIUによって作成された実際のチェックポイントが含まれています。
config.dumpとspec.dump - これらのファイルには、復元中に必要とされるコンテナについてのメタデータが含まれています。
dump.log - このファイルにはチェックポイント作成中に作成されたCRIUのデバッグ出力が含まれています。
stats-dump - このファイルには、checkpointctlが--print-statsでダンプ統計情報を表示するために使用するデータが含まれています。
rootfs-diff.tar - このファイルには、コンテナのファイルシステム上で変更された全てのファイルが含まれています。

ファイルシステムの変更 - `rootfs-diff.tar`

コンテナのチェックポイントをさらに分析するための最初のステップは、コンテナ内で変更されたファイルを見ることです。これはrootfs-diff.tarファイルを参照することで行えます。

$ tar xvf rootfs-diff.tar
home/counter/logfile
home/counter/test-file

これでコンテナ内で変更されたファイルを調べられます。

$ cat home/counter/logfile
10.88.0.1 - - [02/Mar/2023 06:07:29] "GET /create?test-file HTTP/1.1" 200 -
10.88.0.1 - - [02/Mar/2023 06:07:40] "GET /secret?RANDOM_1432_KEY HTTP/1.1" 200 -
10.88.0.1 - - [02/Mar/2023 06:07:43] "GET / HTTP/1.1" 200 -
$ cat home/counter/test-file
test-file

このコンテナのベースになっているコンテナイメージ(quay.io/adrianreber/counter:blog)と比較すると、コンテナが提供するサービスへの全てのアクセス情報を含んだlogfileや予想通り作成されたtest-fileファイルを確認することができます。

rootfs-diff.tarの助けを借りることで、作成または変更された全てのファイルを、コンテナのベースイメージと比較して検査することが可能です。

チェックポイント処理したプロセスを分析する - `checkpoint/`

ディレクトリcheckpoint/はコンテナ内でプロセスをチェックポイントしている間にCRIUによって作成されたデータを含んでいます。ディレクトリcheckpoint/の内容は、CRIUの一部として配布されているCRITツールを使用して分析できるさまざまなイメージファイルで構成されています。

まず、コンテナの内部プロセスの概要を取得してみましょう。

$ crit show checkpoint/pstree.img | jq .entries[].pid
1
7
8

この出力はコンテナのPID名前空間の内部に3つのプロセス(PIDが1と7と8)があることを意味しています。

これはコンテナのPID名前空間の内部からの視界を表示しているだけです。復元中に正確にそれらのPIDが再作成されます。コンテナのPID名前空間の外部からPIDは復元後に変更されます。

次のステップは、それらの3つのプロセスについての追加情報を取得することです。

$ crit show checkpoint/core-1.img | jq .entries[0].tc.comm
"bash"
$ crit show checkpoint/core-7.img | jq .entries[0].tc.comm
"counter.py"
$ crit show checkpoint/core-8.img | jq .entries[0].tc.comm
"tee"

これは、コンテナ内の3つのプロセスがbashとcounter.py(Pythonインタプリター)とteeであることを意味しています。プロセスの親子関係についての詳細は、checkpoint/pstree.imgに分析するデータがさらにあります。

ここまでで収集した情報をまだ実行中のコンテナと比較してみましょう。

$ crictl inspect --output go-template --template "{{(index .info.pid)}}" 059a219a22e56
722520
$ ps auxf | grep -A 2 722520
fedora    722520  \_ bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile
fedora    722541      \_ /usr/bin/python3 /home/counter/counter.py
fedora    722542      \_ /usr/bin/coreutils --coreutils-prog-shebang=tee /usr/bin/tee /home/counter/logfile
$ cat /proc/722520/comm
bash
$ cat /proc/722541/comm
counter.py
$ cat /proc/722542/comm
tee

この出力では、まずコンテナ内の最初のプロセスのPIDを取得しています。そしてコンテナを実行しているシステム上で、そのPIDと子プロセスを探しています。 3つのプロセスが表示され、最初のものはコンテナPID名前空間の中でPID 1である"bash"です。次に/proc/<PID>/commを見ると、チェックポイントイメージと正確に同じ値を見つけることができます。

覚えておく重要なことは、チェックポイントはコンテナのPID名前空間内の視界が含まれていることです。なぜなら、これらの情報はプロセスを復元するために重要だからです。

critがコンテナについて教えてくれる最後の例は、UTS名前空間に関する情報です。

$ crit show checkpoint/utsns-12.img
{
    "magic": "UTSNS",
    "entries": [
        {
            "nodename": "counters",
            "domainname": "(none)"
        }
    ]
}

UTS名前空間内のホストネームがcountersであることを教えてくれます。

チェックポイント作成中に収集された各リソースCRIUについて、checkpoint/ディレクトリは対応するイメージファイルを含んでいます。このイメージファイルはcritを使用することで分析可能です。

メモリーページを見る

CRITを使用して復号化できるCRIUからの情報に加えて、CRIUがディスクに書き込んだ生のメモリーページを含んでいるファイルもあります。

$ ls  checkpoint/pages-*
checkpoint/pages-1.img  checkpoint/pages-2.img  checkpoint/pages-3.img

最初にコンテナを使用した際に、メモリー内のどこかにランダムキー(RANDOM_1432_KEY)を保存しました。見つけることができるかどうか見てみましょう。

$ grep -ao RANDOM_1432_KEY checkpoint/pages-*
checkpoint/pages-2.img:RANDOM_1432_KEY

そして実際に、私のデータがあります。この方法で、コンテナ内のプロセスの全てのメモリーページの内容を簡単に見ることができます。しかし、チェックポイントアーカイブにアクセスできるなら誰でも、コンテナのプロセスのメモリー内に保存された全ての情報にアクセスできることを覚えておくことも重要です。

さらなる分析のためにgdbを使用する

チェックポイントイメージを見るための他の方法はgdbです。 CRIUリポジトリは、チェックポイントをコアダンプファイルに変換するcoredumpスクリプトを含んでいます。

$ /home/criu/coredump/coredump-python3
$ ls -al core*
core.1  core.7  core.8

coredump-python3スクリプトを実行すると、チェックポイントイメージがコンテナ内の各プロセスに対し1つのコアダンプファイルに変換されます。 gdbを使用してプロセスの詳細を見ることもできます。

$ echo info registers | gdb --core checkpoint/core.1 -q

[New LWP 1]

Core was generated by `bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile'.

#0  0x00007fefba110198 in ?? ()
(gdb)
rax            0x3d                61
rbx            0x8                 8
rcx            0x7fefba11019a      140667595587994
rdx            0x0                 0
rsi            0x7fffed9c1110      140737179816208
rdi            0xffffffff          4294967295
rbp            0x1                 0x1
rsp            0x7fffed9c10e8      0x7fffed9c10e8
r8             0x1                 1
r9             0x0                 0
r10            0x0                 0
r11            0x246               582
r12            0x0                 0
r13            0x7fffed9c1170      140737179816304
r14            0x0                 0
r15            0x0                 0
rip            0x7fefba110198      0x7fefba110198
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

この例では、チェックポイント中の全てのレジストリの値を見ることができ、コンテナのPID 1のプロセスの完全なコマンドライン(bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile)を見ることもできます。

まとめ

コンテナチェックポイントを作成することで、コンテナを停止することやチェックポイントが作成されたことを知ることなく、実行中のコンテナのチェックポイントを作成することが可能です。 Kubernetesにおいてコンテナのチェックポイントを作成した結果がチェックポイントアーカイブです。 checkpointctlやtar、crit、gdbのような異なるツールを使用して、チェックポイントを分析できます。 grepのようなシンプルなツールでさえ、チェックポイントアーカイブ内の情報を見つけることが可能です。

この記事で示したチェックポイントの分析方法のさまざまな例は出発点にすぎません。この記事ではチェックポイントの分析を始める方法を紹介しましたが、要件によってはかなり詳細に特定の物事を見ることも可能です。

参加するためにはどうすればよいですか？

SIG Nodeにはいくつかの方法でアクセスできます。

Kubernetes 1.26: PodDisruptionBudgetによって保護された不健全なPodに対する退避ポリシー

By Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple) | 2023.01.06

アプリケーションの中断がその可用性に影響を与えないようにすることは、簡単な作業ではありません。先月リリースされたKubernetes v1.26では、PodDisruptionBudget (PDB) に 不健全なPodの退避ポリシー を指定して、ノード管理操作中に可用性を維持できるようになりました。この記事では、アプリケーション所有者が中断をより柔軟に管理できるようにするために、PDBにどのような変更が導入されたのかを詳しく説明します。

これはどのような問題を解決しますか？

APIによって開始されるPodの退避では、PodDisruptionBudget(PDB)が考慮されます。これは、退避によるPodへの自発的な中断の要求は保護されたアプリケーションを中断してはならず、 PDBの.status.currentHealthyが.status.desiredHealthyを下回ってはいけないことを意味します。 Unhealthyな実行中のPodはPDBステータスにはカウントされませんが、これらの退避はアプリケーションが中断されない場合にのみ可能です。これにより、中断されたアプリケーションやまだ開始されていないアプリケーションが、退避によって追加のダウンタイムが発生することなく、できるだけ早く可用性を達成できるようになります。

残念ながら、これは手動の介入なしでノードをドレインしたいクラスター管理者にとって問題を引き起こします。 (バグまたは構成ミスにより)PodがCrashLoopBackOff状態になっているアプリケーション、または単に準備ができていないPodがあるアプリケーションが誤動作している場合、このタスクはさらに困難になります。アプリケーションのすべてのPodが正常でない場合、PDBの違反により退避リクエストは失敗します。その場合、ノードのドレインは進行できません。

一方で、次の目的で従来の動作に依存するユーザーもいます。

基盤となるリソースまたはストレージを保護しているPodの削除によって引き起こされるデータ損失を防止する
アプリケーションに対して可能な限り最高の可用性を実現する

Kubernetes 1.26では、PodDisruptionBudget APIに新しい実験的フィールド.spec.unhealthyPodEvictionPolicyが導入されました。このフィールドを有効にすると、これらの要件の両方をサポートできるようになります。

どのように機能しますか？

APIによって開始される退避は、Podの安全な終了をトリガーするプロセスです。このプロセスは、APIを直接呼び出すか、kubectl drainコマンドを使用するか、クラスター内の他のアクターを使用して開始できます。このプロセス中に、十分な数のPodが常にクラスター内で実行されていることを確認するために、すべてのPodの削除が適切なPDBと照合されます。

次のポリシーにより、PDBの作成者は、プロセスが不健全なPodを処理する方法をより詳細に制御できるようになります。

IfHealthyBudgetとAlwaysAllowの2つのポリシーから選択できます。

前者のIfHealthyBudgetは、従来の動作に従って、デフォルトで得られる最高の可用性を実現します。不健全なPodは、アプリケーションが利用可能な最小数の.status.desiredHealthyだけPodがある場合にのみ中断できます。

PDBのspec.unhealthyPodEvictionPolicyフィールドをAlwaysAllowに設定することにより、アプリケーションにとってベストエフォートの可用性を選択することになります。このポリシーを使用すると、不健全なPodをいつでも削除できます。これにより、クラスターの保守とアップグレードが容易になります。

多くの場合、AlwaysAllowがより良い選択であると考えられますが、一部の重要なワークロードでは、不健全なPodであってもノードドレインやAPIによって開始される他の形式の退避から保護する方が望ましい場合もあります。

どのように利用できますか？

これはアルファ機能であるため、kube-apiserverに対してコマンドライン引数--feature-gates=PDBUnhealthyPodEvictionPolicy=trueを指定して PDBUnhealthyPodEvictionPolicyフィーチャーゲートを有効にする必要があります。

ここに例を示します。クラスターでフィーチャーゲートを有効にし、プレーンなWebサーバーを実行するDeploymentをすでに定義していると仮定します。そのDeploymentのPodにapp: nginxというラベルを付けました。回避可能な中断を制限したいと考えており、このアプリにはベストエフォートの可用性で十分であることがわかっています。 WebサーバーのPodが不健全な場合でも、退避を許可することにしました。不健全なPodを排除するためのAlwaysAllowポリシーを使用して、このアプリケーションを保護するPDBを作成します。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  selector:
    matchLabels:
      app: nginx
  maxUnavailable: 1
  unhealthyPodEvictionPolicy: AlwaysAllow

もっと学ぶには？

KEPを読んでください: Unhealthy Pod Eviction Policy for PDBs
PodDisruptionBudgetについてのドキュメントを読んでください: Unhealthy Pod Eviction Policy
PodDisruptionBudget、draining of NodesおよびevictionsについてKubernetesドキュメントを確認してください

どうすれば参加できますか？

フィードバックがある場合は、Slackの#sig-apps チャンネル(必要な場合は https://slack.k8s.io/ にアクセスして招待を受けてください)、またはSIG Appsメーリングリストにご連絡ください。kubernetes-sig-apps@googlegroups.com

Kubernetesにおけるフォレンジックコンテナチェックポイント処理

By Adrian Reber (Red Hat) | 2022.12.05

フォレンジックコンテナチェックポイント処理はCheckpoint/Restore In Userspace (CRIU)に基づいており、コンテナがチェックポイントされていることを認識することなく、実行中のコンテナのステートフルコピーを作成することができます。コンテナのコピーは、元のコンテナに気づかれることなく、サンドボックス環境で複数回の分析やリストアが可能です。フォレンジックコンテナチェックポイント処理はKubernetes v1.25でalpha機能として導入されました。

どのように機能しますか？

CRIUを使用してコンテナのチェックポイントやリストアを行うことが可能です。 CRIUはruncやcrun、CRI-O、containerdと統合されており、Kubernetesで実装されているフォレンジックコンテナチェックポイント処理は、既存のCRIU統合を使用します。

なぜ重要なのか？

CRIUと対応する統合機能を使用することで、後でフォレンジック分析を行うために、ディスク上で実行中のコンテナに関する全ての情報と状態を取得することが可能です。フォレンジック分析は、疑わしいコンテナを停止したり影響を与えることなく検査するために重要となる場合があります。コンテナが本当に攻撃を受けている場合、攻撃者はコンテナを検査する処理を検知するかもしれません。チェックポイントを取得しサンドボックス環境でコンテナを分析することは、元のコンテナや、おそらく攻撃者にも検査を認識されることなく、コンテナを検査することができる可能性があります。

フォレンジックコンテナチェックポイント処理のユースケースに加えて、内部状態を失うことなく、あるノードから他のノードにコンテナを移行することも可能です。特に初期化時間の長いステートフルコンテナの場合、チェックポイントからリストアすることは再起動後の時間が節約されるか、起動時間がより早くなる可能性があります。

コンテナチェックポイント処理を利用するには？

機能はフィーチャーゲートで制限されているため、新しい機能を使用する前にContainerCheckpointを有効にしてください。

ランタイムがコンテナチェックポイント処理をサポートしている必要もあります。

containerd: サポートは現在検討中です。詳細はcontainerdプルリクエスト#6965を見てください。
CRI-O: v1.25はフォレンジックコンテナチェックポイント処理をサポートしています。

CRI-Oでの使用例

CRI-Oとの組み合わせでフォレンジックコンテナチェックポイント処理を使用するためには、ランタイムをコマンドラインオプション--enable-criu-support=trueで起動する必要があります。 Kubernetesでは、ContainerCheckpointフィーチャーゲートを有効にしたクラスターを実行する必要があります。チェックポイント処理の機能はCRIUによって提供されているため、CRIUをインストールすることも必要となります。通常、runcやcrunはCRIUに依存しているため、自動的にインストールされます。

執筆時点ではチェックポイント機能はCRI-OやKubernetesにおいてalpha機能としてみなされており、セキュリティ影響がまだ検討中であることに言及することも重要です。

コンテナとPodが実行されると、チェックポイントを作成することが可能になります。チェックポイント処理はkubeletレベルでのみ公開されています。コンテナをチェックポイントするためには、コンテナが実行されているノード上でcurlを実行し、チェックポイントをトリガーします。

curl -X POST "https://localhost:10250/checkpoint/namespace/podId/container"

default名前空間内のcountersと呼ばれるPod内のcounterと呼ばれるコンテナに対し、kubelet APIエンドポイントが次の場所で到達可能です。

curl -X POST "https://localhost:10250/checkpoint/default/counters/counter"

厳密には、kubeletの自己署名証明書を許容し、kubeletチェックポイントAPIの使用を認可するために、下記のcurlコマンドのオプションが必要です。

--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key

このkubelet APIが実行されると、CRI-Oからチェックポイントの作成をリクエストします。 CRI-Oは低レベルランタイム(例えばrunc)からチェックポイントをリクエストします。そのリクエストを確認すると、runcは実際のチェックポイントを行うためにcriuツールを呼び出します。

チェックポイント処理が終了すると、チェックポイントは/var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tarで利用可能になります。

その後、そのtarアーカイブを使用してコンテナを別の場所にリストアできます。

Kubernetesの外部でチェックポイントしたコンテナをリストアする(CRI-Oを使用)

チェックポイントtarアーカイブを使用すると、CRI-Oのサンドボックスインスタンス内のKubernetesの外部にコンテナをリストア可能です。リストア中のより良いユーザエクスペリエンスのために、main CRI-O GitHubブランチからCRI-Oのlatestバージョンを使用することを推奨します。 CRI-O v1.25を使用している場合、コンテナを開始する前にKubernetesが作成する特定のディレクトリを手動で作成する必要があります。

Kubernetesの外部にコンテナをリストアするための最初のステップは、crictlを使用してPodサンドボックスを作成することです。

crictl runp pod-config.json

次に、さきほどチェックポイントしたコンテナを新しく作成したPodサンドボックスにリストアします。

crictl create <POD_ID> container-config.json pod-config.json

container-config.jsonのレジストリでコンテナイメージを指定する代わりに、前に作成したチェックポイントアーカイブへのパスを指定する必要があります。

{
  "metadata": {
      "name": "counter"
  },
  "image":{
      "image": "/var/lib/kubelet/checkpoints/<checkpoint-archive>.tar"
  }
}

次に、そのコンテナを開始するためにcrictl start <CONTAINER_ID>を実行すると、さきほどチェックポイントしたコンテナのコピーが実行されているはずです。

Kubernetes内でチェックポイントしたコンテナをリストアする

先ほどチェックポイントしたコンテナをKubernetes内で直接リストアするためには、レジストリにプッシュできるイメージにチェックポイントアーカイブを変換する必要があります。

ローカルのチェックポイントアーカイブを変換するための方法として、buildahを使用した下記のステップが考えられます。

newcontainer=$(buildah from scratch)
buildah add $newcontainer /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar /
buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=<container-name> $newcontainer
buildah commit $newcontainer checkpoint-image:latest
buildah rm $newcontainer

出来上がったイメージは標準化されておらず、CRI-Oとの組み合わせでのみ動作します。このイメージはalphaにも満たないフォーマットであると考えてください。このようなチェックポイントイメージのフォーマットを標準化するための議論が進行中です。これはまだ標準化されたイメージフォーマットではなく、CRI-Oを--enable-criu-support=trueで起動した場合のみ動作することを忘れないでください。 CRIUサポートでCRI-Oを起動することのセキュリティ影響はまだ明確ではなく、そのため、イメージフォーマットだけでなく機能も気を付けて使用するべきです。

さて、そのイメージをコンテナイメージレジストリにプッシュする必要があります。例えば以下のような感じです。

buildah push localhost/checkpoint-image:latest container-image-registry.example/user/checkpoint-image:latest

このチェックポイントイメージ(container-image-registry.example/user/checkpoint-image:latest)をリストアするために、イメージはPodの仕様(Specification)に記載する必要があります。以下はマニフェストの例です。

apiVersion: v1
kind: Pod
metadata:
  namePrefix: example-
spec:
  containers:
  - name: <container-name>
    image: container-image-registry.example/user/checkpoint-image:latest
  nodeName: <destination-node>

Kubernetesは新しいPodをノード上にスケジュールします。そのノード上のKubeletは、registry/user/checkpoint-image:latestとして指定されたイメージをもとに、コンテナを作成し開始するようにコンテナランタイム(この例ではCRI-O)に指示をします。 CRI-Oはregistry/user/checkpoint-image:latestがコンテナイメージでなく、チェックポイントデータへの参照であることを検知します。その時、コンテナを作成し開始する通常のステップの代わりに、CRI-Oはチェックポイントデータをフェッチし、指定されたチェックポイントからコンテナをリストアします。

Pod内のアプリケーションはチェックポイントを取得しなかったかのように実行し続けます。コンテナ内では、アプリケーションはチェックポイントからリストアされず通常起動したコンテナのような見た目や動作をします。

これらのステップで、あるノードで動作しているPodを、別のノードで動作している新しい同等のPodに置き換えることができ、そのPod内のコンテナの状態を失うことはないです。

どのように参加すればよいですか？

SIG Nodeにはいくつかの手段でアクセスすることができます。

Slack: #sig-node
メーリングリスト

さらなる読み物

コンテナチェックポイントの分析方法に関する詳細は後続のブログForensic container analysisを参照してください。

更新: dockershimの削除に関するFAQ

2022.02.17

この記事は2020年の後半に投稿されたオリジナルの記事Dockershim Deprecation FAQの更新版です。この記事にはv1.24のリリースに関する更新を含みます。

この文書では、Kubernetesからの dockershim の削除に関するよくある質問について説明します。この削除はKubernetes v1.20リリースの一部としてはじめて発表されたものです。 Kubernetes v1.24のリリースにおいてdockershimは実際にKubernetesから削除されました。

これが何を意味するかについては、ブログ記事Don't Panic: Kubernetes and Dockerをご覧ください。

dockershim削除の影響範囲を確認するをお読みいただくことで、 dockershimの削除があなたやあなたの組織に与える影響をご判断いただけます。

Kubernetes 1.24リリースに至るまでの間、Kubernetesコントリビューターはこの移行を円滑に行えるようにするために尽力してきました。

私たちのコミットメントと次のステップを詳述したブログ記事。
他のコンテナランタイムへの移行に大きな障害があるかどうかのチェック。
dockershimからの移行ガイドの追加。
dockershimの削除とCRI互換ランタイムの使用に関する記事一覧の作成。このリストには、上に示した文書の一部が含まれており、また、厳選された外部の情報(ベンダーによるガイドを含む)もカバーしています。

dockershimはなぜKubernetesから削除されたのですか？

Kubernetesの初期のバージョンは、特定のコンテナランタイム上でのみ動作しました。 Docker Engineです。その後、Kubernetesは他のコンテナランタイムと連携するためのサポートを追加しました。オーケストレーター(Kubernetesなど)と多くの異なるコンテナランタイムの間の相互運用を可能にするため、 CRI標準が作成されました。 Docker Engineはそのインターフェース(CRI)を実装していないため、Kubernetesプロジェクトは移行を支援する特別なコードを作成し、その dockershim コードをKubernetes自身の一部としました。

dockershimコードは常に一時的な解決策であることを意図されていました(このためshimと名付けられています)。コミュニティでの議論や計画については、dockershimの削除によるKubernetes改良の提案にてお読みいただけます。

実際、dockershimのメンテナンスはKubernetesメンテナーにとって大きな負担になっていました。

さらに、dockershimとほとんど互換性のなかった機能、たとえばcgroups v2やユーザーネームスペースなどが、これらの新しいCRIランタイムに実装されています。Kubernetesからdockershimを削除することで、これらの分野でのさらなる開発が可能になります。

Dockerとコンテナは同じものですか？

DockerはLinuxのコンテナパターンを普及させ、その基盤技術の発展に寄与してきましたが、 Linuxのコンテナ技術そのものはかなり以前から存在しています。また、コンテナエコシステムはDockerを超えてより広範に発展してきました。 OCIやCRIのような標準は、Dockerの機能の一部を置き換えたり、既存の機能を強化したりすることで、私達のエコシステムの多くのツールの成長と繁栄を助けてきました。

既存のコンテナイメージは引き続き使えるのですか？

はい、docker buildから生成されるイメージは、全てのCRI実装で動作します。既存のイメージも全く同じように動作します。

プライベートイメージについてはどうでしょうか？

はい、すべてのCRIランタイムはKubernetesで使われているものと同一のpull secretsをサポートしており、 PodSpecまたはService Accountを通して利用できます。

Kubernetes 1.23でDocker Engineを引き続き使用できますか？

はい、1.20で変更されたのは、Docker Engineランタイムを使用している場合に警告ログがkubelet起動時に出るようになったことだけです。この警告は、1.23までのすべてのバージョンで表示されます。 dockershimの削除はKubernetes 1.24で行われました。

Kubernetes v1.24以降を実行している場合は、Docker Engineを引き続きコンテナランタイムとして利用できますか？をご覧ください。 (CRIがサポートされているKubernetesリリースを使用している場合、dockershimから切り替えることができることを忘れないでください。リリースv1.24からはKubernetesにdockershimが含まれなくなったため、必ず切り替えなければなりません)。

どのCRIの実装を使うべきでしょうか？

これは難しい質問で、様々な要素に依存します。もしDocker Engineがうまく動いているのであれば、containerdに移行するのは比較的簡単で、性能もオーバーヘッドも確実に改善されるでしょう。しかし、他の選択のほうがあなたの環境により適合する場合もありますので、 CNCF landscapeにあるすべての選択肢を検討されることをおすすめします。

Docker Engineを引き続きコンテナランタイムとして利用できますか？

第一に、ご自身のPCで開発やテスト用途でDockerを使用している場合、何も変わることはありません。 Kubernetesでどのコンテナランタイムを使っていても、Dockerをローカルで使い続けることができます。コンテナではこのような相互運用性を実現できます。

MirantisとDockerは、Kubernetesから内蔵のdockershimが削除された後も、 Docker Engineの代替アダプターを維持することにコミットしています。代替アダプターの名前はcri-dockerdです。

cri-dockerdをインストールして、kubeletをDocker Engineに接続するために使用することができます。詳細については、Migrate Docker Engine nodes from dockershim to cri-dockerdを読んでください。

今現在でプロダクション環境に他のランタイムを使用している例はあるのでしょうか？

Kubernetesプロジェクトが生み出したすべての成果物(Kubernetesバイナリ)は、リリースごとに検証されています。

また、kindプロジェクトは以前からcontainerdを使っており、プロジェクトのユースケースにおいて安定性が向上してきています。 kindとcontainerdは、Kubernetesコードベースの変更を検証するために毎日何回も利用されています。他の関連プロジェクトも同様のパターンを追っており、他のコンテナランタイムの安定性と使いやすさが示されています。例として、OpenShift 4.xは2019年6月以降、CRI-Oランタイムをプロダクション環境で使っています。

他の事例や参考資料はについては、 containerdとCRI-O(Cloud Native Computing Foundation (CNCF)の2つのコンテナランタイム)の採用例をご覧ください。

OCIという単語をよく見るのですが、これは何ですか？

OCIはOpen Container Initiativeの略で、コンテナツールとテクノロジー間の数多くのインターフェースの標準化を行った団体です。彼らはコンテナイメージをパッケージするための標準仕様(OCI image-spec)と、コンテナを実行するための標準仕様(OCI runtime-spec)をメンテナンスしています。また、runcという形でruntime-specの実装もメンテナンスしており、これはcontainerdとCRI-Oの両方でデフォルトの下位ランタイムとなっています。 CRIはこれらの低レベル仕様に基づいて、コンテナを管理するためのエンドツーエンドの標準を提供します。

CRI実装を変更する際に注意すべきことは何ですか？

DockerとほとんどのCRI(containerdを含む)において、下位で使用されるコンテナ化コードは同じものですが、いくつかの細かい違いが存在します。移行する際に考慮すべき一般的な事項は次のとおりです。

ログ設定
ランタイムリソースの制限
ノード構成スクリプトでdockerコマンドやコントロールソケット経由でDocker Engineを使用しているもの
kubectlのプラグインでdocker CLIまたはDocker Engineコントロールソケットが必要なもの
KubernetesプロジェクトのツールでDocker Engineへの直接アクセスが必要なもの(例:廃止されたkube-imagepullerツール)
registry-mirrorsやinsecureレジストリなどの機能の設定
その他の支援スクリプトやデーモンでDocker Engineが利用可能であることを想定していてKubernetes外で実行されるもの(モニタリング・セキュリティエージェントなど)
GPUまたは特別なハードウェア、そしてランタイムおよびKubernetesとそれらハードウェアの統合方法

あなたがKubernetesのリソース要求/制限やファイルベースのログ収集DaemonSetを使用しているのであれば、それらは問題なく動作し続けますが、 dockerdの設定をカスタマイズしていた場合は、それを新しいコンテナランタイムに適合させる必要があるでしょう。

他に注意することとしては、システムメンテナンスを実行するようなものや、コンテナ内でイメージをビルドするようなものが動作しなくなります。前者の場合は、crictlツールをdrop-inの置き換えとして使用できます(docker cliからcrictlへのマッピングを参照)。後者の場合は、img、buildah、kaniko、buildkit-cli-for-kubectlのようなDockerを必要としない新しいコンテナビルドの選択肢を使用できます。

containerdを使っているのであれば、ドキュメントを参照して、移行するのにどのような構成が利用可能かを確認するところから始めるといいでしょう。

containerdとCRI-OをKubernetesで使用する方法に関しては、コンテナランタイムに関するKubernetesのドキュメントを参照してください。

さらに質問がある場合どうすればいいでしょうか？

ベンダーサポートのKubernetesディストリビューションを使用している場合、彼らの製品に対するアップグレード計画について尋ねることができます。エンドユーザーの質問に関しては、エンドユーザーコミュニティフォーラムに投稿してください。

dockershimの削除に関する決定については、専用のGitHub issueで議論することができます。

変更点に関するより詳細な技術的な議論は、待ってください、DockerはKubernetesで非推奨になったのですか？という素晴らしいブログ記事も参照してください。

dockershimを使っているかどうかを検出できるツールはありますか？

はい！Detector for Docker Socket (DDS)というkubectlプラグインをインストールすることであなたのクラスターを確認していただけます。 DDSは、アクティブなKubernetesワークロードがDocker Engineソケット(docker.sock)をボリュームとしてマウントしているかを検出できます。さらなる詳細と使用パターンについては、DDSプロジェクトのREADMEを参照してください。

ハグしていただけますか？

はい、私達は引き続きいつでもハグに応じています。🤗🤗🤗

Don't Panic: Kubernetes and Docker

By Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan "POP" Papandrea, Jeffrey Sica, Davanum "Dims" Srinivas | 2020.12.02

Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとしてDockerをサポートしません。

パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。

概要: ランタイムとしてのDockerは、Kubernetesのために開発されたContainer Runtime Interface(CRI)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。

もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスター上でこれからも動作可能なのです。

もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトでcontainerdを使用しています)を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。

もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど)

では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。

ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。

お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。このhuman-friendlyな抽象化レイヤーが作られたために、結果としてはKubernetesクラスターはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。

DockerはCRI(Container Runtime Interface)に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。しかし、これは世界の終わりでありません、心配しないでください。みなさんはContainer runtimeをDockerから他のサポート対象であるContainer runtimeに切り替えるだけでよいのです。

1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(/var/run/docker.sock)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。kaniko、img、buildahなどです。

では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。

この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI(Open Container Initiative) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。containerdもCRI-Oも、そのようなImageをPullし、起動することが出来ます。これがコンテナの仕様について、共通の仕様を策定している理由なのです。

さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。もし、この問題がまだわかりにくいとしても、心配しないでください。Kubernetesでは多くのものが変化しており、その全てに完璧に精通している人など存在しません。経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。

別の情報をお探しであれば、dockershimの削除に関するFAQを参照してください。

Kubernetesブログ

Kubernetes v1.33: 思い描いていたとおりに動作するようになったImage Pull Policy！

思い描いていたとおりに動作するようになったImage Pull Policy！

備考:

IfNotPresent、たとえ本来持つべきでないとしても

IfNotPresent、ただし本来アクセス権がある場合に限る

Never pull、ただし認証されている場合に限る

Always pull、ただし認証されている場合に限る

仕組みについて

試してみよう

今後の予定

参加するには

Kubernetes v1.33: HorizontalPodAutoscalerの設定可能な許容値

これは何ですか？

どうやって使うのか？

すべての詳細を知りたい！

Kubernetes v1.33: Octarine

リリースのテーマとロゴ

主なアップデート情報

GA: サイドカーコンテナ

ベータ: Podの垂直スケーリングのためのインプレースなリソースリサイズ

アルファ: .kubercによるkubectl向けユーザー設定の新しい記述オプション

GAに昇格した機能

インデックス付きJobのインデックスごとのバックオフ制限

Job成功ポリシー

バインドされたServiceAccountトークンのセキュリティ改善

kubectlでのサブリソースサポート

複数のサービスCIDR

kube-proxyのnftablesバックエンド

trafficDistribution: PreferCloseによるTopology Aware Routing

SMT非対応ワークロードを拒否するオプション

matchLabelKeysとmismatchLabelKeysを使用したPodアフィニティまたはアンチアフィニティの定義

Podトポロジー分散制約スキューの計算時にtaintとtolerationを考慮する

Volume Populators

PersistentVolumeの再利用ポリシーを常に尊重する

ベータの新機能

Windowsのkube-proxyにおけるDirect Service Return (DSR)のサポート

構造化パラメーターのサポート

ネットワークインターフェース向けDynamic Resource Allocation(DRA)

スケジューラーがactiveQにPodを持たない場合に、スケジュールされていないPodを早期に処理

Kubernetesスケジューラーにおける非同期プリエンプション

ClusterTrustBundle

きめ細かいSupplementalGroupsの制御

イメージをボリュームとしてマウントする機能をサポート

Linux Podにおけるユーザー名前空間のサポート

PodのprocMountオプション

NUMAノード間でCPUを分散させるCPUManagerポリシー

コンテナのPreStopフックのゼロ秒スリープ

Kubernetesネイティブ型の宣言的検証のための内部ツール

アルファの新機能

HorizontalPodAutoscalerの設定可能な許容値

設定可能なコンテナの再起動遅延

カスタムコンテナの停止シグナル

豊富なDRA機能強化

IfNotPresentとNeverのイメージに対する認証を行う堅牢なimagePullPolicy

Downward APIを通じて利用可能なノードトポロジーラベル

生成番号と観測された生成番号によるより良いPodステータス

kubeletのCPU Managerによる分割レベル3キャッシュアーキテクチャのサポート

スケジューリング改善のためのPSI(Pressure Stall Information)メトリクス

kubeletによるシークレットレスイメージPull

v1.33での昇格、非推奨化、および削除

GAへの昇格

非推奨化と削除

Endpoints APIの非推奨化

Nodeステータスにおけるkube-proxyバージョン情報の削除

インツリーのgitRepoボリュームドライバーの削除

Windows Podにおけるホストネットワークサポートの削除

リリースノート

入手方法

リリースチーム

プロジェクトの活動状況

イベント情報

ウェビナーのご案内

参加方法

kube-scheduler-simulatorの紹介

動機

kube-scheduler-simulatorの機能

シミュレーターのwebフロントエンド

より優れた開発クラスターとしてのシミュレーター

ユースケースは？

アルファ: `.kuberc`によるkubectl向けユーザー設定の新しい記述オプション

kube-proxyの`nftables`バックエンド

`trafficDistribution: PreferClose`によるTopology Aware Routing

`matchLabelKeys`と`mismatchLabelKeys`を使用したPodアフィニティまたはアンチアフィニティの定義

スケジューラーが`activeQ`にPodを持たない場合に、スケジュールされていないPodを早期に処理

Podの`procMount`オプション

`IfNotPresent`と`Never`のイメージに対する認証を行う堅牢なimagePullPolicy

動機: コンテナイメージ内の`/etc/group`に定義される暗黙的なグループ情報

PodにおけるFine-grained(きめ細かい) SupplementalGroups control: `SupplementaryGroupsPolicy`