정책을 썼다와 정책이 지켜진다는 다르다

한 줄 요약

kubectl apply 가 성공했다는 것은 정책이 저장됐다는 뜻일 뿐입니다. 데이터플레인이 없으면 아무것도 막히지 않습니다.

왜 진짜 Cilium 이어야 하나

앞 모듈들에서 CiliumNetworkPolicy 를 여러 개 썼습니다. 그런데 그 실습들이 도는 곳은 CRD 만 적재된 클러스터라서, kubectl apply 가 성공했다는 것 외에는 아무것도 확인되지 않았습니다.

이 모듈에서는 VM 안에 진짜 Cilium 을 세우고 같은 정책을 다시 씁니다. 그러면 세 가지가 새로 보입니다.

1. 아이덴티티는 실제 번호다

kubectl get ciliumendpoint 에 파드마다 아이덴티티 번호가 붙어 있습니다. 정책은 IP 가 아니라 이 번호로 판단하고, 번호는 라벨 조합에서 나옵니다. 파드를 재시작해 IP 가 바뀌어도 라벨이 같으면 번호가 같습니다.

규모에서 이 한 겹이 결정적입니다. 규칙 수가 파드 수가 아니라 아이덴티티 수를 따르기 때문입니다. 같은 라벨의 파드가 1000개여도 아이덴티티는 하나입니다.

2. L7 거부는 403 이다

Cilium 이 HTTP 를 보려면 패킷을 Envoy 로 넘겨야 합니다. 그래서 L7 에서 막힐 때는 연결이 끊기는 것이 아니라 403 이 돌아옵니다.

이것이 L3 차단보다 낫습니다. 타임아웃은 "네트워크가 이상한가, 서버가 죽었나, 방화벽인가" 를 구분할 수 없지만 403 은 명확한 거부입니다. 클라이언트가 재시도할지 말지를 바로 판단할 수 있고 로그에도 원인이 남습니다.

3. Hubble 은 "왜" 를 알려 준다

hubble observe --type policy-verdict 는 각 흐름이 어느 방향에서 어떤 판정을 받았는지 보여 줍니다. 이것이 없으면 정책 스무 개를 하나씩 지워 가며 범인을 찾게 됩니다.

실무에서 진짜 중요한 것

정책은 IP 가 아니라 아이덴티티로 판단합니다. 그래서 파드를 재시작해 IP 가 바뀌어도 정책이 흔들리지 않고, 규칙 수가 파드 수가 아니라 아이덴티티 수를 따릅니다. 라벨 설계가 곧 정책 규모 설계입니다.

L7 거부가 403 으로 오는 것은 운영에서 큰 이득입니다. 타임아웃은 네트워크·서버·방화벽을 구분해 주지 못하지만 403 은 명확한 거부라, 클라이언트가 재시도할지 말지를 바로 판단할 수 있고 로그에도 원인이 남습니다.

막혔을 때 정책을 하나씩 지우지 말고 Hubble 에 물어봅니다. hubble observe --type policy-verdict 가 어느 방향에서 어떤 판정이 났는지 알려 줍니다. 이것이 없으면 스무 개짜리 정책 묶음에서 범인을 이진 탐색하게 됩니다.

다음 실습에서 이 셋을 직접 확인합니다.