Синтаксис YAML - списки, словари

Question

Со следующим файлом YAML:

• почему policyTypes содержит список, а metadata нет?

• почему У ports есть 1 элемент списка ниже (то есть protocol), тогда как port нет?

Меня не интересует сторона вещей Kubernetes только YAML синтаксис.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Например, синтаксически это действительно YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  - name: test-network-policy
  - namespace: default

Чем он отличается (с точки зрения YAML) от первого примера?

Answer 1

Полное игнорирование контекста Kubernetes: YAML имеет последовательности и сопоставления (точно так же, как JSON массивы и объекты). Везде, где у вас есть маркер -, это элемент списка; везде есть пара key: value, это отображение. Вы можете иметь одно внутри другого.

ports:
- protocol: TCP
  port: 6379

# is equivalent to
ports: [{"protocol": "TCP", "port": 6379}]

metadata:
  name: test-network-policy
  namespace: default

# is equivalent to
metadata: {"name": "test-network-policy", "namespace": "default"}

metadata:
  - name: test-network-policy
  - namespace: default

# is equivalent to
metadata: [
  {"name": "test-network-policy"},
  {"namespace": "default"}
]

Различия между отображениями и последовательностями имеют значение, и если приложение ожидает отображение, но на самом деле получает последовательность отображений (сравните два metadata: блоков) вы получите ошибку на уровне приложения.

Шаблон, который действительно появляется в API Kubernetes, но может немного сбить с толку, - это иметь список объектов с некоторым логическим «видом». Объем в пакете c - хороший пример. У каждого из них есть ключ, чтобы сказать, какого они типа, но вам разрешено иметь несколько томов одного типа, поэтому отображение не является правильной структурой.

volumes:
  # This is a list of mappings
  - name: logs
    emptyDir: {}
  - name: coreDumps
    emptyDir: {}

Answer 2

• Почему policyTypes содержит список, а metadata нет?

Как написано в Справочник по API kubernetes поле policyTypes - это поле string array (в структуре данных YAML, называемой списком), что означает, что это набор значений. Для этих конкретных объектов могут быть указаны только эти 2 значения (но стандартный список YAML позволяет расширить количество значений).

  policyTypes:
  - Ingress
  - Egress

Metadata - карта - она ​​состоит из пар ключевых значений, но может быть и дальше расширен, добавив к нему еще одну карту - например, поле labels в разделе metadata:

apiVersion: v1
kind: Pod
metadata:
  name: podname
  labels:
    key: value 
[...]

Все строки должны иметь префикс с одинаковым количеством пробелов, чтобы принадлежать к одной карте

• почему у портов ниже 1 элемента списка (то есть протокола), а у порта нет?

Аналогично ранее - ports поле имеет значение map inside list и для NetworkPolicy объект только port и protocol могут быть указаны. Определение поля port:

port по данному протоколу. Это может быть цифровой или именованный порт на модуле. Если это поле не указано, оно соответствует всем именам и номерам портов.

Таким образом, это пара key: value, такая же, как поле protocol.