Kubernetes 네트워크 정책을 NSX 분산 방화벽 정책으로 변환

Antrea NSX 어댑터는 등록된 Antrea Kubernetes 클러스터의 Kubernetes 네트워크 정책을 NSX 인벤토리와 동기화합니다. 그러나 이러한 K8s 네트워크 정책은 NSX 환경에서 업데이트하거나 관리할 수 없습니다.

NSX에서 K8s 네트워크 정책을 편집하려면 NSX 환경으로 가져올 수 있습니다. 이 가져오기 기능은 NSX 4.2부터 사용할 수 있으며 NSX API에서만 지원됩니다.

K8s 네트워크 정책 가져오기 개요

가져오기 작업은 K8s 네트워크 정책을 동등한 트래픽 동작을 사용해서 NSX DFW(Distributed Firewall) 정책으로 변환합니다. K8s 네트워크 정책이 NSX DFW 정책으로 변환되면 NSX는 변환된 DFW 정책을 관리하기 위한 소스가 됩니다. 그런 다음, NSX Manager UI 또는 NSX API를 사용하여 DFW 정책을 편집할 수 있습니다.

이 변환은 단방향 작업입니다. NSX DFW 정책을 K8s 네트워크 정책으로 다시 변환할 수 없습니다.

중요: NSX 인벤토리에 NCP( NSX Container Plugin)에서 관리되는 Kubernetes 네트워크 정책이 포함되어 있으면 가져오기 기능이 지원되지 않습니다. NSX로 가져오려는 K8s 네트워크 정책은 Antrea CNI에서 관리되어야 합니다.

가져온 각 K8s 네트워크 정책은 하나 또는 두 개의 NSX DFW 정책으로 변환됩니다. 하나의 DFW 정책에는 모든 허용 규칙(K8s 네트워크 정책에 수신 또는 송신 규칙이 있는 경우)이 포함되고 다른 DFW 정책에는 기본 트래픽 삭제 규칙이 포함됩니다. 기본 삭제 규칙이 있는 DFW 정책은 항상 생성됩니다.

시스템은 NSX DFW 정책의 범위를 Antrea Kubernetes 클러스터로 설정합니다. 또한 DFW 정책의 범위는 Kubernetes 네임스페이스의 유효 포드 멤버가 포함된 Antrea 그룹으로 좀 더 제한됩니다.

변환된 DFW 정책은 NSX의 애플리케이션 계층에 배치됩니다. 가져오기 API는 애플리케이션 계층의 다른 기존 Antrea 정책 뒤에 변환된 DFW 정책을 추가합니다. 가져온 정책은 NSX의 기존 Antrea 정책이 적용된 다음에, Kubernetes 클러스터에서 기본적으로 정의된 ACNP(Antrea 클러스터 네트워크 정책) 및 ANP(Antrea 네트워크 정책)가 적용되기 전에 적용됩니다. K8s 네임스페이스 내의 원래 트래픽 동작은 NSX DFW 정책으로 변환한 후에도 유지됩니다.

Antrea CNI는 변환된 DFW 정책을 Kubernetes 클러스터의 Antrea 클러스터 네트워크 정책으로 인식합니다. 이러한 Antrea 클러스터 네트워크 정책은 이제 NSX에서 관리되며 NSX 환경에서만 편집할 수 있습니다. kubectl 명령줄을 사용하여 ACNP 구성을 편집하려고 하면 NSX에 존재하므로 Antrea NSX 어댑터에서 ACNP 변경 내용을 덮어쓰거나 원래 정책 정의로 되돌려 놓습니다.

K8s 네트워크 정책을 NSX로 성공적으로 가져온 후에 시스템은 K8s 인벤토리에서 원래 Kubernetes 네트워크 정책을 자동으로 삭제합니다. 또한 시스템은 변환된 DFW 정책에 K8s 클러스터의 이름, 원래 K8s 네트워크 정책 및 K8s 네임스페이스를 태그로 지정합니다. 이러한 태그는 NSX Manager UI에서 변환된 DFW 정책을 검색하는 데 도움이 될 수 있습니다. 또는 kubectl 명령줄에서 kubectl get acnp -o wide 명령을 실행하여 인식된 해당 ACNP의 태그(즉, K8s의 레이블)를 볼 수 있습니다.

K8s 네트워크 정책을 가져오기 위한 사전 요구 사항

Antrea Kubernetes 클러스터를 NSX 4.2 이상에 등록해야 합니다.
가져오기 기능을 사용하려면 VMware Container Networking™ with Antrea™ 1.9.0 이상에서 사용할 수 있는 Antrea-NSX 상호 작업 버전이 필요합니다.
시스템에 분산 방화벽 보안 정책을 구성할 수 있는 권한을 부여하는 적절한 보안 라이센스를 NSX 배포에 적용합니다.
NSX 환경의 기본 공간에서 엔터프라이즈 관리자 역할 또는 보안 관리자 역할이 할당됩니다.
Antrea NSX 어댑터에서 Kubernetes 네트워크 정책을 NSX 인벤토리에 보고했는지 확인합니다.
예를 들어 NSX Manager UI에서 확인하려면 다음 단계를 수행합니다.
1. 인벤토리 > 컨테이너 > 네임스페이스로 이동합니다.
2. 필요한 경우 CNI 유형을 Antrea로 지정하여 네임스페이스 목록을 필터링합니다.
3. 네임스페이스를 확장한 다음, 네트워크 정책 수를 클릭하여 Kubernetes 네트워크 정책이 NSX 인벤토리와 동기화되었는지 확인합니다.
  NSX에서 네임스페이스의 모든 Kubernetes 네트워크 정책을 읽고 있는지 확인하려면 UI에 표시된 개수를 다음 kubectl 명령으로 검색된 정책 수와 비교할 수 있습니다. 개수는 동일해야 합니다.
```
kubectl get networkpolicies -n <namespace>
```

K8s 네트워크 정책 필드를 NSX 분산 방화벽 정책 필드에 매핑

앞서 설명한 대로 Kubernetes 네트워크 정책을 NSX로 가져오면 시스템은 이 네트워크 정책을 하나 또는 두 개의 DFW 정책으로 변환합니다. 한 DFW 정책에는 모든 허용 규칙이 포함되어 있고 다른 DFW 정책에는 기본 삭제 트래픽 규칙이 포함되어 있습니다. 시스템은 K8s 네트워크 정책의 규격에 따라 Antrea 그룹을 생성합니다. Antrea 그룹은 변환된 DFW 정책의 소스, 대상 및 적용 대상 필드에 사용됩니다.

다음 표에서는 Kubernetes 네트워크 정책의 필드와 NSX 분산 방화벽 정책의 필드 매핑에 대해 설명합니다.

K8s 네트워크 정책의 필드	NSX 리소스	설명
K8s 네트워크 정책 자체	하나 또는 두 개의 DFW 정책	K8s 네트워크 정책의 `spec.ingress` 또는 `spec.egress`에 있는 모든 규칙이 DFW "허용" 정책에 추가됩니다. 즉, 이 DFW 정책의 모든 규칙에 대한 규칙 작업은 허용으로 설정됩니다. 기본 삭제 규칙이 있는 DFW 정책은 K8s 네트워크 정책의 `spec.policyTypes` 목록에 있는 값에 따라 수신 트래픽, 송신 트래픽 또는 수신 및 송신 트래픽을 삭제하는 규칙으로 생성됩니다. 예를 들어 K8s 네트워크 정책 규격의 `spec.policyTypes` 목록에 `egress`만 포함된 경우 DFW "삭제" 정책에는 송신 트래픽에 대한 기본 삭제 규칙(트래픽 방향: 송신)이 포함됩니다. Kubernetes 네트워크 정책에 수신 및 송신 규칙이 포함되어 있지 않으면 기본 삭제 규칙만 있는 DFW 정책이 생성됩니다.
`spec.podSelector` 및 `metadata.namespace`	Antrea 유형 그룹	`spec.podSelector` 및 `metadata.namespace` 모두 Antrea 그룹으로 변환하는 데 사용됩니다. 생성된 Antrea 그룹은 DFW "허용" 정책 및 DFW "삭제" 정책의 적용 대상에서 참조됩니다. `spec.podSelector`를 지정하지 않으면 Antrea 그룹에 네임스페이스만 포함됩니다.
`spec.ingress[]` 및 `spec.egress[]`	DFW "허용" 정책의 방화벽 규칙	K8s 네트워크 정책의 `spec.ingress` 및 `spec.egress` 섹션에 있는 각 규칙은 NSX DFW 규칙으로 변환됩니다. 이러한 DFW 규칙은 DFW "허용" 정책에 추가됩니다.
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	Antrea 유형 그룹	`ingress` `from` 섹션의 포드 및 네임스페이스 선택기는 동적 멤버 자격 조건이 있는 Antrea 그룹으로 변환됩니다. `ipBlock` 선택기에서 IP CIDR 범위는 Antrea 그룹의 고정 IP 주소 멤버로 변환됩니다. 이러한 Antrea 그룹은 DFW 규칙의 소스 필드에서 참조됩니다.
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	Antrea 유형 그룹	`egress` `to` 섹션의 포드 및 네임스페이스 선택기는 동적 멤버 자격 조건이 있는 Antrea 그룹으로 변환됩니다. `ipBlock` 선택기에서 IP CIDR 범위는 Antrea 그룹의 고정 IP 주소 멤버로 변환됩니다. 이러한 Antrea 그룹은 DFW 규칙의 대상 필드에서 참조됩니다.
`spec.ingress[].ports` `protocol` `port` 및 `spec.egress[].ports` `protocol` `port`	DFW 규칙의 서비스 항목	K8s 네트워크 정책의 수신 및 송신 규칙 규격에서 계층 4 프로토콜 및 대상 포트(대상 포트 범위 포함)는 DFW 규칙에서 서비스 항목으로 변환됩니다. K8s 규칙 규격의 대상 포트 또는 포트 범위는 항상 서비스 항목의 대상 포트에 매핑됩니다.

필드 매핑의 예

이 섹션에는 K8s 네트워크 정책을 NSX로 가져올 때 Kubernetes 네트워크 정책의 필드가 DFW 정책의 필드로 어떻게 매핑되는지 이해하는 데 도움이 되는 몇 가지 예가 포함되어 있습니다.

예 1

K8s 네트워크 정책 규격:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns1
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp1
  namespace: my-ns1
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 8.8.8.8/32
      ports:
        - protocol: UDP
          port: 53

이 K8s 네트워크 정책은 my-ns1 네임스페이스의 모든 포드를 선택하고 이 네임스페이스의 모든 포드에서 UDP 포트 53의 8.8.8.8/32 CIDR로 송신 트래픽(송신 연결)을 허용합니다. 이 네임스페이스의 포드에서의 다른 모든 송신 트래픽은 삭제됩니다.

이 K8s 네트워크 정책을 NSX로 가져오면 두 개의 DFW 정책이 생성됩니다. 한 DFW 정책에는 단일 허용 규칙이 포함되어 있고 다른 DFW 정책에는 단일 삭제 규칙이 포함되어 있습니다.

spec.podSelector 섹션은 동적 멤버 자격 조건이 있는 Antrea 그룹으로 변환됩니다. 그룹의 이 조건은 my-ns1 네임스페이스의 모든 포드를 선택합니다. 이 Antrea 그룹은 DFW 허용 정책과 DFW 삭제 정책 모두의 적용 대상 필드에서 참조됩니다.

spec.egress.to 섹션의 ipBlock 선택기는 고정 IP 주소 멤버가 8.8.8.8/32인 Antrea 그룹으로 변환됩니다. 이 Antrea 그룹은 DFW 허용 규칙의 대상 필드에서 참조됩니다. 이 그룹을 Group-1로 나타냅니다.

spec.egress.ports 섹션은 UDP 프로토콜 및 대상 포트 53이 있는 서비스 항목으로 변환됩니다.

NSX의 DFW 허용 규칙 구성은 다음과 같습니다.

소스	대상	서비스	컨텍스트 프로파일	규칙 적용 대상	규칙 작업	규칙 방향
해당 없음	Group-1	UDP 소스: 임의, 대상: 53	해당 없음	임의	허용	송신

소스

대상

서비스

컨텍스트 프로파일

규칙 적용 대상

규칙 작업

규칙 방향

해당 없음

Group-1

UDP

소스: 임의, 대상: 53

해당 없음

임의

허용

송신

NSX의 DFW 삭제 규칙 구성은 다음과 같습니다.

소스	대상	서비스	컨텍스트 프로파일	규칙 적용 대상	규칙 작업	규칙 방향
임의	임의	임의	해당 없음	임의	삭제	송신

예 2

K8s 네트워크 정책 규격:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns2
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp2
  namespace: my-ns2
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

이 Kubernetes 네트워크 정책은 my-ns2 네임스페이스의 모든 포드를 선택하고 이러한 포드의 모든 수신 트래픽 및 송신 트래픽을 삭제합니다. 이 정책은 기본적으로 네임스페이스에 대한 모든 수신 및 송신 트래픽의 기본 삭제를 생성합니다.

이 K8s 네트워크 정책을 NSX로 가져오면 DFW 삭제 정책이 하나만 생성됩니다. 변환된 DFW 정책에는 삭제 작업이 있는 단일 방화벽 규칙이 포함되어 있습니다.

spec.podSelector 섹션은 동적 멤버 자격 조건이 있는 Antrea 그룹으로 변환됩니다. 그룹의 이 조건은 my-ns2 네임스페이스의 모든 포드를 선택합니다. 이 Antrea 그룹은 DFW 삭제 정책의 적용 대상 필드에서 참조됩니다.

NSX의 DFW 삭제 규칙 구성은 다음과 같습니다.

소스	대상	서비스	컨텍스트 프로파일	규칙 적용 대상	규칙 작업	규칙 방향
임의	임의	임의	해당 없음	임의	삭제	In_Out

변환된 DFW 정책 및 Antrea 그룹의 이름 지정 규칙

시스템은 변환된 DFW 허용 및 삭제 정책에 대해 다음과 같은 이름 지정 규칙을 사용합니다.

DFW 허용 정책: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-allow
DFW 삭제 정책: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-drop

cluster_name, namespace 및 K8s_networkpolicy_name 값은 각각 12바이트로 잘립니다.

시스템은 Antrea 그룹에 대해 다음과 같은 이름 지정 규칙을 사용합니다.

DFW 허용 및 삭제 정책의 [적용 대상] 필드에서 참조되는 그룹: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>
DFW 규칙의 [소스] 필드에서 참조되는 그룹: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-from-<peer index>
DFW 규칙의 [대상] 필드에서 참조되는 그룹: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-to-<peer index>

cluster_name 및 namespace 값은 각각 12바이트로 잘립니다.

시스템이 Antrea 그룹 이름의 규칙 인덱스 및 피어 인덱스에 값을 할당하는 방법을 이해하려면 세 가지 수신 규칙이 포함된 K8s 네트워크 정책의 다음 예를 고려합니다.

예

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp3
  namespace: my-ns3
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

다음과 같은 첫 번째 ingress.from 규칙의 일부를 살펴보겠습니다.

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80

이 수신 규칙의 from 섹션에는 두 가지 요소가 포함되어 있습니다. 한 요소는 네임스페이스 선택기를 사용하여 포드를 선택하고 다른 요소는 포드 선택기를 사용하여 포드를 선택합니다. 이러한 두 요소를 피어라고 합니다.

시스템은 규칙의 각 피어에 대해 하나의 Antrea 그룹을 생성합니다. 변환된 DFW 규칙에 규칙 인덱스 0이 있으며 이 규칙의 소스 필드에 두 개의 Antrea 그룹이 포함됩니다. 다음과 같이 한 Antrea 그룹 이름에는 피어 인덱스 0이 있고 다른 그룹 이름에는 피어 인덱스 1이 있습니다.

<cluster_name>-my-ns3-knp3-rule[0]-from-0

<cluster_name>-my-ns3-knp3-rule[0]-from-1

이제 다음과 같이 두 번째 및 세 번째 ingress.from 규칙의 일부를 고려하십시오.

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

이러한 두 수신 규칙의 from 섹션에는 네임스페이스 선택기를 사용하여 포드를 선택하는 단일 요소만 포함되어 있습니다. 변환된 DFW 규칙에는 각각 규칙 인덱스 1과 2가 있으며 각 규칙의 소스 필드에 단일 Antrea 그룹이 포함됩니다. 이 경우 피어 인덱스가 Antrea 그룹의 이름에 추가되지 않습니다. 그룹 이름은 다음과 같습니다.

<cluster_name>-my-ns3-knp3-rule[1]-from

<cluster_name>-my-ns3-knp3-rule[2]-from

API를 사용한 개략적인 가져오기 워크플로

이 설명서의 앞부분에서 설명한 대로 Kubernetes 네트워크 정책을 가져오기 위한 사전 요구 사항을 충족했는지 확인합니다.
다음 kubectl 명령을 실행하여 지정된 네임스페이스의 Kubernetes 네트워크 정책 목록을 봅니다.
```
kubectl get networkpolicies -n <namespace>
```
예:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       82m
k-np11   app=myapp      82m
k-np12   app=demo       82m
k-np9    app=myapp      82m
```
이 예에서 test-ns5 네임스페이스에는 4개의 Kuberentes 네트워크 정책이 포함되어 있습니다. 이 절차에서는 "k-np9" 및 "k-np11" 정책을 NSX로 가져옵니다.
다음 kubectl 명령을 실행하여 가져올 각 Kubernetes 네트워크 정책의 ID를 검색합니다.
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
예를 들어 "k-np9" 및 "k-np11" 네트워크 정책의 ID를 검색하려면 다음 명령을 실행합니다.
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
이러한 두 kubectl 명령의 출력에서 metadata.uid 필드에 표시되는 ID를 기록해 둡니다. K8s 클러스터에서 정책 ID는 다음과 같습니다.
- k-np9: e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- k-np11: 84b850fb-69ad-4e95-a563-a95ce6b70557
이러한 정책 ID는 예시 용도로만 사용됩니다. 사용자의 K8s 클러스터에서는 다를 수 있습니다. 다음 단계에서 설명하는 가져오기 API를 실행하려면 이러한 정책 ID가 필요합니다.

다음 NSX API를 실행하여 Kubernetes 네트워크 정책을 가져옵니다.

예:

POST https://<nsx-mgr>/policy/api/v1/infra/import-k8s-np-to-dfw?on_error=ABORT  -k
{
    "network_policy_ids" : ["e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d", "84b850fb-69ad-4e95-a563-a95ce6b70557"],
    "sequence_number_upper" : 1000,
    "sequence_number_lower" : 2000
}

network_policy_ids 매개 변수는 필수이지만 sequence_number_upper 및 sequence_number_lower 매개 변수는 선택 사항입니다.

이 예에서는 NSX로 가져오기 위해 K8s 네트워크 정책의 ID(k-np9 및 k-np11)가 지정됩니다.

이러한 요청 매개 변수, API 예제 요청 및 API 예제 응답에 대한 자세한 내용은 "NSX API 가이드" 항목을 참조하십시오.

on_error 쿼리 매개 변수는 오류가 발생할 때 API가 수행해야 하는 작업을 결정합니다. 다음 표에서는 이 쿼리 매개 변수의 유효한 값을 설명합니다.

값	설명
중단	이 값은 기본값입니다. K8s 네트워크 정책을 가져오는 동안 오류가 발생하면 변환된 모든 DFW 정책 및 Antrea 그룹이 커밋되지 않습니다. 가져오기 작업이 중간에 종료되고 K8s 네트워크 정책이 변환되지 않습니다. API 응답은 오류를 야기한 각 K8s 네트워크 정책에 대한 오류 메시지를 반환합니다. 예: API 요청 본문에 두 K8s 네트워크 정책(예: knp1 및 knp2)의 UUID를 지정했다고 가정합니다. knp1 정책의 송신 규칙 규격에는 지원되지 않는 SCTP 프로토콜이 포함되어 있습니다. 가져오기 API를 실행할 경우 knp1 네트워크 정책을 변환하면 오류가 발생하고 가져오기 작업이 중간에 종료됩니다. 이 네트워크 정책이 유효하더라도 시스템에서는 다음 K8s 네트워크 정책(knp2)을 변환하지 않습니다.
계속	현재 K8s 네트워크 정책을 가져오는 동안 오류가 발생하면 시스템에서 이 정책을 건너뛰고 다음 K8s 네트워크 정책을 계속 가져옵니다. API 응답은 가져오기 작업 중에 건너뛴 각 K8s 네트워크 정책에 대한 오류 메시지를 반환합니다. 경고: 가져온 K8s 네트워크 정책과 건너뛴 K8s 네트워크 정책이 동일한 포드에 적용되는 경우 트래픽 동작이 변경될 수 있습니다. 예: 이전 행에 언급된 것과 동일한 예제를 계속 진행합니다. knp1 네트워크 정책 가져오기 동안 오류가 발생해도 시스템은 knp2 네트워크 정책을 계속 가져오고 이 네트워크 정책을 성공적으로 변환합니다. API 응답은 변환 중에 실패한 knp1 네트워크 정책에 대해 동일한 오류 메시지를 반환합니다.

값

설명

중단

이 값은 기본값입니다.

K8s 네트워크 정책을 가져오는 동안 오류가 발생하면 변환된 모든 DFW 정책 및 Antrea 그룹이 커밋되지 않습니다. 가져오기 작업이 중간에 종료되고 K8s 네트워크 정책이 변환되지 않습니다. API 응답은 오류를 야기한 각 K8s 네트워크 정책에 대한 오류 메시지를 반환합니다.

예:

API 요청 본문에 두 K8s 네트워크 정책(예: knp1 및 knp2)의 UUID를 지정했다고 가정합니다. knp1 정책의 송신 규칙 규격에는 지원되지 않는 SCTP 프로토콜이 포함되어 있습니다. 가져오기 API를 실행할 경우 knp1 네트워크 정책을 변환하면 오류가 발생하고 가져오기 작업이 중간에 종료됩니다. 이 네트워크 정책이 유효하더라도 시스템에서는 다음 K8s 네트워크 정책(knp2)을 변환하지 않습니다.

계속

현재 K8s 네트워크 정책을 가져오는 동안 오류가 발생하면 시스템에서 이 정책을 건너뛰고 다음 K8s 네트워크 정책을 계속 가져옵니다. API 응답은 가져오기 작업 중에 건너뛴 각 K8s 네트워크 정책에 대한 오류 메시지를 반환합니다.

경고: 가져온 K8s 네트워크 정책과 건너뛴 K8s 네트워크 정책이 동일한 포드에 적용되는 경우 트래픽 동작이 변경될 수 있습니다.

예:

이전 행에 언급된 것과 동일한 예제를 계속 진행합니다. knp1 네트워크 정책 가져오기 동안 오류가 발생해도 시스템은 knp2 네트워크 정책을 계속 가져오고 이 네트워크 정책을 성공적으로 변환합니다. API 응답은 변환 중에 실패한 knp1 네트워크 정책에 대해 동일한 오류 메시지를 반환합니다.

단일 API 요청에서 가져오는 K8s 네트워크 정책은 등록된 다른 Antrea Kubernetes 클러스터에 속할 수 있습니다. 또는 단일 Antrea Kubernetes 클러스터 내의 여러 네임스페이스에 속할 수 있습니다.

네임스페이스에 여러 K8s 네트워크 정책이 포함된 경우 단일 API 요청으로 가져오는 것이 좋습니다. 그 이유는 네임스페이스 내의 K8s 네트워크 정책이 서로 관련될 수 있기 때문입니다. 이 방식은 네트워크 정책을 NSX로 가져온 후 트래픽 동작이 변경되지 않도록 하는 데 도움이 됩니다.

가져오기가 성공하면 NSX Manager UI로 이동하고 Antrea 그룹 및 DFW 정책의 구성을 확인합니다.
선택 사항: 구현된 Antrea 클러스터 네트워크 정책을 보고, 다음과 같은 kubectl 명령을 실행하여 ACNP 규격 및 ClusterGroup 규격을 확인합니다.
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
선택 사항: 다음 kubectl 명령을 실행하여 NSX로 성공적으로 가져온 K8s 네트워크 정책이 K8s 클러스터에 표시되지 않는지 확인합니다.
```
kubectl get networkpolicies -n <namespace>
```
이 예제에서는 다음과 같은 명령을 사용합니다.
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
가져온 Kubernetes 네트워크 정책(k-np9 및 k-np11)이 K8s 클러스터에 더 이상 표시되지 않는지 확인합니다.

지원되지 않는 Kubernetes 네트워크 정책 기능

Kubernetes 네트워크 정책의 일부 기능은 현재 NSX DFW 정책 및 Antrea 그룹으로의 변환이 지원되지 않습니다. 다음과 같은 지원되지 않는 기능으로 인해 변환이 실패하면 API 응답에 적절한 오류 메시지가 표시됩니다.

포드에 대해 계층 4 포트 이름을 사용하는 K8s 네트워크 정책은 변환되지 않습니다. DFW 정책은 포트 번호만 지원합니다.
SCTP 프로토콜이 포함된 K8s 네트워크 정책은 변환되지 않습니다. NSX DFW 정책은 SCTP 트래픽을 지원하지 않습니다.
K8s 네트워크 정책에는 podSelector 또는 NetworkPolicyPeer 섹션에 많은 수의 matchLabels 또는 matchExpressions가 있을 수 있습니다. 그러나 Antrea 그룹의 동적 멤버 자격 조건은 멤버 유형이 혼합된 경우 최대 15개 조건, 멤버 유형이 동일한 경우 최대 5개 조건을 지원할 수 있습니다. 그룹 멤버 자격 조건에서 이 최대 제한을 초과하면 변환이 실패합니다.
DoesNotExist 연산자가 있는 matchExpressions를 포함하는 Kubernetes 네트워크 정책은 Antrea 그룹으로 변환되지 않습니다. Kubernetes의 DoesNotExist 연산자가 NSX에서 범위 연산자의 NotEquals 값에 매핑됩니다. 그러나 Antrea 그룹 정의의 범위 연산자는 현재 이 값을 지원하지 않습니다.
In 연산자가 있는 matchExpressions를 포함하는 Kubernetes 네트워크 정책에는 변환이 성공하려면 단일 값만 포함되어야 합니다. In 연산자의 여러 값은 현재 Antrea 그룹으로 변환하는 데 지원되지 않습니다.

Antrea NSX 어댑터 버전이 다른 경우의 동작

Antrea NSX 어댑터 및 NSX를 순서에 관계없이 따로 업그레이드할 수 있습니다. Antrea NSX 어댑터의 새로운 변경 사항은 4.2 이전의 NSX 버전과 호환됩니다.

다음과 같은 시나리오를 고려해야 합니다.

NSX 환경은 버전 4.2이며 여러 Antrea Kubernetes 클러스터가 등록되어 있습니다. 새 버전의 Antrea NSX 어댑터(예: v0.15)가 있는 Kubernetes 클러스터도 있고 이전 버전의 Antrea NSX 어댑터(예: v0.11)가 있는 Kubernetes 클러스터도 있습니다. 이 경우 변환한 후 이전 버전의 Antrea NSX 어댑터는 Kubernetes 클러스터에서 원래 Kubernetes 네트워크 정책을 자동으로 삭제하지 않습니다. Kubernetes 관리자 또는 네임스페이스 관리자는 원래 Kubernetes 네트워크 정책을 수동으로 삭제해야 합니다. DFW 정책으로의 변환은 계속 수행됩니다. 변환된 DFW 허용 정책 및 기본 삭제 정책은 Kubernetes 클러스터에서 Antrea 클러스터 네트워크 정책으로 인식되며 원래 Kubernetes 네트워크 정책보다 먼저 Antrea CNI에서 평가됩니다. 원래 Kubernetes 정책이 Kubernetes 클러스터에서 삭제되지 않으면 변환된 DFW 정책에 정의된 트래픽 동작이 원래 Kubernetes 네트워크 정책과 충돌할 수 있습니다.