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

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:


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:


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:


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa

labels:

test-data: value2

managedFields:

- apiVersion: v1


fieldsV1:

f:metadata:

f:labels: {}

manager: flux-controller

operation: Apply

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

- apiVersion: v1


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


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 事件簿
消えないラベル（解決編）


apiVersion: v1

kind: ConfigMap

metadata:

annotations:


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"key":"value2"},"name":"config","namespace":"d

labels:

test-data: value2

managedFields:

- apiVersion: v1


fieldsV1:

f:metadata:

f:labels: {}


operation: Apply

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

- apiVersion: v1


fieldsV1:

f:metadata:

f:annotations:

.: {}


f:labels:

F:test-data: {}


operation: Update

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

name: config

namespace: default


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


apiVersion: v1

kind: ConfigMap

metadata:

annotations:


{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"test-data":"value2"},"name":"config","namespa

labels:

test-data: value2

managedFields:

- apiVersion: v1


fieldsV1:

f:metadata:

f:labels: {}


operation: Apply

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

- apiVersion: v1


fieldsV1:

f:metadata:

f:annotations:

.: {}


f:labels:

f:test-data: {}


operation: Update

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

name: config

namespace: default


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


apiVersion: v1

kind: ConfigMap

metadata:

annotations:


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


managedFields:

- apiVersion: v1


fieldsV1:

f:metadata:

f:labels: {}


operation: Apply

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

- apiVersion: v1


fieldsV1:

f:metadata:

f:annotations:

.: {}



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
!
まとめ
▶ 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上での分散強化学習実⾏ツール

@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

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

More Related Content

What's hot

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

More from Preferred Networks

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