쿠버네티스 Kubernetes - 네트워크 폴리시 Network Policy
본 포스팅 내용은 쿠버네티스 공식문서를 DeepL
로 번역한 내용이다.
네트워크 폴리시 Network Policies
IP 주소 또는 포트 수준(OSI 레이어 3 또는 4)에서 트래픽 흐름을 제어하려면 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시를 사용하는 것을 고려할 수 있다. 네트워크폴리시는 애플리케이션 중심 구조로, 파드가 네트워크를 통해 다양한 네트워크 "엔티티"(여기서는 특정 쿠버네티스 의미를 가진 "엔드포인트" 및 "서비스"와 같은 더 일반적인 용어의 과부하를 피하기 위해 "엔티티"라는 단어를 사용한다)와 통신할 수 있는 방법을 지정할 수 있게 해준다. 네트워크폴리시는 한쪽 또는 양쪽 끝에 있는 파드와의 연결에 적용되며 다른 연결과는 관련이 없다.
파드가 통신할 수 있는 엔티티는 다음 3가지 식별자의 조합을 통해 식별된다:
허용된 다른 파드(예외: 파드는 자신에 대한 액세스를 차단할 수 없음)
허용된 네임스페이스
IP 블록(예외: 파드 또는 노드의 IP 주소에 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨).
파드 또는 네임스페이스 기반 네트워크폴리시를 정의할 때, 셀렉터를 사용하여 셀렉터와 일치하는 파드에서 어떤 트래픽이 허용되는지 지정한다.
한편, IP 기반 네트워크폴리시가 생성될 때, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다.
전제조건 Prerequisites
네트워크 정책은 네트워크 플러그인에 의해 구현됩니다. 네트워크 정책을 사용하려면 네트워크 정책을 지원하는 네트워킹 솔루션을 사용해야 합니다. 네트워크 정책을 구현하는 컨트롤러 없이 네트워크 정책 리소스를 생성하면 아무런 효과가 없습니다.
파드 격리의 두 가지 방법
파드 격리에는 송신 격리와 수신 격리의 두 가지 종류가 있습니다. 이는 어떤 연결이 설정될 수 있는지에 관한 것이다. 여기서 "격리"는 절대적인 것이 아니라 "일부 제한이 적용됨"을 의미한다. 대안인 "$방향에 대해 격리되지 않음"은 명시된 방향에 제한이 적용되지 않음을 의미합니다. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 둘 다 한 파드에서 다른 파드로의 연결과 관련이 있다.
기본적으로 파드는 송신에 대해 격리되지 않으며 모든 아웃바운드 연결이 허용된다. 파드를 선택하고 정책 유형에 "Egress"가 있는 네트워크폴리시가 있는 경우 파드는 송신을 위해 격리되며, 이러한 정책이 송신을 위해 파드에 적용된다고 한다. 파드가 송신을 위해 격리된 경우, 파드에서 허용되는 유일한 연결은 송신을 위해 파드에 적용되는 일부 네트워크폴리시의 송신 목록에서 허용하는 연결이다. 이러한 송신 목록의 효과는 추가적으로 결합된다.
기본적으로 파드는 인그레스를 위해 격리되지 않으며 모든 인바운드 연결이 허용된다. 파드를 선택하고 정책 유형에 "인그레스"가 있는 네트워크폴리시가 있는 경우 파드는 인그레스를 위해 격리되며, 이러한 정책이 인그레스를 위해 파드에 적용된다고 한다. 파드가 인그레스를 위해 격리된 경우, 파드로의 유일한 허용 연결은 파드의 노드에서 온 연결과 인그레스를 위해 파드에 적용되는 일부 네트워크폴리시의 인그레스 목록에서 허용하는 연결이다. 이러한 인그레스 리스트의 효과는 부가적으로 결합된다.
네트워크 정책은 충돌하지 않고 추가적으로 결합된다. 특정 방향에 대해 특정 파드에 적용되는 정책이 하나 이상 있는 경우, 해당 파드에서 해당 방향으로 허용되는 연결은 해당 정책에서 허용하는 것의 합이다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않습니다.
소스 파드에서 대상 파드로의 연결이 허용되려면, 소스 파드의 송신 정책과 대상 파드의 수신 정책이 모두 연결을 허용해야 한다. 어느 한쪽에서 연결을 허용하지 않으면 연결이 이루어지지 않는다.
네트워크 폴리시 리소스 Network Policy Resource
리소스에 대한 전체 정의는 네트워크 정책 참조를 참조하세요.
네트워크폴리시 예시는 다음과 같습니다:
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
NOTE: 선택한 네트워킹 솔루션이 네트워크 정책을 지원하지 않는 한 클러스터의 API 서버에 이 내용을 게시해도 아무런 효과가 없습니다.
필수 필드
다른 모든 쿠버네티스 구성과 마찬가지로, 네트워크폴리시에는 apiVersion
, kind
및 metadata
필드가 필요하다. 컨피그 파일 작업에 대한 일반적인 정보는 컨피그맵을 사용하도록 파드 구성하기 및 오브젝트 관리를 참고한다.
spec
네트워크 정책 사양에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는 데 필요한 모든 정보가 있습니다.
podSelector
각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 podSelector
가 포함되어 있다. 예시 정책은 레이블이 "role=db"인 파드를 선택한다. 빈 podSelector
는 네임스페이스의 모든 파드를 선택한다.
policyTypes
각 네트워크폴리시에는 인그레스, 이그레스 또는 둘 다 포함될 수 있는 policyTypes
목록이 포함된다. policyTypes
필드는 지정된 정책이 선택한 파드로의 Ingress
트래픽, 선택한 파드로부터의 Egress
트래픽 또는 둘 다에 적용되는지 여부를 나타낸다. 네트워크폴리시에 policyTypes
이 지정되지 않은 경우, 기본적으로 Ingress
이 항상 설정되고 네트워크폴리시에 Egress
규칙이 있는 경우 송신이 설정된다.
Ingresss
각 네트워크폴리시에는 허용된 ingress
규칙 목록이 포함될 수 있습니다. 각 규칙은 from
및 ports
섹션과 일치하는 트래픽을 허용합니다. 예제 정책에는 단일 포트의 트래픽과 일치하는 단일 규칙이 포함되어 있는데, 첫 번째는 ipBlock
, 두 번째는 namespaceSelector
, 세 번째는 podSelector
로 지정된 세 가지 소스 중 하나로부터의 트래픽과 일치합니다.
egress
각 네트워크폴리시에는 허용된 egress
규칙 목록이 포함될 수 있습니다. 각 규칙은 to
및 ports
섹션과 일치하는 트래픽을 허용합니다. 예제 정책에는 단일 포트의 트래픽을 10.0.0.0/24
의 모든 대상과 일치시키는 단일 규칙이 포함되어 있습니다.
네트워크 정책 예제입니다.
- 수신 및 송신 트래픽 모두에 대해 기본 네임스페이스에서 role=db 파드를 격리한다(아직 격리되지 않은 경우).
- (인그레스 규칙)은 TCP 포트 6379에서 role=db 레이블이 있는 기본 네임스페이스의 모든 파드에 대한 연결을 허용한다:
rule=frontend
레이블이 있는default
네임스페이스의 모든 파드- 레이블이
project=myproject
인 네임스페이스의 모든 파드 172.17.0.0
-172.17.0.255
및172.17.2.0
-172.17.255.255
범위의 IP 주소(즉,172.17.0.0/16
에서172.17.1.0/24
를 제외한 모든172.17.0.0/16
)
- (송신 규칙)은
role=db
레이블이 있는default
네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR10.0.0.0/24
로 연결을 허용한다.