deploy
39 lines
1.4 KiB
YAML
39 lines
1.4 KiB
YAML
# =============================================================================
|
|
# O Sino do painel do dono le os alertas ativos do Alertmanager.
|
|
#
|
|
# MESMA ARMADILHA JA VISTA TRES VEZES neste tenant (API do Kubernetes,
|
|
# controlador do sealed-secrets, Gitea): `deny-cross-tenant` libera
|
|
# `ipBlock: 10.43.0.0/16` (a faixa de ClusterIP), e isso NAO adianta — o
|
|
# controlador de rede do k3s avalia a politica DEPOIS do DNAT, quando o
|
|
# destino ja e o IP do POD (10.42.x.x), fora da faixa liberada. Atravessar
|
|
# para outro namespace exige `namespaceSelector` + `podSelector`, sempre.
|
|
#
|
|
# Por que o pod, e nao o Service `alertmanager-operated`: o mesmo raciocinio
|
|
# de sempre — o NetworkPolicy filtra o trafego que chega ao POD de destino,
|
|
# entao o rotulo tem de ser do POD, nao do objeto Service (que nao tem
|
|
# pacote nenhum passando por ele).
|
|
#
|
|
# Saida apenas: o Alertmanager nunca inicia conversa conosco.
|
|
# =============================================================================
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: egress-alertmanager
|
|
namespace: plataforma-prod
|
|
spec:
|
|
podSelector:
|
|
matchLabels:
|
|
app: servico-captacao
|
|
policyTypes: [Egress]
|
|
egress:
|
|
- to:
|
|
- namespaceSelector:
|
|
matchLabels:
|
|
kubernetes.io/metadata.name: monitoring
|
|
podSelector:
|
|
matchLabels:
|
|
app.kubernetes.io/name: alertmanager
|
|
ports:
|
|
- port: 9093
|
|
protocol: TCP
|