в этом случае врде нет, не имеет

в каком - в этом? )

Сохраняет. Порядок не имеет значения для containers, но в CRD, например, он может иметь значение

Кажется так. Кильнул второй контейнер из трех, но под не удалял. Контейнер пересоздался, ямл в выдаче в порядке - как и апплаил.

Привет,

пока у вас тут тишина, у меня созрел ещё один вопрос по kubectl diff :)

Если нет изменений, то дифф пустой, всё норм. А если, например, изменение в один байт, то кроме строки с этим изменением, показывает managed fields с мусором:

@@ -72,7 +72,6 @@  
                   k:{"name":"FOO"}:
                     .: {}
                     f:name: {}
-                    f:value: {}
                   k:{"name":"BAR"}:
                     .: {}
                     f:name: {}
@@ -173,6 +172,20 @@
     manager: kube-controller-manager
     operation: Update
     time: "2021-10-29T01:07:32Z"
+  - apiVersion: apps/v1
+    fieldsType: FieldsV1
+    fieldsV1:
+      f:spec:
+        f:template:
+          f:spec:
+            f:containers:
+              k:{"name":"manager"}:
+                f:env:
+                  k:{"name":"BAR"}:
+                    f:value: {}
+    manager: kubectl-client-side-apply
+    operation: Update
+    time: "2021-10-29T08:30:05Z"

Как его заставить показывать только то, что изменилось, без мусора?

google/metallb tagged: v0.11.0
Link: https://github.com/metallb/metallb/releases/tag/v0.11.0
Release notes:

[https://metallb.universe.tf/release-notes/](https://metallb.universe.tf/release-notes/)

Не везде 3-way diff, даже а kapp

Да в доке же написано, что сравнивается по ключу name. Мне интересно, а можно два контейнера с одним именем сделать?

Но вообще массив - это мапа, где ключами являются индексы.

А что за дока и что с чем сравнивается и зачем? :)

Два контейнера с одним именем - интересно. Попробую и сообщу как до компа доберусь.

философия :)

конечно, верно, до тех пор пока перебирать элементы не начнёшь.  
в массиве ещё порядок важен, а в мапе - нет. в мапе итерация по ключам от 0 до 9 невозможна принципиально без превращения в массив или без изменения кишков мапы, чтобы вместо хэша она брала ключ как есть для создания бакета)

https://t.me/k8spb/33777 вот же дока

Не вижу вообще никакого противоречия. Ключи отсортировать можно, если мы не говорим про различные имплементации мапы. Тебе как раз вместо массива, где важен порядок нужен именно Set, что в теории является мапой, где ключ равен значению. Set<t> = Map<t,t>, Array<t> = Map<int, t>. Есть детали, которые возникают при мутации (например, удаление элемента массива), и детали имплементации для оптимизации определённых операций (выборки, или наоборот вставки)

Но, вероятно, было бы удобней на уровне api представить containers в виде Map<string, Container>.

Делать это никто не будет уже из-за обратной совместимости.

Ага, понял что за дока.

Думаю, ты имел ввиду эту фразу - patch merge key: name. Эта фраза означает, как мне кажется, то как вести себя при обновлении. Например, апплаишь новую спеку и там у тебя в разнобой контейнеры, не так как были в спеке изначально. Всё равно обновится всё корректно так как элементы массива, тип элементов - container (мапа), будут сравниваться по ключу name.

Я рассматривал случай, где мы убиваем контейнер в поде. Ожидал, что в этом случае он пересздастся (есть) и станет первым/последним в массиве (нет).

Вряд ли это из-за мердж стратегии. Там по идее ничего не мержится. Спека является сорс оф тру и вообще не меняется )

Или ты все-таки думаешь, что что-то там мержжится?

сортировка ключей - это создание массива, где ты эти ключи хранишь ;)

Хотя, наверное, ты прав. Снаружи мы не заметим, если  итерироваться от 0 до N, где N размер мапы. Наверное, будет вести себя как массив :)

Теперь не пойму зачем ты это сказал. Ведь containers - настоящий массив, а не мапа с ключами от 0 до N? :)

Ключи мапы - это Set :-)