$30 off During Our Annual Pro Sale. View Details »

個人的、Kubernetes の最新注目機能! (2024年5月版) / TechFeed E...

個人的、Kubernetes の最新注目機能! (2024年5月版) / TechFeed Experts Night#28 〜 コンテナ技術最前線

2024年4月にリリースされた最新の Kubernetes v1.30 や直近実装される機能のなかで私が注目するものを紹介します。

イベントサイト: https://techfeed.io/events/techfeed-experts-night-28

Preferred Networks

May 08, 2024
Tweet

More Decks by Preferred Networks

Other Decks in Technology

Transcript

  1. TechFeed Experts Night#28 〜 コンテナ技術最前線 (2024/05/08) SUDA Kazuki, Preferred Networks,

    Inc. (@superbrothers) 個⼈的、 Kubernetes の最新注⽬機能! 2024年5月版!
  2. @superbrothers  SUDA Kazuki / @superbrothers ▶ Preferred Networks, Inc.

    / エンジニア ▶ Scalar, Inc. / 技術アドバイザ ▶ Kubernetes Meetup Tokyo, K8s@home 共同主催者 ▶ オライリー「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 ▶ stern ツールメンテナ(https://github.com/stern/stern) 2 社内向けの機械学習プラットフォームと
 社外向けのクラウドサービスの開発・運用をやってます!
  3. @superbrothers  KEP-4006: Transition from SPDY to WebSockets (1/2) ベータターゲット:

    v1.30, GA ターゲット: v1.31 ▶ kubectl exec/attach/port-forward の通信プロトコルの SPDY/3.1 からWebSockets への移⾏ ▶ 多くの L7 プロキシが SPDY をサポートしていないことが⻑年の課題だった 3 例えば AWS ALB は SPDY をサポートしていません。なお、L4 なら無問題です。 L7 プロキシを使用する理由として、 API サーバ認証機能の脆弱性対策としてその前段でトークンを検証しておきたいなどのニーズがある API サーバ Kubelet SPDY クライアント WebSockets kubectl exec kubectl attach kubectl port-forward API サーバ Kubelet SPDY クライアント SPDY kubectl exec kubectl attach kubectl port-forward
  4. @superbrothers  KEP-4006: Transition from SPDY to WebSockets (2/2) ベータターゲット:

    v1.30, GA ターゲット: v1.31 4 API サーバ Kubelet SPDY クライアント SPDY コンテナランタイム (CRI) SPDY Node UNIX 
 ドメインソケット API サーバ Kubelet WebSockets クライアント WebSockets コンテナランタイム (CRI) WebSockets Node UNIX 
 ドメインソケット 最終的には SPDY の完全な廃止が目標だが、
 各コンテナランタイムでの対応が必要になるので達成には時間がかかる見込み
  5. @superbrothers  KEP-3331: Structured Authentication Con fi g ベータターゲット: v1.30,

    GA ターゲット: v1.34 1. 複数 OIDC プロバイダ + 多重化をサポートするプロバイダが必要だった + Dex など 2. 動的な設定 + API サーバの再起動なしに設定を反映 3. JWT クレームの検証 (CEL) + 特定のグループに属していないと認証に失敗させる 4. 任意のクレームのユーザ属性へのマッピング + ユーザ名への任意のプレフィックス付与 5. 複数 audiences サポート + kubectl とダッシュボードで使い分ける 5 apiVersion: apiserver.config.k8s.io/v1beta1 kind: AuthenticationConfiguration jwt: - issuer: url: https://issuer.example.com audiences: - example-client-id claimMappings: username: claim: username prefix: "oidc:" groups: claim: groups prefix: "oidc:" claimValidationRules: - claim: hd requiredValue: "example.com" - claim: admin requiredValue: "true" ユーザとクラスタ管理者で OIDC プロバイダを使い分ける等ができるようになる! 任意の prefix も
 付けられてべんり ルールに違反する場合認証失敗にできる
  6. @superbrothers  KEP-127: Support User Namespaces ベータターゲット: v1.30, GA ターゲット:

    N/A ▶ Pod 内の root をノード内の⾮特権ユーザにマッピングすることでノードと Pod の分離を⾼める ▶ Pod でのみ有効な (ホストでは無効な) Capabilities を安全に付与できる + 例えば FUSE ファイルシステムのマウントには CAP_SYS_ADMIN が必要 ▶ 将来的な未知のランタイムやカーネルの脆弱性に対するセキュリティ強化の恩恵を受けられる 6 apt コマンドの使用を許可したいだけなのに!にも応える! Linux カーネル 6.3 以上とコンテナランタイムのサポートが必要です! (Ubuntu 24,04) (containerd 2.0, CRI-O 1.30) Kubernetes 1.30: Beta Support For Pods With User Namespaces | Kubernetes どの範囲を使うか設定できます! apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: hostUsers: false containers: - name: myapp image: myapp command: ['do something']
  7. @superbrothers  KEP-3962: Mutating Admission Policies アルファターゲット: v1.31 CEL を使ったリソースの

    Mutating ▶ Admission Webhook はパフォーマンスが悪く、サーバ運⽤も 必要で管理者の負荷が⾼い ▶ Webhook サーバとして実装しなくて済むので 
 煩わしいコンテナイメージのビルド、リリースが必要なくなる 7 ちなみに Validating Admission Policy は V1.30 で GA しました 🎉 apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: "sidecar-policy.example.com" spec: paramKind: group: mutations.example.com kind: Sidecar version: v1 matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] matchConditions: - name: does-not-already-have-sidecar expression: "!object.spec.initContainers.exists(ic, ic.name == params.name)" failurePolicy: Fail reinvocationPolicy: IfNeeded mutations: - patchType: "ApplyConfiguration" mutation: > Object{ spec: Object.spec{ initContainers: [ Object.spec.initContainers{ name: params.name, image: params.image, args: params.args, restartPolicy: params.restartPolicy } ] } } apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicyBinding metadata: name: "sidecar-binding-test.example.com" spec: policyName: "sidecar-policy.example.com" paramRef: name: "meshproxy-test.example.com" namespace: default apiVersion: mutations.example.com kind: Sidecar metadata: name: meshproxy-test.example.com spec: name: mesh-proxy image: mesh/proxy:v1.0.0 args: ["proxy", "sidecar"] restartPolicy: Always “Bring Your Own CRD” デザインと
 呼ばれている
  8. 機械学習プラットフォームエンジニア We're hiring! https://www.preferred.jp/ja/careers/ 社内向けの機械学習プラットフォームと社外向けのクラウドサービス双⽅の開発・運⽤を共に⾏っていただく エンジニアを募集します。 ▶ ⾃由度・拡張性・使いやすさのトレードオフを⾒極めた⼤規模機械学習プラットフォームの機能設計と開発 ▶ ⾃動化等による運⽤効率の改善

    ▶ 計算資源(GPU、MN-Core を含む)配分の最適化 本ポジションの魅⼒ ▶ オンプレミスの⼤規模な環境で⾼レイヤから低レイヤまですべてをコントロールする経験ができる ▶ オンプレミスとパブリッククラウドのハイブリッドな構成でどちらの経験もできる ▶ HPC(⾼性能計算) とクラウドネイティブの境界領域というますます重要になる分野の経験ができる ▶ 外販のクラウドサービスとして Kubernetes を中⼼とする機械学習プラットフォームの開発を経験できる