다중 네트워크

프로세스

1. 선택 사항: 기본 네트워크를 사용하는 ClusterUserDefinedNetwork CR의 경우 다음 명령을 입력하여 k8s.ovn.org/primary-user-defined-network 레이블이 있는 네임스페이스를 만듭니다.

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: <cudn_namespace_name>
     labels:
       k8s.ovn.org/primary-user-defined-network: ""
   EOF

2. Layer2 또는 Layer3 토폴로지 유형에 대한 클러스터 전체 사용자 정의 네트워크를 만듭니다.

   1. 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의하려면 cluster-layer-two-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchLabels:
            "<label_1_key>": "<label_1_value>"
            "<label_2_key>": "<label_2_value>"
        network:
          topology: Layer2
          layer2:
            role: Primary
            subnets:
              - "2001:db8::/64"
              - "10.100.0.0/16"

      다음과 같습니다.

      이름

      ClusterUserDefinedNetwork CR의 이름을 지정합니다.

      namespaceSelector

      CUDN CR이 적용되는 네임스페이스 집합에 대한 레이블 쿼리를 지정합니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default 또는 openshift-* 네임스페이스를 가리켜서는 안 됩니다.

      matchLabels

      AND 관계로 용어를 평가하는 matchLabels 선택기 유형을 사용합니다. 이 예에서 CUDN CR은 <label_1_ key>=<label_1_value> 및 <label _2_key>=<label_2_value > 라벨이 모두 포함된 네임스페이스에 배포됩니다.

      network

      네트워크 구성을 설명합니다.

      토폴로지

      이 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2 및 Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다. 이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 일 수 있습니다.

      role

      기본 또는 보조를 지정합니다. Primary는 4.19에서 지원되는 유일한 역할 사양입니다.

      subnets

      Layer2 토폴로지 유형의 경우 다음은 필드에 대한 구성 세부 정보를 지정합니다.

      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1~2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/16 및 2001:db8::/64입니다 .
      • Layer2 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "정적 IP 주소로 Pod 구성"을 참조하세요.

   2. 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의하려면 cluster-layer-three-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: In
            values: ["<example_namespace_one>", "<example_namespace_two>"]
        network:
          topology: Layer3
          layer3:
            role: Primary
            subnets:
              - cidr: 10.100.0.0/16
                hostSubnet: 24

      다음과 같습니다.

      이름

      ClusterUserDefinedNetwork CR의 이름을 지정합니다.

      namespaceSelector

      CUDN CR이 적용되는 네임스페이스 집합에 대한 레이블 쿼리를 지정합니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default 또는 openshift-* 네임스페이스를 가리켜서는 안 됩니다. terms는 OR 관계로 평가되는 matchExpressions 선택기 유형을 사용합니다.

      키

      일치시킬 레이블 키를 지정합니다. 연산자 값을 사용합니다. 유효한 값은 다음과 같습니다. ,Not In ,Exists 및 DoesNotExist. matchExpressions 유형이 사용되므로 또는 <example_namespace_two> 와 일치하는 <example_namespace_one> 네임스페이스를 프로비저닝합니다.

      network

      네트워크 구성을 설명합니다.

      토폴로지

      토폴로지 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2 와 Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 다른 서브넷을 갖는 Layer 2 세그먼트가 생성됩니다. 3계층 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.

      role

      기본 또는 보조를 지정합니다. Primary는 4.19에서 지원되는 유일한 역할 사양입니다.

      subnets

      Layer3 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.

      • 서브넷 필드는 필수입니다.

      • 서브넷 필드의 유형은 cidr 및 hostSubnet 입니다.

        • cidr 은 클러스터 서브넷이며 문자열 값을 허용합니다.
        • hostSubnet은 클러스터 서브넷이 분할되는 노드 서브넷 접두사를 지정합니다.
        • IPv6의 경우 hostSubnet 에 대해 /64 길이만 지원됩니다.

3. 다음 명령을 실행하여 요청을 적용하세요.

   $ oc create --validate=true -f <example_cluster_udn>.yaml

   여기서 <example_cluster_udn>.yaml은 Layer2 또는 Layer3 구성 파일의 이름입니다.

4. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

   $ oc get clusteruserdefinednetwork <cudn_name> -o yaml

   여기서 <cudn_name> 은 클러스터 전체 사용자 정의 네트워크에 대해 생성한 이름입니다.

   출력 예

   apiVersion: k8s.ovn.org/v1
   kind: ClusterUserDefinedNetwork
   metadata:
     creationTimestamp: "2024-12-05T15:53:00Z"
     finalizers:
     - k8s.ovn.org/user-defined-network-protection
     generation: 1
     name: my-cudn
     resourceVersion: "47985"
     uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
   spec:
     namespaceSelector:
       matchExpressions:
       - key: custom.network.selector
         operator: In
         values:
         - example-namespace-1
         - example-namespace-2
         - example-namespace-3
     network:
       layer3:
         role: Primary
         subnets:
         - cidr: 10.100.0.0/16
       topology: Layer3
   status:
     conditions:
     - lastTransitionTime: "2024-11-19T16:46:34Z"
       message: 'NetworkAttachmentDefinition has been created in following namespaces:
         [example-namespace-1, example-namespace-2, example-namespace-3]'
       reason: NetworkAttachmentDefinitionReady
       status: "True"
       type: NetworkCreated

프로세스

1. Localnet 토폴로지를 사용하여 클러스터 전체 사용자 정의 네트워크를 만듭니다.

   1. 다음 예와 같이 Localnet 토폴로지에 대한 요청을 정의하려면 cluster-udn-localnet.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchLabels:
            "<label_1_key>": "<label_1_value>"
            "<label_2_key>": "<label_2_value>"
        network:
          topology: Localnet
          localnet:
            role: Secondary
            physicalNetworkName: test
            ipam: {lifecycle: Persistent}
            subnets: ["192.168.0.0/16", "2001:dbb::/64"]

      다음과 같습니다.

      이름

      ClusterUserDefinedNetwork CR의 이름을 지정합니다.

      namespaceSelector

      CUDN CR이 적용되는 네임스페이스 집합에 대한 레이블 쿼리를 지정합니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default 또는 openshift-* 네임스페이스를 가리켜서는 안 됩니다.

      matchLabels

      AND 관계로 용어를 평가하는 matchLabels 선택기 유형을 사용합니다. 이 예에서 CUDN CR은 <label_1_ key>=<alabel_1_value> 및 <label _2_key>=<label_2_value > 라벨이 모두 포함된 네임스페이스에 배포됩니다.

      network

      네트워크 구성을 설명합니다.

      토폴로지

      Localnet 토폴로지 유형을 지정하면 하나의 공급자 네트워크에 직접 연결되는 하나의 논리적 스위치가 생성됩니다.

      role

      네트워크 구성에 대한 역할을 지정합니다. 보조 역할 은 로컬넷 토폴로지에 지원되는 유일한 역할 사양입니다.

      subnets

      로컬넷 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.

      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1~2개의 항목이 허용됩니다. 두 항목은 서로 다른 IP 패밀리에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/16 및 2001:db8::/64입니다 .
      • localnet 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "정적 IP 주소로 Pod 구성"을 참조하세요.

2. 다음 명령을 실행하여 요청을 적용하세요.

   $ oc create --validate=true -f <example_cluster_udn>.yaml

   다음과 같습니다.

   <example_cluster_udn>.yaml

   Localnet 구성 파일의 이름입니다.

3. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

   $ oc get clusteruserdefinednetwork <cudn_name> -o yaml

   다음과 같습니다.

   <cudn_name>

   클러스터 전체 사용자 정의 네트워크에 대해 만든 이름입니다.

프로세스

1. 관리자 관점에서 네트워킹 → 사용자 정의 네트워크를 클릭합니다.
2. ClusterUserDefinedNetwork를 클릭합니다.
3. 이름 필드에서 클러스터 범위 UDN의 이름을 지정합니다.
4. 서브넷 필드에 값을 지정합니다.
5. 프로젝트 일치 레이블 필드에서 클러스터 UDN이 적용되는 네임스페이스를 선택하기 위해 적절한 레이블을 추가합니다.
6. 생성을 클릭합니다. 클러스터 범위 UDN은 5단계에서 지정한 레이블이 포함된 네임스페이스에 있는 포드의 기본 기본 네트워크 역할을 합니다.

프로세스

1. 선택 사항: 기본 네트워크를 사용하는 UserDefinedNetwork CR의 경우 다음 명령을 입력하여 k8s.ovn.org/primary-user-defined-network 레이블이 있는 네임스페이스를 만듭니다.

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: <udn_namespace_name>
     labels:
       k8s.ovn.org/primary-user-defined-network: ""
   EOF

2. Layer2 또는 Layer3 토폴로지 유형에 대한 사용자 정의 네트워크를 만듭니다.

   1. 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의하려면 my-layer-two-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-1
        namespace: <some_custom_namespace>
      spec:
        topology: Layer2
        layer2: 

      1

      
          role: Primary
          subnets:
            - "10.0.0.0/24"
            - "2001:db8::/60"

      다음과 같습니다.

      name

      UserDefinedNetwork 리소스의 이름입니다. 이는 기본값이어서 는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.

      토폴로지

      네트워크 구성을 지정합니다. 허용되는 값은 Layer2 및 Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다.

      role

      기본 또는 보조 역할을 지정합니다.

      subnets

      Layer2 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.

      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1~2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/16 및 2001:db8::/64입니다 .
      • Layer2 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다.
      • ipamLifecycle 필드가 지정된 경우 Layer2 서브넷 필드는 필수입니다.

   2. 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의하려면 my-layer-three-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-2-primary
        namespace: <some_custom_namespace>
      spec:
        topology: Layer3
        layer3:
          role: Primary
          subnets:
            - cidr: 10.150.0.0/16
              hostSubnet: 24
            - cidr: 2001:db8::/60
              hostSubnet: 64
      # ...

      다음과 같습니다.

      name

      UserDefinedNetwork 리소스의 이름입니다. 이는 기본값이어서 는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.

      토폴로지

      네트워크 구성을 지정합니다. 허용되는 값은 Layer2 및 Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다.

      role

      기본 또는 보조 역할을 지정합니다.

      subnets

      Layer3 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.

      • 서브넷 필드는 필수입니다.

      • 서브넷 필드의 유형은 cidr 및 hostSubnet 입니다.

        • cidr은 클러스터의 clusterNetwork 구성 설정과 동일합니다. CIDR의 IP 주소는 사용자 정의 네트워크의 포드에 배포됩니다. 이 매개변수는 문자열 값을 허용합니다.
        • hostSubnet은 노드별 서브넷 접두사를 정의합니다.
        • IPv6의 경우 hostSubnet 에 대해 /64 길이만 지원됩니다.

3. 다음 명령을 실행하여 요청을 적용하세요.

   $ oc apply -f <my_layer_two_udn>.yaml

   여기서 <my_layer_two_udn>.yaml은 Layer2 또는 Layer3 구성 파일의 이름입니다.

4. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

   $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

   여기서 some_custom_namespace 는 사용자 정의 네트워크에 대해 생성한 네임스페이스입니다.

   출력 예

   apiVersion: k8s.ovn.org/v1
   kind: UserDefinedNetwork
   metadata:
     creationTimestamp: "2024-08-28T17:18:47Z"
     finalizers:
     - k8s.ovn.org/user-defined-network-protection
     generation: 1
     name: udn-1
     namespace: some-custom-namespace
     resourceVersion: "53313"
     uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c
   spec:
     layer2:
       role: Primary
       subnets:
       - 10.0.0.0/24
       - 2001:db8::/60
     topology: Layer2
   status:
     conditions:
     - lastTransitionTime: "2024-08-28T17:18:47Z"
       message: NetworkAttachmentDefinition has been created
       reason: NetworkAttachmentDefinitionReady
       status: "True"
       type: NetworkCreated

프로세스

1. 관리자 관점에서 네트워킹 → 사용자 정의 네트워크를 클릭합니다.
2. 사용자 정의 네트워크 만들기를 클릭합니다.
3. 프로젝트 이름 목록에서 이전에 만든 네임스페이스를 선택합니다.
4. 서브넷 필드에 값을 지정합니다.
5. 생성을 클릭합니다. 사용자 정의 네트워크는 이 네임스페이스에서 생성하는 포드의 기본 기본 네트워크 역할을 합니다.

프로세스

1. Pod 리소스 정의를 편집합니다. 기존 Pod 리소스를 편집하는 경우 다음 명령을 실행하여 기본 편집기에서 정의를 편집합니다. <name>을 편집할 Pod 리소스의 이름으로 교체합니다.

   $ oc edit pod <name>

2. Pod 리소스 정의에서 k8s.v1.cni.cncf.io/networks 매개변수를 Pod metadata 매핑에 추가합니다. k8s.v1.cni.cncf.io/networks는 추가 특성을 지정하는 것 외에도 NetworkAttachmentDefinition Custom Resource(CR) 이름을 참조하는 오브젝트 목록의 JSON 문자열을 허용합니다.

   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'
   # ...

   다음과 같습니다.

   <network>

   다음 예제와 같이 JSON 객체로 바꾸세요. 작은 따옴표를 사용해야 합니다.

   다음 예에서 주석은 default-route 매개변수를 사용하여 기본 경로로 지정될 네트워크 연결을 지정합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
       {
         "name": "net1"
       },
       {
         "name": "net2",
         "default-route": ["192.0.2.1"]
       }]'
   spec:
     containers:
     - name: example-pod
       command: ["/bin/bash", "-c", "sleep 2000000000000"]
       image: centos/tools

   다음과 같습니다.

   net1, net2

   Pod와 연결할 보조 네트워크를 정의하는 NetworkAttachmentDefinition 리소스의 이름을 지정합니다.

   192.0.2.1

   라우팅 테이블에 다른 라우팅 항목이 없는 경우 트래픽이 라우팅될 게이트웨이 값을 지정합니다. default-route 키가 두 개 이상 지정되면 Pod가 활성화되지 않습니다.

   기본 경로는 다른 경로에 지정되지 않은 모든 트래픽이 게이트웨이로 라우팅되도록 합니다.

   중요

   OpenShift Container Platform의 기본 네트워크 인터페이스 이외의 인터페이스로 기본 경로를 설정하면 Pod 사이에서 트래픽이 라우팅될 것으로 예상되는 트래픽이 다른 인터페이스를 통해 라우팅될 수 있습니다.

   Pod의 라우팅 속성을 확인하려면 oc 명령을 사용하여 Pod에서 ip 명령을 실행하십시오.

   $ oc exec -it <pod_name> -- ip route

   참고

   JSON 형식의 오브젝트 목록에 default-route 키가 있으면 Pod의 k8s.v1.cni.cncf.io/networks-status를 참조하여 어떤 추가 네트워크에 기본 경로가 할당되었는지를 확인할 수도 있습니다.

   Pod의 고정 IP 주소 또는 MAC 주소를 설정하려면 JSON 형식의 주석을 사용하면 됩니다. 이를 위해서는 이러한 기능을 특별하게 허용하는 네트워크를 생성해야 합니다. 이는 다음과 같이 CNO의 rawCNIConfig에서 지정할 수 있습니다.

3. 다음 명령을 실행하여 CNO CR을 편집합니다.

   $ oc edit networks.operator.openshift.io cluster

   다음 YAML은 CNO의 구성 매개변수를 설명합니다.

   CNO(Cluster Network Operator) YAML 구성

   name: <name>
   namespace: <namespace>
   rawCNIConfig: '{
     ...
   }'
   type: Raw

   다음과 같습니다.

   name

   생성할 보조 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.

   네임스페이스

   네트워크 연결을 생성할 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.

   rawCNIConfig

   다음 템플릿을 기반으로 하는 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

   다음 오브젝트는 macvlan CNI 플러그인을 사용하여 고정 MAC 주소 및 IP 주소를 사용하기 위한 구성 매개변수를 설명합니다.

   고정 IP 및 MAC 주소를 사용하는 macvlan CNI 플러그인 JSON 구성 오브젝트

   {
     "cniVersion": "0.3.1",
     "name": "<name>",
     "plugins": [{
         "type": "macvlan",
         "capabilities": { "ips": true },
         "master": "eth0",
         "mode": "bridge",
         "ipam": {
           "type": "static"
         }
       }, {
         "capabilities": { "mac": true },
         "type": "tuning"
       }]
   }

   다음과 같습니다.

   name

   생성할 보조 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.

   plugins

   CNI 플러그인 구성의 배열을 지정합니다. 첫 번째 오브젝트는 macvlan 플러그인 구성을 지정하고, 두 번째 오브젝트는 튜닝 플러그인 구성을 지정합니다.

   ips

   CNI 플러그인 런타임 구성 기능의 고정 IP 주소 기능 사용을 요청하도록 지정합니다.

   master

   macvlan 플러그인이 사용하는 인터페이스를 지정합니다.

   mac

   CNI 플러그인의 정적 MAC 주소 기능을 활성화하기 위한 요청이 이루어지도록 지정합니다.

   그런 다음 위의 네트워크 연결을 키와 함께 JSON 형식 주석에서 참조하여 지정된 Pod에 할당할 고정 IP 및 MAC 주소를 지정할 수 있습니다.

4. 다음 명령어를 입력하여 Pod를 편집하세요.

   $ oc edit pod <name>

   고정 IP 및 MAC 주소를 사용하는 macvlan CNI 플러그인 JSON 구성 오브젝트

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
         {
           "name": "<name>",
           "ips": [ "192.0.2.205/24" ],
           "mac": "CA:FE:C0:FF:EE:00"
         }
       ]'

   다음과 같습니다.

   metadata.name

   생성할 보조 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.

   metadata.annotations.k8s.v1.cni.cncf.io/ips

   서브넷 마스크를 포함한 IP 주소를 지정합니다.

   metadata.annotations.k8s.v1.cni.cncf.io/mac

   MAC 주소를 지정합니다.

   참고

   고정 IP 주소와 MAC 주소를 동시에 사용할 필요는 없습니다. 개별적으로 사용하거나 함께 사용할 수 있습니다.

프로세스

1. 정책 규칙을 만듭니다.

   1. <policy_name>.yaml 파일을 생성합니다.

      $ touch <policy_name>.yaml

      다음과 같습니다.

      <policy_name>

      다중 네트워크 정책 파일 이름을 지정합니다.

   2. 생성된 파일에서 다중 네트워크 정책을 정의합니다. 다음 예제에서는 모든 네임스페이스의 모든 포드에서 들어오는 트래픽을 거부합니다. 이는 다른 네트워크 정책의 구성에 의해 허용되는 크로스 포드 트래픽 외의 모든 크로스 포드 네트워킹을 차단하는 기본 정책입니다.

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      endif:: multi[]
      metadata:
        name: deny-by-default
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector: {}
        policyTypes:
        - Ingress
        ingress: []

      다음과 같습니다.

      <network_name>

      네트워크 연결 정의의 이름을 지정합니다.

      다음 예제 구성은 동일한 네임스페이스에 있는 모든 포드에서 수신 트래픽을 허용합니다.

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-same-namespace
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      # ...

      다음과 같습니다.

      <network_name>

      네트워크 연결 정의의 이름을 지정합니다.

      다음 예제에서는 특정 네임스페이스에서 하나의 포드로의 수신 트래픽을 허용합니다. 이 정책을 사용하면 namespace-y 에서 실행되는 Pod의 pod-a 레이블이 있는 Pod로의 트래픽을 허용합니다.

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-traffic-pod
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector:
         matchLabels:
            pod: pod-a
        policyTypes:
        - Ingress
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                 kubernetes.io/metadata.name: namespace-y
      # ...

      다음과 같습니다.

      <network_name>

      네트워크 연결 정의의 이름을 지정합니다.

      다음 예제 구성은 서비스에 대한 트래픽을 제한합니다. 이 정책을 적용하면 app=bookstore 및 role=api 레이블이 모두 있는 모든 Pod는 app=bookstore 레이블이 있는 Pod에서만 액세스할 수 있습니다. 이 예에서 애플리케이션은 app=bookstore 및 role=api 레이블이 있는 REST API 서버일 수 있습니다.

      이 예제 구성은 다음과 같은 사용 사례를 다룹니다.

      • 특정 서비스의 트래픽을 해당 서비스를 사용해야 하는 다른 마이크로서비스로만 제한합니다.

      • 해당 애플리케이션에서만 데이터베이스를 사용할 수 있도록 연결을 제한합니다.

        apiVersion: k8s.cni.cncf.io/v1beta1
        kind: MultiNetworkPolicy
        metadata:
          name: api-allow
          annotations:
            k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
        spec:
          podSelector:
            matchLabels:
              app: bookstore
              role: api
          ingress:
          - from:
              - podSelector:
                  matchLabels:
                    app: bookstore
        # ...

        다음과 같습니다.

      <network_name>

      네트워크 연결 정의의 이름을 지정합니다.

2. 다음 명령을 실행하여 다중 네트워크 정책 오브젝트를 생성합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   $ oc apply -f <policy_name>.yaml -n <namespace>

   다음과 같습니다.

   <policy_name>

   다중 네트워크 정책 파일 이름을 지정합니다.

   <namespace>

   선택적 매개변수 현재 네임스페이스와 다른 네임스페이스에 객체를 정의한 경우 매개변수는 네임스페이스를 지정합니다.

   성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   참고

   cluster-admin 권한을 사용하여 웹 콘솔에 로그인하는 경우 클러스터의 모든 네임스페이스에서 직접 또는 웹 콘솔의 양식에서 네트워크 정책을 생성할 수 있습니다.

프로세스

1. 선택 사항: 네임스페이스의 다중 네트워크 정책 오브젝트를 나열하려면 다음 명령을 입력합니다.

   $ oc get multi-network policy -n <namespace>

   다음과 같습니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

2. 다중 네트워크 정책 오브젝트를 편집합니다.

   1. 다중 네트워크 정책 정의를 파일에 저장한 경우 파일을 편집하고 필요한 사항을 변경한 후 다음 명령을 입력합니다.

      $ oc apply -n <namespace> -f <policy_file>.yaml

      다음과 같습니다.

      <namespace>

      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

      <policy_file>

      네트워크 정책이 포함된 파일의 이름을 지정합니다.

   2. 다중 네트워크 정책 오브젝트를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.

      $ oc edit multi-network policy <policy_name> -n <namespace>

      다음과 같습니다.

      <policy_name>

      네트워크 정책의 이름을 지정합니다.

      <namespace>

      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

3. 다중 네트워크 정책 오브젝트가 업데이트되었는지 확인합니다.

   $ oc describe multi-networkpolicy <policy_name> -n <namespace>

   다음과 같습니다.

   <policy_name>

   다중 네트워크 정책의 이름을 지정합니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

프로세스

1. 네임스페이스에 있는 다중 네트워크 정책을 나열합니다.

   1. 네임스페이스에 정의된 다중 네트워크 정책 객체를 보려면 다음 명령을 입력하세요.

      $ oc get multi-networkpolicy

   2. 선택 사항: 특정 다중 네트워크 정책을 조사하려면 다음 명령을 입력하세요.

      $ oc describe multi-networkpolicy <policy_name> -n <namespace>

      다음과 같습니다.

      <policy_name>

      검사할 다중 네트워크 정책의 이름을 지정합니다.

      <namespace>

      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

프로세스

1. 모든 네임스페이스의 모든 포드의 수신을 거부하도록 기본 거부 정책을 정의하는 다음 YAML을 생성합니다. YAML을 deny-by-default.yaml 파일에 저장합니다.

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: deny-by-default
     namespace: my-project
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     ingress: []

   다음과 같습니다.

   네임스페이스

   정책을 배포할 네임스페이스를 지정합니다. 예를 들어 my-project 네임스페이스는 다음과 같습니다.

   annotations

   네임스페이스 프로젝트 이름 뒤에 네트워크 연결 정의 이름을 지정합니다.

   podSelector

   이 필드가 비어 있으면 구성이 모든 포드와 일치합니다. 따라서 정책은 my-project 네임스페이스의 모든 pod에 적용됩니다.

   policyTypes

   NetworkPolicy 와 관련된 규칙 유형 목록을 지정합니다.

   - Ingress

   Ingress 는 policyTypes 만 지정합니다.

   Ingress

   수신 규칙을 지정합니다. 지정하지 않으면 모든 포드에 대한 모든 수신 트래픽이 삭제됩니다.

2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   $ oc apply -f deny-by-default.yaml

프로세스

1. 퍼블릭 인터넷에서 직접 또는 로드 밸런서를 사용하여 트래픽이 포드에 액세스할 수 있도록 허용하는 정책을 만듭니다. YAML을 web-allow-external.yaml 파일에 저장합니다.

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-external
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     policyTypes:
     - Ingress
     podSelector:
       matchLabels:
         app: web
     ingress:
       - {}

2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   $ oc apply -f web-allow-external.yaml

   이 정책은 다음 다이어그램에 표시된 것처럼 외부 트래픽을 포함한 모든 리소스의 트래픽을 허용합니다.

   

프로세스

1. 모든 네임스페이스의 모든 포드에서 특정 애플리케이션으로의 트래픽을 허용하는 정책을 만듭니다. YAML을 web-allow-all-namespaces.yaml 파일에 저장합니다.

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-all-namespaces
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector:
       matchLabels:
        app: web
     policyTypes:
     - Ingress
     ingress:
     - from:
       - namespaceSelector: {}

   다음과 같습니다.

   app

   기본 네임스페이스의 app:web pod에만 정책을 적용합니다.

   namespaceSelector

   모든 네임스페이스의 모든 포드를 선택합니다.

   참고

   기본적으로 정책 오브젝트에 namespaceSelector 매개변수를 지정하지 않으면 네임스페이스를 선택하지 않습니다. 즉, 정책은 네트워크 정책이 배포된 네임스페이스에서만 트래픽을 허용합니다.

2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   $ oc apply -f web-allow-all-namespaces.yaml

검증

1. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다.

   $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

2. 다음 명령을 실행하여 보조 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

   $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh

3. 셸에서 다음 명령을 실행하고 서비스가 요청을 허용하는지 확인합니다.

   # wget -qO- --timeout=2 http://web.default

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   html { color-scheme: light dark; }
   body { width: 35em; margin: 0 auto;
   font-family: Tahoma, Verdana, Arial, sans-serif; }
   </style>
   </head>
   <body>
   <h1>Welcome to nginx!</h1>
   <p>If you see this page, the nginx web server is successfully installed and
   working. Further configuration is required.</p>
   
   <p>For online documentation and support please refer to
   <a href="http://nginx.org/">nginx.org</a>.<br/>
   Commercial support is available at
   <a href="http://nginx.com/">nginx.com</a>.</p>
   
   <p><em>Thank you for using nginx.</em></p>
   </body>
   </html>

프로세스

1. purpose=production 레이블이 있는 특정 네임스페이스의 모든 Pod의 트래픽을 허용하는 정책을 생성합니다. YAML을 web-allow-prod.yaml 파일에 저장합니다.

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-prod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector:
       matchLabels:
         app: web
     policyTypes:
     - Ingress
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             purpose: production

   다음과 같습니다.

   app

   기본 네임스페이스의 app:web pod에만 정책을 적용합니다.

   목적

   purpose=production 레이블이 있는 네임스페이스의 Pod로만 트래픽을 제한합니다.

2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

   $ oc apply -f web-allow-prod.yaml

검증

1. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다.

   $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

2. 다음 명령을 실행하여 prod 네임스페이스를 생성합니다.

   $ oc create namespace prod

3. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다.

   $ oc label namespace/prod purpose=production

4. 다음 명령을 실행하여 dev 네임스페이스를 생성합니다.

   $ oc create namespace dev

5. 다음 명령을 실행하여 dev 네임스페이스에 레이블을 지정합니다.

   $ oc label namespace/dev purpose=testing

6. 다음 명령을 실행하여 dev 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

   $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh

7. 셸에서 다음 명령을 실행하고 요청이 차단된 이유를 살펴보세요. 예를 들어 예상되는 출력 상태는 wget: download timed out 입니다.

   # wget -qO- --timeout=2 http://web.default

8. 다음 명령을 실행하여 prod 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

   $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh

9. 셸에서 다음 명령을 실행하고 요청이 허용되는지 확인하세요.

   # wget -qO- --timeout=2 http://web.default

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   html { color-scheme: light dark; }
   body { width: 35em; margin: 0 auto;
   font-family: Tahoma, Verdana, Arial, sans-serif; }
   </style>
   </head>
   <body>
   <h1>Welcome to nginx!</h1>
   <p>If you see this page, the nginx web server is successfully installed and
   working. Further configuration is required.</p>
   
   <p>For online documentation and support please refer to
   <a href="http://nginx.org/">nginx.org</a>.<br/>
   Commercial support is available at
   <a href="http://nginx.com/">nginx.com</a>.</p>
   
   <p><em>Thank you for using nginx.</em></p>
   </body>
   </html>