네트워킹


OpenShift Container Platform 4.13

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

Red Hat OpenShift Documentation Team

초록

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

1장. 네트워킹 정보

Red Hat OpenShift Networking은 클러스터가 하나 또는 여러 하이브리드 클러스터의 네트워크 트래픽을 관리하는 데 필요한 고급 네트워킹 관련 기능으로 Kubernetes 네트워킹을 확장하는 기능, 플러그인 및 고급 네트워킹 기능의 에코시스템입니다. 이 네트워킹 기능 에코시스템은 수신, 송신, 로드 밸런싱, 고성능 처리량, 보안, 클러스터 간 트래픽 관리, 역할 기반 관찰 도구를 제공하여 자연의 복잡성을 줄입니다.

다음 목록은 클러스터에서 사용할 수 있는 가장 일반적으로 사용되는 Red Hat OpenShift Networking 기능 중 일부를 강조 표시합니다.

  • 다음 CNI(Container Network Interface) 플러그인 중 하나에서 제공하는 기본 클러스터 네트워크:

  • 인증된 타사 대체 네트워크 플러그인
  • Network Operator for network plugin management
  • TLS 암호화 웹 트래픽용 Ingress Operator
  • 이름 할당을 위한 DNS Operator
  • 베어 메탈 클러스터에서 트래픽 로드 밸런싱을 위한 MetalLB Operator
  • 고가용성을 위한 IP 페일오버 지원
  • macvlan, ipvlan 및 SR-IOV 하드웨어 네트워크를 포함한 여러 CNI 플러그인을 통한 추가 하드웨어 네트워크 지원
  • IPv4, IPv6 및 듀얼 스택 주소 지정
  • 하이브리드 Linux-Windows 호스트 클러스터 Windows 기반 워크로드
  • 검색, 로드 밸런싱, 서비스 간 인증, 실패 복구, 지표 및 서비스 모니터링을 위한 Red Hat OpenShift Service Mesh
  • Single-node OpenShift
  • 네트워크 디버깅 및 인사이트를 위한 Network Observability Operator
  • 클러스터 간 네트워킹을 위한 Submariner
  • 계층 7 간 네트워킹을 위한 Red Hat Service Interconnect

2장. 네트워킹 이해

클러스터 관리자는 클러스터 내에서 실행되는 애플리케이션을 외부 트래픽으로 노출하고 네트워크 연결을 보호하는 몇 가지 옵션이 있습니다.

  • 노드 포트 또는 로드 밸런서와 같은 서비스 유형
  • IngressRoute와 같은 API 리소스

기본적으로 Kubernetes는 pod 내에서 실행되는 애플리케이션의 내부 IP 주소를 각 pod에 할당합니다. 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에 기본 네트워크 인프라에 대한 액세스 권한이 부여됩니다.

2.1. OpenShift Container Platform DNS

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

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

2.2. OpenShift Container Platform Ingress Operator

OpenShift Container Platform 클러스터를 생성할 때 클러스터에서 실행되는 Pod 및 서비스에는 각각 자체 IP 주소가 할당됩니다. IP 주소는 내부에서 실행되지만 외부 클라이언트가 액세스할 수 없는 다른 pod 및 서비스에 액세스할 수 있습니다. Ingress Operator는 IngressController API를 구현하며 OpenShift Container Platform 클러스터 서비스에 대한 외부 액세스를 활성화하는 구성 요소입니다.

Ingress Operator를 사용하면 라우팅을 처리하기 위해 하나 이상의 HAProxy 기반 Ingress 컨트롤러를 배포하고 관리하여 외부 클라이언트가 서비스에 액세스할 수 있습니다. Ingress Operator를 사용하여 OpenShift 컨테이너 플랫폼 Route 및 Kubernetes Ingress 리소스를 지정하면 수신 트래픽을 라우팅할 수 있습니다. endpointPublishingStrategy 유형 및 내부 로드 밸런싱을 정의하는 기능과 같은 Ingress 컨트롤러 내 구성은 Ingress 컨트롤러 끝점을 게시하는 방법을 제공합니다.

2.2.1. 경로와 Ingress 비교

OpenShift Container Platform의 Kubernetes Ingress 리소스는 클러스터 내에서 Pod로 실행되는 공유 라우터 서비스를 사용하여 Ingress 컨트롤러를 구현합니다. Ingress 트래픽을 관리하는 가장 일반적인 방법은 Ingress 컨트롤러를 사용하는 것입니다. 다른 일반 Pod와 마찬가지로 이 Pod를 확장하고 복제할 수 있습니다. 이 라우터 서비스는 오픈 소스 로드 밸런서 솔루션인 HAProxy를 기반으로 합니다.

OpenShift Container Platform 경로는 클러스터의 서비스에 대한 Ingress 트래픽을 제공합니다. 경로는 TLS 재암호화, TLS 패스스루, 블루-그린 배포를 위한 분할 트래픽등 표준 Kubernetes Ingress 컨트롤러에서 지원하지 않는 고급 기능을 제공합니다.

Ingress 트래픽은 경로를 통해 클러스터의 서비스에 액세스합니다. 경로 및 Ingress는 Ingress 트래픽을 처리하는 데 필요한 주요 리소스입니다. Ingress는 외부 요청을 수락하고 경로를 기반으로 위임하는 것과 같은 경로와 유사한 기능을 제공합니다. 그러나 Ingress를 사용하면 HTTP/2, HTTPS, SNI(서버 이름 식별) 및 인증서가 있는 TLS와 같은 특정 유형의 연결만 허용할 수 있습니다. OpenShift Container Platform에서는 Ingress 리소스에서 지정하는 조건을 충족하기 위해 경로가 생성됩니다.

2.3. OpenShift Container Platform 네트워킹에 대한 일반 용어집

이 용어집은 네트워킹 콘텐츠에 사용되는 일반적인 용어를 정의합니다.

인증
OpenShift Container Platform 클러스터에 대한 액세스를 제어하기 위해 클러스터 관리자는 사용자 인증을 구성하고 승인된 사용자만 클러스터에 액세스할 수 있는지 확인할 수 있습니다. OpenShift Container Platform 클러스터와 상호 작용하려면 OpenShift Container Platform API에 인증해야 합니다. OpenShift Container Platform API에 대한 요청에 OAuth 액세스 토큰 또는 X.509 클라이언트 인증서를 제공하여 인증할 수 있습니다.
AWS Load Balancer Operator
AWS Load Balancer(ALB) Operator는 aws-load-balancer-controller 의 인스턴스를 배포하고 관리합니다.
CNO(Cluster Network Operator)
CNO(Cluster Network Operator)는 OpenShift Container Platform 클러스터에서 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 여기에는 설치 중에 클러스터에 대해 선택한 CNI(Container Network Interface) 네트워크 플러그인 배포가 포함됩니다.
구성 맵
구성 맵에서는 구성 데이터를 Pod에 삽입하는 방법을 제공합니다. 구성 맵에 저장된 데이터를 ConfigMap 유형의 볼륨에서 참조할 수 있습니다. Pod에서 실행되는 애플리케이션에서는 이 데이터를 사용할 수 있습니다.
CR(사용자 정의 리소스)
CR은 Kubernetes API의 확장입니다. 사용자 정의 리소스를 생성할 수 있습니다.
DNS
클러스터 DNS는 Kubernetes 서비스에 대한 DNS 레코드를 제공하는 DNS 서버입니다. Kubernetes에서 시작하는 컨테이너는 DNS 검색에 이 DNS 서버를 자동으로 포함합니다.
DNS Operator
DNS Operator는 CoreDNS를 배포하고 관리하여 Pod에 이름 확인 서비스를 제공합니다. 이를 통해 OpenShift Container Platform에서 DNS 기반 Kubernetes 서비스 검색을 사용할 수 있습니다.
Deployment
애플리케이션의 라이프사이클을 유지 관리하는 Kubernetes 리소스 오브젝트입니다.
domain
domain은 Ingress 컨트롤러에서 제공하는 DNS 이름입니다.
egress
Pod에서 네트워크의 아웃바운드 트래픽을 통해 외부적으로 공유하는 데이터 프로세스입니다.
외부 DNS Operator
외부 DNS Operator는 ExternalDNS를 배포 및 관리하여 외부 DNS 공급자에서 OpenShift Container Platform으로 서비스 및 경로에 대한 이름 확인을 제공합니다.
HTTP 기반 경로
HTTP 기반 경로는 기본 HTTP 라우팅 프로토콜을 사용하고 보안되지 않은 애플리케이션 포트에 서비스를 노출하는 비보안 경로입니다.
Ingress
OpenShift Container Platform의 Kubernetes Ingress 리소스는 클러스터 내에서 Pod로 실행되는 공유 라우터 서비스를 사용하여 Ingress 컨트롤러를 구현합니다.
Ingress 컨트롤러
Ingress Operator는 Ingress 컨트롤러를 관리합니다. OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하는 가장 일반적인 방법은 Ingress 컨트롤러를 사용하는 것입니다.
설치 프로그램에서 제공하는 인프라
설치 프로그램은 클러스터가 실행되는 인프라를 배포하고 구성합니다.
kubelet
Pod에서 컨테이너가 실행 중인지 확인하기 위해 클러스터의 각 노드에서 실행되는 기본 노드 에이전트입니다.
Kubernetes NMState Operator
Kubernetes NMState Operator는 OpenShift Container Platform 클러스터 노드에서 NMState를 사용하여 상태 중심 네트워크 구성을 수행하는 데 필요한 Kubernetes API를 제공합니다.
kube-proxy
kube-proxy는 각 노드에서 실행되며 외부 호스트에서 서비스를 사용할 수 있도록 지원하는 프록시 서비스입니다. 컨테이너를 수정하도록 요청을 전달하는 데 도움이 되며 기본 로드 밸런싱을 수행할 수 있습니다.
로드 밸런서
OpenShift Container Platform은 로드 밸런서를 사용하여 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신합니다.
MetalLB Operator
클러스터 관리자는 LoadBalancer 유형의 서비스가 클러스터에 추가되면 MetalLB가 서비스에 대한 외부 IP 주소를 추가할 수 있도록 MetalLB Operator를 클러스터에 추가할 수 있습니다.
멀티 캐스트
IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.
네임스페이스
네임스페이스는 모든 프로세스에 표시되는 특정 시스템 리소스를 격리합니다. 네임스페이스 내에서 해당 네임스페이스의 멤버인 프로세스만 해당 리소스를 볼 수 있습니다.
networking
OpenShift Container Platform 클러스터의 네트워크 정보입니다.
node
OpenShift Container Platform 클러스터의 작업자 시스템입니다. 노드는 VM(가상 머신) 또는 물리적 머신입니다.
OpenShift Container Platform Ingress Operator
Ingress Operator는 IngressController API를 구현하며 OpenShift Container Platform 서비스에 대한 외부 액세스를 가능하게 하는 구성 요소입니다.
Pod
OpenShift Container Platform 클러스터에서 실행되는 볼륨 및 IP 주소와 같은 공유 리소스가 있는 하나 이상의 컨테이너입니다. Pod는 정의, 배포 및 관리되는 최소 컴퓨팅 단위입니다.
PTP Operator
PTP Operator는 linuxptp 서비스를 생성하고 관리합니다.
Route
OpenShift Container Platform 경로는 클러스터의 서비스에 대한 Ingress 트래픽을 제공합니다. 경로는 TLS 재암호화, TLS 패스스루, 블루-그린 배포를 위한 분할 트래픽등 표준 Kubernetes Ingress 컨트롤러에서 지원하지 않는 고급 기능을 제공합니다.
스케일링
리소스 용량을 늘리거나 줄입니다.
service
Pod 세트에 실행 중인 애플리케이션을 노출합니다.
SR-IOV(Single Root I/O Virtualization) Network Operator
SR-IOV(Single Root I/O Virtualization) Network Operator는 클러스터의 SR-IOV 네트워크 장치 및 네트워크 첨부 파일을 관리합니다.
소프트웨어 정의 네트워킹(SDN)
OpenShift Container Platform에서는 소프트웨어 정의 네트워킹(SDN) 접근법을 사용하여 OpenShift Container Platform 클러스터 전체의 pod 간 통신이 가능한 통합 클러스터 네트워크를 제공합니다.
SCTP(스트림 제어 전송 프로토콜)
SCTP는 IP 네트워크에서 실행되는 안정적인 메시지 기반 프로토콜입니다.
taint
테인트 및 톨러레이션은 Pod가 적절한 노드에 예약되도록 합니다. 노드에 하나 이상의 테인트를 적용할 수 있습니다.
허용 오차
Pod에 허용 오차를 적용할 수 있습니다. 허용 오차를 사용하면 스케줄러에서 일치하는 테인트를 사용하여 Pod를 예약할 수 있습니다.
웹 콘솔
OpenShift Container Platform을 관리할 UI(사용자 인터페이스)입니다.

3장. 호스트에 액세스

배스천 호스트(Bastion Host)를 생성하여 OpenShift Container Platform 인스턴스에 액세스하고 SSH(Secure Shell) 액세스 권한으로 컨트롤 플레인 노드에 액세스하는 방법을 알아봅니다.

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에 수동으로 배포한 베스천 SSH 호스트에서 해당 컨트롤 플레인 호스트에 SSH로 연결합니다. 설치 중 지정한 것과 동일한 SSH 키를 사용해야 합니다.

    $ ssh -i <ssh-key-path> core@<master-hostname>
    Copy to Clipboard Toggle word wrap

4장. 네트워킹 Operator 개요

OpenShift Container Platform은 여러 유형의 네트워킹 Operator를 지원합니다. 이러한 네트워킹 Operator를 사용하여 클러스터 네트워킹을 관리할 수 있습니다.

4.1. CNO(Cluster Network Operator)

CNO(Cluster Network Operator)는 OpenShift Container Platform 클러스터에서 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 여기에는 설치 중에 클러스터에 대해 선택한 CNI(Container Network Interface) 네트워크 플러그인 배포가 포함됩니다. 자세한 내용은 OpenShift Container Platform의 Cluster Network Operator 를 참조하십시오.

4.2. DNS Operator

DNS Operator는 CoreDNS를 배포하고 관리하여 Pod에 이름 확인 서비스를 제공합니다. 이를 통해 OpenShift Container Platform에서 DNS 기반 Kubernetes 서비스 검색을 사용할 수 있습니다. 자세한 내용은 OpenShift Container Platform의 DNS Operator 를 참조하십시오.

4.3. Ingress Operator

OpenShift Container Platform 클러스터를 생성할 때 클러스터에서 실행 중인 Pod 및 서비스는 각 할당된 IP 주소입니다. IP 주소는 인근 다른 Pod 및 서비스에 액세스할 수 있지만 외부 클라이언트에서는 액세스할 수 없습니다. Ingress Operator는 Ingress 컨트롤러 API를 구현하고 OpenShift Container Platform 클러스터 서비스에 대한 외부 액세스를 활성화합니다. 자세한 내용은 OpenShift Container Platform의 Ingress Operator 를 참조하십시오.

4.4. 외부 DNS Operator

외부 DNS Operator는 ExternalDNS를 배포 및 관리하여 외부 DNS 공급자에서 OpenShift Container Platform으로 서비스 및 경로에 대한 이름 확인을 제공합니다. 자세한 내용은 외부 DNS Operator 이해를 참조하십시오.

4.5. Ingress Node Firewall Operator

Ingress Node Firewall Operator는 확장된 Berkley Packet Filter(eBPF) 및 eXpress Data Path(XDP) 플러그인을 사용하여 노드 방화벽 규칙을 처리하고 통계를 업데이트하고, 삭제된 트래픽에 대한 이벤트를 생성합니다. Operator는 수신 노드 방화벽 리소스를 관리하고, 방화벽 구성을 확인하고, 클러스터 액세스를 방지할 수 있는 잘못된 규칙을 허용하지 않으며, 수신 노드 방화벽 XDP 프로그램을 규칙 오브젝트에서 선택한 인터페이스에 로드합니다. 자세한 내용은 Ingress Node Firewall Operator 이해를참조하십시오.

4.6. Network Observability Operator

Network Observability Operator는 클러스터 관리자가 OpenShift Container Platform 클러스터의 네트워크 트래픽을 확인할 수 있는 선택적 Operator입니다. Network Observability Operator는 eBPF 기술을 사용하여 네트워크 흐름을 생성합니다. 그런 다음 네트워크 흐름은 OpenShift Container Platform 정보로 보강되고 CloudEvent에 저장됩니다. OpenShift Container Platform 콘솔에서 저장된 네트워크 흐름 정보를 보고 분석하여 추가 정보 및 문제 해결을 수행할 수 있습니다. 자세한 내용은 Network Observability Operator 정보를 참조하십시오.

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

CNO(Cluster Network Operator)를 사용하여 설치 중에 클러스터에 대해 선택한 CNI(Container Network Interface) 네트워크 플러그인을 포함하여 OpenShift Container Platform 클러스터에 클러스터 네트워크 구성 요소를 배포하고 관리할 수 있습니다.

5.1. CNO(Cluster Network Operator)

Cluster Network Operator는 operator.openshift.io API 그룹에서 네트워크 API를 구현합니다. Operator는 데몬 세트를 사용하여 OVN-Kubernetes 네트워크 플러그인 또는 클러스터 설치 중에 선택한 네트워크 공급자 플러그인을 배포합니다.

절차

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

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

    $ oc get -n openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m
    Copy to Clipboard Toggle word wrap

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

    $ oc get clusteroperator/network
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.5.4     True        False         False      50m
    Copy to Clipboard Toggle word wrap

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

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

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

프로세스

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

    $ oc describe network.config/cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    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>
    Copy to Clipboard Toggle word wrap

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

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

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

프로세스

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

    $ oc describe clusteroperators/network
    Copy to Clipboard Toggle word wrap

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

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

프로세스

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

    $ oc logs --namespace=openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

5.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 오브젝트의 필드를 설정하여 클러스터의 클러스터 네트워크 플러그인 구성을 지정할 수 있습니다.

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

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

Expand
표 5.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
Copy to Clipboard Toggle word wrap

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

spec.serviceNetwork

array

서비스의 IP 주소 블록입니다. OpenShift SDN 및 OVN-Kubernetes 네트워크 플러그인은 서비스 네트워크에 대한 단일 IP 주소 블록만 지원합니다. 예를 들면 다음과 같습니다.

spec:
  serviceNetwork:
  - 172.30.0.0/14
Copy to Clipboard Toggle word wrap

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

spec.defaultNetwork

object

클러스터 네트워크의 네트워크 플러그인을 구성합니다.

spec.kubeProxyConfig

object

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

defaultNetwork 오브젝트 구성

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

Expand
표 5.2. defaultNetwork 오브젝트
필드유형설명

type

string

OpenShiftSDN 또는 OVNKubernetes 중 하나이며, Red Hat OpenShift Networking 네트워크 플러그인은 설치 중에 선택됩니다. 클러스터를 설치한 후에는 이 값을 변경할 수 없습니다.

참고

OpenShift Container Platform에서는 기본적으로 OVN-Kubernetes 네트워크 플러그인을 사용합니다.

openshiftSDNConfig

object

이 오브젝트는 OpenShift SDN 네트워크 플러그인에만 유효합니다.

ovnKubernetesConfig

object

이 오브젝트는 OVN-Kubernetes 네트워크 플러그인에만 유효합니다.

OpenShift SDN 네트워크 플러그인 구성

다음 표에서는 OpenShift SDN 네트워크 플러그인의 구성 필드를 설명합니다.

Expand
표 5.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
Copy to Clipboard Toggle word wrap

OVN-Kubernetes 네트워크 플러그인 구성

다음 표에서는 OVN-Kubernetes 네트워크 플러그인의 구성 필드를 설명합니다.

Expand
표 5.4. ovnKubernetesConfig object
필드유형설명

mtu

integer

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

genevePort

integer

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

ipsecConfig

object

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

policyAuditConfig

object

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

gatewayConfig

object

선택 사항: 송신 트래픽이 노드 게이트웨이로 전송되는 방법을 사용자 정의할 구성 오브젝트를 지정합니다.

참고

송신 트래픽을 마이그레이션하는 동안 CNO(Cluster Network Operator)에서 변경 사항을 성공적으로 롤아웃할 때까지 워크로드 및 서비스 트래픽에 대한 일부 중단을 기대할 수 있습니다.

v4InternalSubnet

기존 네트워크 인프라가 100.64.0.0/16 IPv4 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부용으로 다른 IP 주소 범위를 지정할 수 있습니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 예를 들어 clusterNetwork.cidr 값이 10.128.0.0/14 이고 clusterNetwork.hostPrefix 값이 /23 인 경우 최대 노드 수는 2^(23-14)=512 입니다.

이 필드는 설치 후 변경할 수 없습니다.

기본값은 100.64.0.0/16 입니다.

v6InternalSubnet

기존 네트워크 인프라가 fd98::/48 IPv6 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부용으로 다른 IP 주소 범위를 지정할 수 있습니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다.

이 필드는 설치 후 변경할 수 없습니다.

기본값은 fd98::/48 입니다.

Expand
표 5.5. policyAuditConfig 오브젝트
필드유형설명

rateLimit

integer

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

maxFileSize

integer

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

maxLogFiles

integer

유지되는 최대 로그 파일 수입니다.

대상

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입니다.

Expand
표 5.6. gatewayConfig 오브젝트
필드유형설명

routingViaHost

boolean

Pod에서 호스트 네트워킹 스택으로 송신 트래픽을 보내려면 이 필드를 true로 설정합니다. 커널 라우팅 테이블에 수동으로 구성된 경로를 사용하는 고도의 전문 설치 및 애플리케이션의 경우 송신 트래픽을 호스트 네트워킹 스택으로 라우팅해야 할 수 있습니다. 기본적으로 송신 트래픽은 클러스터를 종료하기 위해 OVN에서 처리되며 커널 라우팅 테이블의 특수 경로의 영향을 받지 않습니다. 기본값은 false입니다.

이 필드는 Open vSwitch 하드웨어 오프로드 기능과 상호 작용합니다. 이 필드를 true 로 설정하면 송신 트래픽이 호스트 네트워킹 스택에서 처리되므로 오프로드의 성능 이점이 제공되지 않습니다.

참고

설치 후 활동으로 런타임 시 변경할 수 있는 gatewayConfig 필드를 제외하고 클러스터 설치 중에 클러스터 네트워크 플러그인의 구성만 변경할 수 있습니다.

IPSec가 활성화된 OVN-Kubernetes 구성의 예

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}
Copy to Clipboard Toggle word wrap

kubeProxyConfig 오브젝트 구성

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

Expand
표 5.7. 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
Copy to Clipboard Toggle word wrap

5.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
Copy to Clipboard Toggle word wrap

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

6장. OpenShift Container Platform에서의 DNS Operator

DNS Operator는 CoreDNS를 배포 및 관리하여 Pod에 이름 확인 서비스를 제공하여 OpenShift Container Platform에서 DNS 기반 Kubernetes 서비스 검색을 활성화합니다.

6.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
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

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

    $ oc get clusteroperator/dns
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    dns       4.1.0-0.11  True        False         False      92m
    Copy to Clipboard Toggle word wrap

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

6.2. DNS Operator managementState 변경

DNS는 CoreDNS 구성 요소를 관리하여 클러스터의 pod 및 서비스에 대한 이름 확인 서비스를 제공합니다. DNS Operator의 managementState는 기본적으로 Managed로 설정되어 있으며 이는 DNS Operator가 리소스를 적극적으로 관리하고 있음을 의미합니다. Unmanaged로 변경할 수 있습니다. 이는 DNS Operator가 해당 리소스를 관리하지 않음을 의미합니다.

다음은 DNS Operator managementState를 변경하는 사용 사례입니다.

  • 사용자가 개발자이며 구성 변경을 테스트하여 CoreDNS의 문제가 해결되었는지 확인하려고 합니다. managementStateUnmanaged로 설정하여 DNS Operator가 수정 사항을 덮어쓰지 않도록 할 수 있습니다.
  • 클러스터 관리자이며 CoreDNS 관련 문제를 보고했지만 문제가 해결될 때까지 해결 방법을 적용해야 합니다. DNS Operator의 managementState 필드를 Unmanaged로 설정하여 해결 방법을 적용할 수 있습니다.

절차

  • managementState DNS Operator 변경:

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
    Copy to Clipboard Toggle word wrap

6.3. 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
      Copy to Clipboard Toggle word wrap
    2. spec.nodePlacement.nodeSelector API 필드에 컨트롤 플레인 노드만 포함하는 노드 선택기를 지정합니다.

       spec:
         nodePlacement:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
      Copy to Clipboard Toggle word wrap
  • CoreDNS의 데몬 세트가 노드에서 실행되도록 테인트 및 허용 오차를 구성합니다.

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

      $ oc edit dns.operator/default
      Copy to Clipboard Toggle word wrap
    2. 테인트 키와 테인트에 대한 허용 오차를 지정합니다.

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

6.4. 기본 DNS보기

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

프로세스

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

    $ oc describe dns.operator/default
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    
    ...
    Copy to Clipboard Toggle word wrap

    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}'
    Copy to Clipboard Toggle word wrap

출력 예

[172.30.0.0/16]
Copy to Clipboard Toggle word wrap

6.5. DNS 전달 사용

다음과 같은 방법으로 DNS 전달을 사용하여 /etc/resolv.conf 파일의 기본 전달 구성을 덮어쓸 수 있습니다.

  • 모든 영역에 이름 서버를 지정합니다. 전달된 영역이 OpenShift Container Platform에서 관리하는 Ingress 도메인인 경우 도메인에 대한 업스트림 이름 서버를 승인해야 합니다.
  • 업스트림 DNS 서버 목록을 제공합니다.
  • 기본 전달 정책을 변경합니다.
참고

기본 도메인에 대한 DNS 전달 구성에는 /etc/resolv.conf 파일과 업스트림 DNS 서버에 기본 서버가 모두 지정될 수 있습니다.

절차

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

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    이전 명령을 실행한 후 Operator는 서버를 기반으로 추가 서버 구성 블록을 사용하여 dns-default 라는 구성 맵을 생성하고 업데이트합니다. 서버에 쿼리와 일치하는 영역이 없으면 이름 확인이 업스트림 DNS 서버로 대체됩니다.

    DNS 전달 구성

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: example-server 
    1
    
        zones: 
    2
    
        - example.com
        forwardPlugin:
          policy: Random 
    3
    
          upstreams: 
    4
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    5
    
        policy: Random 
    6
    
        upstreams: 
    7
    
        - type: SystemResolvConf 
    8
    
        - type: Network
          address: 1.2.3.4 
    9
    
          port: 53 
    10
    Copy to Clipboard Toggle word wrap

    1
    rfc6335 서비스 이름 구문을 준수해야 합니다.
    2
    rfc1123 서비스 이름 구문에 있는 하위 도메인 정의를 준수해야 합니다. 클러스터 도메인 cluster.localzones 필드에 유효하지 않은 하위 도메인입니다.
    3
    업스트림 리졸버를 선택하는 정책을 정의합니다. 기본값은 Random 입니다. RoundRobinSequential 값을 사용할 수도 있습니다.
    4
    forwardPlugin당 최대 15개의 업스트림이 허용됩니다.
    5
    선택 사항: 이를 사용하여 기본 정책을 재정의하고 기본 도메인에 대해 지정된 DNS 확인자(업스트림 확인자)로 DNS 확인을 전달할 수 있습니다. 업스트림 리졸버를 제공하지 않으면 DNS 이름 쿼리는 /etc/resolv.conf 의 서버로 이동합니다.
    6
    업스트림 서버를 쿼리하기 위해 선택한 순서를 결정합니다. 다음 값 중 하나를 지정할 수 있습니다. Random,RoundRobin, 또는 Sequential. 기본값은 Sequential 입니다.
    7
    선택 사항: 이를 사용하여 업스트림 리졸버를 제공할 수 있습니다.
    8
    업스트림의 두 가지 유형인 SystemResolvConfNetwork 를 지정할 수 있습니다. SystemResolvConf/etc/resolv.conf 를 사용하도록 업스트림을 구성하고 Network resolver 를 정의합니다. 둘 중 하나 또는 둘 다를 지정할 수 있습니다.
    9
    지정된 유형이 네트워크 이면 IP 주소를 제공해야 합니다. address 필드는 유효한 IPv4 또는 IPv6 주소여야 합니다.
    10
    지정된 유형이 네트워크 이면 선택적으로 포트를 제공할 수 있습니다. port 필드에는 1 에서 65535 사이의 값이 있어야 합니다. 업스트림의 포트를 지정하지 않으면 기본적으로 포트 853이 시도됩니다.
  2. 선택 사항: 고도로 규제된 환경에서 작업할 때 추가 DNS 트래픽 및 데이터 개인 정보를 보장할 수 있도록 요청을 업스트림 해석기로 전달할 때 DNS 트래픽을 보호할 수 있는 기능이 필요할 수 있습니다. 클러스터 관리자는 전달된 DNS 쿼리에 대해 TLS(Transport Layer Security)를 구성할 수 있습니다.

    TLS를 사용하여 DNS 전달 구성

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: example-server 
    1
    
        zones: 
    2
    
        - example.com
        forwardPlugin:
          transportConfig:
            transport: TLS 
    3
    
            tls:
              caBundle:
                name: mycacert
              serverName: dnstls.example.com  
    4
    
          policy: Random 
    5
    
          upstreams: 
    6
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    7
    
        transportConfig:
          transport: TLS
          tls:
            caBundle:
              name: mycacert
            serverName: dnstls.example.com
        upstreams:
        - type: Network 
    8
    
          address: 1.2.3.4 
    9
    
          port: 53 
    10
    Copy to Clipboard Toggle word wrap

    1
    rfc6335 서비스 이름 구문을 준수해야 합니다.
    2
    rfc1123 서비스 이름 구문에 있는 하위 도메인 정의를 준수해야 합니다. 클러스터 도메인 cluster.localzones 필드에 유효하지 않은 하위 도메인입니다. 클러스터 도메인에 해당하는 cluster.local영역에 유효하지 않은 하위 도메인입니다.
    3
    전달된 DNS 쿼리에 대해 TLS를 구성할 때 전송 필드를 값 TLS 를 갖도록 설정합니다. 기본적으로 CoreDNS 캐시는 10초 동안 연결을 전달합니다. CoreDNS는 요청이 발행되지 않은 경우 10초 동안 TCP 연결을 엽니다. 대규모 클러스터에서는 노드당 연결을 시작할 수 있으므로 DNS 서버에서 많은 새 연결을 유지할 수 있는지 확인합니다. 성능 문제가 발생하지 않도록 DNS 계층을 적절하게 설정합니다.
    4
    전달된 DNS 쿼리에 대해 TLS를 구성할 때 이는 업스트림 TLS 서버 인증서의 유효성을 확인하기 위해 SNI(서버 이름 표시)의 일부로 사용되는 필수 서버 이름입니다.
    5
    업스트림 리졸버를 선택하는 정책을 정의합니다. 기본값은 Random 입니다. RoundRobinSequential 값을 사용할 수도 있습니다.
    6
    필수 항목입니다. 이를 사용하여 업스트림 리졸버를 제공할 수 있습니다. forwardPlugin 항목당 최대 15 개의 업스트림 항목이 허용됩니다.
    7
    선택 사항: 이를 사용하여 기본 정책을 재정의하고 기본 도메인에 대해 지정된 DNS 확인자(업스트림 확인자)로 DNS 확인을 전달할 수 있습니다. 업스트림 리졸버를 제공하지 않으면 DNS 이름 쿼리는 /etc/resolv.conf 의 서버로 이동합니다.
    8
    네트워크 유형은 이 업스트림 리졸버가 /etc/resolv.conf 에 나열된 업스트림 리졸버와 별도로 전달된 요청을 처리해야 함을 나타냅니다. TLS를 사용할 때 네트워크 유형만 허용되며 IP 주소를 제공해야 합니다.
    9
    address 필드는 유효한 IPv4 또는 IPv6 주소여야 합니다.
    10
    선택적으로 포트를 제공할 수 있습니다. 포트 의 값은 1 에서 65535 사이여야 합니다. 업스트림의 포트를 지정하지 않으면 기본적으로 포트 853이 시도됩니다.
    참고

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

검증

  1. 구성 맵을 표시합니다.

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

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

    apiVersion: v1
    data:
      Corefile: |
        example.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 1.2.3.4:53 {
                policy Random
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns
    Copy to Clipboard Toggle word wrap

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

6.6. DNS Operator 상태

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

프로세스

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

$ oc describe clusteroperators/dns
Copy to Clipboard Toggle word wrap

6.7. DNS Operator 로그

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

프로세스

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

$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
Copy to Clipboard Toggle word wrap

6.8. CoreDNS 로그 수준 설정

로깅된 오류 메시지의 세부 사항을 결정하도록 CoreDNS 로그 수준을 구성할 수 있습니다. CoreDNS 로그 수준에 유효한 값은 정상,디버그, 추적 입니다. 기본 logLevelNormal 입니다.

참고

오류 플러그인은 항상 활성화되어 있습니다. 다음 logLevel 설정은 다른 오류 응답을 보고합니다.

  • log level :Normal 은 "errors" class: log . { class error } 를 활성화합니다.
  • log level :Debug 를 사용하면 "denial" class: log . { class denial error } }를 사용할 수 있습니다.
  • log level :Trace 는 "all" class: log . { class all } 를 활성화합니다.

절차

  • logLevelDebug 로 설정하려면 다음 명령을 입력합니다.

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • logLevelTrace 로 설정하려면 다음 명령을 입력합니다.

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

검증

  • 원하는 로그 수준이 설정되었는지 확인하려면 구성 맵을 확인합니다.

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

6.9. CoreDNS Operator 로그 수준 설정

클러스터 관리자는 OpenShift DNS 문제를 더 빠르게 추적하도록 Operator 로그 수준을 구성할 수 있습니다. operatorLogLevel 의 유효한 값은 Normal,Debug, and Trace 입니다. 추적에 가장 자세한 정보가 있습니다. 기본 operatorlogLevelNormal 입니다. 추적, 디버그, 정보, 경고, 오류, 치명적 및 패닉의 7 가지 로깅 수준이 있습니다. 로깅 수준이 설정되면 해당 심각도 또는 위의 항목이 있는 로그 항목이 기록됩니다.

  • operatorLogLevel: "Normal"logrus.SetLogLevel("Info") 을 설정합니다.
  • operatorLogLevel: "Debug"logrus.SetLogLevel("Debug") 을 설정합니다.
  • operatorLogLevel: "Trace"logrus.SetLogLevel("Trace") 을 설정합니다.

절차

  • operatorLogLevelDebug 로 설정하려면 다음 명령을 입력합니다.

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • operatorLogLevelTrace 로 설정하려면 다음 명령을 입력합니다.

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

6.10. CoreDNS 캐시 튜닝

CoreDNS에서 수행하는 각각 양수 또는 음수 캐싱이라고도 하는 성공적인 캐싱 또는 실패한 캐싱의 최대 기간을 구성할 수 있습니다. DNS 쿼리 응답의 캐싱 기간을 조정하면 업스트림 DNS 확인 프로그램의 부하를 줄일 수 있습니다.

절차

  1. 다음 명령을 실행하여 default 라는 DNS Operator 오브젝트를 편집합니다.

    $ oc edit dns.operator.openshift.io/default
    Copy to Clipboard Toggle word wrap
  2. TTL(Time-to-live) 캐싱 값을 수정합니다.

    DNS 캐싱 구성

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        positiveTTL: 1h 
    1
    
        negativeTTL: 0.5h10m 
    2
    Copy to Clipboard Toggle word wrap

    1
    문자열 값 1h 는 CoreDNS에서 해당 초 수로 변환됩니다. 이 필드를 생략하면 값이 0s 로 간주되고 클러스터는 내부 기본값 900s 를 대체 값으로 사용합니다.
    2
    문자열 값은 0.5h10m 과 같은 단위의 조합일 수 있으며 CoreDNS에서 해당 초 수로 변환됩니다. 이 필드를 생략하면 값이 0s 로 간주되고 클러스터는 내부 기본값인 30s 를 대체 값으로 사용합니다.
    주의

    TTL 필드를 낮은 값으로 설정하면 클러스터의 부하 증가, 모든 업스트림 리졸버 또는 둘 다 발생할 수 있습니다.

7장. OpenShift Container Platform에서의 Ingress Operator

7.1. OpenShift Container Platform Ingress Operator

OpenShift Container Platform 클러스터를 생성할 때 클러스터에서 실행되는 Pod 및 서비스에는 각각 자체 IP 주소가 할당됩니다. IP 주소는 내부에서 실행되지만 외부 클라이언트가 액세스할 수 없는 다른 pod 및 서비스에 액세스할 수 있습니다. Ingress Operator는 IngressController API를 구현하며 OpenShift Container Platform 클러스터 서비스에 대한 외부 액세스를 활성화하는 구성 요소입니다.

Ingress Operator를 사용하면 라우팅을 처리하기 위해 하나 이상의 HAProxy 기반 Ingress 컨트롤러를 배포하고 관리하여 외부 클라이언트가 서비스에 액세스할 수 있습니다. Ingress Operator를 사용하여 OpenShift 컨테이너 플랫폼 Route 및 Kubernetes Ingress 리소스를 지정하면 수신 트래픽을 라우팅할 수 있습니다. endpointPublishingStrategy 유형 및 내부 로드 밸런싱을 정의하는 기능과 같은 Ingress 컨트롤러 내 구성은 Ingress 컨트롤러 끝점을 게시하는 방법을 제공합니다.

7.2. 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
Copy to Clipboard Toggle word wrap

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

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

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

IngressController CR(사용자 정의 리소스)에는 조직의 특정 요구 사항을 충족하도록 구성할 수 있는 선택적 구성 매개변수가 포함되어 있습니다.

Expand
매개변수설명

domain

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

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

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

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

replicas

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

endpointPublishingStrategy

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

클라우드 환경의 경우 loadBalancer 필드를 사용하여 Ingress 컨트롤러에 대한 끝점 게시 전략을 구성합니다.

GCP, AWS 및 Azure에서 다음 endpointPublishingStrategy 필드를 구성할 수 있습니다.

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

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

  • AWS(Amazon Web Services): LoadBalancerService (외부 범위 포함)
  • Azure: LoadBalancerService (외부 범위 포함)
  • GCP(Google Cloud Platform): LoadBalancerService (외부 범위 포함)

대부분의 플랫폼의 경우 endpointPublishingStrategy 값을 업데이트할 수 있습니다. GCP에서 다음 endpointPublishingStrategy 필드를 구성할 수 있습니다.

  • loadBalancer.scope
  • loadbalancer.providerParameters.gcp.clientAccess

베어 메탈 플랫폼과 같은 클라우드 이외의 환경의 경우 NodePortService,HostNetwork 또는 Private 필드를 사용하여 Ingress 컨트롤러에 대한 끝점 게시 전략을 구성합니다.

이러한 필드 중 하나에 값을 설정하지 않으면 기본값은 IngressController CR의 .status.platform 값에 지정된 바인딩 포트를 기반으로 합니다.

클러스터가 배포된 후 endpointPublishingStrategy 값을 업데이트해야 하는 경우 다음 endpointPublishingStrategy 필드를 구성할 수 있습니다.

  • hostNetwork.protocol
  • nodePort.protocol
  • private.protocol

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:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists
Copy to Clipboard Toggle word wrap

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.3입니다.

참고

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

중요

Ingress Operator는 Old 또는 Custom 프로파일의 TLS 1.01.1 로 변환합니다.

clientTLS

clientTLS는 클러스터 및 서비스에 대한 클라이언트 액세스를 인증하므로 상호 TLS 인증이 활성화됩니다. 설정되지 않은 경우 클라이언트 TLS가 활성화되지 않습니다.

clientTLS에는 필수 하위 필드인 spec.clientTLS.clientCertificatePolicyspec.clientTLS.ClientCA가 있습니다.

ClientCertificatePolicy 하위 필드는 Required 또는 Optional 이라는 두 값 중 하나를 허용합니다. ClientCA 하위 필드는 openshift-config 네임스페이스에 있는 구성 맵을 지정합니다. 구성 맵에는 CA 인증서 번들이 포함되어야 합니다.

AllowedSubjectPatterns는 요청을 필터링할 유효한 클라이언트 인증서의 고유 이름과 일치하는 정규식 목록을 지정하는 선택적 값입니다. 정규 표현식은 PCRE 구문을 사용해야 합니다. 클라이언트 인증서의 고유 이름과 하나 이상의 패턴이 일치해야 합니다. 그러지 않으면 Ingress 컨트롤러에서 인증서를 거부하고 연결을 거부합니다. 지정하지 않으면 Ingress 컨트롤러에서 고유 이름을 기반으로 인증서를 거부하지 않습니다.

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 포트 번호입니다.
        • maxLength 는 syslog 메시지의 최대 길이입니다. 480 에서 4096 바이트 사이여야 합니다. 이 필드가 비어 있으면 최대 길이는 기본값 1024 바이트로 설정됩니다.
        • 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 응답에 적용됩니다. 이 필드가 비어 있으면 요청 헤더가 조정되지 않습니다.

httpCompression

httpCompression 은 HTTP 트래픽 압축 정책을 정의합니다.

  • Mimetypes 는 압축을 적용해야 하는 MIME 유형 목록을 정의합니다. 예를 들어, text/css;knativeset=utf-8,text/html,text/*, image/svg+xml,application/octet-stream,X-custom/customsub, 형식 패턴을 사용하여 type/subtype; [;attribute=value]. 형식은 다음과 같습니다. application, image, message, multipart, text, video, or a custom type prefaced by X-; 예를 들어 MIME 유형 및 하위 유형에 대한 전체 표기법을 보려면 RFC1341을 참조하십시오.

httpErrorCodePages

httpErrorCodePages는 사용자 정의 HTTP 오류 코드 응답 페이지를 지정합니다. 기본적으로 IngressController는 IngressController 이미지에 빌드된 오류 페이지를 사용합니다.

httpCaptureCookies

httpCapECDHECookies 는 액세스 로그에서 캡처하려는 HTTP 쿠키를 지정합니다. httpCapECDHECookies 필드가 비어 있으면 액세스 로그에서 쿠키를 캡처하지 않습니다.

캡처하려는 모든 쿠키의 경우 다음 매개변수는 IngressController 구성에 있어야 합니다.

  • name 은 쿠키 이름을 지정합니다.
  • MaxLength 는 쿠키의 최대 길이를 지정합니다.
  • matchType 은 쿠키의 필드 이름이 캡처 쿠키 설정과 정확히 일치하는지 또는 캡처 쿠키 설정의 접두사인지 지정합니다. matchType 필드는 ExactPrefix 매개변수를 사용합니다.

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

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE
Copy to Clipboard Toggle word wrap

httpCaptureHeaders

httpCapECDHEHeaders 는 액세스 로그에서 캡처할 HTTP 헤더를 지정합니다. httpCapECDHEHeaders 필드가 비어 있으면 액세스 로그에서 헤더를 캡처하지 않습니다.

httpCapECDHEHeaders 에는 액세스 로그에서 캡처할 두 개의 헤더 목록이 포함되어 있습니다. 두 헤더 필드 목록은 requestresponse 입니다. 두 목록 모두에서 name 필드는 헤더 이름을 지정해야 하며 maxlength 필드는 헤더의 최대 길이를 지정해야 합니다. 예를 들면 다음과 같습니다.

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length
Copy to Clipboard Toggle word wrap

tuningOptions

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

  • clientFinTimeout은 연결을 닫는 서버에 대한 클라이언트 응답을 기다리는 동안 연결이 열린 상태로 유지되는 시간을 지정합니다. 기본 타임아웃은 1s 입니다.
  • ClientTimeout은 클라이언트 응답을 기다리는 동안 연결이 열린 상태로 유지되는 시간을 지정합니다. 기본 제한 시간은 30s 입니다.
  • headerBufferBytes는 Ingress 컨트롤러 연결 세션에 대해 예약된 메모리 양을 바이트 단위로 지정합니다. Ingress 컨트롤러에 HTTP/2가 활성화된 경우 이 값은 16384 이상이어야 합니다. 설정되지 않은 경우, 기본값은 32768 바이트입니다. headerBufferBytes 값이 너무 작으면 Ingress 컨트롤러가 손상될 수 있으며 headerBufferBytes 값이 너무 크면 Ingress 컨트롤러가 필요 이상으로 많은 메모리를 사용할 수 있기 때문에 이 필드를 설정하지 않는 것이 좋습니다.
  • headerBufferMaxRewriteBytes는 HTTP 헤더 재작성 및 Ingress 컨트롤러 연결 세션에 대한 headerBufferBytes의 바이트 단위로 예약해야 하는 메모리 양을 지정합니다. headerBufferMaxRewriteBytes의 최소 값은 4096입니다. headerBufferBytes는 들어오는 HTTP 요청에 대해 headerBufferMaxRewriteBytes보다 커야 합니다. 설정되지 않은 경우, 기본값은 8192 바이트입니다. headerBufferMaxRewriteBytes 값이 너무 작으면 Ingress 컨트롤러가 손상될 수 있으며 headerBufferMaxRewriteBytes 값이 너무 크면 Ingress 컨트롤러가 필요 이상으로 많은 메모리를 사용할 수 있기 때문에 이 필드를 설정하지 않는 것이 좋습니다.
  • healthCheckInterval 은 라우터가 상태 점검 간에 대기하는 시간을 지정합니다. 기본값은 5s입니다.
  • serverFinTimeout은 연결을 종료하는 클라이언트에 대한 서버 응답을 기다리는 동안 연결이 열린 상태로 유지되는 시간을 지정합니다. 기본 타임아웃은 1s 입니다.
  • ServerTimeout은 서버 응답을 기다리는 동안 연결이 열린 상태로 유지되는 시간을 지정합니다. 기본 제한 시간은 30s 입니다.
  • threadCount는 HAProxy 프로세스별로 생성할 스레드 수를 지정합니다. 더 많은 스레드를 생성하면 각 Ingress 컨트롤러 Pod가 더 많은 시스템 리소스 비용으로 더 많은 연결을 처리할 수 있습니다. HAProxy는 최대 64개의 스레드를 지원합니다. 이 필드가 비어 있으면 Ingress 컨트롤러는 기본값 4 스레드를 사용합니다. 기본값은 향후 릴리스에서 변경될 수 있습니다. HAProxy 스레드 수를 늘리면 Ingress 컨트롤러 Pod에서 부하에 더 많은 CPU 시간을 사용할 수 있고 다른 Pod에서 수행해야 하는 CPU 리소스를 수신하지 못하므로 이 필드를 설정하지 않는 것이 좋습니다. 스레드 수를 줄이면 Ingress 컨트롤러가 제대로 작동하지 않을 수 있습니다.
  • tlsInspectDelay는 라우터에서 일치하는 경로를 찾기 위해 데이터를 보유할 수 있는 기간을 지정합니다. 이 값을 너무 짧게 설정하면 라우터가 더 나은 일치 인증서를 사용하는 경우에도 에지 종료, 재암호화 또는 패스스루 경로를 위해 기본 인증서로 대체될 수 있습니다. 기본 검사 지연은 5s 입니다.
  • tunnelTimeout은 터널이 유휴 상태일 때 웹소켓을 포함한 터널 연결이 열린 상태로 유지되는 시간을 지정합니다. 기본 제한 시간은 1h 입니다.
  • maxConnections 는 HAProxy 프로세스별로 설정할 수 있는 최대 동시 연결 수를 지정합니다. 이 값을 늘리면 각 Ingress 컨트롤러 Pod에서 추가 시스템 리소스 비용으로 더 많은 연결을 처리할 수 있습니다. 허용되는 값은 0,-1, 범위 내의 모든 값 20002000000 또는 필드를 비워 둘 수 있습니다.

    • 이 필드가 비어 있거나 값이 0 인 경우 Ingress 컨트롤러에서 기본값 50000 을 사용합니다. 이 값은 향후 릴리스에서 변경될 수 있습니다.
    • 필드에 -1 값이 있는 경우 HAProxy는 실행 중인 컨테이너에서 사용 가능한 ulimits 에 따라 최대값을 동적으로 계산합니다. 이 프로세스로 인해 대규모 계산 값이 생성되어 현재 기본값 50000 에 비해 메모리 사용량이 많이 발생합니다.
    • 필드에 현재 운영 체제 제한보다 큰 값이 있는 경우 HAProxy 프로세스가 시작되지 않습니다.
    • 이산 값을 선택하고 라우터 Pod가 새 노드로 마이그레이션되면 새 노드에 동일한 ulimit 가 구성되어 있지 않을 수 있습니다. 이러한 경우 Pod가 시작되지 않습니다.
    • ulimits 가 다른 노드가 구성되어 있고 이산 값을 선택하는 경우 런타임에 최대 연결 수를 계산하도록 이 필드에 -1 값을 사용하는 것이 좋습니다.

logEmptyRequests

logEmptyRequests는 요청이 수신 및 기록되지 않은 연결을 지정합니다. 이러한 빈 요청은 로드 밸런서 상태 프로브 또는 웹 브라우저 추측 연결(사전 연결)에서 발생하며 이러한 요청을 로깅하는 것은 바람직하지 않을 수 있습니다. 이러한 빈 요청은 로드 밸런서 상태 프로브 또는 웹 브라우저 추측 연결(사전 연결)에서 발생하며 이러한 요청을 로깅하는 것은 바람직하지 않을 수 있습니다. 이러한 요청은 포트 검색으로 인해 발생할 수 있으며 빈 요청을 로깅하면 침입 시도를 감지하는 데 도움이 될 수 있습니다. 이 필드에 허용되는 값은 LogIgnore 입니다. 기본값은 Log 입니다.

LoggingPolicy 유형은 다음 두 값 중 하나를 허용합니다.

  • Log: 이 값을 Log로 설정하면 이벤트가 로깅되어야 함을 나타냅니다.
  • ignore: 이 값을 Ignore 로 설정하면 HAproxy 구성에서 dontlognull 옵션이 설정됩니다.

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy는 요청을 수신하기 전에 연결 시간이 초과된 경우 HTTP 연결이 처리되는 방법을 설명합니다.. 이 필드에 허용되는 값은 RespondIgnore입니다. 기본값은 Respond입니다.

HTTPEmptyRequestsPolicy 유형은 다음 두 값 중 하나를 허용합니다.

  • Response: 필드가 Respond로 설정된 경우 Ingress 컨트롤러는 HTTP 400 또는 408 응답을 전송하고 액세스 로깅이 활성화된 경우 연결을 로깅한 다음 적절한 메트릭의 연결을 계산합니다.
  • ignore: 이 옵션을 Ignore로 설정하면 HAproxy 구성에 http-ignore-probes 매개변수가 추가됩니다. 필드가 Ignore 로 설정된 경우 Ingress 컨트롤러는 응답을 전송하지 않고 연결을 종료한 다음 연결을 기록하거나 메트릭을 늘립니다.

이러한 연결은 로드 밸런서 상태 프로브 또는 웹 브라우저 추측 연결(preconnect)에서 제공되며 무시해도 됩니다. 그러나 이러한 요청은 네트워크 오류로 인해 발생할 수 있으므로 이 필드를 Ignore로 설정하면 문제를 탐지하고 진단할 수 있습니다. 이러한 요청은 포트 검색으로 인해 발생할 수 있으며, 이 경우 빈 요청을 로깅하면 침입 시도를 탐지하는 데 도움이 될 수 있습니다.

7.3.1. Ingress 컨트롤러 TLS 보안 프로필

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

7.3.1.1. TLS 보안 프로필 이해

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

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

Expand
표 7.1. TLS 보안 프로필
Profile설명

Old

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

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

참고

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

Intermediate

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

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

Modern

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

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

사용자 지정

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

주의

Custom 프로파일을 사용할 때는 잘못된 구성으로 인해 문제가 발생할 수 있으므로 주의해야 합니다.

참고

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

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

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

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

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...
Copy to Clipboard Toggle word wrap

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

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

참고

HAProxy Ingress 컨트롤러 이미지는 TLS 1.3Modern 프로필을 지원합니다.

Ingress Operator는 Old 또는 Custom 프로파일의 TLS 1.01.1로 변환합니다.

사전 요구 사항

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

프로세스

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

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  2. spec.tlsSecurityProfile 필드를 추가합니다.

    Custom 프로필에 대한 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
     ...
    Copy to Clipboard Toggle word wrap

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

검증

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

    $ oc describe IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    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
     ...
    Copy to Clipboard Toggle word wrap

7.3.1.3. 상호 TLS 인증 구성

spec.clientTLS 값을 설정하여 mTLS(mTLS) 인증을 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다. clientTLS 값은 클라이언트 인증서를 확인하도록 Ingress 컨트롤러를 구성합니다. 이 구성에는 구성 맵에 대한 참조인 clientCA 값 설정이 포함됩니다. 구성 맵에는 클라이언트의 인증서를 확인하는 데 사용되는 PEM 인코딩 CA 인증서 번들이 포함되어 있습니다. 필요한 경우 인증서 주체 필터 목록을 구성할 수도 있습니다.

clientCA 값이 X509v3 인증서 취소 목록(CRL) 배포 지점을 지정하는 경우 Ingress Operator는 제공된 각 인증서에 지정된 HTTP URI X509v3 CRL 배포 포인트를 기반으로 CRL 구성 맵을 다운로드하고 관리합니다. Ingress 컨트롤러는 mTLS/TLS 협상 중에 이 구성 맵을 사용합니다. 유효한 인증서를 제공하지 않는 요청은 거부됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • PEM 인코딩 CA 인증서 번들이 있습니다.
  • CA 번들이 CRL 배포 지점을 참조하는 경우 클라이언트 CA 번들에 end-entity 또는 leaf 인증서도 포함되어 있어야 합니다. 이 인증서에는 RFC 5280에 설명된 대로 CRL 배포 포인트 아래에 HTTP URI가 포함되어야 합니다. 예를 들면 다음과 같습니다.

     Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
             Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                    Full Name:
                      URI:http://crl.example.com/example.crl
    Copy to Clipboard Toggle word wrap

절차

  1. openshift-config 네임스페이스에서 CA 번들에서 구성 맵을 생성합니다.

    $ oc create configmap \
       router-ca-certs-default \
       --from-file=ca-bundle.pem=client-ca.crt \
    1
    
       -n openshift-config
    Copy to Clipboard Toggle word wrap
    1
    구성 맵 데이터 키는 ca-bundle.pem이어야 하며 데이터 값은 PEM 형식의 CA 인증서여야 합니다.
  2. openshift-ingress-operator 프로젝트에서 IngressController 리소스를 편집합니다.

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  3. spec.clientTLS 필드 및 하위 필드를 추가하여 상호 TLS를 구성합니다.

    패턴 필터링을 지정하는 clientTLS 프로필에 대한 IngressController CR 샘플

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        clientTLS:
          clientCertificatePolicy: Required
          clientCA:
            name: router-ca-certs-default
          allowedSubjectPatterns:
          - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
    Copy to Clipboard Toggle word wrap

  4. 선택 사항, 다음 명령을 입력하여 allowedSubjectPatterns 에 대한 Distinguished Name (DN)을 가져옵니다.
$ openssl  x509 -in custom-cert.pem  -noout -subject
subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift
Copy to Clipboard Toggle word wrap

7.4. 기본 Ingress 컨트롤러 보기

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

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

프로세스

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

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
    Copy to Clipboard Toggle word wrap

7.5. Ingress Operator 상태 보기

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

프로세스

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

    $ oc describe clusteroperators/ingress
    Copy to Clipboard Toggle word wrap

7.6. Ingress 컨트롤러 로그 보기

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

프로세스

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

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
    Copy to Clipboard Toggle word wrap

7.7. Ingress 컨트롤러 상태 보기

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

프로세스

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

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
    Copy to Clipboard Toggle word wrap

7.8. Ingress 컨트롤러 구성

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

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

사전 요구 사항

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

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

    $ oc --namespace openshift-ingress-operator get ingresscontrollers
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      AGE
    default   10m
    Copy to Clipboard Toggle word wrap

참고

임시 인증서가 있는 경우 사용자 정의 기본 인증서가 포함 된 보안의 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
    Copy to Clipboard Toggle word wrap
  2. 새 인증서 보안 키를 참조하도록 IngressController CR을 업데이트합니다.

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

    $ echo Q |\
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <domain>
    클러스터의 기본 도메인 이름을 지정합니다.

    출력 예

    subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
    issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
    notAfter=May 10 08:32:45 2022 GM
    Copy to Clipboard Toggle word wrap

    작은 정보

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default
    Copy to Clipboard Toggle word wrap

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

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

7.8.2. 사용자 정의 기본 인증서 제거

관리자는 사용할 Ingress 컨트롤러를 구성한 사용자 정의 인증서를 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 이전에 Ingress 컨트롤러에 대한 사용자 정의 기본 인증서를 구성했습니다.

절차

  • 사용자 정의 인증서를 제거하고 OpenShift Container Platform과 함께 제공된 인증서를 복원하려면 다음 명령을 입력합니다.

    $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
      --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
    Copy to Clipboard Toggle word wrap

    클러스터가 새 인증서 구성을 조정하는 동안 지연될 수 있습니다.

검증

  • 원래 클러스터 인증서가 복원되었는지 확인하려면 다음 명령을 입력합니다.

    $ echo Q | \
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <domain>
    클러스터의 기본 도메인 이름을 지정합니다.

    출력 예

    subject=CN = *.apps.<domain>
    issuer=CN = ingress-operator@1620633373
    notAfter=May 10 10:44:36 2023 GMT
    Copy to Clipboard Toggle word wrap

7.8.3. Ingress 컨트롤러 자동 스케일링

처리량 증가 요구와 같은 라우팅 성능 또는 가용성 요구 사항을 동적으로 충족하도록 Ingress 컨트롤러를 자동으로 확장할 수 있습니다.

다음 절차에서는 기본 Ingress 컨트롤러를 확장하는 예제를 제공합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있어야 합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • Custom Metrics Autoscaler Operator 및 관련 KEDA 컨트롤러가 설치되어 있습니다.

    • 웹 콘솔에서 OperatorHub를 사용하여 Operator를 설치할 수 있습니다. Operator를 설치한 후 KedaController 의 인스턴스를 생성할 수 있습니다.

절차

  1. 다음 명령을 실행하여 Thanos로 인증할 서비스 계정을 생성합니다.

    $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                thanos
    Namespace:           openshift-ingress-operator
    Labels:              <none>
    Annotations:         <none>
    Image pull secrets:  thanos-dockercfg-kfvf2
    Mountable secrets:   thanos-dockercfg-kfvf2
    Tokens:              thanos-token-c422q
    Events:              <none>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 사용하여 서비스 계정 시크릿 토큰을 수동으로 생성합니다.

    $ oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-token
      namespace: openshift-ingress-operator
      annotations:
        kubernetes.io/service-account.name: thanos
    type: kubernetes.io/service-account-token
    EOF
    Copy to Clipboard Toggle word wrap
  3. 서비스 계정의 토큰을 사용하여 openshift-ingress-operator 네임스페이스에 TriggerAuthentication 오브젝트를 정의합니다.

    1. 다음 명령을 실행하여 보안이 포함된 시크릿 변수를 정의합니다.

      $ secret=$(oc get secret -n openshift-ingress-operator | grep thanos-token | head -n 1 | awk '{ print $1 }')
      Copy to Clipboard Toggle word wrap
    2. TriggerAuthentication 오브젝트를 생성하고 secret 변수의 값을 TOKEN 매개변수에 전달합니다.

      $ oc process TOKEN="$secret" -f - <<EOF | oc apply -n openshift-ingress-operator -f -
      apiVersion: template.openshift.io/v1
      kind: Template
      parameters:
      - name: TOKEN
      objects:
      - apiVersion: keda.sh/v1alpha1
        kind: TriggerAuthentication
        metadata:
          name: keda-trigger-auth-prometheus
        spec:
          secretTargetRef:
          - parameter: bearerToken
            name: \${TOKEN}
            key: token
          - parameter: ca
            name: \${TOKEN}
            key: ca.crt
      EOF
      Copy to Clipboard Toggle word wrap
  4. Thanos에서 메트릭을 읽는 역할을 생성하고 적용합니다.

    1. Pod 및 노드에서 지표를 읽는 os-metrics-reader.yaml 보다 새 역할을 생성합니다.

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 새 역할을 적용합니다.

      $ oc apply -f thanos-metrics-reader.yaml
      Copy to Clipboard Toggle word wrap
  5. 다음 명령을 입력하여 서비스 계정에 새 역할을 추가합니다.

    $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
    $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
    Copy to Clipboard Toggle word wrap
    참고

    인수 add-cluster-role-to-user 는 네임스페이스 간 쿼리를 사용하는 경우에만 필요합니다. 다음 단계에서는 이 인수가 필요한 kube-metrics 네임스페이스의 쿼리를 사용합니다.

  6. 기본 Ingress 컨트롤러 배포를 대상으로 하는 새 scaledObject YAML 파일 ingress-autoscaler.yaml 을 생성합니다.

    scaledObject 정의의 예

    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: ingress-scaler
      namespace: openshift-ingress-operator
    spec:
      scaleTargetRef: 
    1
    
        apiVersion: operator.openshift.io/v1
        kind: IngressController
        name: default
        envSourceContainerName: ingress-operator
      minReplicaCount: 1
      maxReplicaCount: 20 
    2
    
      cooldownPeriod: 1
      pollingInterval: 1
      triggers:
      - type: prometheus
        metricType: AverageValue
        metadata:
          serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 
    3
    
          namespace: openshift-ingress-operator 
    4
    
          metricName: 'kube-node-role'
          threshold: '1'
          query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 
    5
    
          authModes: "bearer"
        authenticationRef:
          name: keda-trigger-auth-prometheus
    Copy to Clipboard Toggle word wrap

    1
    대상으로 지정하려는 사용자 정의 리소스입니다. 이 경우 Ingress 컨트롤러가 사용됩니다.
    2
    선택사항: 최대 복제본 수입니다. 이 필드를 생략하면 기본 최대값은 100개의 복제본으로 설정됩니다.
    3
    openshift-monitoring 네임스페이스의 Thanos 서비스 끝점입니다.
    4
    Ingress Operator 네임스페이스입니다.
    5
    이 표현식은 배포된 클러스터에 있는 다수의 작업자 노드로 평가됩니다.
    중요

    네임스페이스 간 쿼리를 사용하는 경우 serverAddress 필드에서 포트 9092가 아닌 포트 9091을 대상으로 해야 합니다. 또한 이 포트에서 메트릭을 읽을 수 있는 승격된 권한이 있어야 합니다.

  7. 다음 명령을 실행하여 사용자 정의 리소스 정의를 적용합니다.

    $ oc apply -f ingress-autoscaler.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 kube-state-metrics 쿼리에서 반환된 값과 일치하도록 기본 Ingress 컨트롤러가 확장되었는지 확인합니다.

    • grep 명령을 사용하여 Ingress 컨트롤러 YAML 파일에서 복제를 검색합니다.

      $ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
      Copy to Clipboard Toggle word wrap

      출력 예

        replicas: 3
      Copy to Clipboard Toggle word wrap

    • openshift-ingress 프로젝트에서 Pod를 가져옵니다.

      $ oc get pods -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                             READY   STATUS    RESTARTS   AGE
      router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
      router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
      router-default-7b5df44ff-wwsth   2/2     Running   0          66s
      Copy to Clipboard Toggle word wrap

7.8.4. Ingress 컨트롤러 확장

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

참고

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

프로세스

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

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap

    출력 예

    2
    Copy to Clipboard Toggle word wrap

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

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
    Copy to Clipboard Toggle word wrap

    출력 예

    ingresscontroller.operator.openshift.io/default patched
    Copy to Clipboard Toggle word wrap

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

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap

    출력 예

    3
    Copy to Clipboard Toggle word wrap

    작은 정보

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

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

7.8.5. 수신 액세스 로깅 구성

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
      logging:
        access:
          destination:
            type: Container
    Copy to Clipboard Toggle word wrap
  • 사이드카에 로그를 기록하도록 Ingress 컨트롤러를 구성하면 Operator는 Ingress 컨트롤러 Pod에 logs 라는 컨테이너를 만듭니다.

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs
    Copy to Clipboard Toggle word wrap

    출력 예

    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"
    Copy to Clipboard Toggle word wrap

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
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
    Copy to Clipboard Toggle word wrap
    참고

    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
      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'
    Copy to Clipboard Toggle word wrap

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

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access: null
    Copy to Clipboard Toggle word wrap

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

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

사전 요구 사항

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

프로세스

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

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

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

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

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

주의

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

중요

IngressController범위를 변경하려면 CR(사용자 정의 리소스)을 생성한 후 .spec.endpointPublishingStrategy.loadBalancer.scope 매개변수를 변경할 수 있습니다.

그림 7.1. LoadBalancer 다이어그램

위의 그래픽에서는 OpenShift Container Platform Ingress LoadBalancerService 끝점 게시 전략과 관련된 다음 개념을 보여줍니다.

  • OpenShift Ingress 컨트롤러 로드 밸런서를 사용하여 클라우드 공급자 로드 밸런서를 사용하거나 내부적으로 로드 밸런싱할 수 있습니다.
  • 로드 밸런서의 단일 IP 주소와 그래픽에 표시된 클러스터에 표시된 대로 8080 및 4200과 같은 보다 친숙한 포트를 사용할 수 있습니다.
  • 외부 로드 밸런서의 트래픽은 Pod에서 전달되며 다운 노드의 인스턴스에 표시된 대로 로드 밸런서에 의해 관리됩니다. 구현 세부 사항은 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
    Copy to Clipboard Toggle word wrap
    1
    <name>IngressController 오브젝트의 이름으로 변경합니다.
    2
    컨트롤러가 게시한 애플리케이션의 domain을 지정합니다.
    3
    내부 로드 밸런서를 사용하려면 Internal 값을 지정합니다.
  2. 다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.

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

    $ oc --all-namespaces=true get ingresscontrollers
    Copy to Clipboard Toggle word wrap

7.8.8. 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
      Copy to Clipboard Toggle word wrap
    2. YAML 파일을 편집합니다.

      Global에 대한 clientAccess 구성 샘플

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 
      1
      
                type: GCP
              scope: Internal
            type: LoadBalancerService
      Copy to Clipboard Toggle word wrap

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

    $ oc -n openshift-ingress edit svc/router-default -o yaml
    Copy to Clipboard Toggle word wrap

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

7.8.9. Ingress 컨트롤러 상태 점검 간격 설정

클러스터 관리자는 상태 점검 간격을 설정하여 라우터가 연속된 상태 점검 사이에 대기하는 시간을 정의할 수 있습니다. 이 값은 모든 경로의 기본값으로 전역적으로 적용됩니다. 기본값은 5초입니다.

사전 요구 사항

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

절차

  • Ingress 컨트롤러를 업데이트하여 백엔드 상태 점검 간 간격을 변경합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
    Copy to Clipboard Toggle word wrap
    참고

    단일 경로의 healthCheckInterval 을 재정의하려면 경로 주석 router.openshift.io/haproxy.health.check.interval을 사용합니다.

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

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

주의

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

중요

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
    Copy to Clipboard Toggle word wrap

7.8.11. 경로 허용 정책 구성

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

주의

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

사전 요구 사항

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

프로세스

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

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    샘플 Ingress 컨트롤러 구성

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...
    Copy to Clipboard Toggle word wrap

    작은 정보

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    Copy to Clipboard Toggle word wrap

7.8.12. 와일드카드 경로 사용

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

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

프로세스

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

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

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    2. spec에서 wildcardPolicy 필드를 WildcardsDisallowed 또는 WildcardsAllowed로 설정합니다.

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
      Copy to Clipboard Toggle word wrap

7.8.13. X-Forwarded 헤더 사용

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

프로세스

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

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

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap
사용 사례 예

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

  • 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 주석을 설정할 수 있습니다.

7.8.14. 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 라우팅에는 적합하지 않음을 의미합니다.

주의

재암호화 경로가 있고 Ingress 컨트롤러에서 HTTP/2가 활성화된 WebSockets를 사용하려면 HTTP/2를 통한 WebSocket 지원이 필요합니다. HTTP/2 이상의 WebSocket은 현재 OpenShift Container Platform에서 지원되지 않는 HAProxy 2.4의 기능입니다.

중요

패스스루(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
    Copy to Clipboard Toggle word wrap

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

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

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

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    Copy to Clipboard Toggle word wrap
    작은 정보

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

    apiVersion: config.openshift.io/v1
    kind: Ingress
    metadata:
      name: cluster
      annotations:
        ingress.operator.openshift.io/default-enable-http2: "true"
    Copy to Clipboard Toggle word wrap

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

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

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

중요

PROXY 프로토콜을 사용하거나 TCP를 사용하도록 OpenShift Container Platform 및 외부 로드 밸런서를 둘 다 구성해야 합니다.

주의

PROXY 프로토콜은 Keepalived Ingress VIP를 사용하는 클라우드 이외의 플랫폼에서 설치 관리자 프로비저닝 클러스터를 사용하는 기본 Ingress 컨트롤러에서 지원되지 않습니다.

사전 요구 사항

  • Ingress 컨트롤러가 생성되어 있습니다.

프로세스

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

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
    Copy to Clipboard Toggle word wrap
  2. PROXY 구성을 설정합니다.

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

      PROXY에 대한 hostNetwork 구성 샘플

        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: HostNetwork
      Copy to Clipboard Toggle word wrap

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

      PROXY에 대한 nodePort 구성 샘플

        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService
      Copy to Clipboard Toggle word wrap

7.8.16. appsDomain 옵션을 사용하여 대체 클러스터 도메인 지정

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

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

사전 요구 사항

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

프로세스

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

    1. 수신 클러스터 리소스를 편집합니다.

      $ oc edit ingresses.config/cluster -o yaml
      Copy to Clipboard Toggle word wrap
    2. YAML 파일을 편집합니다.

      test.example.com을 위한 샘플 appsDomain 구성

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            
      1
      
        appsDomain: <test.example.com>      
      2
      Copy to Clipboard Toggle word wrap

      1
      기본 도메인을 지정합니다. 설치 후에는 기본 도메인을 수정할 수 없습니다.
      2
      선택사항: 애플리케이션 경로에 사용할 OpenShift Container Platform 인프라의 도메인입니다. 기본 접두사 대신 test 와 같은 대체 접두사를 사용할 수 있습니다.
  2. 경로를 노출하고 경로 도메인 변경을 확인하여 기존 경로에 appsDomain 필드에 지정된 도메인 이름이 포함되어 있는지 확인합니다.

    참고

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

    1. 경로를 노출합니다.

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed
      Copy to Clipboard Toggle word wrap

      출력 예:

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None
      Copy to Clipboard Toggle word wrap

7.8.17. HTTP 헤더 대소문자 변환

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

중요

OpenShift Container Platform에는 HAProxy 2.2가 포함되어 있습니다. 이 웹 기반 로드 밸런서 버전으로 업데이트하려면 spec.httpHeaders.headerNameCaseAdjustments 섹션을 클러스터의 구성 파일에 추가해야 합니다.

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

사전 요구 사항

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

프로세스

  • oc patch 명령을 사용하여 HTTP 헤더를 대문자로 설정합니다.

    1. 다음 명령을 실행하여 HTTP 헤더를 host 에서 Host 로 변경합니다.

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
      Copy to Clipboard Toggle word wrap
    2. 주석을 애플리케이션에 적용할 수 있도록 Route 리소스 YAML 파일을 생성합니다.

      my-application이라는 경로 예

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 
      1
      
        name: <application_name>
        namespace: <application_name>
      # ...
      Copy to Clipboard Toggle word wrap

      1
      Ingress 컨트롤러가 지정된 대로 호스트 요청 헤더를 조정할 수 있도록 haproxy.router.openshift.io/h1-adjust-case 를 설정합니다.
  • Ingress 컨트롤러 YAML 구성 파일에서 HeaderNameCaseAdjustments 필드를 구성하여 조정을 지정합니다.

    1. 다음 예제 Ingress 컨트롤러 YAML 파일은 적절한 주석이 달린 경로에 대해 HTTP/1 요청에 대해 호스트 헤더를 Host 로 조정합니다.

      Ingress 컨트롤러 YAML 예시

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

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

7.8.18. 라우터 압축 사용

특정 MIME 유형에 대해 전역적으로 라우터 압축을 지정하도록 HAProxy Ingress 컨트롤러를 구성합니다. mimeTypes 변수를 사용하여 압축이 적용되는 MIME 유형의 형식을 정의할 수 있습니다. 유형은 application, image, message, multipart, text, video 또는 "X-"로 시작하는 사용자 지정 유형입니다. MIME 유형 및 하위 형식에 대한 전체 표기법을 보려면 RFC1341 을 참조하십시오.

참고

압축을 위해 할당된 메모리는 max 연결에 영향을 미칠 수 있습니다. 또한 대용량 버퍼를 압축하면 regex 또는 regex의 긴 목록과 같이 대기 시간이 발생할 수 있습니다.

모든 MIME 유형이 압축을 활용하는 것은 아니지만 HAProxy는 지시된 경우 압축을 위해 리소스를 사용합니다. 일반적으로 html, css 및 js와 같은 텍스트 형식은 압축의 이점을 얻을 수 있지만 이미지,오디오 및 비디오와 같이 이미 압축된 형식은 압축에 소비된 시간과 리소스를 교환하지 않아도 됩니다.

절차

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

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

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default
      Copy to Clipboard Toggle word wrap
    2. spec 에서 httpCompression policy 필드를 mimeTypes 로 설정하고 압축이 적용되는 MIME 유형 목록을 지정합니다.

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...
      Copy to Clipboard Toggle word wrap

7.8.19. 라우터 지표 노출

기본 통계 포트인 1936의 Prometheus 형식으로 기본적으로 HAProxy 라우터 메트릭을 노출할 수 있습니다. Prometheus와 같은 외부 지표 수집 및 집계 시스템은 HAProxy 라우터 지표에 액세스할 수 있습니다. 브라우저에서 HAProxy 라우터 메트릭과 쉼표로 구분된 값(CSV) 형식을 볼 수 있습니다.

사전 요구 사항

  • 기본 통계 포트인 1936에 액세스하도록 방화벽을 구성했습니다.

절차

  1. 다음 명령을 실행하여 라우터 포드 이름을 가져옵니다.

    $ oc get pods -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              READY   STATUS    RESTARTS   AGE
    router-default-76bfffb66c-46qwp   1/1     Running   0          11h
    Copy to Clipboard Toggle word wrap

  2. 라우터 Pod가 /var/lib/haproxy/conf/metrics-auth/statsUsername/var/lib/haproxy/conf/metrics-auth/statsPassword 파일에 저장하는 라우터의 사용자 이름과 암호를 가져옵니다.

    1. 다음 명령을 실행하여 사용자 이름을 가져옵니다.

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 암호를 가져옵니다.

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword
      Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 라우터 IP 및 지표 인증서를 가져옵니다.

    $ oc describe pod <router_pod>
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 Prometheus 형식으로 원시 통계를 가져옵니다.

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 메트릭에 안전하게 액세스합니다.

    $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 기본 통계 포트 1936에 액세스합니다.

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap

    예 7.1. 출력 예

    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
    Copy to Clipboard Toggle word wrap
  7. 브라우저에 다음 URL을 입력하여 통계 창을 시작합니다.

    http://<user>:<password>@<router_IP>:<stats_port>
    Copy to Clipboard Toggle word wrap
  8. 선택 사항: 브라우저에 다음 URL을 입력하여 CSV 형식으로 통계를 가져옵니다.

    http://<user>:<password>@<router_ip>:1936/metrics;csv
    Copy to Clipboard Toggle word wrap

7.8.20. HAProxy 오류 코드 응답 페이지 사용자 정의

클러스터 관리자는 503, 404 또는 두 오류 페이지에 대한 사용자 지정 오류 코드 응답 페이지를 지정할 수 있습니다. HAProxy 라우터는 애플리케이션 pod가 실행 중이 아닌 경우 503 오류 페이지 또는 요청된 URL이 없는 경우 404 오류 페이지를 제공합니다. 예를 들어 503 오류 코드 응답 페이지를 사용자 지정하면 애플리케이션 pod가 실행되지 않을 때 페이지가 제공되며 HAProxy 라우터에서 잘못된 경로 또는 존재하지 않는 경로에 대해 기본 404 오류 코드 HTTP 응답 페이지가 제공됩니다.

사용자 정의 오류 코드 응답 페이지가 구성 맵에 지정되고 Ingress 컨트롤러에 패치됩니다. 구성 맵 키의 사용 가능한 파일 이름은 error-page-503.httperror-page-404.http 입니다.

사용자 지정 HTTP 오류 코드 응답 페이지는 HAProxy HTTP 오류 페이지 구성 지침을 따라야 합니다. 다음은 기본 OpenShift Container Platform HAProxy 라우터 http 503 오류 코드 응답 페이지의 예입니다. 기본 콘텐츠를 고유한 사용자 지정 페이지를 생성하기 위한 템플릿으로 사용할 수 있습니다.

기본적으로 HAProxy 라우터는 애플리케이션이 실행 중이 아니거나 경로가 올바르지 않거나 존재하지 않는 경우 503 오류 페이지만 제공합니다. 이 기본 동작은 OpenShift Container Platform 4.8 및 이전 버전의 동작과 동일합니다. HTTP 오류 코드 응답 사용자 정의에 대한 구성 맵이 제공되지 않고 사용자 정의 HTTP 오류 코드 응답 페이지를 사용하는 경우 라우터는 기본 404 또는 503 오류 코드 응답 페이지를 제공합니다.

참고

OpenShift Container Platform 기본 503 오류 코드 페이지를 사용자 지정의 템플릿으로 사용하는 경우 파일의 헤더에는 CRLF 줄 끝을 사용할 수 있는 편집기가 필요합니다.

절차

  1. openshift-config 네임스페이스에 my-custom-error-code-pages 라는 구성 맵을 생성합니다.

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
    --from-file=error-page-503.http \
    --from-file=error-page-404.http
    Copy to Clipboard Toggle word wrap
    중요

    사용자 정의 오류 코드 응답 페이지에 올바른 형식을 지정하지 않으면 라우터 Pod 중단이 발생합니다. 이 중단을 해결하려면 구성 맵을 삭제하거나 수정하고 영향을 받는 라우터 Pod를 삭제하여 올바른 정보로 다시 생성해야 합니다.

  2. 이름별로 my-custom-error-code-pages 구성 맵을 참조하도록 Ingress 컨트롤러를 패치합니다.

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Ingress Operator는 my-custom-error-code-pages 구성 맵을 openshift-config 네임스페이스에서 openshift-ingress 네임스페이스로 복사합니다. Operator는 openshift-ingress 네임스페이스에서 <your_ingresscontroller_name>-errorpages 패턴에 따라 구성 맵의 이름을 지정합니다.

  3. 복사본을 표시합니다.

    $ oc get cm default-errorpages -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       DATA   AGE
    default-errorpages         2      25s  
    1
    Copy to Clipboard Toggle word wrap

    1
    default Ingress 컨트롤러 CR(사용자 정의 리소스)이 패치되었기 때문에 구성 맵 이름은 default-errorpages입니다.
  4. 사용자 정의 오류 응답 페이지가 포함된 구성 맵이 라우터 볼륨에 마운트되는지 확인합니다. 여기서 구성 맵 키는 사용자 정의 HTTP 오류 코드 응답이 있는 파일 이름입니다.

    • 503 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
      Copy to Clipboard Toggle word wrap
    • 404 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
      Copy to Clipboard Toggle word wrap

검증

사용자 정의 오류 코드 HTTP 응답을 확인합니다.

  1. 테스트 프로젝트 및 애플리케이션을 생성합니다.

     $ oc new-project test-ingress
    Copy to Clipboard Toggle word wrap
    $ oc new-app django-psql-example
    Copy to Clipboard Toggle word wrap
  2. 503 사용자 정의 http 오류 코드 응답의 경우:

    1. 애플리케이션의 모든 pod를 중지합니다.
    2. 다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  3. 404 사용자 정의 http 오류 코드 응답의 경우:

    1. 존재하지 않는 경로 또는 잘못된 경로를 방문합니다.
    2. 다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  4. errorfile 속성이 haproxy.config 파일에 제대로 있는지 확인합니다.

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
    Copy to Clipboard Toggle word wrap

7.8.21. Ingress 컨트롤러 최대 연결 설정

클러스터 관리자는 OpenShift 라우터 배포에 최대 동시 연결 수를 설정할 수 있습니다. 기존 Ingress 컨트롤러에 패치를 적용하여 최대 연결 수를 늘릴 수 있습니다.

사전 요구 사항

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

절차

  • HAProxy의 최대 연결 수를 변경하도록 Ingress 컨트롤러를 업데이트합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
    Copy to Clipboard Toggle word wrap
    주의

    spec.tuningOptions.maxConnections 값을 현재 운영 체제 제한보다 크게 설정하면 HAProxy 프로세스가 시작되지 않습니다. 이 매개변수에 대한 자세한 내용은 "Ingress Controller 구성 매개변수" 섹션의 표를 참조하십시오.

8장. OpenShift Container Platform의 Ingress Node Firewall Operator

Ingress Node Firewall Operator를 사용하면 관리자가 노드 수준에서 방화벽 구성을 관리할 수 있습니다.

8.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator는 방화벽 구성에서 지정 및 관리하는 노드에 데몬 세트를 배포하여 노드 수준에서 수신 방화벽 규칙을 제공합니다. 데몬 세트를 배포하려면 IngressNodeFirewallConfig CR(사용자 정의 리소스)을 생성합니다. Operator는 IngressNodeFirewallConfig CR을 적용하여 nodeSelector 와 일치하는 모든 노드에서 실행되는 Ingress 노드 방화벽 데몬 데몬 데몬 을 생성합니다.

IngressNodeFirewall CR의 규칙을 구성하고 nodeSelector 를 사용하여 클러스터에 적용하고 값을 "true"로 설정합니다.

중요

Ingress Node Firewall Operator는 상태 비저장 방화벽 규칙만 지원합니다.

최대 전송 단위(MTU) 매개변수는 OpenShift Container Platform 4.13의 4Kb(kilobytes)입니다.

기본 XDP 드라이버를 지원하지 않는 NIC(네트워크 인터페이스 컨트롤러)는 더 낮은 성능으로 실행됩니다.

Ingress Node Firewall Operator는 기본 OpenShift 설치 또는 AWS(ROSA)의 Red Hat OpenShift Service를 사용하는 AWS(Amazon Web Services)에서 지원되지 않습니다. AWS 지원 및 수신에 대한 Red Hat OpenShift Service에 대한 자세한 내용은 AWS의 Red Hat OpenShift Service의 Ingress Operator 를 참조하십시오.

8.2. Ingress Node Firewall Operator 설치

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

8.2.1. CLI를 사용하여 Ingress Node Firewall Operator 설치

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

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 관리자 권한이 있는 계정이 있습니다.

절차

  1. openshift-ingress-node-firewall 네임스페이스를 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup CR을 생성하려면 다음 명령을 입력합니다.

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ingress-node-firewall-operators
      namespace: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  3. Ingress Node Firewall Operator를 서브스크립션합니다.

    1. Ingress Node Firewall Operator에 대한 Subscription CR을 생성하려면 다음 명령을 입력합니다.

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get ip -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            CSV                                         APPROVAL    APPROVED
    install-5cvnz   ingress-node-firewall.4.13.0-202211122336   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. Operator 버전을 확인하려면 다음 명령을 입력합니다.

    $ oc get csv -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
    ingress-node-firewall.4.13.0-202211122336   Ingress Node Firewall Operator   4.13.0-202211122336   ingress-node-firewall.4.13.0-202211102047   Succeeded
    Copy to Clipboard Toggle word wrap

8.2.2. 웹 콘솔을 사용하여 Ingress Node Firewall Operator 설치

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

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 관리자 권한이 있는 계정이 있습니다.

절차

  1. Ingress Node Firewall Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Ingress Node Firewall Operator 를 선택한 다음 설치를 클릭합니다.
    3. Operator 설치 페이지의 설치된 네임스페이스 에서 Operator 권장 네임스페이스 를 선택합니다.
    4. 설치를 클릭합니다.
  2. Ingress Node Firewall Operator가 설치되었는지 확인합니다.

    1. Operator설치된 Operator 페이지로 이동합니다.
    2. Ingress Node Firewall Operatoropenshift-ingress-node-firewall 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

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

      Operator에 InstallSucceeded 상태가 없는 경우 다음 단계를 사용하여 문제를 해결합니다.

      • Operator 서브스크립션설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드Pod 페이지로 이동하여 openshift-ingress-node-firewall 프로젝트에서 Pod 로그를 확인합니다.
      • YAML 파일의 네임스페이스를 확인합니다. 주석이 없는 경우 다음 명령을 사용하여 workload.openshift.io/allowed=management 주석을 Operator 네임스페이스에 추가할 수 있습니다.

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        참고

        단일 노드 OpenShift 클러스터의 경우 openshift-ingress-node-firewall 네임스페이스에 workload.openshift.io/allowed=management 주석이 필요합니다.

8.3. Ingress Node Firewall Operator 배포

사전 요구 사항

  • Ingress Node Firewall Operator가 설치되어 있습니다.

절차

Ingress Node Firewall Operator를 배포하려면 Operator의 데몬 세트를 배포할 IngressNodeFirewallConfig 사용자 정의 리소스를 생성합니다. 방화벽 규칙을 적용하여 노드에 하나 이상의 IngressNodeFirewall CRD를 배포할 수 있습니다.

  1. ingressnodefirewallconfig 라는 openshift-ingress-node-firewall 네임스페이스에 IngressNodeFirewallConfig 를 생성합니다.
  2. 다음 명령을 실행하여 Ingress Node Firewall Operator 규칙을 배포합니다.

    $ oc apply -f rule.yaml
    Copy to Clipboard Toggle word wrap

8.3.1. Ingress 노드 방화벽 구성 오브젝트

Ingress 노드 방화벽 구성 오브젝트의 필드는 다음 표에 설명되어 있습니다.

Expand
표 8.1. Ingress 노드 방화벽 구성 오브젝트
필드유형설명

metadata.name

string

CR 오브젝트의 이름입니다. 방화벽 규칙 오브젝트의 이름은 ingressnodefirewallconfig 여야 합니다.

metadata.namespace

string

Ingress 방화벽 Operator CR 오브젝트의 네임스페이스입니다. IngressNodeFirewallConfig CR은 openshift-ingress-node-firewall 네임스페이스 내부에서 생성해야 합니다.

spec.nodeSelector

string

지정된 노드 레이블을 통해 노드를 대상으로 하는 노드 선택 제약 조건입니다. 예를 들면 다음과 같습니다.

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap
참고

데몬 세트를 시작하려면 nodeSelector 에 사용된 하나의 레이블이 노드의 라벨과 일치해야 합니다. 예를 들어 노드 레이블 node-role.kubernetes.io/workernode-type.kubernetes.io/vm 이 노드에 적용되는 경우 데몬 세트를 시작하기 위해 nodeSelector 를 사용하여 하나 이상의 라벨을 설정해야 합니다.

참고

Operator는 CR을 사용하고 nodeSelector 와 일치하는 모든 노드에서 Ingress 노드 방화벽 데몬 세트를 생성합니다.

Ingress Node Firewall Operator 구성 예

전체 Ingress 노드 방화벽 구성은 다음 예에 지정됩니다.

Ingress 노드 방화벽 구성 오브젝트의 예

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap

참고

Operator는 CR을 사용하고 nodeSelector 와 일치하는 모든 노드에서 Ingress 노드 방화벽 데몬 세트를 생성합니다.

8.3.2. Ingress 노드 방화벽 규칙 오브젝트

Ingress 노드 방화벽 규칙 오브젝트의 필드는 다음 표에 설명되어 있습니다.

Expand
표 8.2. Ingress 노드 방화벽 규칙 오브젝트
필드유형설명

metadata.name

string

CR 오브젝트의 이름입니다.

인터페이스

array

이 오브젝트의 필드는 방화벽 규칙을 적용할 인터페이스를 지정합니다. 예를 들면 - en0- en1 입니다.

nodeSelector

array

nodeSelector 를 사용하여 방화벽 규칙을 적용할 노드를 선택할 수 있습니다. 규칙을 적용하려면 이름이 지정된 nodeselector 레이블의 값을 true 로 설정합니다.

Ingress

object

Ingress 를 사용하면 외부에서 클러스터의 서비스에 액세스할 수 있는 규칙을 구성할 수 있습니다.

Ingress 오브젝트 구성

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

Expand
표 8.3. Ingress 오브젝트
필드유형설명

sourceCIDRs

array

CIDR 블록을 설정할 수 있습니다. 다른 주소 제품군에서 여러 CIDR을 구성할 수 있습니다.

참고

다른 CIDR을 사용하면 동일한 순서 규칙을 사용할 수 있습니다. 동일한 노드와 겹치는 CIDR이 있는 인터페이스에 대해 IngressNodeFirewall 오브젝트가 여러 개 있는 경우 order 필드에서 먼저 적용되는 규칙을 지정합니다. 규칙은 순서대로 적용됩니다.

rules

array

Ingress 방화벽 규칙. 순서 오브젝트는 CIDR당 최대 100개의 규칙이 있는 source.CIDR 마다 1 부터 정렬됩니다. 더 낮은 순서 규칙이 먼저 실행됩니다.

rules.protocolConfig.protocol 은 TCP, UDP, SCTP, ICMP 및 ICMPv6의 다음 프로토콜을 지원합니다. ICMP 및 ICMPv6 규칙은 ICMP 및 ICMPv6 유형 또는 코드와 일치할 수 있습니다. TCP, UDP 및 SCTP 규칙은 < start : end-1 > 형식을 사용하여 단일 대상 포트 또는 포트 범위와 일치할 수 있습니다.

규칙을 적용하거나 규칙을 허용하지 않도록 거부할 rules.action 을 설정합니다.

참고

Ingress 방화벽 규칙은 잘못된 구성을 차단하는 확인 Webhook를 사용하여 확인합니다. 확인 Webhook를 사용하면 API 서버 또는 SSH와 같은 중요한 클러스터 서비스를 차단할 수 없습니다.

Ingress 노드 방화벽 규칙 오브젝트의 예

전체 Ingress 노드 방화벽 구성은 다음 예에 지정됩니다.

Ingress 노드 방화벽 구성의 예

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 
1

  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny
Copy to Clipboard Toggle word wrap

1
<label_name> 및 <label_value>는 노드에 있어야 하며 ingressfirewallconfig CR을 실행할 노드에 적용되는 nodeselector 레이블 및 값과 일치해야 합니다. <label_value>는 true 또는 false 일 수 있습니다. nodeSelector 레이블을 사용하면 별도의 노드 그룹을 대상으로 하여 ingressfirewallconfig CR을 사용하는 데 다른 규칙을 적용할 수 있습니다.
신뢰할 수 있는 Ingress 노드 방화벽 규칙 오브젝트 예

제로 트러스트된 Ingress 노드 방화벽 규칙은 다중 인터페이스 클러스터에 추가 보안을 제공할 수 있습니다. 예를 들어, 제로 트러스트 Ingress 노드 방화벽 규칙을 사용하여 SSH를 제외한 특정 인터페이스의 모든 트래픽을 삭제할 수 있습니다.

제로 신뢰 Ingress 노드 방화벽 규칙 세트의 전체 구성이 다음 예에 지정됩니다.

중요

사용자는 적절한 기능을 보장하기 위해 다음 경우 해당 애플리케이션이 allowlist에 사용하는 모든 포트를 추가해야 합니다.

제로 신뢰 Ingress 노드 방화벽 규칙의 예

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 
1

 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 
2

 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 
3

   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 
4
Copy to Clipboard Toggle word wrap

1
network-interface 클러스터
2
<label_name> 및 <label_value>는 ingressfirewallconfig CR을 적용하려는 특정 노드에 적용되는 nodeSelector 레이블 및 값과 일치해야 합니다.
3
0.0.0.0/0 이 모든 CIDR과 일치하도록 설정
4
작업이 Deny로 설정

8.4. Ingress Node Firewall Operator 규칙 보기

절차

  1. 다음 명령을 실행하여 모든 현재 규칙을 확인합니다.

    $ oc get ingressnodefirewall
    Copy to Clipboard Toggle word wrap
  2. 반환된 < resource> 이름 중 하나를 선택하고 다음 명령을 실행하여 규칙 또는 구성을 확인합니다.

    $ oc get <resource> <name> -o yaml
    Copy to Clipboard Toggle word wrap

8.5. Ingress Node Firewall Operator 문제 해결

  • 다음 명령을 실행하여 설치된 Ingress 노드 방화벽 CRD(사용자 정의 리소스 정의)를 나열합니다.

    $ oc get crds | grep ingressnodefirewall
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
    ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
    ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                       READY  STATUS         RESTARTS  AGE
    ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
    ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h
    Copy to Clipboard Toggle word wrap

    다음 필드는 Operator 상태에 대한 정보를 제공합니다. READY,STATUS,AGE, RESTARTS. Ingress Node Firewall Operator가 데몬 세트를 할당된 노드에 배포할 때 STATUS 필드가 실행 중입니다.

  • 다음 명령을 실행하여 모든 수신 방화벽 노드 Pod의 로그를 수집합니다.

    $ oc adm must-gather – gather_ingress_node_firewall
    Copy to Clipboard Toggle word wrap

    로그는 /sos_commands/ebpf ff 의 eBPF bpftool 출력이 포함된 sos 노드의 보고서에서 사용할 수 있습니다. 이러한 보고서에는 수신 방화벽 XDP에서 패킷 처리, 통계 업데이트, 이벤트 발송로 사용 또는 업데이트되는 조회 테이블이 포함되어 있습니다.

9장. 수동 DNS 관리를 위한 Ingress 컨트롤러 구성

클러스터 관리자는 Ingress 컨트롤러를 생성할 때 Operator는 DNS 레코드를 자동으로 관리합니다. 이는 필수 DNS 영역이 클러스터 DNS 영역과 다르거나 DNS 영역이 클라우드 공급자 외부에서 호스팅되는 경우 몇 가지 제한 사항이 있습니다.

클러스터 관리자는 자동 DNS 관리를 중지하고 수동 DNS 관리를 시작하도록 Ingress 컨트롤러를 구성할 수 있습니다. 자동 또는 수동으로 관리해야 하는 시기를 지정하도록 dnsManagementPolicy 를 설정합니다.

Ingress 컨트롤러를 Managed 에서 Unmanaged DNS 관리 정책으로 변경하면 Operator에서 클라우드에 프로비저닝된 이전 와일드카드 DNS 레코드를 정리하지 않습니다. Ingress 컨트롤러를 Unmanaged 에서 Managed DNS 관리 정책으로 변경하면 Operator가 클라우드 공급자에 DNS 레코드를 생성하거나 이미 존재하는 경우 DNS 레코드를 업데이트합니다.

중요

dnsManagementPolicyUnmanaged 로 설정하면 클라우드 공급자의 와일드카드 DNS 레코드의 라이프사이클을 수동으로 관리해야 합니다.

9.1. 관리형 DNS 관리 정책

Ingress 컨트롤러에 대한 Managed DNS 관리 정책은 클라우드 공급자의 와일드카드 DNS 레코드의 라이프사이클이 Operator에 의해 자동으로 관리되도록 합니다.

9.2. 관리되지 않는 DNS 관리 정책

Ingress 컨트롤러에 대한 Unmanaged DNS 관리 정책에서는 클라우드 공급자의 와일드카드 DNS 레코드의 라이프사이클이 자동으로 관리되지 않으며, 대신 클러스터 관리자가 됩니다.

참고

AWS 클라우드 플랫폼에서 Ingress 컨트롤러의 도메인이 dnsConfig.Spec.BaseDomain 과 일치하지 않으면 DNS 관리 정책이 자동으로 Unmanaged 로 설정됩니다.

클러스터 관리자는 관리되지 않는 DNS 관리 정책을 사용하여 새 사용자 정의 Ingress 컨트롤러를 생성할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음을 포함하는 sample-ingress.yaml 이라는 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: External 
    3
    
          dnsManagementPolicy: Unmanaged 
    4
    Copy to Clipboard Toggle word wrap
    1
    IngressController 오브젝트의 이름으로 <name>을 지정합니다.
    2
    사전 요구 사항으로 생성된 DNS 레코드를 기반으로 도메인을 지정합니다.
    3
    로드 밸런서를 외부로 노출하려면 범위를 External 로 지정합니다.
    4
    dnsManagementPolicy 는 Ingress 컨트롤러가 로드 밸런서와 연결된 와일드카드 DNS 레코드의 라이프사이클을 관리하고 있는지 여부를 나타냅니다. 유효한 값은 ManagedUnmanaged 입니다. 기본값은 Managed 입니다.
  2. 파일을 저장하여 변경 사항을 적용합니다.

    oc apply -f <name>.yaml 
    1
    Copy to Clipboard Toggle word wrap

9.4. 기존 Ingress 컨트롤러 수정

클러스터 관리자는 기존 Ingress 컨트롤러를 수정하여 DNS 레코드 라이프사이클을 수동으로 관리할 수 있습니다.

사전 요구 사항

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

절차

  1. 선택한 IngressController 를 수정하여 dnsManagementPolicy:을 설정합니다.

    SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")
    
    oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 클라우드 공급자에서 연결된 DNS 레코드를 삭제할 수 있습니다.

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

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

10.1. 연결 상태 점검 수행

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

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

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

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

10.2. 연결 상태 점검 구현

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

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

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

10.3. PodNetworkConnectivityCheck 오브젝트 필드

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

Expand
표 10.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 배열에서 오브젝트 필드를 설명합니다.

Expand
표 10.2. status.conditions
필드유형설명

lastTransitionTime

string

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

message

string

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

reason

string

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

status

string

조건의 상태:

type

string

조건의 유형입니다.

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

Expand
표 10.3. status.outages
필드유형설명

end

string

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

endLogs

array

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

message

string

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

start

string

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

startLogs

array

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

연결 로그 필드

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

  • status.failures[]
  • status.successes[]
  • status.outages[].startLogs[]
  • status.outages[].endLogs[]
Expand
표 10.4. 연결 로그 오브젝트
필드유형설명

latency

string

작업 기간을 기록합니다.

message

string

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

reason

string

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

success

boolean

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

time

string

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

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

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

사전 요구 사항

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

프로세스

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

    $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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

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

      $ oc get podnetworkconnectivitycheck <name> \
        -n openshift-network-diagnostics -o yaml
      Copy to Clipboard Toggle word wrap

      여기서 <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"
      Copy to Clipboard Toggle word wrap

11장. 클러스터 네트워크의 MTU 변경

클러스터 관리자는 클러스터 설치 후 클러스터 네트워크의 MTU를 변경할 수 있습니다. MTU 변경을 완료하기 위해 클러스터 노드를 재부팅해야 하므로 이러한 변경이 중단됩니다. OVN-Kubernetes 또는 OpenShift SDN 네트워크 플러그인을 사용하여 클러스터의 MTU만 변경할 수 있습니다.

11.1. 클러스터 MTU 정보

설치하는 동안 클러스터 네트워크의 최대 전송 단위(MTU)는 클러스터에 있는 노드의 기본 네트워크 인터페이스의 MTU를 기반으로 자동으로 탐지됩니다. 일반적으로 감지된 MTU를 재정의할 필요는 없습니다.

다음과 같은 여러 가지 이유로 클러스터 네트워크의 MTU를 변경할 수 있습니다.

  • 클러스터 설치 중에 감지된 MTU가 인프라에 적합하지 않음
  • 이제 클러스터 인프라에 최적의 성능을 위해 다른 MTU가 필요한 노드 추가와 같은 다른 MTU가 필요합니다.

OVN-Kubernetes 및 OpenShift SDN 클러스터 네트워크 플러그인에 대해서만 클러스터 MTU를 변경할 수 있습니다.

11.1.1. 서비스 중단 고려 사항

클러스터에서 MTU 변경 사항을 시작하면 다음과 같은 영향이 서비스 가용성에 영향을 미칠 수 있습니다.

  • 새 MTU로 마이그레이션을 완료하려면 롤링 재부팅이 두 개 이상 필요합니다. 이 시간 동안 일부 노드는 다시 시작할 때 사용할 수 없습니다.
  • 절대 TCP 시간 초과 간격보다 제한 시간이 짧은 클러스터에 배포된 특정 애플리케이션에는 MTU 변경 시 중단될 수 있습니다.

11.1.2. MTU 값 선택

MTU 마이그레이션을 계획할 때 고려해야 할 두 개의 관련 MTU 값이 있습니다.

  • Hardware MTU: 이 MTU 값은 네트워크 인프라의 세부 사항에 따라 설정됩니다.
  • 클러스터 네트워크 MTU: 이 MTU 값은 항상 하드웨어 MTU보다 작아 클러스터 네트워크 오버레이 오버헤드를 고려합니다. 특정 오버헤드는 네트워크 플러그인에 따라 결정됩니다.

    • OVN-Kubernetes:100 바이트
    • OpenShift SDN:50 바이트

클러스터에 다른 노드에 대해 다른 MTU 값이 필요한 경우 클러스터의 노드에서 사용하는 가장 낮은 MTU 값에서 네트워크 플러그인의 오버헤드 값을 제거해야 합니다. 예를 들어, 클러스터의 일부 노드에 9001의 MTU가 있고 일부에는 1500의 MTU가 있는 경우 이 값을 1400으로 설정해야 합니다.

중요

노드에서 허용되지 않는 MTU 값을 선택하지 않으려면 ip -d link 명령을 사용하여 네트워크 인터페이스에서 허용하는 최대 MTU 값(maxmtu)을 확인합니다.

11.1.3. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

Expand
표 11.1. 클러스터 MTU의 실시간 마이그레이션
사용자 시작 단계OpenShift Container Platform 활동

Cluster Network Operator 구성에 다음 값을 설정합니다.

  • spec.migration.mtu.machine.to
  • spec.migration.mtu.network.from
  • spec.migration.mtu.network.to

CNO(Cluster Network Operator): 각 필드가 유효한 값으로 설정되어 있는지 확인합니다.

  • mtu.machine.to 는 하드웨어의 MTU가 변경되지 않는 경우 새 하드웨어 MTU 또는 현재 하드웨어 MTU로 설정해야 합니다. 이 값은 일시적이며 마이그레이션 프로세스의 일부로 사용됩니다. 별도로 기존 하드웨어 MTU 값과 다른 하드웨어 MTU를 지정하는 경우 시스템 구성, DHCP 설정 또는 Linux 커널 명령줄과 같은 다른 방법으로 유지되도록 MTU를 수동으로 구성해야 합니다.
  • mtu.network.from 필드는 클러스터 네트워크의 현재 MTU인 network.status.clusterNetworkMTU 필드와 같아야 합니다.
  • mtu.network.to 필드를 대상 클러스터 네트워크 MTU로 설정해야 하며 네트워크 플러그인의 오버레이 오버헤드를 허용하려면 하드웨어 MTU보다 작아야 합니다. OVN-Kubernetes의 경우 오버헤드는 100 바이트이고 OpenShift SDN의 경우 오버헤드는 50 바이트입니다.

제공된 값이 유효한 경우 CNO는 mtu.network.to 필드의 값으로 설정된 클러스터 네트워크의 MTU로 새로운 임시 구성을 씁니다.

MCO(Machine Config Operator): 클러스터의 각 노드를 롤링 재부팅을 수행합니다.

클러스터에 있는 노드에 대한 기본 네트워크 인터페이스의 MTU를 재구성합니다. 다음을 포함하여 다양한 방법을 사용할 수 있습니다.

  • MTU 변경을 사용하여 새 NetworkManager 연결 프로필 배포
  • DHCP 서버 설정을 통해 MTU 변경
  • 부팅 매개변수를 통해 MTU 변경

해당 없음

네트워크 플러그인의 CNO 구성에 있는 mtu 값을 설정하고 spec.migrationnull 로 설정합니다.

MCO(Machine Config Operator): 클러스터의 각 노드를 새 MTU 구성으로 롤링 재부팅합니다.

11.2. 클러스터 MTU 변경

클러스터 관리자는 클러스터의 최대 전송 단위(MTU)를 변경할 수 있습니다. 마이그레이션이 중단되고 MTU 업데이트가 롤아웃되면 클러스터의 노드를 일시적으로 사용할 수 없게 될 수 있습니다.

다음 절차에서는 시스템 구성, DHCP 또는 ISO를 사용하여 클러스터 MTU를 변경하는 방법을 설명합니다. DHCP 또는 ISO 방법을 사용하는 경우 절차를 완료하기 위해 클러스터를 설치한 후 보관한 구성 아티팩트를 참조해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터의 대상 MTU를 식별했습니다. 클러스터가 사용하는 네트워크 플러그인에 따라 올바른 MTU가 다릅니다.

    • OVN-Kubernetes: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다 100 작아야 합니다.
    • OpenShift SDN: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다 50 미만으로 설정해야 합니다.

절차

클러스터 네트워크의 MTU를 늘리거나 줄이려면 다음 절차를 완료합니다.

  1. 클러스터 네트워크의 현재 MTU를 얻으려면 다음 명령을 입력합니다.

    $ oc describe network.config cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    Status:
      Cluster Network:
        Cidr:               10.217.0.0/22
        Host Prefix:        23
      Cluster Network MTU:  1400
      Network Type:         OpenShiftSDN
      Service Network:
        10.217.4.0/23
    ...
    Copy to Clipboard Toggle word wrap

  2. 하드웨어 MTU를 위한 구성을 준비합니다.

    • DHCP로 하드웨어 MTU를 지정하면 다음 dnsmasq 구성과 같은 DHCP 구성을 업데이트합니다.

      dhcp-option-force=26,<mtu>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <mtu>
      공개할 DHCP 서버의 하드웨어 MTU를 지정합니다.
    • 하드웨어 MTU를 PXE를 사용하여 커널 명령줄로 지정하면 그에 따라 해당 구성을 업데이트합니다.
    • NetworkManager 연결 구성에 하드웨어 MTU가 지정된 경우 다음 단계를 완료합니다. DHCP, 커널 명령줄 또는 기타 방법으로 네트워크 구성을 명시적으로 지정하지 않는 경우 이 방법은 OpenShift Container Platform의 기본값입니다. 클러스터 노드는 다음 절차에 따라 수정되지 않은 작업을 위해 모두 동일한 기본 네트워크 구성을 사용해야 합니다.

      1. 기본 네트워크 인터페이스를 찾습니다.

        • OpenShift SDN 네트워크 플러그인을 사용하는 경우 다음 명령을 입력합니다.

          $ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'
          Copy to Clipboard Toggle word wrap

          다음과 같습니다.

          <node_name>
          클러스터에 있는 노드의 이름을 지정합니다.
        • OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 다음 명령을 입력합니다.

          $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
          Copy to Clipboard Toggle word wrap

          다음과 같습니다.

          <node_name>
          클러스터에 있는 노드의 이름을 지정합니다.
      2. < interface>-mtu.conf 파일에 다음 NetworkManager 구성을 만듭니다.

        NetworkManager 연결 구성 예

        [connection-<interface>-mtu]
        match-device=interface-name:<interface>
        ethernet.mtu=<mtu>
        Copy to Clipboard Toggle word wrap

        다음과 같습니다.

        <mtu>
        새 하드웨어 MTU 값을 지정합니다.
        <interface>
        기본 네트워크 인터페이스 이름을 지정합니다.
      3. 두 개의 MachineConfig 오브젝트를 만듭니다. 하나는 컨트롤 플레인 노드용이고 다른 하나는 클러스터의 작업자 노드에 사용됩니다.

        1. control-plane-interface.bu 파일에 다음 Butane 구성을 생성합니다.

          variant: openshift
          version: 4.13.0
          metadata:
            name: 01-control-plane-interface
            labels:
              machineconfiguration.openshift.io/role: master
          storage:
            files:
              - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 
          1
          
                contents:
                  local: <interface>-mtu.conf 
          2
          
                mode: 0600
          Copy to Clipboard Toggle word wrap
          1 1
          기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.
          2
          이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.
        2. worker-interface.bu 파일에 다음 Butane 구성을 생성합니다.

          variant: openshift
          version: 4.13.0
          metadata:
            name: 01-worker-interface
            labels:
              machineconfiguration.openshift.io/role: worker
          storage:
            files:
              - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 
          1
          
                contents:
                  local: <interface>-mtu.conf 
          2
          
                mode: 0600
          Copy to Clipboard Toggle word wrap
          1
          기본 네트워크 인터페이스에 대한 NetworkManager 연결 이름을 지정합니다.
          2
          이전 단계에서 업데이트된 NetworkManager 구성 파일의 로컬 파일 이름을 지정합니다.
        3. 다음 명령을 실행하여 Butane 구성에서 MachineConfig 오브젝트를 생성합니다.

          $ for manifest in control-plane-interface worker-interface; do
              butane --files-dir . $manifest.bu > $manifest.yaml
            done
          Copy to Clipboard Toggle word wrap
  3. MTU 마이그레이션을 시작하려면 다음 명령을 입력하여 마이그레이션 구성을 지정합니다. Machine Config Operator는 MTU 변경을 준비하기 위해 클러스터에서 노드를 롤링 재부팅합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <overlay_from>
    현재 클러스터 네트워크 MTU 값을 지정합니다.
    <overlay_to>
    클러스터 네트워크의 대상 MTU를 지정합니다. 이 값은 < machine_to > 값을 기준으로 설정되며 OVN-Kubernetes의 경우 100 미만이어야 하며 OpenShift SDN의 경우 50 작아야 합니다.
    <machine_to>
    기본 호스트 네트워크의 기본 네트워크 인터페이스에 대한 MTU를 지정합니다.

    클러스터 MTU를 늘리는 예

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
    Copy to Clipboard Toggle word wrap

  4. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  5. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/mtu-migration.sh
      Copy to Clipboard Toggle word wrap
  6. 기본 네트워크 인터페이스 MTU 값을 업데이트합니다.

    • NetworkManager 연결 구성으로 새 MTU를 지정하는 경우 다음 명령을 입력합니다. MachineConfig Operator는 클러스터의 노드 롤링 재부팅을 자동으로 수행합니다.

      $ for manifest in control-plane-interface worker-interface; do
          oc create -f $manifest.yaml
        done
      Copy to Clipboard Toggle word wrap
    • DHCP 서버 옵션 또는 커널 명령줄 및 PXE로 새 MTU를 지정하는 경우 인프라에 필요한 변경을 수행합니다.
  7. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  8. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep path:
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성이 성공적으로 배포된 경우 이전 출력에는 /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 파일 경로와 ExecStart=/usr/local/bin/mtu-migration.sh 행이 포함됩니다.

  9. MTU 마이그레이션을 완료하려면 다음 명령 중 하나를 입력합니다.

    • OVN-Kubernetes 네트워크 플러그인을 사용하는 경우:

      $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
        '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <mtu>
      < overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다.
    • OpenShift SDN 네트워크 플러그인을 사용하는 경우:

      $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
        '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <mtu>
      < overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다.
  10. MTU 마이그레이션을 완료한 후 각 MCP 노드가 하나씩 재부팅됩니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

검증

클러스터의 노드가 이전 프로세스에서 지정한 MTU를 사용하는지 확인할 수 있습니다.

  1. 클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.

    $ oc describe network.config cluster
    Copy to Clipboard Toggle word wrap
  2. 노드의 기본 네트워크 인터페이스에 대한 현재 MTU를 가져옵니다.

    1. 클러스터의 노드를 나열하려면 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    2. 노드의 기본 네트워크 인터페이스의 현재 MTU 설정을 가져오려면 다음 명령을 입력합니다.

      $ oc debug node/<node> -- chroot /host ip address show <interface>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <node>
      이전 단계의 출력에서 노드를 지정합니다.
      <interface>
      노드의 기본 네트워크 인터페이스 이름을 지정합니다.

      출력 예

      ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
      Copy to Clipboard Toggle word wrap

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

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

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

12.1. 사전 요구 사항

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

12.2. 노드 포트 범위 확장

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

사전 요구 사항

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

프로세스

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

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

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

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNodePortRange: "30000-<port>"
    Copy to Clipboard Toggle word wrap

    출력 예

    network.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

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

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

    출력 예

    "service-node-port-range":["30000-33000"]
    Copy to Clipboard Toggle word wrap

13장. 클러스터 네트워크 범위 구성

클러스터 관리자는 클러스터 설치 후 클러스터 네트워크 범위를 확장할 수 있습니다. 추가 노드를 위해 더 많은 IP 주소가 필요한 경우 클러스터 네트워크 범위를 확장해야 할 수 있습니다.

예를 들어 클러스터를 배포하고 10.128.0.0/19 를 클러스터 네트워크 범위와 23 의 호스트 접두사로 지정한 경우 16개의 노드로 제한됩니다. 클러스터의 CIDR 마스크를 /14 로 변경하여 이를 510 노드로 확장할 수 있습니다.

클러스터 네트워크 주소 범위를 확장할 때 클러스터에서 OVN-Kubernetes 네트워크 플러그인 을 사용해야 합니다. 다른 네트워크 플러그인은 지원되지 않습니다.

다음 제한 사항은 클러스터 네트워크 IP 주소 범위를 수정할 때 적용됩니다.

  • 지정된 CIDR 마스크 크기는 설치된 클러스터에 노드를 추가하여 IP 공간을 늘릴 수 있으므로 항상 현재 구성된 CIDR 마스크 크기보다 작아야 합니다.
  • 호스트 접두사를 수정할 수 없음
  • 재정의된 기본 게이트웨이로 구성된 Pod는 클러스터 네트워크를 확장한 후 다시 생성해야 합니다.

13.1. 클러스터 네트워크 IP 주소 범위 확장

클러스터 네트워크의 IP 주소 범위를 확장할 수 있습니다. 이러한 변경 사항을 적용하려면 클러스터에 새 Operator 구성을 롤아웃해야 하므로 적용하는데 최대 30분이 걸릴 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인합니다.

프로세스

  1. 클러스터의 클러스터 네트워크 범위 및 호스트 접두사를 가져오려면 다음 명령을 입력합니다.

    $ oc get network.operator.openshift.io \
      -o jsonpath="{.items[0].spec.clusterNetwork}"
    Copy to Clipboard Toggle word wrap

    출력 예

    [{"cidr":"10.217.0.0/22","hostPrefix":23}]
    Copy to Clipboard Toggle word wrap

  2. 클러스터 네트워크 IP 주소 범위를 확장하려면 다음 명령을 입력합니다. 이전 명령의 출력에서 반환된 CIDR IP 주소 범위 및 호스트 접두사를 사용합니다.

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
      '{
        "spec":{
          "clusterNetwork": [ {"cidr":"<network>/<cidr>","hostPrefix":<prefix>} ],
          "networkType": "OVNKubernetes"
        }
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <network>
    이전 단계에서 얻은 cidr 필드의 네트워크 부분을 지정합니다. 이 값은 변경할 수 없습니다.
    <cidr>
    네트워크 접두사 길이를 지정합니다. 예를 들면 14 입니다. 이 값을 이전 단계의 출력 값보다 작은 숫자로 변경하여 클러스터 네트워크 범위를 확장합니다.
    <prefix>
    클러스터의 현재 호스트 접두사를 지정합니다. 이 값은 이전 단계에서 얻은 hostPrefix 필드에 대해 동일해야 합니다.

    명령 예

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
      '{
        "spec":{
          "clusterNetwork": [ {"cidr":"10.217.0.0/14","hostPrefix": 23} ],
          "networkType": "OVNKubernetes"
        }
      }'
    Copy to Clipboard Toggle word wrap

    출력 예

    network.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

  3. 구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 이 변경 사항을 적용하는 데 최대 30분이 걸릴 수 있습니다.

    $ oc get network.operator.openshift.io \
      -o jsonpath="{.items[0].spec.clusterNetwork}"
    Copy to Clipboard Toggle word wrap

    출력 예

    [{"cidr":"10.217.0.0/14","hostPrefix":23}]
    Copy to Clipboard Toggle word wrap

14장. IP 페일오버 구성

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

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

세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 방법은 없으므로 VIP가 없는 노드와 많은 VIP가 많은 다른 노드가 있을 수 있습니다 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.

관리자는 모든 VIP 주소가 다음 요구 사항을 충족하는지 확인해야 합니다.

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

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

참고

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

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

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

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

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

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

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

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

중요

VIP 서비스의 가용성이 높더라도 성능은 여전히 영향을 받을 수 있습니다. keepalived는 각 VIP가 구성의 일부 노드에서 서비스되도록 하고, 다른 노드에 아무것도 없는 경우에도 여러 VIP가 동일한 노드에 배치될 수 있도록 합니다. IP 페일오버가 동일한 노드에 여러 VIP를 배치하면 일련의 VIP에 걸쳐 외부적으로 로드 밸런싱을 수행하는 전략이 좌절될 수 있습니다.

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

중요

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

14.1. IP 페일오버 환경 변수

다음 표에는 IP 페일오버를 구성하는 데 사용되는 변수가 표시되어 있습니다.

Expand
표 14.1. IP 페일오버 환경 변수
변수 이름Default설명

OPENSHIFT_HA_MONITOR_PORT

80

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

OPENSHIFT_HA_NETWORK_INTERFACE

 

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

OPENSHIFT_HA_REPLICA_COUNT

2

생성할 복제본 수입니다. 이는 IP 페일오버 배포 구성의 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

INPUT

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 전략에서는 더 낮은 우선 순위 호스트에서 더 높은 우선 순위 호스트로 마스터를 이동하지 않습니다.

14.2. 클러스터에서 IP 페일오버 구성

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

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

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

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

사전 요구 사항

프로세스

  1. IP 페일오버 서비스 계정을 생성합니다.

    $ oc create sa ipfailover
    Copy to Clipboard Toggle word wrap
  2. hostNetwork의 SCC(보안 컨텍스트 제약 조건)를 업데이트합니다.

    $ oc adm policy add-scc-to-user privileged -z ipfailover
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-scc-to-user hostnetwork -z ipfailover
    Copy to Clipboard Toggle word wrap
  3. RHOSP(Red Hat OpenStack Platform)만 해당: RHOSP 포트에서 장애 조치 VIP 주소에 연결할 수 있도록 다음 단계를 완료합니다.

    1. RHOSP CLI를 사용하여 RHOSP 클러스터의 allowed_address_pairs 매개변수에 기본 RHOSP API 및 VIP 주소를 표시합니다.

      $ openstack port show <cluster_name> -c allowed_address_pairs
      Copy to Clipboard Toggle word wrap

      출력 예

      *Field*                  *Value*
      allowed_address_pairs    ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb'
                               ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'
      Copy to Clipboard Toggle word wrap

    2. IP 페일오버 배포의 다른 VIP 주소를 설정하고 RHOSP CLI에 다음 명령을 입력하여 RHOSP 포트에서 주소에 연결할 수 있도록 합니다. 기본 RHOSP API 및 VIP 주소를 IP 페일오버 배포의 페일오버 VIP 주소로 설정하지 마십시오.

      1.1.1.1 페일오버 IP 주소를 RHOSP 포트에서 허용된 주소로 추가하는 예.

      $ openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cb
      Copy to Clipboard Toggle word wrap

    3. 배포 YAML 파일을 생성하여 배포에 대한 IP 페일오버를 구성합니다. 이후 단계에서 "IP 페일오버 구성용 배포 YAML 예"를 참조하십시오.
    4. 장애 조치(failover) VIP 주소를 OPENSHIFT_HA_VIRTUAL_IPS 환경 변수에 전달하도록 IP 페일오버 배포에서 다음 사양을 지정합니다.

      OPENSHIFT_HA_VIRTUAL_IPS1.1.1.1 VIP 주소를 추가하는 예

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: ipfailover-keepalived
      # ...
            spec:
                env:
                - name: OPENSHIFT_HA_VIRTUAL_IPS
                value: "1.1.1.1"
      # ...
      Copy to Clipboard Toggle word wrap

  4. 배포 YAML 파일을 생성하여 IP 페일오버를 구성합니다.

    참고

    RHOSP(Red Hat OpenStack Platform)의 경우 배포 YAML 파일을 다시 생성할 필요가 없습니다. 이전 명령의 일부로 이 파일을 이미 생성하셨습니다.

    IP 페일오버 구성을 위한 배포 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: registry.redhat.io/openshift4/ose-keepalived-ipfailover:v4.13
            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
    Copy to Clipboard Toggle word wrap

    1
    IP 페일오버 배포의 이름입니다.
    2
    복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: 1.2.3.4-6,1.2.3.9.
    3
    VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 OPENSHIFT_HA_VIP_GROUPS 변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다.
    4
    IP 페일오버가 VRRP 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본적으로 eth0이 사용됩니다.
    5
    IP 페일오버 pod는 각 VIP에서 이 포트에 대한 TCP 연결을 열려고 합니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 0으로 설정되면 테스트가 항상 통과합니다. 기본값은 80입니다.
    6
    가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 0이며 허용되는 범위는 0에서 255 사이입니다.
    7
    생성할 복제본 수입니다. 이는 IP 페일오버 배포 구성의 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
    배포를 만들기 전에 풀 시크릿을 생성합니다. 그렇지 않으면 배포를 생성할 때 오류가 발생합니다.

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

keepalived는 사용자 제공 검사 스크립트를 주기적으로 실행하여 애플리케이션의 상태를 모니터링합니다. 예를 들어 스크립트는 요청을 발행하고 응답을 확인하여 웹 서버를 테스트할 수 있습니다. 클러스터 관리자는 상태가 변경될 때마다 호출되는 선택적 알림 스크립트를 제공할 수 있습니다.

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

Keepalived가 시작될 때마다 로드되는 검사 및 알림 스크립트의 전체 경로 이름이 Keepalived 구성 파일인 _/etc/keepalived/keepalived.conf에 추가됩니다. 스크립트는 다음 방법에 설명된 대로 ConfigMap 오브젝트를 사용하여 Pod에 추가할 수 있습니다.

스크립트 확인

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

각 IP 페일오버 Pod는 Pod가 실행 중인 노드에서 하나 이상의 가상 IP(VIP) 주소를 관리하는 Keepalived 데몬을 관리합니다. Keepalived 데몬은 해당 노드의 각 VIP 상태를 유지합니다. 특정 노드의 특정 VIP는 master,backup 또는 fault 상태가 될 수 있습니다.

검사 스크립트가 0이 아닌 값을 반환하면 노드가 백업 상태가 되고 보유한 VIP가 다시 할당됩니다.

스크립트 알림

keepalived는 다음 세 가지 매개변수를 알림 스크립트에 전달합니다.

  • $1 - group 또는 instance
  • $2 - group 또는 instance 이름
  • $3 - 새 상태: master, backup 또는 fault

사전 요구 사항

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

프로세스

  1. 원하는 스크립트를 생성하고 저장할 ConfigMap 오브젝트를 생성합니다. 스크립트에는 입력 인수가 없으며 OK의 경우 0fail의 경우 1을 반환해야 합니다.

    검사 스크립트, mycheckscript.sh:

    #!/bin/bash
        # Whatever tests are needed
        # E.g., send request and verify response
    exit 0
    Copy to Clipboard Toggle word wrap
  2. ConfigMap 오브젝트를 생성합니다.

    $ oc create configmap mycustomcheck --from-file=mycheckscript.sh
    Copy to Clipboard Toggle word wrap
  3. pod에 스크립트를 추가합니다. 마운트된 ConfigMap 오브젝트 파일의 defaultModeoc 명령을 사용하거나 배포 구성을 편집하여 실행할 수 있어야 합니다. 0755, 493 10진수 값이 일반적입니다.

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

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

    작은 정보

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

    $ oc edit deploy ipfailover-keepalived
    Copy to Clipboard Toggle word wrap
        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
    ...
    Copy to Clipboard Toggle word wrap
    1
    spec.container.env 필드에서 마운트된 스크립트 파일을 가리키도록 OPENSHIFT_HA_CHECK_SCRIPT 환경 변수를 추가합니다.
    2
    spec.container.volumeMounts 필드를 추가하여 마운트 지점을 생성합니다.
    3
    spec.volumes 필드를 추가하여 구성 맵을 언급합니다.
    4
    파일에 대한 실행 권한을 설정합니다. 다시 읽으면 10진수 493으로 표시됩니다.

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

14.4. VRRP 선점 구성

노드의 가상 IP(VIP)가 검사 스크립트를 전달하여 fault 상태를 벗어나면 노드의 VIP가 현재 master 상태에 있는 노드의 VIP보다 우선 순위가 낮은 경우 backup 상태가 됩니다. nopreempt 전략에서는 호스트의 우선 순위가 낮은 VIP에서 호스트의 우선 순위가 높은 VIP로 master를 이동하지 않습니다. preempt_delay 300을 사용하면 기본값인 Keepalived가 지정된 300초 동안 기다린 후 fault를 호스트의 우선 순위 VIP로 이동합니다.

프로세스

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

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

14.5. 여러 IP 페일오버 인스턴스 배포

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

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

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

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

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

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

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

참고

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

참고

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

사전 요구 사항

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

프로세스

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

    IP 페일오버 구성을 위한 Deployment YAML의 예

    ...
        spec:
            env:
            - name: OPENSHIFT_HA_VIP_GROUPS 
    1
    
              value: "3"
    ...
    Copy to Clipboard Toggle word wrap

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

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

14.7. ExternalIP의 고가용성

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

접근 방식은 클러스터 네트워크 구성의 spec.ExternalIP.autoAssignCIDRs 범위를 지정한 다음 IP 페일오버 구성을 생성할 때 동일한 범위를 사용하는 것입니다.

IP 페일오버는 전체 클러스터에 대해 최대 255개의 VIP를 지원할 수 있으므로 spec.ExternalIP.autoAssignCIDRs/24 또는 작아야 합니다.

14.8. IP 페일오버 제거

IP 페일오버가 처음 구성되면 클러스터의 작업자 노드는 Keepalived에 대해 224.0.0.18의 멀티 캐스트 패킷을 명시적으로 허용하는 iptables 규칙을 사용하여 수정됩니다. 노드를 변경하여 IP 페일오버를 제거하려면 iptables 규칙을 제거하고 Keepalived에서 사용하는 가상 IP 주소를 제거하는 작업을 실행해야 합니다.

프로세스

  1. 선택 사항: 구성 맵으로 저장된 점검 및 알림 스크립트를 식별하고 삭제합니다.

    1. IP 페일오버에 대한 Pod가 구성 맵을 볼륨으로 사용하는지 여부를 확인합니다.

      $ oc get pod -l ipfailover \
        -o jsonpath="\
      {range .items[?(@.spec.volumes[*].configMap)]}
      {'Namespace: '}{.metadata.namespace}
      {'Pod:       '}{.metadata.name}
      {'Volumes that use config maps:'}
      {range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
        {'configMap: '}{.configMap.name}{'\n'}{end}
      {end}"
      Copy to Clipboard Toggle word wrap

      출력 예

      Namespace: default
      Pod:       keepalived-worker-59df45db9c-2x9mn
      Volumes that use config maps:
        volume:    config-volume
        configMap: mycustomcheck
      Copy to Clipboard Toggle word wrap

    2. 이전 단계에서 볼륨으로 사용되는 구성 맵의 이름을 제공한 경우 구성 맵을 삭제합니다.

      $ oc delete configmap <configmap_name>
      Copy to Clipboard Toggle word wrap
  2. IP 페일오버를 위한 기존 배포를 식별합니다.

    $ oc get deployment -l ipfailover
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    default     ipfailover   2/2     2            2           105d
    Copy to Clipboard Toggle word wrap

  3. 배포를 삭제합니다.

    $ oc delete deployment <ipfailover_deployment_name>
    Copy to Clipboard Toggle word wrap
  4. ipfailover 서비스 계정을 제거합니다.

    $ oc delete sa ipfailover
    Copy to Clipboard Toggle word wrap
  5. IP 페일오버를 처음 구성할 때 추가된 IP 테이블 규칙을 제거하는 작업을 실행합니다.

    1. 다음 예와 유사한 콘텐츠를 사용하여 remove-ipfailover-job.yaml과 같은 파일을 생성합니다.

      apiVersion: batch/v1
      kind: Job
      metadata:
        generateName: remove-ipfailover-
        labels:
          app: remove-ipfailover
      spec:
        template:
          metadata:
            name: remove-ipfailover
          spec:
            containers:
            - name: remove-ipfailover
              image: registry.redhat.io/openshift4/ose-keepalived-ipfailover:v4.13
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector: 
      1
      
              kubernetes.io/hostname: <host_name>  
      2
      
            restartPolicy: Never
      Copy to Clipboard Toggle word wrap
      1
      nodeSelector 는 이전 IP 페일오버 배포에 사용된 선택기와 같을 수 있습니다.
      2
      IP 페일오버용으로 구성된 클러스터의 각 노드에 대해 작업을 실행하고 매번 호스트 이름을 바꿉니다.
    2. 작업을 실행합니다.

      $ oc create -f remove-ipfailover-job.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      job.batch/remove-ipfailover-2h8dm created
      Copy to Clipboard Toggle word wrap

검증

  • 작업이 IP 페일오버의 초기 구성을 제거했는지 확인합니다.

    $ oc logs job/remove-ipfailover-2h8dm
    Copy to Clipboard Toggle word wrap

    출력 예

    remove-failover.sh: OpenShift IP Failover service terminating.
      - Removing ip_vs module ...
      - Cleaning up ...
      - Releasing VIPs  (interface eth0) ...
    Copy to Clipboard Toggle word wrap

15장. 인터페이스 수준 네트워크 sysctl 구성

Linux에서 sysctl을 사용하면 관리자가 런타임에 커널 매개 변수를 수정할 수 있습니다. 튜닝 CNI(Container Network Interface) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl을 수정할 수 있습니다. 튜닝 CNI 메타 플러그인은 설명된 대로 기본 CNI 플러그인이 있는 체인에서 작동합니다.

기본 CNI 플러그인은 인터페이스를 할당하고 런타임 시 튜닝 CNI 메타 플러그인에 이를 전달합니다. 튜닝 CNI 메타 플러그인을 사용하여 네트워크 네임스페이스에서 일부 sysctl 및 여러 인터페이스 속성(프로미스 모드, all-multicast 모드, MTU 및 MAC 주소)을 변경할 수 있습니다. 튜닝 CNI 메타 플러그인 구성에서 인터페이스 이름은 IFNAME 토큰으로 표시되고 런타임 시 인터페이스 이름으로 교체됩니다.

참고

OpenShift Container Platform에서 튜닝 CNI 메타 플러그인은 인터페이스 수준 네트워크 sysctl 변경만 지원합니다.

15.1. 튜닝 CNI 구성

다음 절차에서는 인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects sysctl을 변경하도록 튜닝 CNI를 구성합니다. 이 예제에서는 ICMP 리디렉션된 패킷을 수락하고 전송할 수 있습니다.

절차

  1. 다음 콘텐츠를 사용하여 tuning-example.yaml 과 같은 네트워크 연결 정의를 생성합니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: <name> 
    1
    
      namespace: default 
    2
    
    spec:
      config: '{
        "cniVersion": "0.4.0", 
    3
    
        "name": "<name>", 
    4
    
        "plugins": [{
           "type": "<main_CNI_plugin>" 
    5
    
          },
          {
           "type": "tuning", 
    6
    
           "sysctl": {
                "net.ipv4.conf.IFNAME.accept_redirects": "1" 
    7
    
            }
          }
         ]
    }
    Copy to Clipboard Toggle word wrap
    1
    생성할 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 네임스페이스 내에서 고유해야 합니다.
    2
    오브젝트가 연결된 네임스페이스를 지정합니다.
    3
    CNI 사양 버전을 지정합니다.
    4
    구성의 이름을 지정합니다. 구성 이름을 네트워크 연결 정의의 name 값과 일치시키는 것이 좋습니다.
    5
    구성할 기본 CNI 플러그인의 이름을 지정합니다.
    6
    CNI 메타 플러그인의 이름을 지정합니다.
    7
    설정할 sysctl을 지정합니다.

    yaml 파일의 예는 다음과 같습니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: tuningnad
      namespace: default
    spec:
      config: '{
        "cniVersion": "0.4.0",
        "name": "tuningnad",
        "plugins": [{
          "type": "bridge"
          },
          {
          "type": "tuning",
          "sysctl": {
             "net.ipv4.conf.IFNAME.accept_redirects": "1"
            }
        }
      ]
    }'
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 yaml을 적용합니다.

    $ oc apply -f tuning-example.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
    Copy to Clipboard Toggle word wrap

  3. 다음과 유사한 네트워크 연결 정의를 사용하여 examplepod.yaml 과 같은 Pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/networks: tuningnad 
    1
    
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000 
    2
    
          runAsGroup: 3000 
    3
    
          allowPrivilegeEscalation: false 
    4
    
          capabilities: 
    5
    
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true 
    6
    
        seccompProfile: 
    7
    
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    1
    구성된 NetworkAttachmentDefinition 의 이름을 지정합니다.
    2
    RunAsUser 는 컨테이너가 실행되는 사용자 ID를 제어합니다.
    3
    RunAsGroup 은 컨테이너를 사용하여 실행하는 기본 그룹 ID를 제어합니다.
    4
    allowPrivilegeEscalation 은 Pod에서 권한 에스컬레이션을 허용하도록 요청할 수 있는지 여부를 결정합니다. 지정하지 않으면 기본값은 true입니다. 이 부울은 no_new_privs 플래그가 컨테이너 프로세스에 설정되어 있는지 여부를 직접 제어합니다.
    5
    기능을 통해 완전한 루트 액세스 권한을 부여하지 않고 권한 있는 작업을 수행할 수 있습니다. 이 정책은 Pod에서 모든 기능을 삭제합니다.
    6
    runAsNonRoot: true 를 사용하려면 컨테이너가 0 이외의 UID가 있는 사용자로 컨테이너를 실행해야 합니다.
    7
    RuntimeDefault 는 Pod 또는 컨테이너 워크로드에 대한 기본 seccomp 프로필을 활성화합니다.
  4. 다음 명령을 실행하여 yaml을 적용합니다.

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 포드에 로그인합니다.

    $ oc rsh tunepod
    Copy to Clipboard Toggle word wrap
  7. 구성된 sysctl 플래그의 값을 확인합니다. 예를 들어 다음 명령을 실행하여 net.ipv4.conf.net1.accept_redirects 값을 찾습니다.

    sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
    Copy to Clipboard Toggle word wrap

    예상 출력

    net.ipv4.conf.net1.accept_redirects = 1
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

16.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
Copy to Clipboard Toggle word wrap

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

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP
Copy to Clipboard Toggle word wrap

다음 예에서 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
Copy to Clipboard Toggle word wrap

16.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
    Copy to Clipboard Toggle word wrap
  2. MachineConfig 오브젝트를 생성하려면 다음 명령을 입력합니다.

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

16.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/ubi9/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
            ports:
              - containerPort: 30102
                name: sctpserver
                protocol: SCTP
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 입력하여 pod를 생성합니다.

      $ oc create -f sctp-server.yaml
      Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap
    2. 서비스를 생성하려면 다음 명령을 입력합니다.

      $ oc create -f sctp-service.yaml
      Copy to Clipboard Toggle word wrap
  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/ubi9/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
      Copy to Clipboard Toggle word wrap
    2. Pod 오브젝트를 생성하려면 다음 명령을 입력합니다.

      $ oc apply -f sctp-client.yaml
      Copy to Clipboard Toggle word wrap
  4. 서버에서 SCTP 리스너를 실행합니다.

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

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

      $ nc -l 30102 --sctp
      Copy to Clipboard Toggle word wrap
  5. 서버의 SCTP 리스너에 연결합니다.

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

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

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

      # nc <cluster_IP> 30102 --sctp
      Copy to Clipboard Toggle word wrap

17장. PTP 하드웨어 사용

linuxptp 서비스를 구성하고 OpenShift Container Platform 클러스터 노드에서 PTP 지원 하드웨어를 사용할 수 있습니다.

17.1. PTP 하드웨어 정보

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

  • 클러스터에서 PTP 가능 장치 검색.
  • linuxptp 서비스의 구성 관리.
  • PTP Operator cloud-event-proxy 사이드카를 사용하여 애플리케이션의 성능 및 안정성에 부정적인 영향을 주는 PTP 클록 이벤트 알림
참고

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

17.2. PTP 정보

PTP(Precision Time Protocol)는 네트워크의 클럭을 동기화하는 데 사용됩니다. 하드웨어 지원과 함께 사용할 경우 PTP는 마이크로초 미만의 정확성을 수행할 수 있으며 NTP(Network Time Protocol)보다 더 정확합니다.

17.2.1. PTP 도메인의 요소

PTP는 네트워크에 연결된 여러 노드를 각 노드의 클럭과 동기화하는 데 사용됩니다. PTP에 의해 동기화된 클럭은 소스 대상 계층 구조로 구성됩니다. 계층 구조는 모든 클럭에서 실행되는 최상의 마스터 클럭(BMC) 알고리즘에 의해 자동으로 생성되고 업데이트됩니다. 대상 클럭은 소스 클럭에 동기화되며 대상 클럭은 다른 다운스트림 클럭의 소스일 수 있습니다. 아래에는 PTP 시계의 세 가지 기본 유형이 설명되어 있습니다.

GRandmaster 클록
마스터 클록은 네트워크의 다른 클록에 표준 시간 정보를 제공하며 정확하고 안정적인 동기화를 보장합니다. 타임스탬프를 작성하고 다른 시계의 시간 요청에 응답합니다. GNSS(Global Navigation Satellite System) 시간 소스와 동기화됩니다. master 시계는 네트워크에서 신뢰할 수있는 시간 소스이며 다른 모든 장치에 시간 동기화를 제공합니다.
일반 클록
일반 클록에는 네트워크의 위치에 따라 소스 또는 대상 클록의 역할을 수행할 수 있는 단일 포트가 연결되어 있습니다. 일반 클록은 타임스탬프를 읽고 쓸 수 있습니다.
경계 클록
경계 클록에는 두 개 이상의 통신 경로에 포트가 있으며, 동시에 소스와 다른 대상 클록의 대상일 수 있습니다. 경계 클록은 대상 클록으로 작동합니다. 대상 클럭이 타이밍 메시지를 수신하고 지연을 조정한 다음 네트워크를 전달하기 위한 새 소스 시간 신호를 생성합니다. 경계 클록은 소스 클록과 정확하게 동기화되는 새로운 타이밍 패킷을 생성하며 소스 클럭에 직접 보고하는 연결된 장치의 수를 줄일 수 있습니다.

17.2.2. NTP를 통한 PTP의 이점

PTP가 NTP를 능가하는 주요 이점 중 하나는 다양한 NIC(네트워크 인터페이스 컨트롤러) 및 네트워크 스위치에 있는 하드웨어 지원입니다. 특수 하드웨어를 사용하면 PTP가 메시지 전송 지연을 고려하여 시간 동기화의 정확성을 향상시킬 수 있습니다. 최대한의 정확성을 달성하려면 PTP 클록 사이의 모든 네트워킹 구성 요소를 PTP 하드웨어를 사용하도록 설정하는 것이 좋습니다.

NIC는 전송 및 수신 즉시 PTP 패킷을 타임스탬프할 수 있으므로 하드웨어 기반 PTP는 최적의 정확성을 제공합니다. 이를 운영 체제에서 PTP 패킷을 추가로 처리해야 하는 소프트웨어 기반 PTP와 비교합니다.

중요

PTP를 활성화하기 전에 필수 노드에 대해 NTP가 비활성화되어 있는지 확인합니다. MachineConfig 사용자 정의 리소스를 사용하여 chrony 타임 서비스 (chronyd)를 비활성화할 수 있습니다. 자세한 내용은 chrony 타임 서비스 비활성화를 참조하십시오.

17.2.3. 듀얼 NIC 하드웨어에서 PTP 사용

OpenShift Container Platform은 클러스터에서 PTP 타이밍을 위해 단일 및 듀얼 NIC 하드웨어를 지원합니다.

중간 대역의 가상 분산 장치(vDU)를 제공하는 5G 통신 네트워크의 경우 각 가상 분산 단위(vDU)는 6개의 무선 장치(RU)에 연결해야 합니다. 이러한 연결을 위해 각 vDU 호스트에는 경계 클럭으로 구성된 2개의 NIC가 필요합니다.

듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 각 NIC에 대해 별도의 ptp4l 인스턴스를 사용하여 각 NIC를 동일한 업스트림 리더 클럭에 연결할 수 있습니다.

17.3. OpenShift Container Platform 노드의 linuxptp 개요

OpenShift Container Platform은 베어 메탈 인프라에서 높은 정밀 시스템 타이밍을 위해 PTP 및 linuxptp 를 사용합니다. linuxptp 패키지에는 시스템 클럭 동기화를 위한 ts2phc,pmc,ptp4l, phc2sys 프로그램이 포함되어 있습니다.

ts2phc

ts2phc 는 PTP 장치 전체에서 PTP 하드웨어 클럭(PHC)을 높은 수준의 정확도와 동기화합니다. ts2phc 는 경수 마스터 클럭 구성에 사용됩니다. GPS(Global Navigation Satellite System)와 같은 정밀한 클럭 소스를 수신합니다. GNSS는 대규모 분산 네트워크에서 사용하기 위해 정확하고 안정적인 동기화 시간 소스를 제공합니다. GNSS 시계는 일반적으로 몇 나노초의 정확도로 시간 정보를 제공합니다.

ts2phc 시스템 데몬은 경직 마스터 시계에서 시간 정보를 읽고 PHC 형식으로 변환하여 네트워크의 다른 PTP 장치로 타이밍 정보를 보냅니다. PHC 시간은 네트워크의 다른 장치에 의해 시계를 그랜드 마스터 시계와 동기화하는 데 사용됩니다.

pmc
PMC 는 IEEE 표준 1588.1588에 따라 PTP 관리 클라이언트(pmc)를 구현합니다. PMCptp4l 시스템 데몬에 대한 기본 관리 액세스를 제공합니다. PMC 는 표준 입력에서 읽고 선택한 전송에 대한 출력을 전송하여 수신한 모든 응답을 출력합니다.
ptp4l

ptp4l 은 PTP 경계 클럭과 일반 시계를 구현하고 시스템 데몬으로 실행됩니다. ptp4l 은 다음을 수행합니다.

  • 하드웨어 타임 스탬프를 사용하여 PHC를 소스 클럭과 동기화
  • 소프트웨어 타임스탬프를 사용하여 시스템 시계를 소스 클럭에 동기화
phc2sys
phc2sys 는 시스템 시계를 NIC(네트워크 인터페이스 컨트롤러)의 PHC에 동기화합니다. phc2sys 시스템 데몬은 타이밍 정보를 위해 PHC를 지속적으로 모니터링합니다. 타이밍 오류를 감지하면 PHC가 시스템 시계를 수정합니다.

17.4. CLI를 사용하여 PTP Operator 설치

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

사전 요구 사항

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

절차

  1. PTP Operator의 네임스페이스를 생성합니다.

    1. 다음 YAML을 ptp-namespace.yaml 파일에 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-ptp
        annotations:
          workload.openshift.io/allowed: management
        labels:
          name: openshift-ptp
          openshift.io/cluster-monitoring: "true"
      Copy to Clipboard Toggle word wrap
    2. Namespace CR을 생성합니다.

      $ oc create -f ptp-namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. PTP Operator에 대한 Operator group을 생성합니다.

    1. 다음 YAML을 ptp-operatorgroup.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: ptp-operators
        namespace: openshift-ptp
      spec:
        targetNamespaces:
        - openshift-ptp
      Copy to Clipboard Toggle word wrap
    2. OperatorGroup CR을 생성합니다.

      $ oc create -f ptp-operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. PTP Operator에 등록합니다.

    1. 다음 YAML을 ptp-sub.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "stable"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
    2. Subscription CR을 생성합니다.

      $ oc create -f ptp-sub.yaml
      Copy to Clipboard Toggle word wrap
  4. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    출력 예

    Name                         Phase
    4.13.0-202301261535          Succeeded
    Copy to Clipboard Toggle word wrap

17.5. 웹 콘솔을 사용하여 PTP Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 PTP 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 로그를 확인합니다.

17.6. PTP 장치 구성

PTP Operator는 NodePtpDevice.ptp.openshift.io CRD(custom resource definition)를 OpenShift Container Platform에 추가합니다.

PTP Operator가 설치되면 각 노드에서 PTP 가능 네트워크 장치를 클러스터에서 검색합니다. 호환되는 PTP 가능 네트워크 장치를 제공하는 각 노드에 대해 NodePtpDevice CR(사용자 정의 리소스) 오브젝트를 생성하고 업데이트합니다.

17.6.1. 클러스터에서 PTP 지원 네트워크 장치 검색

  • 클러스터에서 PTP 가능 네트워크 장치의 전체 목록을 반환하려면 다음 명령을 실행합니다.

    $ oc get NodePtpDevice -n openshift-ptp -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    items:
    - apiVersion: ptp.openshift.io/v1
      kind: NodePtpDevice
      metadata:
        creationTimestamp: "2022-01-27T15:16:28Z"
        generation: 1
        name: dev-worker-0 
    1
    
        namespace: openshift-ptp
        resourceVersion: "6538103"
        uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
      spec: {}
      status:
        devices: 
    2
    
        - name: eno1
        - name: eno2
        - name: eno3
        - name: eno4
        - name: enp5s0f0
        - name: enp5s0f1
    ...
    Copy to Clipboard Toggle word wrap

    1
    name 매개변수의 값은 상위 노드의 이름과 동일합니다.
    2
    장치 컬렉션에는 PTP Operator가 노드에 대해 검색하는 PTP 가능 장치 목록이 포함됩니다.

17.6.2. linuxptp 서비스를 위주로 구성

호스트 NIC를 구성하는 PtpConfig CR(사용자 정의 리소스)을 생성하여 linuxptp 서비스(ptp4l,phc2sys,ts2phc)를 마스터 클록(T-GM)으로 구성할 수 있습니다.

ts2phc 유틸리티를 사용하면 노드가 PTP 일반 시계 및 경계 클럭을 다운스트림하기 위해 정확도 시계 신호를 스트리밍할 수 있도록 시스템 시계를 PTP 유예 시계 시계와 동기화할 수 있습니다.

참고

다음 예제 PtpConfig CR을 기반으로 사용하여 linuxptp 서비스를 특정 하드웨어 및 환경에 대한 그랜드마스터 시계로 구성합니다. 이 예제 CR에서는 PTP 빠른 이벤트를 구성하지 않습니다. PTP 빠른 이벤트를 구성하려면 ptp4lOpts,ptp4lConf, ptpClockThreshold 에 적절한 값을 설정합니다. ptpClockThreshold 는 이벤트가 활성화된 경우에만 사용됩니다. 자세한 내용은 " PTP 빠른 이벤트 알림 게시자 구성"을 참조하십시오.

사전 요구 사항

  • 프로덕션 환경의 T-GM 클록의 경우 베어 메탈 클러스터 호스트에 Intel E810 Westport 채널 NIC를 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • PTP Operator를 설치합니다.

절차

  1. PtpConfig 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    1. 요구 사항에 따라 배포에 다음 T-GM 구성 중 하나를 사용하십시오. YAML을 grandmaster-clock-ptp-config.yaml 파일에 저장합니다.

      예 17.1. PTP grandmaster 클럭 구성의 예

      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        name: grandmaster-clock
        namespace: openshift-ptp
        annotations: {}
      spec:
        profile:
          - name: grandmaster-clock
            # The interface name is hardware-specific
            interface: $interface
            ptp4lOpts: "-2"
            phc2sysOpts: "-a -r -r -n 24"
            ptpSchedulingPolicy: SCHED_FIFO
            ptpSchedulingPriority: 10
            ptpSettings:
              logReduce: "true"
            ptp4lConf: |
              [global]
              #
              # Default Data Set
              #
              twoStepFlag 1
              slaveOnly 0
              priority1 128
              priority2 128
              domainNumber 24
              #utc_offset 37
              clockClass 255
              clockAccuracy 0xFE
              offsetScaledLogVariance 0xFFFF
              free_running 0
              freq_est_interval 1
              dscp_event 0
              dscp_general 0
              dataset_comparison G.8275.x
              G.8275.defaultDS.localPriority 128
              #
              # Port Data Set
              #
              logAnnounceInterval -3
              logSyncInterval -4
              logMinDelayReqInterval -4
              logMinPdelayReqInterval -4
              announceReceiptTimeout 3
              syncReceiptTimeout 0
              delayAsymmetry 0
              fault_reset_interval -4
              neighborPropDelayThresh 20000000
              masterOnly 0
              G.8275.portDS.localPriority 128
              #
              # Run time options
              #
              assume_two_step 0
              logging_level 6
              path_trace_enabled 0
              follow_up_info 0
              hybrid_e2e 0
              inhibit_multicast_service 0
              net_sync_monitor 0
              tc_spanning_tree 0
              tx_timestamp_timeout 50
              unicast_listen 0
              unicast_master_table 0
              unicast_req_duration 3600
              use_syslog 1
              verbose 0
              summary_interval 0
              kernel_leap 1
              check_fup_sync 0
              clock_class_threshold 7
              #
              # Servo Options
              #
              pi_proportional_const 0.0
              pi_integral_const 0.0
              pi_proportional_scale 0.0
              pi_proportional_exponent -0.3
              pi_proportional_norm_max 0.7
              pi_integral_scale 0.0
              pi_integral_exponent 0.4
              pi_integral_norm_max 0.3
              step_threshold 2.0
              first_step_threshold 0.00002
              max_frequency 900000000
              clock_servo pi
              sanity_freq_limit 200000000
              ntpshm_segment 0
              #
              # Transport options
              #
              transportSpecific 0x0
              ptp_dst_mac 01:1B:19:00:00:00
              p2p_dst_mac 01:80:C2:00:00:0E
              udp_ttl 1
              udp6_scope 0x0E
              uds_address /var/run/ptp4l
              #
              # Default interface options
              #
              clock_type OC
              network_transport L2
              delay_mechanism E2E
              time_stamping hardware
              tsproc_mode filter
              delay_filter moving_median
              delay_filter_length 10
              egressLatency 0
              ingressLatency 0
              boundary_clock_jbod 0
              #
              # Clock description
              #
              productDescription ;;
              revisionData ;;
              manufacturerIdentity 00:00:00
              userDescription ;
              timeSource 0xA0
        recommend:
          - profile: grandmaster-clock
            priority: 4
            match:
              - nodeLabel: "node-role.kubernetes.io/$mcp"
      Copy to Clipboard Toggle word wrap
      참고

      예제 PTP 할 마스터 클록 구성은 테스트 목적으로만 사용되며 프로덕션을 위한 것은 아닙니다.

      예 17.2. E810 NIC의 PTP 마스터 클럭 구성

      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        name: grandmaster
        namespace: openshift-ptp
        annotations:
          ran.openshift.io/ztp-deploy-wave: "10"
      spec:
        profile:
        - name: "grandmaster"
          ptp4lOpts: "-2 --summary_interval -4"
          phc2sysOpts: -r -u 0 -m -O -37 -N 8 -R 16 -s $iface_master -n 24
          ptpSchedulingPolicy: SCHED_FIFO
          ptpSchedulingPriority: 10
          ptpSettings:
            logReduce: "true"
          plugins:
            e810:
              enableDefaultConfig: true
          ts2phcOpts: " "
          ts2phcConf: |
            [nmea]
            ts2phc.master 1
            [global]
            use_syslog  0
            verbose 1
            logging_level 7
            ts2phc.pulsewidth 100000000
            ts2phc.nmea_serialport $gnss_serialport
            leapfile  /usr/share/zoneinfo/leap-seconds.list
            [$iface_master]
            ts2phc.extts_polarity rising
            ts2phc.extts_correction 0
          ptp4lConf: |
            [$iface_master]
            masterOnly 1
            [$iface_master_1]
            masterOnly 1
            [$iface_master_2]
            masterOnly 1
            [$iface_master_3]
            masterOnly 1
            [global]
            #
            # Default Data Set
            #
            twoStepFlag 1
            priority1 128
            priority2 128
            domainNumber 24
            #utc_offset 37
            clockClass 6
            clockAccuracy 0x27
            offsetScaledLogVariance 0xFFFF
            free_running 0
            freq_est_interval 1
            dscp_event 0
            dscp_general 0
            dataset_comparison G.8275.x
            G.8275.defaultDS.localPriority 128
            #
            # Port Data Set
            #
            logAnnounceInterval -3
            logSyncInterval -4
            logMinDelayReqInterval -4
            logMinPdelayReqInterval 0
            announceReceiptTimeout 3
            syncReceiptTimeout 0
            delayAsymmetry 0
            fault_reset_interval -4
            neighborPropDelayThresh 20000000
            masterOnly 0
            G.8275.portDS.localPriority 128
            #
            # Run time options
            #
            assume_two_step 0
            logging_level 6
            path_trace_enabled 0
            follow_up_info 0
            hybrid_e2e 0
            inhibit_multicast_service 0
            net_sync_monitor 0
            tc_spanning_tree 0
            tx_timestamp_timeout 50
            unicast_listen 0
            unicast_master_table 0
            unicast_req_duration 3600
            use_syslog 1
            verbose 0
            summary_interval -4
            kernel_leap 1
            check_fup_sync 0
            clock_class_threshold 7
            #
            # Servo Options
            #
            pi_proportional_const 0.0
            pi_integral_const 0.0
            pi_proportional_scale 0.0
            pi_proportional_exponent -0.3
            pi_proportional_norm_max 0.7
            pi_integral_scale 0.0
            pi_integral_exponent 0.4
            pi_integral_norm_max 0.3
            step_threshold 2.0
            first_step_threshold 0.00002
            clock_servo pi
            sanity_freq_limit  200000000
            ntpshm_segment 0
            #
            # Transport options
            #
            transportSpecific 0x0
            ptp_dst_mac 01:1B:19:00:00:00
            p2p_dst_mac 01:80:C2:00:00:0E
            udp_ttl 1
            udp6_scope 0x0E
            uds_address /var/run/ptp4l
            #
            # Default interface options
            #
            clock_type BC
            network_transport L2
            delay_mechanism E2E
            time_stamping hardware
            tsproc_mode filter
            delay_filter moving_median
            delay_filter_length 10
            egressLatency 0
            ingressLatency 0
            boundary_clock_jbod 0
            #
            # Clock description
            #
            productDescription ;;
            revisionData ;;
            manufacturerIdentity 00:00:00
            userDescription ;
            timeSource 0x20
        recommend:
        - profile: "grandmaster"
          priority: 4
          match:
          - nodeLabel: "node-role.kubernetes.io/$mcp"
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 CR을 생성합니다.

      $ oc create -f grandmaster-clock-ptp-config.yaml
      Copy to Clipboard Toggle word wrap

검증

  1. PtpConfig 프로필이 노드에 적용되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-ptp 네임스페이스에서 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-ptp -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
      linuxptp-daemon-74m2g         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
      ptp-operator-5f4f48d7c-x7zkf  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com
      Copy to Clipboard Toggle word wrap

    2. 프로필이 올바른지 확인합니다. PtpConfig 프로필에 지정한 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 다음 명령을 실행합니다.

      $ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
      Copy to Clipboard Toggle word wrap

      출력 예

      ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns
      ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1
      ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset         -1 s2 freq      -1
      ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V
      phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset       943 s2 freq  -89604 delay    504
      phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset      1000 s2 freq  -89264 delay    474
      Copy to Clipboard Toggle word wrap

17.6.2.1. ovnmaster 클럭 PtpConfig 구성 참조

다음 참조 정보는 linuxptp 서비스(ptp4l,phc2sys,ts2phc)를 마스터 클록으로 구성하는 PtpConfig CR(사용자 정의 리소스)의 구성 옵션을 설명합니다.

Expand
표 17.1. PTP>-<master 클럭에 대한 PtpConfig 구성 옵션
PtpConfig CR 필드설명

plugins

.exec.cmdline 옵션의 배열을 지정하여 그랜드 마스터 클럭 작업에 대한 NIC를 구성합니다. ovnmaster 클럭 구성을 사용하려면 특정 PTP 핀을 비활성화해야 합니다.

플러그인 메커니즘을 사용하면 PTP Operator가 자동화된 하드웨어 구성을 수행할 수 있습니다. Intel Westport Channel NIC의 경우 enableDefaultConfig 가 true인 경우 PTP Operator는 하드 코딩된 스크립트를 실행하여 NIC에 필요한 구성을 수행합니다.

ptp4lOpts

ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf를 포함하지 않아야 합니다.

ptp4lConf

ptp4l 을 할 마스터 클록으로 시작하는 데 필요한 구성을 지정합니다. 예를 들어 ens2f1 인터페이스는 다운스트림 연결된 장치를 동기화합니다. 마스터 시계의 경우 clockClass6 으로 설정하고 clockAccuracy0x27 로 설정합니다. GNSS(Global navigation satellite system)에서 타이밍 신호를 수신할 때 timeSource0x20 으로 설정합니다.

tx_timestamp_timeout

데이터를 삭제하기 전에 발신자의 전송 (TX) 타임 스탬프를 기다릴 최대 시간을 지정합니다.

boundary_clock_jbod

JBOD 경계 클럭 지연 값을 지정합니다. 이 값은 네트워크 시간 장치 간에 전달되는 시간 값을 수정하는 데 사용됩니다.

phc2sysOpts

phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서 phc2sys 서비스를 시작하지 않습니다.

참고

여기에 나열된 네트워크 인터페이스가 그랜드 마스터로 구성되어 있으며 ts2phcConfptp4lConf 필드에서 필요에 따라 참조되는지 확인합니다.

ptpSchedulingPolicy

ptp4lphc2sys 프로세스에 대한 스케줄링 정책을 구성합니다. 기본값은ECDHE _OTHER 입니다. FIFO 스케줄링을 지원하는 시스템에서ECDHE_ FIFO를 사용합니다.

ptpSchedulingPriority

ptpSchedulingPolicy 가 10.0.0.1 _FIFO로 설정된 경우 ptpSchedulingPolicy의 FIFO 우선 순위를 1-65에서 설정하여 ptp4lphc2sys 프로세스의 FIFO 우선 순위를 구성합니다. ptpSchedulingPriority 필드는 ptpSchedulingPolicy 가ECDHE _OTHER 로 설정된 경우 사용되지 않습니다.

ptpClockThreshold

선택 사항: ptpClockThreshold 스탠자가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

ts2phcConf

ts2phc 명령의 구성을 설정합니다.

leapfile 은 PTP Operator 컨테이너 이미지의 현재 윤초 정의 파일에 대한 기본 경로입니다.

ts2phc.nmea_serialport 는 NMEA GPS 클럭 소스에 연결된 직렬 포트 장치입니다. 구성되면 /dev/gnss<id> 에서 GNSS 수신기에 액세스할 수 있습니다. 호스트에 여러 GNSS 수신자가 있는 경우 다음 장치 중 하나를 사용하여 올바른 장치를 찾을 수 있습니다.

  • /sys/class/net/<eth_port>/device/gnss/
  • /sys/class/gnss/gnss<id>/device/

ts2phcOpts

ts2phc 명령에 대한 옵션을 설정합니다.

권장

프로필을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.

.recommend.profile

profile 섹션에 정의된 .recommend. profile 오브젝트 이름을 지정합니다.

.recommend.priority

0에서 99 사이의 정수 값으로 priority를 지정합니다. 숫자가 클수록 우선순위가 낮으므로 우선순위 99는 우선순위 10보다 낮습니다. match 필드에 정의된 규칙에 따라 여러 프로필과 노드를 일치시킬 수 있는 경우 우선 순위가 높은 프로필이 해당 노드에 적용됩니다.

.recommend.match

nodeLabel 또는 nodeName 값을 사용하여 .recommend.match 규칙을 지정합니다.

.recommend.match.nodeLabel

oc get nodes --show-labels 명령을 사용하여 노드 오브젝트에서 node.Labels 필드의 키로 nodeLabel 을 설정합니다. 예: node-role.kubernetes.io/worker.

.recommend.match.nodeName

oc get nodes 명령을 사용하여 노드 오브젝트의 node.Name 필드 값으로 nodeName 을 설정합니다. 예를 들면 compute-1.example.com 입니다.

17.6.3. linuxptp 서비스를 일반 시계로 구성

PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp 서비스(ptp4l,phc2sys)를 일반 클럭으로 구성할 수 있습니다.

참고

다음 예제 PtpConfig CR을 기반으로 사용하여 linuxptp 서비스를 특정 하드웨어 및 환경에 대한 일반 클럭으로 구성합니다. 이 예제 CR에서는 PTP 빠른 이벤트를 구성하지 않습니다. PTP 빠른 이벤트를 구성하려면 ptp4lOpts,ptp4lConf, ptpClockThreshold 에 적절한 값을 설정합니다. ptpClockThreshold 는 이벤트가 활성화된 경우에만 필요합니다. 자세한 내용은 " PTP 빠른 이벤트 알림 게시자 구성"을 참조하십시오.

사전 요구 사항

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

절차

  1. 다음 PtpConfig CR을 생성한 다음 YAML을 ordinary-clock-ptp-config.yaml 파일에 저장합니다.

    PTP 일반 클럭 구성의 예

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: ordinary-clock
      namespace: openshift-ptp
      annotations: {}
    spec:
      profile:
        - name: ordinary-clock
          # The interface name is hardware-specific
          interface: $interface
          ptp4lOpts: "-2 -s"
          phc2sysOpts: "-a -r -n 24"
          ptpSchedulingPolicy: SCHED_FIFO
          ptpSchedulingPriority: 10
          ptpSettings:
            logReduce: "true"
          ptp4lConf: |
            [global]
            #
            # Default Data Set
            #
            twoStepFlag 1
            slaveOnly 1
            priority1 128
            priority2 128
            domainNumber 24
            #utc_offset 37
            clockClass 255
            clockAccuracy 0xFE
            offsetScaledLogVariance 0xFFFF
            free_running 0
            freq_est_interval 1
            dscp_event 0
            dscp_general 0
            dataset_comparison G.8275.x
            G.8275.defaultDS.localPriority 128
            #
            # Port Data Set
            #
            logAnnounceInterval -3
            logSyncInterval -4
            logMinDelayReqInterval -4
            logMinPdelayReqInterval -4
            announceReceiptTimeout 3
            syncReceiptTimeout 0
            delayAsymmetry 0
            fault_reset_interval -4
            neighborPropDelayThresh 20000000
            masterOnly 0
            G.8275.portDS.localPriority 128
            #
            # Run time options
            #
            assume_two_step 0
            logging_level 6
            path_trace_enabled 0
            follow_up_info 0
            hybrid_e2e 0
            inhibit_multicast_service 0
            net_sync_monitor 0
            tc_spanning_tree 0
            tx_timestamp_timeout 50
            unicast_listen 0
            unicast_master_table 0
            unicast_req_duration 3600
            use_syslog 1
            verbose 0
            summary_interval 0
            kernel_leap 1
            check_fup_sync 0
            clock_class_threshold 7
            #
            # Servo Options
            #
            pi_proportional_const 0.0
            pi_integral_const 0.0
            pi_proportional_scale 0.0
            pi_proportional_exponent -0.3
            pi_proportional_norm_max 0.7
            pi_integral_scale 0.0
            pi_integral_exponent 0.4
            pi_integral_norm_max 0.3
            step_threshold 2.0
            first_step_threshold 0.00002
            max_frequency 900000000
            clock_servo pi
            sanity_freq_limit 200000000
            ntpshm_segment 0
            #
            # Transport options
            #
            transportSpecific 0x0
            ptp_dst_mac 01:1B:19:00:00:00
            p2p_dst_mac 01:80:C2:00:00:0E
            udp_ttl 1
            udp6_scope 0x0E
            uds_address /var/run/ptp4l
            #
            # Default interface options
            #
            clock_type OC
            network_transport L2
            delay_mechanism E2E
            time_stamping hardware
            tsproc_mode filter
            delay_filter moving_median
            delay_filter_length 10
            egressLatency 0
            ingressLatency 0
            boundary_clock_jbod 0
            #
            # Clock description
            #
            productDescription ;;
            revisionData ;;
            manufacturerIdentity 00:00:00
            userDescription ;
            timeSource 0xA0
      recommend:
        - profile: ordinary-clock
          priority: 4
          match:
            - nodeLabel: "node-role.kubernetes.io/$mcp"
    Copy to Clipboard Toggle word wrap

    Expand
    표 17.2. PTP 일반 클럭 CR 구성 옵션
    사용자 정의 리소스 필드설명

    name

    PtpConfig CR의 이름입니다.

    profile

    하나 이상의 profile 오브젝트의 배열을 지정합니다. 각 프로필은 고유하게 이름을 지정해야 합니다.

    인터페이스

    ptp4l 서비스에서 사용할 네트워크 인터페이스를 지정합니다(예: ens787f1 ).

    ptp4lOpts

    ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다. 예를 들면 -2 에서 IEEE 802.3 네트워크 전송을 선택합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf를 포함하지 않아야 합니다. 이 인터페이스에서 PTP 빠른 이벤트를 사용하려면 --summary_interval -4 를 추가합니다.

    phc2sysOpts

    phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서 phc2sys 서비스를 시작하지 않습니다. Intel Columbiaville 800 시리즈 NIC의 경우 phc2sysOpts 옵션을 -a -r -m -n 24 -N 8 -R 16 으로 설정합니다. -m 에서 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.

    ptp4lConf

    기본 /etc/ptp4l.conf 파일을 대체할 구성이 포함된 문자열을 지정합니다. 기본 구성을 사용하려면 필드를 비워 둡니다.

    tx_timestamp_timeout

    Intel Columbiaville 800 시리즈 NIC의 경우 tx_timestamp_timeout50 으로 설정합니다.

    boundary_clock_jbod

    Intel Columbiaville 800 시리즈 NIC의 경우 boundary_clock_jbod0 으로 설정합니다.

    ptpSchedulingPolicy

    ptp4lphc2sys 프로세스에 대한 스케줄링 정책입니다. 기본값은ECDHE _OTHER 입니다. FIFO 스케줄링을 지원하는 시스템에서ECDHE_ FIFO를 사용합니다.

    ptpSchedulingPriority

    ptpSchedulingPolicy 가ECDHE _FIFO로 설정된 경우 ptp4lphc2sys 프로세스의 FIFO 우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다. ptpSchedulingPriority 필드는 ptpSchedulingPolicy 가ECDHE _OTHER 로 설정된 경우 사용되지 않습니다.

    ptpClockThreshold

    선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. ptpClockThreshold 는 PTP 이벤트가 트리거되기 전에 PTP 마스터 시계가 연결이 끊긴 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭이 연결 해제되면 PTP 클럭 이벤트 상태가 Free RUN 로 변경되는 시간 값(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교하여 나노초 단위로 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나면 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

    권장

    프로필을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.

    .recommend.profile

    profile 섹션에 정의된 .recommend. profile 오브젝트 이름을 지정합니다.

    .recommend.priority

    일반 시계의 경우 .recommend.priority0 으로 설정합니다.

    .recommend.match

    nodeLabel 또는 nodeName 값을 사용하여 .recommend.match 규칙을 지정합니다.

    .recommend.match.nodeLabel

    oc get nodes --show-labels 명령을 사용하여 노드 오브젝트에서 node.Labels 필드의 키로 nodeLabel 을 설정합니다. 예: node-role.kubernetes.io/worker.

    .recommend.match.nodeName

    oc get nodes 명령을 사용하여 노드 오브젝트의 node.Name 필드 값으로 nodeName 을 설정합니다. 예를 들면 compute-1.example.com 입니다.

  2. 다음 명령을 실행하여 PtpConfig CR을 생성합니다.

    $ oc create -f ordinary-clock-ptp-config.yaml
    Copy to Clipboard Toggle word wrap

검증

  1. PtpConfig 프로필이 노드에 적용되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-ptp 네임스페이스에서 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-ptp -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
      linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
      linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
      ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com
      Copy to Clipboard Toggle word wrap

    2. 프로필이 올바른지 확인합니다. PtpConfig 프로필에 지정한 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 다음 명령을 실행합니다.

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
      I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s
      I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
      Copy to Clipboard Toggle word wrap

17.6.4. linuxptp 서비스를 경계 클럭으로 구성

PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp 서비스(ptp4l,phc2sys)를 경계 클럭으로 구성할 수 있습니다.

참고

다음 예제 PtpConfig CR을 기반으로 linuxptp 서비스를 특정 하드웨어 및 환경에 대한 경계 클럭으로 구성합니다. 이 예제 CR에서는 PTP 빠른 이벤트를 구성하지 않습니다. PTP 빠른 이벤트를 구성하려면 ptp4lOpts,ptp4lConf, ptpClockThreshold 에 적절한 값을 설정합니다. ptpClockThreshold 는 이벤트가 활성화된 경우에만 사용됩니다. 자세한 내용은 " PTP 빠른 이벤트 알림 게시자 구성"을 참조하십시오.

사전 요구 사항

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

절차

  1. 다음 PtpConfig CR을 만든 다음 YAML을 boundary-clock-ptp-config.yaml 파일에 저장합니다.

    PTP 경계 클럭 구성의 예

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: boundary-clock
      namespace: openshift-ptp
      annotations: {}
    spec:
      profile:
        - name: boundary-clock
          ptp4lOpts: "-2"
          phc2sysOpts: "-a -r -n 24"
          ptpSchedulingPolicy: SCHED_FIFO
          ptpSchedulingPriority: 10
          ptpSettings:
            logReduce: "true"
          ptp4lConf: |
            # The interface name is hardware-specific
            [$iface_slave]
            masterOnly 0
            [$iface_master_1]
            masterOnly 1
            [$iface_master_2]
            masterOnly 1
            [$iface_master_3]
            masterOnly 1
            [global]
            #
            # Default Data Set
            #
            twoStepFlag 1
            slaveOnly 0
            priority1 128
            priority2 128
            domainNumber 24
            #utc_offset 37
            clockClass 248
            clockAccuracy 0xFE
            offsetScaledLogVariance 0xFFFF
            free_running 0
            freq_est_interval 1
            dscp_event 0
            dscp_general 0
            dataset_comparison G.8275.x
            G.8275.defaultDS.localPriority 128
            #
            # Port Data Set
            #
            logAnnounceInterval -3
            logSyncInterval -4
            logMinDelayReqInterval -4
            logMinPdelayReqInterval -4
            announceReceiptTimeout 3
            syncReceiptTimeout 0
            delayAsymmetry 0
            fault_reset_interval -4
            neighborPropDelayThresh 20000000
            masterOnly 0
            G.8275.portDS.localPriority 128
            #
            # Run time options
            #
            assume_two_step 0
            logging_level 6
            path_trace_enabled 0
            follow_up_info 0
            hybrid_e2e 0
            inhibit_multicast_service 0
            net_sync_monitor 0
            tc_spanning_tree 0
            tx_timestamp_timeout 50
            unicast_listen 0
            unicast_master_table 0
            unicast_req_duration 3600
            use_syslog 1
            verbose 0
            summary_interval 0
            kernel_leap 1
            check_fup_sync 0
            clock_class_threshold 135
            #
            # Servo Options
            #
            pi_proportional_const 0.0
            pi_integral_const 0.0
            pi_proportional_scale 0.0
            pi_proportional_exponent -0.3
            pi_proportional_norm_max 0.7
            pi_integral_scale 0.0
            pi_integral_exponent 0.4
            pi_integral_norm_max 0.3
            step_threshold 2.0
            first_step_threshold 0.00002
            max_frequency 900000000
            clock_servo pi
            sanity_freq_limit 200000000
            ntpshm_segment 0
            #
            # Transport options
            #
            transportSpecific 0x0
            ptp_dst_mac 01:1B:19:00:00:00
            p2p_dst_mac 01:80:C2:00:00:0E
            udp_ttl 1
            udp6_scope 0x0E
            uds_address /var/run/ptp4l
            #
            # Default interface options
            #
            clock_type BC
            network_transport L2
            delay_mechanism E2E
            time_stamping hardware
            tsproc_mode filter
            delay_filter moving_median
            delay_filter_length 10
            egressLatency 0
            ingressLatency 0
            boundary_clock_jbod 0
            #
            # Clock description
            #
            productDescription ;;
            revisionData ;;
            manufacturerIdentity 00:00:00
            userDescription ;
            timeSource 0xA0
      recommend:
        - profile: boundary-clock
          priority: 4
          match:
            - nodeLabel: "node-role.kubernetes.io/$mcp"
    Copy to Clipboard Toggle word wrap

    Expand
    표 17.3. PTP 경계 클럭 CR 구성 옵션
    사용자 정의 리소스 필드설명

    name

    PtpConfig CR의 이름입니다.

    profile

    하나 이상의 profile 오브젝트의 배열을 지정합니다.

    name

    프로파일 오브젝트를 고유하게 식별하는 프로파일 오브젝트의 이름을 지정합니다.

    ptp4lOpts

    ptp4l 서비스에 대한 시스템 구성 옵션을 지정합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름 -i <interface> 및 서비스 구성 파일 -f /etc/ptp4l.conf를 포함하지 않아야 합니다.

    ptp4lConf

    ptp4l 을 경계 클럭으로 시작하는 데 필요한 구성을 지정합니다. 예를 들어 ens1f0 은 그랜드 마스터 클록에서 동기화되고 ens1f3은 연결된 장치를 동기화합니다.

    <interface_1>

    동기화 시계를 수신하는 인터페이스입니다.

    <interface_2>

    동기화 클럭을 전송하는 인터페이스입니다.

    tx_timestamp_timeout

    Intel Columbiaville 800 시리즈 NIC의 경우 tx_timestamp_timeout50 으로 설정합니다.

    boundary_clock_jbod

    Intel Columbiaville 800 시리즈 NIC의 경우 boundary_clock_jbod0 으로 설정되어 있는지 확인합니다. Intel Fortville X710 시리즈 NIC의 경우 boundary_clock_jbod1 로 설정되어 있는지 확인합니다.

    phc2sysOpts

    phc2sys 서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서 phc2sys 서비스를 시작하지 않습니다.

    ptpSchedulingPolicy

    ptp4l 및 phc2sys 프로세스에 대한 스케줄링 정책입니다. 기본값은ECDHE _OTHER 입니다. FIFO 스케줄링을 지원하는 시스템에서ECDHE_ FIFO를 사용합니다.

    ptpSchedulingPriority

    ptpSchedulingPolicy 가ECDHE _FIFO로 설정된 경우 ptp4lphc2sys 프로세스의 FIFO 우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다. ptpSchedulingPriority 필드는 ptpSchedulingPolicy 가ECDHE _OTHER 로 설정된 경우 사용되지 않습니다.

    ptpClockThreshold

    선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. ptpClockThreshold 는 PTP 이벤트가 트리거되기 전에 PTP 마스터 시계가 연결이 끊긴 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭이 연결 해제되면 PTP 클럭 이벤트 상태가 Free RUN 로 변경되는 시간 값(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교하여 나노초 단위로 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나면 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

    권장

    프로필을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의 recommend 오브젝트 배열을 지정합니다.

    .recommend.profile

    profile 섹션에 정의된 .recommend. profile 오브젝트 이름을 지정합니다.

    .recommend.priority

    0에서 99 사이의 정수 값으로 priority를 지정합니다. 숫자가 클수록 우선순위가 낮으므로 우선순위 99는 우선순위 10보다 낮습니다. match 필드에 정의된 규칙에 따라 여러 프로필과 노드를 일치시킬 수 있는 경우 우선 순위가 높은 프로필이 해당 노드에 적용됩니다.

    .recommend.match

    nodeLabel 또는 nodeName 값을 사용하여 .recommend.match 규칙을 지정합니다.

    .recommend.match.nodeLabel

    oc get nodes --show-labels 명령을 사용하여 노드 오브젝트에서 node.Labels 필드의 키로 nodeLabel 을 설정합니다. 예: node-role.kubernetes.io/worker.

    .recommend.match.nodeName

    oc get nodes 명령을 사용하여 노드 오브젝트의 node.Name 필드 값으로 nodeName 을 설정합니다. 예를 들면 compute-1.example.com 입니다.

  2. 다음 명령을 실행하여 CR을 생성합니다.

    $ oc create -f boundary-clock-ptp-config.yaml
    Copy to Clipboard Toggle word wrap

검증

  1. PtpConfig 프로필이 노드에 적용되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-ptp 네임스페이스에서 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-ptp -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
      linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
      linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
      ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com
      Copy to Clipboard Toggle word wrap

    2. 프로필이 올바른지 확인합니다. PtpConfig 프로필에 지정한 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 다음 명령을 실행합니다.

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
      I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
      I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
      Copy to Clipboard Toggle word wrap

17.6.5. Linuxptp 서비스를 듀얼 NIC 하드웨어의 경계 클럭으로 구성

각 NIC에 대해 PtpConfig CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp 서비스(ptp4l,phc2sys)를 듀얼 NIC 하드웨어의 경계 클록으로 구성할 수 있습니다.

듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 각 NIC에 대해 별도의 ptp4l 인스턴스를 사용하여 각 NIC를 동일한 업스트림 리더 클럭에 연결할 수 있습니다.

사전 요구 사항

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

절차

  1. 각 CR의 기반으로 linuxptp 서비스를 경계 클럭으로 구성"의 참조 CR을 사용하여 각 NIC에 대해 별도의 PtpConfig CR을 생성합니다. 예를 들면 다음과 같습니다.

    1. boundary-clock-ptp-config-nic1.yaml 을 생성하여 phc2sysOpts 값을 지정합니다.

      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        name: boundary-clock-ptp-config-nic1
        namespace: openshift-ptp
      spec:
        profile:
        - name: "profile1"
          ptp4lOpts: "-2 --summary_interval -4"
          ptp4lConf: | 
      1
      
            [ens5f1]
            masterOnly 1
            [ens5f0]
            masterOnly 0
          ...
          phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
      2
      Copy to Clipboard Toggle word wrap
      1
      ptp4l 을 경계 클럭으로 시작하는 데 필요한 인터페이스를 지정합니다. 예를 들어 ens5f0 은 모달 마스터 클럭의 동기화와 ens5f1 이 연결된 장치를 동기화합니다.
      2
      필수 phc2sysOpts 값. -m 에서 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
    2. boundary-clock-ptp-config-nic2.yaml 을 생성하여 phc2sysOpts 필드를 완전히 제거하여 두 번째 NIC의 phc2sys 서비스를 비활성화합니다.

      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        name: boundary-clock-ptp-config-nic2
        namespace: openshift-ptp
      spec:
        profile:
        - name: "profile2"
          ptp4lOpts: "-2 --summary_interval -4"
          ptp4lConf: | 
      1
      
            [ens7f1]
            masterOnly 1
            [ens7f0]
            masterOnly 0
      ...
      Copy to Clipboard Toggle word wrap
      1
      두 번째 NIC에서 ptp4l 을 경계 클럭으로 시작하는 데 필요한 인터페이스를 지정합니다.
      참고

      두 번째 NIC에서 phc2sysOpts 필드를 완전히 제거하려면 두 번째 PtpConfig CR에서 phc2sys 서비스를 비활성화해야 합니다.

  2. 다음 명령을 실행하여 듀얼 NIC PtpConfig CR을 생성합니다.

    1. 첫 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.

      $ oc create -f boundary-clock-ptp-config-nic1.yaml
      Copy to Clipboard Toggle word wrap
    2. 두 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.

      $ oc create -f boundary-clock-ptp-config-nic2.yaml
      Copy to Clipboard Toggle word wrap

검증

  • PTP Operator가 두 NIC 모두에 PtpConfig CR을 적용했는지 확인합니다. 듀얼 NIC 하드웨어가 설치된 노드에 해당하는 linuxptp 데몬의 로그를 검사합니다. 예를 들어 다음 명령을 실행합니다.

    $ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
    Copy to Clipboard Toggle word wrap

    출력 예

    ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
    ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
    phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539
    Copy to Clipboard Toggle word wrap

17.6.6. Intel Columbiaville E800 시리즈 NIC as PTP 일반 클럭 참조

다음 표에서는 Intel Columbiaville E800 시리즈 NIC를 일반 시계로 사용하기 위해 참조 PTP 구성에 대한 변경 사항을 설명합니다. 클러스터에 적용하는 PtpConfig CR(사용자 정의 리소스)을 변경합니다.

Expand
표 17.4. Intel Columbiaville NIC에 권장되는 PTP 설정
PTP 구성권장 설정

phc2sysOpts

-a -r -m -n 24 -N 8 -R 16

tx_timestamp_timeout

50

boundary_clock_jbod

0

참고

phc2sysOpts 의 경우-m 은 메시지를 stdout 에 인쇄합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.

17.6.7. PTP 하드웨어에 대한 FIFO 우선 순위 스케줄링 구성

대기 시간이 짧은 배포 구성 또는 기타 배포 구성에서 PTP 데몬 스레드는 나머지 인프라 구성 요소와 함께 제한된 CPU 풋프린트에서 실행됩니다. 기본적으로 PTP 스레드는ECDHE _OTHER 정책과 함께 실행됩니다. 로드가 많은 경우 이러한 스레드는 오류가 없는 작업에 필요한 스케줄링 대기 시간을 얻지 못할 수 있습니다.

잠재적인 스케줄링 대기 시간 오류를 완화하려면 PTP Operator linuxptp 서비스를 구성하여 스레드가ECDHE _FIFO 정책으로 실행될 수 있도록 할 수 있습니다. dotnet _FIFOPtpConfig CR에 대해 설정된 경우 PtpConfig CR의 ptpSchedulingPriority 필드에 의해 설정된 우선 순위로 ptp4lphc2sys 가 부모 컨테이너에서 실행됩니다.

참고

ptpSchedulingPolicy 설정은 선택 사항이며 대기 시간 오류가 발생하는 경우에만 필요합니다.

절차

  1. PtpConfig CR 프로필을 편집합니다.

    $ oc edit PtpConfig -n openshift-ptp
    Copy to Clipboard Toggle word wrap
  2. ptpSchedulingPolicyptpSchedulingPriority 필드를 변경합니다.

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: <ptp_config_name>
      namespace: openshift-ptp
    ...
    spec:
      profile:
      - name: "profile1"
    ...
        ptpSchedulingPolicy: SCHED_FIFO 
    1
    
        ptpSchedulingPriority: 10 
    2
    Copy to Clipboard Toggle word wrap
    1
    ptp4lphc2sys 프로세스에 대한 스케줄링 정책입니다. FIFO 스케줄링을 지원하는 시스템에서ECDHE_ FIFO를 사용합니다.
    2
    필수 항목입니다. ptp4lphc2sys 프로세스에 대한 FIFO 우선 순위를 구성하는 데 사용되는 정수 값 1-65를 설정합니다.
  3. 저장 후 종료하여 PtpConfig CR에 변경 사항을 적용합니다.

검증

  1. linuxptp-daemon Pod의 이름과 PtpConfig CR이 적용된 해당 노드를 가져옵니다.

    $ oc get pods -n openshift-ptp -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
    linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
    linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
    ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com
    Copy to Clipboard Toggle word wrap

  2. 업데이트된 chrt FIFO 우선 순위로 ptp4l 프로세스가 실행 중인지 확인합니다.

    $ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
    Copy to Clipboard Toggle word wrap

    출력 예

    I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m
    Copy to Clipboard Toggle word wrap

17.6.8. linuxptp 서비스에 대한 로그 필터링 구성

linuxptp 데몬은 디버깅 목적으로 사용할 수 있는 로그를 생성합니다. 제한된 스토리지 용량을 갖춘 telco 또는 기타 배포 구성에서 이러한 로그는 스토리지 수요에 추가할 수 있습니다.

로그 메시지를 줄이기 위해 마스터 오프셋 값을 보고하는 로그 메시지를 제외하도록 PtpConfig CR(사용자 정의 리소스)을 구성할 수 있습니다. 마스터 오프셋 로그 메시지는 현재 노드의 클럭과 마스터 클럭의 나노초 단위의 차이를 보고합니다.

사전 요구 사항

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

절차

  1. PtpConfig CR을 편집합니다.

    $ oc edit PtpConfig -n openshift-ptp
    Copy to Clipboard Toggle word wrap
  2. spec.profile 에서 ptpECDHE.logReduce 사양을 추가하고 해당 값을 true 로 설정합니다.

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: <ptp_config_name>
      namespace: openshift-ptp
    ...
    spec:
      profile:
      - name: "profile1"
    ...
        ptpSettings:
          logReduce: "true"
    Copy to Clipboard Toggle word wrap
    참고

    디버깅을 위해 마스터 오프셋 메시지를 포함하도록 이 사양을 False 로 되돌릴 수 있습니다.

  3. 저장 후 종료하여 PtpConfig CR에 변경 사항을 적용합니다.

검증

  1. linuxptp-daemon Pod의 이름과 PtpConfig CR이 적용된 해당 노드를 가져옵니다.

    $ oc get pods -n openshift-ptp -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
    linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
    linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
    ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 마스터 오프셋 메시지가 로그에서 제외되었는지 확인합니다.

    $ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset" 
    1
    Copy to Clipboard Toggle word wrap
    1
    <linux_daemon_container>는 linuxptp-daemon Pod의 이름입니다(예: linuxptp-daemon-gmv2n ).

    logReduce 사양을 구성하면 이 명령에서 linuxptp 데몬의 로그에 마스터 오프셋 의 인스턴스를 보고하지 않습니다.

17.7. 일반적인 PTP Operator 문제 해결

다음 단계를 수행하여 PTP Operator의 일반적인 문제를 해결합니다.

사전 요구 사항

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

절차

  1. 구성된 노드를 위해 Operator 및 Operand가 클러스터에 성공적으로 배포되었는지 확인합니다.

    $ oc get pods -n openshift-ptp -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
    linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
    linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
    ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com
    Copy to Clipboard Toggle word wrap

    참고

    PTP 빠른 이벤트 버스가 활성화되면 준비된 linuxptp-daemon Pod 수는 3/3가 됩니다. PTP 빠른 이벤트 버스가 활성화되지 않으면 2/2가 표시됩니다.

  2. 지원되는 하드웨어가 클러스터에 있는지 확인합니다.

    $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                  AGE
    control-plane-0.example.com           10d
    control-plane-1.example.com           10d
    compute-0.example.com                 10d
    compute-1.example.com                 10d
    compute-2.example.com                 10d
    Copy to Clipboard Toggle word wrap

  3. 노드에 사용 가능한 PTP 네트워크 인터페이스를 확인합니다.

    $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <node_name>

    쿼리할 노드를 지정합니다 (예: compute-0.example.com).

    출력 예

    apiVersion: ptp.openshift.io/v1
    kind: NodePtpDevice
    metadata:
      creationTimestamp: "2021-09-14T16:52:33Z"
      generation: 1
      name: compute-0.example.com
      namespace: openshift-ptp
      resourceVersion: "177400"
      uid: 30413db0-4d8d-46da-9bef-737bacd548fd
    spec: {}
    status:
      devices:
      - name: eno1
      - name: eno2
      - name: eno3
      - name: eno4
      - name: enp5s0f0
      - name: enp5s0f1
    Copy to Clipboard Toggle word wrap

  4. 해당 노드의 linuxptp-daemon Pod에 액세스하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.

    1. 다음 명령을 실행하여 linuxptp-daemon Pod의 이름과 문제를 해결하려는 해당 노드를 가져옵니다.

      $ oc get pods -n openshift-ptp -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
      linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
      linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
      ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com
      Copy to Clipboard Toggle word wrap

    2. 필수 linuxptp-daemon 컨테이너로의 원격 쉘:

      $ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <linux_daemon_container>
      진단할 컨테이너입니다 (예: linuxptp-daemon-lmvgn).
    3. linuxptp-daemon 컨테이너에 대한 원격 쉘 연결에서 PTP 관리 클라이언트(pmc) 툴을 사용하여 네트워크 인터페이스를 진단합니다. 다음 pmc 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다(예: ptp4l ).

      # pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
      Copy to Clipboard Toggle word wrap

      노드가 기본 클록에 성공적으로 동기화되었을 때의 출력 예

      sending: GET PORT_DATA_SET
          40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
              portIdentity            40a6b7.fffe.166ef0-1
              portState               SLAVE
              logMinDelayReqInterval  -4
              peerMeanPathDelay       0
              logAnnounceInterval     -3
              announceReceiptTimeout  3
              logSyncInterval         -4
              delayMechanism          1
              logMinPdelayReqInterval -4
              versionNumber           2
      Copy to Clipboard Toggle word wrap

17.7.1. PTP(Precision Time Protocol) Operator 데이터 수집

oc adm must-gather CLI 명령을 사용하여 PTP(Precision Time Protocol) Operator와 관련된 기능 및 오브젝트를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다.

사전 요구 사항

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

절차

  • must-gather 를 사용하여 PTP Operator 데이터를 수집하려면 PTP Operator must-gather 이미지를 지정해야 합니다.

    $ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.13
    Copy to Clipboard Toggle word wrap

17.8. PTP 하드웨어 빠른 이벤트 알림 프레임워크

vRAN(가상 RAN)과 같은 클라우드 네이티브 애플리케이션에서는 전체 네트워크의 기능에 중요한 하드웨어 타이밍 이벤트에 대한 알림에 액세스해야 합니다. PTP 클럭 동기화 오류는 대기 시간이 짧은 애플리케이션의 성능과 안정성에 부정적인 영향을 미칠 수 있습니다(예: 분산 장치(DU)에서 실행되는 vRAN 애플리케이션).

17.8.1. PTP 및 클럭 동기화 오류 이벤트 정보

PTP 동기화 손실은 RAN 네트워크에 심각한 오류입니다. 노드에서 동기화가 손실된 경우 라디오가 종료될 수 있으며 네트워크 Over the Air (OTA) 트래픽이 무선 네트워크의 다른 노드로 이동될 수 있습니다. 클러스터 노드에서 PTP 클럭 동기화 상태를 DU에서 실행 중인 vRAN 애플리케이션에 통신할 수 있도록 함으로써 이벤트 알림이 워크로드 오류와 비교하여 완화됩니다.

이벤트 알림은 동일한 DU 노드에서 실행되는 vRAN 애플리케이션에서 사용할 수 있습니다. 게시-서브스크립션 REST API는 이벤트 알림을 메시징 버스에 전달합니다. 게시-서브스크립션 메시징 또는 published-sub 메시징은 모든 구독자가 해당 항목에 게시한 메시지를 즉시 수신하는 비동기 서비스 간 통신 아키텍처입니다.

PTP Operator는 모든 PTP 가능 네트워크 인터페이스에 대한 빠른 이벤트 알림을 생성합니다. HTTP 또는 AMQP(Advanced MessageECDHE Protocol) 메시지 버스를 통해 cloud-event-proxy 사이드카 컨테이너를 사용하여 이벤트에 액세스할 수 있습니다.

참고

PTP 빠른 이벤트 알림은 PTP 일반 클럭 또는 PTP 경계 클럭을 사용하도록 구성된 네트워크 인터페이스에 사용할 수 있습니다.

참고

HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS (Extended Life cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.

17.8.2. PTP 빠른 이벤트 알림 프레임워크 정보

PTP(Precision Time Protocol) 빠른 이벤트 알림 프레임워크를 사용하여 베어 메탈 클러스터 노드가 생성하는 PTP 이벤트에 클러스터 애플리케이션을 등록합니다.

참고

빠른 이벤트 알림 프레임워크는 통신에 REST API를 사용합니다. REST API는 O-RAN ALLIANCE 사양에서 사용할 수 있는 이벤트 소비자 3.0에 대한 O-RAN O-Cloud 알림 API 사양 을 기반으로 합니다.

프레임워크는 게시자와 구독자 애플리케이션 간의 통신을 처리하는 게시자, 구독자 및 AMQ 또는 HTTP 메시징 프로토콜로 구성됩니다. 애플리케이션은 사이드카 패턴에서 cloud-event-proxy 컨테이너를 실행하여 PTP 이벤트를 구독합니다. cloud-event-proxy 사이드카 컨테이너는 기본 애플리케이션의 리소스를 사용하지 않고 대기 시간이 크게 발생하지 않고 기본 애플리케이션 컨테이너와 동일한 리소스에 액세스할 수 있습니다.

참고

HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS (Extended Life cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.

그림 17.1. PTP 빠른 이벤트 개요

20 클러스터 호스트에서 이벤트가 생성됨
PTP Operator 관리 Pod의 linuxptp-daemon 은 Kubernetes DaemonSet 으로 실행되며 다양한 linuxptp 프로세스(ptp4l,phc2sys, 선택 옵션으로 할머 마스터 클럭, ts2phc)를 관리합니다. linuxptp-daemon 은 이벤트를 UNIX 도메인 소켓에 전달합니다.
20 이벤트가 cloud-event-proxy 사이드카에 전달됩니다.
PTP 플러그인은 UNIX 도메인 소켓에서 이벤트를 읽고 PTP Operator 관리 Pod의 cloud-event-proxy 사이드카로 전달합니다. Cloud-event-proxy 는 Kubernetes 인프라에서 대기 시간이 짧은 CNF(Cloud-Native Network Functions)로 이벤트를 제공합니다.
20 이벤트가 유지됨
PTP Operator 관리 Pod의 cloud-event-proxy 사이드카는 REST API를 사용하여 이벤트를 처리하고 클라우드 네이티브 이벤트를 게시합니다.
20 메시지가 전송됨
메시지 전송기는 HTTP 또는 AMQP 1.0 QPID를 통해 애플리케이션 Pod의 cloud-event-proxy 사이드카로 이벤트를 전송합니다.
20 REST API에서 이벤트 사용 가능
애플리케이션 Pod의 cloud-event-proxy 사이드카는 이벤트를 처리하고 REST API를 사용하여 이를 사용할 수 있도록 합니다.
20 소비자 애플리케이션은 서브스크립션을 요청하고 서브스크립션 이벤트를 수신합니다.
소비자 애플리케이션은 애플리케이션 Pod의 cloud-event-proxy 사이드카로 API 요청을 보내 PTP 이벤트 서브스크립션을 생성합니다. cloud-event-proxy 사이드카는 서브스크립션에 지정된 리소스에 대한 AMQ 또는 HTTP 메시징 리스너 프로토콜을 생성합니다.

애플리케이션 Pod의 cloud-event-proxy 사이드카는 PTP Operator 관리 Pod에서 이벤트를 수신하고, 클라우드 이벤트 오브젝트를 래핑하여 데이터를 검색하고 이벤트를 소비자 애플리케이션에 게시합니다. 소비자 애플리케이션은 리소스 한정자에 지정된 주소를 수신 대기하고 PTP 이벤트를 수신하고 처리합니다.

17.8.3. PTP 빠른 이벤트 알림 게시자 구성

클러스터에서 네트워크 인터페이스에 PTP 빠른 이벤트 알림을 사용하려면 PTP Operator PtpOperatorConfig CR(사용자 정의 리소스)에서 빠른 이벤트 게시자를 활성화하고 생성한 PtpConfig CR에서 ptpClockThreshold 값을 구성해야 합니다.

사전 요구 사항

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

절차

  1. PTP 빠른 이벤트를 활성화하려면 기본 PTP Operator 구성을 수정합니다.

    1. 다음 YAML을 ptp-operatorconfig.yaml 파일에 저장합니다.

      apiVersion: ptp.openshift.io/v1
      kind: PtpOperatorConfig
      metadata:
        name: default
        namespace: openshift-ptp
      spec:
        daemonNodeSelector:
          node-role.kubernetes.io/worker: ""
        ptpEventConfig:
          enableEventPublisher: true 
      1
      Copy to Clipboard Toggle word wrap
      1
      enableEventPublishertrue로 설정하여 PTP 빠른 이벤트 알림을 활성화합니다.
    참고

    OpenShift Container Platform 4.13 이상에서는 PTP 이벤트에 HTTP 전송을 사용할 때 PtpOperatorConfig.transportHost 리소스에서 spec.ptpEventConfig.transportHost 필드를 설정할 필요가 없습니다. PTP 이벤트에 AMQP 전송을 사용하는 경우에만 transportHost 를 설정합니다.

    1. PtpOperatorConfig CR을 업데이트합니다.

      $ oc apply -f ptp-operatorconfig.yaml
      Copy to Clipboard Toggle word wrap
  2. PTP 지원 인터페이스에 대한 PtpConfig CR(사용자 정의 리소스)을 생성하고 ptpClockThresholdptp4lOpts 에 필요한 값을 설정합니다. 다음 YAML은 PtpConfig CR에 설정해야 하는 필수 값을 보여줍니다.

    spec:
      profile:
      - name: "profile1"
        interface: "enp5s0f0"
        ptp4lOpts: "-2 -s --summary_interval -4" 
    1
    
        phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
    2
    
        ptp4lConf: "" 
    3
    
        ptpClockThreshold: 
    4
    
          holdOverTimeout: 5
          maxOffsetThreshold: 100
          minOffsetThreshold: -100
    Copy to Clipboard Toggle word wrap
    1
    PTP 빠른 이벤트를 사용하려면 --summary_interval -4 를 추가합니다.
    2
    필수 phc2sysOpts 값. -m 에서 stdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
    3
    기본 /etc/ptp4l.conf 파일을 대체할 구성이 포함된 문자열을 지정합니다. 기본 구성을 사용하려면 필드를 비워 둡니다.
    4
    선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.

이전에 PTP 또는 베어 메탈 이벤트 소비자 애플리케이션을 배포한 경우 HTTP 메시지 전송을 사용하도록 애플리케이션을 업데이트해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 기본적으로 HTTP 전송을 사용하는 PTP Operator 또는 Bare Metal Event Relay를 버전 4.13 이상으로 업데이트했습니다.

절차

  1. HTTP 전송을 사용하도록 이벤트 소비자 애플리케이션을 업데이트합니다. 클라우드 이벤트 사이드카 배포에 http-event-publishers 변수를 설정합니다.

    예를 들어 PTP 이벤트가 구성된 클러스터에서 다음 YAML 스니펫은 클라우드 이벤트 사이드카 배포를 보여줍니다.

    containers:
      - name: cloud-event-sidecar
        image: cloud-event-sidecar
        args:
          - "--metrics-addr=127.0.0.1:9091"
          - "--store-path=/store"
          - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
          - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043" 
    1
    
          - "--api-port=8089"
    Copy to Clipboard Toggle word wrap
    1
    PTP Operator는 NODE_NAME 을 PTP 이벤트를 생성하는 호스트로 자동으로 확인합니다. 예: compute-1.example.com.

    베어 메탈 이벤트가 구성된 클러스터에서는 클라우드 이벤트 사이드카 배포 CR에서 http-event-publishers 필드를 hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043 으로 설정합니다.

  2. 이벤트 소비자 애플리케이션과 함께 consumer-events-subscription-service 서비스를 배포합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret
      name: consumer-events-subscription-service
      namespace: cloud-events
      labels:
        app: consumer-service
    spec:
      ports:
        - name: sub-port
          port: 9043
      selector:
        app: consumer
      clusterIP: None
      sessionAffinity: None
      type: ClusterIP
    Copy to Clipboard Toggle word wrap

17.8.5. AMQ 메시징 버스 설치

노드에서 게시자와 구독자 간에 PTP 빠른 이벤트 알림을 전달하려면 노드에서 로컬로 실행되도록 AMQ 메시징 버스를 설치하고 구성할 수 있습니다. AMQ 메시징을 사용하려면 AMQ Interconnect Operator를 설치해야 합니다.

참고

HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS (Extended Life cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.

사전 요구 사항

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

절차

검증

  1. AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.

    $ oc get pods -n amq-interconnect
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
    interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h
    Copy to Clipboard Toggle word wrap

  2. 필수 linuxptp-daemon PTP 이벤트 생산자 Pod가 openshift-ptp 네임스페이스에서 실행되고 있는지 확인합니다.

    $ oc get pods -n openshift-ptp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                     READY   STATUS    RESTARTS       AGE
    linuxptp-daemon-2t78p    3/3     Running   0              12h
    linuxptp-daemon-k8n88    3/3     Running   0              12h
    Copy to Clipboard Toggle word wrap

17.8.6. PTP 이벤트 REST API 참조에 DU 애플리케이션 구독

PTP 이벤트 알림 REST API를 사용하여 상위 노드에서 생성된 PTP 이벤트에 분산 단위(DU) 애플리케이션을 구독합니다.

리소스 주소 /cluster/node/<node_name>/ptp 를 사용하여 PTP 이벤트에 애플리케이션을 서브스크립션합니다. 여기서 < node_name >은 DU 애플리케이션을 실행하는 클러스터 노드입니다.

별도의 DU 애플리케이션 Pod에 cloud-event-consumer DU 애플리케이션 컨테이너 및 cloud-event-proxy 사이드카 컨테이너를 배포합니다. cloud-event-consumer DU 애플리케이션은 애플리케이션 Pod의 cloud-event-proxy 컨테이너를 서브스크립션합니다.

다음 API 끝점을 사용하여 DU 애플리케이션 Pod의 http://localhost:8089/api/ocloudNotifications/v1/ 에서 cloud-event- consumer DU 애플리케이션을 게시한 PTP 이벤트에 등록합니다.

  • /api/ocloudNotifications/v1/subscriptions

    • POST: 새 서브스크립션을 생성합니다.
    • GET: 서브스크립션 목록 검색합니다.
    • DELETE: 모든 서브스크립션 삭제
  • /api/ocloudNotifications/v1/subscriptions/<subscription_id>

    • GET: 지정된 서브스크립션 ID에 대한 세부 정보를 반환합니다.
    • DELETE: 지정된 서브스크립션 ID와 연결된 서브스크립션 삭제
  • /api/ocloudNotifications/v1/health

    • GET: ocloudNotifications API의 상태를 반환합니다.
  • api/ocloudNotifications/v1/publishers

    • GET: 클러스터 노드에 대한 os-clock-sync-state,ptp-clock-class-changelock-state 메시지 배열을 반환합니다.
  • /api/ocloudnotifications/v1/{resource_address}/CurrentState

    • GET: os-clock-sync-state,ptp-clock-class-change, lock-state 이벤트 등 하나의 현재 상태를 반환합니다.
참고

9089 는 애플리케이션 Pod에 배포된 cloud-event-consumer 컨테이너의 기본 포트입니다. 필요에 따라 DU 애플리케이션의 다른 포트를 구성할 수 있습니다.

17.8.6.1. api/ocloudNotifications/v1/subscriptions
HTTP 방법

GET api/ocloudNotifications/v1/subscriptions

설명

서브스크립션 목록을 반환합니다. 서브스크립션이 존재하는 경우 200 OK 상태 코드가 서브스크립션 목록과 함께 반환됩니다.

API 응답 예

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]
Copy to Clipboard Toggle word wrap

HTTP 방법

POST api/ocloudNotifications/v1/subscriptions

설명

새 서브스크립션을 생성합니다. 서브스크립션이 성공적으로 생성되었거나 이미 존재하는 경우 201 Created 상태 코드가 반환됩니다.

Expand
표 17.5. 쿼리 매개변수
매개변수유형

subscription

data

페이로드 예

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}
Copy to Clipboard Toggle word wrap

HTTP 방법

DELETE api/ocloudNotifications/v1/subscriptions

설명

모든 서브스크립션을 삭제합니다.

API 응답 예

{
"status": "deleted all subscriptions"
}
Copy to Clipboard Toggle word wrap

17.8.6.2. api/ocloudNotifications/v1/subscriptions/{subscription_id}
HTTP 방법

GET api/ocloudNotifications/v1/subscriptions/{subscription_id}

설명

ID subscription_id 가 있는 서브스크립션 세부 정보를 반환합니다.

Expand
표 17.6. 글로벌 경로 매개변수
매개변수유형

subscription_id

string

API 응답 예

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}
Copy to Clipboard Toggle word wrap

HTTP 방법

DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}

설명

ID subscription_id 가 있는 서브스크립션을 삭제합니다.

Expand
표 17.7. 글로벌 경로 매개변수
매개변수유형

subscription_id

string

API 응답 예

{
"status": "OK"
}
Copy to Clipboard Toggle word wrap

17.8.6.3. api/ocloudNotifications/v1/health
HTTP 방법

GET api/ocloudNotifications/v1/health/

설명

ocloudNotifications REST API의 상태를 반환합니다.

API 응답 예

OK
Copy to Clipboard Toggle word wrap

17.8.6.4. api/ocloudNotifications/v1/publishers
HTTP 방법

GET api/ocloudNotifications/v1/publishers

설명

os-clock-sync-state,ptp-clock-class-change, and lock-state details for the cluster node를 반환합니다. 시스템은 관련 장비 상태가 변경될 때 알림을 생성합니다.

  • OS -clock-sync-state notifications는 호스트 운영 체제 클럭 동기화 상태를 설명합니다. LOCKED 또는 Free RUN 상태에 있을 수 있습니다.
  • PTP-clock-class-change notifications는 PTP 클럭 클래스의 현재 상태를 설명합니다.
  • lock-state notifications는 PTP 장비 잠금 상태의 현재 상태를 설명합니다. LOCKED,HOLDOVER 또는 FREERUN 상태에 있을 수 있습니다.

API 응답 예

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]
Copy to Clipboard Toggle word wrap

cloud-event-proxy 컨테이너의 로그에서 os-clock-sync-state,ptp-clock-class-changelock-state 이벤트를 찾을 수 있습니다. 예를 들면 다음과 같습니다.

$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
Copy to Clipboard Toggle word wrap

os-clock-sync-state 이벤트 예

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}
Copy to Clipboard Toggle word wrap

ptp-clock-class-change 이벤트 예

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}
Copy to Clipboard Toggle word wrap

lock-state 이벤트 예

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}
Copy to Clipboard Toggle word wrap

17.8.6.5. api/ocloudNotifications/v1/{resource_address}/CurrentState
HTTP 방법

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState

설명

클러스터 노드의 os-clock-sync-state,ptp-clock-class-change, lock-state 이벤트의 현재 상태를 반환하도록 CurrentState API 엔드포인트를 구성합니다.

  • OS -clock-sync-state notifications는 호스트 운영 체제 클럭 동기화 상태를 설명합니다. LOCKED 또는 Free RUN 상태에 있을 수 있습니다.
  • PTP-clock-class-change notifications는 PTP 클럭 클래스의 현재 상태를 설명합니다.
  • lock-state notifications는 PTP 장비 잠금 상태의 현재 상태를 설명합니다. LOCKED,HOLDOVER 또는 FREERUN 상태에 있을 수 있습니다.
Expand
표 17.8. 글로벌 경로 매개변수
매개변수유형

resource_address

string

lock-state API 응답 예

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

os-clock-sync-state API 응답 예

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

ptp-clock-class-change API 응답 예

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

17.8.7. PTP 빠른 이벤트 메트릭 모니터링

linuxptp-daemon 이 실행중인 클러스터 노드에서 PTP 빠른 이벤트 메트릭을 모니터링할 수 있습니다. 사전 구성 및 자체 업데이트 Prometheus 모니터링 스택을 사용하여 OpenShift Container Platform 웹 콘솔에서 PTP 빠른 이벤트 메트릭을 모니터링할 수도 있습니다.

사전 요구 사항

  • OpenShift Container Platform CLI oc를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • PTP 가능 하드웨어를 사용하여 노드에 PTP Operator를 설치하고 구성합니다.

절차

  1. linuxptp-daemon 이 실행 중인 모든 노드에서 노출된 PTP 지표를 확인합니다. 예를 들어 다음 명령을 실행합니다.

    $ curl http://<node_name>:9091/metrics
    Copy to Clipboard Toggle word wrap

    출력 예

    # HELP openshift_ptp_clock_state 0 = FREERUN, 1 = LOCKED, 2 = HOLDOVER
    # TYPE openshift_ptp_clock_state gauge
    openshift_ptp_clock_state{iface="ens1fx",node="compute-1.example.com",process="ptp4l"} 1
    openshift_ptp_clock_state{iface="ens3fx",node="compute-1.example.com",process="ptp4l"} 1
    openshift_ptp_clock_state{iface="ens5fx",node="compute-1.example.com",process="ptp4l"} 1
    openshift_ptp_clock_state{iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 1
    # HELP openshift_ptp_delay_ns
    # TYPE openshift_ptp_delay_ns gauge
    openshift_ptp_delay_ns{from="master",iface="ens1fx",node="compute-1.example.com",process="ptp4l"} 842
    openshift_ptp_delay_ns{from="master",iface="ens3fx",node="compute-1.example.com",process="ptp4l"} 480
    openshift_ptp_delay_ns{from="master",iface="ens5fx",node="compute-1.example.com",process="ptp4l"} 584
    openshift_ptp_delay_ns{from="master",iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 482
    openshift_ptp_delay_ns{from="phc",iface="CLOCK_REALTIME",node="compute-1.example.com",process="phc2sys"} 547
    # HELP openshift_ptp_offset_ns
    # TYPE openshift_ptp_offset_ns gauge
    openshift_ptp_offset_ns{from="master",iface="ens1fx",node="compute-1.example.com",process="ptp4l"} -2
    openshift_ptp_offset_ns{from="master",iface="ens3fx",node="compute-1.example.com",process="ptp4l"} -44
    openshift_ptp_offset_ns{from="master",iface="ens5fx",node="compute-1.example.com",process="ptp4l"} -8
    openshift_ptp_offset_ns{from="master",iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 3
    openshift_ptp_offset_ns{from="phc",iface="CLOCK_REALTIME",node="compute-1.example.com",process="phc2sys"} 12
    Copy to Clipboard Toggle word wrap

  2. OpenShift Container Platform 웹 콘솔에서 PTP 이벤트를 보려면 쿼리할 PTP 메트릭의 이름을 복사합니다(예: openshift_ptp_offset_ns ).
  3. OpenShift Container Platform 웹 콘솔에서 모니터링메트릭을 클릭합니다.
  4. PTP 메트릭 이름을 표현식 필드에 붙여넣고 쿼리 실행을 클릭합니다.

18장. PTP 이벤트 소비자 애플리케이션 개발

베어 메탈 클러스터 노드에서 PTP(Precision Time Protocol) 이벤트를 사용하는 소비자 애플리케이션을 개발할 때 소비자 애플리케이션 및 클라우드 이벤트 프록시 컨테이너를 별도의 애플리케이션 Pod에 배포해야 합니다. cloud-event-proxy 컨테이너는 PTP Operator Pod에서 이벤트를 수신하여 소비자 애플리케이션으로 전달합니다. 소비자 애플리케이션은 REST API를 사용하여 cloud-event-proxy 컨테이너에 게시된 이벤트를 구독합니다.

PTP 이벤트 애플리케이션 배포에 대한 자세한 내용은 PTP 빠른 이벤트 알림 프레임워크 정보를 참조하십시오.

참고

다음 정보는 PTP 이벤트를 사용하는 소비자 애플리케이션을 개발하기 위한 일반적인 지침을 제공합니다. 전체 이벤트 소비자 애플리케이션 예는 이 정보의 범위를 벗어납니다.

18.1. PTP 이벤트 소비자 애플리케이션 참조

PTP 이벤트 소비자 애플리케이션에는 다음 기능이 필요합니다.

  1. 클라우드 기본 PTP 이벤트 JSON 페이로드를 수신하기 위해 POST 처리기로 실행되는 웹 서비스
  2. PTP 이벤트 프로듀서에 가입하는 createSubscription 함수
  3. PTP 이벤트 프로듀서의 현재 상태를 폴링하는 getCurrentState 함수

다음 예제 Go 스니펫에서는 이러한 요구 사항을 보여줍니다.

Go의 PTP 이벤트 소비자 서버 함수의 예

func server() {
  http.HandleFunc("/event", getEvent)
  http.ListenAndServe("localhost:8989", nil)
}

func getEvent(w http.ResponseWriter, req *http.Request) {
  defer req.Body.Close()
  bodyBytes, err := io.ReadAll(req.Body)
  if err != nil {
    log.Errorf("error reading event %v", err)
  }
  e := string(bodyBytes)
  if e != "" {
    processEvent(bodyBytes)
    log.Infof("received event %s", string(bodyBytes))
  } else {
    w.WriteHeader(http.StatusNoContent)
  }
}
Copy to Clipboard Toggle word wrap

Go에서 PTP 이벤트 createSubscription 함수의 예

import (
"github.com/redhat-cne/sdk-go/pkg/pubsub"
"github.com/redhat-cne/sdk-go/pkg/types"
v1pubsub "github.com/redhat-cne/sdk-go/v1/pubsub"
)

// Subscribe to PTP events using REST API
s1,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state") 
1

s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change")
s3,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/lock-state")

// Create PTP event subscriptions POST
func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) {
  var status int
      apiPath:= "/api/ocloudNotifications/v1/"
      localAPIAddr:=localhost:8989 // vDU service API address
      apiAddr:= "localhost:8089" // event framework API address

  subURL := &types.URI{URL: url.URL{Scheme: "http",
    Host: apiAddr
    Path: fmt.Sprintf("%s%s", apiPath, "subscriptions")}}
  endpointURL := &types.URI{URL: url.URL{Scheme: "http",
    Host: localAPIAddr,
    Path: "event"}}

  sub = v1pubsub.NewPubSub(endpointURL, resourceAddress)
  var subB []byte

  if subB, err = json.Marshal(&sub); err == nil {
    rc := restclient.New()
    if status, subB = rc.PostWithReturn(subURL, subB); status != http.StatusCreated {
      err = fmt.Errorf("error in subscription creation api at %s, returned status %d", subURL, status)
    } else {
      err = json.Unmarshal(subB, &sub)
    }
  } else {
    err = fmt.Errorf("failed to marshal subscription for %s", resourceAddress)
  }
  return
}
Copy to Clipboard Toggle word wrap

1
& lt;node_name >을 PTP 이벤트를 생성하는 노드의 FQDN으로 바꿉니다. 예: compute-1.example.com.

Go의 PTP 이벤트 소비자 getCurrentState 함수의 예

//Get PTP event state for the resource
func getCurrentState(resource string) {
  //Create publisher
  url := &types.URI{URL: url.URL{Scheme: "http",
    Host: localhost:8989,
    Path: fmt.SPrintf("/api/ocloudNotifications/v1/%s/CurrentState",resource}}
  rc := restclient.New()
  status, event := rc.Get(url)
  if status != http.StatusOK {
    log.Errorf("CurrentState:error %d from url %s, %s", status, url.String(), event)
  } else {
    log.Debugf("Got CurrentState: %s ", event)
  }
}
Copy to Clipboard Toggle word wrap

18.2. 참조 cloud-event-proxy 배포 및 서비스 CR

PTP 이벤트 소비자 애플리케이션을 배포할 때 다음 예제 cloud-event-proxy 배포 및 구독자 서비스 CR을 참조로 사용합니다.

참고

HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS (Extended Life cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.

HTTP 전송을 사용하는 cloud-event-proxy 배포 참조

apiVersion: apps/v1
kind: Deployment
metadata:
  name: event-consumer-deployment
  namespace: <namespace>
  labels:
    app: consumer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: consumer
  template:
    metadata:
      labels:
        app: consumer
    spec:
      serviceAccountName: sidecar-consumer-sa
      containers:
        - name: event-subscriber
          image: event-subscriber-app
        - name: cloud-event-proxy-as-sidecar
          image: openshift4/ose-cloud-event-proxy
          args:
            - "--metrics-addr=127.0.0.1:9091"
            - "--store-path=/store"
            - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
            - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
            - "--api-port=8089"
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: NODE_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
              volumeMounts:
                - name: pubsubstore
                  mountPath: /store
          ports:
            - name: metrics-port
              containerPort: 9091
            - name: sub-port
              containerPort: 9043
          volumes:
            - name: pubsubstore
              emptyDir: {}
Copy to Clipboard Toggle word wrap

AMQ 전송을 사용한 cloud-event-proxy 배포 참조

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-event-proxy-sidecar
  namespace: cloud-events
  labels:
    app: cloud-event-proxy
spec:
  selector:
    matchLabels:
      app: cloud-event-proxy
  template:
    metadata:
      labels:
        app: cloud-event-proxy
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      containers:
        - name: cloud-event-sidecar
          image: openshift4/ose-cloud-event-proxy
          args:
            - "--metrics-addr=127.0.0.1:9091"
            - "--store-path=/store"
            - "--transport-host=amqp://router.router.svc.cluster.local"
            - "--api-port=8089"
          env:
            - name: <node_name>
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: <node_ip>
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
          volumeMounts:
            - name: pubsubstore
              mountPath: /store
          ports:
            - name: metrics-port
              containerPort: 9091
            - name: sub-port
              containerPort: 9043
          volumes:
            - name: pubsubstore
              emptyDir: {}
Copy to Clipboard Toggle word wrap

참조 cloud-event-proxy 구독자 서비스

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: "true"
    service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret
  name: consumer-events-subscription-service
  namespace: cloud-events
  labels:
    app: consumer-service
spec:
  ports:
    - name: sub-port
      port: 9043
  selector:
    app: consumer
  clusterIP: None
  sessionAffinity: None
  type: ClusterIP
Copy to Clipboard Toggle word wrap

18.3. cloud-event-proxy 사이드카 REST API에서 PTP 이벤트 사용

PTP 이벤트 소비자 애플리케이션은 다음 PTP 타이밍 이벤트에 대해 PTP 이벤트 생산자를 폴링할 수 있습니다.

Expand
표 18.1. cloud-event-proxy 사이드카에서 사용 가능한 PTP 이벤트
리소스 URI설명

/cluster/node/<node_name>/sync/ptp-status/lock-state

PTP 장치 잠금 상태의 현재 상태를 설명합니다. LOCKED, HECDHEOVER 또는 FREERUN 상태에 있을 수 있습니다.

/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state

호스트 운영 체제 클럭 동기화 상태를 설명합니다. LOCKED 또는 free RUN 상태에 있을 수 있습니다.

/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change

PTP 클럭 클래스의 현재 상태를 설명합니다.

18.4. PTP 이벤트에 소비자 애플리케이션 구독

PTP 이벤트 소비자 애플리케이션에서 이벤트를 폴링하려면 먼저 애플리케이션을 이벤트 프로듀서에 가입해야 합니다.

18.4.1. PTP 잠금 이벤트 구독

PTP 잠금 상태 이벤트에 대한 서브스크립션을 생성하려면 다음 페이로드를 사용하여 http://localhost:8081/api/ocloudNotifications/v1/subscriptions 의 클라우드 이벤트 API에 POST 작업을 보냅니다.

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/<node_name>/sync/ptp-status/lock-state",
}
Copy to Clipboard Toggle word wrap

응답 예

{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/ptp-status/lock-state",
}
Copy to Clipboard Toggle word wrap

18.4.2. PTP os-clock-sync-state 이벤트 구독

PTP os-clock-sync-state 이벤트에 대한 서브스크립션을 생성하려면 다음 페이로드가 있는 http://localhost:8081/api/ocloudNotifications/v1/subscriptions 에서 클라우드 이벤트 API에 POST 작업을 보냅니다.

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state",
}
Copy to Clipboard Toggle word wrap

응답 예

{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state",
}
Copy to Clipboard Toggle word wrap

18.4.3. PTP ptp-clock-class-change 이벤트 구독

PTP ptp-clock-class-change 이벤트에 대한 서브스크립션을 생성하려면 다음 페이로드를 사용하여 http://localhost:8081/api/ocloudNotifications/v1/subscriptions 에서 클라우드 이벤트 API에 POST 작업을 보냅니다.

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change",
}
Copy to Clipboard Toggle word wrap

응답 예

{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change",
}
Copy to Clipboard Toggle word wrap

18.5. 현재 PTP 클럭 상태 가져오기

노드의 현재 PTP 상태를 가져오려면 다음 이벤트 REST API 중 하나에 GET 작업을 보냅니다.

  • http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<NODE_NAME>/sync/ptp-status/lock-state/CurrentState
  • http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<NODE_NAME>/sync/sync-status/os-clock-sync-state/CurrentState
  • http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<NODE_NAME>/sync/ptp-status/ptp-clock-class-change/CurrentState

응답은 클라우드 네이티브 이벤트 JSON 오브젝트입니다. 예를 들면 다음과 같습니다.

lock-state API 응답 예

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

18.6. PTP 이벤트 소비자 애플리케이션이 이벤트를 수신하는지 확인

애플리케이션 Pod의 cloud-event-proxy 컨테이너에서 PTP 이벤트를 수신하고 있는지 확인합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • PTP Operator를 설치하고 구성했습니다.

프로세스

  1. 활성 linuxptp-daemon Pod 목록을 가져옵니다. 다음 명령을 실행합니다.

    $ oc get pods -n openshift-ptp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    READY   STATUS    RESTARTS   AGE
    linuxptp-daemon-2t78p   3/3     Running   0          8h
    linuxptp-daemon-k8n88   3/3     Running   0          8h
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 필수 소비자 측 cloud-event-proxy 컨테이너의 메트릭에 액세스합니다.

    $ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <linuxptp-daemon>

    쿼리할 Pod를 지정합니다(예: linuxptp-daemon-2t78p ).

    출력 예

    # HELP cne_transport_connections_resets Metric to get number of connection resets
    # TYPE cne_transport_connections_resets gauge
    cne_transport_connection_reset 1
    # HELP cne_transport_receiver Metric to get number of receiver created
    # TYPE cne_transport_receiver gauge
    cne_transport_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 2
    cne_transport_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"} 2
    # HELP cne_transport_sender Metric to get number of sender created
    # TYPE cne_transport_sender gauge
    cne_transport_sender{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
    cne_transport_sender{address="/cluster/node/compute-1.example.com/redfish/event",status="active"} 1
    # HELP cne_events_ack Metric to get number of events produced
    # TYPE cne_events_ack gauge
    cne_events_ack{status="success",type="/cluster/node/compute-1.example.com/ptp"} 18
    cne_events_ack{status="success",type="/cluster/node/compute-1.example.com/redfish/event"} 18
    # HELP cne_events_transport_published Metric to get number of events published by the transport
    # TYPE cne_events_transport_published gauge
    cne_events_transport_published{address="/cluster/node/compute-1.example.com/ptp",status="failed"} 1
    cne_events_transport_published{address="/cluster/node/compute-1.example.com/ptp",status="success"} 18
    cne_events_transport_published{address="/cluster/node/compute-1.example.com/redfish/event",status="failed"} 1
    cne_events_transport_published{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 18
    # HELP cne_events_transport_received Metric to get number of events received  by the transport
    # TYPE cne_events_transport_received gauge
    cne_events_transport_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 18
    cne_events_transport_received{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 18
    # HELP cne_events_api_published Metric to get number of events published by the rest api
    # TYPE cne_events_api_published gauge
    cne_events_api_published{address="/cluster/node/compute-1.example.com/ptp",status="success"} 19
    cne_events_api_published{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 19
    # HELP cne_events_received Metric to get number of events received
    # TYPE cne_events_received gauge
    cne_events_received{status="success",type="/cluster/node/compute-1.example.com/ptp"} 18
    cne_events_received{status="success",type="/cluster/node/compute-1.example.com/redfish/event"} 18
    # HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served.
    # TYPE promhttp_metric_handler_requests_in_flight gauge
    promhttp_metric_handler_requests_in_flight 1
    # HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.
    # TYPE promhttp_metric_handler_requests_total counter
    promhttp_metric_handler_requests_total{code="200"} 4
    promhttp_metric_handler_requests_total{code="500"} 0
    promhttp_metric_handler_requests_total{code="503"} 0
    Copy to Clipboard Toggle word wrap

19장. 외부 DNS Operator

19.1. OpenShift Container Platform의 외부 DNS Operator

외부 DNS Operator는 ExternalDNS 를 배포 및 관리하여 외부 DNS 공급자에서 OpenShift Container Platform으로 서비스 및 경로에 대한 이름 확인을 제공합니다.

19.1.1. 외부 DNS Operator

외부 DNS Operator는 olm.openshift.io API 그룹에서 외부 DNS API를 구현합니다. 외부 DNS Operator는 서비스, 경로 및 외부 DNS 공급자를 업데이트합니다.

사전 요구 사항

  • yq CLI 툴을 설치했습니다.

프로세스

OperatorHub에서 필요에 따라 외부 DNS Operator를 배포할 수 있습니다. 외부 DNS Operator를 배포하면 Subscription 개체가 생성됩니다.

  1. 다음 명령을 실행하여 설치 계획의 이름을 확인합니다.

    $ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
    Copy to Clipboard Toggle word wrap

    출력 예

    install-zcvlr
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 설치 계획의 상태가 Complete 인지 확인합니다.

    $ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
    Copy to Clipboard Toggle word wrap

    출력 예

    Complete
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 external-dns-operator 배포의 상태를 확인합니다.

    $ oc get -n external-dns-operator deployment/external-dns-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
    external-dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

19.1.2. 외부 DNS Operator 로그

oc logs 명령을 사용하여 외부 DNS Operator 로그를 볼 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 외부 DNS Operator의 로그를 확인합니다.

    $ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
    Copy to Clipboard Toggle word wrap
19.1.2.1. 외부 DNS Operator 도메인 이름 제한

외부 DNS Operator는 TXT 레코드에 대한 접두사를 추가하는 TXT 레지스트리를 사용합니다. 이렇게 하면 TXT 레코드의 도메인 이름의 최대 길이가 줄어듭니다. 해당 TXT 레코드 없이는 DNS 레코드를 존재할 수 없으므로 DNS 레코드의 도메인 이름은 TXT 레코드와 동일한 제한을 따라야 합니다. 예를 들어 < domain_name_from_source >의 DNS 레코드는 external-dns-<record_type>-<domain_name_from_source >의 TXT 레코드를 생성합니다.

외부 DNS Operator에서 생성한 DNS 레코드의 도메인 이름에는 다음과 같은 제한 사항이 있습니다.

Expand
레코드 유형문자 수

CNAME

44

AzureDNS의 와일드카드 CNAME 레코드

42

A

48

AzureDNS의 와일드카드 A 레코드

46

생성된 도메인 이름이 도메인 이름 제한 사항을 초과하는 경우 외부 DNS Operator 로그에 다음 오류가 표시됩니다.

time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"
Copy to Clipboard Toggle word wrap

19.2. 클라우드 공급자에 외부 DNS Operator 설치

AWS, Azure 및 GCP와 같은 클라우드 공급자에 외부 DNS Operator를 설치할 수 있습니다.

19.2.1. OperatorHub를 사용하여 외부 DNS Operator 설치

OpenShift Container Platform OperatorHub를 사용하여 외부 DNS Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorsOperatorHub 를 클릭합니다.
  2. External DNS Operator 를 클릭합니다. 키워드로 필터링 텍스트 상자 또는 필터 목록을 사용하여 Operator 목록에서 외부 DNS Operator를 검색할 수 있습니다.
  3. external-dns-operator 네임스페이스를 선택합니다.
  4. 외부 DNS Operator 페이지에서 설치를 클릭합니다.
  5. Operator 설치 페이지에서 다음 옵션을 선택했는지 확인합니다.

    1. 채널을 stable-v1 로 업데이트합니다.
    2. 설치 모드를 클러스터의 특정 이름으로 설정합니다.
    3. 네임스페이스를 external-dns-operator 로 설치했습니다. external-dns-operator 네임스페이스가 없으면 Operator 설치 중에 생성됩니다.
    4. 자동 또는 수동으로 승인 전략을 선택합니다. 승인 전략은 기본적으로 자동으로 설정됩니다.
    5. 설치를 클릭합니다.

자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)에서 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.

수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

검증

External DNS Operator에 설치된 Operator 대시보드에서 상태가 성공으로 표시되는지 확인합니다.

19.2.2. CLI를 사용하여 외부 DNS Operator 설치

CLI를 사용하여 외부 DNS Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 로그인되어 있습니다.
  • OpenShift CLI(oc)에 로그인되어 있습니다.

프로세스

  1. Namespace 오브젝트를 생성합니다.

    1. Namespace 오브젝트를 정의하는 YAML 파일을 생성합니다.

      namespace.yaml 파일 예

      apiVersion: v1
      kind: Namespace
      metadata:
        name: external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 Namespace 오브젝트를 생성합니다.

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. OperatorGroup 오브젝트를 생성합니다.

    1. OperatorGroup 오브젝트를 정의하는 YAML 파일을 생성합니다.

      operatorgroup.yaml 파일 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        upgradeStrategy: Default
        targetNamespaces:
        - external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 OperatorGroup 오브젝트를 생성합니다.

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. Subscription 오브젝트를 생성합니다.

    1. Subscription 오브젝트를 정의하는 YAML 파일을 생성합니다.

      subscription.yaml 파일의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: external-dns-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 Subscription 오브젝트를 생성합니다.

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 서브스크립션에서 설치 계획의 이름을 가져옵니다.

    $ oc -n external-dns-operator \
        get subscription external-dns-operator \
        --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 설치 계획의 상태가 Complete 인지 확인합니다.

    $ oc -n external-dns-operator \
        get ip <install_plan_name> \
        --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 external-dns-operator Pod의 상태가 Running 인지 확인합니다.

    $ oc -n external-dns-operator get pod
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS   AGE
    external-dns-operator-5584585fd7-5lwqm   2/2     Running   0          11m
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 서브스크립션의 카탈로그 소스가 redhat-operators 인지 확인합니다.

    $ oc -n external-dns-operator get subscription
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    PACKAGE                 SOURCE             CHANNEL
    external-dns-operator   external-dns-operator   redhat-operators   stable-v1
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 external-dns-operator 버전을 확인합니다.

    $ oc -n external-dns-operator get csv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                           DISPLAY                VERSION   REPLACES   PHASE
    external-dns-operator.v<1.y.z>   ExternalDNS Operator   <1.y.z>                Succeeded
    Copy to Clipboard Toggle word wrap

19.3. 외부 DNS Operator 구성 매개변수

외부 DNS Operator에는 다음 구성 매개변수가 포함되어 있습니다.

19.3.1. 외부 DNS Operator 구성 매개변수

외부 DNS Operator에는 다음 구성 매개변수가 포함되어 있습니다.

Expand
매개변수설명

spec

클라우드 공급자의 유형을 활성화합니다.

spec:
  provider:
    type: AWS 
1

    aws:
      credentials:
        name: aws-access-key 
2
Copy to Clipboard Toggle word wrap
1
AWS, GCP, Azure 및 Infoblox와 같은 사용 가능한 옵션을 정의합니다.
2
클라우드 공급자의 시크릿 이름을 정의합니다.

영역

도메인을 통해 DNS 영역을 지정할 수 있습니다. 영역을 지정하지 않으면 ExternalDNS 리소스가 클라우드 공급자 계정에 있는 모든 영역을 검색합니다.

zones:
- "myzoneid" 
1
Copy to Clipboard Toggle word wrap
1
DNS 영역의 이름을 지정합니다.

도메인

도메인을 통해 AWS 영역을 지정할 수 있습니다. 도메인을 지정하지 않으면 ExternalDNS 리소스는 클라우드 공급자 계정에 있는 모든 영역을 검색합니다.

domains:
- filterType: Include 
1

  matchType: Exact 
2

  name: "myzonedomain1.com" 
3

- filterType: Include
  matchType: Pattern 
4

  pattern: ".*\\.otherzonedomain\\.com" 
5
Copy to Clipboard Toggle word wrap
1
ExternalDNS 리소스에 도메인 이름이 포함되어 있는지 확인합니다.
2
ExtrnalDNS 에 정규 표현식 일치와 달리 도메인 일치가 정확해야 함을 지시합니다.
3
도메인의 이름을 정의합니다.
4
ExternalDNS 리소스에 regex-domain-filter 플래그를 설정합니다. Regex 필터를 사용하여 가능한 도메인을 제한할 수 있습니다.
5
ExternalDNS 리소스에서 대상 영역의 도메인을 필터링하는 데 사용할 regex 패턴을 정의합니다.

소스

DNS 레코드, 서비스 또는 경로의 소스를 지정할 수 있습니다.

source: 
1

  type: Service 
2

  service:
    serviceType:
3

      - LoadBalancer
      - ClusterIP
  labelFilter: 
4

    matchLabels:
      external-dns.mydomain.org/publish: "yes"
  hostnameAnnotation: "Allow" 
5

  fqdnTemplate:
  - "{{.Name}}.myzonedomain.com" 
6
Copy to Clipboard Toggle word wrap
1
DNS 레코드의 소스에 대한 설정을 정의합니다.
2
ExternalDNS 리소스는 서비스 유형을 DNS 레코드를 생성하기 위한 소스로 사용합니다.
3
ExternalDNS 리소스에서 service-type-filter 플래그를 설정합니다. serviceType 에는 다음 필드가 포함됩니다.
  • 기본값:LoadBalancer
  • 예상 됨:ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName
4
컨트롤러에서 라벨 필터와 일치하는 리소스만 고려합니다.
5
hostnameAnnotation 의 기본값은 fqdnTemplates 필드에 지정된 템플릿을 사용하여 ExternalDNS 에 DNS 레코드를 생성하도록 지시하는 Ignore 입니다. 값이 Allow the DNS records get generated based on the value specified in the external-dns.alpha.kubernetes.io/hostname 주석입니다.
6
외부 DNS Operator는 문자열을 사용하여 호스트 이름을 정의하지 않는 소스에서 DNS 이름을 생성하거나 페이크 소스와 페어링할 때 호스트 이름 접미사를 추가합니다.
source:
  type: OpenShiftRoute 
1

  openshiftRouteOptions:
    routerName: default 
2

    labelFilter:
      matchLabels:
        external-dns.mydomain.org/publish: "yes"
Copy to Clipboard Toggle word wrap
1
DNS 레코드를 만듭니다.
2
소스 유형이 OpenShiftRoute 이면 Ingress 컨트롤러 이름을 전달할 수 있습니다. ExternalDNS 리소스는 Ingress 컨트롤러의 정식 이름을 CNAME 레코드의 대상으로 사용합니다.

19.4. AWS에서 DNS 레코드 생성

외부 DNS Operator를 사용하여 AWS 및 AWS GovCloud에서 DNS 레코드를 생성할 수 있습니다.

Red Hat External DNS Operator를 사용하여 AWS의 퍼블릭 호스팅 영역에서 DNS 레코드를 생성할 수 있습니다. 동일한 지침을 사용하여 AWS GovCloud의 호스팅 영역에서 DNS 레코드를 만들 수 있습니다.

프로세스

  1. 사용자를 확인합니다. 사용자가 kube-system 네임스페이스에 액세스할 수 있어야 합니다. 인증 정보가 없는 경우 kube-system 네임스페이스에서 인증 정보를 가져와서 클라우드 공급자 클라이언트를 사용할 수 있습니다.

    $ oc whoami
    Copy to Clipboard Toggle word wrap

    출력 예

    system:admin
    Copy to Clipboard Toggle word wrap

  2. kube-system 네임스페이스에 있는 aws-creds 시크릿에서 값을 가져옵니다.

    $ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
    $ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  3. 도메인을 확인할 경로를 가져옵니다.

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    출력 예

    openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. dns 영역 목록을 가져와서 이전에 발견된 경로의 도메인에 해당하는 항목을 찾습니다.

    $ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
    Copy to Clipboard Toggle word wrap

    출력 예

    HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5
    Copy to Clipboard Toggle word wrap

  5. 경로 소스에 대한 ExternalDNS 리소스 생성:

    $ cat <<EOF | oc create -f -
    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-aws 
    1
    
    spec:
      domains:
      - filterType: Include   
    2
    
        matchType: Exact   
    3
    
        name: testextdnsoperator.apacshift.support 
    4
    
      provider:
        type: AWS 
    5
    
      source:  
    6
    
        type: OpenShiftRoute 
    7
    
        openshiftRouteOptions:
          routerName: default 
    8
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    외부 DNS 리소스의 이름을 정의합니다.
    2
    기본적으로 모든 호스팅 영역은 잠재적인 대상으로 선택됩니다. 필요한 호스팅 영역을 포함할 수 있습니다.
    3
    대상 영역 도메인의 일치는 정확해야 합니다(정규 표현식 일치와 대조).
    4
    업데이트할 영역의 정확한 도메인을 지정합니다. 경로의 호스트 이름은 지정된 도메인의 하위 도메인이어야 합니다.
    5
    AWS Route53 DNS 공급자를 정의합니다.
    6
    DNS 레코드 소스에 대한 옵션을 정의합니다.
    7
    이전에 지정된 DNS 공급자에서 생성된 DNS 레코드의 소스로 OpenShift 경로 리소스를 정의합니다.
    8
    소스가 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS Operator는 CNAME 레코드를 생성하는 동안 해당 라우터의 표준 호스트 이름을 대상으로 선택합니다.
  6. 다음 명령을 사용하여 OCP 경로에 대해 생성된 레코드를 확인합니다.

    $ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
    Copy to Clipboard Toggle word wrap

19.5. Azure에서 DNS 레코드 생성

외부 DNS Operator를 사용하여 Azure에 DNS 레코드를 생성할 수 있습니다.

중요

{entra-first}-enabled cluster 또는 Microsoft Azure Government (MAG) 리전에서 실행되는 클러스터에서 외부 DNS Operator를 사용하는 것은 지원되지 않습니다.

19.5.1. Azure 퍼블릭 DNS 영역에 DNS 레코드 생성

외부 DNS Operator를 사용하여 Azure의 퍼블릭 DNS 영역에 DNS 레코드를 생성할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야합니다.
  • admin 사용자는 kube-system 네임스페이스에 액세스할 수 있어야 합니다.

절차

  1. 다음 명령을 실행하여 클라우드 공급자 클라이언트를 사용하도록 kube-system 네임스페이스에서 인증 정보를 가져옵니다.

    $ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
    $ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
    $ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
    $ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
    $ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 Azure에 로그인합니다.

    $ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 경로 목록을 가져옵니다.

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    출력 예

    openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 DNS 영역 목록을 가져옵니다.

    $ az network dns zone list --resource-group "${RESOURCE_GROUP}"
    Copy to Clipboard Toggle word wrap
  5. ExternalDNS 오브젝트를 정의하는 YAML 파일(예: external-dns-sample-azure.yaml )을 생성합니다.

    external-dns-sample-azure.yaml 파일의 예

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-azure 
    1
    
    spec:
      zones:
      - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" 
    2
    
      provider:
        type: Azure 
    3
    
      source:
        openshiftRouteOptions: 
    4
    
          routerName: default 
    5
    
        type: OpenShiftRoute 
    6
    Copy to Clipboard Toggle word wrap

    1
    외부 DNS 이름을 지정합니다.
    2
    영역 ID를 정의합니다.
    3
    공급자 유형을 정의합니다.
    4
    DNS 레코드 소스에 대한 옵션을 정의할 수 있습니다.
    5
    소스 유형이 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.
    6
    경로 리소스를 Azure DNS 레코드의 소스로 정의합니다.
  6. 다음 명령을 실행하여 OpenShift Container Platform 경로에 대해 생성된 DNS 레코드를 확인합니다.

    $ az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
    Copy to Clipboard Toggle word wrap
    참고

    프라이빗 Azure DNS의 프라이빗 호스팅 영역에 레코드를 만들려면 ExternalDNS 컨테이너 인수에서 공급자 유형을 azure-private-dns 로 채우는 zones 필드 아래에 프라이빗 영역을 지정해야 합니다.

19.6. GCP에서 DNS 레코드 생성

외부 DNS Operator를 사용하여 GCP(Google Cloud Platform)에 DNS 레코드를 생성할 수 있습니다.

중요

GCP 워크로드 ID가 활성화된 클러스터에서 외부 DNS Operator 사용은 지원되지 않습니다. GCP 워크로드 ID에 대한 자세한 내용은 GCP Workload Identity에서 수동 모드 사용을 참조하십시오.

19.6.1. GCP의 퍼블릭 관리 영역에 DNS 레코드 생성

외부 DNS Operator를 사용하여 GCP의 퍼블릭 관리 영역에 DNS 레코드를 생성할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 명령을 실행하여 encoded-gcloud.json 파일에 gcp-credentials 시크릿을 복사합니다.

    $ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 Google 인증 정보를 내보냅니다.

    $ export GOOGLE_CREDENTIALS=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 계정을 활성화합니다.

    $ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 프로젝트를 설정합니다.

    $ gcloud config set project <project_id as per decoded-gcloud.json>
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 경로 목록을 가져옵니다.

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    출력 예

    openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 관리 영역 목록을 가져옵니다.

    $ gcloud dns managed-zones list | grep test.gcp.example.com
    Copy to Clipboard Toggle word wrap

    출력 예

    qe-cvs4g-private-zone test.gcp.example.com
    Copy to Clipboard Toggle word wrap

  7. ExternalDNS 오브젝트를 정의하는 YAML 파일(예: external-dns-sample-gcp.yaml )을 생성합니다.

    external-dns-sample-gcp.yaml 파일 예

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-gcp 
    1
    
    spec:
      domains:
        - filterType: Include 
    2
    
          matchType: Exact 
    3
    
          name: test.gcp.example.com 
    4
    
      provider:
        type: GCP 
    5
    
      source:
        openshiftRouteOptions: 
    6
    
          routerName: default 
    7
    
        type: OpenShiftRoute 
    8
    Copy to Clipboard Toggle word wrap

    1
    외부 DNS 이름을 지정합니다.
    2
    기본적으로 모든 호스팅 영역은 잠재적 대상으로 선택됩니다. 호스팅 영역을 포함할 수 있습니다.
    3
    대상의 도메인은 name 키로 정의된 문자열과 일치해야 합니다.
    4
    업데이트할 영역의 정확한 도메인을 지정합니다. 경로의 호스트 이름은 지정된 도메인의 하위 도메인이어야 합니다.
    5
    공급자 유형을 정의합니다.
    6
    DNS 레코드 소스에 대한 옵션을 정의할 수 있습니다.
    7
    소스 유형이 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.
    8
    경로 리소스를 GCP DNS 레코드의 소스로 정의합니다.
  8. 다음 명령을 실행하여 OpenShift Container Platform 경로에 대해 생성된 DNS 레코드를 확인합니다.

    $ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
    Copy to Clipboard Toggle word wrap

19.7. Infoblox에서 DNS 레코드 생성

외부 DNS Operator를 사용하여 Infoblox에서 DNS 레코드를 생성할 수 있습니다.

19.7.1. Infoblox의 퍼블릭 DNS 영역에 DNS 레코드 생성

외부 DNS Operator를 사용하여 Infoblox의 퍼블릭 DNS 영역에 DNS 레코드를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스할 수 있습니다.
  • Infoblox UI에 액세스할 수 있습니다.

절차

  1. 다음 명령을 실행하여 Infoblox 자격 증명을 사용하여 보안 오브젝트를 생성합니다.

    $ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 경로 목록을 가져옵니다.

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    출력 예

    openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  3. ExternalDNS 오브젝트를 정의하는 YAML 파일(예: external-dns-sample-infoblox.yaml )을 생성합니다.

    external-dns-sample-infoblox.yaml 파일의 예

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-infoblox 
    1
    
    spec:
      provider:
        type: Infoblox 
    2
    
        infoblox:
          credentials:
            name: infoblox-credentials
          gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
          wapiPort: 443
          wapiVersion: "2.3.1"
      domains:
      - filterType: Include
        matchType: Exact
        name: test.example.com
      source:
        type: OpenShiftRoute 
    3
    
        openshiftRouteOptions:
          routerName: default 
    4
    Copy to Clipboard Toggle word wrap

    1
    외부 DNS 이름을 지정합니다.
    2
    공급자 유형을 정의합니다.
    3
    DNS 레코드 소스에 대한 옵션을 정의할 수 있습니다.
    4
    소스 유형이 OpenShiftRoute 인 경우 OpenShift Ingress 컨트롤러 이름을 전달할 수 있습니다. 외부 DNS는 CNAME 레코드를 생성하는 동안 해당 라우터의 정식 호스트 이름을 대상으로 선택합니다.
  4. 다음 명령을 실행하여 Infoblox에서 ExternalDNS 리소스를 만듭니다.

    $ oc create -f external-dns-sample-infoblox.yaml
    Copy to Clipboard Toggle word wrap
  5. Infoblox UI에서 콘솔 경로에 대해 생성된 DNS 레코드를 확인합니다.

    1. 데이터 관리DNS영역을 클릭합니다.
    2. 영역 이름을 선택합니다.

19.8. 외부 DNS Operator에서 클러스터 전체 프록시 구성

클러스터 전체 프록시를 구성한 후 OLM(Operator Lifecycle Manager)은 HTTP_PROXY,HTTPS_PROXYNO_PROXY 환경 변수의 새 콘텐츠를 사용하여 배포된 모든 Operator에 대한 자동 업데이트를 트리거합니다.

19.8.1. 클러스터 전체 프록시의 인증 기관 신뢰

클러스터 전체 프록시의 인증 기관을 신뢰하도록 외부 DNS Operator를 구성할 수 있습니다.

절차

  1. 다음 명령을 실행하여 외부-dns-operator 네임스페이스에 CA 번들을 포함하도록 구성 맵을 생성합니다.

    $ oc -n external-dns-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 신뢰할 수 있는 CA 번들을 구성 맵에 삽입하려면 다음 명령을 실행하여 config.openshift.io/inject-trusted-cabundle=true 라벨을 구성 맵에 추가합니다.

    $ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 외부 DNS Operator의 서브스크립션을 업데이트합니다.

    $ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'
    Copy to Clipboard Toggle word wrap

검증

  • 외부 DNS Operator 배포가 완료되면 다음 명령을 실행하여 신뢰할 수 있는 CA 환경 변수가 external-dns-operator 배포에 추가되었는지 확인합니다.

    $ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
    Copy to Clipboard Toggle word wrap

    출력 예

    trusted-ca
    Copy to Clipboard Toggle word wrap

20장. 네트워크 정책

20.1. 네트워크 정책 정의

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

20.1.1. 네트워크 정책 정의

Kubernetes 네트워크 정책을 지원하는 네트워크 플러그인을 사용하는 클러스터에서 네트워크 격리는 NetworkPolicy 개체에 의해 전적으로 제어됩니다. OpenShift Container Platform 4.13에서 OpenShift SDN은 기본 네트워크 격리 모드에서 네트워크 정책의 사용을 지원합니다.

주의

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

네트워크 정책은 localhost 또는 상주 노드의 트래픽을 차단할 수 없습니다.

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

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

네트워크 정책은 TCP, UDP, ICMP 및 SCTP 프로토콜에만 적용됩니다. 다른 프로토콜은 영향을 받지 않습니다.

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

  • 모든 트래픽 거부:

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector: {}
      ingress: []
    Copy to Clipboard Toggle word wrap
  • 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
    Copy to Clipboard Toggle word wrap
  • 프로젝트 내 Pod 연결만 허용:

    중요

    동일한 네임스페이스에 있는 hostNetwork Pod의 수신 연결을 허용하려면 allow-from-hostnetwork 정책을 allow-same-namespace 정책과 함께 적용해야 합니다.

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector: {}
      ingress:
      - from:
        - podSelector: {}
    Copy to Clipboard Toggle word wrap
  • 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
    Copy to Clipboard Toggle word wrap
  • 네임스페이스와 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
    Copy to Clipboard Toggle word wrap

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

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

20.1.1.1. allow-from-router 네트워크 정책 사용

다음 NetworkPolicy 를 사용하여 라우터 구성에 관계없이 외부 트래픽을 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
1

  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap
1
policy-group.network.openshift.io/ingress:" 레이블은 OpenShift-SDN 및 OVN-Kubernetes를 모두 지원합니다.
20.1.1.2. allow-from-hostnetwork 네트워크 정책 사용

다음 allow-from-hostnetwork NetworkPolicy 오브젝트를 추가하여 호스트 네트워크 Pod에서 트래픽을 전달합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap

20.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 흐름 규칙만 생성합니다.

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

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

  • 동일한 spec.podSelector 사양이 있는 네트워크 정책의 경우 수신 또는 송신 규칙의 서브 세트가 있는 여러 네트워크 정책보다 여러 수신 또는 송신 규칙이 있는 하나의 네트워크 정책을 사용하는 것이 더 효율적입니다.
  • podSelector 또는 namespaceSelector 사양을 기반으로 하는 모든 수신 또는 송신 규칙은 수신 또는 송신 규칙에서 선택한 네트워크 정책 + Pod 수에 비례하여 OVS 흐름 수를 생성합니다. 따라서 모든 Pod에 대해 개별 규칙을 생성하는 대신 하나의 규칙에서 필요한 만큼의 Pod를 선택할 수 있는 podSelector 또는 namespaceSelector 사양을 사용하는 것이 좋습니다.

    예를 들어 다음 정책에는 두 개의 규칙이 있습니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: test-network-policy
    spec:
      podSelector: {}
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
      - from:
        - podSelector:
            matchLabels:
              role: backend
    Copy to Clipboard Toggle word wrap

    다음 정책은 다음과 같은 두 가지 규칙을 나타냅니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: test-network-policy
    spec:
      podSelector: {}
      ingress:
      - from:
        - podSelector:
            matchExpressions:
            - {key: role, operator: In, values: [frontend, backend]}
    Copy to Clipboard Toggle word wrap

    spec.podSelector 사양에 동일한 지침이 적용됩니다. 다른 네트워크 정책에 대해 동일한 수신 또는 송신 규칙이 있는 경우 공통 spec.podSelector 사양을 사용하여 하나의 네트워크 정책을 생성하는 것이 더 효과적일 수 있습니다. 예를 들어 다음 두 정책에는 다른 규칙이 있습니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy1
    spec:
      podSelector:
        matchLabels:
          role: db
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    ---
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy2
    spec:
      podSelector:
        matchLabels:
          role: client
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    Copy to Clipboard Toggle word wrap

    다음 네트워크 정책은 다음과 같은 두 가지 규칙을 나타냅니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy3
    spec:
      podSelector:
        matchExpressions:
        - {key: role, operator: In, values: [db, client]}
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    Copy to Clipboard Toggle word wrap

    이 최적화는 여러 개의 선택기만 하나의 선택기로 표시되는 경우에만 적용할 수 있습니다. 선택기가 다른 레이블을 기반으로 하는 경우 이 최적화를 적용하지 못할 수 있습니다. 이러한 경우 네트워크 정책 최적화에 새로운 레이블을 적용하는 것이 좋습니다.

20.1.4. 다음 단계

20.2. 네트워크 정책 생성

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

20.2.1. 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
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트에서 인그레스 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 수락할 하나 이상의 대상 포트 목록입니다.

20.2.2. CLI를 사용하여 네트워크 정책 생성

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

참고

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

사전 요구 사항

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

절차

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

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

      $ touch <policy_name>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

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

      이는 다른 네트워크 정책 구성에서 허용하는 교차 포드 트래픽 이외의 모든 포드 간 네트워킹을 차단하는 기본 정책입니다.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []
      Copy to Clipboard Toggle word wrap

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

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      Copy to Clipboard Toggle word wrap

      특정 네임스페이스에서 하나의 Pod로 들어오는 트래픽 허용

      이 정책을 사용하면 namespace-y 에서 실행되는 Pod의 pod-a 레이블이 지정된 Pod로의 트래픽을 수행할 수 있습니다.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-traffic-pod
      spec:
        podSelector:
         matchLabels:
            pod: pod-a
        policyTypes:
        - Ingress
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                 kubernetes.io/metadata.name: namespace-y
      Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 네트워크 정책 오브젝트를 생성합니다.

    $ oc apply -f <policy_name>.yaml -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

    출력 예

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

참고

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

20.2.3. 기본 거부 모든 네트워크 정책 생성

이는 배포된 다른 네트워크 정책에서 허용하는 네트워크 트래픽 이외의 모든 교차 포드 네트워킹을 차단하는 기본 정책입니다. 이 절차에서는 기본 거부 정책을 적용합니다.

참고

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

사전 요구 사항

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

절차

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
      namespace: default 
    1
    
    spec:
      podSelector: {} 
    2
    
      ingress: [] 
    3
    Copy to Clipboard Toggle word wrap
    1
    namespace: default 는 이 정책을 default 네임스페이스에 배포합니다.
    2
    podSelector: 비어 있습니다. 즉, 모든 Pod와 일치합니다. 따라서 이 정책은 default 네임스페이스의 모든 Pod에 적용됩니다.
    3
    Ingress 규칙이 지정되지 않았습니다. 이로 인해 들어오는 트래픽이 모든 Pod로 삭제됩니다.
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

20.2.4. 외부 클라이언트의 트래픽을 허용하는 네트워크 정책 생성

deny-by-default 정책을 사용하여 외부 클라이언트에서 라벨이 app=web 인 Pod로의 트래픽을 허용하는 정책을 구성할 수 있습니다.

참고

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

다음 절차에 따라 공용 인터넷에서 직접 또는 Load Balancer를 사용하여 포드에 액세스할 수 있는 정책을 구성합니다. 트래픽은 app=web 레이블이 있는 Pod에만 허용됩니다.

사전 요구 사항

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

절차

  1. 공용 인터넷에서 직접 또는 로드 밸런서를 사용하여 포드에 액세스하는 방식으로 트래픽을 허용하는 정책을 생성합니다. web-allow-external.yaml 파일에 YAML을 저장합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-external
      namespace: default
    spec:
      policyTypes:
      - Ingress
      podSelector:
        matchLabels:
          app: web
      ingress:
        - {}
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-external.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/web-allow-external created
    Copy to Clipboard Toggle word wrap

이 정책은 다음 다이어그램에 설명된 대로 외부 트래픽을 포함하여 모든 리소스의 트래픽을 허용합니다.

참고

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

다음 절차에 따라 모든 네임스페이스의 모든 Pod에서 특정 애플리케이션으로의 트래픽을 허용하는 정책을 구성합니다.

사전 요구 사항

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

절차

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-all-namespaces
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector: {} 
    2
    Copy to Clipboard Toggle word wrap
    1
    정책을 기본 네임스페이스의 app:web Pod에만 적용합니다.
    2
    모든 네임스페이스에서 모든 Pod를 선택합니다.
    참고

    기본적으로 namespaceSelector 를 지정하지 않으면 정책이 네트워크 정책이 배포된 네임스페이스에서만 트래픽을 허용하는 네임스페이스를 선택하지 않습니다.

  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-all-namespaces.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/web-allow-all-namespaces created
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 보조 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  3. 쉘에서 다음 명령을 실행하고 요청이 허용되는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

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

참고

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

다음 절차에 따라 특정 네임스페이스에서 app=web 레이블이 있는 Pod로의 트래픽을 허용하는 정책을 구성합니다. 다음을 수행할 수 있습니다.

  • 프로덕션 워크로드가 배포된 네임스페이스로만 트래픽을 제한합니다.
  • 특정 네임스페이스에 배포된 모니터링 툴을 활성화하여 현재 네임스페이스에서 지표를 스크랩할 수 있습니다.

사전 요구 사항

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

절차

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-prod
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production 
    2
    Copy to Clipboard Toggle word wrap
    1
    정책을 default 네임스페이스의 app:web Pod에만 적용합니다.
    2
    purpose=production 레이블이 있는 네임스페이스의 Pod로만 트래픽을 제한합니다.
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/web-allow-prod created
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 prod 네임스페이스를 생성합니다.

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 dev 네임스페이스를 생성합니다.

    $ oc create namespace dev
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 dev 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/dev purpose=testing
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 dev 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  7. 쉘에서 다음 명령을 실행하고 요청이 차단되었는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

    wget: download timed out
    Copy to Clipboard Toggle word wrap

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

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  9. 쉘에서 다음 명령을 실행하고 요청이 허용되는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

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

20.3. 네트워크 정책 보기

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

20.3.1. 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
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트에서 인그레스 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 수락할 하나 이상의 대상 포트 목록입니다.

20.3.2. CLI를 사용하여 네트워크 정책 보기

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

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네트워크 정책을 볼 수 있습니다.

사전 요구 사항

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

절차

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

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

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

      $ oc describe networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

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

      $ oc describe networkpolicy allow-same-namespace
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한으로 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 YAML에서 직접 또는 웹 콘솔의 양식에서 볼 수 있습니다.

20.4. 네트워크 정책 편집

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

20.4.1. 네트워크 정책 편집

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

참고

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

사전 요구 사항

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

절차

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

    $ oc get networkpolicy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

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

      $ oc apply -n <namespace> -f <policy_file>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

      $ oc edit networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

    $ oc describe networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

cluster-admin 권한으로 웹 콘솔에 로그인하면 YAML의 모든 네임스페이스에서 또는 Actions 메뉴를 통해 웹 콘솔의 정책에서 직접 네트워크 정책을 편집할 수 있습니다.

20.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
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트에서 인그레스 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 수락할 하나 이상의 대상 포트 목록입니다.

20.5. 네트워크 정책 삭제

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

20.5.1. CLI를 사용하여 네트워크 정책 삭제

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

참고

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

사전 요구 사항

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

절차

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

    $ oc delete networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

    출력 예

    networkpolicy.networking.k8s.io/default-deny deleted
    Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한으로 웹 콘솔에 로그인하는 경우 YAML의 모든 네임스페이스에서 또는 Actions 메뉴를 통해 웹 콘솔의 정책에서 직접 네트워크 정책을 삭제할 수 있습니다.

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

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

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

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

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

절차

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

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

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

    • 웹 콘솔에 액세스:

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

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

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

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

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
    # ...
    spec:
      projectRequestTemplate:
        name: <template_name>
    # ...
    Copy to Clipboard Toggle word wrap

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

20.6.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
    Copy to Clipboard Toggle word wrap

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

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

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

    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
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
    ...
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 다음 명령을 실행하여 새 프로젝트를 생성하고 네트워크 정책 오브젝트가 생성되었는지 확인합니다.

    1. 새 프로젝트를 생성합니다.

      $ oc new-project <project> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <project> 를 생성중인 프로젝트의 이름으로 변경합니다.
    2. 새 프로젝트 템플릿의 네트워크 정책 오브젝트가 새 프로젝트에 있는지 확인합니다.

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s
      Copy to Clipboard Toggle word wrap

20.7. 네트워크 정책으로 다중 테넌트 격리 구성

클러스터 관리자는 다중 테넌트 네트워크 격리를 제공하도록 네트워크 정책을 구성할 수 있습니다.

참고

OpenShift SDN 네트워크 플러그인을 사용하는 경우 이 섹션에서 설명하는 네트워크 정책을 구성하면 다중 테넌트 모드와 유사하지만 네트워크 정책 모드가 설정됩니다.

20.7.1. 네트워크 정책을 사용하여 다중 테넌트 격리 구성

다른 프로젝트 네임스페이스의 Pod 및 서비스에서 격리하도록 프로젝트를 구성할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-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:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
      Copy to Clipboard Toggle word wrap
      참고

      policy-group.network.openshift.io/ingress: "" 는 OpenShift SDN의 기본 네임스페이스 선택기 레이블입니다. network.openshift.io/policy-group: ingress 네임스페이스 선택기 레이블을 사용할 수 있지만 이는 레거시 레이블입니다.

    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
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap
    4. 이름이 allow-from-kube-apiserver-operator 인 정책:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
      EOF
      Copy to Clipboard Toggle word wrap

      자세한 내용은 웹 후크 의 상태를 검증하는 새로운 kube-apiserver-operator 웹 후크 컨트롤러 를 참조하십시오.

  2. 선택 사항: 현재 프로젝트에 네트워크 정책이 있는지 확인하려면 다음 명령을 입력합니다.

    $ oc describe networkpolicy
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

20.7.2. 다음 단계

21장. CIDR 범위 정의

다음 CIDR 범위에 대해 겹치지 않는 범위를 지정해야 합니다.

참고

클러스터를 생성한 후에는 시스템 CIDR 범위를 변경할 수 없습니다.

중요

OpenShift Container Platform 4.11에서 4.13의 기본 네트워크 공급자인 OVN-Kubernetes는 내부적으로 100.64.0.0/16,169.254.169.0/29,fd98::/64fd69::/125. 클러스터에서 OVN-Kubernetes를 사용하는 경우 클러스터의 다른 CIDR 정의에 IP 주소 범위를 포함하지 마십시오.

21.1. 머신 CIDR

CIDR(Machine classless inter-domain routing) 필드에서 시스템 또는 클러스터 노드의 IP 주소 범위를 지정해야 합니다.

기본값은 10.0.0.0/16 입니다. 이 범위는 연결된 네트워크와 충돌해서는 안 됩니다.

21.2. 서비스 CIDR

Service CIDR 필드에서 서비스의 IP 주소 범위를 지정해야 합니다. 범위는 워크로드를 수용할 수 있을 만큼 커야 합니다. 주소 블록은 클러스터 내에서 액세스한 외부 서비스와 겹치지 않아야 합니다. 기본값은 172.30.0.0/16입니다.

21.3. Pod CIDR

Pod CIDR 필드에서 Pod의 IP 주소 범위를 지정해야 합니다.

Pod CIDR은 clusterNetwork CIDR 및 클러스터 CIDR과 동일합니다. 범위는 워크로드를 수용할 수 있을 만큼 커야 합니다. 주소 블록은 클러스터 내에서 액세스한 외부 서비스와 겹치지 않아야 합니다. 기본값은 10.128.0.0/14 입니다. 클러스터 설치 후 범위를 확장할 수 있습니다.

21.4. 호스트 접두사

Host Prefix 필드에서 개별 머신에 예약된 Pod에 할당된 서브넷 접두사 길이를 지정해야 합니다. 호스트 접두사는 각 시스템의 Pod IP 주소 풀을 결정합니다.

예를 들어 호스트 접두사가 /23 으로 설정된 경우 각 시스템에는 Pod CIDR 주소 범위의 /23 서브넷이 할당됩니다. 기본값은 /23 으로, 노드당 510 클러스터 노드 및 510 Pod IP 주소를 허용합니다.

22장. AWS Load Balancer Operator

22.1. AWS Load Balancer Operator 릴리스 정보

AWS Load Balancer(ALB) Operator는 AWSLoadBalancerController 리소스의 인스턴스를 배포하고 관리합니다.

중요

AWS Load Balancer(ALB) Operator는 x86_64 아키텍처에서만 지원됩니다.

이 릴리스 노트는 OpenShift Container Platform에서 AWS Load Balancer Operator의 개발을 추적합니다.

AWS Load Balancer Operator에 대한 개요는 OpenShift Container Platform의 AWS Load Balancer Operator 를 참조하십시오.

참고

AWS Load Balancer Operator는 현재 AWS GovCloud를 지원하지 않습니다.

22.1.1. AWS Load Balancer Operator 1.0.0

이제 이 릴리스에서 AWS Load Balancer Operator를 일반적으로 사용할 수 있습니다. AWS Load Balancer Operator 버전 1.0.0은 AWS Load Balancer 컨트롤러 버전 2.4.4를 지원합니다.

AWS Load Balancer Operator 버전 1.0.0에는 다음 권고를 사용할 수 있습니다.

22.1.1.1. 주요 변경 사항
  • 이 릴리스에서는 새로운 v1 API 버전을 사용합니다.
22.1.1.2. 버그 수정
  • 이전에는 AWS Load Balancer Operator에서 프로비저닝한 컨트롤러가 클러스터 전체 프록시에 구성을 제대로 사용하지 않았습니다. 이제 이러한 설정이 컨트롤러에 적절하게 적용됩니다. (OCPBUGS-4052, OCPBUGS-5295)

22.1.2. 이전 버전

AWS Load Balancer Operator의 첫 번째 두 버전은 기술 프리뷰로 사용할 수 있습니다. 이러한 버전은 프로덕션 클러스터에서 사용해서는 안 됩니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

AWS Load Balancer Operator 버전 0.2.0에는 다음 권고를 사용할 수 있습니다.

AWS Load Balancer Operator 버전 0.0.1에서 다음 권고를 사용할 수 있습니다.

22.2. OpenShift Container Platform의 AWS Load Balancer Operator

AWS Load Balancer Operator는 AWS Load Balancer 컨트롤러를 배포하고 관리합니다. OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 AWS Load Balancer Operator를 설치할 수 있습니다.

22.2.1. AWS Load Balancer Operator 고려 사항

AWS Load Balancer Operator를 설치하고 사용하기 전에 다음 제한 사항을 검토하십시오.

  • IP 트래픽 모드는 AWS Elastic Kubernetes Service(EKS)에서만 작동합니다. AWS Load Balancer Operator는 AWS Load Balancer Controller의 IP 트래픽 모드를 비활성화합니다. IP 트래픽 모드를 비활성화하면 AWS Load Balancer 컨트롤러에서 Pod 준비 게이트를 사용할 수 없습니다.
  • AWS Load Balancer Operator는 --disable-ingress- class-annotation 및 --disable-ingress -group-name-annotation 과 같은 명령줄 플래그를 AWS Load Balancer 컨트롤러에 추가합니다. 따라서 AWS Load Balancer Operator는 Ingress 리소스의 kubernetes.io/ingress.classalb.ingress.kubernetes.io/group.name 주석을 사용할 수 없습니다.
  • SVC 유형이 NodePort ( LoadBalancer 또는 ClusterIP아님)가 되도록 AWS Load Balancer Operator를 구성했습니다.

22.2.2. AWS Load Balancer Operator

kubernetes.io/role/elb 태그가 누락된 경우 AWS Load Balancer Operator는 퍼블릭 서브넷에 태그를 지정할 수 있습니다. 또한 AWS Load Balancer Operator는 기본 AWS 클라우드에서 다음 정보를 감지합니다.

  • Operator를 호스팅하는 클러스터가 배포되는 VPC(가상 프라이빗 클라우드)의 ID입니다.
  • 검색된 VPC의 퍼블릭 및 프라이빗 서브넷.

AWS Load Balancer Operator는 인스턴스 대상 유형에서만 NLB(Network Load Balancer)를 사용하여 LoadBalancer 유형의 Kubernetes 서비스 리소스를 지원합니다.

사전 요구 사항

  • AWS 인증 정보 시크릿이 있어야 합니다. 인증 정보는 서브넷 태그 및 VPC 검색을 제공하는 데 사용됩니다.

절차

  1. 다음 명령을 실행하여 Subscription 오브젝트를 생성하여 OperatorHub의 필요에 따라 AWS Load Balancer Operator를 배포할 수 있습니다.

    $ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    install-zlfbt
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 설치 계획의 상태가 Complete 인지 확인합니다.

    $ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    Complete
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 aws-load-balancer-operator-controller-manager 배포의 상태를 확인합니다.

    $ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
    aws-load-balancer-operator-controller-manager  1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

22.2.3. AWS Load Balancer Operator 로그

oc logs 명령을 사용하여 AWS Load Balancer Operator 로그를 볼 수 있습니다.

절차

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

    $ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
    Copy to Clipboard Toggle word wrap

22.3. AWS Load Balancer Operator 설치

AWS Load Balancer Operator는 AWS Load Balancer 컨트롤러를 배포하고 관리합니다. OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 AWS Load Balancer Operator를 설치할 수 있습니다.

22.3.1. 웹 콘솔을 사용하여 AWS Load Balancer Operator 설치

웹 콘솔을 사용하여 AWS Load Balancer Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • 클러스터는 플랫폼 유형 및 클라우드 공급자로 AWS로 구성되어 있습니다.
  • STS(보안 토큰 서비스) 또는 사용자 프로비저닝 인프라를 사용하는 경우 관련 준비 단계를 따르십시오. 예를 들어 AWS Security Token Service를 사용하는 경우 "AWS Security Token Service (STS)를 사용하여 클러스터에서 AWS Load Balancer Operator 준비"를 참조하십시오.

절차

  1. OpenShift Container Platform 웹 콘솔에서 OperatorsOperatorHub 로 이동합니다.
  2. AWS Load Balancer Operator 를 선택합니다. 키워드로 필터링 텍스트 상자를 사용하거나 필터 목록을 사용하여 Operator 목록에서 AWS Load Balancer Operator를 검색할 수 있습니다.
  3. aws-load-balancer-operator 네임스페이스를 선택합니다.
  4. Operator 설치 페이지에서 다음 옵션을 선택합니다.

    1. 채널을 stable-v1 로 업데이트합니다.
    2. 클러스터의 모든 네임스페이스(기본값)설치 모드입니다.
    3. 네임스페이스aws-load-balancer-operator 로 설치했습니다. aws-load-balancer-operator 네임스페이스가 없으면 Operator 설치 중에 생성됩니다.
    4. 자동 또는 수동으로 업데이트 승인을 선택합니다. 기본적으로 업데이트 승인자동 로 설정됩니다. 자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)에서 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다. 수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 해당 업데이트 요청을 수동으로 승인해야 합니다.
  5. 설치를 클릭합니다.

검증

  • AWS Load Balancer Operator가 설치된 Operator 대시보드에 Succeeded 로 표시되는지 확인합니다.

22.3.2. CLI를 사용하여 AWS Load Balancer Operator 설치

CLI를 사용하여 AWS Load Balancer Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 로그인되어 있습니다.
  • 클러스터는 플랫폼 유형 및 클라우드 공급자로 AWS로 구성되어 있습니다.
  • OpenShift CLI(oc)에 로그인되어 있습니다.

절차

  1. Namespace 오브젝트를 생성합니다.

    1. Namespace 오브젝트를 정의하는 YAML 파일을 생성합니다.

      namespace.yaml 파일 예

      apiVersion: v1
      kind: Namespace
      metadata:
        name: aws-load-balancer-operator
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 Namespace 오브젝트를 생성합니다.

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. CredentialsRequest 오브젝트를 생성합니다.

    1. CredentialsRequest 오브젝트를 정의하는 YAML 파일을 생성합니다.

      credentialsrequest.yaml 파일 예

      apiVersion: cloudcredential.openshift.io/v1
      kind: CredentialsRequest
      metadata:
        name: aws-load-balancer-operator
        namespace: openshift-cloud-credential-operator
      spec:
        providerSpec:
          apiVersion: cloudcredential.openshift.io/v1
          kind: AWSProviderSpec
          statementEntries:
            - action:
                - ec2:DescribeSubnets
              effect: Allow
              resource: "*"
            - action:
                - ec2:CreateTags
                - ec2:DeleteTags
              effect: Allow
              resource: arn:aws:ec2:*:*:subnet/*
            - action:
                - ec2:DescribeVpcs
              effect: Allow
              resource: "*"
        secretRef:
          name: aws-load-balancer-operator
          namespace: aws-load-balancer-operator
        serviceAccountNames:
          - aws-load-balancer-operator-controller-manager
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 CredentialsRequest 오브젝트를 생성합니다.

      $ oc apply -f credentialsrequest.yaml
      Copy to Clipboard Toggle word wrap
  3. OperatorGroup 오브젝트를 생성합니다.

    1. OperatorGroup 오브젝트를 정의하는 YAML 파일을 생성합니다.

      operatorgroup.yaml 파일 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: aws-lb-operatorgroup
        namespace: aws-load-balancer-operator
      spec:
        upgradeStrategy: Default
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 OperatorGroup 오브젝트를 생성합니다.

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  4. Subscription 오브젝트를 생성합니다.

    1. Subscription 오브젝트를 정의하는 YAML 파일을 생성합니다.

      subscription.yaml 파일의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: aws-load-balancer-operator
        namespace: aws-load-balancer-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: aws-load-balancer-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 Subscription 오브젝트를 생성합니다.

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

검증

  1. 서브스크립션에서 설치 계획의 이름을 가져옵니다.

    $ oc -n aws-load-balancer-operator \
        get subscription aws-load-balancer-operator \
        --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 설치 계획의 상태를 확인합니다.

    $ oc -n aws-load-balancer-operator \
        get ip <install_plan_name> \
        --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

    출력은 Complete 여야 합니다.

STS를 사용하는 클러스터에 AWS Load Balancer Operator를 설치할 수 있습니다. 다음 단계에 따라 Operator를 설치하기 전에 클러스터를 준비합니다.

AWS Load Balancer Operator는 CredentialsRequest 오브젝트를 사용하여 Operator 및 AWS Load Balancer 컨트롤러를 부트스트랩합니다. AWS Load Balancer Operator는 필요한 시크릿이 생성되고 사용 가능할 때까지 기다립니다. Cloud Credential Operator는 STS 클러스터에서 자동으로 시크릿을 프로비저닝하지 않습니다. ccoctl 바이너리를 사용하여 인증 정보 보안을 수동으로 설정해야 합니다.

Cloud Credential Operator를 사용하여 인증 정보 시크릿을 프로비저닝하지 않으려면 AWS load Balancer Controller CR(사용자 정의 리소스)에 인증 정보 시크릿을 지정하여 STS 클러스터에서 AWSLoadBalancerController 인스턴스를 구성할 수 있습니다.

사전 요구 사항

  • ccoctl 바이너리를 추출하고 준비해야 합니다.

절차

  1. 다음 명령을 실행하여 aws-load-balancer-operator 네임스페이스를 생성합니다.

    $ oc create namespace aws-load-balancer-operator
    Copy to Clipboard Toggle word wrap
  2. AWS Load Balancer Operator의 CredentialsRequest CR(사용자 정의 리소스)을 다운로드하고 다음 명령을 실행하여 저장할 디렉터리를 생성합니다.

    $ curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  3. ccoctl 툴을 사용하여 다음 명령을 실행하여 AWS Load Balancer Operator의 CredentialsRequest 오브젝트를 처리합니다.

    $ ccoctl aws create-iam-roles \
        --name <name> --region=<aws_region> \
        --credentials-requests-dir=<path-to-credrequests-dir> \
        --identity-provider-arn <oidc-arn>
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 클러스터의 매니페스트 디렉터리에 생성된 보안을 적용합니다.

    $ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 AWS Load Balancer Operator의 인증 정보 시크릿이 생성되었는지 확인합니다.

    $ oc -n aws-load-balancer-operator get secret aws-load-balancer-operator --template='{{index .data "credentials"}}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    [default]
    sts_regional_endpoints = regional
    role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-operator
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
    Copy to Clipboard Toggle word wrap

사전 요구 사항

  • ccoctl 바이너리를 추출하고 준비해야 합니다.

절차

  1. AWS Load Balancer Operator는 각 AWSLoadBalancerController 사용자 정의 리소스(CR)의 openshift-cloud-credential-operator 네임스페이스에 CredentialsRequest 오브젝트를 생성합니다. 다음 명령을 실행하여 생성된 CredentialsRequest 오브젝트를 디렉터리에 추출 및 저장할 수 있습니다.

    $ oc get credentialsrequest -n openshift-cloud-credential-operator  \
        aws-load-balancer-controller-<cr-name> -o yaml > <path-to-credrequests-dir>/cr.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    aws-load-balancer-controller-<cr-name > 매개변수는 AWS Load Balancer Operator가 생성한 인증 정보 요청 이름을 지정합니다. cr-name 은 AWS Load Balancer Controller 인스턴스의 이름을 지정합니다.
  2. ccoctl 도구를 사용하여 다음 명령을 실행하여 credrequests 디렉터리의 모든 CredentialsRequest 오브젝트를 처리합니다.

    $ ccoctl aws create-iam-roles \
        --name <name> --region=<aws_region> \
        --credentials-requests-dir=<path-to-credrequests-dir> \
        --identity-provider-arn <oidc-arn>
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 매니페스트 디렉터리에 생성된 보안을 클러스터에 적용합니다.

    $ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
    Copy to Clipboard Toggle word wrap
  4. aws-load-balancer-controller Pod가 생성되었는지 확인합니다.

    $ oc -n aws-load-balancer-operator get pods
    NAME                                                            READY   STATUS    RESTARTS   AGE
    aws-load-balancer-controller-cluster-9b766d6-gg82c              1/1     Running   0          137m
    aws-load-balancer-operator-controller-manager-b55ff68cc-85jzg   2/2     Running   0          3h26m
    Copy to Clipboard Toggle word wrap

AWS Load Balancer Controller CR(사용자 정의 리소스)에서 spec.credentials 필드를 사용하여 인증 정보 시크릿을 지정할 수 있습니다. 컨트롤러의 사전 정의된 CredentialsRequest 오브젝트를 사용하여 필요한 역할을 확인할 수 있습니다.

사전 요구 사항

  • ccoctl 바이너리를 추출하고 준비해야 합니다.

절차

  1. AWS Load Balancer 컨트롤러의 CredentialsRequest CR(사용자 정의 리소스)을 다운로드하고 다음 명령을 실행하여 저장할 디렉터리를 생성합니다.

    $ curl --create-dirs -o <path-to-credrequests-dir>/cr.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  2. ccoctl 도구를 사용하여 컨트롤러의 CredentialsRequest 오브젝트를 처리합니다.

    $ ccoctl aws create-iam-roles \
            --name <name> --region=<aws_region> \
            --credentials-requests-dir=<path-to-credrequests-dir> \
            --identity-provider-arn <oidc-arn>
    Copy to Clipboard Toggle word wrap
  3. 클러스터에 시크릿을 적용합니다.

    $ ls manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
    Copy to Clipboard Toggle word wrap
  4. 컨트롤러에서 사용할 인증 정보 시크릿이 생성되었는지 확인합니다.

    $ oc -n aws-load-balancer-operator get secret aws-load-balancer-controller-manual-cluster --template='{{index .data "credentials"}}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    [default]
        sts_regional_endpoints = regional
        role_arn = arn:aws:iam::999999999999:role/aws-load-balancer-operator-aws-load-balancer-controller
        web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
    Copy to Clipboard Toggle word wrap

  5. 다음과 같이 AWSLoadBalancerController 리소스 YAML 파일 (예: sample-aws-lb-lb-ECDHE-creds.yaml )을 만듭니다.

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      credentials:
        name: <secret-name> 
    3
    Copy to Clipboard Toggle word wrap
    1
    AWSLoadBalancerController 리소스를 정의합니다.
    2
    AWS Load Balancer 컨트롤러 인스턴스 이름을 정의합니다. 이 인스턴스 이름은 모든 관련 리소스에 접미사로 추가됩니다.
    3
    컨트롤러에서 사용하는 AWS 인증 정보가 포함된 시크릿 이름을 지정합니다.

22.5. AWS Load Balancer 컨트롤러 인스턴스 생성

AWS Load Balancer Operator를 설치한 후 AWS Load Balancer 컨트롤러를 생성할 수 있습니다.

22.5.1. AWS Load Balancer 컨트롤러 생성

클러스터에 AWSLoadBalancerController 오브젝트의 단일 인스턴스만 설치할 수 있습니다. CLI를 사용하여 AWS Load Balancer 컨트롤러를 생성할 수 있습니다. AWS Load Balancer Operator는 resource라는 클러스터 만 조정합니다.

사전 요구 사항

  • echoserver 네임스페이스를 생성했습니다.
  • OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

  1. AWSLoadBalancerController 오브젝트를 정의하는 YAML 파일을 생성합니다.

    sample-aws-lb.yaml 파일 예

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      subnetTagging: Auto 
    3
    
      additionalResourceTags: 
    4
    
      - key: example.org/security-scope
        value: staging
      ingressClass: alb 
    5
    
      config:
        replicas: 2 
    6
    
      enabledAddons: 
    7
    
        - AWSWAFv2 
    8
    Copy to Clipboard Toggle word wrap

    1
    AWSLoadBalancerController 개체를 정의합니다.
    2
    AWS Load Balancer 컨트롤러 이름을 정의합니다. 이 인스턴스 이름은 모든 관련 리소스에 접미사로 추가됩니다.
    3
    AWS Load Balancer Controller의 서브넷 태그 지정 방법을 구성합니다. 다음 값이 유효합니다.
    • Auto: AWS Load Balancer Operator는 클러스터에 속하는 서브넷을 결정하고 적절하게 태그를 지정합니다. 내부 서브넷 태그가 내부 서브넷에 없으면 Operator에서 올바르게 역할을 결정할 수 없습니다.
    • Manual: 적절한 역할 태그를 사용하여 클러스터에 속한 서브넷에 수동으로 태그를 지정합니다. 사용자 제공 인프라에 클러스터를 설치한 경우 이 옵션을 사용합니다.
    4
    AWS 리소스를 프로비저닝할 때 AWS Load Balancer 컨트롤러에서 사용하는 태그를 정의합니다.
    5
    Ingress 클래스 이름을 정의합니다. 기본값은 alb 입니다.
    6
    AWS Load Balancer 컨트롤러의 복제본 수를 지정합니다.
    7
    AWS Load Balancer Controller의 애드온으로 주석을 지정합니다.
    8
    alb.ingress.kubernetes.io/wafv2-acl-arn 주석을 활성화합니다.
  2. 다음 명령을 실행하여 AWSLoadBalancerController 오브젝트를 생성합니다.

    $ oc create -f sample-aws-lb.yaml
    Copy to Clipboard Toggle word wrap
  3. Deployment 리소스를 정의하는 YAML 파일을 생성합니다.

    sample-aws-lb.yaml 파일 예

    apiVersion: apps/v1
    kind: Deployment 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      selector:
        matchLabels:
          app: echoserver
      replicas: 3 
    3
    
      template:
        metadata:
          labels:
            app: echoserver
        spec:
          containers:
            - image: openshift/origin-node
              command:
               - "/bin/socat"
              args:
                - TCP4-LISTEN:8080,reuseaddr,fork
                - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
              imagePullPolicy: Always
              name: echoserver
              ports:
                - containerPort: 8080
    Copy to Clipboard Toggle word wrap

    1
    배포 리소스를 정의합니다.
    2
    배포 이름을 지정합니다.
    3
    배포 복제본 수를 지정합니다.
  4. Service 리소스를 정의하는 YAML 파일을 생성합니다.

    service-albo.yaml 파일의 예:

    apiVersion: v1
    kind: Service 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector:
        app: echoserver
    Copy to Clipboard Toggle word wrap

    1
    서비스 리소스를 정의합니다.
    2
    서비스 이름을 지정합니다.
  5. Ingress 리소스를 정의하는 YAML 파일을 생성합니다.

    ingress-albo.yaml 파일의 예:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <name> 
    1
    
      namespace: echoserver
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <echoserver> 
    2
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    Ingress 리소스의 이름을 지정합니다.
    2
    서비스 이름을 지정합니다.

검증

  • 다음 명령을 실행하여 Ingress 리소스의 상태를 HOST 변수에 저장합니다.

    $ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
    Copy to Clipboard Toggle word wrap
  • 다음 명령을 실행하여 Ingress 리소스의 상태를 확인합니다.

    $ curl $HOST
    Copy to Clipboard Toggle word wrap

22.6. 단일 AWS Load Balancer를 통해 여러 수신 리소스 제공

단일 AWS Load Balancer를 통해 트래픽을 단일 도메인에 속하는 다양한 서비스로 라우팅할 수 있습니다. 각 Ingress 리소스는 도메인의 서로 다른 끝점을 제공합니다.

22.6.1. 단일 AWS Load Balancer를 통해 여러 수신 리소스 생성

CLI를 사용하여 단일 AWS Load Balancer를 통해 트래픽을 여러 수신 리소스로 라우팅할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

  1. 다음과 같이 IngressClassParams 리소스 YAML 파일 (예: sample-single-lb-params.yaml )을 생성합니다.

    apiVersion: elbv2.k8s.aws/v1beta1 
    1
    
    kind: IngressClassParams
    metadata:
      name: single-lb-params 
    2
    
    spec:
      group:
        name: single-lb 
    3
    Copy to Clipboard Toggle word wrap
    1
    IngressClassParams 리소스의 API 그룹 및 버전을 정의합니다.
    2
    IngressClassParams 리소스 이름을 지정합니다.
    3
    IngressGroup 리소스 이름을 지정합니다. 이 클래스의 모든 Ingress 리소스는 이 IngressGroup 에 속합니다.
  2. 다음 명령을 실행하여 IngressClassParams 리소스를 생성합니다.

    $ oc create -f sample-single-lb-params.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음과 같이 IngressClass 리소스 YAML 파일을 생성합니다(예: sample-single-lb-class.yaml ).

    apiVersion: networking.k8s.io/v1 
    1
    
    kind: IngressClass
    metadata:
      name: single-lb 
    2
    
    spec:
      controller: ingress.k8s.aws/alb 
    3
    
      parameters:
        apiGroup: elbv2.k8s.aws 
    4
    
        kind: IngressClassParams 
    5
    
        name: single-lb-params 
    6
    Copy to Clipboard Toggle word wrap
    1
    IngressClass 리소스의 API 그룹 및 버전을 정의합니다.
    2
    Ingress 클래스 이름을 지정합니다.
    3
    컨트롤러 이름을 정의합니다. ingress.k8s.aws/alb 값은 이 클래스의 모든 수신 리소스가 AWS Load Balancer 컨트롤러에서 관리해야 함을 나타냅니다.
    4
    IngressClassParams 리소스의 API 그룹을 정의합니다.
    5
    IngressClassParams 리소스의 리소스 유형을 정의합니다.
    6
    IngressClassParams 리소스 이름을 정의합니다.
  4. 다음 명령을 실행하여 IngressClass 리소스를 생성합니다.

    $ oc create -f sample-single-lb-class.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음과 같이 AWSLoadBalancerController 리소스 YAML 파일을 생성합니다(예: sample-single-lb.yaml ).

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: single-lb 
    1
    Copy to Clipboard Toggle word wrap
    1
    IngressClass 리소스의 이름을 정의합니다.
  6. 다음 명령을 실행하여 AWSLoadBalancerController 리소스를 생성합니다.

    $ oc create -f sample-single-lb.yaml
    Copy to Clipboard Toggle word wrap
  7. 다음과 같이 Ingress 리소스 YAML 파일(예: sample-multiple-ingress.yaml )을 생성합니다.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-1 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/group.order: "1" 
    3
    
        alb.ingress.kubernetes.io/target-type: instance 
    4
    
    spec:
      ingressClassName: single-lb 
    5
    
      rules:
      - host: example.com 
    6
    
        http:
            paths:
            - path: /blog 
    7
    
              pathType: Prefix
              backend:
                service:
                  name: example-1 
    8
    
                  port:
                    number: 80 
    9
    
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-2
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "2"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /store
              pathType: Prefix
              backend:
                service:
                  name: example-2
                  port:
                    number: 80
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-3
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "3"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: example-3
                  port:
                    number: 80
    Copy to Clipboard Toggle word wrap
    1
    수신 이름을 지정합니다.
    2
    인터넷에 액세스하기 위해 공용 서브넷에서 프로비저닝할 로드 밸런서를 나타냅니다.
    3
    로드 밸런서에서 요청을 수신할 때 여러 수신 리소스의 규칙과 일치하는 순서를 지정합니다.
    4
    로드 밸런서가 OpenShift Container Platform 노드를 대상으로 서비스에 도달하도록 지정합니다.
    5
    이 수신에 속하는 Ingress 클래스를 지정합니다.
    6
    요청 라우팅에 사용되는 도메인 이름을 정의합니다.
    7
    서비스에 라우팅해야 하는 경로를 정의합니다.
    8
    Ingress 리소스에 구성된 엔드포인트를 제공하는 서비스 이름을 정의합니다.
    9
    엔드포인트를 제공하는 서비스의 포트를 정의합니다.
  8. 다음 명령을 실행하여 Ingress 리소스를 생성합니다.

    $ oc create -f sample-multiple-ingress.yaml
    Copy to Clipboard Toggle word wrap

22.7. TLS 종료 추가

AWS Load Balancer에서 TLS 종료를 추가할 수 있습니다.

22.7.1. AWS Load Balancer에서 TLS 종료 추가

도메인의 트래픽을 서비스 Pod로 라우팅하고 AWS Load Balancer에서 TLS 종료를 추가할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스할 수 있습니다.

프로세스

  1. AWSLoadBalancerController 리소스를 정의하는 YAML 파일을 생성합니다.

    add-tls-termination-albc.yaml 파일 예

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: tls-termination 
    1
    Copy to Clipboard Toggle word wrap

    1
    Ingress 클래스 이름을 정의합니다. Ingress 클래스가 클러스터에 없으면 AWS Load Balancer 컨트롤러가 하나를 생성합니다. spec.controlleringress.k8s.aws/alb 로 설정된 경우 AWS Load Balancer 컨트롤러는 추가 ingress 클래스 값을 조정합니다.
  2. Ingress 리소스를 정의하는 YAML 파일을 생성합니다.

    add-tls-termination-ingress.yaml 파일의 예

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <example> 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
    3
    
    spec:
      ingressClassName: tls-termination 
    4
    
      rules:
      - host: <example.com> 
    5
    
        http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <example-service> 
    6
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    수신 이름을 지정합니다.
    2
    컨트롤러는 공용 서브넷에서 Ingress의 로드 밸런서를 프로비저닝하여 인터넷을 통해 로드 밸런서에 액세스합니다.
    3
    로드 밸런서에 연결하는 인증서의 ARM(Amazon Resource Name)입니다.
    4
    Ingress 클래스 이름을 정의합니다.
    5
    트래픽 라우팅을 위한 도메인을 정의합니다.
    6
    트래픽 라우팅을 위한 서비스를 정의합니다.

22.8. 클러스터 전체 프록시 구성

AWS Load Balancer Operator에서 클러스터 전체 프록시를 구성할 수 있습니다. 클러스터 전체 프록시를 구성한 후 OLM(Operator Lifecycle Manager)은 HTTP_PROXY,HTTPS_PROXY, NO_PROXY 와 같은 환경 변수로 Operator의 모든 배포를 자동으로 업데이트합니다. 이러한 변수는 AWS Load Balancer Operator가 관리하는 컨트롤러로 채워집니다.

22.8.1. 클러스터 전체 프록시의 인증 기관 신뢰

  1. 다음 명령을 실행하여 aws-load-balancer-operator 네임스페이스에 CA(인증 기관) 번들을 포함할 구성 맵을 생성합니다.

    $ oc -n aws-load-balancer-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 신뢰할 수 있는 CA 번들을 구성 맵에 삽입하려면 다음 명령을 실행하여 config.openshift.io/inject-trusted-cabundle=true 라벨을 구성 맵에 추가합니다.

    $ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 AWS Load Balancer Operator 서브스크립션을 업데이트하여 AWS Load Balancer Operator 배포의 구성 맵에 액세스합니다.

    $ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'
    Copy to Clipboard Toggle word wrap
  4. AWS Load Balancer Operator가 배포된 후 다음 명령을 실행하여 CA 번들이 aws-load-balancer-operator-controller-manager 배포에 추가되었는지 확인합니다.

    $ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"
    Copy to Clipboard Toggle word wrap

    출력 예

    -rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
    trusted-ca
    Copy to Clipboard Toggle word wrap

  5. 선택 사항: 구성 맵이 변경될 때마다 다음 명령을 실행하여 AWS Load Balancer Operator를 다시 시작합니다.

    $ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

23장. 다중 네트워크

23.1. 다중 네트워크 이해하기

Kubernetes에서 컨테이너 네트워킹은 CNI(컨테이너 네트워크 인터페이스)를 구현하는 네트워킹 플러그인에 위임됩니다.

OpenShift Container Platform은 Multus CNI 플러그인을 사용하여 CNI 플러그인 체인을 허용합니다. 클러스터 설치 중에 기본 pod 네트워크를 구성합니다. 기본 네트워크는 클러스터의 모든 일반 네트워크 트래픽을 처리합니다. 사용 가능한 CNI 플러그인을 기반으로 추가 네트워크를 정의하고 이러한 네트워크 중 하나 이상을 Pod에 연결할 수 있습니다. 필요에 따라 클러스터에 2개 이상의 추가 네트워크를 정의 할 수 있습니다. 따라서 스위칭 또는 라우팅과 같은 네트워크 기능을 제공하는 pod를 구성할 때 유연성이 제공됩니다.

23.1.1. 추가 네트워크 사용 시나리오

데이터 플레인 및 컨트롤 플레인 분리를 포함하여 네트워크 격리가 필요한 상황에서 추가 네트워크를 사용할 수 있습니다. 네트워크 트래픽 격리는 다음과 같은 성능 및 보안상의 이유로 유용합니다.

성능
각 플레인의 트래픽 수량을 관리하기 위해 두 개의 다른 플레인으로 트래픽을 보낼 수 있습니다.
보안
보안 고려 사항을 위해 특별히 관리되는 네트워크 플레인으로 중요한 트래픽을 보낼 수 있으며 테넌트 또는 고객 간에 공유되지 않아야 하는 개인 데이터를 분리할 수 있습니다.

클러스터의 모든 pod는 여전히 클러스터 전체의 기본 네트워크를 사용하여 클러스터 전체의 연결을 유지합니다. 모든 pod에는 클러스터 전체 pod 네트워크에 연결된 eth0 인터페이스가 있습니다. oc exec -it <pod_name> -- ip a 명령을 사용하여 pod의 인터페이스를 확인할 수 있습니다. Multus CNI를 사용하는 네트워크 인터페이스를 추가하는 경우 이름은 net1, net2, … , netN입니다.

Pod에 추가 네트워크 인터페이스를 연결하려면 인터페이스 연결 방법을 정의하는 구성을 생성해야 합니다. NetworkAttachmentDefinition CR(사용자 정의 리소스)을 사용하여 각 인터페이스를 지정합니다. 각 CR 내부의 CNI 구성은 해당 인터페이스의 생성 방법을 정의합니다.

23.1.2. OpenShift Container Platform의 그룹은 중첩되지 않습니다.

OpenShift Container Platform은 클러스터에서 추가 네트워크를 생성하기 위해 다음 CNI 플러그인을 제공합니다.

23.2. 추가 네트워크 구성

클러스터 관리자는 클러스터에 대한 추가 네트워크를 구성할 수 있습니다. 지원되는 네트워크 유형은 다음과 같습니다.

23.2.1. 추가 네트워크 관리 방법

두 가지 방법으로 추가 네트워크의 라이프사이클을 관리할 수 있습니다. 각 접근 방식은 상호 배타적이며 한 번에 추가 네트워크를 관리하는 데 하나의 접근 방식만 사용할 수 있습니다. 두 방법 모두 추가 네트워크는 사용자가 구성하는 CNI(Container Network Interface) 플러그인에 의해 관리됩니다.

추가 네트워크의 경우 추가 네트워크의 일부로 구성하는 IPAM(IP 주소 관리) CNI 플러그인을 통해 IP 주소가 프로비저닝됩니다. IPAM 플러그인은 DHCP 및 고정 할당을 포함한 다양한 IP 주소 할당 방식을 지원합니다.

  • CNO(Cluster Network Operator) 구성을 수정합니다. CNO는 NetworkAttachmentDefinition 오브젝트를 자동으로 생성하고 관리합니다. 오브젝트 라이프사이클을 관리하는 것 외에도 CNO는 DHCP 할당된 IP 주소를 사용하는 추가 네트워크에 DHCP를 사용할 수 있도록 합니다.
  • YAML 매니페스트 적용: NetworkAttachmentDefinition 오브젝트를 생성하여 추가 네트워크를 직접 관리할 수 있습니다. 이 방법을 사용하면 CNI 플러그인을 연결할 수 있습니다.
참고

OVN SDN을 사용하여 RHOSP(Red Hat OpenStack Platform)에 여러 네트워크 인터페이스를 사용하여 OpenShift Container Platform 노드를 배포하는 경우 보조 인터페이스의 DNS 구성이 기본 인터페이스의 DNS 구성보다 우선할 수 있습니다. 이 경우 보조 인터페이스에 연결된 서브넷 ID의 DNS 네임 서버를 제거합니다.

$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
Copy to Clipboard Toggle word wrap

23.2.2. 추가 네트워크 연결 구성

추가 네트워크는 k8s.cni.cncf.io API 그룹에서 NetworkAttachmentDefinition API를 사용하여 구성됩니다.

중요

이 정보는 프로젝트 관리 사용자가 액세스할 수 있으므로 중요한 정보 또는 시크릿을 NetworkAttachmentDefinition 오브젝트에 저장하지 마십시오.

API의 구성은 다음 표에 설명되어 있습니다.

Expand
표 23.1. NetworkAttachmentDefinition API 필드
필드유형설명

metadata.name

string

추가 네트워크의 이름입니다.

metadata.namespace

string

오브젝트와 연결된 네임스페이스입니다.

spec.config

string

JSON 형식의 CNI 플러그인 구성입니다.

23.2.2.1. Cluster Network Operator를 통한 추가 네트워크 구성

추가 네트워크 연결 구성은 CNO(Cluster Network Operator) 구성의 일부로 지정됩니다.

다음 YAML은 CNO를 사용하여 추가 네트워크를 관리하기 위한 구성 매개변수를 설명합니다.

CNO(Cluster Network Operator) 구성

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks: 
1

  - name: <name> 
2

    namespace: <namespace> 
3

    rawCNIConfig: |- 
4

      {
        ...
      }
    type: Raw
Copy to Clipboard Toggle word wrap

1
하나 이상의 추가 네트워크 구성으로 구성된 배열입니다.
2
생성 중인 추가 네트워크 연결의 이름입니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
3
네트워크를 연결할 네임스페이스입니다. 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.
중요

OVN-Kubernetes 네트워크 플러그인의 네임스페이스 문제를 방지하려면 이 네임스페이스가 기본 추가 네트워크 연결을 위해 예약되어 있으므로 추가 네트워크 연결 기본값 을 지정하지 마십시오.

4
JSON 형식의 CNI 플러그인 구성입니다.
23.2.2.2. YAML 매니페스트에서 추가 네트워크 구성

추가 네트워크의 구성은 다음 예와 같이 YAML 구성 파일에서 지정됩니다.

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
1

spec:
  config: |- 
2

    {
      ...
    }
Copy to Clipboard Toggle word wrap
1
생성 중인 추가 네트워크 연결의 이름입니다.
2
JSON 형식의 CNI 플러그인 구성입니다.

23.2.3. 추가 네트워크 유형의 구성

추가 네트워크의 특정 구성 필드는 다음 섹션에 설명되어 있습니다.

23.2.3.1. 브리지 추가 네트워크 구성

다음 오브젝트는 브릿지 CNI 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.2. 브릿지 CNI 플러그인 JSON 구성 오브젝트
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 0.3.1 값이 필요합니다.

name

string

CNO 구성에 대해 이전에 제공한 name 매개변수의 값입니다.

type

string

구성할 CNI 플러그인의 이름: bridge.

IPAM

object

IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

Bridge

string

선택 사항: 사용할 가상 브리지의 이름을 지정합니다. 브릿지 인터페이스가 호스트에 없으면 생성됩니다. 기본값은 cni0입니다.

ipMasq

boolean

선택 사항: 가상 네트워크를 떠나는 트래픽에 대해 IP 마스커레이딩을 활성화하려면 true 로 설정합니다. 모든 트래픽의 소스 IP 주소가 브리지의 IP 주소로 다시 작성됩니다. 브리지에 IP 주소가 없으면 이 설정이 적용되지 않습니다. 기본값은 false입니다.

isGateway

boolean

선택 사항: 브릿지에 IP 주소를 할당하려면 true 로 설정합니다. 기본값은 false입니다.

isDefaultGateway

boolean

선택 사항: 브릿지를 가상 네트워크의 기본 게이트웨이로 구성하려면 true 로 설정합니다. 기본값은 false입니다. isDefaultGatewaytrue로 설정되면 isGateway도 자동으로 true로 설정됩니다.

forceAddress

boolean

선택 사항: 이전에 할당된 IP 주소를 가상 브리지에 할당할 수 있도록 true 로 설정합니다. false로 설정하면 중첩되는 하위 집합의 IPv4 주소 또는 IPv6 주소가 가상 브릿지에 지정되는 경우 오류가 발생합니다. 기본값은 false입니다.

hairpinMode

boolean

선택 사항: 가상 브리지가 수신한 가상 포트를 통해 이더넷 프레임을 다시 보낼 수 있도록 하려면 true 로 설정합니다. 이 모드를 반사 릴레이라고도 합니다. 기본값은 false입니다.

promiscMode

boolean

선택 사항: 브릿지에서 무차별 모드를 활성화하려면 true 로 설정합니다. 기본값은 false입니다.

vlan

string

선택 사항: VLAN(가상 LAN) 태그를 정수 값으로 지정합니다. 기본적으로 VLAN 태그는 할당되지 않습니다.

preserveDefaultVlan

string

선택 사항: 기본 vlan을 브리지에 연결된 veth 끝에 유지해야 하는지 여부를 나타냅니다. 기본값은 true입니다.

mtu

integer

선택 사항: 최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.

enabledad

boolean

선택 사항: 컨테이너 사이드 veth 에 대해 중복 주소 탐지를 활성화합니다. 기본값은 false입니다.

macspoofchk

boolean

선택 사항: mac 스푸핑 검사를 활성화하여 컨테이너에서 발생하는 트래픽을 인터페이스의 mac 주소로 제한합니다. 기본값은 false입니다.

참고

VLAN 매개 변수는 veth 의 호스트에서 VLAN 태그를 구성하고 브리지 인터페이스에서 vlan_filtering 기능도 활성화합니다.

참고

L2 네트워크에 대한 uplink를 구성하려면 다음 명령을 사용하여 uplink 인터페이스에서 vlan을 허용해야 합니다.

$  bridge vlan add vid VLAN_ID dev DEV
Copy to Clipboard Toggle word wrap
23.2.3.1.1. 브릿지 구성 예

다음 예제는 이름이 bridge-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "bridge-net",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}
Copy to Clipboard Toggle word wrap
23.2.3.2. 호스트 장치 추가 네트워크에 대한 구성
참고

device ,hwaddr,kernelpath 또는 pciBusID 매개변수 중 하나만 설정하여 네트워크 장치를 지정합니다.

다음 오브젝트는 호스트 장치 CNI 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.3. 호스트 장치 CNI 플러그인 JSON 구성 오브젝트
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 0.3.1 값이 필요합니다.

name

string

CNO 구성에 대해 이전에 제공한 name 매개변수의 값입니다.

type

string

구성할 CNI 플러그인의 이름: 호스트 장치.

device

string

선택사항: 장치 이름(예: eth0) 입니다.

hwaddr

string

선택사항: 장치 하드웨어 MAC 주소입니다.

kernelpath

string

선택 사항: Linux 커널 장치 경로입니다(예: /sys/devices/pci0000:00/0000:00:1f.6 ).

pciBusID

string

선택 사항: 네트워크 장치의 PCI 주소(예 : 0000:00:1f.6)

23.2.3.2.1. 호스트 장치 구성 예

다음 예제는 이름이 hostdev-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "hostdev-net",
  "type": "host-device",
  "device": "eth1"
}
Copy to Clipboard Toggle word wrap
23.2.3.3. VLAN 추가 네트워크에 대한 구성

다음 오브젝트는 VLAN CNI 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.4. VLAN CNI 플러그인 JSON 구성 오브젝트
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 0.3.1 값이 필요합니다.

name

string

CNO 구성에 대해 이전에 제공한 name 매개변수의 값입니다.

type

string

구성할 CNI 플러그인의 이름: vlan.

master

string

네트워크 연결과 연결할 이더넷 인터페이스입니다. 마스터를 지정하지 않으면 기본 네트워크 경로에 대한 인터페이스가 사용됩니다.

vlanId

integer

vlan의 ID를 설정합니다.

IPAM

object

IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

mtu

integer

선택 사항: 최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.

dns

integer

선택 사항: 반환할 DNS 정보(예: 우선순위 지정 DNS 이름 서버 목록)입니다.

linkInContainer

boolean

선택 사항: 마스터 인터페이스가 컨테이너 네트워크 네임스페이스 또는 기본 네트워크 네임스페이스에 있는지 여부를 지정합니다.

23.2.3.3.1. VLAN 구성 예

다음 예제에서는 vlan-net 이라는 추가 네트워크를 구성합니다.

{
  "name": "vlan-net",
  "cniVersion": "0.3.1",
  "type": "vlan",
  "master": "eth0",
  "mtu": 1500,
  "vlanId": 5,
  "linkInContainer": false,
  "ipam": {
      "type": "host-local",
      "subnet": "10.1.1.0/24"
  },
  "dns": {
      "nameservers": [ "10.1.1.1", "8.8.8.8" ]
  }
}
Copy to Clipboard Toggle word wrap
23.2.3.4. IPVLAN 추가 네트워크 구성

다음 오브젝트는 IPVLAN CNI 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.5. IPVLAN CNI 플러그인 JSON 구성 오브젝트
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 0.3.1 값이 필요합니다.

name

string

CNO 구성에 대해 이전에 제공한 name 매개변수의 값입니다.

type

string

구성할 CNI 플러그인의 이름: ipvlan.

IPAM

object

IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다. 플러그인이 연결되어 있지 않으면 이 작업이 필요합니다.

mode

string

선택사항: 가상 네트워크의 작동 모드입니다. 값은 l2, l3 또는 l3s여야 합니다. 기본값은 l2입니다.

master

string

선택 사항: 네트워크 연결과 연결할 이더넷 인터페이스입니다. 마스터를 지정하지 않으면 기본 네트워크 경로에 대한 인터페이스가 사용됩니다.

mtu

integer

선택 사항: 최대 전송 단위(MTU)를 지정된 값으로 설정합니다. 기본값은 커널에 의해 자동으로 설정됩니다.

참고
  • ipvlan 오브젝트에서는 가상 인터페이스가 마스터 인터페이스와 통신할 수 없습니다. 따라서 컨테이너는 ipvlan 인터페이스를 사용하여 호스트에 연결할 수 없습니다. 컨테이너가PTP(Precision Time Protocol)를 지원하는 네트워크와 같이 호스트에 대한 연결을 제공하는 네트워크에 참여하고 있는지 확인합니다.
  • 단일 마스터 인터페이스는 macvlanipvlan 을 둘 다 사용하도록 동시에 구성할 수 없습니다.
  • 인터페이스와 무관할 수 없는 IP 할당 체계의 경우 ipvlan 플러그인은 이 논리를 처리하는 이전 플러그인과 연결할 수 있습니다. 마스터 를 생략한 경우 이전 결과에 슬레이브를 부여하려면 ipvlan 플러그인에 대한 단일 인터페이스 이름이 포함되어야 합니다. ipam 을 생략하면 이전 결과가 ipvlan 인터페이스를 구성하는 데 사용됩니다.
23.2.3.4.1. ipvlan 구성 예

다음 예제는 이름이 ipvlan-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "ipvlan-net",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}
Copy to Clipboard Toggle word wrap
23.2.3.5. MACVLAN 추가 네트워크 구성

다음 오브젝트는 macvlan CNI 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.6. MACVLAN CNI 플러그인 JSON 구성 오브젝트
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 0.3.1 값이 필요합니다.

name

string

CNO 구성에 대해 이전에 제공한 name 매개변수의 값입니다.

type

string

구성할 CNI 플러그인의 이름입니다. macvlan.

IPAM

object

IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

mode

string

선택 사항: 가상 네트워크에 대한 트래픽 가시성을 구성합니다. bridge, passthru, private 또는 vepa 중 하나여야 합니다. 값을 입력하지 않으면 기본값은 bridge입니다.

master

string

선택 사항: 새로 생성된 macvlan 인터페이스와 연결할 호스트 네트워크 인터페이스입니다. 값을 지정하지 않으면 기본 경로 인터페이스가 사용됩니다.

mtu

string

선택 사항: 지정된 값으로 최대 전송 단위(MTU)입니다. 기본값은 커널에 의해 자동으로 설정됩니다.

참고

플러그인 구성에 대한 마스터 키를 지정하는 경우, 가능한 충돌을 방지하려면 기본 네트워크 플러그인과 연결된 것과 다른 물리적 네트워크 인터페이스를 사용합니다.

23.2.3.5.1. macvlan 구성 예

다음 예제는 이름이 macvlan-net인 추가 네트워크를 구성합니다.

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}
Copy to Clipboard Toggle word wrap
23.2.3.6. OVN-Kubernetes 추가 네트워크의 구성

Red Hat OpenShift Networking OVN-Kubernetes 네트워크 플러그인을 사용하면 Pod에 대한 보조 네트워크 인터페이스를 구성할 수 있습니다. 보조 네트워크 인터페이스를 구성하려면 NetworkAttachmentDefinition CRD(사용자 정의 리소스 정의)에서 구성을 정의해야 합니다.

중요

OVN-Kubernetes 추가 네트워크에 대한 구성은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

참고

노드의 OVN-Kubernetes 컨트롤 플레인 에이전트가 연결된 network-attachment-definition CR을 처리할 때까지 Pod 및 다중 네트워크 정책 생성은 보류 중 상태로 유지될 수 있습니다.

다음 섹션에서는 OVN-Kubernetes가 현재 보조 네트워크를 허용하는 각 토폴로지에 대한 구성 예를 제공합니다.

참고

네트워크 이름은 고유해야 합니다. 예를 들어 동일한 네트워크를 참조하는 다양한 구성으로 여러 NetworkAttachmentDefinition CRD를 생성하는 것은 지원되지 않습니다.

23.2.3.6.1. OVN-Kubernetes 네트워크 플러그인 JSON 구성 테이블

다음 표에서는 OVN-Kubernetes CNI 네트워크 플러그인의 구성 매개변수를 설명합니다.

Expand
표 23.7. OVN-Kubernetes 네트워크 플러그인 JSON 구성 테이블
필드유형설명

cniVersion

string

CNI 사양 버전입니다. 필수 값은 0.3.1 입니다.

name

string

네트워크의 이름입니다. 이러한 네트워크는 네임스페이스가 지정되지 않습니다. 예를 들어 두 개의 서로 다른 네임스페이스에 존재하는 두 개의 다른 NetworkAttachmentDefinitions 에서 참조되는 l2-network 라는 네트워크가 있을 수 있습니다. 이렇게 하면 자체 다른 네임스페이스에서 NetworkAttachmentDefinition 을 사용하는 Pod가 동일한 보조 네트워크를 통해 통신할 수 있습니다. 그러나 이러한 두 개의 NetworkAttachmentDefinitions토폴로지,서브넷,mtu, excludeSubnets 와 같은 동일한 네트워크 특정 매개변수도 공유해야 합니다.

type

string

구성할 CNI 플러그인의 이름입니다. 필수 값은 ovn-k8s-cni-overlay 입니다.

토폴로지

string

네트워크의 토폴로지 구성입니다. 필요한 값은 layer2 입니다.

subnets

string

클러스터 전체에서 네트워크에 사용할 서브넷입니다.

"topology":"layer2" 배포의 경우 IPv6 (2001:DBB::/64) 및 듀얼 스택 (192.168.100.0/24,2001:DBB::/64) 서브넷이 지원됩니다.

mtu

string

지정된 값의 최대 전송 단위(MTU)입니다. 기본값 1300 은 커널에 의해 자동으로 설정됩니다.

netAttachDefName

string

메타데이터 네임스페이스 및 이 구성이 포함된 네트워크 연결 정의 오브젝트의 이름입니다. 예를 들어 이 구성이 l2-network 라는 네임스페이스 ns1NetworkAttachmentDefinition 에 정의된 경우 이 구성은 ns1/l2-network 로 설정해야 합니다.

excludeSubnets

string

CIDR 및 IP 쉼표로 구분된 목록입니다. IPS는 할당 가능한 IP 풀에서 제거되며 Pod로 전달되지 않습니다. 생략하면 네트워크를 구현하는 논리 스위치는 계층 2 통신만 제공하며 사용자는 포드에 대한 IP를 구성해야 합니다. 포트 보안은 MAC 스푸핑만 방지합니다.

23.2.3.6.2. 전환 토폴로지 구성

전환(레이어 2) 토폴로지 네트워크는 클러스터 전체 논리 스위치를 통해 워크로드를 상호 연결합니다. 이 구성은 IPv6 및 듀얼 스택 배포에 사용할 수 있습니다.

참고

계층 2 전환 토폴로지 네트워크는 클러스터 내에서 Pod 간에 데이터 패킷을 전송할 때만 가능합니다.

다음 NetworkAttachmentDefinition CRD(사용자 정의 리소스 정의) YAML은 전환된 보조 네트워크를 구성하는 데 필요한 필드를 설명합니다.

    {
            "cniVersion": "0.3.1",
            "name": "l2-network",
            "type": "ovn-k8s-cni-overlay",
            "topology":"layer2",
            "subnets": "10.100.200.0/24",
            "mtu": 1300,
            "netAttachDefName": "ns1/l2-network",
            "excludeSubnets": "10.100.200.0/29"
    }
Copy to Clipboard Toggle word wrap
23.2.3.6.3. 추가 네트워크의 Pod 구성

k8s.v1.cni.cncf.io/networks 주석을 통해 보조 네트워크 연결을 지정해야 합니다.

다음 예제에서는 이 가이드에 표시된 각 연결 구성에 대해 하나씩 두 개의 보조 첨부 파일이 있는 Pod를 프로비저닝합니다.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: l2-network
  name: tinypod
  namespace: ns1
spec:
  containers:
  - args:
    - pause
    image: k8s.gcr.io/e2e-test-images/agnhost:2.36
    imagePullPolicy: IfNotPresent
    name: agnhost-container
Copy to Clipboard Toggle word wrap
23.2.3.6.4. 고정 IP 주소로 Pod 구성

다음 예제에서는 고정 IP 주소를 사용하여 Pod를 프로비저닝합니다.

참고
  • 계층 2 연결에 대한 Pod의 보조 네트워크 연결의 IP 주소만 지정할 수 있습니다.
  • Pod에 고정 IP 주소를 지정하는 것은 연결 구성에 서브넷이 포함되지 않은 경우에만 가능합니다.
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "l2-network", 
1

        "mac": "02:03:04:05:06:07", 
2

        "interface": "myiface1", 
3

        "ips": [
          "192.0.2.20/24"
          ] 
4

      }
    ]'
  name: tinypod
  namespace: ns1
spec:
  containers:
  - args:
    - pause
    image: k8s.gcr.io/e2e-test-images/agnhost:2.36
    imagePullPolicy: IfNotPresent
    name: agnhost-container
Copy to Clipboard Toggle word wrap
1
네트워크의 이름입니다. 이 값은 모든 NetworkAttachmentDefinitions 에서 고유해야 합니다.
2
인터페이스에 할당할 MAC 주소입니다.
3
Pod에 생성할 네트워크 인터페이스의 이름입니다.
4
네트워크 인터페이스에 할당할 IP 주소입니다.

23.2.4. 추가 네트워크의 IP 주소 할당 구성

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
23.2.4.1. 고정 IP 주소 할당 구성

다음 표에서는 고정 IP 주소 할당 구성을 설명합니다.

Expand
표 23.8. IPAM 정적 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 정적 값이 필요합니다.

addresses

array

가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

Pod 내부에서 구성할 경로를 지정하는 오브젝트 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 어레이에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand
표 23.9. ipam.addresses[] array
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand
표 23.10. IPAM.routes[] 배열
필드유형설명

dst

string

CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 192.168.17.0/24 또는 0.0.0.0/0 )입니다.

gw

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand
표 23.11. IPAM.dns 오브젝트
필드유형설명

nameservers

array

DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}
Copy to Clipboard Toggle word wrap

23.2.4.2. DHCP(Dynamic 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"
        }
      }
  # ...
Copy to Clipboard Toggle word wrap

Expand
표 23.12. IPAM DHCP 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. dhcp 값이 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}
Copy to Clipboard Toggle word wrap

23.2.4.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand
표 23.13. IPAM: 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 필요한 경우 값을 가져옵니다 . Gets the value whereabouts.

범위

string

CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}
Copy to Clipboard Toggle word wrap

23.2.4.4. Whereabouts-reconciler 데몬 세트 생성

Whereabouts 조정기는 Whereabouts IP Address Management(IPAM) 솔루션을 사용하여 클러스터 내에서 Pod의 동적 IP 주소 할당을 관리합니다. 이렇게 하면 각 pod가 지정된 IP 주소 범위에서 고유한 IP 주소를 가져옵니다. Pod가 삭제되거나 축소될 때 IP 주소 릴리스도 처리합니다.

참고

NetworkAttachmentDefinition CR(사용자 정의 리소스)을 동적 IP 주소 할당에 사용할 수도 있습니다.

Cluster Network Operator를 통해 추가 네트워크를 구성할 때 whereabouts-reconciler 데몬 세트가 자동으로 생성됩니다. YAML 매니페스트에서 추가 네트워크를 구성할 때 자동으로 생성되지 않습니다.

whereabouts-reconciler 데몬 세트의 배포를 트리거하려면 Cluster Network Operator CR(사용자 정의 리소스) 파일을 편집하여 whereabouts-shim 네트워크 연결을 수동으로 생성해야 합니다.

다음 절차에 따라 whereabouts-reconciler 데몬 세트를 배포합니다.

절차

  1. 다음 명령을 실행하여 Network.operator.openshift.io CR(사용자 정의 리소스)을 편집합니다.

    $ oc edit network.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap
  2. 이 예제 YAML 추출에 표시된 additionalNetworks 섹션을 CR(사용자 정의 리소스)의 사양 정의 내에 포함합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    # ...
    spec:
      additionalNetworks:
      - name: whereabouts-shim
        namespace: default
        rawCNIConfig: |-
          {
           "name": "whereabouts-shim",
           "cniVersion": "0.3.1",
           "type": "bridge",
           "ipam": {
             "type": "whereabouts"
           }
          }
        type: Raw
    # ...
    Copy to Clipboard Toggle word wrap
  3. 파일을 저장하고 텍스트 편집기를 종료합니다.
  4. 다음 명령을 실행하여 whereabouts-reconciler 데몬 세트가 성공적으로 배포되었는지 확인합니다.

    $ oc get all -n openshift-multus | grep whereabouts-reconciler
    Copy to Clipboard Toggle word wrap

    출력 예

    pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
    pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
    pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
    pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
    pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
    pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
    daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s
    Copy to Clipboard Toggle word wrap

23.2.4.5. Whereabouts IP 조정기 일정 구성

Whereabouts IPAM CNI 플러그인은 IP 조정기를 매일 실행합니다. 이 프로세스에서는 IP가 소진될 수 있는 모든 진행 중인 IP 할당을 정리하므로 새 Pod가 IP를 할당하지 못하도록 합니다.

IP 조정기가 실행되는 빈도를 변경하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • whereabouts-reconciler 데몬 세트를 배포하고 whereabouts-reconciler Pod가 실행 중입니다.

절차

  1. 다음 명령을 실행하여 openshift-multus 네임스페이스에 IP 조정기에 대한 특정 cron 표현식을 사용하여 이름이 whereabouts-config 라는 ConfigMap 오브젝트를 생성합니다.

    $ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"
    Copy to Clipboard Toggle word wrap

    이 cron 표현식은 IP 조정기가 15분마다 실행됨을 나타냅니다. 특정 요구 사항에 따라 표현식을 조정합니다.

    참고

    whereabouts-reconciler 데몬 세트는 5개의 별표를 포함하는 cron 표현식 패턴만 사용할 수 있습니다. 초를 나타내는 데 사용되는 여섯 번째 단계는 현재 지원되지 않습니다.

  2. 다음 명령을 실행하여 openshift-multus 네임스페이스 내에서 whereabouts-reconciler 데몬 세트 및 Pod와 관련된 리소스에 대한 정보를 검색합니다.

    $ oc get all -n openshift-multus | grep whereabouts-reconciler
    Copy to Clipboard Toggle word wrap

    출력 예

    pod/whereabouts-reconciler-2p7hw                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-76jk7                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-94zw6                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-mfh68                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-pgshz                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-xn5xz                   1/1     Running   0             4m14s
    daemonset.apps/whereabouts-reconciler          6         6         6       6            6           kubernetes.io/os=linux   4m16s
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 whereabouts-reconciler Pod가 구성된 간격으로 IP 조정기를 실행하는지 확인합니다.

    $ oc -n openshift-multus logs whereabouts-reconciler-2p7hw
    Copy to Clipboard Toggle word wrap

    출력 예

    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CHMOD
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..data_tmp": RENAME
    2024-02-02T16:33:54Z [verbose] using expression: */15 * * * *
    2024-02-02T16:33:54Z [verbose] configuration updated to file "/cron-schedule/..data". New cron expression: */15 * * * *
    2024-02-02T16:33:54Z [verbose] successfully updated CRON configuration id "00c2d1c9-631d-403f-bb86-73ad104a6817" - new cron expression: */15 * * * *
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/config": CREATE
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_26_17.3874177937": REMOVE
    2024-02-02T16:45:00Z [verbose] starting reconciler run
    2024-02-02T16:45:00Z [debug] NewReconcileLooper - inferred connection data
    2024-02-02T16:45:00Z [debug] listing IP pools
    2024-02-02T16:45:00Z [debug] no IP addresses to cleanup
    2024-02-02T16:45:00Z [verbose] reconciler success
    Copy to Clipboard Toggle word wrap

23.2.5. Cluster Network Operator를 사용하여 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

중요

Cluster Network Operator가 관리하는 NetworkAttachmentDefinition 오브젝트를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

사전 요구 사항

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

절차

  1. 선택 사항: 추가 네트워크의 네임스페이스를 생성합니다.

    $ oc create namespace <namespace_name>
    Copy to Clipboard Toggle word wrap
  2. CNO 구성을 편집하려면 다음 명령을 입력합니다.

    $ oc edit networks.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap
  3. 다음 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      # ...
      additionalNetworks:
      - name: tertiary-net
        namespace: namespace2
        type: Raw
        rawCNIConfig: |-
          {
            "cniVersion": "0.3.1",
            "name": "tertiary-net",
            "type": "ipvlan",
            "master": "eth1",
            "mode": "l2",
            "ipam": {
              "type": "static",
              "addresses": [
                {
                  "address": "192.168.1.23/24"
                }
              ]
            }
          }
    Copy to Clipboard Toggle word wrap
  4. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

검증

  • CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 생성했는지 확인합니다. CNO가 오브젝트를 생성하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <namespace>
    CNO 구성에 추가한 네트워크 연결의 네임스페이스를 지정합니다.

    출력 예

    NAME                 AGE
    test-network-1       14m
    Copy to Clipboard Toggle word wrap

23.2.6. YAML 매니페스트를 적용하여 추가 네트워크 연결 생성

사전 요구 사항

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

절차

  1. 다음 예와 같이 추가 네트워크 구성으로 YAML 파일을 생성합니다.

    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      name: next-net
    spec:
      config: |-
        {
          "cniVersion": "0.3.1",
          "name": "work-network",
          "type": "host-device",
          "device": "eth1",
          "ipam": {
            "type": "dhcp"
          }
        }
    Copy to Clipboard Toggle word wrap
  2. 추가 네트워크를 생성하려면 다음 명령을 입력합니다.

    $ oc apply -f <file>.yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <file>
    YAML 매니페스트가 포함된 파일의 이름을 지정합니다.

23.3. 가상 라우팅 및 전달 정보

23.3.1. 가상 라우팅 및 전달 정보

IP 규칙과 결합된 가상 라우팅 및 전달(VRF) 장치는 가상 라우팅 및 전달 도메인을 생성하는 기능을 제공합니다. VRF는 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 증대시킵니다. VRF는 예를 들어 각 테넌트마다 고유한 라우팅 테이블이 있고 다른 기본 게이트웨이가 필요한 멀티 테넌시 기능을 제공하는 데 사용됩니다.

프로세스는 소켓을 VRF 장치에 바인딩할 수 있습니다. 바인딩된 소켓을 통한 패킷은 VRF 장치와 연결된 라우팅 테이블을 사용합니다. VRF의 중요한 기능은 OSI 모델 레이어 3 트래픽 및 LLDP와 같은 L2 도구에만 영향을 미치지 않는다는 것입니다. 이를 통해 정책 기반 라우팅과 같은 우선순위가 높은 IP 규칙이 특정 트래픽을 지시하는 VRF 장치 규칙보다 우선합니다.

23.3.1.1. 통신 운영자의 포드에 대한 보조 네트워크 이점

통신사용 사례에서 각 CNF는 동일한 주소 공간을 공유하는 여러 다른 네트워크에 잠재적으로 연결할 수 있습니다. 이러한 보조 네트워크는 클러스터의 기본 네트워크 CIDR과 잠재적으로 충돌할 수 있습니다. CNI VRF 플러그인을 사용하여 네트워크 기능은 동일한 IP 주소를 사용하여 다른 고객의 인프라에 연결할 수 있으므로 서로 다른 고객을 분리할 수 있습니다. IP 주소는 OpenShift Container Platform IP 공간과 겹치게 됩니다. CNI VRF 플러그인은 CNF에 필요한 권한 수를 줄이고 보조 네트워크의 네트워크 토폴로지의 가시성을 높입니다.

23.4. 다중 네트워크 정책 구성

클러스터 관리자는 추가 네트워크에 대한 다중 네트워크를 구성할 수 있습니다. SR-IOV 및 macvlan 추가 네트워크에 대한 다중 네트워크 정책을 지정할 수 있습니다. macvlan 추가 네트워크가 완전히 지원됩니다. ipvlan과 같은 기타 유형의 추가 네트워크는 지원되지 않습니다.

중요

SR-IOV 추가 네트워크에 대한 다중 네트워크 정책 구성은 기술 프리뷰 기능이며 커널 네트워크 인터페이스 카드(NIC)에서만 지원됩니다. DPDK(Data Plane Development Kit) 애플리케이션에서 SR-IOV가 지원되지 않습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

참고

IPv6 네트워크에서 구성된 네트워크 정책은 무시됩니다.

23.4.1. 다중 네트워크 정책과 네트워크 정책의 차이점

MultiNetworkPolicy API는 NetworkPolicy API를 구현하지만 다음과 같은 몇 가지 중요한 차이점이 있습니다.

  • MultiNetworkPolicy API를 사용해야 합니다.

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    Copy to Clipboard Toggle word wrap
  • CLI를 사용하여 다중 네트워크 정책과 상호 작용할 때 multi-networkpolicy 리소스 이름을 사용해야 합니다. 예를 들어 oc get multi-networkpolicy <name> 명령을 사용하여 다중 네트워크 정책 오브젝트를 볼 수 있습니다. 여기서 <name>은 다중 네트워크 정책의 이름입니다.
  • macvlan 또는 SR-IOV 추가 네트워크를 정의하는 네트워크 연결 정의의 이름으로 주석을 지정해야 합니다.

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

23.4.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
    Copy to Clipboard Toggle word wrap
  2. 다중 네트워크 정책을 활성화하도록 클러스터를 구성합니다.

    $ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

23.4.3. 다중 네트워크 정책 작업

클러스터 관리자는 다중 네트워크 정책을 생성, 편집, 보기 및 삭제할 수 있습니다.

23.4.3.1. 사전 요구 사항
  • 클러스터에 대한 다중 네트워크 정책 지원을 활성화했습니다.
23.4.3.2. CLI를 사용하여 다중 네트워크 정책 생성

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

사전 요구 사항

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

프로세스

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

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

      $ touch <policy_name>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <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: []
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <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: {}
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

      특정 네임스페이스에서 하나의 Pod로 들어오는 트래픽 허용

      이 정책을 사용하면 namespace-y 에서 실행되는 Pod의 pod-a 레이블이 지정된 Pod로의 트래픽을 수행할 수 있습니다.

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

      다음과 같습니다.

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

      서비스에 대한 트래픽 제한

      이 정책을 적용하면 app=bookstorerole=api 레이블이 모두 있는 모든 Pod는 app=bookstore 라벨이 있는 Pod에서만 액세스할 수 있습니다. 이 예제에서 애플리케이션은 레이블 app=bookstorerole=api 로 표시된 REST API 서버일 수 있습니다.

      이 예제에서는 다음 사용 사례를 다룹니다.

      • 서비스에 대한 트래픽을 사용해야 하는 다른 마이크로 서비스로만 제한합니다.
      • 애플리케이션 사용만 허용하도록 데이터베이스에 대한 연결 제한.

        apiVersion: k8s.cni.cncf.io/v1beta1
        kind: MultiNetworkPolicy
        metadata:
          name: api-allow
          annotations:
            k8s.v1.cni.cncf.io/policy-for: <network_name>
        spec:
          podSelector:
            matchLabels:
              app: bookstore
              role: api
          ingress:
          - from:
              - podSelector:
                  matchLabels:
                    app: bookstore
        Copy to Clipboard Toggle word wrap

        다음과 같습니다.

        <network_name>
        네트워크 연결 정의의 이름을 지정합니다.
  2. 다음 명령을 실행하여 다중 네트워크 정책 오브젝트를 생성합니다.

    $ oc apply -f <policy_name>.yaml -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

참고

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

23.4.3.3. 다중 네트워크 정책 편집

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

사전 요구 사항

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

프로세스

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

    $ oc get multi-networkpolicy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

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

      $ oc apply -n <namespace> -f <policy_file>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

      $ oc edit multi-networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

    $ oc describe multi-networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

cluster-admin 권한으로 웹 콘솔에 로그인하면 YAML의 모든 네임스페이스에서 또는 Actions 메뉴를 통해 웹 콘솔의 정책에서 직접 네트워크 정책을 편집할 수 있습니다.

23.4.3.4. CLI를 사용하여 다중 네트워크 정책 보기

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

사전 요구 사항

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

프로세스

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

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

      $ oc get multi-networkpolicy
      Copy to Clipboard Toggle word wrap
    • 선택 사항: 특정 다중 네트워크 정책을 검사하려면 다음 명령을 입력합니다.

      $ oc describe multi-networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

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

cluster-admin 권한으로 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 YAML에서 직접 또는 웹 콘솔의 양식에서 볼 수 있습니다.

23.4.3.5. CLI를 사용하여 다중 네트워크 정책 삭제

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

사전 요구 사항

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

프로세스

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

    $ oc delete multi-networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
    Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한으로 웹 콘솔에 로그인하는 경우 YAML의 모든 네임스페이스에서 또는 Actions 메뉴를 통해 웹 콘솔의 정책에서 직접 네트워크 정책을 삭제할 수 있습니다.

23.4.3.6. 기본 거부 모든 다중 네트워크 정책 생성

이는 배포된 다른 네트워크 정책에서 허용하는 네트워크 트래픽 이외의 모든 교차 포드 네트워킹을 차단하는 기본 정책입니다. 이 절차에서는 기본 거부 정책을 적용합니다.

참고

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

사전 요구 사항

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

프로세스

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

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: deny-by-default
      namespace: default 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name> 
    2
    
    spec:
      podSelector: {} 
    3
    
      ingress: [] 
    4
    Copy to Clipboard Toggle word wrap
    1
    namespace: default 는 이 정책을 default 네임스페이스에 배포합니다.
    2
    network_name: 네트워크 연결 정의의 이름을 지정합니다.
    3
    podSelector: 비어 있습니다. 즉, 모든 Pod와 일치합니다. 따라서 이 정책은 default 네임스페이스의 모든 Pod에 적용됩니다.
    4
    Ingress 규칙이 지정되지 않았습니다. 이로 인해 들어오는 트래픽이 모든 Pod로 삭제됩니다.
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

deny-by-default 정책을 사용하여 외부 클라이언트에서 라벨이 app=web 인 Pod로의 트래픽을 허용하는 정책을 구성할 수 있습니다.

참고

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

다음 절차에 따라 공용 인터넷에서 직접 또는 Load Balancer를 사용하여 포드에 액세스할 수 있는 정책을 구성합니다. 트래픽은 app=web 레이블이 있는 Pod에만 허용됩니다.

사전 요구 사항

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

프로세스

  1. 공용 인터넷에서 직접 또는 로드 밸런서를 사용하여 포드에 액세스하는 방식으로 트래픽을 허용하는 정책을 생성합니다. web-allow-external.yaml 파일에 YAML을 저장합니다.

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-external
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      policyTypes:
      - Ingress
      podSelector:
        matchLabels:
          app: web
      ingress:
        - {}
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-external.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created
    Copy to Clipboard Toggle word wrap

이 정책은 다음 다이어그램에 설명된 대로 외부 트래픽을 포함하여 모든 리소스의 트래픽을 허용합니다.

참고

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

다음 절차에 따라 모든 네임스페이스의 모든 Pod에서 특정 애플리케이션으로의 트래픽을 허용하는 정책을 구성합니다.

사전 요구 사항

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

프로세스

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

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-all-namespaces
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector: {} 
    2
    Copy to Clipboard Toggle word wrap
    1
    정책을 기본 네임스페이스의 app:web Pod에만 적용합니다.
    2
    모든 네임스페이스에서 모든 Pod를 선택합니다.
    참고

    기본적으로 namespaceSelector 를 지정하지 않으면 정책이 네트워크 정책이 배포된 네임스페이스에서만 트래픽을 허용하는 네임스페이스를 선택하지 않습니다.

  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-all-namespaces.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 보조 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  3. 쉘에서 다음 명령을 실행하고 요청이 허용되는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

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

참고

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

다음 절차에 따라 특정 네임스페이스에서 app=web 레이블이 있는 Pod로의 트래픽을 허용하는 정책을 구성합니다. 다음을 수행할 수 있습니다.

  • 프로덕션 워크로드가 배포된 네임스페이스로만 트래픽을 제한합니다.
  • 특정 네임스페이스에 배포된 모니터링 툴을 활성화하여 현재 네임스페이스에서 지표를 스크랩할 수 있습니다.

사전 요구 사항

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

절차

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

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-prod
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production 
    2
    Copy to Clipboard Toggle word wrap
    1
    정책을 default 네임스페이스의 app:web Pod에만 적용합니다.
    2
    purpose=production 레이블이 있는 네임스페이스의 Pod로만 트래픽을 제한합니다.
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 prod 네임스페이스를 생성합니다.

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 dev 네임스페이스를 생성합니다.

    $ oc create namespace dev
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 dev 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/dev purpose=testing
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 dev 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  7. 쉘에서 다음 명령을 실행하고 요청이 차단되었는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

    wget: download timed out
    Copy to Clipboard Toggle word wrap

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

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  9. 쉘에서 다음 명령을 실행하고 요청이 허용되는지 확인합니다.

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

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

23.5. 추가 네트워크에 pod 연결

클러스터 사용자는 pod를 추가 네트워크에 연결할 수 있습니다.

23.5.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
      Copy to Clipboard Toggle word wrap
      1
      둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 
      1
      
                "namespace": "<namespace>", 
      2
      
                "default-route": ["<default-route>"] 
      3
      
              }
            ]
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음 예에서 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/network-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:
      ...
    Copy to Clipboard Toggle word wrap
    1
    k8s.v1.cni.cncf.io/network-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.
23.5.1.1. Pod별 주소 지정 및 라우팅 옵션 지정

추가 네트워크에 Pod를 연결할 때 특정 Pod에서 해당 네트워크에 대한 추가 속성을 지정할 수 있습니다. 이를 통해 라우팅의 일부 측면을 변경하고 고정 IP 주소 및 MAC 주소를 지정할 수 있습니다. 이를 위해 JSON 형식의 주석을 사용할 수 있습니다.

사전 요구 사항

  • Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

절차

주소 지정 및/또는 라우팅 옵션을 지정하는 동안 추가 네트워크에 Pod를 추가하려면 다음 단계를 완료하십시오.

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

    $ oc edit pod <name>
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    name 키는 Pod와 연결할 추가 네트워크의 이름입니다.
    2
    default-route 키는 라우팅 테이블에 다른 라우팅 항목이 없는 경우 트래픽이 라우팅될 게이트웨이 값을 지정합니다. default-route 키가 두 개 이상 지정되면 Pod가 활성화되지 않습니다.

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

중요

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

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

$ oc exec -it <pod_name> -- ip route
Copy to Clipboard Toggle word wrap
참고

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

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

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

    $ oc edit networks.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap

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

CNO(Cluster Network Operator) YAML 구성

name: <name> 
1

namespace: <namespace> 
2

rawCNIConfig: '{ 
3

  ...
}'
type: Raw
Copy to Clipboard Toggle word wrap

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"
    }]
}
Copy to Clipboard Toggle word wrap

1
생성할 추가 네트워크 연결의 이름을 지정합니다. 이름은 지정된 namespace 내에서 고유해야 합니다.
2
CNI 플러그인 구성의 배열을 지정합니다. 첫 번째 오브젝트는 macvlan 플러그인 구성을 지정하고 두 번째 오브젝트는 튜닝 플러그인 구성을 지정합니다.
3
CNI 플러그인 런타임 구성 기능의 고정 IP 주소 기능을 사용하도록 요청하도록 지정합니다.
4
macvlan 플러그인이 사용하는 인터페이스를 지정합니다.
5
CNI 플러그인의 정적 MAC 주소 기능을 사용하도록 요청하도록 지정합니다.

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

다음을 사용하여 Pod를 편집합니다.

$ oc edit pod <name>
Copy to Clipboard Toggle word wrap

고정 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

      }
    ]'
Copy to Clipboard Toggle word wrap

1
위의 rawCNIConfig를 구성하는 경우에는 제공되는 <name>을 사용해야 합니다.
2
서브넷 마스크를 포함하여 IP 주소를 제공합니다.
3
MAC 주소를 입력합니다.
참고

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

추가 네트워크가 있는 Pod의 IP 주소 및 MAC 속성을 확인하려면 oc 명령을 사용하여 Pod에서 ip 명령을 실행합니다.

$ oc exec -it <pod_name> -- ip a
Copy to Clipboard Toggle word wrap

23.6. 추가 네트워크에서 Pod 제거

클러스터 사용자는 추가 네트워크에서 Pod를 제거할 수 있습니다.

23.6.1. 추가 네트워크에서 Pod 제거

Pod를 삭제해야만 추가 네트워크에서 Pod를 제거할 수 있습니다.

사전 요구 사항

  • Pod에 추가 네트워크가 연결되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.

절차

  • Pod를 삭제하려면 다음 명령을 입력합니다.

    $ oc delete pod <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
    • <name>은 Pod의 이름입니다.
    • <namespace>는 Pod가 포함된 네임스페이스입니다.

23.7. 추가 네트워크 편집

클러스터 관리자는 기존 추가 네트워크의 구성을 수정할 수 있습니다.

23.7.1. 추가 네트워크 연결 정의 수정

클러스터 관리자는 기존 추가 네트워크를 변경할 수 있습니다. 추가 네트워크에 연결된 기존 Pod는 업데이트되지 않습니다.

사전 요구 사항

  • 클러스터에 추가 네트워크가 구성되어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

클러스터의 추가 네트워크를 편집하려면 다음 단계를 완료하십시오.

  1. 기본 텍스트 편집기에서 CNO(Cluster Network Operator) CR을 편집하려면 다음 명령을 실행합니다.

    $ oc edit networks.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap
  2. additionalNetworks 컬렉션에서 변경 내용으로 추가 네트워크를 업데이트합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. 선택 사항: CNO에서 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 업데이트했는지 확인합니다. <network-name>을 표시할 추가 네트워크의 이름으로 변경합니다. CNO가 변경 사항을 반영하기 위해서 NetworkAttachmentDefinition 오브젝트를 업데이트하기 전에 지연이 발생할 수 있습니다.

    $ oc get network-attachment-definitions <network-name> -o yaml
    Copy to Clipboard Toggle word wrap

    예를 들어, 다음 콘솔 출력은 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"]}} }
    Copy to Clipboard Toggle word wrap

23.8. 추가 네트워크 제거

클러스터 관리자는 추가 네트워크의 연결을 제거할 수 있습니다.

23.8.1. 추가 네트워크 연결 정의 제거

클러스터 관리자는 OpenShift Container Platform 클러스터에서 추가 네트워크를 제거할 수 있습니다. 추가 네트워크는 연결된 Pod에서 제거되지 않습니다.

사전 요구 사항

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

절차

클러스터에서 추가 네트워크를 제거하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 기본 텍스트 편집기에서 CNO(Cluster Network Operator)를 편집합니다.

    $ oc edit networks.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap
  2. 제거할 네트워크 연결 정의에 대한 additionalNetworks 컬렉션에서 구성을 제거하여 CR을 수정합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: [] 
    1
    Copy to Clipboard Toggle word wrap
    1
    additionalNetworks 컬렉션에서 유일한 추가 네트워크 첨부 파일 정의에 대한 구성 매핑을 제거하는 경우 빈 컬렉션을 지정해야 합니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
  4. 선택 사항: 추가 네트워크 CR이 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get network-attachment-definition --all-namespaces
    Copy to Clipboard Toggle word wrap

23.9. VRF에 보조 네트워크 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 가상 라우팅 및 전달(VRF) 도메인에 대한 추가 네트워크를 구성할 수 있습니다. 이 플러그인이 생성하는 가상 네트워크는 사용자가 지정하는 물리적 인터페이스와 연결됩니다.

VRF 인스턴스에서 보조 네트워크를 사용하면 다음과 같은 이점이 있습니다.

워크로드 격리
추가 네트워크에 대한 VRF 인스턴스를 구성하여 워크로드 트래픽을 분리합니다.
보안 개선
VRF 도메인의 격리된 네트워크 경로를 통해 보안을 강화합니다.
멀티 테넌시 지원
각 테넌트에 대해 VRF 도메인의 고유한 라우팅 테이블을 사용하여 네트워크 분할을 통해 멀티 테넌시를 지원합니다.
참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE 옵션은 소켓을 전달된 인터페이스 이름(예: eth1 )에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE 옵션을 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

23.9.1. CNI VRF 플러그인으로 추가 네트워크 연결 생성

CNO(Cluster Network Operator)는 추가 네트워크 정의를 관리합니다. 생성할 추가 네트워크를 지정하면 CNO가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

CNO가 관리하는 NetworkAttachmentDefinition CR을 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

CNI VRF 플러그인으로 추가 네트워크 연결을 생성하려면 다음 절차를 수행하십시오.

사전 요구 사항

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

절차

  1. 추가 Network 연결에 사용할 네트워크 CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 추가 네트워크의 rawCNIConfig 구성을 삽입합니다. YAML을 additional-network-attachment.yaml 파일로 저장합니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks:
        - name: test-network-1
          namespace: additional-network-1
          type: Raw
          rawCNIConfig: '{
            "cniVersion": "0.3.1",
            "name": "macvlan-vrf",
            "plugins": [  
    1
    
            {
              "type": "macvlan",
              "master": "eth1",
              "ipam": {
                  "type": "static",
                  "addresses": [
                  {
                      "address": "191.168.1.23/24"
                  }
                  ]
              }
            },
            {
              "type": "vrf", 
    2
    
              "vrfname": "vrf-1",  
    3
    
              "table": 1001   
    4
    
            }]
          }'
    Copy to Clipboard Toggle word wrap
    1
    plugins는 목록이어야 합니다. 목록의 첫 번째 항목은 VRF 네트워크를 기반으로 하는 보조 네트워크여야 합니다. 목록의 두 번째 항목은 VRF 플러그인 구성입니다.
    2
    typevrf로 설정해야 합니다.
    3
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
    4
    선택 사항: table은 라우팅 테이블 ID입니다. 기본적으로 tableid 매개변수가 사용됩니다. 지정하지 않으면 CNI에서 무료 라우팅 테이블 ID를 VRF에 할당합니다.
    참고

    VRF는 리소스의 유형이 netdevice인 경우에만 올바르게 작동합니다.

  2. Network 리소스를 생성합니다.

    $ oc create -f additional-network-attachment.yaml
    Copy to Clipboard Toggle word wrap
  3. CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다. <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-network-1)로 바꿉니다.

    $ oc get network-attachment-definitions -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       AGE
    additional-network-1       14m
    Copy to Clipboard Toggle word wrap

    참고

    CNO가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

검증

  1. pod를 생성하고 VRF 인스턴스를 사용하여 추가 네트워크에 할당합니다.

    1. Pod 리소스를 정의하는 YAML 파일을 생성합니다.

      pod-additional-net.yaml 파일 예

      apiVersion: v1
      kind: Pod
      metadata:
       name: pod-additional-net
       annotations:
         k8s.v1.cni.cncf.io/networks: '[
             {
                     "name": "test-network-1" 
      1
      
             }
       ]'
      spec:
       containers:
       - name: example-pod-1
         command: ["/bin/bash", "-c", "sleep 9000000"]
         image: centos:8
      Copy to Clipboard Toggle word wrap

      1
      VRF 인스턴스를 사용하여 추가 네트워크의 이름을 지정합니다.
    2. 다음 명령을 실행하여 Pod 리소스를 생성합니다.

      $ oc create -f pod-additional-net.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      pod/test-pod created
      Copy to Clipboard Toggle word wrap

  2. 포드 네트워크 연결이 VRF 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 세션을 시작하고 다음 명령을 실행합니다.

    $ ip vrf show
    Copy to Clipboard Toggle word wrap

    출력 예

    Name              Table
    -----------------------
    vrf-1             1001
    Copy to Clipboard Toggle word wrap

  3. VRF 인터페이스가 추가 인터페이스의 컨트롤러인지 확인합니다.

    $ ip link
    Copy to Clipboard Toggle word wrap

    출력 예

    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    Copy to Clipboard Toggle word wrap

24장. 하드웨어 네트워크

24.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 드라이버: 컨테이너에 마운트된 문자 장치

높은 대역폭 또는 짧은 대기 시간이 필요한 애플리케이션에 대해 베어 메탈 또는 RHOSP(Red Hat OpenStack Platform) 인프라에 설치된 OpenShift Container Platform 클러스터에 추가 네트워크와 함께 SR-IOV 네트워크 장치를 사용할 수 있습니다.

SR-IOV 네트워크에 대한 다중 네트워크 정책을 구성할 수 있습니다. 이에 대한 지원은 기술 프리뷰이며 SR-IOV 추가 네트워크는 커널 NIC에서만 지원됩니다. DPDK(Data Plane Development Kit) 애플리케이션에서는 지원되지 않습니다.

참고

SR-IOV 네트워크에서 다중 네트워크 정책을 생성하면 다중 네트워크 정책이 구성되지 않은 SR-IOV 네트워크와 비교하여 애플리케이션에 동일한 성능을 제공하지 못할 수 있습니다.

중요

SR-IOV 네트워크의 다중 네트워크 정책은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음 명령을 사용하여 노드에서 SR-IOV를 활성화할 수 있습니다.

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
Copy to Clipboard Toggle word wrap

24.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 네트워크 Operator가 시작될 때 작업자 노드에 배포되는 데몬 세트입니다. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
SR-IOV 네트워크 Operator webhook
Operator 사용자 정의 리소스의 유효성을 검증하고 설정되지 않은 필드에 적절한 기본값을 설정하는 동적 승인 컨트롤러 webhook.
SR-IOV 네트워크 리소스 인젝터
SR-IOV VF와 같은 사용자 정의 네트워크 리소스에 대한 요청 및 제한으로 Kubernetes pod 사양을 패치하는 기능을 제공하는 동적 승인 컨트롤러 webhook. SR-IOV 네트워크 리소스 인젝터는 Pod의 첫 번째 컨테이너에만 리소스 필드를 자동으로 추가합니다.
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을 편집하여 비활성화할 수 있습니다. SR-IOV Network Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다.

24.1.1.1. 지원되는 플랫폼

SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.

  • 베어 메탈
  • Red Hat OpenStack Platform (RHOSP)
24.1.1.2. 지원되는 장치

OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.

Expand
표 24.1. 지원되는 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

Broadcom

BCM57414

14e4

16d7

Broadcom

BCM57508

14e4

1750

Broadcom

BCM57504

14e4

1751

Intel

X710

8086

1572

Intel

XL710

8086

1583

Intel

X710 Base T

8086

15FF

Intel

XXV710

8086

158b

Intel

E810-CQDA2

8086

1592

Intel

E810-2CQDA2

8086

1592

Intel

E810-XXVDA2

8086

159b

Intel

E810-XXVDA4

8086

1593

Intel

E810-XXVDA4T

8086

1593

Mellanox

MT27700 제품군 [ConnectX-4]

15b3

1013

Mellanox

MT27710 제품군 [ConnectX-4 Lx]

15b3

1015

Mellanox

MT27800 제품군 [ConnectX-5]

15b3

1017

Mellanox

MT28880 제품군 [ConnectX-5 Ex]

15b3

1019

Mellanox

MT28908 제품군 [ConnectX-6]

15b3

101b

Mellanox

MT2892 제품군 [ConnectX-6 Dx]

15b3

101d

Mellanox

MT2894 제품군 [ConnectX-6 Lx]

15b3

101f

Mellanox

MT42822 ConnectX-6 NIC 모드 BlueField-2

15b3

a2d6

Pensando [1]

ECDHE-25 ionic 드라이버용 듀얼 포트 25G 분산 서비스 카드

0x1dd8

0x1002

Pensando [1]

ECDHE-100 듀얼 포트 100G 분산 서비스 카드 (ionic 드라이버용)

0x1dd8

0x1003

Silicom

STS 제품군

8086

1591

  1. OpenShift SR-IOV는 지원되지만 SR-IOV를 사용할 때 SR-IOV CNI 구성 파일을 사용하여 고정 VF(가상 기능) 미디어 액세스 제어(MAC) 주소를 설정해야 합니다.
참고

지원되는 카드 및 호환 가능한 OpenShift Container Platform 버전의 최신 목록은 Openshift Single Root I/O Virtualization (SR-IOV) 및 PTP 하드웨어 네트워크 지원 매트릭스 를 참조하십시오.

24.1.1.3. SR-IOV 네트워크 장치의 자동 검색

SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.

중요

SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.

24.1.1.3.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
Copy to Clipboard Toggle word wrap

1
name 필드의 값은 작업자 노드의 이름과 동일합니다.
2
인터페이스 스탠자에는 작업자 노드에서 Operator가 감지한 모든 SR-IOV 장치 목록이 포함되어 있습니다.
24.1.1.4. 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:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]
Copy to Clipboard Toggle word wrap

다음 예는 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:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    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
Copy to Clipboard Toggle word wrap

24.1.1.5. 컨테이너 애플리케이션에서 사용하는 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이 포함되어 있습니다. 컨테이너 이미지는 pod 사양의 환경 변수에 따라 다음 DPDK 샘플 애플리케이션 중 하나를 실행할 수 있습니다. l2fwd,l3wd 또는 testpmd. 컨테이너 이미지는 app-netutil 라이브러리를 컨테이너 이미지 자체에 통합하는 예를 제공합니다. 라이브러리는 init 컨테이너에 통합할 수도 있습니다. init 컨테이너는 필요한 데이터를 수집하고 기존 DPDK 워크로드에 데이터를 전달할 수 있습니다.

24.1.1.6. 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> 접미사로 종료할 수 있습니다.

24.1.3. 다음 단계

24.2. SR-IOV Network Operator 설치

SR-IOV(Single Root I/O Virtualization) Network Operator를 클러스터에 설치하여 SR-IOV 네트워크 장치 및 네트워크 연결을 관리할 수 있습니다.

24.2.1. SR-IOV Network Operator 설치

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

24.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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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)
      Copy to Clipboard Toggle word wrap
    2. SR-IOV Network Operator에 대한 서브스크립션 CR을 만들려면 다음 명령을 입력합니다.

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

    $ oc get csv -n openshift-sriov-network-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    출력 예

    Name                                         Phase
    sriov-network-operator.4.13.0-202310121402   Succeeded
    Copy to Clipboard Toggle word wrap

24.2.1.2. 웹 콘솔 : SR-IOV Network Operator 설치

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

사전 요구 사항

  • SR-IOV를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 계정.

프로세스

  1. SR-IOV Network Operator 설치:

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 SR-IOV Network Operator를 선택한 다음 설치를 클릭합니다.
    3. Operator 설치 페이지의 설치된 네임스페이스 에서 Operator 권장 네임스페이스 를 선택합니다.
    4. 설치를 클릭합니다.
  2. 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 로그를 확인하십시오.
      • YAML 파일의 네임스페이스를 확인합니다. 주석이 없는 경우 다음 명령을 사용하여 workload.openshift.io/allowed=management 주석을 Operator 네임스페이스에 추가할 수 있습니다.

        $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        참고

        단일 노드 OpenShift 클러스터의 경우 네임스페이스에 주석 workload.openshift.io/allowed=management 가 필요합니다.

24.2.2. 다음 단계

24.3. SR-IOV Network Operator 구성

SR-IOV(Single Root I/O Virtualization) Network Operator는 클러스터의 SR-IOV 네트워크 장치 및 네트워크 첨부 파일을 관리합니다.

24.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을 수정해야 합니다.

24.3.1.1. SR-IOV Network Operator 구성 사용자 정의 리소스

sriovoperatorconfig 사용자 정의 리소스의 필드는 다음 표에 설명되어 있습니다.

Expand
표 24.2. SR-IOV Network Operator 구성 사용자 정의 리소스
필드유형설명

metadata.name

string

SR-IOV Network Operator 인스턴스의 이름을 지정합니다. 기본값은 default입니다. 다른 값을 설정하지 마십시오.

metadata.namespace

string

SR-IOV Network Operator 인스턴스의 네임스페이스를 지정합니다. 기본값은 openshift-sriov-network-operator 입니다. 다른 값을 설정하지 마십시오.

spec.configDaemonNodeSelector

string

선택한 노드에서 SR-IOV Network Config Daemon 예약을 제어하기 위해 노드 선택을 지정합니다. 기본적으로 이 필드가 설정되지 않고 Operator는 작업자 노드에 SR-IOV Network Config 데몬 세트를 배포합니다.

spec.disableDrain

boolean

새 정책을 적용하여 노드에서 NIC를 구성할 때 노드 드레이닝 프로세스를 비활성화하거나 노드 드레이닝 프로세스를 활성화할지 여부를 지정합니다. 이 필드를 true 로 설정하면 소프트웨어 개발 및 단일 노드에 OpenShift Container Platform을 쉽게 설치할 수 있습니다. 기본적으로 이 필드는 설정되어 있지 않습니다.

단일 노드 클러스터의 경우 Operator를 설치한 후 이 필드를 true 로 설정합니다. 이 필드는 true 로 설정되어야 합니다.

spec.enableInjector

boolean

Network Resources Injector 데몬 세트를 활성화하거나 비활성화할지 여부를 지정합니다. 기본적으로 이 필드는 true 로 설정됩니다.

spec.enableOperatorWebhook

boolean

Operator Admission Controller 웹 후크 데몬 세트를 활성화하거나 비활성화할지 여부를 지정합니다. 기본적으로 이 필드는 true 로 설정됩니다.

spec.logLevel

integer

Operator의 로그 세부 정보 표시 수준을 지정합니다. 기본 로그만 표시하려면 0 으로 설정합니다. 사용 가능한 모든 로그를 표시하려면 2 로 설정합니다. 기본적으로 이 필드는 2 로 설정됩니다.

24.3.1.2. Network Resources Injector 정보

Network Resources Injector는 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

  • SR-IOV 네트워크 연결 정의 주석에 따라 SR-IOV 리소스 이름을 추가하기 위해 Pod 사양의 리소스 요청 및 제한 변경
  • Pod 사양을 Downward API 볼륨으로 변경하여 Pod 주석, 라벨 및 대규모 페이지 요청 및 제한을 노출합니다. pod에서 실행되는 컨테이너는 /etc/podnetinfo 경로에 있는 파일로 노출된 정보에 액세스할 수 있습니다.

기본적으로 Network Resources Injector는 SR-IOV Network Operator에 의해 활성화되며 모든 컨트롤 플레인 노드에서 데몬 세트로 실행됩니다. 다음은 3개의 컨트롤 플레인 노드가 있는 클러스터에서 실행 중인 Network Resources Injector Pod의 예입니다.

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

출력 예

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
Copy to Clipboard Toggle word wrap

24.3.1.3. SR-IOV 네트워크 Operator Admission Controller webhook 정보

SR-IOV 네트워크 Operator Admission Controller webhook은 Kubernetes Dynamic Admission Controller 애플리케이션입니다. 다음과 같은 기능을 제공합니다.

  • SriovNetworkNodePolicy CR이 생성 또는 업데이트될 때 유효성 검사
  • CR을 만들거나 업데이트할 때 prioritydeviceType 필드의 기본값을 설정하여 SriovNetworkNodePolicy CR 변경

기본적으로 SR-IOV 네트워크 Operator Admission Controller 웹 후크는 Operator에서 활성화하며 모든 컨트롤 플레인 노드에서 데몬 세트로 실행됩니다.

참고

SR-IOV Network Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다. 지원되지 않는 장치 구성에 대한 자세한 내용은 지원되지 않는 NIC를 사용하도록 SR-IOV Network Operator 구성을 참조하십시오.

다음은 3개의 컨트롤 플레인 노드가 있는 클러스터에서 실행되는 Operator Admission Controller 웹 후크 Pod의 예입니다.

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

출력 예

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
Copy to Clipboard Toggle word wrap

24.3.1.4. 사용자 정의 노드 선택기 정보

SR-IOV Network Config 데몬은 클러스터 노드에서 SR-IOV 네트워크 장치를 검색하고 구성합니다. 기본적으로 클러스터의 모든 worker 노드에 배포됩니다. 노드 레이블을 사용하여 SR-IOV Network Config 데몬이 실행되는 노드를 지정할 수 있습니다.

24.3.1.5. 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> } }'
    Copy to Clipboard Toggle word wrap
    작은 정보

    또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: <value>
    Copy to Clipboard Toggle word wrap

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> } }'
    Copy to Clipboard Toggle word wrap
    작은 정보

    또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableOperatorWebhook: <value>
    Copy to Clipboard Toggle word wrap
24.3.1.7. 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>}
        }]'
    Copy to Clipboard Toggle word wrap

    "node-role.kubernetes.io/worker": ""에서와 같이 적용하려면 <node_label>을 레이블로 바꿉니다.

    작은 정보

    또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        <node_label>
    Copy to Clipboard Toggle word wrap
24.3.1.8. 단일 노드 설치를 위해 SR-IOV Network Operator 구성

기본적으로 SR-IOV Network Operator는 모든 정책이 변경되기 전에 노드에서 워크로드를 드레인합니다. Operator는 이 작업을 수행하여 재구성 전에 가상 기능을 사용하는 워크로드가 없는지 확인합니다.

단일 노드에 설치하는 경우 워크로드를 수신할 다른 노드가 없습니다. 결과적으로 Operator는 단일 노드에서 워크로드를 드레이닝하지 않도록 구성해야 합니다.

중요

드레이닝 워크로드를 비활성화하기 위해 다음 절차를 수행한 후 SR-IOV 네트워크 인터페이스를 사용하는 워크로드를 제거한 후 SR-IOV 네트워크 노드 정책을 변경해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • SR-IOV Network Operator가 설치되어 있어야 합니다.

프로세스

  • disableDrain 필드를 true 로 설정하려면 다음 명령을 입력합니다.

    $ oc patch sriovoperatorconfig default --type=merge \
      -n openshift-sriov-network-operator \
      --patch '{ "spec": { "disableDrain": true } }'
    Copy to Clipboard Toggle word wrap
    작은 정보

    또는 다음 YAML을 적용하여 Operator를 업데이트할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      disableDrain: true
    Copy to Clipboard Toggle word wrap
24.3.1.9. 호스트 컨트롤 플레인에 대한 SR-IOV Operator 배포
중요

호스트 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

호스팅 서비스 클러스터를 구성하고 배포한 후 호스팅 클러스터에서 SR-IOV Operator에 대한 서브스크립션을 생성할 수 있습니다. SR-IOV Pod는 컨트롤 플레인이 아닌 작업자 머신에서 실행됩니다.

사전 요구 사항

AWS에 호스팅 클러스터를 구성하고 배포해야 합니다. 자세한 내용은 AWS에서 호스팅 클러스터 구성 (기술 프리뷰) 을 참조하십시오.

프로세스

  1. 네임스페이스 및 Operator 그룹을 생성합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap
  2. SR-IOV Operator에 대한 서브스크립션을 생성합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subsription
      namespace: openshift-sriov-network-operator
    spec:
      channel: "4.13"
      name: sriov-network-operator
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: ""
      source: s/qe-app-registry/redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

검증

  1. SR-IOV Operator가 준비되었는지 확인하려면 다음 명령을 실행하고 결과 출력을 확인합니다.

    $ oc get csv -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
    sriov-network-operator.4.13.0-202211021237   SR-IOV Network Operator   4.13.0-202211021237   sriov-network-operator.4.13.0-202210290517   Succeeded
    Copy to Clipboard Toggle word wrap

  2. SR-IOV Pod가 배포되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

24.3.2. 다음 단계

24.4. SR-IOV 네트워크 장치 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.

24.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

  needVhostNet: false 
7

  numVfs: <num> 
8

  nicSelector: 
9

    vendor: "<vendor_code>" 
10

    deviceID: "<device_id>" 
11

    pfNames: ["<pf_name>", ...] 
12

    rootDevices: ["<pci_bus_id>", ...] 
13

    netFilter: "<filter_string>" 
14

  deviceType: <device_type> 
15

  isRdma: false 
16

  linkType: <link_type> 
17

  eSwitchMode: <mode> 
18

  excludeTopology: false 
19
Copy to Clipboard Toggle word wrap
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.

이름을 지정할 때 resourceName 에 허용되는 구문 표현식 ^[a-zA-Z0-9_]+$ 를 사용해야 합니다.

4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.
중요

SR-IOV Network Operator는 노드 네트워크 구성 정책을 순서대로 노드에 적용합니다. 노드 네트워크 구성 정책을 적용하기 전에 SR-IOV Network Operator는 노드의 MCP(Machine config pool)가 Degraded 또는 Update와 같은 비정상적인 상태에 있는지 확인합니다. 노드가 비정상 MCP에 있는 경우 MCP가 정상 상태로 돌아올 때까지 클러스터의 모든 대상 노드에 노드 네트워크 구성 정책을 적용하는 프로세스입니다.

비정상 MCP의 노드가 다른 MCP의 노드를 포함하여 다른 노드에 대한 노드 네트워크 구성 정책의 애플리케이션을 차단하지 않도록 하려면 각 MCP에 대한 별도의 노드 네트워크 구성 정책을 생성해야 합니다.

5
선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
6
선택사항: 가상 기능의 최대 전송 단위(MTU)입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.
중요

기본 네트워크 인터페이스에서 가상 기능을 생성하려면 MTU가 클러스터 MTU와 일치하는 값으로 설정되어 있는지 확인합니다.

7
선택 사항: pod에 /dev/vhost-net 장치를 마운트하려면 needVhostNettrue로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된 /dev/vhost-net 장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다.
8
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.
9
NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.

10
선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 허용되는 값은 808615b3입니다.
11
선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다. 예를 들어 101b는 Mellanox ConnectX-6 장치의 장치 ID입니다.
12
선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
13
선택 사항: 장치의 PF에 대해 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 주소를 0000:02: 00.1 형식으로 입력합니다.
14
선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다.
15
선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevicevfio-pci입니다. 기본값은 netdevice입니다.

베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면 netdevice 드라이버 유형을 사용하고 isRdmatrue로 설정합니다.

16
선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다.

isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.

isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.

참고

intel NIC의 경우 isRdma 매개변수를 true 로 설정할 수 없습니다.

17
선택사항: VF의 링크 유형입니다. 기본값은 eth 이더넷입니다. 이 값을 InfiniBand의 'ib'로 변경합니다.

linkTypeib로 설정하면 isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로 true로 설정됩니다. linkTypeib로 설정하면 deviceTypevfio-pci로 설정해서는 안 됩니다.

SriovNetworkNodePolicy에 대해 linkType을 'eth'로 설정하지 마십시오. 장치 플러그인에서 보고한 사용 가능한 장치가 잘못된 수 있기 때문입니다.

18
선택사항: NIC 장치 모드입니다. 허용되는 유일한 값은 legacy 또는 switchdev 입니다.

eSwitchModelegacy 로 설정되면 기본 SR-IOV 동작이 활성화됩니다.

eSwitchModeswitchdev 로 설정되면 하드웨어 오프로드가 활성화됩니다.

19
선택 사항: SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을 true 로 설정합니다. 기본값은 false입니다.
24.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
Copy to Clipboard Toggle word wrap

다음 예제에서는 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
Copy to Clipboard Toggle word wrap

1
가상 머신에 대한 노드 네트워크 정책을 구성할 때 numVfs 필드는 항상 1로 설정됩니다.
2
가상 머신이 RHOSP에 배포될 때 netFilter 필드는 네트워크 ID를 참조해야 합니다. netFilter의 유효한 값은 SriovNetworkNodeState 오브젝트에서 사용할 수 있습니다.
24.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"]
Copy to Clipboard Toggle word wrap
  • 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
Copy to Clipboard Toggle word wrap

정책 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
Copy to Clipboard Toggle word wrap

인터페이스가 성공적으로 분할되었는지 확인

다음 명령을 실행하여 SR-IOV 장치의 VF(가상 기능)로 분할된 인터페이스가 있는지 확인합니다.

$ ip link show <interface> 
1
Copy to Clipboard Toggle word wrap
1
& lt;interface >를 SR-IOV 장치의 VF로 분할할 때 지정한 인터페이스로 바꿉니다(예: ens3f1 ).

출력 예

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
Copy to Clipboard Toggle word wrap

24.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>을 이 구성의 이름으로 바꿉니다.
  2. 선택 사항: SriovNetworkNodePolicy.Spec.NodeSelector 를 사용하여 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드에 레이블 지정에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오.
  3. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f <name>-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    <name>은 이 구성의 이름을 지정합니다.

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.

  4. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

24.4.3. SR-IOV 구성 문제 해결

SR-IOV 네트워크 장치를 구성하는 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 다룹니다.

노드 상태를 표시하려면 다음 명령을 실행합니다.

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
Copy to Clipboard Toggle word wrap

여기서 <node_name>은 SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.

오류 출력 : 메모리를 할당할 수 없음

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"
Copy to Clipboard Toggle word wrap

노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.

  • 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
  • BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.

24.4.4. SR-IOV 네트워크를 VRF에 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.

이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

24.4.4.1. CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결 생성

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결을 생성하려면 다음 절차를 수행합니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

절차

  1. 추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.

    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
    
        }
    Copy to Clipboard Toggle word wrap
    1
    typevrf로 설정해야 합니다.
    2
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-sriov-network-1)로 바꿉니다.

    출력 예

    NAME                            AGE
    additional-sriov-network-1      14m
    Copy to Clipboard Toggle word wrap

    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.

    $ ip vrf show
    Copy to Clipboard Toggle word wrap

    출력 예

    Name              Table
    -----------------------
    red                 10
    Copy to Clipboard Toggle word wrap

  4. VRF 인터페이스가 보조 인터페이스의 마스터인지 확인합니다.

    $ ip link
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    ...
    Copy to Clipboard Toggle word wrap

24.4.5. NUMA 인식 스케줄링의 SR-IOV 네트워크 토폴로지 제외

SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 알리면 NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 제외할 수 있습니다.

일부 시나리오에서는 단일 NUMA 노드에서 Pod의 CPU 및 메모리 리소스를 최대화하는 것이 우선 순위입니다. 토폴로지 관리자는 Pod의 SR-IOV 네트워크 리소스에 대한 NUMA 노드에 대한 힌트를 제공하지 않기 때문에 토폴로지 관리자는 SR-IOV 네트워크 리소스 및 Pod CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. NUMA 노드 간 데이터 전송으로 인해 네트워크 대기 시간에 추가할 수 있습니다. 그러나 워크로드에 최적의 CPU 및 메모리 성능이 필요한 경우에는 이 기능이 허용됩니다.

예를 들어 numa0numa1 이라는 두 개의 NUMA 노드가 있는 컴퓨팅 노드인 compute-1 을 고려해 보십시오. SR-IOV 지원 NIC는 numa0 에 있습니다. Pod 예약에 사용 가능한 CPU는 numa1 에만 있습니다. Topology Manager는 excludeTopology 사양을 true 로 설정하여 Pod의 CPU 및 메모리 리소스를 numa1 에 할당할 수 있으며 동일한 pod의 SR-IOV 네트워크 리소스를 numa0 에 할당할 수 있습니다. 이는 excludeTopology 사양을 true 로 설정한 경우에만 가능합니다. 그렇지 않으면 토폴로지 관리자가 동일한 NUMA 노드에 모든 리소스를 배치하려고 합니다.

24.4.5.1. NUMA 인식 스케줄링을 위한 SR-IOV 네트워크 토폴로지 제외

SR-IOV 네트워크 리소스의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자로 알리기 위해 SriovNetworkNodePolicy 사용자 정의 리소스에서 excludeTopology 사양을 구성할 수 있습니다. NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 위해 이 구성을 사용합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • CPU 관리자 정책을 static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오.
  • 토폴로지 관리자 정책을 single-numa-node로 구성했습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.

프로세스

  1. SriovNetworkNodePolicy CR을 생성합니다.

    1. 다음 YAML을 sriov-network-node-policy.yaml 파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: <policy_name>
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 
      1
      
        nodeSelector:
          kubernetes.io/hostname: <node_name>
        numVfs: <number_of_Vfs>
        nicSelector: 
      2
      
          vendor: "<vendor_ID>"
          deviceID: "<device_ID>"
        deviceType: netdevice
        excludeTopology: true 
      3
      Copy to Clipboard Toggle word wrap
      1
      SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      2
      NIC 선택기를 사용하여 Operator가 구성할 장치를 식별합니다.
      3
      SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을 true 로 설정합니다. 기본값은 false입니다.
      참고

      여러 SriovNetworkNodePolicy 리소스가 동일한 SR-IOV 네트워크 리소스를 대상으로 하는 경우 SriovNetworkNodePolicy 리소스에 excludeTopology 사양과 동일한 값이 있어야 합니다. 그러지 않으면 충돌하는 정책이 거부됩니다.

    2. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 생성합니다.

      $ oc create -f sriov-network-node-policy.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
      Copy to Clipboard Toggle word wrap

  2. SriovNetwork CR을 생성합니다.

    1. 다음 YAML을 sriov-network.yaml 파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriov-numa-0-network 
      1
      
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 
      2
      
        networkNamespace: <namespace> 
      3
      
        ipam: |- 
      4
      
          {
            "type": "<ipam_type>",
          }
      Copy to Clipboard Toggle word wrap
      1
      sriov-numa-0-network 를 SR-IOV 네트워크 리소스의 이름으로 교체합니다.
      2
      이전 단계의 SriovNetworkNodePolicy CR의 리소스 이름을 지정합니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      3
      SR-IOV 네트워크 리소스의 네임스페이스를 입력합니다.
      4
      SR-IOV 네트워크의 IP 주소 관리 구성을 입력합니다.
    2. 다음 명령을 실행하여 SriovNetwork 리소스를 생성합니다.

      $ oc create -f sriov-network.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
      Copy to Clipboard Toggle word wrap

  3. Pod를 생성하고 이전 단계의 SR-IOV 네트워크 리소스를 할당합니다.

    1. 다음 YAML을 sriov-network-pod.yaml 파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.

      apiVersion: v1
      kind: Pod
      metadata:
        name: <pod_name>
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "sriov-numa-0-network", 
      1
      
              }
            ]
      spec:
        containers:
        - name: <container_name>
          image: <image>
          imagePullPolicy: IfNotPresent
          command: ["sleep", "infinity"]
      Copy to Clipboard Toggle word wrap
      1
      SriovNetworkNodePolicy 리소스를 사용하는 SriovNetwork 리소스의 이름입니다.
    2. 다음 명령을 실행하여 Pod 리소스를 생성합니다.

      $ oc create -f sriov-network-pod.yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      pod/example-pod created
      Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 Pod의 상태를 확인하고 < pod_name> 을 Pod 이름으로 교체합니다.

    $ oc get pod <pod_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS   AGE
    test-deployment-sriov-76cbbf4756-k9v72   1/1     Running   0          45h
    Copy to Clipboard Toggle word wrap

  2. 대상 Pod로 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 Pod로 디버그 세션을 열고 <pod_name>을 대상 Pod 이름으로 교체합니다.

      $ oc debug pod/<pod_name>
      Copy to Clipboard Toggle word wrap
    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.

      $ chroot /host
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하여 CPU 할당에 대한 정보를 확인합니다.

      $ lscpu | grep NUMA
      Copy to Clipboard Toggle word wrap

      출력 예

      NUMA node(s):                    2
      NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,...
      NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,...
      Copy to Clipboard Toggle word wrap

      $ cat /proc/self/status | grep Cpus
      Copy to Clipboard Toggle word wrap

      출력 예

      Cpus_allowed:	aa
      Cpus_allowed_list:	1,3,5,7
      Copy to Clipboard Toggle word wrap

      $ cat  /sys/class/net/net1/device/numa_node
      Copy to Clipboard Toggle word wrap

      출력 예

      0
      Copy to Clipboard Toggle word wrap

      이 예에서 CPU 1,3,5, 7은 NUMA node1 에 할당되지만 SR-IOV 네트워크 리소스는 NUMA node0 의 NIC를 사용할 수 있습니다.

참고

excludeTopology 사양이 True 로 설정된 경우 필요한 리소스가 동일한 NUMA 노드에 존재할 수 있습니다.

24.4.6. 다음 단계

24.5. SR-IOV 이더넷 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.

24.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
Copy to Clipboard Toggle word wrap
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 주소 지원을 활성화할 수 있습니다.
24.5.1.1. 추가 네트워크의 IP 주소 할당 구성

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
24.5.1.1.1. 고정 IP 주소 할당 구성

다음 표에서는 고정 IP 주소 할당 구성을 설명합니다.

Expand
표 24.3. IPAM 정적 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 정적 값이 필요합니다.

addresses

array

가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

Pod 내부에서 구성할 경로를 지정하는 오브젝트 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 어레이에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand
표 24.4. ipam.addresses[] array
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand
표 24.5. IPAM.routes[] 배열
필드유형설명

dst

string

CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 192.168.17.0/24 또는 0.0.0.0/0 )입니다.

gw

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand
표 24.6. IPAM.dns 오브젝트
필드유형설명

nameservers

array

DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}
Copy to Clipboard Toggle word wrap

24.5.1.1.2. DHCP(Dynamic 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"
        }
      }
  # ...
Copy to Clipboard Toggle word wrap

Expand
표 24.7. IPAM DHCP 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. dhcp 값이 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}
Copy to Clipboard Toggle word wrap

24.5.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand
표 24.8. IPAM: 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 필요한 경우 값을 가져옵니다 . Gets the value whereabouts.

범위

string

CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}
Copy to Clipboard Toggle word wrap

24.5.2. SR-IOV 추가 네트워크 구성

SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 오브젝트를 생성하면 SR-IOV Network 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"
        }
    Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택사항: 이전 단계에서 생성한 SriovNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>
    Copy to Clipboard Toggle word wrap

24.5.3. 다음 단계

24.6. SR-IOV InfiniBand 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 IB(InfiniBand) 네트워크 연결을 구성할 수 있습니다.

24.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
Copy to Clipboard Toggle word wrap
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 }"를 지정하면 됩니다.
24.6.1.1. 추가 네트워크의 IP 주소 할당 구성

IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인은 다른 CNI 플러그인에 대한 IP 주소를 제공합니다.

다음 IP 주소 할당 유형을 사용할 수 있습니다.

  • 정적 할당
  • DHCP 서버를 통한 동적 할당. 지정한 DHCP 서버는 추가 네트워크에서 연결할 수 있어야 합니다.
  • Whereabouts IPAM CNI 플러그인을 통한 동적 할당
24.6.1.1.1. 고정 IP 주소 할당 구성

다음 표에서는 고정 IP 주소 할당 구성을 설명합니다.

Expand
표 24.9. IPAM 정적 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 정적 값이 필요합니다.

addresses

array

가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

Pod 내부에서 구성할 경로를 지정하는 오브젝트 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 오브젝트의 배열입니다.

addresses 어레이에는 다음 필드가 있는 오브젝트가 필요합니다.

Expand
표 24.10. ipam.addresses[] array
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand
표 24.11. IPAM.routes[] 배열
필드유형설명

dst

string

CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 192.168.17.0/24 또는 0.0.0.0/0 )입니다.

gw

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand
표 24.12. IPAM.dns 오브젝트
필드유형설명

nameservers

array

DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}
Copy to Clipboard Toggle word wrap

24.6.1.1.2. DHCP(Dynamic 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"
        }
      }
  # ...
Copy to Clipboard Toggle word wrap

Expand
표 24.13. IPAM DHCP 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. dhcp 값이 필요합니다.

DHCP(Dynamic IP 주소) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}
Copy to Clipboard Toggle word wrap

24.6.1.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당 구성을 설명합니다.

Expand
표 24.14. IPAM: 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 필요한 경우 값을 가져옵니다 . Gets the value whereabouts.

범위

string

CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

Whereabouts를 사용하는 동적 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}
Copy to Clipboard Toggle word wrap

24.6.2. SR-IOV 추가 네트워크 구성

SriovIBNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovIBNetwork 오브젝트를 생성하면 SR-IOV Network 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"
        }
    Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택 사항: 이전 단계에서 생성한 SriovIBNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovIBNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>
    Copy to Clipboard Toggle word wrap

24.6.3. 다음 단계

24.7. SR-IOV 추가 네트워크에 pod 추가

기존 SR-IOV(Single Root I/O Virtualization) 네트워크에 pod를 추가할 수 있습니다.

24.7.1. 네트워크 연결을 위한 런타임 구성

추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.

Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.

24.7.1.1. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성

다음 JSON은 이더넷 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<name>", 
1

    "mac": "<mac_address>", 
2

    "ips": ["<cidr_range>"] 
3

  }
]
Copy to Clipboard Toggle word wrap
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"]
Copy to Clipboard Toggle word wrap

24.7.1.2. InfiniBand 기반 SR-IOV 연결을 위한 런타임 구성

다음 JSON은 InfiniBand 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<network_attachment>", 
1

    "infiniband-guid": "<guid>", 
2

    "ips": ["<cidr_range>"] 
3

  }
]
Copy to Clipboard Toggle word wrap
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"]
Copy to Clipboard Toggle word wrap

24.7.2. 추가 네트워크에 Pod 추가

추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.

Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.

참고

SR-IOV Network Resource Injector는 Pod의 첫 번째 컨테이너에 리소스 필드를 자동으로 추가합니다.

DPDK(Data Plane Development Kit) 모드에서 Intel NIC(네트워크 인터페이스 컨트롤러)를 사용하는 경우 Pod의 첫 번째 컨테이너만 NIC에 액세스하도록 구성됩니다. SriovNetworkNodePolicy 오브젝트에서 deviceTypevfio-pci 로 설정된 경우 SR-IOV 추가 네트워크는 DPDK 모드에 대해 구성됩니다.

NIC에 액세스해야 하는 컨테이너가 Pod 오브젝트에 정의된 첫 번째 컨테이너인지 확인하거나 Network Resource Injector를 비활성화하여 이 문제를 해결할 수 있습니다. 자세한 내용은 BZ#1990953 에서 참조하십시오.

사전 요구 사항

  • 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
      Copy to Clipboard Toggle word wrap
      1
      둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 
      1
      
                "namespace": "<namespace>", 
      2
      
                "default-route": ["<default-route>"] 
      3
      
              }
            ]
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음 예에서 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/network-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:
      ...
    Copy to Clipboard Toggle word wrap
    1
    k8s.v1.cni.cncf.io/network-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

24.7.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성

SR-IOV 및 제한된 또는 single-numa-node 토폴로지 관리자 정책으로 동일한 NUMA 노드에서 할당된 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV Pod를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • CPU 관리자 정책을 static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
  • 토폴로지 관리자 정책을 single-numa-node로 구성했습니다.

    참고

    single-numa-node가 요청을 충족할 수 없는 경우 Topology Manager 정책을 restricted로 구성할 수 있습니다. 보다 유연한 SR-IOV 네트워크 리소스 스케줄링은 추가 리소스 섹션에서 NUMA 인식 스케줄링 중 SR-IOV 네트워크 토폴로지 제외 참조하십시오.

프로세스

  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"
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    <filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
  3. sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.

    $ oc describe pod sample-pod
    Copy to Clipboard Toggle word wrap
  4. sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard Toggle word wrap
  5. sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard Toggle word wrap

24.7.4. OpenStack에서 SR-IOV를 사용하는 클러스터의 테스트 Pod 템플릿

다음 testpmd Pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.

testpmd Pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
1

  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
이 예에서는 성능 프로필의 이름이 cnf-performance 프로필 이라고 가정합니다.

클러스터 관리자는 SR-IOV 네트워크 장치에 연결된 Pod의 CNI(Container Network Interface) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl을 수정할 수 있습니다.

24.8.1. SR-IOV가 활성화된 NIC를 사용하여 노드에 레이블 지정

SR-IOV 가능 노드에서만 SR-IOV를 활성화하려면 다음을 수행하는 몇 가지 방법이 있습니다.

  1. NFD(Node Feature Discovery) Operator를 설치합니다. NFD는 SR-IOV가 활성화된 NIC의 존재를 감지하고 node.alpha.kubernetes-incubator.io/nfd-network-sriov.enabled = true 로 노드에 레이블을 지정합니다.
  2. 각 노드에 대해 SriovNetworkNodeState CR을 검사합니다. interfaces 스탠자에는 작업자 노드에서 SR-IOV Network Operator가 검색한 모든 SR-IOV 장치 목록이 포함됩니다. 다음 명령을 사용하여 각 노드에 feature.node.kubernetes.io/network-sriov.able: "true" 로 레이블을 지정합니다.

    $ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
    Copy to Clipboard Toggle word wrap
    참고

    원하는 이름으로 노드에 레이블을 지정할 수 있습니다.

24.8.2. 하나의 sysctl 플래그 설정

SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.

이 예에서는 생성된 가상 인터페이스에서 net.ipv4.conf.IFNAME.accept_redirects1 로 설정됩니다.

sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.

  • 다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 생성합니다.

    $ oc create namespace sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.

프로세스

  1. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성합니다. 예를 들어 다음 YAML을 policyoneflag-sriov-node-network.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policyoneflag 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyoneflag 
    3
    
      nodeSelector: 
    4
    
        feature.node.kubernetes.io/network-sriov.capable="true"
      priority: 10 
    5
    
      numVfs: 5 
    6
    
      nicSelector: 
    7
    
        pfNames: ["ens5"] 
    8
    
      deviceType: "netdevice" 
    9
    
      isRdma: false 
    10
    Copy to Clipboard Toggle word wrap
    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
    SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.
    7
    NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
    8
    선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
    9
    선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevice 입니다. 베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면 isRdmatrue 로 설정합니다.
    10
    선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
    참고

    vfio-pci 드라이버 유형은 지원되지 않습니다.

  2. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f policyoneflag-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 변경됩니다.

  3. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

    출력 예

    Succeeded
    Copy to Clipboard Toggle word wrap

24.8.2.2. SR-IOV 네트워크에서 sysctl 구성

SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 튜닝 구성을 추가하여 SR-IOV에서 생성된 가상 인터페이스에 인터페이스별 sysctl 설정을 설정할 수 있습니다.

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects sysctl 설정을 변경하려면 CNI(Container Network Interface) 튜닝 플러그인을 사용하여 추가 SR-IOV 네트워크를 생성합니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

절차

  1. 추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-interface-sysctl.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: onevalidflag 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyoneflag 
    3
    
      networkNamespace: sysctl-tuning-test 
    4
    
      ipam: '{ "type": "static" }' 
    5
    
      capabilities: '{ "mac": true, "ips": true }' 
    6
    
      metaPlugins : | 
    7
    
        {
          "type": "tuning",
          "capabilities":{
            "mac":true
          },
          "sysctl":{
             "net.ipv4.conf.IFNAME.accept_redirects": "1"
          }
        }
    Copy to Clipboard Toggle word wrap
    1
    오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
    4
    SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
    5
    YAML 블록 스칼라 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    6
    선택 사항: 추가 네트워크에 대한 기능을 설정합니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
    7
    선택 사항: metaPlugins 매개변수는 장치에 기능을 추가하는 데 사용됩니다. 이 사용 사례에서 type 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크 sysctl 을 지정합니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-interface-sysctl.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;namespace >를 SriovNetwork 오브젝트에 지정한 networkNamespace 값으로 바꿉니다. 예를 들면 sysctl-tuning-test 입니다.

    출력 예

    NAME                                  AGE
    onevalidflag                          14m
    Copy to Clipboard Toggle word wrap

    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. Pod CR을 생성합니다. 다음 YAML을 examplepod.yaml 파일로 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: sysctl-tuning-test
      annotations:
        k8s.v1.cni.cncf.io/networks: |-
          [
            {
              "name": "onevalidflag",  
    1
    
              "mac": "0a:56:0a:83:04:0c", 
    2
    
              "ips": ["10.100.100.200/24"] 
    3
    
           }
          ]
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000
          runAsGroup: 3000
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    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 }도 지정해야 합니다.
  2. Pod CR을 생성합니다.

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

    $ oc get pod -n sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 포드에 로그인합니다.

    $ oc rsh -n sysctl-tuning-test tunepod
    Copy to Clipboard Toggle word wrap
  5. 구성된 sysctl 플래그의 값을 확인합니다. 다음 명령을 실행하여 net.ipv4.conf.IFNAME.accept_redirects 값을 찾습니다.

    $ sysctl net.ipv4.conf.net1.accept_redirects
    Copy to Clipboard Toggle word wrap

    출력 예

    net.ipv4.conf.net1.accept_redirects = 1
    Copy to Clipboard Toggle word wrap

24.8.3. 본딩 SR-IOV 인터페이스 플래그와 연결된 Pod의 sysctl 설정 구성

본딩된 SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.

이 예제에서 구성할 수 있는 특정 네트워크 인터페이스 수준 sysctl 설정은 본딩된 인터페이스에 설정됩니다.

sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.

  • 다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 생성합니다.

    $ oc create namespace sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.

절차

  1. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성합니다. 다음 YAML을 policyallflags-sriov-node-network.yaml 로 저장합니다. policyallflags 를 구성 이름으로 교체합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policyallflags 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyallflags 
    3
    
      nodeSelector: 
    4
    
        node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
      priority: 10 
    5
    
      numVfs: 5 
    6
    
      nicSelector: 
    7
    
        pfNames: ["ens1f0"]  
    8
    
      deviceType: "netdevice" 
    9
    
      isRdma: false 
    10
    Copy to Clipboard Toggle word wrap
    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
    SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.
    7
    NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
    8
    선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
    9
    선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevice 입니다. 베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면 isRdmatrue 로 설정합니다.
    10
    선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
    참고

    vfio-pci 드라이버 유형은 지원되지 않습니다.

  2. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f policyallflags-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 변경됩니다.

  3. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

    출력 예

    Succeeded
    Copy to Clipboard Toggle word wrap

24.8.3.2. 결합된 SR-IOV 네트워크에서 sysctl 구성

두 SR-IOV 인터페이스에서 생성된 본딩된 인터페이스에서 인터페이스별 sysctl 설정을 설정할 수 있습니다. 본딩 네트워크 연결 정의의 선택적 Plugins 매개변수에 튜닝 구성을 추가하여 이 작업을 수행합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

특정 인터페이스 수준 네트워크 sysctl 설정을 변경하려면 다음 절차를 사용하여 컨테이너 네트워크 인터페이스(CNI) 튜닝 플러그인으로 SriovNetwork CR(사용자 정의 리소스)을 생성합니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

절차

  1. 다음 예제 CR과 같이 본딩된 인터페이스에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성합니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: allvalidflags 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyallflags 
    3
    
      networkNamespace: sysctl-tuning-test 
    4
    
      capabilities: '{ "mac": true, "ips": true }' 
    5
    Copy to Clipboard Toggle word wrap
    1
    오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
    4
    SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
    5
    선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예제 CR에서와 같이 본딩 네트워크 연결 정의를 생성합니다. YAML을 sriov-bond-network-interface.yaml 파일로 저장합니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-sysctl-network
      namespace: sysctl-tuning-test
    spec:
      config: '{
      "cniVersion":"0.4.0",
      "name":"bound-net",
      "plugins":[
        {
          "type":"bond", 
    1
    
          "mode": "active-backup", 
    2
    
          "failOverMac": 1, 
    3
    
          "linksInContainer": true, 
    4
    
          "miimon": "100",
          "links": [ 
    5
    
            {"name": "net1"},
            {"name": "net2"}
          ],
          "ipam":{ 
    6
    
            "type":"static"
          }
        },
        {
          "type":"tuning", 
    7
    
          "capabilities":{
            "mac":true
          },
          "sysctl":{
            "net.ipv4.conf.IFNAME.accept_redirects": "0",
            "net.ipv4.conf.IFNAME.accept_source_route": "0",
            "net.ipv4.conf.IFNAME.disable_policy": "1",
            "net.ipv4.conf.IFNAME.secure_redirects": "0",
            "net.ipv4.conf.IFNAME.send_redirects": "0",
            "net.ipv6.conf.IFNAME.accept_redirects": "0",
            "net.ipv6.conf.IFNAME.accept_source_route": "1",
            "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
            "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
          }
        }
      ]
    }'
    Copy to Clipboard Toggle word wrap
    1
    유형은 본딩 입니다.
    2
    mode 속성은 본딩 모드를 지정합니다. 지원되는 본딩 모드는 다음과 같습니다.
    • balance-rr - 0
    • active-backup - 1
    • balance-xor - 2

      balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 기능에 대해 신뢰 모드를 on 으로 설정해야 합니다.

    3
    active-backup 모드에서는 페일오버 속성이 필요합니다.
    4
    linksInContainer=true 플래그는 Bond CNI에 컨테이너 내에서 필요한 인터페이스를 찾을 수 있음을 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합이 작동하지 않는 호스트에서 이러한 인터페이스를 찾습니다.
    5
    links 섹션에서는 본딩을 만드는 데 사용할 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net"으로 지정하고 연속된 수로 지정합니다.
    6
    YAML 블록 스칼라 IPAM CNI 플러그인에 대한 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다. 이 Pod 예제 IP 주소는 수동으로 구성되므로 이 경우ipam 은 static으로 설정됩니다.
    7
    장치에 기능을 추가합니다. 예를 들어 type 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크 sysctl 을 지정합니다. 이 예제에서는 설정할 수 있는 모든 인터페이스 수준 네트워크 sysctl 설정을 설정합니다.
  4. 본딩 네트워크 연결 리소스를 만듭니다.

    $ oc create -f sriov-bond-network-interface.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;namespace >를 네트워크 연결을 구성할 때 지정한 networkNamespace로 바꿉니다(예: sysctl-tuning-test ).

    출력 예

    NAME                          AGE
    bond-sysctl-network           22m
    allvalidflags                 47m
    Copy to Clipboard Toggle word wrap

    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 리소스가 성공했는지 확인

튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. Pod CR을 생성합니다. 예를 들어 다음 YAML을 examplepod.yaml 파일로 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: sysctl-tuning-test
      annotations:
        k8s.v1.cni.cncf.io/networks: |-
          [
            {"name": "allvalidflags"}, 
    1
    
            {"name": "allvalidflags"},
            {
              "name": "bond-sysctl-network",
              "interface": "bond0",
              "mac": "0a:56:0a:83:04:0c", 
    2
    
              "ips": ["10.100.100.200/24"] 
    3
    
           }
          ]
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000
          runAsGroup: 3000
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    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 }도 지정해야 합니다.
  2. YAML을 적용합니다.

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.

    $ oc get pod -n sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 포드에 로그인합니다.

    $ oc rsh -n sysctl-tuning-test tunepod
    Copy to Clipboard Toggle word wrap
  5. 구성된 sysctl 플래그의 값을 확인합니다. 다음 명령을 실행하여 net.ipv6.neigh.IFNAME.base_reachable_time_ms 값을 찾습니다.

    $ sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
    Copy to Clipboard Toggle word wrap

    출력 예

    net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
    Copy to Clipboard Toggle word wrap

24.9. 고성능 멀티 캐스트 사용

SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크에서 멀티 캐스트를 사용할 수 있습니다.

24.9.1. 고성능 멀티 캐스트

OpenShift SDN 네트워크 플러그인은 기본 네트워크의 pod 간 멀티 캐스트를 지원합니다. 이는 고 대역폭 애플리케이션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다. IPTV(Internet Protocol Television) 및 멀티 포인트 화상 회의와 같은 스트리밍 미디어와 같은 애플리케이션의 경우 SR-IOV(Single Root I/O Virtualization) 하드웨어를 사용하여 거의 네이티브와 같은 성능을 제공할 수 있습니다.

멀티 캐스트에 추가 SR-IOV 인터페이스를 사용하는 경우:

  • 멀티 캐스트 패키지는 추가 SR-IOV 인터페이스를 통해 pod에서 보내거나 받아야 합니다.
  • SR-IOV 인터페이스를 연결하는 물리적 네트워크는 멀티 캐스트 라우팅 및 토폴로지를 결정하며 OpenShift Container Platform에서 제어하지 않습니다.

24.9.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']
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    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"]
    Copy to Clipboard Toggle word wrap
    1
    NET_ADMIN 기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.

24.10. DPDK 및 RDMA 사용

컨테이너화된 DPDK(Data Plane Development Kit) 애플리케이션은 OpenShift Container Platform에서 지원됩니다. DPDK(Data Plane Development Kit) 및 RDMA(Remote Direct Memory Access)와 함께 SR-IOV(Single Root I/O Virtualization) 네트워크 하드웨어를 사용할 수 있습니다.

지원되는 장치에 대한 자세한 내용은 지원되는 장치를 참조하십시오.

24.10.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
    Copy to Clipboard Toggle word wrap
    1
    가상 기능의 드라이버 유형을 vfio-pci로 지정합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

    선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-network.yaml
    Copy to Clipboard Toggle word wrap
  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:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    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
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 intel-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면 Pod 사양과 SriovNetwork 오브젝트 모두에서 target_namespace 를 변경합니다.
    2
    애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    /mnt/huge 의 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
    Copy to Clipboard Toggle word wrap

24.10.2. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용

Mellanox NIC와 함께 DPDK 모드에서 가상 기능을 사용하여 네트워크 노드 정책을 생성하고 DPDK(Data Plane Development Kit) Pod를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • SR-IOV(Single Root I/O Virtualization) 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
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다. Mellanox SR-IOV VF(가상 기능)는 vfio-pci 장치 유형을 사용하지 않고도 DPDK 모드에서 작동할 수 있습니다. VF 장치는 컨테이너 내부에 커널 네트워크 인터페이스로 나타납니다.
    3
    RDMA(Remote Direct Memory Access) 모드를 활성화합니다. 이는 DPDK 모드에서 Mellanox 카드가 작동하기 위해 필요합니다.
    참고

    SriovNetworkNodePolicy 오브젝트의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator에서 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    IP 주소 관리(IPAM) CNI(Container Network Interface) 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork 오브젝트 의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 을 참조하십시오.

    app-netutil 옵션 라이브러리는 컨테이너의 상위 포드에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-network.yaml
    Copy to Clipboard Toggle word wrap
  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:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    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
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 mlx-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면 Pod 사양과 SriovNetwork 오브젝트 모두에서 target_namespace 를 변경합니다.
    2
    애플리케이션 및 애플리케이션에서 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    hugepage 볼륨을 /mnt/huge 아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 medium가 HugepagesemptyDir 볼륨 유형으로 지원됩니다.
    5
    선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    6
    CPU 수를 지정합니다. DPDK Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이렇게 하려면 CPU 관리자 정책을 static 으로 설정하고 QoS(Quality of Service) 있는 Pod를 생성합니다.
    7
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepages를 구성하려면 커널 인수를 노드에 추가해야 합니다.
  6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f mlx-dpdk-pod.yaml
    Copy to Clipboard Toggle word wrap

24.10.3. 특정 DPDK 라인 비율 달성 개요

특정 DPDK(Data Plane Development Kit) 라인 속도를 달성하려면 Node Tuning Operator를 배포하고 SR-IOV(Single Root I/O Virtualization)를 구성합니다. 다음 리소스에 대해 DPDK 설정도 조정해야 합니다.

  • 분리된 CPU
  • hugepages
  • 토폴로지 스케줄러
참고

이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift Container Platform 애플리케이션의 대기 시간을 단축할 수 있도록 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다.

DPDK 테스트 환경

다음 다이어그램에서는 트래픽 테스트 환경의 구성 요소를 보여줍니다.

  • 트래픽 생성기: 대용량 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
  • SR-IOV-supporting NIC: SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 카드는 물리적 인터페이스에서 여러 가상 기능을 실행합니다.
  • 물리적 기능(PF ): SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCIe) 기능입니다.
  • VF(가상 기능): SR-IOV를 지원하는 네트워크 어댑터의 경량 PCIe 기능입니다. VF는 네트워크 어댑터의 PCIe PF와 연결되어 있습니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
  • Switch: 네트워크 스위치 노드를 back-to-back으로 연결할 수도 있습니다.
  • testpmd: DPDK에 포함된 예제 애플리케이션입니다. testpmd 애플리케이션을 사용하여 패킷 전달 모드에서 DPDK를 테스트할 수 있습니다. testpmd 애플리케이션은 DPDK SDK(Software Development Kit)를 사용하여 완전한 애플리케이션을 빌드하는 방법의 예이기도 합니다.
  • 작업자 0작업자 1: OpenShift Container Platform 노드.

24.10.4. SR-IOV 및 Node Tuning Operator를 사용하여 DPDK 라인 비율 달성

Node Tuning Operator를 사용하여 분리된 CPU, hugepages 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 SR-IOV(Single Root I/O Virtualization)와 함께 Node Tuning Operator를 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 얻을 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 독립 실행형 Node Tuning Operator를 배포했습니다.

    참고

    이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션에 대한 대기 시간을 단축할 수 있도록 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다.

프로세스

  1. 다음 예제를 기반으로 PerformanceProfile 오브젝트를 생성합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      globallyDisableIrqLoadBalancing: true
      cpu:
        isolated: 21-51,73-103 
    1
    
        reserved: 0-20,52-72 
    2
    
      hugepages:
        defaultHugepagesSize: 1G 
    3
    
        pages:
          - count: 32
            size: 1G
      net:
        userLevelNetworking: true
      numa:
        topologyPolicy: "single-numa-node"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
    Copy to Clipboard Toggle word wrap
    1
    시스템에서 하이퍼 스레딩이 활성화된 경우 격리된 CPU 그룹과 예약된 CPU 그룹에 관련 심볼릭 링크를 할당합니다. 시스템에 NUMA(메모리 액세스 노드)가 여러 개 포함된 경우 두 NUMA에서 두 그룹으로 모두 CPU를 할당합니다. 이 작업에 Performance Profile Creator를 사용할 수도 있습니다. 자세한 내용은 성능 프로필 생성을 참조하십시오.
    2
    대기열이 예약된 CPU 수로 설정될 장치 목록을 지정할 수도 있습니다. 자세한 내용은 Node Tuning Operator를 사용하여 NIC 대기열 단축을 참조하십시오.
    3
    필요한 hugepage 수와 크기를 할당합니다. hugepages에 대한 NUMA 구성을 지정할 수 있습니다. 기본적으로 시스템은 시스템의 모든 NUMA 노드에 짝수를 할당합니다. 필요한 경우 노드에 대한 실시간 커널 사용을 요청할 수 있습니다. 자세한 내용은 실시간 기능이 있는 작업자 프로비저닝 을 참조하십시오.
  2. yaml 파일을 mlx-dpdk-perfprofile-policy.yaml 로 저장합니다.
  3. 다음 명령을 사용하여 성능 프로필을 적용합니다.

    $ oc create -f mlx-dpdk-perfprofile-policy.yaml
    Copy to Clipboard Toggle word wrap
24.10.4.1. 가상 기능에 대한 SR-IOV Network Operator의 예

SR-IOV(Single Root I/O Virtualization) Network Operator를 사용하여 노드의 SR-IOV 지원 물리적 기능 NIC에서 VF(가상 기능)를 할당하고 구성할 수 있습니다.

Operator 배포에 대한 자세한 내용은 SR-IOV Network Operator 설치를 참조하십시오. SR-IOV 네트워크 장치 구성에 대한 자세한 내용은 SR-IOV 네트워크 장치 구성을 참조하십시오.

Intel VF 및 Mellanox VF에서 DPDK(Data Plane Development Kit) 워크로드를 실행하는 데는 몇 가지 차이점이 있습니다. 이 섹션에서는 두 VF 유형에 대한 오브젝트 구성 예제를 제공합니다. 다음은 Intel NIC에서 DPDK 애플리케이션을 실행하는 데 사용되는 sriovNetworkNodePolicy 오브젝트의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 
1

  needVhostNet: true 
2

  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Intel NIC의 경우 deviceTypevfio-pci 여야 합니다.
2
DPDK 워크로드와 커널 통신이 필요한 경우 needVhostNet: true 를 추가합니다. 그러면 애플리케이션이 탭 장치를 생성하고 탭 장치를 DPDK 워크로드에 연결할 수 있도록 /dev/net/tun/dev/vhost-net 장치를 컨테이너에 마운트합니다.

다음은 Mellanox NIC의 sriovNetworkNodePolicy 오브젝트의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 
1

  isRdma: true 
2

  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Mellanox 장치의 경우 deviceTypenetdevice 여야 합니다.
2
Mellanox 장치의 경우 isRdmatrue 여야 합니다. Mellanox 카드는 Flow Bifurcation을 사용하여 DPDK 애플리케이션에 연결됩니다. 이 메커니즘은 Linux 사용자 공간과 커널 공간 간의 트래픽을 분할하고 라인 속도 처리 기능을 향상시킬 수 있습니다.
24.10.4.2. SR-IOV 네트워크 Operator의 예

다음은 sriovNetwork 오브젝트 정의의 예입니다. 이 경우 Intel 및 Mellanox 구성은 동일합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 
1

  networkNamespace: dpdk-test 
2

  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 
3

---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Whereabouts와 같은 다른 IP 주소 관리 (IPAM) 구현을 사용할 수 있습니다. 자세한 내용은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 참조하십시오.
2
네트워크 연결 정의가 생성될 networkNamespace 를 요청해야 합니다. openshift-sriov-network-operator 네임스페이스에서 sriovNetwork CR을 생성해야 합니다.
3
resourceName 값은 sriovNetworkNodePolicy 에서 생성된 resourceName 값과 일치해야 합니다.
24.10.4.3. DPDK 기본 워크로드 예

다음은 DPDK(Data Plane Development Kit) 컨테이너의 예입니다.

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 
1

     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 
2

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 
3

  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 
4

        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages
Copy to Clipboard Toggle word wrap
1
필요한 SR-IOV 네트워크를 요청합니다. 장치 리소스가 자동으로 삽입됩니다.
2
CPU 및 IRQ 로드 밸런싱 기반을 비활성화합니다. 자세한 내용은 개별 Pod의 인터럽트 처리 비활성화를 참조하십시오.
3
runtimeClassperformance-performance 로 설정합니다. runtimeClassHostNetwork 또는 privileged 로 설정하지 마십시오.
4
QoS(Quality of Service)로 Pod를 시작하기 위해 요청 및 제한에 동일한 수의 리소스를 요청합니다.
참고

SLEEP 로 Pod를 시작한 다음 pod를 실행하여 testpmd 또는 DPDK 워크로드를 시작합니다. exec 프로세스가 CPU에 고정되지 않으므로 추가 인터럽트를 추가할 수 있습니다.

24.10.4.4. testpmd 스크립트 예

다음은 testpmd 를 실행하기 위한 예제 스크립트입니다.

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02
Copy to Clipboard Toggle word wrap

이 예제에서는 두 개의 다른 sriovNetwork CR을 사용합니다. 환경 변수에는 Pod에 할당된 VF(Virtual Function) PCI 주소가 포함됩니다. 포드 정의에서 동일한 네트워크를 사용하는 경우 pciAddress 를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예에서는 사용자 정의 MAC 주소를 사용합니다.

24.10.5. Mellanox NIC와 함께 RDMA 모드에서 가상 기능 사용

중요

RoCE(RDMA over Converged Ethernet)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

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
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다.
    3
    RDMA 모드를 활성화합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

    선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-network.yaml
    Copy to Clipboard Toggle word wrap
  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:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    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
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 mlx-rdma-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면 Pod 사양과 SriovNetwork 오브젝트 모두에서 target_namespace 를 변경합니다.
    2
    애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    hugepage 볼륨을 /mnt/huge 아래의 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
    Copy to Clipboard Toggle word wrap

24.10.6. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 테스트 Pod 템플릿

다음 testpmd Pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.

testpmd Pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 
1

      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
2

  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
이 예제의 이름 dpdk1 은 사용자가 생성한 SriovNetworkNodePolicy 리소스입니다. 이 이름을 생성한 리소스의 이름을 대체할 수 있습니다.
2
성능 프로필의 이름이 cnf-performance 프로필 로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.

다음 testpmd Pod는 RHOSP(Red Hat OpenStack Platform)에서 OVS(Open vSwitch) 하드웨어 오프로드를 보여줍니다.

testpmd Pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 
1

  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
성능 프로필의 이름이 cnf-performance 프로필 로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.

24.11. Pod 수준 본딩 사용

Pod 수준의 본딩은 고가용성과 처리량이 필요한 Pod 내부의 워크로드를 활성화하는 데 중요합니다. Pod 수준 본딩을 사용하면 커널 모드 인터페이스에서 여러 SR-IOV(Single Root I/O Virtualization) 가상 기능 인터페이스에서 본딩 인터페이스를 생성할 수 있습니다. SR-IOV 가상 기능은 Pod에 전달되고 커널 드라이버에 연결됩니다.

Pod 수준 본딩이 필요한 시나리오 중 하나는 다른 물리적 기능의 여러 SR-IOV 가상 함수에서 본딩 인터페이스를 생성하는 것입니다. 호스트의 두 가지 물리적 기능에서 본딩 인터페이스를 생성하여 Pod 수준에서 고가용성 및 처리량을 달성하는 데 사용할 수 있습니다.

SR-IOV 네트워크, 네트워크 정책, 네트워크 연결 정의 및 Pod 생성과 같은 작업에 대한 지침은 SR-IOV 네트워크 장치 구성을 참조하십시오.

24.11.1. 두 개의 SR-IOV 인터페이스에서 본딩 인터페이스 구성

본딩을 사용하면 여러 네트워크 인터페이스를 단일 논리 "보딩" 인터페이스로 집계할 수 있습니다. 본딩 컨테이너 네트워크 인터페이스(Bond-CNI)는 본딩 기능을 컨테이너에 제공합니다.

본딩-CNI는 SR-IOV(Single Root I/O Virtualization) 가상 기능을 사용하여 생성하여 컨테이너 네트워크 네임스페이스에 배치할 수 있습니다.

OpenShift Container Platform은 SR-IOV 가상 기능을 사용하는 본딩 CNI만 지원합니다. SR-IOV Network Operator는 가상 기능을 관리하는 데 필요한 SR-IOV CNI 플러그인을 제공합니다. 기타 CNI 또는 인터페이스 유형은 지원되지 않습니다.

사전 요구 사항

  • 컨테이너의 가상 기능을 가져오도록 SR-IOV Network Operator를 설치하고 구성해야 합니다.
  • SR-IOV 인터페이스를 구성하려면 각 인터페이스에 대해 SR-IOV 네트워크 및 정책을 생성해야 합니다.
  • SR-IOV Network Operator는 정의된 SR-IOV 네트워크 및 정책을 기반으로 각 SR-IOV 인터페이스에 대한 네트워크 연결 정의를 생성합니다.
  • linkState 는 SR-IOV 가상 기능의 기본값 auto 로 설정됩니다.
24.11.1.1. 본딩 네트워크 연결 정의 생성

SR-IOV 가상 기능을 사용할 수 있으므로 본딩 네트워크 연결 정의를 생성할 수 있습니다.

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 
1

      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 
2

      "failOverMac": 1, 
3

      "linksInContainer": true, 
4

      "miimon": "100",
      "mtu": 1500,
      "links": [ 
5

            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'
Copy to Clipboard Toggle word wrap
1
cni-type은 항상 bond 로 설정됩니다.
2
mode 속성은 본딩 모드를 지정합니다.
참고

지원되는 본딩 모드는 다음과 같습니다.

  • balance-rr - 0
  • active-backup - 1
  • balance-xor - 2

balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 기능에 대해 신뢰 모드를 on 으로 설정해야 합니다.

3
failover 속성은 active-backup 모드의 경우 필수이며 1로 설정해야 합니다.
4
linksInContainer=true 플래그는 Bond CNI에 컨테이너 내에서 필요한 인터페이스를 찾을 수 있음을 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합이 작동하지 않는 호스트에서 이러한 인터페이스를 찾습니다.
5
links 섹션에서는 본딩을 만드는 데 사용할 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net"으로 지정하고 연속된 수로 지정합니다.
24.11.1.2. 본딩 인터페이스를 사용하여 Pod 생성
  1. 다음과 유사한 콘텐츠가 있는 pod의 YAML 파일 (예: podbonding.yaml )을 사용하여 pod를 생성하여 설정을 테스트합니다.

    apiVersion: v1
        kind: Pod
        metadata:
          name: bondpod1
          namespace: demo
          annotations:
            k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 
    1
    
        spec:
          containers:
          - name: podexample
            image: quay.io/openshift/origin-network-interface-bond-cni:4.11.0
            command: ["/bin/bash", "-c", "sleep INF"]
    Copy to Clipboard Toggle word wrap
    1
    네트워크 주석: SR-IOV 네트워크 연결 두 개와 하나의 본딩 네트워크 연결이 포함되어 있습니다. 본딩 연결에서는 두 개의 SR-IOV 인터페이스를 결합된 포트 인터페이스로 사용합니다.
  2. 다음 명령을 실행하여 yaml을 적용합니다.

    $ oc apply -f podbonding.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 Pod 인터페이스를 검사합니다.

    $ oc rsh -n demo bondpod1
    sh-4.4#
    sh-4.4# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
    valid_lft forever preferred_lft forever
    4: net3: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    1
    
    inet 10.56.217.66/24 scope global bond0
    valid_lft forever preferred_lft forever
    43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    2
    
    44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    3
    Copy to Clipboard Toggle word wrap
    1
    본딩 인터페이스의 이름은 자동으로 net3 로 지정됩니다. 특정 인터페이스 이름을 설정하려면 Pod의 k8s.v1.cni.cncf.io/networks 주석에 @name 접미사를 추가합니다.
    2
    net1 인터페이스는 SR-IOV 가상 기능을 기반으로 합니다.
    3
    net2 인터페이스는 SR-IOV 가상 기능을 기반으로 합니다.
    참고

    Pod 주석에 인터페이스 이름이 구성되지 않은 경우 인터페이스 이름은 net<n > 로 자동으로 할당되며 < n >은 1 부터 시작합니다.

  4. 선택 사항: bond0 과 같은 특정 인터페이스 이름을 설정하려면 k8s.v1.cni.cncf.io/networks 주석을 편집하고 다음과 같이 bond0 을 인터페이스 이름으로 설정합니다.

    annotations:
            k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0
    Copy to Clipboard Toggle word wrap

24.12. 하드웨어 오프로드 구성

클러스터 관리자는 호환 가능한 노드에서 하드웨어 오프로드를 구성하여 데이터 처리 성능을 높이고 호스트 CPU의 부하를 줄일 수 있습니다.

24.12.1. 하드웨어 오프로드 정보

Open vSwitch 하드웨어 오프로드는 CPU에서 벗어나 네트워크 인터페이스 컨트롤러의 전용 프로세서로 오프로드하여 네트워크 작업을 처리하는 방법입니다. 결과적으로 클러스터는 데이터 전송 속도를 높이고 CPU 워크로드를 줄이며 컴퓨팅 비용을 절감할 수 있습니다.

이 기능의 주요 요소는 SmartNICs라는 최신 네트워크 인터페이스 컨트롤러 클래스입니다. SmartNIC는 과도하게 많은 네트워크 처리 작업을 처리할 수 있는 네트워크 인터페이스 컨트롤러입니다. 전용 그래픽 카드가 그래픽 성능을 향상시킬 수있는 것과 마찬가지로 SmartNIC는 네트워크 성능을 향상시킬 수 있습니다. 각 경우 전용 프로세서는 특정 유형의 처리 작업에 대한 성능을 향상시킵니다.

OpenShift Container Platform에서는 호환되는 SmartNIC가 있는 베어 메탈 노드에 대한 하드웨어 오프로드를 구성할 수 있습니다. 하드웨어 오프로드는 SR-IOV Network Operator에 의해 구성 및 활성화됩니다.

하드웨어 오프로드는 모든 워크로드 또는 애플리케이션 유형과 호환되지 않습니다. 다음 두 가지 통신 유형만 지원됩니다.

  • pod-to-pod
  • pod-to-service - 서비스는 일반 Pod에서 지원하는 ClusterIP 서비스

모든 경우에서 하드웨어 오프로드는 해당 Pod 및 서비스가 호환되는 SmartNIC 노드에 할당되는 경우에만 수행됩니다. 예를 들어 하드웨어 오프로드가 있는 노드의 Pod가 일반 노드에서 서비스와 통신하려고 한다고 가정합니다. 일반 노드에서 모든 처리가 커널에서 수행되므로 pod-to-service 통신의 전반적인 성능은 해당 일반 노드의 최대 성능으로 제한됩니다. 하드웨어 오프로드는 DPDK 애플리케이션과 호환되지 않습니다.

노드에서 하드웨어 오프로드를 활성화하지만 사용할 Pod를 구성하지 않으면 Pod 트래픽에 대한 처리량 성능이 저하될 수 있습니다. OpenShift Container Platform에서 관리하는 Pod의 하드웨어 오프로드는 구성할 수 없습니다.

24.12.2. 지원되는 장치

하드웨어 오프로드는 다음 네트워크 인터페이스 컨트롤러에서 지원됩니다.

Expand
표 24.15. 지원되는 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

Mellanox

MT27800 제품군 [ConnectX-5]

15b3

1017

Mellanox

MT28880 제품군 [ConnectX-5 Ex]

15b3

1019

Mellanox

MT2892 제품군 [ConnectX-6 Dx]

15b3

101d

Mellanox

MT2894 제품군 [ConnectX-6 Lx]

15b3

101f

Mellanox

MT42822 ConnectX-6 NIC 모드 BlueField-2

15b3

a2d6

24.12.3. 사전 요구 사항

24.12.4. SR-IOV Network Operator를 systemd 모드로 설정

하드웨어 오프로드를 지원하려면 먼저 SR-IOV Network Operator를 systemd 모드로 설정해야 합니다.

사전 요구 사항

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

절차

  1. SriovOperatorConfig CR(사용자 정의 리소스)을 생성하여 모든 SR-IOV Operator 구성 요소를 배포합니다.

    1. 다음 YAML이 포함된 sriovOperatorConfig.yaml 파일을 생성합니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovOperatorConfig
      metadata:
        name: default 
      1
      
        namespace: openshift-sriov-network-operator
      spec:
        enableInjector: true
        enableOperatorWebhook: true
        configurationMode: "systemd" 
      2
      
        logLevel: 2
      Copy to Clipboard Toggle word wrap
      1
      SriovOperatorConfig 리소스에 대한 유일한 유효한 이름은 default 이며 Operator가 배포된 네임스페이스에 있어야 합니다.
      2
      SR-IOV Network Operator를 systemd 모드로 설정하는 것은 Open vSwitch 하드웨어 오프로드에만 관련이 있습니다.
    2. 다음 명령을 실행하여 리소스를 생성합니다.

      $ oc apply -f sriovOperatorConfig.yaml
      Copy to Clipboard Toggle word wrap

24.12.5. 하드웨어 오프로드를 위한 머신 구성 풀 구성

하드웨어 오프로드를 활성화하기 위해 전용 머신 구성 풀을 생성하고 SR-IOV Network Operator에서 작동하도록 구성합니다.

사전 요구 사항

  1. SR-IOV Network Operator가 설치되어 systemd 모드로 설정됩니다.

절차

  1. 하드웨어 오프로드를 사용할 머신의 머신 구성 풀을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 mcp-offloading.yaml 과 같은 파일을 생성합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: mcp-offloading 
      1
      
      spec:
        machineConfigSelector:
          matchExpressions:
            - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 
      2
      
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/mcp-offloading: "" 
      3
      Copy to Clipboard Toggle word wrap
      1 2
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
      3
      이 노드 역할 레이블은 머신 구성 풀에 노드를 추가하는 데 사용됩니다.
    2. 머신 구성 풀의 구성을 적용합니다.

      $ oc create -f mcp-offloading.yaml
      Copy to Clipboard Toggle word wrap
  2. 머신 구성 풀에 노드를 추가합니다. 풀의 노드 역할 라벨을 사용하여 각 노드에 레이블을 지정합니다.

    $ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 새 풀이 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME       STATUS   ROLES                   AGE   VERSION
    master-0   Ready    master                  2d    v1.26.0
    master-1   Ready    master                  2d    v1.26.0
    master-2   Ready    master                  2d    v1.26.0
    worker-0   Ready    worker                  2d    v1.26.0
    worker-1   Ready    worker                  2d    v1.26.0
    worker-2   Ready    mcp-offloading,worker   47h   v1.26.0
    worker-3   Ready    mcp-offloading,worker   47h   v1.26.0
    Copy to Clipboard Toggle word wrap

  4. 이 머신 구성 풀을 SriovNetworkPoolConfig 사용자 정의 리소스에 추가합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 sriov-pool-config.yaml 과 같은 파일을 생성합니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: sriovnetworkpoolconfig-offload
        namespace: openshift-sriov-network-operator
      spec:
        ovsHardwareOffloadConfig:
          name: mcp-offloading 
      1
      Copy to Clipboard Toggle word wrap
      1
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
    2. 설정을 적용합니다.

      $ oc create -f <SriovNetworkPoolConfig_name>.yaml
      Copy to Clipboard Toggle word wrap
      참고

      SriovNetworkPoolConfig 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 머신 구성 풀에서 노드를 비우고 재시작합니다.

      구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

24.12.6. SR-IOV 네트워크 노드 정책 구성

SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 생성할 수 있습니다. 하드웨어 오프로드를 활성화하려면 "switchdev" 값으로 .spec.eSwitchMode 필드를 정의해야 합니다.

다음 절차에서는 하드웨어 오프로드가 있는 네트워크 인터페이스 컨트롤러에 대한 SR-IOV 인터페이스를 생성합니다.

사전 요구 사항

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

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 sriov-node-policy.yaml 과 같은 파일을 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-policy <.>
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice <.>
      eSwitchMode: "switchdev" <.>
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 6
      priority: 5
      resourceName: mlxnics
    Copy to Clipboard Toggle word wrap

    <.> 사용자 정의 리소스 오브젝트의 이름입니다. <.> 필수 항목입니다. vfio-pci. <.> 필수에서는 하드웨어 오프로드가 지원되지 않습니다.

  2. 정책에 대한 구성을 적용합니다.

    $ oc create -f sriov-node-policy.yaml
    Copy to Clipboard Toggle word wrap
    참고

    SriovNetworkPoolConfig 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 머신 구성 풀에서 노드를 비우고 재시작합니다.

    구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

24.12.6.1. OpenStack의 SR-IOV 네트워크 노드 정책의 예

다음 예제에서는 RHOSP(Red Hat OpenStack Platform)에서 하드웨어를 오프로드하는 NIC(네트워크 인터페이스 컨트롤러)의 SR-IOV 인터페이스를 설명합니다.

RHOSP에서 하드웨어 오프로드가 있는 NIC용 SR-IOV 인터페이스

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}
Copy to Clipboard Toggle word wrap

24.12.7. 네트워크 연결 정의 생성

머신 구성 풀과 SR-IOV 네트워크 노드 정책을 정의한 후 사용자가 지정한 네트워크 인터페이스 카드에 대한 네트워크 연결 정의를 생성할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 net-attach-def.yaml 과 같은 파일을 생성합니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: net-attach-def <.>
      namespace: net-attach-def <.>
      annotations:
        k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.>
    spec:
      config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'
    Copy to Clipboard Toggle word wrap

    <.> 네트워크 연결 정의의 이름입니다. <.> 네트워크 연결 정의의 네임스페이스입니다. <.> SriovNetworkNodePolicy 오브젝트에 지정한 spec.resourceName 필드의 값입니다.

  2. 네트워크 연결 정의에 대한 구성을 적용합니다.

    $ oc create -f net-attach-def.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 새 정의가 있는지 확인합니다.

    $ oc get net-attach-def -A
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE         NAME             AGE
    net-attach-def    net-attach-def   43h
    Copy to Clipboard Toggle word wrap

24.12.8. Pod에 네트워크 연결 정의 추가

머신 구성 풀, SriovNetworkPoolConfigSriovNetworkNodePolicy 사용자 정의 리소스 및 네트워크 연결 정의를 생성한 후 Pod 사양에 네트워크 연결 정의를 추가하여 Pod에 이러한 구성을 적용할 수 있습니다.

절차

  • Pod 사양에서 .metadata.annotations.k8s.v1.cni.cncf.io/networks 필드를 추가하고 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의를 지정합니다.

    ....
    metadata:
      annotations:
        v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>
    Copy to Clipboard Toggle word wrap

    <.> 값은 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의의 이름과 네임스페이스여야 합니다.

24.13. Bluefield-2를 DPU에서 NIC로 전환

Bluefield-2 네트워크 장치를 DPDK(Data Processing Unit) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환할 수 있습니다.

24.13.1. Bluefield-2를 DPU 모드에서 NIC 모드로 전환

다음 절차에 따라 Bluefield-2를 DPDK(데이터 처리 장치) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환합니다.

중요

현재 Bluefield-2를 DPU에서 NIC 모드로 전환만 지원됩니다. NIC 모드에서 DPU 모드로 전환하는 것은 지원되지 않습니다.

사전 요구 사항

  • SR-IOV Network Operator가 설치되어 있습니다. 자세한 내용은 " SR-IOV Network Operator 설치"를 참조하십시오.
  • Bluefield-2를 최신 펌웨어로 업데이트했습니다. 자세한 내용은 NVIDIA BlueField-2 펌웨어를 참조하십시오.

절차

  1. 다음 명령을 입력하여 각 작업자 노드에 다음 라벨을 추가합니다.

    $ oc label node <example_node_name_one> node-role.kubernetes.io/sriov=
    Copy to Clipboard Toggle word wrap
    $ oc label node <example_node_name_two> node-role.kubernetes.io/sriov=
    Copy to Clipboard Toggle word wrap
  2. SR-IOV Network Operator의 머신 구성 풀을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: sriov
    spec:
      machineConfigSelector:
        matchExpressions:
        - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,sriov]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/sriov: ""
    Copy to Clipboard Toggle word wrap
  3. 다음 machineconfig.yaml 파일을 작업자 노드에 적용합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: sriov
      name: 99-bf2-dpu
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,ZmluZF9jb250YWluZXIoKSB7CiAgY3JpY3RsIHBzIC1vIGpzb24gfCBqcSAtciAnLmNvbnRhaW5lcnNbXSB8IHNlbGVjdCgubWV0YWRhdGEubmFtZT09InNyaW92LW5ldHdvcmstY29uZmlnLWRhZW1vbiIpIHwgLmlkJwp9CnVudGlsIG91dHB1dD0kKGZpbmRfY29udGFpbmVyKTsgW1sgLW4gIiRvdXRwdXQiIF1dOyBkbwogIGVjaG8gIndhaXRpbmcgZm9yIGNvbnRhaW5lciB0byBjb21lIHVwIgogIHNsZWVwIDE7CmRvbmUKISBzdWRvIGNyaWN0bCBleGVjICRvdXRwdXQgL2JpbmRhdGEvc2NyaXB0cy9iZjItc3dpdGNoLW1vZGUuc2ggIiRAIgo=
            mode: 0755
            overwrite: true
            path: /etc/default/switch_in_sriov_config_daemon.sh
        systemd:
          units:
          - name: dpu-switch.service
            enabled: true
            contents: |
              [Unit]
              Description=Switch BlueField2 card to NIC/DPU mode
              RequiresMountsFor=%t/containers
              Wants=network.target
              After=network-online.target kubelet.service
              [Service]
              SuccessExitStatus=0 120
              RemainAfterExit=True
              ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic || shutdown -r now' 
    1
    
              Type=oneshot
              [Install]
              WantedBy=multi-user.target
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: 특정 카드의 PCI 주소는 선택적으로 지정할 수 있습니다(예: ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic 0000:5e:00.0 || echo done' ). 기본적으로 첫 번째 장치가 선택됩니다. 둘 이상의 장치가 있는 경우 사용할 PCI 주소를 지정해야 합니다. PCI 주소는 Bluefield-2를 DPU 모드에서 NIC 모드로 전환하는 모든 노드에서 동일해야 합니다.
  4. 작업자 노드가 다시 시작될 때까지 기다립니다. 다시 시작한 후 작업자 노드의 Bluefield-2 네트워크 장치는 NIC 모드로 전환됩니다.
  5. 선택 사항: 최신 Bluefield-2 펌웨어 릴리스의 경우 NIC 모드로 전환하려면 하드웨어를 다시 시작해야 하므로 호스트 하드웨어를 다시 시작해야 할 수 있습니다.

24.14. SR-IOV Network Operator 설치 제거

SR-IOV Network Operator를 설치 제거하려면 실행 중인 SR-IOV 워크로드를 삭제하고 Operator를 설치 제거하며 Operator에서 사용한 Webhook를 삭제해야 합니다.

24.14.1. SR-IOV Network Operator 설치 제거

클러스터 관리자는 SR-IOV Network Operator를 설치 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • SR-IOV Network Operator가 설치되어 있어야 합니다.

절차

  1. 모든 SR-IOV 사용자 정의 리소스(CR)를 삭제합니다.

    $ oc delete sriovnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovibnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
  2. "클러스터에서 Operator 삭제" 섹션의 지침에 따라 SR-IOV Network Operator를 클러스터에서 제거합니다.
  3. SR-IOV Network Operator가 제거된 후에도 클러스터에 남아 있는 SR-IOV 사용자 정의 리소스 정의를 삭제합니다.

    $ oc delete crd sriovibnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
  4. SR-IOV Webhook를 삭제합니다.

    $ oc delete mutatingwebhookconfigurations network-resources-injector-config
    Copy to Clipboard Toggle word wrap
    $ oc delete MutatingWebhookConfiguration sriov-operator-webhook-config
    Copy to Clipboard Toggle word wrap
    $ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config
    Copy to Clipboard Toggle word wrap
  5. SR-IOV Network Operator 네임스페이스를 삭제합니다.

    $ oc delete namespace openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

25장. OVN-Kubernetes 네트워크 플러그인

25.1. OVN-Kubernetes 네트워크 플러그인 정보

OpenShift Container Platform 클러스터는 pod 및 service 네트워크에 가상화된 네트워크를 사용합니다.

Red Hat OpenShift Networking의 일부인 OVN-Kubernetes 네트워크 플러그인은 OpenShift Container Platform의 기본 네트워크 공급자입니다. OVN-Kubernetes는 OVN(Open Virtual Network)을 기반으로 하며 오버레이 기반 네트워킹 구현을 제공합니다.

중요

cloud -provider=external 옵션이 cloud-provider- vsphere 로 설정된 클라우드 컨트롤러 관리자(CCM)의 경우 여러 서브넷이 있는 네트워킹 환경에서 작동하는 클러스터에 대해 알려진 문제가 있습니다.

OpenShift Container Platform 4.12에서 OpenShift Container Platform 4.13으로 클러스터를 업그레이드할 때 CCM은 잘못된 노드 IP 주소를 선택하고 이 작업은 네임스페이스/openshift-cloud-controller-manager/pods/vsphere-cloud-controller-manager 로그에 오류 메시지를 생성합니다. 오류 메시지는 클러스터의 노드 IP 주소 및 vsphere-cloud-controller-manager Pod IP 주소와 일치하지 않음을 나타냅니다.

알려진 문제는 클러스터 업그레이드 작업에 영향을 미치지 않지만 클러스터가 네트워킹 요구 사항에 사용하는 nodeNetworking.external.networkSubnetCidrnodeNetworking.internal.networkSubnetCidr 매개변수 모두에서 올바른 IP 주소를 설정할 수 있습니다.

OVN-Kubernetes 플러그인을 사용하는 클러스터도 각 노드에서 OVS(Open vSwitch)를 실행합니다. OVN은 각 노드에서 선언된 네트워크 구성을 구현하도록 OVS를 구성합니다.

참고

OVN-Kubernetes는 OpenShift Container Platform 및 단일 노드 OpenShift 배포를 위한 기본 네트워킹 솔루션입니다.

OVS 프로젝트에서 발생한 OVN-Kubernetes는 오픈 흐름 규칙과 같은 많은 동일한 구성을 사용하여 패킷이 네트워크를 통과하는 방식을 결정합니다. 자세한 내용은 Open Virtual Network 웹 사이트를 참조하십시오.

OVN-Kubernetes는 가상 네트워크 구성을 OpenFlow 규칙으로 변환하는 OVS의 일련의 데몬입니다. OpenFlow 는 네트워크 스위치 및 라우터와 통신하기 위한 프로토콜로, 네트워크 장치에서 네트워크 트래픽 흐름을 원격으로 제어하는 수단을 제공하여 네트워크 트래픽 흐름을 구성, 관리 및 모니터링할 수 있습니다.

OVN-Kubernetes는 OpenFlow 에서 사용할 수 없는 고급 기능을 더 많이 제공합니다. OVN은 분산 가상 라우팅, 분산 논리 스위치, 액세스 제어, DHCP 및 DNS를 지원합니다. OVN은 개방형 흐름과 같은 논리 흐름 내에서 분산 가상 라우팅을 구현합니다. 예를 들어 네트워크에서 DHCP 요청을 보내는 Pod가 있는 경우 DHCP 주소를 찾는 브로드캐스트가 해당 패킷과 일치하는 논리 흐름 규칙이 되고, DNS 서버에서 IP 주소를 제공하는 논리 흐름 규칙이 표시됩니다.

OVN-Kubernetes는 각 노드에서 데몬을 실행합니다. 데이터베이스 및 모든 노드에서 실행되는 OVN 컨트롤러에 대한 데몬 세트가 있습니다. OVN 컨트롤러는 네트워크 공급자 기능, 송신 IP, 방화벽, 라우터, 하이브리드 네트워킹, IPSEC 암호화, IPv6, 네트워크 정책, 네트워크 정책 로그, 하드웨어 오프로드 및 멀티 캐스트를 지원하기 위해 노드의 Open vSwitch 데몬을 프로그래밍합니다.

25.1.1. OVN-Kubernetes 목적

OVN-Kubernetes 네트워크 플러그인은 OVN(Open Virtual Network)을 사용하여 네트워크 트래픽 흐름을 관리하는 완전한 기능을 갖춘 오픈 소스 Kubernetes CNI 플러그인입니다. OVN은 커뮤니티에서 개발한 벤더와 무관한 네트워크 가상화 솔루션입니다. OVN-Kubernetes 네트워크 플러그인:

  • OVN(Open Virtual Network)을 사용하여 네트워크 트래픽 흐름을 관리합니다. OVN은 커뮤니티에서 개발한 벤더와 무관한 네트워크 가상화 솔루션입니다.
  • 수신 및 송신 규칙을 포함한 Kubernetes 네트워크 정책 지원을 구현합니다.
  • VXLAN 대신 Geneve(Generic Network Virtualization Encapsulation) 프로토콜을 사용하여 노드 간에 오버레이 네트워크를 만듭니다.

OVN-Kubernetes 네트워크 플러그인은 OpenShift SDN에 비해 다음과 같은 이점을 제공합니다.

  • 지원되는 플랫폼에서 IPv6 단일 스택 및 IPv4/IPv6 듀얼 스택 네트워킹을 완전히 지원합니다.
  • Linux 및 Microsoft Windows 워크로드가 모두 있는 하이브리드 클러스터 지원
  • 클러스터 내부 통신의 선택적 IPsec 암호화
  • 호스트 CPU에서 호환되는 네트워크 카드 및 DPDK(데이터 처리 장치)에 대한 네트워크 데이터 처리 오프로드

25.1.2. 지원되는 네트워크 플러그인 기능 매트릭스

Red Hat OpenShift Networking은 네트워크 플러그인에 대해 네트워크 플러그인의 두 가지 옵션인 OpenShift SDN 및 OVN-Kubernetes를 제공합니다. 다음 표에는 두 네트워크 플러그인에 대한 현재 기능 지원이 요약되어 있습니다.

Expand
표 25.1. 기본 CNI 네트워크 플러그인 기능 비교
기능OpenShift SDNOVN-Kubernetes

송신 IP

지원됨

지원됨

송신 방화벽

지원됨

지원됨 [1]

송신 라우터

지원됨

지원됨 [2]

하이브리드 네트워킹

지원되지 않음

지원됨

클러스터 내 통신에 대한 IPsec 암호화

지원되지 않음

지원됨

IPv4 단일 스택

지원됨

지원됨

IPv6 단일 스택

지원되지 않음

지원됨 [3]

IPv4/IPv6 dual-stack

지원되지 않음

지원됨 [4]

IPv6/IPv4 듀얼 스택

지원되지 않음

지원됨 [5]

Kubernetes 네트워크 정책

지원됨

지원됨

Kubernetes 네트워크 정책 로그

지원되지 않음

지원됨

하드웨어 오프로드

지원되지 않음

지원됨

멀티 캐스트

지원됨

지원됨

  1. 송신 방화벽은 OpenShift SDN에서 송신 네트워크 정책이라고도 합니다. 이것은 네트워크 정책 송신과 동일하지 않습니다.
  2. OVN-Kubernetes용 송신 라우터는 리디렉션 모드만 지원합니다.
  3. 베어 메탈 플랫폼의 IPv6 단일 스택 네트워킹.
  4. 베어 메탈, VMware vSphere(installer 프로비저닝 인프라 설치 전용), IBM Power® 및 IBM Z® 플랫폼의 IPv4/IPv6 듀얼 스택 네트워킹. VMware vSphere에는 듀얼 스택 네트워킹 제한 사항이 있습니다.
  5. 베어 메탈 및 IBM Power® 플랫폼의 IPv6/IPv4 듀얼 스택 네트워킹.

25.1.3. OVN-Kubernetes IPv6 및 듀얼 스택 제한 사항

OVN-Kubernetes 네트워크 플러그인에는 다음과 같은 제한 사항이 있습니다.

  • 듀얼 스택 네트워킹용으로 구성된 클러스터의 경우 IPv4 및 IPv6 트래픽 모두 기본 게이트웨이와 동일한 네트워크 인터페이스를 사용해야 합니다. 이 요구 사항이 충족되지 않으면 ovnkube-node 데몬 세트의 호스트의 Pod가 CrashLoopBackOff 상태가 됩니다. oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml 과 같은 명령으로 Pod를 표시하는 경우 status 필드에 다음 출력에 표시된 대로 기본 게이트웨이에 대한 메시지가 두 개 이상 포함됩니다.

    I1006 16:09:50.985852   60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1
    I1006 16:09:50.985923   60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4
    F1006 16:09:50.985939   60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
    Copy to Clipboard Toggle word wrap

    유일한 해결 방법은 두 IP 제품군이 기본 게이트웨이에 동일한 네트워크 인터페이스를 사용하도록 호스트 네트워킹을 재구성하는 것입니다.

  • 듀얼 스택 네트워킹용으로 구성된 클러스터의 경우 IPv4 및 IPv6 라우팅 테이블 모두에 기본 게이트웨이가 포함되어야 합니다. 이 요구 사항이 충족되지 않으면 ovnkube-node 데몬 세트의 호스트의 Pod가 CrashLoopBackOff 상태가 됩니다. oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml 과 같은 명령으로 Pod를 표시하는 경우 status 필드에 다음 출력에 표시된 대로 기본 게이트웨이에 대한 메시지가 두 개 이상 포함됩니다.

    I0512 19:07:17.589083  108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1
    F0512 19:07:17.589141  108432 ovnkube.go:133] failed to get default gateway interface
    Copy to Clipboard Toggle word wrap

    유일한 해결 방법은 두 IP 제품군에 기본 게이트웨이가 포함되도록 호스트 네트워킹을 재구성하는 것입니다.

25.1.4. 세션 선호도

세션 선호도는 Kubernetes Service 오브젝트에 적용되는 기능입니다. <service_VIP>:<Port>에 연결할 때마다 트래픽이 항상 동일한 백엔드에 분산되도록 하려면 세션 선호도를 사용할 수 있습니다. 클라이언트의 IP 주소를 기반으로 세션 선호도를 설정하는 방법을 포함한 자세한 내용은 세션 선호도를 참조하십시오.

세션 선호도에 대한 고정 시간 제한

OpenShift Container Platform의 OVN-Kubernetes 네트워크 플러그인은 마지막 패킷을 기반으로 클라이언트에서 세션에 대한 고정 제한 시간을 계산합니다. 예를 들어 curl 명령을 10번 실행하면 고정 세션 타이머가 첫 번째 패킷이 아닌 10번째 패킷에서 시작됩니다. 결과적으로 클라이언트가 서비스에 지속적으로 연결하는 경우 세션은 시간 초과되지 않습니다. 서비스가 timeoutSeconds 매개변수에 설정된 시간 양에 대한 패킷을 수신하지 않으면 시간 초과가 시작됩니다.

25.2. OVN-Kubernetes 아키텍처

25.2.1. OVN-Kubernetes 아키텍처 소개

다음 다이어그램은 OVN-Kubernetes 아키텍처를 보여줍니다.

그림 25.1. OVK-Kubernetes 아키텍처

주요 구성 요소는 다음과 같습니다.

  • CMS(Cloud Management System) - OVN 통합을 위한 CMS 특정 플러그인을 제공하는 OVN용 플랫폼 특정 클라이언트입니다. 플러그인은 CMS 고유의 형식으로 CMS 구성 데이터베이스에 저장된 클라우드 관리 시스템의 논리적 네트워크 구성 개념을 OVN에서 인식하는 중간 표현으로 변환합니다.
  • OVN Northbound 데이터베이스(nbdb) - CMS 플러그인에서 전달하는 논리 네트워크 구성을 저장합니다.
  • OVN Southbound 데이터베이스(sbdb) - 바인딩 테이블을 포함하여 각 노드의 OVS(OpenVswitch) 시스템의 물리적 및 논리적 네트워크 구성 상태를 저장합니다.
  • OVN-northd - nbdbsbdb 사이의 중간 클라이언트입니다. nbdb 에서 가져온 기존 네트워크 개념의 관점에서 논리적 네트워크 구성을 그 아래의 sbdb 의 논리 데이터 경로 흐름으로 변환합니다. 컨테이너 이름은 northd 이며 ovnkube-master Pod에서 실행됩니다.
  • OVN-controller - sbdb 에 필요한 정보 또는 업데이트에 대해 OVS 및 하이퍼바이저와 상호 작용하는 OVN 에이전트입니다. ovn-controllersbdb 에서 논리 흐름을 읽고, 이를 OpenFlow 흐름으로 변환하여 노드의 OVS 데몬으로 전송합니다. 컨테이너 이름은 ovn-controller 이며 ovnkube-node Pod에서 실행됩니다.

OVN northbound 데이터베이스에는 클라우드 관리 시스템(CMS)에 의해 전달된 논리 네트워크 구성이 있습니다. OVN northbound 데이터베이스에는 현재 원하는 네트워크 상태가 포함되며, 논리 포트, 논리 스위치, 논리 라우터 등으로 표시됩니다. ovn-northd (northd 컨테이너)는 OVN northbound 데이터베이스 및 OVN southbound 데이터베이스에 연결됩니다. OVN northbound 데이터베이스에서 가져온 기존 네트워크 개념의 관점에서 논리적 네트워크 구성을 OVN southbound 데이터베이스의 논리 데이터 경로로 변환합니다.

OVN southbound 데이터베이스에는 연결된 네트워크 및 바인딩 테이블에 대한 물리적 및 논리적 표현이 있습니다. 클러스터의 모든 노드는 southbound 데이터베이스에 표시되고 연결된 포트를 볼 수 있습니다. 또한 모든 논리 흐름이 포함되어 있으며 논리 흐름은 각 노드에서 실행되는 ovn-controller 프로세스와 공유되고 ovn-controller 는 이를 Open vSwitch 프로그램을 위해 OpenFlow 규칙으로 전환합니다.

Kubernetes 컨트롤 플레인 노드에는 각각 OVN northbound 및 southbound 데이터베이스의 컨테이너를 호스팅하는 ovnkube-master Pod가 포함되어 있습니다. 모든 OVN northbound 데이터베이스는 Raft 클러스터를 형성하고 모든 southbound 데이터베이스는 별도의 Raft 클러스터를 형성합니다. 언제든지 단일 ovnkube-master 가 리더이고 다른 ovnkube-master Pod는 팔로우입니다.

25.2.2. OVN-Kubernetes 프로젝트의 모든 리소스 나열

OVN-Kubernetes 프로젝트에서 실행되는 리소스 및 컨테이너를 찾는 것은 OVN-Kubernetes 네트워킹 구현을 이해하는 데 도움이 됩니다.

사전 요구 사항

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

절차

  1. 다음 명령을 실행하여 OVN-Kubernetes 프로젝트에서 모든 리소스, 끝점 및 ConfigMap 을 가져옵니다.

    $ oc get all,ep,cm -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       READY   STATUS    RESTARTS      AGE
    pod/ovnkube-master-9g7zt   6/6     Running   1 (48m ago)   57m
    pod/ovnkube-master-lqs4v   6/6     Running   0             57m
    pod/ovnkube-master-vxhtq   6/6     Running   0             57m
    pod/ovnkube-node-9k9kc     5/5     Running   0             57m
    pod/ovnkube-node-jg52r     5/5     Running   0             51m
    pod/ovnkube-node-k8wf7     5/5     Running   0             57m
    pod/ovnkube-node-tlwk6     5/5     Running   0             47m
    pod/ovnkube-node-xsvnk     5/5     Running   0             57m
    
    NAME                            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
    service/ovn-kubernetes-master   ClusterIP   None         <none>        9102/TCP            57m
    service/ovn-kubernetes-node     ClusterIP   None         <none>        9103/TCP,9105/TCP   57m
    service/ovnkube-db              ClusterIP   None         <none>        9641/TCP,9642/TCP   57m
    
    NAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                 AGE
    daemonset.apps/ovnkube-master   3         3         3       3            3           beta.kubernetes.io/os=linux,node-role.kubernetes.io/master=   57m
    daemonset.apps/ovnkube-node     5         5         5       5            5           beta.kubernetes.io/os=linux                                   57m
    
    NAME                              ENDPOINTS                                                        AGE
    endpoints/ovn-kubernetes-master   10.0.132.11:9102,10.0.151.18:9102,10.0.192.45:9102               57m
    endpoints/ovn-kubernetes-node     10.0.132.11:9105,10.0.143.72:9105,10.0.151.18:9105 + 7 more...   57m
    endpoints/ovnkube-db              10.0.132.11:9642,10.0.151.18:9642,10.0.192.45:9642 + 3 more...   57m
    
    NAME                                 DATA   AGE
    configmap/control-plane-status       1      55m
    configmap/kube-root-ca.crt           1      57m
    configmap/openshift-service-ca.crt   1      57m
    configmap/ovn-ca                     1      57m
    configmap/ovnkube-config             1      57m
    configmap/signer-ca                  1      57m
    Copy to Clipboard Toggle word wrap

    컨트롤 플레인 노드에서 실행되는 ovnkube-masters 3개와 ovnkube-masterovnkube-node Pod를 배포하는 데 사용되는 데몬 세트 두 개가 있습니다. 클러스터의 각 노드에 대해 하나의 ovnkube-node Pod가 있습니다. ovnkube-config ConfigMap 에는 online-master 및 ovnkube-node 에서 시작된 OpenShift Container Platform OVN-Kubernetes 구성이 있습니다.

  2. 다음 명령을 실행하여 ovnkube-master Pod의 모든 컨테이너를 나열합니다.

    $ oc get pods ovnkube-master-9g7zt \
    -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    예상 출력

    northd nbdb kube-rbac-proxy sbdb ovnkube-master ovn-dbchecker
    Copy to Clipboard Toggle word wrap

    ovnkube-master Pod는 여러 컨테이너로 구성됩니다. northbound 데이터베이스(nbdb 컨테이너), southbound 데이터베이스(sbdb 컨테이너)를 호스팅하고, Pod, egressIP, 네임스페이스, 서비스, 엔드포인트, 송신 방화벽 및 네트워크 정책에 대한 클러스터 이벤트를 조사하고 이를 northbound 데이터베이스(ovnkube-master Pod)에 쓰고 노드에 Pod 서브넷 할당을 관리합니다.

  3. 다음 명령을 실행하여 ovnkube-node Pod의 모든 컨테이너를 나열합니다.

    $ oc get pods ovnkube-node-jg52r \
    -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    예상 출력

    ovn-controller ovn-acl-logging kube-rbac-proxy kube-rbac-proxy-ovn-metrics ovnkube-node
    Copy to Clipboard Toggle word wrap

    ovnkube-node Pod에는 각 OpenShift Container Platform 노드에 있는 컨테이너(ovn-controller)가 있습니다. 각 노드의 ovn-controller 는 OVN northbound를 OVN southbound 데이터베이스에 연결하여 OVN 구성에 대해 알아봅니다. ovn-controller 는 southbound를 ovs-vswitchd 를 OpenFlow 컨트롤러로 연결하고 네트워크 트래픽을 제어하며 로컬 ovsdb-server 에 연결하여 Open vSwitch 구성을 모니터링하고 제어할 수 있습니다.

  4. 다음 명령을 실행하여 현재 선택한 OVN-Kubernetes 마스터 리더를 나열합니다.

    $ oc get lease -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    예상 출력

    NAME                    HOLDER                               AGE
    ovn-kubernetes-master   ci-ln-gz990pb-72292-rthz2-master-2   50m
    Copy to Clipboard Toggle word wrap

25.2.3. OVN-Kubernetes northbound 데이터베이스 콘텐츠 나열

논리 흐름 규칙을 이해하려면 northbound 데이터베이스를 검사하고 어떤 오브젝트가 논리 흐름 규칙으로 어떻게 변환되는지 이해해야 합니다. 최신 정보는 OVN Raft 리더에 있으며, 이 절차에서는 Raft 리더를 찾아 나중에 OVN northbound 데이터베이스 콘텐츠를 나열하는 방법을 설명합니다.

사전 요구 사항

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

절차

  1. northbound 데이터베이스의 OVN Raft 리더를 찾습니다.

    참고

    Raft 리더는 최신 정보를 가장 많이 저장합니다.

    1. 다음 명령을 실행하여 Pod를 나열합니다.

      $ oc get po -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                   READY   STATUS    RESTARTS       AGE
      ovnkube-master-7j97q   6/6     Running   2 (148m ago)   149m
      ovnkube-master-gt4ms   6/6     Running   1 (140m ago)   147m
      ovnkube-master-mk6p6   6/6     Running   0              148m
      ovnkube-node-8qvtr     5/5     Running   0              149m
      ovnkube-node-fqdc9     5/5     Running   0              149m
      ovnkube-node-tlfwv     5/5     Running   0              149m
      ovnkube-node-wlwkn     5/5     Running   0              142m
      Copy to Clipboard Toggle word wrap

    2. 무작위로 마스터 Pod 중 하나를 선택하고 다음 명령을 실행합니다.

      $ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
      -- /usr/bin/ovn-appctl -t /var/run/ovn/ovnnb_db.ctl \
      --timeout=3 cluster/status OVN_Northbound
      Copy to Clipboard Toggle word wrap

      출력 예

      Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
      1c57
      Name: OVN_Northbound
      Cluster ID: c48a (c48aa5c0-a704-4c77-a066-24fe99d9b338)
      Server ID: 1c57 (1c57b6fc-2849-49b7-8679-fbf18bafe339)
      Address: ssl:10.0.147.219:9643
      Status: cluster member
      Role: follower 
      1
      
      Term: 5
      Leader: 2b4f 
      2
      
      Vote: unknown
      
      Election timer: 10000
      Log: [2, 3018]
      Entries not yet committed: 0
      Entries not yet applied: 0
      Connections: ->0000 ->0000 <-8844 <-2b4f
      Disconnections: 0
      Servers:
          1c57 (1c57 at ssl:10.0.147.219:9643) (self)
          8844 (8844 at ssl:10.0.163.212:9643) last msg 8928047 ms ago
          2b4f (2b4f at ssl:10.0.242.240:9643) last msg 620 ms ago 
      3
      Copy to Clipboard Toggle word wrap

      1
      이 Pod는 후속 조치로 확인
      2
      리더는 2b4f로 식별됩니다.
      3
      2b4f 는 IP 주소 10.0.242.240에 있습니다.
    3. 다음 명령을 사용하여 IP 주소 10.0.242.240 에서 실행 중인 ovnkube-master Pod를 찾습니다.

      $ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.242.240 | grep -v ovnkube-node
      Copy to Clipboard Toggle word wrap

      출력 예

      ovnkube-master-gt4ms   6/6     Running             1 (143m ago)   150m   10.0.242.240   ip-10-0-242-240.ec2.internal   <none>           <none>
      Copy to Clipboard Toggle word wrap

      ovnkube-master-gt4ms Pod는 IP 주소 10.0.242.240에서 실행됩니다.

  2. 다음 명령을 실행하여 northbound 데이터베이스의 모든 오브젝트를 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
    -c northd -- ovn-nbctl show
    Copy to Clipboard Toggle word wrap

    여기에 나열하기에는 너무 긴 출력이 표시됩니다. 목록에는 NAT 규칙, 논리 스위치, 로드 밸런서 등이 포함됩니다.

    다음 명령을 실행하여 ovn-nbctl: 명령과 함께 사용 가능한 옵션을 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
    -c northd ovn-nbctl --help
    Copy to Clipboard Toggle word wrap

    다음 명령 중 일부를 사용하여 특정 구성 요소에 중점을 두고 특정 구성 요소에 중점을 둘 수 있습니다.

  3. 다음 명령을 실행하여 논리 라우터 목록을 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
    -c northd -- ovn-nbctl lr-list
    Copy to Clipboard Toggle word wrap

    출력 예

    f971f1f3-5112-402f-9d1e-48f1d091ff04 (GR_ip-10-0-145-205.ec2.internal)
    69c992d8-a4cf-429e-81a3-5361209ffe44 (GR_ip-10-0-147-219.ec2.internal)
    7d164271-af9e-4283-b84a-48f2a44851cd (GR_ip-10-0-163-212.ec2.internal)
    111052e3-c395-408b-97b2-8dd0a20a29a5 (GR_ip-10-0-165-9.ec2.internal)
    ed50ce33-df5d-48e8-8862-2df6a59169a0 (GR_ip-10-0-209-170.ec2.internal)
    f44e2a96-8d1e-4a4d-abae-ed8728ac6851 (GR_ip-10-0-242-240.ec2.internal)
    ef3d0057-e557-4b1a-b3c6-fcc3463790b0 (ovn_cluster_router)
    Copy to Clipboard Toggle word wrap

    참고

    이 출력에서 각 노드에 router이 있고 ovn_cluster_router 가 있음을 확인할 수 있습니다.

  4. 다음 명령을 실행하여 논리 스위치 목록을 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
    -c northd -- ovn-nbctl ls-list
    Copy to Clipboard Toggle word wrap

    출력 예

    82808c5c-b3bc-414a-bb59-8fec4b07eb14 (ext_ip-10-0-145-205.ec2.internal)
    3d22444f-0272-4c51-afc6-de9e03db3291 (ext_ip-10-0-147-219.ec2.internal)
    bf73b9df-59ab-4c58-a456-ce8205b34ac5 (ext_ip-10-0-163-212.ec2.internal)
    bee1e8d0-ec87-45eb-b98b-63f9ec213e5e (ext_ip-10-0-165-9.ec2.internal)
    812f08f2-6476-4abf-9a78-635f8516f95e (ext_ip-10-0-209-170.ec2.internal)
    f65e710b-32f9-482b-8eab-8d96a44799c1 (ext_ip-10-0-242-240.ec2.internal)
    84dad700-afb8-4129-86f9-923a1ddeace9 (ip-10-0-145-205.ec2.internal)
    1b7b448b-e36c-4ca3-9f38-4a2cf6814bfd (ip-10-0-147-219.ec2.internal)
    d92d1f56-2606-4f23-8b6a-4396a78951de (ip-10-0-163-212.ec2.internal)
    6864a6b2-de15-4de3-92d8-f95014b6f28f (ip-10-0-165-9.ec2.internal)
    c26bf618-4d7e-4afd-804f-1a2cbc96ec6d (ip-10-0-209-170.ec2.internal)
    ab9a4526-44ed-4f82-ae1c-e20da04947d9 (ip-10-0-242-240.ec2.internal)
    a8588aba-21da-4276-ba0f-9d68e88911f0 (join)
    Copy to Clipboard Toggle word wrap

    참고

    이 출력에서 각 노드에 대해 ext 스위치와 노드 이름 자체 및 조인 스위치를 사용한 스위치가 있음을 확인할 수 있습니다.

  5. 다음 명령을 실행하여 로드 밸런서 목록을 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-gt4ms \
    -c northd -- ovn-nbctl lb-list
    Copy to Clipboard Toggle word wrap

    출력 예

    UUID                                    LB                  PROTO      VIP                     IPs
    f0fb50f9-4968-4b55-908c-616bae4db0a2    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
    0dc42012-4f5b-432e-ae01-2cc4bfe81b00    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,169.254.169.2:6443,10.0.242.240:6443
    f7fff5d5-5eff-4a40-98b1-3a4ba8f7f69c    Service_default/    tcp        172.30.0.1:443          169.254.169.2:6443,10.0.163.212:6443,10.0.242.240:6443
    12fe57a0-50a4-4a1b-ac10-5f288badee07    Service_default/    tcp        172.30.0.1:443          10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
    3f137fbf-0b78-4875-ba44-fbf89f254cf7    Service_openshif    tcp        172.30.23.153:443       10.130.0.14:8443
    174199fe-0562-4141-b410-12094db922a7    Service_openshif    tcp        172.30.69.51:50051      10.130.0.84:50051
    5ee2d4bd-c9e2-4d16-a6df-f54cd17c9ac3    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,10.0.242.240:9001
    a056ae3d-83f8-45bc-9c80-ef89bce7b162    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,10.0.242.240:6443
    bac51f3d-9a6f-4f5e-ac02-28fd343a332a    Service_openshif    tcp        172.30.0.10:53          10.131.0.6:5353
                                                                tcp        172.30.0.10:9154        10.131.0.6:9154
    48105bbc-51d7-4178-b975-417433f9c20a    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,169.254.169.2:2379,10.0.242.240:2379
                                                                tcp        172.30.26.159:9979      10.0.147.219:9979,169.254.169.2:9979,10.0.242.240:9979
    7de2b8fc-342a-415f-ac13-1a493f4e39c0    Service_openshif    tcp        172.30.53.219:443       10.128.0.7:8443
                                                                tcp        172.30.53.219:9192      10.128.0.7:9192
    2cef36bc-d720-4afb-8d95-9350eff1d27a    Service_openshif    tcp        172.30.81.66:443        10.128.0.23:8443
    365cb6fb-e15e-45a4-a55b-21868b3cf513    Service_openshif    tcp        172.30.96.51:50051      10.130.0.19:50051
    41691cbb-ec55-4cdb-8431-afce679c5e8d    Service_openshif    tcp        172.30.98.218:9099      169.254.169.2:9099
    82df10ba-8143-400b-977a-8f5f416a4541    Service_openshif    tcp        172.30.26.159:2379      10.0.147.219:2379,10.0.163.212:2379,169.254.169.2:2379
                                                                tcp        172.30.26.159:9979      10.0.147.219:9979,10.0.163.212:9979,169.254.169.2:9979
    debe7f3a-39a8-490e-bc0a-ebbfafdffb16    Service_openshif    tcp        172.30.23.244:443       10.128.0.48:8443,10.129.0.27:8443,10.130.0.45:8443
    8a749239-02d9-4dc2-8737-716528e0da7b    Service_openshif    tcp        172.30.124.255:8443     10.128.0.14:8443
    880c7c78-c790-403d-a3cb-9f06592717a3    Service_openshif    tcp        172.30.0.10:53          10.130.0.20:5353
                                                                tcp        172.30.0.10:9154        10.130.0.20:9154
    d2f39078-6751-4311-a161-815bbaf7f9c7    Service_openshif    tcp        172.30.26.159:2379      169.254.169.2:2379,10.0.163.212:2379,10.0.242.240:2379
                                                                tcp        172.30.26.159:9979      169.254.169.2:9979,10.0.163.212:9979,10.0.242.240:9979
    30948278-602b-455c-934a-28e64c46de12    Service_openshif    tcp        172.30.157.35:9443      10.130.0.43:9443
    2cc7e376-7c02-4a82-89e8-dfa1e23fb003    Service_openshif    tcp        172.30.159.212:17698    10.128.0.48:17698,10.129.0.27:17698,10.130.0.45:17698
    e7d22d35-61c2-40c2-bc30-265cff8ed18d    Service_openshif    tcp        172.30.143.87:9001      10.0.145.205:9001,10.0.147.219:9001,10.0.163.212:9001,10.0.165.9:9001,10.0.209.170:9001,169.254.169.2:9001
    75164e75-e0c5-40fb-9636-bfdbf4223a02    Service_openshif    tcp        172.30.150.68:1936      10.129.4.8:1936,10.131.0.10:1936
                                                                tcp        172.30.150.68:443       10.129.4.8:443,10.131.0.10:443
                                                                tcp        172.30.150.68:80        10.129.4.8:80,10.131.0.10:80
    7bc4ee74-dccf-47e9-9149-b011f09aff39    Service_openshif    tcp        172.30.164.74:443       10.0.147.219:6443,10.0.163.212:6443,169.254.169.2:6443
    0db59e74-1cc6-470c-bf44-57c520e0aa8f    Service_openshif    tcp        10.0.163.212:31460
                                                                tcp        10.0.163.212:32361
    c300e134-018c-49af-9f84-9deb1d0715f8    Service_openshif    tcp        172.30.42.244:50051     10.130.0.47:50051
    5e352773-429b-4881-afb3-a13b7ba8b081    Service_openshif    tcp        172.30.244.66:443       10.129.0.8:8443,10.130.0.8:8443
    54b82d32-1939-4465-a87d-f26321442a7a    Service_openshif    tcp        172.30.12.9:8443        10.128.0.35:8443
    Copy to Clipboard Toggle word wrap

    참고

    이 잘린 출력에서 많은 OVN-Kubernetes 로드 밸런서가 있음을 확인할 수 있습니다. OVN-Kubernetes의 로드 밸런서는 서비스를 나타냅니다.

다음 표에서는 ovn-nbctl 과 함께 사용하여 northbound 데이터베이스의 콘텐츠를 검사할 수 있는 명령줄 인수를 설명합니다.

Expand
표 25.2. northbound 데이터베이스 콘텐츠를 검사하기 위한 명령줄 인수
인수설명

OVN-nbctl show

northbound 데이터베이스 콘텐츠의 개요입니다.

ovn-nbctl show <switch_or_router>

지정된 스위치 또는 라우터와 연결된 세부 정보를 표시합니다.

ovn-nbctl lr-list

논리 라우터를 표시합니다.

ovn-nbctl lrp-list <router>

ovn-nbctl lr-list 의 라우터 정보를 사용하여 라우터 포트를 표시합니다.

ovn-nbctl lr-nat-list <router>

지정된 라우터의 네트워크 주소 변환 세부 정보를 표시합니다.

ovn-nbctl ls-list

논리 스위치 표시

ovn-nbctl lsp-list <switch>

ovn-nbctl ls-list 의 스위치 정보를 사용하여 스위치 포트를 표시합니다.

ovn-nbctl lsp-get-type <port>

논리 포트의 유형을 가져옵니다.

ovn-nbctl lb-list

로드 밸런서를 표시합니다.

25.2.5. OVN-Kubernetes southbound 데이터베이스 콘텐츠 나열

논리 흐름 규칙은 인프라를 나타내는 southbound 데이터베이스에 저장됩니다. 최신 정보는 OVN Raft 리더에 있으며, 이 절차에서는 Raft 리더를 찾아 쿼리하여 OVN southbound 데이터베이스 콘텐츠를 나열하는 방법을 설명합니다.

사전 요구 사항

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

절차

  1. southbound 데이터베이스의 OVN Raft 리더를 찾습니다.

    참고

    Raft 리더는 최신 정보를 가장 많이 저장합니다.

    1. 다음 명령을 실행하여 Pod를 나열합니다.

      $ oc get po -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                   READY   STATUS    RESTARTS       AGE
      ovnkube-master-7j97q   6/6     Running   2 (134m ago)   135m
      ovnkube-master-gt4ms   6/6     Running   1 (126m ago)   133m
      ovnkube-master-mk6p6   6/6     Running   0              134m
      ovnkube-node-8qvtr     5/5     Running   0              135m
      ovnkube-node-bqztb     5/5     Running   0              117m
      ovnkube-node-fqdc9     5/5     Running   0              135m
      ovnkube-node-tlfwv     5/5     Running   0              135m
      ovnkube-node-wlwkn     5/5     Running   0              128m
      Copy to Clipboard Toggle word wrap

    2. 임의로 마스터 Pod 중 하나를 선택하고 다음 명령을 실행하여 OVN southbound Raft 리더를 찾습니다.

      $ oc exec -n openshift-ovn-kubernetes ovnkube-master-7j97q \
      -- /usr/bin/ovn-appctl -t /var/run/ovn/ovnsb_db.ctl \
      --timeout=3 cluster/status OVN_Southbound
      Copy to Clipboard Toggle word wrap

      출력 예

      Defaulted container "northd" out of: northd, nbdb, kube-rbac-proxy, sbdb, ovnkube-master, ovn-dbchecker
      1930
      Name: OVN_Southbound
      Cluster ID: f772 (f77273c0-7986-42dd-bd3c-a9f18e25701f)
      Server ID: 1930 (1930f4b7-314b-406f-9dcb-b81fe2729ae1)
      Address: ssl:10.0.147.219:9644
      Status: cluster member
      Role: follower 
      1
      
      Term: 3
      Leader: 7081 
      2
      
      Vote: unknown
      
      Election timer: 16000
      Log: [2, 2423]
      Entries not yet committed: 0
      Entries not yet applied: 0
      Connections: ->0000 ->7145 <-7081 <-7145
      Disconnections: 0
      Servers:
          7081 (7081 at ssl:10.0.163.212:9644) last msg 59 ms ago 
      3
      
          1930 (1930 at ssl:10.0.147.219:9644) (self)
          7145 (7145 at ssl:10.0.242.240:9644) last msg 7871735 ms ago
      Copy to Clipboard Toggle word wrap

      1
      이 Pod는 후속 조치로 확인
      2
      리더는 7081로 식별됩니다.
      3
      7081 IP 주소 10.0.163.212
    3. 다음 명령을 사용하여 IP 주소 10.0.163.212 에서 실행 중인 ovnkube-master Pod를 찾습니다.

      $ oc get po -o wide -n openshift-ovn-kubernetes | grep 10.0.163.212 | grep -v ovnkube-node
      Copy to Clipboard Toggle word wrap

      출력 예

      ovnkube-master-mk6p6   6/6     Running   0              136m   10.0.163.212   ip-10-0-163-212.ec2.internal   <none>           <none>
      Copy to Clipboard Toggle word wrap

      ovnkube-master-mk6p6 Pod는 IP 주소 10.0.163.212에서 실행됩니다.

  2. 다음 명령을 실행하여 southbound 데이터베이스에 저장된 모든 정보를 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
    -c northd -- ovn-sbctl show
    Copy to Clipboard Toggle word wrap

    출력 예

    Chassis "8ca57b28-9834-45f0-99b0-96486c22e1be"
        hostname: ip-10-0-156-16.ec2.internal
        Encap geneve
            ip: "10.0.156.16"
            options: {csum="true"}
        Port_Binding k8s-ip-10-0-156-16.ec2.internal
        Port_Binding etor-GR_ip-10-0-156-16.ec2.internal
        Port_Binding jtor-GR_ip-10-0-156-16.ec2.internal
        Port_Binding openshift-ingress-canary_ingress-canary-hsblx
        Port_Binding rtoj-GR_ip-10-0-156-16.ec2.internal
        Port_Binding openshift-monitoring_prometheus-adapter-658fc5967-9l46x
        Port_Binding rtoe-GR_ip-10-0-156-16.ec2.internal
        Port_Binding openshift-multus_network-metrics-daemon-77nvz
        Port_Binding openshift-ingress_router-default-64fd8c67c7-df598
        Port_Binding openshift-dns_dns-default-ttpcq
        Port_Binding openshift-monitoring_alertmanager-main-0
        Port_Binding openshift-e2e-loki_loki-promtail-g2pbh
        Port_Binding openshift-network-diagnostics_network-check-target-m6tn4
        Port_Binding openshift-monitoring_thanos-querier-75b5cf8dcb-qf8qj
        Port_Binding cr-rtos-ip-10-0-156-16.ec2.internal
        Port_Binding openshift-image-registry_image-registry-7b7bc44566-mp9b8
    Copy to Clipboard Toggle word wrap

    이 상세 출력에서는 섀시 및 섀시에 연결된 포트를 보여줍니다. 이 경우 모든 라우터 포트와 호스트 네트워킹과 같이 실행되는 모든 항목이 있습니다. 모든 pod는 소스 네트워크 주소 변환(SNAT)을 사용하여 더 광범위한 네트워크와 통신합니다. 해당 IP 주소는 포드가 실행 중인 노드의 IP 주소로 변환된 다음 네트워크로 전송됩니다.

    southbound 데이터베이스에 있는 섀시 정보 외에도 southbound 데이터베이스에는 모든 논리 흐름이 있으며 이러한 논리 흐름은 각 노드에서 실행되는 ovn-controller 로 전송됩니다. ovn-controller 는 논리를 공개 흐름 규칙으로 변환하고 궁극적으로 OpenvSwitch 를 프로그램하여 pod가 열린 흐름 규칙을 따르고 네트워크에서 제외할 수 있도록 합니다.

    다음 명령을 실행하여 ovn-sbctl 명령과 함께 사용할 수 있는 옵션을 표시합니다.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-master-mk6p6 \
    -c northd -- ovn-sbctl --help
    Copy to Clipboard Toggle word wrap

다음 표에서는 ovn-sbctl 과 함께 southbound 데이터베이스의 콘텐츠를 검사하는 데 사용할 수 있는 명령줄 인수를 설명합니다.

Expand
표 25.3. southbound 데이터베이스 콘텐츠를 검사하기 위한 명령줄 인수
인수설명

OVN-sbctl show

southbound 데이터베이스 콘텐츠의 개요입니다.

OVN-sbctl list Port_Binding <port>

지정된 포트에 대한 southbound 데이터베이스의 콘텐츠를 나열합니다.

ovn-sbctl dump-flows

논리 흐름을 나열합니다.

25.2.7. OVN-Kubernetes 논리 아키텍처

OVN은 네트워크 가상화 솔루션입니다. 논리 스위치 및 라우터를 생성합니다. 이러한 스위치 및 라우터는 네트워크 토폴로지를 생성하기 위해 조정됩니다. 2 또는 5로 설정된 로그 수준을 사용하여 ovnkube-trace 를 실행하면 OVN-Kubernetes 논리 구성 요소가 노출됩니다. 다음 다이어그램에서는 OpenShift Container Platform에서 라우터 및 스위치를 연결하는 방법을 보여줍니다.

그림 25.2. OVN-Kubernetes 라우터 및 스위치 구성 요소

패킷 처리와 관련된 주요 구성 요소는 다음과 같습니다.

게이트웨이 라우터
일반적으로 L3 게이트웨이 라우터라고 하는 게이트웨이 라우터는 일반적으로 분산 라우터와 물리적 네트워크 간에 사용됩니다. 논리 패치 포트를 포함하는 게이트웨이 라우터는 물리적 위치(분산되지 않음) 또는 섀시에 바인딩됩니다. 이 라우터의 패치 포트는 ovn-southbound 데이터베이스(ovn-sbdb)의 l3gateway 포트라고 합니다.
분산 논리 라우터
가상 시스템과 컨테이너가 연결되는 분산 논리 라우터와 논리 스위치는 각 하이퍼바이저에 효과적으로 상주합니다.
로컬 스위치에 가입
로컬 스위치 조인은 분산 라우터 및 게이트웨이 라우터를 연결하는 데 사용됩니다. 분산 라우터에 필요한 IP 주소 수를 줄입니다.
패치 포트가 있는 논리 스위치
패치 포트가 있는 논리 스위치는 네트워크 스택을 가상화하는 데 사용됩니다. 원격 논리 포트를 터널을 통해 연결합니다.
localnet 포트가 있는 논리 스위치
localnet 포트가 있는 논리 스위치는 OVN을 물리적 네트워크에 연결하는 데 사용됩니다. 로컬넷 포트를 사용하여 직접 연결된 물리적 L2 세그먼트에 패킷을 브리징하여 원격 논리 포트를 연결합니다.
패치 포트
패치 포트는 논리 스위치와 논리 라우터 간 연결과 피어 논리 라우터 간 연결을 나타냅니다. 단일 연결에는 이러한 연결 지점마다 한 쌍의 패치 포트가 있으며 각 포트에 하나씩 있습니다.
l3gateway 포트
l3gateway 포트는 게이트웨이 라우터에 사용되는 논리 패치 포트용 ovn-sbdb 의 포트 바인딩 항목입니다. 이러한 포트는 게이트웨이 라우터 자체와 마찬가지로 섀시에 바인딩되어 있다는 팩트를 포트하기 위해 패치 포트가 아닌 l3gateway 포트라고 합니다.
localnet 포트
ovn-controller 인스턴스에서 로컬 액세스 네트워크에 연결할 수 있는 브리지된 논리 스위치에 localnet 포트가 있습니다. 이를 통해 논리 스위치에서 물리적 네트워크에 직접 연결할 수 있습니다. 논리 스위치는 단일 localnet 포트만 연결할 수 있습니다.
25.2.7.1. 로컬 호스트에 network-tools 설치

로컬 호스트에 network-tools 를 설치하여 OpenShift Container Platform 클러스터 네트워크 문제를 디버깅하는 데 필요한 툴 컬렉션을 사용할 수 있도록 합니다.

프로세스

  1. 다음 명령을 사용하여 network-tools 리포지토리를 워크스테이션에 복제합니다.

    $ git clone git@github.com:openshift/network-tools.git
    Copy to Clipboard Toggle word wrap
  2. 방금 복제한 리포지토리의 디렉터리로 변경합니다.

    $ cd network-tools
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 사용 가능한 모든 명령을 나열합니다.

    $ ./debug-scripts/network-tools -h
    Copy to Clipboard Toggle word wrap
25.2.7.2. network-tools 실행

network-tools 를 실행하여 논리 스위치 및 라우터에 대한 정보를 가져옵니다.

사전 요구 사항

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

프로세스

  1. 다음 명령을 실행하여 라우터를 나열합니다.

    $ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
    Copy to Clipboard Toggle word wrap

    출력 예

    Leader pod is ovnkube-master-vslqm
    5351ddd1-f181-4e77-afc6-b48b0a9df953 (GR_helix13.lab.eng.tlv2.redhat.com)
    ccf9349e-1948-4df8-954e-39fb0c2d4d06 (GR_helix14.lab.eng.tlv2.redhat.com)
    e426b918-75a8-4220-9e76-20b7758f92b7 (GR_hlxcl7-master-0.hlxcl7.lab.eng.tlv2.redhat.com)
    dded77c8-0cc3-4b99-8420-56cd2ae6a840 (GR_hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com)
    4f6747e6-e7ba-4e0c-8dcd-94c8efa51798 (GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com)
    52232654-336e-4952-98b9-0b8601e370b4 (ovn_cluster_router)
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 로컬net 포트를 나열합니다.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=localnet
    Copy to Clipboard Toggle word wrap

    출력 예

    Leader pod is ovnkube-master-vslqm
    _uuid               : 3de79191-cca8-4c28-be5a-a228f0f9ebfc
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : 3f1a4928-7ff5-471f-9092-fe5f5c67d15c
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : br-ex_helix13.lab.eng.tlv2.redhat.com
    mac                 : [unknown]
    nat_addresses       : []
    options             : {network_name=physnet}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 2
    type                : localnet
    up                  : false
    virtual_parent      : []
    
    _uuid               : dbe21daf-9594-4849-b8f0-5efbfa09a455
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : br-ex_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
    mac                 : [unknown]
    nat_addresses       : []
    options             : {network_name=physnet}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 2
    type                : localnet
    up                  : false
    virtual_parent      : []
    
    [...]
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 l3gateway 포트를 나열합니다.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=l3gateway
    Copy to Clipboard Toggle word wrap

    출력 예

    Leader pod is ovnkube-master-vslqm
    _uuid               : 9314dc80-39e1-4af7-9cc0-ae8a9708ed59
    additional_chassis  : []
    additional_encap    : []
    chassis             : 336a923d-99e8-4e71-89a6-12564fde5760
    datapath            : db2a6067-fe7c-4d11-95a7-ff2321329e11
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : etor-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com
    mac                 : ["52:54:00:3e:95:d3"]
    nat_addresses       : ["52:54:00:3e:95:d3 10.46.56.77"]
    options             : {l3gateway-chassis="7eb1f1c3-87c2-4f68-8e89-60f5ca810971", peer=rtoe-GR_hlxcl7-master-2.hlxcl7.lab.eng.tlv2.redhat.com}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 1
    type                : l3gateway
    up                  : true
    virtual_parent      : []
    
    _uuid               : ad7eb303-b411-4e9f-8d36-d07f1f268e27
    additional_chassis  : []
    additional_encap    : []
    chassis             : f41453b8-29c5-4f39-b86b-e82cf344bce4
    datapath            : 082e7a60-d9c7-464b-b6ec-117d3426645a
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : etor-GR_helix14.lab.eng.tlv2.redhat.com
    mac                 : ["34:48:ed:f3:e2:2c"]
    nat_addresses       : ["34:48:ed:f3:e2:2c 10.46.56.14"]
    options             : {l3gateway-chassis="2e8abe3a-cb94-4593-9037-f5f9596325e2", peer=rtoe-GR_helix14.lab.eng.tlv2.redhat.com}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 1
    type                : l3gateway
    up                  : true
    virtual_parent      : []
    
    [...]
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 패치 포트를 나열합니다.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=patch
    Copy to Clipboard Toggle word wrap

    출력 예

    Leader pod is ovnkube-master-vslqm
    _uuid               : c48b1380-ff26-4965-a644-6bd5b5946c61
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : 72734d65-fae1-4bd9-a1ee-1bf4e085a060
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : jtor-ovn_cluster_router
    mac                 : [router]
    nat_addresses       : []
    options             : {peer=rtoj-ovn_cluster_router}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 4
    type                : patch
    up                  : false
    virtual_parent      : []
    
    _uuid               : 5df51302-f3cd-415b-a059-ac24389938f7
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : 0551c90f-e891-4909-8e9e-acc7909e06d0
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com
    mac                 : ["0a:58:0a:82:00:01 10.130.0.1/23"]
    nat_addresses       : []
    options             : {chassis-redirect-port=cr-rtos-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com, peer=stor-hlxcl7-master-1.hlxcl7.lab.eng.tlv2.redhat.com}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 4
    type                : patch
    up                  : false
    virtual_parent      : []
    
    [...]
    Copy to Clipboard Toggle word wrap

25.3. OVN-Kubernetes 문제 해결

OVN-Kubernetes에는 여러 가지 기본 상태 점검 및 로그 소스가 있습니다.

25.3.1. 준비 상태 프로브를 사용하여 OVN-Kubernetes 상태 모니터링

ovnkube-masterovnkube-node Pod에는 준비 프로브로 컨테이너가 구성되어 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • jq를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 ovnkube-master 준비 상태 프로브의 세부 정보를 검토합니다.

    $ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
    -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
    Copy to Clipboard Toggle word wrap

    ovnkube-master Pod의 northbound 및 southbound 데이터베이스 컨테이너에 대한 준비 상태 프로브는 데이터베이스를 호스팅하는 Raft 클러스터의 상태를 확인합니다.

  2. 다음 명령을 실행하여 ovnkube-node 준비 상태 프로브의 세부 정보를 검토합니다.

    $ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master \
    -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
    Copy to Clipboard Toggle word wrap

    ovnkube-node Pod의 ovnkube-node 컨테이너에는 ovn-kubernetes CNI 구성 파일이 있는지 확인하기 위한 준비 상태 프로브가 있으며 Pod가 실행 중이 아니거나 Pod 구성 요청을 수락할 준비가 되어 있지 않음을 나타냅니다.

  3. 다음 명령을 사용하여 네임스페이스에 대한 프로브 오류를 포함하여 모든 이벤트를 표시합니다.

    $ oc get events -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
  4. 이 Pod에만 대한 이벤트를 표시합니다.

    $ oc describe pod ovnkube-master-tp2z8 -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
  5. 클러스터 네트워크 Operator의 메시지 및 상태를 표시합니다.

    $ oc get co/network -o json | jq '.status.conditions[]'
    Copy to Clipboard Toggle word wrap
  6. 다음 스크립트를 실행하여 ovnkube-master Pod에서 각 컨테이너의 준비 상태를 표시합니다.

    $ for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
    -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===;  \
    oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \
    done
    Copy to Clipboard Toggle word wrap
    참고

    모든 컨테이너 상태가 true 로 보고될 것으로 예상합니다. 준비 상태 프로브가 실패하면 상태가 false 로 설정됩니다.

25.3.2. 콘솔에서 OVN-Kubernetes 경고 보기

경고 UI는 경고 및 관리 경고 규칙과 음소거에 대한 자세한 정보를 제공합니다.

사전 요구 사항

  • 개발자로 또는 메트릭을 확인하는 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스(UI)

  1. 관리자 관점에서 모니터링경고를 선택합니다. 이 관점에서 경고 UI의 세 가지 주요 페이지는 경고, 음소거경고 규칙 페이지입니다.
  2. 모니터링 → 경고 → 경고 규칙을 선택하여 OVN -Kubernetes 경고 규칙을 확인합니다.

25.3.3. CLI에서 OVN-Kubernetes 경고 보기

명령줄에서 경고 및 관리 경고 규칙 및 음소거에 대한 정보를 가져올 수 있습니다.

사전 요구 사항

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

프로세스

  1. 다음 명령을 실행하여 활성 또는 실행 경고를 확인합니다.

    1. 다음 명령을 실행하여 경고 관리자 경로 환경 변수를 설정합니다.

      $ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \
      -o jsonpath='{@.spec.host}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 특정 필드를 요청하는 올바른 권한 부여 세부 정보를 사용하여 경고 관리자 경로 API에 curl 요청을 실행합니다.

      $ curl -s -k -H "Authorization: Bearer \
      $(oc create token prometheus-k8s -n openshift-monitoring)" \
      https://$ALERT_MANAGER/api/v1/alerts \
      | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'
      Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 경고 규칙을 확인합니다.

    $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'
    Copy to Clipboard Toggle word wrap

25.3.4. CLI를 사용하여 OVN-Kubernetes 로그 보기

OpenShift CLI(oc)를 사용하여 ovnkube-masterovnkube-node Pod에서 각 Pod의 로그를 볼 수 있습니다.

사전 요구 사항

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

프로세스

  1. 특정 Pod의 로그를 확인합니다.

    $ oc logs -f <pod_name> -c <container_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    -f
    선택 사항: 출력에서 로그에 기록되는 내용을 따르도록 지정합니다.
    <pod_name>
    pod 이름을 지정합니다.
    <container_name>
    선택 사항: 컨테이너의 이름을 지정합니다. Pod에 여러 컨테이너가 있는 경우 컨테이너 이름을 지정해야 합니다.
    <namespace>
    Pod가 실행 중인 네임스페이스를 지정합니다.

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

    $ oc logs ovnkube-master-7h4q7 -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
    $ oc logs -f ovnkube-master-7h4q7 -n openshift-ovn-kubernetes -c ovn-dbchecker
    Copy to Clipboard Toggle word wrap

    로그 파일의 내용이 출력됩니다.

  2. ovnkube-master Pod의 모든 컨테이너에서 최신 항목을 검사합니다.

    $ for p in $(oc get pods --selector app=ovnkube-master -n openshift-ovn-kubernetes \
    -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \
    do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \
    -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \
    oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 ovnkube-master Pod의 모든 컨테이너에 있는 모든 로그의 마지막 5행을 확인합니다.

    $ oc logs -l app=ovnkube-master -n openshift-ovn-kubernetes --all-containers --tail 5
    Copy to Clipboard Toggle word wrap

25.3.5. 웹 콘솔을 사용하여 OVN-Kubernetes 로그 보기

웹 콘솔에서 ovnkube-masterovnkube-node Pod에서 각 Pod의 로그를 볼 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.

프로세스

  1. OpenShift Container Platform 콘솔에서 워크로드Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.
  2. 드롭다운 메뉴에서 openshift-ovn-kubernetes 프로젝트를 선택합니다.
  3. 조사할 Pod 이름을 클릭합니다.
  4. 로그를 클릭합니다. 기본적으로 ovnkube-master 의 경우 northd 컨테이너와 연결된 로그가 표시됩니다.
  5. 다운 다운 메뉴를 사용하여 각 컨테이너의 로그를 차례로 선택합니다.
25.3.5.1. OVN-Kubernetes 로그 수준 변경

OVN-Kubernetes의 기본 로그 수준은 2입니다. OVN-Kubernetes를 디버깅하려면 로그 수준을 5로 설정합니다. 문제를 디버깅하는 데 도움이 되도록 OVN-Kubernetes의 로그 수준을 늘리려면 다음 절차를 따르십시오.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 OVN-Kubernetes 프로젝트의 모든 Pod에 대한 자세한 정보를 가져옵니다.

    $ oc get po -o wide -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                   READY   STATUS    RESTARTS      AGE   IP             NODE                           NOMINATED NODE   READINESS GATES
    ovnkube-master-84nc9   6/6     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>
    ovnkube-master-gmlqv   6/6     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
    ovnkube-master-nhts2   6/6     Running   1 (48m ago)   50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
    ovnkube-node-2cbh8     5/5     Running   0             43m   10.0.217.114   ip-10-0-217-114.ec2.internal   <none>           <none>
    ovnkube-node-6fvzl     5/5     Running   0             50m   10.0.147.31    ip-10-0-147-31.ec2.internal    <none>           <none>
    ovnkube-node-f4lzz     5/5     Running   0             24m   10.0.146.76    ip-10-0-146-76.ec2.internal    <none>           <none>
    ovnkube-node-jf67d     5/5     Running   0             50m   10.0.209.180   ip-10-0-209-180.ec2.internal   <none>           <none>
    ovnkube-node-np9mf     5/5     Running   0             40m   10.0.165.191   ip-10-0-165-191.ec2.internal   <none>           <none>
    ovnkube-node-qjldg     5/5     Running   0             50m   10.0.134.156   ip-10-0-134-156.ec2.internal   <none>           <none>
    Copy to Clipboard Toggle word wrap

  2. 다음 예제와 유사한 ConfigMap 파일을 생성하고 env-overrides.yaml 과 같은 파일 이름을 사용합니다.

    ConfigMap 파일 예

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: env-overrides
      namespace: openshift-ovn-kubernetes
    data:
      ip-10-0-217-114.ec2.internal: | 
    1
    
        # This sets the log level for the ovn-kubernetes node process:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for ovn-controller:
        OVN_LOG_LEVEL=dbg
      ip-10-0-209-180.ec2.internal: |
        # This sets the log level for the ovn-kubernetes node process:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for ovn-controller:
        OVN_LOG_LEVEL=dbg
      _master: | 
    2
    
        # This sets the log level for the ovn-kubernetes master process as well as the ovn-dbchecker:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for northd, nbdb and sbdb on all masters:
        OVN_LOG_LEVEL=dbg
    Copy to Clipboard Toggle word wrap

    1
    디버그 로그 수준을 설정할 노드의 이름을 지정합니다.
    2
    ovnkube-master 구성 요소의 로그 수준을 설정하려면 _master 를 지정합니다.
  3. 다음 명령을 사용하여 ConfigMap 파일을 적용합니다.

    $ oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    configmap/env-overrides.yaml created
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 사용하여 ovnkube Pod를 다시 시작하여 새 로그 수준을 적용합니다.

    $ oc delete pod -n openshift-ovn-kubernetes \
    --field-selector spec.nodeName=ip-10-0-217-114.ec2.internal -l app=ovnkube-node
    Copy to Clipboard Toggle word wrap
    $ oc delete pod -n openshift-ovn-kubernetes \
    --field-selector spec.nodeName=ip-10-0-209-180.ec2.internal -l app=ovnkube-node
    Copy to Clipboard Toggle word wrap
    $ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-master
    Copy to Clipboard Toggle word wrap

25.3.6. OVN-Kubernetes Pod 네트워크 연결 확인

OpenShift Container Platform 4.10 이상에서 연결 확인 컨트롤러는 클러스터의 연결 확인 검사를 오케스트레이션합니다. 여기에는 Kubernetes API, OpenShift API 및 개별 노드가 포함됩니다. 연결 테스트의 결과는 openshift-network-diagnosticsPodNetworkConnectivity 오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.

사전 요구 사항

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

프로세스

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

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 사용하여 각 연결 오브젝트의 최신 성공 상태를 확인합니다.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 각 연결 오브젝트의 최근 실패를 확인합니다.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 사용하여 각 연결 오브젝트의 최근 중단을 확인합니다.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
    Copy to Clipboard Toggle word wrap

    연결 확인 컨트롤러는 이러한 확인 지표의 메트릭도 Prometheus에 기록합니다.

  5. 다음 명령을 실행하여 모든 메트릭을 확인합니다.

    $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
    promtool query instant  http://localhost:9090 \
    '{component="openshift-network-diagnostics"}'
    Copy to Clipboard Toggle word wrap
  6. 최근 5분 동안 소스 Pod와 openshift api 서비스 간 대기 시간을 확인합니다.

    $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
    promtool query instant  http://localhost:9090 \
    '{component="openshift-network-diagnostics"}'
    Copy to Clipboard Toggle word wrap

25.4. ovnkube-trace를 사용하여 Openflow 추적

OVN 및 OVS 트래픽 흐름은 ovnkube-trace 라는 단일 유틸리티에서 시뮬레이션할 수 있습니다. ovnkube-trace 유틸리티는 ovn-trace,ovs-appctl ofproto/traceovn-detrace 를 실행하고 단일 출력에서 해당 정보와 관련이 있습니다.

전용 컨테이너에서 ovnkube-trace 바이너리를 실행할 수 있습니다. OpenShift Container Platform 4.7 이후 릴리스의 경우 바이너리를 로컬 호스트에 복사하여 해당 호스트에서 실행할 수도 있습니다.

참고

Quay 이미지의 바이너리는 현재 듀얼 IP 스택 또는 IPv6 환경에서만 작동하지 않습니다. 이러한 환경의 경우 소스에서 빌드해야 합니다.

25.4.1. 로컬 호스트에 ovnkube-trace 설치

ovnkube-trace 툴은 OVN-Kubernetes 기반 OpenShift Container Platform 클러스터의 지점 간 임의의 UDP 또는 TCP 트래픽에 대한 패킷 시뮬레이션을 추적합니다. ovnkube-trace 바이너리를 로컬 호스트에 복사하여 클러스터에 대해 실행할 수 있도록 합니다.

사전 요구 사항

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

프로세스

  1. 다음 명령을 사용하여 Pod 변수를 생성합니다.

    $  POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-master -o name | head -1 | awk -F '/' '{print $NF}')
    Copy to Clipboard Toggle word wrap
  2. 로컬 호스트에서 다음 명령을 실행하여 ovnkube-master Pod에서 바이너리를 복사합니다.

    $  oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace ovnkube-trace
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 ovnkube-trace 를 실행 가능하게 만듭니다.

    $  chmod +x ovnkube-trace
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 ovnkube-trace 에서 사용할 수 있는 옵션을 표시합니다.

    $  ./ovnkube-trace -help
    Copy to Clipboard Toggle word wrap

    예상 출력

    I0111 15:05:27.973305  204872 ovs.go:90] Maximum command line arguments set to: 191102
    Usage of ./ovnkube-trace:
      -dst string
        	dest: destination pod name
      -dst-ip string
        	destination IP address (meant for tests to external targets)
      -dst-namespace string
        	k8s namespace of dest pod (default "default")
      -dst-port string
        	dst-port: destination port (default "80")
      -kubeconfig string
        	absolute path to the kubeconfig file
      -loglevel string
        	loglevel: klog level (default "0")
      -ovn-config-namespace string
        	namespace used by ovn-config itself
      -service string
        	service: destination service name
      -skip-detrace
        	skip ovn-detrace command
      -src string
        	src: source pod name
      -src-namespace string
        	k8s namespace of source pod (default "default")
      -tcp
        	use tcp transport protocol
      -udp
        	use udp transport protocol
    Copy to Clipboard Toggle word wrap

    지원되는 명령줄 인수는 네임스페이스, pod, 서비스와 같은 친숙한 Kubernetes 구조이므로 MAC 주소, 대상 노드의 IP 주소 또는 ICMP 유형을 찾을 필요가 없습니다.

    로그 수준은 다음과 같습니다.

    • 0 (최소 출력)
    • 2 (추적 명령 결과를 보여주는 자세한 출력)
    • 5 (디버그 출력)

25.4.2. ovnkube-trace 실행

ovn-trace 를 실행하여 OVN 논리 네트워크 내에서 패킷 전달을 시뮬레이션합니다.

사전 요구 사항

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

예: 배포된 Pod에서 DNS 확인이 작동하는 테스트

이 예제에서는 배포된 Pod에서 클러스터에서 실행되는 코어 DNS pod로의 DNS 확인을 테스트하는 방법을 보여줍니다.

프로세스

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. openshift-dns 네임스페이스에서 실행 중인 Pod를 나열합니다.

    oc get pods -n openshift-dns
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                  READY   STATUS    RESTARTS   AGE
    dns-default-467qw     2/2     Running   0          49m
    dns-default-6prvx     2/2     Running   0          53m
    dns-default-fkqr8     2/2     Running   0          53m
    dns-default-qv2rg     2/2     Running   0          49m
    dns-default-s29vr     2/2     Running   0          49m
    dns-default-vdsbn     2/2     Running   0          53m
    node-resolver-6thtt   1/1     Running   0          53m
    node-resolver-7ksdn   1/1     Running   0          49m
    node-resolver-8sthh   1/1     Running   0          53m
    node-resolver-c5ksw   1/1     Running   0          50m
    node-resolver-gbvdp   1/1     Running   0          53m
    node-resolver-sxhkd   1/1     Running   0          50m
    Copy to Clipboard Toggle word wrap

  3. 다음 ovn-kube-trace 명령을 실행하여 DNS 확인이 작동하는지 확인합니다.

    $ ./ovnkube-trace \
      -src-namespace default \ 
    1
    
      -src web \ 
    2
    
      -dst-namespace openshift-dns \ 
    3
    
      -dst dns-default-467qw \ 
    4
    
      -udp -dst-port 53 \ 
    5
    
      -loglevel 0 
    6
    Copy to Clipboard Toggle word wrap
    1
    소스 Pod의 네임스페이스
    2
    소스 Pod 이름
    3
    대상 Pod의 네임스페이스
    4
    대상 Pod 이름
    5
    udp 전송 프로토콜을 사용합니다. 포트 53은 DNS 서비스에서 사용하는 포트입니다.
    6
    로그 수준을 1로 설정합니다(최소한 및 5는 디버그).

    예상 출력

    I0116 10:19:35.601303   17900 ovs.go:90] Maximum command line arguments set to: 191102
    ovn-trace source pod to destination pod indicates success from web to dns-default-467qw
    ovn-trace destination pod to source pod indicates success from dns-default-467qw to web
    ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-467qw
    ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-467qw to web
    ovn-detrace source pod to destination pod indicates success from web to dns-default-467qw
    ovn-detrace destination pod to source pod indicates success from dns-default-467qw to web
    Copy to Clipboard Toggle word wrap

    강조 표시는 배포된 Pod에서 DNS 포트로의 성공을 나타내며 다른 방향으로 되돌아가는 것을 나타냅니다. 따라서 웹 pod가 코어 DNS에서 dns 확인을 원하는 경우 UDP 포트 53에서 양방향 트래픽이 지원됩니다.

예를 들어 작동하지 않고 ovn-trace, ovs-appctl ofproto/traceovn-detrace, 더 많은 디버그 유형 정보는 로그 수준을 2로 늘리고 다음과 같이 명령을 다시 실행합니다.

$ ./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 2
Copy to Clipboard Toggle word wrap

이 증가된 로그 수준의 출력은 여기에 나열하기에는 너무 많습니다. 실패 상황에서 이 명령의 출력은 해당 트래픽을 삭제하는 흐름을 보여줍니다. 예를 들어 송신 또는 수신 네트워크 정책은 해당 트래픽을 허용하지 않는 클러스터에 구성할 수 있습니다.

예: debug 출력을 사용하여 구성된 기본 거부 확인

이 예제에서는 Ingress 기본 거부 정책이 트래픽을 차단하는 디버그 출력을 사용하여 식별하는 방법을 보여줍니다.

프로세스

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

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
      namespace: default
    spec:
      podSelector: {}
      ingress: []
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

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

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 prod 네임스페이스를 생성합니다.

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 prod 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다.

    $ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  7. 다른 터미널 세션을 엽니다.
  8. 이 새 터미널 세션에서 ovn-trace 를 실행하여 네임스페이스 prod 에서 실행되는 소스 Pod test-6459default 네임스페이스에서 실행되는 대상 Pod 간의 통신 실패를 확인합니다.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 0
    Copy to Clipboard Toggle word wrap

    예상 출력

    I0116 14:20:47.380775   50822 ovs.go:90] Maximum command line arguments set to: 191102
    ovn-trace source pod to destination pod indicates failure from test-6459 to web
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 실패 이유를 노출하려면 로그 수준을 2로 늘립니다.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 2
    Copy to Clipboard Toggle word wrap

    예상 출력

    ct_lb_mark /* default (use --ct to customize) */
    ------------------------------------------------
     3. ls_out_acl_hint (northd.c:6092): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 32d45ad4
        reg0[8] = 1;
        reg0[10] = 1;
        next;
     4. ls_out_acl (northd.c:6435): reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid f730a887 
    1
    
        ct_commit { ct_mark.blocked = 1; };
    Copy to Clipboard Toggle word wrap

    1
    Ingress 트래픽은 기본 거부 정책 시행으로 인해 차단됩니다.
  10. purpose=production 레이블이 있는 특정 네임스페이스의 모든 Pod의 트래픽을 허용하는 정책을 생성합니다. YAML을 web-allow-prod.yaml 파일에 저장합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-prod
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production
    Copy to Clipboard Toggle word wrap
  11. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap
  12. ovnkube-trace 를 실행하여 다음 명령을 입력하여 트래픽이 지금 허용되는지 확인합니다.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 0
    Copy to Clipboard Toggle word wrap

    예상 출력

    I0116 14:25:44.055207   51695 ovs.go:90] Maximum command line arguments set to: 191102
    ovn-trace source pod to destination pod indicates success from test-6459 to web
    ovn-trace destination pod to source pod indicates success from web to test-6459
    ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
    ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
    ovn-detrace source pod to destination pod indicates success from test-6459 to web
    ovn-detrace destination pod to source pod indicates success from web to test-6459
    Copy to Clipboard Toggle word wrap

  13. 열려 있는 쉘에서 다음 명령을 실행합니다.

     wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

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

25.5. OpenShift SDN 네트워크 플러그인에서 마이그레이션

클러스터 관리자는 OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션할 수 있습니다.

OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 네트워크 플러그인 정보를 참조하십시오.

25.5.1. OVN-Kubernetes 네트워크 플러그인으로 마이그레이션

OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하는 것은 클러스터에 연결할 수 없는 몇 가지 다운 타임이 포함된 수동 프로세스입니다.

중요

OVN-Kubernetes 네트워크 플러그인을 사용하도록 OpenShift Container Platform 클러스터를 마이그레이션하기 전에 모든 최신 버그 수정이 클러스터에 적용되도록 클러스터를 최신 z-stream 릴리스로 업데이트합니다.

롤백 절차가 제공되지만 마이그레이션은 단방향 프로세스로 설정됩니다.

다음 플랫폼에서 OVN-Kubernetes 네트워크 플러그인으로의 마이그레이션이 지원됩니다.

  • 베어 메탈 하드웨어
  • AWS(Amazon Web Services)
  • GCP(Google Cloud Platform)
  • IBM Cloud®
  • Microsoft Azure
  • Red Hat OpenStack Platform (RHOSP)
  • RHV(Red Hat Virtualization)
  • {vmw-first}
중요

Red Hat OpenShift Dedicated, Azure Red Hat OpenShift(ARO) 및 Red Hat OpenShift Service on AWS(ROSA)와 같은 관리형 OpenShift 클라우드 서비스로 또는 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션은 지원되지 않습니다.

OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하는 것은 Nutanix에서 지원되지 않습니다.

OpenShift Container Platform 클러스터에 150개 이상의 노드가 있는 경우 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하기 위한 지원 케이스를 엽니다.

노드에 할당된 서브넷과 개별 포드에 할당된 IP 주소는 마이그레이션 중에 유지되지 않습니다.

OVN-Kubernetes 네트워크 플러그인은 OpenShift SDN 네트워크 플러그인에 있는 많은 기능을 구현하지만 구성은 동일하지 않습니다.

  • 클러스터에서 다음 OpenShift SDN 네트워크 플러그인 기능을 사용하는 경우 OVN-Kubernetes 네트워크 플러그인에서 동일한 기능을 수동으로 구성해야 합니다.

    • 네임스페이스 격리
    • 송신 라우터 Pod
  • 클러스터 또는 주변 네트워크에서 100.64.0.0/16 주소 범위의 일부를 사용하는 경우 spec.defaultNetwork.ovnKubernetesConfig 개체 정의에서 v4InternalSubnet 사양을 지정하여 사용되지 않는 다른 IP 범위를 선택해야 합니다. OVN-Kubernetes는 기본적으로 내부적으로 IP 범위 100.64.0.0/16 을 사용합니다.

다음 섹션에서는 OVN-Kubernetes 및 OpenShift SDN 네트워크 플러그인의 앞서 언급한 기능 간의 구성 차이점을 설명합니다.

기본 네트워크 인터페이스

OpenShift SDN 플러그인을 사용하면 NodeNetworkConfigurationPolicy (NNCP) 사용자 정의 리소스(CR)를 노드의 기본 인터페이스에 적용할 수 있습니다. OVN-Kubernetes 네트워크 플러그인에는 이 기능이 없습니다.

기본 인터페이스에 NNCP가 적용된 경우 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하기 전에 NNCP를 삭제해야 합니다. NNCP를 삭제해도 기본 인터페이스에서 구성은 제거되지 않지만 OVN-Kubernetes를 사용하면 Kubernetes NMState가 이 구성을 관리할 수 없습니다. 대신 configure-ovs.sh 쉘 스크립트는 기본 인터페이스와 이 인터페이스에 연결된 구성을 관리합니다.

네임스페이스 격리

OVN-Kubernetes는 네트워크 정책 격리 모드만 지원합니다.

중요

다중 테넌트 또는 서브넷 격리 모드에서 구성된 OpenShift SDN을 사용하는 클러스터의 경우 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션할 수 있습니다. 마이그레이션 작업 후에는 다중 테넌트 격리 모드가 삭제되므로 Pod 및 서비스에 대해 동일한 수준의 프로젝트 수준 격리를 달성하려면 네트워크 정책을 수동으로 구성해야 합니다.

송신 IP 주소

OpenShift SDN은 두 가지 다른 Egress IP 모드를 지원합니다.

  • 자동 할당 방식에서는 송신 IP 주소 범위가 노드에 할당됩니다.
  • 수동으로 할당된 방식에서는 하나 이상의 송신 IP 주소 목록이 노드에 할당됩니다.

마이그레이션 프로세스에서는 자동으로 할당된 모드를 사용하는 Egress IP 구성 마이그레이션을 지원합니다.

OVN-Kubernetes와 OpenShift SDN 간의 송신 IP 주소를 구성하는 데 있어서 차이점은 다음 표에 설명되어 있습니다.

Expand
표 25.4. 송신 IP 주소 구성의 차이점
OVN-KubernetesOpenShift SDN
  • EgressIPs 오브젝트 생성
  • Node 오브젝트에 주석 추가
  • NetNamespace 오브젝트 패치
  • HostSubnet 오브젝트 패치

OVN-Kubernetes에서 송신 IP 주소를 사용하는 방법에 대한 자세한 내용은 " 송신 IP 주소 구성"을 참조하십시오.

송신 네트워크 정책

OVN-Kubernetes와 OpenShift SDN 간의 송신 방화벽이라고도 하는 송신 네트워크 정책 구성의 차이점은 다음 표에 설명되어 있습니다.

Expand
표 25.5. 송신 네트워크 정책 구성의 차이점
OVN-KubernetesOpenShift SDN
  • 네임스페이스에 EgressFirewall 오브젝트 생성
  • 네임스페이스에서 EgressNetworkPolicy 오브젝트 생성
참고

EgressFirewall 오브젝트의 이름은 OpenShift SDN에 있는 이름에 관계없이 마이그레이션된 모든 EgressNetworkPolicy 오브젝트의 이름을 default 로 지정한 후에만 기본값으로 설정할 수 있습니다.

나중에 OpenShift SDN으로 롤백하면 이전 이름이 손실되므로 모든 EgressNetworkPolicy 오브젝트의 이름이 default 로 지정됩니다.

OVN-Kubernetes에서 송신 방화벽을 사용하는 방법에 대한 자세한 내용은 "프로젝트에 대한 송신 방화벽 구성"을 참조하십시오.

송신 라우터 Pod

OVN-Kubernetes는 리디렉션 모드에서 송신 라우터 pod를 지원합니다. OVN-Kubernetes는 HTTP 프록시 모드 또는 DNS 프록시 모드에서 송신 라우터 Pod를 지원하지 않습니다.

Cluster Network Operator를 사용하여 송신 라우터를 배포할 때 송신 라우터 Pod를 호스팅하는 데 사용되는 노드를 제어하기 위해 노드 선택기를 지정할 수 없습니다.

멀티 캐스트

OVN-Kubernetes 및 OpenShift SDN에서 멀티 캐스트 트래픽 활성화의 차이점은 다음 표에 설명되어 있습니다.

Expand
표 25.6. 멀티 캐스트 구성의 차이점
OVN-KubernetesOpenShift SDN
  • Namespace 오브젝트에 주석 추가
  • NetNamespace 오브젝트에 주석 추가

OVN-Kubernetes에서 멀티 캐스트를 사용하는 방법에 대한 자세한 내용은 "프로젝션에 멀티 캐스트 사용"을 참조하십시오.

네트워크 정책

OVN-Kubernetes는 networking.k8s.io/v1 API 그룹에서 Kubernetes NetworkPolicy API를 완전히 지원합니다. OpenShift SDN에서 마이그레이션할 때 네트워크 정책에 변경 사항이 필요하지 않습니다.

25.5.1.2. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

Expand
표 25.7. OpenShift SDN에서 OVN-Kubernetes로 마이그레이션
사용자 시작 단계마이그레이션 활동

cluster라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OVNKubernetes로 설정합니다. 값으로 설정하기 전에 migration 필드가 null인지 확인합니다.

CNO(Cluster Network Operator)
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.
Machine Config Operator (MCO)
OVN-Kubernetes에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하여 기본적으로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간을 생성합니다.

Network.config.openshift.io CR의 networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OpenShift SDN 컨트롤 플레인 pod를 삭제합니다.
  • OVN-Kubernetes 컨트롤 플레인 pod를 배포합니다.
  • 새 네트워크 플러그인을 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터에서 OVN-Kubernetes 클러스터 네트워크의 Pod에 IP 주소를 할당합니다.

OpenShift SDN으로의 롤백이 필요한 경우 다음 표에서 프로세스를 설명합니다.

중요

롤백을 시작하기 전에 OpenShift SDN에서 OVN-Kubernetes 네트워크 플러그인으로의 마이그레이션 프로세스가 성공할 때까지 기다려야 합니다.

Expand
표 25.8. OpenShift SDN으로 롤백 수행
사용자 시작 단계마이그레이션 활동

MCO가 마이그레이션을 중단하지 않도록 일시 중지합니다.

MCO가 중지됩니다.

cluster 라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OpenShiftSDN 으로 설정합니다. 값으로 설정하기 전에 migration 필드가 null인지 확인합니다.

CNO
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.

networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OVN-Kubernetes 컨트롤 플레인 Pod를 제거합니다.
  • OpenShift SDN 컨트롤 플레인 포드를 배포합니다.
  • 새 네트워크 플러그인을 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터는 OpenShift-SDN 네트워크의 포드에 IP 주소를 할당합니다.

클러스터 재부팅의 모든 노드 후에 MCO를 활성화합니다.

MCO
OpenShift SDN에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하여 기본적으로 마이그레이션에 걸리는 총 시간이 클러스터 크기에 따라 증가합니다.

25.5.2. OVN-Kubernetes 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 클러스터의 네트워크 플러그인을 OVN-Kubernetes로 변경할 수 있습니다. 마이그레이션하는 동안 클러스터의 모든 노드를 재부팅해야 합니다.

중요

마이그레이션을 수행하는 동안 클러스터를 사용할 수 없으며 워크로드가 중단될 수 있습니다. 서비스 중단이 허용되는 경우에만 마이그레이션을 수행합니다.

사전 요구 사항

  • 네트워크 정책 격리 모드에서 OpenShift SDN CNI 네트워크 플러그인으로 구성된 클러스터가 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 데이터베이스의 최근 백업이 있습니다.
  • 각 노드를 수동으로 재부팅할 수 있습니다.
  • 클러스터가 오류 없이 알려진 양호한 상태에 있는지 확인합니다.
  • 모든 클라우드 플랫폼의 모든 노드에 대해 포트 6081 에서 UDP(User Datagram Protocol) 패킷을 허용하는 보안 그룹 규칙을 생성했습니다.

프로세스

  1. 클러스터 네트워크의 구성을 백업하려면 다음 명령을 입력합니다.

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 OVN_SDN_MIGRATION_TIMEOUT 환경 변수가 설정되어 있고 0s 와 같은지 확인합니다.

    #!/bin/bash
    
    if [ -n "$OVN_SDN_MIGRATION_TIMEOUT" ] && [ "$OVN_SDN_MIGRATION_TIMEOUT" = "0s" ]; then
        unset OVN_SDN_MIGRATION_TIMEOUT
    fi
    
    #loops the timeout command of the script to repeatedly check the cluster Operators until all are available.
    
    co_timeout=${OVN_SDN_MIGRATION_TIMEOUT:-1200s}
    timeout "$co_timeout" bash <<EOT
    until
      oc wait co --all --for='condition=AVAILABLE=True' --timeout=10s && \
      oc wait co --all --for='condition=PROGRESSING=False' --timeout=10s && \
      oc wait co --all --for='condition=DEGRADED=False' --timeout=10s;
    do
      sleep 10
      echo "Some ClusterOperators Degraded=False,Progressing=True,or Available=False";
    done
    EOT
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 CNO(Cluster Network Operator) 구성 오브젝트에서 구성을 제거합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
    --patch '{"spec":{"migration":null}}'
    Copy to Clipboard Toggle word wrap
  4. 다음 단계를 완료하여 OpenShift SDN 네트워크 플러그인의 기본 네트워크 인터페이스를 정의하는 NodeNetworkConfigurationPolicy (NNCP) 사용자 정의 리소스(CR)를 삭제합니다.

    1. 다음 명령을 입력하여 기존 NNCP CR이 기본 인터페이스를 클러스터에 연결했는지 확인합니다.

      $ oc get nncp
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured
      Copy to Clipboard Toggle word wrap

      Network Manager는 결합된 기본 인터페이스에 대한 연결 프로필을 /etc/NetworkManager/system-connections 시스템 경로에 저장합니다.

    2. 클러스터에서 NNCP를 제거합니다.

      $ oc delete nncp <nncp_manifest_filename>
      Copy to Clipboard Toggle word wrap
  5. 마이그레이션을 위해 모든 노드를 준비하려면 다음 명령을 실행하여 CNO 구성 오브젝트에서 migration 필드를 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    Copy to Clipboard Toggle word wrap
    참고

    이 단계는 OVN-Kubernetes를 즉시 배포하지 않습니다. 대신 migration 필드를 지정하면 OVN-Kubernetes 배포를 준비하기 위해 MCO(Machine Config Operator)가 클러스터의 모든 노드에 새 머신 구성을 적용합니다.

    1. 다음 명령을 실행하여 재부팅이 완료되었는지 확인합니다.

      $ oc get mcp
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 모든 클러스터 Operator를 사용할 수 있는지 확인합니다.

      $ oc get co
      Copy to Clipboard Toggle word wrap
    3. 또는 여러 OpenShift SDN 기능을 동등한 OVN-Kubernetes로 자동 마이그레이션을 비활성화할 수 있습니다.

      • 송신 IP
      • 송신 방화벽
      • 멀티 캐스트

      이전에 명시된 OpenShift SDN 기능에 대한 구성 자동 마이그레이션을 비활성화하려면 다음 키를 지정합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{
          "spec": {
            "migration": {
              "networkType": "OVNKubernetes",
              "features": {
                "egressIP": <bool>,
                "egressFirewall": <bool>,
                "multicast": <bool>
              }
            }
          }
        }'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      bool: 기능의 마이그레이션을 활성화할지 여부를 지정합니다. 기본값은 true입니다.

  6. 선택 사항: OVN-Kubernetes에 대해 다음 설정을 사용자 정의하여 네트워크 인프라 요구 사항을 충족할 수 있습니다.

    • 최대 전송 단위(MTU)입니다. 이 선택적 단계에 대한 MTU를 사용자 정의하기 전에 다음을 고려하십시오.

      • 기본 MTU를 사용하고 마이그레이션 중에 기본 MTU를 유지하려면 이 단계를 무시할 수 있습니다.
      • 사용자 지정 MTU를 사용한 후 마이그레이션 중에 사용자 지정 MTU를 유지하려면 이 단계에서 사용자 지정 MTU 값을 선언해야 합니다.
      • 마이그레이션 중에 MTU 값을 변경하려는 경우 이 단계가 작동하지 않습니다. 대신 먼저 "클러스터 MTU 변경"에 대한 지침을 따라야 합니다. 그런 다음 이 절차를 수행하고 이 단계에서 사용자 지정 MTU 값을 선언하여 사용자 지정 MTU 값을 유지할 수 있습니다.

        참고

        OpenShift-SDN 및 OVN-Kubernetes에는 다른 오버레이 오버헤드가 있습니다. MTU 값은 "MTU 값 선택" 페이지에 있는 지침에 따라 선택해야 합니다.

    • Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크 포트
    • OVN-Kubernetes IPv4 내부 서브넷
    • OVN-Kubernetes IPv6 내부 서브넷

    이전에 명시된 설정 중 하나를 사용자 정의하려면 다음 명령을 입력하고 사용자 정의합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    mtu
    Geneve 오버레이 네트워크용 MTU입니다. MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 100을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    Geneve 오버레이 네트워크용 UDP 포트입니다. 값을 지정하지 않으면 기본값은 6081입니다. 이 포트는 OpenShift SDN에서 사용하는 VXLAN 포트와 같을 수 없습니다. VXLAN 포트의 기본값은 4789입니다.
    ipv4_subnet
    OVN-Kubernetes에서 내부용으로 사용할 IPv4 주소 범위입니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 100.64.0.0/16 입니다.
    ipv6_subnet
    OVN-Kubernetes에서 내부용으로 사용할 IPv6 주소 범위입니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 fd98::/48 입니다.

    mtu 필드를 업데이트하는 패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'
    Copy to Clipboard Toggle word wrap

  7. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  8. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
      Copy to Clipboard Toggle word wrap
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 다음 명령을 입력하여 이전 출력에 표시된 첫 번째 머신 구성 데몬 포드에 대한 포드 로그를 표시합니다.

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
  9. 마이그레이션을 시작하려면 다음 명령 중 하나를 사용하여 OVN-Kubernetes 네트워크 플러그인을 구성합니다.

    • 클러스터 네트워크 IP 주소 블록을 변경하지 않고 네트워크 공급자를 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
      Copy to Clipboard Toggle word wrap
    • 다른 클러스터 네트워크 IP 주소 블록을 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'
      Copy to Clipboard Toggle word wrap

      여기서 cidr은 CIDR 블록이며 prefix는 클러스터의 각 노드에 승인된 CIDR 블록 조각입니다. OVN-Kubernetes 네트워크 공급자가 이 블록을 내부에서 사용하므로 100.64.0.0/16 CIDR 블록과 겹치는 CIDR 블록을 사용할 수 없습니다.

      중요

      마이그레이션 중에 서비스 네트워크 주소 블록을 변경할 수 없습니다.

  10. 후속 단계를 계속 진행하기 전에 Multus 데몬 세트 롤아웃이 완료되었는지 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus pod의 이름은 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
    Copy to Clipboard Toggle word wrap

  11. 네트워크 플러그인 변경을 완료하려면 클러스터의 각 노드를 재부팅합니다. 다음 방법 중 하나를 사용하여 클러스터의 노드를 재부팅할 수 있습니다.

    중요

    다음 스크립트는 클러스터의 모든 노드를 동시에 재부팅합니다. 이로 인해 클러스터가 불안정해질 수 있습니다. 또 다른 옵션은 노드를 한 번에 수동으로 재부팅하는 것입니다. 노드를 하나씩 재부팅하면 여러 노드가 있는 클러스터에서 상당한 다운타임이 발생합니다.

    노드를 재부팅하기 전에 클러스터 Operator가 제대로 작동하지 않습니다.

    • oc rsh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다.

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 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
      Copy to Clipboard Toggle word wrap
  12. 마이그레이션이 성공했는지 확인합니다.

    1. 네트워크 플러그인이 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다. status.networkType의 값은 OVNKubernetes이어야 합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

    4. 모든 클러스터 Operator가 비정상적인 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get co
      Copy to Clipboard Toggle word wrap

      모든 클러스터 Operator의 상태는 AVAILABLE="True", PROGRESSING="False", DEGRADED="False"여야 합니다. 클러스터 Operator를 사용할 수 없거나 성능이 저하된 경우 자세한 내용은 클러스터 Operator의 로그를 확인합니다.

  13. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. CNO 구성 오브젝트에서 마이그레이션 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OpenShift SDN 네트워크 제공자에 대한 사용자 정의 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
      Copy to Clipboard Toggle word wrap
    3. OpenShift SDN 네트워크 공급자 네임스페이스를 제거하려면 다음 명령을 입력합니다.

      $ oc delete namespace openshift-sdn
      Copy to Clipboard Toggle word wrap

25.6. OpenShift SDN 네트워크 공급자로 롤백

클러스터 관리자는 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션이 완료되고 성공한 경우에만 OVN-Kubernetes 네트워크 플러그인에서 OpenShift SDN으로 롤백할 수 있습니다.

25.6.1. OpenShift SDN 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 오프라인 마이그레이션 방법을 사용하여 OpenShift SDN CNI(Container Network Interface) 네트워크 플러그인으로 롤백할 수 있습니다. 마이그레이션 중에 클러스터의 모든 노드를 수동으로 재부팅해야 합니다. 오프라인 마이그레이션 방법을 사용하면 클러스터에 연결할 수 없는 몇 가지 다운타임이 있습니다.

중요

롤백을 시작하기 전에 OpenShift SDN에서 OVN-Kubernetes 네트워크 플러그인으로의 마이그레이션 프로세스가 성공할 때까지 기다려야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OVN-Kubernetes 네트워크 플러그인으로 구성된 인프라에 설치된 클러스터입니다.
  • etcd 데이터베이스의 최근 백업을 사용할 수 있습니다.
  • 각 노드에 대해 재부팅을 수동으로 트리거할 수 있습니다.
  • 클러스터가 오류 없이 알려진 정상 상태입니다.

프로세스

  1. MCO(Machine Config Operator)에서 관리하는 모든 머신 구성 풀을 중지합니다.

    • CLI에 다음 명령을 입력하여 마스터 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": true } }'
      Copy to Clipboard Toggle word wrap
    • CLI에 다음 명령을 입력하여 작업자 머신 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec":{ "paused": true } }'
      Copy to Clipboard Toggle word wrap
  2. 마이그레이션을 준비하려면 CLI에 다음 명령을 입력하여 migration 필드를 null 로 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'
    Copy to Clipboard Toggle word wrap
  3. CLI에 다음 명령을 입력하여 마이그레이션 상태가 Network.config.openshift.io 오브젝트에 비어 있는지 확인합니다. 빈 명령 출력은 오브젝트가 마이그레이션 작업에 없음을 나타냅니다.

    $ oc get Network.config cluster -o jsonpath='{.status.migration}'
    Copy to Clipboard Toggle word wrap
  4. CLI에 다음 명령을 입력하여 네트워크 플러그인을 OpenShift SDN으로 설정하려면 Network.operator.openshift.io 오브젝트에 패치를 적용합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'
    Copy to Clipboard Toggle word wrap
    중요

    패치 작업이 Network.operator.openshift.io 오브젝트에서 종료되기 전에 Network.config.openshift.io 오브젝트에 패치를 적용한 경우 CNO(Cluster Network Operator)가 성능 저하 상태로 전환되어 CNO가 degraded 상태에서 복구될 때까지 약간의 지연이 발생합니다.

  5. CLI에 다음 명령을 입력하여 Network.config.openshift.io 클러스터 오브젝트의 네트워크 플러그인의 마이그레이션 상태가 OpenShiftSDN 인지 확인합니다.

    $ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'
    Copy to Clipboard Toggle word wrap
  6. CLI에 다음 명령을 입력하여 네트워크 플러그인을 OpenShift SDN으로 설정하려면 Network.config.openshift.io 오브젝트에 패치를 적용합니다.

    $ oc patch Network.config.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'
    Copy to Clipboard Toggle word wrap
  7. 선택 사항: 동일한 OpenShift SDN으로 여러 OVN-Kubernetes 기능의 자동 마이그레이션을 비활성화합니다.

    • 송신 IP
    • 송신 방화벽
    • 멀티 캐스트

    이전에 명시된 OpenShift SDN 기능에 대한 구성 자동 마이그레이션을 비활성화하려면 다음 키를 지정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{
        "spec": {
          "migration": {
            "networkType": "OpenShiftSDN",
            "features": {
              "egressIP": <bool>,
              "egressFirewall": <bool>,
              "multicast": <bool>
            }
          }
        }
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    bool: 기능의 마이그레이션을 활성화할지 여부를 지정합니다. 기본값은 true입니다.

  8. 선택 사항: OpenShift SDN에 대해 네트워크 인프라 요구 사항을 충족하도록 다음 설정을 사용자 정의할 수 있습니다.

    • 최대 전송 단위(MTU)
    • VXLAN 포트

    이전에 명시된 설정 중 하나 또는 둘 다를 사용자 지정하려면 CLI에 다음 명령을 사용자 지정하고 입력합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":<mtu>,
              "vxlanPort":<port>
        }}}}'
    Copy to Clipboard Toggle word wrap
    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
        }}}}'
    Copy to Clipboard Toggle word wrap

  9. 클러스터의 각 노드를 재부팅합니다. 다음 방법 중 하나를 사용하여 클러스터의 노드를 재부팅할 수 있습니다.

    • oc rsh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다.

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 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
      Copy to Clipboard Toggle word wrap
  10. Multus 데몬 세트 롤아웃이 완료될 때까지 기다립니다. 다음 명령을 실행하여 롤아웃 상태를 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus pod의 이름은 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
    Copy to Clipboard Toggle word wrap

  11. 클러스터의 노드가 재부팅되고 multus Pod가 롤아웃되면 다음 명령을 실행하여 모든 머신 구성 풀을 시작합니다.

    • 마스터 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap
    • 작업자 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap

    MCO는 각 구성 풀에서 머신을 업데이트하므로 각 노드를 재부팅합니다.

    기본적으로 MCO는 한 번에 풀당 단일 머신을 업데이트하므로 마이그레이션이 완료하는 데 필요한 시간은 클러스터 크기와 함께 증가합니다.

  12. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 CLI에 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

  13. 마이그레이션이 성공했는지 확인합니다.

    1. 네트워크 플러그인이 OpenShift SDN인지 확인하려면 CLI에 다음 명령을 입력합니다. status.networkType 값은 OpenShiftSDN이어야 합니다.

      $ oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. 클러스터 노드가 Ready 상태인지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. Pod를 나열하려면 CLI에 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 이전 출력에 표시된 각 머신 구성 데몬 포드에 대한 Pod 로그를 표시하려면 CLI에 다음 명령을 입력합니다.

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
    4. Pod가 오류 상태가 아닌지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

  14. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. Cluster Network Operator 구성 오브젝트에서 마이그레이션 구성을 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OVN-Kubernetes 구성을 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
      Copy to Clipboard Toggle word wrap
    3. OVN-Kubernetes 네트워크 공급자 네임스페이스를 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc delete namespace openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap
중요

Kuryr에서 OVN-Kubernetes로의 마이그레이션은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터의 관리자는 Kuryr SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션할 수 있습니다.

OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 네트워크 플러그인 정보를 참조하십시오.

25.7.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션

RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터를 OVN-Kubernetes 네트워크 공급자로 수동으로 마이그레이션할 수 있습니다.

중요

OVN-Kubernetes로의 마이그레이션은 단방향 프로세스입니다. 마이그레이션하는 동안 짧은 시간 동안 클러스터에 연결할 수 없습니다.

25.7.1.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션할 때 고려 사항

Kubernetes 네임스페이스는 Kuryr에 의해 별도의 RHOSP 네트워킹 서비스(Neutron) 서브넷에 보관됩니다. 개별 포드에 할당된 서브넷 및 IP 주소는 마이그레이션 중에 보존되지 않습니다.

25.7.1.2. 마이그레이션 프로세스의 작동 방식

다음 표에는 클러스터 및 Operator에서 수행하는 작업과 관련된 마이그레이션 프로세스가 요약되어 있습니다.

Expand
표 25.9. Kuryr에서 OVN-Kubernetes 마이그레이션 프로세스
사용자 시작 단계마이그레이션 활동

cluster라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OVNKubernetes로 설정합니다.

CNO(Cluster Network Operator)
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.
Machine Config Operator (MCO)

Network.config.openshift.io CR의 networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OVN-Kubernetes 컨트롤 플레인 pod를 배포합니다.
  • 새 네트워크 플러그인을 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터에서 OVN-Kubernetes 클러스터 네트워크의 Pod에 IP 주소를 할당합니다.

Cluster

25.7.2. OVN-Kubernetes 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 클러스터의 네트워크 플러그인을 OVN-Kubernetes로 변경할 수 있습니다.

중요

마이그레이션하는 동안 클러스터의 모든 노드를 재부팅해야 합니다.

사전 요구 사항

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

프로세스

  1. $ oc get Network.config.openshift.io cluster -o yaml > cluster-kuryr.yaml
    Copy to Clipboard Toggle word wrap
  2. $ CLUSTERID=$(oc get infrastructure.config.openshift.io cluster -o=jsonpath='{.status.infrastructureName}')
    Copy to Clipboard Toggle word wrap
  3. $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    Copy to Clipboard Toggle word wrap
    참고

    이 단계는 OVN-Kubernetes를 즉시 배포하지 않습니다.

    • 최대 전송 단위(MTU)
    • Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크 포트
    • OVN-Kubernetes IPv4 내부 서브넷
    • OVN-Kubernetes IPv6 내부 서브넷

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    mtu
    MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 100을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    값을 지정하지 않으면 기본값은 6081입니다. VXLAN 포트의 기본값은 4789입니다.
    ipv4_subnet
    IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 100.64.0.0/16 입니다.
    ipv6_subnet
    IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 fd98::/48 입니다.

    기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    mtu 필드를 업데이트하는 패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

  5. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b 
      1
      
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b 
      2
      
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done
      Copy to Clipboard Toggle word wrap

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <config_name>

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      출력 예

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
      Copy to Clipboard Toggle word wrap

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 다음 명령을 입력하여 이전 출력에 표시된 첫 번째 머신 구성 데몬 포드에 대한 포드 로그를 표시합니다.

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        다음과 같습니다.

        <pod>
      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
  6. 마이그레이션을 시작하려면 다음 명령 중 하나를 사용하여 OVN-Kubernetes 네트워크 플러그인을 구성합니다.

    • 클러스터 네트워크 IP 주소 블록을 변경하지 않고 네트워크 공급자를 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
      Copy to Clipboard Toggle word wrap
    • 다른 클러스터 네트워크 IP 주소 블록을 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": "<prefix>"
              }
            ]
            "networkType": "OVNKubernetes"
          }
        }'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <cidr>
      <prefix>

      중요

      마이그레이션 중에 서비스 네트워크 주소 블록을 변경할 수 없습니다.

      OVN-Kubernetes 네트워크 공급자가 이 블록을 내부에서 사용하므로 100.64.0.0/16 CIDR 블록과 겹치는 CIDR 블록을 사용할 수 없습니다.

  7. $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    포드를 다시 시작하는 데 시간이 다소 걸릴 수 있습니다.

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  8. 마이그레이션을 완료하려면 클러스터의 각 노드를 재부팅합니다. 예를 들어 다음 예와 유사한 bash 스크립트를 사용할 수 있습니다.

    #!/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
    Copy to Clipboard Toggle word wrap
    참고

    $ for name in $(openstack server list --name ${CLUSTERID}\* -f value -c Name); do openstack server reboot $name; done
    Copy to Clipboard Toggle word wrap

    그렇지 않으면 SSH 또는 관리 포털 및 OpenStack 클라이언트를 통해 가상 시스템에 액세스할 수 있는 적절한 기관에 문의하십시오.

검증

  1. 마이그레이션이 성공했는지 확인한 다음 마이그레이션 리소스를 제거합니다.

    1. 네트워크 플러그인이 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap

      status.networkType의 값은 OVNKubernetes이어야 합니다.

    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

    4. 모든 클러스터 Operator가 비정상적인 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get co
      Copy to Clipboard Toggle word wrap

      모든 클러스터 Operator의 상태는 AVAILABLE="True", PROGRESSING="False", DEGRADED="False"여야 합니다. 클러스터 Operator를 사용할 수 없거나 성능이 저하된 경우 자세한 내용은 클러스터 Operator의 로그를 확인합니다.

      중요

      이전 확인 단계에서 오류가 표시되면 진행하지 마십시오. 오류 표시가 아닙니다.

  2. 마이그레이션이 완료되고 클러스터가 정상 상태인 경우 다음 명령을 입력하여 CNO 구성 오브젝트에서 마이그레이션 구성을 제거합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'
    Copy to Clipboard Toggle word wrap

25.7.3. 마이그레이션 후 리소스 정리

Kuryr 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션한 후 Kuryr가 이전에 생성한 리소스를 정리해야 합니다.

참고

정리 프로세스는 Python 가상 환경을 사용하여 Octavia 오브젝트에 대한 지원 태그를 사용하는 패키지 버전이 있는지 확인합니다.

사전 요구 사항

  • Python 인터프리터를 설치했습니다.
  • 기본 RHOSP 클라우드에 액세스할 수 있습니다.

프로세스

  1. 정리 Python 가상 환경을 생성합니다.

    1. 환경에 사용할 임시 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

      $ python3 -m venv /tmp/venv
      Copy to Clipboard Toggle word wrap

    2. 가상 환경을 입력합니다. 예를 들면 다음과 같습니다.

      $ source /tmp/venv/bin/activate
      Copy to Clipboard Toggle word wrap
    3. (venv) $ pip install pip --upgrade
      Copy to Clipboard Toggle word wrap
    4. 다음 명령을 실행하여 필요한 Python 패키지를 설치합니다.

      (venv) $ pip install openstacksdk==0.54.0 python-openstackclient==5.5.0 python-octaviaclient==2.3.0
      Copy to Clipboard Toggle word wrap
  2. 터미널에서 다음 명령을 실행하여 변수를 클러스터 및 Kuryr 식별자로 설정합니다.

    1. 클러스터 ID를 설정합니다.

      (venv) $ CLUSTERID=$(oc get infrastructure.config.openshift.io cluster -o=jsonpath='{.status.infrastructureName}')
      Copy to Clipboard Toggle word wrap
    2. 클러스터 태그를 설정합니다.

      (venv) $ CLUSTERTAG="openshiftClusterID=${CLUSTERID}"
      Copy to Clipboard Toggle word wrap
    3. 라우터 ID를 설정합니다.

      (venv) $ ROUTERID=$(oc get kuryrnetwork -A --no-headers -o custom-columns=":status.routerId"|head -n 1)
      Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 지정된 리소스에서 종료자를 제거하는 Bash 함수를 생성합니다.

    (venv) $ function REMFIN {
        local resource=$1
        local finalizer=$2
        for res in $(oc get $resource -A --template='{{range $i,$p := .items}}{{ $p.metadata.name }}|{{ $p.metadata.namespace }}{{"\n"}}{{end}}'); do
            name=${res%%|*}
            ns=${res##*|}
            yaml=$(oc get -n $ns $resource $name -o yaml)
            if echo "${yaml}" | grep -q "${finalizer}"; then
                echo "${yaml}" | grep -v  "${finalizer}" | oc replace -n $ns $resource $name -f -
            fi
        done
    }
    Copy to Clipboard Toggle word wrap

    함수에는 두 개의 매개 변수가 사용됩니다. 첫 번째 매개 변수는 리소스 이름이고 두 번째 매개 변수는 제거할 종료자입니다. 지정된 리소스는 클러스터에서 제거되고 지정된 종료자를 제외하고 해당 정의는 복사된 데이터로 교체됩니다.

  4. 서비스에서 Kuryr 종료자를 제거하려면 다음 명령을 입력합니다.

    (venv) $ REMFIN services kuryr.openstack.org/service-finalizer
    Copy to Clipboard Toggle word wrap
  5. (venv) $ if $(oc get -n openshift-kuryr service service-subnet-gateway-ip &>/dev/null); then
        oc -n openshift-kuryr delete service service-subnet-gateway-ip
    fi
    Copy to Clipboard Toggle word wrap
  6. Octavia에서 태그가 지정된 모든 RHOSP 로드 밸런서를 제거하려면 다음 명령을 입력합니다.

    (venv) $ for lb in $(openstack loadbalancer list --tags $CLUSTERTAG -f value -c id); do
        openstack loadbalancer delete --cascade $lb
    done
    Copy to Clipboard Toggle word wrap
  7. (venv) $ REMFIN kuryrloadbalancers.openstack.org kuryr.openstack.org/kuryrloadbalancer-finalizers
    Copy to Clipboard Toggle word wrap
  8. (venv) $ oc delete namespace openshift-kuryr
    Copy to Clipboard Toggle word wrap
  9. 라우터에서 Kuryr 서비스 서브넷을 제거하려면 다음 명령을 입력합니다.

    (venv) $ openstack router remove subnet $ROUTERID ${CLUSTERID}-kuryr-service-subnet
    Copy to Clipboard Toggle word wrap
  10. Kuryr 서비스 네트워크를 제거하려면 다음 명령을 입력합니다.

    (venv) $ openstack network delete ${CLUSTERID}-kuryr-service-network
    Copy to Clipboard Toggle word wrap
  11. 모든 Pod에서 Kuryr 종료자를 제거하려면 다음 명령을 입력합니다.

    (venv) $ REMFIN pods kuryr.openstack.org/pod-finalizer
    Copy to Clipboard Toggle word wrap
  12. (venv) $ REMFIN kuryrports.openstack.org kuryr.openstack.org/kuryrport-finalizer
    Copy to Clipboard Toggle word wrap

  13. 네트워크 정책에서 Kuryr 종료자를 제거하려면 다음 명령을 입력합니다.

    (venv) $ REMFIN networkpolicy kuryr.openstack.org/networkpolicy-finalizer
    Copy to Clipboard Toggle word wrap
  14. 나머지 네트워크 정책에서 Kuryr 종료자를 제거하려면 다음 명령을 입력합니다.

    (venv) $ REMFIN kuryrnetworkpolicies.openstack.org kuryr.openstack.org/networkpolicy-finalizer
    Copy to Clipboard Toggle word wrap
  15. 트렁크에서 Kuryr가 생성한 하위 포트를 제거하려면 다음 명령을 입력합니다.

    (venv) $ read -ra trunks <<< $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x.id for x in n.trunks(any_tags='$CLUSTERTAG')]))") && \
    i=0 && \
    for trunk in "${trunks[@]}"; do
        i=$((i+1))
        echo "Processing trunk $trunk, ${i}/${#trunks[@]}."
        subports=()
        for subport in $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x['port_id'] for x in n.get_trunk('$trunk').sub_ports if '$CLUSTERTAG' in n.get_port(x['port_id']).tags]))"); do
            subports+=("$subport");
        done
        args=()
        for sub in "${subports[@]}" ; do
            args+=("--subport $sub")
        done
        if [ ${#args[@]} -gt 0 ]; then
            openstack network trunk unset ${args[*]} $trunk
        fi
    done
    Copy to Clipboard Toggle word wrap
  16. (venv) $ mapfile -t kuryrnetworks < <(oc get kuryrnetwork -A --template='{{range $i,$p := .items}}{{ $p.status.netId }}|{{ $p.status.subnetId }}{{"\n"}}{{end}}') && \
    i=0 && \
    for kn in "${kuryrnetworks[@]}"; do
        i=$((i+1))
        netID=${kn%%|*}
        subnetID=${kn##*|}
        echo "Processing network $netID, ${i}/${#kuryrnetworks[@]}"
        # Remove all ports from the network.
        for port in $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x.id for x in n.ports(network_id='$netID') if x.device_owner != 'network:router_interface']))"); do
            ( openstack port delete $port ) &
    
            # Only allow 20 jobs in parallel.
            if [[ $(jobs -r -p | wc -l) -ge 20 ]]; then
                wait -n
            fi
        done
        wait
    
        # Remove the subnet from the router.
        openstack router remove subnet $ROUTERID $subnetID
    
        # Remove the network.
        openstack network delete $netID
    done
    Copy to Clipboard Toggle word wrap
  17. Kuryr 보안 그룹을 제거하려면 다음 명령을 입력합니다.

    (venv) $ openstack security group delete ${CLUSTERID}-kuryr-pods-security-group
    Copy to Clipboard Toggle word wrap
  18. 태그가 지정된 서브넷 풀을 모두 제거하려면 다음 명령을 입력합니다.

    (venv) $ for subnetpool in $(openstack subnet pool list --tags $CLUSTERTAG -f value -c ID); do
        openstack subnet pool delete $subnetpool
    done
    Copy to Clipboard Toggle word wrap
  19. (venv) $ networks=$(oc get kuryrnetwork -A --no-headers -o custom-columns=":status.netId") && \
    for existingNet in $(openstack network list --tags $CLUSTERTAG -f value -c ID); do
        if [[ $networks =~ $existingNet ]]; then
            echo "Network still exists: $existingNet"
        fi
    done
    Copy to Clipboard Toggle word wrap

    명령에서 기존 네트워크를 반환하는 경우 계속하기 전에 Intestigate를 수행합니다.

  20. 네트워크 정책과 관련된 보안 그룹을 제거하려면 다음 명령을 입력합니다.

    (venv) $ for sgid in $(openstack security group list -f value -c ID -c Description | grep 'Kuryr-Kubernetes Network Policy' | cut -f 1 -d ' '); do
        openstack security group delete $sgid
    done
    Copy to Clipboard Toggle word wrap
  21. (venv) $ REMFIN kuryrnetworks.openstack.org kuryrnetwork.finalizers.kuryr.openstack.org
    Copy to Clipboard Toggle word wrap
  22. Kuryr 라우터를 제거하려면 다음 명령을 입력합니다.

    (venv) $ if $(python3 -c "import sys; import openstack; n = openstack.connect().network; r = n.get_router('$ROUTERID'); sys.exit(0) if r.description != 'Created By OpenShift Installer' else sys.exit(1)"); then
        openstack router delete $ROUTERID
    fi
    Copy to Clipboard Toggle word wrap

25.8. IPv4/IPv6 듀얼 스택 네트워킹으로 변환

클러스터 관리자는 IPv4 단일 스택 클러스터를 IPv4 및 IPv6 주소 제품군을 지원하는 듀얼 네트워크 클러스터 네트워크로 변환할 수 있습니다. 듀얼 스택으로 변환한 후 새로 생성된 모든 pod는 듀얼 스택이 활성화됩니다.

참고

참고

25.8.1. 듀얼 스택 클러스터 네트워크로 변환

클러스터 관리자는 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.

참고

듀얼 스택 네트워킹으로 변환한 후에는 새로 생성된 pod만 IPv6 주소에 할당됩니다. IPv6 주소를 받으려면 변환하기 전에 생성된 모든 Pod를 다시 생성해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
  • 클러스터 노드에는 IPv6 주소가 있습니다.
  • 인프라를 기반으로 IPv6 지원 라우터를 구성했습니다.

프로세스

  1. 클러스터 및 서비스 네트워크에 대한 IPv6 주소 블록을 지정하려면 다음 YAML이 포함된 파일을 생성합니다.

    - op: add
      path: /spec/clusterNetwork/-
      value: 
    1
    
        cidr: fd01::/48
        hostPrefix: 64
    - op: add
      path: /spec/serviceNetwork/-
      value: fd02::/112 
    2
    Copy to Clipboard Toggle word wrap
    1
    cidrhostPrefix 필드를 사용하여 오브젝트를 지정합니다. 호스트 접두사는 64 이상이어야 합니다. IPv6 CIDR 접두사는 지정된 호스트 접두사를 수용할 수 있을 만큼 커야 합니다.
    1 2
    접두사가 112인 IPv6 CIDR을 지정합니다. Kubernetes는 가장 낮은 16비트만 사용합니다. 접두사 112의 경우 IP 주소는 112비트에서 128비트로 할당됩니다.
  2. 클러스터 네트워크 구성을 패치하려면 다음 명령을 입력합니다.

    $ oc patch network.config.openshift.io cluster \
      --type='json' --patch-file <file>.yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    file
    이전 단계에서 만든 파일의 이름을 지정합니다.

    출력 예

    network.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

다음 단계를 완료하여 클러스터 네트워크가 이전 프로세스에서 지정한 IPv6 주소 블록을 인식하는지 확인합니다.

  1. 네트워크 구성을 표시합니다.

    $ oc describe network
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

25.8.2. 단일 스택 클러스터 네트워크로 변환

클러스터 관리자는 듀얼 스택 클러스터 네트워크를 단일 스택 클러스터 네트워크로 변환할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
  • 클러스터 노드에는 IPv6 주소가 있습니다.
  • 듀얼 스택 네트워킹을 활성화했습니다.

프로세스

  1. $ oc edit networks.config.openshift.io
    Copy to Clipboard Toggle word wrap

25.9. 송신 방화벽 및 네트워크 정책 규칙에 대한 로깅

클러스터 관리자는 클러스터에 대한 감사 로깅을 구성하고 하나 이상의 네임스페이스에 대해 로깅을 활성화할 수 있습니다. OpenShift Container Platform은 송신 방화벽 및 네트워크 정책 모두에 대한 감사 로그를 생성합니다.

참고

25.9.1. 감사 로깅

OVN-Kubernetes 네트워크 플러그인은 OVN(Open Virtual Network) ACL을 사용하여 송신 방화벽 및 네트워크 정책을 관리합니다. 감사 로깅은 ACL 이벤트를 허용 및 거부합니다.

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

참고

네임스페이스 주석의 예

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

syslog 기능은 구성 가능하며 기본값은 local0입니다.

<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
Copy to Clipboard Toggle word wrap

다음과 같습니다.

<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
Copy to Clipboard Toggle word wrap

다음과 같습니다.

참고

네트워크 정책의 ACL 거부 로그 항목 예

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_ingressDefaultDeny", 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_ingressDefaultDeny", 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
Copy to Clipboard Toggle word wrap

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

Expand
표 25.10.
필드설명

deny

allow

25.9.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
Copy to Clipboard Toggle word wrap

다음 표에서는 감사 로깅을 위한 구성 필드를 설명합니다.

Expand
표 25.11. policyAuditConfig 오브젝트
필드유형설명

rateLimit

integer

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

maxFileSize

integer

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

maxLogFiles

integer

대상

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입니다.

25.9.3. 클러스터에 대한 송신 방화벽 및 네트워크 정책 감사 구성

클러스터 관리자는 클러스터에 대한 감사 로깅을 사용자 지정할 수 있습니다.

사전 요구 사항

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

프로세스

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

    $ oc edit network.operator.openshift.io/cluster
    Copy to Clipboard Toggle word wrap
    작은 정보

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

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

검증

  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
      Copy to Clipboard Toggle word wrap

      출력 예

      namespace/verify-audit-logging created
      Copy to Clipboard Toggle word wrap

    2. 네임스페이스의 네트워크 정책을 생성합니다.

      $ 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
        namespace: verify-audit-logging
      spec:
        podSelector: {}
        policyTypes:
         - Ingress
         - Egress
        ingress:
          - from:
              - podSelector: {}
        egress:
          - to:
             - namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: verify-audit-logging
      EOF
      Copy to Clipboard Toggle word wrap

      출력 예

      networkpolicy.networking.k8s.io/deny-all created
      networkpolicy.networking.k8s.io/allow-from-same-namespace created
      Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

    출력 예

    pod/client created
    pod/server created
    Copy to Clipboard Toggle word wrap

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

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

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

      $ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

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

      $ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    출력 예

    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_ingressDefaultDeny", 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_ingressDefaultDeny", 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
    Copy to Clipboard Toggle word wrap

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

사전 요구 사항

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

프로세스

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

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

    다음과 같습니다.

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

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

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

    출력 예

    namespace/verify-audit-logging annotated
    Copy to Clipboard Toggle word wrap

검증

  • 감사 로그의 최신 항목을 표시합니다.

    $ 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
    Copy to Clipboard Toggle word wrap

    출력 예

    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_ingressDefaultDeny", 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_ingressDefaultDeny", 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
    Copy to Clipboard Toggle word wrap

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

사전 요구 사항

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

프로세스

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

    $ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

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

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/acl-logging: null
    Copy to Clipboard Toggle word wrap

    출력 예

    namespace/verify-audit-logging annotated
    Copy to Clipboard Toggle word wrap

25.10. IPsec 암호화 구성

IPsec이 활성화되면 OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 pod-to-pod 네트워크 트래픽은 IPsec 전송 모드로 암호화됩니다.

IPsec은 기본적으로 비활성화되어 있습니다. 클러스터를 설치한 후 또는 동안 활성화할 수 있습니다. 클러스터 설치 후 IPsec을 활성화해야 하는 경우 IPsec ESP IP 헤더의 오버헤드를 고려하여 먼저 클러스터 MTU의 크기를 조정해야 합니다.

다음 문서에서는 클러스터 설치 후 IPSec를 활성화 및 비활성화하는 방법을 설명합니다.

25.10.1. 사전 요구 사항

25.10.2. IPsec에서 암호화하는 네트워크 트래픽 흐름 유형

IPsec을 활성화하면 포드 간 다음 네트워크 트래픽 흐름만 암호화됩니다.

  • 클러스터 네트워크의 서로 다른 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드에서 클러스터 네트워크의 포드로의 트래픽

다음 트래픽 흐름은 암호화되지 않습니다.

  • 클러스터 네트워크의 동일한 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드 간 트래픽
  • 클러스터 네트워크의 포드에서 호스트 네트워크 포드로의 트래픽

암호화되거나 암호화되지 않은 흐름은 다음 다이어그램에 설명되어 있습니다.

25.10.2.1. IPsec이 활성화된 경우 네트워크 연결 요구 사항

OpenShift Container Platform 클러스터 구성 요소가 통신할 수 있도록 시스템 간 네트워크 연결을 구성해야 합니다. 각 시스템에서 클러스터에 있는 다른 모든 시스템의 호스트 이름을 확인할 수 있어야 합니다.

Expand
표 25.12. 모든 시스템 간 통신에 사용되는 포트
프로토콜포트설명

UDP

500

IPsec IKE 패킷

4500

IPsec NAT-T 패킷

ESP

해당 없음

IPsec 캡슐화 보안 페이로드(ESP)

25.10.3. 암호화 프로토콜 및 IPsec 모드

사용된 암호화 암호는 AES-GCM-16-256입니다. 무결성 검사 값(ICV)은 16바이트입니다. 키 길이는 256비트입니다.

사용된 IPsec 모드는 전송 모드입니다. 즉, ESP(Encapsulated Security Payload) 헤더를 원래 패킷의 IP 헤더에 추가하고 패킷 데이터를 암호화하여 엔드 투 엔드 통신을 암호화하는 모드입니다. OpenShift Container Platform은 현재 pod-to-pod 통신에 IPsec tunnel 모드를 사용하거나 지원하지 않습니다.

25.10.4. 보안 인증서 생성 및 교체

CNO(Cluster Network Operator)는 암호화에 IPsec에서 사용하는 자체 서명된 X.509 인증 기관(CA)을 생성합니다. 각 노드의 CSR(인증서 서명 요청)은 CNO에서 자동으로 충족됩니다.

CA는 10년 동안 유효합니다. 개별 노드 인증서는 5년간 유효하며 4년 6개월 경과 후 자동으로 교체됩니다.

25.10.5. IPsec 암호화 활성화

클러스터 관리자는 클러스터를 설치한 후 IPsec 암호화를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • IPsec ESP 헤더의 오버헤드를 허용하도록 클러스터 MTU의 크기를 46 바이트 감소했습니다.

프로세스

  • IPsec 암호화를 활성화하려면 다음 명령을 입력합니다.

    $ oc patch networks.operator.openshift.io cluster --type=merge \
    -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipsecConfig":{ }}}}}'
    Copy to Clipboard Toggle word wrap

검증

  1. OVN-Kubernetes 컨트롤 플레인 Pod의 이름을 찾으려면 다음 명령을 입력합니다.

    $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                   READY   STATUS    RESTARTS   AGE
    ovnkube-master-fvtnh   6/6     Running   0          122m
    ovnkube-master-hsgmm   6/6     Running   0          122m
    ovnkube-master-qcmdc   6/6     Running   0          122m
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 cluste에서 IPsec이 활성화되었는지 확인합니다.

    $ oc -n openshift-ovn-kubernetes rsh ovnkube-master-<XXXXX> \
      ovn-nbctl --no-leader-only get nb_global . ipsec
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <XXXXX>
    이전 단계에서 Pod의 임의 문자 시퀀스를 지정합니다.

    출력 예

    true
    Copy to Clipboard Toggle word wrap

25.10.6. IPsec 암호화 비활성화

클러스터 관리자는 클러스터 설치 후 IPsec을 활성화한 경우에만 IPsec 암호화를 비활성화할 수 있습니다.

참고

클러스터를 설치할 때 IPsec을 활성화한 경우 이 절차를 통해 IPsec을 비활성화할 수 없습니다.

사전 요구 사항

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

프로세스

  1. IPsec 암호화를 비활성화하려면 다음 명령을 입력합니다.

    $ oc patch networks.operator.openshift.io/cluster --type=json \
      -p='[{"op":"remove", "path":"/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig"}]'
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: IP 패킷의 IPsec ESP 헤더에서 오버헤드가 더 이상 없으므로 클러스터 MTU 크기를 46 바이트까지 늘릴 수 있습니다.
  3. 클러스터에서 IPsec이 비활성화되어 있는지 확인합니다.

    $ oc -n openshift-ovn-kubernetes -c nbdb rsh ovnkube-master-<XXXXX> \
      ovn-nbctl --no-leader-only get nb_global . ipsec
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <XXXXX>
    이전 단계에서 Pod의 임의 문자 시퀀스를 지정합니다.

    출력 예

    false
    Copy to Clipboard Toggle word wrap

25.10.7. 추가 리소스

25.11. 프로젝트에 대한 송신 방화벽 구성

클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

25.11.1. 프로젝트에서 송신 방화벽이 작동하는 방식

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

참고

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

EgressFirewall CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
  • 포트 번호
  • 다음 프로토콜 중 하나인 프로토콜 : TCP, UDP 및 SCTP
중요

송신 방화벽에 0.0.0.0/0에 대한 거부 규칙이 포함된 경우 OpenShift Container Platform API 서버에 대한 액세스 권한이 차단됩니다. 각 IP 주소에 대해 허용 규칙을 추가하거나 송신 정책 규칙에서 nodeSelector 유형 허용 규칙을 사용하여 API 서버에 연결해야 합니다.

다음 예제에서는 API 서버 액세스를 확인하는 데 필요한 송신 방화벽 규칙의 순서를 보여줍니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace> 
1

spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 
2

    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 
3

    type: Deny
Copy to Clipboard Toggle word wrap
1
송신 방화벽의 네임스페이스입니다.
2
OpenShift Container Platform API 서버를 포함하는 IP 주소 범위입니다.
3
글로벌 거부 규칙은 OpenShift Container Platform API 서버에 액세스할 수 없습니다.

API 서버의 IP 주소를 찾으려면 oc get ep kubernetes -n default 를 실행합니다.

자세한 내용은 BZ#1988324에서 참조하십시오.

주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

25.11.1.1. 송신 방화벽의 제한

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 프로젝트당 최대 50개의 규칙이 있는 최대 하나의 EgressFirewall 오브젝트를 정의할 수 있습니다.
  • Red Hat OpenShift Networking에서 공유 게이트웨이 모드와 함께 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 수신 응답을 송신 방화벽 규칙의 영향을 받습니다. 송신 방화벽 규칙이 수신 응답 대상 IP를 삭제하면 트래픽이 삭제됩니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상됩니다. 결과적으로 모든 외부 네트워크 트래픽이 삭제되어 조직에 보안 위험이 발생할 수 있습니다.

Egress Firewall 리소스는 kube-node-lease,kube-public,kube-system,openshiftopenshift- 프로젝트에서 생성할 수 있습니다.

25.11.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

25.11.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 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽 정책에서 DNS 이름을 사용하는 것은 CoreDNS를 통한 로컬 DNS 확인에는 영향을 미치지 않습니다.

그러나 송신 방화벽 정책이 도메인 이름을 사용하고 외부 DNS 서버가 영향을 받는 Pod의 DNS 확인을 처리하는 경우 DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 포함해야 합니다.

25.11.2. EgressFirewall CR(사용자 정의 리소스) 오브젝트

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 Allow 규칙 또는 Deny 규칙입니다.

다음 YAML은 EgressFirewall CR 오브젝트를 설명합니다.

EgressFirewall 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 
1

spec:
  egress: 
2

    ...
Copy to Clipboard Toggle word wrap

1
오브젝트의 이름은 default이어야 합니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.
25.11.2.1. EgressFirewall 규칙

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 사용자는 CIDR 형식, 도메인 이름에서 IP 주소 범위를 선택하거나 nodeSelector 를 사용하여 송신 트래픽을 허용하거나 거부할 수 있습니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type> 
1

  to: 
2

    cidrSelector: <cidr> 
3

    dnsName: <dns_name> 
4

    nodeSelector: <label_name>: <label_value> 
5

  ports: 
6

      ...
Copy to Clipboard Toggle word wrap

1
규칙 유형입니다. 값은 Allow 또는 Deny여야 합니다.
2
cidrSelector 필드 또는 dnsName 필드를 지정하는 송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
DNS 도메인 이름입니다.
5
레이블은 사용자가 정의하는 키/값 쌍입니다. 레이블은 Pod와 같은 오브젝트에 연결됩니다. nodeSelector 를 사용하면 하나 이상의 노드 레이블을 선택하고 Pod에 연결할 수 있습니다.
6
선택 사항: 규칙에 대한 네트워크 포트 및 프로토콜 컬렉션을 설명하는 스탠자입니다.

포트 스탠자

ports:
- port: <port> 
1

  protocol: <protocol> 
2
Copy to Clipboard Toggle word wrap

1
80 또는 443과 같은 네트워크 포트. 이 필드의 값을 지정하는 경우 protocol의 값도 지정해야 합니다.
2
네트워크 프로토콜. 값은 TCP, UDP 또는 SCTP여야 합니다.
25.11.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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
25.11.2.3. EgressFirewall의 nodeSelector 예

클러스터 관리자는 nodeSelector 를 사용하여 라벨을 지정하여 클러스터의 노드에 대한 송신 트래픽을 허용하거나 거부할 수 있습니다. 레이블은 하나 이상의 노드에 적용할 수 있습니다. 다음은 region=east 라벨이 있는 예입니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow
Copy to Clipboard Toggle word wrap
작은 정보

노드 IP 주소당 수동 규칙을 추가하는 대신 노드 선택기를 사용하여 송신 방화벽 뒤의 pod가 호스트 네트워크 Pod에 액세스할 수 있는 레이블을 생성합니다.

25.11.3. 송신 방화벽 정책 오브젝트 생성

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressFirewall 오브젝트가 정의되어 있는 경우 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

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

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.
  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다.

    $ oc create -f <policy_name>.yaml -n <project>
    Copy to Clipboard Toggle word wrap

    다음 예제에서는 project1이라는 프로젝트에 새 EgressFirewall 오브젝트가 생성됩니다.

    $ oc create -f default.yaml -n project1
    Copy to Clipboard Toggle word wrap

    출력 예

    egressfirewall.k8s.ovn.org/v1 created
    Copy to Clipboard Toggle word wrap

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.

25.12. 프로젝트의 송신 방화벽 보기

클러스터 관리자는 기존 송신 방화벽의 이름을 나열하고 특정 송신 방화벽에 대한 트래픽 규칙을 볼 수 있습니다.

25.12.1. EgressFirewall 오브젝트 보기

클러스터의 EgressFirewall 오브젝트를 볼 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressFirewall 오브젝트의 이름을 보려면 다음 명령을 입력합니다.

    $ oc get egressfirewall --all-namespaces
    Copy to Clipboard Toggle word wrap
  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다.

    $ oc describe egressfirewall <policy_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

25.13. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

25.13.1. EgressFirewall 오브젝트 편집

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 송신 네트워크 방화벽을 만들 때 EgressFirewall 오브젝트의 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다.

    $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
    Copy to Clipboard Toggle word wrap

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressFirewall 오브젝트를 바꿉니다. 업데이트된 EgressFirewall 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다.

    $ oc replace -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

25.14. 프로젝트에서 송신 방화벽 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

25.14.1. EgressFirewall 오브젝트 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 EgressFirewall 오브젝트를 삭제합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다.

    $ oc delete -n <project> egressfirewall <name>
    Copy to Clipboard Toggle word wrap

25.15. 송신 IP 주소 구성

클러스터 관리자는 OVN-Kubernetes CNI(Container Network Interface) 네트워크 플러그인을 구성하여 하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.

25.15.1. 송신 IP 주소 아키텍처 설계 및 구현

OpenShift Container Platform 송신 IP 주소 기능을 사용하면 하나 이상의 네임스페이스에 있는 하나 이상의 Pod에서 발생하는 트래픽의 소스 IP 주소가 클러스터 네트워크 외부 서비스에 일관되게 표시되도록 할 수 있습니다.

예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.

네임스페이스에 할당된 송신 IP 주소는 특정 대상으로 트래픽을 보내는 데 사용되는 송신 라우터와 다릅니다.

일부 클러스터 구성에서 애플리케이션 Pod 및 수신 라우터 Pod는 동일한 노드에서 실행됩니다. 이 시나리오에서 애플리케이션 프로젝트의 송신 IP 주소를 구성하면 애플리케이션 프로젝트의 경로에 요청을 보낼 때 IP 주소가 사용되지 않습니다.

중요

송신 IP 주소는 ifcfg-eth0과 같은 Linux 네트워크 구성 파일에서 구성하지 않아야 합니다.

25.15.1.1. 플랫폼 지원

다음 표에는 다양한 플랫폼의 송신 IP 주소 기능에 대한 지원이 요약되어 있습니다.

Expand
플랫폼지원됨

베어 메탈

제공됨

VMware vSphere

제공됨

Red Hat OpenStack Platform (RHOSP)

제공됨

AWS(Amazon Web Services)

제공됨

GCP(Google Cloud Platform)

제공됨

Microsoft Azure

제공됨

IBM Z 및 IBM® LinuxONE

제공됨

IBM Z 및 IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM

제공됨

IBM Power

제공됨

중요

EgressIP 기능을 사용하여 컨트롤 플레인 노드에 송신 IP 주소 할당은 AWS(Amazon Web Services)에서 프로비저닝된 클러스터에서 지원되지 않습니다. (BZ#2039656)

25.15.1.2. 퍼블릭 클라우드 플랫폼 고려 사항

퍼블릭 클라우드 인프라에 프로비저닝된 클러스터의 경우 노드당 할당 가능한 IP 주소 수에 제약 조건이 있습니다. 노드당 할당 가능한 최대 IP 주소 수 또는 IP 용량 은 다음 공식에서 설명할 수 있습니다.

IP capacity = public cloud default capacity - sum(current IP assignments)
Copy to Clipboard Toggle word wrap

Egress IPs 기능은 노드당 IP 주소 용량을 관리하지만 배포에서 이 제약 조건을 계획해야 합니다. 예를 들어 8개의 노드로 베어 메탈 인프라에 설치된 클러스터의 경우 150개 송신 IP 주소를 구성할 수 있습니다. 그러나 퍼블릭 클라우드 공급자가 노드당 IP 주소 용량을 10개로 제한하는 경우 할당 가능한 총 IP 주소 수는 80입니다. 이 예제 클라우드 공급자에서 동일한 IP 주소 용량을 얻으려면 7 개의 추가 노드를 할당해야 합니다.

퍼블릭 클라우드 환경에서 노드의 IP 용량 및 서브넷을 확인하려면 oc get node <node_name> -o yaml 명령을 입력합니다. cloud.network.openshift.io/egress-ipconfig 주석에는 노드의 용량 및 서브넷 정보가 포함됩니다.

주석 값은 기본 네트워크 인터페이스에 대해 다음 정보를 제공하는 필드가 있는 단일 오브젝트가 있는 배열입니다.

  • Interface: AWS 및 Azure의 인터페이스 ID와 GCP의 인터페이스 이름을 지정합니다.
  • ifaddr: 하나 또는 두 IP 주소 제품군의 서브넷 마스크를 지정합니다.
  • capacity: 노드의 IP 주소 용량을 지정합니다. AWS에서는 IP 주소 제품군별로 IP 주소 용량이 제공됩니다. Azure 및 GCP에서 IP 주소 용량에는 IPv4 및 IPv6 주소가 모두 포함됩니다.

노드 간 트래픽에 대한 송신 IP 주소 자동 연결 및 분리를 사용할 수 있습니다. 이렇게 하면 네임스페이스의 많은 Pod에서 트래픽이 클러스터 외부의 위치와 일관된 소스 IP 주소를 가질 수 있습니다. 이는 OpenShift Container Platform 4.13의 Red Hat OpenShift Networking의 기본 네트워킹 플러그인인 OpenShift SDN 및 OVN-Kubernetes도 지원합니다.

참고

RHOSP 클러스터 관리자가 예약 포트에 유동 IP를 할당하면 OpenShift Container Platform에서 예약 포트를 삭제할 수 없습니다. CloudPrivateIPConfig 오브젝트는 RHOSP 클러스터 관리자가 예약 포트에서 유동 IP를 할당 해제할 때까지 삭제 및 이동 작업을 수행할 수 없습니다.

다음 예제에서는 여러 퍼블릭 클라우드 공급자에 있는 노드의 주석을 보여줍니다. 가독성을 위해 주석이 들여쓰기됩니다.

AWS의 cloud.network.openshift.io/egress-ipconfig 주석의 예

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]
Copy to Clipboard Toggle word wrap

GCP의 cloud.network.openshift.io/egress-ipconfig 주석의 예

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]
Copy to Clipboard Toggle word wrap

다음 섹션에서는 용량 계산에 사용할 지원되는 퍼블릭 클라우드 환경에 대한 IP 주소 용량을 설명합니다.

25.15.1.2.1. AWS(Amazon Web Services) IP 주소 용량 제한

AWS에서 IP 주소 할당에 대한 제약 조건은 구성된 인스턴스 유형에 따라 달라집니다. 자세한 내용은 인스턴스 유형당 네트워크 인터페이스당 IP 주소를참조하십시오.

25.15.1.2.2. GCP(Google Cloud Platform) IP 주소 용량 제한

GCP에서 네트워킹 모델은 IP 주소 할당이 아닌 IP 주소 별칭을 통해 추가 노드 IP 주소를 구현합니다. 그러나 IP 주소 용량은 IP 별칭 용량에 직접 매핑됩니다.

IP 별칭 할당을 위해 다음 용량 제한이 있습니다.

  • 노드당 최대 IP 별칭 수, IPv4 및 IPv6 모두 100입니다.
  • VPC당 최대 IP 별칭은 지정되지 않지만 OpenShift Container Platform 확장성 테스트에서는 최대 IP가 약 15,000개임을 보여줍니다.

자세한 내용은 Per instance Quota and Alias IP ranges overview 를 참조하십시오.

25.15.1.2.3. Microsoft Azure IP 주소 용량 제한

Azure에서 IP 주소 할당에 대해 다음 용량 제한이 있습니다.

  • NIC당 IPv4 및 IPv6의 할당 가능 IP 주소의 최대 수는 256입니다.
  • 가상 네트워크당 할당된 IP 주소의 최대 수는 65,536개를 초과할 수 없습니다.

자세한 내용은 네트워킹 제한 항목을 참조하십시오.

25.15.1.3. 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 주소를 호스팅할 노드에 항상 레이블을 적용하십시오.

25.15.1.4. 노드에 송신 IP 할당

EgressIP 오브젝트를 생성할 때 k8s.ovn.org/egress-assignable: "" 레이블이 지정된 노드에 다음 조건이 적용됩니다.

  • 송신 IP 주소는 한 번에 두 개 이상의 노드에 할당되지 않습니다.
  • 송신 IP 주소는 송신 IP 주소를 호스팅할 수 있는 사용 가용한 노드 간에 균형을 이룹니다.
  • EgressIP 오브젝트의 spec.EgressIPs 배열에서 둘 이상의 IP 주소를 지정하는 경우 다음 조건이 적용됩니다.

    • 지정된 IP 주소 중 두 개 이상을 호스팅할 노드는 없습니다.
    • 지정된 네임스페이스에 대해 지정된 IP 주소 간에 트래픽이 거의 동일하게 분산됩니다.
  • 노드를 사용할 수 없게 되면 할당된 모든 송신 IP 주소가 이전에 설명한 조건에 따라 자동으로 재할당됩니다.

Pod가 여러 EgressIP 오브젝트의 선택기와 일치하는 경우 EgressIP 오브젝트에 지정된 송신 IP 주소 중 어느 것이 Pod의 송신 IP 주소로 할당되는지 보장할 수 없습니다.

또한 EgressIP 오브젝트가 여러 송신 IP 주소를 지정하는 경우 송신 IP 주소 중 사용할 수 있는 보장이 없습니다. 예를 들어 Pod가 두 개의 송신 IP 주소 10.10.20.110.10.20.2 가 있는 EgressIP 오브젝트의 선택기와 일치하는 경우 각 TCP 연결 또는 UDP 대화에 사용할 수 있습니다.

25.15.1.5. 송신 IP 주소 구성에 대한 아키텍처 다이어그램

다음 다이어그램에서는 송신 IP 주소 구성을 보여줍니다. 다이어그램은 클러스터의 세 개 노드에서 실행 중인 두 개의 다른 네임스페이스에 있는 포드 4개를 설명합니다. 노드는 호스트 네트워크의 192.168.126.0/18 CIDR 블록에서 할당된 IP 주소입니다.

노드 1과 노드 3은 모두 k8s.ovn.org/egress-assignable: ""로 레이블이 지정되어 있으므로 송신 IP 주소 할당에 사용할 수 있습니다.

다이어그램에 있는 점선은 노드 1 및 노드 3에서 클러스터를 나가기 위해 포드 네트워크를 통해 이동하는 pod1, pod2, pod3의 트래픽 흐름을 나타냅니다. 외부 서비스에서 예제의 EgressIP 오브젝트에서 선택한 Pod 중 하나에서 트래픽을 수신하는 경우 소스 IP 주소는 192.168.126.10 또는 192.168.126.102입니다. 트래픽은 이 두 노드 간에 대략적으로 균등하게 분산됩니다.

다이어그램의 다음 리소스는 자세히 설명되어 있습니다.

Namespace 오브젝트

네임스페이스는 다음 매니페스트에 정의됩니다.

네임스페이스 오브젝트

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
  labels:
    env: prod
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  labels:
    env: prod
Copy to Clipboard Toggle word wrap

EgressIP 오브젝트

다음 EgressIP 오브젝트는 env 라벨이 prod로 설정된 모든 포드를 선택하는 구성을 설명합니다. 선택한 포드의 송신 IP 주소는 192.168.126.10192.168.126.102입니다.

EgressIP 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egressips-prod
spec:
  egressIPs:
  - 192.168.126.10
  - 192.168.126.102
  namespaceSelector:
    matchLabels:
      env: prod
status:
  items:
  - node: node1
    egressIP: 192.168.126.10
  - node: node3
    egressIP: 192.168.126.102
Copy to Clipboard Toggle word wrap

이전 예제의 구성에 대해 OpenShift Container Platform은 두 송신 IP 주소를 사용 가능한 노드에 할당합니다. status 필드는 송신 IP 주소가 할당되었는지 여부와 위치를 반영합니다.

25.15.2. EgressIP 오브젝트

다음 YAML에서는 EgressIP 오브젝트의 API를 설명합니다. 오브젝트의 범위는 클러스터 전체이며 네임스페이스에 생성되지 않습니다.

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: <name> 
1

spec:
  egressIPs: 
2

  - <ip_address>
  namespaceSelector: 
3

    ...
  podSelector: 
4

    ...
Copy to Clipboard Toggle word wrap
1
EgressIPs 오브젝트의 이름입니다.
2
하나 이상의 IP 주소로 이루어진 배열입니다.
3
송신 IP 주소를 연결할 네임스페이스에 대해 하나 이상의 선택기입니다.
4
선택사항: 지정된 네임스페이스에서 송신 IP 주소를 연결할 Pod에 대해 하나 이상의 선택기입니다. 이러한 선택기를 적용하면 네임스페이스 내에서 Pod 하위 집합을 선택할 수 있습니다.

다음 YAML은 네임스페이스 선택기에 대한 스탠자를 설명합니다.

네임스페이스 선택기 스탠자

namespaceSelector: 
1

  matchLabels:
    <label_name>: <label_value>
Copy to Clipboard Toggle word wrap

1
네임스페이스에 대해 일치하는 하나 이상의 규칙입니다. 둘 이상의 일치 규칙이 제공되면 일치하는 모든 네임스페이스가 선택됩니다.

다음 YAML은 Pod 선택기에 대한 선택적 스탠자를 설명합니다.

Pod 선택기 스탠자

podSelector: 
1

  matchLabels:
    <label_name>: <label_value>
Copy to Clipboard Toggle word wrap

1
선택사항: 지정된 namespaceSelector 규칙과 일치하는 네임스페이스의 Pod에 대해 일치하는 하나 이상의 규칙입니다. 지정된 경우 일치하는 Pod만 선택됩니다. 네임스페이스의 다른 Pod는 선택되지 않습니다.

다음 예에서 EgressIP 오브젝트는 192.168.126.11192.168.126.102 송신 IP 주소를 app 라벨을 web으로 설정하고 env 라벨을 prod로 설정한 네임스페이스에 있는 포드와 연결합니다.

EgressIP 오브젝트의 예

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group1
spec:
  egressIPs:
  - 192.168.126.11
  - 192.168.126.102
  podSelector:
    matchLabels:
      app: web
  namespaceSelector:
    matchLabels:
      env: prod
Copy to Clipboard Toggle word wrap

다음 예에서 EgressIP 오브젝트는 192.168.127.30192.168.127.40 송신 IP 주소를 environment 레이블이 development로 설정되지 않은 모든 Pod와 연결합니다.

EgressIP 오브젝트의 예

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group2
spec:
  egressIPs:
  - 192.168.127.30
  - 192.168.127.40
  namespaceSelector:
    matchExpressions:
    - key: environment
      operator: NotIn
      values:
      - development
Copy to Clipboard Toggle word wrap

25.15.3. egressIPConfig 오브젝트

송신 IP의 기능으로 reachabilityTotalTimeoutSeconds 매개변수는 EgressIP 노드 도달 가능성 검사 총 시간(초)을 구성합니다. 이 시간 초과 내에 EgressIP 노드에 도달할 수 없는 경우 노드가 다운됩니다.

egressIPConfig 오브젝트의 구성 파일에서 reachabilityTotalTimeoutSeconds 값을 설정할 수 있습니다. 큰 값을 설정하면 EgressIP 구현이 노드 변경에 천천히 반응할 수 있습니다. 이 구현에서는 문제가 있고 연결할 수 없는 EgressIP 노드에 대해 천천히 반응합니다.

egressIPConfig 오브젝트에서 reachabilityTotalTimeoutSeconds 매개변수를 생략하면 플랫폼은 시간이 지남에 따라 변경될 수 있는 적절한 기본값을 선택합니다. 현재 기본값은 1 초입니다. 값이 0 이면 EgressIP 노드의 도달 가능성 검사를 비활성화합니다.

다음 egressIPConfig 오브젝트는 기본 1 초 프로브에서 5 초 프로브로 reachabilityTotalTimeoutSeconds 를 변경하는 방법을 설명합니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  defaultNetwork:
    ovnKubernetesConfig:
      egressIPConfig: 
1

        reachabilityTotalTimeoutSeconds: 5 
2

      gatewayConfig:
        routingViaHost: false
      genevePort: 6081
Copy to Clipboard Toggle word wrap
1
egressIPConfig 에는 EgressIP 오브젝트 옵션의 구성이 있습니다. 이러한 구성을 변경하면 EgressIP 오브젝트를 확장할 수 있습니다.
2
reachabilityTotalTimeoutSeconds 의 값은 0 에서 60 까지의 정수 값을 허용합니다. 값이 0 이면 egressIP 노드의 도달 가능성 검사를 비활성화합니다. 값을 1 에서 60 으로 설정하면 프로브가 도달 가능 검사를 노드에 보내는 데 걸리는 시간(초)에 해당합니다.

25.15.4. 송신 IP 주소 호스팅을 위해 노드에 레이블 지정

OpenShift Container Platform에서 노드에 하나 이상의 송신 IP 주소를 할당할 수 있도록 k8s.ovn.org/egress-assignable="" 레이블을 클러스터의 노드에 적용할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인합니다.

프로세스

  • 하나 이상의 송신 IP 주소를 호스팅할 수 있도록 노드에 레이블을 지정하려면 다음 명령을 입력합니다.

    $ oc label nodes <node_name> k8s.ovn.org/egress-assignable="" 
    1
    Copy to Clipboard Toggle word wrap
    1
    레이블을 지정할 노드 이름입니다.
    작은 정보

    다음 YAML을 적용하여 노드에 레이블을 추가할 수 있습니다.

    apiVersion: v1
    kind: Node
    metadata:
      labels:
        k8s.ovn.org/egress-assignable: ""
      name: <node_name>
    Copy to Clipboard Toggle word wrap

25.15.5. 다음 단계

25.16. 송신 IP 주소 할당

클러스터 관리자는 네임스페이스 또는 네임스페이스의 특정 Pod에서 클러스터를 떠나는 트래픽에 송신 IP 주소를 할당할 수 있습니다.

25.16.1. 네임스페이스에 송신 IP 주소 할당

하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인합니다.
  • 송신 IP 주소를 호스팅할 하나 이상의 노드를 구성합니다.

프로세스

  1. EgressIP 오브젝트를 만듭니다.

    1. <egressips_name>.yaml 파일을 만듭니다. 여기서 <egressips_name>은 오브젝트 이름입니다.
    2. 생성한 파일에서 다음 예와 같이 EgressIP 오브젝트를 정의합니다.

      apiVersion: k8s.ovn.org/v1
      kind: EgressIP
      metadata:
        name: egress-project1
      spec:
        egressIPs:
        - 192.168.127.10
        - 192.168.127.11
        namespaceSelector:
          matchLabels:
            env: qa
      Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다.

    $ oc apply -f <egressips_name>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <egressips_name>을 오브젝트 이름으로 변경합니다.

    출력 예

    egressips.k8s.ovn.org/<egressips_name> created
    Copy to Clipboard Toggle word wrap

  3. 선택 사항: 나중에 변경할 수 있도록 < egressips_name>.yaml 파일을 저장합니다.
  4. 송신 IP 주소가 필요한 네임스페이스에 라벨을 추가합니다. 1단계에서 정의된 EgressIP 오브젝트의 네임스페이스에 라벨을 추가하려면 다음 명령을 실행합니다.

    $ oc label ns <namespace> env=qa 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;namespace& gt;를 송신 IP 주소가 필요한 네임스페이스로 바꿉니다.

검증

  • 클러스터에서 사용 중인 모든 송신 IP를 표시하려면 다음 명령을 입력합니다.

    $ oc get egressip -o yaml
    Copy to Clipboard Toggle word wrap
    참고

    oc get egressip 명령은 구성된 수에 관계없이 하나의 송신 IP 주소만 반환합니다. 이는 버그가 아니며 Kubernetes의 제한 사항입니다. 이 문제를 해결하려면 -o yaml 또는 -o json 플래그를 전달하여 사용 중인 모든 송신 IP 주소를 반환할 수 있습니다.

    출력 예

    # ...
    spec:
      egressIPs:
      - 192.168.127.10
      - 192.168.127.11
    # ...
    Copy to Clipboard Toggle word wrap

25.17. 송신 라우터 Pod 사용에 대한 고려 사항

25.17.1. 송신 라우터 Pod 정보

OpenShift Container Platform 송신 라우터 포드는 다른 용도로 사용되지 않는 프라이빗 소스 IP 주소에서 지정된 원격 서버로 트래픽을 리디렉션합니다. 송신 라우터 포드를 통해 특정 IP 주소에서만 액세스할 수 있도록 설정된 서버로 네트워크 트래픽을 보낼 수 있습니다.

참고

송신 라우터 Pod는 모든 발신 연결을 위한 것은 아닙니다. 다수의 송신 라우터 Pod를 생성하는 경우 네트워크 하드웨어 제한을 초과할 수 있습니다. 예를 들어 모든 프로젝트 또는 애플리케이션에 대해 송신 라우터 Pod를 생성하면 소프트웨어에서 MAC 주소 필터링으로 돌아가기 전에 네트워크 인터페이스에서 처리할 수 있는 로컬 MAC 주소 수를 초과할 수 있습니다.

중요

송신 라우터 이미지는 Amazon AWS, Azure Cloud 또는 macvlan 트래픽과의 비호환성으로 인해 계층 2 조작을 지원하지 않는 기타 클라우드 플랫폼과 호환되지 않습니다.

25.17.1.1. 송신 라우터 모드

리디렉션 모드에서는 송신 라우터 포드가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables 규칙을 구성합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 Pod는 대상 IP에 직접 연결하는 대신 송신 라우터의 서비스에 액세스하도록 구성해야 합니다. curl 명령을 사용하여 애플리케이션 포드에서 대상 서비스 및 포트에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.

$ curl <router_service_IP> <port>
Copy to Clipboard Toggle word wrap
참고

송신 라우터 CNI 플러그인은 리디렉션 모드만 지원합니다. 이는 OpenShift SDN과 함께 배포할 수 있는 송신 라우터 구현의 차이점입니다. OpenShift SDN의 송신 라우터와 달리 송신 라우터 CNI 플러그인은 HTTP 프록시 모드 또는 DNS 프록시 모드를 지원하지 않습니다.

25.17.1.2. 송신 라우터 Pod 구현

송신 라우터 구현에서는 송신 라우터 CNI(Container Network Interface) 플러그인을 사용합니다. 플러그인은 보조 네트워크 인터페이스를 포드에 추가합니다.

송신 라우터는 두 개의 네트워크 인터페이스가 있는 포드입니다. 예를 들어 포드에는 eth0net1 네트워크 인터페이스가 있을 수 있습니다. eth0 인터페이스는 클러스터 네트워크에 있으며 포드는 일반 클러스터 관련 네트워크 트래픽에 대한 인터페이스를 계속 사용합니다. net1 인터페이스는 보조 네트워크에 있으며 해당 네트워크에 대한 IP 주소 및 게이트웨이가 있습니다. OpenShift Container Platform 클러스터의 다른 포드는 송신 라우터 서비스에 액세스할 수 있으며, 서비스를 통해 포드가 외부 서비스에 액세스할 수 있습니다. 송신 라우터는 포드와 외부 시스템 간의 브리지 역할을 합니다.

송신 라우터를 종료하는 트래픽은 노드를 통해 종료되지만 패킷에는 송신 라우터 포드에서 net1 인터페이스의 MAC 주소가 있습니다.

송신 라우터 사용자 정의 리소스를 추가하면 Cluster Network Operator에서 다음 오브젝트를 생성합니다.

  • pod의 net1 보조 네트워크 인터페이스에 대한 네트워크 연결 정의입니다.
  • 출력 라우터에 대한 배포입니다.

송신 라우터 사용자 정의 리소스를 삭제하는 경우 Operator는 송신 라우터와 연결된 이전 목록에서 두 개의 오브젝트를 삭제합니다.

25.17.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>
Copy to Clipboard Toggle word wrap
RHV(Red Hat Virtualization)
RHV 를 사용하는 경우 가상 네트워크 인터페이스 컨트롤러(vNIC)에 대해 네트워크 필터 없음을 선택해야 합니다.
VMware vSphere
VMware vSphere를 사용하는 경우 vSphere 표준 스위치 보안을 위한 VMware 설명서를 참조하십시오. vSphere Web Client에서 호스트 가상 스위치를 선택하여 VMware vSphere 기본 설정을 보고 변경합니다.

특히 다음이 활성화되어 있는지 확인하십시오.

25.17.1.4. 장애 조치 구성

다운타임을 방지하기 위해 Cluster Network Operator는 송신 라우터 Pod를 배포 리소스로 배포합니다. 배포 이름은 egress-router-cni-deployment입니다. 배포에 해당하는 포드의 레이블은 app=egress-router-cni입니다.

배포에 사용할 새 서비스를 생성하려면 oc expose deployment/egress-router-cni-deployment --port <port_number> 명령을 사용하거나 다음 예와 같이 파일을 생성합니다.

apiVersion: v1
kind: Service
metadata:
  name: app-egress
spec:
  ports:
  - name: tcp-8080
    protocol: TCP
    port: 8080
  - name: tcp-8443
    protocol: TCP
    port: 8443
  - name: udp-80
    protocol: UDP
    port: 80
  type: ClusterIP
  selector:
    app: egress-router-cni
Copy to Clipboard Toggle word wrap

25.18. 리디렉션 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 예약된 소스 IP 주소에서 지정된 대상 IP 주소로 트래픽을 리디렉션하도록 송신 라우터 포드를 배포할 수 있습니다.

송신 라우터 구현에서는 송신 라우터 CNI(Container Network Interface) 플러그인을 사용합니다.

25.18.1. 송신 라우터 사용자 정의 리소스

송신 라우터 사용자 정의 리소스에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 리디렉션 모드에서 송신 라우터 구성을 위한 필드를 설명합니다.

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: <egress_router_name>
  namespace: <namespace>  <.>
spec:
  addresses: [  <.>
    {
      ip: "<egress_router>",  <.>
      gateway: "<egress_gateway>"  <.>
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [  <.>
      {
        destinationIP: "<egress_destination>",
        port: <egress_router_port>,
        targetPort: <target_port>,  <.>
        protocol: <network_protocol>  <.>
      },
      ...
    ],
    fallbackIP: "<egress_destination>" <.>
  }
Copy to Clipboard Toggle word wrap

<.> 선택 사항: namespace 필드는 출력 라우터를 생성할 네임스페이스를 지정합니다. 파일 또는 명령줄에 값을 지정하지 않으면 default 네임스페이스가 사용됩니다.

<.> address 필드는 보조 네트워크 인터페이스에서 구성할 IP 주소를 지정합니다.

<.> ip 필드는 노드가 송신 라우터 Pod에서 사용할 실제 네트워크의 예약된 소스 IP 주소와 넷마스크를 지정합니다. CIDR 표기법을 사용하여 IP 주소와 넷마스크를 지정합니다.

<.> gateway 필드는 네트워크 게이트웨이의 IP 주소를 지정합니다.

<.> 선택 사항: redirectRules 필드는 송신 대상 IP 주소, 송신 라우터 포트 및 프로토콜의 조합을 지정합니다. 지정된 포트 및 프로토콜의 출력 라우터에 대한 수신 연결은 대상 IP 주소로 라우팅됩니다.

<.> 선택 사항: targetPort 필드는 대상 IP 주소에 네트워크 포트를 지정합니다. 이 필드를 지정하지 않으면 트래픽이 도달한 동일한 네트워크 포트로 라우팅됩니다.

<.> protocol 필드는 TCP, UDP 또는 SCTP를 지원합니다.

<.> 선택 사항: fallbackIP 필드는 대상 IP 주소를 지정합니다. 리디렉션 규칙을 지정하지 않으면 송신 라우터에서 모든 트래픽을 이 폴백 IP 주소로 보냅니다. 리디렉션 규칙을 지정하면 규칙에 정의되지 않은 네트워크 포트에 대한 모든 연결이 송신 라우터에서 이 대체 IP 주소로 전송됩니다. 이 필드를 지정하지 않으면 송신 라우터는 규칙에 정의되지 않은 네트워크 포트에 대한 연결을 거부합니다.

송신 라우터 사양의 예

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-redirect
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.12.99/24",
      gateway: "192.168.12.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "10.0.0.99",
        port: 80,
        protocol: UDP
      },
      {
        destinationIP: "203.0.113.26",
        port: 8080,
        targetPort: 80,
        protocol: TCP
      },
      {
        destinationIP: "203.0.113.27",
        port: 8443,
        targetPort: 443,
        protocol: TCP
      }
    ]
  }
Copy to Clipboard Toggle word wrap

25.18.2. 리디렉션 모드에서 송신 라우터 배포

송신 라우터 pod를 배포하여 자체 예약된 소스 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션할 수 있습니다.

송신 라우터 pod를 추가한 후 예약된 소스 IP 주소를 사용해야 하는 클라이언트 pod는 대상 IP에 직접 연결하는 대신 송신 라우터에 연결하도록 수정해야 합니다.

사전 요구 사항

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

프로세스

  1. 송신 라우터 정의를 생성합니다.
  2. 다른 포드에서 송신 라우터 pod의 IP 주소를 찾을 수 있도록 하려면 다음 예제와 같이 송신 라우터를 사용하는 서비스를 만듭니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: web-app
        protocol: TCP
        port: 8080
      type: ClusterIP
      selector:
        app: egress-router-cni <.>
    Copy to Clipboard Toggle word wrap

    <.> 송신 라우터의 레이블을 지정합니다. 표시된 값은 Cluster Network Operator에서 추가하며 구성 불가능합니다.

    서비스를 생성한 후 포드가 서비스에 연결할 수 있습니다. 송신 라우터 pod는 트래픽을 대상 IP 주소의 해당 포트로 리디렉션합니다. 이 연결은 예약된 소스 IP 주소에서 시작됩니다.

검증

Cluster Network Operator가 송신 라우터를 시작했는지 확인하려면 다음 절차를 완료합니다.

  1. 송신 라우터에 대해 Operator가 생성한 네트워크 연결 정의를 확인합니다.

    $ oc get network-attachment-definition egress-router-cni-nad
    Copy to Clipboard Toggle word wrap

    네트워크 연결 정의의 이름은 구성할 수 없습니다.

    출력 예

    NAME                    AGE
    egress-router-cni-nad   18m
    Copy to Clipboard Toggle word wrap

  2. 송신 라우터 pod에 대한 배포를 확인합니다.

    $ oc get deployment egress-router-cni-deployment
    Copy to Clipboard Toggle word wrap

    배포 이름은 구성할 수 없습니다.

    출력 예

    NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    egress-router-cni-deployment   1/1     1            1           18m
    Copy to Clipboard Toggle word wrap

  3. 송신 라우터 pod의 상태를 확인합니다.

    $ oc get pods -l app=egress-router-cni
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE
    egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m
    Copy to Clipboard Toggle word wrap

  4. 송신 라우터 pod의 로그 및 라우팅 테이블을 확인합니다.
  1. 송신 라우터 pod에 대한 노드 이름을 가져옵니다.

    $ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")
    Copy to Clipboard Toggle word wrap
  2. 대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

    $ oc debug node/$POD_NODENAME
    Copy to Clipboard Toggle word wrap
  3. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. 루트 디렉터리를 /host로 변경하면 호스트의 실행 경로에서 바이너리를 실행할 수 있습니다.

    # chroot /host
    Copy to Clipboard Toggle word wrap
  4. chroot 환경 콘솔에서 송신 라우터 로그를 표시합니다.

    # cat /tmp/egress-router-log
    Copy to Clipboard Toggle word wrap

    출력 예

    2021-04-26T12:27:20Z [debug] Called CNI ADD
    2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
    2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
    2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
    2021-04-26T12:27:20Z [debug] Created macvlan interface
    2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
    2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
    2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
    2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99
    Copy to Clipboard Toggle word wrap

    로깅 파일 위치 및 로깅 수준은 이 프로세스에 설명된 대로 EgressRouter 오브젝트를 생성하여 송신 라우터를 시작할 때 구성되지 않습니다.

  5. chroot 환경 콘솔에서 컨테이너 ID를 가져옵니다.

    # crictl ps --name egress-router-cni-pod | awk '{print $1}'
    Copy to Clipboard Toggle word wrap

    출력 예

    CONTAINER
    bac9fae69ddb6
    Copy to Clipboard Toggle word wrap

  6. 컨테이너의 프로세스 ID를 확인합니다. 이 예에서 컨테이너 ID는 bac9fae69ddb6입니다.

    # crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
    Copy to Clipboard Toggle word wrap

    출력 예

    68857
    Copy to Clipboard Toggle word wrap

  7. 컨테이너의 네트워크 네임스페이스를 입력합니다.

    # nsenter -n -t 68857
    Copy to Clipboard Toggle word wrap
  8. 라우팅 테이블을 표시합니다.

    # ip route
    Copy to Clipboard Toggle word wrap

    다음 예제 출력에서 net1 네트워크 인터페이스가 기본 경로입니다. 클러스터 네트워크의 트래픽은 eth0 네트워크 인터페이스를 사용합니다. 192.168.12.0/24 네트워크의 트래픽은 net1 네트워크 인터페이스를 사용하며 예약된 소스 IP 주소 192.168.12.99에서 시작됩니다. 포드는 다른 모든 트래픽을 IP 주소 192.168.12.1의 게이트웨이로 라우팅합니다. 서비스 네트워크의 라우팅이 표시되지 않습니다.

    출력 예

    default via 192.168.12.1 dev net1
    10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18
    192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99
    192.168.12.1 dev net1
    Copy to Clipboard Toggle word wrap

25.19. 프로젝트에 멀티 캐스트 사용

25.19.1. 멀티 캐스트 정보

IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.

중요
  • 현재 멀티 캐스트는 고 대역폭 솔루션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다.
  • 기본적으로 네트워크 정책은 네임스페이스의 모든 연결에 영향을 미칩니다. 그러나 멀티캐스트는 네트워크 정책의 영향을 받지 않습니다. 네트워크 정책과 동일한 네임스페이스에서 멀티 캐스트를 활성화하면 모든 네트워크 정책이 거부 된 경우에도 항상 허용됩니다. 클러스터 관리자는 활성화하기 전에 네트워크 정책에서 멀티 캐스트에 미치는 영향을 고려해야 합니다.

OpenShift Container Platform Pod 간 멀티 캐스트 트래픽은 기본적으로 비활성화되어 있습니다. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 프로젝트별로 멀티 캐스트를 활성화할 수 있습니다.

25.19.2. Pod 간 멀티 캐스트 활성화

프로젝트의 Pod 간 멀티 캐스트를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

절차

  • 다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로 <namespace>를 바꿉니다.

    $ oc annotate namespace <namespace> \
        k8s.ovn.org/multicast-enabled=true
    Copy to Clipboard Toggle word wrap
    작은 정보

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

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/multicast-enabled: "true"
    Copy to Clipboard Toggle word wrap

검증

프로젝트에 멀티 캐스트가 활성화되어 있는지 확인하려면 다음 절차를 완료합니다.

  1. 멀티 캐스트를 활성화한 프로젝트로 현재 프로젝트를 변경합니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc project <project>
    Copy to Clipboard Toggle word wrap
  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/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat hostname && sleep inf"]
          ports:
            - containerPort: 30102
              name: mlistener
              protocol: UDP
    EOF
    Copy to Clipboard Toggle word wrap
  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/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat && sleep inf"]
    EOF
    Copy to Clipboard Toggle word wrap
  4. 새 터미널 창 또는 탭에서 멀티 캐스트 리스너를 시작합니다.

    1. Pod의 IP 주소를 가져옵니다.

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 입력하여 멀티 캐스트 리스너를 시작합니다.

      $ oc exec mlistener -i -t -- \
          socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname
      Copy to Clipboard Toggle word wrap
  5. 멀티 캐스트 송신기를 시작합니다.

    1. Pod 네트워크 IP 주소 범위를 가져옵니다.

      $ CIDR=$(oc get Network.config.openshift.io cluster \
          -o jsonpath='{.status.clusterNetwork[0].cidr}')
      Copy to Clipboard Toggle word wrap
    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"
      Copy to Clipboard Toggle word wrap

      멀티 캐스트가 작동하는 경우 이전 명령은 다음 출력을 반환합니다.

      mlistener
      Copy to Clipboard Toggle word wrap

25.20. 프로젝트에 대한 멀티 캐스트 비활성화

25.20.1. Pod 간 멀티 캐스트 비활성화

프로젝트의 Pod 간 멀티 캐스트를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

절차

  • 다음 명령을 실행하여 멀티 캐스트를 비활성화합니다.

    $ oc annotate namespace <namespace> \ 
    1
    
        k8s.ovn.org/multicast-enabled-
    Copy to Clipboard Toggle word wrap
    1
    멀티 캐스트를 비활성화하려는 프로젝트의 namespace입니다.
    작은 정보

    다음 YAML을 적용하여 주석을 삭제할 수도 있습니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/multicast-enabled: null
    Copy to Clipboard Toggle word wrap

25.21. 네트워크 흐름 추적

클러스터 관리자는 다음 영역을 지원하기 위해 클러스터에서 Pod 네트워크 흐름에 대한 정보를 수집할 수 있습니다.

  • pod 네트워크에서 수신 및 송신 트래픽을 모니터링합니다.
  • 성능 문제를 해결합니다.
  • 용량 계획 및 보안 감사를 위한 데이터를 수집합니다.

네트워크 흐름 컬렉션을 활성화하면 트래픽에 대한 메타데이터만 수집됩니다. 예를 들어 패킷 데이터는 수집되지 않지만 프로토콜, 소스 주소, 대상 주소, 포트 번호, 바이트 수 및 기타 패킷 수준 정보가 수집됩니다.

데이터는 다음 레코드 형식 중 하나로 수집됩니다.

  • NetFlow
  • sFlow
  • IPFIX

하나 이상의 컬렉터 IP 주소와 포트 번호를 사용하여 CNO(Cluster Network Operator)를 구성하는 경우 Operator는 각 노드에 OVS(Open vSwitch)를 구성하여 네트워크 흐름 레코드를 각 컬렉터에 전송합니다.

여러 유형의 네트워크 흐름 수집기로 레코드를 보내도록 Operator를 구성할 수 있습니다. 예를 들어 NetFlow 컬렉터에 레코드를 보내고 레코드를 sFlow 수집기에 전송할 수도 있습니다.

OVS가 수집기에 데이터를 보내면 각 유형의 컬렉터는 동일한 레코드를 수신합니다. 예를 들어 노드의 OVS가 두 개의 NetFlow 컬렉터를 구성하는 경우 두 컬렉터에 동일한 레코드를 보냅니다. 또한 두 개의 sFlow 컬렉터를 구성하는 경우 두 개의 sFlow 수집기는 동일한 레코드를 받습니다. 그러나 각 컬렉터 유형에는 고유한 레코드 형식이 있습니다.

네트워크 흐름 데이터를 수집하고 컬렉터로 레코드를 전송하면 성능에 영향을 미칩니다. 노드는 더 느린 속도로 패킷을 처리합니다. 성능 영향이 너무 크면 컬렉터의 대상을 삭제하여 네트워크 흐름 데이터 수집 및 복원 성능을 비활성화할 수 있습니다.

참고

네트워크 흐름 수집기를 활성화하면 클러스터 네트워크의 전반적인 성능에 영향을 미칠 수 있습니다.

25.21.1. 네트워크 흐름 추적을 위한 네트워크 오브젝트 구성

CNO(Cluster Network Operator)에서 네트워크 흐름 수집기를 구성하는 필드는 다음 표에 표시되어 있습니다.

Expand
표 25.13. 네트워크 흐름 구성
필드유형설명

metadata.name

string

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

spec.exportNetworkFlows

object

netFlow,sFlow 또는 ipfix 중 하나 이상입니다.

spec.exportNetworkFlows.netFlow.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

spec.exportNetworkFlows.sFlow.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

spec.exportNetworkFlows.ipfix.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

CNO에 다음 매니페스트를 적용한 후 Operator는 클러스터의 각 노드에서 OVS(Open vSwitch)를 구성하여 네트워크 흐름 레코드를 192.168.1.99:2056에서 수신 대기 중인 NetFlow 수집기에 전송합니다.

네트워크 흐름 추적을 위한 구성 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056
Copy to Clipboard Toggle word wrap

25.21.2. 네트워크 흐름 수집기 추가

클러스터 관리자는 pod 네트워크에 대한 네트워크 흐름 메타데이터를 네트워크 흐름 수집기로 보내도록 CNO(Cluster Network Operator)를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 흐름 수집기가 있고 수신 대기하는 IP 주소와 포트를 알고 있습니다.

절차

  1. 네트워크 흐름 수집기 유형과 컬렉터의 IP 주소 및 포트 정보를 지정하는 패치 파일을 생성합니다.

    spec:
      exportNetworkFlows:
        netFlow:
          collectors:
            - 192.168.1.99:2056
    Copy to Clipboard Toggle word wrap
  2. 네트워크 흐름 수집기를 사용하여 CNO를 구성합니다.

    $ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
    Copy to Clipboard Toggle word wrap

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

일반적으로 검증은 필요하지 않습니다. 다음 명령을 실행하여 각 노드의 OVS(Open vSwitch)가 하나 이상의 컬렉터에 네트워크 흐름 레코드를 전송하도록 구성되어 있는지 확인할 수 있습니다.

  1. Operator 구성을 보고 exportNetworkFlows 필드가 구성되었는지 확인합니다.

    $ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"
    Copy to Clipboard Toggle word wrap

    출력 예

    {"netFlow":{"collectors":["192.168.1.99:2056"]}}
    Copy to Clipboard Toggle word wrap

  2. 각 노드에서 OVS의 네트워크 흐름 구성을 확인합니다.

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range@.items[*]}{.metadata.name}{"\n"}{end}');
      do ;
        echo;
        echo $pod;
        oc -n openshift-ovn-kubernetes exec -c ovnkube-node $pod \
          -- bash -c 'for type in ipfix sflow netflow ; do ovs-vsctl find $type ; done';
    done
    Copy to Clipboard Toggle word wrap

    출력 예

    ovnkube-node-xrn4p
    _uuid               : a4d2aaca-5023-4f3d-9400-7275f92611f9
    active_timeout      : 60
    add_id_to_interface : false
    engine_id           : []
    engine_type         : []
    external_ids        : {}
    targets             : ["192.168.1.99:2056"]
    
    ovnkube-node-z4vq9
    _uuid               : 61d02fdb-9228-4993-8ff5-b27f01a29bd6
    active_timeout      : 60
    add_id_to_interface : false
    engine_id           : []
    engine_type         : []
    external_ids        : {}
    targets             : ["192.168.1.99:2056"]-
    
    ...
    Copy to Clipboard Toggle word wrap

25.21.3. 네트워크 흐름 수집기의 모든 대상 삭제

클러스터 관리자는 네트워크 흐름 수집기로 네트워크 흐름 메타데이터를 중지하도록 CNO(Cluster Network Operator)를 구성할 수 있습니다.

사전 요구 사항

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

절차

  1. 모든 네트워크 흐름 수집기를 제거합니다.

    $ oc patch network.operator cluster --type='json' \
        -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'
    Copy to Clipboard Toggle word wrap

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

25.22. 하이브리드 네트워킹 구성

클러스터 관리자는 Linux 및 Windows 노드에서 각각 Linux 및 Windows 워크로드를 호스팅할 수 있도록 Red Hat OpenShift Networking OVN-Kubernetes 네트워크 플러그인을 구성할 수 있습니다.

25.22.1. OVN-Kubernetes로 하이브리드 네트워킹 구성

OVN-Kubernetes 네트워크 플러그인에서 하이브리드 네트워킹을 사용하도록 클러스터를 구성할 수 있습니다. 이를 통해 다양한 노드 네트워킹 구성을 지원하는 하이브리드 클러스터를 사용할 수 있습니다.

참고

이 구성은 동일한 클러스터에서 Linux 및 Windows 노드를 모두 실행하려면 필요합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인합니다.

프로세스

  1. OVN-Kubernetes 하이브리드 네트워크 오버레이를 구성하려면 다음 명령을 입력합니다.

    $ oc patch networks.operator.openshift.io cluster --type=merge \
      -p '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "hybridOverlayConfig":{
                "hybridClusterNetwork":[
                  {
                    "cidr": "<cidr>",
                    "hostPrefix": <prefix>
                  }
                ],
                "hybridOverlayVXLANPort": <overlay_port>
              }
            }
          }
        }
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    cidr
    추가 오버레이 네트워크의 노드에 사용되는 CIDR 구성을 지정합니다. 이 CIDR은 클러스터 네트워크 CIDR과 겹치지 않아야 합니다.
    hostPrefix
    각 개별 노드에 할당할 서브넷 접두사 길이를 지정합니다. 예를 들어 hostPrefix23으로 설정하면 지정된 cidr 이외 /23 서브넷이 각 노드에 할당되어 510(2^(32 - 23) - 2) Pod IP 주소가 허용됩니다. 외부 네트워크에서 노드에 액세스해야 하는 경우 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.
    hybridOverlayVXLANPort
    추가 오버레이 네트워크에 대한 사용자 정의 VXLAN 포트를 지정합니다. 이는 vSphere에 설치된 클러스터에서 Windows 노드를 실행해야 하며 다른 클라우드 공급자에 대해 구성해서는 안 됩니다. 사용자 정의 포트는 기본 4789 포트를 제외한 모든 오픈 포트일 수 있습니다. 이 요구 사항에 대한 자세한 내용은 호스트 간의 포드 투 포트 연결 중단에 대한 Microsoft 문서를 참조하십시오.
    참고

    Windows Server LTSC(Long-Term Servicing Channel): Windows Server 2019는 사용자 지정 hybridOverlayVXLANPort 값이 있는 클러스터에서 지원되지 않습니다. 이 Windows 서버 버전은 사용자 지정 VXLAN 포트를 선택하는 것을 지원하지 않기 때문입니다.

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

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

    $ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"
    Copy to Clipboard Toggle word wrap

26장. OpenShift SDN 네트워크 플러그인

26.1. OpenShift SDN 네트워크 플러그인 정보

Red Hat OpenShift Networking의 일부인 OpenShift SDN은 소프트웨어 정의 네트워킹(SDN) 접근법을 사용하여 OpenShift Container Platform 클러스터 전체의 포드 간 통신이 가능한 통합 클러스터 네트워크를 제공하는 네트워크 플러그인입니다. 이 pod 네트워크는 OVS(Open vSwitch)를 사용하여 오버레이 네트워크를 구성하는 OpenShift SDN에 의해 설정 및 유지 관리됩니다.

중요

cloud -provider=external 옵션이 cloud-provider- vsphere 로 설정된 클라우드 컨트롤러 관리자(CCM)의 경우 여러 서브넷이 있는 네트워킹 환경에서 작동하는 클러스터에 대해 알려진 문제가 있습니다.

OpenShift Container Platform 4.12에서 OpenShift Container Platform 4.13으로 클러스터를 업그레이드할 때 CCM은 잘못된 노드 IP 주소를 선택하고 이 작업은 네임스페이스/openshift-cloud-controller-manager/pods/vsphere-cloud-controller-manager 로그에 오류 메시지를 생성합니다. 오류 메시지는 클러스터의 노드 IP 주소 및 vsphere-cloud-controller-manager Pod IP 주소와 일치하지 않음을 나타냅니다.

알려진 문제는 클러스터 업그레이드 작업에 영향을 미치지 않지만 클러스터가 네트워킹 요구 사항에 사용하는 nodeNetworking.external.networkSubnetCidrnodeNetworking.internal.networkSubnetCidr 매개변수 모두에서 올바른 IP 주소를 설정할 수 있습니다.

26.1.1. OpenShift SDN 네트워크 격리 모드

OpenShift SDN은 pod 네트워크 구성을 위한 세 가지 SDN 모드를 제공합니다.

  • 네트워크 정책 모드를 통해 프로젝트 관리자는 NetworkPolicy 개체를 사용하여 자체 격리 정책을 구성할 수 있습니다. 네트워크 정책은 OpenShift Container Platform 4.13의 기본 모드입니다.
  • 다중 테넌트 모드를 사용하면 Pod 및 서비스에 대한 프로젝트 수준 격리를 제공할 수 있습니다. 다른 프로젝트의 Pod는 다른 프로젝트의 Pod 및 Service에서 패킷을 보내거나 받을 수 없습니다. 프로젝트에 대한 격리를 비활성화하여 전체 클러스터의 모든 pod 및 service에 네트워크 트래픽을 보내고 해당 pod 및 service로부터 네트워크 트래픽을 수신할 수 있습니다.
  • 서브넷 모드는 모든 pod가 다른 모든 pod 및 service와 통신할 수 있는 플랫 pod 네트워크를 제공합니다. 네트워크 정책 모드는 서브넷 모드와 동일한 기능을 제공합니다.

26.1.2. 지원되는 네트워크 플러그인 기능 매트릭스

Red Hat OpenShift Networking은 네트워크 플러그인에 대해 네트워크 플러그인의 두 가지 옵션인 OpenShift SDN 및 OVN-Kubernetes를 제공합니다. 다음 표에는 두 네트워크 플러그인에 대한 현재 기능 지원이 요약되어 있습니다.

Expand
표 26.1. 기본 CNI 네트워크 플러그인 기능 비교
기능OpenShift SDNOVN-Kubernetes

송신 IP

지원됨

지원됨

송신 방화벽

지원됨

지원됨 [1]

송신 라우터

지원됨

지원됨 [2]

하이브리드 네트워킹

지원되지 않음

지원됨

클러스터 내 통신에 대한 IPsec 암호화

지원되지 않음

지원됨

IPv4 단일 스택

지원됨

지원됨

IPv6 단일 스택

지원되지 않음

지원됨 [3]

IPv4/IPv6 dual-stack

지원되지 않음

지원됨 [4]

IPv6/IPv4 듀얼 스택

지원되지 않음

지원됨 [5]

Kubernetes 네트워크 정책

지원됨

지원됨

Kubernetes 네트워크 정책 로그

지원되지 않음

지원됨

하드웨어 오프로드

지원되지 않음

지원됨

멀티 캐스트

지원됨

지원됨

  1. 송신 방화벽은 OpenShift SDN에서 송신 네트워크 정책이라고도 합니다. 이것은 네트워크 정책 송신과 동일하지 않습니다.
  2. OVN-Kubernetes용 송신 라우터는 리디렉션 모드만 지원합니다.
  3. 베어 메탈 플랫폼의 IPv6 단일 스택 네트워킹.
  4. 베어 메탈, VMware vSphere(installer 프로비저닝 인프라 설치 전용), IBM Power® 및 IBM Z® 플랫폼의 IPv4/IPv6 듀얼 스택 네트워킹. VMware vSphere에는 듀얼 스택 네트워킹 제한 사항이 있습니다.
  5. 베어 메탈 및 IBM Power® 플랫폼의 IPv6/IPv4 듀얼 스택 네트워킹.

26.2. OpenShift SDN 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 OVN-Kubernetes 네트워크 플러그인에서 OpenShift SDN 네트워크 플러그인으로 마이그레이션할 수 있습니다.

OpenShift SDN에 대한 자세한 내용은 OpenShift SDN 네트워크 플러그인 정보를 참조하십시오.

26.2.1. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

Expand
표 26.2. OVN-Kubernetes에서 OpenShift SDN으로 마이그레이션
사용자 시작 단계마이그레이션 활동

cluster 라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OpenShiftSDN 으로 설정합니다. 값으로 설정하기 전에 migration 필드가 null인지 확인합니다.

CNO(Cluster Network Operator)
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.
Machine Config Operator (MCO)
OpenShift SDN에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하여 기본적으로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간을 생성합니다.

Network.config.openshift.io CR의 networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OVN-Kubernetes 컨트롤 플레인 Pod를 제거합니다.
  • OpenShift SDN 컨트롤 플레인 포드를 배포합니다.
  • 새 네트워크 플러그인을 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터는 OpenShift SDN 클러스터 네트워크의 포드에 IP 주소를 할당합니다.

26.2.2. OpenShift SDN 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 오프라인 마이그레이션 방법을 사용하여 OpenShift SDN CNI(Container Network Interface) 네트워크 플러그인으로 롤백할 수 있습니다. 마이그레이션 중에 클러스터의 모든 노드를 수동으로 재부팅해야 합니다. 오프라인 마이그레이션 방법을 사용하면 클러스터에 연결할 수 없는 몇 가지 다운타임이 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OVN-Kubernetes 네트워크 플러그인으로 구성된 인프라에 설치된 클러스터입니다.
  • etcd 데이터베이스의 최근 백업을 사용할 수 있습니다.
  • 각 노드에 대해 재부팅을 수동으로 트리거할 수 있습니다.
  • 클러스터가 오류 없이 알려진 정상 상태입니다.

절차

  1. MCO(Machine Config Operator)에서 관리하는 모든 머신 구성 풀을 중지합니다.

    • CLI에 다음 명령을 입력하여 마스터 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": true } }'
      Copy to Clipboard Toggle word wrap
    • CLI에 다음 명령을 입력하여 작업자 머신 구성 풀을 중지합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec":{ "paused": true } }'
      Copy to Clipboard Toggle word wrap
  2. 마이그레이션을 준비하려면 CLI에 다음 명령을 입력하여 migration 필드를 null 로 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'
    Copy to Clipboard Toggle word wrap
  3. CLI에 다음 명령을 입력하여 마이그레이션 상태가 Network.config.openshift.io 오브젝트에 비어 있는지 확인합니다. 빈 명령 출력은 오브젝트가 마이그레이션 작업에 없음을 나타냅니다.

    $ oc get Network.config cluster -o jsonpath='{.status.migration}'
    Copy to Clipboard Toggle word wrap
  4. CLI에 다음 명령을 입력하여 네트워크 플러그인을 OpenShift SDN으로 설정하려면 Network.operator.openshift.io 오브젝트에 패치를 적용합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'
    Copy to Clipboard Toggle word wrap
    중요

    패치 작업이 Network.operator.openshift.io 오브젝트에서 종료되기 전에 Network.config.openshift.io 오브젝트에 패치를 적용한 경우 CNO(Cluster Network Operator)가 성능 저하 상태로 전환되어 CNO가 degraded 상태에서 복구될 때까지 약간의 지연이 발생합니다.

  5. CLI에 다음 명령을 입력하여 Network.config.openshift.io 클러스터 오브젝트의 네트워크 플러그인의 마이그레이션 상태가 OpenShiftSDN 인지 확인합니다.

    $ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'
    Copy to Clipboard Toggle word wrap
  6. CLI에 다음 명령을 입력하여 네트워크 플러그인을 OpenShift SDN으로 설정하려면 Network.config.openshift.io 오브젝트에 패치를 적용합니다.

    $ oc patch Network.config.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'
    Copy to Clipboard Toggle word wrap
  7. 선택 사항: 동일한 OpenShift SDN으로 여러 OVN-Kubernetes 기능의 자동 마이그레이션을 비활성화합니다.

    • 송신 IP
    • 송신 방화벽
    • 멀티 캐스트

    이전에 명시된 OpenShift SDN 기능에 대한 구성 자동 마이그레이션을 비활성화하려면 다음 키를 지정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{
        "spec": {
          "migration": {
            "networkType": "OpenShiftSDN",
            "features": {
              "egressIP": <bool>,
              "egressFirewall": <bool>,
              "multicast": <bool>
            }
          }
        }
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    bool: 기능의 마이그레이션을 활성화할지 여부를 지정합니다. 기본값은 true입니다.

  8. 선택 사항: OpenShift SDN에 대해 네트워크 인프라 요구 사항을 충족하도록 다음 설정을 사용자 정의할 수 있습니다.

    • 최대 전송 단위(MTU)
    • VXLAN 포트

    이전에 명시된 설정 중 하나 또는 둘 다를 사용자 지정하려면 CLI에 다음 명령을 사용자 지정하고 입력합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":<mtu>,
              "vxlanPort":<port>
        }}}}'
    Copy to Clipboard Toggle word wrap
    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
        }}}}'
    Copy to Clipboard Toggle word wrap

  9. 클러스터의 각 노드를 재부팅합니다. 다음 방법 중 하나를 사용하여 클러스터의 노드를 재부팅할 수 있습니다.

    • oc rsh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다.

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 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
      Copy to Clipboard Toggle word wrap
  10. Multus 데몬 세트 롤아웃이 완료될 때까지 기다립니다. 다음 명령을 실행하여 롤아웃 상태를 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus pod의 이름은 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
    Copy to Clipboard Toggle word wrap

  11. 클러스터의 노드가 재부팅되고 multus Pod가 롤아웃되면 다음 명령을 실행하여 모든 머신 구성 풀을 시작합니다.

    • 마스터 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap
    • 작업자 구성 풀을 시작합니다.

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap

    MCO는 각 구성 풀에서 머신을 업데이트하므로 각 노드를 재부팅합니다.

    기본적으로 MCO는 한 번에 풀당 단일 머신을 업데이트하므로 마이그레이션이 완료하는 데 필요한 시간은 클러스터 크기와 함께 증가합니다.

  12. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 CLI에 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

  13. 마이그레이션이 성공했는지 확인합니다.

    1. 네트워크 플러그인이 OpenShift SDN인지 확인하려면 CLI에 다음 명령을 입력합니다. status.networkType 값은 OpenShiftSDN이어야 합니다.

      $ oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. 클러스터 노드가 Ready 상태인지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. Pod를 나열하려면 CLI에 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 이전 출력에 표시된 각 머신 구성 데몬 포드에 대한 Pod 로그를 표시하려면 CLI에 다음 명령을 입력합니다.

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
    4. Pod가 오류 상태가 아닌지 확인하려면 CLI에 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

  14. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. Cluster Network Operator 구성 오브젝트에서 마이그레이션 구성을 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OVN-Kubernetes 구성을 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
      Copy to Clipboard Toggle word wrap
    3. OVN-Kubernetes 네트워크 공급자 네임스페이스를 제거하려면 CLI에 다음 명령을 입력합니다.

      $ oc delete namespace openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

26.3. OVN-Kubernetes 네트워크 플러그인으로 롤백

클러스터 관리자는 OpenShift SDN으로 마이그레이션에 실패한 경우 OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 롤백할 수 있습니다.

OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 네트워크 플러그인 정보를 참조하십시오.

26.3.1. OVN-Kubernetes 네트워크 플러그인으로 마이그레이션

클러스터 관리자는 클러스터의 네트워크 플러그인을 OVN-Kubernetes로 변경할 수 있습니다. 마이그레이션하는 동안 클러스터의 모든 노드를 재부팅해야 합니다.

중요

마이그레이션을 수행하는 동안 클러스터를 사용할 수 없으며 워크로드가 중단될 수 있습니다. 서비스 중단이 허용되는 경우에만 마이그레이션을 수행합니다.

사전 요구 사항

  • 네트워크 정책 격리 모드에서 OpenShift SDN CNI 네트워크 플러그인으로 구성된 클러스터가 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 데이터베이스의 최근 백업이 있습니다.
  • 각 노드를 수동으로 재부팅할 수 있습니다.
  • 클러스터가 오류 없이 알려진 양호한 상태에 있는지 확인합니다.
  • 모든 클라우드 플랫폼의 모든 노드에 대해 포트 6081 에서 UDP(User Datagram Protocol) 패킷을 허용하는 보안 그룹 규칙을 생성했습니다.

프로세스

  1. 클러스터 네트워크의 구성을 백업하려면 다음 명령을 입력합니다.

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 OVN_SDN_MIGRATION_TIMEOUT 환경 변수가 설정되어 있고 0s 와 같은지 확인합니다.

    #!/bin/bash
    
    if [ -n "$OVN_SDN_MIGRATION_TIMEOUT" ] && [ "$OVN_SDN_MIGRATION_TIMEOUT" = "0s" ]; then
        unset OVN_SDN_MIGRATION_TIMEOUT
    fi
    
    #loops the timeout command of the script to repeatedly check the cluster Operators until all are available.
    
    co_timeout=${OVN_SDN_MIGRATION_TIMEOUT:-1200s}
    timeout "$co_timeout" bash <<EOT
    until
      oc wait co --all --for='condition=AVAILABLE=True' --timeout=10s && \
      oc wait co --all --for='condition=PROGRESSING=False' --timeout=10s && \
      oc wait co --all --for='condition=DEGRADED=False' --timeout=10s;
    do
      sleep 10
      echo "Some ClusterOperators Degraded=False,Progressing=True,or Available=False";
    done
    EOT
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 CNO(Cluster Network Operator) 구성 오브젝트에서 구성을 제거합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
    --patch '{"spec":{"migration":null}}'
    Copy to Clipboard Toggle word wrap
  4. 다음 단계를 완료하여 OpenShift SDN 네트워크 플러그인의 기본 네트워크 인터페이스를 정의하는 NodeNetworkConfigurationPolicy (NNCP) 사용자 정의 리소스(CR)를 삭제합니다.

    1. 다음 명령을 입력하여 기존 NNCP CR이 기본 인터페이스를 클러스터에 연결했는지 확인합니다.

      $ oc get nncp
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured
      Copy to Clipboard Toggle word wrap

      Network Manager는 결합된 기본 인터페이스에 대한 연결 프로필을 /etc/NetworkManager/system-connections 시스템 경로에 저장합니다.

    2. 클러스터에서 NNCP를 제거합니다.

      $ oc delete nncp <nncp_manifest_filename>
      Copy to Clipboard Toggle word wrap
  5. 마이그레이션을 위해 모든 노드를 준비하려면 다음 명령을 실행하여 CNO 구성 오브젝트에서 migration 필드를 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    Copy to Clipboard Toggle word wrap
    참고

    이 단계는 OVN-Kubernetes를 즉시 배포하지 않습니다. 대신 migration 필드를 지정하면 OVN-Kubernetes 배포를 준비하기 위해 MCO(Machine Config Operator)가 클러스터의 모든 노드에 새 머신 구성을 적용합니다.

    1. 다음 명령을 실행하여 재부팅이 완료되었는지 확인합니다.

      $ oc get mcp
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 모든 클러스터 Operator를 사용할 수 있는지 확인합니다.

      $ oc get co
      Copy to Clipboard Toggle word wrap
    3. 또는 여러 OpenShift SDN 기능을 동등한 OVN-Kubernetes로 자동 마이그레이션을 비활성화할 수 있습니다.

      • 송신 IP
      • 송신 방화벽
      • 멀티 캐스트

      이전에 명시된 OpenShift SDN 기능에 대한 구성 자동 마이그레이션을 비활성화하려면 다음 키를 지정합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{
          "spec": {
            "migration": {
              "networkType": "OVNKubernetes",
              "features": {
                "egressIP": <bool>,
                "egressFirewall": <bool>,
                "multicast": <bool>
              }
            }
          }
        }'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      bool: 기능의 마이그레이션을 활성화할지 여부를 지정합니다. 기본값은 true입니다.

  6. 선택 사항: OVN-Kubernetes에 대해 다음 설정을 사용자 정의하여 네트워크 인프라 요구 사항을 충족할 수 있습니다.

    • 최대 전송 단위(MTU)입니다. 이 선택적 단계에 대한 MTU를 사용자 정의하기 전에 다음을 고려하십시오.

      • 기본 MTU를 사용하고 마이그레이션 중에 기본 MTU를 유지하려면 이 단계를 무시할 수 있습니다.
      • 사용자 지정 MTU를 사용한 후 마이그레이션 중에 사용자 지정 MTU를 유지하려면 이 단계에서 사용자 지정 MTU 값을 선언해야 합니다.
      • 마이그레이션 중에 MTU 값을 변경하려는 경우 이 단계가 작동하지 않습니다. 대신 먼저 "클러스터 MTU 변경"에 대한 지침을 따라야 합니다. 그런 다음 이 절차를 수행하고 이 단계에서 사용자 지정 MTU 값을 선언하여 사용자 지정 MTU 값을 유지할 수 있습니다.

        참고

        OpenShift-SDN 및 OVN-Kubernetes에는 다른 오버레이 오버헤드가 있습니다. MTU 값은 "MTU 값 선택" 페이지에 있는 지침에 따라 선택해야 합니다.

    • Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크 포트
    • OVN-Kubernetes IPv4 내부 서브넷
    • OVN-Kubernetes IPv6 내부 서브넷

    이전에 명시된 설정 중 하나를 사용자 정의하려면 다음 명령을 입력하고 사용자 정의합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    mtu
    Geneve 오버레이 네트워크용 MTU입니다. MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 100을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    Geneve 오버레이 네트워크용 UDP 포트입니다. 값을 지정하지 않으면 기본값은 6081입니다. 이 포트는 OpenShift SDN에서 사용하는 VXLAN 포트와 같을 수 없습니다. VXLAN 포트의 기본값은 4789입니다.
    ipv4_subnet
    OVN-Kubernetes에서 내부용으로 사용할 IPv4 주소 범위입니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 100.64.0.0/16 입니다.
    ipv6_subnet
    OVN-Kubernetes에서 내부용으로 사용할 IPv6 주소 범위입니다. IP 주소 범위가 OpenShift Container Platform 설치에 사용된 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 fd98::/48 입니다.

    mtu 필드를 업데이트하는 패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'
    Copy to Clipboard Toggle word wrap

  7. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  8. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      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
      Copy to Clipboard Toggle word wrap

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart
      Copy to Clipboard Toggle word wrap

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
      Copy to Clipboard Toggle word wrap
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 다음 명령을 입력하여 이전 출력에 표시된 첫 번째 머신 구성 데몬 포드에 대한 포드 로그를 표시합니다.

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
  9. 마이그레이션을 시작하려면 다음 명령 중 하나를 사용하여 OVN-Kubernetes 네트워크 플러그인을 구성합니다.

    • 클러스터 네트워크 IP 주소 블록을 변경하지 않고 네트워크 공급자를 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
      Copy to Clipboard Toggle word wrap
    • 다른 클러스터 네트워크 IP 주소 블록을 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'
      Copy to Clipboard Toggle word wrap

      여기서 cidr은 CIDR 블록이며 prefix는 클러스터의 각 노드에 승인된 CIDR 블록 조각입니다. OVN-Kubernetes 네트워크 공급자가 이 블록을 내부에서 사용하므로 100.64.0.0/16 CIDR 블록과 겹치는 CIDR 블록을 사용할 수 없습니다.

      중요

      마이그레이션 중에 서비스 네트워크 주소 블록을 변경할 수 없습니다.

  10. 후속 단계를 계속 진행하기 전에 Multus 데몬 세트 롤아웃이 완료되었는지 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus pod의 이름은 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
    Copy to Clipboard Toggle word wrap

  11. 네트워크 플러그인 변경을 완료하려면 클러스터의 각 노드를 재부팅합니다. 다음 방법 중 하나를 사용하여 클러스터의 노드를 재부팅할 수 있습니다.

    중요

    다음 스크립트는 클러스터의 모든 노드를 동시에 재부팅합니다. 이로 인해 클러스터가 불안정해질 수 있습니다. 또 다른 옵션은 노드를 한 번에 수동으로 재부팅하는 것입니다. 노드를 하나씩 재부팅하면 여러 노드가 있는 클러스터에서 상당한 다운타임이 발생합니다.

    노드를 재부팅하기 전에 클러스터 Operator가 제대로 작동하지 않습니다.

    • oc rsh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다.

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh 명령을 사용하면 다음과 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 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
      Copy to Clipboard Toggle word wrap
  12. 마이그레이션이 성공했는지 확인합니다.

    1. 네트워크 플러그인이 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다. status.networkType의 값은 OVNKubernetes이어야 합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

    4. 모든 클러스터 Operator가 비정상적인 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get co
      Copy to Clipboard Toggle word wrap

      모든 클러스터 Operator의 상태는 AVAILABLE="True", PROGRESSING="False", DEGRADED="False"여야 합니다. 클러스터 Operator를 사용할 수 없거나 성능이 저하된 경우 자세한 내용은 클러스터 Operator의 로그를 확인합니다.

  13. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. CNO 구성 오브젝트에서 마이그레이션 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OpenShift SDN 네트워크 제공자에 대한 사용자 정의 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
      Copy to Clipboard Toggle word wrap
    3. OpenShift SDN 네트워크 공급자 네임스페이스를 제거하려면 다음 명령을 입력합니다.

      $ oc delete namespace openshift-sdn
      Copy to Clipboard Toggle word wrap

26.4. 프로젝트의 송신 IP 구성

클러스터 관리자는 OpenShift SDN CNI(Container Network Interface) 네트워크 플러그인을 구성하여 하나 이상의 송신 IP 주소를 프로젝트에 할당할 수 있습니다.

26.4.1. 송신 IP 주소 아키텍처 설계 및 구현

OpenShift Container Platform 송신 IP 주소 기능을 사용하면 하나 이상의 네임스페이스에 있는 하나 이상의 Pod에서 발생하는 트래픽의 소스 IP 주소가 클러스터 네트워크 외부 서비스에 일관되게 표시되도록 할 수 있습니다.

예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.

네임스페이스에 할당된 송신 IP 주소는 특정 대상으로 트래픽을 보내는 데 사용되는 송신 라우터와 다릅니다.

일부 클러스터 구성에서 애플리케이션 Pod 및 수신 라우터 Pod는 동일한 노드에서 실행됩니다. 이 시나리오에서 애플리케이션 프로젝트의 송신 IP 주소를 구성하면 애플리케이션 프로젝트의 경로에 요청을 보낼 때 IP 주소가 사용되지 않습니다.

송신 IP 주소는 노드의 기본 네트워크 인터페이스에서 추가 IP 주소로 구현되며 노드의 기본 IP 주소와 동일한 서브넷에 있어야 합니다. 추가 IP 주소를 클러스터의 다른 노드에 할당해서는 안 됩니다.

중요

송신 IP 주소는 ifcfg-eth0과 같은 Linux 네트워크 구성 파일에서 구성하지 않아야 합니다.

26.4.1.1. 플랫폼 지원

다음 표에는 다양한 플랫폼의 송신 IP 주소 기능에 대한 지원이 요약되어 있습니다.

Expand
플랫폼지원됨

베어 메탈

제공됨

VMware vSphere

제공됨

Red Hat OpenStack Platform (RHOSP)

제공됨

AWS(Amazon Web Services)

제공됨

GCP(Google Cloud Platform)

제공됨

Microsoft Azure

제공됨

IBM Z 및 IBM® LinuxONE

제공됨

IBM Z 및 IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM

제공됨

IBM Power

제공됨

중요

EgressIP 기능을 사용하여 컨트롤 플레인 노드에 송신 IP 주소 할당은 AWS(Amazon Web Services)에서 프로비저닝된 클러스터에서 지원되지 않습니다. (BZ#2039656)

26.4.1.2. 퍼블릭 클라우드 플랫폼 고려 사항

퍼블릭 클라우드 인프라에 프로비저닝된 클러스터의 경우 노드당 할당 가능한 IP 주소 수에 제약 조건이 있습니다. 노드당 할당 가능한 최대 IP 주소 수 또는 IP 용량 은 다음 공식에서 설명할 수 있습니다.

IP capacity = public cloud default capacity - sum(current IP assignments)
Copy to Clipboard Toggle word wrap

Egress IPs 기능은 노드당 IP 주소 용량을 관리하지만 배포에서 이 제약 조건을 계획해야 합니다. 예를 들어 8개의 노드로 베어 메탈 인프라에 설치된 클러스터의 경우 150개 송신 IP 주소를 구성할 수 있습니다. 그러나 퍼블릭 클라우드 공급자가 노드당 IP 주소 용량을 10개로 제한하는 경우 할당 가능한 총 IP 주소 수는 80입니다. 이 예제 클라우드 공급자에서 동일한 IP 주소 용량을 얻으려면 7 개의 추가 노드를 할당해야 합니다.

퍼블릭 클라우드 환경에서 노드의 IP 용량 및 서브넷을 확인하려면 oc get node <node_name> -o yaml 명령을 입력합니다. cloud.network.openshift.io/egress-ipconfig 주석에는 노드의 용량 및 서브넷 정보가 포함됩니다.

주석 값은 기본 네트워크 인터페이스에 대해 다음 정보를 제공하는 필드가 있는 단일 오브젝트가 있는 배열입니다.

  • Interface: AWS 및 Azure의 인터페이스 ID와 GCP의 인터페이스 이름을 지정합니다.
  • ifaddr: 하나 또는 두 IP 주소 제품군의 서브넷 마스크를 지정합니다.
  • capacity: 노드의 IP 주소 용량을 지정합니다. AWS에서는 IP 주소 제품군별로 IP 주소 용량이 제공됩니다. Azure 및 GCP에서 IP 주소 용량에는 IPv4 및 IPv6 주소가 모두 포함됩니다.

노드 간 트래픽에 대한 송신 IP 주소 자동 연결 및 분리를 사용할 수 있습니다. 이렇게 하면 네임스페이스의 많은 Pod에서 트래픽이 클러스터 외부의 위치와 일관된 소스 IP 주소를 가질 수 있습니다. 이는 OpenShift Container Platform 4.13의 Red Hat OpenShift Networking의 기본 네트워킹 플러그인인 OpenShift SDN 및 OVN-Kubernetes도 지원합니다.

참고

RHOSP 송신 IP 주소 기능은 egressip-<IP address>라는 Neutron 예약 포트를 생성합니다. OpenShift Container Platform 클러스터 설치에 사용된 RHOSP 사용자와 동일한 RHOSP 사용자를 사용하면 이 예약 포트에 유동 IP 주소를 할당하여 송신 트래픽에 대해 예측 가능한 SNAT 주소를 보유할 수 있습니다. RHOSP 네트워크의 송신 IP 주소가 한 노드에서 다른 노드로 이동되면 노드 장애 조치로 인해 Neutron 예약 포트가 제거되고 다시 생성됩니다. 즉, 유동 IP 연결이 손실되고 유동 IP 주소를 새 예약 포트에 수동으로 다시 할당해야 합니다.

참고

RHOSP 클러스터 관리자가 예약 포트에 유동 IP를 할당하면 OpenShift Container Platform에서 예약 포트를 삭제할 수 없습니다. CloudPrivateIPConfig 오브젝트는 RHOSP 클러스터 관리자가 예약 포트에서 유동 IP를 할당 해제할 때까지 삭제 및 이동 작업을 수행할 수 없습니다.

다음 예제에서는 여러 퍼블릭 클라우드 공급자에 있는 노드의 주석을 보여줍니다. 가독성을 위해 주석이 들여쓰기됩니다.

AWS의 cloud.network.openshift.io/egress-ipconfig 주석의 예

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]
Copy to Clipboard Toggle word wrap

GCP의 cloud.network.openshift.io/egress-ipconfig 주석의 예

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]
Copy to Clipboard Toggle word wrap

다음 섹션에서는 용량 계산에 사용할 지원되는 퍼블릭 클라우드 환경에 대한 IP 주소 용량을 설명합니다.

26.4.1.2.1. AWS(Amazon Web Services) IP 주소 용량 제한

AWS에서 IP 주소 할당에 대한 제약 조건은 구성된 인스턴스 유형에 따라 달라집니다. 자세한 내용은 인스턴스 유형당 네트워크 인터페이스당 IP 주소를참조하십시오.

26.4.1.2.2. GCP(Google Cloud Platform) IP 주소 용량 제한

GCP에서 네트워킹 모델은 IP 주소 할당이 아닌 IP 주소 별칭을 통해 추가 노드 IP 주소를 구현합니다. 그러나 IP 주소 용량은 IP 별칭 용량에 직접 매핑됩니다.

IP 별칭 할당을 위해 다음 용량 제한이 있습니다.

  • 노드당 최대 IP 별칭 수, IPv4 및 IPv6 모두 100입니다.
  • VPC당 최대 IP 별칭은 지정되지 않지만 OpenShift Container Platform 확장성 테스트에서는 최대 IP가 약 15,000개임을 보여줍니다.

자세한 내용은 Per instance Quota and Alias IP ranges overview 를 참조하십시오.

26.4.1.2.3. Microsoft Azure IP 주소 용량 제한

Azure에서 IP 주소 할당에 대해 다음 용량 제한이 있습니다.

  • NIC당 IPv4 및 IPv6의 할당 가능 IP 주소의 최대 수는 256입니다.
  • 가상 네트워크당 할당된 IP 주소의 최대 수는 65,536개를 초과할 수 없습니다.

자세한 내용은 네트워킹 제한 항목을 참조하십시오.

26.4.1.3. 제한

다음 제한 사항은 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를 참조하십시오.

26.4.1.4. IP 주소 할당 접근 방식

NetNamespace 오브젝트의 egressIPs 매개변수를 설정하여 네임스페이스에 송신 IP 주소를 지정할 수 있습니다. 송신 IP 주소가 프로젝트와 연결된 후 OpenShift SDN을 사용하면 다음 두 가지 방법으로 송신 IP 주소를 호스트에 할당할 수 있습니다.

  • 자동 할당 방식에서는 송신 IP 주소 범위가 노드에 할당됩니다.
  • 수동 할당 방식에서는 하나 이상의 송신 IP 주소 목록이 노드에 할당됩니다.

송신 IP 주소를 요청하는 네임스페이스는 해당 송신 IP 주소를 호스트할 수 있는 노드와 일치되며 송신 IP 주소가 해당 노드에 할당됩니다. egressIPs 매개변수가 NetNamespace 오브젝트에 설정되었지만 IP 주소를 송신하는 노드 호스트가 없는 경우 네임스페이스에서 송신하는 트래픽이 삭제됩니다.

노드의 고가용성은 자동입니다. 송신 IP 주소를 호스팅하는 노드에 도달할 수 없고 해당 송신 IP 주소를 호스트할 수 있는 노드가 있으면 송신 IP 주소가 새 노드로 이동합니다. 연결할 수 없는 노드가 다시 온라인 상태가 되면 송신 IP 주소가 자동으로 이동하여 노드 간에 송신 IP 주소의 균형을 조정합니다.

26.4.1.4.1. 자동 할당된 송신 IP 주소 사용 시 고려사항

송신 IP 주소에 자동 할당 방식을 사용할 때는 다음 사항을 고려해야 합니다.

  • 각 노드의 HostSubnet 리소스의 egressCIDRs 매개변수를 설정하여 노드가 호스트할 수 있는 송신 IP 주소 범위를 나타냅니다. OpenShift Container Platform은 지정한 IP 주소 범위를 기반으로 HostSubnet 리소스의 egressIPs 매개변수를 설정합니다.

네임스페이스의 송신 IP 주소를 호스팅하는 노드에 도달할 수 없는 경우 OpenShift Container Platform은 호환되는 송신 IP 주소 범위를 가진 다른 노드에 송신 IP 주소를 다시 할당합니다. 자동 할당 방식은 추가 IP 주소를 노드와 연결할 수 있는 유연성이 있는 환경에 설치된 클러스터에 가장 적합합니다.

26.4.1.4.2. 수동으로 할당된 송신 IP 주소 사용 시 고려사항

이 방법을 사용하면 송신 IP 주소를 호스팅할 수 있는 노드를 제어할 수 있습니다.

참고

클러스터가 퍼블릭 클라우드 인프라에 설치된 경우 송신 IP 주소를 할당하는 각 노드에 IP 주소를 호스팅할 수 있는 충분한 예비 용량이 있는지 확인해야 합니다. 자세한 내용은 이전 섹션의 "플랫사이트 고려 사항"을 참조하십시오.

송신 IP 주소에 수동 할당 방식을 사용할 때는 다음 사항을 고려해야 합니다.

  • 각 노드의 HostSubnet 리소스의 egressIPs 매개변수를 설정하여 노드가 호스트할 수 있는 IP 주소를 표시합니다.
  • 네임스페이스당 여러 개의 송신 IP 주소가 지원됩니다.

네임스페이스에 여러 송신 IP 주소가 있고 해당 주소가 여러 노드에서 호스팅되는 경우 다음과 같은 추가 고려 사항이 적용됩니다.

  • Pod가 송신 IP 주소를 호스팅하는 노드에 있는 경우 해당 pod는 항상 노드에서 송신 IP 주소를 사용합니다.
  • Pod가 송신 IP 주소를 호스팅하는 노드에 없는 경우 해당 Pod는 송신 IP 주소를 임의로 사용합니다.

26.4.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>"
        ]
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <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"]}'
    Copy to Clipboard Toggle word wrap
    참고

    OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

  2. 다음 JSON을 사용하여 각 호스트에 대해 egressCIDRs 매개변수를 설정하여 송신 IP 주소를 호스팅할 수 있는 노드를 표시합니다.

    $ oc patch hostsubnet <node_name> --type=merge -p \
      '{
        "egressCIDRs": [
          "<ip_address_range>", "<ip_address_range>"
        ]
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <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"]}'
    Copy to Clipboard Toggle word wrap

    OpenShift Container Platform은 특정 송신 IP 주소를 균형 잡힌 방식으로 사용 가능한 노드에 자동으로 할당합니다. 이 경우 송신 IP 주소 192.168.1.100을 node1에 할당하고 송신 IP 주소 192.168.1.101을 node2에 할당하거나 그 반대의 경우도 마찬가지입니다.

26.4.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>"
        ]
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <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"]}'
    Copy to Clipboard Toggle word wrap

    고가용성을 제공하기 위해 egressIPs 값을 서로 다른 노드에서 둘 이상의 IP 주소로 설정합니다. 여러 송신 IP 주소가 설정되면 Pod는 모든 송신 IP 주소를 거의 동일하게 사용합니다.

    참고

    OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

  2. 송신 IP 주소를 노드 호스트에 수동으로 할당합니다.

    클러스터가 퍼블릭 클라우드 인프라에 설치된 경우 노드에 사용 가능한 IP 주소 용량이 있는지 확인해야 합니다.

    노드 호스트의 HostSubnet 오브젝트에서 egressIPs 매개변수를 설정합니다. 다음 JSON을 사용하여 해당 노드 호스트에 할당하려는 만큼의 IP 주소를 포함합니다.

    $ oc patch hostsubnet <node_name> --type=merge -p \
      '{
        "egressIPs": [
          "<ip_address>",
          "<ip_address>"
          ]
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <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"]}'
    Copy to Clipboard Toggle word wrap

    이전 예에서 project1의 모든 송신 트래픽은 지정된 송신 IP를 호스팅하는 노드로 라우팅된 다음 NAT(Network Address Translation)를 사용하여 해당 IP 주소에 연결됩니다.

26.4.4. 추가 리소스

  • 수동 송신 IP 주소 할당을 구성하는 경우 IP 용량 계획에 대한 자세한 내용은 플랫폼 고려 사항을 참조하십시오.

26.5. 프로젝트에 대한 송신 방화벽 구성

클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

26.5.1. 프로젝트에서 송신 방화벽이 작동하는 방식

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

참고

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

EgressNetworkPolicy CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
중요

송신 방화벽에 0.0.0.0/0에 대한 거부 규칙이 포함된 경우 OpenShift Container Platform API 서버에 대한 액세스 권한이 차단됩니다. 각 IP 주소에 대해 허용 규칙을 추가하거나 송신 정책 규칙에서 nodeSelector 유형 허용 규칙을 사용하여 API 서버에 연결해야 합니다.

다음 예제에서는 API 서버 액세스를 확인하는 데 필요한 송신 방화벽 규칙의 순서를 보여줍니다.

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: <namespace> 
1

spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 
2

    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 
3

    type: Deny
Copy to Clipboard Toggle word wrap
1
송신 방화벽의 네임스페이스입니다.
2
OpenShift Container Platform API 서버를 포함하는 IP 주소 범위입니다.
3
글로벌 거부 규칙은 OpenShift Container Platform API 서버에 액세스할 수 없습니다.

API 서버의 IP 주소를 찾으려면 oc get ep kubernetes -n default 를 실행합니다.

자세한 내용은 BZ#1988324에서 참조하십시오.

중요

송신 방화벽을 구성하려면 네트워크 정책 또는 다중 테넌트 모드를 사용하도록 OpenShift SDN을 구성해야 합니다.

네트워크 정책 모드를 사용하는 경우 송신 방화벽은 네임스페이스당 하나의 정책과만 호환되며 글로벌 프로젝트와 같이 네트워크를 공유하는 프로젝트에서는 작동하지 않습니다.

주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

26.5.1.1. 송신 방화벽의 제한

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressNetworkPolicy 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.

    중요

    EgressNetworkPolicy 오브젝트를 두 개 이상 생성할 수 있지만 수행할 수는 없습니다. 두 개 이상의 EgressNetworkPolicy 오브젝트를 생성하면 다음 메시지가 반환됩니다. 모든 규칙 삭제. 실제로 모든 외부 트래픽이 삭제되어 조직에 보안 위험이 발생할 수 있습니다.

  • 프로젝트당 최대 1000개의 규칙이 있는 최대 하나의 EgressNetworkPolicy 오브젝트를 정의할 수 있습니다.
  • 기본 프로젝트는 송신 방화벽을 사용할 수 없습니다.
  • 다중 테넌트 모드에서 OpenShift SDN 네트워크 플러그인을 사용하는 경우 다음과 같은 제한 사항이 적용됩니다.

    • 글로벌 프로젝트는 송신 방화벽을 사용할 수 없습니다. oc adm pod-network make-projects-global 명령을 사용하여 프로젝트를 글로벌로 만들 수 있습니다.
    • oc adm pod-network join-projects 명령을 사용하여 병합된 프로젝트는 결합된 프로젝트에서 송신 방화벽을 사용할 수 없습니다.
  • 선택기 없는 서비스를 생성하고 외부 IP를 가리키는 끝점 또는 EndpointSlices 를 수동으로 정의하는 경우 EgressNetworkPolicy 가 모든 송신 트래픽을 거부하도록 구성된 경우에도 서비스 IP로의 트래픽이 계속 허용될 수 있습니다. 이는 OpenShift SDN이 이러한 외부 끝점에 대해 송신 네트워크 정책을 완전히 적용하지 않기 때문에 발생합니다. 이로 인해 외부 서비스에 대한 예기치 않은 액세스가 발생할 수 있습니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상됩니다. 결과적으로 모든 외부 네트워크 트래픽이 삭제되어 조직에 보안 위험이 발생할 수 있습니다.

Egress Firewall 리소스는 kube-node-lease,kube-public,kube-system,openshiftopenshift- 프로젝트에서 생성할 수 있습니다.

26.5.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

26.5.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 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽 정책에서 DNS 이름을 사용하는 것은 CoreDNS를 통한 로컬 DNS 확인에는 영향을 미치지 않습니다.

그러나 송신 방화벽 정책이 도메인 이름을 사용하고 외부 DNS 서버가 영향을 받는 Pod의 DNS 확인을 처리하는 경우 DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 포함해야 합니다.

26.5.2. EgressNetworkPolicy CR(사용자 정의 리소스) 오브젝트

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 허용 규칙 또는 거부 규칙입니다.

다음 YAML은 EgressNetworkPolicy CR 오브젝트를 설명합니다.

EgressNetworkPolicy 오브젝트

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name> 
1

spec:
  egress: 
2

    ...
Copy to Clipboard Toggle word wrap

1
송신 방화벽 정책의 이름입니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.
26.5.2.1. EgressNetworkPolicy 규칙

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 사용자는 CIDR 형식, 도메인 이름에서 IP 주소 범위를 선택하거나 nodeSelector 를 사용하여 송신 트래픽을 허용하거나 거부할 수 있습니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type> 
1

  to: 
2

    cidrSelector: <cidr> 
3

    dnsName: <dns_name> 
4
Copy to Clipboard Toggle word wrap

1
규칙 유형입니다. 값은 허용 또는 거부여야 합니다.
2
송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 규칙에 대한 cidrSelector 필드 또는 dnsName 필드의 값입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
도메인 이름입니다.
26.5.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
Copy to Clipboard Toggle word wrap
1
송신 방화벽 정책 규칙 오브젝트의 컬렉션입니다.

26.5.3. 송신 방화벽 정책 오브젝트 생성

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressNetworkPolicy 오브젝트가 정의되어 있으면 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OpenShift SDN 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

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

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.
  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다.

    $ oc create -f <policy_name>.yaml -n <project>
    Copy to Clipboard Toggle word wrap

    다음 예제에서는 project1이라는 프로젝트에 새 EgressNetworkPolicy 오브젝트를 생성합니다.

    $ oc create -f default.yaml -n project1
    Copy to Clipboard Toggle word wrap

    출력 예

    egressnetworkpolicy.network.openshift.io/v1 created
    Copy to Clipboard Toggle word wrap

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.

26.6. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

26.6.1. EgressNetworkPolicy 오브젝트 보기

클러스터의 EgressNetworkPolicy 오브젝트를 확인할 수 있습니다.

사전 요구 사항

  • OpenShift SDN 네트워크 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressNetworkPolicy 오브젝트의 이름을 보려면 다음 명령을 입력합니다.

    $ oc get egressnetworkpolicy --all-namespaces
    Copy to Clipboard Toggle word wrap
  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다.

    $ oc describe egressnetworkpolicy <policy_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

26.7. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

26.7.1. EgressNetworkPolicy 오브젝트 편집

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OpenShift SDN 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressNetworkPolicy 오브젝트 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressnetworkpolicy
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 송신 네트워크 방화벽을 생성할 때 EgressNetworkPolicy 오브젝트 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다.

    $ oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml
    Copy to Clipboard Toggle word wrap

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressNetworkPolicy 오브젝트를 바꿉니다. 업데이트된 EgressNetworkPolicy 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다.

    $ oc replace -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

26.8. 프로젝트에서 송신 방화벽 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

26.8.1. EgressNetworkPolicy 오브젝트 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OpenShift SDN 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressNetworkPolicy 오브젝트 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressnetworkpolicy
    Copy to Clipboard Toggle word wrap
  2. EgressNetworkPolicy 오브젝트를 삭제하려면 다음 명령을 입력합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다.

    $ oc delete -n <project> egressnetworkpolicy <name>
    Copy to Clipboard Toggle word wrap

26.9. 송신 라우터 Pod 사용에 대한 고려 사항

26.9.1. 송신 라우터 Pod 정보

OpenShift Container Platform 송신 라우터 포드는 다른 용도로 사용되지 않는 프라이빗 소스 IP 주소에서 지정된 원격 서버로 트래픽을 리디렉션합니다. 송신 라우터 포드를 통해 특정 IP 주소에서만 액세스할 수 있도록 설정된 서버로 네트워크 트래픽을 보낼 수 있습니다.

참고

송신 라우터 Pod는 모든 발신 연결을 위한 것은 아닙니다. 다수의 송신 라우터 Pod를 생성하는 경우 네트워크 하드웨어 제한을 초과할 수 있습니다. 예를 들어 모든 프로젝트 또는 애플리케이션에 대해 송신 라우터 Pod를 생성하면 소프트웨어에서 MAC 주소 필터링으로 돌아가기 전에 네트워크 인터페이스에서 처리할 수 있는 로컬 MAC 주소 수를 초과할 수 있습니다.

중요

송신 라우터 이미지는 Amazon AWS, Azure Cloud 또는 macvlan 트래픽과의 비호환성으로 인해 계층 2 조작을 지원하지 않는 기타 클라우드 플랫폼과 호환되지 않습니다.

26.9.1.1. 송신 라우터 모드

리디렉션 모드에서는 송신 라우터 포드가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables 규칙을 구성합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 Pod는 대상 IP에 직접 연결하는 대신 송신 라우터의 서비스에 액세스하도록 구성해야 합니다. curl 명령을 사용하여 애플리케이션 포드에서 대상 서비스 및 포트에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.

$ curl <router_service_IP> <port>
Copy to Clipboard Toggle word wrap

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 프록시 모드를 사용하십시오.

26.9.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를 지정할 수 있습니다.

26.9.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>
Copy to Clipboard Toggle word wrap
RHV(Red Hat Virtualization)
RHV 를 사용하는 경우 가상 네트워크 인터페이스 컨트롤러(vNIC)에 대해 네트워크 필터 없음을 선택해야 합니다.
VMware vSphere
VMware vSphere를 사용하는 경우 vSphere 표준 스위치 보안을 위한 VMware 설명서를 참조하십시오. vSphere Web Client에서 호스트 가상 스위치를 선택하여 VMware vSphere 기본 설정을 보고 변경합니다.

특히 다음이 활성화되어 있는지 확인하십시오.

26.9.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:
        ...
Copy to Clipboard Toggle word wrap
1
항상 하나의 Pod만 지정된 송신 소스 IP 주소를 사용할 수 있으므로 복제본이 1로 설정되어 있는지 확인합니다. 이는 하나의 라우터 사본만 노드에서 실행됨을 의미합니다.
2
송신 라우터 Pod에 대한 Pod 오브젝트 템플릿을 지정합니다.

26.10. 리디렉션 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 트래픽을 지정된 대상 IP 주소로 리디렉션하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

26.10.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
Copy to Clipboard Toggle word wrap
1
주석은 OpenShift Container Platform에 기본 네트워크 인터페이스 컨트롤러(NIC)에서 macvlan 네트워크 인터페이스를 생성하고 해당 macvlan 인터페이스를 Pod의 네트워크 네임스페이스로 이동하도록 지시합니다. "true" 값을 따옴표로 묶어야 합니다. OpenShift Container Platform에서 다른 NIC 인터페이스에서 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
Copy to Clipboard Toggle word wrap

26.10.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
Copy to Clipboard Toggle word wrap

26.10.3. 리디렉션 모드에서 송신 라우터 Pod 배포

리디렉션 모드에서는 송신 라우터 Pod가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables 규칙을 설정합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 pod는 대상 IP에 직접 연결하는 대신 송신 라우터의 서비스에 액세스하도록 구성해야 합니다. curl 명령을 사용하여 애플리케이션 포드에서 대상 서비스 및 포트에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.

$ curl <router_service_IP> <port>
Copy to Clipboard Toggle word wrap

사전 요구 사항

  • 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
    Copy to Clipboard Toggle word wrap

    이제 Pod에서 이 서비스에 연결할 수 있습니다. 이러한 연결은 예약된 송신 IP 주소를 사용하여 외부 서버의 해당 포트로 리디렉션됩니다.

26.11. HTTP 프록시 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 지정된 HTTP 및 HTTPS 기반 서비스로 트래픽을 프록시하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

26.11.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: |-
        ...
    ...
Copy to Clipboard Toggle word wrap
1
주석은 OpenShift Container Platform에 기본 네트워크 인터페이스 컨트롤러(NIC)에서 macvlan 네트워크 인터페이스를 생성하고 해당 macvlan 인터페이스를 Pod의 네트워크 네임스페이스로 이동하도록 지시합니다. "true" 값을 따옴표로 묶어야 합니다. OpenShift Container Platform에서 다른 NIC 인터페이스에서 macvlan 인터페이스를 생성하려면 주석 값을 해당 인터페이스 이름으로 설정합니다. 예를 들면 eth1입니다.
2
송신 라우터 Pod에서 사용하도록 예약된 노드가 있는 물리적 네트워크의 IP 주소입니다. 선택사항: 서브넷 길이를 나타내는 /24 접미사를 포함하여 로컬 서브넷 경로를 적절하게 설정할 수 있습니다. 서브넷 길이를 지정하지 않으면 송신 라우터에서 EGRESS_GATEWAY 변수로 지정된 호스트에만 액세스하고 서브넷의 다른 호스트에는 액세스할 수 없습니다.
3
노드에서 사용하는 기본 게이트웨이와 동일한 값입니다.
4
프록시 구성 방법을 지정하는 문자열 또는 여러 줄로 된 YAML 문자열입니다. 이 문자열은 init 컨테이너의 다른 환경 변수가 아닌 HTTP 프록시 컨테이너의 환경 변수로 지정됩니다.

26.11.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
*
Copy to Clipboard Toggle word wrap

26.11.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
    Copy to Clipboard Toggle word wrap
    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/
        ...
    Copy to Clipboard Toggle word wrap
    1
    이전 단계에서 생성한 서비스입니다.
    참고

    모든 설정에 http_proxyhttps_proxy 환경 변수를 사용할 필요는 없습니다. 위 방법으로 유효한 설정이 생성되지 않으면 Pod에서 실행 중인 툴이나 소프트웨어에 대한 설명서를 참조하십시오.

26.12. DNS 프록시 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 지정된 DNS 이름 및 IP 주소로 트래픽을 프록시하도록 구성된 송신 라우터 Pod를 배포할 수 있습니다.

26.12.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"
    ...
Copy to Clipboard Toggle word wrap
1
주석은 OpenShift Container Platform에 기본 네트워크 인터페이스 컨트롤러(NIC)에서 macvlan 네트워크 인터페이스를 생성하고 해당 macvlan 인터페이스를 Pod의 네트워크 네임스페이스로 이동하도록 지시합니다. "true" 값을 따옴표로 묶어야 합니다. OpenShift Container Platform에서 다른 NIC 인터페이스에서 macvlan 인터페이스를 생성하려면 주석 값을 해당 인터페이스 이름으로 설정합니다. 예를 들면 eth1입니다.
2
송신 라우터 Pod에서 사용하도록 예약된 노드가 있는 물리적 네트워크의 IP 주소입니다. 선택사항: 서브넷 길이를 나타내는 /24 접미사를 포함하여 로컬 서브넷 경로를 적절하게 설정할 수 있습니다. 서브넷 길이를 지정하지 않으면 송신 라우터에서 EGRESS_GATEWAY 변수로 지정된 호스트에만 액세스하고 서브넷의 다른 호스트에는 액세스할 수 없습니다.
3
노드에서 사용하는 기본 게이트웨이와 동일한 값입니다.
4
하나 이상의 프록시 대상 목록을 지정합니다.
5
선택사항: DNS 프록시 로그 출력을 stdout로 출력하도록 지정합니다.

26.12.2. 송신 대상 구성 형식

라우터가 DNS 프록시 모드에서 배포되면 포트 및 대상 매핑 목록을 지정합니다. 대상은 IP 주소 또는 DNS 이름일 수 있습니다.

송신 라우터 Pod는 포트 및 대상 매핑을 지정하기 위해 다음 형식을 지원합니다.

포트 및 원격 주소
두 가지 필드 형식인 <port> <remote_address>를 사용하여 소스 포트와 대상 호스트를 지정할 수 있습니다.

호스트는 IP 주소 또는 DNS 이름일 수 있습니다. DNS 이름을 제공하면 런타임에 DNS를 확인합니다. 지정된 호스트의 경우 프록시는 대상 호스트 IP 주소에 연결할 때 대상 호스트의 지정된 소스 포트에 연결합니다.

포트 및 원격 주소 쌍의 예

80 172.16.12.11
100 example.com
Copy to Clipboard Toggle word wrap

포트, 원격 주소, 원격 포트
세 가지 필드 형식인 <port> <remote_address> <remote_port>를 사용하여 소스 포트, 대상 호스트, 대상 포트를 지정할 수 있습니다.

세 가지 필드 형식은 대상 포트가 소스 포트와 다를 수 있다는 점을 제외하고 두 가지 필드 버전과 동일하게 작동합니다.

포트, 원격 주소, 원격 포트의 예

8080 192.168.60.252 80
8443 web.example.com 443
Copy to Clipboard Toggle word wrap

26.12.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
      Copy to Clipboard Toggle word wrap

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

      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
      Copy to Clipboard Toggle word wrap
    2. 서비스를 생성하려면 다음 명령을 입력합니다.

      $ oc create -f egress-router-service.yaml
      Copy to Clipboard Toggle word wrap

      이제 Pod에서 이 서비스에 연결할 수 있습니다. 이러한 연결은 예약된 송신 IP 주소를 사용하여 외부 서버의 해당 포트에 프록시로 연결됩니다.

26.13. 구성 맵에서 송신 라우터 Pod 대상 목록 구성

클러스터 관리자는 송신 라우터 Pod에 대한 대상 매핑을 지정하는 ConfigMap 오브젝트를 정의할 수 있습니다. 구체적인 구성 형식은 송신 라우터 Pod 유형에 따라 다릅니다. 형식에 대한 자세한 내용은 해당 송신 라우터 Pod에 대한 설명서를 참조하십시오.

26.13.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
    Copy to Clipboard Toggle word wrap

    이 파일에 빈 줄과 주석을 넣을 수 있습니다.

  2. 파일에서 ConfigMap 오브젝트를 만듭니다.

    $ oc delete configmap egress-routes --ignore-not-found
    Copy to Clipboard Toggle word wrap
    $ oc create configmap egress-routes \
      --from-file=destination=my-egress-destination.txt
    Copy to Clipboard Toggle word wrap

    이전 명령에서 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
    Copy to Clipboard Toggle word wrap
  3. 송신 라우터 Pod 정의를 생성하고 환경 스탠자의 EGRESS_DESTINATION 필드에 configMapKeyRef 스탠자를 지정합니다.

    ...
    env:
    - name: EGRESS_DESTINATION
      valueFrom:
        configMapKeyRef:
          name: egress-routes
          key: destination
    ...
    Copy to Clipboard Toggle word wrap

26.14. 프로젝트에 멀티 캐스트 사용

26.14.1. 멀티 캐스트 정보

IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.

중요
  • 현재 멀티 캐스트는 고 대역폭 솔루션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다.
  • 기본적으로 네트워크 정책은 네임스페이스의 모든 연결에 영향을 미칩니다. 그러나 멀티캐스트는 네트워크 정책의 영향을 받지 않습니다. 네트워크 정책과 동일한 네임스페이스에서 멀티 캐스트를 활성화하면 모든 네트워크 정책이 거부 된 경우에도 항상 허용됩니다. 클러스터 관리자는 활성화하기 전에 네트워크 정책에서 멀티 캐스트에 미치는 영향을 고려해야 합니다.

OpenShift Container Platform Pod 간 멀티 캐스트 트래픽은 기본적으로 비활성화되어 있습니다. OpenShift SDN 네트워크 플러그인을 사용하는 경우 프로젝트별로 멀티 캐스트를 활성화할 수 있습니다.

networkpolicy 격리 모드에서 OpenShift SDN 네트워크 플러그인을 사용하는 경우:

  • Pod에서 전송한 멀티 캐스트 패킷은 NetworkPolicy 오브젝트에 관계없이 프로젝트의 다른 모든 Pod로 전달됩니다. Pod는 유니 캐스트를 통해 통신할 수 없는 경우에도 멀티 캐스트를 통해 통신할 수 있습니다.
  • 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 프로젝트 간에 통신을 허용하는 NetworkPolicy 오브젝트가 있더라도 다른 프로젝트의 Pod로 전달되지 않습니다.

다중 테넌트 격리 모드에서 OpenShift SDN 네트워크 플러그인을 사용하는 경우:

  • Pod에서 전송한 멀티 캐스트 패킷은 프로젝트의 다른 모든 Pod로 전달됩니다.
  • 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 각 프로젝트가 함께 결합되고 각 참여 프로젝트에서 멀티 캐스트가 활성화된 경우에만 다른 프로젝트의 Pod로 전달됩니다.

26.14.2. Pod 간 멀티 캐스트 활성화

프로젝트의 Pod 간 멀티 캐스트를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로 <namespace>를 바꿉니다.

    $ oc annotate netnamespace <namespace> \
        netnamespace.network.openshift.io/multicast-enabled=true
    Copy to Clipboard Toggle word wrap

검증

프로젝트에 멀티 캐스트가 활성화되어 있는지 확인하려면 다음 절차를 완료합니다.

  1. 멀티 캐스트를 활성화한 프로젝트로 현재 프로젝트를 변경합니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc project <project>
    Copy to Clipboard Toggle word wrap
  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/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat hostname && sleep inf"]
          ports:
            - containerPort: 30102
              name: mlistener
              protocol: UDP
    EOF
    Copy to Clipboard Toggle word wrap
  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/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat && sleep inf"]
    EOF
    Copy to Clipboard Toggle word wrap
  4. 새 터미널 창 또는 탭에서 멀티 캐스트 리스너를 시작합니다.

    1. Pod의 IP 주소를 가져옵니다.

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 입력하여 멀티 캐스트 리스너를 시작합니다.

      $ oc exec mlistener -i -t -- \
          socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname
      Copy to Clipboard Toggle word wrap
  5. 멀티 캐스트 송신기를 시작합니다.

    1. Pod 네트워크 IP 주소 범위를 가져옵니다.

      $ CIDR=$(oc get Network.config.openshift.io cluster \
          -o jsonpath='{.status.clusterNetwork[0].cidr}')
      Copy to Clipboard Toggle word wrap
    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"
      Copy to Clipboard Toggle word wrap

      멀티 캐스트가 작동하는 경우 이전 명령은 다음 출력을 반환합니다.

      mlistener
      Copy to Clipboard Toggle word wrap

26.15. 프로젝트에 대한 멀티 캐스트 비활성화

26.15.1. Pod 간 멀티 캐스트 비활성화

프로젝트의 Pod 간 멀티 캐스트를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 다음 명령을 실행하여 멀티 캐스트를 비활성화합니다.

    $ oc annotate netnamespace <namespace> \ 
    1
    
        netnamespace.network.openshift.io/multicast-enabled-
    Copy to Clipboard Toggle word wrap
    1
    멀티 캐스트를 비활성화하려는 프로젝트의 namespace입니다.

26.16. OpenShift SDN을 사용하여 네트워크 격리 구성

OpenShift SDN 네트워크 플러그인에 다중 테넌트 격리 모드를 사용하도록 클러스터를 구성하면 기본적으로 각 프로젝트가 격리됩니다. 다중 테넌트 격리 모드에서 다른 프로젝트의 pod 또는 Service 간에 네트워크 트래픽이 허용되지 않습니다.

두 가지 방법으로 프로젝트의 다중 테넌트 격리 동작을 변경할 수 있습니다.

  • 하나 이상의 프로젝트에 참여하여 다른 프로젝트의 pod와 service 간에 네트워크 트래픽을 허용할 수 있습니다.
  • 프로젝트의 네트워크 격리를 비활성화할 수 있습니다. 다른 모든 프로젝트에서 pod 및 service의 네트워크 트래픽을 수락하여 전역에서 액세스할 수 있습니다. 전역에서 액세스 가능한 프로젝트는 다른 모든 프로젝트의 pod 및 service에 액세스할 수 있습니다.

26.16.1. 사전 요구 사항

  • 다중 테넌트 격리 모드에서 OpenShift SDN 네트워크 플러그인을 사용하도록 구성된 클러스터가 있어야 합니다.

26.16.2. 프로젝트 참여

두 개 이상의 프로젝트에 참여하여 다른 프로젝트의 Pod와 Service 간 네트워크 트래픽을 허용할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음 명령을 사용하여 기존 프로젝트 네트워크에 프로젝트를 결합합니다.

    $ oc adm pod-network join-projects --to=<project1> <project2> <project3>
    Copy to Clipboard Toggle word wrap

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

  2. 선택 사항: 다음 명령을 실행하여 결합한 Pod 네트워크를 봅니다.

    $ oc get netnamespaces
    Copy to Clipboard Toggle word wrap

    동일한 Pod 네트워크에 있는 프로젝트는 NETID 열에서 동일한 네트워크 ID를 보유합니다.

26.16.3. 프로젝트 격리

다른 프로젝트의 Pod 및 Service가 해당 Pod 및 Service에 액세스할 수 없도록 프로젝트를 격리할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 클러스터에서 프로젝트를 격리하려면 다음 명령을 실행합니다.

    $ oc adm pod-network isolate-projects <project1> <project2>
    Copy to Clipboard Toggle word wrap

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

26.16.4. 프로젝트의 네트워크 격리 비활성화

프로젝트의 네트워크 격리를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 프로젝트에 대해 다음 명령을 실행합니다.

    $ oc adm pod-network make-projects-global <project1> <project2>
    Copy to Clipboard Toggle word wrap

    또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용하여 관련 레이블을 기반으로 프로젝트를 지정할 수 있습니다.

26.17. kube-proxy 설정

Kubernetes 네트워크 프록시(kube-proxy)는 각 노드에서 실행되며 CNO(Cluster Network Operator)에 의해 관리됩니다. kube-proxy는 서비스와 관련된 끝점에 대한 연결을 전달하기 위한 네트워크 규칙을 유지 관리합니다.

26.17.1. iptables 규칙 동기화 정보

동기화 기간은 Kubernetes 네트워크 프록시(kube-proxy)가 노드에서 iptables 규칙을 동기화하는 빈도를 결정합니다.

다음 이벤트 중 하나가 발생하면 동기화가 시작됩니다.

  • 서비스 또는 끝점과 같은 이벤트가 클러스터에 추가되거나 클러스터에서 제거됩니다.
  • 마지막 동기화 이후 시간이 kube-proxy에 대해 정의된 동기화 기간을 초과합니다.

26.17.2. kube-proxy 구성 매개변수

다음 kubeProxyConfig 매개변수를 수정할 수 있습니다.

참고

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

Expand
표 26.3. 매개변수
매개변수설명Default

iptablesSyncPeriod

iptables 규칙의 새로 고침 간격입니다.

30s 또는 2m과 같은 시간 간격입니다. 유효 접미사로 s, m, h가 있으며, 자세한 설명은 Go time 패키지 문서를 참조하십시오.

30s

proxyArguments.iptables-min-sync-period

iptables 규칙을 새로 고치기 전 최소 기간입니다. 이 매개변수를 이용하면 새로 고침 간격이 너무 짧지 않도록 조정할 수 있습니다. 기본적으로 새로 고침은 iptables 규칙에 영향을 주는 변경이 발생하는 즉시 시작됩니다.

30s 또는 2m과 같은 시간 간격입니다. 유효 접미사로 s, mh가 있으며, 자세한 설명은 Go time 패키지를 참조하십시오

0s

26.17.3. kube-proxy 구성 수정

클러스터의 Kubernetes 네트워크 프록시 구성을 수정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 사용하여 실행 중인 클러스터에 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 Network.operator.openshift.io CR(사용자 정의 리소스)을 편집합니다.

    $ oc edit network.operator.openshift.io cluster
    Copy to Clipboard Toggle word wrap
  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"]
    Copy to Clipboard Toggle word wrap
  3. 파일을 저장하고 텍스트 편집기를 종료합니다.

    파일을 저장하고 편집기를 종료하면 oc 명령에 의해 구문의 유효성이 검사됩니다. 수정 사항에 구문 오류가 포함되어 있으면 편집기가 파일을 열고 오류 메시지를 표시합니다.

  4. 다음 명령을 입력하여 구성 업데이트를 확인하십시오.

    $ oc get networks.operator.openshift.io -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  5. 선택 사항: Cluster Network Operator가 구성 변경을 승인했는지 확인하려면 다음 명령을 입력합니다.

    $ oc get clusteroperator network
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.1.0-0.9   True        False         False      1m
    Copy to Clipboard Toggle word wrap

    구성 업데이트가 성공적으로 적용되면 AVAILABLE 필드는 True입니다.

27장. 경로 구성

27.1. 경로 구성

27.1.1. HTTP 기반 경로 생성

경로를 사용하면 공용 URL에서 애플리케이션을 호스팅할 수 있습니다. 애플리케이션의 네트워크 보안 구성에 따라 보안 또는 비보안일 수 있습니다. HTTP 기반 경로는 기본 HTTP 라우팅 프로토콜을 사용하고 보안되지 않은 애플리케이션 포트에 서비스를 노출하는 비보안 경로입니다.

다음 절차에서는 hello-openshift 애플리케이션을 예제로 사용하여 웹 애플리케이션에 대한 간단한 HTTP 기반 경로를 생성하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 관리자로 로그인되어 있습니다.
  • 포트 및 TCP 끝점이 포트의 트래픽을 청취하는 웹 애플리케이션이 있습니다.

프로세스

  1. 다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.

    $ oc new-project hello-openshift
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 프로젝트에서 Pod를 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 hello-openshift 라는 서비스를 생성합니다.

    $ oc expose pod/hello-openshift
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 hello-openshift 애플리케이션에 대한 비보안 경로를 생성합니다.

    $ oc expose svc hello-openshift
    Copy to Clipboard Toggle word wrap

검증

  • 생성한 경로 리소스가 있는지 확인하려면 다음 명령을 실행합니다.

    $ oc get routes -o yaml <name of resource> 
    1
    Copy to Clipboard Toggle word wrap
    1
    이 예에서 경로 이름은 hello-openshift 입니다.

생성된 비보안 경로에 대한 샘플 YAML 정의:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain> 
1

  port:
    targetPort: 8080 
2

  to:
    kind: Service
    name: hello-openshift
Copy to Clipboard Toggle word wrap

1
<Ingress_Domain >은 기본 Ingress 도메인 이름입니다. ingresses.config/cluster 오브젝트는 설치 중에 생성되며 변경할 수 없습니다. 다른 도메인을 지정하려면 appsDomain 옵션을 사용하여 대체 클러스터 도메인을 지정할 수 있습니다.
2
targetPort 는 이 경로가 가리키는 서비스에서 선택한 Pod의 대상 포트입니다.
참고

기본 수신 도메인을 표시하려면 다음 명령을 실행합니다.

$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
Copy to Clipboard Toggle word wrap

27.1.2. Ingress 컨트롤러 샤딩 경로 생성

경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. 이 경우 호스트 이름이 설정되지 않고 경로에서 하위 도메인을 대신 사용합니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress 컨트롤러의 도메인을 자동으로 사용합니다. 여러 Ingress 컨트롤러에서 경로를 노출하는 경우 경로가 여러 URL에서 호스팅됩니다.

다음 절차에서는 hello-openshift 애플리케이션을 예제로 사용하여 Ingress 컨트롤러 샤딩의 경로를 생성하는 방법을 설명합니다.

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

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트 관리자로 로그인되어 있습니다.
  • 포트의 트래픽을 청취하는 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
  • 샤딩을 위해 Ingress 컨트롤러가 구성되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.

    $ oc new-project hello-openshift
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 프로젝트에서 Pod를 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 hello-openshift 라는 서비스를 생성합니다.

    $ oc expose pod/hello-openshift
    Copy to Clipboard Toggle word wrap
  4. hello-openshift-route.yaml 이라는 경로 정의를 생성합니다.

    분할을 위해 생성된 경로에 대한 YAML 정의:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded 
    1
    
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift 
    2
    
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    Copy to Clipboard Toggle word wrap

    1
    label 키와 해당 레이블 값은 Ingress 컨트롤러에 지정된 레이블 값과 일치해야 합니다. 이 예에서 Ingress 컨트롤러에는 라벨 키와 값 type: sharded 가 있습니다.
    2
    하위 도메인 필드 값을 사용하여 경로가 노출됩니다. subdomain 필드를 지정하는 경우 호스트 이름을 설정되지 않은 상태로 두어야 합니다. hostsubdomain 필드를 모두 지정하면 경로에서 호스트 필드의 값을 사용하고 subdomain 필드를 무시합니다.
  5. 다음 명령을 실행하여 hello-openshift-route.yaml 을 사용하여 hello-openshift 애플리케이션에 대한 경로를 생성합니다.

    $ oc -n hello-openshift create -f hello-openshift-route.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 사용하여 경로 상태를 가져옵니다.

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
    Copy to Clipboard Toggle word wrap

    결과 경로 리소스는 다음과 유사합니다.

    출력 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    status:
      ingress:
      - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    1
    
        routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    2
    
        routerName: sharded 
    3
    Copy to Clipboard Toggle word wrap

    1
    Ingress 컨트롤러 또는 라우터에서 사용하는 호스트 이름에서 경로를 노출합니다. 호스트 필드의 값은 Ingress 컨트롤러에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress 컨트롤러의 도메인은 < apps-sharded.basedomain.example.net>입니다.
    2
    Ingress 컨트롤러의 호스트 이름입니다.
    3
    Ingress 컨트롤러의 이름입니다. 이 예에서 Ingress 컨트롤러의 이름은 sharded 입니다.

27.1.3. 경로 시간 초과 구성

SLA(Service Level Availability) 목적에 필요한 낮은 시간 초과 또는 백엔드가 느린 경우 높은 시간 초과가 필요한 서비스가 있는 경우 기존 경로에 대한 기본 시간 초과를 구성할 수 있습니다.

사전 요구 사항

  • 실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

프로세스

  1. oc annotate 명령을 사용하여 경로에 시간 초과를 추가합니다.

    $ oc annotate route <route_name> \
        --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 
    1
    Copy to Clipboard Toggle word wrap
    1
    지원되는 시간 단위는 마이크로초(us), 밀리초(ms), 초(s), 분(m), 시간(h) 또는 일(d)입니다.

    다음 예제는 이름이 myroute인 경로에서 2초의 시간 초과를 설정합니다.

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
    Copy to Clipboard Toggle word wrap

27.1.4. HSTS(HTTP Strict Transport Security)

HSTS(HTTP Strict Transport Security) 정책은 라우트 호스트에서 HTTPS 트래픽만 허용됨을 브라우저 클라이언트에 알리는 보안 강화 정책입니다. 또한 HSTS는 HTTP 리디렉션을 사용하지 않고 HTTPS 전송 신호를 통해 웹 트래픽을 최적화합니다. HSTS는 웹사이트와의 상호 작용을 가속화하는 데 유용합니다.

HSTS 정책이 적용되면 HSTS는 사이트의 HTTP 및 HTTPS 응답에 Strict Transport Security 헤더를 추가합니다. 경로에서 insecureEdgeTerminationPolicy 값을 사용하여 HTTP를 HTTPS로 리디렉션할 수 있습니다. HSTS를 적용하면 클라이언트는 요청을 전송하기 전에 HTTP URL의 모든 요청을 HTTPS로 변경하여 리디렉션이 필요하지 않습니다.

클러스터 관리자는 다음을 수행하도록 HSTS를 구성할 수 있습니다.

  • 경로당 HSTS 활성화
  • 라우팅당 HSTS 비활성화
  • 도메인당 HSTS 시행, 도메인 집합 또는 도메인과 함께 네임스페이스 라벨 사용
중요

HSTS는 보안 경로(엣지 종료 또는 재암호화)에서만 작동합니다. HTTP 또는 패스스루(passthrough) 경로에서는 구성이 유효하지 않습니다.

27.1.4.1. 라우팅당 HSTS(HTTP Strict Transport Security) 활성화

HSTS(HTTP Strict Transport Security)는 HAProxy 템플릿에 구현되고 haproxy.router.openshift.io/hsts_header 주석이 있는 에지 및 재암호화 경로에 적용됩니다.

사전 요구 사항

  • 프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • oc CLI를 설치했습니다.

프로세스

  • 경로에서 HSTS를 활성화하려면 haproxy.router.openshift.io/hsts_header 값을 에지 종료 또는 재암호화 경로에 추가합니다. oc annotate tool을 사용하여 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ 
    1
    
    includeSubDomains;preload"
    Copy to Clipboard Toggle word wrap
    1
    이 예에서 최대 나이는 31536000 ms로 설정되며 이는 약 8시간 반입니다.
    참고

    이 예에서 등호(=)는 따옴표로 되어 있습니다. 이 명령은 annotate 명령을 올바르게 실행하는 데 필요합니다.

    주석으로 구성된 경로 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 
    1
     
    2
     
    3
    
    ...
    spec:
      host: def.abc.com
      tls:
        termination: "reencrypt"
        ...
      wildcardPolicy: "Subdomain"
    Copy to Clipboard Toggle word wrap

    1
    필수 항목입니다. Max-age는 HSTS 정책이 적용되는 시간(초)을 측정합니다. 0으로 설정하면 정책이 무효화됩니다.
    2
    선택 사항: 포함되는 경우 includeSubDomains는 호스트의 모든 하위 도메인에 호스트와 동일한 HSTS 정책이 있어야 함을 알려줍니다.
    3
    선택 사항: max-age가 0보다 크면 haproxy.router.openshift.io/hsts_headerpreload를 추가하여 외부 서비스에서 이 사이트를 HSTS 사전 로드 목록에 포함할 수 있습니다. 예를 들어 Google과 같은 사이트는 preload가 설정된 사이트 목록을 구성할 수 있습니다. 그런 다음 브라우저는 이 목록을 사용하여 사이트와 상호 작용하기 전에 HTTPS를 통해 통신할 수 있는 사이트를 결정할 수 있습니다. preload를 설정하지 않으면 브라우저가 HTTPS를 통해 사이트와 상호 작용하여 헤더를 가져와야 합니다.
27.1.4.2. 라우팅당 HSTS(HTTP Strict Transport Security) 비활성화

경로당 HSTS(HTTP Strict Transport Security)를 비활성화하려면 경로 주석에서 max-age 값을 0으로 설정할 수 있습니다.

사전 요구 사항

  • 프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • oc CLI를 설치했습니다.

프로세스

  • HSTS를 비활성화하려면 다음 명령을 입력하여 경로 주석의 max-age 값을 0으로 설정합니다.

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
    Copy to Clipboard Toggle word wrap
    작은 정보

    다음 YAML을 적용하여 구성 맵을 만들 수 있습니다.

    경로당 HSTS 비활성화 예

    metadata:
      annotations:
        haproxy.router.openshift.io/hsts_header: max-age=0
    Copy to Clipboard Toggle word wrap

  • 네임스페이스의 모든 경로에 대해 HSTS를 비활성화하려면 다음 명령을 입력합니다.

    $ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 경로에 대한 주석을 쿼리하려면 다음 명령을 입력합니다.

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    Name: routename HSTS: max-age=0
    Copy to Clipboard Toggle word wrap

27.1.4.3. 도메인별 HSTS(HTTP Strict Transport Security) 적용

도메인당 HSTS(HTTP Strict Transport Security)를 적용하여 보안 경로에 requiredHSTSPolicies 레코드를 Ingress 사양에 추가하여 HSTS 정책 구성을 캡처합니다.

HSTS를 적용하도록 requiredHSTSPolicy를 구성하는 경우 규정 준수 HSTS 정책 주석을 사용하여 새로 생성된 경로를 구성해야 합니다.

참고

준수하지 않는 HSTS 경로를 사용하여 업그레이드된 클러스터를 처리하려면 소스에서 매니페스트를 업데이트하고 업데이트를 적용할 수 있습니다.

참고

oc expose route 또는 oc create route 명령을 사용하여 이러한 명령의 API에서 주석을 수락하지 않기 때문에 HSTS를 적용하는 도메인에 경로를 추가할 수 없습니다.

중요

HSTS는 전 세계의 모든 경로에 HSTS가 요청된 경우에도 비보안 또는 비TLS 경로에 적용할 수 없습니다.

사전 요구 사항

  • 프로젝트에 대한 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • oc CLI를 설치했습니다.

프로세스

  1. Ingress 구성 파일을 편집합니다.

    $ oc edit ingresses.config.openshift.io/cluster
    Copy to Clipboard Toggle word wrap

    HSTS 정책 예

    apiVersion: config.openshift.io/v1
    kind: Ingress
    metadata:
      name: cluster
    spec:
      domain: 'hello-openshift-default.apps.username.devcluster.openshift.com'
      requiredHSTSPolicies: 
    1
    
      - domainPatterns: 
    2
    
        - '*hello-openshift-default.apps.username.devcluster.openshift.com'
        - '*hello-openshift-default2.apps.username.devcluster.openshift.com'
        namespaceSelector: 
    3
    
          matchLabels:
            myPolicy: strict
        maxAge: 
    4
    
          smallestMaxAge: 1
          largestMaxAge: 31536000
        preloadPolicy: RequirePreload 
    5
    
        includeSubDomainsPolicy: RequireIncludeSubDomains 
    6
    
      - domainPatterns: 
    7
    
        - 'abc.example.com'
        - '*xyz.example.com'
        namespaceSelector:
          matchLabels: {}
        maxAge: {}
        preloadPolicy: NoOpinion
        includeSubDomainsPolicy: RequireNoIncludeSubDomains
    Copy to Clipboard Toggle word wrap

    1
    필수 항목입니다. requiredHSTSPolicies는 순서대로 검증되고 일치하는 첫 번째 domainPatterns가 적용됩니다.
    2 7
    필수 항목입니다. 하나 이상의 domainPatterns 호스트 이름을 지정해야 합니다. 도메인 수를 나열할 수 있습니다. 다른 domainPatterns에 대한 적용 옵션의 여러 섹션을 포함할 수 있습니다.
    3
    선택 사항: namespaceSelector를 포함하는 경우 경로가 있는 프로젝트의 레이블과 일치하여 경로에 설정된 HSTS 정책을 적용해야 합니다. namespaceSelector만 일치하고 domainPatterns와 일치하지 않는 경로는 검증되지 않습니다.
    4
    필수 항목입니다. Max-age는 HSTS 정책이 적용되는 시간(초)을 측정합니다. 이 정책 설정을 사용하면 최소 및 최대 max-age를 적용할 수 있습니다.
    • largestMaxAge 값은 0에서 2147483647 사이여야 합니다. 지정되지 않은 상태로 둘 수 있습니다. 즉, 상한이 적용되지 않습니다.
    • smallestMaxAge 값은 0에서 2147483647 사이여야 합니다. 문제 해결을 위해 HSTS를 비활성화하려면 0을 입력합니다. HSTS를 비활성화하지 않으려면 1을 입력합니다. 지정되지 않은 상태로 둘 수 있습니다. 즉, 더 낮은 제한이 적용되지 않습니다.
    5
    선택 사항: haproxy.router.openshift.io/hsts_headerpreload를 포함하면 외부 서비스에서 이 사이트를 HSTS 사전 로드 목록에 포함할 수 있습니다. 그런 다음 브라우저는 이 목록을 사용하여 사이트와 상호 작용하기 전에 HTTPS를 통해 통신할 수 있는 사이트를 결정할 수 있습니다. preload를 설정하지 않으면 브라우저가 헤더를 얻기 위해 사이트와 한 번 이상 상호 작용해야 합니다. 다음 중 하나로 preload를 설정할 수 있습니다.
    • RequirePreload: RequiredHSTSPolicypreload가 필요합니다.
    • RequireNoPreload: RequiredHSTSPolicy에서 preload를 금지합니다.
    • NoOpinion:preloadRequiredHSTSPolicy에 중요하지 않습니다.
    6
    선택 사항: includeSubDomainsPolicy는 다음 중 하나를 사용하여 설정할 수 있습니다.
    • RequireIncludeSubDomains:includeSubDomainsRequiredHSTSPolicy에 필요합니다.
    • RequireNoIncludeSubDomains:includeSubDomainsRequiredHSTSPolicy에서 금지합니다.
    • NoOpinion:includeSubDomainsRequiredHSTSPolicy와 관련이 없습니다.
  2. oc annotate command를 입력하여 클러스터 또는 특정 네임스페이스에 HSTS를 적용할 수 있습니다.

    • 클러스터의 모든 경로에 HSTS를 적용하려면 oc annotate command를 입력합니다. 예를 들면 다음과 같습니다.

      $ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
      Copy to Clipboard Toggle word wrap
    • 특정 네임스페이스의 모든 경로에 HSTS를 적용하려면 oc annotate command를 입력합니다. 예를 들면 다음과 같습니다.

      $ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
      Copy to Clipboard Toggle word wrap

검증

구성한 HSTS 정책을 검토할 수 있습니다. 예를 들면 다음과 같습니다.

  • 필요한 HSTS 정책에 대한 maxAge 세트를 검토하려면 다음 명령을 입력합니다.

    $ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap
  • 모든 경로에서 HSTS 주석을 검토하려면 다음 명령을 입력합니다.

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
    Copy to Clipboard Toggle word wrap

27.1.5. 처리량 문제 해결 방법

OpenShift Container Platform을 사용하여 애플리케이션을 배포하면 특정 서비스 간에 대기 시간이 비정상적으로 길어지는 등 네트워크 처리량 문제가 발생할 수 있습니다.

Pod 로그에 문제의 원인이 드러나지 않으면 다음 방법을 사용하여 성능 문제를 분석하십시오.

  • ping 또는 tcpdump 와 같은 패킷 Analyzer를 사용하여 Pod와 해당 노드 간의 트래픽을 분석합니다.

    예를 들어 각 Pod에서 tcpdump 도구를 실행하여 문제의 원인이 되는 동작을 재현합니다. Pod에서 나가거나 Pod로 들어오는 트래픽의 대기 시간을 분석하기 위해 전송 및 수신 타임 스탬프를 비교하려면 전송 캡처와 수신 캡처를 둘 다 검토하십시오. 다른 Pod, 스토리지 장치 또는 데이터 플레인의 트래픽으로 노드 인터페이스가 과부하된 경우 OpenShift Container Platform에서 대기 시간이 발생할 수 있습니다.

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 
    1
    Copy to Clipboard Toggle word wrap
    1
    podip은 Pod의 IP 주소입니다. oc get pod <pod_name> -o wide 명령을 실행하여 Pod의 IP 주소를 가져옵니다.

    tcpdump 명령은 두 Pod 간 모든 트래픽을 포함하는 /tmp/dump.pcap 에 파일을 생성합니다. 문제가 재현되기 직전에 Analyzer를 실행하고 문제 재현이 완료된 직후 Analyzer를 중지하여 파일 크기를 최소화할 수 있습니다. 다음을 사용하여 노드 간에 패킷 Analyzer를 실행할 수도 있습니다(방정식에서 SDN 제거).

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
    Copy to Clipboard Toggle word wrap
  • 스트리밍 처리량 및 UDP 처리량을 측정하려면 iperf 와 같은 대역폭 측정 툴을 사용합니다. 먼저 Pod에서 툴을 실행한 다음 노드에서 실행하여 병목 현상이 발생합니다.

  • 경우에 따라 클러스터에서 대기 시간 문제로 인해 라우터 pod로 노드를 비정상으로 표시할 수 있습니다. 작업자 대기 시간 프로필을 사용하여 조치를 수행하기 전에 클러스터가 노드에서 상태 업데이트를 대기하는 빈도를 조정합니다.
  • 클러스터에 대기 시간이 짧고 대기 시간이 많은 노드가 지정된 경우 Ingress 컨트롤러에서 spec.nodePlacement 필드를 구성하여 라우터 Pod 배치를 제어합니다.

27.1.6. 쿠키를 사용하여 경로 상태 유지

OpenShift Container Platform은 모든 트래픽이 동일한 끝점에 도달하도록 하여 스테이트풀(stateful) 애플리케이션 트래픽을 사용할 수 있는 고정 세션을 제공합니다. 그러나 재시작, 스케일링 또는 구성 변경 등으로 인해 끝점 pod가 종료되면 이러한 상태 저장 특성이 사라질 수 있습니다.

OpenShift Container Platform에서는 쿠키를 사용하여 세션 지속성을 구성할 수 있습니다. Ingress 컨트롤러에서는 사용자 요청을 처리할 끝점을 선택하고 세션에 대한 쿠키를 생성합니다. 쿠키는 요청에 대한 응답으로 다시 전달되고 사용자는 세션의 다음 요청과 함께 쿠키를 다시 보냅니다. 쿠키는 세션을 처리하는 끝점을 Ingress 컨트롤러에 알려 클라이언트 요청이 쿠키를 사용하여 동일한 Pod로 라우팅되도록 합니다.

참고

HTTP 트래픽을 표시할 수 없기 때문에 쿠키는 패스스루 경로에 설정할 수 없습니다. 대신 백엔드를 결정하는 소스 IP 주소를 기반으로 숫자를 계산합니다.

백엔드가 변경되면 트래픽이 잘못된 서버로 전송되어 고정이 줄어들 수 있습니다. 소스 IP를 숨기는 로드 밸런서를 사용하는 경우 모든 연결에 대해 동일한 번호가 설정되고 트래픽이 동일한 Pod로 전송됩니다.

27.1.7. 경로 기반 라우터

경로 기반 라우터는 URL과 비교할 수 있는 경로 구성 요소를 지정하며 이를 위해 라우트의 트래픽이 HTTP 기반이어야 합니다. 따라서 동일한 호스트 이름을 사용하여 여러 경로를 제공할 수 있으며 각각 다른 경로가 있습니다. 라우터는 가장 구체적인 경로를 기반으로 하는 라우터와 일치해야 합니다.

다음 표에서는 경로 및 액세스 가능성을 보여줍니다.

Expand
표 27.1. 경로 가용성
경로비교 대상액세스 가능

www.example.com/test

www.example.com/test

제공됨

www.example.com

없음

www.example.com/testwww.example.com

www.example.com/test

제공됨

www.example.com

제공됨

www.example.com

www.example.com/text

예 (경로가 아닌 호스트에 의해 결정됨)

www.example.com

제공됨

경로가 있는 보안되지 않은 라우터

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" 
1

  to:
    kind: Service
    name: service-name
Copy to Clipboard Toggle word wrap

1
경로는 경로 기반 라우터에 대해 추가된 유일한 속성입니다.
참고

라우터가 해당 경우 TLS를 종료하지 않고 요청 콘텐츠를 읽을 수 없기 때문에 패스스루 TLS를 사용할 때 경로 기반 라우팅을 사용할 수 없습니다.

27.1.8. 경로별 주석

Ingress 컨트롤러는 노출하는 모든 경로에 기본 옵션을 설정할 수 있습니다. 개별 경로는 주석에 특정 구성을 제공하는 방식으로 이러한 기본값 중 일부를 덮어쓸 수 있습니다. Red Hat은 operator 관리 경로에 경로 주석 추가를 지원하지 않습니다.

중요

여러 소스 IP 또는 서브넷이 있는 화이트리스트를 생성하려면 공백으로 구분된 목록을 사용합니다. 다른 구분 기호 유형으로 인해 경고 또는 오류 메시지 없이 목록이 무시됩니다.

Expand
표 27.2. 경로 주석
Variable설명기본값으로 사용되는 환경 변수

haproxy.router.openshift.io/balance

로드 밸런싱 알고리즘을 설정합니다. 사용 가능한 옵션은 random, source, roundrobin, leastconn입니다. 기본값은 TLS 패스스루 경로의 source 입니다. 다른 모든 경로의 경우 기본값은 random 입니다.

경유 경로의 경우 ROUTER_TCP_BALANCE_SCHEME입니다. 그 외에는 ROUTER_LOAD_BALANCE_ALGORITHM을 사용하십시오.

haproxy.router.openshift.io/disable_cookies

쿠키를 사용하여 관련 연결을 추적하지 않도록 설정합니다. 'true' 또는 'TRUE' 로 설정하면 들어오는 각 HTTP 요청에 대한 백엔드 연결을 제공하는 백엔드를 선택하는 데 밸런스 알고리즘이 사용됩니다.

 

router.openshift.io/cookie_name

이 경로에 사용할 선택적 쿠키를 지정합니다. 이름은 대문자와 소문자, 숫자, ‘_’, ‘-’의 조합으로 구성해야 합니다. 기본값은 경로의 해시된 내부 키 이름입니다.

 

haproxy.router.openshift.io/pod-concurrent-connections

라우터에서 백업 pod로 허용되는 최대 연결 수를 설정합니다.
참고: Pod가 여러 개인 경우 각각 이 수만큼의 연결이 있을 수 있습니다. 라우터가 여러 개 있고 조정이 이루어지지 않는 경우에는 각각 이 횟수만큼 연결할 수 있습니다. 설정하지 않거나 0으로 설정하면 제한이 없습니다.

 

haproxy.router.openshift.io/rate-limit-connections

'true' 또는 'TRUE' 를 설정하면 경로당 특정 백엔드의 고정 테이블을 통해 구현되는 속도 제한 기능이 활성화됩니다.
참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본 보호 기능이 제공됩니다.

 

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

동일한 소스 IP 주소를 통해 만든 동시 TCP 연결 수를 제한합니다. 숫자 값을 허용합니다.
참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본 보호 기능이 제공됩니다.

 

haproxy.router.openshift.io/rate-limit-connections.rate-http

동일한 소스 IP 주소가 있는 클라이언트에서 HTTP 요청을 수행할 수 있는 속도를 제한합니다. 숫자 값을 허용합니다.
참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본 보호 기능이 제공됩니다.

 

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

동일한 소스 IP 주소가 있는 클라이언트에서 TCP 연결을 수행할 수 있는 속도를 제한합니다. 숫자 값을 허용합니다.
참고: 이 주석을 사용하면 서비스 거부 공격에 대한 기본 보호 기능이 제공됩니다.

 

haproxy.router.openshift.io/timeout

경로에 대한 서버 쪽 타임아웃을 설정합니다. (TimeUnits)

ROUTER_DEFAULT_SERVER_TIMEOUT

haproxy.router.openshift.io/timeout-tunnel

이 제한 시간은 터널 연결(예: 일반 텍스트, 에지, 재암호화 또는 패스스루 라우팅)에 적용됩니다. 일반 텍스트, 에지 또는 재암호화 경로 유형을 사용하면 이 주석이 기존 시간 초과 값이 있는 시간 제한 터널로 적용됩니다. passthrough 경로 유형의 경우 주석은 설정된 기존 시간 초과 값보다 우선합니다.

ROUTER_DEFAULT_TUNNEL_TIMEOUT

ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after

IngressController 또는 Ingress 구성을 설정할 수 있습니다. 이 주석은 라우터를 재배포하고, 정리 소프트 중지를 수행하는 데 허용되는 최대 시간을 정의하는 haproxy 하드 중지 후 글로벌 옵션을 내보내도록 HA 프록시를 구성합니다.

ROUTER_HARD_STOP_AFTER

router.openshift.io/haproxy.health.check.interval

백엔드 상태 점검 간격을 설정합니다. (TimeUnits)

ROUTER_BACKEND_CHECK_INTERVAL

haproxy.router.openshift.io/ip_whitelist

경로에 대한 허용 목록을 설정합니다. 허용 목록은 승인된 소스 주소에 대한 IP 주소 및 CIDR 범위로 이루어진 공백으로 구분된 목록입니다. 허용 목록에 없는 IP 주소의 요청은 삭제됩니다.

haproxy.config 파일에 직접 표시되는 최대 IP 주소 및 CIDR 범위는 61입니다. [1]

 

haproxy.router.openshift.io/hsts_header

엣지 종단 경로 또는 재암호화 경로에 Strict-Transport-Security 헤더를 설정합니다.

 

haproxy.router.openshift.io/rewrite-target

백엔드의 요청 재작성 경로를 설정합니다.

 

router.openshift.io/cookie-same-site

쿠키를 제한하는 값을 설정합니다. 값은 다음과 같습니다.

LAX: 브라우저는 사이트 간 요청에 쿠키를 보내지 않지만 사용자가 외부 사이트에서 원본 사이트로 이동할 때 쿠키를 보냅니다. 이는 SameSite 값이 지정되지 않은 경우 기본 브라우저 동작입니다.

Strict: 브라우저가 동일한 사이트 요청에 대해서만 쿠키를 보냅니다.

none: 브라우저가 교차 사이트 요청과 동일한 사이트 요청에 대해 쿠키를 보냅니다.

이 값은 재암호화 및 엣지 경로에만 적용됩니다. 자세한 내용은 SameSite 쿠키 설명서를 참조하십시오.

 

haproxy.router.openshift.io/set-forwarded-headers

라우터당 ForwardedX-Forwarded-For HTTP 헤더를 처리하기 위한 정책을 설정합니다. 값은 다음과 같습니다.

append: 기존 헤더를 유지하면서 헤더를 추가합니다. 이는 기본값입니다.

replace: 헤더를 설정하고 기존 헤더를 제거합니다.

never: 헤더를 설정하지 않고 기존 헤더를 유지합니다.

if-none: 아직 설정되지 않은 경우 헤더를 설정합니다.

ROUTER_SET_FORWARDED_HEADERS

  1. 허용 목록의 IP 주소 및 CIDR 범위가 61를 초과하면 haproxy.config 에서 참조되는 별도의 파일에 작성됩니다. 이 파일은 var/lib/haproxy/router/whitelists 폴더에 저장됩니다.

    참고

    주소가 허용 목록에 작성되도록 하려면 전체 CIDR 범위가 Ingress 컨트롤러 구성 파일에 나열되어 있는지 확인합니다. etcd 오브젝트 크기 제한은 경로 주석의 크기를 제한합니다. 이로 인해 허용 목록에 포함할 수 있는 최대 IP 주소 및 CIDR 범위에 대한 임계값이 생성됩니다.

참고

환경 변수는 편집할 수 없습니다.

라우터 시간 제한 변수

TimeUnits는 다음과 같이 표시됩니다. us *(마이크로초), ms (밀리초, 기본값), s (초), m (분), h *(시간), d (일).

정규 표현식은 [1-9][0-9]*(us\|ms\|s\|m\|h\|d)입니다.

Expand
VariableDefault설명

ROUTER_BACKEND_CHECK_INTERVAL

5000ms

백엔드에서 후속 활성 검사 사이의 시간입니다.

ROUTER_CLIENT_FIN_TIMEOUT

1s

경로에 연결된 클라이언트의 TCP FIN 시간 제한 기간을 제어합니다. FIN이 연결을 닫도록 전송한 경우 지정된 시간 내에 응답하지 않으면 HAProxy가 연결을 종료합니다. 낮은 값으로 설정하면 문제가 없으며 라우터에서 더 적은 리소스를 사용합니다.

ROUTER_DEFAULT_CLIENT_TIMEOUT

30s

클라이언트가 데이터를 승인하거나 보내야 하는 시간입니다.

ROUTER_DEFAULT_CONNECT_TIMEOUT

5s

최대 연결 시간입니다.

ROUTER_DEFAULT_SERVER_FIN_TIMEOUT

1s

라우터에서 경로를 지원하는 pod로의 TCP FIN 시간 초과를 제어합니다.

ROUTER_DEFAULT_SERVER_TIMEOUT

30s

서버에서 데이터를 승인하거나 보내야 하는 시간입니다.

ROUTER_DEFAULT_TUNNEL_TIMEOUT

1h

TCP 또는 WebSocket 연결이 열린 상태로 유지되는 동안의 시간입니다. 이 시간 제한 기간은 HAProxy를 다시 로드할 때마다 재설정됩니다.

ROUTER_SLOWLORIS_HTTP_KEEPALIVE

300s

새 HTTP 요청이 표시될 때까지 대기할 최대 시간을 설정합니다. 이 값을 너무 낮게 설정하면 작은 keepalive 값을 예상하지 못하는 브라우저 및 애플리케이션에 문제가 발생할 수 있습니다.

일부 유효한 시간 제한 값은 예상되는 특정 시간 초과가 아니라 특정 변수의 합계일 수 있습니다. 예를 들어 ROUTER_SLOWLORIS_HTTP_KEEPALIVEtimeout http-keep-alive를 조정합니다. 기본적으로 300s로 설정되지만 HAProxy는 5s로 설정된 tcp-request inspect-delay도 대기합니다. 이 경우 전체 시간 초과는 300s + 5s입니다.

ROUTER_SLOWLORIS_TIMEOUT

10s

HTTP 요청 전송에 걸리는 시간입니다.

RELOAD_INTERVAL

5s

라우터의 최소 빈도가 새 변경 사항을 다시 로드하고 승인하도록 허용합니다.

ROUTER_METRICS_HAPROXY_TIMEOUT

5s

HAProxy 메트릭 수집에 대한 시간 제한입니다.

경로 설정 사용자 정의 타임아웃

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 
1

...
Copy to Clipboard Toggle word wrap

1
HAProxy 지원 단위(us, ms, s, m, h, d)를 사용하여 새 타임아웃을 지정합니다. 단위가 제공되지 않는 경우 ms가 기본값입니다.
참고

패스스루(passthrough) 경로에 대한 서버 쪽 타임아웃 값을 너무 낮게 설정하면 해당 경로에서 WebSocket 연결이 자주 시간 초과될 수 있습니다.

하나의 특정 IP 주소만 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
Copy to Clipboard Toggle word wrap

여러 IP 주소를 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
Copy to Clipboard Toggle word wrap

IP 주소 CIDR 네트워크를 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
Copy to Clipboard Toggle word wrap

IP 주소 및 IP 주소 CIDR 네트워크를 둘 다 허용하는 경로

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
Copy to Clipboard Toggle word wrap

재작성 대상을 지정하는 경로

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 
1

...
Copy to Clipboard Toggle word wrap

1
/를 백엔드의 요청 재작성 경로로 설정합니다.

경로에 haproxy.router.openshift.io/rewrite-target 주석을 설정하면 Ingress Controller에서 요청을 백엔드 애플리케이션으로 전달하기 전에 이 경로를 사용하여 HTTP 요청의 경로를 재작성해야 합니다. spec.path에 지정된 경로와 일치하는 요청 경로 부분은 주석에 지정된 재작성 대상으로 교체됩니다.

다음 표에 spec.path, 요청 경로, 재작성 대상의 다양한 조합에 따른 경로 재작성 동작의 예가 있습니다.

Expand
표 27.3. 재작성 대상의 예:
Route.spec.path요청 경로재작성 대상전달된 요청 경로

/foo

/foo

/

/

/foo

/foo/

/

/

/foo

/foo/bar

/

/bar

/foo

/foo/bar/

/

/bar/

/foo

/foo

/bar

/bar

/foo

/foo/

/bar

/bar/

/foo

/foo/bar

/baz

/baz/bar

/foo

/foo/bar/

/baz

/baz/bar/

/foo/

/foo

/

N/A(요청 경로가 라우팅 경로와 일치하지 않음)

/foo/

/foo/

/

/

/foo/

/foo/bar

/

/bar

27.1.9. 경로 허용 정책 구성

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

주의

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

사전 요구 사항

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

절차

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

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    샘플 Ingress 컨트롤러 구성

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...
    Copy to Clipboard Toggle word wrap

    작은 정보

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    Copy to Clipboard Toggle word wrap

27.1.10. Ingress 오브젝트를 통해 경로 생성

일부 에코시스템 구성 요소는 Ingress 리소스와 통합되지만 경로 리소스와는 통합되지 않습니다. 이러한 경우를 처리하기 위해 OpenShift Container Platform에서는 Ingress 오브젝트가 생성될 때 관리형 경로 오브젝트를 자동으로 생성합니다. 이러한 경로 오브젝트는 해당 Ingress 오브젝트가 삭제될 때 삭제됩니다.

절차

  1. OpenShift Container Platform 콘솔에서 또는 oc create 명령을 입력하여 Ingress 오브젝트를 정의합니다.

    Ingress의 YAML 정의

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      annotations:
        route.openshift.io/termination: "reencrypt" 
    1
    
        route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
    2
    
    spec:
      rules:
      - host: www.example.com 
    3
    
        http:
          paths:
          - backend:
              service:
                name: frontend
                port:
                  number: 443
            path: /
            pathType: Prefix
      tls:
      - hosts:
        - www.example.com
        secretName: example-com-tls-certificate
    Copy to Clipboard Toggle word wrap

    1
    Ingress에는 Route에 대한 필드가 없으므로 route.openshift.io/termination 주석을 사용하여 spec.tls.termination 필드를 구성할 수 있습니다. 허용되는 값은 edge, passthrough, reencrypt입니다. 다른 모든 값은 자동으로 무시됩니다. 주석 값이 설정되지 않으면 edge 가 기본 경로입니다. 기본 엣지 경로를 구현하려면 TLS 인증서 세부 정보를 템플릿 파일에 정의해야 합니다.
    3
    Ingress 오브젝트로 작업할 때는 경로를 사용할 때와 달리 명시적 호스트 이름을 지정해야 합니다. < host_name>.<cluster_ingress_domain > 구문(예: apps.openshiftdemos.com )을 사용하여 *.<cluster_ingress_domain > 와일드카드 DNS 레코드 및 클러스터에 대한 인증서를 제공할 수 있습니다. 그렇지 않으면 선택한 호스트 이름에 대한 DNS 레코드가 있는지 확인해야 합니다.
    1. route.openshift.io/termination 주석에 passthrough 값을 지정하는 경우 path''로 설정하고 spec에서 pathTypeImplementationSpecific으로 설정합니다.

        spec:
          rules:
          - host: www.example.com
            http:
              paths:
              - path: ''
                pathType: ImplementationSpecific
                backend:
                  service:
                    name: frontend
                    port:
                      number: 443
      Copy to Clipboard Toggle word wrap
      $ oc apply -f ingress.yaml
      Copy to Clipboard Toggle word wrap
    2
    Ingress 오브젝트에서 route.openshift.io/destination-ca-certificate-secret 을 사용하여 사용자 정의 대상 인증서(CA)로 경로를 정의할 수 있습니다. 이 주석은 생성된 경로에 삽입될 kubernetes 시크릿 secret secret-ca-cert 를 참조합니다.
    1. Ingress 오브젝트에서 대상 CA를 사용하여 경로 오브젝트를 지정하려면 시크릿의 data.tls.crt 지정자에 PEM 인코딩 형식으로 인증서를 사용하여 kubernetes.io/tls 또는 Opaque 유형 시크릿을 생성해야 합니다.
  2. 노드를 나열합니다.

    $ oc get routes
    Copy to Clipboard Toggle word wrap

    결과에는 이름이 frontend-로 시작하는 자동 생성 경로가 포함됩니다.

    NAME             HOST/PORT         PATH    SERVICES    PORT    TERMINATION          WILDCARD
    frontend-gnztq   www.example.com           frontend    443     reencrypt/Redirect   None
    Copy to Clipboard Toggle word wrap

    이 경로를 살펴보면 다음과 같습니다.

    자동 생성 경로의 YAML 정의

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend-gnztq
      ownerReferences:
      - apiVersion: networking.k8s.io/v1
        controller: true
        kind: Ingress
        name: frontend
        uid: 4e6c59cc-704d-4f44-b390-617d879033b6
    spec:
      host: www.example.com
      path: /
      port:
        targetPort: https
      tls:
        certificate: |
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        insecureEdgeTerminationPolicy: Redirect
        key: |
          -----BEGIN RSA PRIVATE KEY-----
          [...]
          -----END RSA PRIVATE KEY-----
        termination: reencrypt
        destinationCACertificate: |
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
      to:
        kind: Service
        name: frontend
    Copy to Clipboard Toggle word wrap

27.1.11. Ingress 오브젝트를 통해 기본 인증서를 사용하여 경로 생성

TLS 구성을 지정하지 않고 Ingress 오브젝트를 생성하면 OpenShift Container Platform에서 비보안 경로를 생성합니다. 기본 수신 인증서를 사용하여 보안 엣지 종료 경로를 생성하는 Ingress 오브젝트를 생성하려면 다음과 같이 빈 TLS 구성을 지정할 수 있습니다.

사전 요구 사항

  • 노출하려는 서비스가 있습니다.
  • OpenShift CLI(oc)에 액세스할 수 있습니다.

절차

  1. Ingress 오브젝트에 대한 YAML 파일을 생성합니다. 이 예제에서는 파일을 example-ingress.yaml 이라고 합니다.

    Ingress 오브젝트의 YAML 정의

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      ...
    spec:
      rules:
        ...
      tls:
      - {} 
    1
    Copy to Clipboard Toggle word wrap

    1
    이 정확한 구문을 사용하여 사용자 정의 인증서를 지정하지 않고 TLS를 지정합니다.
  2. 다음 명령을 실행하여 Ingress 오브젝트를 생성합니다.

    $ oc create -f example-ingress.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 OpenShift Container Platform에서 Ingress 오브젝트에 대한 예상 경로를 생성했는지 확인합니다.

    $ oc get routes -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    items:
    - apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: frontend-j9sdd 
    1
    
        ...
      spec:
      ...
        tls: 
    2
    
          insecureEdgeTerminationPolicy: Redirect
          termination: edge 
    3
    
      ...
    Copy to Clipboard Toggle word wrap

    1
    경로 이름에는 Ingress 오브젝트의 이름 뒤에 임의의 접미사가 포함됩니다.
    2
    기본 인증서를 사용하려면 경로에서 spec.certificate 를 지정하지 않아야 합니다.
    3
    경로는 엣지 종료 정책을 지정해야 합니다.

27.1.12. Ingress 주석에서 대상 CA 인증서를 사용하여 경로 생성

Ingress 오브젝트에 route.openshift.io/destination-ca-certificate-secret 주석을 사용하여 사용자 정의 대상 CA 인증서로 경로를 정의할 수 있습니다.

사전 요구 사항

  • PEM 인코딩 파일에 인증서/키 쌍이 있을 수 있습니다. 여기서 인증서가 경로 호스트에 유효합니다.
  • 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
  • PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
  • 노출하려는 서비스가 있어야 합니다.

절차

  1. Ingress 주석에 route.openshift.io/destination-ca-certificate-secret 을 추가합니다.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      annotations:
        route.openshift.io/termination: "reencrypt"
        route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
    1
    
    ...
    Copy to Clipboard Toggle word wrap
    1
    주석은 kubernetes 보안을 참조합니다.
  2. 이 주석에서 참조하는 보안이 생성된 경로에 삽입됩니다.

    출력 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend
      annotations:
        route.openshift.io/termination: reencrypt
        route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
    spec:
    ...
      tls:
        insecureEdgeTerminationPolicy: Redirect
        termination: reencrypt
        destinationCACertificate: |
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
    ...
    Copy to Clipboard Toggle word wrap

OpenShift Container Platform 클러스터가 IPv4 및 IPv6 이중 스택 네트워킹에 맞게 구성된 경우 OpenShift Container Platform 경로에서 외부에서 클러스터에 연결할 수 있습니다.

Ingress 컨트롤러는 IPv4 및 IPv6 엔드 포인트가 모두 있는 서비스를 자동으로 제공하지만 단일 스택 또는 듀얼 스택 서비스에 대해 Ingress 컨트롤러를 구성할 수 있습니다.

사전 요구 사항

  • 베어메탈에 OpenShift Container Platform 클러스터를 배포했습니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. Ingress 컨트롤러가 워크로드로 IPv4/IPv6을 통해 트래픽을 제공하도록 하려면 ipFamiliesipFamilyPolicy 필드를 설정하여 서비스 YAML 파일을 생성하거나 기존 서비스 YAML 파일을 수정할 수 있습니다. 예를 들면 다음과 같습니다.

    샘플 서비스 YAML 파일

    apiVersion: v1
    kind: Service
    metadata:
      creationTimestamp: yyyy-mm-ddT00:00:00Z
      labels:
        name: <service_name>
        manager: kubectl-create
        operation: Update
        time: yyyy-mm-ddT00:00:00Z
      name: <service_name>
      namespace: <namespace_name>
      resourceVersion: "<resource_version_number>"
      selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
      uid: <uid_number>
    spec:
      clusterIP: 172.30.0.0/16
      clusterIPs: 
    1
    
      - 172.30.0.0/16
      - <second_IP_address>
      ipFamilies: 
    2
    
      - IPv4
      - IPv6
      ipFamilyPolicy: RequireDualStack 
    3
    
      ports:
      - port: 8080
        protocol: TCP
        targetport: 8080
      selector:
        name: <namespace_name>
      sessionAffinity: None
      type: ClusterIP
    status:
      loadbalancer: {}
    Copy to Clipboard Toggle word wrap

    1
    듀얼 스택 인스턴스에는 두 개의 서로 다른 clusterIPs가 제공됩니다.
    2
    단일 스택 인스턴스의 경우 IPv4 또는 IPv6을 입력합니다. 듀얼 스택 인스턴스의 경우 IPv4IPv6 모두를 입력합니다.
    3
    단일 스택 인스턴스의 경우 SingleStack을 입력합니다. 듀얼 스택 인스턴스의 경우 RequireDualStack을 입력합니다.

    이러한 리소스는 해당 endpoints를 생성합니다. Ingress 컨트롤러는 이제 endpointslices를 감시합니다.

  2. endpoints를 확인하려면 다음 명령을 입력합니다:

    $ oc get endpoints
    Copy to Clipboard Toggle word wrap
  3. endpointslices를 확인하려면 다음 명령을 입력합니다.

    $ oc get endpointslices
    Copy to Clipboard Toggle word wrap

27.2. 보안 경로

보안 경로는 여러 유형의 TLS 종료를 사용하여 클라이언트에 인증서를 제공하는 기능을 제공합니다. 다음 섹션에서는 사용자 정의 인증서를 사용하여 재암호화 에지 및 패스스루 경로를 생성하는 방법을 설명합니다.

중요

공용 끝점을 통해 Microsoft Azure에서 경로를 생성하는 경우 리소스 이름에 제한이 적용됩니다. 특정 용어를 사용하는 리소스를 생성할 수 없습니다. Azure에서 제한하는 용어 목록은 Azure 설명서의 예약된 리소스 이름 오류 해결을 참조하십시오.

27.2.1. 사용자 정의 인증서를 사용하여 재암호화 경로 생성

oc create route 명령을 사용하면 재암호화 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다.

사전 요구 사항

  • PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
  • 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
  • PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
  • 노출하려는 서비스가 있어야 합니다.
참고

암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.

$ openssl rsa -in password_protected_tls.key -out tls.key
Copy to Clipboard Toggle word wrap

절차

이 절차에서는 사용자 정의 인증서를 사용하여 Route 리소스를 생성하고 TLS 종료를 재암호화합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crttls.key 파일에 있다고 가정합니다. Ingress 컨트롤러에서 서비스의 인증서를 신뢰하도록 하려면 대상 CA 인증서도 지정해야 합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, cacert.crt, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 리소스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.

  • 재암호화 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

    $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
    Copy to Clipboard Toggle word wrap

    생성된 Route 리소스는 다음과 유사합니다.

    보안 경로의 YAML 정의

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend
    spec:
      host: www.example.com
      to:
        kind: Service
        name: frontend
      tls:
        termination: reencrypt
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        destinationCACertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

    자세한 옵션은 oc create route reencrypt --help를 참조하십시오.

27.2.2. 사용자 정의 인증서를 사용하여 엣지 경로 생성

oc create route 명령을 사용하면 엣지 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 엣지 경로를 사용하면 Ingress 컨트롤러에서 트래픽을 대상 Pod로 전달하기 전에 TLS 암호화를 종료합니다. 이 경로는 Ingress 컨트롤러가 경로에 사용하는 TLS 인증서 및 키를 지정합니다.

사전 요구 사항

  • PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
  • 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
  • 노출하려는 서비스가 있어야 합니다.
참고

암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.

$ openssl rsa -in password_protected_tls.key -out tls.key
Copy to Clipboard Toggle word wrap

절차

이 절차에서는 사용자 정의 인증서 및 엣지 TLS 종료를 사용하여 Route 리소스를 생성합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crttls.key 파일에 있다고 가정합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.

  • 엣지 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

    $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
    Copy to Clipboard Toggle word wrap

    생성된 Route 리소스는 다음과 유사합니다.

    보안 경로의 YAML 정의

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend
    spec:
      host: www.example.com
      to:
        kind: Service
        name: frontend
      tls:
        termination: edge
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

    추가 옵션은 oc create route edge --help를 참조하십시오.

27.2.3. 패스스루 라우팅 생성

oc create route 명령을 사용하면 패스스루 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 패스스루 종료를 사용하면 암호화된 트래픽이 라우터에서 TLS 종료를 제공하지 않고 바로 대상으로 전송됩니다. 따라서 라우터에 키 또는 인증서가 필요하지 않습니다.

사전 요구 사항

  • 노출하려는 서비스가 있어야 합니다.

절차

  • Route 리소스를 생성합니다.

    $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080
    Copy to Clipboard Toggle word wrap

    생성된 Route 리소스는 다음과 유사합니다.

    패스스루 종료를 사용하는 보안 경로

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: route-passthrough-secured 
    1
    
    spec:
      host: www.example.com
      port:
        targetPort: 8080
      tls:
        termination: passthrough 
    2
    
        insecureEdgeTerminationPolicy: None 
    3
    
      to:
        kind: Service
        name: frontend
    Copy to Clipboard Toggle word wrap

    1
    63자로 제한되는 개체의 이름입니다.
    2
    termination 필드는 passthrough로 설정됩니다. 이 필드는 유일한 필수 tls 필드입니다.
    3
    insecureEdgeTerminationPolicy는 선택 사항입니다. 비활성화경우 유효한 값은 None, Redirect 또는 빈 값입니다.

    대상 Pod는 끝점의 트래픽에 대한 인증서를 제공해야 합니다. 현재 이 방법은 양방향 인증이라고도 하는 클라이언트 인증서도 지원할 수 있는 유일한 방법입니다.

28장. 수신 클러스터 트래픽 구성

28.1. 수신 클러스터 트래픽 구성 개요

OpenShift Container Platform에서는 다음 방법을 통해 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다.

순서 또는 기본 설정에 따라 권장되는 방법입니다.

  • HTTP/HTTPS가 있는 경우 Ingress 컨트롤러를 사용합니다.
  • HTTPS 이외의 TLS 암호화 프로토콜이 있는 경우(예: SNI 헤더가 있는 TLS), Ingress 컨트롤러를 사용합니다.
  • 그 외에는 로드 밸런서, 외부 IP 또는 NodePort를 사용합니다.
Expand
방법목적

Ingress 컨트롤러 사용

HTTPS 이외의 HTTP/HTTPS 트래픽 및 TLS 암호화 프로토콜(예: SNI 헤더가 있는 TLS)에 액세스할 수 있습니다.

로드 밸런서 서비스를 사용하여 외부 IP 자동 할당

풀에서 할당된 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다. 대부분의 클라우드 플랫폼은 로드 밸런서 IP 주소로 서비스를 시작하는 방법을 제공합니다.

MetalLB 및 MetalLB Operator 정보

시스템 네트워크의 풀에서 특정 IP 주소 또는 주소로의 트래픽을 허용합니다. 베어 메탈과 같은 베어 메탈 설치 또는 플랫폼의 경우 MetalLB는 로드 밸런서 IP 주소로 서비스를 시작하는 방법을 제공합니다.

서비스에 외부 IP를 수동으로 할당

특정 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다.

NodePort구성

클러스터의 모든 노드에 서비스를 공개합니다.

28.1.1. 비교: 외부 IP 주소에 대한 내결함성 액세스

외부 IP 주소에 대한 액세스를 제공하는 통신 방법의 경우 IP 주소에 대한 내결함성 액세스를 고려해야 합니다. 다음 기능은 외부 IP 주소에 대한 내결함성 액세스를 제공합니다.

IP 페일오버
IP 페일오버는 노드 집합의 가상 IP 주소 풀을 관리합니다. Keepalived 및 VRRP(Virtual Router Redundancy Protocol)로 구현됩니다. IP 페일오버는 계층 2 메커니즘일 뿐이며 멀티캐스트를 사용합니다. 멀티캐스트에는 일부 네트워크에 대한 단점이 있을 수 있습니다.
MetalLB
MetalLB에는 계층 2 모드가 있지만 멀티캐스트를 사용하지 않습니다. 계층 2 모드에는 하나의 노드를 통해 외부 IP 주소에 대한 모든 트래픽을 전송하는 단점이 있습니다.
수동으로 외부 IP 주소 할당
외부 IP 주소를 서비스에 할당하는 데 사용되는 IP 주소 블록을 사용하여 클러스터를 구성할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다. 이 기능은 유연하지만 클러스터 또는 네트워크 관리자에게 가장 큰 부담이 됩니다. 클러스터는 외부 IP로 향하는 트래픽을 수신할 준비가 되지만 각 고객은 트래픽을 노드로 라우팅하는 방법을 결정해야 합니다.

28.2. 서비스의 ExternalIP 구성

클러스터 관리자는 클러스터의 서비스로 트래픽을 보낼 수 있는 클러스터 외부의 IP 주소 블록을 지정할 수 있습니다.

이 기능은 일반적으로 베어 메탈 하드웨어에 설치된 클러스터에 가장 유용합니다.

28.2.1. 사전 요구 사항

  • 네트워크 인프라는 외부 IP 주소에 대한 트래픽을 클러스터로 라우팅해야 합니다.

28.2.2. ExternalIP 정보

클라우드 환경이 아닌 경우 OpenShift Container Platform에서는 ExternalIP 기능을 통해 Service 오브젝트 spec.externalIPs[] 필드에 외부 IP 주소 할당을 지원합니다. 이 필드를 설정하면 OpenShift Container Platform에서 추가 가상 IP 주소를 서비스에 할당합니다. IP 주소는 클러스터에 정의된 서비스 네트워크 외부에 있을 수 있습니다. ExternalIP 함수로 구성된 서비스는 type=NodePort인 서비스와 유사하게 작동하므로 부하 분산을 위해 트래픽을 로컬 노드로 보낼 수 있습니다.

정의한 외부 IP 주소 블록이 클러스터로 라우팅되도록 네트워킹 인프라를 구성해야 합니다. 결과적으로 노드의 네트워크 인터페이스에 IP 주소가 구성되지 않습니다. 트래픽을 처리하려면 ARM(Static Address Resolution Protocol) 항목과 같은 방법을 사용하여 라우팅 및 외부 IP에 대한 액세스를 구성해야 합니다.

OpenShift Container Platform은 다음 기능을 추가하여 Kubernetes의 ExternalIP 기능을 확장합니다.

  • 구성 가능한 정책을 통해 사용자가 외부 IP 주소 사용 제한
  • 요청 시 서비스에 자동으로 외부 IP 주소 할당
주의

ExternalIP 기능은 기본적으로 비활성화되어 있으며, 사용 시 외부 IP 주소에 대한 클러스터 내 트래픽이 해당 서비스로 전달되기 때문에 보안 위험이 발생할 수 있습니다. 이 경우 클러스터 사용자가 외부 리소스로 향하는 민감한 트래픽을 가로챌 수 있습니다.

중요

이 기능은 클라우드 배포가 아닌 경우에만 지원됩니다. 클라우드 배포의 경우 클라우드 로드 밸런서 자동 배포를 위한 로드 밸런서 서비스를 사용하여 서비스 끝점을 대상으로 합니다.

MetalLB 구현 또는 IP 페일오버 배포를 사용하여 다음과 같은 방법으로 ExternalIP 리소스를 서비스에 연결할 수 있습니다.

외부 IP 자동 할당
OpenShift Container Platform에서는 spec.type=LoadBalancer가 설정된Service 오브젝트를 생성할 때 autoAssignCIDRs CIDR 블록의 IP 주소를 spec.externalIPs[] 배열에 자동으로 할당합니다. 이 경우 OpenShift Container Platform은 로드 밸런서 서비스 유형의 비클라우드 버전을 구현하고 서비스에 IP 주소를 할당합니다. 자동 할당은 기본적으로 비활성화되어 있으며 다음 섹션에 설명된 대로 클러스터 관리자가 구성해야 합니다.
외부 IP 수동 할당
OpenShift Container Platform에서는 Service 오브젝트를 생성할 때 spec.externalIPs[] 배열에 할당된 IP 주소를 사용합니다. 다른 서비스에서 이미 사용 중인 IP 주소는 지정할 수 없습니다.
28.2.2.1. ExternalIP 구성

OpenShift Container Platform에 대한 외부 IP 주소 사용은 cluster라는 Network.config.openshift.io CR에 있는 다음 필드로 관리합니다.

  • spec.externalIP.autoAssignCIDRs는 서비스에 대한 외부 IP 주소를 선택할 때 로드 밸런서에서 사용하는 IP 주소 블록을 정의합니다. OpenShift Container Platform에서는 자동 할당에 대해 하나의 IP 주소 블록만 지원합니다. 이렇게 하면 서비스에 ExternalIP를 수동으로 할당 때 제한된 수의 공유 IP 주소로 구성된 포트 공간을 관리하는 것보다 더 간단할 수 있습니다. 자동 할당을 사용하는 경우 spec.type=LoadBalancerService에 외부 IP 주소가 할당됩니다.
  • spec.externalIP.policy는 IP 주소를 수동으로 지정할 때 허용되는 IP 주소 블록을 정의합니다. OpenShift Container Platform은 spec.externalIP.autoAssignCIDRs로 정의된 IP 주소 블록에 정책 규칙을 적용하지 않습니다.

올바르게 라우팅되면 구성된 외부 IP 주소 블록의 외부 트래픽이 서비스에서 노출하는 TCP 또는 UDP 포트를 통해 서비스 끝점에 도달할 수 있습니다.

중요

클러스터 관리자는 OpenShiftSDN 및 OVN-Kubernetes 네트워크 유형 모두에서 externalIP로 라우팅을 구성해야 합니다. 또한 할당하는 IP 주소 블록이 클러스터의 하나 이상의 노드에서 종료되어야 합니다. 자세한 내용은 Kubernetes 외부 IP를 참조하십시오.

OpenShift Container Platform에서는 IP 주소의 자동 및 수동 할당을 모두 지원하며 각 주소는 최대 하나의 서비스에 할당됩니다. 따라서 각 서비스는 다른 서비스에서 노출하는 포트와 관계없이 선택한 포트를 노출할 수 있습니다.

참고

OpenShift Container Platform에서 autoAssignCIDR로 정의된 IP 주소 블록을 사용하려면 호스트 네트워크에 필요한 IP 주소 할당 및 라우팅을 구성해야 합니다.

다음 YAML에서는 외부 IP 주소가 구성된 서비스를 설명합니다.

spec.externalIPs[]가 설정된 Service 오브젝트의 예

apiVersion: v1
kind: Service
metadata:
  name: http-service
spec:
  clusterIP: 172.30.163.110
  externalIPs:
  - 192.168.132.253
  externalTrafficPolicy: Cluster
  ports:
  - name: highport
    nodePort: 31903
    port: 30102
    protocol: TCP
    targetPort: 30102
  selector:
    app: web
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.168.132.253
Copy to Clipboard Toggle word wrap

28.2.2.2. 외부 IP 주소 할당 제한 사항

클러스터 관리자는 허용 및 거부할 IP 주소 블록을 지정할 수 있습니다.

제한 사항은 cluster-admin 권한이 없는 사용자에게만 적용됩니다. 클러스터 관리자는 서비스 spec.externalIPs[] 필드를 IP 주소로 항상 설정할 수 있습니다.

spec.ExternalIP.policy 필드를 지정하여 정의된 policy 오브젝트를 사용하여 IP 주소 정책을 구성합니다. 정책 오브젝트의 형태는 다음과 같습니다.

{
  "policy": {
    "allowedCIDRs": [],
    "rejectedCIDRs": []
  }
}
Copy to Clipboard Toggle word wrap

정책 제한을 구성할 때는 다음 규칙이 적용됩니다.

  • policy={}가 설정된 경우 spec.ExternalIPs[]가 설정된 Service 오브젝트를 생성할 수 없습니다. 이는 OpenShift Container Platform의 기본값입니다. policy=null을 설정할 때의 동작은 동일합니다.
  • policy가 설정되고 policy.allowedCIDRs[] 또는 policy.rejectedCIDRs[]가 설정된 경우 다음 규칙이 적용됩니다.

    • allowedCIDRs[]rejectedCIDRs[]가 둘 다 설정된 경우 rejectedCIDRs[]allowedCIDRs[]보다 우선합니다.
    • allowedCIDRs[]가 설정된 경우 지정된 IP 주소가 허용되는 경우에만 spec.ExternalIPs[]를 사용하여 Service를 생성할 수 있습니다.
    • rejectedCIDRs[]가 설정된 경우 지정된 IP 주소가 거부되지 않는 경우에만 spec.ExternalIPs[]를 사용하여 Service를 생성할 수 있습니다.
28.2.2.3. 정책 오브젝트의 예

다음 예제에서는 다양한 정책 구성을 보여줍니다.

  • 다음 예에서 정책은 OpenShift Container Platform에서 외부 IP 주소가 지정된 서비스를 생성하지 못하도록 합니다.

    Service 오브젝트 spec.externalIPs[]에 지정된 값을 거부하는 정책의 예

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      externalIP:
        policy: {}
      ...
    Copy to Clipboard Toggle word wrap

  • 다음 예에서는 allowedCIDRsrejectedCIDRs 필드가 모두 설정되어 있습니다.

    허용되거나 거부된 CIDR 블록을 모두 포함하는 정책의 예

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      externalIP:
        policy:
          allowedCIDRs:
          - 172.16.66.10/23
          rejectedCIDRs:
          - 172.16.66.10/24
      ...
    Copy to Clipboard Toggle word wrap

  • 다음 예에서는 policynull로 설정됩니다. null로 설정하면 oc get networks.config.openshift.io -o yaml을 입력하여 구성 오브젝트를 검사할 때 policy 필드가 출력에 표시되지 않습니다.

    Service 오브젝트 spec.externalIPs[]에 지정된 값을 허용하는 정책의 예

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      externalIP:
        policy: null
      ...
    Copy to Clipboard Toggle word wrap

28.2.3. ExternalIP 주소 블록 구성

ExternalIP 주소 블록에 대한 구성은 cluster라는 네트워크 CR(사용자 정의 리소스)에 의해 정의됩니다. 네트워크 CR은 config.openshift.io API 그룹의 일부입니다.

중요

CVO(Cluster Version Operator)는 클러스터를 설치하는 동안 cluster라는 네트워크 CR을 자동으로 생성합니다. 이 유형의 다른 CR 오브젝트는 생성할 수 없습니다.

다음 YAML에서는 ExternalIP 구성을 설명합니다.

cluster라는 Network.config.openshift.io CR

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  externalIP:
    autoAssignCIDRs: [] 
1

    policy: 
2

      ...
Copy to Clipboard Toggle word wrap

1
서비스에 대한 외부 IP 주소 자동 할당에 사용할 수 있는 CIDR 형식으로 IP 주소 블록을 정의합니다. 단일 IP 주소 범위만 허용됩니다.
2
서비스에 대한 IP 주소 수동 할당에 대한 제한을 정의합니다. 제한이 정의되지 않은 경우 Service에서 spec.externalIP 필드를 지정할 수 없습니다. 기본적으로는 제한이 정의되어 있지 않습니다.

다음 YAML에서는 policy 스탠자의 필드를 설명합니다.

Network.config.openshift.io policy 스탠자

policy:
  allowedCIDRs: [] 
1

  rejectedCIDRs: [] 
2
Copy to Clipboard Toggle word wrap

1
CIDR 형식의 허용된 IP 주소 범위 목록입니다.
2
CIDR 형식의 거부된 IP 주소 범위 목록입니다.
외부 IP 구성의 예

외부 IP 주소 풀에 사용 가능한 몇 가지 구성이 다음 예에 표시되어 있습니다.

  • 다음 YAML에서는 자동으로 할당된 외부 IP 주소를 사용하는 구성을 설명합니다.

    spec.externalIP.autoAssignCIDRs가 설정된 구성의 예

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      ...
      externalIP:
        autoAssignCIDRs:
        - 192.168.132.254/29
    Copy to Clipboard Toggle word wrap

  • 다음 YAML에서는 허용되거나 거부된 CIDR 범위에 대한 정책 규칙을 구성합니다.

    spec.externalIP.policy가 설정된 구성의 예

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      ...
      externalIP:
        policy:
          allowedCIDRs:
          - 192.168.132.0/29
          - 192.168.132.8/29
          rejectedCIDRs:
          - 192.168.132.7/32
    Copy to Clipboard Toggle word wrap

28.2.4. 클러스터에 대한 외부 IP 주소 블록 구성

클러스터 관리자는 다음 ExternalIP 설정을 구성할 수 있습니다.

  • Service 오브젝트의 spec.clusterIP 필드를 자동으로 채우도록 OpenShift Container Platform에서 사용하는 ExternalIP 주소 블록입니다.
  • Service 오브젝트의 spec.clusterIP 배열에 수동으로 할당할 수 있는 IP 주소를 제한하는 정책 오브젝트입니다.

사전 요구 사항

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

프로세스

  1. 선택 사항: 현재 외부 IP 구성을 표시하려면 다음 명령을 입력합니다.

    $ oc describe networks.config cluster
    Copy to Clipboard Toggle word wrap
  2. 구성을 편집하려면 다음 명령을 입력합니다.

    $ oc edit networks.config cluster
    Copy to Clipboard Toggle word wrap
  3. 다음 예와 같이 ExternalIP 구성을 수정합니다.

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      ...
      externalIP: 
    1
    
      ...
    Copy to Clipboard Toggle word wrap
    1
    externalIP 스탠자에 대한 구성을 지정합니다.
  4. 업데이트된 ExternalIP 구성을 확인하려면 다음 명령을 입력합니다.

    $ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

28.2.5. 다음 단계

28.3. Ingress 컨트롤러를 사용한 수신 클러스터 트래픽 구성

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 Ingress 컨트롤러를 사용합니다.

28.3.1. Ingress 컨트롤러 및 경로 사용

Ingress Operator에서는 Ingress 컨트롤러 및 와일드카드 DNS를 관리합니다.

OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하는 가장 일반적인 방법은 Ingress 컨트롤러를 사용하는 것입니다.

Ingress 컨트롤러는 외부 요청을 수락하고 구성된 경로를 기반으로 이러한 요청을 프록시하도록 구성되어 있습니다. 이는 HTTP, SNI를 사용하는 HTTPS, SNI를 사용하는 TLS로 제한되며, SNI를 사용하는 TLS를 통해 작동하는 웹 애플리케이션 및 서비스에 충분합니다.

관리자와 협력하여 구성된 경로를 기반으로 외부 요청을 수락하고 프록시하도록 Ingress 컨트롤러를 구성하십시오.

관리자는 와일드카드 DNS 항목을 생성한 다음 Ingress 컨트롤러를 설정할 수 있습니다. 그러면 관리자에게 문의하지 않고도 엣지 Ingress 컨트롤러로 작업할 수 있습니다.

기본적으로 클러스터의 모든 Ingress 컨트롤러는 클러스터의 모든 프로젝트에서 생성된 경로를 허용할 수 있습니다.

Ingress 컨트롤러의 경우

  • 기본적으로 두 개의 복제본이 있으므로 두 개의 작업자 노드에서 실행되어야 합니다.
  • 더 많은 노드에 더 많은 복제본을 갖도록 확장할 수 있습니다.
참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

28.3.2. 사전 요구 사항

다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

  • 요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
  • 클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user cluster-admin username
    Copy to Clipboard Toggle word wrap
  • 클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 하나 이상 있고 클러스터 외부의 시스템이 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

28.3.3. 프로젝트 및 서비스 생성

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트 및 서비스가 이미 존재하는 경우 서비스 노출 절차로 건너뛰어 경로를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치하고 클러스터 관리자로 로그인합니다.

프로세스

  1. oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 생성합니다.

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap
  2. oc new-app 명령을 사용하여 서비스를 생성합니다.

    $ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
    Copy to Clipboard Toggle word wrap
  3. 서비스가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get svc -n <project_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    nodejs-ex   ClusterIP   172.30.197.157   <none>        8080/TCP   70s
    Copy to Clipboard Toggle word wrap

    참고

    기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

28.3.4. 경로를 생성하여 서비스 노출

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에 로그인되어 있습니다.

프로세스

  1. 노출하려는 서비스가 있는 프로젝트에 로그인합니다.

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap
  2. oc expose service 명령을 실행하여 경로를 노출합니다.

    $ oc expose service nodejs-ex
    Copy to Clipboard Toggle word wrap

    출력 예

    route.route.openshift.io/nodejs-ex exposed
    Copy to Clipboard Toggle word wrap

  3. 서비스가 노출되었는지 확인하려면 curl 과 같은 툴을 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.

    1. 경로의 호스트 이름을 찾으려면 다음 명령을 입력합니다.

      $ oc get route
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME        HOST/PORT                        PATH   SERVICES    PORT       TERMINATION   WILDCARD
      nodejs-ex   nodejs-ex-myproject.example.com         nodejs-ex   8080-tcp                 None
      Copy to Clipboard Toggle word wrap

    2. 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력합니다.

      curl 명령 예

      $ curl --head nodejs-ex-myproject.example.com
      Copy to Clipboard Toggle word wrap

      출력 예

      HTTP/1.1 200 OK
      ...
      Copy to Clipboard Toggle word wrap

28.3.5. OpenShift Container Platform의 Ingress 분할

OpenShift Container Platform에서 Ingress 컨트롤러는 모든 경로를 제공하거나 경로 서브 세트를 제공할 수 있습니다. 기본적으로 Ingress 컨트롤러는 클러스터의 모든 네임스페이스에서 생성된 모든 경로를 제공합니다. 선택한 특성을 기반으로 경로 서브 세트인 shard 를 생성하여 라우팅을 최적화하도록 클러스터에 Ingress 컨트롤러를 추가할 수 있습니다. 경로를 shard의 멤버로 표시하려면 경로 또는 네임스페이스 메타데이터 필드의 라벨을 사용합니다. Ingress 컨트롤러는 선택 표현식 이라고도 하는 선택기 를 사용하여 제공할 전체 경로 풀에서 경로 서브 세트를 선택합니다.

Ingress 분할은 트래픽을 특정 Ingress 컨트롤러로 분리하거나 다음 섹션에 설명된 다양한 이유로 트래픽을 분리하려는 경우 여러 Ingress 컨트롤러에서 들어오는 트래픽을 로드 밸런싱하려는 경우에 유용합니다.

기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 그러나 라우터의 도메인을 대신 사용하도록 경로를 구성할 수 있습니다.

28.3.6. Ingress 컨트롤러 분할

라우터 샤딩이라고도 하는 Ingress 샤딩을 사용하여 라우팅, 네임스페이스 또는 둘 다에 라벨을 추가하여 여러 라우터에 경로 집합을 배포할 수 있습니다. Ingress 컨트롤러는 해당 선택기 세트를 사용하여 라벨이 지정된 경로만 허용합니다. 각 Ingress shard는 지정된 선택 표현식을 사용하여 필터링된 경로로 구성됩니다.

트래픽이 클러스터로 유입되는 기본 메커니즘으로 Ingress 컨트롤러의 요구 사항이 중요할 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.

  • 여러 경로를 통해 Ingress 컨트롤러 또는 라우터를 로드 밸런싱하여 변경에 대한 응답 속도 향상
  • 특정 경로가 나머지 경로와 다른 수준의 신뢰성을 가지도록 할당
  • 특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
  • 특정 경로만 추가 기능을 사용하도록 허용
  • 예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출
  • Blue Green 배포 중에 한 버전의 애플리케이션에서 다른 애플리케이션으로 트래픽을 전송합니다.

Ingress 컨트롤러가 분할되면 지정된 경로가 그룹에서 0개 이상의 Ingress 컨트롤러에 허용됩니다. 경로의 상태는 Ingress 컨트롤러가 이를 승인했는지 여부를 나타냅니다. Ingress 컨트롤러는 shard에 고유한 경로만 허용합니다.

Ingress 컨트롤러는 다음 세 가지 분할 방법을 사용할 수 있습니다.

  • 네임스페이스 선택기와 일치하는 라벨이 있는 네임스페이스의 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 네임스페이스 선택기만 추가합니다.
  • 경로 선택기와 일치하는 라벨이 있는 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 경로 선택기만 추가합니다.
  • 네임스페이스 선택기와 경로 선택기를 모두 Ingress 컨트롤러에 추가하여 네임스페이스 선택기와 일치하는 네임스페이스의 경로 선택기와 일치하는 라벨이 있는 경로가 Ingress shard에 있습니다.

분할을 사용하면 여러 Ingress 컨트롤러에 경로 서브 세트를 배포할 수 있습니다. 이러한 하위 세트는 기존 샤딩이라고도 하는 겹치지 않거나 겹치는 분할이라고 할 수 있습니다.

28.3.6.1. 기존 분할 예

레이블 선택기 spec.namespaceSelector.matchExpressions 가 있는 구성된 Ingress 컨트롤러 finops-router 의 예로, key 값이 financial 및 ops 로 설정되어 있습니다.

finops-router의 YAML 정의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - finance
      - ops
Copy to Clipboard Toggle word wrap

선택기 spec.namespaceSelector.matchLabels.name 레이블이 dev 로 설정된 구성된 Ingress 컨트롤러 dev-router 의 예입니다.

dev-router의 YAML 정의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev
Copy to Clipboard Toggle word wrap

name:finance,name:ops, name:dev 로 레이블이 지정된 각 네임스페이스와 같은 모든 애플리케이션 경로가 별도의 네임스페이스에 있는 경우 구성은 두 Ingress 컨트롤러 간에 경로를 효과적으로 배포합니다. 콘솔, 인증 및 기타 용도로는 OpenShift Container Platform 경로를 처리해서는 안 됩니다.

이전 시나리오에서는 분할의 특수한 경우가 되며 하위 집합이 겹치지 않습니다. 경로는 라우터 shard로 나뉩니다.

주의

namespaceSelector 또는 routeSelector 필드에 제외를 위한 경로가 포함되지 않는 한 기본 Ingress 컨트롤러는 모든 경로를 계속 제공합니다. 기본 Ingress 컨트롤러에서 경로를 제외하는 방법에 대한 자세한 내용은 이 Red Hat Knowledgebase 솔루션 및 "기본 Ingress 컨트롤러" 섹션 "기본 Ingress 컨트롤러"를 참조하십시오.

28.3.6.2. 겹치는 분할 예

선택기 spec.namespaceSelector.matchExpressions에 devops 로 설정된 라벨 선택기 spec.namespaceSelector.matchExpressions 가 있는 구성된 Ingress 컨트롤러 Cryostat -router 의 예

CloudEvent -router에 대한 YAML정의의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - dev
      - ops
Copy to Clipboard Toggle word wrap

name:devname:ops 레이블이 지정된 네임스페이스의 경로는 이제 두 개의 다른 Ingress 컨트롤러에서 서비스를 제공합니다. 이 구성을 사용하면 경로의 하위 집합이 중복됩니다.

겹치는 경로 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 생성할 수 있습니다. 예를 들어 더 높은 우선순위 트래픽을 CloudEvent-router로 보내는 동안 더 높은 우선 순위 트래픽을 전용 finops -router 로 변환할 수 있습니다.

28.3.6.3. 기본 Ingress 컨트롤러 분할

새 Ingress shard를 생성한 후 기본 Ingress 컨트롤러에서 허용하는 새 Ingress shard에 허용되는 경로가 있을 수 있습니다. 기본 Ingress 컨트롤러에는 선택기가 없고 기본적으로 모든 경로를 허용하기 때문입니다.

네임스페이스 선택기 또는 경로 선택기를 사용하여 특정 라벨이 있는 서비스 경로에서 Ingress 컨트롤러를 제한할 수 있습니다. 다음 절차에서는 네임스페이스 선택기를 사용하여 기본 Ingress 컨트롤러가 새로 분할된 financial ,opsdev 경로를 서비스하지 못하도록 제한합니다. 이렇게 하면 Ingress shard에 추가 격리가 추가됩니다.

중요

모든 OpenShift Container Platform의 관리 경로를 동일한 Ingress 컨트롤러에 보관해야 합니다. 따라서 이러한 필수 경로를 제외하는 기본 Ingress 컨트롤러에 선택기를 추가하지 마십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트 관리자로 로그인되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 기본 Ingress 컨트롤러를 수정합니다.

    $ oc edit ingresscontroller -n openshift-ingress-operator default
    Copy to Clipboard Toggle word wrap
  2. financial ,ops, dev 라벨이 있는 경로를 제외하는 namespaceSelector 를 포함하도록 Ingress 컨트롤러를 편집합니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      namespaceSelector:
        matchExpressions:
          - key: name
            operator: NotIn
            values:
              - finance
              - ops
              - dev
    Copy to Clipboard Toggle word wrap

기본 Ingress 컨트롤러는 더 이상 name:finance,name:ops, name:dev 라는 이름을 제공하지 않습니다.

28.3.6.4. Ingress 분할 및 DNS

클러스터 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 만들어야 합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.

다음 예제를 고려하십시오.

  • 라우터 A는 호스트 192.168.0.5에 있으며 *.foo.com 이 있는 경로가 있습니다.
  • 라우터 B는 호스트 192.168.1.9에 있으며 *.example.com 이 있는 경로가 있습니다.

별도의 DNS 항목이 라우터 A 및 *.example.com 을 호스팅하는 노드로 *.foo.com 을 확인하고 라우터 B를 호스팅하는 노드로 확인해야합니다.

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9
28.3.6.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성

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

그림 28.1. 경로 라벨을 사용한 Ingress 분할

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

프로세스

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: sharded
      namespace: openshift-ingress-operator
    spec:
      domain: <apps-sharded.basedomain.example.net> 
    1
    
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
      routeSelector:
        matchLabels:
          type: sharded
    Copy to Clipboard Toggle word wrap
    1
    Ingress 컨트롤러에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress 컨트롤러 도메인과 달라야 합니다.
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml
    Copy to Clipboard Toggle word wrap

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

  3. router-internal.yaml 에 구성된 도메인을 사용하여 새 경로를 생성합니다.

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
    Copy to Clipboard Toggle word wrap
28.3.6.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성

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

그림 28.2. 네임스페이스 라벨을 사용한 Ingress 분할

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

프로세스

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

    $ cat router-internal.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: sharded
      namespace: openshift-ingress-operator
    spec:
      domain: <apps-sharded.basedomain.example.net> 
    1
    
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
      namespaceSelector:
        matchLabels:
          type: sharded
    Copy to Clipboard Toggle word wrap

    1
    Ingress 컨트롤러에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress 컨트롤러 도메인과 달라야 합니다.
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    $ oc apply -f router-internal.yaml
    Copy to Clipboard Toggle word wrap

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

  3. router-internal.yaml 에 구성된 도메인을 사용하여 새 경로를 생성합니다.

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
    Copy to Clipboard Toggle word wrap
28.3.6.7. Ingress 컨트롤러 샤딩 경로 생성

경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. 이 경우 호스트 이름이 설정되지 않고 경로에서 하위 도메인을 대신 사용합니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress 컨트롤러의 도메인을 자동으로 사용합니다. 여러 Ingress 컨트롤러에서 경로를 노출하는 경우 경로가 여러 URL에서 호스팅됩니다.

다음 절차에서는 hello-openshift 애플리케이션을 예제로 사용하여 Ingress 컨트롤러 샤딩의 경로를 생성하는 방법을 설명합니다.

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

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트 관리자로 로그인되어 있습니다.
  • 포트의 트래픽을 청취하는 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
  • 샤딩을 위해 Ingress 컨트롤러가 구성되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.

    $ oc new-project hello-openshift
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 프로젝트에서 Pod를 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 hello-openshift 라는 서비스를 생성합니다.

    $ oc expose pod/hello-openshift
    Copy to Clipboard Toggle word wrap
  4. hello-openshift-route.yaml 이라는 경로 정의를 생성합니다.

    분할을 위해 생성된 경로에 대한 YAML 정의:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded 
    1
    
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift 
    2
    
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    Copy to Clipboard Toggle word wrap

    1
    label 키와 해당 레이블 값은 Ingress 컨트롤러에 지정된 레이블 값과 일치해야 합니다. 이 예에서 Ingress 컨트롤러에는 라벨 키와 값 type: sharded 가 있습니다.
    2
    하위 도메인 필드 값을 사용하여 경로가 노출됩니다. subdomain 필드를 지정하는 경우 호스트 이름을 설정되지 않은 상태로 두어야 합니다. hostsubdomain 필드를 모두 지정하면 경로에서 호스트 필드의 값을 사용하고 subdomain 필드를 무시합니다.
  5. 다음 명령을 실행하여 hello-openshift-route.yaml 을 사용하여 hello-openshift 애플리케이션에 대한 경로를 생성합니다.

    $ oc -n hello-openshift create -f hello-openshift-route.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 사용하여 경로 상태를 가져옵니다.

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
    Copy to Clipboard Toggle word wrap

    결과 경로 리소스는 다음과 유사합니다.

    출력 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    status:
      ingress:
      - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    1
    
        routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    2
    
        routerName: sharded 
    3
    Copy to Clipboard Toggle word wrap

    1
    Ingress 컨트롤러 또는 라우터에서 사용하는 호스트 이름에서 경로를 노출합니다. 호스트 필드의 값은 Ingress 컨트롤러에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress 컨트롤러의 도메인은 < apps-sharded.basedomain.example.net>입니다.
    2
    Ingress 컨트롤러의 호스트 이름입니다.
    3
    Ingress 컨트롤러의 이름입니다. 이 예에서 Ingress 컨트롤러의 이름은 sharded 입니다.
추가 리소스

28.4. Ingress 컨트롤러 끝점 게시 전략 구성

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

중요

RHOSP(Red Hat OpenStack Platform)에서 LoadBalancerService 끝점 게시 전략은 클라우드 공급자가 상태 모니터를 생성하도록 구성된 경우에만 지원됩니다. RHOSP 16.2의 경우 이 전략은 Amphora Octavia 공급자를 사용하는 경우에만 가능합니다.

자세한 내용은 RHOSP 설치 설명서의 "RHOSP Cloud Controller Manager 옵션 설정" 섹션을 참조하십시오.

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

NodePortService 끝점 게시 전략

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

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

그림 28.3. NodePortService 다이어그램

위의 그래픽에서는 OpenShift Container Platform Ingress NodePort 끝점 게시 전략과 관련된 다음 개념을 보여줍니다.

  • 클러스터에서 사용 가능한 모든 노드에는 외부 액세스가 가능한 자체 IP 주소가 있습니다. 클러스터에서 실행 중인 서비스는 모든 노드의 고유한 NodePort에 바인딩됩니다.
  • 클라이언트가 다운된 노드에 연결하는 경우(예: 10.0.128.4 IP 주소를 hammer)에 연결하면 노드 포트는 서비스를 실행하는 사용 가능한 노드에 클라이언트를 직접 연결합니다. 이 시나리오에서는 로드 밸런싱이 필요하지 않습니다. 이미지에서 볼 수 있듯이 10.0.128.4 주소가 다운되어 다른 IP 주소를 대신 사용해야 합니다.
참고

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

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

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

HostNetwork 끝점 게시 전략

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

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

HostNetwork 오브젝트에는 httpPort: 80,httpsPort: 443, statsPort: 1936 이라는 선택적 바인딩 포트에 대해 다음과 같은 기본값이 있는 hostNetwork 필드가 있습니다. 네트워크에 다른 바인딩 포트를 지정하면 HostNetwork 전략에 대해 동일한 노드에 여러 Ingress 컨트롤러를 배포할 수 있습니다.

예제

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: internal
  namespace: openshift-ingress-operator
spec:
  domain: example.com
  endpointPublishingStrategy:
    type: HostNetwork
    hostNetwork:
      httpPort: 80
      httpsPort: 443
      statsPort: 1936
Copy to Clipboard Toggle word wrap

28.4.1.1. Ingress 컨트롤러 끝점 게시 범위를 Internal로 구성

클러스터 관리자가 클러스터가 비공개임을 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 외부로 설정된 범위를 사용하여 생성됩니다. 클러스터 관리자는 외부 범위가 지정된 Ingress 컨트롤러를 Internal 로 변경할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 외부 범위가 지정된 Ingress 컨트롤러를 Internal 로 변경하려면 다음 명령을 입력합니다.

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'
    Copy to Clipboard Toggle word wrap
  • Ingress 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.

    $ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
    Copy to Clipboard Toggle word wrap
    • 진행 상태 조건은 추가 조치를 취해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.

      $ oc -n openshift-ingress delete services/router-default
      Copy to Clipboard Toggle word wrap

      서비스를 삭제하면 Ingress Operator가 서비스를 Internal 로 다시 생성합니다.

28.4.1.2. Ingress 컨트롤러 끝점 게시 범위를 외부로 구성

클러스터 관리자가 클러스터가 비공개임을 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 외부로 설정된 범위를 사용하여 생성됩니다.

Ingress 컨트롤러의 범위는 설치 중 내부로 구성할 수 있으며 클러스터 관리자는 내부 Ingress 컨트롤러를 외부로 변경할 수 있습니다.

중요

일부 플랫폼에서는 서비스를 삭제하고 다시 생성해야 합니다.

범위를 변경하면 몇 분 동안 잠재적으로 Ingress 트래픽이 중단될 수 있습니다. 이는 서비스를 삭제하고 재생성해야 하는 플랫폼에 적용됩니다. 이 절차를 수행하면 OpenShift Container Platform에서 기존 서비스 로드 밸런서를 프로비저닝 해제하고 새 서비스 로드 밸런서를 프로비저닝하고 DNS를 업데이트할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 내부 범위가 지정된 Ingress 컨트롤러를 외부로 변경하려면 다음 명령을 입력합니다.

    $ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'
    Copy to Clipboard Toggle word wrap
  • Ingress 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.

    $ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
    Copy to Clipboard Toggle word wrap
    • 진행 상태 조건은 추가 조치를 취해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.

      $ oc -n openshift-ingress delete services/router-default
      Copy to Clipboard Toggle word wrap

      서비스를 삭제하면 Ingress Operator가 서비스를 외부로 다시 생성합니다.

28.4.1.3. Ingress 컨트롤러에 단일 NodePort 서비스 추가

각 프로젝트에 NodePort-type Service 를 생성하는 대신 사용자 정의 Ingress 컨트롤러를 생성하여 NodePortService 끝점 게시 전략을 사용할 수 있습니다. 포트 충돌을 방지하려면 Ingress 샤딩을 통해 HostNetwork Ingress 컨트롤러가 있을 수 있는 노드에 경로 세트를 적용하려면 Ingress 컨트롤러에 대해 이 구성을 고려하십시오.

각 프로젝트에 NodePort-type 서비스를 설정하기 전에 다음 고려 사항을 읽으십시오.

  • Nodeport Ingress 컨트롤러 도메인에 대한 와일드카드 DNS 레코드를 생성해야 합니다. Nodeport Ingress 컨트롤러 경로는 작업자 노드의 주소에서 연결할 수 있습니다. 경로에 필요한 DNS 레코드에 대한 자세한 내용은 "사용자 프로비저닝 DNS 요구 사항"을 참조하십시오.
  • 서비스의 경로를 노출하고 사용자 정의 Ingress 컨트롤러 도메인의 --hostname 인수를 지정해야 합니다.
  • 애플리케이션 Pod에 액세스할 수 있도록 경로의 NodePort-type 서비스에 할당된 포트를 추가해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 와일드카드 DNS 레코드를 생성했습니다.

프로세스

  1. Ingress 컨트롤러에 대한 CR(사용자 정의 리소스) 파일을 생성합니다.

    IngressController 오브젝트에 대한 정보를 정의하는 CR 파일의 예

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: <custom_ic_name> 
    1
    
        namespace: openshift-ingress-operator
      spec:
        replicas: 1
        domain: <custom_ic_domain_name> 
    2
    
        nodePlacement:
          nodeSelector:
            matchLabels:
              <key>: <value> 
    3
    
        namespaceSelector:
         matchLabels:
           <key>: <value> 
    4
    
        endpointPublishingStrategy:
          type: NodePortService
    # ...
    Copy to Clipboard Toggle word wrap

    1
    IngressController CR의 사용자 정의 이름을 지정합니다.
    2
    Ingress 컨트롤러 서비스의 DNS 이름입니다. 예를 들어 기본 ingresscontroller 도메인은 apps.ipi-cluster.example.com 이므로 < custom_ic_domain_name >을 nodeportsvc.ipi-cluster.example.com 으로 지정합니다.
    3
    사용자 정의 Ingress 컨트롤러를 포함하는 노드의 라벨을 지정합니다.
    4
    네임스페이스 집합의 라벨을 지정합니다. < key>:<value >를 <key>가 새 레이블의 고유 이름이며 < value >가 값인 -값 쌍의 맵으로 바꿉니다. 예: ingresscontroller: custom-ic.
  2. oc label node 명령을 사용하여 노드에 라벨을 추가합니다.

    $ oc label node <node_name> <key>=<value> 
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <value >는 IngressController CR의 nodePlacement 섹션에 지정된 키-값 쌍과 일치해야 합니다.
  3. IngressController 오브젝트를 생성합니다.

    $ oc create -f <ingress_controller_cr>.yaml
    Copy to Clipboard Toggle word wrap
  4. IngressController CR에 대해 생성된 서비스의 포트를 찾습니다.

    $ oc get svc -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    router-nodeport-custom-ic3 서비스의 포트 80:32432/TCP 를 표시하는 출력 예

    NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                     AGE
    router-internal-default      ClusterIP   172.30.195.74    <none>        80/TCP,443/TCP,1936/TCP                     223d
    router-nodeport-custom-ic3   NodePort    172.30.109.219   <none>        80:32432/TCP,443:31366/TCP,1936:30499/TCP   155m
    Copy to Clipboard Toggle word wrap

  5. 새 프로젝트를 생성하려면 다음 명령을 입력합니다.

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap
  6. 새 네임스페이스에 레이블을 지정하려면 다음 명령을 입력합니다.

    $ oc label namespace <project_name> <key>=<value> 
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 & lt;key>=& lt;value>는 Ingress 컨트롤러 CR의 namespaceSelector 섹션에 있는 값과 일치해야 합니다.
  7. 클러스터에 새 애플리케이션을 생성합니다.

    $ oc new-app --image=<image_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    < image_name >의 예는 quay.io/openshifttest/hello-openshift:multiarch 입니다.
  8. Pod에서 서비스를 사용하여 클러스터 외부에 애플리케이션을 노출할 수 있도록 서비스의 Route 오브젝트를 생성합니다.

    $ oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name> 
    1
    Copy to Clipboard Toggle word wrap
    참고

    --hostname 인수에서 사용자 정의 Ingress 컨트롤러의 도메인 이름을 지정해야 합니다. 이 작업을 수행하지 않으면 Ingress Operator는 기본 Ingress 컨트롤러를 사용하여 클러스터의 모든 경로를 제공합니다.

  9. 경로에 Admitted 상태가 있고 사용자 정의 Ingress 컨트롤러에 대한 메타데이터가 포함되어 있는지 확인합니다.

    $ oc get route/hello-openshift -o json | jq '.status.ingress'
    Copy to Clipboard Toggle word wrap

    출력 예

    # ...
    {
      "conditions": [
        {
          "lastTransitionTime": "2024-05-17T18:25:41Z",
          "status": "True",
          "type": "Admitted"
        }
      ],
      [
        {
          "host": "hello-openshift.nodeportsvc.ipi-cluster.example.com",
          "routerCanonicalHostname": "router-nodeportsvc.nodeportsvc.ipi-cluster.example.com",
          "routerName": "nodeportsvc", "wildcardPolicy": "None"
        }
      ],
    }
    Copy to Clipboard Toggle word wrap

  10. 기본 Ingress 컨트롤러에서 NodePort-type 서비스를 관리하지 못하도록 기본 IngressController CR을 업데이트합니다. 기본 Ingress 컨트롤러는 다른 모든 클러스터 트래픽을 계속 모니터링합니다.

    $ oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 입력하여 DNS 항목이 클러스터 내부 및 외부에서 라우팅될 수 있는지 확인합니다. 이 명령은 절차의 앞부분에서 oc label node 명령을 실행하여 레이블을 수신한 노드의 IP 주소를 출력합니다.

    $ dig +short <svc_name>-<project_name>.<custom_ic_domain_name>
    Copy to Clipboard Toggle word wrap
  2. 클러스터가 DNS 확인을 위해 외부 DNS 서버의 IP 주소를 사용하는지 확인하려면 다음 명령을 입력하여 클러스터 연결을 확인합니다.

    $ curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port> 
    1
    Copy to Clipboard Toggle word wrap
    1 1
    여기서 <port >는 NodePort-type 서비스 의 노드 포트입니다. oc get svc -n openshift-ingress 명령의 예제 출력에 따라 80:32432/TCP HTTP 경로는 32432 가 노드 포트임을 의미합니다.

    출력 예

    Hello OpenShift!
    Copy to Clipboard Toggle word wrap

28.5. 로드 밸런서를 사용하여 수신 클러스터 트래픽 구성

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 로드 밸런서를 사용합니다.

28.5.1. 로드 밸런서를 사용하여 클러스터로 트래픽 가져오기

특정 외부 IP 주소가 필요하지 않은 경우 OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하도록 로드 밸런서 서비스를 구성할 수 있습니다.

로드 밸런서 서비스에서는 고유 IP를 할당합니다. 로드 밸런서에는 VIP(가상 IP)일 수 있는 단일 엣지 라우터 IP가 있지만 이는 초기 로드 밸런싱을 위한 단일 머신에 불과합니다.

참고

풀이 구성된 경우 클러스터 관리자가 아닌 인프라 수준에서 수행됩니다.

참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

28.5.2. 사전 요구 사항

다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

  • 요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
  • 클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user cluster-admin username
    Copy to Clipboard Toggle word wrap
  • 클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

28.5.3. 프로젝트 및 서비스 생성

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트 및 서비스가 이미 존재하는 경우 서비스 노출 절차로 건너뛰어 경로를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치하고 클러스터 관리자로 로그인합니다.

프로세스

  1. oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 생성합니다.

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap
  2. oc new-app 명령을 사용하여 서비스를 생성합니다.

    $ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
    Copy to Clipboard Toggle word wrap
  3. 서비스가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get svc -n <project_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    nodejs-ex   ClusterIP   172.30.197.157   <none>        8080/TCP   70s
    Copy to Clipboard Toggle word wrap

    참고

    기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

28.5.4. 경로를 생성하여 서비스 노출

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에 로그인되어 있습니다.

프로세스

  1. 노출하려는 서비스가 있는 프로젝트에 로그인합니다.

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap
  2. oc expose service 명령을 실행하여 경로를 노출합니다.

    $ oc expose service nodejs-ex
    Copy to Clipboard Toggle word wrap

    출력 예

    route.route.openshift.io/nodejs-ex exposed
    Copy to Clipboard Toggle word wrap

  3. 서비스가 노출되었는지 확인하려면 curl 과 같은 툴을 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.

    1. 경로의 호스트 이름을 찾으려면 다음 명령을 입력합니다.

      $ oc get route
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME        HOST/PORT                        PATH   SERVICES    PORT       TERMINATION   WILDCARD
      nodejs-ex   nodejs-ex-myproject.example.com         nodejs-ex   8080-tcp                 None
      Copy to Clipboard Toggle word wrap

    2. 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력합니다.

      curl 명령 예

      $ curl --head nodejs-ex-myproject.example.com
      Copy to Clipboard Toggle word wrap

      출력 예

      HTTP/1.1 200 OK
      ...
      Copy to Clipboard Toggle word wrap

28.5.5. 로드 밸런서 서비스 생성

다음 절차에 따라 로드 밸런서 서비스를 생성합니다.

사전 요구 사항

  • 노출하려는 프로젝트와 서비스가 존재하는지 확인합니다.
  • 클라우드 공급자는 로드 밸런서를 지원합니다.

프로세스

로드 밸런서 서비스를 생성하려면 다음을 수행합니다.

  1. OpenShift Container Platform 4에 로그인합니다.
  2. 노출하려는 서비스가 있는 프로젝트를 로드합니다.

    $ oc project project1
    Copy to Clipboard Toggle word wrap
  3. 필요에 따라 컨트롤 플레인 노드에서 텍스트 파일을 열고 다음 텍스트를 붙여넣고 파일을 편집합니다.

    로드 밸런서 구성 파일 샘플

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-2 
    1
    
    spec:
      ports:
      - name: db
        port: 3306 
    2
    
      loadBalancerIP:
      loadBalancerSourceRanges: 
    3
    
      - 10.0.0.0/8
      - 192.168.0.0/16
      type: LoadBalancer 
    4
    
      selector:
        name: mysql 
    5
    Copy to Clipboard Toggle word wrap

    1
    로드 밸런서 서비스를 설명하는 이름을 입력합니다.
    2
    노출하려는 서비스가 수신 대기 중인 포트와 동일한 포트를 입력합니다.
    3
    로드 밸런서를 통한 트래픽을 제한하려면 특정 IP 주소 목록을 입력합니다. cloud-provider가 이 기능을 지원하지 않는 경우 이 필드는 무시됩니다.
    4
    유형으로 Loadbalancer를 입력합니다.
    5
    서비스 이름을 입력합니다.
    참고

    로드 밸런서를 통한 트래픽을 특정 IP 주소로 제한하려면 Ingress 컨트롤러 필드 spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges 를 사용하는 것이 좋습니다. loadBalancerSourceRanges 필드를 설정하지 마십시오.

  4. 파일을 저장하고 종료합니다.
  5. 다음 명령을 실행하여 서비스를 생성합니다.

    $ oc create -f <file-name>
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f mysql-lb.yaml
    Copy to Clipboard Toggle word wrap
  6. 새 서비스를 보려면 다음 명령을 실행합니다.

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
    egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m
    Copy to Clipboard Toggle word wrap

    활성화된 클라우드 공급자가 있는 경우 서비스에 외부 IP 주소가 자동으로 할당됩니다.

  7. 마스터에서 cURL과 같은 도구를 사용하여 공개 IP 주소로 서비스에 도달할 수 있는지 확인합니다.

    $ curl <public-ip>:<port>
    Copy to Clipboard Toggle word wrap

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

    $ curl 172.29.121.74:3306
    Copy to Clipboard Toggle word wrap

    이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.

    MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.

    $ mysql -h 172.30.131.89 -u admin -p
    Copy to Clipboard Toggle word wrap

    출력 예

    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    
    MySQL [(none)]>
    Copy to Clipboard Toggle word wrap

28.6. AWS에서 수신 클러스터 트래픽 구성

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법은 AWS의 로드 밸런서, 특히 NLB(Network Load Balancer) 또는 Classic Load Balancer(CLB)를 사용합니다. 두 유형의 로드 밸런서 모두 클라이언트의 IP 주소를 노드로 전달할 수 있지만 CLB에는 OpenShift Container Platform이 자동으로 활성화하는 프록시 프로토콜 지원이 필요합니다.

NLB를 사용하도록 Ingress 컨트롤러를 구성하는 방법은 다음 두 가지가 있습니다.

  1. 현재 CLB를 사용하고 있는 Ingress 컨트롤러를 강제로 교체합니다. 이렇게 하면 IngressController 오브젝트가 삭제되고 새 DNS 레코드가 전파되고 NLB가 프로비저닝되는 동안 중단이 발생합니다.
  2. CLB를 사용하여 NLB를 사용하는 기존 Ingress 컨트롤러를 편집합니다. 이렇게 하면 IngressController 오브젝트를 삭제하고 다시 생성할 필요 없이 로드 밸런서가 변경됩니다.

두 방법 모두 NLB에서 CLB로 전환하는 데 사용할 수 있습니다.

이러한 로드 밸런서를 신규 또는 기존 AWS 클러스터에서 구성할 수 있습니다.

28.6.1. AWS에서 Classic 로드 밸런서 타임아웃 구성

OpenShift Container Platform에서는 특정 경로 또는 Ingress 컨트롤러에 대한 사용자 정의 시간 제한 기간을 설정하는 방법을 제공합니다. 또한 AWS Classic Load Balancer(CLB)에는 기본 시간이 60초인 자체 시간 초과 기간이 있습니다.

CLB의 시간 초과 기간이 경로 시간 초과 또는 Ingress 컨트롤러 타임아웃보다 짧은 경우 로드 밸런서에서 연결을 조기 종료할 수 있습니다. 경로의 시간 제한 기간과 CLB를 모두 늘려 이 문제를 방지할 수 있습니다.

28.6.1.1. 경로 시간 초과 구성

SLA(Service Level Availability) 목적에 필요한 낮은 시간 초과 또는 백엔드가 느린 경우 높은 시간 초과가 필요한 서비스가 있는 경우 기존 경로에 대한 기본 시간 초과를 구성할 수 있습니다.

사전 요구 사항

  • 실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

절차

  1. oc annotate 명령을 사용하여 경로에 시간 초과를 추가합니다.

    $ oc annotate route <route_name> \
        --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 
    1
    Copy to Clipboard Toggle word wrap
    1
    지원되는 시간 단위는 마이크로초(us), 밀리초(ms), 초(s), 분(m), 시간(h) 또는 일(d)입니다.

    다음 예제는 이름이 myroute인 경로에서 2초의 시간 초과를 설정합니다.

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
    Copy to Clipboard Toggle word wrap
28.6.1.2. Classic 로드 밸런서 타임아웃 구성

유휴 연결을 확장하도록 CLB( Classic Load Balancer)의 기본 타임아웃을 구성할 수 있습니다.

사전 요구 사항

  • 실행 중인 클러스터에 배포된 Ingress 컨트롤러가 있어야 합니다.

절차

  1. 다음 명령을 실행하여 기본 ingresscontroller 에 대해 AWS 연결 유휴 시간 제한 시간을 5분으로 설정합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"type":"LoadBalancerService", "loadBalancer": \
        {"scope":"External", "providerParameters":{"type":"AWS", "aws": \
        {"type":"Classic", "classicLoadBalancer": \
        {"connectionIdleTimeout":"5m"}}}}}}}'
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 다음 명령을 실행하여 시간 초과의 기본값을 복원합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \
        {"connectionIdleTimeout":null}}}}}}}'
    Copy to Clipboard Toggle word wrap
참고

현재 범위가 이미 설정되어 있지 않으면 연결 시간 초과 값을 변경할 때 scope 필드를 지정해야 합니다. 범위 필드를 설정할 때 기본 시간 초과 값을 복원하는 경우 다시 수행할 필요가 없습니다.

OpenShift Container Platform은 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있는 방법을 제공합니다. 이러한 방법 중 하나는 NLB(Network Load Balancer)를 사용합니다. 신규 또는 기존 AWS 클러스터에서 NLB를 구성할 수 있습니다.

CLB(Network Load Balancer)를 AWS의 NLB(Network Load Balancer)를 사용하는 Ingress 컨트롤러를 사용할 수 있습니다.

이러한 로드 밸런서 간에 전환해도 IngressController 오브젝트가 삭제되지 않습니다.

주의

이 절차에서는 다음과 같은 문제가 발생할 수 있습니다.

  • 새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요인으로 인해 몇 분 정도 걸릴 수 있는 중단입니다. 이 절차를 적용한 후 Ingress 컨트롤러 로드 밸런서의 IP 주소 및 정식 이름이 변경될 수 있습니다.
  • 서비스 주석이 변경되어 로드 밸런서 리소스가 유출되었습니다.

절차

  1. NLB를 사용하여 전환할 기존 Ingress 컨트롤러를 수정합니다. 이 예에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없는 것으로 가정합니다.

    ingresscontroller.yaml 파일 예

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
    Copy to Clipboard Toggle word wrap

    참고

    spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type 필드의 값을 지정하지 않으면 Ingress 컨트롤러는 설치 중에 설정된 클러스터 Ingress 구성에서 spec.loadBalancer.platform.aws.type 값을 사용합니다.

    작은 정보

    Ingress 컨트롤러에 도메인 변경과 같이 업데이트할 다른 사용자 정의가 있는 경우 Ingress 컨트롤러 정의 파일을 대신 교체하는 것이 좋습니다.

  2. 명령을 실행하여 Ingress 컨트롤러 YAML 파일에 변경 사항을 적용합니다.

    $ oc apply -f ingresscontroller.yaml
    Copy to Clipboard Toggle word wrap

    Ingress 컨트롤러 업데이트 중에 몇 분의 중단이 예상됩니다.

28.6.2.2. Ingress 컨트롤러를 Network Load Balancer를 Classic Load Balancer로 전환

NLB(Network Load Balancer)를 사용하는 Ingress 컨트롤러를 AWS에서 CLB( Classic Load Balancer)를 사용하는 컨트롤러로 전환할 수 있습니다.

이러한 로드 밸런서 간에 전환해도 IngressController 오브젝트가 삭제되지 않습니다.

주의

이 절차에서는 새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요인으로 인해 몇 분 정도 걸릴 수 있는 중단이 발생할 수 있습니다. 이 절차를 적용한 후 Ingress 컨트롤러 로드 밸런서의 IP 주소 및 정식 이름이 변경될 수 있습니다.

절차

  1. CLB를 사용하여 전환할 기존 Ingress 컨트롤러를 수정합니다. 이 예에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없는 것으로 가정합니다.

    ingresscontroller.yaml 파일 예

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: Classic
        type: LoadBalancerService
    Copy to Clipboard Toggle word wrap

    참고

    spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type 필드의 값을 지정하지 않으면 Ingress 컨트롤러는 설치 중에 설정된 클러스터 Ingress 구성에서 spec.loadBalancer.platform.aws.type 값을 사용합니다.

    작은 정보

    Ingress 컨트롤러에 도메인 변경과 같이 업데이트할 다른 사용자 정의가 있는 경우 Ingress 컨트롤러 정의 파일을 대신 교체하는 것이 좋습니다.

  2. 명령을 실행하여 Ingress 컨트롤러 YAML 파일에 변경 사항을 적용합니다.

    $ oc apply -f ingresscontroller.yaml
    Copy to Clipboard Toggle word wrap

    Ingress 컨트롤러 업데이트 중에 몇 분의 중단이 예상됩니다.

CLB(Network Load Balancer)를 AWS에서 NLB(Network Load Balancer)를 사용하는 Ingress 컨트롤러를 교체할 수 있습니다.

주의

이 절차에서는 다음과 같은 문제가 발생할 수 있습니다.

  • 새로운 DNS 레코드 전파, 새로운 로드 밸런서 프로비저닝 및 기타 요인으로 인해 몇 분 정도 걸릴 수 있는 중단입니다. 이 절차를 적용한 후 Ingress 컨트롤러 로드 밸런서의 IP 주소 및 정식 이름이 변경될 수 있습니다.
  • 서비스 주석이 변경되어 로드 밸런서 리소스가 유출되었습니다.

절차

  1. 새 기본 Ingress 컨트롤러를 사용하여 파일을 생성합니다. 다음 예제에서는 기본 Ingress 컨트롤러에 외부 범위가 있고 다른 사용자 정의가 없는 것으로 가정합니다.

    ingresscontroller.yml 파일 예

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
    Copy to Clipboard Toggle word wrap

    기본 Ingress 컨트롤러에 다른 사용자 정의가 있는 경우 그에 따라 파일을 수정해야 합니다.

    작은 정보

    Ingress 컨트롤러에 다른 사용자 지정 기능이 없고 로드 밸런서 유형만 업데이트하는 경우 "프로세스 로드 밸런서를 네트워크 로드 밸런서로 사용하지 못하도록 전환에서 Ingress 컨트롤러가 네트워크 로드 밸런서로 전환"에 자세히 설명된 절차를 고려하십시오.

  2. Ingress 컨트롤러 YAML 파일을 강제로 교체합니다.

    $ oc replace --force --wait -f ingresscontroller.yml
    Copy to Clipboard Toggle word wrap

    Ingress 컨트롤러가 교체될 때까지 기다립니다. 몇 분의 중단이 발생할 것으로 예상합니다.

기존 클러스터에서 AWS NLB(Network Load Balancer)가 지원하는 Ingress 컨트롤러를 생성할 수 있습니다.

사전 요구 사항

  • AWS 클러스터가 설치되어 있어야 합니다.
  • 인프라 리소스의 PlatformStatus는 AWS여야 합니다.

    • PlatformStatus가 AWS인지 확인하려면 다음을 실행하십시오.

      $ oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}'
      AWS
      Copy to Clipboard Toggle word wrap

절차

기존 클러스터에서 AWS NLB가 지원하는 Ingress 컨트롤러를 생성합니다.

  1. Ingress 컨트롤러 매니페스트를 생성합니다.

     $ cat ingresscontroller-aws-nlb.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: $my_ingress_controller
    1
    
      namespace: openshift-ingress-operator
    spec:
      domain: $my_unique_ingress_domain
    2
    
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External
    3
    
          providerParameters:
            type: AWS
            aws:
              type: NLB
    Copy to Clipboard Toggle word wrap

    1
    $my_ingress_controller를 Ingress 컨트롤러에 대해 고유한 이름으로 교체합니다.
    2
    $my_unique_ingress_domain을 클러스터의 모든 Ingress 컨트롤러 간에 고유한 도메인 이름으로 교체합니다. 이 변수는 DNS 이름 < clustername>.<domain>의 하위 도메인이어야 합니다.
    3
    내부 NLB를 사용하려면 ExternalInternal로 교체할 수 있습니다.
  2. 클러스터에서 리소스를 생성합니다.

    $ oc create -f ingresscontroller-aws-nlb.yaml
    Copy to Clipboard Toggle word wrap
중요

새 AWS 클러스터에서 Ingress 컨트롤러 NLB를 구성하려면 먼저 설치 구성 파일 생성 절차를 완료해야 합니다.

새 클러스터에서 AWS NLB(Network Load Balancer)가 지원하는 Ingress 컨트롤러를 생성할 수 있습니다.

사전 요구 사항

  • install-config.yaml 파일을 생성하고 수정합니다.

절차

새 클러스터에서 AWS NLB가 지원하는 Ingress 컨트롤러를 생성합니다.

  1. 설치 프로그램이 포함된 디렉터리로 변경하고 매니페스트를 생성합니다.

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <installation_directory>는 클러스터의 install-config.yaml 파일이 포함된 디렉터리의 이름을 지정합니다.
  2. <installation_directory>/manifests/ 디렉터리에 cluster-ingress-default-ingresscontroller.yaml이라는 이름으로 파일을 만듭니다.

    $ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <installation_directory>는 클러스터의 manifests / 디렉터리가 포함된 디렉터리 이름을 지정합니다.

    파일이 생성되면 다음과 같이 여러 네트워크 구성 파일이 manifests/ 디렉토리에 나타납니다.

    $ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    cluster-ingress-default-ingresscontroller.yaml
    Copy to Clipboard Toggle word wrap

  3. 편집기에서 cluster-ingress-default-ingresscontroller.yaml 파일을 열고 원하는 운영자 구성을 설명하는 CR(사용자 정의 리소스)을 입력합니다.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
    Copy to Clipboard Toggle word wrap
  4. cluster-ingress-default-ingresscontroller.yaml 파일을 저장하고 텍스트 편집기를 종료합니다.
  5. 선택 사항: manifests / cluster-ingress-default-ingresscontroller.yaml 파일을 백업합니다. 설치 프로그램은 클러스터를 생성할 때 manifests/ 디렉터리를 삭제합니다.

28.7. 서비스 외부 IP에 대한 수신 클러스터 트래픽 구성

MetalLB 구현 또는 IP 페일오버 배포를 사용하여 OpenShift Container Platform 클러스터 외부의 트래픽에 서비스를 사용할 수 있도록 ExternalIP 리소스를 서비스에 연결할 수 있습니다. 이러한 방식으로 외부 IP 주소를 호스팅하는 것은 베어 메탈 하드웨어에 설치된 클러스터에만 적용됩니다.

트래픽을 서비스로 라우팅하도록 외부 네트워크 인프라를 올바르게 구성해야 합니다.

28.7.1. 사전 요구 사항

  • 클러스터는 ExternalIP가 활성화된 상태로 구성됩니다. 자세한 내용은 서비스에 대한 ExternalIP 구성을 참조하십시오.

    참고

    송신 IP에 대해 동일한 ExternalIP를 사용하지 마십시오.

28.7.2. 서비스에 ExternalIP 연결

ExternalIP 리소스를 서비스에 연결할 수 있습니다. 리소스를 서비스에 자동으로 연결하도록 클러스터를 구성한 경우 ExternalIP를 서비스에 수동으로 연결할 필요가 없습니다.

이 절차의 예제에서는 IP 페일오버 구성을 사용하여 클러스터의 서비스에 ExternalIP 리소스를 수동으로 연결하는 시나리오를 사용합니다.

절차

  1. CLI에 다음 명령을 입력하여 ExternalIP 리소스에 호환되는 IP 주소 범위를 확인합니다.

    $ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'
    Copy to Clipboard Toggle word wrap
    참고

    autoAssignCIDRs 가 설정되어 ExternalIP 리소스에서 spec.externalIPs 값을 지정하지 않은 경우 OpenShift Container Platform은 새 Service 오브젝트에 ExternalIP를 자동으로 할당합니다.

  2. 다음 옵션 중 하나를 선택하여 ExternalIP 리소스를 서비스에 연결합니다.

    1. 새 서비스를 생성하는 경우 spec.externalIPs 필드에 값을 지정하고 allowedCIDRs 매개변수에서 하나 이상의 유효한 IP 주소 배열을 지정합니다.

      ExternalIP 리소스를 지원하는 서비스 YAML 구성 파일의 예

      apiVersion: v1
      kind: Service
      metadata:
        name: svc-with-externalip
      spec:
        externalIPs:
          policy:
            allowedCIDRs:
            - 192.168.123.0/28
      Copy to Clipboard Toggle word wrap

    2. ExternalIP를 기존 서비스에 연결하는 경우 다음 명령을 입력합니다. <name>을 서비스 이름으로 교체합니다. <ip_address>를 유효한 ExternalIP 주소로 교체합니다. 쉼표로 구분된 여러 IP 주소를 제공할 수 있습니다.

      $ oc patch svc <name> -p \
        '{
          "spec": {
            "externalIPs": [ "<ip_address>" ]
          }
        }'
      Copy to Clipboard Toggle word wrap

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

      $ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'
      Copy to Clipboard Toggle word wrap

      출력 예

      "mysql-55-rhel7" patched
      Copy to Clipboard Toggle word wrap

  3. ExternalIP 주소가 서비스에 연결되었는지 확인하려면 다음 명령을 입력합니다. 새 서비스에 ExternalIP를 지정한 경우 먼저 서비스를 생성해야 합니다.

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
    mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m
    Copy to Clipboard Toggle word wrap

28.8. NodePort를 사용하여 수신 클러스터 트래픽 구성

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 NodePort를 사용합니다.

28.8.1. NodePort를 사용하여 클러스터로 트래픽 가져오기

클러스터의 모든 노드에서 특정 포트에 서비스를 노출하려면 NodePort 유형의 서비스 리소스를 사용하십시오. 포트는 Service 리소스의 .spec.ports[*].nodePort 필드에 지정됩니다.

중요

노드 포트를 사용하려면 추가 포트 리소스가 필요합니다.

NodePort는 서비스를 노드 IP 주소의 정적 포트에 노출합니다. NodePort는 기본적으로 30000~32767 범위에 있으며, 서비스에서 의도한 포트와 NodePort가 일치하지 않을 수 있습니다. 예를 들어, 포트 8080은 노드에서 포트 31020으로 노출될 수 있습니다.

관리자는 외부 IP 주소가 노드로 라우팅되는지 확인해야 합니다.

NodePort 및 외부 IP는 독립적이며 둘 다 동시에 사용할 수 있습니다.

참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

28.8.2. 사전 요구 사항

다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

  • 요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
  • 클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user cluster-admin <user_name>
    Copy to Clipboard Toggle word wrap
  • 클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

28.8.3. 프로젝트 및 서비스 생성

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트 및 서비스가 이미 존재하는 경우 서비스 노출 절차로 건너뛰어 경로를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치하고 클러스터 관리자로 로그인합니다.

절차

  1. oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 생성합니다.

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap
  2. oc new-app 명령을 사용하여 서비스를 생성합니다.

    $ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
    Copy to Clipboard Toggle word wrap
  3. 서비스가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get svc -n <project_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    nodejs-ex   ClusterIP   172.30.197.157   <none>        8080/TCP   70s
    Copy to Clipboard Toggle word wrap

    참고

    기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

28.8.4. 경로를 생성하여 서비스 노출

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에 로그인되어 있습니다.

절차

  1. 노출하려는 서비스가 있는 프로젝트에 로그인합니다.

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap
  2. 애플리케이션의 노드 포트를 노출하려면 다음 명령을 입력하여 서비스의 CRD(사용자 정의 리소스 정의)를 수정합니다.

    $ oc edit svc <service_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    spec:
      ports:
      - name: 8443-tcp
        nodePort: 30327 
    1
    
        port: 8443
        protocol: TCP
        targetPort: 8443
      sessionAffinity: None
      type: NodePort 
    2
    Copy to Clipboard Toggle word wrap

    1
    선택 사항: 애플리케이션의 노드 포트 범위를 지정합니다. 기본적으로 OpenShift Container Platform은 30000-32767 범위에서 사용 가능한 포트를 선택합니다.
    2
    서비스 유형을 정의합니다.
  3. 선택 사항: 노드 포트가 노출된 상태로 서비스를 사용할 수 있는지 확인하려면 다음 명령을 입력합니다.

    $ oc get svc -n myproject
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    nodejs-ex           ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
    nodejs-ex-ingress   NodePort    172.30.107.72    <none>        3306:31345/TCP   39s
    Copy to Clipboard Toggle word wrap

  4. 선택 사항: oc new-app 명령에서 자동 생성한 서비스를 제거하려면 다음 명령을 입력합니다.

    $ oc delete svc nodejs-ex
    Copy to Clipboard Toggle word wrap

검증

  • 30000-32767 범위의 포트로 서비스 노드 포트가 업데이트되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get svc
    Copy to Clipboard Toggle word wrap

    다음 예제 출력에서 업데이트된 포트는 30327 입니다.

    출력 예

    NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
    httpd   NodePort   172.xx.xx.xx    <none>        8443:30327/TCP   109s
    Copy to Clipboard Toggle word wrap

IngressController 의 IP 주소 범위 목록을 지정할 수 있습니다. 이렇게 하면 endpointPublishingStrategyLoadBalancerService 인 경우 로드 밸런서 서비스에 대한 액세스가 제한됩니다.

28.9.1. 로드 밸런서 허용 소스 범위 구성

spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges 필드를 활성화하고 구성할 수 있습니다. 로드 밸런서 허용 소스 범위를 구성하면 Ingress 컨트롤러의 로드 밸런서에 대한 액세스를 지정된 IP 주소 범위 목록으로 제한할 수 있습니다. Ingress Operator는 로드 밸런서 서비스를 조정하고 AllowedSourceRanges 를 기반으로 spec.loadBalancerSourceRanges 필드를 설정합니다.

참고

이전 버전의 OpenShift Container Platform에서 spec.loadBalancerSourceRanges 필드 또는 로드 밸런서 서비스 주석 service.beta.kubernetes.io/load-balancer-source-ranges 를 이미 설정한 경우 Ingress 컨트롤러는 업그레이드 후 Progressing=True 보고를 시작합니다. 이 문제를 해결하려면 spec.loadBalancerSourceRanges 필드를 덮어쓰는 AllowedSourceRanges 를 설정하고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 지웁니다. Ingress 컨트롤러가 Progressing=False 보고를 다시 시작합니다.

사전 요구 사항

  • 실행 중인 클러스터에 배포된 Ingress 컨트롤러가 있어야 합니다.

절차

  • 다음 명령을 실행하여 Ingress 컨트롤러에 허용되는 소스 범위 API를 설정합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"type":"LoadBalancerService", "loadbalancer": \
        {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    예제 값 0.0.0.0/0 은 허용되는 소스 범위를 지정합니다.

28.9.2. 로드 밸런서 허용 소스 범위로 마이그레이션

service.beta.kubernetes.io/load-balancer-source-ranges 주석을 이미 설정한 경우 로드 밸런서 허용 소스 범위로 마이그레이션할 수 있습니다. AllowedSourceRanges 를 설정하면 Ingress 컨트롤러는 AllowedSourceRanges 값을 기반으로 spec.loadBalancerSourceRanges 필드를 설정하고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 설정합니다.

참고

이전 버전의 OpenShift Container Platform에서 spec.loadBalancerSourceRanges 필드 또는 로드 밸런서 서비스 주석 service.beta.kubernetes.io/load-balancer-source-ranges 를 이미 설정한 경우 Ingress 컨트롤러는 업그레이드 후 Progressing=True 보고를 시작합니다. 이 문제를 해결하려면 spec.loadBalancerSourceRanges 필드를 덮어쓰는 AllowedSourceRanges 를 설정하고 service.beta.kubernetes.io/load-balancer-source-ranges 주석을 지웁니다. Ingress 컨트롤러는 Progressing=False 보고를 다시 시작합니다.

사전 요구 사항

  • service.beta.kubernetes.io/load-balancer-source-ranges 주석을 설정해야 합니다.

절차

  1. service.beta.kubernetes.io/load-balancer-source-ranges 가 설정되어 있는지 확인합니다.

    $ oc get svc router-default -n openshift-ingress -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32
    Copy to Clipboard Toggle word wrap

  2. spec.loadBalancerSourceRanges 필드가 설정되지 않았는지 확인합니다.

    $ oc get svc router-default -n openshift-ingress -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    spec:
      loadBalancerSourceRanges:
      - 0.0.0.0/0
    ...
    Copy to Clipboard Toggle word wrap

  3. 클러스터를 OpenShift Container Platform 4.13으로 업데이트합니다.
  4. 다음 명령을 실행하여 ingresscontroller 에 허용되는 소스 범위 API를 설정합니다.

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    예제 값 0.0.0.0/0 은 허용되는 소스 범위를 지정합니다.

29장. Kubernetes NMState

29.1. Kubernetes NMState Operator 정보

Kubernetes NMState Operator는 OpenShift Container Platform 클러스터 노드에서 NMState를 사용하여 상태 중심 네트워크 구성을 수행하는 데 필요한 Kubernetes API를 제공합니다. Kubernetes NMState Operator는 사용자에게 클러스터 노드에서 다양한 네트워크 인터페이스 유형, DNS 및 라우팅을 구성하는 기능을 제공합니다. 또한 클러스터 노드의 데몬은 각 노드의 네트워크 인터페이스 상태를 API 서버에 정기적으로 보고합니다.

중요

Red Hat은 베어 메탈, IBM Power, IBM Z, IBM® LinuxONE, VMware vSphere 및 OpenStack 설치의 프로덕션 환경에서 Kubernetes NMState Operator를 지원합니다.

OpenShift Container Platform과 함께 NMState를 사용하기 전에 Kubernetes NMState Operator를 설치해야 합니다.

참고

Kubernetes NMState Operator는 보조 NIC의 네트워크 구성을 업데이트합니다. 기본 NIC 또는 br-ex 브리지의 네트워크 구성을 업데이트할 수 없습니다.

OpenShift Container Platform에서는 nmstate를 사용하여 노드 네트워크의 상태를 보고하고 구성합니다. 이렇게 하면 단일 구성 매니페스트를 클러스터에 적용하여 모든 노드에서 Linux 브리지를 생성하는 등의 네트워크 정책 구성을 수정할 수 있습니다.

노드 네트워킹은 다음 오브젝트에서 모니터링하고 업데이트합니다.

NodeNetworkState
해당 노드의 네트워크 상태를 보고합니다.
NodeNetworkConfigurationPolicy
노드에서 요청된 네트워크 구성을 설명합니다. NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하는 방식으로 인터페이스 추가 및 제거를 포함하여 노드 네트워크 구성을 업데이트합니다.
NodeNetworkConfigurationEnactment
각 노드에 적용된 네트워크 정책을 보고합니다.

29.1.1. Kubernetes NMState Operator 설치

웹 콘솔 또는 CLI를 사용하여 Kubernetes NMState Operator를 설치할 수 있습니다.

29.1.1.1. 웹 콘솔을 사용하여 Kubernetes NMState Operator 설치

웹 콘솔을 사용하여 Kubernetes NMState Operator를 설치할 수 있습니다. Operator가 설치되면 NMState State Controller를 모든 클러스터 노드에 데몬 세트로 배포할 수 있습니다.

사전 요구 사항

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

절차

  1. OperatorsOperatorHub를 선택합니다.
  2. 모든 항목 아래의 검색 필드에 nmstate를 입력하고 Enter를 클릭하여 Kubernetes NMState Operator를 검색합니다.
  3. Kubernetes NMState Operator 검색 결과를 클릭합니다.
  4. 설치를 클릭하여 Operator 설치 창을 엽니다.
  5. 설치를 클릭하여 Operator를 설치합니다.
  6. Operator 설치가 완료되면 Operator 보기를 클릭합니다.
  7. 제공된 API 아래에서 인스턴스 생성을 클릭하여 kubernetes-nmstate의 인스턴스 생성을 위해 대화 상자를 엽니다.
  8. 대화 상자의 이름 필드에서 인스턴스 이름이 nmstate인지 확인합니다.

    참고

    이름 제한은 알려진 문제입니다. 인스턴스는 전체 클러스터에 대한 단일 생성입니다.

  9. 기본 설정을 수락하고 만들기를 클릭하여 인스턴스를 만듭니다.

요약

완료되면 Operator가 NMState State Controller를 모든 클러스터 노드에 데몬 세트로 배포했습니다.

29.1.1.2. CLI를 사용하여 Kubernetes NMState Operator 설치

OpenShift CLI(oc) 를 사용하여 Kubernetes NMState Operator를 설치할 수 있습니다. Operator가 설치되면 NMState State Controller를 모든 클러스터 노드에 데몬 세트로 배포할 수 있습니다.

사전 요구 사항

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

절차

  1. nmstate Operator 네임스페이스를 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-nmstate
    spec:
      finalizers:
      - kubernetes
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup 을 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-nmstate
      namespace: openshift-nmstate
    spec:
      targetNamespaces:
      - openshift-nmstate
    EOF
    Copy to Clipboard Toggle word wrap
  3. nmstate Operator에 가입합니다.

    $ cat << EOF| oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: kubernetes-nmstate-operator
      namespace: openshift-nmstate
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: kubernetes-nmstate-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap
  4. nmstate Operator의 인스턴스를 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: nmstate.io/v1
    kind: NMState
    metadata:
      name: nmstate
    EOF
    Copy to Clipboard Toggle word wrap

검증

  • nmstate Operator에 대한 배포가 실행 중인지 확인합니다.

    oc get clusterserviceversion -n openshift-nmstate \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    출력 예

    Name                                             Phase
    kubernetes-nmstate-operator.4.13.0-202210210157   Succeeded
    Copy to Clipboard Toggle word wrap

29.2. 노드 네트워크 상태 및 구성 모니터링 및 업데이트

29.2.1. 노드의 네트워크 상태 보기

노드 네트워크 상태는 클러스터의 모든 노드에 대한 네트워크 구성입니다. NodeNetworkState 오브젝트는 클러스터의 모든 노드에 존재합니다. 이 오브젝트는 주기적으로 업데이트되며 해당 노드의 네트워크 상태를 캡처합니다.

절차

  1. 클러스터의 모든 NodeNetworkState 오브젝트를 나열합니다.

    $ oc get nns
    Copy to Clipboard Toggle word wrap
  2. NodeNetworkState 오브젝트를 검사하여 해당 노드의 네트워크를 확인합니다. 이 예제의 출력은 명확성을 위해 수정되었습니다.

    $ oc get nns node01 -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: nmstate.io/v1
    kind: NodeNetworkState
    metadata:
      name: node01 
    1
    
    status:
      currentState: 
    2
    
        dns-resolver:
    # ...
        interfaces:
    # ...
        route-rules:
    # ...
        routes:
    # ...
      lastSuccessfulUpdateTime: "2020-01-31T12:14:00Z" 
    3
    Copy to Clipboard Toggle word wrap

    1
    NodeNetworkState 오브젝트의 이름은 노드에서 가져옵니다.
    2
    currentState에는 DNS, 인터페이스, 경로를 포함하여 노드에 대한 전체 네트워크 구성이 포함됩니다.
    3
    마지막으로 성공한 업데이트의 타임 스탬프 노드에 연결할 수 있는 동안 주기적으로 업데이트되고 보고서의 최신 상태를 평가하는 데 사용됩니다.

29.2.2. CLI를 사용하여 정책 관리

29.2.2.1. 노드에서 인터페이스 만들기

NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 클러스터의 노드에서 인터페이스를 만듭니다. 매니페스트는 요청된 인터페이스 구성을 자세히 설명합니다.

기본적으로 매니페스트는 클러스터의 모든 노드에 적용됩니다. 특정 노드에 인터페이스를 추가하려면 spec: nodeSelector 매개변수와 노드 선택기에 적합한 <key>:<value>를 추가합니다.

여러 nmstate 지원 노드를 동시에 구성할 수 있습니다. 구성은 노드의 50%에 병렬로 적용됩니다. 이 전략에서는 네트워크 연결에 실패할 경우 전체 클러스터를 사용할 수 없습니다. 클러스터의 특정 부분에 병렬로 정책 구성을 적용하려면 maxUnavailable 필드를 사용합니다.

절차

  1. NodeNetworkConfigurationPolicy 매니페스트를 생성합니다. 다음 예제는 모든 작업자 노드에서 Linux 브리지를 구성하고 DNS 확인자를 구성합니다.

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: br1-eth1-policy 
    1
    
    spec:
      nodeSelector: 
    2
    
        node-role.kubernetes.io/worker: "" 
    3
    
      maxUnavailable: 3 
    4
    
      desiredState:
        interfaces:
          - name: br1
            description: Linux bridge with eth1 as a port 
    5
    
            type: linux-bridge
            state: up
            ipv4:
              dhcp: true
              enabled: true
              auto-dns: false
            bridge:
              options:
                stp:
                  enabled: false
              port:
                - name: eth1
        dns-resolver: 
    6
    
          config:
            search:
            - example.com
            - example.org
            server:
            - 8.8.8.8
    Copy to Clipboard Toggle word wrap
    1
    정책 이름입니다.
    2
    선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
    3
    이 예제에서는 node-role.kubernetes.io/worker: "" 노드 선택기를 사용하여 클러스터의 모든 작업자 노드를 선택합니다.
    4
    선택 사항: 정책 구성을 동시에 적용할 수 있는 최대 nmstate 지원 노드 수를 지정합니다. 이 매개변수는 백분율 값(문자열), 예를 들어 "10%" 또는 절대 값(예: 3 )으로 설정할 수 있습니다.
    5
    선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
    6
    선택 사항: DNS 서버의 검색 및 서버 설정을 지정합니다.
  2. 노드 네트워크 정책을 생성합니다.

    $ oc apply -f br1-eth1-policy.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    노드 네트워크 구성 정책 매니페스트의 파일 이름입니다.
추가 리소스

29.2.3. 노드에 노드 네트워크 정책 업데이트 확인

NodeNetworkConfigurationPolicy 매니페스트는 클러스터의 노드에 대해 요청된 네트워크 구성을 설명합니다. 노드 네트워크 정책에는 요청된 네트워크 구성과 클러스터 전체에 대한 정책 실행 상태가 포함됩니다.

노드 네트워크 정책을 적용하면 클러스터의 모든 노드에 대해 NodeNetworkConfigurationEnactment 오브젝트가 생성됩니다. 노드 네트워크 구성 시행은 해당 노드에서 정책의 실행 상태를 나타내는 읽기 전용 오브젝트입니다. 정책이 노드에 적용되지 않으면 문제 해결을 위해 해당 노드에 대한 시행에 역추적이 포함됩니다.

절차

  1. 정책이 클러스터에 적용되었는지 확인하려면 정책과 해당 상태를 나열합니다.

    $ oc get nncp
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 정책을 구성하는 데 예상보다 오래 걸리는 경우 특정 정책의 요청된 상태 및 상태 조건을 검사할 수 있습니다.

    $ oc get nncp <policy> -o yaml
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 모든 노드에서 정책을 구성하는 데 예상보다 오래 걸리는 경우 클러스터의 시행 상태를 나열할 수 있습니다.

    $ oc get nnce
    Copy to Clipboard Toggle word wrap
  4. 선택 사항: 구성 실패에 대한 오류 보고를 포함하여 특정 시행의 구성을 확인하려면 다음 명령을 실행하십시오.

    $ oc get nnce <node>.<policy> -o yaml
    Copy to Clipboard Toggle word wrap

29.2.4. 노드에서 인터페이스 제거

NodeNetworkConfigurationPolicy 오브젝트를 편집하고 인터페이스의 state없음으로 설정하여 클러스터의 1개 이상의 노드에서 인터페이스를 제거할 수 있습니다.

노드에서 인터페이스를 제거해도 노드 네트워크 구성이 이전 상태로 자동 복원되지 않습니다. 이전 상태를 복원하려면 정책에서 노드 네트워크 구성을 정의해야 합니다.

브리지 또는 본딩 인터페이스를 제거하면 이전에 해당 브릿지 또는 본딩 인터페이스에 연결되었거나 종속되었던 클러스터의 모든 노드 NIC가 down 상태가 되어 연결할 수 없습니다. 연결 손실을 방지하기 위해, 노드 NIC를 동일한 정책으로 구성하여 DHCP 또는 고정 IP 주소의 상태를 up으로 구성합니다.

참고

인터페이스를 추가한 노드 네트워크 정책을 삭제해도 노드의 정책 구성은 변경되지 않습니다. NodeNetworkConfigurationPolicy는 클러스터의 오브젝트이지만 요청된 구성만 나타냅니다.
마찬가지로 인터페이스를 제거해도 정책은 삭제되지 않습니다.

절차

  1. 인터페이스를 생성하는 데 사용되는 NodeNetworkConfigurationPolicy 매니페스트를 업데이트합니다. 다음 예에서는 Linux 브릿지를 제거한 후 연결이 손실되지 않도록 DHCP로 eth1 NIC를 구성합니다.

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: <br1-eth1-policy> 
    1
    
    spec:
      nodeSelector: 
    2
    
        node-role.kubernetes.io/worker: "" 
    3
    
      desiredState:
        interfaces:
        - name: br1
          type: linux-bridge
          state: absent 
    4
    
        - name: eth1 
    5
    
          type: ethernet 
    6
    
          state: up 
    7
    
          ipv4:
            dhcp: true 
    8
    
            enabled: true 
    9
    Copy to Clipboard Toggle word wrap
    1
    정책 이름입니다.
    2
    선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
    3
    이 예제에서는 node-role.kubernetes.io/worker: "" 노드 선택기를 사용하여 클러스터의 모든 작업자 노드를 선택합니다.
    4
    absent 상태로 변경하면 인터페이스가 제거됩니다.
    5
    브리지 인터페이스에서 연결을 해제할 인터페이스의 이름입니다.
    6
    인터페이스 유형입니다. 이 예제에서는 이더넷 네트워킹 인터페이스를 생성합니다.
    7
    인터페이스에 요청되는 상태입니다.
    8
    선택 사항: dhcp를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다.
    9
    이 예제에서 ipv4를 활성화합니다.
  2. 노드에서 정책을 업데이트하고 인터페이스를 제거합니다.

    $ oc apply -f <br1-eth1-policy.yaml> 
    1
    Copy to Clipboard Toggle word wrap
    1
    정책 매니페스트의 파일 이름입니다.

29.2.5. 다양한 인터페이스에 대한 예제 정책 구성

다른 예제 NodeNetworkConfigurationPolicy (NNCP) 매니페스트 구성을 읽기 전에 클러스터가 최상의 성능 조건에서 실행되도록 정책을 적용할 때 다음 요인을 고려하십시오.

  • 둘 이상의 노드에 정책을 적용해야 하는 경우 각 대상 노드에 대한 NodeNetworkConfigurationPolicy 매니페스트를 생성합니다. Kubernetes NMState Operator는 지정되지 않은 순서로 NNCP를 사용하여 각 노드에 정책을 적용합니다. 이 방법을 사용하여 정책 범위를 지정하면 정책 애플리케이션의 기간이 단축되지만 클러스터 구성에 오류가 있는 경우 클러스터 전체에서 중단될 위험이 있습니다. 이러한 유형의 오류를 방지하려면 처음에 NNCP를 일부 노드에 적용하고 올바르게 구성한 후 나머지 노드에 정책 적용을 진행합니다.
  • 여러 노드에 정책을 적용해야 하지만 모든 대상 노드에 대해 단일 NNCP만 생성하려는 경우 Kubernetes NMState Operator는 정책을 각 노드에 순서대로 적용합니다. 클러스터 구성에서 maxUnavailable 매개변수를 사용하여 대상 노드의 정책 애플리케이션 속도 및 범위를 설정할 수 있습니다. 매개변수의 백분율 낮은 값을 설정하면 중단이 정책 애플리케이션을 수신하는 노드의 소수에 영향을 미치는 경우 클러스터 전체 중단 위험을 줄일 수 있습니다.
  • 단일 정책에서 관련 네트워크 구성을 모두 지정하는 것이 좋습니다.
  • 노드가 다시 시작되면 Kubernetes NMState Operator는 노드에 정책을 적용하는 순서를 제어할 수 없습니다. Kubernetes NMState Operator는 성능이 저하된 네트워크 오브젝트를 생성하는 순서대로 상호 종속적인 정책을 적용할 수 있습니다.
29.2.5.1. 예: Linux 브리지 인터페이스 노드 네트워크 구성 정책

NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 클러스터의 노드에서 Linux 브리지 인터페이스를 만듭니다.

다음 YAML 파일은 Linux 브리지 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
      - name: br1 
4

        description: Linux bridge with eth1 as a port 
5

        type: linux-bridge 
6

        state: up 
7

        ipv4:
          dhcp: true 
8

          enabled: true 
9

        bridge:
          options:
            stp:
              enabled: false 
10

          port:
            - name: eth1 
11
Copy to Clipboard Toggle word wrap
1
정책 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
3
이 예제에서는 hostname 노드 선택기를 사용합니다.
4
인터페이스 이름입니다.
5
선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
6
인터페이스 유형입니다. 이 예제에서는 브리지를 만듭니다.
7
생성 후 인터페이스에 요청되는 상태입니다.
8
선택 사항: dhcp를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다.
9
이 예제에서 ipv4를 활성화합니다.
10
이 예제에서 stp를 비활성화합니다.
11
브리지가 연결되는 노드 NIC입니다.
29.2.5.2. 예제: VLAN 인터페이스 노드 네트워크 구성 정책

NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 클러스터의 노드에서 VLAN 인터페이스를 만듭니다.

참고

단일 NodeNetworkConfigurationPolicy 매니페스트에서 노드의 VLAN 인터페이스에 대한 모든 관련 구성을 정의합니다. 예를 들어 노드의 VLAN 인터페이스와 동일한 NodeNetworkConfigurationPolicy 매니페스트에서 VLAN 인터페이스에 대한 관련 경로를 정의합니다.

노드가 다시 시작되면 Kubernetes NMState Operator는 정책이 적용되는 순서를 제어할 수 없습니다. 따라서 관련 네트워크 구성에 별도의 정책을 사용하는 경우 Kubernetes NMState Operator에서 이러한 정책을 순서대로 적용하여 저하된 네트워크 오브젝트를 만들 수 있습니다.

다음 YAML 파일은 VLAN 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vlan-eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: eth1.102 
4

      description: VLAN using eth1 
5

      type: vlan 
6

      state: up 
7

      vlan:
        base-iface: eth1 
8

        id: 102 
9
Copy to Clipboard Toggle word wrap
1
정책 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
3
이 예제에서는 hostname 노드 선택기를 사용합니다.
4
인터페이스 이름입니다. 베어 메탈에 배포하는 경우 < interface_name>.<vlan_number > VLAN 형식만 지원됩니다.
5
선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
6
인터페이스 유형입니다. 이 예제에서는 VLAN을 만듭니다.
7
생성 후 인터페이스에 요청되는 상태입니다.
8
VLAN이 연결되는 노드 NIC입니다.
9
VLAN 태그입니다.
29.2.5.3. 예제: 본딩 인터페이스 노드 네트워크 구성 정책

NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 클러스터의 노드에서 본딩 인터페이스를 만듭니다.

참고

OpenShift Container Platform에서는 다음과 같은 본딩 모드만 지원합니다.

  • mode=1 active-backup
  • mode=2 balance-xor
  • mode=4 802.3ad

다른 본딩 모드는 지원되지 않습니다.

다음 YAML 파일은 본딩 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: bond0-eth1-eth2-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: bond0 
4

      description: Bond with ports eth1 and eth2 
5

      type: bond 
6

      state: up 
7

      ipv4:
        dhcp: true 
8

        enabled: true 
9

      link-aggregation:
        mode: active-backup 
10

        options:
          miimon: '140' 
11

        port: 
12

        - eth1
        - eth2
      mtu: 1450 
13
Copy to Clipboard Toggle word wrap
1
정책 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
3
이 예제에서는 hostname 노드 선택기를 사용합니다.
4
인터페이스 이름입니다.
5
선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
6
인터페이스 유형입니다. 이 예제에서는 본딩을 생성합니다.
7
생성 후 인터페이스에 요청되는 상태입니다.
8
선택 사항: dhcp를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다.
9
이 예제에서 ipv4를 활성화합니다.
10
본딩의 드라이버 모드입니다. 이 예제에서는 활성 백업 모드를 사용합니다.
11
선택 사항: 이 예제에서는 miimon을 사용하여 140ms마다 본딩 링크를 검사합니다.
12
본딩의 하위 노드 NIC입니다.
13
선택 사항: 본딩의 MTU(최대 전송 단위)입니다. 지정하지 않는 경우 이 값은 기본적으로 1500으로 설정됩니다.
29.2.5.4. 예제: 이더넷 인터페이스 노드 네트워크 구성 정책

NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 클러스터의 노드에서 이더넷 인터페이스를 구성합니다.

다음 YAML 파일은 이더넷 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: eth1 
4

      description: Configuring eth1 on node01 
5

      type: ethernet 
6

      state: up 
7

      ipv4:
        dhcp: true 
8

        enabled: true 
9
Copy to Clipboard Toggle word wrap
1
정책 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
3
이 예제에서는 hostname 노드 선택기를 사용합니다.
4
인터페이스 이름입니다.
5
선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
6
인터페이스 유형입니다. 이 예제에서는 이더넷 네트워킹 인터페이스를 생성합니다.
7
생성 후 인터페이스에 요청되는 상태입니다.
8
선택 사항: dhcp를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다.
9
이 예제에서 ipv4를 활성화합니다.
29.2.5.5. 예제: 노드 네트워크 구성 정책이 동일한 여러 인터페이스

동일한 노드 네트워크 구성 정책으로 여러 개의 인터페이스를 생성할 수 있습니다. 이러한 인터페이스는 서로를 참조할 수 있으므로 단일 정책 매니페스트를 사용하여 네트워크 구성을 빌드하고 배포할 수 있습니다.

다음 예제 YAML 파일은 본딩에 연결하는 bond10.103 이라는 두 NIC와 VLAN에서 이름이 bond10 인 본딩을 생성합니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: bond-vlan 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: bond10 
4

      description: Bonding eth2 and eth3 
5

      type: bond 
6

      state: up 
7

      link-aggregation:
        mode: balance-xor 
8

        options:
          miimon: '140' 
9

        port: 
10

        - eth2
        - eth3
    - name: bond10.103 
11

      description: vlan using bond10 
12

      type: vlan 
13

      state: up 
14

      vlan:
         base-iface: bond10 
15

         id: 103 
16

      ipv4:
        dhcp: true 
17

        enabled: true 
18
Copy to Clipboard Toggle word wrap
1
정책 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다.
3
이 예에서는 호스트 이름 노드 선택기를 사용합니다.
4 11
인터페이스 이름입니다.
5 12
선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
6 13
인터페이스 유형입니다.
7 14
생성 후 인터페이스에 요청되는 상태입니다.
8
본딩의 드라이버 모드입니다.
9
선택 사항: 이 예제에서는 miimon을 사용하여 140ms마다 본딩 링크를 검사합니다.
10
본딩의 하위 노드 NIC입니다.
15
VLAN이 연결되는 노드 NIC입니다.
16
VLAN 태그입니다.
17
선택 사항: dhcp를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다.
18
이 예제에서 ipv4를 활성화합니다.

29.2.6. 브리지에 연결된 NIC의 고정 IP 캡처

중요

NIC의 고정 IP를 캡처하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

클러스터의 노드에서 Linux 브리지 인터페이스를 생성하고 단일 NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하여 NIC의 고정 IP 구성을 브리지로 전송합니다.

다음 YAML 파일은 Linux 브리지 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-eth1-copy-ipv4-policy 
1

spec:
  nodeSelector: 
2

    node-role.kubernetes.io/worker: ""
  capture:
    eth1-nic: interfaces.name=="eth1" 
3

    eth1-routes: routes.running.next-hop-interface=="eth1"
    br1-routes: capture.eth1-routes | routes.running.next-hop-interface := "br1"
  desiredState:
    interfaces:
      - name: br1
        description: Linux bridge with eth1 as a port
        type: linux-bridge 
4

        state: up
        ipv4: "{{ capture.eth1-nic.interfaces.0.ipv4 }}" 
5

        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: eth1 
6

     routes:
        config: "{{ capture.br1-routes.routes.running }}"
Copy to Clipboard Toggle word wrap
1
정책의 이름입니다.
2
선택 사항: nodeSelector 매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다. 이 예제에서는 node-role.kubernetes.io/worker: "" 노드 선택기를 사용하여 클러스터의 모든 작업자 노드를 선택합니다.
3
브리지가 연결되는 노드 NIC에 대한 참조입니다.
4
인터페이스 유형입니다. 이 예제에서는 브리지를 만듭니다.
5
브리지 인터페이스의 IP 주소입니다. 이 값은 spec.capture.eth1-nic 항목에서 참조하는 NIC의 IP 주소와 일치합니다.
6
브리지가 연결되는 노드 NIC입니다.

29.2.7. 예제: IP 관리

다음 예제 구성 스니펫에서는 다양한 IP 관리 방법을 보여줍니다.

이 예제에서는 ethernet 인터페이스 유형을 사용하여 예제를 단순화하면서 정책 구성에 관련 컨텍스트를 표시합니다. 이러한 IP 관리 예제는 다른 인터페이스 유형과 함께 사용할 수 있습니다.

29.2.7.1. 고정

다음 스니펫은 이더넷 인터페이스에서 IP 주소를 정적으로 구성합니다.

# ...
    interfaces:
    - name: eth1
      description: static IP on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: false
        address:
        - ip: 192.168.122.250 
1

          prefix-length: 24
        enabled: true
# ...
Copy to Clipboard Toggle word wrap
1
이 값을 인터페이스의 고정 IP 주소로 교체합니다.
29.2.7.2. IP 주소 없음

다음 스니펫에서는 인터페이스에 IP 주소가 없습니다.

# ...
    interfaces:
    - name: eth1
      description: No IP on eth1
      type: ethernet
      state: up
      ipv4:
        enabled: false
# ...
Copy to Clipboard Toggle word wrap
29.2.7.3. 동적 호스트 구성

다음 스니펫에서는 동적 IP 주소, 게이트웨이 주소, DNS를 사용하는 이더넷 인터페이스를 구성합니다.

# ...
    interfaces:
    - name: eth1
      description: DHCP on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        enabled: true
# ...
Copy to Clipboard Toggle word wrap

다음 스니펫에서는 동적 IP 주소를 사용하지만 동적 게이트웨이 주소 또는 DNS를 사용하지 않는 이더넷 인터페이스를 구성합니다.

# ...
    interfaces:
    - name: eth1
      description: DHCP without gateway or DNS on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        auto-gateway: false
        auto-dns: false
        enabled: true
# ...
Copy to Clipboard Toggle word wrap
29.2.7.4. DNS

기본적으로 nmstate API는 네트워크 인터페이스에 저장하는 대신 전역적으로 DNS 값을 저장합니다. 특정 상황에서는 DNS 값을 저장하도록 네트워크 인터페이스를 구성해야 합니다. 네트워크 인터페이스에 대한 DNS 구성을 정의하려면 처음에 네트워크 인터페이스의 YAML 구성 파일에서 dns-resolver 섹션을 지정해야 합니다.

작은 정보

DNS 구성을 설정하는 것은 /etc/resolv.conf 파일을 수정하는 것과 동일합니다.

중요

DNS 확인자를 구성할 때 OVNKubernetes 관리 Open vSwitch 브리지인 br-ex 브리지를 인터페이스로 사용할 수 없습니다.

다음 예제에서는 DNS 값을 전역적으로 저장하는 기본 상황을 보여줍니다.

  • 네트워크 인터페이스 없이 정적 DNS를 구성합니다. 호스트 노드에서 /etc/resolv.conf 파일을 업데이트할 때 NodeNetworkConfigurationPolicy (NNCP) 매니페스트에 인터페이스 IPv4 또는 IPv6를 지정할 필요가 없습니다.

    전역적으로 DNS 값을 저장하는 네트워크 인터페이스의 DNS 구성 예

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
     name: worker-0-dns-testing
    spec:
      nodeSelector:
        kubernetes.io/hostname: <target_node>
      desiredState:
        dns-resolver:
          config:
            search:
            - example.com
            - example.org
            server:
            - 2001:db8:f::1
            - 192.0.2.251
    # ...
    Copy to Clipboard Toggle word wrap

다음 예제에서는 DNS 값을 저장하기 위해 네트워크 인터페이스를 구성해야 하는 상황을 보여줍니다.

  • 동적 DNS 이름 서버를 통해 정적 DNS 이름 서버의 순위를 지정하려면 네트워크 인터페이스 YAML 구성 파일에서 DHCP(Dynamic Host Configuration Protocol) 또는 IPv6 자동 구성(autoconf) 메커니즘을 실행하는 인터페이스를 정의합니다.

    DHCPv4 네트워크 프로토콜에서 검색된 DNS 이름 서버에 192.0.2.1 을 추가하는 구성 예

    # ...
    dns-resolver:
      config:
        server:
        - 192.0.2.1
    interfaces:
      - name: eth1
        type: ethernet
        state: up
        ipv4:
          enabled: true
          dhcp: true
          auto-dns: true
    # ...
    Copy to Clipboard Toggle word wrap

  • nmstate API를 사용하여 DNS 값을 전역적으로 저장하는 기본 방법을 채택하는 대신 네트워크 인터페이스를 구성해야 하는 경우 정적 DNS 값과 고정 IP 주소를 네트워크 인터페이스 YAML 파일에 설정할 수 있습니다.

    중요

    네트워크 인터페이스 수준에 DNS 값을 저장하면 인터페이스를 OVS(Open vSwitch) 브리지, Linux 브리지 또는 본딩과 같은 네트워크 구성 요소에 연결한 후 이름 확인 문제가 발생할 수 있습니다.

    인터페이스 수준에서 DNS 값을 저장하는 구성 예

    # ...
    dns-resolver:
      config:
        search:
        - example.com
        - example.org
        server:
        - 2001:db8:1::d1
        - 2001:db8:1::d2
        - 192.0.2.1
    interfaces:
      - name: eth1
        type: ethernet
        state: up
        ipv4:
          address:
          - ip: 192.0.2.251
            prefix-length: 24
          dhcp: false
          enabled: true
        ipv6:
          address:
          - ip: 2001:db8:1::1
            prefix-length: 64
          dhcp: false
          enabled: true
          autoconf: false
    # ...
    Copy to Clipboard Toggle word wrap

  • 네트워크 인터페이스에 정적 DNS 검색 도메인 및 동적 DNS 이름 서버를 설정하려면 DHCP(Dynamic Host Configuration Protocol) 또는 네트워크 인터페이스 YAML 구성 파일에서 IPv6 자동 구성(autoconf) 메커니즘을 실행하는 동적 인터페이스를 정의합니다.

    동적 DNS 이름 서버 설정과 함께 example.comexample.org 정적 DNS 검색 도메인을 설정하는 구성의 예

    # ...
    dns-resolver:
      config:
        search:
        - example.com
        - example.org
        server: []
    interfaces:
      - name: eth1
        type: ethernet
        state: up
        ipv4:
          enabled: true
          dhcp: true
          auto-dns: true
        ipv6:
          enabled: true
          dhcp: true
          autoconf: true
          auto-dns: true
    # ...
    Copy to Clipboard Toggle word wrap

29.2.7.5. 고정 라우팅

다음 스니펫에서는 eth1 인터페이스에 고정 경로와 고정 IP를 구성합니다.

dns-resolver:
  config:
# ...
interfaces:
  - name: eth1
    description: Static routing on eth1
    type: ethernet
    state: up
    ipv4:
      dhcp: false
      enabled: true
      address:
      - ip: 192.0.2.251 
1

        prefix-length: 24
routes:
  config:
  - destination: 198.51.100.0/24
    metric: 150
    next-hop-address: 192.0.2.1 
2

    next-hop-interface: eth1
    table-id: 254
# ...
Copy to Clipboard Toggle word wrap
1
이더넷 인터페이스의 고정 IP 주소입니다.
2
노드 트래픽의 다음 홉 주소입니다. 이더넷 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.

29.3. 노드 네트워크 구성 문제 해결

노드 네트워크 구성에 문제가 발생하면 정책이 자동으로 롤백되고 시행이 실패로 보고됩니다. 여기에는 다음과 같은 문제가 포함됩니다.

  • 호스트에 구성을 적용하지 못했습니다.
  • 호스트와 기본 게이트웨이의 연결이 끊어졌습니다.
  • 호스트와 API 서버의 연결이 끊어졌습니다.

29.3.1. 잘못된 노드 네트워크 구성 정책의 구성 문제 해결

노드 네트워크 구성 정책을 적용하여 전체 클러스터에 노드 네트워크 구성 변경 사항을 적용할 수 있습니다.

잘못된 구성을 적용한 경우 다음 예제를 사용하여 실패한 노드 네트워크 정책의 문제를 해결하고 수정할 수 있습니다. 이 예제에서는 컨트롤 플레인 노드와 컴퓨팅 노드 3개가 있는 클러스터에 Linux 브리지 정책을 적용하려고 합니다. 정책이 잘못된 인터페이스를 참조하므로 정책이 적용되지 않습니다.

오류를 찾으려면 사용 가능한 NMState 리소스를 조사해야 합니다. 그런 다음 올바른 구성으로 정책을 업데이트할 수 있습니다.

사전 요구 사항

  • Linux 시스템에 ens01 인터페이스가 없는지 확인합니다.

절차

  1. 클러스터에 정책을 생성합니다. 다음 예제에서는 멤버로 ens01 이 있는 간단한 브리지 br1 을 생성합니다.

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: ens01-bridge-testfail
    spec:
      desiredState:
        interfaces:
          - name: br1
            description: Linux bridge with the wrong port
            type: linux-bridge
            state: up
            ipv4:
              dhcp: true
              enabled: true
            bridge:
              options:
                stp:
                  enabled: false
              port:
                - name: ens01
    # ...
    Copy to Clipboard Toggle word wrap
  2. 네트워크 인터페이스에 정책을 적용합니다.

    $ oc apply -f ens01-bridge-testfail.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail created
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 정책의 상태를 확인합니다.

    $ oc get nncp
    Copy to Clipboard Toggle word wrap

    출력에 정책이 실패했다는 내용이 표시됩니다.

    출력 예

    NAME                    STATUS
    ens01-bridge-testfail   FailedToConfigure
    Copy to Clipboard Toggle word wrap

    정책 상태만으로는 모든 노드에서 실패했는지 또는 노드의 하위 집합에서 실패했는지를 나타내지 않습니다.

  4. 노드 네트워크 구성 시행을 나열하여 정책이 모든 노드에서 성공적인지 확인합니다. 정책이 노드 서브 세트에서만 실패한 경우 출력에 특정 노드 구성에 문제가 있음을 나타냅니다. 정책이 모든 노드에서 실패하면 출력에 문제가 정책에 있음을 나타냅니다.

    $ oc get nnce
    Copy to Clipboard Toggle word wrap

    출력에 정책이 모든 노드에서 실패했다는 내용이 표시됩니다.

    출력 예

    NAME                                         STATUS
    control-plane-1.ens01-bridge-testfail        FailedToConfigure
    control-plane-2.ens01-bridge-testfail        FailedToConfigure
    control-plane-3.ens01-bridge-testfail        FailedToConfigure
    compute-1.ens01-bridge-testfail              FailedToConfigure
    compute-2.ens01-bridge-testfail              FailedToConfigure
    compute-3.ens01-bridge-testfail              FailedToConfigure
    Copy to Clipboard Toggle word wrap

  5. 실패한 시행 중 하나를 봅니다. 다음 명령은 출력 툴 jsonpath를 사용하여 출력을 필터링합니다.

    $ oc get nnce compute-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'
    Copy to Clipboard Toggle word wrap

    출력 예

    [2024-10-10T08:40:46Z INFO  nmstatectl] Nmstate version: 2.2.37
    NmstateError: InvalidArgument: Controller interface br1 is holding unknown port ens01
    Copy to Clipboard Toggle word wrap

    이전 예제에서는 ens01 이 알 수 없는 포트임을 나타내는 InvalidArgument 오류의 출력을 보여줍니다. 이 예에서는 정책 구성 파일에서 포트 구성을 변경해야 할 수 있습니다.

  6. 정책이 제대로 구성되었는지 확인하기 위해 NodeNetworkState 오브젝트를 요청하여 하나 또는 모든 노드의 네트워크 구성을 확인합니다. 다음 명령에서는 control-plane-1 노드의 네트워크 구성을 반환합니다.

    $ oc get nns control-plane-1 -o yaml
    Copy to Clipboard Toggle word wrap

    출력에 노드의 인터페이스 이름이 ens1인데 실패한 정책에서 ens01로 잘못 사용하고 있다는 내용이 표시됩니다.

    출력 예

       - ipv4:
    # ...
          name: ens1
          state: up
          type: ethernet
    Copy to Clipboard Toggle word wrap

  7. 기존 정책을 편집하여 오류를 수정합니다.

    $ oc edit nncp ens01-bridge-testfail
    Copy to Clipboard Toggle word wrap
    # ...
              port:
                - name: ens1
    Copy to Clipboard Toggle word wrap

    정책을 저장하여 수정 사항을 적용합니다.

  8. 정책 상태를 확인하여 업데이트가 완료되었는지 확인합니다.

    $ oc get nncp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    STATUS
    ens01-bridge-testfail   SuccessfullyConfigured
    Copy to Clipboard Toggle word wrap

    업데이트된 정책이 클러스터의 모든 노드에 성공적으로 구성되었습니다.

29.3.2. 연결이 끊긴 환경에서 DNS 연결 문제 해결

연결이 끊긴 환경에서 nmstate 를 구성할 때 DNS 연결 문제가 발생하는 경우 DNS 서버를 구성하여 도메인 root-servers.net 의 이름 서버 목록을 확인할 수 있습니다.

중요

DNS 서버에 root-servers.net 영역의 이름 서버(NS) 항목이 포함되어 있는지 확인합니다. DNS 서버는 쿼리를 업스트림 리졸버에 전달할 필요가 없지만 서버는 NS 쿼리에 대한 올바른 응답을 반환해야합니다.

29.3.2.1. server라는 bind9 DNS 구성

bind9 DNS 서버를 쿼리하도록 구성된 클러스터의 경우 root-servers.net 영역을 하나 이상의 NS 레코드가 포함된 구성 파일에 추가할 수 있습니다. 예를 들어 /var/named/named.localhost 를 이 기준과 일치하는 영역 파일로 사용할 수 있습니다.

절차

  1. 다음 명령을 실행하여 /etc/named.conf 구성 파일 끝에 root-servers.net 영역을 추가합니다.

    $ cat >> /etc/named.conf <<EOF
    zone "root-servers.net" IN {
        	type master;
        	file "named.localhost";
    };
    EOF
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 named 서비스를 다시 시작합니다.

    $ systemctl restart named
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 root-servers.net 영역이 있는지 확인합니다.

    $ journalctl -u named|grep root-servers.net
    Copy to Clipboard Toggle word wrap

    출력 예

    Jul 03 15:16:26 rhel-8-10 bash[xxxx]: zone root-servers.net/IN: loaded serial 0
    Jul 03 15:16:26 rhel-8-10 named[xxxx]: zone root-servers.net/IN: loaded serial 0
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 DNS 서버에서 root-servers.net 도메인의 NS 레코드를 확인할 수 있는지 확인합니다.

    $ host -t NS root-servers.net. 127.0.0.1
    Copy to Clipboard Toggle word wrap

    출력 예

    Using domain server:
    Name: 127.0.0.1
    Address: 127.0.0.53
    Aliases:
    root-servers.net name server root-servers.net.
    Copy to Clipboard Toggle word wrap

29.3.2.2. dnsmasq DNS 서버 구성

dnsmasq 를 DNS 서버로 사용하는 경우, 사용자가 지정하는 DNS 서버를 사용하여 root-servers.net 을 확인하는 새 구성 파일을 생성하여 root-servers.net 도메인의 확인을 다른 DNS 서버에 위임할 수 있습니다.

  1. 다음 명령을 실행하여 도메인 root-servers.net 을 다른 DNS 서버에 위임하는 구성 파일을 생성합니다.

    $ echo 'server=/root-servers.net/<DNS_server_IP>'> /etc/dnsmasq.d/delegate-root-servers.net.conf
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 dnsmasq 서비스를 다시 시작합니다.

    $ systemctl restart dnsmasq
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 root-servers.net 도메인이 다른 DNS 서버에 위임되었는지 확인합니다.

    $ journalctl -u dnsmasq|grep root-servers.net
    Copy to Clipboard Toggle word wrap

    출력 예

    Jul 03 15:31:25 rhel-8-10 dnsmasq[1342]: using nameserver 192.168.1.1#53 for domain root-servers.net
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 DNS 서버에서 root-servers.net 도메인의 NS 레코드를 확인할 수 있는지 확인합니다.

    $ host -t NS root-servers.net. 127.0.0.1
    Copy to Clipboard Toggle word wrap

    출력 예

    Using domain server:
    Name: 127.0.0.1
    Address: 127.0.0.1#53
    Aliases:
    root-servers.net name server root-servers.net.
    Copy to Clipboard Toggle word wrap

30장. 클러스터 전체 프록시 구성

프로덕션 환경에서는 인터넷에 대한 직접 액세스를 거부하고 대신 HTTP 또는 HTTPS 프록시를 사용할 수 있습니다. 기존 클러스터의 프록시 오브젝트를 수정하거나 새 클러스터의 install-config.yaml 파일에서 프록시 설정을 구성하여 프록시를 사용하도록 OpenShift Container Platform을 구성할 수 있습니다.

30.1. 사전 요구 사항

  • 클러스터에서 액세스해야 하는 사이트를 검토하고 프록시를 바이패스해야 하는지 확인합니다. 클러스터를 호스팅하는 클라우드의 클라우드 공급자 API에 대한 호출을 포함하여 기본적으로 모든 클러스터 시스템 송신 트래픽이 프록시됩니다. 시스템 전반의 프록시는 사용자 워크로드가 아닌 시스템 구성 요소에만 영향을 미칩니다. 필요한 경우 프록시를 바이패스하려면 프록시 오브젝트의 spec.noProxy 필드에 사이트를 추가합니다.

    참고

    프록시 오브젝트 status.noProxy 필드는 대부분의 설치 유형으로 설치 구성의 networking.machineNetwork[].cidr,networking.clusterNetwork[].cidr, networking.serviceNetwork[] 필드의 값으로 채워집니다.

    Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure 및 Red Hat OpenStack Platform (RHOSP)에 설치하는 경우 Proxy 오브젝트 status.noProxy 필드도 인스턴스 메타데이터 끝점(169.254.169.254)로 채워집니다.

    중요

    설치 유형에 networking.machineNetwork[].cidr 필드 설정이 포함되지 않은 경우 노드 간 트래픽이 프록시를 바이패스할 수 있도록 .status.noProxy 필드에 머신 IP 주소를 수동으로 포함해야 합니다.

30.2. 클러스터 전체 프록시 사용

프록시 오브젝트는 클러스터 전체 송신 프록시를 관리하는 데 사용됩니다. 프록시를 구성하지 않고 클러스터를 설치하거나 업그레이드하면 프록시 오브젝트 계속 생성되지만 spec 은 nil이 됩니다. 예를 들면 다음과 같습니다.

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:
Copy to Clipboard Toggle word wrap

클러스터 관리자는 이 cluster Proxy 오브젝트를 수정하여 OpenShift Container Platform의 프록시를 구성할 수 있습니다.

참고

cluster라는 Proxy 오브젝트만 지원되며 추가 프록시는 생성할 수 없습니다.

주의

클러스터 전체 프록시를 활성화하면 MCO(Machine Config Operator)가 노드 재부팅을 트리거합니다.

사전 요구 사항

  • 클러스터 관리자 권한
  • OpenShift Container Platform oc CLI 도구 설치

절차

  1. HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 포함된 구성 맵을 생성합니다.

    참고

    프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명한 경우 이 단계를 건너뛸 수 있습니다.

    1. 다음 내용으로 user-ca-bundle.yaml이라는 파일을 생성하고 PEM 인코딩 인증서 값을 제공합니다.

      apiVersion: v1
      data:
        ca-bundle.crt: | 
      1
      
          <MY_PEM_ENCODED_CERTS> 
      2
      
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 
      3
      
        namespace: openshift-config 
      4
      Copy to Clipboard Toggle word wrap
      1
      이 데이터 키의 이름은 ca-bundle.crt여야 합니다.
      2
      프록시의 ID 인증서 서명에 사용되는 하나 이상의 PEM 인코딩 X.509 인증서입니다.
      3
      프록시 오브젝트에서 참조할 구성 맵 이름입니다.
      4
      구성 맵은 openshift-config 네임스페이스에 있어야 합니다.
    2. 이 파일에서 구성 맵을 생성합니다.

      $ oc create -f user-ca-bundle.yaml
      Copy to Clipboard Toggle word wrap
  2. oc edit 명령을 사용하여 프록시 오브젝트를 수정합니다.

    $ oc edit proxy/cluster
    Copy to Clipboard Toggle word wrap
  3. 프록시에 필요한 필드를 구성합니다.

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: example.com 
    3
    
      readinessEndpoints:
      - http://www.google.com 
    4
    
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 
    5
    Copy to Clipboard Toggle word wrap
    1
    클러스터 외부에서 HTTP 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http여야 합니다.
    2
    클러스터 외부에서 HTTPS 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http 또는 https 여야 합니다. URL 스키마를 지원하는 프록시의 URL을 지정합니다. 예를 들어 대부분의 프록시는 https 를 사용하도록 구성된 경우 오류를 보고하지만 http 만 지원합니다. 이 실패 메시지는 로그에 전파되지 않을 수 있으며 대신 네트워크 연결 실패로 표시될 수 있습니다. 클러스터에서 https 연결을 수신하는 프록시를 사용하는 경우 프록시에서 사용하는 CA 및 인증서를 수락하도록 클러스터를 구성해야 할 수 있습니다.
    3
    대상 도메인 이름, 도메인, IP 주소 또는 프록시를 제외할 기타 네트워크 CIDR로 이루어진 쉼표로 구분된 목록입니다.

    하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.comx.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. networking.machineNetwork[].cidr 필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.

    httpProxyhttpsProxy 필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.

    4
    httpProxyhttpsProxy 값을 상태에 쓰기 전에 준비 검사를 수행하는 데 사용할 하나 이상의 클러스터 외부 URL입니다.
    5
    HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 포함된 openshift-config 네임스페이스의 구성 맵에 대한 참조입니다. 여기서 구성 맵을 참조하기 전에 구성 맵이 이미 있어야 합니다. 프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명하지 않은 경우 이 필드가 있어야 합니다.
  4. 파일을 저장하여 변경 사항을 적용합니다.

30.3. 클러스터 전체 프록시 제거

cluster 프록시 오브젝트는 삭제할 수 없습니다. 클러스터에서 이 프록시를 제거하려면 프록시 오브젝트에서 모든 spec 필드를 제거해야 합니다.

사전 요구 사항

  • 클러스터 관리자 권한
  • OpenShift Container Platform oc CLI 도구 설치

절차

  1. 프록시를 수정하려면 oc edit 명령을 사용합니다.

    $ oc edit proxy/cluster
    Copy to Clipboard Toggle word wrap
  2. 프록시 오브젝트에서 모든 spec 필드를 제거합니다. 예를 들면 다음과 같습니다.

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec: {}
    Copy to Clipboard Toggle word wrap
  3. 파일을 저장하여 변경 사항을 적용합니다.

추가 리소스

31장. 사용자 정의 PKI 구성

웹 콘솔과 같은 일부 플랫폼 구성 요소에서는 통신에 경로를 사용하고, 다른 구성 요소와의 상호 작용을 위해 해당 구성 요소의 인증서를 신뢰해야 합니다. 사용자 정의 PKI(공개 키 인프라)를 사용하는 경우 개인 서명 CA 인증서가 클러스터에서 인식되도록 PKI를 구성해야 합니다.

프록시 API를 활용하면 클러스터 전체에서 신뢰하는 CA 인증서를 추가할 수 있습니다. 이 작업은 설치 중 또는 런타임에 수행해야 합니다.

  • 설치클러스터 전체 프록시를 구성합니다. install-config.yaml 파일의 additionalTrustBundle 설정에 개인 서명 CA 인증서를 정의해야 합니다.

    설치 프로그램에서 사용자가 정의한 추가 CA 인증서가 포함된 user-ca-bundle이라는 ConfigMap을 생성합니다. 그러면 CNO(Cluster Network Operator)에서 이러한 CA 인증서를 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들과 병합하는 trusted-ca-bundle ConfigMap을 생성합니다. 이 ConfigMap은 프록시 오브젝트의 trustedCA 필드에서 참조됩니다.

  • 런타임개인 서명 CA 인증서를 포함하도록 기본 프록시 오브젝트를 수정합니다(클러스터의 프록시 사용 워크플로우의 일부). 이를 위해서는 클러스터에서 신뢰해야 하는 개인 서명 CA 인증서가 포함된 ConfigMap을 생성한 다음 개인 서명 인증서의 ConfigMap을 참조하는 trustedCA를 사용하여 프록시 리소스를 수정해야 합니다.
참고

설치 관리자 구성의 additionalTrustBundle 필드와 프록시 리소스의 trustedCA 필드는 클러스터 전체의 트러스트 번들을 관리하는 데 사용됩니다. additionalTrustBundle은 설치 시 사용되며, 프록시의 trustedCA는 런타임에 사용됩니다.

trustedCA 필드는 클러스터 구성 요소에서 사용하는 사용자 정의 인증서와 키 쌍이 포함된 ConfigMap에 대한 참조입니다.

31.1. 설치 중 클러스터 단위 프록시 구성

프로덕션 환경에서는 인터넷에 대한 직접 액세스를 거부하고 대신 HTTP 또는 HTTPS 프록시를 사용할 수 있습니다. install-config.yaml 파일에서 프록시 설정을 구성하여 프록시가 사용되도록 새 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • 기존 install-config.yaml 파일이 있습니다.
  • 클러스터에서 액세스해야 하는 사이트를 검토하고 프록시를 바이패스해야 하는지 확인했습니다. 기본적으로 호스팅 클라우드 공급자 API에 대한 호출을 포함하여 모든 클러스터 발신(Egress) 트래픽이 프록시됩니다. 필요한 경우 프록시를 바이패스하기 위해 Proxy 오브젝트의 spec.noProxy 필드에 사이트를 추가했습니다.

    참고

    Proxy 오브젝트의 status.noProxy 필드는 설치 구성에 있는 networking.machineNetwork[].cidr, networking.clusterNetwork[].cidr, networking.serviceNetwork[] 필드의 값으로 채워집니다.

    Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure 및 Red Hat OpenStack Platform (RHOSP)에 설치하는 경우 Proxy 오브젝트 status.noProxy 필드도 인스턴스 메타데이터 끝점(169.254.169.254)로 채워집니다.

절차

  1. install-config.yaml 파일을 편집하고 프록시 설정을 추가합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 
    5
    Copy to Clipboard Toggle word wrap
    1
    클러스터 외부에서 HTTP 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http여야 합니다.
    2
    클러스터 외부에서 HTTPS 연결을 구축하는 데 사용할 프록시 URL입니다.
    3
    대상 도메인 이름, IP 주소 또는 프록시에서 제외할 기타 네트워크 CIDR로 이루어진 쉼표로 구분된 목록입니다. 하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.comx.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. Amazon EC2,Elastic Load BalancingS3 VPC 끝점을 VPC에 추가한 경우 이러한 끝점을 noProxy 필드에 추가해야 합니다.
    4
    이 값을 제공하면 설치 프로그램에서 HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 하나 이상 포함된 openshift-config 네임스페이스에 user-ca-bundle이라는 이름으로 구성 맵을 생성합니다. 그러면 CNO(Cluster Network Operator)에서 이러한 콘텐츠를 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들과 병합하는 trusted-ca-bundle 구성 맵을 생성합니다. 이 구성 맵은 Proxy 오브젝트의 trustedCA 필드에서 참조됩니다. 프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명하지 않은 경우 additionalTrustBundle 필드가 있어야 합니다.
    5
    선택 사항: trustedCA 필드에서 user-ca-bundle 구성 맵을 참조할 프록시 오브젝트의 구성을 결정하는 정책입니다. 허용되는 값은 ProxyonlyAlways 입니다. http/https 프록시가 구성된 경우에만 user-ca-bundle 구성 맵을 참조하려면 Proxyonly 를 사용합니다. Always 를 사용하여 user-ca-bundle 구성 맵을 항상 참조합니다. 기본값은 Proxyonly 입니다.
    참고

    설치 프로그램에서 프록시 adinessEndpoints 필드를 지원하지 않습니다.

    참고

    설치 프로그램이 시간 초과되면 설치 프로그램의 wait-for 명령을 사용하여 배포를 다시 시작한 다음 완료합니다. 예를 들면 다음과 같습니다.

    $ ./openshift-install wait-for install-complete --log-level debug
    Copy to Clipboard Toggle word wrap
  2. 파일을 저장해 놓고 OpenShift Container Platform을 설치할 때 참조하십시오.

제공되는 install-config.yaml 파일의 프록시 설정을 사용하는 cluster라는 이름의 클러스터 전체 프록시가 설치 프로그램에 의해 생성됩니다. 프록시 설정을 제공하지 않아도 cluster Proxy 오브젝트는 계속 생성되지만 spec은 nil이 됩니다.

참고

cluster라는 Proxy 오브젝트만 지원되며 추가 프록시는 생성할 수 없습니다.

31.2. 클러스터 전체 프록시 사용

프록시 오브젝트는 클러스터 전체 송신 프록시를 관리하는 데 사용됩니다. 프록시를 구성하지 않고 클러스터를 설치하거나 업그레이드하면 프록시 오브젝트 계속 생성되지만 spec 은 nil이 됩니다. 예를 들면 다음과 같습니다.

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:
Copy to Clipboard Toggle word wrap

클러스터 관리자는 이 cluster Proxy 오브젝트를 수정하여 OpenShift Container Platform의 프록시를 구성할 수 있습니다.

참고

cluster라는 Proxy 오브젝트만 지원되며 추가 프록시는 생성할 수 없습니다.

주의

클러스터 전체 프록시를 활성화하면 MCO(Machine Config Operator)가 노드 재부팅을 트리거합니다.

사전 요구 사항

  • 클러스터 관리자 권한
  • OpenShift Container Platform oc CLI 도구 설치

절차

  1. HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 포함된 구성 맵을 생성합니다.

    참고

    프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명한 경우 이 단계를 건너뛸 수 있습니다.

    1. 다음 내용으로 user-ca-bundle.yaml이라는 파일을 생성하고 PEM 인코딩 인증서 값을 제공합니다.

      apiVersion: v1
      data:
        ca-bundle.crt: | 
      1
      
          <MY_PEM_ENCODED_CERTS> 
      2
      
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 
      3
      
        namespace: openshift-config 
      4
      Copy to Clipboard Toggle word wrap
      1
      이 데이터 키의 이름은 ca-bundle.crt여야 합니다.
      2
      프록시의 ID 인증서 서명에 사용되는 하나 이상의 PEM 인코딩 X.509 인증서입니다.
      3
      프록시 오브젝트에서 참조할 구성 맵 이름입니다.
      4
      구성 맵은 openshift-config 네임스페이스에 있어야 합니다.
    2. 이 파일에서 구성 맵을 생성합니다.

      $ oc create -f user-ca-bundle.yaml
      Copy to Clipboard Toggle word wrap
  2. oc edit 명령을 사용하여 프록시 오브젝트를 수정합니다.

    $ oc edit proxy/cluster
    Copy to Clipboard Toggle word wrap
  3. 프록시에 필요한 필드를 구성합니다.

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: example.com 
    3
    
      readinessEndpoints:
      - http://www.google.com 
    4
    
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 
    5
    Copy to Clipboard Toggle word wrap
    1
    클러스터 외부에서 HTTP 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http여야 합니다.
    2
    클러스터 외부에서 HTTPS 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http 또는 https 여야 합니다. URL 스키마를 지원하는 프록시의 URL을 지정합니다. 예를 들어 대부분의 프록시는 https 를 사용하도록 구성된 경우 오류를 보고하지만 http 만 지원합니다. 이 실패 메시지는 로그에 전파되지 않을 수 있으며 대신 네트워크 연결 실패로 표시될 수 있습니다. 클러스터에서 https 연결을 수신하는 프록시를 사용하는 경우 프록시에서 사용하는 CA 및 인증서를 수락하도록 클러스터를 구성해야 할 수 있습니다.
    3
    대상 도메인 이름, 도메인, IP 주소 또는 프록시를 제외할 기타 네트워크 CIDR로 이루어진 쉼표로 구분된 목록입니다.

    하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.comx.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. networking.machineNetwork[].cidr 필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.

    httpProxyhttpsProxy 필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.

    4
    httpProxyhttpsProxy 값을 상태에 쓰기 전에 준비 검사를 수행하는 데 사용할 하나 이상의 클러스터 외부 URL입니다.
    5
    HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 포함된 openshift-config 네임스페이스의 구성 맵에 대한 참조입니다. 여기서 구성 맵을 참조하기 전에 구성 맵이 이미 있어야 합니다. 프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명하지 않은 경우 이 필드가 있어야 합니다.
  4. 파일을 저장하여 변경 사항을 적용합니다.

31.3. Operator를 사용한 인증서 주입

ConfigMap을 통해 사용자 정의 CA 인증서가 클러스터에 추가되면 CNO(Cluster Network Operator)에서 사용자 제공 및 시스템 CA 인증서를 단일 번들로 병합한 후 병합한 번들을 신뢰 번들 주입을 요청하는 Operator에 주입합니다.

중요

config.openshift.io/inject-trusted-cabundle="true" 레이블을 구성 맵에 추가하면 기존 데이터가 삭제됩니다. CNO(Cluster Network Operator)는 구성 맵의 소유권을 가지며 ca-bundle 만 데이터로만 허용합니다. service.beta.openshift.io/inject-cabundle=true 주석 또는 유사한 구성을 사용하여 별도의 구성 맵을 사용하여 service-ca.crt 를 저장해야 합니다. 동일한 구성 맵에 config.openshift.io/inject-trusted-cabundle="true" 레이블 및 service.beta.openshift.io/inject-cabundle=true 주석을 추가하면 문제가 발생할 수 있습니다.

Operator는 다음 라벨이 있는 빈 ConfigMap을 생성하여 이러한 주입을 요청합니다.

config.openshift.io/inject-trusted-cabundle="true"
Copy to Clipboard Toggle word wrap

빈 ConfigMap의 예:

apiVersion: v1
data: {}
kind: ConfigMap
metadata:
  labels:
    config.openshift.io/inject-trusted-cabundle: "true"
  name: ca-inject 
1

  namespace: apache
Copy to Clipboard Toggle word wrap
1
빈 ConfigMap 이름을 지정합니다.

Operator는 이 ConfigMap을 컨테이너의 로컬 신뢰 저장소에 마운트합니다.

참고

신뢰할 수 있는 CA 인증서를 추가하는 작업은 인증서가 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들에 포함되지 않은 경우에만 필요합니다.

Operator는 제한 없이 인증서를 주입할 수 있습니다. config.openshift.io/inject-trusted-cabundle=true 라벨을 사용하여 비어있는 ConfigMap이 생성되면 CNO(Cluster Network Operator)에서 모든 네임스페이스에 인증서를 주입합니다.

ConfigMap은 모든 네임스페이스에 상주할 수 있지만 사용자 정의 CA가 필요한 Pod 내의 각 컨테이너에 볼륨으로 마운트해야 합니다. 예를 들면 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-example-custom-ca-deployment
  namespace: my-example-custom-ca-ns
spec:
  ...
    spec:
      ...
      containers:
        - name: my-container-that-needs-custom-ca
          volumeMounts:
          - name: trusted-ca
            mountPath: /etc/pki/ca-trust/extracted/pem
            readOnly: true
      volumes:
      - name: trusted-ca
        configMap:
          name: trusted-ca
          items:
            - key: ca-bundle.crt 
1

              path: tls-ca-bundle.pem 
2
Copy to Clipboard Toggle word wrap
1
ca-bundle.crt는 ConfigMap 키로 필요합니다.
2
tls-ca-bundle.pem은 ConfigMap 경로로 필요합니다.

32장. RHOSP의 로드 밸런싱

32.1. 로드 밸런서 서비스의 제한 사항

RHOSP(Red Hat OpenStack Platform)의 OpenShift Container Platform 클러스터는 Octavia를 사용하여 로드 밸런서 서비스를 처리합니다. 이러한 선택으로 인해 이러한 클러스터에는 다양한 기능 제한 사항이 있습니다.

RHOSP Octavia에는 두 가지 공급자인 Amphora와 OVN이 지원됩니다. 이러한 공급자는 사용 가능한 기능 및 구현 세부 사항에 따라 다릅니다. 이러한 차이점은 클러스터에서 생성된 로드 밸런서 서비스에 영향을 미칩니다.

32.1.1. 로컬 외부 트래픽 정책

로드 밸런서 서비스에서 외부 트래픽 정책(ETP) 매개변수 .spec.externalTrafficPolicy 를 설정하여 서비스 끝점 Pod에 도달할 때 들어오는 트래픽의 소스 IP 주소를 유지할 수 있습니다. 그러나 클러스터가 Amphora Octavia 공급자를 사용하는 경우 트래픽의 소스 IP가 Amphora VM의 IP 주소로 교체됩니다. 클러스터가 OVN Octavia 공급자를 사용하는 경우 이 동작이 발생하지 않습니다.

ETP 옵션을 Local 로 설정하려면 로드 밸런서에 대한 상태 모니터를 생성해야 합니다. 상태 모니터가 없으면 트래픽이 기능적인 끝점이 없는 노드로 라우팅될 수 있으므로 연결이 끊어집니다. Cloud Provider OpenStack에서 상태 모니터를 생성하도록 하려면 클라우드 공급자 구성에서 create-monitor 옵션 값을 true 로 설정해야 합니다.

RHOSP 16.2에서 OVN Octavia 공급자는 상태 모니터를 지원하지 않습니다. 따라서 ETP를 local로 설정하는 것은 지원되지 않습니다.

RHOSP 16.2에서 Amphora Octavia 공급자는 UDP 풀에서 HTTP 모니터를 지원하지 않습니다. 결과적으로 UDP 로드 밸런서 서비스에는 UDP-CONNECT 모니터가 대신 생성됩니다. 구현 세부 정보로 인해 이 구성은 OVN-Kubernetes CNI 플러그인에서만 제대로 작동합니다. OpenShift SDN CNI 플러그인을 사용하면 UDP 서비스가 정상적으로 감지됩니다.

32.1.2. 로드 밸런서 소스 범위

.spec.loadBalancerSourceRanges 속성을 사용하여 소스 IP에 따라 로드 밸런서를 통과할 수 있는 트래픽을 제한합니다. 이 속성은 Amphora Octavia 공급자에서만 사용할 수 있습니다. 클러스터에서 OVN Octavia 공급자를 사용하는 경우 옵션이 무시되고 트래픽이 무제한입니다.

32.2. Kuryr SDN으로 Octavia OVN 로드 밸런서 공급자 드라이버 사용

중요

Kuryr는 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

OpenShift Container Platform 클러스터에서 Kuryr를 사용하고 나중에 RHOSP 16으로 업그레이드된 RHOSP(Red Hat OpenStack Platform) 13 클라우드에 설치된 경우, Octavia OVN 공급자 드라이버를 사용하도록 구성할 수 있습니다.

중요

공급자 드라이버를 변경하면 Kuryr가 기존 로드 밸런서를 대신합니다. 이 프로세스로 인해 약간의 다운 타임이 발생합니다.

사전 요구 사항

  • RHOSP CLI, openstack을 설치합니다.
  • OpenShift Container Platform CLI, oc를 설치합니다.
  • RHOSP의 Octavia OVN 드라이버가 활성화되었는지 확인합니다.

    작은 정보

    사용 가능한 Octavia 드라이버 목록을 보려면 명령줄에서 openstack loadbalancer provider list를 입력하십시오.

    명령 출력에 ovn 드라이버가 표시됩니다.

절차

Octavia Amphora 공급자 드라이버에서 Octavia OVN으로 변경하려면 다음을 수행하십시오.

  1. kuryr-config ConfigMap을 엽니다. 명령줄에 다음을 입력합니다.

    $ oc -n openshift-kuryr edit cm kuryr-config
    Copy to Clipboard Toggle word wrap
  2. ConfigMap에서 kuryr-octavia-provider:default가 포함된 행을 삭제합니다. 예를 들면 다음과 같습니다.

    ...
    kind: ConfigMap
    metadata:
      annotations:
        networkoperator.openshift.io/kuryr-octavia-provider: default 
    1
    
    ...
    Copy to Clipboard Toggle word wrap
    1
    이 행을 삭제합니다. 클러스터에서 ovn을 값으로 사용하여 이 행을 다시 생성합니다.

    CNO(Cluster Network Operator)에서 수정 사항을 감지하고 kuryr-controllerkuryr-cni Pod를 재배포할 때까지 기다리십시오. 이 과정에 몇 분이 걸릴 수 있습니다.

  3. kuryr-config ConfigMap 주석이 값 ovn과 함께 표시되는지 확인합니다. 명령줄에 다음을 입력합니다.

    $ oc -n openshift-kuryr edit cm kuryr-config
    Copy to Clipboard Toggle word wrap

    ovn 공급자 값이 출력에 표시됩니다.

    ...
    kind: ConfigMap
    metadata:
      annotations:
        networkoperator.openshift.io/kuryr-octavia-provider: ovn
    ...
    Copy to Clipboard Toggle word wrap
  4. RHOSP에서 로드 밸런서를 다시 생성했는지 확인합니다.

    1. 명령줄에 다음을 입력합니다.

      $ openstack loadbalancer list | grep amphora
      Copy to Clipboard Toggle word wrap

      하나의 Amphora 로드 밸런서가 표시됩니다. 예를 들면 다음과 같습니다.

      a4db683b-2b7b-4988-a582-c39daaad7981 | ostest-7mbj6-kuryr-api-loadbalancer  | 84c99c906edd475ba19478a9a6690efd | 172.30.0.1     | ACTIVE              | amphora
      Copy to Clipboard Toggle word wrap
    2. 다음을 입력하여 ovn 로드 밸런서를 검색합니다.

      $ openstack loadbalancer list | grep ovn
      Copy to Clipboard Toggle word wrap

      ovn 유형의 나머지 로드 밸런서가 표시됩니다. 예를 들면 다음과 같습니다.

      2dffe783-98ae-4048-98d0-32aa684664cc | openshift-apiserver-operator/metrics | 84c99c906edd475ba19478a9a6690efd | 172.30.167.119 | ACTIVE              | ovn
      0b1b2193-251f-4243-af39-2f99b29d18c5 | openshift-etcd/etcd                  | 84c99c906edd475ba19478a9a6690efd | 172.30.143.226 | ACTIVE              | ovn
      f05b07fc-01b7-4673-bd4d-adaa4391458e | openshift-dns-operator/metrics       | 84c99c906edd475ba19478a9a6690efd | 172.30.152.27  | ACTIVE              | ovn
      Copy to Clipboard Toggle word wrap

32.3. Octavia를 사용하여 애플리케이션 트래픽의 클러스터 확장

RHOSP(Red Hat OpenStack Platform)에서 실행되는 OpenShift Container Platform 클러스터는 Octavia 로드 밸런싱 서비스를 사용하여 여러 VM(가상 머신) 또는 유동 IP 주소에 트래픽을 배포할 수 있습니다. 이 기능을 사용하면 단일 머신 또는 주소가 생성하는 병목 현상이 완화됩니다.

클러스터가 Kuryr를 사용하는 경우 CNO(Cluster Network Operator)가 배포 시 내부 Octavia 로드 밸런서를 생성했습니다. 이 로드 밸런서를 애플리케이션 네트워크 스케일링에 사용할 수 있습니다.

클러스터가 Kuryr를 사용하지 않는 경우 애플리케이션 네트워크 확장에 사용할 자체 Octavia 로드 밸런서를 생성해야 합니다.

32.3.1. Octavia를 사용하여 클러스터 스케일링

여러 API 로드 밸런서를 사용하거나 클러스터가 Kuryr를 사용하지 않는 경우 Octavia 로드 밸런서를 생성하고 이를 사용할 클러스터를 구성합니다.

사전 요구 사항

  • Octavia는 RHOSP(Red Hat OpenStack Platform) 배포에서 사용할 수 있습니다.

절차

  1. 명령줄에서 Amphora 드라이버를 사용하는 Octavia 로드 밸런서를 생성합니다.

    $ openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
    Copy to Clipboard Toggle word wrap

    API_OCP_CLUSTER 대신 선택한 이름을 사용할 수 있습니다.

  2. 로드 밸런서가 활성화된 후 리스너를 생성합니다.

    $ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER
    Copy to Clipboard Toggle word wrap
    참고

    로드 밸런서의 상태를 보려면 openstack loadbalancer list를 입력합니다.

  3. 라운드 로빈 알고리즘을 사용하고 세션 지속성이 활성화된 풀을 생성합니다.

    $ openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS
    Copy to Clipboard Toggle word wrap
  4. 컨트롤 플레인 머신을 사용할 수 있도록 하려면 상태 모니터를 생성합니다.

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443
    Copy to Clipboard Toggle word wrap
  5. 컨트롤 플레인 머신을 로드 밸런서 풀의 멤버로 추가합니다.

    $ for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP)
    do
      openstack loadbalancer member create --address $SERVER  --protocol-port 6443 API_OCP_CLUSTER_pool_6443
    done
    Copy to Clipboard Toggle word wrap
  6. 선택 사항: 클러스터 API 유동 IP 주소를 재사용하려면 설정을 해제합니다.

    $ openstack floating ip unset $API_FIP
    Copy to Clipboard Toggle word wrap
  7. 생성된 로드 밸런서 VIP에 설정되지 않은 API_FIP 또는 새 주소를 추가합니다.

    $ openstack floating ip set  --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP
    Copy to Clipboard Toggle word wrap

이제 클러스터에서 로드 밸런싱에 Octavia를 사용합니다.

참고

Kuryr가 Octavia Amphora 드라이버를 사용하는 경우 모든 트래픽은 단일 Amphora VM(가상 머신)을 통해 라우팅됩니다.

병목 현상을 완화할 수 있는 추가 로드 밸런서를 생성하기 위해 이 절차를 반복할 수 있습니다.

32.3.2. Octavia를 사용하여 Kuryr를 사용하는 클러스터 스케일링

중요

Kuryr는 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

클러스터가 Kuryr를 사용하는 경우 클러스터의 API 유동 IP 주소를 기존 Octavia 로드 밸런서와 연결합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터는 Kuryr을 사용합니다.
  • Octavia는 RHOSP(Red Hat OpenStack Platform) 배포에서 사용할 수 있습니다.

절차

  1. 선택 사항: 명령줄에서 클러스터 API 유동 IP 주소를 재사용하려면 설정을 해제합니다.

    $ openstack floating ip unset $API_FIP
    Copy to Clipboard Toggle word wrap
  2. 생성된 로드 밸런서 VIP에 설정되지 않은 API_FIP 또는 새 주소를 추가합니다.

    $ openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value ${OCP_CLUSTER}-kuryr-api-loadbalancer) $API_FIP
    Copy to Clipboard Toggle word wrap

이제 클러스터에서 로드 밸런싱에 Octavia를 사용합니다.

참고

Kuryr가 Octavia Amphora 드라이버를 사용하는 경우 모든 트래픽은 단일 Amphora VM(가상 머신)을 통해 라우팅됩니다.

병목 현상을 완화할 수 있는 추가 로드 밸런서를 생성하기 위해 이 절차를 반복할 수 있습니다.

32.4. RHOSP Octavia를 사용하여 수신 트래픽 스케일링

중요

Kuryr는 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

Octavia 로드 밸런서를 사용하여 Kuryr를 사용하는 클러스터에서 Ingress 컨트롤러를 스케일링할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터는 Kuryr을 사용합니다.
  • RHOSP 배포에서 Octavia를 사용할 수 있습니다.

절차

  1. 현재 내부 라우터 서비스를 복사하려면 명령줄에서 다음을 입력합니다.

    $ oc -n openshift-ingress get svc router-internal-default -o yaml > external_router.yaml
    Copy to Clipboard Toggle word wrap
  2. 파일 external_router.yaml에서 metadata.namespec.type의 값을 LoadBalancer로 변경합니다.

    라우터 파일 예

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        ingresscontroller.operator.openshift.io/owning-ingresscontroller: default
      name: router-external-default 
    1
    
      namespace: openshift-ingress
    spec:
      ports:
      - name: http
        port: 80
        protocol: TCP
        targetPort: http
      - name: https
        port: 443
        protocol: TCP
        targetPort: https
      - name: metrics
        port: 1936
        protocol: TCP
        targetPort: 1936
      selector:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
      sessionAffinity: None
      type: LoadBalancer 
    2
    Copy to Clipboard Toggle word wrap

    1
    이 값이 router-external-default와 같이 설명적인지 확인합니다.
    2
    이 값이 LoadBalancer인지 확인합니다.
참고

로드 밸런싱에 적합하지 않은 타임 스탬프 및 기타 정보를 삭제할 수 있습니다.

  1. 명령줄에서 external_router.yaml 파일의 서비스를 생성합니다.

    $ oc apply -f external_router.yaml
    Copy to Clipboard Toggle word wrap
  2. 서비스의 외부 IP 주소가 로드 밸런서와 연결된 항목과 동일한지 확인합니다.

    1. 명령줄에서 서비스의 외부 IP 주소를 검색합니다.

      $ oc -n openshift-ingress get svc
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                                     AGE
      router-external-default   LoadBalancer   172.30.235.33    10.46.22.161   80:30112/TCP,443:32359/TCP,1936:30317/TCP   3m38s
      router-internal-default   ClusterIP      172.30.115.123   <none>         80/TCP,443/TCP,1936/TCP                     22h
      Copy to Clipboard Toggle word wrap

    2. 로드 밸런서의 IP 주소를 검색합니다.

      $ openstack loadbalancer list | grep router-external
      Copy to Clipboard Toggle word wrap

      출력 예

      | 21bf6afe-b498-4a16-a958-3229e83c002c | openshift-ingress/router-external-default | 66f3816acf1b431691b8d132cc9d793c | 172.30.235.33  | ACTIVE | octavia |
      Copy to Clipboard Toggle word wrap

    3. 이전 단계에서 검색한 주소가 유동 IP 목록에서 서로 연결되어 있는지 확인합니다.

      $ openstack floating ip list | grep 172.30.235.33
      Copy to Clipboard Toggle word wrap

      출력 예

      | e2f80e97-8266-4b69-8636-e58bacf1879e | 10.46.22.161 | 172.30.235.33 | 655e7122-806a-4e0a-a104-220c6e17bda6 | a565e55a-99e7-4d15-b4df-f9d7ee8c9deb | 66f3816acf1b431691b8d132cc9d793c |
      Copy to Clipboard Toggle word wrap

이제 EXTERNAL-IP 값을 새 Ingress 주소로 사용할 수 있습니다.

참고

Kuryr가 Octavia Amphora 드라이버를 사용하는 경우 모든 트래픽은 단일 Amphora VM(가상 머신)을 통해 라우팅됩니다.

병목 현상을 완화할 수 있는 추가 로드 밸런서를 생성하기 위해 이 절차를 반복할 수 있습니다.

32.5. 외부 로드 밸런서 서비스

기본 로드 밸런서 대신 외부 로드 밸런서를 사용하도록 RHOSP(Red Hat OpenStack Platform)에서 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

외부 로드 밸런서 구성은 벤더의 로드 밸런서에 따라 다릅니다.

이 섹션의 정보와 예제는 지침용으로만 사용됩니다. 벤더의 로드 밸런서에 대한 자세한 내용은 벤더 설명서를 참조하십시오.

Red Hat은 외부 로드 밸런서에 대해 다음 서비스를 지원합니다.

  • Ingress 컨트롤러
  • OpenShift API
  • OpenShift MachineConfig API

외부 로드 밸런서에 대해 이러한 서비스 중 하나 또는 모두를 구성할지 여부를 선택할 수 있습니다. Ingress 컨트롤러 서비스만 구성하는 것은 일반적인 구성 옵션입니다. 각 서비스를 더 잘 이해하려면 다음 다이어그램을 참조하십시오.

그림 32.1. OpenShift Container Platform 환경에서 작동하는 Ingress 컨트롤러를 보여주는 네트워크 워크플로의 예

그림 32.2. OpenShift Container Platform 환경에서 작동하는 OpenShift API를 보여주는 네트워크 워크플로우의 예

그림 32.3. OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API를 보여주는 네트워크 워크플로우의 예

외부 로드 밸런서에 지원되는 구성 옵션은 다음과 같습니다.

  • 노드 선택기를 사용하여 Ingress 컨트롤러를 특정 노드 세트에 매핑합니다. 이 세트의 각 노드에 고정 IP 주소를 할당하거나 DHCP(Dynamic Host Configuration Protocol)에서 동일한 IP 주소를 수신하도록 각 노드를 구성해야 합니다. 인프라 노드는 일반적으로 이러한 유형의 구성을 수신합니다.
  • 서브넷의 모든 IP 주소를 대상으로 지정합니다. 이 구성은 로드 밸런서 대상을 재구성하지 않고 해당 네트워크 내에서 노드를 생성하고 삭제할 수 있으므로 유지 관리 오버헤드를 줄일 수 있습니다. /27 또는 /28 과 같은 작은 네트워크에 머신 세트를 사용하여 Ingress Pod를 배포하는 경우 로드 밸런서 대상을 단순화할 수 있습니다.

    작은 정보

    머신 구성 풀의 리소스를 확인하여 네트워크에 존재하는 모든 IP 주소를 나열할 수 있습니다.

OpenShift Container Platform 클러스터에 대한 외부 로드 밸런서를 구성하기 전에 다음 정보를 고려하십시오.

  • 프런트 엔드 IP 주소의 경우 프런트 엔드 IP 주소, Ingress 컨트롤러의 로드 밸런서 및 API 로드 밸런서에 동일한 IP 주소를 사용할 수 있습니다. 이 기능에 대해서는 벤더의 설명서를 확인하십시오.
  • 백엔드 IP 주소의 경우 OpenShift Container Platform 컨트롤 플레인 노드의 IP 주소가 외부 로드 밸런서의 수명 동안 변경되지 않아야 합니다. 다음 작업 중 하나를 완료하여 이 작업을 수행할 수 있습니다.

    • 각 컨트롤 플레인 노드에 고정 IP 주소를 할당합니다.
    • 노드가 DHCP 리스를 요청할 때마다 DHCP에서 동일한 IP 주소를 수신하도록 각 노드를 구성합니다. 공급 업체에 따라 DHCP 리스를 IP 예약 또는 정적 DHCP 할당의 형태로 될 수 있습니다.
  • Ingress 컨트롤러 백엔드 서비스의 외부 로드 밸런서에서 Ingress 컨트롤러를 실행하는 각 노드를 수동으로 정의합니다. 예를 들어 Ingress 컨트롤러가 정의되지 않은 노드로 이동하는 경우 연결 중단이 발생할 수 있습니다.

32.5.1. 외부 로드 밸런서 구성

기본 로드 밸런서 대신 외부 로드 밸런서를 사용하도록 RHOSP(Red Hat OpenStack Platform)에서 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

외부 로드 밸런서를 구성하기 전에 "외부 로드 밸런서용 서비스" 섹션을 읽으십시오.

외부 로드 밸런서에 대해 구성할 서비스에 적용되는 다음 사전 요구 사항을 읽으십시오.

참고

클러스터에서 실행되는 MetalLB는 외부 로드 밸런서로 작동합니다.

OpenShift API 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.
  • TCP 포트 6443 및 22623은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다. 다음 항목을 확인합니다.

    • 포트 6443은 OpenShift API 서비스에 대한 액세스를 제공합니다.
    • 포트 22623은 노드에 Ignition 시작 구성을 제공할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 6443은 OpenShift Container Platform 클러스터 외부의 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 22623은 OpenShift Container Platform 노드에서만 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 6443 및 22623의 OpenShift Container Platform 컨트롤 플레인 노드와 통신할 수 있습니다.

Ingress 컨트롤러 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.
  • TCP 포트 443 및 80은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터 외부에 있는 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터에서 작동하는 모든 노드에 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 80, 443, 1936에서 Ingress 컨트롤러를 실행하는 OpenShift Container Platform 노드와 통신할 수 있습니다.

상태 점검 URL 사양의 사전 요구 사항

서비스를 사용할 수 없거나 사용할 수 없는지 결정하는 상태 점검 URL을 설정하여 대부분의 로드 밸런서를 구성할 수 있습니다. OpenShift Container Platform은 OpenShift API, 머신 구성 API 및 Ingress 컨트롤러 백엔드 서비스에 대한 이러한 상태 점검을 제공합니다.

다음 예제에서는 이전에 나열된 백엔드 서비스에 대한 상태 점검 사양을 보여줍니다.

Kubernetes API 상태 점검 사양의 예

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API 상태 점검 사양의 예

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress 컨트롤러 상태 점검 사양의 예

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

절차

  1. 포트 6443, 443 및 80의 로드 밸런서에서 클러스터에 액세스할 수 있도록 HAProxy Ingress 컨트롤러를 구성합니다.

    HAProxy 구성 예

    #...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
            bind 192.168.1.100:443
            mode tcp
            balance roundrobin
        option httpchk
        http-check connect
        http-check send meth GET uri /healthz/ready
        http-check expect status 200
            server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
            bind 192.168.1.100:80
            mode tcp
            balance roundrobin
        option httpchk
        http-check connect
        http-check send meth GET uri /healthz/ready
        http-check expect status 200
            server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
            server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...
    Copy to Clipboard Toggle word wrap

  2. curl CLI 명령을 사용하여 외부 로드 밸런서 및 해당 리소스가 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 응답을 관찰하여 Kubernetes API 서버 리소스에서 클러스터 머신 구성 API에 액세스할 수 있는지 확인합니다.

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성 API에 머신 구성 서버 리소스에 액세스할 수 있는지 확인합니다.

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하고 출력을 관찰하여 포트 80의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다.

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
      Copy to Clipboard Toggle word wrap
    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다.

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
  3. 외부 로드 밸런서의 프런트 엔드 IP 주소를 대상으로 하도록 클러스터의 DNS 레코드를 구성합니다. 로드 밸런서를 통해 클러스터 API 및 애플리케이션의 DNS 서버로 레코드를 업데이트해야 합니다.

    수정된 DNS 레코드 예

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    중요

    DNS 전파는 각 DNS 레코드를 사용할 수 있을 때까지 약간의 시간이 걸릴 수 있습니다. 각 레코드를 검증하기 전에 각 DNS 레코드가 전파되는지 확인합니다.

  4. curl CLI 명령을 사용하여 외부 로드 밸런서 및 DNS 레코드 구성이 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 출력을 관찰하여 클러스터 API에 액세스할 수 있는지 확인합니다.

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성에 액세스할 수 있는지 확인합니다.

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하고 출력을 관찰하여 포트의 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다.

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443에서 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다.

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap

33장. MetalLB로 로드 밸런싱

33.1. MetalLB 및 MetalLB Operator 정보

클러스터 관리자는 LoadBalancer 유형의 서비스가 클러스터에 추가되면 MetalLB가 서비스에 대한 외부 IP 주소를 추가할 수 있도록 MetalLB Operator를 클러스터에 추가할 수 있습니다. 외부 IP 주소가 클러스터의 호스트 네트워크에 추가됩니다.

33.1.1. MetalLB 사용 시기

MetalLB를 사용하는 것은 베어 메탈 클러스터 또는 베어 메탈과 같은 인프라가 있는 경우 중요하며, 외부 IP 주소를 통해 애플리케이션에 내결함성 액세스를 원할 때 중요합니다.

외부 IP 주소의 네트워크 트래픽이 클라이언트에서 클러스터의 호스트 네트워크로 라우팅되도록 네트워킹 인프라를 구성해야 합니다.

MetalLB Operator를 사용하여 MetalLB를 배포한 후 LoadBalancer 유형의 서비스를 추가하면 MetalLB에서 플랫폼 네이티브 로드 밸런서를 제공합니다.

layer2 모드에서 operations in layer2 mode는 IP 페일오버와 유사한 메커니즘을 사용하여 장애 조치(failover)를 지원합니다. 그러나 VRRP(가상 라우터 중복 프로토콜) 및 keepalived를 사용하는 대신 gossip 기반 프로토콜을 활용하여 노드 실패 인스턴스를 식별합니다. 페일오버가 감지되면 다른 노드에서 리더 노드의 역할을 가정하고, 비정상적인 ARP 메시지가 전송되어 이 변경 사항을 브로드캐스트합니다.

layer3 또는 BGP(Border Gateway Protocol) 모드에서 작동하는 CloudEvent 모드는 실패 감지를 네트워크에 위임합니다. OpenShift Container Platform 노드가 연결된 BGP 라우터 또는 라우터는 노드 오류를 식별하고 해당 노드에 대한 경로를 종료합니다.

Pod 및 서비스의 고가용성을 보장하는 데 IP 페일오버 대신 CloudEvent를 사용하는 것이 좋습니다.

33.1.2. MetalLB Operator 사용자 정의 리소스

MetalLB Operator는 다음과 같은 사용자 정의 리소스에 대해 자체 네임스페이스를 모니터링합니다.

MetalLB
클러스터에 MetalLB 사용자 정의 리소스를 추가하면 MetalLB Operator에서 클러스터에 MetalLB를 배포합니다. Operator는 사용자 정의 리소스의 단일 인스턴스만 지원합니다. 인스턴스가 삭제되면 Operator는 클러스터에서 MetalLB를 제거합니다.
IPAddressPool

MetalLB에는 LoadBalancer 유형의 서비스를 추가할 때 서비스에 할당할 수 있는 하나 이상의 IP 주소 풀이 필요합니다. IPAddressPool 에는 IP 주소 목록이 포함되어 있습니다. 목록은 1.1.1.1-1.1.1.1, CIDR 표기법에 지정된 범위, 시작 및 종료 주소로 지정된 범위 또는 하이픈으로 구분된 범위 또는 세 가지 조합을 사용하여 설정된 단일 IP 주소일 수 있습니다. IPAddressPool 에는 이름이 필요합니다. 이 문서에서는 doc-example,doc-example -reserved, doc- example-ipv6 등의 이름을 사용합니다. MetalLB 컨트롤러는 IPAddressPool 의 주소 풀에서 IP 주소를 할당합니다. L2AdvertisementBGPAdvertisement 사용자 정의 리소스를 사용하면 지정된 풀에서 지정된 IP를 알릴 수 있습니다. IPAddressPool 의 IP 주소를 IPAddressPoolspec.serviceAllocation 사양을 사용하여 서비스 및 네임스페이스에 할당할 수 있습니다.

참고

단일 IPAddressPool 은 L2 광고 및 BGP 광고에서 참조할 수 있습니다.

BGPPeer
BGP 피어 사용자 지정 리소스는 통신할 MetalLB의 BGP 라우터, 라우터의 AS 번호, MetalLB의 AS 번호, 경로 알림에 대한 사용자 지정을 식별합니다. MetalLB는 서비스 로드 밸런서 IP 주소의 경로를 하나 이상의 BGP 피어로 알립니다.
BFDProfile
BFD 프로필 사용자 정의 리소스는 BGP 피어에 대해 BFD( Bidirectional Forwarding Detection)를 구성합니다. BFD는 BGP에서만 제공하는 것보다 더 빠른 경로 장애 감지 기능을 제공합니다.
L2Advertisement
L2Advertisement 사용자 정의 리소스는 L2 프로토콜을 사용하여 IPAddressPool 에서 들어오는 IP를 알립니다.
BGPAdvertisement
BGPAdvertisement 사용자 정의 리소스는 BGP 프로토콜을 사용하여 IPAddressPool 에서 들어오는 IP를 알립니다.

MetalLB 사용자 정의 리소스를 클러스터에 추가하고 Operator가 MetalLB를 배포하면 컨트롤러speaker MetalLB 소프트웨어 구성 요소가 실행되기 시작합니다.

MetalLB는 모든 관련 사용자 정의 리소스의 유효성을 검증합니다.

33.1.3. MetalLB 소프트웨어 구성 요소

MetalLB Operator를 설치하면 metallb-operator-controller-manager 배포가 Pod를 시작합니다. Pod는 Operator의 구현입니다. Pod는 모든 관련 리소스에 대한 변경 사항을 모니터링합니다.

Operator에서 MetalLB 인스턴스를 시작하면 controller 배포 및 speaker 데몬 세트를 시작합니다.

참고

MetalLB 사용자 정의 리소스에서 배포 사양을 구성하여 컨트롤러발표자 Pod가 클러스터에서 배포 및 실행되는 방법을 관리할 수 있습니다. 이러한 배포 사양에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오.

controller

Operator는 배포 및 단일 Pod를 시작합니다. LoadBalancer 유형의 서비스를 추가하면 Kubernetes는 controller를 사용하여 주소 풀에서 IP 주소를 할당합니다. 서비스 실패의 경우 컨트롤러 Pod 로그에 다음 항목이 있는지 확인합니다.

출력 예

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
Copy to Clipboard Toggle word wrap

speaker

Operator는 발표자 Pod의 데몬 세트를 시작합니다. 기본적으로 Pod는 클러스터의 각 노드에서 시작됩니다. MetalLB를 시작할 때 MetalLB 사용자 정의 리소스에 노드 선택기를 지정하여 Pod를 특정 노드로 제한할 수 있습니다. 컨트롤러가 서비스에 IP 주소를 할당하고 서비스를 계속 사용할 수 없는 경우 speaker Pod 로그를 읽습니다. speaker pod를 사용할 수 없는 경우 oc describe pod -n 명령을 실행합니다.

계층 2 모드의 경우 컨트롤러에서 서비스에 IP 주소를 할당한 후 speaker Pod는 알고리즘을 사용하여 로드 밸런서 IP 주소를 알릴 speaker Pod를 결정합니다. 알고리즘은 노드 이름과 로드 밸런서 IP 주소를 해시하는 것과 관련이 있습니다. 자세한 내용은 "MetalLB and external traffic policy"를 참조하십시오. speaker는 ARP(Address Resolution Protocol)를 사용하여 IPv4 주소를 알리고 NDP(neighbor Discovery Protocol)를 사용하여 IPv6 주소를 알립니다.

BGP(Border Gateway Protocol) 모드의 경우 컨트롤러가 서비스에 IP 주소를 할당한 후 각 speaker pod는 BGP 피어를 사용하여 로드 밸런서 IP 주소를 알립니다. BGP 피어에서 BGP 세션을 시작하는 노드를 구성할 수 있습니다.

로드 밸런서 IP 주소에 대한 요청은 IP 주소를 알려주는 speaker가 있는 노드로 라우팅됩니다. 노드가 패킷을 수신하면 서비스 프록시가 패킷을 서비스의 엔드포인트로 라우팅합니다. 최적의 경우 엔드포인트가 동일한 노드에 있거나 다른 노드에 있을 수 있습니다. 서비스 프록시는 연결이 설정될 때마다 엔드포인트를 선택합니다.

33.1.4. MetalLB 및 외부 트래픽 정책

계층 2 모드에서는 클러스터의 한 노드에서 서비스 IP 주소에 대한 모든 트래픽을 수신합니다. BGP 모드를 사용하면 호스트 네트워크의 라우터가 새 클라이언트 연결을 위해 클러스터의 노드 중 하나에 대한 연결을 엽니다. 노드가 입력된 후 클러스터에서 트래픽을 처리하는 방법은 외부 트래픽 정책의 영향을 받습니다.

cluster

spec.externalTrafficPolicy의 기본값입니다.

cluster 트래픽 정책을 사용하면 노드가 트래픽을 수신한 후 서비스 프록시에서 서비스의 모든 pod에 트래픽을 배포합니다. 이 정책은 pod에서 균일한 트래픽 배포를 제공하지만 클라이언트 IP 주소가 지워지고 클라이언트 대신 노드에서 트래픽이 시작된 pod의 애플리케이션에 표시될 수 있습니다.

로컬

local 트래픽 정책에서는 노드가 트래픽을 수신한 후 서비스 프록시에서 동일한 노드의 pod에만 트래픽을 보냅니다. 예를 들어 A 노드의 speaker Pod에서 외부 서비스 IP를 알릴 경우 모든 트래픽이 노드 A로 전송됩니다. 트래픽이 노드 A에 진입하면 서비스 프록시는 A 노드에도 있는 서비스의 Pod에만 트래픽을 전송합니다. 추가 노드에 있는 서비스의 Pod는 A 노드에서 트래픽을 받지 않습니다. 추가 노드의 서비스에 대한 Pod는 장애 조치가 필요한 경우 복제본 역할을 합니다.

이 정책은 클라이언트 IP 주소에 영향을 미치지 않습니다. 애플리케이션 pod는 들어오는 연결에서 클라이언트 IP 주소를 확인할 수 있습니다.

참고

BGP 모드에서 외부 트래픽 정책을 구성할 때 다음 정보가 중요합니다.

MetalLB는 모든 적격한 노드에서 로드 밸런서 IP 주소를 알리지만 서비스 부하 분산은 라우터 용량에 의해 제한되어 ECMP(Equal-cost multipath) 경로를 설정할 수 있습니다. IP를 알리는 노드 수가 라우터의 ECMP 그룹 제한보다 크면 라우터는 IP를 알리는 노드보다 적은 노드를 사용합니다.

예를 들어 외부 트래픽 정책이 로컬 로 설정되어 있고 라우터에 ECMP 그룹 제한이 16으로 설정되어 있고 LoadBalancer 서비스를 구현하는 Pod가 30개의 노드에 배포된 경우 14개의 노드에 배포된 Pod가 트래픽을 수신하지 않습니다. 이 경우 서비스의 외부 트래픽 정책을 cluster 로 설정하는 것이 좋습니다.

33.1.5. 계층 2 모드의 MetalLB 개념

계층 2 모드에서 하나의 노드의 speaker pod는 서비스의 외부 IP 주소를 호스트 네트워크에 알립니다. 네트워크 화면에서 볼 때 노드에는 네트워크 인터페이스에 할당된 여러 IP 주소가 있는 것으로 보입니다.

참고

계층 2 모드에서 MetalLB는 ARP 및 NDP를 사용합니다. 이러한 프로토콜은 특정 서브넷 내에서 로컬 주소 확인을 구현합니다. 이 컨텍스트에서 클라이언트는 MetalLB가 작동하도록 서비스를 발표하는 노드와 동일한 서브넷에 존재하는 MetalLB에서 할당한 VIP에 연결할 수 있어야 합니다.

speaker pod는 IPv6에 대한 IPv4 서비스 및 NDP 요청에 대한 ARP 요청에 응답합니다.

계층 2 모드에서는 서비스 IP 주소의 모든 트래픽이 하나의 노드를 통해 라우팅됩니다. 트래픽이 노드에 진입하면 CNI 네트워크 공급자의 서비스 프록시에서 서비스의 모든 Pod에 트래픽을 배포합니다.

서비스의 모든 트래픽이 계층 2 모드에서 단일 노드를 통해 시작되기 때문에 MetalLB는 계층 2에 대한 로드 밸런서를 구현하지 않습니다. 대신 MetalLB는 speaker pod를 사용할 수 없게 되는 계층 2에 대한 페일오버 메커니즘을 구현하여 다른 노드의 speaker Pod에서 서비스 IP 주소를 알릴 수 있습니다.

노드를 사용할 수 없게 되면 장애 조치가 자동으로 수행됩니다. 다른 노드의 speaker Pod는 노드를 사용할 수 없음을 감지하고 새 speaker Pod 및 노드가 실패한 노드에서 서비스 IP 주소의 소유권을 가져옵니다.

이전 그림에서는 MetalLB와 관련된 다음 개념을 보여줍니다.

  • 애플리케이션은 172.130.0.0/16 서브넷에 클러스터 IP가 있는 서비스를 통해 사용할 수 있습니다. 이 IP 주소는 클러스터 내부에서 액세스할 수 있습니다. 서비스에는 MetalLB가 서비스에 할당된 외부 IP 주소 192.168.100.200도 있습니다.
  • 노드 1 및 3에는 애플리케이션용 pod가 있습니다.
  • speaker 데몬 세트는 각 노드에서 Pod를 실행합니다. MetalLB Operator는 이러한 Pod를 시작합니다.
  • speaker pod는 호스트 네트워크 포드입니다. pod의 IP 주소는 호스트 네트워크에 있는 노드의 IP 주소와 동일합니다.
  • 노드 1의 speaker pod는 ARP를 사용하여 서비스의 외부 IP 주소 192.168.100.200을 알립니다. 외부 IP 주소를 발표하는 speaker pod는 서비스의 엔드포인트와 동일한 노드에 있어야 하며 엔드포인트는 Ready 상태에 있어야 합니다.
  • 클라이언트 트래픽은 호스트 네트워크로 라우팅되고 192.168.100.200 IP 주소에 연결됩니다. 트래픽이 노드로 전환되면 서비스 프록시는 서비스에 설정한 외부 트래픽 정책에 따라 동일한 노드 또는 다른 노드의 애플리케이션 pod로 트래픽을 전송합니다.

    • 서비스의 외부 트래픽 정책이 cluster 로 설정되면 speaker pod가 실행 중인 노드에서 192.168.100.200 로드 밸런서 IP 주소를 알리는 노드가 선택됩니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다.
    • 서비스의 외부 트래픽 정책이 로컬 로 설정되면 192.168.100.200 로드 밸런서 IP 주소를 알리는 노드가 speaker pod가 실행 중인 노드와 서비스 끝점에서 선택됩니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다. 이전 그림에서 노드 1 또는 3은 192.168.100.200 을 알립니다.
  • 노드 1을 사용할 수 없게 되면 외부 IP 주소가 다른 노드로 장애 조치됩니다. 애플리케이션 pod 및 서비스 엔드포인트의 인스턴스가 있는 다른 노드에서 speaker pod는 외부 IP 주소 192.168.100.200을 알리기 시작하고 새 노드는 클라이언트 트래픽을 수신합니다. 다이어그램에서 유일한 후보는 노드 3입니다.

33.1.6. BGP 모드 MetalLB 개념

BGP 모드에서 기본적으로 각 speaker pod는 서비스의 로드 밸런서 IP 주소를 각 BGP 피어에 알립니다. BGP 피어의 선택적 목록을 추가하여 지정된 풀에서 특정 피어 세트로 들어오는 IP를 알릴 수도 있습니다. BGP 피어는 일반적으로 BGP 프로토콜을 사용하도록 구성된 네트워크 라우터입니다. 라우터가 로드 밸런서 IP 주소에 대한 트래픽을 수신하면 라우터는 IP 주소를 알리는 speaker Pod가 있는 노드 중 하나를 선택합니다. 라우터는 트래픽을 해당 노드로 보냅니다. 트래픽이 노드에 진입하면 CNI 네트워크 플러그인의 서비스 프록시에서 서비스의 모든 Pod에 트래픽을 배포합니다.

클러스터 노드와 동일한 계층 2 네트워크 세그먼트에 직접 연결된 라우터를 BGP 피어로 구성할 수 있습니다. 직접 연결된 라우터가 BGP 피어로 구성되지 않은 경우 로드 밸런서 IP 주소의 패킷이 speaker Pod를 실행하는 BGP 피어와 클러스터 노드 간에 라우팅되도록 네트워크를 구성해야 합니다.

라우터가 로드 밸런서 IP 주소에 대한 새 트래픽을 수신할 때마다 노드에 대한 새 연결을 생성합니다. 각 라우터 제조업체에는 연결을 시작할 노드를 선택하기 위한 구현별 알고리즘이 있습니다. 그러나 알고리즘은 일반적으로 네트워크 로드의 균형을 조정하기 위해 사용 가능한 노드에 트래픽을 분산하도록 설계되었습니다.

노드를 사용할 수 없게 되면 라우터는 로드 밸런서 IP 주소를 알리는 speaker pod가 있는 다른 노드로 새 연결을 시작합니다.

그림 33.1. BGP 모드 MetalLB 토폴로지 다이어그램

이전 그림에서는 MetalLB와 관련된 다음 개념을 보여줍니다.

  • 애플리케이션은 172.130.0.0/16 서브넷에 IPv4 클러스터 IP가 있는 서비스를 통해 사용할 수 있습니다. 이 IP 주소는 클러스터 내부에서 액세스할 수 있습니다. 서비스에는 MetalLB가 서비스에 할당된 외부 IP 주소인 203.0.113.200 도 있습니다.
  • 노드 2 및 3에는 애플리케이션에 대한 Pod가 있습니다.
  • speaker 데몬 세트는 각 노드에서 Pod를 실행합니다. MetalLB Operator는 이러한 Pod를 시작합니다. speaker Pod를 실행하는 노드를 지정하도록 MetalLB를 구성할 수 있습니다.
  • speaker pod는 호스트 네트워크 포드입니다. pod의 IP 주소는 호스트 네트워크에 있는 노드의 IP 주소와 동일합니다.
  • speaker pod는 모든 BGP 피어로 BGP 세션을 시작하고 로드 밸런서 IP 주소 또는 집계 경로를 BGP 피어에 알립니다. 발표자 Pod는 Autonomous System 65010의 일부임을 알립니다. 이 다이어그램은 동일한 Autonomous System 내에서 BGP 피어로 라우터 R1을 보여줍니다. 그러나 다른 Autonomous 시스템에 속한 피어와 BGP 세션을 시작하도록 MetalLB를 구성할 수 있습니다.
  • 로드 밸런서 IP 주소를 알리는 speaker pod가 있는 모든 노드는 서비스에 대한 트래픽을 수신할 수 있습니다.

    • 서비스의 외부 트래픽 정책이 cluster 로 설정된 경우 speaker pod가 실행 중인 모든 노드에서 203.0.113.200 로드 밸런서 IP 주소를 알리고 speaker pod가 있는 모든 노드는 서비스에 대한 트래픽을 수신할 수 있습니다. 호스트 접두사는 외부 트래픽 정책이 cluster로 설정된 경우에만 라우터 피어에 알립니다.
    • 서비스의 외부 트래픽 정책이 local 로 설정된 경우 speaker pod가 실행 중인 모든 노드가 있고 서비스 끝점이 실행 중인 모든 노드는 203.0.113.200 로드 밸런서 IP 주소를 알릴 수 있습니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다. 이전 그래픽에서 노드 2 및 3은 203.0.113.200 을 알립니다.
  • BGP 피어 사용자 정의 리소스를 추가할 때 노드 선택기를 지정하여 특정 BGP 피어로 BGP 세션을 시작하도록 MetalLB를 구성할 수 있습니다.
  • BGP를 사용하도록 구성된 R1과 같은 라우터는 BGP 피어로 설정할 수 있습니다.
  • 클라이언트 트래픽은 호스트 네트워크의 노드 중 하나로 라우팅됩니다. 트래픽이 노드로 전환되면 서비스 프록시는 서비스에 설정한 외부 트래픽 정책에 따라 동일한 노드 또는 다른 노드의 애플리케이션 pod로 트래픽을 전송합니다.
  • 노드를 사용할 수 없게 되면 라우터에서 오류를 감지하고 다른 노드와의 새 연결을 시작합니다. BGP 피어에 대해 BFD(Bidirectional Forwarding Detection) 프로필을 사용하도록 MetalLB를 구성할 수 있습니다. BFD는 더 빠른 링크 실패 감지 기능을 제공하여 라우터가 BFD보다 먼저 새로운 연결을 시작할 수 있도록 합니다.

33.1.7. 제한 사항

33.1.7.1. MetalLB의 인프라 고려 사항

MetalLB는 기본적으로 베어 메탈 설치에 유용합니다. 이러한 설치에는 기본 로드 밸런서 기능이 포함되어 있지 않기 때문입니다. 베어 메탈 설치 외에도 일부 인프라에 OpenShift Container Platform을 설치할 때 기본 로드 밸런서 기능이 포함되지 않을 수 있습니다. 예를 들어 다음 인프라는 MetalLB Operator를 추가하는 데 도움이 될 수 있습니다.

  • 베어 메탈
  • VMware vSphere
  • IBM Z 및 IBM® LinuxONE
  • IBM Z 및 IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
  • IBM Power

MetalLB Operator 및 MetalLB는 OpenShift SDN 및 OVN-Kubernetes 네트워크 공급자에서 지원됩니다.

33.1.7.2. 계층 2 모드에 대한 제한 사항
33.1.7.2.1. 단일 노드 성능 장애

MetalLB는 단일 노드를 통해 서비스에 대한 모든 트래픽을 라우팅합니다. 이 노드는 병목 현상을 일으키고 성능을 제한할 수 있습니다.

계층 2 모드는 서비스의 수신 대역폭을 단일 노드의 대역폭으로 제한합니다. 이는 ARP 및 NDP를 사용하여 트래픽을 전달하는 기본 제한 사항입니다.

33.1.7.2.2. 페일오버 성능 저하

노드 간 페일오버는 클라이언트와의 협업에 따라 달라집니다. 페일오버가 발생하면 MetalLB에서 적절한 ARP 패킷을 전송하여 서비스에 연결된 MAC 주소가 변경되었음을 알립니다.

대부분의 클라이언트 운영 체제는 적절한 ARP 패킷을 올바르게 처리하고 인접 캐시를 즉시 업데이트합니다. 클라이언트에서 캐시를 빠르게 업데이트하면 몇 초 내에 페일오버가 완료됩니다. 일반적으로 클라이언트는 10초 내에 새 노드로 페일오버합니다. 그러나 일부 클라이언트 운영 체제는 적절한 ARP 패킷을 전혀 처리하지 않거나 캐시 업데이트를 지연하는 오래된 구현을 보유하고 있습니다.

Windows, macOS 및 Linux와 같은 일반적인 운영 체제의 최신 버전은 계층 2 페일오버를 올바르게 구현합니다. 오래되고 덜 일반적인 클라이언트 운영 체제를 제외하고는 느린 페일오버 문제가 발생하지 않습니다.

계획된 페일오버가 오래된 클라이언트에 미치는 영향을 최소화하려면 리더십 전환 후 몇 분 동안 이전 노드를 계속 실행하십시오. 이전 노드는 캐시가 새로 고쳐질 때까지 오래된 클라이언트의 트래픽을 계속 전달할 수 있습니다.

계획되지 않은 페일오버가 발생하면 오래된 클라이언트가 캐시 항목을 새로 고칠 때까지 서비스 IP에 연결할 수 없습니다.

MetalLB 및 소스 Pod에 설정된 추가 네트워크 인터페이스에 동일한 VLAN을 사용하면 연결에 실패할 수 있습니다. 이는 MetalLB IP와 소스 Pod가 모두 동일한 노드에 있는 경우 발생합니다.

연결 실패를 방지하려면 소스 Pod가 있는 것과 다른 서브넷에 MetalLB IP를 배치합니다. 이 구성을 사용하면 소스 Pod의 트래픽이 기본 게이트웨이를 사용할 수 있습니다. 결과적으로 OVN 오버레이 네트워크를 사용하여 트래픽이 효과적으로 대상에 도달하여 연결이 의도한 대로 작동하도록 할 수 있습니다.

33.1.7.3. BGP 모드 제한 사항
33.1.7.3.1. 노드 장애로 모든 활성 연결이 중단될 수 있습니다.

MetalLB는 BGP 기반 로드 밸런싱에 공통된 제한을 공유합니다. BGP 세션이 종료되면 노드가 실패하거나 speaker Pod가 다시 시작되면 세션 종료로 모든 활성 연결이 재설정될 수 있습니다. 최종 사용자는 피어 메시지로 연결 재설정이 발생할 수 있습니다.

종료된 BGP 세션의 결과는 각 라우터 제조업체에 따라 구현되었습니다. 그러나 발표자 Pod 수가 변경되어 BGP 세션 수에 영향을 미치고 BGP 피어와의 활성 연결이 끊어질 것으로 예상할 수 있습니다.

서비스 중단 가능성을 방지하거나 줄이기 위해 BGP 피어를 추가할 때 노드 선택기를 지정할 수 있습니다. BGP 세션을 시작하는 노드 수를 제한함으로써 BGP 세션이 없는 노드의 결함은 서비스 연결에 영향을 미치지 않습니다.

33.1.7.3.2. 단일 ASN 및 단일 라우터 ID만 지원

BGP 피어 사용자 지정 리소스를 추가할 때 spec.myASN 필드를 지정하여 MetalLB가 속한 Autonomous System Number(ASN)를 식별합니다. OpenShift Container Platform은 MetalLB가 단일 ASN에 속해야 하는 MetalLB와 함께 BGP 구현을 사용합니다. BGP 피어를 추가하고 기존 BGP 피어 사용자 지정 리소스와 spec.myASN 에 대해 다른 값을 지정하려고 하면 오류가 발생합니다.

마찬가지로 BGP 피어 사용자 지정 리소스를 추가하면 spec.routerID 필드는 선택 사항입니다. 이 필드의 값을 지정하는 경우 추가하는 다른 모든 BGP 피어 사용자 정의 리소스에 대해 동일한 값을 지정해야 합니다.

단일 ASN 및 단일 라우터 ID를 지원하는 제한은 MetalLB의 커뮤니티 지원 구현과 다릅니다.

33.2. MetalLB Operator 설치

클러스터 관리자는 Operator가 클러스터에서 MetalLB 인스턴스의 라이프사이클을 관리할 수 있도록 MetallB Operator를 추가할 수 있습니다.

MetalLB 및 IP 페일오버가 호환되지 않습니다. 클러스터에 IP 페일오버를 구성한 경우 Operator를 설치하기 전에 IP 페일오버를 제거하는 단계를 수행합니다.

33.2.1. 웹 콘솔을 사용하여 OperatorHub에서 MetalLB Operator 설치

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

사전 요구 사항

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

절차

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub로 이동합니다.
  2. 키워드로 필터링 상자에 키워드 를 입력하거나 원하는 Operator를 찾습니다. 예를 들어 metallb를 입력하여 MetalLB Operator를 찾습니다.

    인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

  3. Operator 설치 페이지에서 기본값을 수락하고 설치를 클릭합니다.

검증

  1. 설치에 성공했는지 확인하려면 다음을 수행하십시오.

    1. Operator설치된 Operator 페이지로 이동합니다.
    2. Operator가 openshift-operators 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.
  2. Operator가 성공적으로 설치되지 않은 경우 Operator 상태를 확인하고 로그를 확인합니다.

    1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
    2. 워크로드Pod 페이지로 이동하여 openshift-operators 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.

33.2.2. CLI를 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하는 대신 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다. OpenShift CLI(oc)를 사용하여 MetalLB Operator를 설치할 수 있습니다.

Operator를 metallb-system 네임스페이스에 설치하는 CLI를 사용하는 것이 좋습니다.

사전 요구 사항

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

절차

  1. 다음 명령을 입력하여 MetalLB Operator의 네임스페이스를 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  2. 네임스페이스에 Operator group CR(사용자 정의 리소스)을 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  3. Operator group이 네임스페이스에 설치되어 있는지 확인합니다.

    $ oc get operatorgroup -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               AGE
    metallb-operator   14m
    Copy to Clipboard Toggle word wrap

  4. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일(예: metallb-sub.yaml )을 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator-sub
        namespace: metallb-system
      spec:
        channel: stable
        name: metallb-operator
        source: redhat-operators 
      1
      
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
      1
      redhat-operators 값을 지정해야 합니다.
    2. 서브스크립션 CR을 생성하려면 다음 명령을 실행합니다.

      $ oc create -f metallb-sub.yaml
      Copy to Clipboard Toggle word wrap
  5. 선택 사항: BGP 및 BFD 지표가 Prometheus에 표시되도록 하려면 다음 명령과 같이 네임스페이스에 라벨을 지정할 수 있습니다.

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
    Copy to Clipboard Toggle word wrap

검증

확인 단계에서는 MetalLB Operator가 metallb-system 네임스페이스에 설치되어 있다고 가정합니다.

  1. 설치 계획이 네임스페이스에 있는지 확인합니다.

    $ oc get installplan -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            CSV                                   APPROVAL    APPROVED
    install-wzg94   metallb-operator.4.13.0-nnnnnnnnnnnn   Automatic   true
    Copy to Clipboard Toggle word wrap

    참고

    Operator를 설치하는 데 몇 초가 걸릴 수 있습니다.

  2. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get clusterserviceversion -n metallb-system \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    출력 예

    Name                                  Phase
    metallb-operator.4.13.0-nnnnnnnnnnnn   Succeeded
    Copy to Clipboard Toggle word wrap

33.2.3. 클러스터에서 MetalLB 시작

Operator를 설치한 후 MetalLB 사용자 정의 리소스의 단일 인스턴스를 구성해야 합니다. 사용자 정의 리소스를 구성한 후 Operator는 클러스터에서 MetalLB를 시작합니다.

사전 요구 사항

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

절차

이 절차에서는 MetalLB Operator가 metallb-system 네임스페이스에 설치되어 있다고 가정합니다. 웹 콘솔을 사용하여 설치한 경우 네임스페이스의 openshift-operators 를 대체합니다.

  1. MetalLB 사용자 지정 리소스의 단일 인스턴스를 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap

검증

MetalLB 컨트롤러 및 MetalLB 발표자의 데몬 세트가 실행 중인지 확인합니다.

  1. 컨트롤러의 배포가 실행 중인지 확인합니다.

    $ oc get deployment -n metallb-system controller
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    controller   1/1     1            1           11m
    Copy to Clipboard Toggle word wrap

  2. speaker의 데몬 세트가 실행 중인지 확인합니다.

    $ oc get daemonset -n metallb-system speaker
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    speaker   6         6         6       6            6           kubernetes.io/os=linux   18m
    Copy to Clipboard Toggle word wrap

    예제 출력은 6개의 발표자 pod를 나타냅니다. 클러스터의 발표자 Pod 수는 예제 출력과 다를 수 있습니다. 출력에 클러스터의 각 노드에 하나의 pod가 표시되는지 확인합니다.

33.2.4. MetalLB의 배포 사양

MetalLB 사용자 정의 리소스를 사용하여 MetalLB의 인스턴스를 시작할 때 MetalLB 사용자 정의 리소스에서 배포 사양을 구성하여 컨트롤러 또는 발표자 Pod가 클러스터에서 배포 및 실행되는 방법을 관리할 수 있습니다. 이러한 배포 사양을 사용하여 다음 작업을 관리합니다.

  • MetalLB Pod 배포로 노드를 선택합니다.
  • Pod 우선순위 및 Pod 유사성을 사용하여 예약을 관리합니다.
  • MetalLB Pod의 CPU 제한을 할당합니다.
  • MetalLB Pod에 대한 컨테이너 RuntimeClass를 할당합니다.
  • MetalLB Pod의 메타데이터를 할당합니다.
33.2.4.1. 발표자 Pod를 특정 노드로 제한

기본적으로 MetalLB Operator를 사용하여 MetalLB를 시작하면 Operator는 클러스터의 각 노드에서 speaker Pod 인스턴스를 시작합니다. speaker pod가 있는 노드만 로드 밸런서 IP 주소를 알릴 수 있습니다. 노드 선택기를 사용하여 MetalLB 사용자 정의 리소스를 구성하여 speaker Pod를 실행하는 노드를 지정할 수 있습니다.

speaker pod를 특정 노드로 제한하는 가장 일반적인 이유는 특정 네트워크의 네트워크 인터페이스가 있는 노드만 로드 밸런서 IP 주소를 알리는 것입니다. 실행 중인 speaker pod가 있는 노드만 로드 밸런서 IP 주소의 대상으로 표시됩니다.

speaker Pod를 특정 노드로 제한하고 서비스의 외부 트래픽 정책에 대해 local 을 지정하는 경우 서비스의 애플리케이션 Pod가 동일한 노드에 배포되었는지 확인해야 합니다.

발표자 Pod를 작업자 노드로 제한하는 구성 예

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  <.>
    node-role.kubernetes.io/worker: ""
  speakerTolerations:   <.>
  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"
Copy to Clipboard Toggle word wrap

<.> 예제 구성은 speaker Pod를 작업자 노드에 할당하도록 지정하지만 노드 또는 유효한 노드 선택기에 할당한 라벨을 지정할 수 있습니다. <.> 이 예제 구성에서는 Operator 를 사용하여 값 및 effect 값과 일치하는 테인트를 허용하도록 이 허용 오차가 연결된 Pod입니다.

spec.nodeSelector 필드를 사용하여 매니페스트를 적용한 후 oc get daemonset -n metallb-system speaker 명령을 사용하여 Operator가 배포한 Pod 수를 확인할 수 있습니다. 마찬가지로 oc get nodes -l node-role.kubernetes.io/worker= 와 같은 명령을 사용하여 레이블과 일치하는 노드를 표시할 수 있습니다.

선택 옵션으로 노드에서 선호도 규칙을 사용하여 예약해야 하는 발표자 Pod를 제어하도록 허용할 수 있습니다. 허용 오차 목록을 적용하여 이러한 Pod를 제한할 수도 있습니다. 유사성 규칙, 테인트 및 허용 오차에 대한 자세한 내용은 추가 리소스를 참조하십시오.

33.2.4.2. MetalLB 배포에서 Pod 우선순위 및 Pod 유사성 구성

필요한 경우 MetalLB 사용자 정의 리소스를 구성하여 컨트롤러speaker Pod에 Pod 우선순위 및 Pod 유사성 규칙을 할당할 수 있습니다. Pod 우선순위는 노드에서 Pod의 상대적 중요도를 나타내며 이 우선 순위에 따라 Pod를 예약합니다. 컨트롤러 또는 발표자 Pod에서 높은 우선 순위를 설정하여 노드의 다른 Pod보다 우선 순위를 유지합니다.

Pod 유사성은 Pod 간 관계를 관리합니다. 컨트롤러 또는 발표자 Pod에 Pod 유사성을 할당하여 스케줄러가 Pod 관계 컨텍스트에서 Pod를 배치하는 노드를 제어합니다. 예를 들어 Pod 유사성 규칙을 사용하여 특정 Pod가 동일한 노드 또는 노드에 위치하도록 할 수 있으므로 네트워크 통신을 개선하고 해당 구성 요소 간의 대기 시간을 줄일 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MetalLB Operator가 설치되어 있습니다.
  • 클러스터에서 MetalLB Operator를 시작했습니다.

절차

  1. 우선 순위 수준을 구성하기 위해 my PriorityClass.yaml과 같은 PriorityClass 사용자 정의 리소스를 생성합니다. 이 예제에서는 값이 1000000high-priority 라는 PriorityClass 를 정의합니다. 이 우선순위 클래스가 할당된 Pod는 우선순위가 낮은 Pod에 비해 예약 중에 더 높은 우선 순위로 간주됩니다.

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: high-priority
    value: 1000000
    Copy to Clipboard Toggle word wrap
  2. PriorityClass 사용자 정의 리소스 구성을 적용합니다.

    $ oc apply -f myPriorityClass.yaml
    Copy to Clipboard Toggle word wrap
  3. MetalLB PodConfig.yaml 과 같은 MetalLB 사용자 정의 리소스를 생성하여 priorityClassNamepodAffinity 값을 지정합니다.

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        priorityClassName: high-priority 
    1
    
        affinity:
          podAffinity: 
    2
    
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
      speakerConfig:
        priorityClassName: high-priority
        affinity:
          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
    Copy to Clipboard Toggle word wrap
    1
    MetalLB 컨트롤러 Pod의 우선순위 클래스를 지정합니다. 이 경우 높은 우선 순위로 설정됩니다.
    2
    Pod 유사성 규칙을 구성하도록 지정합니다. 이러한 규칙은 다른 Pod 또는 노드와 관련하여 Pod를 예약하는 방법을 지정합니다. 이 구성은 스케줄러에서 동일한 호스트 이름을 공유하는 노드에 app: metallb 레이블이 있는 Pod를 예약하도록 지시합니다. 이렇게 하면 동일한 노드에서 MetalLB 관련 Pod를 공동 배치하여 이러한 Pod 간 네트워크 통신, 대기 시간 및 리소스 사용량을 최적화할 수 있습니다.
  4. MetalLB 사용자 정의 리소스 구성을 적용합니다.

    $ oc apply -f MetalLBPodConfig.yaml
    Copy to Clipboard Toggle word wrap

검증

  • metallb-system 네임스페이스에서 Pod에 할당한 우선순위 클래스를 보려면 다음 명령을 실행합니다.

    $ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                 PRIORITY
    controller-584f5c8cd8-5zbvg                          high-priority
    metallb-operator-controller-manager-9c8d9985-szkqg   <none>
    metallb-operator-webhook-server-c895594d4-shjgx      <none>
    speaker-dddf7                                        high-priority
    Copy to Clipboard Toggle word wrap

  • 스케줄러가 Pod 유사성 규칙에 따라 Pod를 배치했는지 확인하려면 다음 명령을 실행하여 Pod 노드 또는 노드의 메타데이터를 확인합니다.

    $ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
    Copy to Clipboard Toggle word wrap
33.2.4.3. MetalLB 배포에서 Pod CPU 제한 구성

필요한 경우 MetalLB 사용자 정의 리소스를 구성하여 컨트롤러발표 Pod에 Pod CPU 제한을 할당할 수 있습니다. 컨트롤러 또는 발표자 Pod에 대한 CPU 제한을 정의하면 노드에서 컴퓨팅 리소스를 관리할 수 있습니다. 이렇게 하면 노드의 모든 Pod에 워크로드 및 클러스터 하우스키핑을 관리하는 데 필요한 컴퓨팅 리소스가 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MetalLB Operator가 설치되어 있습니다.

절차

  1. CPULimits.yaml 과 같은 MetalLB 사용자 정의 리소스 파일을 생성하여 컨트롤러발표자 Pod의 cpu 값을 지정합니다.

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        resources:
          limits:
            cpu: "200m"
      speakerConfig:
        resources:
          limits:
            cpu: "300m"
    Copy to Clipboard Toggle word wrap
  2. MetalLB 사용자 정의 리소스 구성을 적용합니다.

    $ oc apply -f CPULimits.yaml
    Copy to Clipboard Toggle word wrap

검증

  • Pod의 컴퓨팅 리소스를 보려면 다음 명령을 실행하여 < pod_name >을 대상 Pod로 교체합니다.

    $ oc describe pod <pod_name>
    Copy to Clipboard Toggle word wrap

33.2.6. 다음 단계

33.3. CloudEvent 업그레이드

현재 버전 4.10 또는 이전 버전의 ScanSetting Operator를 실행 중인 경우 4.10 이후 버전에 대한 자동 업데이트가 작동하지 않습니다. 4.11 이상인 모든 version of theECDHE Operator에서 최신 버전으로 업그레이드할 수 있습니다. 예를 들어 버전 4.12에서 버전 4.13으로의 업그레이드가 원활하게 수행됩니다.

4.10 및 이전 버전에서 CloudEvent Operator의 업그레이드 절차에 대한 요약은 다음과 같습니다.

  1. 4.10과 같이 설치된 ScanSetting Operator 버전을 삭제합니다. 네임스페이스 및 metallb 사용자 정의 리소스가 제거되지 않았는지 확인합니다.
  2. CLI를 사용하여 이전 버전의 CloudEvent Operator가 설치된 것과 동일한 네임스페이스에 ScanSetting Operator 4.13을 설치합니다.
참고

이 절차는 표준 간단한 방법을 따르는 MetalLB Operator의 z-stream 자동 업데이트에 적용되지 않습니다.

4.10 및 이전 버전에서 CloudEvent Operator를 업그레이드하는 자세한 단계는 다음 지침을 참조하십시오. 클러스터 관리자는 OpenShift CLI(oc) 또는 웹 콘솔을 사용하여 MetalLB Operator를 삭제하여 업그레이드 프로세스를 시작합니다.

33.3.1. 웹 콘솔을 사용하여 클러스터에서 MetalLB Operator 삭제

클러스터 관리자는 웹 콘솔을 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터 웹 콘솔에 액세스할 수 있습니다.

절차

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. MetalLB Operator를 검색합니다. 그런 다음 해당 Operator를 클릭합니다.
  3. Operator 상세 정보 페이지 오른쪽에 있는 작업 드롭다운 메뉴에서 Operator 제거를 선택합니다.

    Operator를 설치 제거하시겠습니까? 대화 상자가 표시됩니다.

  4. 설치 제거를 선택하여 Operator, Operator 배포 및 Pod를 제거합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.

    참고

    이 작업은 CRD(사용자 정의 리소스 정의) 및 CR(사용자 정의 리소스)을 포함하여 Operator에서 관리하는 리소스를 제거하지 않습니다. 웹 콘솔에서 활성화된 대시보드 및 탐색 항목과 계속 실행되는 클러스터 외부 리소스는 수동 정리가 필요할 수 있습니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.

33.3.2. CLI를 사용하여 클러스터에서 MetalLB Operator 삭제

클러스터 관리자는 CLI를 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • oc 명령이 워크스테이션에 설치되어 있습니다.

절차

  1. currentCSV 필드에서 구독한 MetalLB Operator의 현재 버전을 확인합니다.

    $ oc get subscription metallb-operator -n metallb-system -o yaml | grep currentCSV
    Copy to Clipboard Toggle word wrap

    출력 예

      currentCSV: metallb-operator.4.10.0-202207051316
    Copy to Clipboard Toggle word wrap

  2. 서브스크립션을 삭제합니다.

    $ oc delete subscription metallb-operator -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    subscription.operators.coreos.com "metallb-operator" deleted
    Copy to Clipboard Toggle word wrap

  3. 이전 단계의 currentCSV 값을 사용하여 대상 네임스페이스에서 Operator의 CSV를 삭제합니다.

    $ oc delete clusterserviceversion metallb-operator.4.10.0-202207051316 -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    clusterserviceversion.operators.coreos.com "metallb-operator.4.10.0-202207051316" deleted
    Copy to Clipboard Toggle word wrap

33.3.3. MetalLB Operator group 편집

MetalLB Operator 버전에서 4.10에서 4.11 이상으로 포함하는 경우 Operator group CR(사용자 정의 리소스)에서 spec.targetNamespaces 를 제거합니다. 웹 콘솔을 사용했는지 또는 CLI를 사용하여 MetalLB Operator를 삭제하는지 여부와 관계없이 사양을 제거해야 합니다.

참고

MetalLB Operator 버전 4.11 이상은 AllNamespaces 설치 모드만 지원하지만 4.10 또는 이전 버전은 OwnNamespace 또는 SingleNamespace 모드를 지원합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 다음 명령을 실행하여 metallb-system 네임스페이스에 Operator 그룹을 나열합니다.

    $ oc get operatorgroup -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                   AGE
    metallb-system-7jc66   85m
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 metallb-system 네임스페이스와 연결된 Operator group CR에 spec.targetNamespaces 가 있는지 확인합니다.

    $ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      annotations:
        olm.providedAPIs: ""
      creationTimestamp: "2023-10-25T09:42:49Z"
      generateName: metallb-system-
      generation: 1
      name: metallb-system-7jc66
      namespace: metallb-system
      resourceVersion: "25027"
      uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3
    spec:
      targetNamespaces:
      - metallb-system
      upgradeStrategy: Default
    status:
      lastUpdated: "2023-10-25T09:42:49Z"
      namespaces:
      - metallb-system
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 Operator group을 편집하고 spec 섹션 아래에 있는 targetNamespacesmetallb-system 을 제거합니다.

    $ oc edit n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    operatorgroup.operators.coreos.com/metallb-system-7jc66 edited
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 metallb-system 네임스페이스와 연결된 Operator group 사용자 정의 리소스에서 spec.targetNamespaces 가 제거되었는지 확인합니다.

    $ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      annotations:
        olm.providedAPIs: ""
      creationTimestamp: "2023-10-25T09:42:49Z"
      generateName: metallb-system-
      generation: 2
      name: metallb-system-7jc66
      namespace: metallb-system
      resourceVersion: "61658"
      uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3
    spec:
      upgradeStrategy: Default
    status:
      lastUpdated: "2023-10-25T14:31:30Z"
      namespaces:
      - ""
    Copy to Clipboard Toggle word wrap

33.3.4. MetalLB Operator 업그레이드

사전 요구 사항

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

절차

  1. metallb-system 네임스페이스가 여전히 있는지 확인합니다.

    $ oc get namespaces | grep metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    metallb-system                                     Active   31m
    Copy to Clipboard Toggle word wrap

  2. metallb 사용자 정의 리소스가 여전히 존재하는지 확인합니다.

    $ oc get metallb -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      AGE
    metallb   33m
    Copy to Clipboard Toggle word wrap

  3. "CLI를 사용하여 OperatorHub에서 설치"의 지침에 따라 MetalLB Operator의 최신 4.13 버전을 설치합니다.

    참고

    MetalLB Operator의 최신 4.13 버전을 설치할 때 Operator를 이전에 설치한 동일한 네임스페이스에 설치해야 합니다.

  4. 업그레이드된 Operator 버전이 이제 4.13 버전인지 확인합니다.

    $ oc get csv -n metallb-system
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                   DISPLAY            VERSION               REPLACES   PHASE
    metallb-operator.4.13.0-202207051316   MetalLB Operator   4.13.0-202207051316              Succeeded
    Copy to Clipboard Toggle word wrap

33.3.5. 추가 리소스

33.4. MetalLB 주소 풀 구성

클러스터 관리자는 주소 풀을 추가, 수정, 삭제할 수 있습니다. MetalLB Operator는 주소 풀 사용자 정의 리소스를 사용하여 MetalLB에서 서비스에 할당할 수 있는 IP 주소를 설정합니다. 예제에 사용되는 네임스페이스는 네임스페이스가 metallb-system 이라고 가정합니다.

33.4.1. IPAddressPool 사용자 정의 리소스 정보

참고

OpenShift Container Platform 4.10의 " MetalLB를 사용한 "Load balancing with MetalLB"에 설명된 주소 풀 CRD(Custom Resource Definition) 및 API는 4.13에서 계속 사용할 수 있습니다. 그러나 계층 2 프로토콜 또는 BGP 프로토콜을 사용하여 IPAddressPool 에서 IP 주소를 알리는 것과 관련된 향상된 기능은 AddressPool CRD를 사용할 때 지원되지 않습니다.

IPAddressPool 사용자 정의 리소스의 필드는 다음 표에 설명되어 있습니다.

Expand
표 33.1. MetalLB IPAddressPool pool 사용자 정의 리소스
필드유형설명

metadata.name

string

주소 풀의 이름을 지정합니다. 서비스를 추가할 때 metallb.universe.tf/address-pool 주석에 이 풀 이름을 지정하여 특정 풀에서 IP 주소를 선택할 수 있습니다. 문서 전체에서 doc-example, silver, gold라는 이름이 사용됩니다.

metadata.namespace

string

주소 풀의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.

metadata.label

string

선택 사항: IPAddressPool 에 할당된 키 값 쌍을 지정합니다. 이는 IPAddressPool 을 광고와 연결하기 위해 BGPAdvertisementL2Advertisement CRD의 ipAddressPoolSelectors 에서 참조할 수 있습니다.

spec.addresses

string

MetalLB Operator의 IP 주소 목록을 서비스에 할당할 수 있도록 지정합니다. 단일 풀에 여러 범위를 지정할 수 있습니다. 모두 동일한 설정을 공유합니다. CIDR 표기법에서 각 범위를 지정하거나 하이픈으로 구분된 시작 및 끝 IP 주소로 지정합니다.

spec.autoAssign

boolean

선택 사항: MetalLB에서 이 풀에서 IP 주소를 자동으로 할당하는지 여부를 지정합니다. metallb.universe.tf/address-pool 주석을 사용하여 이 풀에서 IP 주소를 명시적으로 요청하려면 false 를 지정합니다. 기본값은 true입니다.

spec.avoidBuggyIPs

boolean

선택 사항: IP 주소가 .0 및 .255로 끝나는 경우 풀에서 할당되지 않도록 합니다. 기본값은 false입니다. 일부 이전 소비자 네트워크 장치는 .0 및 .255로 끝나는 IP 주소를 실수로 차단합니다.

spec.serviceAllocation 사양을 구성하여 IPAddressPool 의 IP 주소를 서비스 및 네임스페이스에 할당할 수 있습니다.

Expand
표 33.2. ScanSetting IPAddressPool 사용자 정의 리소스 spec.serviceAllocation 하위 필드
필드유형설명

priority

int

선택 사항: 둘 이상의 IP 주소 풀이 서비스 또는 네임스페이스와 일치하는 경우 IP 주소 풀 간 우선 순위를 정의합니다. 숫자가 작을수록 우선순위가 높습니다.

네임스페이스

배열(문자열)

선택 사항: IP 주소 풀의 IP 주소에 할당할 수 있는 네임스페이스 목록을 지정합니다.

namespaceSelectors

array (LabelSelector)

선택 사항: 목록 형식의 라벨 선택기를 사용하여 IP 주소 풀에서 IP 주소에 할당할 수 있는 네임스페이스 레이블을 지정합니다.

serviceSelectors

array (LabelSelector)

선택 사항: 목록 형식의 라벨 선택기를 사용하여 주소 풀에서 IP 주소에 할당할 수 있는 서비스 레이블을 지정합니다.

33.4.2. 주소 풀 구성

클러스터 관리자는 클러스터에 주소 풀을 추가하여 MetalLB가 부하 분산 서비스에 할당할 수 있는 IP 주소를 제어할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      namespace: metallb-system
      name: doc-example
      labels: 
    1
    
        zone: east
    spec:
      addresses:
      - 203.0.113.1-203.0.113.10
      - 203.0.113.65-203.0.113.75
    Copy to Clipboard Toggle word wrap
    1
    IPAddressPool 에 할당된 이 레이블은 BGPAdvertisement CRD의 ipAddressPoolSelectors 에서 참조하여 IPAddressPool 을 광고와 연결할 수 있습니다.
  2. IP 주소 풀에 대한 구성을 적용합니다.

    $ oc apply -f ipaddresspool.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 주소 풀을 확인합니다.

    $ oc describe -n metallb-system IPAddressPool doc-example
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:         doc-example
    Namespace:    metallb-system
    Labels:       zone=east
    Annotations:  <none>
    API Version:  metallb.io/v1beta1
    Kind:         IPAddressPool
    Metadata:
      ...
    Spec:
      Addresses:
        203.0.113.1-203.0.113.10
        203.0.113.65-203.0.113.75
      Auto Assign:  true
    Events:         <none>
    Copy to Clipboard Toggle word wrap

주소 풀 이름(예: doc-example ) 및 IP 주소 범위가 출력에 표시되는지 확인합니다.

33.4.3. 주소 풀 구성의 예

33.4.3.1. 예: IPv4 및 CIDR 범위

CIDR 표기법에서 IP 주소 범위를 지정할 수 있습니다. 하이픈을 사용하는 표기법과 CIDR 표기법을 결합하여 하한 및 상한을 분리할 수 있습니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-cidr
  namespace: metallb-system
spec:
  addresses:
  - 192.168.100.0/24
  - 192.168.200.0/24
  - 192.168.255.1-192.168.255.5
Copy to Clipboard Toggle word wrap
33.4.3.2. 예: IP 주소

MetalLB가 풀에서 IP 주소를 자동으로 할당하지 못하도록 autoAssign 필드를 false 로 설정할 수 있습니다. 서비스를 추가할 때 풀에서 특정 IP 주소를 요청하거나 주석에 풀 이름을 지정하여 풀에서 IP 주소를 요청할 수 있습니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-reserved
  namespace: metallb-system
spec:
  addresses:
  - 10.0.100.0/28
  autoAssign: false
Copy to Clipboard Toggle word wrap
33.4.3.3. 예: IPv4 및 IPv6 주소

IPv4 및 IPv6을 사용하는 주소 풀을 추가할 수 있습니다. 여러 IPv4 예제와 마찬가지로 address 목록에 여러 범위를 지정할 수 있습니다.

서비스에 단일 IPv4 주소, 단일 IPv6 주소 또는 둘 다 서비스를 추가하는 방법에 따라 결정됩니다. spec.ipFamiliesspec.ipFamilyPolicy 필드는 서비스에 IP 주소를 할당하는 방법을 제어합니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-combined
  namespace: metallb-system
spec:
  addresses:
  - 10.0.100.0/28
  - 2002:2:2::1-2002:2:2::100
Copy to Clipboard Toggle word wrap
33.4.3.4. 예: 서비스 또는 네임스페이스에 IP 주소 풀 할당

IPAddressPool 의 IP 주소를 지정한 서비스 및 네임스페이스에 할당할 수 있습니다.

서비스 또는 네임스페이스를 두 개 이상의 IP 주소 풀에 할당하는 경우 CloudEvent는 우선순위가 높은 IP 주소 풀에서 사용 가능한 IP 주소를 사용합니다. 우선 순위가 높은 할당된 IP 주소 풀에서 IP 주소를 사용할 수 없는 경우 CloudEvent는 우선 순위가 높은 IP 주소 풀에서 사용 가능한 IP 주소를 사용합니다.

참고

matchLabels 라벨 선택기, matchExpressions 라벨 선택기 또는 둘 다 namespaceSelectorsserviceSelectors 사양에 사용할 수 있습니다. 이 예제에서는 각 사양에 대해 하나의 라벨 선택기를 보여줍니다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: doc-example-service-allocation
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.0/24
  serviceAllocation:
    priority: 50 
1

    namespaces: 
2

      - namespace-a
      - namespace-b
    namespaceSelectors: 
3

      - matchLabels:
          zone: east
    serviceSelectors: 
4

      - matchExpressions:
        - key: security
          operator: In
          values:
          - S1
Copy to Clipboard Toggle word wrap
1
주소 풀에 우선 순위를 할당합니다. 숫자가 작을수록 우선순위가 높습니다.
2
목록 형식의 IP 주소 풀에 하나 이상의 네임스페이스를 할당합니다.
3
목록 형식의 라벨 선택기를 사용하여 IP 주소 풀에 하나 이상의 네임스페이스 레이블을 할당합니다.
4
목록 형식의 라벨 선택기를 사용하여 IP 주소 풀에 하나 이상의 서비스 레이블을 할당합니다.

33.4.4. 다음 단계

33.5. IP 주소 풀 광고 정보

IP 주소가 계층 2 프로토콜, BGP 프로토콜 또는 둘 다로 알려지도록 MetalLB를 구성할 수 있습니다. 계층 2에서 MetalLB는 내결함성 외부 IP 주소를 제공합니다. BGP를 사용하면 MetalLB는 외부 IP 주소 및 로드 밸런싱에 대한 내결함성을 제공합니다.

MetalLB는 동일한 IP 주소 세트에 L2 및 BGP를 사용한 알림을 지원합니다.

MetalLB는 특정 BGP 피어에 주소 풀을 네트워크 상의 노드 서브 세트에 효과적으로 할당할 수 있는 유연성을 제공합니다. 이를 통해 더 복잡한 구성(예: 노드의 격리 또는 네트워크 분할)이 가능합니다.

33.5.1. BGPAdvertisement 사용자 정의 리소스 정보

BGPAdvertisements 오브젝트의 필드는 다음 표에 정의되어 있습니다.

Expand
표 33.3. BGPAdvertisements 구성
필드유형설명

metadata.name

string

BGP 알림의 이름을 지정합니다.

metadata.namespace

string

BGP 알림의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.

spec.aggregationLength

integer

선택 사항: 32비트 CIDR 마스크에 포함할 비트 수를 지정합니다. 발표자가 BGP 피어에 알리는 경로를 집계하기 위해 마스크는 여러 서비스 IP 주소의 경로에 적용되며, 발표자는 집계된 경로를 알립니다. 예를 들어 집계 길이가 24 인 경우 speaker는 여러 10.0.1.x/32 서비스 IP 주소를 집계하고 단일 10.0.1.0/24 경로를 알릴 수 있습니다.

spec.aggregationLengthV6

integer

선택 사항: 128비트 CIDR 마스크에 포함할 비트 수를 지정합니다. 예를 들어 집계 길이가 124 인 경우 speaker는 여러 fc00:f853:0ccd:e799::x/128 서비스 IP 주소를 집계하고 단일 fc00:f853:0ccd:e799::0/124 경로를 알릴 수 있습니다.

spec.communities

string

선택 사항: 하나 이상의 BGP 커뮤니티를 지정합니다. 각 커뮤니티는 콜론 문자로 구분된 두 개의 16비트 값으로 지정됩니다. 잘 알려진 커뮤니티는 16비트 값으로 지정해야 합니다.

  • NO_EXPORT: 65535:65281
  • NO_ADVERTISE: 65535:65282
  • NO_EXPORT_SUBCONFED: 65535:65283

    참고

    문자열과 함께 생성된 커뮤니티 오브젝트를 사용할 수도 있습니다.

spec.localPref

integer

선택 사항: 이 알림의 로컬 기본 설정을 지정합니다. 이 BGP 속성은 Autonomous System 내의 BGP 세션에 적용됩니다.

spec.ipAddressPools

string

선택 사항: 이 광고와 함께 광고할 IPAddressPools 목록입니다. 이름별로 선택됩니다.

spec.ipAddressPoolSelectors

string

선택 사항: 이 광고와 함께 광고되는 IPAddressPool 에 대한 선택기입니다. IPAddressPool 을 이름 자체 대신 IPAddressPool 에 할당된 레이블을 기반으로 광고에 연결하기 위한 것입니다. 이 또는 목록에 의해 선택된 IPAddressPool 이 없는 경우, 광고는 모든 IPAddressPools 에 적용됩니다.

spec.nodeSelectors

string

선택 사항: NodeSelectors 를 사용하면 로드 밸런서 IP의 다음 홉으로 노드를 알릴 수 있습니다. 비어 있으면 모든 노드가 다음 홉으로 표시됩니다.

spec.peers

string

선택 사항: 피어는 BGP 피어를 제한하여 선택한 풀의 IP를 다음과 같이 알립니다. 비어 있으면 로드 밸런서 IP가 구성된 모든 BGP 피어에 표시됩니다.

33.5.2. BGP 알림 및 기본 사용 사례를 사용하여 MetalLB 구성

피어 BGP 라우터가 203.0.113.200/32 경로를 수신하고 MetalLB에서 서비스에 할당하는 각 로드 밸런서 IP 주소에 대해 fc00:f853:ccd:e799::1/128 경로를 수신하도록 MetalLB를 다음과 같이 구성합니다. localPref 및 community 필드를 지정하지 않으므로 localPref 가 0으로 설정되고 BGP 커뮤니티가 없는 상태에서 경로가 광고됩니다.

33.5.2.1. 예: BGP를 사용하여 기본 주소 풀 구성 확인

IPAddressPool 이 BGP 프로토콜과 함께 알리도록 다음과 같이 MetalLB를 구성합니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-bgp-basic
      spec:
        addresses:
          - 203.0.113.200/30
          - fc00:f853:ccd:e799::/124
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. BGP 알림을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgpadvertisement-basic
        namespace: metallb-system
      spec:
        ipAddressPools:
        - doc-example-bgp-basic
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement.yaml
      Copy to Clipboard Toggle word wrap

33.5.3. BGP 알림 및 고급 사용 사례를 사용하여 MetalLB 구성

MetalLB가 203.0.113.200203.0.113.203 사이의 범위에서 로드 밸런서 서비스에 IP 주소를 할당하고 fc00:f853:ccd:e799::0fc00:f853:ccd:e799::f.

두 개의 BGP 알림을 설명하려면 MetalLB에서 203.0.113.200 의 IP 주소를 서비스에 할당할 때 인스턴스를 고려하십시오. 이 IP 주소를 예로 들어, 발표자는 BGP 피어에 대한 두 개의 경로를 알립니다.

  • 203.0.113.200/32, localPref100 으로 설정되고 커뮤니티는 NO_ADVERTISE 커뮤니티의 숫자 값으로 설정됩니다. 이 사양은 이 경로를 사용할 수 있다는 피어 라우터에 표시되지만 이 경로에 대한 정보를 BGP 피어에 전파해서는 안 됩니다.
  • 203.0.113.200/30 은 MetalLB에서 할당한 로드 밸런서 IP 주소를 단일 경로로 집계합니다. MetalLB는 8000:800 으로 설정된 커뮤니티 특성을 사용하여 집계된 경로를 BGP 피어로 알립니다. BGP 피어는 203.0.113.200/30 경로를 다른 BGP 피어에 전파합니다. 트래픽이 speaker가 있는 노드로 라우팅되는 경우 203.0.113.200/32 경로는 트래픽을 클러스터로 전달하고 서비스와 연결된 Pod에 사용됩니다.

더 많은 서비스를 추가하고 MetalLB는 풀에서 더 많은 로드 밸런서 IP 주소를 할당하면 피어 라우터는 각 서비스에 대해 하나의 로컬 경로와 203.0.113.200/30 집계 경로를 수신합니다. 추가하는 각 서비스는 /30 경로를 생성하지만 MetalLB는 피어 라우터와 통신하기 전에 경로를 하나의 BGP 광고에 중복시킵니다.

33.5.3.1. 예: BGP를 사용하여 고급 주소 풀 구성 확인

IPAddressPool 이 BGP 프로토콜과 함께 알리도록 다음과 같이 MetalLB를 구성합니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-bgp-adv
        labels:
          zone: east
      spec:
        addresses:
          - 203.0.113.200/30
          - fc00:f853:ccd:e799::/124
        autoAssign: false
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. BGP 알림을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement1.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgpadvertisement-adv-1
        namespace: metallb-system
      spec:
        ipAddressPools:
          - doc-example-bgp-adv
        communities:
          - 65535:65282
        aggregationLength: 32
        localPref: 100
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement1.yaml
      Copy to Clipboard Toggle word wrap
    3. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement2.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgpadvertisement-adv-2
        namespace: metallb-system
      spec:
        ipAddressPools:
          - doc-example-bgp-adv
        communities:
          - 8000:800
        aggregationLength: 30
        aggregationLengthV6: 124
      Copy to Clipboard Toggle word wrap
    4. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement2.yaml
      Copy to Clipboard Toggle word wrap

33.5.4. 노드 서브 세트에서 IP 주소 풀을 표시

특정 노드 세트에서만 IP 주소 풀에서 IP 주소를 알리려면 BGPAdvertisement 사용자 정의 리소스에서 .spec.nodeSelector 사양을 사용합니다. 이 사양은 IP 주소 풀을 클러스터의 노드 세트와 연결합니다. 이는 클러스터의 다른 서브넷에 있는 노드가 있고 특정 서브넷의 주소 풀에서 IP 주소를 알리려는 경우 유용합니다(예: 공용 서브넷).

사전 요구 사항

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

절차

  1. 사용자 정의 리소스를 사용하여 IP 주소 풀을 생성합니다.

    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      namespace: metallb-system
      name: pool1
    spec:
      addresses:
        - 4.4.4.100-4.4.4.200
        - 2001:100:4::200-2001:100:4::400
    Copy to Clipboard Toggle word wrap
  2. BGPAdvertisement 사용자 정의 리소스에서 .spec.nodeSelector 값을 정의하여 클러스터의 IP 주소를 알릴 노드를 제어합니다.

    apiVersion: metallb.io/v1beta1
    kind: BGPAdvertisement
    metadata:
      name: example
    spec:
      ipAddressPools:
      - pool1
      nodeSelector:
      - matchLabels:
          kubernetes.io/hostname: NodeA
      - matchLabels:
          kubernetes.io/hostname: NodeB
    Copy to Clipboard Toggle word wrap

이 예에서 pool1 의 IP 주소는 NodeANodeB 에서만 알립니다.

33.5.5. L2Advertisement 사용자 정의 리소스 정보

l2Advertisements 오브젝트의 필드는 다음 표에 정의되어 있습니다.

Expand
표 33.4. L2 알림 설정
필드유형설명

metadata.name

string

L2 알림의 이름을 지정합니다.

metadata.namespace

string

L2 알림의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.

spec.ipAddressPools

string

선택 사항: 이 광고와 함께 광고할 IPAddressPools 목록입니다. 이름별로 선택됩니다.

spec.ipAddressPoolSelectors

string

선택 사항: 이 광고와 함께 광고되는 IPAddressPool 에 대한 선택기입니다. IPAddressPool 을 이름 자체 대신 IPAddressPool 에 할당된 레이블을 기반으로 광고에 연결하기 위한 것입니다. 이 또는 목록에 의해 선택된 IPAddressPool 이 없는 경우, 광고는 모든 IPAddressPools 에 적용됩니다.

spec.nodeSelectors

string

선택 사항: NodeSelectors 는 로드 밸런서 IP의 다음 홉으로 노드를 알리도록 제한합니다. 비어 있으면 모든 노드가 다음 홉으로 표시됩니다.

중요

다음 홉으로 알릴 노드를 제한하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

spec.interfaces

string

선택 사항: 로드 밸런서 IP를 알리는 데 사용되는 인터페이스 목록입니다.

33.5.6. L2 알림을 사용하여 MetalLB 구성

IPAddressPool 이 L2 프로토콜과 함께 알리도록 다음과 같이 MetalLB를 구성합니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-l2
      spec:
        addresses:
          - 4.4.4.0/24
        autoAssign: false
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. L2 알림을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 l2advertisement.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
         - doc-example-l2
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f l2advertisement.yaml
      Copy to Clipboard Toggle word wrap

33.5.7. L2 알림 및 라벨을 사용하여 MetalLB 구성

BGPAdvertisementL2Advertisement 사용자 정의 리소스 정의의 ipAddressPoolSelectors 필드는 이름 자체 대신 IPAddressPool 에 할당된 레이블을 기반으로 IPAddressPool 을 광고에 연결하는 데 사용됩니다.

이 예제에서는 ipAddressPoolSelectors 필드를 구성하여 IPAddressPool Pool이 L2 프로토콜로 광고되도록 MetalLB를 구성하는 방법을 보여줍니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-l2-label
        labels:
          zone: east
      spec:
        addresses:
          - 172.31.249.87/32
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. ipAddressPoolSelectors 를 사용하여 IP를 알리는 L2 광고를 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 l2advertisement.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement-label
        namespace: metallb-system
      spec:
        ipAddressPoolSelectors:
          - matchExpressions:
              - key: zone
                operator: In
                values:
                  - east
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f l2advertisement.yaml
      Copy to Clipboard Toggle word wrap

33.5.8. 선택한 인터페이스에 대한 L2 알림을 사용하여 ScanSetting 구성

기본적으로 서비스에 할당된 IP 주소 풀의 IP 주소는 모든 네트워크 인터페이스에서 알립니다. L2Advertisement 사용자 정의 리소스 정의의 interfaces 필드는 IP 주소 풀을 알리는 네트워크 인터페이스를 제한하는 데 사용됩니다.

이 예제에서는 IP 주소 풀이 모든 노드의 interfaces 필드에 나열된 네트워크 인터페이스에서만 광고되도록 MetalLB를 구성하는 방법을 보여줍니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. ipaddresspool.yaml 과 같은 파일을 생성하고 다음 예와 같은 구성 세부 정보를 입력합니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-l2
      spec:
        addresses:
          - 4.4.4.0/24
        autoAssign: false
      Copy to Clipboard Toggle word wrap
    2. 다음 예제와 같이 IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. 인터페이스 선택기를 사용하여 IP를 알리는 L2 광고를 만듭니다.

    1. l2advertisement.yaml 과 같은 YAML 파일을 생성하고 다음 예와 같은 구성 세부 정보를 입력합니다.

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
         - doc-example-l2
         interfaces:
         - interfaceA
         - interfaceB
      Copy to Clipboard Toggle word wrap
    2. 다음 예제와 같이 광고의 구성을 적용합니다.

      $ oc apply -f l2advertisement.yaml
      Copy to Clipboard Toggle word wrap
중요

인터페이스 선택기는 L2를 사용하여 지정된 IP를 알릴 노드를 선택하는 방법에는 영향을 미치지 않습니다. 노드에 선택된 인터페이스가 없는 경우 선택한 노드는 서비스를 알리지 않습니다.

33.6. MetalLB BGP 피어 구성

클러스터 관리자는 BGP(Border Gateway Protocol) 피어를 추가, 수정, 삭제할 수 있습니다. MetalLB Operator는 BGP 피어 사용자 정의 리소스를 사용하여 MetalLB 발표 Pod가 BGP 세션을 시작하기 위해 연결하는 피어를 식별합니다. 피어는 MetalLB가 서비스에 할당하는 로드 밸런서 IP 주소에 대한 경로 알림을 받습니다.

33.6.1. BGP 피어 사용자 정의 리소스 정보

BGP 피어 사용자 정의 리소스의 필드는 다음 표에 설명되어 있습니다.

Expand
표 33.5. MetalLB BGP 피어 사용자 정의 리소스
필드유형설명

metadata.name

string

BGP 피어 사용자 정의 리소스의 이름을 지정합니다.

metadata.namespace

string

BGP 피어 사용자 정의 리소스의 네임스페이스를 지정합니다.

spec.myASN

integer

BGP 세션의 로컬 끝에 대한 Autonomous System 번호를 지정합니다. 추가하는 모든 BGP 피어 사용자 정의 리소스에 동일한 값을 지정합니다. 범위는 0 에서 4294967295 입니다.

spec.peerASN

integer

BGP 세션의 원격 끝에 대한 Autonomous System 번호를 지정합니다. 범위는 0 에서 4294967295 입니다.

spec.peerAddress

string

BGP 세션을 설정하기 위해 연결할 피어의 IP 주소를 지정합니다.

spec.sourceAddress

string

선택 사항: BGP 세션을 설정할 때 사용할 IP 주소를 지정합니다. 값은 IPv4 주소여야 합니다.

spec.peerPort

integer

선택 사항: BGP 세션을 설정하기 위해 연결할 피어의 네트워크 포트를 지정합니다. 범위는 0 에서 16384 입니다.

spec.holdTime

string

선택 사항: 보유 시간 동안 BGP 피어에 대한 기간을 지정합니다. 최소값은 3초입니다(3s). 일반적인 단위는 3s,1m5m30s 와 같은 초와 분입니다. 경로 오류를 더 빠르게 감지하려면 BFD를 구성합니다.

spec.keepaliveTime

string

선택 사항: keep-alive 메시지를 BGP 피어로 보내는 것 사이의 최대 간격을 지정합니다. 이 필드를 지정하는 경우 holdTime 필드의 값도 지정해야 합니다. 지정된 값은 holdTime 필드의 값보다 작아야 합니다.

spec.routerID

string

선택 사항: BGP 피어에 공개할 라우터 ID를 지정합니다. 이 필드를 지정하는 경우 추가하는 모든 BGP 피어 사용자 정의 리소스에 동일한 값을 지정해야 합니다.

spec.password

string

선택 사항: TCP MD5 인증된 BGP 세션을 적용하는 라우터의 피어에 전송할 MD5 암호를 지정합니다.

spec.passwordSecret

string

선택 사항: BGP Peer의 인증 시크릿 이름을 지정합니다. 시크릿은 metallb 네임스페이스에 있어야 하며 basic-auth 유형이어야 합니다.

spec.bfdProfile

string

선택 사항: BFD 프로필의 이름을 지정합니다.

spec.nodeSelectors

object[]

선택 사항: 일치 표현식과 일치 레이블을 사용하여 선택기를 지정하여 BGP 피어에 연결할 수 있는 노드를 제어합니다.

spec.ebgpMultiHop

boolean

선택 사항: BGP 피어가 여러 네트워크 홉 떨어져 있음을 지정합니다. BGP 피어가 동일한 네트워크에 직접 연결되지 않은 경우 이 필드가 true 로 설정되지 않는 한 speaker는 BGP 세션을 설정할 수 없습니다. 이 필드는 외부 BGP 에 적용됩니다. 외부 BGP는 BGP 피어가 다른 자동 시스템에 속하는 시기를 설명하는 데 사용되는 용어입니다.

참고

passwordSecret 필드는 password 필드와 함께 사용할 수 있으며 사용할 암호 가 포함된 보안에 대한 참조를 포함합니다. 두 필드를 모두 설정하면 구문 분석에 실패합니다.

33.6.2. BGP 피어 구성

클러스터 관리자는 BGP 피어 사용자 정의 리소스를 추가하여 네트워크 라우터와 라우팅 정보를 교환하고 서비스에 대한 IP 주소를 알릴 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • BGP 알림을 사용하여 MetalLB를 구성합니다.

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 bgppeer.yaml 과 같은 파일을 생성합니다.

    apiVersion: metallb.io/v1beta2
    kind: BGPPeer
    metadata:
      namespace: metallb-system
      name: doc-example-peer
    spec:
      peerAddress: 10.0.0.1
      peerASN: 64501
      myASN: 64500
      routerID: 10.10.10.10
    Copy to Clipboard Toggle word wrap
  2. BGP 피어에 대한 구성을 적용합니다.

    $ oc apply -f bgppeer.yaml
    Copy to Clipboard Toggle word wrap

33.6.3. 지정된 주소 풀에 대해 특정 BGP 피어 세트를 구성

다음 절차에서는 다음을 수행하는 방법을 설명합니다.

  • 주소 풀 집합(pool1pool2)을 구성합니다.
  • BGP 피어(peer1peer2) 세트를 구성합니다.
  • pool1peer1 에 할당하고 pool2peer2 에 할당하도록 BGP 광고를 구성합니다.

사전 요구 사항

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

절차

  1. 주소 풀 pool1 을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool1.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: pool1
      spec:
        addresses:
          - 4.4.4.100-4.4.4.200
          - 2001:100:4::200-2001:100:4::400
      Copy to Clipboard Toggle word wrap
    2. IP 주소 pool1 에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool1.yaml
      Copy to Clipboard Toggle word wrap
  2. 주소 풀 풀2 를 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool2.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: pool2
      spec:
        addresses:
          - 5.5.5.100-5.5.5.200
          - 2001:100:5::200-2001:100:5::400
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀2 의 구성을 적용합니다.

      $ oc apply -f ipaddresspool2.yaml
      Copy to Clipboard Toggle word wrap
  3. BGP 피어1 을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgppeer1.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta2
      kind: BGPPeer
      metadata:
        namespace: metallb-system
        name: peer1
      spec:
        peerAddress: 10.0.0.1
        peerASN: 64501
        myASN: 64500
        routerID: 10.10.10.10
      Copy to Clipboard Toggle word wrap
    2. BGP 피어에 대한 구성을 적용합니다.

      $ oc apply -f bgppeer1.yaml
      Copy to Clipboard Toggle word wrap
  4. BGP 피어2 를 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgppeer2.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta2
      kind: BGPPeer
      metadata:
        namespace: metallb-system
        name: peer2
      spec:
        peerAddress: 10.0.0.2
        peerASN: 64501
        myASN: 64500
        routerID: 10.10.10.10
      Copy to Clipboard Toggle word wrap
    2. BGP 피어2에 대한 구성을 적용합니다.

      $ oc apply -f bgppeer2.yaml
      Copy to Clipboard Toggle word wrap
  5. BGP 알림 1을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement1.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgpadvertisement-1
        namespace: metallb-system
      spec:
        ipAddressPools:
          - pool1
        peers:
          - peer1
        communities:
          - 65535:65282
        aggregationLength: 32
        aggregationLengthV6: 128
        localPref: 100
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement1.yaml
      Copy to Clipboard Toggle word wrap
  6. BGP 알림 2를 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement2.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgpadvertisement-2
        namespace: metallb-system
      spec:
        ipAddressPools:
          - pool2
        peers:
          - peer2
        communities:
          - 65535:65282
        aggregationLength: 32
        aggregationLengthV6: 128
        localPref: 100
      Copy to Clipboard Toggle word wrap
    2. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement2.yaml
      Copy to Clipboard Toggle word wrap

33.6.4. BGP 피어 구성 예

33.6.4.1. 예: BGP 피어에 연결하는 노드 제한

BGP 피어에 연결할 수 있는 노드를 제어하기 위해 노드 선택기 필드를 지정할 수 있습니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-nodesel
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  nodeSelectors:
  - matchExpressions:
    - key: kubernetes.io/hostname
      operator: In
      values: [compute-1.example.com, compute-2.example.com]
Copy to Clipboard Toggle word wrap
33.6.4.2. 예: BGP 피어에 대한 BFD 프로필 지정

BGP 피어와 연결할 BFD 프로필을 지정할 수 있습니다. BFD는 BGP 자체보다 피어 간의 통신 오류를 보다 신속하게 감지하여 BGP를 제공합니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-peer-bfd
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64501
  myASN: 64500
  holdTime: "10s"
  bfdProfile: doc-example-bfd-profile-full
Copy to Clipboard Toggle word wrap
참고

BFD(Earwayal forwarding detection) 프로필을 삭제하고 BGP(Border Gateway Protocol) 피어 리소스에 추가된 bfdProfile 을 제거해도 BFD가 비활성화되지 않습니다. 대신 BGP 피어는 기본 BFD 프로필 사용을 시작합니다. BGP 피어 리소스에서 BFD를 비활성화하려면 BGP 피어 구성을 삭제하고 BFD 프로필없이 다시 생성합니다. 자세한 내용은 BZ#2050824 에서 참조하십시오.

33.6.4.3. 예: 듀얼 스택 네트워킹에 대해 BGP 피어 지정

듀얼 스택 네트워킹을 지원하려면 IPv4용 BGP 피어 사용자 정의 리소스 1개와 IPv6용 BGP 피어 사용자 정의 리소스 1개를 추가합니다.

apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv4
  namespace: metallb-system
spec:
  peerAddress: 10.0.20.1
  peerASN: 64500
  myASN: 64500
---
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: doc-example-dual-stack-ipv6
  namespace: metallb-system
spec:
  peerAddress: 2620:52:0:88::104
  peerASN: 64500
  myASN: 64500
Copy to Clipboard Toggle word wrap

33.6.5. 다음 단계

33.7. 커뮤니티 별칭 구성

클러스터 관리자는 커뮤니티 별칭을 구성하고 다양한 알림에서 사용할 수 있습니다.

33.7.1. 커뮤니티 사용자 정의 리소스 정보

커뮤니티 사용자 정의 리소스는 커뮤니티의 별칭 컬렉션입니다. 사용자는 BGPAdvertisement 를 사용하여 ipAddressPools 를 알릴 때 사용할 이름이 지정된 별칭을 정의할 수 있습니다. 커뮤니티 사용자 정의 리소스의 필드는 다음 표에 설명되어 있습니다.

참고

커뮤니티 CRD는 BGPAdvertisement에만 적용됩니다.

Expand
표 33.6. MetalLB 커뮤니티 사용자 정의 리소스
필드유형설명

metadata.name

string

커뮤니티 이름을 지정합니다.

metadata.namespace

string

커뮤니티 의 네임스페이스를 지정합니다. MetalLB Operator에서 사용하는 동일한 네임스페이스를 지정합니다.

spec.communities

string

BGPAdvertisements에서 사용할 수 있는 BGP 커뮤니티 별칭 목록을 지정합니다. 커뮤니티 별칭은 이름(alias)과 값(number:number)으로 구성됩니다. spec.communities 필드에서 별칭 이름을 참조하여 BGPAdvertisement를 커뮤니티 별칭에 연결합니다.

Expand
표 33.7. CommunityAlias
필드유형설명

name

string

커뮤니티 의 별칭의 이름입니다.

value

string

지정된 이름에 해당하는 BGP 커뮤니티 값입니다.

33.7.2. BGP 알림 및 커뮤니티 별칭을 사용하여 MetalLB 구성

IPAddressPool 이 BGP 프로토콜 및 NO_ADVERTISE 커뮤니티의 숫자 값으로 설정된 커뮤니티 별칭과 함께 알리도록 다음과 같이 MetalLB를 구성합니다.

다음 예에서 피어 BGP 라우터 doc-example-peer-community203.0.113.200/32 경로를 수신하고 MetalLB에서 서비스에 할당하는 각 로드 밸런서 IP 주소에 대해 fc00:f853:ccd:e799::1/128 경로를 수신합니다. 커뮤니티 별칭은 NO_ADVERTISE 커뮤니티로 구성됩니다.

사전 요구 사항

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

절차

  1. IP 주소 풀을 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb-system
        name: doc-example-bgp-community
      spec:
        addresses:
          - 203.0.113.200/30
          - fc00:f853:ccd:e799::/124
      Copy to Clipboard Toggle word wrap
    2. IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  2. community1 이라는 커뮤니티 별칭을 생성합니다.

    apiVersion: metallb.io/v1beta1
    kind: Community
    metadata:
      name: community1
      namespace: metallb-system
    spec:
      communities:
        - name: NO_ADVERTISE
          value: '65535:65282'
    Copy to Clipboard Toggle word wrap
  3. doc-example-bgp-peer 라는 BGP 피어를 만듭니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgppeer.yaml 과 같은 파일을 생성합니다.

      apiVersion: metallb.io/v1beta2
      kind: BGPPeer
      metadata:
        namespace: metallb-system
        name: doc-example-bgp-peer
      spec:
        peerAddress: 10.0.0.1
        peerASN: 64501
        myASN: 64500
        routerID: 10.10.10.10
      Copy to Clipboard Toggle word wrap
    2. BGP 피어에 대한 구성을 적용합니다.

      $ oc apply -f bgppeer.yaml
      Copy to Clipboard Toggle word wrap
  4. 커뮤니티 별칭을 사용하여 BGP 알림을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 bgpadvertisement.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: bgp-community-sample
        namespace: metallb-system
      spec:
        aggregationLength: 32
        aggregationLengthV6: 128
        communities:
          - NO_ADVERTISE 
      1
      
        ipAddressPools:
          - doc-example-bgp-community
        peers:
          - doc-example-peer
      Copy to Clipboard Toggle word wrap
      1
      여기에서 CommunityAlias.name 을 지정하고 커뮤니티 CR(사용자 정의 리소스) 이름은 지정합니다.
    2. 설정을 적용합니다.

      $ oc apply -f bgpadvertisement.yaml
      Copy to Clipboard Toggle word wrap

33.8. MetalLB BFD 프로필 구성

클러스터 관리자는 BFD(Bidirectional Forwarding Detection) 프로필을 추가, 수정, 삭제할 수 있습니다. MetalLB Operator는 BFD 프로필 사용자 정의 리소스를 사용하여 BGP 단독으로 제공하는 것보다 더 빠른 경로 오류 탐지를 제공하는 BFD 세션을 식별합니다.

33.8.1. BFD 프로필 사용자 정의 리소스 정보

BFD 프로필 사용자 정의 리소스의 필드는 다음 표에 설명되어 있습니다.

Expand
표 33.8. BFD 프로필 사용자 정의 리소스
필드유형설명

metadata.name

string

BFD 프로필 사용자 정의 리소스의 이름을 지정합니다.

metadata.namespace

string

BFD 프로필 사용자 정의 리소스의 네임스페이스를 지정합니다.

spec.detectMultiplier

integer

패킷 손실을 결정하기 위해 탐지 멀티플라이어를 지정합니다. 원격 전송 간격이 이 값을 곱하여 연결 손실 탐지 타이머를 결정합니다.

예를 들어, 로컬 시스템에 탐지기를 3 으로 설정하고 원격 시스템의 전송 간격이 300 으로 설정된 경우 로컬 시스템은 패킷을 수신하지 않고 900 ms 후에만 오류를 감지합니다.

범위는 2 에서 255 사이입니다. 기본값은 3입니다.

spec.echoMode

boolean

에코 전송 모드를 지정합니다. 분산 BFD를 사용하지 않는 경우 에코 전송 모드는 피어가 FRR인 경우에만 작동합니다. 기본값은 false 이고 에코 전송 모드는 비활성화되어 있습니다.

에코 전송 모드가 활성화되면 대역폭 사용량을 줄이기 위해 제어 패킷의 전송 간격을 늘리는 것이 좋습니다. 예를 들어 전송 간격을 2000 ms로 늘리는 것이 좋습니다.

spec.echoInterval

integer

이 시스템이 에코 패킷을 전송하고 수신하는데 사용하는 최소 전송 간격을 지정합니다. 범위는 10 에서 60000 입니다. 기본값은 50 ms입니다.

spec.minimumTtl

integer

들어오는 제어 패킷에 대해 예상되는 최소 TTL을 지정합니다. 이 필드는 멀티란트 세션에만 적용됩니다.

최소 TTL을 설정하는 목적은 패킷 검증 요구 사항을 보다 철저하게 만들고 다른 세션의 제어 패킷을 받지 않도록 하는 것입니다.

기본값은 254 이며 시스템이 이 시스템과 피어 간에 하나의 홉만 예상함을 나타냅니다.

spec.passiveMode

boolean

세션을 active 또는 passive로 표시할지 여부를 지정합니다. 패시브 세션은 연결을 시작하지 않습니다. 대신 수동 세션은 응답을 시작하기 전에 피어의 제어 패킷을 대기합니다.

세션을 패시브로 표시하는 것은 별 네트워크의 중앙 노드 역할을 하는 라우터가 있고 시스템이 전송할 필요가 없는 제어 패킷을 전송하지 않으려는 경우에 유용합니다.

기본값은 false 이며 세션을 활성으로 표시합니다.

spec.receiveInterval

integer

이 시스템에서 제어 패킷을 수신할 수 있는 최소 간격을 지정합니다. 범위는 10 에서 60000 입니다. 기본값은 300 ms입니다.

spec.transmitInterval

integer

이 시스템에서 제어 패킷을 보내는 데 사용하는 최소 전송 간격(Jitter)을 지정합니다. 범위는 10 에서 60000 입니다. 기본값은 300 ms입니다.

33.8.2. BFD 프로필 구성

클러스터 관리자는 BFD 프로필을 추가하고 프로필을 사용하도록 BGP 피어를 구성할 수 있습니다. BFD는 BGP보다 더 빠른 경로 장애 감지 기능을 제공합니다.

사전 요구 사항

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

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 bfdprofile.yaml 과 같은 파일을 생성합니다.

    apiVersion: metallb.io/v1beta1
    kind: BFDProfile
    metadata:
      name: doc-example-bfd-profile-full
      namespace: metallb-system
    spec:
      receiveInterval: 300
      transmitInterval: 300
      detectMultiplier: 3
      echoMode: false
      passiveMode: true
      minimumTtl: 254
    Copy to Clipboard Toggle word wrap
  2. BFD 프로필에 대한 구성을 적용합니다.

    $ oc apply -f bfdprofile.yaml
    Copy to Clipboard Toggle word wrap

33.8.3. 다음 단계

33.9. MetalLB를 사용하도록 서비스 구성

클러스터 관리자는 LoadBalancer 유형의 서비스를 추가할 때 MetalLB에서 IP 주소를 할당하는 방법을 제어할 수 있습니다.

33.9.1. 특정 IP 주소 요청

다른 로드 밸런서 구현과 마찬가지로 MetalLB에는 서비스 사양에서 spec.loadBalancerIP 필드가 허용됩니다.

요청된 IP 주소가 주소 풀의 범위 내에 있는 경우 MetalLB는 요청된 IP 주소를 할당합니다. 요청된 IP 주소가 범위 내에 없는 경우 MetalLB에서 경고를 보고합니다.

특정 IP 주소에 대한 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.universe.tf/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
  loadBalancerIP: <ip_address>
Copy to Clipboard Toggle word wrap

MetalLB에서 요청된 IP 주소를 할당할 수 없는 경우 서비스의 EXTERNAL-IP<pending>을 보고하고 oc describe service <service_name>을 실행하면 다음 예와 같은 이벤트가 포함됩니다.

MetalLB에서 요청된 IP 주소를 할당할 수 없는 이벤트의 예

  ...
Events:
  Type     Reason            Age    From                Message
  ----     ------            ----   ----                -------
  Warning  AllocationFailed  3m16s  metallb-controller  Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
Copy to Clipboard Toggle word wrap

33.9.2. 특정 풀에서 IP 주소 요청

특정 범위의 IP 주소를 할당하지만 특정 IP 주소와 관련이 없는 경우 metallb.universe.tf/address-pool 주석을 사용하여 지정된 주소 풀의 IP 주소를 요청할 수 있습니다.

특정 풀의 IP 주소에 대한 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    metallb.universe.tf/address-pool: <address_pool_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
Copy to Clipboard Toggle word wrap

<address_pool_name>에 대해 지정한 주소 풀이 없는 경우 MetalLB는 자동 할당을 허용하는 모든 풀에서 IP 주소를 할당하려고 시도합니다.

33.9.3. IP 주소 수락

기본적으로 주소 풀은 자동 할당을 허용하도록 구성됩니다. MetalLB는 이러한 주소 풀에서 IP 주소를 할당합니다.

자동 할당을 위해 구성된 풀의 IP 주소를 수락하려면 특별한 주석이나 구성이 필요하지 않습니다.

IP 주소를 수락하는 서비스 YAML의 예

apiVersion: v1
kind: Service
metadata:
  name: <service_name>
spec:
  selector:
    <label_key>: <label_value>
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
Copy to Clipboard Toggle word wrap

33.9.4. 특정 IP 주소 공유

기본적으로 서비스는 IP 주소를 공유하지 않습니다. 그러나 단일 IP 주소에 서비스를 공동 배치해야 하는 경우 metallb.universe.tf/allow-shared-ip 주석을 서비스에 추가하여 선택적 IP 공유를 활성화할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: service-http
  annotations:
    metallb.universe.tf/address-pool: doc-example
    metallb.universe.tf/allow-shared-ip: "web-server-svc"  
1

spec:
  ports:
    - name: http
      port: 80  
2

      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>  
3

  type: LoadBalancer
  loadBalancerIP: 172.31.249.7  
4

---
apiVersion: v1
kind: Service
metadata:
  name: service-https
  annotations:
    metallb.universe.tf/address-pool: doc-example
    metallb.universe.tf/allow-shared-ip: "web-server-svc"  
5

spec:
  ports:
    - name: https
      port: 443  
6

      protocol: TCP
      targetPort: 8080
  selector:
    <label_key>: <label_value>  
7

  type: LoadBalancer
  loadBalancerIP: 172.31.249.7  
8
Copy to Clipboard Toggle word wrap
1 5
metallb.universe.tf/allow-shared-ip 주석에 동일한 값을 지정합니다. 이 값을 공유 키라고 합니다.
2 6
서비스에 대해 서로 다른 포트 번호를 지정합니다.
3 7
서비스가 동일한 Pod 세트로 트래픽을 보내도록 externalTrafficPolicy: local을 지정해야 하는 경우 동일한 Pod 선택기를 지정합니다. cluster 외부 트래픽 정책을 사용하는 경우 Pod 선택기를 동일할 필요가 없습니다.
4 8
선택 사항: 이전 항목 3개를 지정하는 경우 MetalLB에서 서비스를 동일한 IP 주소에 배치할 수 있습니다. 서비스가 IP 주소를 공유하도록 하려면 공유할 IP 주소를 지정합니다.

기본적으로 Kubernetes는 다중 프로토콜 로드 밸런서 서비스를 허용하지 않습니다. 이 제한으로 인해 일반적으로 TCP 및 UDP에서 수신 대기해야 하는 DNS와 같은 서비스를 실행할 수 없습니다. MetalLB를 사용하여 이 Kubernetes 제한 사항을 해결하려면 다음 두 서비스를 생성합니다.

  • 한 서비스에 대해 TCP를 지정하고 두 번째 서비스에 대해 UDP를 지정합니다.
  • 두 서비스 모두에서 동일한 pod 선택기를 지정합니다.
  • 동일한 공유 키와 spec.loadBalancerIP 값을 지정하여 TCP 및 UDP 서비스를 동일한 IP 주소에 공동 배치합니다.

33.9.5. MetalLB를 사용하여 서비스 구성

주소 풀에서 외부 IP 주소를 사용하도록 로드 밸런싱 서비스를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • MetalLB Operator를 설치하고 MetalLB를 시작합니다.
  • 하나 이상의 주소 풀을 구성합니다.
  • 클라이언트의 트래픽을 클러스터의 호스트 네트워크로 라우팅하도록 네트워크를 구성합니다.

절차

  1. <service_name>.yaml 파일을 생성합니다. 파일에서 spec.type 필드가 LoadBalancer로 설정되어 있는지 확인합니다.

    MetalLB에서 서비스에 할당하는 외부 IP 주소를 요청하는 방법에 대한 자세한 내용은 예제를 참조하십시오.

  2. 서비스를 생성합니다.

    $ oc apply -f <service_name>.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    service/<service_name> created
    Copy to Clipboard Toggle word wrap

검증

  • 서비스를 설명합니다.

    $ oc describe service <service_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                     <service_name>
    Namespace:                default
    Labels:                   <none>
    Annotations:              metallb.universe.tf/address-pool: doc-example  <.>
    Selector:                 app=service_name
    Type:                     LoadBalancer  <.>
    IP Family Policy:         SingleStack
    IP Families:              IPv4
    IP:                       10.105.237.254
    IPs:                      10.105.237.254
    LoadBalancer Ingress:     192.168.100.5  <.>
    Port:                     <unset>  80/TCP
    TargetPort:               8080/TCP
    NodePort:                 <unset>  30550/TCP
    Endpoints:                10.244.0.50:8080
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:  <.>
      Type    Reason        Age                From             Message
      ----    ------        ----               ----             -------
      Normal  nodeAssigned  32m (x2 over 32m)  metallb-speaker  announcing from node "<node_name>"
    Copy to Clipboard Toggle word wrap

    <.> 특정 풀에서 IP 주소를 요청하면 주석이 표시됩니다. <.> 서비스 유형에 LoadBalancer 가 표시되어야 합니다. <.> 로드 밸런서 Ingress 필드는 서비스가 올바르게 할당된 경우 외부 IP 주소를 나타냅니다. <.> 이벤트 필드는 외부 IP 주소를 알리기 위해 할당된 노드 이름을 나타냅니다. 오류가 발생하면 이벤트 필드에 오류 이유가 표시됩니다.

33.10. MetalLB 로깅, 문제 해결 및 지원

MetalLB 구성 문제를 해결해야 하는 경우 일반적으로 사용되는 명령에 대해서는 다음 섹션을 참조하십시오.

33.10.1. MetalLB 로깅 수준 설정

MetalLB는 기본 정보 설정을 사용하여 컨테이너에서 FRRouting(FRR)을 사용합니다. 이 예에 설명된 대로 logLevel 을 설정하여 생성된 로그의 상세 수준을 제어할 수 있습니다.

logLevel 을 다음과 같이 debug 로 설정하여 MetalLB에 대한 더 깊은 통찰력을 얻습니다.

사전 요구 사항

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

절차

  1. 다음 예와 같은 콘텐츠를 사용하여 setdebugloglevel.yaml 과 같은 파일을 생성합니다.

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      nodeSelector:
        node-role.kubernetes.io/worker: ""
    Copy to Clipboard Toggle word wrap
  2. 설정을 적용합니다.

    $ oc replace -f setdebugloglevel.yaml
    Copy to Clipboard Toggle word wrap
    참고

    여기에서는 metallb CR이 이미 생성되어 있으며 여기에서 로그 수준을 변경하고 있는 경우 oc replace 를 사용합니다.

  3. 발표자 Pod의 이름을 표시합니다.

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    READY   STATUS    RESTARTS   AGE
    speaker-2m9pm           4/4     Running   0          9m19s
    speaker-7m4qw           3/4     Running   0          19s
    speaker-szlmx           4/4     Running   0          9m19s
    Copy to Clipboard Toggle word wrap

    참고

    업데이트된 로깅 수준이 적용되도록 발표자 및 컨트롤러 Pod가 다시 생성됩니다. MetalLB의 모든 구성 요소에 대해 로깅 수준이 수정되었습니다.

  4. 발표자 로그를 확인합니다.

    $ oc logs -n metallb-system speaker-7m4qw -c speaker
    Copy to Clipboard Toggle word wrap

    출력 예

    {"branch":"main","caller":"main.go:92","commit":"3d052535","goversion":"gc / go1.17.1 / amd64","level":"info","msg":"MetalLB speaker starting (commit 3d052535, branch main)","ts":"2022-05-17T09:55:05Z","version":""}
    {"caller":"announcer.go:110","event":"createARPResponder","interface":"ens4","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
    {"caller":"announcer.go:119","event":"createNDPResponder","interface":"ens4","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
    {"caller":"announcer.go:110","event":"createARPResponder","interface":"tun0","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
    {"caller":"announcer.go:119","event":"createNDPResponder","interface":"tun0","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
    I0517 09:55:06.515686      95 request.go:665] Waited for 1.026500832s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/operators.coreos.com/v1alpha1?timeout=32s
    {"Starting Manager":"(MISSING)","caller":"k8s.go:389","level":"info","ts":"2022-05-17T09:55:08Z"}
    {"caller":"speakerlist.go:310","level":"info","msg":"node event - forcing sync","node addr":"10.0.128.4","node event":"NodeJoin","node name":"ci-ln-qb8t3mb-72292-7s7rh-worker-a-vvznj","ts":"2022-05-17T09:55:08Z"}
    {"caller":"service_controller.go:113","controller":"ServiceReconciler","enqueueing":"openshift-kube-controller-manager-operator/metrics","epslice":"{\"metadata\":{\"name\":\"metrics-xtsxr\",\"generateName\":\"metrics-\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"uid\":\"ac6766d7-8504-492c-9d1e-4ae8897990ad\",\"resourceVersion\":\"9041\",\"generation\":4,\"creationTimestamp\":\"2022-05-17T07:16:53Z\",\"labels\":{\"app\":\"kube-controller-manager-operator\",\"endpointslice.kubernetes.io/managed-by\":\"endpointslice-controller.k8s.io\",\"kubernetes.io/service-name\":\"metrics\"},\"annotations\":{\"endpoints.kubernetes.io/last-change-trigger-time\":\"2022-05-17T07:21:34Z\"},\"ownerReferences\":[{\"apiVersion\":\"v1\",\"kind\":\"Service\",\"name\":\"metrics\",\"uid\":\"0518eed3-6152-42be-b566-0bd00a60faf8\",\"controller\":true,\"blockOwnerDeletion\":true}],\"managedFields\":[{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"discovery.k8s.io/v1\",\"time\":\"2022-05-17T07:20:02Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:addressType\":{},\"f:endpoints\":{},\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:endpoints.kubernetes.io/last-change-trigger-time\":{}},\"f:generateName\":{},\"f:labels\":{\".\":{},\"f:app\":{},\"f:endpointslice.kubernetes.io/managed-by\":{},\"f:kubernetes.io/service-name\":{}},\"f:ownerReferences\":{\".\":{},\"k:{\\\"uid\\\":\\\"0518eed3-6152-42be-b566-0bd00a60faf8\\\"}\":{}}},\"f:ports\":{}}}]},\"addressType\":\"IPv4\",\"endpoints\":[{\"addresses\":[\"10.129.0.7\"],\"conditions\":{\"ready\":true,\"serving\":true,\"terminating\":false},\"targetRef\":{\"kind\":\"Pod\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"name\":\"kube-controller-manager-operator-6b98b89ddd-8d4nf\",\"uid\":\"dd5139b8-e41c-4946-a31b-1a629314e844\",\"resourceVersion\":\"9038\"},\"nodeName\":\"ci-ln-qb8t3mb-72292-7s7rh-master-0\",\"zone\":\"us-central1-a\"}],\"ports\":[{\"name\":\"https\",\"protocol\":\"TCP\",\"port\":8443}]}","level":"debug","ts":"2022-05-17T09:55:08Z"}
    Copy to Clipboard Toggle word wrap

  5. FRR 로그를 확인합니다.

    $ oc logs -n metallb-system speaker-7m4qw -c frr
    Copy to Clipboard Toggle word wrap

    출력 예

    Started watchfrr
    2022/05/17 09:55:05 ZEBRA: client 16 says hello and bids fair to announce only bgp routes vrf=0
    2022/05/17 09:55:05 ZEBRA: client 31 says hello and bids fair to announce only vnc routes vrf=0
    2022/05/17 09:55:05 ZEBRA: client 38 says hello and bids fair to announce only static routes vrf=0
    2022/05/17 09:55:05 ZEBRA: client 43 says hello and bids fair to announce only bfd routes vrf=0
    2022/05/17 09:57:25.089 BGP: Creating Default VRF, AS 64500
    2022/05/17 09:57:25.090 BGP: dup addr detect enable max_moves 5 time 180 freeze disable freeze_time 0
    2022/05/17 09:57:25.090 BGP: bgp_get: Registering BGP instance (null) to zebra
    2022/05/17 09:57:25.090 BGP: Registering VRF 0
    2022/05/17 09:57:25.091 BGP: Rx Router Id update VRF 0 Id 10.131.0.1/32
    2022/05/17 09:57:25.091 BGP: RID change : vrf VRF default(0), RTR ID 10.131.0.1
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF br0
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ens4
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr 10.0.128.4/32
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr fe80::c9d:84da:4d86:5618/64
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF lo
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ovs-system
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF tun0
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr 10.131.0.1/23
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr fe80::40f1:d1ff:feb6:5322/64
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2da49fed
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2da49fed addr fe80::24bd:d1ff:fec1:d88/64
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2fa08c8c
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2fa08c8c addr fe80::6870:ff:fe96:efc8/64
    2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth41e356b7
    2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth41e356b7 addr fe80::48ff:37ff:fede:eb4b/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth1295c6e2
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth1295c6e2 addr fe80::b827:a2ff:feed:637/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth9733c6dc
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth9733c6dc addr fe80::3cf4:15ff:fe11:e541/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth336680ea
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth336680ea addr fe80::94b1:8bff:fe7e:488c/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vetha0a907b7
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vetha0a907b7 addr fe80::3855:a6ff:fe73:46c3/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf35a4398
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf35a4398 addr fe80::40ef:2fff:fe57:4c4d/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf831b7f4
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf831b7f4 addr fe80::f0d9:89ff:fe7c:1d32/64
    2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vxlan_sys_4789
    2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vxlan_sys_4789 addr fe80::80c1:82ff:fe4b:f078/64
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Timer (start timer expire).
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] BGP_Start (Idle->Connect), fd -1
    2022/05/17 09:57:26.094 BGP: Allocated bnc 10.0.0.1/32(0)(VRF default) peer 0x7f807f7631a0
    2022/05/17 09:57:26.094 BGP: sendmsg_zebra_rnh: sending cmd ZEBRA_NEXTHOP_REGISTER for 10.0.0.1/32 (vrf VRF default)
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Waiting for NHT
    2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Connect established_peers 0
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Idle to Connect
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] TCP_connection_open_failed (Connect->Active), fd -1
    2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Active established_peers 0
    2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Connect to Active
    2022/05/17 09:57:26.094 ZEBRA: rnh_register msg from client bgp: hdr->length=8, type=nexthop vrf=0
    2022/05/17 09:57:26.094 ZEBRA: 0: Add RNH 10.0.0.1/32 type Nexthop
    2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: Evaluate RNH, type Nexthop (force)
    2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: NH has become unresolved
    2022/05/17 09:57:26.094 ZEBRA: 0: Client bgp registers for RNH 10.0.0.1/32 type Nexthop
    2022/05/17 09:57:26.094 BGP: VRF default(0): Rcvd NH update 10.0.0.1/32(0) - metric 0/0 #nhops 0/0 flags 0x6
    2022/05/17 09:57:26.094 BGP: NH update for 10.0.0.1/32(0)(VRF default) - flags 0x6 chgflags 0x0 - evaluate paths
    2022/05/17 09:57:26.094 BGP: evaluate_paths: Updating peer (10.0.0.1(VRF default)) status with NHT
    2022/05/17 09:57:30.081 ZEBRA: Event driven route-map update triggered
    2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-out
    2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-in
    2022/05/17 09:57:31.104 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
    2022/05/17 09:57:31.104 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
    2022/05/17 09:57:31.105 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
    2022/05/17 09:57:31.105 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
    Copy to Clipboard Toggle word wrap

33.10.1.1. FRRouting(FRR) 로그 수준

다음 표에서는 FRR 로깅 수준에 대해 설명합니다.

Expand
표 33.9. 로그 수준
로그 수준설명

all

모든 로깅 수준에 대한 모든 로깅 정보를 제공합니다.

debug

이 정보는 진단적으로 사람에게 도움이 됩니다. 디버그 로 설정하여 자세한 문제 해결 정보를 제공합니다.

info

항상 기록되어야 하지만 정상적인 상황에서는 사용자 개입이 필요하지 않은 정보를 제공합니다. 기본 로깅 수준입니다.

warn

잠재적으로 일관되지 않은 MetalLB 동작을 유발할 수 있는 모든 것 일반적으로 MetalLB 는 이러한 유형의 오류에서 자동으로 복구됩니다.

error

MetalLB 의 기능에 치명적인 모든 오류입니다. 이러한 오류를 해결하려면 일반적으로 관리자 개입이 필요합니다.

none

모든 로깅을 종료합니다.

33.10.2. BGP 문제 해결

Red Hat이 지원하는 BGP 구현에서는 speaker Pod의 컨테이너에서 FRRouting(FRR)을 사용합니다. 클러스터 관리자는 BGP 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.

사전 요구 사항

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

절차

  1. 발표자 Pod의 이름을 표시합니다.

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            READY   STATUS    RESTARTS   AGE
    speaker-66bth   4/4     Running   0          56m
    speaker-gvfnf   4/4     Running   0          56m
    ...
    Copy to Clipboard Toggle word wrap

  2. FRR에 대한 실행 중인 구성을 표시합니다.

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"
    Copy to Clipboard Toggle word wrap

    출력 예

    Building configuration...
    
    Current configuration:
    !
    frr version 7.5.1_git
    frr defaults traditional
    hostname some-hostname
    log file /etc/frr/frr.log informational
    log timestamp precision 3
    service integrated-vtysh-config
    !
    router bgp 64500  
    1
    
     bgp router-id 10.0.1.2
     no bgp ebgp-requires-policy
     no bgp default ipv4-unicast
     no bgp network import-check
     neighbor 10.0.2.3 remote-as 64500  
    2
    
     neighbor 10.0.2.3 bfd profile doc-example-bfd-profile-full  
    3
    
     neighbor 10.0.2.3 timers 5 15
     neighbor 10.0.2.4 remote-as 64500  
    4
    
     neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full  
    5
    
     neighbor 10.0.2.4 timers 5 15
     !
     address-family ipv4 unicast
      network 203.0.113.200/30   
    6
    
      neighbor 10.0.2.3 activate
      neighbor 10.0.2.3 route-map 10.0.2.3-in in
      neighbor 10.0.2.4 activate
      neighbor 10.0.2.4 route-map 10.0.2.4-in in
     exit-address-family
     !
     address-family ipv6 unicast
      network fc00:f853:ccd:e799::/124  
    7
    
      neighbor 10.0.2.3 activate
      neighbor 10.0.2.3 route-map 10.0.2.3-in in
      neighbor 10.0.2.4 activate
      neighbor 10.0.2.4 route-map 10.0.2.4-in in
     exit-address-family
    !
    route-map 10.0.2.3-in deny 20
    !
    route-map 10.0.2.4-in deny 20
    !
    ip nht resolve-via-default
    !
    ipv6 nht resolve-via-default
    !
    line vty
    !
    bfd
     profile doc-example-bfd-profile-full  
    8
    
      transmit-interval 35
      receive-interval 35
      passive-mode
      echo-mode
      echo-interval 35
      minimum-ttl 10
     !
    !
    end
    Copy to Clipboard Toggle word wrap

    <.> 라우터 bgp 섹션은 MetalLB에 대한 ASN을 나타냅니다. <.> 추가한 각 BGP 피어 사용자 정의 리소스에 대해 인접한 <ip-address> remote-as <peer-ASN > 행이 있는지 확인합니다. <.> BFD를 구성한 경우 BFD 프로필이 연결되어 있는지 확인합니다. 올바른 BGP 피어와 BFD 프로필이 명령 출력에 표시됩니다. <.> 네트워크가 <ip-address-range > 라인이 사용자가 추가한 주소 풀 사용자 정의 리소스에서 지정한 IP 주소 범위와 일치하는지 확인합니다.

  3. BGP 요약을 표시합니다.

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"
    Copy to Clipboard Toggle word wrap

    출력 예

    IPv4 Unicast Summary:
    BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
    BGP table version 1
    RIB entries 1, using 192 bytes of memory
    Peers 2, using 29 KiB of memory
    
    Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
    10.0.2.3        4      64500       387       389        0    0    0 00:32:02            0        1  
    1
    
    10.0.2.4        4      64500         0         0        0    0    0    never       Active        0  
    2
    
    
    Total number of neighbors 2
    
    IPv6 Unicast Summary:
    BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
    BGP table version 1
    RIB entries 1, using 192 bytes of memory
    Peers 2, using 29 KiB of memory
    
    Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
    10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg  
    3
    
    10.0.2.4        4      64500         0         0        0    0    0    never       Active        0  
    4
    
    
    Total number of neighbors 2
    Copy to Clipboard Toggle word wrap

    1 1 3
    출력에 사용자가 추가한 각 BGP 피어 사용자 정의 리소스에 대한 행이 포함되어 있는지 확인합니다.
    2 4 2 4
    0 개의 메시지 및 전송된 메시지를 표시하는 출력은 BGP 세션이 없는 BGP 피어를 나타냅니다. 네트워크 연결 및 BGP 피어의 BGP 구성을 확인합니다.
  4. 주소 풀을 수신한 BGP 피어를 표시합니다.

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"
    Copy to Clipboard Toggle word wrap

    ipv4ipv6 으로 교체하여 IPv6 주소 풀을 수신한 BGP 피어를 표시합니다. 203.0.113.200/30 을 주소 풀에서 IPv4 또는 IPv6 IP 주소 범위로 바꿉니다.

    출력 예

    BGP routing table entry for 203.0.113.200/30
    Paths: (1 available, best #1, table default)
      Advertised to non peer-group peers:
      10.0.2.3  <.>
      Local
        0.0.0.0 from 0.0.0.0 (10.0.1.2)
          Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received)
          Last update: Mon Jan 10 19:49:07 2022
    Copy to Clipboard Toggle word wrap

    <.> 출력에 BGP 피어의 IP 주소가 포함되어 있는지 확인합니다.

33.10.3. BFD 문제 해결

Red Hat이 지원하는 BFD(Bidirectional Forwarding Detection) 구현에서는 발표자 Pod의 컨테이너에서 FRRouting(FRR)을 사용합니다. BFD 구현은 기존 BGP 세션을 통해 BGP 피어로 구성된 BFD 피어에도 의존합니다. 클러스터 관리자는 BFD 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.

사전 요구 사항

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

절차

  1. 발표자 Pod의 이름을 표시합니다.

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            READY   STATUS    RESTARTS   AGE
    speaker-66bth   4/4     Running   0          26m
    speaker-gvfnf   4/4     Running   0          26m
    ...
    Copy to Clipboard Toggle word wrap

  2. BFD 피어를 표시합니다.

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"
    Copy to Clipboard Toggle word wrap

    출력 예

    Session count: 2
    SessionId  LocalAddress              PeerAddress              Status
    =========  ============              ===========              ======
    3909139637 10.0.1.2                  10.0.2.3                 up  <.>
    Copy to Clipboard Toggle word wrap

    <.> PeerAddress 열에 각 BFD 피어가 포함되어 있는지 확인합니다. 출력에 출력에 포함할 BFD 피어 IP 주소가 나열되지 않으면 피어와의 BGP 연결 문제를 해결합니다. 상태 필드가 다운 된 경우 노드와 피어 간의 링크와 장비에 대한 연결을 확인합니다. oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}' 와 같은 명령을 사용하여 speaker Pod의 노드 이름을 확인할 수 있습니다.

33.10.4. BGP 및 BFD에 대한 CloudEvent 지표

OpenShift Container Platform은 BGP 피어 및 BFD 프로필과 관련된 MetalLB의 다음 Prometheus 지표를 캡처합니다.

  • metallb_bfd_control_packet_input 는 각 BFD 피어로부터 수신된 BFD 제어 패킷의 수를 계산합니다.
  • metallb_bfd_control_packet_output 은 각 BFD 피어로 전송되는 BFD 제어 패킷의 수를 계산합니다.
  • metallb_bfd_echo_packet_input 는 각 BFD 피어에서 수신한 BFD 에코 패킷의 수를 계산합니다.
  • metallb_bfd_echo_packet_output 은 각 BFD 피어로 전송된 BFD 에코 패킷의 수를 계산합니다.
  • metallb_bfd_session_down_events 는 피어가 down 상태를 입력한 BFD 세션의 수를 계산합니다.
  • metallb_bfd_session_up 은 BFD 피어와의 연결 상태를 나타냅니다. 1 세션이 up 이고 0 은 세션이 중단 되었음을 나타냅니다.
  • metallb_bfd_session_up_events 는 피어가 up 상태를 입력한 BFD 세션의 수를 계산합니다.
  • metallb_bfd_zebra_notifications 각 BFD 피어에 대한 BFD Zebra 알림 수를 계산합니다.
  • metallb_bgp_announced_prefixes_total 은 BGP 피어에 광고되는 로드 밸런서 IP 주소 접두사 수를 계산합니다. 접두사집계 경로 라는 용어는 동일한 의미가 있습니다.
  • metallb_bgp_session_up 은 BGP 피어와의 연결 상태를 나타냅니다. 1 세션이 up 이고 0 은 세션이 중단 되었음을 나타냅니다.
  • metallb_bgp_updates_total 은 BGP 피어로 전송된 BGP 업데이트 메시지 수를 계산합니다.

추가 리소스

  • 모니터링 대시보드 사용에 대한 자세한 내용은 메트릭 쿼리 를 참조하십시오.

33.10.5. CloudEvent 데이터 수집 정보

oc adm must-gather CLI 명령을 사용하여 클러스터, MetalLB 구성 및 MetalLB Operator에 대한 정보를 수집할 수 있습니다. 다음 기능 및 오브젝트는 CloudEvent 및 objects와 연결되어 있습니다.

  • CloudEvent Operator가 배포된 네임스페이스 및 하위 오브젝트
  • 모든 ScanSetting Operator CRD(사용자 정의 리소스 정의)

oc adm must-gather CLI 명령은 Red Hat이 BGP 및 BFD를 구현하는 데 사용하는 FRRouting (FRR)에서 다음 정보를 수집합니다.

  • /etc/frr/frr.conf
  • /etc/frr/frr.log
  • /etc/frr/daemons 구성 파일
  • /etc/frr/vtysh.conf

이전 목록의 로그 및 구성 파일은 각 speaker pod의 frr 컨테이너에서 수집됩니다.

로그 및 구성 파일 외에도 oc adm must-gather CLI 명령은 다음 vtysh 명령에서 출력을 수집합니다.

  • running-config 표시
  • show bgp ipv4
  • show bgp ipv6
  • Bgp Neories를 표시합니다.
  • bfd 피어 표시

oc adm must-gather CLI 명령을 실행할 때 추가 구성이 필요하지 않습니다.

34장. 보조 인터페이스 지표와 네트워크 연결 연관 짓기

34.1. 모니터링을 위한 보조 네트워크 지표 확장

보조 장치 또는 인터페이스는 다양한 용도로 사용됩니다. 동일한 분류 기준으로 보조 장치에 대한 지표를 집계하려면 보조 장치를 분류할 방법이 있어야 합니다.

노출된 지표는 인터페이스를 포함하지만 인터페이스가 시작되는 위치는 지정하지 않습니다. 추가 인터페이스가 없는 경우 이 작업을 수행할 수 있습니다. 그러나 보조 인터페이스를 추가하는 경우 인터페이스 이름만 사용하여 인터페이스를 식별하기가 어렵기 때문에 지표를 사용하기 어려울 수 있습니다.

보조 인터페이스를 추가할 때는 이름이 추가하는 순서에 따라 달라집니다. 서로 다른 보조 인터페이스는 다른 네트워크에 속할 수 있으며 다른 용도로 사용할 수 있습니다.

pod_network_name_info 를 사용하면 인터페이스 유형을 식별하는 추가 정보를 사용하여 현재 지표를 확장할 수 있습니다. 이러한 방식으로 지표를 집계하고 특정 인터페이스 유형에 특정 경보를 추가할 수 있습니다.

네트워크 유형은 관련 NetworkAttachmentDefinition 의 이름을 사용하여 생성되며, 보조 네트워크의 다른 클래스를 구별하는 데 사용됩니다. 예를 들어 서로 다른 네트워크에 속하거나 서로 다른 CNI를 사용하는 서로 다른 인터페이스는 서로 다른 네트워크 연결 정의 이름을 사용합니다.

34.1.1. 네트워크 지표 데몬

네트워크 지표 데몬은 네트워크 관련 지표를 수집하고 게시하는 데몬 구성 요소입니다.

kubelet은 이미 관찰 가능한 네트워크 관련 지표를 게시하고 있습니다. 이러한 지표는 다음과 같습니다.

  • container_network_receive_bytes_total
  • container_network_receive_errors_total
  • container_network_receive_packets_total
  • container_network_receive_packets_dropped_total
  • container_network_transmit_bytes_total
  • container_network_transmit_errors_total
  • container_network_transmit_packets_total
  • container_network_transmit_packets_dropped_total

이러한 지표의 레이블에는 다음이 포함됩니다.

  • 포드 이름
  • 포드 네임스페이스
  • 인터페이스 이름(예: eth0)

이러한 지표는 예를 들면 Multus를 통해 Pod에 새 인터페이스를 추가할 때까지는 인터페이스 이름이 무엇을 나타내는지 명확하지 않기 때문에 잘 작동합니다.

인터페이스 레이블은 인터페이스 이름을 나타내지만 해당 인터페이스가 무엇을 의미하는지는 명확하지 않습니다. 인터페이스가 다양한 경우 모니터링 중인 지표에서 어떤 네트워크를 참조하는지 파악하기란 불가능합니다.

이 문제는 다음 섹션에 설명된 새로운 pod_network_name_info를 도입하여 해결됩니다.

34.1.2. 네트워크 이름이 있는 지표

이 daemonset는 고정 값이 0pod_network_name_info 게이지 지표를 게시합니다.

pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
Copy to Clipboard Toggle word wrap

네트워크 이름 레이블은 Multus에서 추가한 주석을 사용하여 생성됩니다. 네트워크 연결 정의가 속하는 네임스페이스와 네트워크 연결 정의의 이름입니다.

새 지표 단독으로는 많은 가치를 제공하지 않지만 네트워크 관련 container_network_* 지표와 결합되는 경우 보조 네트워크 모니터링을 더 잘 지원합니다.

다음과 같은 promql 쿼리를 사용하면 값이 포함된 새 메트릭과 k8s.v1.cni.cncf.io/network-status 주석에서 검색된 네트워크 이름을 가져올 수 있습니다.

(container_network_receive_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_receive_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_receive_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_receive_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_transmit_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_transmit_errors_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_transmit_packets_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
(container_network_transmit_packets_dropped_total) + on(namespace,pod,interface) group_left(network_name)
Copy to Clipboard Toggle word wrap

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat