SlideShare a Scribd company logo
Kubernetes Meetup Tokyo #48(2022/02/22)
SUDA Kazuki, Preferred Networks, Inc.
@superbrothers
わかる!metadata.managedFields
@superbrothers
!
SUDA Kazuki / @superbrothers
▶ Preferred Networks, Inc. / エンジニア
▶ Scalar, Inc. / 技術アドバイザ
▶ Kubernetes Meetup Tokyo 共同主催者
▶ Cloud Native Ambassador (CNCF)
▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書
▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書
2
@superbrothers
!
もくじ
▶ Kubernetes 事件簿: 消えないラベル(事件編、疑惑編)
▶ Server Side Apply(SSA)と metadata.managedFields
▶ わかる!metadata.managedFields
▶ Kubernetes 事件簿: 消えないラベル(解決編)
▶ まとめ
3
@superbrothers
!
Kubernetes 事件簿
消えないラベル
@superbrothers
!
😱
消えないラベル(事件編)
ある⽇の、GitOps ツールの Flux2 を導⼊している企業で、開発者がマニフェストファイルのあるラベル
を削除してリポジトリに変更をコミットした。GitOps ツール導⼊企業なので、あとは放っておけば
ツールがクラスタに変更を適⽤してくれる。
数時間後、Flux2 による適⽤が成功しているにも関わらず削除したはずのラベルが実際には削除されて
いないことに開発者が気がついた。
5
! " !
リポジトリ
開発者
!
1. マニフェストファイルを変更して
リポジトリにコミット
2. GitOps ツールがリポジトリに更新があると
マニフェストをクラスタに Apply
3. 数時間後にオブジェクトを確認すると


変更が反映されていないことが判明
!"!#$%&'()*+,-&$./0123456
@superbrothers
!
消えないラベル(事件編)
6
証拠品1: Flux2 が適⽤したマニフェスト 証拠品2: 適⽤後のオブジェクトの状態
apiVersion: v1


kind: ConfigMap


metadata:


name: config


labels:
$ kubectl get configmap config -o yaml


apiVersion: v1


kind: ConfigMap


metadata:


annotations:


kubectl.kubernetes.io/last-applied-configuration: |


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"ann


creationTimestamp: "2022-02-17T12:22:15Z"


labels:


test-data: value2


name: config


namespace: default


resourceVersion: "3758306"


uid: 2c4d5bda-1c3b-450d-b7f7-5fa3e8159f83
test-data ラベルを消したはずが


オブジェクトから消えていない。
📝$#7(89$:;<=>:?@AB:CDEFGHAIJKL
@superbrothers
!
消えないラベル(疑惑編)
「最近何か変わったことがあっただろうか...」
「そういえば Flux2 がアップグレードされていたはず。」


「変更内容は... SSA(Server Side Apply)のサポートだ。」
開発者は、SSA には覚えがあったので SSA でフィールドの管理⽅法がクライアントサイドのときから


⼤きく変わっていることを知っていた。
「まずは久しく⾒てない metadata.managedFields を確認するところからだ。」
7
@superbrothers
!
嫌われものの metadata.managedFields
8
$ kubectl version --client


Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15",
GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-01-19T17:27:39Z",
GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}


$ kubectl get po nginx-66f6ffdddf-p2kt5 -o yaml


apiVersion: v1


kind: Pod


metadata:


creationTimestamp: "2022-02-17T05:33:10Z"


generateName: nginx-66f6ffdddf-


labels:


app: nginx


pod-template-hash: 66f6ffdddf


managedFields:


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:generateName: {}


f:labels:


.: {}


f:app: {}


f:pod-template-hash: {}




MNOP>QJ6FHRSIJBTU
@superbrothers
!
kubectl v1.21 でデフォルトで出⼒されなくなった
9
$ kubectl version --client


Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9",
GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z",
GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}


$ kubectl get po nginx-66f6ffdddf-p2kt5 -o yaml


apiVersion: v1


kind: Pod


metadata:


creationTimestamp: "2022-02-17T05:33:10Z"


generateName: nginx-66f6ffdddf-


labels:


app: nginx


pod-template-hash: 66f6ffdddf


name: nginx-66f6ffdddf-p2kt5


namespace: default


ownerReferences:


- apiVersion: apps/v1


blockOwnerDeletion: true


controller: true


kind: ReplicaSet


name: nginx-66f6ffdddf




V*&*WXY#,X7YZ$[Q]IK
デフォルトで出⼒されなくなっただけで、実際には存在しています。


⾒やすくなってよかったが、⼀⽅で⽬にすることが減り、知る機会がなくなってしまった。
--show-managed-fields ^._`a4b
$$$$$$$$$$$cdedfghSi5
$ kubectl get cm config -o yaml --show-managed-fields


apiVersion: v1


kind: ConfigMap


metadata:


annotations:


kubectl.kubernetes.io/last-applied-configuration: |


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa
creationTimestamp: "2022-02-17T12:59:48Z"


labels:


test-data: value2


managedFields:


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:labels: {}


manager: flux-controller


operation: Apply


time: "2022-02-17T13:00:42Z"


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:annotations:


.: {}


f:kubectl.kubernetes.io/last-applied-configuration: {}


f:labels:


F:test-data: {}


manager: kubectl-client-side-apply


operation: Update


time: "2022-02-17T13:00:10Z"


name: config


namespace: default


resourceVersion: "3762113"


uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3
@superbrothers
!
ユーザが metadata.managedFields を理解する必要がある?
11
$ kubectl explain po.metadata.managedFields


KIND: Pod


VERSION: v1


RESOURCE: managedFields <[]Object>


DESCRIPTION:


ManagedFields maps workflow-id and version to the set of fields that are


managed by that workflow. This is mostly for internal housekeeping, and


users typically shouldn't need to set or understand this field. A workflow


can be the user's name, a controller's name, or the name of a specific


apply path like "ci-cd". The set of fields is always in the version that


the workflow used when modifying the object.


ManagedFieldsEntry is a workflow-id, a FieldSet and the group version of


the resource that the fieldset applies to.
@superbrothers
!
metadata.managedFields と
Server Side Apply(SSA)
@superbrothers
!
Server Side Apply(SSA)とは
差分の計算をサーバサイドで実施する Apply(適⽤)のこと
▶ そもそも Kubernetes における Apply(適⽤)は、オブジェクトが存在しなければ作成し、


存在すれば差分(パッチ)を適⽤する操作
▶ 差分を計算するには、ユーザが管理しているフィールドを記憶しておく必要がある
+ 現在のオブジェクトの状態から差分を計算してしまうと、そのフィールドがユーザが管理してい
るものなのか、Kubernetes(コントローラ等)が管理しているものなのかわからない
▶ SSA は誰がそのフィールドを管理しているかの情報を metadata.managedFields に保存する
+ SSA 以外の⼿段によるフィールドの更新も SSA への移⾏や互換性のために同様に記録される
▶ SSA は Kubernetes v1.22 で GA となり、利⽤が広がっている
13
jkl$mno$:$pXq7-rVX&+$ZqX'stXq7,'*Z$uvwxyz{|Ai56
@superbrothers
!
サーバサイドがあるなら、クライアントサイドは?🤔
▶ クライアントサイドの Apply には問題があることが分かっているため、SSA が開発された
+ kubectl edit でコンテナイメージを変更したあとにマニフェストが適⽤すると変更が巻き戻る
+ SSA では、フィールドの衝突が検知されて誰かがオブジェクトを変更したことがわかる
+ クライアントサイドにロジックがあることでGo 以外の⾔語や kubectl 以外のツールから使うこと
がむずかしい
+ SSA はサーバサイドで実⾏されるため、curl からでも利⽤できる
+ ユーザの管理しているフィールドの情報のみを保存している
+ SSA は、ユーザに加えてコントローラが管理しているフィールドも含めて保存する
▶ v1.23 時点で kubectl apply はまだクライアントサイドの Apply を使っている
+ --server-side オプションで SSA に変更できるが、いちユーザが積極的に使う理由はない
14
}()X'+7s}()Xt&X+XZs,-~7*Z+•*qq7,XY•'-&€,W(t*+,-&b
FJ•‚ƒ„w_`az…]Ii5L
@superbrothers
!
わかる!metadata.managedFields
@superbrothers
! 16
apiVersion: v1


kind: ConfigMap


metadata:


name: test-cm


namespace: default


labels:


test-label: test


managedFields:


- manager: kubectl


operation: Apply


apiVersion: v1


fields:


f:metadata:


f:labels:


f:test-label: {}


- manager: kube-controller-manager


operation: Update


apiVersion: v1


time: '2019-03-30T16:00:00.000Z'


fields:


f:data:


f:key: {}


data:


key: new value


フィールドのマネージャ名で⾃分で宣⾔する。
(kubectl apply --server-side の


マネージャ名が kubectl (デフォルト))
どの操作でオブジェクトを変更したか。
SSA は "Apply" 、それ以外で "Update" になる。
managedFields は SSA でしか使われないが


既存の⽅法との互換性を持たせるために


Update も記録されるようになっている。
このマネージャが管理している


フィールドを⽰している
kube-controller-manager があとから SSA 以外の⼿段で


フィールドを追加したことがわかる
V*&*WXY#,X7YZ$[$†()Xt&X+XZ$[{|AIJK‡4


ˆ‰Š‹>ˆŒ•Žd•kB•AI:J‘J’
@superbrothers
!
フィールド管理
SSA の⽬的の1つは、ユーザと"コントローラ"の協⼒でオブジェクトで管理すること。どのフィールド
をどのマネージャが管理しているかがわかるようになっている。
▶ あるフィールドを1⼈のマネージャが管理している場合
+ 基本的に他のマネージャに更新してくれるなということなので、更新されそうになったら


コンフリクト(衝突)として失敗させる
▶ あるフィールドを複数のマネージャが管理している場合
+ 複数のマネージャが同じフィールドを "同じ値で"設定するとそのフィールドを共同で


所有している状態になる


共同所有しているマネージャが値を変更しようとしてもコンフリクトとして失敗させる
+ 所有権を放棄するには、そのフィールドを削除してから Apply する
17
@superbrothers
!
フィールド更新時のコンフリクト
他のマネージャがすでに管理しているフィールドを更新しようとするとコンフリクトが発⽣し、


意図しない上書きが発⽣することを防ぐ。コンフリクトが発⽣した場合には3つの選択肢がある。
▶ 値を上書きして唯⼀のマネージャになる
+ 意図した上書きの場合は force パラメータを true にして Apply することで強制的に上書きする。
また、他のマネージャの所有権が失われる。
+ マネージャがコントローラの場合、コンフリクトしたらどうにもならないので


基本的に force ありで上書きすることになる
▶ 値を上書きせずに所有権を放棄する
+ コンフリクトしたフィールドの定義を削除して Apply することで所有権を放棄できる
▶ 値を上書きせずに共同所有者になる
+ コンフリクトしたフィールドで同じ値を設定して Apply することで共同所有者になれる
コンフリクトが発⽣するのは "Apply" 操作だけで "Update" が失敗することはない。
18
}()X'+7$*qq7r$4:$••€-t'X•'-&€7,'+Z$^._`a45’
@superbrothers
!
kubectl apply でのコンフリクト
19
$ kubectl apply -f deploy.yaml --server-side


error: Apply failed with 1 conflict: conflict with "kubectl-edit" using apps/
v1: .spec.template.spec.containers[name="nginx-unprivileged"].image


Please review the fields above--they currently have other managers. Here


are the ways you can resolve this warning:


* If you intend to manage all of these fields, please re-run the apply


command with the `--force-conflicts` flag.


* If you do not intend to manage all of the fields, please edit your


manifest to remove references to the fields that should keep their


current managers.


* You may co-own fields by updating your manifest to match the existing


value; in this case, you'll become the manager if the other manager(s)


stop managing the field (remove it from their configuration).


See http://k8s.io/docs/reference/using-api/server-side-apply/#conflicts
“SK‚2_`az”gAIQSI•]–—˜™6😊
@superbrothers
!
Kubernetes 事件簿
消えないラベル(解決編)
$ kubectl get cm config -o yaml --show-managed-fields


apiVersion: v1


kind: ConfigMap


metadata:


annotations:


kubectl.kubernetes.io/last-applied-configuration: |


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"key":"value2"},"name":"config","namespace":"d
creationTimestamp: "2022-02-17T12:59:48Z"


labels:


test-data: value2


managedFields:


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:labels: {}


manager: flux-controller


operation: Apply


time: "2022-02-17T13:00:42Z"


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:annotations:


.: {}


f:kubectl.kubernetes.io/last-applied-configuration: {}


f:labels:


F:test-data: {}


manager: kubectl-client-side-apply


operation: Update


time: "2022-02-17T13:00:10Z"


name: config


namespace: default


resourceVersion: "3762113"


uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3
Flux はたしかに test-data ラベルを所有していない
別のマネージャが test-data ラベルを所有権を保持したままになっている!
VX+*Y*+*sV*&WXY#,X7YZ$>5šI‡›œ[•K6
$ kubectl get cm config -o yaml --show-managed-fields


apiVersion: v1


kind: ConfigMap


metadata:


annotations:


kubectl.kubernetes.io/last-applied-configuration: |


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa
creationTimestamp: "2022-02-17T12:59:48Z"


labels:


test-data: value2


managedFields:


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:labels: {}


manager: flux-controller


operation: Apply


time: "2022-02-17T13:00:42Z"


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:annotations:


.: {}


f:kubectl.kubernetes.io/last-applied-configuration: {}


f:labels:


f:test-data: {}


manager: kubectl-client-side-apply


operation: Update


time: "2022-02-17T13:00:10Z"


name: config


namespace: default


resourceVersion: "3762113"


uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3
▶ kubectl-client-side-apply マネージャのみがこのフィールドを所有している
▶ このマネージャが所有権を放棄すればこのフィールドが削除される
▶ manager と operation から


kubectl apply (クライアントサイド)で変更されていることがわかる
解決策
$ cat <<EOL | kubectl apply -f-


apiVersion: v1


kind: ConfigMap


metadata:


name: config


labels:


EOL


configmap/config configured


$ kubectl get cm config -o yaml --show-managed-fields


apiVersion: v1


kind: ConfigMap


metadata:


annotations:


kubectl.kubernetes.io/last-applied-configuration: |


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":null,"name":"config","namespace":"default"}}


creationTimestamp: "2022-02-17T12:59:48Z"


managedFields:


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:labels: {}


manager: flux-controller


operation: Apply


time: "2022-02-17T13:00:42Z"


- apiVersion: v1


fieldsType: FieldsV1


fieldsV1:


f:metadata:


f:annotations:


.: {}


f:kubectl.kubernetes.io/last-applied-configuration: {}


manager: kubectl-client-side-apply


operation: Update


time: "2022-02-17T13:00:10Z"


test-data ラベルの所有権を放棄できている
ラベルのフィールドが削除されている
test-data ラベルの存在しないマニフェストを kubectl apply(クライアントサイド)で適⽤
@superbrothers
!
「消えないラベル」の真相
1. 開発者は Flux2 による適⽤(SSA)を⽌めて⼿元のマニフェストファイルを適⽤した
+ 開発者は test-data ラベルの値を変更し適⽤したことでこのフィールドのマネージャになっていた


(kubectl-client-side-apply マネージャがそれ)
2. 開発者はこの変更でうまく機能したので変更をリポジトリにコミットした
3. 開発者は Flux2 による適⽤(SSA)を再開した
+ test-data ラベルはすでに他のマネージャが所有権を持っている
+ Flux2 はラベルを同じ値で適⽤したので所有権を取得し、共同所有者になった
4. 開発者はその後ラベルがいらなくなったのでマニフェストを変更してリポジトリにコミットした
+ Flux2 は test-data ラベルの削除されたマニフェストを適⽤してラベルを削除しようとするが、


他に共同所有がいるため、所有権を放棄するだけで実際にフィールドは削除されなかった
24
ž:5šIŸ‘B6
@superbrothers
!
根本的な解決はむずかしい
▶ 問題1: Flux2 がユーザとは異なるマネージャとして SSA していること
+ SSA を使う前はクライアントサイドの適⽤を使⽤していた("ユーザ"としての適⽤と同等)
+ SSA を採⽤し独⾃のマネージャを使⽤したことで "ユーザ" として適⽤しなくなった
+ "ユーザ" として適⽤してくれれば共同所有にならない(上書きになる)
+ SSA で "ユーザ" として適⽤するには適⽤時に manager 名を kubectl にすればいける
▶ 問題2: kubectl apply がクライアントサイドの適⽤をデフォルトで使⽤していること
+ クライアントサイドの適⽤は manager が "kubectl-client-side-apply", operation が "Update"
+ Flux2 が "ユーザ" として SSA してくれてもユーザがクライアントサイドの適⽤を使ったら


同じユーザにならない
+ すべての⼈間が常に kubectl apply に --server-side オプションをつけるのは困難
現実的には⼈間が変更を kubectl apply で適⽤したら、あとで変更前の状態で


適⽤し直しておくくらいしかできない。しかし⼈間は忘れるのでむずかしい。
25
@superbrothers
!
まとめ
@superbrothers
!
まとめ
▶ metadata.manageFields は Server Side Apply(SSA)でどのユーザまたはコントローラが


オブジェクトのどのフィールドを所有しているのかの管理に使われる
+ SSA は Kubernetes v1.22 で GA となり、利⽤が広がっているが、


いちユーザが kubectl apply で積極的に SSA を使う必要はない
▶ kubectl v1.21 からデフォルトで出⼒されなくなったけど、いなくなったわけじゃない
▶ managedFields は Kubernetes が管理しているので"基本的に"直接書き換えたりしてはいけない
▶ SSA における metadata.managedFields を使ったフィールド管理
+ 1⼈のマネージャが所有している場合と複数で共同所有している場合がある
+ 所有するフィールドが削除されたマニフェストを適⽤することでマネージャは所有権を放棄する
▶ SSA で複数のマネージャが同じフィールドを更新しようとするとコンフリクトする
27
機械学習プラットフォームエンジニア
We're hiring! https://www.preferred.jp/ja/careers/
⼤規模計算基盤エンジニア
▶ ⼤規模な計算基盤の実現に関する企画、設計および研究開発
+ CPU/GPU/MN-Coreを組み合わせた


ドメイン最適化された計算基盤の企画・設計
+ クラスタ型計算機の設計
+ 規模性の⾼い計算機を⽀えるインターコネクトネットワーク
およびデータセンタ規模ネットワーク技術
+ 規模性の⾼い計算機を⽀えるストレージ階層、


ストレージシステム
▶ 規模性の⾼い計算機を⽀える技術の研究開発
+ エネルギー効率の良い⼤規模計算機システム
+ ⾼い電⼒密度をもつ⾼性能計算機の構成技術
+ ⾼い熱密度をもつ⾼性能計算機の構成技術
+ スケーラブルな計算基盤の監視・管理技術
+ 管理運⽤しやすい⼤規模計算システム
▶ ⼤規模なクラスタ計算機の継続的な性能改善
+ 物理的なシステムメトリクス収集とそれを⽤いた


既存システムの改善、新規設計へのフィードバック
▶ ⾃由度・拡張性・使いやすさのトレードオフが取れた⼤規模機械学
習プラットフォームの機能設計と開発
+ 例: 機械学習ワークフローツール、実験管理ツール、


GPUやMN-Core向け統合開発環境の構築
▶ ⼤規模機械学習プラットフォームの運⽤と運⽤改善(⾃動化等)
+ 例: ⾃動サーバプロビジョニング、パブリッククラウド連携に
よる運⽤効率化、インフラ健全性の⾃動診断と保守省⼒化
▶ ⼤規模機械学習プラットフォーム上での計算資源


(GPU, MN-Coreを含む)配分の最適化
+ 例: Kubernetes Schedulerの機能拡張、


リソース利⽤量制限拡張の開発
▶ 最先端の分散計算基盤技術の Proof of Concept 構築及び


プラットフォームでの実⽤化
+ 例: Kubernetes上での分散強化学習実⾏ツール
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
@superbrothers
!
Appendix
▶ Server-Side Apply | Kubernetes
+ https://kubernetes.io/docs/reference/using-api/server-side-apply/
▶ KEP 555 - Apply
+ https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/555-server-side-apply
▶ Kubernetes 1.21: SIG-CLI (kubectl) 変更内容 - Qiita
+ https://qiita.com/superbrothers/items/afeea65db4f3d4d1c5ef
▶ Enable kubectl-get to strip managed
fi
elds by knight42 · Pull Request #96878 · kubernetes/kubernetes
+ https://github.com/kubernetes/kubernetes/pull/96878
▶ Kubernetes 1.14: Server-side Apply (alpha) - Qiita
+ https://qiita.com/superbrothers/items/aeba9406691388b6a19e
▶ Kubernetes: kubectl apply の動作 - Qiita
+ https://qiita.com/tkusumi/items/0bf5417c865ef716b221
▶ Server-side reconciliation is coming | Flux
+ https://
fl
uxcd.io/blog/2021/09/server-side-reconciliation-is-coming/
▶ https://github.com/superbrothers-sandbox/kubernetes-meetup-tokyo-48-metadata-managedFields
30

More Related Content

What's hot

コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
NTT DATA Technology & Innovation
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説
貴仁 大和屋
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
Preferred Networks
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Preferred Networks
 
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
 
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
Ohyama Masanori
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 

What's hot (20)

コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
 
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
 
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ(CloudNative Days Tokyo 2021 発表資料)
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 

Similar to わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48

PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!
Shohei Okada
 
Ruby on Rails3 Tutorial Chapter2
Ruby on Rails3 Tutorial Chapter2Ruby on Rails3 Tutorial Chapter2
Ruby on Rails3 Tutorial Chapter2
Sea Mountain
 
Wsfc basic 130720
Wsfc basic 130720Wsfc basic 130720
Wsfc basic 130720
wintechq
 
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
VirtualTech Japan Inc.
 
Active directory の移行 (2011年6月の資料)
Active directory の移行 (2011年6月の資料)Active directory の移行 (2011年6月の資料)
Active directory の移行 (2011年6月の資料)
wintechq
 
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
softlayerjp
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Samir Hammoudi
 
20181120 HowtoFlow
20181120 HowtoFlow20181120 HowtoFlow
20181120 HowtoFlow
Tomoyuki Obi
 
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperleger Tokyo Meetup
 
Sflt17 meteorではじめる最速ウェブアプリ開発
Sflt17 meteorではじめる最速ウェブアプリ開発Sflt17 meteorではじめる最速ウェブアプリ開発
Sflt17 meteorではじめる最速ウェブアプリ開発
Hironao Sekine
 
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Uemura Yuichi
 
Mvc conf session_4_ono
Mvc conf session_4_onoMvc conf session_4_ono
Mvc conf session_4_ono
Hiroshi Okunushi
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
Yoshio Terada
 
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
Ryuta Otaki
 
CloudStack User Inferface
CloudStack User InferfaceCloudStack User Inferface
CloudStack User Inferface
Kimihiko Kitase
 
Rails基礎講座 part.2
Rails基礎講座 part.2Rails基礎講座 part.2
Rails基礎講座 part.2
Jun Yokoyama
 
Acm2.1 short public
Acm2.1 short publicAcm2.1 short public
Acm2.1 short public
Yuhki Hanada
 
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組みモバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
MorioImai
 
ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~
Yoshitaka Seo
 

Similar to わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48 (20)

PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!PHP 2大 web フレームワークの徹底比較!
PHP 2大 web フレームワークの徹底比較!
 
Ruby on Rails3 Tutorial Chapter2
Ruby on Rails3 Tutorial Chapter2Ruby on Rails3 Tutorial Chapter2
Ruby on Rails3 Tutorial Chapter2
 
Wsfc basic 130720
Wsfc basic 130720Wsfc basic 130720
Wsfc basic 130720
 
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
 
Active directory の移行 (2011年6月の資料)
Active directory の移行 (2011年6月の資料)Active directory の移行 (2011年6月の資料)
Active directory の移行 (2011年6月の資料)
 
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
 
20181120 HowtoFlow
20181120 HowtoFlow20181120 HowtoFlow
20181120 HowtoFlow
 
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
Hyperledger Fabric 簡単構築ツール minifabricのご紹介 〜productionへの移行をminifabricで加速〜
 
Sflt17 meteorではじめる最速ウェブアプリ開発
Sflt17 meteorではじめる最速ウェブアプリ開発Sflt17 meteorではじめる最速ウェブアプリ開発
Sflt17 meteorではじめる最速ウェブアプリ開発
 
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
 
Mvc conf session_4_ono
Mvc conf session_4_onoMvc conf session_4_ono
Mvc conf session_4_ono
 
20110607
2011060720110607
20110607
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
 
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話
 
CloudStack User Inferface
CloudStack User InferfaceCloudStack User Inferface
CloudStack User Inferface
 
Rails基礎講座 part.2
Rails基礎講座 part.2Rails基礎講座 part.2
Rails基礎講座 part.2
 
Acm2.1 short public
Acm2.1 short publicAcm2.1 short public
Acm2.1 short public
 
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組みモバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み
 
ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~
 

More from Preferred Networks

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
Preferred Networks
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Preferred Networks
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Preferred Networks
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
Preferred Networks
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Preferred Networks
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
Preferred Networks
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Preferred Networks
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
Preferred Networks
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
Preferred Networks
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Preferred Networks
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Preferred Networks
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
Preferred Networks
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
Preferred Networks
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
Preferred Networks
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
Preferred Networks
 

More from Preferred Networks (20)

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
 

わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48

  • 1. Kubernetes Meetup Tokyo #48(2022/02/22) SUDA Kazuki, Preferred Networks, Inc. @superbrothers わかる!metadata.managedFields
  • 2. @superbrothers ! SUDA Kazuki / @superbrothers ▶ Preferred Networks, Inc. / エンジニア ▶ Scalar, Inc. / 技術アドバイザ ▶ Kubernetes Meetup Tokyo 共同主催者 ▶ Cloud Native Ambassador (CNCF) ▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書 ▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 2
  • 3. @superbrothers ! もくじ ▶ Kubernetes 事件簿: 消えないラベル(事件編、疑惑編) ▶ Server Side Apply(SSA)と metadata.managedFields ▶ わかる!metadata.managedFields ▶ Kubernetes 事件簿: 消えないラベル(解決編) ▶ まとめ 3
  • 5. @superbrothers ! 😱 消えないラベル(事件編) ある⽇の、GitOps ツールの Flux2 を導⼊している企業で、開発者がマニフェストファイルのあるラベル を削除してリポジトリに変更をコミットした。GitOps ツール導⼊企業なので、あとは放っておけば ツールがクラスタに変更を適⽤してくれる。 数時間後、Flux2 による適⽤が成功しているにも関わらず削除したはずのラベルが実際には削除されて いないことに開発者が気がついた。 5 ! " ! リポジトリ 開発者 ! 1. マニフェストファイルを変更して リポジトリにコミット 2. GitOps ツールがリポジトリに更新があると マニフェストをクラスタに Apply 3. 数時間後にオブジェクトを確認すると 
 変更が反映されていないことが判明 !"!#$%&'()*+,-&$./0123456
  • 6. @superbrothers ! 消えないラベル(事件編) 6 証拠品1: Flux2 が適⽤したマニフェスト 証拠品2: 適⽤後のオブジェクトの状態 apiVersion: v1 kind: ConfigMap metadata: name: config labels: $ kubectl get configmap config -o yaml apiVersion: v1 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ConfigMap","metadata":{"ann creationTimestamp: "2022-02-17T12:22:15Z" labels: test-data: value2 name: config namespace: default resourceVersion: "3758306" uid: 2c4d5bda-1c3b-450d-b7f7-5fa3e8159f83 test-data ラベルを消したはずが 
 オブジェクトから消えていない。 📝$#7(89$:;<=>:?@AB:CDEFGHAIJKL
  • 7. @superbrothers ! 消えないラベル(疑惑編) 「最近何か変わったことがあっただろうか...」 「そういえば Flux2 がアップグレードされていたはず。」 
 「変更内容は... SSA(Server Side Apply)のサポートだ。」 開発者は、SSA には覚えがあったので SSA でフィールドの管理⽅法がクライアントサイドのときから 
 ⼤きく変わっていることを知っていた。 「まずは久しく⾒てない metadata.managedFields を確認するところからだ。」 7
  • 8. @superbrothers ! 嫌われものの metadata.managedFields 8 $ kubectl version --client Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15", GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-01-19T17:27:39Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"} $ kubectl get po nginx-66f6ffdddf-p2kt5 -o yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: "2022-02-17T05:33:10Z" generateName: nginx-66f6ffdddf- labels: app: nginx pod-template-hash: 66f6ffdddf managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:generateName: {} f:labels: .: {} f:app: {} f:pod-template-hash: {} MNOP>QJ6FHRSIJBTU
  • 9. @superbrothers ! kubectl v1.21 でデフォルトで出⼒されなくなった 9 $ kubectl version --client Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"} $ kubectl get po nginx-66f6ffdddf-p2kt5 -o yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: "2022-02-17T05:33:10Z" generateName: nginx-66f6ffdddf- labels: app: nginx pod-template-hash: 66f6ffdddf name: nginx-66f6ffdddf-p2kt5 namespace: default ownerReferences: - apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: ReplicaSet name: nginx-66f6ffdddf V*&*WXY#,X7YZ$[Q]IK デフォルトで出⼒されなくなっただけで、実際には存在しています。 
 ⾒やすくなってよかったが、⼀⽅で⽬にすることが減り、知る機会がなくなってしまった。 --show-managed-fields ^._`a4b $$$$$$$$$$$cdedfghSi5
  • 10. $ kubectl get cm config -o yaml --show-managed-fields apiVersion: v1 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa creationTimestamp: "2022-02-17T12:59:48Z" labels: test-data: value2 managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: {} manager: flux-controller operation: Apply time: "2022-02-17T13:00:42Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} f:labels: F:test-data: {} manager: kubectl-client-side-apply operation: Update time: "2022-02-17T13:00:10Z" name: config namespace: default resourceVersion: "3762113" uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3
  • 11. @superbrothers ! ユーザが metadata.managedFields を理解する必要がある? 11 $ kubectl explain po.metadata.managedFields KIND: Pod VERSION: v1 RESOURCE: managedFields <[]Object> DESCRIPTION: ManagedFields maps workflow-id and version to the set of fields that are managed by that workflow. This is mostly for internal housekeeping, and users typically shouldn't need to set or understand this field. A workflow can be the user's name, a controller's name, or the name of a specific apply path like "ci-cd". The set of fields is always in the version that the workflow used when modifying the object. ManagedFieldsEntry is a workflow-id, a FieldSet and the group version of the resource that the fieldset applies to.
  • 13. @superbrothers ! Server Side Apply(SSA)とは 差分の計算をサーバサイドで実施する Apply(適⽤)のこと ▶ そもそも Kubernetes における Apply(適⽤)は、オブジェクトが存在しなければ作成し、 
 存在すれば差分(パッチ)を適⽤する操作 ▶ 差分を計算するには、ユーザが管理しているフィールドを記憶しておく必要がある + 現在のオブジェクトの状態から差分を計算してしまうと、そのフィールドがユーザが管理してい るものなのか、Kubernetes(コントローラ等)が管理しているものなのかわからない ▶ SSA は誰がそのフィールドを管理しているかの情報を metadata.managedFields に保存する + SSA 以外の⼿段によるフィールドの更新も SSA への移⾏や互換性のために同様に記録される ▶ SSA は Kubernetes v1.22 で GA となり、利⽤が広がっている 13 jkl$mno$:$pXq7-rVX&+$ZqX'stXq7,'*Z$uvwxyz{|Ai56
  • 14. @superbrothers ! サーバサイドがあるなら、クライアントサイドは?🤔 ▶ クライアントサイドの Apply には問題があることが分かっているため、SSA が開発された + kubectl edit でコンテナイメージを変更したあとにマニフェストが適⽤すると変更が巻き戻る + SSA では、フィールドの衝突が検知されて誰かがオブジェクトを変更したことがわかる + クライアントサイドにロジックがあることでGo 以外の⾔語や kubectl 以外のツールから使うこと がむずかしい + SSA はサーバサイドで実⾏されるため、curl からでも利⽤できる + ユーザの管理しているフィールドの情報のみを保存している + SSA は、ユーザに加えてコントローラが管理しているフィールドも含めて保存する ▶ v1.23 時点で kubectl apply はまだクライアントサイドの Apply を使っている + --server-side オプションで SSA に変更できるが、いちユーザが積極的に使う理由はない 14 }()X'+7s}()Xt&X+XZs,-~7*Z+•*qq7,XY•'-&€,W(t*+,-&b FJ•‚ƒ„w_`az…]Ii5L
  • 16. @superbrothers ! 16 apiVersion: v1 kind: ConfigMap metadata: name: test-cm namespace: default labels: test-label: test managedFields: - manager: kubectl operation: Apply apiVersion: v1 fields: f:metadata: f:labels: f:test-label: {} - manager: kube-controller-manager operation: Update apiVersion: v1 time: '2019-03-30T16:00:00.000Z' fields: f:data: f:key: {} data: key: new value フィールドのマネージャ名で⾃分で宣⾔する。 (kubectl apply --server-side の 
 マネージャ名が kubectl (デフォルト)) どの操作でオブジェクトを変更したか。 SSA は "Apply" 、それ以外で "Update" になる。 managedFields は SSA でしか使われないが 
 既存の⽅法との互換性を持たせるために 
 Update も記録されるようになっている。 このマネージャが管理している 
 フィールドを⽰している kube-controller-manager があとから SSA 以外の⼿段で 
 フィールドを追加したことがわかる V*&*WXY#,X7YZ$[$†()Xt&X+XZ$[{|AIJK‡4 ˆ‰Š‹>ˆŒ•Žd•kB•AI:J‘J’
  • 17. @superbrothers ! フィールド管理 SSA の⽬的の1つは、ユーザと"コントローラ"の協⼒でオブジェクトで管理すること。どのフィールド をどのマネージャが管理しているかがわかるようになっている。 ▶ あるフィールドを1⼈のマネージャが管理している場合 + 基本的に他のマネージャに更新してくれるなということなので、更新されそうになったら 
 コンフリクト(衝突)として失敗させる ▶ あるフィールドを複数のマネージャが管理している場合 + 複数のマネージャが同じフィールドを "同じ値で"設定するとそのフィールドを共同で 
 所有している状態になる 
 共同所有しているマネージャが値を変更しようとしてもコンフリクトとして失敗させる + 所有権を放棄するには、そのフィールドを削除してから Apply する 17
  • 18. @superbrothers ! フィールド更新時のコンフリクト 他のマネージャがすでに管理しているフィールドを更新しようとするとコンフリクトが発⽣し、 
 意図しない上書きが発⽣することを防ぐ。コンフリクトが発⽣した場合には3つの選択肢がある。 ▶ 値を上書きして唯⼀のマネージャになる + 意図した上書きの場合は force パラメータを true にして Apply することで強制的に上書きする。 また、他のマネージャの所有権が失われる。 + マネージャがコントローラの場合、コンフリクトしたらどうにもならないので 
 基本的に force ありで上書きすることになる ▶ 値を上書きせずに所有権を放棄する + コンフリクトしたフィールドの定義を削除して Apply することで所有権を放棄できる ▶ 値を上書きせずに共同所有者になる + コンフリクトしたフィールドで同じ値を設定して Apply することで共同所有者になれる コンフリクトが発⽣するのは "Apply" 操作だけで "Update" が失敗することはない。 18 }()X'+7$*qq7r$4:$••€-t'X•'-&€7,'+Z$^._`a45’
  • 19. @superbrothers ! kubectl apply でのコンフリクト 19 $ kubectl apply -f deploy.yaml --server-side error: Apply failed with 1 conflict: conflict with "kubectl-edit" using apps/ v1: .spec.template.spec.containers[name="nginx-unprivileged"].image Please review the fields above--they currently have other managers. Here are the ways you can resolve this warning: * If you intend to manage all of these fields, please re-run the apply command with the `--force-conflicts` flag. * If you do not intend to manage all of the fields, please edit your manifest to remove references to the fields that should keep their current managers. * You may co-own fields by updating your manifest to match the existing value; in this case, you'll become the manager if the other manager(s) stop managing the field (remove it from their configuration). See http://k8s.io/docs/reference/using-api/server-side-apply/#conflicts “SK‚2_`az”gAIQSI•]–—˜™6😊
  • 21. $ kubectl get cm config -o yaml --show-managed-fields apiVersion: v1 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"key":"value2"},"name":"config","namespace":"d creationTimestamp: "2022-02-17T12:59:48Z" labels: test-data: value2 managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: {} manager: flux-controller operation: Apply time: "2022-02-17T13:00:42Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} f:labels: F:test-data: {} manager: kubectl-client-side-apply operation: Update time: "2022-02-17T13:00:10Z" name: config namespace: default resourceVersion: "3762113" uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3 Flux はたしかに test-data ラベルを所有していない 別のマネージャが test-data ラベルを所有権を保持したままになっている! VX+*Y*+*sV*&WXY#,X7YZ$>5šI‡›œ[•K6
  • 22. $ kubectl get cm config -o yaml --show-managed-fields apiVersion: v1 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa creationTimestamp: "2022-02-17T12:59:48Z" labels: test-data: value2 managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: {} manager: flux-controller operation: Apply time: "2022-02-17T13:00:42Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} f:labels: f:test-data: {} manager: kubectl-client-side-apply operation: Update time: "2022-02-17T13:00:10Z" name: config namespace: default resourceVersion: "3762113" uid: 5ee6567e-5248-4494-a0aa-d55a5e16b8f3 ▶ kubectl-client-side-apply マネージャのみがこのフィールドを所有している ▶ このマネージャが所有権を放棄すればこのフィールドが削除される ▶ manager と operation から 
 kubectl apply (クライアントサイド)で変更されていることがわかる 解決策
  • 23. $ cat <<EOL | kubectl apply -f- apiVersion: v1 kind: ConfigMap metadata: name: config labels: EOL configmap/config configured $ kubectl get cm config -o yaml --show-managed-fields apiVersion: v1 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":null,"name":"config","namespace":"default"}} creationTimestamp: "2022-02-17T12:59:48Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: {} manager: flux-controller operation: Apply time: "2022-02-17T13:00:42Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} manager: kubectl-client-side-apply operation: Update time: "2022-02-17T13:00:10Z" test-data ラベルの所有権を放棄できている ラベルのフィールドが削除されている test-data ラベルの存在しないマニフェストを kubectl apply(クライアントサイド)で適⽤
  • 24. @superbrothers ! 「消えないラベル」の真相 1. 開発者は Flux2 による適⽤(SSA)を⽌めて⼿元のマニフェストファイルを適⽤した + 開発者は test-data ラベルの値を変更し適⽤したことでこのフィールドのマネージャになっていた 
 (kubectl-client-side-apply マネージャがそれ) 2. 開発者はこの変更でうまく機能したので変更をリポジトリにコミットした 3. 開発者は Flux2 による適⽤(SSA)を再開した + test-data ラベルはすでに他のマネージャが所有権を持っている + Flux2 はラベルを同じ値で適⽤したので所有権を取得し、共同所有者になった 4. 開発者はその後ラベルがいらなくなったのでマニフェストを変更してリポジトリにコミットした + Flux2 は test-data ラベルの削除されたマニフェストを適⽤してラベルを削除しようとするが、 
 他に共同所有がいるため、所有権を放棄するだけで実際にフィールドは削除されなかった 24 ž:5šIŸ‘B6
  • 25. @superbrothers ! 根本的な解決はむずかしい ▶ 問題1: Flux2 がユーザとは異なるマネージャとして SSA していること + SSA を使う前はクライアントサイドの適⽤を使⽤していた("ユーザ"としての適⽤と同等) + SSA を採⽤し独⾃のマネージャを使⽤したことで "ユーザ" として適⽤しなくなった + "ユーザ" として適⽤してくれれば共同所有にならない(上書きになる) + SSA で "ユーザ" として適⽤するには適⽤時に manager 名を kubectl にすればいける ▶ 問題2: kubectl apply がクライアントサイドの適⽤をデフォルトで使⽤していること + クライアントサイドの適⽤は manager が "kubectl-client-side-apply", operation が "Update" + Flux2 が "ユーザ" として SSA してくれてもユーザがクライアントサイドの適⽤を使ったら 
 同じユーザにならない + すべての⼈間が常に kubectl apply に --server-side オプションをつけるのは困難 現実的には⼈間が変更を kubectl apply で適⽤したら、あとで変更前の状態で 
 適⽤し直しておくくらいしかできない。しかし⼈間は忘れるのでむずかしい。 25
  • 27. @superbrothers ! まとめ ▶ metadata.manageFields は Server Side Apply(SSA)でどのユーザまたはコントローラが 
 オブジェクトのどのフィールドを所有しているのかの管理に使われる + SSA は Kubernetes v1.22 で GA となり、利⽤が広がっているが、 
 いちユーザが kubectl apply で積極的に SSA を使う必要はない ▶ kubectl v1.21 からデフォルトで出⼒されなくなったけど、いなくなったわけじゃない ▶ managedFields は Kubernetes が管理しているので"基本的に"直接書き換えたりしてはいけない ▶ SSA における metadata.managedFields を使ったフィールド管理 + 1⼈のマネージャが所有している場合と複数で共同所有している場合がある + 所有するフィールドが削除されたマニフェストを適⽤することでマネージャは所有権を放棄する ▶ SSA で複数のマネージャが同じフィールドを更新しようとするとコンフリクトする 27
  • 28. 機械学習プラットフォームエンジニア We're hiring! https://www.preferred.jp/ja/careers/ ⼤規模計算基盤エンジニア ▶ ⼤規模な計算基盤の実現に関する企画、設計および研究開発 + CPU/GPU/MN-Coreを組み合わせた 
 ドメイン最適化された計算基盤の企画・設計 + クラスタ型計算機の設計 + 規模性の⾼い計算機を⽀えるインターコネクトネットワーク およびデータセンタ規模ネットワーク技術 + 規模性の⾼い計算機を⽀えるストレージ階層、 
 ストレージシステム ▶ 規模性の⾼い計算機を⽀える技術の研究開発 + エネルギー効率の良い⼤規模計算機システム + ⾼い電⼒密度をもつ⾼性能計算機の構成技術 + ⾼い熱密度をもつ⾼性能計算機の構成技術 + スケーラブルな計算基盤の監視・管理技術 + 管理運⽤しやすい⼤規模計算システム ▶ ⼤規模なクラスタ計算機の継続的な性能改善 + 物理的なシステムメトリクス収集とそれを⽤いた 
 既存システムの改善、新規設計へのフィードバック ▶ ⾃由度・拡張性・使いやすさのトレードオフが取れた⼤規模機械学 習プラットフォームの機能設計と開発 + 例: 機械学習ワークフローツール、実験管理ツール、 
 GPUやMN-Core向け統合開発環境の構築 ▶ ⼤規模機械学習プラットフォームの運⽤と運⽤改善(⾃動化等) + 例: ⾃動サーバプロビジョニング、パブリッククラウド連携に よる運⽤効率化、インフラ健全性の⾃動診断と保守省⼒化 ▶ ⼤規模機械学習プラットフォーム上での計算資源 
 (GPU, MN-Coreを含む)配分の最適化 + 例: Kubernetes Schedulerの機能拡張、 
 リソース利⽤量制限拡張の開発 ▶ 最先端の分散計算基盤技術の Proof of Concept 構築及び 
 プラットフォームでの実⽤化 + 例: Kubernetes上での分散強化学習実⾏ツール
  • 30. @superbrothers ! Appendix ▶ Server-Side Apply | Kubernetes + https://kubernetes.io/docs/reference/using-api/server-side-apply/ ▶ KEP 555 - Apply + https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/555-server-side-apply ▶ Kubernetes 1.21: SIG-CLI (kubectl) 変更内容 - Qiita + https://qiita.com/superbrothers/items/afeea65db4f3d4d1c5ef ▶ Enable kubectl-get to strip managed fi elds by knight42 · Pull Request #96878 · kubernetes/kubernetes + https://github.com/kubernetes/kubernetes/pull/96878 ▶ Kubernetes 1.14: Server-side Apply (alpha) - Qiita + https://qiita.com/superbrothers/items/aeba9406691388b6a19e ▶ Kubernetes: kubectl apply の動作 - Qiita + https://qiita.com/tkusumi/items/0bf5417c865ef716b221 ▶ Server-side reconciliation is coming | Flux + https:// fl uxcd.io/blog/2021/09/server-side-reconciliation-is-coming/ ▶ https://github.com/superbrothers-sandbox/kubernetes-meetup-tokyo-48-metadata-managedFields 30