Запутанная семантика Kubernetes в спецификации yaml NetworkPolicy
Обратите внимание: значение поля ingress
под spec
.
Случай 1: ЗАПРЕЩАЕТСЯ весь трафик приложения. Здесь ingress принимает в качестве значения пустой массив.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-deny-all
spec:
podSelector:
matchLabels:
app: web
ingress: [] # <-- This DENIES ALL traffic
Случай 2: РАЗРЕШИТЬ весь трафик приложению. Здесь ingress принимает в качестве значения элемент списка пустой карты.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-allow-all
namespace: default
spec:
podSelector:
matchLabels:
app: web
ingress:
- {} # <-- This ALLOWS ALL traffic
Мне просто интересно, если бы я прочитал вслух значения присваивания ingress
из вышеперечисленного, как мне это прочитать?
1 ответ
В YAML есть несколько способов писать списки (и в этом отношении большинство других объектов). Это может стать понятнее, если мы напишем оба, используя один и тот же синтаксис списка:
# deny-all
ingress: []
# allow-all
ingress: [{}]
Предположим, что одна из этих политик - единственная, которая соответствует рассматриваемому модулю. Первая политика не имеет элементов вingress
список, второй. Документация по API NetworkPolicySpec сообщает нам
Трафик разрешен для модуля [...], если трафик соответствует хотя бы одному правилу входа для всех объектов NetworkPolicy, чей podSelector соответствует этому модулю.
Итак, в первом случае политика соответствует модулю, но нет правил входа, и, следовательно, нет хотя бы одного правила входа, которое соответствует, поэтому трафик запрещен.
Во втором случае есть одно правило - пустое NetworkPolicyIngressRule. У этого есть два поля,from
а также ports
, но в документации для обоих этих полей указано
Если это поле пустое или отсутствует, это правило соответствует всем [источники или порты]
Таким образом, правило пустого объекта соответствует всем источникам и всем портам; и поскольку существует соответствующее правило входа, трафик разрешен.