Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

4.10.2. route-override CNI 플러그인으로 플러그인 연결 구성

플러그인 체인을 사용하면 동일한 네트워크 인터페이스에 순차적으로 여러 CNI 플러그인을 구성할 수 있으며 체인의 각 플러그인은 인터페이스를 순서대로 처리합니다.

플러그인 배열을 사용하여 NetworkAttachmentDefinition (NAD)을 정의할 때 첫 번째 플러그인 은 인터페이스를 생성할 수 있으며, 두 번째 플러그인은 라우팅 구성을 수정할 수 있습니다.

route-override CNI 플러그인은 일반적으로 첫 번째 플러그인에서 생성한 인터페이스의 라우팅 구성을 수정하기 위해 체인에서 두 번째 플러그인으로 사용됩니다. 다음 작업을 지원합니다.

  • addroutes: 정적 경로를 추가하여 인터페이스를 통해 특정 대상 네트워크의 트래픽을 보냅니다.
  • delroutes: 인터페이스에서 특정 경로를 제거합니다.
  • flushroutes: 인터페이스에서 모든 경로를 제거합니다.
  • flushgateway: 인터페이스에서 기본 게이트웨이 경로를 제거합니다.

다음 예제에서는 각각 사용자 지정 라우팅을 사용하여 별도의 VLAN에서 두 개의 추가 네트워크 인터페이스를 사용하여 pod를 구성하여 플러그인 체인을 보여줍니다.

  • 192.168.100.0/24 네트워크(VLAN 100)의 eth1 과 이 인터페이스를 통해 10.0.0.0/8 트래픽을 지시하는 정적 경로가 있습니다.
  • 이 인터페이스를 통해 172.16.0.0/12 트래픽을 지시하는 정적 경로가 있는 192.168.200.0/24 네트워크(VLAN 200)의 eth2 입니다.

각 인터페이스는 두 개의 플러그인 체인을 사용합니다. macvlan 를 사용하여 VLAN에서 인터페이스를 생성하고 route-override 를 사용하여 해당 인터페이스를 통해 특정 트래픽을 전달하는 정적 경로를 추가합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 계정.

프로세스

  1. 다음 명령을 실행하여 예제의 네임스페이스를 생성합니다. 

    $ oc create namespace chain-example

  2. 연결된 플러그인 구성을 사용하여 첫 번째 NetworkAttachmentDefinition(NAD)을 생성합니다.

    1. management.yaml 과 같은 YAML 파일을 생성하여 다음 구성을 사용하여 VLAN 100에서 새 인터페이스 eth1 을 구성하는 CryostatD를 정의합니다. 

      apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: management-net
  namespace: chain-example
spec:
  config: '{
    "cniVersion": "1.0.0",
    "name": "management-net",
    "plugins": [
      {
        "type": "macvlan",
        "master": "br-ex",
        "vlan": 100,
        "mode": "bridge",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.100.10/24",
              "gateway": "192.168.100.1"
            }
          ]
        }
      },
      {
        "type": "route-override",
        "addroutes": [
          {
            "dst": "10.0.0.0/8",
            "gw": "192.168.100.1"
          }
        ]
      }
    ]
  }'

  3. 다음 명령을 실행하여 CryostatD를 생성합니다. 

    $ oc apply -f management.yaml

  4. 체인된 플러그인 구성을 사용하여 두 번째 CryostatD를 생성합니다.

    1. sip.yaml 과 같은 YAML 파일을 생성하여 다음 구성을 사용하여 VLAN 200에서 새 인터페이스 eth2 를 구성하는 CryostatD를 정의합니다. 

      apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: sip-net
  namespace: chain-example
spec:
  config: '{
    "cniVersion": "1.0.0",
    "name": "sip-net",
    "plugins": [
      {
        "type": "macvlan",
        "master": "br-ex",
        "vlan": 200,
        "mode": "bridge",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.200.10/24",
              "gateway": "192.168.200.1"
            }
          ]
        }
      },
      {
        "type": "route-override",
        "addroutes": [
          {
            "dst": "172.16.0.0/12",
            "gw": "192.168.200.1"
          }
        ]
      }
    ]
  }'

  5. 다음 명령을 실행하여 CryostatD를 생성합니다. 

    $ oc apply -f sip.yaml

  6. 다음 구성으로 pod 정의 파일(예: pod.yaml )을 생성하여 NetworkAttachmentDefinition 리소스를 Pod에 연결합니다. 

    apiVersion: v1
kind: Pod
metadata:
  name: chain-test-pod
  namespace: chain-example
  labels:
    app: chain-test
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      { "name": "management-net", "interface": "eth1" },
      { "name": "sip-net", "interface": "eth2" }
    ]'
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test-container
    image: registry.access.redhat.com/ubi9/ubi:latest
    command: ["sleep", "infinity"]
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

  7. 다음 명령을 실행하여 Pod를 생성합니다. 

    $ oc apply -f pod.yaml

  8. 다음 명령을 사용하여 Pod가 실행 중인지 확인합니다. 

    $ oc wait --for=condition=Ready pod/chain-test-pod -n chain-example --timeout=120s

    출력 예: 

    pod/chain-test-pod condition met

검증

  1. 다음 명령을 실행하여 포드 내부의 모든 네트워크 인터페이스와 할당된 IP 주소를 나열합니다. 이렇게 하면 Pod에 플러그인 체인으로 구성된 추가 인터페이스가 있는지 확인합니다. 

    $ oc exec chain-test-pod -n chain-example -- ip a

    출력 예: 

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8901 qdisc noqueue state UP
    link/ether 0a:58:0a:83:02:19 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.131.2.25/23 brd 10.131.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::858:aff:fe83:219/64 scope link
       valid_lft forever preferred_lft forever
3: eth1@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP qlen 1000
    link/ether aa:25:73:ff:a7:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.100.10/24 brd 192.168.100.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a825:73ff:feff:a700/64 scope link
       valid_lft forever preferred_lft forever
4: eth2@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP qlen 1000
    link/ether aa:a4:6c:4e:e8:97 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.200.10/24 brd 192.168.200.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::a8a4:6cff:fe4e:e897/64 scope link
       valid_lft forever preferred_lft forever

    이 출력에서는 Pod에 세 개의 네트워크 인터페이스가 있음을 보여줍니다.

    • eth0: 클러스터 네트워크에 연결된 기본 인터페이스입니다.
    • eth1: management-net 의 첫 번째 추가 인터페이스 IP 192.168.100.10.
    • eth2: sip-net 의 두 번째 추가 인터페이스가 IP 192.168.200.10 인 .

  2. 다음 명령을 실행하여 route-override 플러그인이 예상 정적 경로를 추가했는지 확인합니다. 

    $ oc exec chain-test-pod -n chain-example -- ip route

    출력 예: 

    default via 10.132.0.1 dev eth0
10.0.0.0/8 via 192.168.100.1 dev eth1
10.132.0.0/23 dev eth0 proto kernel scope link src 10.132.1.97
10.132.0.0/14 via 10.132.0.1 dev eth0
100.64.0.0/16 via 10.132.0.1 dev eth0
169.254.0.5 via 10.132.0.1 dev eth0
172.16.0.0/12 via 192.168.200.1 dev eth2
172.30.0.0/16 via 10.132.0.1 dev eth0
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.10
192.168.200.0/24 dev eth2 proto kernel scope link src 192.168.200.10

    이 출력은 각 체인의 route-override 플러그인이 예상되는 정적 경로를 추가했음을 확인합니다.

    • 10.0.0.0/8에서 192.168.100.1 dev eth1 의 경우 10.0.0.0/8 로 향하는 트래픽은 management-net 게이트웨이를 통해 eth1 을 통해 라우팅됩니다. 이 경로는 management-net 체인의 route-override 플러그인에 의해 추가되었습니다.
    • 172.16.0.0/12 - 192.168.200.1 dev eth2 의 경우 172.16.0.0/12 로 향하는 트래픽은 sip-net 게이트웨이를 통해 eth2 를 통해 라우팅됩니다. 이 경로는 sip-net 체인의 route-override 플러그인에 의해 추가되었습니다.
    • 연결된 서브넷 경로(192.168.100.0/24 및 192.168.200.0/24)는 macvlan 플러그인에 의해 생성되었으며 기본 경로는 클러스터 네트워크 인터페이스인 eth0 을 사용합니다.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동