네트워킹

OpenShift Container Platform 4.8

클러스터 네트워킹 구성 및 관리

Red Hat OpenShift Documentation Team

초록

이 문서는 DNS, 인그레스 및 Pod 네트워크를 포함하여 OpenShift Container Platform 클러스터 네트워크를 구성 및 관리하기 위한 지침을 제공합니다.

1장. 네트워킹 이해

Kubernetes는 pod가 네트워크를 통해 서로 연결할 수 있도록 하며 각 pod에 내부 네트워크의 IP 주소를 할당합니다. 이렇게 하면 pod 내의 모든 컨테이너가 마치 동일한 호스트에 있는 것처럼 작동합니다. 각 pod에 고유 IP 주소를 부여하면 포트 할당, 네트워킹, 이름 지정, 서비스 검색, 로드 밸런싱, 애플리케이션 구성 및 마이그레이션 등 다양한 업무를 할 때 pod를 물리적 호스트 또는 가상 머신처럼 취급할 수 있습니다.

참고

일부 클라우드 플랫폼은 IPv4 169.254.0.0/16 CIDR 블록의 링크 로컬 IP 주소인 169.254.169.254 IP 주소에서 수신 대기하는 메타데이터 API를 제공합니다.

Pod 네트워크에서는 이 CIDR 블록에 접근할 수 없습니다. 이러한 IP 주소에 액세스해야 하는 pod의 경우 pod 사양의 spec.hostNetwork 필드를 true로 설정하여 호스트 네트워크 액세스 권한을 부여해야 합니다.

Pod의 호스트 네트워크 액세스를 허용하면 해당 pod에 기본 네트워크 인프라에 대한 액세스 권한이 부여됩니다.

1.1. OpenShift Container Platform DNS

여러 Pod에 사용하기 위해 프론트엔드 및 백엔드 서비스와 같은 여러 서비스를 실행하는 경우 사용자 이름, 서비스 IP 등에 대한 환경 변수를 생성하여 프론트엔드 Pod가 백엔드 서비스와 통신하도록 할 수 있습니다. 서비스를 삭제하고 다시 생성하면 새 IP 주소를 서비스에 할당할 수 있으며 서비스 IP 환경 변수의 업데이트된 값을 가져오기 위해 프론트엔드 Pod를 다시 생성해야 합니다. 또한 백엔드 서비스를 생성한 후 프론트엔드 Pod를 생성해야 서비스 IP가 올바르게 생성되고 프론트엔드 Pod에 환경 변수로 제공할 수 있습니다.

이러한 이유로 서비스 DNS는 물론 서비스 IP/포트를 통해서도 서비스를 이용할 수 있도록 OpenShift Container Platform에 DNS를 내장했습니다.

2장. 호스트에 액세스

bastion 호스트를 생성하여 OpenShift Container Platform 인스턴스에 액세스하고 SSH(Secure Shell) 액세스를 사용하여 컨트롤 플레인 노드(마스터 노드라고도 함)에 액세스하는 방법을 알아봅니다.

2.1. 설치 관리자 프로비저닝 인프라 클러스터에서 Amazon Web Services의 호스트에 액세스

OpenShift Container Platform 설치 관리자는 OpenShift Container Platform 클러스터에 프로비저닝된 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에 대한 퍼블릭 IP 주소를 생성하지 않습니다. OpenShift Container Platform 호스트에 SSH를 사용하려면 다음 절차를 따라야 합니다.

프로세스

  1. openshift-install 명령으로 생성된 가상 프라이빗 클라우드(VPC)에 SSH로 액세스할 수 있는 보안 그룹을 만듭니다.
  2. 설치 관리자가 생성한 퍼블릭 서브넷 중 하나에 Amazon EC2 인스턴스를 생성합니다.
  3. 생성한 Amazon EC2 인스턴스와 퍼블릭 IP 주소를 연결합니다.

    OpenShift Container Platform 설치와는 달리, 생성한 Amazon EC2 인스턴스를 SSH 키 쌍과 연결해야 합니다. 이 인스턴스에서 사용되는 운영 체제는 중요하지 않습니다. 그저 인터넷을 OpenShift Container Platform 클러스터의 VPC에 연결하는 SSH 베스천의 역할을 수행하기 때문입니다. 사용하는 AMI(Amazon 머신 이미지)는 중요합니다. 예를 들어, RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하면 설치 프로그램과 마찬가지로 Ignition을 통해 키를 제공할 수 있습니다.

  4. Amazon EC2 인스턴스를 프로비저닝한 후 SSH로 연결할 수 있는 경우 OpenShift Container Platform 설치와 관련된 SSH 키를 추가해야 합니다. 이 키는 베스천 인스턴스의 키와 다를 수 있지만 반드시 달라야 하는 것은 아닙니다.

    참고

    SSH 직접 액세스는 재해 복구 시에만 권장됩니다. Kubernetes API가 응답할 때는 권한 있는 Pod를 대신 실행합니다.

  5. oc get nodes를 실행하고 출력을 확인한 후 마스터 노드 중 하나를 선택합니다. 호스트 이름은 ip-10-0-1-163.ec2.internal과 유사합니다.
  6. Amazon EC2에 수동으로 배포한 bastion SSH 호스트에서 해당 컨트롤 플레인 호스트(마스터 호스트라고도 함)에 SSH로 연결합니다. 설치 중 지정한 것과 동일한 SSH 키를 사용해야 합니다.

    $ ssh -i <ssh-key-path> core@<master-hostname>

3장. OpenShift 컨테이너 플랫폼의 Cluster Network Operator

CNO(Cluster Network Operator)는 설치 중 클러스터에 대해 선택한 CNI(Container Network Interface) 기본 네트워크 공급자 플러그인 등 클러스터 네트워크 구성 요소를 OpenShift Container Platform 클러스터에 배포하고 관리합니다.

3.1. CNO(Cluster Network Operator)

Cluster Network Operator는 operator.openshift.io API 그룹에서 네트워크 API를 구현합니다. Operator는 데몬 세트를 사용하여 OpenShift SDN 기본 컨테이너 네트워크 인터페이스(CNI) 네트워크 공급자 플러그인 또는 클러스터 설치 중에 선택한 기본 네트워크 공급자 플러그인을 배포합니다.

프로세스

Cluster Network Operator는 설치 중에 Kubernetes Deployment로 배포됩니다.

  1. 다음 명령을 실행하여 배포 상태를 확인합니다.

    $ oc get -n openshift-network-operator deployment/network-operator

    출력 예

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m

  2. 다음 명령을 실행하여 Cluster Network Operator의 상태를 확인합니다.

    $ oc get clusteroperator/network

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.5.4     True        False         False      50m

    AVAILABLE, PROGRESSINGDEGRADED 필드에서 Operator 상태에 대한 정보를 볼 수 있습니다. Cluster Network Operator가 사용 가능한 상태 조건을 보고하는 경우 AVAILABLE 필드는 True로 설정됩니다.

3.2. 클러스터 네트워크 구성 보기

모든 새로운 OpenShift Container Platform 설치에는 이름이 clusternetwork.config 오브젝트가 있습니다.

프로세스

  • oc describe 명령을 사용하여 클러스터 네트워크 구성을 확인합니다.

    $ oc describe network.config/cluster

    출력 예

    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Self Link:           /apis/config.openshift.io/v1/networks/cluster
    Spec: 1
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      Network Type:   OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Status: 2
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  8951
      Network Type:         OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Events:  <none>

    1
    Spec 필드에는 클러스터 네트워크의 구성 상태가 표시됩니다.
    2
    Status 필드에는 클러스터 네트워크 구성의 현재 상태가 표시됩니다.

3.3. CNO(Cluster Network Operator) 상태 보기

oc describe 명령을 사용하여 상태를 조사하고 Cluster Network Operator의 세부 사항을 볼 수 있습니다.

프로세스

  • 다음 명령을 실행하여 Cluster Network Operator의 상태를 확인합니다.

    $ oc describe clusteroperators/network

3.4. CNO(Cluster Network Operator) 로그 보기

oc logs 명령을 사용하여 Cluster Network Operator 로그를 확인할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 Cluster Network Operator의 로그를 확인합니다.

    $ oc logs --namespace=openshift-network-operator deployment/network-operator

3.5. CNO(Cluster Network Operator) 구성

클러스터 네트워크의 구성은 CNO(Cluster Network Operator) 구성의 일부로 지정되며 cluster라는 이름의 CR(사용자 정의 리소스) 오브젝트에 저장됩니다. CR은 operator.openshift.io API 그룹에서 Network API의 필드를 지정합니다.

CNO 구성은 Network.config.openshift.io API 그룹의 Network API에서 클러스터 설치 중에 다음 필드를 상속하며 이러한 필드는 변경할 수 없습니다.

clusterNetwork
Pod IP 주소가 할당되는 IP 주소 풀입니다.
serviceNetwork
서비스를 위한 IP 주소 풀입니다.
defaultNetwork.type
OpenShift SDN 또는 OVN-Kubernetes와 같은 클러스터 네트워크 공급자입니다.
참고

클러스터를 설치한 후에는 이전 섹션에 나열된 필드를 수정할 수 없습니다.

cluster라는 CNO 오브젝트에서 defaultNetwork 오브젝트의 필드를 설정하여 클러스터의 클러스터 네트워크 공급자 구성을 지정할 수 있습니다.

3.5.1. CNO(Cluster Network Operator) 구성 오브젝트

CNO(Cluster Network Operator)의 필드는 다음 표에 설명되어 있습니다.

표 3.1. CNO(Cluster Network Operator) 구성 오브젝트

필드유형설명

metadata.name

string

CNO 개체 이름입니다. 이 이름은 항상 cluster입니다.

spec.clusterNetwork

array

Pod IP 주소가 할당되는 IP 주소 블록과 클러스터의 각 개별 노드에 할당된 서브넷 접두사 길이를 지정하는 목록입니다. 예를 들면 다음과 같습니다.

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

이 값은 준비 전용이며 클러스터 설치 중에 cluster 라는 Network.config.openshift.io 개체에서 상속됩니다.

spec.serviceNetwork

array

서비스의 IP 주소 블록입니다. OpenShift SDN 및 OVN-Kubernetes CNI(Container Network Interface) 네트워크 공급자는 서비스 네트워크에 대한 단일 IP 주소 블록만 지원합니다. 예를 들면 다음과 같습니다.

spec:
  serviceNetwork:
  - 172.30.0.0/14

이 값은 준비 전용이며 클러스터 설치 중에 cluster 라는 Network.config.openshift.io 개체에서 상속됩니다.

spec.defaultNetwork

object

클러스터 네트워크의 CNI(Container Network Interface) 클러스터 네트워크 공급자를 구성합니다.

spec.kubeProxyConfig

object

이 개체의 필드는 kube-proxy 구성을 지정합니다. OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 kube-proxy 구성이 적용되지 않습니다.

defaultNetwork 오브젝트 구성

defaultNetwork 오브젝트의 값은 다음 표에 정의되어 있습니다.

표 3.2. defaultNetwork 오브젝트

필드유형설명

type

string

OpenShiftSDN 또는 OVNKubernetes 중 하나이며, 클러스터 네트워크 공급자가 설치 중에 선택됩니다. 클러스터를 설치한 후에는 이 값을 변경할 수 없습니다.

참고

OpenShift Container Platform은 기본적으로 OpenShift SDN CNI(Container Network Interface) 클러스터 네트워크 공급자를 사용합니다.

openshiftSDNConfig

object

이 오브젝트는 OpenShift SDN 클러스터 네트워크 공급자에만 유효합니다.

ovnKubernetesConfig

object

이 오브젝트는 OVN-Kubernetes 클러스터 네트워크 공급자에만 유효합니다.

OpenShift SDN CNI 네트워크 공급자에 대한 구성

다음 표에서는 OpenShift SDN Container Network Interface (CNI) 클러스터 네트워크 공급자의 구성 필드를 설명합니다.

표 3.3. openshiftSDNConfig 오브젝트

필드유형설명

mode

string

OpenShift SDN의 네트워크 격리 모드입니다.

mtu

integer

VXLAN 오버레이 네트워크의 최대 전송 단위(MTU)입니다. 이 값은 일반적으로 자동 구성됩니다.

vxlanPort

integer

모든 VXLAN 패킷에 사용할 포트입니다. 기본값은 4789입니다.

참고

클러스터 설치 중 클러스터 네트워크 공급자에 대한 구성만 변경할 수 있습니다.

OpenShift SDN 구성 예

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI 클러스터 네트워크 공급자에 대한 구성

다음 표에서는 OVN-Kubernetes CNI 클러스터 네트워크 공급자의 구성 필드를 설명합니다.

표 3.4. ovnKubernetesConfig object

필드유형설명

mtu

integer

Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크의 MTU(최대 전송 단위)입니다. 이 값은 일반적으로 자동 구성됩니다.

genevePort

integer

Geneve 오버레이 네트워크용 UDP 포트입니다.

ipsecConfig

object

필드가 있으면 클러스터에 IPsec이 활성화됩니다.

policyAuditConfig

object

네트워크 정책 감사 로깅을 사용자 정의할 구성 오브젝트를 지정합니다. 설정되지 않으면 기본값 감사 로그 설정이 사용됩니다.

표 3.5. policyAuditConfig object

필드유형설명

rateLimit

integer

노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 20 개의 메시지입니다.

maxFileSize

integer

감사 로그의 최대 크기(바이트)입니다. 기본값은 50000000 또는 50MB입니다.

대상

string

다음 추가 감사 로그 대상 중 하나입니다.

libc
호스트에서 journald 프로세스의 libc syslog() 함수입니다.
udp:<host>:<port>
syslog 서버입니다. <host>:<port>를 syslog 서버의 호스트 및 포트로 바꿉니다.
unix:<file>
<file>로 지정된 Unix Domain Socket 파일입니다.
null
감사 로그를 추가 대상으로 보내지 마십시오.

syslogFacility

string

RFC5424에 정의된 kern과 같은 syslog 기능입니다. 기본값은 local0입니다.

참고

클러스터 설치 중 클러스터 네트워크 공급자에 대한 구성만 변경할 수 있습니다.

OVN-Kubernetes 구성 예

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig 오브젝트 구성

kubeProxyConfig 오브젝트의 값은 다음 표에 정의되어 있습니다.

표 3.6. kubeProxyConfig object

필드유형설명

iptablesSyncPeriod

string

iptables 규칙의 새로 고침 간격입니다. 기본값은 30s입니다. 유효 접미사로 s, m, h가 있으며, 자세한 설명은 Go time 패키지 문서를 참조하십시오.

참고

OpenShift Container Platform 4.3 이상에서는 성능이 개선되어 더 이상 iptablesSyncPeriod 매개변수를 조정할 필요가 없습니다.

proxyArguments.iptables-min-sync-period

array

iptables 규칙을 새로 고치기 전 최소 기간입니다. 이 필드를 통해 새로 고침 간격이 너무 짧지 않도록 조정할 수 있습니다. 유효 접미사로 s, m, h가 있으며, 자세한 설명은 Go time 패키지를 참조하십시오. 기본값은 다음과 같습니다.

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

3.5.2. CNO(Cluster Network Operator) 구성 예시

다음 예에서는 전체 CNO 구성이 지정됩니다.

CNO(Cluster Network Operator) 개체 예시

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork: 1
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork: 2
  - 172.30.0.0/16
  defaultNetwork: 3
    type: OpenShiftSDN
    openshiftSDNConfig:
      mode: NetworkPolicy
      mtu: 1450
      vxlanPort: 4789
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period:
      - 0s

1 2 3
클러스터 설치 중에만 구성됩니다.

3.6. 추가 리소스

4장. OpenShift Container Platform에서의 DNS Operator

DNS Operator는 CoreDNS를 배포 및 관리하고 Pod에 이름 확인 서비스를 제공하여 OpenShift에서 DNS 기반 Kubernetes 서비스 검색을 사용할 수 있도록 합니다.

4.1. DNS Operator

DNS Operator는 operator.openshift.io API 그룹에서 dns API를 구현합니다. Operator는 데몬 세트를 사용하여 CoreDNS를 배포하고 데몬 세트에 대한 서비스를 생성하며 이름 확인에서 CoreDNS 서비스 IP 주소를 사용하기 위해 Pod에 명령을 내리도록 kubelet을 구성합니다.

프로세스

DNS Operator는 설치 중에 Deployment 오브젝트로 배포됩니다.

  1. oc get 명령을 사용하여 배포 상태를 확인합니다.

    $ oc get -n openshift-dns-operator deployment/dns-operator

    출력 예

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h

  2. oc get 명령을 사용하여 DNS Operator의 상태를 확인합니다.

    $ oc get clusteroperator/dns

    출력 예

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    dns       4.1.0-0.11  True        False         False      92m

    AVAILABLE, PROGRESSINGDEGRADED는 Operator의 상태에 대한 정보를 제공합니다. AVAILABLE은 CoreDNS 데몬 세트에서 1개 이상의 포드가 Available 상태 조건을 보고할 때 True입니다.

4.2. DNS Pod 배치 제어

DNS Operator에는 2개의 데몬 세트(CoreDNS 및 /etc/hosts 파일 관리용)가 있습니다. 이미지 가져오기를 지원할 클러스터 이미지 레지스트리의 항목을 추가하려면 모든 노드 호스트에서 /etc/hosts의 데몬 세트를 실행해야 합니다. 보안 정책은 CoreDNS에 대한 데몬 세트가 모든 노드에서 실행되지 않도록 하는 노드 쌍 간 통신을 금지할 수 있습니다.

클러스터 관리자는 사용자 정의 노드 선택기를 사용하여 CoreDNS의 데몬 세트를 구성하여 특정 노드에서 실행하거나 실행할 수 없습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 특정 노드 간 통신을 방지하려면 spec.nodePlacement.nodeSelector API 필드를 구성합니다.

    1. 이름이 default인 DNS Operator 오브젝트를 수정합니다.

      $ oc edit dns.operator/default
    2. spec.nodePlacement.nodeSelector API 필드에 컨트롤 플레인 노드만 포함하는 노드 선택기를 지정합니다.

       spec:
         nodePlacement:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
  • CoreDNS의 데몬 세트가 노드에서 실행되도록 테인트 및 톨러레이션을 구성합니다.

    1. 이름이 default인 DNS Operator 오브젝트를 수정합니다.

      $ oc edit dns.operator/default
    2. 테인트 키와 테인트에 대한 톨러레이션을 지정합니다.

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only"
             operators: Equal
             value: abc
             tolerationSeconds: 3600 1
      1
      테인트가 dns-only인 경우 무기한 허용될 수 있습니다. tolerationSeconds를 생략할 수 있습니다.

4.3. 기본 DNS보기

모든 새로운 OpenShift Container Platform 설치에서는 dns.operator의 이름이 default로 지정됩니다.

프로세스

  1. oc describe 명령을 사용하여 기본 dns를 확인합니다.

    $ oc describe dns.operator/default

    출력 예

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 1
      Cluster IP:      172.30.0.10 2
    ...

    1
    Cluster Domain 필드는 정규화된 pod 및 service 도메인 이름을 구성하는 데 사용되는 기본 DNS 도메인입니다.
    2
    Cluster IP는 이름을 확인하기 위한 주소 Pod 쿼리입니다. IP는 service CIDR 범위에서 10번째 주소로 정의됩니다.
  2. 클러스터의 service CIDR을 찾으려면 oc get 명령을 사용합니다.

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

출력 예

[172.30.0.0/16]

4.4. DNS 전달 사용

지정된 구역에 사용해야 하는 네임 서버를 지정하는 방식으로 DNS 전달을 사용하여 etc/resolv.conf에서 식별된 영역별 전달 구성을 덮어쓸 수 있습니다. 전달된 영역이 OpenShift Container Platform에서 관리하는 Ingress 도메인인 경우 도메인에 대한 업스트림 이름 서버를 승인해야 합니다.

프로세스

  1. 이름이 default인 DNS Operator 오브젝트를 수정합니다.

    $ oc edit dns.operator/default

    이를 통해 Operator는 Server 기반의 추가 서버 구성 블록으로 dns-default라는 ConfigMap을 생성 및 업데이트할 수 있습니다. 서버에 쿼리와 일치하는 영역이 없는 경우 이름 확인은 /etc/resolv.conf에 지정된 네임 서버로 대체됩니다.

    샘플 DNS

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: foo-server 1
        zones: 2
          - foo.com
        forwardPlugin:
          upstreams: 3
            - 1.1.1.1
            - 2.2.2.2:5353
      - name: bar-server
        zones:
          - bar.com
          - example.com
        forwardPlugin:
          upstreams:
            - 3.3.3.3
            - 4.4.4.4:5454

    1
    namerfc6335 서비스 이름 구문을 준수해야 합니다.
    2
    zonesrfc1123하위 도메인 정의를 준수해야 합니다. 클러스터 도메인에 해당하는 cluster.local영역에 유효하지 않은 하위 도메인입니다.
    3
    forwardPlugin당 최대 15개의 업스트림이 허용됩니다.
    참고

    servers 가 정의되지 않았거나 유효하지 않은 경우 ConfigMap에는 기본 서버만 포함됩니다.

  2. ConfigMap을 확인합니다.

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    이전 샘플 DNS를 기반으로 하는 샘플 DNS ConfigMap

    apiVersion: v1
    data:
      Corefile: |
        foo.com:5353 {
            forward . 1.1.1.1 2.2.2.2:5353
        }
        bar.com:5353 example.com:5353 {
            forward . 3.3.3.3 4.4.4.4:5454 1
        }
        .:5353 {
            errors
            health
            kubernetes cluster.local in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            prometheus :9153
            forward . /etc/resolv.conf {
                policy sequential
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns

    1
    forwardPlugin을 변경하면 CoreDNS 데몬 세트의 롤링 업데이트가 트리거됩니다.

추가 리소스

4.5. DNS Operator 상태

oc describe 명령을 사용하여 상태를 확인하고 DNS Operator의 세부 사항을 볼 수 있습니다.

프로세스

DNS Operator의 상태를 확인하려면 다음을 실행합니다.

$ oc describe clusteroperators/dns

4.6. DNS Operator 로그

oc logs 명령을 사용하여 DNS Operator 로그를 확인할 수 있습니다.

프로세스

DNS Operator의 로그를 확인합니다.

$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

5장. OpenShift Container Platform에서의 Ingress Operator

Ingress Operator는 IngressController API를 구현하며 OpenShift Container Platform 클러스터 서비스에 대한 외부 액세스를 가능하게 하는 구성 요소입니다. Operator는 라우팅을 처리하기 위해 하나 이상의 HAProxy 기반 Ingress 컨트롤러를 배포하고 관리하여 이러한 기능을 제공합니다. Ingress Operator를 사용하여 OpenShift 컨테이너 플랫폼 Route 및 Kubernetes Ingress 리소스를 지정하면 수신 트래픽을 라우팅할 수 있습니다.

5.1. Ingress 구성 자산

설치 프로그램은 config.openshift.io API 그룹인 cluster-ingress-02-config.ymlIngress 리소스가 포함된 자산을 생성합니다.

Ingress 리소스의 YAML 정의

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

설치 프로그램은 이 자산을 manifests / 디렉터리의 cluster-ingress-02-config.yml 파일에 저장합니다. 이 Ingress 리소스는 Ingress와 관련된 전체 클러스터 구성을 정의합니다. 이 Ingress 구성은 다음과 같이 사용됩니다.

  • Ingress Operator는 클러스터 Ingress 구성에 설정된 도메인을 기본 Ingress 컨트롤러의 도메인으로 사용합니다.
  • OpenShift API Server Operator는 클러스터 Ingress 구성의 도메인을 사용합니다. 이 도메인은 명시적 호스트를 지정하지 않는 Route 리소스에 대한 기본 호스트를 생성할 수도 있습니다.

5.2. Ingress 컨트롤러 구성 매개변수

ingresscontrollers.operator.openshift.io 리소스에서 제공되는 구성 매개변수는 다음과 같습니다.

매개변수설명

domain

domain은 Ingress 컨트롤러에서 제공하는 DNS 이름이며 여러 기능을 구성하는 데 사용됩니다.

  • LoadBalancerService 끝점 게시 방식에서는 domain을 사용하여 DNS 레코드를 구성합니다. endpointPublishingStrategy를 참조하십시오.
  • 생성된 기본 인증서를 사용하는 경우, 인증서는 domain 및 해당 subdomains에 유효합니다. defaultCertificate를 참조하십시오.
  • 사용자가 외부 DNS 레코드의 대상 위치를 확인할 수 있도록 이 값이 개별 경로 상태에 게시됩니다.

domain 값은 모든 Ingress 컨트롤러에서 고유해야 하며 업데이트할 수 없습니다.

비어 있는 경우 기본값은 ingress.config.openshift.io/cluster .spec.domain입니다.

appsDomain

appsDomain은 명시적 호스트를 지정하지 않고 경로가 생성될 때 도메인 필드에 지정된 대신 사용할 AWS 인프라에 대한 선택적 도메인입니다. appsDomain에 값이 입력되면 이 값은 경로에 대한 기본 호스트 값을 생성하는 데 사용됩니다. domain과 달리 appsDomain은 설치 후 수정할 수 있습니다. 와일드카드 인증서를 사용하는 새 Ingress 컨트롤러를 설정한 경우에만 이 매개변수를 사용할 수 있습니다.

replicas

복제본은 원하는 수의 Ingress 컨트롤러 복제본입니다. 설정되지 않은 경우, 기본값은 2입니다.

endpointPublishingStrategy

endpointPublishingStrategy는 Ingress 컨트롤러 끝점을 다른 네트워크에 게시하고 로드 밸런서 통합을 활성화하며 다른 시스템에 대한 액세스를 제공하는 데 사용됩니다.

설정되지 않은 경우, 기본값은 infrastructure.config.openshift.io/cluster .status.platform을 기반으로 다음과 같습니다.

  • AWS: LoadBalancerService(외부 범위 포함)
  • Azure: LoadBalancerService(외부 범위 포함)
  • GCP: LoadBalancerService(외부 범위 포함)
  • 베어 메탈: NodePortService
  • 기타: hostnetwork

대부분의 플랫폼의 경우 endpointPublishingStrategy 값을 업데이트할 수 없습니다. 그러나 GCP에서는 loadbalancer.providerParameters.gcp.clientAccess 하위 필드를 구성할 수 있습니다.

defaultCertificate

defaultCertificate 값은 Ingress 컨트롤러에서 제공하는 기본 인증서가 포함된 보안에 대한 참조입니다. 경로가 고유한 인증서를 지정하지 않으면 defaultCertificate가 사용됩니다.

보안에는 키와 데이터, 즉 *tls.crt: 인증서 파일 내용 *tls.key: 키 파일 내용이 포함되어야 합니다.

설정하지 않으면 와일드카드 인증서가 자동으로 생성되어 사용됩니다. 인증서는 Ingress 컨트롤러 도메인하위 도메인에 유효하며 생성된 인증서의 CA는 클러스터의 신뢰 저장소와 자동으로 통합됩니다.

생성된 인증서 또는 사용자 정의 인증서는 OpenShift Container Platform 내장 OAuth 서버와 자동으로 통합됩니다.

namespaceSelector

namespaceSelector는 Ingress 컨트롤러에서 서비스를 제공하는 네임스페이스 집합을 필터링하는 데 사용됩니다. 이는 분할을 구현하는 데 유용합니다.

routeSelector

routeSelector는 Ingress 컨트롤러에서 서비스하는 경로 집합을 필터링하는 데 사용됩니다. 이는 분할을 구현하는 데 유용합니다.

nodePlacement

nodePlacement를 사용하면 Ingress 컨트롤러의 스케줄링을 명시적으로 제어할 수 있습니다.

설정하지 않으면 기본값이 사용됩니다.

참고

nodePlacement 매개변수는 nodeSelectortolerations의 두 부분으로 구성됩니다. 예를 들면 다음과 같습니다.

nodePlacement:
 nodeSelector:
   matchLabels:
     beta.kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists

tlsSecurityProfile

tlsSecurityProfile은 Ingress 컨트롤러에 대한 TLS 연결 설정을 지정합니다.

설정되지 않으면, 기본값은 apiservers.config.openshift.io/cluster 리소스를 기반으로 설정됩니다.

Old, IntermediateModern 프로파일 유형을 사용하는 경우 유효한 프로파일 구성은 릴리스마다 변경될 수 있습니다. 예를 들어 릴리스 X.Y.Z에 배포된 Intermediate 프로필을 사용하는 사양을 고려할 때 X.Y.Z+1 릴리스로의 업그레이드로 인해 새 프로필 구성이 Ingress 컨트롤러에 적용되어 롤아웃이 발생할 수 있습니다.

Ingress 컨트롤러의 최소 TLS 버전은 1.1이며 최대 TLS 버전은 1.2입니다.

중요

HAProxy Ingress 컨트롤러 이미지는 TLS 1.3을 지원하지 않으며 Modern 프로파일에는 TLS 1.3이 필요하므로 지원되지 않습니다. Ingress Operator는 Modern 프로파일을 Intermediate로 변환합니다.

또한, Ingress Operator는 Old 또는 Custom 프로파일의 TLS 1.01.1로 변환하고 Custom 프로파일의 TLS 1.31.2로 변환합니다.

참고

구성된 보안 프로파일의 암호 및 최소 TLS 버전은 TLSProfile 상태에 반영됩니다.

routeAdmission

routeAdmission은 네임스페이스에서 클레임을 허용 또는 거부하는 등 새로운 경로 클레임을 처리하기 위한 정책을 정의합니다.

namespaceOwnership은 네임스페이스에서 호스트 이름 클레임을 처리하는 방법을 설명합니다. 기본값은 Strict입니다.

  • Strict: 경로가 네임스페이스에서 동일한 호스트 이름을 요청하는 것을 허용하지 않습니다.
  • InterNamespaceAllowed: 경로가 네임스페이스에서 동일한 호스트 이름의 다른 경로를 요청하는 것을 허용합니다.

wildcardPolicy는 Ingress 컨트롤러에서 와일드카드 정책이 포함된 경로를 처리하는 방법을 설명합니다.

  • WildcardsAllowed: 와일드카드 정책이 포함된 경로가 Ingress 컨트롤러에 의해 허용됨을 나타냅니다.
  • WildcardsDisallowed: 와일드카드 정책이 None인 경로만 Ingress 컨트롤러에 의해 허용됨을 나타냅니다. WildcardsAllowed에서 WildcardsDisallowedwildcardPolicy를 업데이트하면 와일드카드 정책이 Subdomain인 허용되는 경로의 작동이 중지됩니다. Ingress 컨트롤러에서 이러한 경로를 다시 허용하려면 이 경로를 설정이 None인 와일드카드 정책으로 다시 생성해야 합니다. 기본 설정은 WildcardsDisallowed입니다.

IngressControllerLogging

logging은 어디에서 무엇이 기록되는지에 대한 매개변수를 정의합니다. 이 필드가 비어 있으면 작동 로그는 활성화되지만 액세스 로그는 비활성화됩니다.

  • access는 클라이언트 요청이 기록되는 방법을 설명합니다. 이 필드가 비어 있으면 액세스 로깅이 비활성화됩니다.

    • destination은 로그 메시지의 대상을 설명합니다.

      • type은 로그 대상의 유형입니다.

        • Container 는 로그가 사이드카 컨테이너로 이동하도록 지정합니다. Ingress Operator는 Ingress 컨트롤러 pod에서 logs 라는 컨테이너를 구성하고 컨테이너에 로그를 작성하도록 Ingress 컨트롤러를 구성합니다. 관리자는 이 컨테이너에서 로그를 읽는 사용자 정의 로깅 솔루션을 구성해야 합니다. 컨테이너 로그를 사용한다는 것은 로그 비율이 컨테이너 런타임 용량 또는 사용자 정의 로깅 솔루션 용량을 초과하면 로그가 삭제될 수 있음을 의미합니다.
        • Syslog는 로그가 Syslog 끝점으로 전송되도록 지정합니다. 관리자는 Syslog 메시지를 수신할 수 있는 끝점을 지정해야 합니다. 관리자가 사용자 정의 Syslog 인스턴스를 구성하는 것이 좋습니다.
      • 컨테이너Container 로깅 대상 유형의 매개변수를 설명합니다. 현재는 컨테이너 로깅에 대한 매개변수가 없으므로 이 필드는 비어 있어야 합니다.
      • syslogSyslog 로깅 대상 유형의 매개변수를 설명합니다.

        • address는 로그 메시지를 수신하는 syslog 끝점의 IP 주소입니다.
        • port는 로그 메시지를 수신하는 syslog 끝점의 UDP 포트 번호입니다.
        • facility는 로그 메시지의 syslog 기능을 지정합니다. 이 필드가 비어 있으면 장치가 local1이 됩니다. 아니면 kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, auth2, ftp, ntp, audit, alert, cron2, local0, local1, local2, local3, local4, local5, local6 또는 local7 중에서 유효한 syslog 장치를 지정해야 합니다.
    • httpLogFormat은 HTTP 요청에 대한 로그 메시지의 형식을 지정합니다. 이 필드가 비어 있으면 로그 메시지는 구현의 기본 HTTP 로그 형식을 사용합니다. HAProxy의 기본 HTTP 로그 형식과 관련한 내용은 HAProxy 문서를 참조하십시오.

httpHeaders

httpHeaders는 HTTP 헤더에 대한 정책을 정의합니다.

IngressControllerHTTPHeadersforwardedHeaderPolicy를 설정하여 Ingress 컨트롤러에서 Forwarded, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X-Forwarded-Proto-Version HTTP 헤더를 설정하는 시기와 방법을 지정합니다.

기본적으로 정책은 Append로 설정됩니다.

  • Append는 Ingress 컨트롤러에서 기존 헤더를 유지하면서 헤더를 추가하도록 지정합니다.
  • Replace는 Ingress 컨트롤러에서 헤더를 설정하고 기존 헤더를 제거하도록 지정합니다.
  • IfNone은 헤더가 아직 설정되지 않은 경우 Ingress 컨트롤러에서 헤더를 설정하도록 지정합니다.
  • Never는 Ingress 컨트롤러에서 헤더를 설정하지 않고 기존 헤더를 보존하도록 지정합니다.

headerNameCaseAdjustments를 설정하여 HTTP 헤더 이름에 적용할 수 있는 케이스 조정을 지정할 수 있습니다. 각 조정은 원하는 대문자를 사용하여 HTTP 헤더 이름으로 지정됩니다. 예를 들어 X-Forwarded-For를 지정하면 지정된 대문자를 갖도록 x-forwarded-for HTTP 헤더를 조정해야 합니다.

이러한 조정은 일반 텍스트, 에지 종료 및 재암호화 경로에만 적용되며 HTTP/1을 사용할 때만 적용됩니다.

요청 헤더의 경우 이러한 조정은 haproxy.router.openshift.io/h1-adjust-case=true 주석이 있는 경로에만 적용됩니다. 응답 헤더의 경우 이러한 조정이 모든 HTTP 응답에 적용됩니다. 이 필드가 비어 있으면 요청 헤더가 조정되지 않습니다.

tuningOptions

tuningOptions는 Ingress 컨트롤러 Pod의 성능을 튜닝하는 옵션을 지정합니다.

  • headerBufferBytes는 Ingress 컨트롤러 연결 세션에 대해 예약된 메모리 양을 지정합니다. Ingress 컨트롤러에 HTTP/2가 활성화된 경우 이 값은 16384 이상이어야 합니다. 설정하지 않으면 기본값은 32768바이트입니다. headerBufferBytes 값이 너무 작은 headerBufferBytes 값은 Ingress 컨트롤러가 손상될 수 있으며 너무 큰 headerBufferBytes 값은 Ingress 컨트롤러가 필요한 것보다 훨씬 더 많은 메모리를 사용할 수 있기 때문에 권장되지 않습니다.
  • headerBufferMaxRewriteBytes는 HTTP 헤더 재작성 및 Ingress 컨트롤러 연결 세션에 대한 headerBufferBytes의 바이트 단위로 예약해야 하는 메모리 양을 지정합니다. headerBufferMaxRewriteBytes의 최소 값은 4096입니다. 헤더BufferBytes는 들어오는 HTTP 요청에 대한 headerBufferMaxRewriteBytes보다 커야 합니다. 설정하지 않으면 기본값은 8192바이트입니다. headerBufferMaxRewriteBytes 값이 너무 작은 값은 Ingress 컨트롤러 및 headerBufferMaxRewriteBytes 값이 너무 커서 Ingress 컨트롤러가 필요한 것보다 훨씬 더 많은 메모리를 사용할 수 있기 때문에 이 필드를 설정하지 않는 것이 좋습니다.
  • threadCount는 HAProxy 프로세스별로 생성할 스레드 수를 지정합니다. 더 많은 스레드를 생성하면 각 Ingress 컨트롤러 Pod가 더 많은 시스템 리소스 비용으로 더 많은 연결을 처리할 수 있습니다. HAProxy는 최대 64개의 스레드를 지원합니다. 이 필드가 비어 있으면 Ingress 컨트롤러는 기본값 4 스레드를 사용합니다. 기본값은 향후 릴리스에서 변경될 수 있습니다. HAProxy 스레드 수를 늘리면 Ingress 컨트롤러 Pod에서 부하에 더 많은 CPU 시간을 사용할 수 있고 다른 Pod에서 수행해야 하는 CPU 리소스를 수신하지 못하므로 이 필드를 설정하는 것은 권장되지 않습니다. 스레드 수를 줄이면 Ingress 컨트롤러가 제대로 작동하지 않을 수 있습니다.
참고

모든 매개변수는 선택 사항입니다.

5.2.1. Ingress 컨트롤러 TLS 보안 프로파일

TLS 보안 프로필은 서버가 서버에 연결할 때 연결 클라이언트가 사용할 수 있는 암호를 규제하는 방법을 제공합니다.

5.2.1.1. TLS 보안 프로필 이해

TLS(Transport Layer Security) 보안 프로필을 사용하여 다양한 OpenShift Container Platform 구성 요소에 필요한 TLS 암호를 정의할 수 있습니다. OpenShift Container Platform TLS 보안 프로필은 Mozilla 권장 구성을 기반으로 합니다.

각 구성 요소에 대해 다음 TLS 보안 프로필 중 하나를 지정할 수 있습니다.

표 5.1. TLS 보안 프로필

프로필설명

Old

이 프로필은 레거시 클라이언트 또는 라이브러리와 함께 사용하기 위한 것입니다. 프로필은 이전 버전과의 호환성 권장 구성을 기반으로 합니다.

Old 프로파일에는 최소 TLS 버전 1.0이 필요합니다.

참고

Ingress 컨트롤러의 경우 최소 TLS 버전이 1.0에서 1.1로 변환됩니다.

Intermediate

이 프로필은 대부분의 클라이언트에서 권장되는 구성입니다. Ingress 컨트롤러, kubelet 및 컨트롤 플레인의 기본 TLS 보안 프로필입니다. 프로필은 중간 호환성 권장 구성을 기반으로 합니다.

Intermediate 프로필에는 최소 TLS 버전이 1.2가 필요합니다.

Modern

이 프로필은 이전 버전과의 호환성이 필요하지 않은 최신 클라이언트와 사용하기 위한 것입니다. 이 프로필은 최신 호환성 권장 구성을 기반으로 합니다.

Modern 프로파일에는 최소 TLS 버전 1.3이 필요합니다.

중요

현재 Modern 프로파일은 지원되지 않습니다.

사용자 지정

이 프로필을 사용하면 사용할 TLS 버전과 암호를 정의할 수 있습니다.

주의

잘못된 구성으로 인해 문제가 발생할 수 있으므로 Custom 프로파일을 사용할 때는 주의하십시오.

참고

사전 정의된 프로필 유형 중 하나를 사용하는 경우 유효한 프로필 구성은 릴리스마다 변경될 수 있습니다. 예를 들어 릴리스 X.Y.Z에 배포된 Intermediate 프로필을 사용하는 사양을 고려할 때 X.Y.Z+1 릴리스로의 업그레이드로 인해 새 프로필 구성이 적용되어 롤아웃이 발생할 수 있습니다.

5.2.1.2. Ingress 컨트롤러의 TLS 보안 프로필 구성

Ingress 컨트롤러에 대한 TLS 보안 프로필을 구성하려면 IngressController CR(사용자 정의 리소스)을 편집하여 사전 정의된 또는 사용자 지정 TLS 보안 프로필을 지정합니다. TLS 보안 프로필이 구성되지 않은 경우 기본값은 API 서버에 설정된 TLS 보안 프로필을 기반으로 합니다.

이전 TLS 보안 프로파일을 구성하는 샘플 IngressController CR

apiVersion: config.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

TLS 보안 프로필은 Ingress 컨트롤러에 대한 TLS 연결에 대한 최소 TLS 버전과 TLS 암호를 정의합니다.

Status.Tls Profile의 IngressController CR(사용자 정의 리소스) 및 Spec.Tls Security Profile 아래의 구성된 TLS 보안 프로필에서 구성된 TLS 보안 프로필의 암호 및 최소 TLS 보안 프로파일을 확인할 수 있습니다. Custom TLS 보안 프로필의 경우 특정 암호 및 최소 TLS 버전이 두 매개변수에 나열됩니다.

중요

HAProxy Ingress 컨트롤러 이미지는 TLS 1.3을 지원하지 않으며 Modern 프로파일에는 TLS 1.3이 필요하므로 지원되지 않습니다. Ingress Operator는 Modern 프로파일을 Intermediate로 변환합니다.

또한, Ingress Operator는 Old 또는 Custom 프로파일의 TLS 1.01.1로 변환하고 Custom 프로파일의 TLS 1.31.2로 변환합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. openshift-ingress-operator 프로젝트에서 IngressController CR을 편집하여 TLS 보안 프로필을 구성합니다.

    $ oc edit IngressController default -n openshift-ingress-operator
  2. spec.tlsSecurityProfile 필드를 추가합니다.

    사용자 지정 프로필에 대한 IngressController CR 샘플

    apiVersion: operator.openshift.io/v1
    kind: IngressController
     ...
    spec:
      tlsSecurityProfile:
        type: Custom 1
        custom: 2
          ciphers: 3
          - ECDHE-ECDSA-CHACHA20-POLY1305
          - ECDHE-RSA-CHACHA20-POLY1305
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-GCM-SHA256
          minTLSVersion: VersionTLS11
     ...

    1
    TLS 보안 프로필 유형(Old,Intermediate 또는 Custom)을 지정합니다. 기본값은 Intermediate입니다.
    2
    선택한 유형의 적절한 필드를 지정합니다.
    • 이전: {}
    • 중간: {}
    • 사용자 정의:
    3
    사용자 지정 유형의 경우 TLS 암호화 목록 및 최소 허용된 TLS 버전을 지정합니다.
  3. 파일을 저장하여 변경 사항을 적용합니다.

검증

  • IngressController CR에 프로필이 설정되어 있는지 확인합니다.

    $ oc describe IngressController default -n openshift-ingress-operator

    출력 예

    Name:         default
    Namespace:    openshift-ingress-operator
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         IngressController
     ...
    Spec:
     ...
      Tls Security Profile:
        Custom:
          Ciphers:
            ECDHE-ECDSA-CHACHA20-POLY1305
            ECDHE-RSA-CHACHA20-POLY1305
            ECDHE-RSA-AES128-GCM-SHA256
            ECDHE-ECDSA-AES128-GCM-SHA256
          Min TLS Version:  VersionTLS11
        Type:               Custom
     ...

5.2.2. Ingress 컨트롤러 끝점 게시 전략

NodePortService 끝점 게시 전략

NodePortService 끝점 게시 전략에서는 Kubernetes NodePort 서비스를 사용하여 Ingress 컨트롤러를 게시합니다.

이 구성에서는 Ingress 컨트롤러를 배포하기 위해 컨테이너 네트워킹을 사용합니다. 배포를 게시하기 위해 NodePortService가 생성됩니다. 특정 노드 포트는 OpenShift Container Platform에 의해 동적으로 할당됩니다. 그러나 정적 포트 할당을 지원하기 위해 관리형 NodePortService의 노드 포트 필드에 대한 변경 사항은 유지됩니다.

참고

Ingress Operator는 서비스의 .spec.ports[].nodePort 필드에 대한 업데이트를 무시합니다.

기본적으로 포트는 자동으로 할당되며 통합을 위해 포트 할당에 액세스할 수 있습니다. 그러나 동적 포트에 대한 응답으로 쉽게 재구성할 수 없는 기존 인프라와 통합하기 위해 정적 포트 할당이 필요한 경우가 있습니다. 정적 노드 포트와 통합하기 위해 관리 서비스 리소스를 직접 업데이트할 수 있습니다.

자세한 내용은 NodePort에 대한 Kubernetes 서비스 설명서를 참조하십시오.

HostNetwork 끝점 게시 전략

HostNetwork 끝점 게시 전략에서는 Ingress 컨트롤러가 배포된 노드 포트에 Ingress 컨트롤러를 게시합니다.

HostNetwork 끝점 게시 전략이 있는 Ingress 컨트롤러는 노드당 하나의 pod 복제본만 가질 수 있습니다. n개의 복제본이 필요한 경우에는 해당 복제본을 예약할 수 있는 n개 이상의 노드를 사용해야 합니다. 각 pod 복제본은 예약된 노드 호스트에서 포트 80443을 요청하므로 동일한 노드의 다른 pod가 해당 포트를 사용하는 경우 복제본을 노드에 예약할 수 없습니다.

5.3. 기본 Ingress 컨트롤러 보기

Ingress Operator는 OpenShift Container Platform의 핵심 기능이며 즉시 사용이 가능합니다.

모든 새로운 OpenShift Container Platform 설치에는 이름이 ingresscontroller로 기본으로 지정됩니다. 추가 Ingress 컨트롤러를 추가할 수 있습니다. 기본 ingresscontroller가 삭제되면 Ingress Operator가 1분 이내에 자동으로 다시 생성합니다.

프로세스

  • 기본 Ingress 컨트롤러를 확인합니다.

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

5.4. Ingress Operator 상태 보기

Ingress Operator의 상태를 확인 및 조사할 수 있습니다.

프로세스

  • Ingress Operator 상태를 확인합니다.

    $ oc describe clusteroperators/ingress

5.5. Ingress 컨트롤러 로그 보기

Ingress 컨트롤러의 로그를 확인할 수 있습니다.

프로세스

  • Ingress 컨트롤러 로그를 확인합니다.

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator

5.6. Ingress 컨트롤러 상태 보기

특정 Ingress 컨트롤러의 상태를 확인할 수 있습니다.

프로세스

  • Ingress 컨트롤러의 상태를 확인합니다.

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

5.7. Ingress 컨트롤러 구성

5.7.1. 사용자 정의 기본 인증서 설정

관리자는 Secret 리소스를 생성하고 IngressController CR(사용자 정의 리소스)을 편집하여 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다.

사전 요구 사항

  • PEM 인코딩 파일에 인증서/키 쌍이 있어야 합니다. 이때 인증서는 신뢰할 수 있는 인증 기관 또는 사용자 정의 PKI에서 구성한 신뢰할 수 있는 개인 인증 기관의 서명을 받은 인증서입니다.
  • 인증서가 다음 요구 사항을 충족합니다.

    • 인증서는 수신 도메인에 유효합니다.
    • 인증서는 subjectAltName 확장을 사용하여 *.apps.ocp4.example.com과 같은 와일드카드 도메인을 지정합니다.
  • IngressController CR이 있어야 합니다. 기본 설정을 사용할 수 있어야 합니다.

    $ oc --namespace openshift-ingress-operator get ingresscontrollers

    출력 예

    NAME      AGE
    default   10m

참고

임시 인증서가 있는 경우 사용자 정의 기본 인증서가 포함 된 보안의 tls.crt 파일에 인증서가 포함되어 있어야 합니다. 인증서를 지정하는 경우에는 순서가 중요합니다. 서버 인증서 다음에 임시 인증서를 나열해야 합니다.

프로세스

아래에서는 사용자 정의 인증서 및 키 쌍이 현재 작업 디렉터리의 tls.crttls.key 파일에 있다고 가정합니다. 그리고 tls.crttls.key의 실제 경로 이름으로 변경합니다. Secret 리소스를 생성하고 IngressController CR에서 참조하는 경우 custom-certs-default를 다른 이름으로 변경할 수도 있습니다.

참고

이 작업을 수행하면 롤링 배포 전략에 따라 Ingress 컨트롤러가 재배포됩니다.

  1. tls.crttls.key 파일을 사용하여 openshift-ingress 네임스페이스에 사용자 정의 인증서를 포함하는 Secret 리소스를 만듭니다.

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
  2. 새 인증서 보안 키를 참조하도록 IngressController CR을 업데이트합니다.

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
  3. 업데이트가 적용되었는지 확인합니다.

    $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
      --output jsonpath='{.spec.defaultCertificate}'

    출력 예

    map[name:custom-certs-default]

    작은 정보

    또는 다음 YAML을 적용하여 사용자 정의 기본 인증서를 설정할 수 있습니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default

    인증서 보안 이름은 CR을 업데이트하는 데 사용된 값과 일치해야 합니다.

IngressController CR이 수정되면 Ingress Operator는 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러의 배포를 업데이트합니다.

5.7.2. Ingress 컨트롤러 확장

처리량 증가 요구 등 라우팅 성능 또는 가용성 요구 사항을 충족하도록 Ingress 컨트롤러를 수동으로 확장할 수 있습니다. IngressController 리소스를 확장하려면 oc 명령을 사용합니다. 다음 절차는 기본 IngressController를 확장하는 예제입니다.

참고

원하는 수의 복제본을 만드는 데에는 시간이 걸리기 때문에 확장은 즉시 적용되지 않습니다.

프로세스

  1. 기본 IngressController의 현재 사용 가능한 복제본 개수를 살펴봅니다.

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    출력 예

    2

  2. oc patch 명령을 사용하여 기본 IngressController의 복제본 수를 원하는 대로 조정합니다. 다음 예제는 기본 IngressController를 3개의 복제본으로 조정합니다.

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

    출력 예

    ingresscontroller.operator.openshift.io/default patched

  3. 기본 IngressController가 지정한 복제본 수에 맞게 조정되었는지 확인합니다.

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    출력 예

    3

    작은 정보

    또는 다음 YAML을 적용하여 Ingress 컨트롤러를 세 개의 복제본으로 확장할 수 있습니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 3               1
    1
    다른 양의 복제본이 필요한 경우 replicas 값을 변경합니다.

5.7.3. 수신 액세스 로깅 구성

Ingress 컨트롤러가 로그에 액세스하도록 구성할 수 있습니다. 수신 트래픽이 많지 않은 클러스터의 경우 사이드카에 로그를 기록할 수 있습니다. 트래픽이 많은 클러스터가 있는 경우 로깅 스택의 용량을 초과하지 않거나 OpenShift Container Platform 외부의 로깅 인프라와 통합하기 위해 사용자 정의 syslog 끝점으로 로그를 전달할 수 있습니다. 액세스 로그의 형식을 지정할 수도 있습니다.

컨테이너 로깅은 기존 Syslog 로깅 인프라가 없는 경우 트래픽이 적은 클러스터에서 액세스 로그를 활성화하거나 Ingress 컨트롤러의 문제를 진단하는 동안 단기적으로 사용하는 데 유용합니다.

액세스 로그가 OpenShift 로깅 스택 용량을 초과할 수 있는 트래픽이 많은 클러스터 또는 로깅 솔루션이 기존 Syslog 로깅 인프라와 통합되어야 하는 환경에는 Syslog가 필요합니다. Syslog 사용 사례는 중첩될 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

사이드카에 Ingress 액세스 로깅을 구성합니다.

  • 수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. 사이드카 컨테이너에 로깅을 지정하려면 Container spec.logging.access.destination.type을 지정해야 합니다. 다음 예제는 Container 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      endpointPublishingStrategy:
        type: NodePortService 1
      logging:
        access:
          destination:
            type: Container
    1
    사이드카에 Ingress 액세스 로깅을 구성하는 데 NodePortService가 필요하지 않습니다. 수신 로깅은 모든 endpointPublishingStrategy와 호환됩니다.
  • 사이드카에 로그를 기록하도록 Ingress 컨트롤러를 구성하면 Operator는 Ingress 컨트롤러 Pod에 logs 라는 컨테이너를 만듭니다.

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs

    출력 예

    2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

Syslog 끝점에 대한 Ingress 액세스 로깅을 구성합니다.

  • 수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. Syslog 끝점 대상에 로깅을 지정하려면 spec.logging.access.destination.type에 대한 Syslog를 지정해야 합니다. 대상 유형이 Syslog인 경우, spec.logging.access.destination.syslog.endpoint를 사용하여 대상 끝점을 지정해야 하며 spec.logging.access.destination.syslog.facility를 사용하여 장치를 지정할 수 있습니다. 다음 예제는 Syslog 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      endpointPublishingStrategy:
        type: NodePortService
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
    참고

    syslog 대상 포트는 UDP여야 합니다.

특정 로그 형식으로 Ingress 액세스 로깅을 구성합니다.

  • spec.logging.access.httpLogFormat을 지정하여 로그 형식을 사용자 정의할 수 있습니다. 다음 예제는 IP 주소 1.2.3.4 및 포트 10514를 사용하여 syslog 끝점에 로그하는 Ingress 컨트롤러 정의입니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      endpointPublishingStrategy:
        type: NodePortService
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
          httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

Ingress 액세스 로깅을 비활성화합니다.

  • Ingress 액세스 로깅을 비활성화하려면 spec.logging 또는 spec.logging.access를 비워 둡니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      endpointPublishingStrategy:
        type: NodePortService
      logging:
        access: null

5.7.4. Ingress 컨트롤러 스레드 수 설정

클러스터 관리자는 스레드 수를 설정하여 클러스터에서 처리할 수 있는 수신 연결 양을 늘릴 수 있습니다. 기존 Ingress 컨트롤러에 패치하여 스레드의 양을 늘릴 수 있습니다.

사전 요구 사항

  • 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

프로세스

  • 스레드 수를 늘리도록 Ingress 컨트롤러를 업데이트합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
    참고

    많은 리소스를 실행할 수 있는 노드가 있는 경우 원하는 노드의 용량과 일치하는 라벨을 사용하여 spec.nodePlacement.nodeSelector를 구성하고 spec.tuningOptions.threadCount를 적절하게 높은 값으로 구성할 수 있습니다.

5.7.5. Ingress 컨트롤러 분할

Ingress 컨트롤러 또는 라우터는 트래픽이 클러스터로 유입되는 기본 메커니즘이므로 수요가 매우 클 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.

  • 여러 경로를 통해 Ingress 컨트롤러 또는 라우터를 로드 밸런싱하여 변경에 대한 응답 속도 향상
  • 특정 경로가 나머지 경로와 다른 수준의 신뢰성을 가지도록 할당
  • 특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
  • 특정 경로만 추가 기능을 사용하도록 허용
  • 예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출

Ingress 컨트롤러는 라우팅 라벨 또는 네임스페이스 라벨을 분할 방법으로 사용할 수 있습니다.

5.7.5.1. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성

경로 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 경로 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

프로세스

  1. router-internal.yaml 파일을 다음과 같이 편집합니다.

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml

    Ingress 컨트롤러는 type: sharded 라벨이 있는 네임스페이스에서 경로를 선택합니다.

5.7.5.2. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성

네임스페이스 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 네임스페이스 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

프로세스

  1. router-internal.yaml 파일을 다음과 같이 편집합니다.

    # cat router-internal.yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml

    Ingress 컨트롤러는 네임스페이스 선택기에서 선택한 type: sharded 라벨이 있는 네임스페이스에서 경로를 선택합니다.

5.7.6. 내부 로드 밸런서를 사용하도록 Ingress 컨트롤러 구성

클라우드 플랫폼에서 Ingress 컨트롤러를 생성할 때 Ingress 컨트롤러는 기본적으로 퍼블릭 클라우드 로드 밸런서에 의해 게시됩니다. 관리자는 내부 클라우드 로드 밸런서를 사용하는 Ingress 컨트롤러를 생성할 수 있습니다.

주의

클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.

중요

IngressController오브젝트의 scope를 변경하려면, 해당 IngressController 오브젝트를 삭제한 후 다시 생성해야 합니다. CR(사용자 정의 리소스)을 생성한 후에는 .spec.endpointPublishingStrategy.loadBalancer.scope 매개변수를 변경할 수 없습니다.

구현 세부 사항은 Kubernetes 서비스 설명서를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 예제와 같이 <name>-ingress-controller.yam 파일에 IngressController CR(사용자 정의 리소스)을 생성합니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> 1
    spec:
      domain: <domain> 2
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal 3
    1
    <name>IngressController 오브젝트의 이름으로 변경합니다.
    2
    컨트롤러가 게시한 애플리케이션의 domain을 지정합니다.
    3
    내부 로드 밸런서를 사용하려면 Internal 값을 지정합니다.
  2. 다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.

    $ oc create -f <name>-ingress-controller.yaml 1
    1
    <name>IngressController 오브젝트의 이름으로 변경합니다.
  3. 선택 사항: Ingress 컨트롤러가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc --all-namespaces=true get ingresscontrollers

5.7.7. GCP에서 Ingress 컨트롤러에 대한 글로벌 액세스 구성

내부 로드 밸런서가 있는 GCP에서 생성된 Ingress 컨트롤러는 서비스의 내부 IP 주소를 생성합니다. 클러스터 관리자는 글로벌 액세스 옵션을 지정하여 동일한 VPC 네트워크 및 컴퓨팅 리전 내의 모든 클라이언트가 로드 밸런서와 컴퓨팅 리전 내의 클라이언트가 클러스터에서 실행되는 워크로드에 도달할 수 있도록 할 수 있습니다.

자세한 내용은 GCP 설명서를 참조하십시오.

사전 요구 사항

  • GCP 인프라에 OpenShift Container Platform 클러스터를 배포했습니다.
  • 내부 로드 밸런서를 사용하도록 Ingress 컨트롤러를 구성했습니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 글로벌 액세스를 허용하도록 Ingress 컨트롤러 리소스를 구성합니다.

    참고

    Ingress 컨트롤러를 생성하고 글로벌 액세스 옵션을 지정할 수도 있습니다.

    1. Ingress 컨트롤러 리소스를 구성합니다.

      $ oc -n openshift-ingress-operator edit ingresscontroller/default
    2. YAML 파일을 편집합니다.

      Global에 대한 clientAccess 구성 샘플

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 1
                type: GCP
              scope: Internal
            type: LoadBalancerService

      1
      gcp.clientAccessGlobal로 설정합니다.
    3. 파일을 저장하여 변경 사항을 적용합니다.
  2. 다음 명령을 실행하여 서비스가 글로벌 액세스를 허용하는지 확인합니다.

    $ oc -n openshift-ingress edit svc/router-default -o yaml

    출력에서 주석 networking.gke.io/internal-load-balancer-allow-global-access가 있는 GCP에 글로벌 액세스가 활성화되어 있음을 보여줍니다.

5.7.8. 클러스터의 기본 Ingress 컨트롤러를 내부로 구성

클러스터를 삭제하고 다시 생성하여 클러스터의 default Ingress 컨트롤러를 내부용으로 구성할 수 있습니다.

주의

클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.

중요

IngressController오브젝트의 scope를 변경하려면, 해당 IngressController 오브젝트를 삭제한 후 다시 생성해야 합니다. CR(사용자 정의 리소스)을 생성한 후에는 .spec.endpointPublishingStrategy.loadBalancer.scope 매개변수를 변경할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 클러스터의 기본 Ingress 컨트롤러를 삭제하고 다시 생성하여 내부용으로 구성합니다.

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF

5.7.9. 경로 허용 정책 구성

관리자 및 애플리케이션 개발자는 도메인 이름이 동일한 여러 네임스페이스에서 애플리케이션을 실행할 수 있습니다. 이러한 기능은 동일한 호스트 이름에 노출되는 마이크로 서비스를 여러 팀에서 개발하는 조직을 위한 것입니다.

주의

네임스페이스 간 클레임은 네임스페이스 간 신뢰가 구축된 클러스터에만 허용해야 합니다. 그러지 않으면 악의적인 사용자가 호스트 이름을 장악할 수 있습니다. 따라서 기본 허용 정책에서는 네임스페이스 간 호스트 이름 클레임을 허용하지 않습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야 합니다.

프로세스

  • 다음 명령을 사용하여 ingresscontroller 리소스 변수의 .spec.routeAdmission 필드를 편집합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

    샘플 Ingress 컨트롤러 구성

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...

    작은 정보

    또는 다음 YAML을 적용하여 경로 승인 정책을 구성할 수 있습니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed

5.7.10. 와일드카드 경로 사용

HAProxy Ingress 컨트롤러는 와일드카드 경로를 지원합니다. Ingress Operator는 wildcardPolicy를 사용하여 Ingress 컨트롤러의 ROUTER_ALLOW_WILDCARD_ROUTES 환경 변수를 구성합니다.

Ingress 컨트롤러의 기본 동작은 와일드카드 정책이 None인 경로를 허용하고, 이는 기존 IngressController 리소스의 이전 버전과 호환됩니다.

프로세스

  1. 와일드카드 정책을 구성합니다.

    1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.

      $ oc edit IngressController
    2. spec에서 wildcardPolicy 필드를 WildcardsDisallowed 또는 WildcardsAllowed로 설정합니다.

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

5.7.11. X-Forwarded 헤더 사용

HAProxy Ingress 컨트롤러를 구성하여 ForwardedX-Forwarded-For를 포함한 HTTP 헤더 처리 방법에 대한 정책을 지정합니다. Ingress Operator는 HTTPHeaders 필드를 사용하여 Ingress 컨트롤러의 ROUTER_SET_FORWARDED_HEADERS 환경 변수를 구성합니다.

프로세스

  1. Ingress 컨트롤러에 대한 HTTPHeaders 필드를 구성합니다.

    1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.

      $ oc edit IngressController
    2. spec에서 HTTPHeaders 정책 필드를 Append, Replace, IfNone 또는 Never로 설정합니다.

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append
사용 사례 예

클러스터 관리자는 다음을 수행할 수 있습니다.

  • Ingress 컨트롤러로 전달하기 전에 X-Forwarded-For 헤더를 각 요청에 삽입하는 외부 프록시를 구성합니다.

    헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 never 정책을 지정합니다. 그러면 Ingress 컨트롤러에서 헤더를 설정하지 않으며 애플리케이션은 외부 프록시에서 제공하는 헤더만 수신합니다.

  • 외부 프록시에서 외부 클러스터 요청에 설정한 X-Forwarded-For 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성합니다.

    외부 프록시를 통과하지 않는 내부 클러스터 요청에 X-Forwarded-For 헤더를 설정하도록 Ingress 컨트롤러를 구성하려면 if-none 정책을 지정합니다. HTTP 요청에 이미 외부 프록시를 통해 설정된 헤더가 있는 경우 Ingress 컨트롤러에서 해당 헤더를 보존합니다. 요청이 프록시를 통해 제공되지 않아 헤더가 없는 경우에는 Ingress 컨트롤러에서 헤더를 추가합니다.

애플리케이션 개발자는 다음을 수행할 수 있습니다.

  • X-Forwarded-For 헤더를 삽입하는 애플리케이션별 외부 프록시를 구성합니다.

    다른 경로에 대한 정책에 영향을 주지 않으면서 애플리케이션 경로에 대한 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 애플리케이션 경로에 주석 haproxy.router.openshift.io/set-forwarded-headers: if-none 또는 haproxy.router.openshift.io/set-forwarded-headers: never를 추가하십시오.

    참고

    Ingress 컨트롤러에 전역적으로 설정된 값과 관계없이 경로별로 haproxy.router.openshift.io/set-forwarded-headers 주석을 설정할 수 있습니다.

5.7.12. HTTP/2 수신 연결 사용

이제 HAProxy에서 투명한 엔드 투 엔드 HTTP/2 연결을 활성화할 수 있습니다. 애플리케이션 소유자는 이를 통해 단일 연결, 헤더 압축, 바이너리 스트림 등 HTTP/2 프로토콜 기능을 활용할 수 있습니다.

개별 Ingress 컨트롤러 또는 전체 클러스터에 대해 HAProxy에서 HTTP/2 연결을 활성화할 수 있습니다.

클라이언트에서 HAProxy로의 연결에 HTTP/2 사용을 활성화하려면 경로에서 사용자 정의 인증서를 지정해야 합니다. 기본 인증서를 사용하는 경로에서는 HTTP/2를 사용할 수 없습니다. 이것은 동일한 인증서를 사용하는 다른 경로의 연결을 클라이언트가 재사용하는 등 동시 연결로 인한 문제를 방지하기 위한 제한입니다.

HAProxy에서 애플리케이션 pod로의 연결은 re-encrypt 라우팅에만 HTTP/2를 사용할 수 있으며 Edge termination 또는 비보안 라우팅에는 사용할 수 없습니다. 이 제한은 백엔드와 HTTP/2 사용을 협상할 때 HAProxy가 TLS의 확장인 ALPN(Application-Level Protocol Negotiation)을 사용하기 때문에 필요합니다. 이는 엔드 투 엔드 HTTP/2가 패스스루(passthrough) 및 re-encrypt 라우팅에는 적합하지만 비보안 또는 Edge termination 라우팅에는 적합하지 않음을 의미합니다.

중요

패스스루(passthrough)가 아닌 경로의 경우 Ingress 컨트롤러는 클라이언트와의 연결과 관계없이 애플리케이션에 대한 연결을 협상합니다. 다시 말해 클라이언트가 Ingress 컨트롤러에 연결하여 HTTP/1.1을 협상하고, Ingress 컨트롤러가 애플리케이션에 연결하여 HTTP/2를 협상하고, 클라이언트 HTTP/1.1 연결에서 받은 요청을 HTTP/2 연결을 사용하여 애플리케이션에 전달할 수 있습니다. Ingress 컨트롤러는 WebSocket을 HTTP/2로 전달할 수 없고 HTTP/2 연결을 WebSocket으로 업그레이드할 수 없기 때문에 나중에 클라이언트가 HTTP/1.1 연결을 WebSocket 프로토콜로 업그레이드하려고 하면 문제가 발생하게 됩니다. 결과적으로, WebSocket 연결을 허용하는 애플리케이션이 있는 경우 HTTP/2 프로토콜 협상을 허용하지 않아야 합니다. 그러지 않으면 클라이언트가 WebSocket 프로토콜로 업그레이드할 수 없게 됩니다.

프로세스

단일 Ingress 컨트롤러에서 HTTP/2를 활성화합니다.

  • Ingress 컨트롤러에서 HTTP/2를 사용하려면 다음과 같이 oc annotate 명령을 입력합니다.

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

    <ingresscontroller_name>을 주석 처리할 Ingress 컨트롤러의 이름으로 변경합니다.

전체 클러스터에서 HTTP/2를 활성화합니다.

  • 전체 클러스터에 HTTP/2를 사용하려면 oc annotate 명령을 입력합니다.

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    작은 정보

    또는 다음 YAML을 적용하여 주석을 추가할 수 있습니다.

    apiVersion: v1
    kind: IngressController
    metadata:
      annotations:
        ingress.operator.openshift.io/default-enable-http2: "true"

5.7.13. Ingress 컨트롤러에 대한 PROXY 프로토콜 구성

클러스터 관리자는 Ingress 컨트롤러에서 HostNetwork 또는 NodePortService 끝점 게시 전략 유형을 사용하는 경우 PROXY 프로토콜을 구성할 수 있습니다. PROXY 프로토콜을 사용하면 로드 밸런서에서 Ingress 컨트롤러가 수신하는 연결에 대한 원래 클라이언트 주소를 유지할 수 있습니다. 원래 클라이언트 주소는 HTTP 헤더를 로깅, 필터링 및 삽입하는 데 유용합니다. 기본 구성에서 Ingress 컨트롤러가 수신하는 연결에는 로드 밸런서와 연결된 소스 주소만 포함됩니다.

이 기능은 클라우드 배포에서 지원되지 않습니다. 이 제한 사항은 OpenShift Container Platform이 클라우드 플랫폼에서 실행되고 IngressController에서 서비스 로드 밸런서를 사용해야 함을 지정하기 때문에 Ingress Operator는 로드 밸런서 서비스를 구성하고 소스 주소를 유지하기 위한 플랫폼 요구 사항에 따라 PROXY 프로토콜을 활성화하기 때문입니다.

주의

연결 실패를 방지하려면 PROXY 프로토콜을 사용하도록 Ingress 컨트롤러 및 로드 밸런서를 둘 다 구성합니다.

사전 요구 사항

  • Ingress 컨트롤러를 생성하셨습니다.

프로세스

  1. Ingress 컨트롤러 리소스를 편집합니다.

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
  2. PROXY 구성을 설정합니다.

    • Ingress 컨트롤러에서 hostNetwork 끝점 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.hostNetwork.protocol 하위 필드를 PROXY로 설정합니다.

      PROXY에대한 hostNetwork 구성 샘플

        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: NodePortService

    • Ingress 컨트롤러에서 NodePortService 끝점 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.nodePort.protocol 하위 필드를 PROXY로 설정합니다.

      PROXY로의 nodePort 구성 샘플

        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService

5.7.14. AWS에서 Ingress 컨트롤러 Operator의 애플리케이션 도메인 구성

클러스터 관리자는 appsDomain 필드를 구성하여 사용자가 생성한 경로에 대해 대체 기본 도메인을 지정할 수 있습니다. 대체 도메인을 지정하면 새 경로의 기본 호스트를 결정하기 위해 기본 클러스터 도메인을 덮어씁니다.

예를 들어, 회사의 DNS 도메인을 클러스터에서 실행되는 애플리케이션의 경로 및 인그레스의 기본 도메인으로 사용할 수 있습니다.

사전 요구 사항

  • AWS 인프라에 OpenShift Container Platform 클러스터를 배포했습니다.
  • oc 명령줄 인터페이스를 설치했습니다.

프로세스

  1. 사용자 생성 경로에 대한 대체 기본 도메인을 지정하여 appsDomain 필드를 구성합니다.

    1. Ingress 컨트롤러 Operator를 편집합니다.

      $ oc edit ingresses.config/cluster -o yaml
    2. YAML 파일을 편집합니다.

      apps.acme.io에 대한 샘플 appsDomain 설정

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.<domain_url>
        appsDomain: apps.acme.io

  2. 경로를 노출하고 경로 도메인 변경을 확인하여 기존 경로에 새 도메인 이름이 포함되어 있는지 확인합니다.

    참고

    경로를 노출하기 전에 openshift-apiserver가 롤링 업데이트를 완료할 때까지 기다립니다.

    1. 경로를 노출합니다.

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed
    2. 경로 도메인 변경을 확인합니다.

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello-openshift-my-project.apps.acme.io          hello-openshift   8080-tcp                 None

5.7.15. HTTP 헤더 케이스 변환

예를 들어, HAProxy 2.2 소문자 HTTP 헤더 이름은 기본적으로 Host: xyz.com을 host: xyz.com으로 변경합니다. 기존 애플리케이션이 HTTP 헤더 이름의 대문자에 민감한 경우 Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API 필드를 사용하여 기존 애플리케이션을 수정할 때 까지 지원합니다.

중요

OpenShift Container Platform 4.8에는 HAProxy 2.2가 포함되어 있으므로 업그레이드하기 전에 spec.httpHeaders.headerNameCaseAdjustments를 사용하여 필요한 구성을 추가해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

클러스터 관리자는 oc patch 명령을 입력하거나 Ingress 컨트롤러 YAML 파일에서 HeaderNameCaseAdjustments 필드를 설정하여 HTTP 헤더 케이스를 변환할 수 있습니다.

  • oc patch 명령을 입력하여 대문자로 작성할 HTTP 헤더를 지정합니다.

    1. oc patch 명령을 입력하여 HTTP 호스트 헤더를 Host로 변경합니다.

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
    2. 애플리케이션 경로에 주석을 답니다.

      $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true

      그런 다음 Ingress 컨트롤러는 지정된 대로 호스트 요청 헤더를 조정합니다.

  • Ingress 컨트롤러 YAML 파일을 구성하여 HeaderNameCaseAdjustments 필드를 사용하여 조정을 지정합니다.

    1. 다음 예제 Ingress 컨트롤러 YAML은 HTTP/1 요청에 대한 호스트로 호스트 헤더를 적절하게 주석을 달도록 조정합니다.

      Ingress 컨트롤러 YAML의 예

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host

    2. 다음 예제 경로에서는 haproxy.router.openshift.io/h1-adjust-case 주석을 사용하여 HTTP 응답 헤더 이름 케이스를 조정할 수 있습니다.

      경로 YAML의 예

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 1
        name: my-application
        namespace: my-application
      spec:
        to:
          kind: Service
          name: my-application

      1
      haproxy.router.openshift.io/h1-adjust-case를 true로 설정합니다.

5.8. 추가 리소스

6장. 끝점에 대한 연결 확인

CNO(Cluster Network Operator)는 클러스터 내 리소스 간에 연결 상태 검사를 수행하는 연결 확인 컨트롤러인 컨트롤러를 실행합니다. 상태 점검 결과를 검토하여 연결 문제를 진단하거나 현재 조사하고 있는 문제의 원인으로 네트워크 연결을 제거할 수 있습니다.

6.1. 연결 상태 점검 수행

클러스터 리소스에 도달할 수 있는지 확인하기 위해 다음 클러스터 API 서비스 각각에 TCP 연결이 수행됩니다.

  • Kubernetes API 서버 서비스
  • Kubernetes API 서버 끝점
  • OpenShift API 서버 서비스
  • OpenShift API 서버 끝점
  • 로드 밸런서

클러스터의 모든 노드에서 서비스 및 서비스 끝점에 도달할 수 있는지 확인하기 위해 다음 대상 각각에 TCP 연결이 수행됩니다.

  • 상태 점검 대상 서비스
  • 상태 점검 대상 끝점

6.2. 연결 상태 점검 구현

연결 검증 컨트롤러는 클러스터의 연결 확인 검사를 오케스트레이션합니다. 연결 테스트의 결과는 openshift-network-diagnosticsPodNetworkConnectivity 오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.

CNO(Cluster Network Operator)는 클러스터에 여러 리소스를 배포하여 연결 상태 점검을 전달하고 수신합니다.

상태 점검 소스
이 프로그램은 Deployment 오브젝트에서 관리하는 단일 포드 복제본 세트에 배포됩니다. 프로그램은 PodNetworkConnectivity 오브젝트를 사용하고 각 오브젝트에 지정된 spec.targetEndpoint에 연결됩니다.
상태 점검 대상
클러스터의 모든 노드에서 데몬 세트의 일부로 배포된 포드입니다. 포드는 인바운드 상태 점검을 수신 대기합니다. 모든 노드에 이 포드가 있으면 각 노드로의 연결을 테스트할 수 있습니다.

6.3. PodNetworkConnectivityCheck 오브젝트 필드

PodNetworkConnectivityCheck 오브젝트 필드는 다음 표에 설명되어 있습니다.

표 6.1. PodNetworkConnectivityCheck 오브젝트 필드

필드유형설명

metadata.name

string

다음과 같은 형식의 오브젝트 이름: <source>-to-<target>. <target>에서 설명한 대상에는 다음 문자열 중 하나가 포함되어 있습니다.

  • load-balancer-api-external
  • load-balancer-api-internal
  • kubernetes-apiserver-endpoint
  • kubernetes-apiserver-service-cluster
  • network-check-target
  • openshift-apiserver-endpoint
  • openshift-apiserver-service-cluster

metadata.namespace

string

오브젝트와 연결된 네임스페이스입니다. 이 값은 항상 openshift-network-diagnostics입니다.

spec.sourcePod

string

연결 확인이 시작된 포드의 이름입니다(예: network-check-source-596b4c6566-rgh92).

spec.targetEndpoint

string

연결 검사의 대상입니다(예: api.devcluster.example.com:6443).

spec.tlsClientCert

object

사용할 TLS 인증서 설정입니다.

spec.tlsClientCert.name

string

해당하는 경우 사용되는 TLS 인증서의 이름입니다. 기본값은 빈 문자열입니다.

status

object

연결 테스트의 조건 및 최근 연결 성공 및 실패의 로그를 나타내는 오브젝트입니다.

status.conditions

array

연결 확인의 최신 상태 및 모든 이전 상태입니다.

status.failures

array

실패한 시도에서의 연결 테스트 로그입니다.

status.outages

array

중단 기간을 포함하는 테스트 로그를 연결합니다.

status.successes

array

성공적인 시도에서의 연결 테스트 로그입니다.

다음 표에서는 status.conditions 배열에서 오브젝트 필드를 설명합니다.

표 6.2. status.conditions

필드유형설명

lastTransitionTime

string

연결 조건이 하나의 상태에서 다른 상태로 전환된 시간입니다.

message

string

사람이 읽기 쉬운 형식으로 마지막 전환에 대한 세부 정보입니다.

reason

string

머신에서 읽을 수 있는 형식으로 전환의 마지막 상태입니다.

status

string

조건의 상태:

type

string

조건의 유형입니다.

다음 표에서는 status.conditions 배열에서 오브젝트 필드를 설명합니다.

표 6.3. status.outages

필드유형설명

end

string

연결 오류가 해결될 때부터의 타임 스탬프입니다.

endLogs

array

서비스 중단의 성공적인 종료와 관련된 로그 항목을 포함한 연결 로그 항목입니다.

message

string

사람이 읽을 수 있는 형식의 중단 세부 정보에 대한 요약입니다.

start

string

연결 오류가 먼저 감지될 때부터의 타임 스탬프입니다.

startLogs

array

원래 오류를 포함한 연결 로그 항목입니다.

연결 로그 필드

연결 로그 항목의 필드는 다음 표에 설명되어 있습니다. 오브젝트는 다음 필드에서 사용됩니다.

  • status.failures[]
  • status.successes[]
  • status.outages[].startLogs[]
  • status.outages[].endLogs[]

표 6.4. 연결 로그 오브젝트

필드유형설명

latency

string

작업 기간을 기록합니다.

message

string

사람이 읽을 수 있는 형식으로 상태를 제공합니다.

reason

string

머신에서 읽을 수 있는 형식으로 상태의 이유를 제공합니다. 값은 TCPConnect, TCPConnectError, DNSResolve, DNSError 중 하나입니다.

success

boolean

로그 항목이 성공 또는 실패인지를 나타냅니다.

time

string

연결 확인 시작 시간입니다.

6.4. 끝점에 대한 네트워크 연결 확인

클러스터 관리자는 API 서버, 로드 밸런서, 서비스 또는 포드와 같은 끝점의 연결을 확인할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 현재 PodNetworkConnectivityCheck 오브젝트를 나열하려면 다음 명령을 입력합니다.

    $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

    출력 예

    NAME                                                                                                                                AGE
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

  2. 연결 테스트 로그를 확인합니다.

    1. 이전 명령의 출력에서 연결 로그를 검토할 끝점을 식별합니다.
    2. 오브젝트를 확인하려면 다음 명령을 입력합니다:

      $ oc get podnetworkconnectivitycheck <name> \
        -n openshift-network-diagnostics -o yaml

      여기서 <name>PodNetworkConnectivityCheck 오브젝트의 이름을 지정합니다.

      출력 예

      apiVersion: controlplane.operator.openshift.io/v1alpha1
      kind: PodNetworkConnectivityCheck
      metadata:
        name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
        namespace: openshift-network-diagnostics
        ...
      spec:
        sourcePod: network-check-source-7c88f6d9f-hmg2f
        targetEndpoint: 10.0.0.4:6443
        tlsClientCert:
          name: ""
      status:
        conditions:
        - lastTransitionTime: "2021-01-13T20:11:34Z"
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnectSuccess
          status: "True"
          type: Reachable
        failures:
        - latency: 2.241775ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:10:34Z"
        - latency: 2.582129ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:09:34Z"
        - latency: 3.483578ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:08:34Z"
        outages:
        - end: "2021-01-13T20:11:34Z"
          endLogs:
          - latency: 2.032018ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              tcp connection to 10.0.0.4:6443 succeeded'
            reason: TCPConnect
            success: true
            time: "2021-01-13T20:11:34Z"
          - latency: 2.241775ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:10:34Z"
          - latency: 2.582129ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:09:34Z"
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
          message: Connectivity restored after 2m59.999789186s
          start: "2021-01-13T20:08:34Z"
          startLogs:
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
        successes:
        - latency: 2.845865ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:14:34Z"
        - latency: 2.926345ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:13:34Z"
        - latency: 2.895796ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:12:34Z"
        - latency: 2.696844ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:11:34Z"
        - latency: 1.502064ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:10:34Z"
        - latency: 1.388857ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:09:34Z"
        - latency: 1.906383ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:08:34Z"
        - latency: 2.089073ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:07:34Z"
        - latency: 2.156994ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:06:34Z"
        - latency: 1.777043ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:05:34Z"

7장. 노드 포트 서비스 범위 구성

클러스터 관리자는 사용 가능한 노드 포트 범위를 확장할 수 있습니다. 클러스터에서 많은 수의 노드 포트를 사용하는 경우 사용 가능한 포트 수를 늘려야 할 수 있습니다.

기본 포트 범위는 30000~32767입니다. 기본 범위 이상으로 확장한 경우에도 포트 범위는 축소할 수 없습니다.

7.1. 사전 요구 사항

  • 클러스터 인프라는 확장된 범위 내에서 지정한 포트에 대한 액세스를 허용해야 합니다. 예를 들어, 노드 포트 범위를 30000~32900으로 확장하는 경우 방화벽 또는 패킷 필터링 구성에서 32768~32900의 포함 포트 범위를 허용해야 합니다.

7.2. 노드 포트 범위 확장

클러스터의 노드 포트 범위를 확장할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 노드 포트 범위를 확장하려면 다음 명령을 입력합니다. <port>를 새 범위에서 가장 큰 포트 번호로 변경합니다.

    $ oc patch network.config.openshift.io cluster --type=merge -p \
      '{
        "spec":
          { "serviceNodePortRange": "30000-<port>" }
      }'
    작은 정보

    또는 다음 YAML을 적용하여 노드 포트 범위를 업데이트할 수 있습니다.

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNodePortRange: "30000-<port>"

    출력 예

    network.config.openshift.io/cluster patched

  2. 구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 업데이트가 적용되려면 몇 분 정도 걸릴 수 있습니다.

    $ oc get configmaps -n openshift-kube-apiserver config \
      -o jsonpath="{.data['config\.yaml']}" | \
      grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

    출력 예

    "service-node-port-range":["30000-33000"]

7.3. 추가 리소스

8장. IP 페일오버 구성

이 주제에서는 OpenShift Container Platform 클러스터의 Pod 및 서비스에 대한 IP 페일오버 구성에 대해 설명합니다.

IP Failover는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 방법은 없으므로 VIP와 VIP가 많은 다른 노드가 없는 노드가 있을 수 있습니다. 노드가 하나뿐이면 모든 VIP가 있습니다.

참고

VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.

IP Failover는 각 VIP의 포트를 모니터링하여 노드에서 포트에 연결할 수 있는지 확인합니다. 포트에 연결할 수 없는 경우 VIP가 노드에 할당되지 않습니다. 포트를 0으로 설정하면 이 확인이 비활성화됩니다. 검사 스크립트는 필요한 테스트를 수행합니다.

IP Failover는 Keepalived를 사용하여 호스트 집합에서 외부에서 액세스할 수 있는 VIP 주소 집합을 호스팅합니다. 각 VIP는 한 번에 하나의 호스트에서만 서비스를 제공합니다. keepalived는 VRRP(Virtual Router Redundancy Protocol: 가상 라우터 중복 프로토콜)를 사용하여 호스트 집합에서 VIP를 대상으로 서비스를 결정합니다. 호스트를 사용할 수 없게 되거나 Keepalived 서비스가 응답하지 않는 경우 VIP가 세트의 다른 호스트로 전환됩니다. 즉, 호스트를 사용할 수 있는 한 VIP는 항상 서비스됩니다.

Keepalived를 실행하는 노드가 확인 스크립트를 통과하면 해당 노드의 VIP가 우선 순위와 현재 마스터의 우선 순위 및 선점 전략에 따라 마스터 상태를 입력할 수 있습니다.

클러스터 관리자는 OPENSHIFT_HA_NOTIFY_SCRIPT 변수를 통해 스크립트를 제공할 수 있으며 이 스크립트는 노드의 VIP 상태가 변경될 때마다 호출됩니다. keepalived는 VIP를 서비스하는 경우 master 상태, 다른 노드가 VIP를 서비스하는 경우 또는 확인 스크립트에 실패할 때 오류 상태에 있는 백업 상태를 사용합니다. 알림 스크립트는 상태가 변경될 때마다 새 상태로 호출됩니다.

OpenShift Container Platform에서 IP Failover 배포 구성을 생성할 수 있습니다. IP Failover 배포 구성은 VIP 주소 집합과 서비스를 서비스할 노드 집합을 지정합니다. 클러스터에는 고유한 VIP 주소 집합을 관리할 때마다 여러 IP 페일오버 배포 구성이 있을 수 있습니다. IP 장애 조치 구성의 각 노드는 IP Failover Pod를 실행하며 이 Pod는 Keepalived를 실행합니다.

VIP를 사용하여 호스트 네트워킹이 있는 포드에 액세스하는 경우 애플리케이션 포드는 IP 페일오버 포드를 실행 중인 모든 노드에서 실행됩니다. 그러면 필요한 경우 모든 IP 장애 조치 노드가 마스터가 되고 VIP를 서비스할 수 있습니다. IP Failover가 있는 모든 노드에서 애플리케이션 포드가 실행되지 않는 경우 일부 IP 장애 조치 노드가 VIP를 서비스하지 않거나 일부 애플리케이션 포드는 트래픽을 수신하지 않습니다. 이 불일치하지 않도록 IP Failover와 애플리케이션 포드 모두에 동일한 선택기 및 복제 수를 사용합니다.

VIP를 사용하여 서비스에 액세스하는 동안 애플리케이션 포드가 실행 중인 위치와 상관없이 서비스가 모든 노드에서 연결할 수 있으므로 모든 노드가 IP Failover 노드 세트에 있을 수 있습니다. 언제든지 IP 페일오버 노드가 마스터가 될 수 있습니다. 서비스는 외부 IP와 서비스 포트를 사용하거나 NodePort를 사용할 수 있습니다.

서비스 정의에서 외부 IP를 사용하는 경우 VIP가 외부 IP로 설정되고 IP Failover 모니터링 포트가 서비스 포트로 설정됩니다. 노드 포트를 사용하면 클러스터의 모든 노드에서 포트가 열려 있으며, 서비스는 현재 VIP를 서비스하는 모든 노드에서 트래픽을 로드 밸런싱합니다. 이 경우 서비스 정의에서 IP Failover 모니터링 포트가 NodePort로 설정됩니다.

중요

NodePort 설정은 권한 있는 작업입니다.

중요

VIP 서비스가 고가용성이지만 성능은 여전히 영향을 받을 수 있습니다. keepalived는 각 VIP가 구성의 일부 노드에서 서비스되도록 하고, 다른 노드가 없는 경우에도 여러 VIP가 동일한 노드에 존재할 수 있습니다. IP Failover가 동일한 노드에 여러 VIP를 배치하면 일련의 VIP를 외부적으로 부하 분산시킬 수 있습니다.

ingressIP를 사용하는 경우 ingressIP 범위와 동일한 VIP 범위를 갖도록 IP Failover를 설정할 수 있습니다. 모니터링 포트를 비활성화할 수도 있습니다. 이 경우 모든 VIP가 클러스터의 동일한 노드에 표시됩니다. 모든 사용자는 ingressIP를 사용하여 서비스를 설정하고 고가용성으로 설정할 수 있습니다.

중요

클러스터에는 최대 254개의 VIP가 있습니다.

8.1. IP Failover 환경 변수

다음 테이블에는 IP Failover를 구성하는 데 사용되는 변수가 포함되어 있습니다.

표 8.1. IP Failover 환경 변수

변수 이름기본설명

OPENSHIFT_HA_MONITOR_PORT

80

IP Failover 포드는 각 가상 IP(VIP)에서 이 포트에 대한 TCP 연결을 엽니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 0으로 설정되면 테스트가 항상 통과합니다.

OPENSHIFT_HA_NETWORK_INTERFACE

 

IP Failover가 VRRP(Virtual Router Redundancy Protocol) 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본값은 eth0입니다.

OPENSHIFT_HA_REPLICA_COUNT

2

생성할 복제본 수입니다. 이는 IP Failover 배포 구성의 spec.replicas 값과 일치해야 합니다.

OPENSHIFT_HA_VIRTUAL_IPS

 

복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: 1.2.3.4-6,1.2.3.9

OPENSHIFT_HA_VRRP_ID_OFFSET

0

가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 0이며 허용되는 범위는 0에서 255 사이입니다.

OPENSHIFT_HA_VIP_GROUPS

 

VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 OPENSHIFT_HA_VIP_GROUPS 변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다.

OPENSHIFT_HA_IPTABLES_CHAIN

입력

VRRP 트래픽을 허용하는 iptables 규칙을 자동으로 추가하는 iptables 체인의 이름입니다. 값을 설정하지 않으면 iptables 규칙이 추가되지 않습니다. 체인이 없으면 생성되지 않습니다.

OPENSHIFT_HA_CHECK_SCRIPT

 

애플리케이션이 작동하는지 확인하기 위해 정기적으로 실행되는 스크립트의 Pod 파일 시스템에 있는 전체 경로 이름입니다.

OPENSHIFT_HA_CHECK_INTERVAL

2

확인 스크립트가 실행되는 기간(초)입니다.

OPENSHIFT_HA_NOTIFY_SCRIPT

 

상태가 변경될 때마다 실행되는 스크립트의 Pod 파일 시스템의 전체 경로 이름입니다.

OPENSHIFT_HA_PREEMPTION

preempt_nodelay 300

더 높은 우선 순위의 호스트를 처리하는 전략입니다. nopreempt 전략에서는 더 낮은 우선 순위 호스트에서 더 높은 우선 순위 호스트로 마스터를 이동하지 않습니다.

8.2. IP 페일오버 구성

클러스터 관리자는 레이블 선택기에 정의된 대로 전체 클러스터 또는 노드의 하위 집합에서 IP Failover를 구성할 수 있습니다. 클러스터에서 여러 IP 페일오버 배포 구성을 구성할 수도 있습니다. 이 배포 구성은 각각 다른 항목과 독립적입니다.

IP Failover 배포 구성을 사용하면 제약 조건 또는 사용된 라벨과 일치하는 각 노드에서 페일오버 포드가 실행됩니다.

이 Pod는 Keepalived를 실행합니다. 이는 끝점을 모니터링하고 VRRP(Virtual Router Redundancy Protocol)를 사용하여 첫 번째 노드가 서비스 또는 엔드포인트에 연결할 수 없는 경우 한 노드에서 다른 노드로의 가상 IP(VIP)에 장애 조치할 수 있습니다.

프로덕션 용도의 경우 두 개 이상의 노드를 선택하고 선택한 노드 수와 동일한 복제본을 설정하는 선택기를 설정합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 풀 시크릿을 생성하셨습니다.

프로세스

  1. IP Failover 서비스 계정을 생성합니다.

    $ oc create sa ipfailover
  2. hostNetwork의 SCC(보안 컨텍스트 제약 조건) 업데이트 :

    $ oc adm policy add-scc-to-user privileged -z ipfailover
    $ oc adm policy add-scc-to-user hostnetwork -z ipfailover
  3. 배포 YAML 파일을 만들어 IP Failover를 구성합니다.

    IP Failover 구성에 대한 배포 YAML의 예

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ipfailover-keepalived 1
      labels:
        ipfailover: hello-openshift
    spec:
      strategy:
        type: Recreate
      replicas: 2
      selector:
        matchLabels:
          ipfailover: hello-openshift
      template:
        metadata:
          labels:
            ipfailover: hello-openshift
        spec:
          serviceAccountName: ipfailover
          privileged: true
          hostNetwork: true
          nodeSelector:
            node-role.kubernetes.io/worker: ""
          containers:
          - name: openshift-ipfailover
            image: quay.io/openshift/ose-keepalived-ipfailover:latest
            ports:
            - containerPort: 63000
              hostPort: 63000
            imagePullPolicy: IfNotPresent
            securityContext:
              privileged: true
            volumeMounts:
            - name: lib-modules
              mountPath: /lib/modules
              readOnly: true
            - name: host-slash
              mountPath: /host
              readOnly: true
              mountPropagation: HostToContainer
            - name: etc-sysconfig
              mountPath: /etc/sysconfig
              readOnly: true
            - name: config-volume
              mountPath: /etc/keepalive
            env:
            - name: OPENSHIFT_HA_CONFIG_NAME
              value: "ipfailover"
            - name: OPENSHIFT_HA_VIRTUAL_IPS 2
              value: "1.1.1.1-2"
            - name: OPENSHIFT_HA_VIP_GROUPS 3
              value: "10"
            - name: OPENSHIFT_HA_NETWORK_INTERFACE 4
              value: "ens3" #The host interface to assign the VIPs
            - name: OPENSHIFT_HA_MONITOR_PORT 5
              value: "30060"
            - name: OPENSHIFT_HA_VRRP_ID_OFFSET 6
              value: "0"
            - name: OPENSHIFT_HA_REPLICA_COUNT 7
              value: "2" #Must match the number of replicas in the deployment
            - name: OPENSHIFT_HA_USE_UNICAST
              value: "false"
            #- name: OPENSHIFT_HA_UNICAST_PEERS
              #value: "10.0.148.40,10.0.160.234,10.0.199.110"
            - name: OPENSHIFT_HA_IPTABLES_CHAIN 8
              value: "INPUT"
            #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 9
            #  value: /etc/keepalive/mynotifyscript.sh
            - name: OPENSHIFT_HA_CHECK_SCRIPT 10
              value: "/etc/keepalive/mycheckscript.sh"
            - name: OPENSHIFT_HA_PREEMPTION 11
              value: "preempt_delay 300"
            - name: OPENSHIFT_HA_CHECK_INTERVAL 12
              value: "2"
            livenessProbe:
              initialDelaySeconds: 10
              exec:
                command:
                - pgrep
                - keepalived
          volumes:
          - name: lib-modules
            hostPath:
              path: /lib/modules
          - name: host-slash
            hostPath:
              path: /
          - name: etc-sysconfig
            hostPath:
              path: /etc/sysconfig
          # config-volume contains the check script
          # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
          - configMap:
              defaultMode: 0755
              name: keepalived-checkscript
            name: config-volume
          imagePullSecrets:
            - name: openshift-pull-secret 13

    1
    IP 페일오버 배포의 이름입니다.
    2
    복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: 1.2.3.4-6,1.2.3.9
    3
    VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 OPENSHIFT_HA_VIP_GROUPS 변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다.
    4
    IP Failover가 VRRP 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본적으로 eth0이 사용됩니다.
    5
    IP Failover 포드는 각 VIP에서 이 포트에 대한 TCP 연결을 열려고 합니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 0으로 설정되면 테스트가 항상 통과합니다. 기본값은 80입니다.
    6
    가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 0이며 허용되는 범위는 0에서 255 사이입니다.
    7
    생성할 복제본 수입니다. 이는 IP Failover 배포 구성의 spec.replicas 값과 일치해야 합니다. 기본값은 2입니다.
    8
    VRRP 트래픽을 허용하는 iptables 규칙을 자동으로 추가하는 iptables 체인의 이름입니다. 값을 설정하지 않으면 iptables 규칙이 추가되지 않습니다. 체인이 존재하지 않으면 이 체인이 생성되지 않으며 Keepalived는 유니캐스트 모드로 작동합니다. 기본값은 INPUT입니다.
    9
    상태가 변경될 때마다 실행되는 스크립트의 Pod 파일 시스템의 전체 경로 이름입니다.
    10
    애플리케이션이 작동하는지 확인하기 위해 정기적으로 실행되는 스크립트의 Pod 파일 시스템에 있는 전체 경로 이름입니다.
    11
    더 높은 우선 순위의 호스트를 처리하는 전략입니다. 기본값은 preempt_delay 300으로, 우선순위가 낮은 마스터가 VIP를 유지하는 경우 Keepalived 인스턴스가 5분 후에 VIP를 대신합니다.
    12
    확인 스크립트가 실행되는 기간(초)입니다. 기본값은 2입니다.
    13
    배포를 만들기 전에 가져오기 시크릿을 생성합니다. 그렇지 않으면 배포를 생성할 때 오류가 발생합니다.

8.3. 가상 IP 주소 정보

keepalived는 가상 IP 주소 집합(VIP)을 관리합니다. 관리자는 다음 주소를 모두 확인해야 합니다.

  • 클러스터 외부에서 구성된 호스트에서 액세스할 수 있습니다.
  • 클러스터 내의 다른 목적으로는 사용되지 않습니다.

각 노드의 keepalive는 필요한 서비스가 실행 중인지 여부를 결정합니다. 이 경우 VIP가 지원되고 Keepalived가 협상에 참여하여 VIP를 제공하는 노드를 결정합니다. 노드가 참여하려면 VIP의 워치 포트에서 서비스를 수신 대기하거나 점검을 비활성화해야 합니다.

참고

세트의 각 VIP는 다른 노드에서 제공할 수 있습니다.

8.4. 검사 구성 및 스크립트 알림

keepalived는 사용자가 제공한 선택적 확인 스크립트를 정기적으로 실행하여 애플리케이션의 상태를 모니터링합니다. 예를 들어 스크립트는 요청을 발행하고 응답을 확인하여 웹 서버를 테스트할 수 있습니다.

확인 스크립트를 제공하지 않으면 TCP 연결을 테스트하는 간단한 기본 스크립트가 실행됩니다. 이 기본 테스트는 모니터 포트가 0이면 비활성화됩니다.

각 IP 장애 조치 포드는 포드가 실행 중인 노드에서 하나 이상의 가상 IP(VIP)를 관리하는 Keepalived 데몬을 관리합니다. Keepalived 데몬은 해당 노드의 각 VIP 상태를 유지합니다. 특정 노드의 특정 VIP는 마스터,백업 또는 결함 상태일 수 있습니다.

마스터 상태에 있는 노드에서 해당 VIP에 대한 확인 스크립트가 실패하면 해당 노드의 VIP가 오류 상태가 되면 재협상이 트리거됩니다. 재협상하는 동안 장애 상태에 없는 노드의 모든 VIP는 VIP를 통해 어떤 노드를 결정하는 데 참여합니다. 결과적으로 VIP는 일부 노드의 마스터 상태로 전환되고 VIP는 다른 노드의 백업 상태로 유지됩니다.

백업 상태의 VIP 노드가 실패하면 해당 노드의 VIP가 결함 상태가 됩니다. 확인 스크립트가 오류 상태의 노드에서 VIP를 다시 전달하면 해당 노드의 VIP 상태가 오류 상태를 종료하고 마스터 상태로 전환하도록 협상합니다. 그런 다음 해당 노드의 VIP는 마스터 또는 백업 상태를 입력할 수 있습니다.

클러스터 관리자는 상태가 변경될 때마다 호출되는 선택적 알림 스크립트를 제공할 수 있습니다. keepalived는 다음 세 개의 매개변수를 스크립트에 전달합니다.

  • $1 - 그룹 또는 인스턴스
  • $2 - 그룹 또는 인스턴스의이름
  • $3 - 새 상태: 마스터,백업 또는 오류

검사 및 알림 스크립트가 IP Failover 포드에서 실행되고 호스트 파일 시스템이 아닌 포드 파일 시스템을 사용합니다. 그러나 IP Failover Pod를 사용하면 /hosts 마운트 경로에서 호스트 파일 시스템을 사용할 수 있습니다. 점검을 구성하거나 스크립트에 알릴 때 스크립트에 대한 전체 경로를 제공해야 합니다. 스크립트를 제공하는 데 권장되는 접근 방식은 구성 맵을 사용하는 것입니다.

Keepalived가 시작될 때마다 로드되는 check 및 notify 스크립트의 전체 경로 이름이 Keepalived 구성 파일인 _/etc/keepalived/keepalived.conf에 추가됩니다. 스크립트는 다음과 같이 구성 맵이 있는 Pod에 추가할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 원하는 스크립트를 생성하고 해당 스크립트를 보유할 구성 맵을 생성합니다. 스크립트에는 입력 인수가 없으며 OK (확인)와 fail (실패)의 경우 1을 반환해야 합니다.

    검사 스크립트mycheckscript.sh:

    #!/bin/bash
        # Whatever tests are needed
        # E.g., send request and verify response
    exit 0
  2. config map을 생성합니다.

    $ oc create configmap mycustomcheck --from-file=mycheckscript.sh
  3. 포드에 스크립트를 추가합니다. 마운트된 구성 맵 파일의 defaultMode는 oc 명령을 사용하거나 배포 구성을 편집하여 실행할 수 있어야 합니다. 0755 값인493개의 10진수는 일반적입니다.

    $ oc set env deploy/ipfailover-keepalived \
        OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
    $ oc set volume deploy/ipfailover-keepalived --add --overwrite \
        --name=config-volume \
        --mount-path=/etc/keepalive \
        --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
    참고

    oc set env 명령은 공백을 구분합니다. = 기호 양쪽에 공백이 없어야 합니다.

    작은 정보

    또는 ipfailover-keepalived 배포 구성을 편집할 수 있습니다.

    $ oc edit deploy ipfailover-keepalived
        spec:
          containers:
          - env:
            - name: OPENSHIFT_HA_CHECK_SCRIPT  1
              value: /etc/keepalive/mycheckscript.sh
    ...
            volumeMounts: 2
            - mountPath: /etc/keepalive
              name: config-volume
          dnsPolicy: ClusterFirst
    ...
          volumes: 3
          - configMap:
              defaultMode: 0755 4
              name: customrouter
            name: config-volume
    ...
    1
    spec.container.env 필드에서 마운트된 스크립트 파일을 가리키도록 OPENSHIFT_HA_CHECK_SCRIPT 환경 변수를 추가합니다.
    2
    spec.container.volumeMounts 필드를 추가하여 마운트 지점을 생성합니다.
    3
    구성 맵을 언급하도록 새 spec.volumes 필드를 추가합니다.
    4
    이 설정은 파일에 대한 실행 권한을 설정합니다. 다시 읽으면 10진수 493로 표시됩니다.

    변경 사항을 저장하고 편집기를 종료합니다. 그러면 ipfailover-keepalived가 다시 시작됩니다.

8.5. VRRP 선점 구성

노드의 가상 IP(VIP)가 확인 스크립트를 전달하여 오류 상태를 유지하면 노드의 VIP가 현재 마스터 상태에 있는 노드의 VIP보다 우선 순위가 낮은 경우 백업 상태가 됩니다. 그러나 오류 상태를 유지하는 노드의 VIP가 우선 순위가 더 높은 경우 선점 전략은 클러스터에서 해당 역할을 결정합니다.

nopreempt 전략은 호스트의 하위 우선 순위 VIP에서 호스트의 더 높은 우선 순위 VIP로 마스터를 이동하지 않습니다. preempt_delay 300을 사용하면 기본값인 Keepalived가 지정된 300초 동안 기다린 후 마스터를 호스트의 우선 순위 VIP로 이동합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

  • 선점 기능을 지정하려면 oc edit deploy ipfailover-keepalived를 입력하여 라우터 배포 구성을 편집합니다.

    $ oc edit deploy ipfailover-keepalived
    ...
        spec:
          containers:
          - env:
            - name: OPENSHIFT_HA_PREEMPTION  1
              value: preempt_delay 300
    ...
    1
    OPENSHIFT_HA_PREEMPTION 값을 설정합니다.
    • preempt_delay 300: Keepalived는 지정된 300초 동안 기다린 후 호스트의 우선 순위가 높은 VIP로 마스터를 이동합니다. 이는 기본값입니다.
    • nopreempt: 호스트의 하위 우선 순위 VIP에서 호스트의 더 높은 우선 순위 VIP로 마스터를 이동하지 않습니다.

8.6. VRRP ID 오프셋 정보

IP Failover 배포 구성에서 관리하는 각 IP 장애 조치 포드는 노드 또는 복제본당 1개의 Pod를 실행하고 Keepalived 데몬을 실행합니다. 더 많은 IP 페일오버 배포 구성이 구성되면 더 많은 Pod가 생성되고 더 많은 데몬이 일반 VRRP(Virtual Router Redundancy Protocol) 협상에 연결됩니다. 이 협상은 모든 Keepalived 데몬에서 수행하며 VIP(가상 IP) 서비스를 결정합니다.

내부적으로 Keepalived는 각 VIP에 고유한 vrrp-id를 할당합니다. 협상은 이 vrrp-id 세트를 사용하며, 결정이 내려지면 당첨된 vrrp-id에 해당하는 VIP가 수상 노드에 제공됩니다.

따라서 IP Failover 배포 구성에 정의된 모든 VIP에 대해 IP Failover Pod에서 해당 vrrp-id를 할당해야 합니다. 이 작업은 OPENSHIFT_HA_VRRP_ID_OFFSET에서 시작하고 vrrp-ids를 VIP 목록에 순차적으로 할당하여 수행됩니다. vrrp-ids는 1..255 범위의 값이 있을 수 있습니다.

IP Failover 배포 구성이 여러 개인 경우 배포 구성의 VIP 수를 늘리고 vrrp-id 범위가 겹치지 않도록 OPENSHIFT_HA_VRRP_ID_OFFSET을 지정해야 합니다.

8.7. 254개 이상의 주소에 대한 IP 페일오버 구성

IP Failover 관리는 254개의 가상 IP(VIP) 주소로 제한됩니다. 기본적으로 OpenShift Container Platform은 각 그룹에 하나의 IP 주소를 할당합니다. OPENSHIFT_HA_VIP_GROUPS 변수를 사용하여 이를 변경하여 여러 IP 주소가 각 그룹에 속하도록 하고 IP Failover를 구성할 때 각 VRRP(Virtual Router Redundancy Protocol) 인스턴스에 사용 가능한 VIP 그룹 수를 정의할 수 있습니다.

VIP 그룹화는 VRRP 페일오버 이벤트의 경우 VRRP당 VIP의 광범위한 할당을 생성하며 클러스터의 모든 호스트가 로컬로 서비스에 액세스할 때 유용합니다. 예를 들어 서비스가 ExternalIP를 사용하여 노출되는 경우.

참고

장애 조치(failover)에 대한 규칙으로 라우터와 같은 서비스를 하나의 특정 호스트로 제한하지 마십시오. 대신 IP 장애 조치의 경우 새 호스트에서 서비스를 다시 생성할 필요가 없도록 각 호스트에 서비스를 복제해야 합니다.

참고

OpenShift Container Platform 상태 점검을 사용하는 경우 IP 페일오버 및 그룹의 특성은 그룹의 모든 인스턴스가 확인되지 않음을 의미합니다. 따라서 서비스가 활성화되어 있는지 확인하려면 Kubernetes 상태 점검을 사용해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 각 그룹에 할당된 IP 주소 수를 변경하려면 OPENSHIFT_HA_VIP_GROUPS 변수의 값을 변경합니다. 예를 들면 다음과 같습니다.

    IP Failover 구성을 위한 Deployment YAML의 예

    ...
        spec:
            env:
            - name: OPENSHIFT_HA_VIP_GROUPS 1
              value: "3"
    ...

    1
    7개의 VIP가 있는 환경에서 OPENSHIFT_HA_VIP_GROUPS가 3개로 설정된 경우 3개의 그룹을 만들어 첫 번째 그룹에 VIP 3개를 할당하고 나머지 2개의 그룹에 VIP 2개를 할당합니다.
참고

OPENSHIFT_HA_VIP_GROUPS로 설정된 그룹 수가 실패로 설정된 IP 주소 수보다 작으면 그룹에는 두 개 이상의 IP 주소가 포함되어 있으며 모든 주소가 단일 단위로 이동합니다.

8.8. ingressIP의 고가용성

클라우드가 아닌 클러스터에서 서비스에 대한 IP 페일오버 및 ingressIP를 결합할 수 있습니다. 그 결과 ingressIP를 사용하여 서비스를 생성하는 사용자를 위한 고가용성 서비스가 생성됩니다.

방법은 ingressIPNetworkCIDR 범위를 지정한 다음 ipfailover 구성을 생성하는 데 동일한 범위를 사용하는 것입니다.

IP Failover는 전체 클러스터에 대해 최대 255 VIP를 지원할 수 있으므로 ingressIPNetworkCIDR은 /24 이상이어야 합니다.

9장. 베어 메탈 클러스터에서 SCTP(Stream Control Transmission Protocol) 사용

클러스터 관리자는 클러스터에서 SCTP(Stream Control Transmission Protocol)를 사용할 수 있습니다.

9.1. OpenShift Container Platform에서의 SCTP(스트림 제어 전송 프로토콜)

클러스터 관리자는 클러스터의 호스트에서 SCTP를 활성화 할 수 있습니다. RHCOS(Red Hat Enterprise Linux CoreOS)에서 SCTP 모듈은 기본적으로 비활성화되어 있습니다.

SCTP는 IP 네트워크에서 실행되는 안정적인 메시지 기반 프로토콜입니다.

활성화하면 Pod, 서비스, 네트워크 정책에서 SCTP를 프로토콜로 사용할 수 있습니다. type 매개변수를 ClusterIP 또는 NodePort 값으로 설정하여 Service를 정의해야 합니다.

9.1.1. SCTP 프로토콜을 사용하는 구성의 예

protocol 매개변수를 포드 또는 서비스 오브젝트의 SCTP 값으로 설정하여 SCTP를 사용하도록 포드 또는 서비스를 구성할 수 있습니다.

다음 예에서는 pod가 SCTP를 사용하도록 구성되어 있습니다.

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

다음 예에서는 서비스가 SCTP를 사용하도록 구성되어 있습니다.

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

다음 예에서 NetworkPolicy 오브젝트는 특정 레이블이 있는 모든 Pod의 포트 80에서 SCTP 네트워크 트래픽에 적용되도록 구성되어 있습니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

9.2. SCTP(스트림 제어 전송 프로토콜) 활성화

클러스터 관리자는 클러스터의 작업자 노드에 블랙리스트 SCTP 커널 모듈을 로드하고 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 YAML 정의가 포함된 load-sctp-module.yaml 파일을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: load-sctp-module
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/modprobe.d/sctp-blacklist.conf
              mode: 0644
              overwrite: true
              contents:
                source: data:,
            - path: /etc/modules-load.d/sctp-load.conf
              mode: 0644
              overwrite: true
              contents:
                source: data:,sctp
  2. MachineConfig 오브젝트를 생성하려면 다음 명령을 입력합니다.

    $ oc create -f load-sctp-module.yaml
  3. 선택 사항: MachineConfig Operator가 구성 변경 사항을 적용하는 동안 노드의 상태를 보려면 다음 명령을 입력합니다. 노드 상태가 Ready로 전환되면 구성 업데이트가 적용됩니다.

    $ oc get nodes

9.3. SCTP(Stream Control Transmission Protocol)의 활성화 여부 확인

SCTP 트래픽을 수신하는 애플리케이션으로 pod를 만들고 서비스와 연결한 다음, 노출된 서비스에 연결하여 SCTP가 클러스터에서 작동하는지 확인할 수 있습니다.

사전 요구 사항

  • 클러스터에서 인터넷에 액세스하여 nc 패키지를 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. SCTP 리스너를 시작하는 포드를 생성합니다.

    1. 다음 YAML로 pod를 정의하는 sctp-server.yaml 파일을 생성합니다.

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpserver
        labels:
          app: sctpserver
      spec:
        containers:
          - name: sctpserver
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
            ports:
              - containerPort: 30102
                name: sctpserver
                protocol: SCTP
    2. 다음 명령을 입력하여 pod를 생성합니다.

      $ oc create -f sctp-server.yaml
  2. SCTP 리스너 pod에 대한 서비스를 생성합니다.

    1. 다음 YAML을 사용하여 서비스를 정의하는 sctp-service.yaml 파일을 생성합니다.

      apiVersion: v1
      kind: Service
      metadata:
        name: sctpservice
        labels:
          app: sctpserver
      spec:
        type: NodePort
        selector:
          app: sctpserver
        ports:
          - name: sctpserver
            protocol: SCTP
            port: 30102
            targetPort: 30102
    2. 서비스를 생성하려면 다음 명령을 입력합니다.

      $ oc create -f sctp-service.yaml
  3. SCTP 클라이언트에 대한 pod를 생성합니다.

    1. 다음 YAML을 사용하여 sctp-client.yaml 파일을 만듭니다.

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpclient
        labels:
          app: sctpclient
      spec:
        containers:
          - name: sctpclient
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
    2. Pod 오브젝트를 생성하려면 다음 명령을 입력합니다.

      $ oc apply -f sctp-client.yaml
  4. 서버에서 SCTP 리스너를 실행합니다.

    1. 서버 Pod에 연결하려면 다음 명령을 입력합니다.

      $ oc rsh sctpserver
    2. SCTP 리스너를 시작하려면 다음 명령을 입력합니다.

      $ nc -l 30102 --sctp
  5. 서버의 SCTP 리스너에 연결합니다.

    1. 터미널 프로그램에서 새 터미널 창 또는 탭을 엽니다.
    2. sctpservice 서비스의 IP 주소를 얻습니다. 다음 명령을 실행합니다.

      $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
    3. 클라이언트 Pod에 연결하려면 다음 명령을 입력합니다.

      $ oc rsh sctpclient
    4. SCTP 클라이언트를 시작하려면 다음 명령을 입력합니다. <cluster_IP>sctpservice 서비스의 클러스터 IP 주소로 변경합니다.

      # nc <cluster_IP> 30102 --sctp

10장. PTP 하드웨어 구성

중요

Precision Time Protocol(PTP) 하드웨어는 기술 프리뷰 기능만 해당합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 고객은 출시 예정된 제품 기능을 Preview를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

10.1. PTP 하드웨어 정보

OpenShift Container Platform에는 노드에서 Precision Time Protocol(PTP) 하드웨어를 사용하는 기능이 포함되어 있습니다. PTP 지원 하드웨어가 있는 클러스터의 노드에서 linuxptp 서비스를 구성할 수 있습니다.

참고

PTP Operator는 베어 메탈 인프라에서만 프로비저닝된 클러스터에서 PTP 가능 장치와 함께 작동합니다.

PTP Operator를 배포하여 OpenShift Container Platform 콘솔을 사용하여 PTP를 설치할 수 있습니다. PTP Operator는 linuxptp 서비스를 생성하고 관리합니다. Operator는 다음 기능을 제공합니다.

  • 클러스터에서 PTP 지원 장치 검색.
  • linuxptp 서비스의 구성 관리.

10.2. PTP 네트워크 장치의 자동 검색

PTP Operator는 NodePtpDevice.ptp.openshift.io CRD(custom resource definition)를 OpenShift Container Platform에 추가합니다. PTP Operator는 각 노드에서 PTP 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환 가능한 PTP 장치를 제공하는 각 노드에 대해 NodePtpDevice CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

각 노드마다 하나의 CR이 작성되며 노드와 동일한 이름을 공유합니다. .status.devices 목록은 노드의 PTP 장치에 대한 정보를 제공합니다.

다음은 PTP Operator가 생성한 NodePtpDevice CR의 예입니다.

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2019-11-15T08:57:11Z"
  generation: 1
  name: dev-worker-0 1
  namespace: openshift-ptp 2
  resourceVersion: "487462"
  selfLink: /apis/ptp.openshift.io/v1/namespaces/openshift-ptp/nodeptpdevices/dev-worker-0
  uid: 08d133f7-aae2-403f-84ad-1fe624e5ab3f
spec: {}
status:
  devices: 3
  - name: eno1
  - name: eno2
  - name: ens787f0
  - name: ens787f1
  - name: ens801f0
  - name: ens801f1
  - name: ens802f0
  - name: ens802f1
  - name: ens803
1
name 매개변수의 값은 노드 이름과 같습니다.
2
CR은 PTP Operator에 의해 openshift-ptp 네임스페이스에 생성됩니다.
3
devices 컬렉션에는 노드에서 Operator가 검색한 모든 PTP 가능 장치 목록이 포함됩니다.

10.3. PTP Operator 설치

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 PTP Operator를 설치할 수 있습니다.

10.3.1. CLI: PTP Operator 설치

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

  • PTP를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. PTP Operator 네임스페이스를 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-ptp
      annotations:
        workload.openshift.io/allowed: management
      labels:
        name: openshift-ptp
        openshift.io/cluster-monitoring: "true"
    EOF
  2. 해당 Operator에 대한 Operator group을 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ptp-operators
      namespace: openshift-ptp
    spec:
      targetNamespaces:
      - openshift-ptp
    EOF
  3. PTP Operator에 등록합니다.

    1. 다음 명령을 실행하여 OpenShift Container Platform의 주 버전과 부 버전을 환경 변수로 설정합니다.이 변수는 다음 단계에서 channel 값으로 사용됩니다.

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)
    2. PTP Operator에 대한 서브스크립션을 만들려면 다음 명령을 입력합니다.

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "${OC_VERSION}"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
  4. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get csv -n openshift-ptp \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase

    출력 예

    Name                                        Phase
    ptp-operator.4.4.0-202006160135             Succeeded

10.3.2. 웹 콘솔: PTP Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 Operator를 설치할 수 있습니다.

참고

이전 섹션에서 언급한 것처럼 네임스페이스 및 Operator group을 생성해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔을 사용하여 PTP Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 PTP Operator를 선택한 다음 설치를 클릭합니다.
    3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-ptp를 선택합니다. 그런 다음, 설치를 클릭합니다.
  2. 선택 사항: PTP Operator가 설치되었는지 확인합니다.

    1. Operator설치된 Operator 페이지로 전환합니다.
    2. PTP Operatoropenshift-ptp 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 트러블슈팅을 수행하십시오.

      • Operator설치된 Operator 페이지로 이동하고 Operator 서브스크립션설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • WorkloadsPod 페이지로 이동하여 openshift-ptp 프로젝트에서 Pod 로그를 확인합니다.

10.4. Linuxptp 서비스 구성

PTP Operator는 PtpConfig.ptp.openshift.io CRD(custom resource definition)를 OpenShift Container Platform에 추가합니다. PtpConfig CR(사용자 정의 리소스)을 생성하여 Linuxptp 서비스(ptp4l, phc2sys)를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • PTP Operator를 설치해야 합니다.

프로세스

  1. 다음 PtpConfig CR을 생성한 다음 YAML을 <name>-ptp-config.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: <name> 1
      namespace: openshift-ptp 2
    spec:
      profile: 3
      - name: "profile1" 4
        interface: "ens787f1" 5
        ptp4lOpts: "-s -2" 6
        phc2sysOpts: "-a -r" 7
      recommend: 8
      - profile: "profile1" 9
        priority: 10 10
        match: 11
        - nodeLabel: "node-role.kubernetes.io/worker" 12
          nodeName: "dev-worker-0" 13
    1
    PtpConfig CR의 이름을 지정합니다.
    2
    PTP Operator가 설치된 네임스페이스를 지정합니다.
    3
    하나 이상의 profile 오브젝트의 배열을 지정합니다.
    4
    프로필 오브젝트를 고유하게 식별하는 데 사용되는 프로필 오브젝트의 이름을 지정합니다.
    5
    ptp4l 서비스에서 사용할 네트워크 인터페이스 이름을 지정합니다(예: ens787f1).
    6
    ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다(예: -s -2). 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf는 자동으로 추가되므로 포함하지 않아야 합니다.
    7
    phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다(예: -a -r).
    8
    profile이 노드에 적용되는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.
    9
    profile 섹션에 정의된 profile 오브젝트 이름을 지정합니다.
    10
    0에서 99 사이의 정수 값으로 priority를 지정합니다. 숫자가 클수록 우선순위가 낮으므로 우선순위 99는 우선순위 10보다 낮습니다. match 필드에 정의된 규칙에 따라 노드를 여러 프로필과 일치시킬 수 있는 경우 우선순위가 높은 프로필이 해당 노드에 적용됩니다.
    11
    nodeLabel 또는 nodeName으로 일치 규칙을 지정합니다.
    12
    노드 오브젝트에서 node.LabelskeynodeLabel을 지정합니다.
    13
    노드 오브젝트에서 node.Name으로 nodeName을 지정합니다.
  2. 다음 명령을 실행하여 CR을 생성합니다.

    $ oc create -f <filename> 1
    1
    <filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
  3. 선택 사항: PtpConfig 프로필이 nodeLabel 또는 nodeName과 일치하는 노드에 적용되는지 확인합니다.

    $ oc get pods -n openshift-ptp -o wide

    출력 예

    NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
    linuxptp-daemon-4xkbb           1/1     Running   0          43m   192.168.111.15   dev-worker-0   <none>           <none>
    linuxptp-daemon-tdspf           1/1     Running   0          43m   192.168.111.11   dev-master-0   <none>           <none>
    ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.128.0.116     dev-master-0   <none>           <none>
    
    $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp
    I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
    I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
    I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
    I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 1
    I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1    2
    I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -s -2       3
    I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r     4
    I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
    I1115 09:41:18.117934 4143292 daemon.go:186] Starting phc2sys...
    I1115 09:41:18.117985 4143292 daemon.go:187] phc2sys cmd: &{Path:/usr/sbin/phc2sys Args:[/usr/sbin/phc2sys -a -r] Env:[] Dir: Stdin:<nil> Stdout:<nil> Stderr:<nil> ExtraFiles:[] SysProcAttr:<nil> Process:<nil> ProcessState:<nil> ctx:<nil> lookPathErr:<nil> finished:false childFiles:[] closeAfterStart:[] closeAfterWait:[] goroutine:[] errch:<nil> waitDone:<nil>}
    I1115 09:41:19.118175 4143292 daemon.go:186] Starting ptp4l...
    I1115 09:41:19.118209 4143292 daemon.go:187] ptp4l cmd: &{Path:/usr/sbin/ptp4l Args:[/usr/sbin/ptp4l -m -f /etc/ptp4l.conf -i ens787f1 -s -2] Env:[] Dir: Stdin:<nil> Stdout:<nil> Stderr:<nil> ExtraFiles:[] SysProcAttr:<nil> Process:<nil> ProcessState:<nil> ctx:<nil> lookPathErr:<nil> finished:false childFiles:[] closeAfterStart:[] closeAfterWait:[] goroutine:[] errch:<nil> waitDone:<nil>}
    ptp4l[102189.864]: selected /dev/ptp5 as PTP clock
    ptp4l[102189.886]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[102189.886]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE

    1
    Profile Namedev-worker-0 노드에 적용되는 이름입니다.
    2
    Interfaceprofile1 인터페이스 필드에 지정된 PTP 장치입니다. ptp4l 서비스는 이 인터페이스에서 실행됩니다.
    3
    Ptp4lOptsprofile1 Ptp4lOpts 필드에 지정된 ptp4l sysconfig 옵션입니다.
    4
    Phc2sysOptsprofile1 Phc2sysOpts 필드에 지정된 phc2sys sysconfig 옵션입니다.

11장. 네트워크 정책

11.1. 네트워크 정책 정의

클러스터 관리자는 클러스터의 pod로 트래픽을 제한하는 네트워크 정책을 정의할 수 있습니다.

11.1.1. 네트워크 정책 정의

Kubernetes 네트워크 정책을 지원하는 CNI(Kubernetes Container Network Interface) 플러그인을 사용하는 클러스터에서 네트워크 격리는 NetworkPolicy 개체에 의해서만 제어됩니다. OpenShift Container Platform 4.8에서 OpenShift SDN은 기본 네트워크 격리 모드에서 네트워크 정책의 사용을 지원합니다.

참고

OpenShift SDN 클러스터 네트워크 공급자를 사용할 경우 네트워크 정책과 관련하여 다음과 같은 제한 사항이 적용됩니다.

  • 송신 필드에서 지정한 egress 네트워크 정책은 지원되지 않습니다.
  • IPBlock은 네트워크 정책에서 지원되지만 except 절에는 지원되지 않습니다. except 절이 포함된 IPBlock 섹션이 포함된 정책을 생성하면 SDN Pod 로그가 경고를 생성하고 해당 정책의 전체 IPBlock 섹션이 무시됩니다.
주의

네트워크 정책은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 네트워크 정책 규칙의 영향을 받지 않습니다.

기본적으로 네트워크 정책 모드에서는 다른 Pod 및 네트워크 끝점에서 프로젝트의 모든 Pod에 액세스할 수 있습니다. 프로젝트에서 하나 이상의 Pod를 분리하기 위해 해당 프로젝트에서 NetworkPolicy 오브젝트를 생성하여 수신되는 연결을 표시할 수 있습니다. 프로젝트 관리자는 자신의 프로젝트 내에서 NetworkPolicy 오브젝트를 만들고 삭제할 수 있습니다.

하나 이상의 NetworkPolicy 오브젝트에서 선택기와 Pod가 일치하면 Pod는 해당 NetworkPolicy 오브젝트 중 하나 이상에서 허용되는 연결만 허용합니다. NetworkPolicy 오브젝트가 선택하지 않은 Pod에 완전히 액세스할 수 있습니다.

다음 예제 NetworkPolicy 오브젝트는 다양한 시나리오 지원을 보여줍니다.

  • 모든 트래픽 거부:

    기본적으로 프로젝트를 거부하려면 모든 Pod와 일치하지만 트래픽을 허용하지 않는 NetworkPolicy 오브젝트를 추가합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector:
      ingress: []
  • OpenShift Container Platform Ingress 컨트롤러의 연결만 허용합니다.

    프로젝트에서 OpenShift Container Platform Ingress 컨트롤러의 연결만 허용하도록 하려면 다음 NetworkPolicy 개체를 추가합니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress
  • 프로젝트 내 Pod 연결만 허용:

    Pod가 동일한 프로젝트 내 다른 Pod의 연결은 수락하지만 다른 프로젝트에 속하는 Pod의 기타 모든 연결을 거부하도록 하려면 다음 NetworkPolicy 오브젝트를 추가합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}
  • Pod 레이블을 기반으로 하는 HTTP 및 HTTPS 트래픽만 허용:

    특정 레이블(다음 예에서 role=frontend)을 사용하여 Pod에 대한 HTTP 및 HTTPS 액세스만 활성화하려면 다음과 유사한 NetworkPolicy 오브젝트를 추가합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-http-and-https
    spec:
      podSelector:
        matchLabels:
          role: frontend
      ingress:
      - ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
  • 네임스페이스와 Pod 선택기를 모두 사용하여 연결 수락:

    네임스페이스와 Pod 선택기를 결합하여 네트워크 트래픽을 일치시키려면 다음과 유사한 NetworkPolicy 오브젝트를 사용하면 됩니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-pod-and-namespace-both
    spec:
      podSelector:
        matchLabels:
          name: test-pods
      ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                project: project_name
            podSelector:
              matchLabels:
                name: test-pods

NetworkPolicy 오브젝트는 추가 기능이므로 여러 NetworkPolicy 오브젝트를 결합하여 복잡한 네트워크 요구 사항을 충족할 수 있습니다.

예를 들어, 이전 샘플에서 정의된 NetworkPolicy 오브젝트의 경우 동일한 프로젝트 내에서 allow-same-namespace 정책과 allow-http-and-https 정책을 모두 정의할 수 있습니다. 따라서 레이블이 role=frontend로 지정된 Pod는 각 정책에서 허용하는 모든 연결을 허용할 수 있습니다. 즉 동일한 네임스페이스에 있는 Pod의 모든 포트 연결과 모든 네임스페이스에 있는 Pod에서 포트 80443에 대한 연결이 허용됩니다.

11.1.2. 네트워크 정책 최적화

네트워크 정책을 사용하여 네임스페이스 내의 라벨에 따라 서로 다른 포드를 분리합니다.

참고

네트워크 정책 규칙을 효율적으로 사용하기 위한 지침은 OpenShift SDN 클러스터 네트워크 공급자에게만 적용됩니다.

NetworkPolicy 오브젝트를 단일 네임스페이스에서 개별 포드의 많은 수에 적용하는 것은 비효율적입니다. 포드 라벨은 IP 주소 수준에 존재하지 않으므로 네트워크 정책은 podSelector로 선택한 모든 포드 간에 가능한 모든 링크에 대한 별도의 OVS(Open vSwitch) 흐름 규칙을 생성합니다.

예를 들어 NetworkPolicy 오브젝트 내의 spec podSelector 및 ingress podSelector가 각각 200개의 포드와 일치하는 경우 40,000(200*200)개의 OVS 흐름 규칙이 생성됩니다. 이 경우 노드가 느려질 수 있습니다.

네트워크 정책을 설계할 때 다음 지침을 참조하십시오.

  • 분리해야 하는 포드 그룹을 포함하도록 네임스페이스를 사용하여 OVS 흐름 규칙의 수를 줄입니다.

    namespaceSelector 또는 빈 podSelector를 사용하여 전체 네임스페이스를 선택하는 NetworkPolicy 오브젝트는 네임스페이스의 VXLAN 가상 네트워크 ID(VNID)와 일치하는 단일 OVS 흐름 규칙만 생성합니다.

  • 원래 네임스페이스에서 분리할 필요가 없는 포드를 유지하고, 분리해야 하는 포드를 하나 이상의 네임스페이스로 이동합니다.
  • 분리된 포드에서 허용하려는 특정 트래픽을 허용하도록 추가 대상의 네임스페이스 간 네트워크 정책을 생성합니다.

11.1.3. 다음 단계

11.1.4. 추가 리소스

11.2. 네트워크 정책 이벤트 로깅

클러스터 관리자는 클러스터에 대한 네트워크 정책 감사 로깅을 구성하고 하나 이상의 네임스페이스에 대해 로깅을 활성화할 수 있습니다.

11.2.1. 네트워크 정책 감사 로깅

OVN-Kubernetes 클러스터 네트워크 공급자는 OVN(Open Virtual Network) ACL을 사용하여 네트워크 정책을 관리합니다. 감사 로깅은 ACL 이벤트를 허용 및 거부합니다.

syslog 서버 또는 UNIX 도메인 소켓과 같은 네트워크 정책 감사 로그의 대상을 구성할 수 있습니다. 추가 구성에 관계없이 감사 로그는 항상 클러스터의 각 OVN-Kubernetes Pod의 /var/log/ovn/acl-audit-log.log에 저장됩니다.

다음 예와 같이 k8s.ovn.org/acl-logging 키로 네임스페이스에 주석을 달면 네트워크 정책 감사 로깅이 네임스페이스별로 활성화됩니다.

네임스페이스 주석 예

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

로깅 형식은 RFC5424에 정의된 syslog와 호환됩니다. syslog 기능은 구성 가능하며 기본값은 local0입니다. 예제 로그 항목은 다음과 유사합니다.

ACL의 예 로그 항목 거부

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

다음 표에서는 네임스페이스 주석 값을 설명합니다.

표 11.1. 네트워크 정책 감사 로깅 네임스페이스 주석

주석

k8s.ovn.org/acl-logging

네임스페이스에 대해 네트워크 정책 감사 로깅을 활성화하려면 허용,거부 또는 둘 중 하나를 지정해야 합니다.

거부
선택 사항: 경고,경고,알림,정보 또는 디버그를 지정합니다.
허용
선택 사항: 경고,경고,알림,정보 또는 디버그를 지정합니다.

11.2.2. 네트워크 정책 감사 구성

감사 로깅 구성은 OVN-Kubernetes 클러스터 네트워크 공급자 구성의 일부로 지정됩니다. 다음 YAML은 네트워크 정책 감사 로깅 기능의 기본값을 보여줍니다.

감사 로깅 구성

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

다음 표에서는 네트워크 정책 감사 로깅의 구성 필드를 설명합니다.

표 11.2. policyAuditConfig object

필드유형설명

rateLimit

integer

노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 20 개의 메시지입니다.

maxFileSize

integer

감사 로그의 최대 크기(바이트)입니다. 기본값은 50000000 또는 50MB입니다.

대상

string

다음 추가 감사 로그 대상 중 하나입니다.

libc
호스트에서 journald 프로세스의 libc syslog() 함수입니다.
udp:<host>:<port>
syslog 서버입니다. <host>:<port>를 syslog 서버의 호스트 및 포트로 바꿉니다.
unix:<file>
<file>로 지정된 Unix Domain Socket 파일입니다.
null
감사 로그를 추가 대상으로 보내지 마십시오.

syslogFacility

string

RFC5424에 정의된 kern과 같은 syslog 기능입니다. 기본값은 local0입니다.

11.2.3. 클러스터에 대한 네트워크 정책 감사 구성

클러스터 관리자는 클러스터의 네트워크 정책 감사 로깅을 사용자 지정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 네트워크 정책 감사 로깅 구성을 사용자 정의하려면 다음 명령을 입력합니다.

    $ oc edit network.operator.openshift.io/cluster
    작은 정보

    또는 다음 YAML을 사용자 지정하고 적용하여 감사 로깅을 구성할 수 있습니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          policyAuditConfig:
            destination: "null"
            maxFileSize: 50
            rateLimit: 20
            syslogFacility: local0

검증

  1. 네트워크 정책을 사용하여 네임스페이스를 생성하려면 다음 단계를 완료합니다.

    1. 확인을 위한 네임스페이스를 생성합니다.

      $ cat <<EOF| oc create -f -
      kind: Namespace
      apiVersion: v1
      metadata:
        name: verify-audit-logging
        annotations:
          k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
      EOF

      출력 예

      namespace/verify-audit-logging created

    2. 감사 로깅을 활성화합니다.

      $ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'
      namespace/verify-audit-logging annotated
    3. 네임스페이스에 대한 네트워크 정책을 생성합니다.

      $ cat <<EOF| oc create -n verify-audit-logging -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: deny-all
      spec:
        podSelector:
          matchLabels:
        policyTypes:
        - Ingress
        - Egress
      ---
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector: {}
        policyTypes:
         - Ingress
         - Egress
        ingress:
          - from:
              - podSelector: {}
        egress:
          - to:
             - namespaceSelector:
                matchLabels:
                  namespace: verify-audit-logging
      EOF

      출력 예

      networkpolicy.networking.k8s.io/deny-all created
      networkpolicy.networking.k8s.io/allow-from-same-namespace created

  2. default 네임스페이스에서 소스 트래픽에 사용할 Pod를 생성합니다.

    $ cat <<EOF| oc create -n default -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: client
    spec:
      containers:
        - name: client
          image: registry.access.redhat.com/rhel7/rhel-tools
          command: ["/bin/sh", "-c"]
          args:
            ["sleep inf"]
    EOF
  3. verify-audit-logging 네임스페이스에 두 개의 Pod를 생성합니다.

    $ for name in client server; do
    cat <<EOF| oc create -n verify-audit-logging -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: ${name}
    spec:
      containers:
        - name: ${name}
          image: registry.access.redhat.com/rhel7/rhel-tools
          command: ["/bin/sh", "-c"]
          args:
            ["sleep inf"]
    EOF
    done

    출력 예

    pod/client created
    pod/server created

  4. 트래픽을 생성하고 네트워크 정책 감사 로그 항목을 생성하려면 다음 단계를 완료합니다.

    1. verify-audit-logging 네임스페이스에서 server라는 Pod의 IP 주소를 가져옵니다.

      $ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')
    2. 기본 네임스페이스에 있는 client라는 Pod에서 이전 명령에서 IP 주소를 ping하고 모든 패킷이 삭제되었는지 확인합니다.

      $ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

      출력 예

      PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.
      
      --- 10.128.2.55 ping statistics ---
      2 packets transmitted, 0 received, 100% packet loss, time 2041ms

    3. verify-audit-logging 네임스페이스의 client라는 Pod에서 POD_IP 쉘 환경 변수에 저장된 IP 주소를 ping하고 모든 패킷이 허용되는지 확인합니다.

      $ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

      출력 예

      PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
      64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
      64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms
      
      --- 10.128.0.86 ping statistics ---
      2 packets transmitted, 2 received, 0% packet loss, time 1001ms
      rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

  5. 네트워크 정책 감사 로그의 최신 항목을 표시합니다.

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
        oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
      done

    출력 예

    Defaulting container name to ovn-controller.
    Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
    2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

11.2.4. 네임스페이스에 대한 네트워크 정책 감사 로깅 활성화

클러스터 관리자는 네임스페이스에 대한 네트워크 정책 감사 로깅을 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 네임스페이스에 네트워크 정책 감사 로깅을 활성화하려면 다음 명령을 입력합니다.

    $ oc annotate namespace <namespace> \
      k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

    다음과 같습니다.

    <namespace>
    네임스페이스의 이름을 지정합니다.
    작은 정보

    또는 다음 YAML을 적용하여 감사 로깅을 활성화할 수 있습니다.

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/acl-logging: |-
          {
            "deny": "alert",
            "allow": "notice"
          }

    출력 예

    namespace/verify-audit-logging annotated

검증

  • 네트워크 정책 감사 로그의 최신 항목을 표시합니다.

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
        oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
      done

    출력 예

    2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

11.2.5. 네임스페이스의 네트워크 정책 감사 로깅 비활성화

클러스터 관리자는 네임스페이스에 대한 네트워크 정책 감사 로깅을 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 네임스페이스에 대한 네트워크 정책 감사 로깅을 비활성화하려면 다음 명령을 입력합니다.

    $ annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging={}

    다음과 같습니다.

    <namespace>
    네임스페이스의 이름을 지정합니다.
    작은 정보

    또는 다음 YAML을 적용하여 감사 로깅을 비활성화할 수 있습니다.

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/acl-logging: null

    출력 예

    namespace/verify-audit-logging annotated

11.2.6. 추가 리소스

11.3. 네트워크 정책 생성

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 만들 수 있습니다.

11.3.1. 네트워크 정책 생성

클러스터의 네임스페이스에서 허용된 수신 또는 송신 네트워크 트래픽을 설명하는 세분화된 규칙을 정의하기 위해 네트워크 정책을 생성할 수 있습니다.

참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터에서 mode: NetworkPolicy로 설정된 OVF-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 개체를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.
  • 클러스터는 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자(예: mode: NetworkPolicy로 설정된 OpenShift SDN 네트워크 공급자)를 사용하고 있습니다. 이 모드는 OpenShift SDN의 기본값입니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

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

      $ touch <policy_name>.yaml

      다음과 같습니다.

      <policy_name>
      네트워크 정책 파일 이름을 지정합니다.
    2. 방금 만든 파일에서 다음 예와 같이 네트워크 정책을 정의합니다.

      모든 네임스페이스의 모든 Pod에서 수신 거부

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []

    .동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}
  2. 다음 명령을 실행하여 네트워크 정책 오브젝트를 생성합니다.

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

    다음과 같습니다.

    <policy_name>
    네트워크 정책 파일 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

    출력 예

    networkpolicy.networking.k8s.io/default-deny created

11.3.2. NetworkPolicy 오브젝트 예

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 모든 프로젝트의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

11.4. 네트워크 정책 보기

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 볼 수 있습니다.

11.4.1. 네트워크 정책 보기

네임스페이스에서 네트워크 정책을 검사할 수 있습니다.

참고

cluster-admin 역할을 사용하여 사용자로 로그인하면 클러스터에서 네트워크 정책을 볼 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 네임스페이스의 네트워크 정책을 나열합니다.

    • 네임스페이스에 정의된 네트워크 정책 오브젝트를 보려면 다음 명령을 입력합니다.

      $ oc get networkpolicy
    • 선택 사항: 특정 네트워크 정책을 검사하려면 다음 명령을 입력합니다.

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

      다음과 같습니다.

      <policy_name>
      검사할 네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

      예를 들면 다음과 같습니다.

      $ oc describe networkpolicy allow-same-namespace

      oc describe 명령의 출력

      Name:         allow-same-namespace
      Namespace:    ns1
      Created on:   2021-05-24 22:28:56 -0400 EDT
      Labels:       <none>
      Annotations:  <none>
      Spec:
        PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
        Allowing ingress traffic:
          To Port: <any> (traffic allowed to all ports)
          From:
            PodSelector: <none>
        Not affecting egress traffic
        Policy Types: Ingress

11.4.2. NetworkPolicy 오브젝트 예

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 모든 프로젝트의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

11.5. 네트워크 정책 편집

admin 역할이 있는 사용자는 네임스페이스에 대한 기존 네트워크 정책을 편집할 수 있습니다.

11.5.1. 네트워크 정책 편집

네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

참고

cluster-admin 역할을 사용하여 사용자로 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

사전 요구 사항

  • 클러스터에서 mode: NetworkPolicy로 설정된 OVF-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 개체를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

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

    $ oc get networkpolicy

    다음과 같습니다.

    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  2. 네트워크 정책 오브젝트를 편집합니다.

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

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

      다음과 같습니다.

      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
      <policy_file>
      네트워크 정책이 포함된 파일의 이름을 지정합니다.
    • 네트워크 정책 오브젝트를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.

      $ oc edit networkpolicy <policy_name> -n <namespace>

      다음과 같습니다.

      <policy_name>
      네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  3. 네트워크 정책 오브젝트가 업데이트되었는지 확인합니다.

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

    다음과 같습니다.

    <policy_name>
    네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

11.5.2. NetworkPolicy 오브젝트 예

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 모든 프로젝트의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

11.5.3. 추가 리소스

11.6. 네트워크 정책 삭제

admin 역할이 있는 사용자는 네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

11.6.1. 네트워크 정책 삭제

네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

참고

cluster-admin 역할을 사용하여 사용자로 로그인하면 클러스터에서 네트워크 정책을 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터에서 mode: NetworkPolicy로 설정된 OVF-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 개체를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 네트워크 정책 오브젝트를 삭제하려면 다음 명령을 입력합니다.

    $ oc delete networkpolicy <policy_name> -n <namespace>

    다음과 같습니다.

    <policy_name>
    네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

    출력 예

    networkpolicy.networking.k8s.io/default-deny deleted

11.7. 프로젝트의 기본 네트워크 정책 정의

클러스터 관리자는 새 프로젝트를 만들 때 네트워크 정책을 자동으로 포함하도록 새 프로젝트 템플릿을 수정할 수 있습니다. 새 프로젝트에 대한 사용자 정의 템플릿이 아직 없는 경우에는 우선 생성해야 합니다.

11.7.1. 새 프로젝트의 템플릿 수정

클러스터 관리자는 사용자 정의 요구 사항을 사용하여 새 프로젝트를 생성하도록 기본 프로젝트 템플릿을 수정할 수 있습니다.

사용자 정의 프로젝트 템플릿을 만들려면:

프로세스

  1. cluster-admin 권한이 있는 사용자로 로그인합니다.
  2. 기본 프로젝트 템플릿을 생성합니다.

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.
  4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.

    $ oc create -f template.yaml -n openshift-config
  5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

    • 웹 콘솔에 액세스:

      1. 관리클러스터 설정으로 이동합니다.
      2. 전역 구성을 클릭하여 모든 구성 리소스를 확인합니다.
      3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.
    • CLI 사용:

      1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster
  6. projectRequestTemplatename 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

    사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      ...
    spec:
      projectRequestTemplate:
        name: <template_name>

  7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

11.7.2. 새 프로젝트 템플릿에 네트워크 정책 추가

클러스터 관리자는 네트워크 정책을 새 프로젝트의 기본 템플릿에 추가할 수 있습니다. OpenShift Container Platform은 프로젝트의 템플릿에 지정된 모든 NetworkPolicy 개체를 자동으로 생성합니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy 오브젝트를 지원하는 기본 CNI 네트워크 공급자(예: mode: NetworkPolicy로 설정된 OpenShift SDN 네트워크 공급자)를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인해야 합니다.
  • 새 프로젝트에 대한 사용자 정의 기본 프로젝트 템플릿을 생성해야 합니다.

프로세스

  1. 다음 명령을 실행하여 새 프로젝트의 기본 템플릿을 편집합니다.

    $ oc edit template <project_template> -n openshift-config

    <project_template>을 클러스터에 대해 구성한 기본 템플릿의 이름으로 변경합니다. 기본 템플릿 이름은 project-request입니다.

  2. 템플릿에서 각 NetworkPolicy 오브젝트를 objects 매개변수의 요소로 추가합니다. objects 매개변수는 하나 이상의 오브젝트 컬렉션을 허용합니다.

    다음 예제에서 objects 매개변수 컬렉션에는 여러 NetworkPolicy 오브젝트가 포함됩니다.

    중요

    OVN-Kubernetes 네트워크 공급자 플러그인의 경우 Ingress 컨트롤러가 HostNetwork 끝점 게시 전략을 사용하도록 구성된 경우 Ingress 트래픽이 허용되고 기타 모든 트래픽이 거부되도록 네트워크 정책을 적용하는 방법은 지원되지 않습니다.

    objects:
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    ...
  3. 선택 사항: 다음 명령을 실행하여 새 프로젝트를 생성하고 네트워크 정책 오브젝트가 생성되었는지 확인합니다.

    1. 새 프로젝트를 생성합니다.

      $ oc new-project <project> 1
      1
      <project> 를 생성중인 프로젝트의 이름으로 변경합니다.
    2. 새 프로젝트 템플릿의 네트워크 정책 오브젝트가 새 프로젝트에 있는지 확인합니다.

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

11.8. 네트워크 정책으로 다중 테넌트 격리 구성

클러스터 관리자는 다중 테넌트 네트워크 격리를 제공하도록 네트워크 정책을 구성할 수 있습니다.

참고

OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 이 섹션에 설명된 대로 네트워크 정책을 구성하는 경우 다중 테넌트 모드와 유사하지만 네투어크 정책 모드가 설정된 네트워크 격리를 제공합니다.

11.8.1. 네트워크 정책을 사용하여 다중 테넌트 격리 구성

다른 프로젝트 네임스페이스의 Pod 및 서비스에서 격리하도록 프로젝트를 구성할 수 있습니다.

사전 요구 사항

  • 클러스터에서 mode: NetworkPolicy로 설정된 OVF-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 개체를 지원하는 클러스터 네트워크 공급자를 사용하고 있습니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 다음 NetworkPolicy 오브젝트를 생성합니다.

    1. 이름이 allow-from-openshift-ingress인 정책입니다.

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
    2. 이름이 allow-from-openshift-monitoring인 정책:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
    3. 이름이 allow-same-namespace인 정책:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF
  2. 선택 사항: 현재 프로젝트에 네트워크 정책이 있는지 확인하려면 다음 명령을 입력합니다.

    $ oc describe networkpolicy

    출력 예

    Name:         allow-from-openshift-ingress
    Namespace:    example1
    Created on:   2020-06-09 00:28:17 -0400 EDT
    Labels:       <none>
    Annotations:  <none>
    Spec:
      PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
      Allowing ingress traffic:
        To Port: <any> (traffic allowed to all ports)
        From:
          NamespaceSelector: network.openshift.io/policy-group: ingress
      Not affecting egress traffic
      Policy Types: Ingress
    
    
    Name:         allow-from-openshift-monitoring
    Namespace:    example1
    Created on:   2020-06-09 00:29:57 -0400 EDT
    Labels:       <none>
    Annotations:  <none>
    Spec:
      PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
      Allowing ingress traffic:
        To Port: <any> (traffic allowed to all ports)
        From:
          NamespaceSelector: network.openshift.io/policy-group: monitoring
      Not affecting egress traffic
      Policy Types: Ingress

11.8.2. 다음 단계

11.8.3. 추가 리소스

12장. 다중 네트워크

12.1. 다중 네트워크 이해하기

Kubernetes에서 컨테이너 네트워킹은 컨테이너 네트워크 인터페이스(CNI)를 구현하는 네트워킹 플러그인에 위임됩니다.

OpenShift Container Platform은 Multus CNI 플러그인을 사용하여 CNI 플러그인 체인을 허용합니다. 클러스터 설치 중에 기본 pod 네트워크를 구성합니다. 기본 네트워크는 클러스터의 모든 일반 네트워크 트래픽을 처리합니다. 사용 가능한 CNI 플러그인을 기반으로 추가 네트워크를 정의하고 이러한 네트워크 중 하나 이상을 pod에 연결할 수 있습니다. 필요에 따라 클러스터에 2개 이상의 추가 네트워크를 정의 할 수 있습니다. 따라서 스위칭 또는 라우팅과 같은 네트워크 기능을 제공하는 pod를 구성할 때 유연성이 제공됩니다.

12.1.1. 추가 네트워크 사용 시나리오

데이터 플레인 및 컨트롤 플레인 분리를 포함하여 네트워크 격리가 필요한 상황에서 추가 네트워크를 사용할 수 있습니다. 네트워크 트래픽 격리는 다음과 같은 성능 및 보안상의 이유로 유용합니다.

성능
각 플레인의 트래픽 수량을 관리하기 위해 두 개의 다른 플레인으로 트래픽을 보낼 수 있습니다.
보안
보안 고려 사항을 위해 특별히 관리되는 네트워크 플레인으로 중요한 트래픽을 보낼 수 있으며 테넌트 또는 고객 간에 공유되지 않아야 하는 개인 데이터를 분리할 수 있습니다.

클러스터의 모든 pod는 여전히 클러스터 전체의 기본 네트워크를 사용하여 클러스터 전체의 연결을 유지합니다. 모든 pod에는 클러스터 전체 pod 네트워크에 연결된 eth0 인터페이스가 있습니다. oc exec -it <pod_name> -- ip a 명령을 사용하여 pod의 인터페이스를 확인할 수 있습니다. Multus CNI를 사용하는 네트워크 인터페이스를 추가하는 경우 이름은 net1, net2, … , netN입니다.

Pod에 추가 네트워크 인터페이스를 연결하려면 인터페이스 연결 방법을 정의하는 구성을 생성해야 합니다. NetworkAttachmentDefinition CR(사용자 정의 리소스)을 사용하여 각 인터페이스를 지정합니다. 각 CR 내부의 CNI 구성은 해당 인터페이스의 생성 방법을 정의합니다.

12.1.2. OpenShift Container Platform의 그룹은 중첩되지 않습니다.

OpenShift Container Platform은 클러스터에서 추가 네트워크를 생성하기 위해 다음과 같은 CNI 플러그인을 제공합니다.

12.2. 가상 라우팅 및 전달 정보

12.2.1. 가상 라우팅 및 전달 정보

IP 규칙과 결합된 가상 라우팅 및 전달(VRF) 장치는 가상 라우팅 및 전달 도메인을 생성하는 기능을 제공합니다. VRF는 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 증대시킵니다. VRF는 예를 들어 각 테넌트마다 고유한 라우팅 테이블이 있고 다른 기본 게이트웨이가 필요한 멀티 테넌시 기능을 제공하는 데 사용됩니다.

프로세스는 소켓을 VRF 장치에 바인딩할 수 있습니다. 바인딩된 소켓을 통한 패킷은 VRF 장치와 연결된 라우팅 테이블을 사용합니다. VRF의 중요한 기능은 OSI 모델 레이어 3 트래픽 및 LLDP와 같은 L2 도구에만 영향을 미치지 않는다는 것입니다. 이를 통해 정책 기반 라우팅과 같은 우선순위가 높은 IP 규칙이 특정 트래픽을 지시하는 VRF 장치 규칙보다 우선합니다.

12.2.1.1. 통신 운영자의 포드에 대한 보조 네트워크 이점

통신사용 사례에서 각 CNF는 동일한 주소 공간을 공유하는 여러 다른 네트워크에 잠재적으로 연결할 수 있습니다. 이러한 보조 네트워크는 클러스터의 기본 네트워크 CIDR과 잠재적으로 충돌할 수 있습니다. CNI VRF 플러그인을 사용하여 네트워크 기능은 동일한 IP 주소를 사용하여 다른 고객의 인프라에 연결할 수 있으며 서로 다른 고객의 분리된 상태를 유지할 수 있습니다. IP 주소는 OpenShift Container Platform IP 공간과 겹치게 됩니다. 또한 CNI VRF 플러그인은 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 증대시킵니다.

12.3. 다중 네트워크 정책 구성

클러스터 관리자는 추가 네트워크에 대한 네트워크 정책을 구성할 수 있습니다.

참고

macvlan 추가 네트워크에 대해서만 다중 네트워크 정책을 지정할 수 있습니다. ipvlan과 같은 기타 유형의 추가 네트워크는 지원되지 않습니다.

12.3.1. 다중 네트워크 정책과 네트워크 정책의 차이점

MultiNetworkPolicy API는 NetworkPolicy API를 구현하지만 다음과 같은 몇 가지 중요한 차이점이 있습니다.

  • MultiNetworkPolicy API를 사용해야 합니다.

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
  • CLI를 사용하여 다중 네트워크 정책과 상호 작용할 때 multi-networkpolicy 리소스 이름을 사용해야 합니다. 예를 들어 oc get multi-networkpolicy <name> 명령을 사용하여 다중 네트워크 정책 오브젝트를 볼 수 있습니다. 여기서 <name>은 다중 네트워크 정책의 이름입니다.
  • macvlan 추가 네트워크를 정의하는 네트워크 연결 정의의 이름으로 주석을 지정해야 합니다.

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>

    다음과 같습니다.

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

12.3.2. 클러스터에 대한 다중 네트워크 정책 활성화

클러스터 관리자는 클러스터에서 다중 네트워크 정책 지원을 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 다음 YAML을 사용하여 multinetwork-enable-patch.yaml 파일을 생성합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      useMultiNetworkPolicy: true
  2. 다중 네트워크 정책을 활성화하도록 클러스터를 구성합니다.

    $ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

    출력 예

    network.operator.openshift.io/cluster patched

12.3.3. 다중 네트워크 정책 작업

클러스터 관리자는 다중 네트워크 정책을 생성, 편집, 보기 및 삭제할 수 있습니다.

12.3.3.1. 사전 요구 사항

  • 클러스터에 대한 다중 네트워크 정책 지원을 활성화했습니다.

12.3.3.2. 다중 네트워크 정책 생성

클러스터의 네임스페이스에 허용된 수신 또는 송신 네트워크 트래픽을 설명하는 세분화된 규칙을 정의하려면 다중 네트워크 정책을 만들 수 있습니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy가 설정된 OVN-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인되어 있습니다.
  • 다중 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

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

      $ touch <policy_name>.yaml

      다음과 같습니다.

      <policy_name>
      다중 네트워크 정책 파일 이름을 지정합니다.
    2. 다음 예제와 같이 방금 생성한 파일에 다중 네트워크 정책을 정의합니다.

      모든 네임스페이스의 모든 Pod에서 수신 거부

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

      위치

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

      동일한 네임 스페이스에 있는 모든 Pod에서 인그레스 허용

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

      위치

      <network_name>
      네트워크 연결 정의의 이름을 지정합니다.
  2. multi-network 정책 오브젝트를 생성하려면 다음 명령을 입력합니다.

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

    다음과 같습니다.

    <policy_name>
    다중 네트워크 정책 파일 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/default-deny created

12.3.3.3. 다중 네트워크 정책 편집

네임스페이스에서 다중 네트워크 정책을 편집할 수 있습니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy가 설정된 OVN-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인되어 있습니다.
  • 다중 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

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

    $ oc get multi-networkpolicy

    다음과 같습니다.

    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  2. multi-network 정책 오브젝트를 편집합니다.

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

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

      다음과 같습니다.

      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
      <policy_file>
      네트워크 정책이 포함된 파일의 이름을 지정합니다.
    • multi-network 정책 오브젝트를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.

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

      다음과 같습니다.

      <policy_name>
      네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
  3. multi-network 정책 오브젝트가 업데이트되었는지 확인합니다.

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

    다음과 같습니다.

    <policy_name>
    다중 네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

12.3.3.4. 다중 네트워크 정책 보기

네임스페이스에서 다중 네트워크 정책을 검사할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인되어 있습니다.
  • 다중 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 네임스페이스의 다중 네트워크 정책을 나열합니다.

    • 네임스페이스에 정의된 다중 네트워크 정책 오브젝트를 보려면 다음 명령을 입력합니다.

      $ oc get multi-networkpolicy
    • 선택 사항: 특정 다중 네트워크 정책을 검사하려면 다음 명령을 입력합니다.

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

      다음과 같습니다.

      <policy_name>
      검사할 다중 네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

12.3.3.5. 다중 네트워크 정책 삭제

네임스페이스에서 다중 네트워크 정책을 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy가 설정된 OVN-Kubernetes 네트워크 공급자 또는 OpenShift SDN 네트워크 공급자와 같은 NetworkPolicy 오브젝트를 지원하는 클러스터 네트워크 공급자를 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다.
  • OpenShift CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인되어 있습니다.
  • 다중 네트워크 정책이 있는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 다중 네트워크 정책 오브젝트를 삭제하려면 다음 명령을 입력합니다.

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

    다음과 같습니다.

    <policy_name>
    다중 네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted

12.3.4. 추가 리소스

12.4. 추가 네트워크에 pod 연결

클러스터 사용자는 pod를 추가 네트워크에 연결할 수 있습니다.

12.4.1. 추가 네트워크에 Pod 추가

추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.

프로세스

  1. Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.

    1. 사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. <network>를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
      1
      둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]
      1
      NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml

    다음 예에서 example-pod Pod는 net1 추가 네트워크에 연결되어 있습니다.

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

12.4.1.1. Pod별 주소 지정 및 라우팅 옵션 지정

추가 네트워크에 Pod를 연결할 때 특정 Pod에서 해당 네트워크에 대한 추가 속성을 지정할 수 있습니다. 이를 통해 라우팅의 일부 측면을 변경하고 고정 IP 주소 및 MAC 주소를 지정할 수 있습니다. 이를 위해 JSON 형식의 주석을 사용할 수 있습니다.

사전 요구 사항

  • Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.
  • OpenShift 명령줄 인터페이스(oc)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

주소 지정 및/또는 라우팅 옵션을 지정하는 동안 추가 네트워크에 Pod를 추가하려면 다음 단계를 완료하십시오.

  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>,...]]' 1
    1
    다음 예제와 같이 <network>를 JSON 오브젝트로 변경합니다. 작은 따옴표를 사용해야 합니다.
  3. 다음 예에서 주석은 default-route 매개변수를 사용하여 기본 경로로 지정될 네트워크 연결을 지정합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: example-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: '
        {
          "name": "net1"
        },
        {
          "name": "net2", 1
          "default-route": ["192.0.2.1"] 2
        }'
    spec:
      containers:
      - name: example-pod
        command: ["/bin/bash", "-c", "sleep 2000000000000"]
        image: centos/tools
    1
    name 키는 Pod와 연결할 추가 네트워크의 이름입니다.
    2
    default-route 키는 라우팅 테이블에 다른 라우팅 항목이 없는 경우 트래픽이 라우팅될 게이트웨이 값을 지정합니다. 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에서 지정할 수 있습니다.

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

    $ oc edit networks.operator.openshift.io cluster

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

CNO(Cluster Network Operator) YAML 구성

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

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

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

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

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

1
생성할 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
CNI 플러그인 구성의 배열을 지정합니다. 첫 번째 오브젝트는 macvlan 플러그인 구성을 지정하고, 두 번째 오브젝트는 튜닝 플러그인 구성을 지정합니다.
3
CNI 플러그인 런타임 구성 기능의 고정 IP 주소 기능을 사용하도록 요청하도록 지정합니다.
4
macvlan 플러그인이 사용하는 인터페이스를 지정합니다.
5
CNI 플러그인의 고정 MAC 주소 기능을 사용하도록 요청하도록 지정합니다.

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

다음을 사용하여 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>", 1
        "ips": [ "192.0.2.205/24" ], 2
        "mac": "CA:FE:C0:FF:EE:00" 3
      }
    ]'

1
위의 rawCNIConfig를 구성하는 경우에는 제공되는 <name>을 사용해야 합니다.
2
서브넷 마스크를 포함하여 IP 주소를 제공합니다.
3
MAC 주소를 제공합니다.
참고

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

추가 네트워크가 있는 Pod의 IP 주소 및 MAC 속성을 확인하려면 oc 명령을 사용하여 Pod에서 ip 명령을 실행합니다.

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

12.5. 추가 네트워크에서 Pod 제거

클러스터 사용자는 추가 네트워크에서 Pod를 제거할 수 있습니다.

12.5.1. 추가 네트워크에서 Pod 제거

Pod를 삭제해야만 추가 네트워크에서 Pod를 제거할 수 있습니다.

사전 요구 사항

  • Pod에 추가 네트워크가 연결되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.

프로세스

  • Pod를 삭제하려면 다음 명령을 입력합니다.

    $ oc delete pod <name> -n <namespace>
    • <name>은 Pod의 이름입니다.
    • <namespace>는 Pod가 포함된 네임스페이스입니다.

12.6. 브리지 네트워크 구성

클러스터 관리자는 브릿지 CNI(Container Network Interface) 플러그인을 사용하여 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. 구성되면 노드의 모든 Pod가 가상 스위치에 연결됩니다. 각 pod에는 추가 네트워크의 IP 주소가 할당됩니다.

12.6.1. 브릿지 CNI 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에 대한 추가 네트워크를 생성하려면 다음 단계를 완료하십시오.

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

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    브릿지 CNI 플러그인을 구성하는 YAML은 다음과 같습니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "test-network-1",
          "type": "bridge",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "192.168.1.23/24"
              }
            ]
          }
        }'
    1
    추가 네트워크 연결 정의에 대한 구성을 지정합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                 AGE
    test-network-1       14m

12.6.1.1. 브리지 구성

브릿지 CNI(Container Network Interface) 플러그인을 사용하는 추가 네트워크 연결 구성은 다음 두 부분으로 제공됩니다.

  • CNO(Cluster Network Operator) 구성
  • CNI 플러그인 구성

CNO 구성은 추가 네트워크 연결의 이름과 연결을 생성할 네임스페이스를 지정합니다. 플러그인은 CNO 구성에서 rawCNIConfig 매개변수로 지정된 JSON 오브젝트로 구성됩니다.

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

CNO(Cluster Network Operator) YAML 구성

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

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

다음 오브젝트는 브릿지 CNI 플러그인의 구성 매개변수를 설명합니다.

브릿지 CNI 플러그인 JSON 구성 오브젝트

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "bridge",
  "bridge": "<bridge>", 2
  "ipam": { 3
    ...
  },
  "ipMasq": false, 4
  "isGateway": false, 5
  "isDefaultGateway": false, 6
  "forceAddress": false, 7
  "hairpinMode": false, 8
  "promiscMode": false, 9
  "vlan": <vlan>, 10
  "mtu": <mtu> 11
}

1
CNO 구성에 대해 이전에 입력한 name 매개변수의 값을 지정합니다.
2
사용할 가상 브릿지의 이름을 지정합니다. 브릿지 인터페이스가 호스트에 없으면 생성됩니다. 기본값은 cni0입니다.
3
ipam CNI 플러그인의 구성 오브젝트를 지정합니다. 이 플러그인은 네트워크 연결 정의에 대한 IP 주소 지정을 관리합니다.
4
가상 네트워크에서 전송되는 트래픽에 IP 마스커레이딩을 사용하려면 true로 설정합니다. 모든 트래픽의 소스 IP 주소가 브리지의 IP 주소로 다시 작성됩니다. 브리지에 IP 주소가 없으면 이 설정이 적용되지 않습니다. 기본값은 false입니다.
5
브리지에 IP 주소를 할당하려면 true로 설정합니다. 기본값은 false입니다.
6
브릿지를 가상 네트워크의 기본 게이트웨이로 구성하려면 true로 설정합니다. 기본값은 false입니다. isDefaultGatewaytrue로 설정되면 isGateway도 자동으로 true로 설정됩니다.
7
이전에 할당된 IP 주소를 가상 브리지에 할당할 수 있도록 하려면 true로 설정합니다. false로 설정하면 중첩되는 하위 집합의 IPv4 주소 또는 IPv6 주소가 가상 브릿지에 지정되는 경우 오류가 발생합니다. 기본값은 false입니다.
8
가상 브릿지가 수신한 가상 포트를 통해 이더넷 프레임을 다시 보낼 수 있도록 하려면 true로 설정합니다. 이 모드를 반사 릴레이라고도 합니다. 기본값은 false입니다.
9
브릿지에서 무차별 모드를 사용하려면 true로 설정합니다. 기본값은 false입니다.
10
VLAN(가상 LAN) 태그를 정수 값으로 지정합니다. 기본적으로 VLAN 태그는 할당되지 않습니다.
11
최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.
12.6.1.1.1. 브릿지 구성 예

다음 예제는 이름이 bridge-net인 추가 네트워크를 구성합니다.

name: bridge-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}'
1
CNI 구성 오브젝트는 YAML 문자열로 지정됩니다.

12.6.1.2. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
12.6.1.2.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
12.6.1.2.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

12.6.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
12.6.1.2.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
12.6.1.2.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
12.6.1.2.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

12.6.2. 다음 단계

12.7. 호스트 장치 네트워크 구성

클러스터 관리자는 호스트 장치 CNI(Container Network Interface) 플러그인을 사용하여 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. 플러그인을 사용하면 지정된 네트워크 장치를 호스트의 네트워크 네임스페이스에서 Pod의 네트워크 네임스페이스로 이동할 수 있습니다.

12.7.1. 호스트 장치 CNI 플러그인을 사용하여 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에 대한 추가 네트워크를 생성하려면 다음 단계를 완료하십시오.

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

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    다음 YAML은 호스트 장치 CNI 플러그인을 구성합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "test-network-1",
          "type": "host-device",
          "device": "eth1",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "192.168.1.23/24"
              }
            ]
          }
        }'
    1
    추가 네트워크 연결 정의에 대한 구성을 지정합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                 AGE
    test-network-1       14m

12.7.1.1. 호스트 장치 구성

호스트 장치 CNI(Container Network Interface) 플러그인을 사용하는 추가 네트워크 연결 구성은 다음 두 부분으로 제공됩니다.

  • CNO(Cluster Network Operator) 구성
  • CNI 플러그인 구성

CNO 구성은 추가 네트워크 연결의 이름과 연결을 생성할 네임스페이스를 지정합니다. 플러그인은 CNO 구성에서 rawCNIConfig 매개변수로 지정된 JSON 오브젝트로 구성됩니다.

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

CNO(Cluster Network Operator) YAML 구성

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

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.
중요

device, hwaddr, kernelpath 또는 pciBusID 매개변수 중 하나만 설정하여 네트워크 장치를 지정합니다.

다음 오브젝트는 호스트 장치 CNI 플러그인의 구성 매개변수를 설명합니다.

호스트 장치 CNI 플러그인 JSON 구성 오브젝트

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "host-device",
  "device": "<device>", 2
  "hwaddr": "<hwaddr>", 3
  "kernelpath": "<kernelpath>", 4
  "pciBusID": "<pciBusID>", 5
  "ipam": { 6
    ...
  }
}

1
CNO 구성에 대해 이전에 입력한 name 매개변수의 값을 지정합니다.
2
장치 이름을 지정합니다(예: eth0).
3
장치 하드웨어 MAC 주소를 지정합니다.
4
Linux 커널 장치 경로(예: /sys/devices/pci0000:00/0000:00:1f.6)를 지정합니다.
5
네트워크 장치의 PCI 주소를 지정합니다(예: 0000:00: 1f.6).
6
ipam CNI 플러그인의 구성 오브젝트를 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
12.7.1.1.1. 호스트 장치 구성 예

다음 예제는 이름이 hostdev-net인 추가 네트워크를 구성합니다.

name: hostdev-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1",
  "ipam": {
    "type": "dhcp"
  }
}'
1
CNI 구성 오브젝트는 YAML 문자열로 지정됩니다.

12.7.1.2. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
12.7.1.2.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
12.7.1.2.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

12.7.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
12.7.1.2.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
12.7.1.2.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
12.7.1.2.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

12.7.2. 다음 단계

12.8. ipvlan 네트워크 구성

클러스터 관리자는 ipvlan CNI(Container Network Interface) 플러그인을 사용하여 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. 이 플러그인으로 생성된 가상 네트워크는 지정한 물리적 인터페이스와 연결됩니다.

12.8.1. ipvlan CNI 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에 대한 추가 네트워크를 생성하려면 다음 단계를 완료하십시오.

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

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    다음 YAML은 ipvlan CNI 플러그인을 구성합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "test-network-1",
          "type": "ipvlan",
          "master": "eth1",
          "mode": "l2",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "192.168.1.23/24"
              }
            ]
          }
        }'
    1
    추가 네트워크 연결 정의에 대한 구성을 지정합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                 AGE
    test-network-1       14m

12.8.1.1. ipvlan 구성

ipvlan CNI(Container Network Interface) 플러그인을 사용하는 추가 네트워크 연결 구성은 다음 두 부분으로 제공됩니다.

  • CNO(Cluster Network Operator) 구성
  • CNI 플러그인 구성

CNO 구성은 추가 네트워크 연결의 이름과 연결을 생성할 네임스페이스를 지정합니다. 플러그인은 CNO 구성에서 rawCNIConfig 매개변수로 지정된 JSON 오브젝트로 구성됩니다.

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

CNO(Cluster Network Operator) YAML 구성

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

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

다음 오브젝트는 ipvlan CNI 플러그인의 구성 매개변수를 설명합니다.

ipvlan CNI 플러그인 JSON 구성 오브젝트

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "ipvlan",
  "mode": "<mode>", 2
  "master": "<master>", 3
  "mtu": <mtu>, 4
  "ipam": { 5
    ...
  }
}

1
CNO 구성에 대해 이전에 입력한 name 매개변수의 값을 지정합니다.
2
가상 네트워크의 작동 모드를 지정합니다. 값은 l2, l3 또는 l3s여야 합니다. 기본값은 l2입니다.
3
네트워크 연결과 연결할 이더넷 인터페이스를 지정합니다. 마스터를 지정하지 않으면 기본 네트워크 경로에 대한 인터페이스가 사용됩니다.
4
최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.
5
ipam CNI 플러그인의 구성 오브젝트를 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
12.8.1.1.1. ipvlan 구성 예

다음 예제는 이름이 ipvlan-net인 추가 네트워크를 구성합니다.

name: ipvlan-net
namespace: work-network
type: Raw
rawCNIConfig: '{ 1
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "dhcp"
    }
}'
1
CNI 구성 오브젝트는 YAML 문자열로 지정됩니다.

12.8.1.2. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
12.8.1.2.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
12.8.1.2.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

12.8.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
12.8.1.2.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
12.8.1.2.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
12.8.1.2.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

12.8.2. 다음 단계

12.9. 기본 사용자 정의로 macvlan 네트워크 구성

클러스터 관리자는 macvlan CNI(Container Network Interface) 플러그인을 사용하여 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. Pod가 네트워크에 연결되면 플러그인은 호스트의 상위 인터페이스에서 하위 인터페이스를 생성합니다. 각 하위 장치마다 고유한 하드웨어 mac 주소가 생성됩니다.

중요

이 플러그인이 하위 인터페이스를 위해 생성하는 고유 MAC 주소는 클라우드 공급자의 보안 정책과 호환되지 않을 수 있습니다.

YAML에서 직접 기본 구성을 지정합니다. 이 방법은 JSON에서 직접 CNI 오브젝트를 사용하여 macvlan 구성을 지정하는 것보다 적은 수의 구성 옵션을 제공합니다.

12.9.1. macvlan CNI 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에 대한 추가 네트워크를 생성하려면 다음 단계를 완료하십시오.

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

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    다음 YAML은 macvlan CNI 플러그인을 구성합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: SimpleMacvlan
        simpleMacvlanConfig:
          ipamConfig:
            type: static
            staticIPAMConfig:
              addresses:
              - address: 10.1.1.7/24
    1
    추가 네트워크 연결 정의에 대한 구성을 지정합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                 AGE
    test-network-1       14m

12.9.1.1. macvlan CNI 플러그인 구성

다음 YAML 오브젝트는 OpenShift SDN 기본 CNI(Container Network Interface) 네트워크 공급자에 대한 구성 매개변수를 설명합니다.

macvlan YAML 구성

name: <name> 1
namespace: <namespace> 2
type: SimpleMacvlan
simpleMacvlanConfig:
  master: <master> 3
  mode: <mode> 4
  mtu: <mtu> 5
  ipamConfig: 6
    ...

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
가상 인터페이스와 연결할 이더넷 인터페이스입니다. master 값을 지정하지 않으면 호스트 시스템의 기본 이더넷 인터페이스가 사용됩니다.
4
가상 네트워크에서 트래픽 가시성을 구성합니다. bridge, passthru, private 또는 vepa 중 하나여야 합니다. mode 값이 입력되지 않으면 기본값은 bridge입니다.
5
최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.
6
ipam CNI 플러그인의 구성 오브젝트를 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
12.9.1.1.1. macvlan 구성 예

다음 예제는 이름이 macvlan-net인 추가 네트워크를 구성합니다.

name: macvlan-net
namespace: work-network
type: SimpleMacvlan
simpleMacvlanConfig:
  ipamConfig:
    type: DHCP

12.9.1.2. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

다음 YAML 구성은 설정할 수 있는 매개변수를 설명합니다.

ipam CNI 플러그인 YAML 구성 오브젝트

ipamConfig:
  type: <type> 1
  ... 2

1
IP 주소 할당을 관리하도록 플러그인을 구성하려면 static을 지정합니다. DHCP 서버가 IP 주소 할당을 관리할 수 있도록 DHCP를 지정합니다. DHCP 값을 지정하면 추가 매개변수를 지정할 수 없습니다.
2
type 매개변수를 static으로 설정한 경우 staticIPAMConfig 매개변수를 입력합니다.
12.9.1.2.1. 고정 IPam 구성 YAML

다음 YAML은 고정 IP 주소를 할당하기 위한 구성을 설명합니다.

고정 IPam 구성 YAML

ipamConfig:
  type: static
  staticIPAMConfig:
    addresses: 1
    - address: <address> 2
      gateway: <gateway> 3
    routes: 4
    - destination: <destination> 5
      gateway: <gateway> 6
    dns: 7
      nameservers: 8
      - <nameserver>
      domain: <domain> 9
      search: 10
      - <search_domain>

1
가상 인터페이스에 할당할 IP 주소를 정의하는 매핑 컬렉션입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 매핑 컬렉션입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 전송하기 위한 하나 이상의 IP 주소 컬렉션입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
12.9.1.2.2. 동적 ipam 구성 YAML

다음 YAML은 고정 IP 주소를 할당하기 위한 구성을 설명합니다.

동적 ipam 구성 YAML

ipamConfig:
  type: DHCP

12.9.1.2.3. 고정 IP 주소 할당 구성 예

다음 예는 고정 IP 주소에 대한 ipam 구성을 보여줍니다.

ipamConfig:
  type: static
  staticIPAMConfig:
    addresses:
    - address: 198.51.100.11/24
      gateway: 198.51.100.10
    routes:
    - destination: 0.0.0.0/0
      gateway: 198.51.100.1
    dns:
      nameservers:
      - 198.51.100.1
      - 198.51.100.2
      domain: testDNS.example
      search:
      - testdomain1.example
      - testdomain2.example
12.9.1.2.4. 동적 IP 주소 할당 구성 예

다음 예는 DHCP의 ipam 구성을 보여줍니다.

ipamConfig:
  type: DHCP

12.9.2. 다음 단계

12.10. macvlan 네트워크 구성

클러스터 관리자는 고급 사용자 정의가 포함된 macvlan 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용하여 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. Pod가 네트워크에 연결되면 플러그인은 호스트의 상위 인터페이스에서 하위 인터페이스를 생성합니다. 각 하위 장치마다 고유한 하드웨어 mac 주소가 생성됩니다.

중요

이 플러그인이 하위 인터페이스를 위해 생성하는 고유 MAC 주소는 클라우드 공급자의 보안 정책과 호환되지 않을 수 있습니다.

CNI 오브젝트로 구성을 지정합니다. 이 방법을 사용하면 YAML 구성을 사용할 때 사용할 수 없는 추가 구성 옵션을 지정할 수 있습니다.

12.10.1. macvlan CNI 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에 대한 추가 네트워크를 생성하려면 다음 단계를 완료하십시오.

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

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    다음 YAML은 macvlan CNI 플러그인을 구성합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: 1
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "test-network-1",
          "type": "macvlan",
          "master": "eth1",
          "ipam": {
            "type": "static",
            "addresses": [
              {
                "address": "192.168.1.23/24"
              }
            ]
          }
        }'
    1
    추가 네트워크 연결 정의에 대한 구성을 지정합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                 AGE
    test-network-1       14m

12.10.1.1. macvlan CNI 플러그인 구성

macvlan CNI(Container Network Interface) 플러그인을 사용하는 추가 네트워크 연결 구성은 다음 두 부분으로 제공됩니다.

  • CNO(Cluster Network Operator) 구성
  • CNI 플러그인 구성

CNO 구성은 추가 네트워크 연결의 이름과 연결을 생성할 네임스페이스를 지정합니다. 플러그인은 CNO 구성에서 rawCNIConfig 매개변수로 지정된 JSON 오브젝트로 구성됩니다.

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

CNO(Cluster Network Operator) YAML 구성

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

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
네트워크를 연결한 네임스페이스를 지정합니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
3
다음 템플릿을 기반으로 CNI 플러그인 구성을 JSON 형식으로 지정합니다.

다음 오브젝트는 macvlan CNI 플러그인의 구성 매개변수를 설명합니다.

macvlan CNI 플러그인 JSON 구성 오브젝트

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "type": "macvlan",
  "mode": "<mode>", 2
  "master": "<master>", 3
  "mtu": <mtu>, 4
  "ipam": { 5
    ...
  }
}

1
생성 중인 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
가상 네트워크에서 트래픽 가시성을 구성합니다. bridge, passthru, private 또는 vepa 중 하나여야 합니다. 값을 입력하지 않으면 기본값은 bridge입니다.
3
가상 인터페이스와 연결할 이더넷 인터페이스입니다. 값을 지정하지 않으면 호스트 시스템의 기본 이더넷 인터페이스가 사용됩니다.
4
최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.
5
ipam CNI 플러그인의 구성 오브젝트를 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
12.10.1.1.1. macvlan 구성 예

다음 예제는 이름이 macvlan-net인 추가 네트워크를 구성합니다.

name: macvlan-net
namespace: work-network
type: Raw
rawCNIConfig: |-
  {
    "cniVersion": "0.3.1",
    "name": "macvlan-net",
    "type": "macvlan",
    "master": "eth1",
    "mode": "bridge",
    "ipam": {
      "type": "dhcp"
      }
  }

12.10.1.2. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
12.10.1.2.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
12.10.1.2.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

12.10.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
12.10.1.2.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
12.10.1.2.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
12.10.1.2.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

12.10.2. 다음 단계

12.11. 추가 네트워크 편집

클러스터 관리자는 기존 추가 네트워크의 구성을 수정할 수 있습니다.

12.11.1. 추가 네트워크 연결 정의 수정

클러스터 관리자는 기존 추가 네트워크를 변경할 수 있습니다. 추가 네트워크에 연결된 기존 Pod는 업데이트되지 않습니다.

사전 요구 사항

  • 클러스터에 추가 네트워크가 구성되어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터의 추가 네트워크를 편집하려면 다음 단계를 완료하십시오.

  1. 기본 텍스트 편집기에서 CNO(Cluster Network Operator) CR을 편집하려면 다음 명령을 실행합니다.

    $ oc edit networks.operator.openshift.io cluster
  2. additionalNetworks 컬렉션에서 변경 내용으로 추가 네트워크를 업데이트합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. 선택 사항: CNO에서 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 업데이트했는지 확인합니다. <network-name>을 표시할 추가 네트워크의 이름으로 변경합니다. CNO가 변경 사항을 반영하기 위해서 NetworkAttachmentDefinition 오브젝트를 업데이트하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions <network-name> -o yaml

    예를 들어, 다음 콘솔 출력은 net1이라는 NetworkAttachmentDefinition 오브젝트를 표시합니다.

    $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
    { "cniVersion": "0.3.1", "type": "macvlan",
    "master": "ens5",
    "mode": "bridge",
    "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

12.12. 추가 네트워크 제거

클러스터 관리자는 추가 네트워크의 연결을 제거할 수 있습니다.

12.12.1. 추가 네트워크 연결 정의 제거

클러스터 관리자는 OpenShift Container Platform 클러스터에서 추가 네트워크를 제거할 수 있습니다. 추가 네트워크는 연결된 Pod에서 제거되지 않습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

클러스터에서 추가 네트워크를 제거하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 기본 텍스트 편집기에서 CNO(Cluster Network Operator)를 편집합니다.

    $ oc edit networks.operator.openshift.io cluster
  2. 제거할 네트워크 연결 정의에 대한 additionalNetworks 컬렉션에서 구성을 제거하여 CR을 수정합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: [] 1
    1
    additionalNetworks 컬렉션에서 유일한 추가 네트워크 첨부 파일 정의에 대한 구성 매핑을 제거하는 경우 빈 컬렉션을 지정해야 합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. 선택 사항: 추가 네트워크 CR이 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get network-attachment-definition --all-namespaces

12.13. VRF에 보조 네트워크 할당

중요

CNI VRF 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 고객은 출시 예정된 제품 기능을 Preview를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

12.13.1. VRF에 보조 네트워크 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 VRF 도메인에 대한 추가 네트워크를 구성할 수 있습니다. 이 플러그인으로 생성된 가상 네트워크는 지정한 물리적 인터페이스와 연결됩니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

12.13.1.1. CNI VRF 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

CNO가 관리하는 NetworkAttachmentDefinition CR을 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 OpenShift 클러스터에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 CNO CR을 생성합니다.

    $ oc edit networks.operator.openshift.io cluster
  2. 아래의 예제 CR과 같이 추가 네트워크의 rawCNIConfig 구성을 추가하여 생성 중인 CR을 확장합니다. CNI VRF플러그인을 구성하는 YAML은 다음과 같습니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
      spec:
      additionalNetworks:
      - name: test-network-1
        namespace: test-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "macvlan-vrf",
          "plugins": [  1
          {
            "type": "macvlan",  2
            "master": "eth1",
            "ipam": {
                "type": "static",
                "addresses": [
                {
                    "address": "191.168.1.23/24"
                }
                ]
            }
          },
          {
            "type": "vrf",
            "vrfname": "example-vrf-name",  3
            "table": 1001   4
          }]
        }'
    1
    plugins는 목록이어야 합니다. 목록의 첫 번째 항목은 VRF 네트워크를 기반으로 하는 보조 네트워크여야 합니다. 목록의 두 번째 항목은 VRF 플러그인 구성입니다.
    2
    typevrf로 설정해야 합니다.
    3
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
    4
    table은 라우팅 테이블 ID입니다. 선택 사항입니다. 기본적으로 tableid 매개변수가 사용됩니다. 지정하지 않으면 CNI에서 무료 라우팅 테이블 ID를 VRF에 할당합니다.
    참고

    VRF는 리소스의 유형이 netdevice인 경우에만 올바르게 작동합니다.

  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. CNO가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>

    출력 예

    NAME                       AGE
    additional-network-1       14m

추가 VRF 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. VRF CNI를 사용하는 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 VRF 추가 네트워크에 연결되어 있는지 확인합니다. 포드에 SSH를 적용하고 다음 명령을 실행합니다.

    $ ip vrf show
    Name              Table
    -----------------------
    red                 10
  4. VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.

    $ ip link
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

13장. 하드웨어 네트워크

13.1. SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크 정보

SR-IOV(Single Root I/O Virtualization) 사양은 단일 장치를 여러 Pod와 공유할 수 있는 PCI 장치 할당 유형의 표준입니다.

SR-IOV는 호스트 노드에서 물리적 기능(PF)으로 인식되는 호환 네트워크 장치를 여러 VF(가상 기능)로 분할할 수 있습니다. VF는 다른 네트워크 장치와 같이 사용됩니다. 장치의 SR-IOV 네트워크 장치 드라이버는 컨테이너에서 VF가 노출되는 방식을 결정합니다.

  • netdevice 드라이버: 컨테이너의 netns에 있는 일반 커널 네트워크 장치
  • vfio-pci 드라이버: 컨테이너에 마운트된 문자 장치

높은 대역폭 또는 낮은 대기 시간이 필요한 애플리케이션을 위해 OpenShift Container Platform 클러스터에서 추가 네트워크와 함께 SR-IOV 네트워크 장치를 사용할 수 있습니다.

13.1.1. SR-IOV 네트워크 장치를 관리하는 구성 요소

SR-IOV 네트워크 Operator는 SR-IOV 스택의 구성 요소를 생성하고 관리합니다. 다음과 같은 기능을 수행합니다.

  • SR-IOV 네트워크 장치 검색 및 관리 오케스트레이션
  • SR-IOV 컨테이너 네트워크 인터페이스(CNI)에 대한 NetworkAttachmentDefinition 사용자 정의 리소스 생성
  • SR-IOV 네트워크 장치 플러그인의 구성 생성 및 업데이트
  • 노드별 SriovNetworkNodeState 사용자 정의 리소스 생성
  • SriovNetworkNodeState 사용자 정의 리소스에서 spec.interfaces 필드 업데이트

Operator는 다음 구성 요소를 프로비저닝합니다.

SR-IOV 네트워크 구성 데몬
SR-IOV Network Operator가 시작될 때 작업자 노드에 배포되는 데몬 세트입니다. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
SR-IOV Network Operator Webhook
Operator 사용자 정의 리소스의 유효성을 검증하고 설정되지 않은 필드에 적절한 기본값을 설정하는 동적 승인 컨트롤러 webhook.
SR-IOV 네트워크 리소스 인젝터
SR-IOV VF와 같은 사용자 정의 네트워크 리소스에 대한 요청 및 제한으로 Kubernetes pod 사양을 패치하는 기능을 제공하는 동적 승인 컨트롤러 webhook.
SR-IOV 네트워크 장치 플러그인
SR-IOV 네트워크 VF(가상 기능) 리소스를 검색, 보급 및 할당하는 장치 플러그인입니다. Kubernetes에서는 장치 플러그인을 사용하여 일반적으로 물리적 장치에서 제한된 리소스를 사용할 수 있습니다. 장치 플러그인은 Kubernetes 스케줄러에 리소스 가용성을 알려 스케줄러가 충분한 리소스가 있는 노드에서 pod를 스케줄링할 수 있도록 합니다.
SR-IOV CNI 플러그인
SR-IOV 네트워크 장치 플러그인에서 할당된 VF 인터페이스를 Pod에 직접 연결하는 CNI 플러그인입니다.
SR-IOV InfiniBand CNI 플러그인
SR-IOV 네트워크 장치 플러그인에서 할당된 IB(InfiniBand) VF 인터페이스를 Pod에 직접 연결하는 CNI 플러그인입니다.
참고

SR-IOV 네트워크 리소스 인젝터 및 SR-IOV 네트워크 Operator webhook는 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR을 편집하여 비활성화할 수 있습니다.

13.1.1.1. 지원되는 장치

OpenShift Container Platform은 다음 NIC(네트워크 인터페이스 컨트롤러) 모델을 지원합니다.

  • 공급업체 ID가 0x8086이고 장치 ID가 0x1572인 Intel X710 10GbE SFP+
  • 공급업체 ID가 0x8086이고 장치 ID가 0x1583 Intel„710 40GbE SFP+
  • 공급업체 ID가 0x8086이고 장치 ID가 0x158b인 Intel XXV710 25GbE SFP28
  • 공급업체 ID가 0x8086이고 장치 ID가 0x1592인Intel E810-CQDA2 100GbE 듀얼 포트 QSPF28 및 E810-2CQDA2 100GbE 듀얼 포트 QSPF28
  • 공급업체 ID가 0x8086이고 장치 ID가 0x159b Intel E810-XXVDA2 25GbE 듀얼 포트 SPF28
  • 공급업체 ID가 0x8086이고 장치 ID가 0x1593 Intel E810-XXVDA4 25GbE 쿼드 포트 SPF28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1015인 Mellanox MT27710 제품군 [ConnectX-4 Lx] 25GbE 이중 포트 SFP28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1017인 Mellanox MT27800 제품군 [ConnectX-5] 25GbE 이중 포트 SFP28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1017인 Mellanox MT27800 제품군 [ConnectX-5] 100GbE
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1013인 Mellanox MT27700 제품군 [ConnectX-4] VPI 어댑터 카드, EDR IB(100Gb/s), 단일 포트 QSFP28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1017인 Mellanox MT27800 제품군 [ConnectX-5] VPI 어댑터 카드, EDR IB(100Gb/s), 단일 포트 QSFP28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x1019 Mellanox MT28880 제품군 [ConnectX-5 Ex] 이더넷 컨트롤러, 100Gb/s, 듀얼 포트 QSPF28
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x101b인 Mellanox MT28908 제품군 [ConnectX-6] VPI 어댑터 카드, HDR100 및 EDR IB(100Gb/s), 단일 포트 QSFP56
  • 공급업체 ID가 0x15b3이고 장치 ID가 0x101b인 Mellanox MT28908 제품군 [ConnectX-6] VPI 어댑터 카드, HDR200 IB(200Gb/s), 단일 포트 QSFP56

13.1.1.2. SR-IOV 네트워크 장치의 자동 검색

SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.

중요

SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.

13.1.1.2.1. SriovNetworkNodeState 오브젝트의 예

다음 YAML은 SR-IOV Network Operator가 생성한 SriovNetworkNodeState 오브젝트의 예입니다.

SriovNetworkNodeState 오브젝트

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1
name 필드의 값은 작업자 노드의 이름과 동일합니다.
2
인터페이스 스탠자에는 작업자 노드에서 Operator가 감지한 모든 SR-IOV 장치 목록이 포함되어 있습니다.

13.1.1.3. Pod에서 가상 함수 사용 예

SR-IOV VF가 연결된 pod에서 RDMA(Remote Direct Memory Access) 또는 DPDK(Data Plane Development Kit) 애플리케이션을 실행할 수 있습니다.

이 예는 RDMA 모드에서 VF(가상 기능)를 사용하는 pod를 보여줍니다.

RDMA 모드를 사용하는 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
     capabilities:
        add: ["IPC_LOCK"]
    command: ["sleep", "infinity"]

다음 예는 DPDK 모드에서 VF가 있는 pod를 보여줍니다.

DPDK 모드를 사용하는 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
     capabilities:
        add: ["IPC_LOCK"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

13.1.1.4. 컨테이너 애플리케이션에서 사용하는 DPDK 라이브러리

선택적 라이브러리app-netutil은 해당 포드에서 실행 중인 컨테이너 내에서 포드에 관한 네트워크 정보를 수집하기 위해 여러 API 메서드를 제공합니다.

이 라이브러리는 DPDK(Data Plane Development Kit) 모드에서 SR-IOV 가상 기능(VF)을 컨테이너에 통합하는 데 도움이 될 수 있습니다. 라이브러리는 Golang API와 C API를 모두 제공합니다.

현재 세 가지 API 메서드가 구현되어 있습니다.

GetCPUInfo()
이 함수는 컨테이너에서 사용할 수 있는 CPU를 확인하고 목록을 반환합니다.
GetHugepages()
이 함수는 각 컨테이너에 대해 Pod 사양에서 요청된 대규모 페이지 메모리의 양을 결정하고 값을 반환합니다.
GetInterfaces()
이 함수는 컨테이너의 인터페이스 집합을 결정하고 목록을 반환합니다. 반환 값에는 각 인터페이스에 대한 인터페이스 유형 및 유형별 데이터가 포함됩니다.

라이브러리 리포지토리에는 컨테이너 이미지,dpdk-app-centos를 빌드하는 샘플 Dockerfile이 포함되어 있습니다. 컨테이너 이미지는 포드 사양의 환경 변수에 따라 다음 DPDK 샘플 애플리케이션 중 하나를 실행할 수 있습니다. l2fwd,l3wd 또는 testpmd. 컨테이너 이미지는 app-netutil 라이브러리를 컨테이너 이미지 자체에 통합하는 예를 제공합니다. 라이브러리는 init 컨테이너에 통합할 수도 있습니다. init 컨테이너는 필요한 데이터를 수집하고 기존 DPDK 워크로드에 데이터를 전달할 수 있습니다.

13.1.1.5. Downward API에 대한 대규모 페이지 리소스 주입

Pod 사양에 대규모 페이지에 대한 리소스 요청 또는 제한이 포함된 경우 Network Resources Injector는 컨테이너에 대규모 페이지 정보를 제공하기 위해 Pod 사양에 Downward API 필드를 자동으로 추가합니다.

Network Resources Injector는 podnetinfo라는 볼륨을 추가하고 Pod의 각 컨테이너에 대해 /etc/podnetinfo에 마운트됩니다. 볼륨은 Downward API를 사용하며 대규모 페이지 요청 및 제한에 대한 파일을 포함합니다. 파일 이름 지정 규칙은 다음과 같습니다.

  • /etc/podnetinfo/hugepages_1G_request_<container-name>
  • /etc/podnetinfo/hugepages_1G_limit_<container-name>
  • /etc/podnetinfo/hugepages_2M_request_<container-name>
  • /etc/podnetinfo/hugepages_2M_limit_<container-name>

이전 목록에 지정된 경로는 app-netutil 라이브러리와 호환됩니다. 기본적으로 라이브러리는 /etc/podnetinfo 디렉터리에서 리소스 정보를 검색하도록 구성됩니다. Downward API 경로 항목을 수동으로 지정하도록 선택하는 경우 app-netutil 라이브러리는 이전 목록의 경로 외에도 다음 경로를 검색합니다.

  • /etc/podnetinfo/hugepages_request
  • /etc/podnetinfo/hugepages_limit
  • /etc/podnetinfo/hugepages_1G_request
  • /etc/podnetinfo/hugepages_1G_limit
  • /etc/podnetinfo/hugepages_2M_request
  • /etc/podnetinfo/hugepages_2M_limit

Network Resources Injector에서 생성할 수 있는 경로와 마찬가지로, 이전 목록의 경로는 선택적으로 _<container-name> 접미사로 종료할 수 있습니다.

13.1.2. 다음 단계

13.2. SR-IOV Network Operator 설치

SR-IOV(Single Root I/O Virtualization) Network Operator를 클러스터에 설치하여 SR-IOV 네트워크 장치 및 네트워크 연결을 관리할 수 있습니다.

13.2.1. SR-IOV Network Operator 설치

클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 SR-IOV Network Operator를 설치할 수 있습니다.

13.2.1.1. CLI: SR-IOV Network Operator 설치

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

  • SR-IOV를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 계정.

프로세스

  1. openshift-sriov-network-operator 네임스페이스를 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
      annotations:
        workload.openshift.io/allowed: management
    EOF
  2. OperatorGroup CR을 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    EOF
  3. SR-IOV Network Operator를 서브스크립션합니다.

    1. 다음 명령을 실행하여 OpenShift Container Platform 주 버전 및 부 버전을 가져옵니다. 다음 단계의 channel 값에 필요합니다.

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)
    2. SR-IOV Network Operator에 대한 서브스크립션 CR을 만들려면 다음 명령을 입력합니다.

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: sriov-network-operator-subsription
        namespace: openshift-sriov-network-operator
      spec:
        channel: "${OC_VERSION}"
        name: sriov-network-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
  4. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get csv -n openshift-sriov-network-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase

    출력 예

    Name                                        Phase
    sriov-network-operator.4.4.0-202006160135   Succeeded

13.2.1.2. 웹 콘솔 : SR-IOV Network Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 Operator를 설치할 수 있습니다.

참고

CLI를 사용하여 Operator group을 생성해야 합니다.

사전 요구 사항

  • SR-IOV를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 계정.

프로세스

  1. SR-IOV Network Operator의 네임스페이스를 만듭니다.

    1. OpenShift Container Platform 웹 콘솔에서 관리네임스페이스를 클릭합니다.
    2. 네임스페이스 생성을 클릭합니다.
    3. 이름 필드에 openshift-sriov-network-operator를 입력한 후 생성을 클릭합니다.
  2. SR-IOV Network Operator 설치:

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 SR-IOV Network Operator를 선택한 다음 설치를 클릭합니다.
    3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-sriov-network-operator를 선택합니다.
    4. 설치를 클릭합니다.
  3. SR-IOV Network Operator가 설치되었는지 확인하십시오.

    1. Operator설치된 Operator 페이지로 이동합니다.
    2. SR-IOV Network Operatoropenshift-sriov-network-operator 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인하십시오.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 트러블슈팅을 수행하십시오.

      • Operator 서브스크립션설치 계획 탭의 상태 아래에서 장애 또는 오류가 있는지 점검합니다.
      • WorkloadsPod 페이지로 이동하여 openshift-sriov-network-operator 프로젝트에서 Pod 로그를 확인하십시오.

13.2.2. 다음 단계

13.3. SR-IOV Network Operator 구성

SR-IOV(Single Root I/O Virtualization) Network Operator는 클러스터의 SR-IOV 네트워크 장치 및 네트워크 첨부 파일을 관리합니다.

13.3.1. SR-IOV Network Operator 구성

중요

SR-IOV Network Operator 구성 수정은 일반적으로 필요하지 않습니다. 대부분의 사용 사례에는 기본 구성이 권장됩니다. Operator의 기본 동작이 사용 사례와 호환되지 않는 경우에만 관련 구성을 수정하는 단계를 완료하십시오.

SR-IOV Network Operator는 SriovOperatorConfig.sriovnetwork.openshift.io CustomResourceDefinition 리소스를 추가합니다. Operator는 openshift-sriov-network-operator 네임스페이스에 default라는 SriovOperatorConfig CR(사용자 정의 리소스)을 자동으로 만듭니다.

참고

default CR에는 클러스터에 대한 SR-IOV Network Operator 구성이 포함됩니다. Operator 구성을 변경하려면 이 CR을 수정해야 합니다.

SriovOperatorConfig 오브젝트는 Operator 구성을 위한 몇 가지 필드를 제공합니다.

  • enableInjector를 사용하면 프로젝트 관리자가 Network Resources Injector 데몬 세트를 활성화하거나 비활성화할 수 있습니다.
  • enableOperatorWebhook을 사용하면 프로젝트 관리자가 Operator Admission Controller 웹 후크 데몬 세트를 활성화하거나 비활성화할 수 있습니다.
  • configDaemonNodeSelector를 사용하면 프로젝트 관리자가 선택된 노드에서 SR-IOV Network Config Daemon을 예약할 수 있습니다.

13.3.1.1. Network Resources Injector 정보

Network Resources Injector는 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

  • SR-IOV 네트워크 연결 정의 주석에 따라 SR-IOV 리소스 이름을 추가하기 위해 Pod 사양의 리소스 요청 및 제한 변경
  • Pod 사양을 Downward API 볼륨으로 변경하여 Pod 주석, 라벨 및 대규모 페이지 요청 및 제한을 노출합니다. 포드에서 실행되는 컨테이너는 /etc/podnetinfo 경로에 있는 파일로 노출된 정보에 액세스할 수 있습니다.

기본적으로 Network Resources Injector는 SR-IOV Network Operator에 의해 활성화되며 모든 컨트롤 플레인 노드(마스터 노드라고도 함)에서 데몬 세트로 실행됩니다. 다음은 컨트롤 플레인 노드가 3개인 클러스터에서 실행되는 Network Resources Injector Pod의 예입니다.

$ oc get pods -n openshift-sriov-network-operator

출력 예

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

13.3.1.2. SR-IOV Network Operator 승인 컨트롤러 Webhook 정보

SR-IOV Network Operator Admission Controller webhook은 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

  • SriovNetworkNodePolicy CR이 생성 또는 업데이트될 때 유효성 검사
  • CR을 만들거나 업데이트할 때 prioritydeviceType 필드의 기본값을 설정하여 SriovNetworkNodePolicy CR 변경

기본적으로 SR-IOV Network Operator Admission Controller webhook는 Operator에서 활성화하며 모든 컨트롤 플레인 노드에서 데몬 세트로 실행됩니다. 다음은 세 개의 컨트롤 플레인 노드가 있는 클러스터에서 실행되는 Operator Admission Controller 웹 후크 Pod의 예입니다.

$ oc get pods -n openshift-sriov-network-operator

출력 예

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

13.3.1.3. 사용자 정의 노드 선택기 정보

SR-IOV Network Config 데몬은 클러스터 노드에서 SR-IOV 네트워크 장치를 검색하고 구성합니다. 기본적으로 클러스터의 모든 worker 노드에 배포됩니다. 노드 레이블을 사용하여 SR-IOV Network Config 데몬이 실행되는 노드를 지정할 수 있습니다.

13.3.1.4. Network Resources Injector 비활성화 또는 활성화

기본적으로 활성화되어 있는 Network Resources Injector를 비활성화하거나 활성화하려면 다음 절차를 완료하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • SR-IOV Network Operator가 설치되어 있어야 합니다.

프로세스

  • enableInjector 필드를 설정합니다. 기능을 비활성화하려면 <value>false로 바꾸고 기능을 활성화하려면 true로 바꿉니다.

    $ oc patch sriovoperatorconfig default \
      --type=merge -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableInjector": <value> } }'
    작은 정보

    대신 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: <value>

13.3.1.5. SR-IOV Network Operator 승인 컨트롤러 webhook 비활성화 또는 활성화

Admission Controller webhook를 비활성화하거나 활성화하려면(기본적으로 활성화되어 있음) 다음 절차를 완료하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • SR-IOV Network Operator가 설치되어 있어야 합니다.

프로세스

  • enableOperatorWebhook 필드를 설정합니다. 기능을 비활성화하려면 <value>false로 바꾸고 활성화하려면 true로 바꿉니다.

    $ oc patch sriovoperatorconfig default --type=merge \
      -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableOperatorWebhook": <value> } }'
    작은 정보

    대신 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableOperatorWebhook: <value>

13.3.1.6. SR-IOV Network Config 데몬에 대한 사용자 정의 NodeSelector 구성

SR-IOV Network Config 데몬은 클러스터 노드에서 SR-IOV 네트워크 장치를 검색하고 구성합니다. 기본적으로 클러스터의 모든 worker 노드에 배포됩니다. 노드 레이블을 사용하여 SR-IOV Network Config 데몬이 실행되는 노드를 지정할 수 있습니다.

SR-IOV Network Config 데몬이 배포된 노드를 지정하려면 다음 절차를 완료하십시오.

중요

configDaemonNodeSelector 필드를 업데이트하면 선택한 각 노드에서 SR-IOV Network Config 데몬이 다시 생성됩니다. 데몬이 다시 생성되는 동안 클러스터 사용자는 새로운 SR-IOV 네트워크 노드 정책을 적용하거나 새로운 SR-IOV Pod를 만들 수 없습니다.

프로세스

  • Operator의 노드 선택기를 업데이트하려면 다음 명령을 입력합니다.

    $ oc patch sriovoperatorconfig default --type=json \
      -n openshift-sriov-network-operator \
      --patch '[{
          "op": "replace",
          "path": "/spec/configDaemonNodeSelector",
          "value": {<node_label>}
        }]'

    <node_label>을 다음 예와 같이 적용할 레이블로 바꿉니다. "node-role.kubernetes.io/worker": "".

    작은 정보

    대신 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        <node_label>

13.3.2. 다음 단계

13.4. SR-IOV 네트워크 장치 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.

13.4.1. SR-IOV 네트워크 노드 구성 오브젝트

SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 지정합니다. 정책의 API 오브젝트는 sriovnetwork.openshift.io API 그룹의 일부입니다.

다음 YAML은 SR-IOV 네트워크 노드 정책을 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  numVfs: <num> 7
  nicSelector: 8
    vendor: "<vendor_code>" 9
    deviceID: "<device_id>" 10
    pfNames: ["<pf_name>", ...] 11
    rootDevices: ["<pci_bus_id>", ...] 12
    netFilter: "<filter_string>" 13
  deviceType: <device_type> 14
  isRdma: false 15
  linkType: <link_type> 16
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택된 노드에만 배포됩니다.
5
선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
6
선택사항: 가상 기능의 최대 전송 단위(MTU)입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.
7
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128보다 클 수 없습니다.
8
NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.

9
선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 허용되는 값은 808615b3입니다.
10
선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다. 예를 들어 101b는 Mellanox ConnectX-6 장치의 장치 ID입니다.
11
선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
12
선택 사항: 장치의 PF에 대해 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 주소를 0000:02: 00.1 형식으로 입력합니다.
13
선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다.
14
선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevicevfio-pci입니다. 기본값은 netdevice입니다.

베어 메탈 노드의 DPDK(Data Plane Development Kit) 모드에서 Mellanox NIC 카드를 작동시키려면 netdevice 드라이버 유형을 사용하고 isRdmatrue로 설정합니다.

15
선택사항: 원격 직접 메모리 액세스(RDMA) 모드 사용 여부입니다. 기본값은 false입니다.

isRDMA 매개변수가 true로 설정된 경우 RDMA 가능 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.

16
선택사항: VF의 링크 유형입니다. eth 또는 ib 값 중 하나를 지정할 수 있습니다. 이더넷의 경우 eth를 지정하거나 InfiniBand의 경우 ib를 지정합니다. 기본값은 eth입니다.

linkTypeib로 설정하면 isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로 true로 설정됩니다. linkTypeib로 설정하면 deviceTypevfio-pci로 설정해서는 안 됩니다.

13.4.1.1. SR-IOV 네트워크 노드 구성 예

다음 예제에서는 InfiniBand 장치의 구성을 설명합니다.

InfiniBand 장치의 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

다음 예제에서는 RHOSP 가상 머신의 SR-IOV 네트워크 장치에 대한 구성을 설명합니다.

가상 머신의 SR-IOV 장치 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2

1
가상 머신에 대한 노드 네트워크 정책을 구성할 때 numVfs 필드는 항상 1로 설정됩니다.
2
가상 머신이 RHOSP에 배포될 때 netFilter 필드는 네트워크 ID를 참조해야 합니다. netFilter의 유효한 값은 SriovNetworkNodeState 오브젝트에서 사용할 수 있습니다.

13.4.1.2. SR-IOV 장치의 VF(가상 기능) 파티셔닝

경우에 따라 동일한 물리적 기능(PF)의 VF(가상 기능)를 여러 리소스 풀로 분할할 수 있습니다. 예를 들어, 일부 VF를 기본 드라이버로 로드하고 나머지 VF를vfio-pci 드라이버로 로드할 수 있습니다. 이러한 배포에서 SriovNetworkNodePolicy CR(사용자 정의 리소스)의 pfNames 선택기를 사용하여 <pfname>#<first_vf>-<last_vf> 형식을 사용하여 풀의 VF 범위를 지정할 수 있습니다.

예를 들어 다음 YAML은 VF 2에서 7까지의 netpf0 인터페이스에 대한 선택기를 보여줍니다.

pfNames: ["netpf0#2-7"]
  • netpf0은 PF 인터페이스 이름입니다.
  • 2는 범위에 포함된 첫 번째 VF 인덱스(0 기반)입니다.
  • 7은 범위에 포함된 마지막 VF 인덱스(0 기반)입니다.

다음 요구 사항이 충족되면 다른 정책 CR을 사용하여 동일한 PF에서 VF를 선택할 수 있습니다.

  • 동일한 PF를 선택하는 정책의 경우 numVfs 값이 동일해야 합니다.
  • VF 색인은 0에서 <numVfs>-1까지의 범위 내에 있어야 합니다. 예를 들어, numVfs8로 설정된 정책이 있는 경우 <first_vf> 값은 0보다 작아야 하며 <last_vf>7보다 크지 않아야 합니다.
  • 다른 정책의 VF 범위는 겹치지 않아야 합니다.
  • <first_vf><last_vf>보다 클 수 없습니다.

다음 예는 SR-IOV 장치의 NIC 파티셔닝을 보여줍니다.

정책 policy-net-1은 기본 VF 드라이버와 함께 PF netpf0의 VF 0을 포함하는 리소스 풀 net-1을 정의합니다. 정책 policy-net-1-dpdkvfio VF 드라이버와 함께 PF netpf0의 VF 8 ~ 15를 포함하는 리소스 풀 net-1-dpdk를 정의합니다.

정책 policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

정책 policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

13.4.2. SR-IOV 네트워크 장치 구성

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
  • SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.

프로세스

  1. SriovNetworkNodePolicy 오브젝트를 생성한 후 YAML을 <name>-sriov-node-network.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.
  1. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f <name>-sriov-node-network.yaml

    <name>은 이 구성의 이름을 지정합니다.

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.

  2. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

13.4.3. SR-IOV 구성 문제 해결

SR-IOV 네트워크 장치를 구성하기 위한 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 해결합니다.

노드 상태를 표시하려면 다음 명령을 실행합니다.

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

여기서 <node_name>은 SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.

오류 출력 : 메모리를 할당할 수 없음

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.

  • 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
  • BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.
중요

CNI VRF 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 고객은 출시 예정된 제품 기능을 Preview를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

13.4.4. SR-IOV 네트워크를 VRF에 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.

이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

13.4.4.1. CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결 생성

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 SriovNetwork CR을 생성합니다.

    $ oc create sriovnetwork.openshift.io cluster
  2. 다음 예제 CR과 같이 생성할 추가 네트워크의 metaPlugins 구성을 추가하여 생성 중인 CR을 확장합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다. 다음 YAML은 SriovNetwork 오브젝트를 구성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: example-network
      namespace: additional-sriov-network-1
    spec:
      ipam: |
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [{
            "dst": "0.0.0.0/0"
          }],
          "gateway": "10.56.217.1"
        }
      vlan: 0
      resourceName: intelnics
      metaPlugins : |
        {
          "type": "vrf", 1
          "vrfname": "example-vrf-name" 2
        }
    1
    typevrf로 설정해야 합니다.
    2
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인합니다.

SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스로 변경합니다. SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

$ oc get network-attachment-definitions -n <namespace>

출력 예

NAME                            AGE
additional-sriov-network-1      14m

추가 SR-IOV 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. 포드에 SSH를 적용하고 다음 명령을 실행합니다.

    $ ip vrf show

    출력 예

    Name              Table
    -----------------------
    red                 10

  4. VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.

    $ ip link

    출력 예

    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

13.4.5. 다음 단계

13.5. SR-IOV 이더넷 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.

13.5.1. 이더넷 장치 구성 오브젝트

SriovNetwork 오브젝트를 정의하여 이더넷 네트워크 장치를 구성할 수 있습니다.

다음 YAML은 SriovNetwork 오브젝트를 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  networkNamespace: <target_namespace> 4
  vlan: <vlan> 5
  spoofChk: "<spoof_check>" 6
  ipam: |- 7
    {}
  linkState: <link_state> 8
  maxTxRate: <max_tx_rate> 9
  minTxRate: <min_tx_rate> 10
  vlanQoS: <vlan_qos> 11
  trust: "<trust_vf>" 12
  capabilities: <capabilities> 13
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
5
선택사항: 추가 네트워크의 VLAN(Virtual LAN) ID입니다. 정수 값은 0에서 4095 사이여야 합니다. 기본값은 0입니다.
6
선택사항: VF의 스푸핑 검사 모드입니다. 허용되는 값은 문자열 "on""off"입니다.
중요

SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 오브젝트를 거부해야 합니다.

7
YAML 블록 스칼라인 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
8
선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disableauto입니다.
9
선택사항: VF의 경우 최대 전송 속도(Mbps)입니다.
10
선택사항: VF의 경우 최소 전송 속도(Mbps)입니다. 이 값은 최대 전송 속도보다 작거나 같아야 합니다.
참고

인텔 NIC는 minTxRate 매개변수를 지원하지 않습니다. 자세한 내용은 BZ#1772847에서 참조하십시오.

11
선택사항: VF의 IEEE 802.1p 우선순위 수준입니다. 기본값은 0입니다.
12
선택사항: VF의 신뢰 모드입니다. 허용되는 값은 문자열 "on""off"입니다.
중요

지정한 값을 따옴표로 묶어야 합니다. 그렇지 않으면 SR-IOV Network Operator에서 오브젝트를 거부합니다.

13
선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.

13.5.1.1. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
13.5.1.1.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
13.5.1.1.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

SR-IOV Network Operator는 DHCP 서버 배포를 생성하지 않습니다. Cluster Network Operator자는 최소 DHCP 서버 배포를 생성합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

13.5.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
13.5.1.1.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
13.5.1.1.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
13.5.1.1.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

13.5.2. SR-IOV 추가 네트워크 구성

SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 오브젝트를 생성하면 SR-IOV Operator에서 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

참고

SriovNetwork 오브젝트가 running 상태의 pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. SriovNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: attach1
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: net1
      networkNamespace: project2
      ipam: |-
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "gateway": "10.56.217.1"
        }
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택사항: 이전 단계에서 생성한 SriovNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>

13.5.3. 다음 단계

13.5.4. 추가 리소스

13.6. SR-IOV InfiniBand 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 IB(InfiniBand) 네트워크 연결을 구성할 수 있습니다.

13.6.1. InfiniBand 장치 구성 오브젝트

SriovIBNetwork 오브젝트를 정의하여 IB(InfiniBand) 네트워크 장치를 구성할 수 있습니다.

다음 YAML은 SriovIBNetwork 오브젝트를 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  networkNamespace: <target_namespace> 4
  ipam: |- 5
    {}
  linkState: <link_state> 6
  capabilities: <capabilities> 7
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovIBNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 네트워크 장치에 연결할 수 있습니다.
5
선택사항: YAML 블록 스칼라인 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
6
선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disable, auto입니다.
7
선택사항: 이 네트워크에 구성할 수 있는 기능입니다. IP 주소 지원을 사용하려면 "{ "ips": true }"를 지정하고 IB GUID(Global Unique Identifier) 지원을 사용하려면 "{ "infinibandGUID": true }"를 지정하면 됩니다.

13.6.1.1. ipam CNI 플러그인 구성

ipam CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IPAM(IP 주소 관리)을 제공합니다.

IP 주소 할당에 다음 방법을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
13.6.1.1.1. 고정 IP 주소 할당 구성

다음 JSON은 고정 IP 주소 할당 구성에 대해 설명합니다.

정적 할당 구성

{
  "ipam": {
    "type": "static",
    "addresses": [ 1
      {
        "address": "<address>", 2
        "gateway": "<gateway>" 3
      }
    ],
    "routes": [ 4
      {
        "dst": "<dst>", 5
        "gw": "<gw>" 6
      }
    ],
    "dns": { 7
      "nameservers": ["<nameserver>"], 8
      "domain": "<domain>", 9
      "search": ["<search_domain>"] 10
    }
  }
}

1
가상 인터페이스에 할당할 IP 주소를 설명하는 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.
2
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.
3
송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.
4
Pod 내부에서 구성할 경로를 설명하는 배열입니다.
5
CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 기본 경로의 경우 0.0.0.0/0)입니다.
6
네트워크 트래픽이 라우팅되는 게이트웨이입니다.
7
선택 사항: DNS 구성.
8
DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.
9
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.
10
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.
13.6.1.1.2. 동적 IP 주소 할당 구성

다음 JSON은 DHCP를 사용한 동적 IP 주소 할당 구성을 설명합니다.

DHCP 리스 갱신

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.

shim 네트워크 연결 정의 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  ...
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }

DHCP 할당 구성

{
  "ipam": {
    "type": "dhcp"
  }
}

13.6.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 JSON은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Whereabouts 할당 구성

{
  "ipam": {
    "type": "whereabouts",
    "range": "<range>", 1
    "exclude": ["<exclude_part>, ..."], 2
  }
}

1
CIDR 표기법으로 IP 주소와 범위를 지정합니다. IP 주소는 이 주소 범위 내에서 할당됩니다.
2
선택 사항: CIDR 표기법으로 IP 주소 및 범위 목록을 지정합니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.
13.6.1.1.4. 고정 IP 주소 할당 구성 예

고정 IP 주소 할당을 위해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}
13.6.1.1.5. DHCP를 사용한 동적 IP 주소 할당 구성 예

DHCP에 대해 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "dhcp"
  }
}
13.6.1.1.6. Whereabouts를 사용한 동적 IP 주소 할당 구성 예

Whereabouts를 사용하도록 ipam을 구성할 수 있습니다.

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

13.6.2. SR-IOV 추가 네트워크 구성

SriovIBNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovIBNetwork 오브젝트를 생성하면 SR-IOV Operator에서 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

참고

SriovIBNetwork 오브젝트가 running 상태의 pod에 연결된 경우 이 오브젝트를 수정하거나 삭제하지 마십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. SriovIBNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovIBNetwork
    metadata:
      name: attach1
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: net1
      networkNamespace: project2
      ipam: |-
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "gateway": "10.56.217.1"
        }
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택 사항: 이전 단계에서 생성한 SriovIBNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovIBNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>

13.6.3. 다음 단계

13.6.4. 추가 리소스

13.7. SR-IOV 추가 네트워크에 pod 추가

기존 SR-IOV(Single Root I/O Virtualization) 네트워크에 pod를 추가할 수 있습니다.

13.7.1. 네트워크 연결을 위한 런타임 구성

추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.

Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.

13.7.1.1. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성

다음 JSON은 이더넷 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<name>", 1
    "mac": "<mac_address>", 2
    "ips": ["<cidr_range>"] 3
  }
]
1
SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2
선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "mac": true }도 지정해야 합니다.
3
선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

13.7.1.2. InfiniBand 기반 SR-IOV 연결을 위한 런타임 구성

다음 JSON은 InfiniBand 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<network_attachment>", 1
    "infiniband-guid": "<guid>", 2
    "ips": ["<cidr_range>"] 3
  }
]
1
SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2
SR-IOV 장치의 InfiniBand GUID입니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "infinibandGUID": true }도 지정해야 합니다.
3
SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

13.7.2. 추가 네트워크에 Pod 추가

추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.

참고

네트워크 첨부 파일이 SR-IOV Network Operator에 의해 관리되는 경우 SR-IOV Network Resource Injector는 resource 필드를 Pod 오브젝트에 자동으로 추가합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.
  • SR-IOV Operator를 설치합니다.
  • Pod를 연결할 SriovNetwork 오브젝트 또는 SriovIBNetwork 오브젝트를 생성합니다.

프로세스

  1. Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.

    1. 사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. <network>를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
      1
      둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]
      1
      NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml

    다음 예에서 example-pod Pod는 net1 추가 네트워크에 연결되어 있습니다.

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

13.7.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성

SR-IOV 및 제한된 또는 single-numa-node 토폴로지 관리자 정책으로 동일한 NUMA 노드에서 할당된 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV Pod를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • LatencySensitive 프로필을 활성화하고 CPU 관리자 정책을 static으로 구성합니다.

프로세스

  1. 다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을 <name>-sriov-pod.yaml 파일에 저장합니다. <name>을 이 Pod의 이름으로 바꿉니다.

    다음 예는 SR-IOV Pod 사양을 보여줍니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: sample-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: <name> 1
    spec:
      containers:
      - name: sample-container
        image: <image> 2
        command: ["sleep", "infinity"]
        resources:
          limits:
            memory: "1Gi" 3
            cpu: "2" 4
          requests:
            memory: "1Gi"
            cpu: "2"
    1
    <name>을 SR-IOV 네트워크 첨부 파일 정의 CR의 이름으로 바꿉니다.
    2
    <image>sample-pod 이미지의 이름으로 바꿉니다.
    3
    보장된 QoS로 SR-IOV Pod를 생성하려면 메모리 제한메모리 요청과 동일하게 설정합니다.
    4
    보장된 QoS로 SR-IOV Pod를 생성하려면 cpu 제한CPU 요청과 동일하게 설정합니다.
  2. 다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.

    $ oc create -f <filename> 1
    1
    <filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
  3. sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.

    $ oc describe pod sample-pod
  4. sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
  5. sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

13.7.4. 추가 리소스

13.8. 고성능 멀티 캐스트 사용

SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크에서 멀티 캐스트를 사용할 수 있습니다.

13.8.1. 고성능 멀티 캐스트 구성

OpenShift SDN 기본 CNI(Container Network Interfac) 네트워크 공급자는 기본 네트워크에서 Pod 간 멀티 캐스트를 지원합니다. 이는 고 대역폭 애플리케이션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다. IPTV(Internet Protocol Television) 및 멀티 포인트 화상 회의와 같은 스트리밍 미디어와 같은 애플리케이션의 경우 SR-IOV(Single Root I/O Virtualization) 하드웨어를 사용하여 거의 네이티브와 같은 성능을 제공할 수 있습니다.

멀티 캐스트에 추가 SR-IOV 인터페이스를 사용하는 경우:

  • 멀티 캐스트 패키지는 추가 SR-IOV 인터페이스를 통해 pod에서 보내거나 받아야 합니다.
  • SR-IOV 인터페이스를 연결하는 물리적 네트워크는 멀티 캐스트 라우팅 및 토폴로지를 결정하며 OpenShift Container Platform에서 제어하지 않습니다.

13.8.2. 멀티 캐스트에 SR-IOV 인터페이스 사용

다음 프로시저는 멀티 캐스트용 SR-IOV 인터페이스 예제를 만듭니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  1. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policy-example
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: example
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 4
      nicSelector:
        vendor: "8086"
        pfNames: ['ens803f0']
        rootDevices: ['0000:86:00.0']
  2. SriovNetwork 오브젝트를 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: net-example
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: default
      ipam: | 1
        {
          "type": "host-local", 2
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [
            {"dst": "224.0.0.0/5"},
            {"dst": "232.0.0.0/5"}
          ],
          "gateway": "10.56.217.1"
        }
      resourceName: example
    1 2
    DHCP를 IPAM으로 구성하도록 선택한 경우 DHCP 서버를 통해 224.0.0.0/5232.0.0.0/5 기본 경로를 프로비저닝해야 합니다. 이는 기본 네트워크 공급자가 설정한 정적 멀티 캐스트 경로를 재정의하는 것입니다.
  3. 멀티 캐스트 애플리케이션으로 pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: testpmd
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/networks: nic1
    spec:
      containers:
      - name: example
        image: rhel7:latest
        securityContext:
          capabilities:
            add: ["NET_ADMIN"] 1
        command: [ "sleep", "infinity"]
    1
    NET_ADMIN 기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.

13.9. DPDK 및 RDMA 모드와 함께 VF(가상 기능) 사용

DPDK(Data Plane Development Kit) 및 RDMA(Remote Direct Memory Access)와 함께 SR-IOV(Single Root I/O Virtualization) 네트워크 하드웨어를 사용할 수 있습니다.

중요

DPDK(Data Plane Development Kit)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 고객은 출시 예정된 제품 기능을 Preview를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

13.9.1. Intel NIC와 함께 DPDK 모드에서 가상 기능 사용

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • SR-IOV Network Operator 설치.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 intel-dpdk-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: intel-dpdk-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: intelnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "8086"
        deviceID: "158b"
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: vfio-pci 1
    1
    가상 기능의 드라이버 유형을 vfio-pci로 지정합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-node-policy.yaml
  3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 intel-dpdk-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: intel-dpdk-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: "{}" 1
      vlan: <vlan>
      resourceName: intelnics
    1
    ipam CNI 플러그인에 빈 오브젝트 "{}"을 지정합니다. DPDK는 사용자 공간 모드에서 작동하며 IP 주소가 필요하지 않습니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 SR-IOV 추가 네트워크 구성 섹션을 참조하십시오.

  4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-network.yaml
  5. 다음 Pod 사양을 생성한 다음 YAML을 intel-dpdk-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-app
      namespace: <target_namespace> 1
      annotations:
        k8s.v1.cni.cncf.io/networks: intel-dpdk-network
    spec:
      containers:
      - name: testpmd
        image: <DPDK_image> 2
        securityContext:
         capabilities:
            add: ["IPC_LOCK"] 3
        volumeMounts:
        - mountPath: /dev/hugepages 4
          name: hugepage
        resources:
          limits:
            openshift.io/intelnics: "1" 5
            memory: "1Gi"
            cpu: "4" 6
            hugepages-1Gi: "4Gi" 7
          requests:
            openshift.io/intelnics: "1"
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    1
    SriovNetwork 오브젝트 intel-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.
    2
    애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    애플리케이션이 컨테이너 내에 hugepage 메모리를 할당하는 데 필요한 IPC_LOCK 기능을 지정합니다.
    4
    /dev/hugepages 아래 DPDK pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    선택사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    6
    CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 보장된 Pod를 생성합니다.
    7
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수 default_hugepagesz = 1GB, hugepagesz = 1Ghugepages = 16을 추가하면 시스템 부팅 시 16 * 1Gi hugepage가 할당됩니다.
  6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f intel-dpdk-pod.yaml

13.9.2. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • SR-IOV Network Operator 설치.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-dpdk-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: mlx-dpdk-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: mlxnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "15b3"
        deviceID: "1015" 1
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: netdevice 2
      isRdma: true 3
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다. Mellanox 카드에 허용되는 유일한 값은 1015, 1017입니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다. Mellanox SR-IOV VF는 vfio-pci 장치 유형을 사용하지 않고도 DPDK 모드에서 작동할 수 있습니다. VF 장치는 컨테이너 내부에 커널 네트워크 인터페이스로 나타납니다.
    3
    RDMA 모드를 활성화합니다. 이는 DPDK 모드에서 작동하기 위해 Mellanox 카드에 필요합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-node-policy.yaml
  3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-dpdk-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: mlx-dpdk-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: |- 1
        ...
      vlan: <vlan>
      resourceName: mlxnics
    1
    ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV additional network 섹션을 참조하십시오.

  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-network.yaml
  5. 다음 Pod 사양을 생성한 다음 YAML을 mlx-dpdk-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-app
      namespace: <target_namespace> 1
      annotations:
        k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
    spec:
      containers:
      - name: testpmd
        image: <DPDK_image> 2
        securityContext:
         capabilities:
            add: ["IPC_LOCK","NET_RAW"] 3
        volumeMounts:
        - mountPath: /dev/hugepages 4
          name: hugepage
        resources:
          limits:
            openshift.io/mlxnics: "1" 5
            memory: "1Gi"
            cpu: "4" 6
            hugepages-1Gi: "4Gi" 7
          requests:
            openshift.io/mlxnics: "1"
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    1
    SriovNetwork 오브젝트 mlx-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.
    2
    애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    애플리케이션에서 컨테이너 내부에 hugepage 메모리를 할당하는 데 필요한 IPC_LOCK 기능과 애플리케이션에서 네트워크 인터페이스에 액세스하는 데 필요한 NET_RAW를 지정합니다.
    4
    hugepage 볼륨을 /dev/hugepages 아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    선택사항: DPDK Pod에 할당되는 DPDK 장치 수를 지정합니다. SR-IOV 네트워크 리소스 인젝터에서 명시적으로 지정하지 않은 경우 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    6
    CPU 수를 지정합니다. DPDK Pod에서는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.
    7
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
  6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f mlx-dpdk-pod.yaml

13.9.3. Mellanox NIC와 함께 RDMA 모드에서 가상 기능 사용

OpenShift Container Platform에서 RDMA를 사용할 때 RoCE(RDMA over Converged Ethernet)가 지원되는 유일한 모드입니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • SR-IOV Network Operator 설치.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-rdma-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: mlx-rdma-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: mlxnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "15b3"
        deviceID: "1015" 1
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: netdevice 2
      isRdma: true 3
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다. Mellanox 카드에 허용되는 유일한 값은 1015, 1017입니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다.
    3
    RDMA 모드를 활성화합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-node-policy.yaml
  3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-rdma-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: mlx-rdma-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: |- 1
        ...
      vlan: <vlan>
      resourceName: mlxnics
    1
    ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV additional network 섹션을 참조하십시오.

  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-network.yaml
  5. 다음 Pod 사양을 생성한 다음 YAML을 mlx-rdma-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: rdma-app
      namespace: <target_namespace> 1
      annotations:
        k8s.v1.cni.cncf.io/networks: mlx-rdma-network
    spec:
      containers:
      - name: testpmd
        image: <RDMA_image> 2
        securityContext:
         capabilities:
            add: ["IPC_LOCK"] 3
        volumeMounts:
        - mountPath: /dev/hugepages 4
          name: hugepage
        resources:
          limits:
            memory: "1Gi"
            cpu: "4" 5
            hugepages-1Gi: "4Gi" 6
          requests:
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    1
    SriovNetwork 오브젝트 mlx-rdma-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.
    2
    애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
    3
    애플리케이션이 컨테이너 내부에 거대한 페이지 메모리를 할당하는 데 필요한 IPC_LOCK 기능을 지정합니다.
    4
    hugepage 볼륨을 /dev/hugepages 아래의 RDMA Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.
    6
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
  6. 다음 명령을 실행하여 RDMA Pod를 생성합니다.

    $ oc create -f mlx-rdma-pod.yaml

14장. OpenShift SDN 기본 CNI 네트워크 공급자

14.1. OpenShift SDN 기본 CNI 네트워크 공급자 정보

OpenShift Container Platform에서는 소프트웨어 정의 네트워킹(SDN) 접근법을 사용하여 OpenShift Container Platform 클러스터 전체의 pod 간 통신이 가능한 통합 클러스터 네트워크를 제공합니다. 이 pod 네트워크는 OVS(Open vSwitch)를 사용하여 오버레이 네트워크를 구성하는 OpenShift SDN에 의해 설정 및 유지 관리됩니다.

14.1.1. OpenShift SDN 네트워크 격리 모드

OpenShift SDN은 pod 네트워크 구성을 위한 세 가지 SDN 모드를 제공합니다.

  • 네트워크 정책 모드를 통해 프로젝트 관리자는 NetworkPolicy 개체를 사용하여 자체 격리 정책을 구성할 수 있습니다. 네트워크 정책은 OpenShift Container Platform 4.8의 기본 모드입니다.
  • 다중 테넌트 모드를 사용하면 Pod 및 서비스에 대한 프로젝트 수준 격리를 제공할 수 있습니다. 다른 프로젝트의 Pod는 다른 프로젝트의 Pod 및 Service에서 패킷을 보내거나 받을 수 없습니다. 프로젝트에 대한 격리를 비활성화하여 전체 클러스터의 모든 pod 및 service에 네트워크 트래픽을 보내고 해당 pod 및 service로부터 네트워크 트래픽을 수신할 수 있습니다.
  • 서브넷 모드는 모든 pod가 다른 모든 pod 및 service와 통신할 수 있는 플랫 pod 네트워크를 제공합니다. 네트워크 정책 모드는 서브넷 모드와 동일한 기능을 제공합니다.

14.1.2. 지원되는 기본 CNI 네트워크 공급자 기능 매트릭스

OpenShift Container Platform은 기본 CNI(Container Network Interface) 네트워크 공급자를 위해 OpenShift SDN 및 OVN-Kubernetes의 두 가지 지원 옵션을 제공합니다. 다음 표는 두 네트워크 공급자 모두에 대한 현재 기능 지원을 요약합니다.

표 14.1. 기본 CNI 네트워크 공급자 기능 비교

기능OpenShift SDNOVN-Kubernetes

송신 IP

지원됨

지원됨

송신 방화벽 [1]

지원됨

지원됨

송신 라우터

지원됨

지원됨 [2]

IPsec 암호화

지원되지 않음

지원됨

IPv6

지원되지 않음

지원됨 [3]

Kubernetes 네트워크 정책

부분적으로 지원됨 [4]

지원됨

Kubernetes 네트워크 정책 로그

지원되지 않음

지원됨

멀티 캐스트

지원됨

지원됨

  1. 송신 방화벽은 OpenShift SDN에서 송신 네트워크 정책이라고도 합니다. 이것은 네트워크 정책 송신과 동일하지 않습니다.
  2. OVN-Kubernetes용 송신 라우터는 리디렉션 모드만 지원합니다.
  3. IPv6는 베어 메탈 클러스터에서만 지원됩니다.
  4. OpenShift SDN의 네트워크 정책은 송신 규칙 및 일부 ipBlock 규칙을 지원하지 않습니다.

14.2. 프로젝트의 송신 IP 구성

클러스터 관리자는 OpenShift SDN 기본 컨테이너 네트워크 인터페이스(CNI) 네트워크 공급자를 구성하여 하나 이상의 송신 IP 주소를 프로젝트에 할당할 수 있습니다.

14.2.1. 프로젝트 송신 트래픽에 대한 송신 IP 주소 할당

프로젝트의 송신 IP 주소를 구성하면 지정된 프로젝트의 모든 발신 외부 연결이 동일한 고정 소스 IP 주소를 공유합니다. 외부 리소스는 송신 IP 주소를 기반으로 특정 프로젝트의 트래픽을 인식할 수 있습니다. 프로젝트에 할당된 송신 IP 주소는 특정 목적지로 트래픽을 보내는 데 사용되는 송신 라우터와 다릅니다.

송신 IP 주소는 노드의 기본 네트워크 인터페이스에서 추가 IP 주소로 구현되며 노드의 기본 IP 주소와 동일한 서브넷에 있어야 합니다.

중요

송신 IP 주소는 ifcfg-eth0과 같은 Linux 네트워크 구성 파일에서 구성하지 않아야 합니다.

기본 네트워크 인터페이스에서 추가 IP 주소를 허용하려면 일부 클라우드 또는 VM 솔루션을 사용할 때 추가 구성이 필요할 수 있습니다.

NetNamespace 오브젝트의 egressIPs 매개변수를 설정하여 네임스페이스에 송신 IP 주소를 지정할 수 있습니다. 송신 IP가 프로젝트와 연결된 후 OpenShift SDN을 사용하면 다음 두 가지 방법으로 송신 IP를 호스트에 할당할 수 있습니다.

  • 자동 할당 방식에서는 송신 IP 주소 범위가 노드에 할당됩니다.
  • 수동 할당 방식에서는 하나 이상의 송신 IP 주소 목록이 노드에 할당됩니다.

송신 IP 주소를 요청하는 네임스페이스는 해당 송신 IP 주소를 호스트할 수 있는 노드와 일치되며 송신 IP 주소가 해당 노드에 할당됩니다. egressIPs 매개변수가 NetNamespace 오브젝트에 설정되었지만 IP 주소를 송신하는 노드 호스트가 없는 경우 네임스페이스에서 송신하는 트래픽이 삭제됩니다.

노드의 고가용성은 자동입니다. 송신 IP 주소를 호스팅하는 노드에 도달할 수 없고 해당 송신 IP 주소를 호스트할 수 있는 노드가 있으면 송신 IP 주소가 새 노드로 이동합니다. 연결할 수 없는 노드가 다시 온라인 상태가 되면 송신 IP 주소가 자동으로 이동하여 노드 간에 송신 IP 주소의 균형을 조정합니다.

중요

다음 제한 사항은 OpenShift SDN 클러스터 네트워크 공급자와 함께 송신 IP 주소를 사용하는 경우 적용됩니다.

  • 동일한 노드에서 수동 할당 및 자동 할당 송신 IP 주소를 사용할 수 없습니다.
  • IP 주소 범위에서 송신 IP 주소를 수동으로 할당하는 경우 해당 범위를 자동 IP 할당에 사용할 수 있도록 설정해서는 안 됩니다.
  • OpenShift SDN 송신 IP 주소 구현을 사용하여 여러 네임스페이스에서 송신 IP 주소를 공유할 수 없습니다. 네임스페이스 간에 IP 주소를 공유해야 하는 경우 OVN-Kubernetes 클러스터 네트워크 공급자 송신 IP 주소 구현을 통해 여러 네임스페이스에서 IP 주소를 확장할 수 있습니다.
참고

다중 테넌트 모드에서 OpenShift SDN을 사용하는 경우 연결된 프로젝트에 의해 다른 네임스페이스에 조인된 네임스페이스와 함께 송신 IP 주소를 사용할 수 없습니다. 예를 들어 oc adm pod-network join-projects --to=project1 project2 명령을 실행하여 project1project2를 조인한 경우 두 프로젝트 모두 송신 IP 주소를 사용할 수 없습니다. 자세한 내용은 BZ#1645577를 참조하십시오.

14.2.1.1. 자동 할당된 송신 IP 주소 사용 시 고려사항

송신 IP 주소에 자동 할당 방식을 사용할 때는 다음 사항을 고려해야 합니다.

  • 각 노드의 HostSubnet 리소스의 egressCIDRs 매개변수를 설정하여 노드가 호스트할 수 있는 송신 IP 주소 범위를 나타냅니다. OpenShift Container Platform은 지정한 IP 주소 범위를 기반으로 HostSubnet 리소스의 egressIPs 매개변수를 설정합니다.

네임스페이스의 송신 IP 주소를 호스팅하는 노드에 도달할 수 없는 경우 OpenShift Container Platform은 호환되는 송신 IP 주소 범위를 가진 다른 노드에 송신 IP 주소를 다시 할당합니다. 자동 할당 방식은 추가 IP 주소를 노드와 연결할 수 있는 유연성이 있는 환경에 설치된 클러스터에 가장 적합합니다.

14.2.1.2. 수동으로 할당된 송신 IP 주소 사용 시 고려사항

이 방법은 추가 IP 주소를 노드와 연결하는 데 제한이 있을 수 있는 퍼블릭 클라우드 환경에 설치된 클러스터에 권장됩니다.

송신 IP 주소에 수동 할당 방식을 사용할 때는 다음 사항을 고려해야 합니다.

  • 각 노드의 HostSubnet 리소스의 egressIPs 매개변수를 설정하여 노드가 호스트할 수 있는 IP 주소를 표시합니다.
  • 네임스페이스당 여러 개의 송신 IP 주소가 지원됩니다.

네임스페이스에 여러 송신 IP 주소가 있고 해당 주소가 여러 노드에서 호스팅되는 경우 다음과 같은 추가 고려 사항이 적용됩니다.

  • Pod가 송신 IP 주소를 호스팅하는 노드에 있는 경우 해당 포드는 항상 노드에서 송신 IP 주소를 사용합니다.
  • Pod가 송신 IP 주소를 호스팅하는 노드에 없는 경우 해당 Pod는 송신 IP 주소를 임의로 사용합니다.

14.2.2. 네임스페이스에 자동으로 할당된 송신 IP 주소 구성

OpenShift Container Platform에서는 하나 이상의 노드에서 특정 네임스페이스에 대한 송신 IP 주소를 자동으로 할당할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 다음 JSON을 사용하여 송신 IP 주소로 NetNamespace 오브젝트를 업데이트합니다.

     $ oc patch netnamespace <project_name> --type=merge -p \
      '{
        "egressIPs": [
          "<ip_address>"
        ]
      }'

    다음과 같습니다.

    <project_name>
    프로젝트 이름을 지정합니다.
    <ip_address>
    egressIPs 배열에 대해 하나 이상의 송신 IP 주소를 지정합니다.

    예를 들어 project1을 IP 주소 192.168.1.100에 할당하고 project2를 IP 주소 192.168.1.101에 할당하려면 다음을 수행합니다.

    $ oc patch netnamespace project1 --type=merge -p \
      '{"egressIPs": ["192.168.1.100"]}'
    $ oc patch netnamespace project2 --type=merge -p \
      '{"egressIPs": ["192.168.1.101"]}'
    참고

    OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

  2. 다음 JSON을 사용하여 각 호스트에 대해 egressCIDRs 매개변수를 설정하여 송신 IP 주소를 호스팅할 수 있는 노드를 표시합니다.

    $ oc patch hostsubnet <node_name> --type=merge -p \
      '{
        "egressCIDRs": [
          "<ip_address_range>", "<ip_address_range>"
        ]
      }'

    다음과 같습니다.

    <node_name>
    노드 이름을 지정합니다.
    <ip_address_range>
    CIDR 형식으로 IP 주소 범위를 지정합니다. egressCIDRs 배열에 대해 두 개 이상의 주소 범위를 지정할 수 있습니다.

    예를 들어, node1node2를 192.168.1.0에서 192.168.1.255 범위의 송신 IP 주소를 호스팅하도록 설정하려면 다음을 수행합니다.

    $ oc patch hostsubnet node1 --type=merge -p \
      '{"egressCIDRs": ["192.168.1.0/24"]}'
    $ oc patch hostsubnet node2 --type=merge -p \
      '{"egressCIDRs": ["192.168.1.0/24"]}'

    OpenShift Container Platform은 특정 송신 IP 주소를 균형 잡힌 방식으로 사용 가능한 노드에 자동으로 할당합니다. 이 경우 송신 IP 주소 192.168.1.100을 node1에 할당하고 송신 IP 주소 192.168.1.101을 node2에 할당하거나 그 반대의 경우도 마찬가지입니다.

14.2.3. 네임스페이스에 수동으로 할당된 송신 IP 주소 구성

OpenShift Container Platform에서 하나 이상의 송신 IP 주소를 네임스페이스와 연결할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 원하는 IP 주소로 다음 JSON 오브젝트를 지정하여 NetNamespace 오브젝트를 업데이트합니다.

     $ oc patch netnamespace <project_name> --type=merge -p \
      '{
        "egressIPs": [
          "<ip_address>"
        ]
      }'

    다음과 같습니다.

    <project_name>
    프로젝트 이름을 지정합니다.
    <ip_address>
    egressIPs 배열에 대해 하나 이상의 송신 IP 주소를 지정합니다.

    예를 들어 project1 프로젝트를 IP 주소 192.168.1.100192.168.1.101에 할당하려면 다음을 수행합니다.

    $ oc patch netnamespace project1 --type=merge \
      -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'

    고가용성을 제공하려면 다른 노드에서 egressIPs 값을 두 개 이상의 IP 주소로 설정합니다. 여러 송신 IP 주소가 설정되면 Pod는 모든 송신 IP 주소를 거의 동일하게 사용합니다.

    참고

    OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

  2. 송신 IP를 노드 호스트에 수동으로 할당합니다. 노드 호스트의 HostSubnet 오브젝트에서 egressIPs 매개변수를 설정합니다. 다음 JSON을 사용하여 해당 노드 호스트에 할당할 IP 주소를 포함합니다.

    $ oc patch hostsubnet <node_name> --type=merge -p \
      '{
        "egressIPs": [
          "<ip_address>",
          "<ip_address>"
          ]
      }'

    다음과 같습니다.

    <node_name>
    노드 이름을 지정합니다.
    <ip_address>
    IP 주소를 지정합니다. egressIPs 배열에 대해 두 개 이상의 IP 주소를 지정할 수 있습니다.

    예를 들어 node1에 송신 IP 192.168.1.100, 192.168.1.101192.168.1.102가 있도록 지정하려면 다음을 수행합니다.

    $ oc patch hostsubnet node1 --type=merge -p \
      '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'

    이전 예에서 project1의 모든 송신 트래픽은 지정된 송신 IP를 호스팅하는 노드로 라우팅된 다음 NAT(네트워크 주소 변환)를 통해 해당 IP 주소로 연결됩니다.

14.3. 프로젝트에 대한 송신 방화벽 구성

클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

14.3.1. 프로젝트에서 송신 방화벽이 작동하는 방식

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

EgressNetworkPolicy CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
중요

송신 방화벽을 구성하려면 네트워크 정책 또는 다중 테넌트 모드를 사용하도록 OpenShift SDN을 구성해야 합니다.

네트워크 정책 모드를 사용하는 경우 송신 방화벽은 네임스페이스당 하나의 정책과만 호환되며 글로벌 프로젝트와 같이 네트워크를 공유하는 프로젝트에서는 작동하지 않습니다.

주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

14.3.1.1. 송신 방화벽의 제한

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressNetworkPolicy 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 프로젝트당 최대 1000개의 규칙이 있는 최대 하나의 EgressNetworkPolicy 오브젝트를 정의할 수 있습니다.
  • 기본 프로젝트는 송신 방화벽을 사용할 수 없습니다.
  • 다중 테넌트 모드에서 OpenShift SDN 기본 컨테이너 네트워크 인터페이스(CNI) 네트워크 공급자를 사용하는 경우 다음 제한 사항이 적용됩니다.

    • 글로벌 프로젝트는 송신 방화벽을 사용할 수 없습니다. oc adm pod-network make-projects-global 명령을 사용하여 프로젝트를 글로벌로 만들 수 있습니다.
    • oc adm pod-network join-projects 명령을 사용하여 병합된 프로젝트는 결합된 프로젝트에서 송신 방화벽을 사용할 수 없습니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상되고 모든 외부 네트워크 트래픽이 삭제될 수 있습니다.

14.3.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

14.3.1.3. DNS(Domain Name Server) 확인 작동 방식

송신 방화벽 정책 규칙에서 DNS 이름을 사용하는 경우 도메인 이름의 적절한 확인에는 다음 제한 사항이 적용됩니다.

  • 도메인 이름 업데이트는 TTL(Time To- Live) 기간에 따라 폴링됩니다. 기본적으로 기간은 30초입니다. 송신 방화벽 컨트롤러가 도메인 이름을 위해 로컬 이름 서버를 쿼리할 때 응답에 30초 미만 TTL이 포함된 경우 컨트롤러는 반환된 값으로 기간을 설정합니다. 응답의 TTL이 30분보다 크면 컨트롤러에서 기간을 30분으로 설정합니다. TTL이 30초에서 30분 사이인 경우 컨트롤러는 값을 무시하고 기간을 30초로 설정합니다.
  • Pod는 필요한 경우 동일한 로컬 이름 서버에서 도메인을 확인해야 합니다. 확인하지 않으면 송신 방화벽 컨트롤러와 Pod에 의해 알려진 도메인의 IP 주소가 다를 수 있습니다. 호스트 이름의 IP 주소가 다르면 송신 방화벽이 일관되게 적용되지 않을 수 있습니다.
  • 송신 방화벽 컨트롤러와 Pod는 동일한 로컬 이름 서버를 비동기적으로 폴링하기 때문에 Pod가 송신 컨트롤러보다 먼저 업데이트된 IP 주소를 얻을 수 있으며 이로 인해 경쟁 조건이 발생합니다. 현재 이런 제한으로 인해 EgressNetworkPolicy 오브젝트의 도메인 이름 사용은 IP 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽은 Pod가 DNS 확인을 위해 Pod가 있는 노드의 외부 인터페이스에 항상 액세스할 수 있도록 합니다.

송신 방화벽 정책에서 도메인 이름을 사용하고 로컬 노드의 DNS 서버에서 DNS 확인을 처리하지 않으면 Pod에서 도메인 이름을 사용하는 경우, DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 추가해야 합니다.

14.3.2. EgressNetworkPolicy CR(사용자 정의 리소스) 오브젝트

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 허용 규칙 또는 거부 규칙입니다.

다음 YAML은 EgressNetworkPolicy CR 오브젝트를 설명합니다.

EgressNetworkPolicy 오브젝트

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

1
송신 방화벽 정책의 이름입니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.

14.3.2.1. EgressNetworkPolicy 규칙

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4

1
규칙 유형입니다. 값은 허용 또는 거부여야 합니다.
2
송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 규칙에 대한 cidrSelector 필드 또는 dnsName 필드의 값입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
도메인 이름입니다.

14.3.2.2. EgressNetworkPolicy CR 오브젝트의 예

다음 예는 여러 가지 송신 방화벽 정책 규칙을 정의합니다.

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
송신 방화벽 정책 규칙 오브젝트의 컬렉션입니다.

14.3.3. 송신 방화벽 정책 오브젝트 생성

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressNetworkPolicy 오브젝트가 정의되어 있으면 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OpenShift SDN 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.
  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다.

    $ oc create -f <policy_name>.yaml -n <project>

    다음 예제에서는 project1이라는 프로젝트에 새 EgressNetworkPolicy 오브젝트를 생성합니다.

    $ oc create -f default.yaml -n project1

    출력 예

    egressnetworkpolicy.network.openshift.io/v1 created

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.

14.4. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

14.4.1. EgressNetworkPolicy 오브젝트 보기

클러스터의 EgressNetworkPolicy 오브젝트를 확인할 수 있습니다.

사전 요구 사항

  • OpenShift SDN CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressNetworkPolicy 오브젝트의 이름을 보려면 다음 명령을 입력합니다.

    $ oc get egressnetworkpolicy --all-namespaces
  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다.

    $ oc describe egressnetworkpolicy <policy_name>

    출력 예

    Name:		default
    Namespace:	project1
    Created:	20 minutes ago
    Labels:		<none>
    Annotations:	<none>
    Rule:		Allow to 1.2.3.0/24
    Rule:		Allow to www.example.com
    Rule:		Deny to 0.0.0.0/0

14.5. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

14.5.1. EgressNetworkPolicy 오브젝트 편집

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OpenShift SDN CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressNetworkPolicy 오브젝트 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressnetworkpolicy
  2. 선택 사항: 송신 네트워크 방화벽을 생성할 때 EgressNetworkPolicy 오브젝트 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다.

    $ oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressNetworkPolicy 오브젝트를 바꿉니다. 업데이트된 EgressNetworkPolicy 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다.

    $ oc replace -f <filename>.yaml

14.6. 프로젝트에서 송신 방화벽 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

14.6.1. EgressNetworkPolicy 오브젝트 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OpenShift SDN CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressNetworkPolicy 오브젝트 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressnetworkpolicy
  2. EgressNetworkPolicy 오브젝트를 삭제하려면 다음 명령을 입력합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다.

    $ oc delete -n <project> egressnetworkpolicy <name>

14.7. 송신 라우터 Pod 사용에 대한 고려 사항

14.7.1. 송신 라우터 Pod 정보

OpenShift Container Platform 송신 라우터 포드는 다른 용도로 사용되지 않는 프라이빗 소스 IP 주소에서 지정된 원격 서버로 트래픽을 리디렉션합니다. 송신 라우터 Pod는 특정 IP 주소에서만 액세스할 수 있도록 설정된 서버로 네트워크 트래픽을 보낼 수 있습니다.

참고

송신 라우터 Pod는 모든 발신 연결을 위한 것은 아닙니다. 다수의 송신 라우터 Pod를 생성하는 경우 네트워크 하드웨어 제한을 초과할 수 있습니다. 예를 들어 모든 프로젝트 또는 애플리케이션에 대해 송신 라우터 Pod를 생성하면 소프트웨어에서 MAC 주소 필터링으로 돌아가기 전에 네트워크 인터페이스에서 처리할 수 있는 로컬 MAC 주소 수를 초과할 수 있습니다.

중요

송신 라우터 이미지는 Amazon AWS, Azure Cloud 또는 macvlan 트래픽과의 비호환성으로 인해 계층 2 조작을 지원하지 않는 기타 클라우드 플랫폼과 호환되지 않습니다.

14.7.1.1. 송신 라우터 모드

리디렉션 모드에서는 송신 라우터 포드가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables 규칙을 구성합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 Pod는 대상 IP에 직접 연결하는 대신 송신 라우터에 연결하도록 수정해야 합니다.

HTTP 프록시 모드에서는 송신 라우터 Pod가 포트 8080에서 HTTP 프록시로 실행됩니다. 이 모드는 HTTP 기반 또는 HTTPS 기반 서비스에 연결하는 클라이언트에 대해서만 작동하지만 일반적으로 클라이언트 Pod를 덜 변경해야 작동합니다. 대부분의 프로그램은 환경 변수를 설정하여 HTTP 프록시를 사용하도록 지시할 수 있습니다.

DNS 프록시 모드에서는 송신 라우터 Pod가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 TCP 기반 서비스의 DNS 프록시로 실행됩니다. 예약된 소스 IP 주소를 사용하려면 대상 IP 주소에 직접 연결하는 대신 송신 라우터 Pod에 연결하도록 클라이언트 Pod를 수정해야 합니다. 이렇게 수정하면 외부 대상에서 트래픽을 알려진 소스에서 발생하는 것처럼 처리합니다.

리디렉션 모드는 HTTP 및 HTTPS를 제외한 모든 서비스에서 작동합니다. HTTP 및 HTTPS 서비스의 경우 HTTP 프록시 모드를 사용하십시오. IP 주소 또는 도메인 이름이 있는 TCP 기반 서비스는 DNS 프록시 모드를 사용하십시오.

14.7.1.2. 송신 라우터 Pod 구현

송신 라우터 Pod 설정은 초기화 컨테이너에서 수행합니다. 해당 컨테이너는 macvlan 인터페이스를 구성하고 iptables 규칙을 설정할 수 있도록 권한 있는 컨텍스트에서 실행됩니다. 초기화 컨테이너는 iptables 규칙 설정을 완료한 후 종료됩니다. 그런 다음 송신 라우터 포드는 컨테이너를 실행하여 송신 라우터 트래픽을 처리합니다. 사용되는 이미지는 송신 라우터 모드에 따라 다릅니다.

환경 변수는 송신 라우터 이미지에서 사용하는 주소를 결정합니다. 이미지는 IP 주소로 EGRESS_SOURCE를, 게이트웨이 IP 주소로 EGRESS_GATEWAY를 사용하도록 macvlan 인터페이스를 구성합니다.

NAT(Network Address Translation) 규칙은 TCP 또는 UDP 포트에 있는 Pod의 클러스터 IP 주소에 대한 연결이 EGRESS_DESTINATION 변수에서 지정하는 IP 주소의 동일한 포트로 리디렉션되도록 설정됩니다.

클러스터의 일부 노드만 지정된 소스 IP 주소를 요청하고 지정된 게이트웨이를 사용할 수 있는 경우 허용 가능한 노드를 나타내는 nodeName 또는 nodeSelector를 지정할 수 있습니다.

14.7.1.3. 배포 고려 사항

송신 라우터 Pod는 노드의 기본 네트워크 인터페이스에 추가 IP 주소와 MAC 주소를 추가합니다. 따라서 추가 주소를 허용하도록 하이퍼바이저 또는 클라우드 공급자를 구성해야 할 수 있습니다.

Red Hat OpenStack Platform (RHOSP)

RHOSP에서 OpenShift Container Platform을 배포하는 경우 OpenStack 환경에서 송신 라우터 포드의 IP 및 MAC 주소의 트래픽을 허용해야 합니다. 트래픽을 허용하지 않으면 통신이 실패합니다.

$ openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
RHV(Red Hat Virtualization)
RHV를 사용하는 경우 가상 네트워크 인터페이스 카드(vNIC)에 대해 네트워크 필터 없음을 선택해야 합니다.
VMware vSphere
VMware vSphere를 사용하는 경우 vSphere 표준 스위치 보안을 위한 VMWare 설명서를 참조하십시오. vSphere Web Client에서 호스트 가상 스위치를 선택하여 VMWare vSphere 기본 설정을 보고 변경합니다.

특히 다음이 활성화되어 있는지 확인하십시오.

14.7.1.4. 장애 조치 구성

다운타임을 방지하기 위해 다음 예와 같이 Deployment 리소스를 사용하여 송신 라우터 Pod를 배포할 수 있습니다. 예제 배포를 위해 새 Service 오브젝트를 생성하려면 oc expose deployment/egress-demo-controller 명령을 사용하십시오.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: egress-demo-controller
spec:
  replicas: 1 1
  selector:
    matchLabels:
      name: egress-router
  template:
    metadata:
      name: egress-router
      labels:
        name: egress-router
      annotations:
        pod.network.openshift.io/assign-macvlan: "true"
    spec: 2
      initContainers:
        ...
      containers:
        ...
1
항상 하나의 Pod만 지정된 송신 소스 IP 주소를 사용할 수 있으므로 복제본이 1로 설정되어 있는지 확인합니다. 이는 하나의 라우터 사본만 노드에서 실행됨을 의미합니다.
2
송신 라우터 Pod에 대한 Pod 오브젝트 템플릿을 지정합니다.

14.7.2. 추가 리소스

14.8. 리디렉션 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 트래픽을 지정된 대상 IP 주소로 리디렉션하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

14.8.1. 리디렉션 모드에 대한 송신 라우터 Pod 사양

Pod 오브젝트에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 리디렉션 모드에서 송신 라우터 Pod를 구성하는 데 필요한 필드를 나타냅니다.

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 1
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 2
      value: <egress_router>
    - name: EGRESS_GATEWAY 3
      value: <egress_gateway>
    - name: EGRESS_DESTINATION 4
      value: <egress_destination>
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod
1
egress-router 컨테이너를 시작하기 전에 기본 네트워크 인터페이스에서 macvlan 네트워크 인터페이스를 만들고 해당 인터페이스를 Pod 네트워크 네임스페이스로 이동합니다. "true" 값을 따옴표로 묶어야 합니다. 기본 인터페이스가 아닌 네트워크 인터페이스에서 macvlan 인터페이스를 생성하려면 주석 값을 해당 인터페이스 이름으로 설정합니다. 예를 들면 eth1입니다.
2
송신 라우터 Pod에서 사용하도록 예약된 노드가 있는 물리적 네트워크의 IP 주소입니다. 선택사항: 서브넷 길이를 나타내는 /24 접미사를 포함하여 로컬 서브넷 경로를 적절하게 설정할 수 있습니다. 서브넷 길이를 지정하지 않으면 송신 라우터에서 EGRESS_GATEWAY 변수로 지정된 호스트에만 액세스하고 서브넷의 다른 호스트에는 액세스할 수 없습니다.
3
노드에서 사용하는 기본 게이트웨이와 동일한 값입니다.
4
트래픽을 전달할 외부 서버입니다. 이 예제를 사용하면 Pod에 대한 연결이 소스 IP 주소가 192.168.12.99203.0.113.25로 리디렉션됩니다.

송신 라우터 Pod 사양의 예

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE
      value: 192.168.12.99/24
    - name: EGRESS_GATEWAY
      value: 192.168.12.1
    - name: EGRESS_DESTINATION
      value: |
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift4/ose-pod

14.8.2. 송신 대상 구성 형식

송신 라우터 Pod가 리디렉션 모드로 배포되면 다음 형식 중 하나 이상을 사용하여 리디렉션 규칙을 지정할 수 있습니다.

  • <port> <protocol> <ip_address> - 지정된 <port>로 들어오는 연결을 지정된 <ip_address>의 동일한 포트로 리디렉션해야 합니다. <protocol>tcp 또는 udp입니다.
  • <port> <protocol> <ip_address> <remote_port> - 연결이 <ip_address>의 다른 <remote_port>로 리디렉션된다는 점을 제외하고는 위와 같습니다.
  • <ip_address> - 마지막 줄이 단일 IP 주소인 경우 기타 포트의 모든 연결이 이 IP 주소의 해당 포트로 리디렉션됩니다. 대체 IP 주소가 없으면 기타 포트의 연결이 거부됩니다.

이어지는 예제에서는 몇 가지 규칙이 정의됩니다.

  • 첫 번째 줄에서는 트래픽을 로컬 포트 80에서 203.0.113.25의 포트 80으로 리디렉션합니다.
  • 두 번째 및 세 번째 줄에서는 로컬 포트 80808443203.0.113.26의 원격 포트 80443으로 리디렉션합니다.
  • 마지막 줄은 이전 규칙에 지정되지 않은 모든 포트의 트래픽과 일치합니다.

설정 예

80   tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27

14.8.3. 리디렉션 모드에서 송신 라우터 Pod 배포

리디렉션 모드에서는 송신 라우터 Pod가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables 규칙을 설정합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 Pod는 대상 IP에 직접 연결하는 대신 송신 라우터에 연결하도록 수정해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 송신 라우터 Pod를 생성합니다.
  2. 다른 Pod에서 송신 라우터 Pod의 IP 주소를 찾을 수 있도록 하려면 다음 예제와 같이 송신 라우터 Pod를 가리키는 서비스를 만듭니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: http
        port: 80
      - name: https
        port: 443
      type: ClusterIP
      selector:
        name: egress-1

    이제 Pod에서 이 서비스에 연결할 수 있습니다. 이러한 연결은 예약된 송신 IP 주소를 사용하여 외부 서버의 해당 포트로 리디렉션됩니다.

14.8.4. 추가 리소스

14.9. HTTP 프록시 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 지정된 HTTP 및 HTTPS 기반 서비스로 트래픽을 프록시하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

14.9.1. HTTP 모드에 대한 송신 라우터 Pod 사양

Pod 오브젝트에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 HTTP 모드에서 송신 라우터 Pod를 구성하는 데 필요한 필드를 나타냅니다.

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 1
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 2
      value: <egress-router>
    - name: EGRESS_GATEWAY 3
      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: http-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-http-proxy
    env:
    - name: EGRESS_HTTP_PROXY_DESTINATION 4
      value: |-
        ...
    ...
1
egress-router 컨테이너를 시작하기 전에 기본 네트워크 인터페이스에서 macvlan 네트워크 인터페이스를 만들고 해당 인터페이스를 Pod 네트워크 네임스페이스로 이동합니다. "true" 값을 따옴표로 묶어야 합니다. 기본 인터페이스가 아닌 네트워크 인터페이스에서 macvlan 인터페이스를 생성하려면 주석 값을 해당 인터페이스 이름으로 설정합니다. 예를 들면 eth1입니다.
2
송신 라우터 Pod에서 사용하도록 예약된 노드가 있는 물리적 네트워크의 IP 주소입니다. 선택사항: 서브넷 길이를 나타내는 /24 접미사를 포함하여 로컬 서브넷 경로를 적절하게 설정할 수 있습니다. 서브넷 길이를 지정하지 않으면 송신 라우터에서 EGRESS_GATEWAY 변수로 지정된 호스트에만 액세스하고 서브넷의 다른 호스트에는 액세스할 수 없습니다.
3
노드에서 사용하는 기본 게이트웨이와 동일한 값입니다.
4
프록시 구성 방법을 지정하는 문자열 또는 여러 줄로 된 YAML 문자열입니다. 이 문자열은 init 컨테이너의 다른 환경 변수가 아닌 HTTP 프록시 컨테이너의 환경 변수로 지정됩니다.

14.9.2. 송신 대상 구성 형식

송신 라우터 Pod가 HTTP 프록시 모드로 배포되면 다음 형식 중 하나 이상을 사용하여 리디렉션 규칙을 지정할 수 있습니다. 구성의 각 줄은 허용 또는 거부할 하나의 연결 그룹을 지정합니다.

  • IP 주소는 192.168.1.1과 같은 해당 IP 주소에 대한 연결을 허용합니다.
  • CIDR 범위는 192.168.1.0/24와 같은 해당 CIDR 범위에 대한 연결을 허용합니다.
  • 호스트 이름은 www.example.com과 같은 해당 호스트에 대한 프록시 사용을 허용합니다.
  • *.으로 시작하는 도메인 이름은 해당 도메인 및 *.example.com과 같은 모든 하위 도메인에 대한 프록시 사용을 허용합니다.
  • 위의 일치 식 뒤에 !가 있으면 연결이 거부됩니다.
  • 마지막 줄이 *이면 명시적으로 거부되지 않은 모든 것이 허용됩니다. 또는 허용되지 않은 모든 것이 거부됩니다.

*를 사용하여 모든 원격 대상에 대한 연결을 허용할 수도 있습니다.

설정 예

!*.example.com
!192.168.1.0/24
192.168.2.1
*

14.9.3. HTTP 프록시 모드에서 송신 라우터 Pod 배포

HTTP 프록시 모드에서는 송신 라우터 Pod가 포트 8080에서 HTTP 프록시로 실행됩니다. 이 모드는 HTTP 기반 또는 HTTPS 기반 서비스에 연결하는 클라이언트에 대해서만 작동하지만 일반적으로 클라이언트 Pod를 덜 변경해야 작동합니다. 대부분의 프로그램은 환경 변수를 설정하여 HTTP 프록시를 사용하도록 지시할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 송신 라우터 Pod를 생성합니다.
  2. 다른 Pod에서 송신 라우터 Pod의 IP 주소를 찾을 수 있도록 하려면 다음 예제와 같이 송신 라우터 Pod를 가리키는 서비스를 만듭니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: http-proxy
        port: 8080 1
      type: ClusterIP
      selector:
        name: egress-1
    1
    http 포트가 8080으로 설정되어 있는지 확인하십시오.
  3. HTTP 프록시를 사용하도록 클라이언트 Pod(송신 프록시 Pod가 아님)를 구성하려면 http_proxy 또는 https_proxy 변수를 설정합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: app-1
      labels:
        name: app-1
    spec:
      containers:
        env:
        - name: http_proxy
          value: http://egress-1:8080/ 1
        - name: https_proxy
          value: http://egress-1:8080/
        ...
    1
    이전 단계에서 생성한 서비스입니다.
    참고

    모든 설정에 http_proxyhttps_proxy 환경 변수를 사용할 필요는 없습니다. 위 방법으로 유효한 설정이 생성되지 않으면 Pod에서 실행 중인 툴이나 소프트웨어에 대한 설명서를 참조하십시오.

14.9.4. 추가 리소스

14.10. DNS 프록시 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 지정된 DNS 이름 및 IP 주소로 트래픽을 프록시하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

14.10.1. DNS 모드에 대한 송신 라우터 Pod 사양

Pod 오브젝트에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 DNS 모드에서 송신 라우터 Pod를 구성하는 데 필요한 필드를 나타냅니다.

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true" 1
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift4/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 2
      value: <egress-router>
    - name: EGRESS_GATEWAY 3
      value: <egress-gateway>
    - name: EGRESS_ROUTER_MODE
      value: dns-proxy
  containers:
  - name: egress-router-pod
    image: registry.redhat.io/openshift4/ose-egress-dns-proxy
    securityContext:
      privileged: true
    env:
    - name: EGRESS_DNS_PROXY_DESTINATION 4
      value: |-
        ...
    - name: EGRESS_DNS_PROXY_DEBUG 5
      value: "1"
    ...
1
egress-router 컨테이너를 시작하기 전에 기본 네트워크 인터페이스에서 macvlan 네트워크 인터페이스를 만들고 해당 인터페이스를 Pod 네트워크 네임스페이스로 이동합니다. "true" 값을 따옴표로 묶어야 합니다. 기본 인터페이스가 아닌 네트워크 인터페이스에서 macvlan 인터페이스를 생성하려면 주석 값을 해당 인터페이스 이름으로 설정합니다. 예를 들면 eth1입니다.
2
송신 라우터 Pod에서 사용하도록 예약된 노드가 있는 물리적 네트워크의 IP 주소입니다. 선택사항: 서브넷 길이를 나타내는 /24 접미사를 포함하여 로컬 서브넷 경로를 적절하게 설정할 수 있습니다. 서브넷 길이를 지정하지 않으면 송신 라우터에서 EGRESS_GATEWAY 변수로 지정된 호스트에만 액세스하고 서브넷의 다른 호스트에는 액세스할 수 없습니다.
3
노드에서 사용하는 기본 게이트웨이와 동일한 값입니다.
4
하나 이상의 프록시 대상 목록을 지정합니다.
5
선택사항: DNS 프록시 로그 출력을 stdout로 출력하도록 지정합니다.

14.10.2. 송신 대상 구성 형식

라우터가 DNS 프록시 모드에서 배포되면 포트 및 대상 매핑 목록을 지정합니다. 대상은 IP 주소 또는 DNS 이름일 수 있습니다.

송신 라우터 Pod는 포트 및 대상 매핑을 지정하기 위해 다음 형식을 지원합니다.

포트 및 원격 주소
두 가지 필드 형식인 <port> <remote_address>를 사용하여 소스 포트와 대상 호스트를 지정할 수 있습니다.

호스트는 IP 주소 또는 DNS 이름일 수 있습니다. DNS 이름을 제공하면 런타임에 DNS를 확인합니다. 지정된 호스트의 경우 프록시는 대상 호스트 IP 주소에 연결할 때 대상 호스트의 지정된 소스 포트에 연결합니다.

포트 및 원격 주소 쌍의 예

80 172.16.12.11
100 example.com

포트, 원격 주소, 원격 포트
세 가지 필드 형식인 <port> <remote_address> <remote_port>를 사용하여 소스 포트, 대상 호스트, 대상 포트를 지정할 수 있습니다.

세 가지 필드 형식은 대상 포트가 소스 포트와 다를 수 있다는 점을 제외하고 두 가지 필드 버전과 동일하게 작동합니다.

포트, 원격 주소, 원격 포트의 예

8080 192.168.60.252 80
8443 web.example.com 443

14.10.3. DNS 프록시 모드에서 송신 라우터 Pod 배포

DNS 프록시 모드에서는 송신 라우터 Pod가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 TCP 기반 서비스의 DNS 프록시 역할을 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 송신 라우터 Pod를 생성합니다.
  2. 송신 라우터 Pod에 대한 서비스를 생성합니다.

    1. 다음 YAML 정의가 포함된 egress-router-service.yaml 파일을 생성합니다. spec.portsEGRESS_DNS_PROXY_DESTINATION 환경 변수에 대해 이전에 정의한 포트 목록으로 설정합니다.

      apiVersion: v1
      kind: Service
      metadata:
        name: egress-dns-svc
      spec:
        ports:
          ...
        type: ClusterIP
        selector:
          name: egress-dns-proxy

      예를 들면 다음과 같습니다.

      apiVersion: v1
      kind: Service
      metadata:
        name: egress-dns-svc
      spec:
        ports:
        - name: con1
          protocol: TCP
          port: 80
          targetPort: 80
        - name: con2
          protocol: TCP
          port: 100
          targetPort: 100
        type: ClusterIP
        selector:
          name: egress-dns-proxy
    2. 서비스를 생성하려면 다음 명령을 입력합니다.

      $ oc create -f egress-router-service.yaml

      이제 Pod에서 이 서비스에 연결할 수 있습니다. 이러한 연결은 예약된 송신 IP 주소를 사용하여 외부 서버의 해당 포트에 프록시로 연결됩니다.

14.10.4. 추가 리소스

14.11. 구성 맵에서 송신 라우터 Pod 대상 목록 구성

클러스터 관리자는 송신 라우터 Pod에 대한 대상 매핑을 지정하는 ConfigMap 오브젝트를 정의할 수 있습니다. 구체적인 구성 형식은 송신 라우터 Pod 유형에 따라 다릅니다. 형식에 대한 자세한 내용은 해당 송신 라우터 Pod에 대한 설명서를 참조하십시오.

14.11.1. 구성 맵을 사용하여 송신 라우터 대상 매핑 구성

대규모 또는 자주 변경되는 대상 매핑 집합의 경우 구성 맵을 사용하여 목록을 외부에서 관리할 수 있습니다. 이 접근 방식의 장점은 구성 맵을 편집할 수 있는 권한을 cluster-admin 권한이 없는 사용자에게 위임할 수 있다는 점입니다. 송신 라우터 Pod에는 권한 있는 컨테이너가 필요하기 때문에 cluster-admin 권한이 없는 사용자는 Pod 정의를 직접 편집할 수 없습니다.

참고

송신 라우터 Pod는 구성 맵이 변경될 때 자동으로 업데이트되지 않습니다. 업데이트하려면 송신 라우터 Pod를 재시작해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 예와 같이 송신 라우터 Pod에 대한 매핑 데이터가 포함된 파일을 만듭니다.

    # Egress routes for Project "Test", version 3
    
    80   tcp 203.0.113.25
    
    8080 tcp 203.0.113.26 80
    8443 tcp 203.0.113.26 443
    
    # Fallback
    203.0.113.27

    이 파일에 빈 줄과 주석을 넣을 수 있습니다.

  2. 파일에서 ConfigMap 오브젝트를 만듭니다.

    $ oc delete configmap egress-routes --ignore-not-found
    $ oc create configmap egress-routes \
      --from-file=destination=my-egress-destination.txt

    이전 명령에서 egress-routes 값은 생성할 ConfigMap 오브젝트의 이름이고, my-egress-destination.txt는 데이터를 읽을 파일의 이름입니다.

    작은 정보

    또는 다음 YAML을 적용하여 구성 맵을 생성할 수 있습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: egress-routes
    data:
      destination: |
        # Egress routes for Project "Test", version 3
    
        80   tcp 203.0.113.25
    
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
    
        # Fallback
        203.0.113.27
  3. 송신 라우터 Pod 정의를 생성하고 환경 스탠자의 EGRESS_DESTINATION 필드에 configMapKeyRef 스탠자를 지정합니다.

    ...
    env:
    - name: EGRESS_DESTINATION
      valueFrom:
        configMapKeyRef:
          name: egress-routes
          key: destination
    ...

14.11.2. 추가 리소스

14.12. 프로젝트에 멀티 캐스트 사용

14.12.1. 멀티 캐스트 정보

IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.

중요

현재 멀티 캐스트는 고 대역폭 솔루션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다.

OpenShift Container Platform Pod 간 멀티 캐스트 트래픽은 기본적으로 비활성화되어 있습니다. OpenShift SDN 기본 CNI(Container Network Interface) 네트워크 공급자를 사용하는 경우 프로젝트별로 멀티 캐스트를 활성화할 수 있습니다.

네트워크 정책 격리 모드에서 OpenShift SDN 네트워크 플러그인을 사용하는 경우:

  • Pod에서 전송한 멀티 캐스트 패킷은 NetworkPolicy 오브젝트에 관계없이 프로젝트의 다른 모든 Pod로 전달됩니다. Pod는 유니 캐스트를 통해 통신할 수 없는 경우에도 멀티 캐스트를 통해 통신할 수 있습니다.
  • 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 프로젝트 간에 통신을 허용하는 NetworkPolicy 오브젝트가 있더라도 다른 프로젝트의 Pod로 전달되지 않습니다.

다중 테넌트 격리 모드에서 OpenShift SDN 네트워크 플러그인을 사용하는 경우:

  • Pod에서 전송한 멀티 캐스트 패킷은 프로젝트의 다른 모든 Pod로 전달됩니다.
  • 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 각 프로젝트가 함께 결합되고 각 참여 프로젝트에서 멀티 캐스트가 활성화된 경우에만 다른 프로젝트의 Pod로 전달됩니다.

14.12.2. Pod 간 멀티 캐스트 활성화

프로젝트의 Pod 간 멀티 캐스트를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로 <namespace>를 바꿉니다.

    $ oc annotate netnamespace <namespace> \
        netnamespace.network.openshift.io/multicast-enabled=true

검증

프로젝트에 멀티 캐스트가 활성화되어 있는지 확인하려면 다음 절차를 완료합니다.

  1. 멀티 캐스트를 활성화한 프로젝트로 현재 프로젝트를 변경합니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc project <project>
  2. 멀티 캐스트 수신자 역할을 할 pod를 만듭니다.

    $ cat <<EOF| oc create -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: mlistener
      labels:
        app: multicast-verify
    spec:
      containers:
        - name: mlistener
          image: registry.access.redhat.com/ubi8
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat hostname && sleep inf"]
          ports:
            - containerPort: 30102
              name: mlistener
              protocol: UDP
    EOF
  3. 멀티 캐스트 발신자 역할을 할 pod를 만듭니다.

    $ cat <<EOF| oc create -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: msender
      labels:
        app: multicast-verify
    spec:
      containers:
        - name: msender
          image: registry.access.redhat.com/ubi8
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat && sleep inf"]
    EOF
  4. 멀티 캐스트 리스너를 시작합니다.

    1. Pod의 IP 주소를 가져옵니다.

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')
    2. 멀티 캐스트 리스너를 시작하려면 새 터미널 창 또는 탭에서 다음 명령을 입력합니다.

      $ oc exec mlistener -i -t -- \
          socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname
  5. 멀티 캐스트 송신기를 시작합니다.

    1. Pod 네트워크 IP 주소 범위를 가져옵니다.

      $ CIDR=$(oc get Network.config.openshift.io cluster \
          -o jsonpath='{.status.clusterNetwork[0].cidr}')
    2. 멀티 캐스트 메시지를 보내려면 다음 명령을 입력합니다.

      $ oc exec msender -i -t -- \
          /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

      멀티 캐스트가 작동하는 경우 이전 명령은 다음 출력을 반환합니다.

      mlistener

14.13. 프로젝트에 대한 멀티 캐스트 비활성화

14.13.1. Pod 간 멀티 캐스트 비활성화

프로젝트의 Pod 간 멀티 캐스트를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 다음 명령을 실행하여 멀티 캐스트를 비활성화합니다.

    $ oc annotate netnamespace <namespace> \ 1
        netnamespace.network.openshift.io/multicast-enabled-
    1
    멀티 캐스트를 비활성화하려는 프로젝트의 namespace입니다.

14.14. OpenShift SDN을 사용하여 네트워크 격리 구성

OpenShift SDN CNI 플러그인에 멀티 테넌트 격리 모드를 사용하도록 클러스터를 구성하면 기본적으로 각 프로젝트가 격리됩니다. 다중 테넌트 격리 모드에서 다른 프로젝트의 pod 또는 Service 간에 네트워크 트래픽이 허용되지 않습니다.

두 가지 방법으로 프로젝트의 다중 테넌트 격리 동작을 변경할 수 있습니다.

  • 하나 이상의 프로젝트에 참여하여 다른 프로젝트의 pod와 service 간에 네트워크 트래픽을 허용할 수 있습니다.
  • 프로젝트의 네트워크 격리를 비활성화할 수 있습니다. 다른 모든 프로젝트에서 pod 및 service의 네트워크 트래픽을 수락하여 전역에서 액세스할 수 있습니다. 전역에서 액세스 가능한 프로젝트는 다른 모든 프로젝트의 pod 및 service에 액세스할 수 있습니다.

14.14.1. 사전 요구 사항

  • 다중 테넌트 격리 모드에서 OpenShift SDN CNI(Container Network Interface) 플러그인을 사용하도록 구성된 클러스터가 있어야 합니다.

14.14.2. 프로젝트 참여

두 개 이상의 프로젝트에 참여하여 다른 프로젝트의 Pod와 Service 간 네트워크 트래픽을 허용할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음 명령을 사용하여 기존 프로젝트 네트워크에 프로젝트를 결합합니다.

    $ oc adm pod-network join-projects --to=<project1> <project2> <project3>

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

  2. 선택 사항: 다음 명령을 실행하여 결합한 Pod 네트워크를 봅니다.

    $ oc get netnamespaces

    동일한 Pod 네트워크에 있는 프로젝트는 NETID 열에서 동일한 네트워크 ID를 보유합니다.

14.14.3. 프로젝트 격리

다른 프로젝트의 Pod 및 Service가 해당 Pod 및 Service에 액세스할 수 없도록 프로젝트를 격리할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 클러스터에서 프로젝트를 격리하려면 다음 명령을 실행합니다.

    $ oc adm pod-network isolate-projects <project1> <project2>

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

14.14.4. 프로젝트의 네트워크 격리 비활성화

프로젝트의 네트워크 격리를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 프로젝트에 대해 다음 명령을 실행합니다.

    $ oc adm pod-network make-projects-global <project1> <project2>

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

14.15. kube-proxy 설정

Kubernetes 네트워크 프록시(kube-proxy)는 각 노드에서 실행되며 CNO(Cluster Network Operator)에 의해 관리됩니다. kube-proxy는 서비스와 관련된 끝점에 대한 연결을 전달하기 위한 네트워크 규칙을 유지 관리합니다.

14.15.1. iptables 규칙 동기화 정보

동기화 기간은 Kubernetes 네트워크 프록시(kube-proxy)가 노드에서 iptables 규칙을 동기화하는 빈도를 결정합니다.

다음 이벤트 중 하나가 발생하면 동기화가 시작됩니다.

  • 서비스 또는 끝점과 같은 이벤트가 클러스터에 추가되거나 클러스터에서 제거됩니다.
  • 마지막 동기화 이후 시간이 kube-proxy에 대해 정의된 동기화 기간을 초과합니다.

14.15.2. kube-proxy 구성 매개변수

다음 kubeProxyConfig 매개변수를 수정할 수 있습니다.

중요

OpenShift Container Platform 4.3 이상에서는 성능이 개선되어 더 이상 iptablesSyncPeriod 매개변수를 조정할 필요가 없습니다.

표 14.2. 매개변수

매개변수설명기본

iptablesSyncPeriod

iptables 규칙의 새로 고침 간격으로,

30s 또는 2m과 같은 시간 간격입니다. 유효 접미사로 s, m, h가 있으며, 자세한 설명은 Go time 패키지 문서를 참조하십시오.

30s

proxyArguments.iptables-min-sync-period

iptables 규칙을 새로 고치기 전 최소 기간입니다. 이 매개변수를 이용하면 새로 고침 간격이 너무 짧지 않도록 조정할 수 있습니다. 기본적으로 새로 고침은 iptables 규칙에 영향을 주는 변경이 발생하는 즉시 시작됩니다.

30s 또는 2m과 같은 시간 간격입니다. 유효 접미사로 s, mh가 있으며, 자세한 설명은 Go time 패키지를 참조하십시오

0s

14.15.3. kube-proxy 구성 수정

클러스터의 Kubernetes 네트워크 프록시 구성을 수정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 사용하여 실행 중인 클러스터에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 Network.operator.openshift.io CR(사용자 정의 리소스)을 편집합니다.

    $ oc edit network.operator.openshift.io cluster
  2. 다음 예제 CR과 같이 kube-proxy 구성을 변경하여 CR의 kubeProxyConfig 매개변수를 수정합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      kubeProxyConfig:
        iptablesSyncPeriod: 30s
        proxyArguments:
          iptables-min-sync-period: ["30s"]
  3. 파일을 저장하고 텍스트 편집기를 종료합니다.

    파일을 저장하고 편집기를 종료하면 oc 명령에 의해 구문의 유효성이 검사됩니다. 수정 사항에 구문 오류가 포함되어 있으면 편집기가 파일을 열고 오류 메시지를 표시합니다.

  4. 다음 명령을 입력하여 구성 업데이트를 확인하십시오.

    $ oc get networks.operator.openshift.io -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: Network
      metadata:
        name: cluster
      spec:
        clusterNetwork:
        - cidr: 10.128.0.0/14
          hostPrefix: 23
        defaultNetwork:
          type: OpenShiftSDN
        kubeProxyConfig:
          iptablesSyncPeriod: 30s
          proxyArguments:
            iptables-min-sync-period:
            - 30s
        serviceNetwork:
        - 172.30.0.0/16
      status: {}
    kind: List

  5. 선택 사항: Cluster Network Operator가 구성 변경을 승인했는지 확인하려면 다음 명령을 입력합니다.

    $ oc get clusteroperator network

    출력 예

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.1.0-0.9   True        False         False      1m

    구성 업데이트가 성공적으로 적용되면 AVAILABLE 필드는 True입니다.

15장. OVN-Kubernetes 기본 CNI 네트워크 공급자

15.1. OVN-Kubernetes 기본 CNI(Container Network Interface) 네트워크 공급자 정보

OpenShift Container Platform 클러스터는 pod 및 service 네트워크에 가상화된 네트워크를 사용합니다. OVN-Kubernetes CNI(Container Network Interface) 플러그인은 기본 클러스터 네트워크의 네트워크 공급자입니다. OVN-Kubernetes는 OVN(Open Virtual Network)을 기반으로 하며 오버레이 기반 네트워킹 구현을 제공합니다. OVN-Kubernetes 네트워크 공급자를 사용하는 클러스터도 각 노드에서 OVS(Open vSwitch)를 실행합니다. OVN은 각 노드에서 선언된 네트워크 구성을 구현하도록 OVS를 구성합니다.

15.1.1. OVN-Kubernetes 기능

OVN-Kubernetes 기본 CNI(Container Network Interface)는 다음 기능을 구현합니다.

  • OVN(Open Virtual Network)을 사용하여 네트워크 트래픽 흐름을 관리합니다. OVN은 커뮤니티에서 개발한 벤더와 무관한 네트워크 가상화 솔루션입니다.
  • 수신 및 송신 규칙을 포함한 Kubernetes 네트워크 정책 지원을 구현합니다.
  • VXLAN 대신 Geneve(Generic Network Virtualization Encapsulation) 프로토콜을 사용하여 노드 간에 오버레이 네트워크를 만듭니다.

15.1.2. 지원되는 기본 CNI 네트워크 공급자 기능 매트릭스

OpenShift Container Platform은 기본 CNI(Container Network Interface) 네트워크 공급자를 위해 OpenShift SDN 및 OVN-Kubernetes의 두 가지 지원 옵션을 제공합니다. 다음 표는 두 네트워크 공급자 모두에 대한 현재 기능 지원을 요약합니다.

표 15.1. 기본 CNI 네트워크 공급자 기능 비교

기능OVN-KubernetesOpenShift SDN

송신 IP

지원됨

지원됨

송신 방화벽 [1]

지원됨

지원됨

송신 라우터

지원됨 [2]

지원됨

IPsec 암호화

지원됨

지원되지 않음

IPv6

지원됨 [3]

지원되지 않음

Kubernetes 네트워크 정책

지원됨

부분적으로 지원됨 [4]

Kubernetes 네트워크 정책 로그

지원됨

지원되지 않음

멀티 캐스트

지원됨

지원됨

  1. 송신 방화벽은 OpenShift SDN에서 송신 네트워크 정책이라고도 합니다. 이것은 네트워크 정책 송신과 동일하지 않습니다.
  2. OVN-Kubernetes용 송신 라우터는 리디렉션 모드만 지원합니다.
  3. IPv6는 베어 메탈 클러스터에서만 지원됩니다.
  4. OpenShift SDN의 네트워크 정책은 송신 규칙 및 일부 ipBlock 규칙을 지원하지 않습니다.

15.2. OpenShift SDN 클러스터 네트워크 공급자에서 마이그레이션

클러스터 관리자는 OpenShift SDN 기본 CNI 네트워크 공급자에서 OVN-Kubernetes 기본 CNI (Container Network Interface) 네트워크 공급자로 마이그레이션 할 수 있습니다.

OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 네트워크 공급자 정보를 읽어보십시오.

15.2.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션

OVN-Kubernetes CNI(Container Network Interface) 클러스터 네트워크 공급자로 마이그레이션하는 것은 클러스터에 연결할 수 없는 몇 가지 중단 시간을 포함하는 수동 프로세스입니다. 롤백 절차가 제공되지만 마이그레이션은 단방향 프로세스로 설정됩니다.

15.2.1.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션에 대한 고려 사항

노드에 할당된 서브넷과 개별 포드에 할당된 IP 주소는 마이그레이션 중에 유지되지 않습니다.

OVN-Kubernetes 네트워크 공급자는 OpenShift SDN 네트워크 공급자에 있는 많은 기능을 구현하지만 구성은 동일하지 않습니다.

  • 클러스터에서 다음 OpenShift SDN 기능을 사용하는 경우 OVN-Kubernetes에서 동일한 기능을 수동으로 구성해야 합니다.

    • 네임스페이스 격리
    • 송신 IP 주소
    • 송신 네트워크 정책
    • 송신 라우터 포드
    • 멀티 캐스트
  • 클러스터에서 100.64.0.0/16 IP 주소 범위의 모든 부분을 사용하는 경우 이 IP 주소 범위를 내부적으로 사용하므로 OVN-Kubernetes로 마이그레이션할 수 없습니다.

다음 섹션에서는 OVN-Kubernetes와 OpenShift SDN의 앞서 언급한 기능 간 구성의 차이점을 설명합니다.

네임스페이스 격리

OVN-Kubernetes는 네트워크 정책 격리 모드만 지원합니다.

중요

클러스터에서 다중 테넌트 또는 서브넷 격리 모드로 구성된 OpenShift SDN을 사용하는 경우 OVN-Kubernetes 네트워크 공급자로 마이그레이션할 수 없습니다.

송신 IP 주소

OVN-Kubernetes와 OpenShift SDN 간의 송신 IP 주소를 구성하는 데 있어서 차이점은 다음 표에 설명되어 있습니다.

표 15.2. 송신 IP 주소 구성의 차이점

OVN-KubernetesOpenShift SDN
  • EgressIPs 오브젝트 생성
  • Node 오브젝트에 주석 추가
  • NetNamespace 오브젝트 패치
  • HostSubnet 오브젝트 패치

OVN-Kubernetes에서 송신 IP 주소를 사용하는 방법에 대한 자세한 내용은 " 송신 IP 주소 구성"을 참조하십시오.

송신 네트워크 정책

OVN-Kubernetes와 OpenShift SDN 간의 송신 방화벽이라고도 하는 송신 네트워크 정책 구성의 차이점은 다음 표에 설명되어 있습니다.

표 15.3. 송신 네트워크 정책 구성의 차이점

OVN-KubernetesOpenShift SDN
  • 네임스페이스에 EgressFirewall 오브젝트 생성
  • 네임스페이스에서 EgressNetworkPolicy 오브젝트 생성

OVN-Kubernetes에서 송신 방화벽을 사용하는 방법에 대한 자세한 내용은 "프로젝트에 대한 송신 방화벽 구성"을 참조하십시오.

송신 라우터 Pod

OVN-Kubernetes는 리디렉션 모드에서 송신 라우터 Pod를 지원합니다. OVN-Kubernetes는 HTTP 프록시 모드 또는 DNS 프록시 모드에서 송신 라우터 Pod를 지원하지 않습니다.

Cluster Network Operator를 사용하여 송신 라우터를 배포할 때 송신 라우터 Pod를 호스팅하는 데 사용되는 노드를 제어하기 위해 노드 선택기를 지정할 수 없습니다.

멀티 캐스트

OVN-Kubernetes 및 OpenShift SDN에서 멀티 캐스트 트래픽 활성화의 차이점은 다음 표에 설명되어 있습니다.

표 15.4. 멀티 캐스트 구성의 차이점

OVN-KubernetesOpenShift SDN
  • Namespace 오브젝트에 주석 추가
  • NetNamespace 오브젝트에 주석 추가

OVN-Kubernetes에서 멀티 캐스트를 사용하는 방법에 대한 자세한 내용은 "프로젝션에 멀티 캐스트 사용"을 참조하십시오.

네트워크 정책

OVN-Kubernetes는 networking.k8s.io/v1 API 그룹에서 Kubernetes NetworkPolicy API를 완전히 지원합니다. OpenShift SDN에서 마이그레이션할 때 네트워크 정책에 변경 사항이 필요하지 않습니다.

15.2.1.2. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

표 15.5. OpenShift SDN에서 OVN-Kubernetes로 마이그레이션

사용자 시작 단계마이그레이션 활동

cluster라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 마이그레이션 필드를 OVNKubernetes로 설정합니다. 값으로 설정하기 전에 마이그레이션 필드가 null인지 확인합니다.

CNO(Cluster Network Operator)
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.
MCO(Machine Config Operator)
OVN-Kubernetes에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하여 기본적으로 클러스터 크기로 마이그레이션을 늘리는 데 걸리는 총 시간을 생성합니다.

Network.config.openshift.io CR의 networkType 필드를 업데이트합니다.

CNO

다음 작업을 수행합니다.

  • OpenShift SDN 컨트롤 플레인 포드를 삭제합니다.
  • OVN-Kubernetes 컨트롤 플레인 Pod를 배포합니다.
  • 새 클러스터 네트워크 공급자를 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

클러스터
노드가 재부팅되면 클러스터에서 OVN-Kubernetes 클러스터 네트워크의 Pod에 IP 주소를 할당합니다.

OpenShift SDN으로의 롤백이 필요한 경우 다음 테이블에서 프로세스를 설명합니다.

표 15.6. OpenShift SDN으로 롤백 수행

사용자 시작 단계마이그레이션 활동

MCO를 일시 중단하여 마이그레이션을 중단하지 않도록 합니다.

MCO가 중지됩니다.

cluster라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 마이그레이션 필드를 OVNKubernetes로 설정합니다. 값으로 설정하기 전에 마이그레이션 필드가 null인지 확인합니다.

CNO
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.

networkType 필드를 업데이트합니다.

CNO

다음 작업을 수행합니다.

  • OpenShift SDN 컨트롤 플레인 포드를 삭제합니다.
  • OVN-Kubernetes 컨트롤 플레인 Pod를 배포합니다.
  • 새 클러스터 네트워크 공급자를 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

클러스터
노드가 재부팅되면 클러스터에서 OVN-Kubernetes 클러스터 네트워크의 Pod에 IP 주소를 할당합니다.

클러스터 재부팅의 모든 노드 후에 MCO를 활성화합니다.

MCO
OpenShift SDN에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하므로 마이그레이션이 걸리는 총 시간이 클러스터 크기로 증가합니다.

15.2.2. OVN-Kubernetes 기본 CNI 네트워크 공급자로 마이그레이션

클러스터 관리자는 클러스터의 기본 CNI(Container Network Interface) 네트워크 공급자를 OVN-Kubernetes로 변경할 수 있습니다. 마이그레이션하는 동안 클러스터의 모든 노드를 재부팅해야 합니다.

중요

마이그레이션을 수행하는 동안 클러스터를 사용할 수 없으며 워크로드가 중단될 수 있습니다. 서비스 중단이 허용되는 경우에만 마이그레이션을 수행합니다.

사전 요구 사항

  • 네트워크 정책 격리 모드에서 OpenShift SDN CNI 네트워크 공급자로 구성된 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 데이터베이스의 최근 백업을 사용할 수 있습니다.
  • 각 노드에 대해 재부팅을 수동으로 트리거할 수 있습니다.
  • 클러스터가 오류 없이 알려진 정상 상태입니다.

프로세스

  1. 클러스터 네트워크의 구성을 백업하려면 다음 명령을 입력합니다.

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
  2. 마이그레이션을 위해 모든 노드를 준비하려면 다음 명령을 입력하여 Cluster Network Operator 구성 오브젝트에서 마이그레이션 필드를 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": {"networkType": "OVNKubernetes" } } }'
    참고

    이 단계는 OVN-Kubernetes를 즉시 배포하지 않습니다. 대신 마이그레이션 필드를 지정하면 OVN-Kubernetes 배포를 준비하기 위해 MCO(Machine Config Operator)가 클러스터의 모든 노드에 새 머신 구성을 적용합니다.

  3. 선택 사항: OVN-Kubernetes에 대해 다음 설정을 사용자 정의하여 네트워크 인프라 요구 사항을 충족할 수 있습니다.

    • 최대 전송 단위(MTU)
    • Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크 포트

    이전에 명시된 설정 중 하나를 사용자 정의하려면 다음 명령을 입력하고 사용자 정의합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>
        }}}}'
    mtu
    Geneve 오버레이 네트워크용 MTU입니다. MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 100을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    Geneve 오버레이 네트워크용 UDP 포트입니다. 값을 지정하지 않으면 기본값은 6081입니다. 이 포트는 OpenShift SDN에서 사용하는 VXLAN 포트와 같을 수 없습니다. VXLAN 포트의 기본값은 4789입니다.

    mtu 필드를 업데이트하는 패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'

  4. MCO는 각 머신 구성 풀의 머신을 업데이트하므로 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp

    업데이트된 노드의 상태가 UPDATED=true,UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 한 번에 풀당 하나의 머신을 업데이트하여 클러스터 크기와 함께 마이그레이션을 늘리는 데 걸리는 총 시간을 생성합니다.

  5. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"

      출력 예

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator

        출력 예

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 다음 명령을 입력하여 이전 출력에 표시된 첫 번째 머신 구성 데몬 포드에 대한 포드 로그를 표시합니다.

        $ oc logs <pod> -n openshift-machine-config-operator

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
  6. 마이그레이션을 시작하려면 다음 명령 중 하나를 사용하여 OVN-Kubernetes 클러스터 네트워크 공급자를 구성합니다.

    • 클러스터 네트워크 IP 주소 블록을 변경하지 않고 네트워크 공급자를 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
    • 다른 클러스터 네트워크 IP 주소 블록을 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": "<prefix>"
              }
            ]
            "networkType": "OVNKubernetes"
          }
        }'

      여기서 cidr은 CIDR 블록이며 prefix는 클러스터의 각 노드에 승인된 CIDR 블록 조각입니다. OVN-Kubernetes 네트워크 공급자는 이 블록을 내부적으로 사용하므로 100.64.0.0/16 CIDR 블록과 겹치는 CIDR 블록을 사용할 수 없습니다.

      중요

      마이그레이션 중에 서비스 네트워크 주소 블록을 변경할 수 없습니다.

  7. 후속 단계를 계속 진행하기 전에 Multus 데몬 세트 롤아웃이 완료되었는지 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus 포드의 이름은 multus-<xxxxx> 형식입니다. 여기서 <xxxxx>는 임의 문자 시퀀스입니다. 포드를 다시 시작하는 데 시간이 다소 걸릴 수 있습니다.

    출력 예

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  8. 마이그레이션을 완료하려면 클러스터의 각 노드를 재부팅합니다. 예를 들어 다음 예와 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 ssh를 사용하여 각 호스트에 연결할 수 있고 암호를 묻지 않도록 sudo를 구성했다고 가정합니다.

    #!/bin/bash
    
    for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
    do
       echo "reboot node $ip"
       ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
    done

    ssh 액세스를 사용할 수 없는 경우 인프라 공급자의 관리 포털을 통해 각 노드를 재부팅할 수 있습니다.

  9. 마이그레이션이 성공했는지 확인합니다.

    1. CNI 클러스터 네트워크 공급자가 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다. status.networkType의 값은 OVNKubernetes이어야 합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
    3. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

    4. 모든 클러스터 Operator가 비정상적인 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get co

      모든 클러스터 Operator의 상태는 AVAILABLE="True", PROGRESSING="False" , DEGRADED="False"여야 합니다. 클러스터 Operator를 사용할 수 없거나 성능이 저하된 경우 자세한 내용은 클러스터 Operator의 로그를 확인합니다.

  10. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. CNO 구성 오브젝트에서 마이그레이션 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. OpenShift SDN 네트워크 공급자에 대한 사용자 지정 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
    3. OpenShift SDN 네트워크 공급자 네임스페이스를 제거하려면 다음 명령을 입력합니다.

      $ oc delete namespace openshift-sdn

15.2.3. 추가 리소스

15.3. OpenShift SDN 네트워크 공급자로 롤백

클러스터 관리자는 OVN-Kubernetes로의 마이그레이션에 실패한 경우 OVN-Kubernetes 기본 CNI 네트워크 공급자에서 OpenShift SDN 클러스터 기본 CNI(Container Network InterfaceI) 공급자로 롤백할 수 있습니다.

15.3.1. 기본 CNI 네트워크 공급자를 OpenShift SDN으로 롤백

클러스터 관리자는 클러스터를 OpenShift SDN CNI(Container Network Interface) 클러스터 네트워크 공급자로 롤백할 수 있습니다. 롤백 중에 클러스터의 모든 노드를 재부팅해야 합니다.

중요

OVN-Kubernetes로의 마이그레이션이 실패한 경우에만 OpenShift SDN으로 롤백하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OVN-Kubernetes CNI 클러스터 네트워크 공급자로 구성된 인프라에 설치된 클러스터입니다.

프로세스

  1. MCO(Machine Config Operator)에서 관리하는 모든 머신 구성 풀을 중지합니다.

    • 마스터 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": true } }'
    • 작업자 머신 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec":{ "paused" :true } }'
  2. 마이그레이션을 시작하려면 다음 명령을 입력하여 클러스터 네트워크 공급자를 다시 OpenShift SDN으로 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'
    
    $ oc patch Network.config.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'
  3. 선택 사항: OpenShift SDN에 대해 네트워크 인프라 요구 사항을 충족하도록 다음 설정을 사용자 정의할 수 있습니다.

    • 최대 전송 단위(MTU)
    • VXLAN 포트

    이전에 명시된 설정 중 하나 또는 둘 다 사용자 정의하려면 사용자 정의하고 다음 명령을 입력합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":<mtu>,
              "vxlanPort":<port>
        }}}}'
    mtu
    VXLAN 오버레이 네트워크의 MTU입니다. MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 50을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    VXLAN 오버레이 네트워크용 UDP 포트입니다. 값을 지정하지 않으면 기본값은 4789입니다. 이 포트는 OVN-Kubernetes에서 사용하는 Geneve 포트와 같을 수 없습니다. Geneve 포트의 기본값은 6081입니다.

    패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":1200
        }}}}'

  4. Multus 데몬 세트 롤아웃이 완료될 때까지 기다립니다.

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus 포드의 이름은 multus-<xxxxx> 형식이며 여기서 <xxxxx>는 임의 문자 순서입니다. 포드를 다시 시작하는 데 시간이 다소 걸릴 수 있습니다.

    출력 예

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  5. 롤백을 완료하려면 클러스터의 각 노드를 재부팅합니다. 예를 들어 다음과 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 ssh를 사용하여 각 호스트에 연결할 수 있고 암호를 묻지 않도록 sudo를 구성했다고 가정합니다.

    #!/bin/bash
    
    for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
    do
       echo "reboot node $ip"
       ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
    done

    ssh 액세스를 사용할 수 없는 경우 인프라 공급자의 관리 포털을 통해 각 노드를 재부팅할 수 있습니다.

  6. 클러스터의 노드가 재부팅된 후 모든 머신 구성 풀을 시작합니다.

    • 마스터 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": false } }'
    • 작업자 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec": { "paused": false } }'

    MCO는 각 구성 풀에서 머신을 업데이트하므로 각 노드를 재부팅합니다.

    기본적으로 MCO는 한 번에 풀당 단일 머신을 업데이트하므로 마이그레이션이 완료하는 데 필요한 시간은 클러스터 크기와 함께 증가합니다.

  7. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"

      출력 예

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

  8. 마이그레이션이 성공했는지 확인합니다.

    1. 기본 CNI 네트워크 공급자가 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다. status.networkType 값은 OpenShiftSDN이어야 합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator

        출력 예

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 이전 출력에 표시된 각 머신 구성 데몬 포드에 대한 포드 로그를 표시하려면 다음 명령을 입력합니다.

        $ oc logs <pod> -n openshift-machine-config-operator

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
    4. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

  9. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. Cluster Network Operator 구성 오브젝트에서 마이그레이션 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. OVN-Kubernetes 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
    3. OVN-Kubernetes 네트워크 공급자 네임스페이스를 제거하려면 다음 명령을 입력합니다.

      $ oc delete namespace openshift-ovn-kubernetes

15.4. IPv4/IPv6 듀얼 스택 네트워킹으로 변환

클러스터 관리자는 IPv4 단일 스택 클러스터를 IPv4 및 IPv6 주소 제품군을 지원하는 듀얼 네트워크 클러스터 네트워크로 변환할 수 있습니다. 듀얼 스택으로 변환한 후 새로 생성된 모든 포드는 듀얼 스택이 활성화됩니다.

참고

이중 스택 네트워크는 베어 메탈 인프라에서만 프로비저닝된 클러스터에서 지원됩니다.

15.4.1. 듀얼 스택 클러스터 네트워크로 변환

클러스터 관리자는 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.

참고

듀얼 스택 네트워킹으로 변환한 후에는 새로 생성된 포드만 IPv6 주소에 할당됩니다. IPv6 주소를 받으려면 변환하기 전에 생성된 모든 Pod를 다시 생성해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터는 OVN-Kubernetes 클러스터 네트워크 공급자를 사용합니다.

프로세스

  1. 클러스터 및 서비스 네트워크에 대한 IPv6 주소 블록을 지정하려면 다음 YAML이 포함된 파일을 생성합니다.

    - op: add
      path: /spec/clusterNetwork/-
      value: 1
        cidr: fd01::/48
        hostPrefix: 64
    - op: add
      path: /spec/serviceNetwork/-
      value: fd02::/112 2
    1
    cidrhostPrefix 필드를 사용하여 오브젝트를 지정합니다. 호스트 접두사는 64 이상이어야 합니다. IPv6 CIDR 접두사는 지정된 호스트 접두사를 수용할 수 있을 만큼 커야 합니다.
    2
    접두사가 112인 IPv6 CIDR을 지정합니다. Kubernetes는 가장 낮은 16비트만 사용합니다. 접두사 112의 경우 IP 주소는 112비트에서 128비트로 할당됩니다.
  2. 클러스터 네트워크 구성을 패치하려면 다음 명령을 입력합니다.

    $ oc patch network.config.openshift.io cluster \
      --type='json' --patch-file <file>.yaml

    다음과 같습니다.

    file
    이전 단계에서 만든 파일의 이름을 지정합니다.

    출력 예

    network.config.openshift.io/cluster patched

검증

다음 단계를 완료하여 클러스터 네트워크가 이전 프로시저에서 지정한 IPv6 주소 블록을 인식하는지 확인합니다.

  1. 네트워크 구성을 표시합니다.

    $ oc describe network

    출력 예

    Status:
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
        Cidr:               fd01::/48
        Host Prefix:        64
      Cluster Network MTU:  1400
      Network Type:         OVNKubernetes
      Service Network:
        172.30.0.0/16
        fd02::/112

15.5. IPsec 암호화 구성

IPsec이 활성화되면 OVN-Kubernetes CNI(Container Network Interface) 클러스터 네트워크의 노드 간 모든 네트워크 트래픽이 암호화된 터널을 통해 이동합니다.

IPsec은 기본적으로 비활성화되어 있습니다.

참고

IPsec 암호화는 클러스터 설치 중에만 활성화할 수 있으며 활성화된 후에는 비활성화할 수 없습니다. 설치 문서의 경우 클러스터 설치 방법 선택 및 사용자를 위한 준비를 참조하십시오.

15.5.1. IPsec에서 암호화하는 네트워크 트래픽 흐름 유형

IPsec을 활성화하면 포드 간 다음 네트워크 트래픽 흐름만 암호화됩니다.

  • 클러스터 네트워크의 서로 다른 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드에서 클러스터 네트워크의 포드로의 트래픽

다음 트래픽 흐름은 암호화되지 않습니다.

  • 클러스터 네트워크의 동일한 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드 간 트래픽
  • 클러스터 네트워크의 포드에서 호스트 네트워크 포드로의 트래픽

암호화되거나 암호화되지 않은 흐름은 다음 다이어그램에 설명되어 있습니다.

IPsec 암호화 및 암호화되지 않은 트래픽 흐름

15.5.2. IPsec의 암호화 프로토콜 및 터널 모드

사용된 암호화 암호는 AES-GCM-16-256입니다. 무결성 검사 값(ICV)은 16바이트입니다. 키 길이는 256비트입니다.

사용된 IPsec 터널 모드는 전송 모드로, 이는 엔드 투 엔드 통신을 암호화하는 모드입니다.

15.5.3. 보안 인증서 생성 및 교체

CNO(Cluster Network Operator)는 암호화에 IPsec에서 사용하는 자체 서명된 X.509 인증 기관(CA)을 생성합니다. 각 노드의 CSR(인증서 서명 요청)은 CNO에서 자동으로 충족됩니다.

CA는 10년 동안 유효합니다. 개별 노드 인증서는 5년간 유효하며 4년 6개월 경과 후 자동으로 교체됩니다.

15.6. 프로젝트에 대한 송신 방화벽 구성

클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

15.6.1. 프로젝트에서 송신 방화벽이 작동하는 방식

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

EgressFirewall CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
  • 포트 번호
  • 다음 프로토콜 중 하나인 프로토콜 : TCP, UDP 및 SCTP
주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

15.6.1.1. 송신 방화벽의 제한

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상되고 모든 외부 네트워크 트래픽이 삭제될 수 있습니다.

15.6.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

15.6.1.3. DNS(Domain Name Server) 확인 작동 방식

송신 방화벽 정책 규칙에서 DNS 이름을 사용하는 경우 도메인 이름의 적절한 확인에는 다음 제한 사항이 적용됩니다.

  • 도메인 이름 업데이트는 TTL(Time To- Live) 기간에 따라 폴링됩니다. 기본적으로 기간은 30분입니다. 송신 방화벽 컨트롤러가 도메인 이름을 위해 로컬 이름 서버를 쿼리할 때 응답에 TTL이 포함되어 있고 TTL이 30분 미만이면 컨트롤러에서 해당 DNS 이름의 기간을 반환된 값으로 설정합니다. 각 DNS 이름은 DNS 레코드의 TTL이 만료된 후에 쿼리됩니다.
  • Pod는 필요한 경우 동일한 로컬 이름 서버에서 도메인을 확인해야 합니다. 확인하지 않으면 송신 방화벽 컨트롤러와 Pod에 의해 알려진 도메인의 IP 주소가 다를 수 있습니다. 호스트 이름의 IP 주소가 다르면 송신 방화벽이 일관되게 적용되지 않을 수 있습니다.
  • 송신 방화벽 컨트롤러와 Pod는 동일한 로컬 이름 서버를 비동기적으로 폴링하기 때문에 Pod가 송신 컨트롤러보다 먼저 업데이트된 IP 주소를 얻을 수 있으며 이로 인해 경쟁 조건이 발생합니다. 현재 이런 제한으로 인해 EgressFirewall 오브젝트의 도메인 이름 사용은 IP 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽은 Pod가 DNS 확인을 위해 Pod가 있는 노드의 외부 인터페이스에 항상 액세스할 수 있도록 합니다.

송신 방화벽 정책에서 도메인 이름을 사용하고 로컬 노드의 DNS 서버에서 DNS 확인을 처리하지 않으면 Pod에서 도메인 이름을 사용하는 경우, DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 추가해야 합니다.

15.6.2. EgressFirewall CR(사용자 정의 리소스) 오브젝트

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 Allow 규칙 또는 Deny 규칙입니다.

다음 YAML은 EgressFirewall CR 오브젝트를 설명합니다.

EgressFirewall 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

1
오브젝트의 이름은 default이어야 합니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.

15.6.2.1. EgressFirewall 규칙

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4
  ports: 5
      ...

1
규칙 유형입니다. 값은 Allow 또는 Deny여야 합니다.
2
cidrSelector 필드 또는 dnsName 필드를 지정하는 송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
DNS 도메인 이름입니다.
5
선택 사항: 규칙에 대한 네트워크 포트 및 프로토콜 컬렉션을 설명하는 스탠자입니다.

포트 스탠자

ports:
- port: <port> 1
  protocol: <protocol> 2

1
80 또는 443과 같은 네트워크 포트. 이 필드의 값을 지정하는 경우 protocol의 값도 지정해야 합니다.
2
네트워크 프로토콜. 값은 TCP, UDP 또는 SCTP여야 합니다.

15.6.2.2. EgressFirewall CR 오브젝트의 예

다음 예는 여러 가지 송신 방화벽 정책 규칙을 정의합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
송신 방화벽 정책 규칙 오브젝트의 컬렉션입니다.

다음 예에서는 트래픽이 TCP 프로토콜 및 대상 포트 80 또는 임의의 프로토콜 및 대상 포트 443을 사용하는 경우 172.16.1.1 IP 주소에서 호스트에 대한 트래픽을 거부하는 정책 규칙을 정의합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1
    ports:
    - port: 80
      protocol: TCP
    - port: 443

15.6.3. 송신 방화벽 정책 오브젝트 생성

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressFirewall 오브젝트가 정의되어 있는 경우 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OVN-Kubernetes 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.
  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다.

    $ oc create -f <policy_name>.yaml -n <project>

    다음 예제에서는 project1이라는 프로젝트에 새 EgressFirewall 오브젝트가 생성됩니다.

    $ oc create -f default.yaml -n project1

    출력 예

    egressfirewall.k8s.ovn.org/v1 created

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.

15.7. 프로젝트의 송신 방화벽 보기

클러스터 관리자는 기존 송신 방화벽의 이름을 나열하고 특정 송신 방화벽에 대한 트래픽 규칙을 볼 수 있습니다.

15.7.1. EgressFirewall 오브젝트 보기

클러스터의 EgressFirewall 오브젝트를 볼 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressFirewall 오브젝트의 이름을 보려면 다음 명령을 입력합니다.

    $ oc get egressfirewall --all-namespaces
  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다.

    $ oc describe egressfirewall <policy_name>

    출력 예

    Name:		default
    Namespace:	project1
    Created:	20 minutes ago
    Labels:		<none>
    Annotations:	<none>
    Rule:		Allow to 1.2.3.0/24
    Rule:		Allow to www.example.com
    Rule:		Deny to 0.0.0.0/0

15.8. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

15.8.1. EgressFirewall 오브젝트 편집

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
  2. 선택 사항: 송신 네트워크 방화벽을 만들 때 EgressFirewall 오브젝트의 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다.

    $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressFirewall 오브젝트를 바꿉니다. 업데이트된 EgressFirewall 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다.

    $ oc replace -f <filename>.yaml

15.9. 프로젝트에서 송신 방화벽 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

15.9.1. EgressFirewall 오브젝트 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
  2. 다음 명령을 입력하여 EgressFirewall 오브젝트를 삭제합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다.

    $ oc delete -n <project> egressfirewall <name>

15.10. 송신 IP 주소 구성

클러스터 관리자는 OVN-Kubernetes 기본 컨테이너 네트워크 인터페이스(CNI) 네트워크 공급자를 구성하여 하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스 내 특정 Pod에 할당할 수 있습니다.

15.10.1. 송신 IP 주소 아키텍처 설계 및 구현

OpenShift Container Platform 송신 IP 주소 기능을 사용하면 하나 이상의 네임스페이스에 있는 하나 이상의 Pod에서 발생하는 트래픽의 소스 IP 주소가 클러스터 네트워크 외부 서비스에 일관되게 표시되도록 할 수 있습니다.

예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.

송신 IP 주소는 노드의 기본 네트워크 인터페이스에서 추가 IP 주소로 구현되며 노드의 기본 IP 주소와 동일한 서브넷에 있어야 합니다. 추가 IP 주소를 클러스터의 다른 노드에 할당해서는 안 됩니다.

15.10.1.1. 플랫폼 지원

다음 표에는 다양한 플랫폼의 송신 IP 주소 기능에 대한 지원이 요약되어 있습니다.

중요

송신 IP 주소 구현은 AWS(Amazon Web Services), Azure Cloud 또는 송신 IP 기능에 필요한 자동 계층 2 네트워크 조작과 호환되지 않는 기타 퍼블릭 클라우드 플랫폼과 호환되지 않습니다.

플랫폼지원됨

베어 메탈

vSphere

Red Hat OpenStack Platform (RHOSP)

아니요

퍼블릭 클라우드

아니요

15.10.1.2. Pod에 송신 IP 할당

하나 이상의 송신 IP를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당하려면 다음 조건을 충족해야 합니다.

  • 클러스터에서 하나 이상의 노드에 k8s.ovn.org/egress-assignable: "" 레이블이 있어야 합니다.
  • 네임스페이스의 Pod에서 클러스터를 떠나는 트래픽의 소스 IP 주소로 사용할 하나 이상의 송신 IP 주소를 정의하는 EgressIP 오브젝트가 있습니다.
중요

송신 IP 할당을 위해 클러스터의 노드에 레이블을 지정하기 전에 EgressIP 오브젝트를 생성하면 OpenShift Container Platform에서 모든 송신 IP 주소를 k8s.ovn.org/egress-assignable: "" 레이블이 있는 첫 번째 노드에 할당할 수 있습니다.

송신 IP 주소가 클러스터의 여러 노드에 널리 분산되도록 하려면 EgressIP 오브젝트를 만들기 전에 송신 IP 주소를 호스팅할 노드에 항상 레이블을 적용하십시오.

15.10.1.3. 노드에 송신 IP 할당

EgressIP 오브젝트를 생성할 때 k8s.ovn.org/egress-assignable: "" 레이블이 지정된 노드에 다음 조건이 적용됩니다.

  • 송신 IP 주소는 한 번에 두 개 이상의 노드에 할당되지 않습니다.
  • 송신 IP 주소는 송신 IP 주소를 호스팅할 수 있는 사용 가용한 노드 간에 균형을 이룹니다.
  • EgressIP 오브젝트의 spec.EgressIPs 배열에서 두 개 이상의 IP 주소를 지정해도 노드에서는 지정된 주소 중 두 개 이상을 호스팅하지 않습니다.
  • 노드를 사