네트워킹
클러스터 네트워킹 구성 및 관리
초록
1장. 네트워킹 이해
클러스터 관리자는 클러스터 내에서 외부 트래픽에 실행되는 애플리케이션을 노출하고 네트워크 연결을 보호하는 몇 가지 옵션이 있습니다.
- 노드 포트 또는 로드 밸런서와 같은 서비스 유형
-
Ingress
및Route
와 같은 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에 기본 네트워크 인프라에 대한 액세스 권한이 부여됩니다.
1.1. OpenShift Container Platform DNS
여러 Pod에 사용하기 위해 프론트엔드 및 백엔드 서비스와 같은 여러 서비스를 실행하는 경우 사용자 이름, 서비스 IP 등에 대한 환경 변수를 생성하여 프론트엔드 Pod가 백엔드 서비스와 통신하도록 할 수 있습니다. 서비스를 삭제하고 다시 생성하면 새 IP 주소를 서비스에 할당할 수 있으며 서비스 IP 환경 변수의 업데이트된 값을 가져오기 위해 프론트엔드 Pod를 다시 생성해야 합니다. 또한 백엔드 서비스를 생성한 후 프론트엔드 Pod를 생성해야 서비스 IP가 올바르게 생성되고 프론트엔드 Pod에 환경 변수로 제공할 수 있습니다.
이러한 이유로 서비스 DNS는 물론 서비스 IP/포트를 통해서도 서비스를 이용할 수 있도록 OpenShift Container Platform에 DNS를 내장했습니다.
1.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 컨트롤러 끝점을 게시하는 방법을 제공합니다.
1.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 리소스에서 지정하는 조건을 충족하기 위해 경로가 생성됩니다.
1.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
-
ALB(AWS Load Balancer) 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(사용자 인터페이스)입니다.
2장. 호스트에 액세스
배스천 호스트(Bastion Host)를 생성하여 OpenShift Container Platform 인스턴스에 액세스하고 SSH(Secure Shell) 액세스 권한으로 컨트롤 플레인 노드에 액세스하는 방법을 알아봅니다.
2.1. 설치 관리자 프로비저닝 인프라 클러스터에서 Amazon Web Services의 호스트에 액세스
OpenShift Container Platform 설치 관리자는 OpenShift Container Platform 클러스터에 프로비저닝된 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에 대한 퍼블릭 IP 주소를 생성하지 않습니다. OpenShift Container Platform 호스트에 SSH를 사용하려면 다음 절차를 따라야 합니다.
프로세스
-
openshift-install
명령으로 생성된 가상 프라이빗 클라우드(VPC)에 SSH로 액세스할 수 있는 보안 그룹을 만듭니다. - 설치 관리자가 생성한 퍼블릭 서브넷 중 하나에 Amazon EC2 인스턴스를 생성합니다.
생성한 Amazon EC2 인스턴스와 퍼블릭 IP 주소를 연결합니다.
OpenShift Container Platform 설치와는 달리, 생성한 Amazon EC2 인스턴스를 SSH 키 쌍과 연결해야 합니다. 이 인스턴스에서 사용되는 운영 체제는 중요하지 않습니다. 그저 인터넷을 OpenShift Container Platform 클러스터의 VPC에 연결하는 SSH 베스천의 역할을 수행하기 때문입니다. 사용하는 AMI(Amazon 머신 이미지)는 중요합니다. 예를 들어, RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하면 설치 프로그램과 마찬가지로 Ignition을 통해 키를 제공할 수 있습니다.
Amazon EC2 인스턴스를 프로비저닝한 후 SSH로 연결할 수 있는 경우 OpenShift Container Platform 설치와 연결된 SSH 키를 추가해야 합니다. 이 키는 베스천 인스턴스의 키와 다를 수 있지만 반드시 달라야 하는 것은 아닙니다.
참고SSH 직접 액세스는 재해 복구 시에만 권장됩니다. Kubernetes API가 응답할 때는 권한 있는 Pod를 대신 실행합니다.
-
oc get nodes
를 실행하고 출력을 확인한 후 마스터 노드 중 하나를 선택합니다. 호스트 이름은ip-10-0-1-163.ec2.internal
과 유사합니다. Amazon EC2에 수동으로 배포한 베스천 SSH 호스트에서 해당 컨트롤 플레인 호스트에 SSH로 연결합니다. 설치 중 지정한 것과 동일한 SSH 키를 사용해야 합니다.
$ ssh -i <ssh-key-path> core@<master-hostname>
3장. 네트워킹 Operator 개요
OpenShift Container Platform은 여러 유형의 네트워킹 Operator를 지원합니다. 이러한 네트워킹 Operator를 사용하여 클러스터 네트워킹을 관리할 수 있습니다.
3.1. CNO(Cluster Network Operator)
CNO(Cluster Network Operator)는 OpenShift Container Platform 클러스터에서 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 여기에는 설치 중에 클러스터에 대해 선택된 CNI(Container Network Interface) 기본 네트워크 공급자 플러그인 배포가 포함됩니다. 자세한 내용은 OpenShift Container Platform의 Cluster Network Operator 를 참조하십시오.
3.2. DNS Operator
DNS Operator는 CoreDNS를 배포하고 관리하여 Pod에 이름 확인 서비스를 제공합니다. 이를 통해 OpenShift Container Platform에서 DNS 기반 Kubernetes 서비스 검색이 가능합니다. 자세한 내용은 OpenShift Container Platform의 DNS Operator 를 참조하십시오.
3.3. Ingress Operator
OpenShift Container Platform 클러스터를 생성할 때 클러스터에서 실행되는 Pod 및 서비스는 각각 할당된 IP 주소입니다. IP 주소는 근처에 있는 다른 포드 및 서비스에서 액세스할 수 있지만 외부 클라이언트는 액세스할 수 없습니다. Ingress Operator는 Ingress 컨트롤러 API를 구현하고 OpenShift Container Platform 클러스터 서비스에 대한 외부 액세스를 활성화해야 합니다. 자세한 내용은 OpenShift Container Platform의 Ingress Operator 를 참조하십시오.
3.4. 외부 DNS Operator
외부 DNS Operator는 ExternalDNS를 배포하고 관리하여 외부 DNS 공급자에서 OpenShift Container Platform으로 서비스 및 경로에 대한 이름 확인을 제공합니다. 자세한 내용은 외부 DNS Operator 이해를 참조하십시오.
4장. OpenShift 컨테이너 플랫폼의 Cluster Network Operator
CNO(Cluster Network Operator)는 설치 중에 클러스터에 대해 선택한 CNI(Container Network Interface) 기본 네트워크 공급자 플러그인을 포함하여 OpenShift Container Platform 클러스터에 클러스터 네트워크 구성 요소를 배포하고 관리합니다.
4.1. CNO(Cluster Network Operator)
Cluster Network Operator는 operator.openshift.io
API 그룹에서 네트워크
API를 구현합니다. Operator는 데몬 세트를 사용하여 OpenShift SDN 기본 CNI(Container Network Interface) 네트워크 공급자 플러그인 또는 클러스터 설치 중에 선택한 기본 네트워크 공급자 플러그인을 배포합니다.
프로세스
Cluster Network Operator는 설치 중에 Kubernetes Deployment
로 배포됩니다.
다음 명령을 실행하여 배포 상태를 확인합니다.
$ oc get -n openshift-network-operator deployment/network-operator
출력 예
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
다음 명령을 실행하여 Cluster Network Operator의 상태를 확인합니다.
$ oc get clusteroperator/network
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.5.4 True False False 50m
AVAILABLE
,PROGRESSING
및DEGRADED
필드에서 Operator 상태에 대한 정보를 볼 수 있습니다. Cluster Network Operator가 사용 가능한 상태 조건을 보고하는 경우AVAILABLE
필드는True
로 설정됩니다.
4.2. 클러스터 네트워크 구성 보기
모든 새로운 OpenShift Container Platform 설치에는 이름이 cluster
인 network.config
오브젝트가 있습니다.
프로세스
oc describe
명령을 사용하여 클러스터 네트워크 구성을 확인합니다.$ oc describe network.config/cluster
출력 예
Name: cluster Namespace: Labels: <none> Annotations: <none> API Version: config.openshift.io/v1 Kind: Network Metadata: Self Link: /apis/config.openshift.io/v1/networks/cluster Spec: 1 Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Status: 2 Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Cluster Network MTU: 8951 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Events: <none>
4.3. CNO(Cluster Network Operator) 상태 보기
oc describe
명령을 사용하여 상태를 조사하고 Cluster Network Operator의 세부 사항을 볼 수 있습니다.
프로세스
다음 명령을 실행하여 Cluster Network Operator의 상태를 확인합니다.
$ oc describe clusteroperators/network
4.4. CNO(Cluster Network Operator) 로그 보기
oc logs
명령을 사용하여 Cluster Network Operator 로그를 확인할 수 있습니다.
프로세스
다음 명령을 실행하여 Cluster Network Operator의 로그를 확인합니다.
$ oc logs --namespace=openshift-network-operator deployment/network-operator
4.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
오브젝트의 필드를 설정하여 클러스터의 클러스터 네트워크 공급자 구성을 지정할 수 있습니다.
4.5.1. CNO(Cluster Network Operator) 구성 오브젝트
CNO(Cluster Network Operator)의 필드는 다음 표에 설명되어 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
CNO 개체 이름입니다. 이 이름은 항상 |
|
| Pod IP 주소가 할당되는 IP 주소 블록과 클러스터의 각 개별 노드에 할당된 서브넷 접두사 길이를 지정하는 목록입니다. 예를 들어 다음과 같습니다. spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
이 값은 준비 전용이며 클러스터 설치 중에 |
|
| 서비스의 IP 주소 블록입니다. OpenShift SDN 및 OVN-Kubernetes CNI(Container Network Interface) 네트워크 공급자는 서비스 네트워크에 대한 단일 IP 주소 블록만 지원합니다. 예를 들어 다음과 같습니다. spec: serviceNetwork: - 172.30.0.0/14
이 값은 준비 전용이며 클러스터 설치 중에 |
|
| 클러스터 네트워크의 CNI(Container Network Interface) 클러스터 네트워크 공급자를 구성합니다. |
|
| 이 개체의 필드는 kube-proxy 구성을 지정합니다. OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 kube-proxy 구성이 적용되지 않습니다. |
defaultNetwork 오브젝트 구성
defaultNetwork
오브젝트의 값은 다음 표에 정의되어 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
참고 OpenShift Container Platform은 기본적으로 OpenShift SDN CNI(Container Network Interface) 클러스터 네트워크 공급자를 사용합니다. |
|
| 이 오브젝트는 OpenShift SDN 클러스터 네트워크 공급자에만 유효합니다. |
|
| 이 오브젝트는 OVN-Kubernetes 클러스터 네트워크 공급자에만 유효합니다. |
OpenShift SDN CNI 네트워크 공급자에 대한 구성
다음 표에서는 OpenShift SDN Container Network Interface (CNI) 클러스터 네트워크 공급자의 구성 필드를 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
| OpenShift SDN의 네트워크 격리 모드입니다. |
|
| VXLAN 오버레이 네트워크의 최대 전송 단위(MTU)입니다. 이 값은 일반적으로 자동 구성됩니다. |
|
|
모든 VXLAN 패킷에 사용할 포트입니다. 기본값은 |
클러스터 설치 중 클러스터 네트워크 공급자에 대한 구성만 변경할 수 있습니다.
OpenShift SDN 구성 예
defaultNetwork: type: OpenShiftSDN openshiftSDNConfig: mode: NetworkPolicy mtu: 1450 vxlanPort: 4789
OVN-Kubernetes CNI 클러스터 네트워크 공급자에 대한 구성
다음 표에서는 OVN-Kubernetes CNI 클러스터 네트워크 공급자의 구성 필드를 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
| Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크의 MTU(최대 전송 단위)입니다. 이 값은 일반적으로 자동 구성됩니다. |
|
| Geneve 오버레이 네트워크용 UDP 포트입니다. |
|
| 필드가 있으면 클러스터에 IPsec이 활성화됩니다. |
|
| 네트워크 정책 감사 로깅을 사용자 정의할 구성 오브젝트를 지정합니다. 설정되지 않으면 기본값 감사 로그 설정이 사용됩니다. |
|
| 선택 사항: 송신 트래픽이 노드 게이트웨이로 전송되는 방법을 사용자 정의할 구성 오브젝트를 지정합니다. 참고 While migrating egress traffic, you can expect some disruption to workloads and service traffic until the Cluster Network Operator (CNO) successfully rolls out the changes. |
필드 | 유형 | 설명 |
---|---|---|
| integer |
노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 |
| integer |
감사 로그의 최대 크기(바이트)입니다. 기본값은 |
| string | 다음 추가 감사 로그 대상 중 하나입니다.
|
| string |
RFC5424에 정의된 |
필드 | 유형 | 설명 |
---|---|---|
|
|
Pod에서 호스트 네트워킹 스택으로 송신 트래픽을 보내려면 이 필드를
이 필드는 Open vSwitch 하드웨어 오프로드 기능과 상호 작용합니다. 이 필드를 |
설치 후 활동으로 런타임 시 변경할 수 있는 gatewayConfig
필드를 제외하고 클러스터 네트워크 공급자의 구성만 변경할 수 있습니다.
IPSec가 활성화된 OVN-Kubernetes 구성의 예
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: {}
kubeProxyConfig 오브젝트 구성
kubeProxyConfig
오브젝트의 값은 다음 표에 정의되어 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
참고
OpenShift Container Platform 4.3 이상에서는 성능이 개선되어 더 이상 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s |
4.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
4.6. 추가 리소스
5장. OpenShift Container Platform에서의 DNS Operator
DNS Operator는 CoreDNS를 배포 및 관리하여 Pod에 이름 확인 서비스를 제공하여 OpenShift Container Platform에서 DNS 기반 Kubernetes 서비스 검색을 활성화합니다.
5.1. DNS Operator
DNS Operator는 operator.openshift.io
API 그룹에서 dns
API를 구현합니다. Operator는 데몬 세트를 사용하여 CoreDNS를 배포하고 데몬 세트에 대한 서비스를 생성하며 이름 확인에서 CoreDNS 서비스 IP 주소를 사용하기 위해 Pod에 명령을 내리도록 kubelet을 구성합니다.
프로세스
DNS Operator는 설치 중에 Deployment
오브젝트로 배포됩니다.
oc get
명령을 사용하여 배포 상태를 확인합니다.$ oc get -n openshift-dns-operator deployment/dns-operator
출력 예
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
oc get
명령을 사용하여 DNS Operator의 상태를 확인합니다.$ oc get clusteroperator/dns
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92m
AVAILABLE,
PROGRESSING
및DEGRADED
는 Operator의 상태에 대한 정보를 제공합니다.AVAILABLE
은 CoreDNS 데몬 세트에서 1개 이상의 포드가Available
상태 조건을 보고할 때True
입니다.
5.2. DNS Operator managementState 변경
DNS는 CoreDNS 구성 요소를 관리하여 클러스터의 pod 및 서비스에 대한 이름 확인 서비스를 제공합니다. DNS Operator의 managementState
는 기본적으로 Managed
로 설정되어 있으며 이는 DNS Operator가 리소스를 적극적으로 관리하고 있음을 의미합니다. Unmanaged
로 변경할 수 있습니다. 이는 DNS Operator가 해당 리소스를 관리하지 않음을 의미합니다.
다음은 DNS Operator managementState
를 변경하는 사용 사례입니다.
-
사용자가 개발자이며 구성 변경을 테스트하여 CoreDNS의 문제가 해결되었는지 확인하려고 합니다.
managementState
를Unmanaged
로 설정하여 DNS Operator가 수정 사항을 덮어쓰지 않도록 할 수 있습니다. -
클러스터 관리자이며 CoreDNS 관련 문제를 보고했지만 문제가 해결될 때까지 해결 방법을 적용해야 합니다. DNS Operator의
managementState
필드를Unmanaged
로 설정하여 해결 방법을 적용할 수 있습니다.
절차
managementState
DNS Operator 변경:oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
5.3. DNS Pod 배치 제어
DNS Operator에는 2개의 데몬 세트(CoreDNS 및 /etc/hosts
파일 관리용)가 있습니다. 이미지 가져오기를 지원할 클러스터 이미지 레지스트리의 항목을 추가하려면 모든 노드 호스트에서 /etc/hosts
의 데몬 세트를 실행해야 합니다. 보안 정책은 CoreDNS에 대한 데몬 세트가 모든 노드에서 실행되지 않도록 하는 노드 쌍 간 통신을 금지할 수 있습니다.
클러스터 관리자는 사용자 정의 노드 선택기를 사용하여 특정 노드에서 CoreDNS를 실행하거나 실행하지 않도록 데몬 세트를 구성할 수 있습니다.
사전 요구 사항
-
oc
CLI를 설치했습니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
특정 노드 간 통신을 방지하려면
spec.nodePlacement.nodeSelector
API 필드를 구성합니다.이름이
default
인 DNS Operator 오브젝트를 수정합니다.$ oc edit dns.operator/default
spec.nodePlacement.nodeSelector
API 필드에 컨트롤 플레인 노드만 포함하는 노드 선택기를 지정합니다.spec: nodePlacement: nodeSelector: node-role.kubernetes.io/worker: ""
CoreDNS의 데몬 세트가 노드에서 실행되도록 테인트 및 허용 오차를 구성합니다.
이름이
default
인 DNS Operator 오브젝트를 수정합니다.$ oc edit dns.operator/default
테인트 키와 테인트에 대한 허용 오차를 지정합니다.
spec: nodePlacement: tolerations: - effect: NoExecute key: "dns-only" operators: Equal value: abc tolerationSeconds: 3600 1
- 1
- 테인트가
dns-only
인 경우 무기한 허용될 수 있습니다.tolerationSeconds를
생략할 수 있습니다.
5.4. 기본 DNS보기
모든 새로운 OpenShift Container Platform 설치에서는 dns.operator
의 이름이 default
로 지정됩니다.
프로세스
oc describe
명령을 사용하여 기본dns
를 확인합니다.$ oc describe dns.operator/default
출력 예
Name: default Namespace: Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: DNS ... Status: Cluster Domain: cluster.local 1 Cluster IP: 172.30.0.10 2 ...
클러스터의 service CIDR을 찾으려면
oc get
명령을 사용합니다.$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
출력 예
[172.30.0.0/16]
5.5. DNS 전달 사용
DNS 전달을 사용하여 /etc/resolv.conf
파일의 기본 전달 구성을 다음과 같은 방법으로 덮어쓸 수 있습니다.
- 모든 영역에 대해 이름 서버를 지정합니다. 전달된 영역이 OpenShift Container Platform에서 관리하는 Ingress 도메인인 경우 도메인에 대한 업스트림 이름 서버를 승인해야 합니다.
- 업스트림 DNS 서버 목록을 제공합니다.
- 기본 전달 정책을 변경합니다.
기본 도메인의 DNS 전달 구성에는 /etc/resolv.conf
파일과 업스트림 DNS 서버에 지정된 기본 서버가 모두 있을 수 있습니다.
절차
이름이
default
인 DNS Operator 오브젝트를 수정합니다.$ oc edit dns.operator/default
이를 통해 Operator는
Server
를 기반으로 추가 서버 구성 블록으로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
- 1
rfc6335
서비스 이름 구문을 준수해야 합니다.- 2
rfc1123
서비스 이름 구문의 하위 도메인 정의를 준수해야 합니다. cluster domain,cluster.local
.local은zones
필드에 유효하지 않은 하위 도메인입니다.- 3
- 업스트림 리졸버를 선택할 정책을 정의합니다. 기본값은
Random
입니다. 또한RoundRobin
및Sequential
값을 사용할 수도 있습니다. - 4
forwardPlugin
당 최대 15개의업스트림
이 허용됩니다.- 5
- 선택 사항: 이를 사용하여 기본 정책을 재정의하고 DNS 확인을 기본 도메인의 지정된 DNS 확인자(업스트림 확인자)로 전달할 수 있습니다. 업스트림 리졸버를 제공하지 않으면 DNS 이름 쿼리는
/etc/resolv.conf
의 서버로 이동합니다. - 6
- 조회를 위해 업스트림 서버가 선택된 순서를 결정합니다. 다음 값 중 하나를 지정할 수 있습니다:
Random
,RoundRobin
, 또는Sequential
. 기본값은Sequential
입니다. - 7
- 선택 사항: 이를 사용하여 업스트림 확인자를 제공할 수 있습니다.
- 8
- 두 가지 유형의
업스트림
(SystemResolvConf
및Network
)을 지정할 수 있습니다.SystemResolvConf
는/etc/resolv.conf
및Network
를 사용하도록 업스트림을 구성하여Networkresolver
를 정의합니다. 하나 또는 둘 다를 지정할 수 있습니다. - 9
- 지정된 유형이
네트워크
이면 IP 주소를 제공해야 합니다.address
필드는 유효한 IPv4 또는 IPv6 주소여야 합니다. - 10
- 지정된 유형이
네트워크
이면 선택적으로 포트를 제공할 수 있습니다.포트
필드는1
에서65535
사이의 값을 가져야합니다. 업스트림 포트를 지정하지 않으면 기본적으로 포트 853이 시도됩니다.
고도로 규제된 환경에서 작업하는 경우 추가 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
- 1
rfc6335
서비스 이름 구문을 준수해야 합니다.- 2
rfc1123
서비스 이름 구문의 하위 도메인 정의를 준수해야 합니다. cluster domain,cluster.local
.local은zones
필드에 유효하지 않은 하위 도메인입니다. 클러스터 도메인에 해당하는cluster.local
은영역
에 유효하지 않은하위 도메인
입니다.- 3
- 전달된 DNS 쿼리를 위해 TLS를 구성할 때 값
TLS
를 갖도록transport
필드를 설정합니다. 기본적으로 CoreDNS는 10초 동안 연결을 전달했습니다. 요청이 발행되지 않은 경우 CoreDNS는 10초 동안 열려 있는 TCP 연결을 유지합니다. 대규모 클러스터를 사용하면 노드당 연결을 시작할 수 있으므로 DNS 서버에서 많은 새 연결이 열려 있을 수 있음을 확인합니다. 성능 문제를 방지하기 위해 적절하게 DNS 계층을 설정합니다. - 4
- 전달된 DNS 쿼리에 대해 TLS를 구성할 때 이는 업스트림 TLS 서버 인증서를 검증하기 위해 SNI(서버 이름 표시)의 일부로 사용되는 필수 서버 이름입니다.
- 5
- 업스트림 리졸버를 선택할 정책을 정의합니다. 기본값은
Random
입니다. 또한RoundRobin
및Sequential
값을 사용할 수도 있습니다. - 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
가 정의되지 않았거나 유효하지 않은 경우 구성 맵에는 기본 서버만 포함됩니다.구성 맵을 표시합니다.
$ oc get configmap/dns-default -n openshift-dns -o yaml
이전 샘플 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
- 1
forwardPlugin
을 변경하면 CoreDNS 데몬 세트의 롤링 업데이트가 트리거됩니다.
추가 리소스
- DNS 전달에 대한 자세한 내용은 CoreDNS 전달 설명서를 참조하십시오.
5.6. DNS Operator 상태
oc describe
명령을 사용하여 상태를 확인하고 DNS Operator의 세부 사항을 볼 수 있습니다.
프로세스
DNS Operator의 상태를 확인하려면 다음을 실행합니다.
$ oc describe clusteroperators/dns
5.7. DNS Operator 로그
oc logs
명령을 사용하여 DNS Operator 로그를 확인할 수 있습니다.
프로세스
DNS Operator의 로그를 확인합니다.
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
5.8. CoreDNS 로그 수준 설정
CoreDNS 로그 수준을 구성하여 로깅된 오류 메시지에 대한 세부 정보 양을 확인할 수 있습니다. CoreDNS 로그 수준에 유효한 값은 Normal
,Debug
, Trace
입니다. 기본 logLevel
은 Normal
입니다.
오류 플러그인은 항상 활성화되어 있습니다. 다음 logLevel
설정은 다른 오류 응답을 보고합니다.
-
logLevel
:Normal
는 "errors" 클래스를 활성화합니다.log . { class error }
} . -
logLevel
:Debug
는 "denial" 클래스:log . { 클래스 거부 오류 }
를 활성화합니다. -
logLevel
:Trace
를 사용하면 "모든" 클래스:log . { 클래스 all }
.
절차
logLevel
을Debug
로 설정하려면 다음 명령을 입력합니다.$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
logLevel
을Trace
로 설정하려면 다음 명령을 입력합니다.$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
검증
원하는 로그 수준을 설정하려면 구성 맵을 확인합니다.
$ oc get configmap/dns-default -n openshift-dns -o yaml
5.9. CoreDNS Operator 로그 수준 설정
클러스터 관리자는 OpenShift DNS 문제를 더 빠르게 추적하도록 Operator 로그 수준을 구성할 수 있습니다. operatorLogLevel
에 유효한 값은 Normal
,Debug
및 Trace
입니다. 추적은
가장 자세한 정보가 있습니다. 기본 operatorlogLevel
은 Normal
입니다. 여기에는 추적, 디버그, 정보, 경고, 오류, Fatal 및 Panic의 7 가지 로깅 수준이 있습니다. 로깅 수준이 설정되면 해당 심각도 또는 그 이상의 모든 항목이 있는 로그 항목이 기록됩니다.
-
operatorLogLevel: "Normal"
은logrus.SetLogLevel("Info")
을 설정합니다. -
operatorLogLevel: "Debug"
는logrus.SetLogLevel("Debug")
을 설정합니다. -
operatorLogLevel: "Trace"
는logrus.SetLogLevel("Trace")
을 설정합니다.
절차
operatorLogLevel
을디버그
로 설정하려면 다음 명령을 입력합니다.$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
operatorLogLevel
을Trace
로 설정하려면 다음 명령을 입력합니다.$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
6장. OpenShift Container Platform에서의 Ingress Operator
6.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 컨트롤러 끝점을 게시하는 방법을 제공합니다.
6.2. Ingress 구성 자산
설치 프로그램은 config.openshift.io
API 그룹인 cluster-ingress-02-config.yml
에 Ingress
리소스가 포함된 자산을 생성합니다.
Ingress
리소스의 YAML 정의
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.openshiftdemos.com
설치 프로그램은 이 자산을 manifests /
디렉터리의 cluster-ingress-02-config.yml
파일에 저장합니다. 이 Ingress
리소스는 Ingress와 관련된 전체 클러스터 구성을 정의합니다. 이 Ingress 구성은 다음과 같이 사용됩니다.
- Ingress Operator는 클러스터 Ingress 구성에 설정된 도메인을 기본 Ingress 컨트롤러의 도메인으로 사용합니다.
-
OpenShift API Server Operator는 클러스터 Ingress 구성의 도메인을 사용합니다. 이 도메인은 명시적 호스트를 지정하지 않는
Route
리소스에 대한 기본 호스트를 생성할 수도 있습니다.
6.3. Ingress 컨트롤러 구성 매개변수
ingresscontrollers.operator.openshift.io
리소스에서 제공되는 구성 매개변수는 다음과 같습니다.
매개변수 | 설명 |
---|---|
|
비어 있는 경우 기본값은 |
|
|
|
설정되지 않은 경우, 기본값은
대부분의 플랫폼의 경우
|
|
보안에는 키와 데이터, 즉 *
설정하지 않으면 와일드카드 인증서가 자동으로 생성되어 사용됩니다. 인증서는 Ingress 컨트롤러 생성된 인증서 또는 사용자 정의 인증서는 OpenShift Container Platform 내장 OAuth 서버와 자동으로 통합됩니다. |
|
|
|
|
|
설정하지 않으면 기본값이 사용됩니다. 참고
nodePlacement: nodeSelector: matchLabels: kubernetes.io/os: linux tolerations: - effect: NoSchedule operator: Exists |
|
설정되지 않으면, 기본값은
Ingress 컨트롤러의 최소 TLS 버전은 참고
구성된 보안 프로파일의 암호 및 최소 TLS 버전은 중요
Ingress Operator는 |
|
|
|
|
|
|
|
기본적으로 정책은
이러한 조정은 HTTP/1을 사용하는 경우에만 일반 텍스트, 에지 종료 및 재암호화 경로에 적용됩니다.
요청 헤더의 경우 이러한 조정은 |
|
|
|
|
|
캡처하려는 모든 쿠키의 경우 다음 매개변수는
예를 들어 다음과 같습니다. httpCaptureCookies: - matchType: Exact maxLength: 128 name: MYCOOKIE |
|
httpCaptureHeaders: request: - maxLength: 256 name: Connection - maxLength: 128 name: User-Agent response: - maxLength: 256 name: Content-Type - maxLength: 256 name: Content-Length |
|
|
|
|
|
이러한 연결은 로드 밸런서 상태 프로브 또는 웹 브라우저 추측 연결(preconnect)에서 제공되며 무시해도 됩니다. 그러나 이러한 요청은 네트워크 오류로 인해 발생할 수 있으므로 이 필드를 |
모든 매개변수는 선택 사항입니다.
6.3.1. Ingress 컨트롤러 TLS 보안 프로필
TLS 보안 프로필은 서버가 서버에 연결할 때 연결 클라이언트가 사용할 수 있는 암호를 규제하는 방법을 제공합니다.
6.3.1.1. TLS 보안 프로필 이해
TLS(Transport Layer Security) 보안 프로필을 사용하여 다양한 OpenShift Container Platform 구성 요소에 필요한 TLS 암호를 정의할 수 있습니다. OpenShift Container Platform TLS 보안 프로필은 Mozilla 권장 구성을 기반으로 합니다.
각 구성 요소에 대해 다음 TLS 보안 프로필 중 하나를 지정할 수 있습니다.
Profile | 설명 |
---|---|
| 이 프로필은 레거시 클라이언트 또는 라이브러리와 함께 사용하기 위한 것입니다. 프로필은 이전 버전과의 호환성 권장 구성을 기반으로 합니다.
참고 Ingress 컨트롤러의 경우 최소 TLS 버전이 1.0에서 1.1로 변환됩니다. |
| 이 프로필은 대부분의 클라이언트에서 권장되는 구성입니다. Ingress 컨트롤러, kubelet 및 컨트롤 플레인의 기본 TLS 보안 프로필입니다. 프로필은 중간 호환성 권장 구성을 기반으로 합니다.
|
| 이 프로필은 이전 버전과의 호환성이 필요하지 않은 최신 클라이언트와 사용하기 위한 것입니다. 이 프로필은 최신 호환성 권장 구성을 기반으로 합니다.
|
| 이 프로필을 사용하면 사용할 TLS 버전과 암호를 정의할 수 있습니다. 주의
|
미리 정의된 프로파일 유형 중 하나를 사용하는 경우 유효한 프로파일 구성은 릴리스마다 변경될 수 있습니다. 예를 들어 릴리스 X.Y.Z에 배포된 중간 프로필을 사용하는 사양이 있는 경우 릴리스 X.Y.Z+1로 업그레이드하면 새 프로필 구성이 적용되어 롤아웃이 발생할 수 있습니다.
6.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 ...
TLS 보안 프로필은 Ingress 컨트롤러의 TLS 연결에 대한 최소 TLS 버전과 TLS 암호를 정의합니다.
Status.Tls Profile
아래의 IngressController
CR(사용자 정의 리소스) 및 Spec.Tls Security Profile
아래 구성된 TLS 보안 프로필에서 구성된 TLS 보안 프로필의 암호 및 최소 TLS 버전을 확인할 수 있습니다. Custom
TLS 보안 프로필의 경우 특정 암호 및 최소 TLS 버전이 두 매개변수 아래에 나열됩니다.
HAProxy Ingress 컨트롤러 이미지는 TLS 1.3
및 Modern
프로필을 지원합니다.
Ingress Operator는 Old
또는 Custom
프로파일의 TLS 1.0
을 1.1
로 변환합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
openshift-ingress-operator
프로젝트에서IngressController
CR을 편집하여 TLS 보안 프로필을 구성합니다.$ oc edit IngressController default -n openshift-ingress-operator
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 ...
- 파일을 저장하여 변경 사항을 적용합니다.
검증
IngressController
CR에 프로파일이 설정되어 있는지 확인합니다.$ oc describe IngressController default -n openshift-ingress-operator
출력 예
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
6.3.1.3. 상호 TLS 인증 구성
spec.clientTLS
값을 설정하여 mTLS(mTLS) 인증을 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다. clientTLS
값은 클라이언트 인증서를 확인하도록 Ingress 컨트롤러를 구성합니다. 이 구성에는 구성 맵에 대한 참조인 clientCA
값 설정이 포함됩니다. 구성 맵에는 클라이언트의 인증서를 확인하는 데 사용되는 PEM 인코딩 CA 인증서 번들이 포함되어 있습니다. 필요한 경우 인증서 제목 필터 목록을 구성할 수 있습니다.
clientCA
값이 X509v3 인증서 취소 목록(CRL) 배포 지점을 지정하는 경우 Ingress Operator는 CRL을 다운로드하고 이를 승인하도록 Ingress 컨트롤러를 구성합니다. 유효한 인증서를 제공하지 않는 요청은 거부됩니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
절차
openshift-config
네임스페이스에 있는 구성 맵을 생성합니다.$ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
참고구성 맵 데이터 키는
ca-bundle.pem
이어야 하며 데이터 값은 PEM 형식의 CA 인증서여야 합니다.openshift-ingress-operator
프로젝트에서IngressController
리소스를 편집합니다.$ oc edit IngressController default -n openshift-ingress-operator
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$"
6.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
6.5. Ingress Operator 상태 보기
Ingress Operator의 상태를 확인 및 조사할 수 있습니다.
프로세스
Ingress Operator 상태를 확인합니다.
$ oc describe clusteroperators/ingress
6.6. Ingress 컨트롤러 로그 보기
Ingress 컨트롤러의 로그를 확인할 수 있습니다.
프로세스
Ingress 컨트롤러 로그를 확인합니다.
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
6.7. Ingress 컨트롤러 상태 보기
특정 Ingress 컨트롤러의 상태를 확인할 수 있습니다.
프로세스
Ingress 컨트롤러의 상태를 확인합니다.
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
6.8. Ingress 컨트롤러 구성
6.8.1. 사용자 정의 기본 인증서 설정
관리자는 Secret 리소스를 생성하고 IngressController
CR(사용자 정의 리소스)을 편집하여 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러를 구성할 수 있습니다.
사전 요구 사항
- PEM 인코딩 파일에 인증서/키 쌍이 있어야 합니다. 이때 인증서는 신뢰할 수 있는 인증 기관 또는 사용자 정의 PKI에서 구성한 신뢰할 수 있는 개인 인증 기관의 서명을 받은 인증서입니다.
인증서가 다음 요구 사항을 충족합니다.
- 인증서가 Ingress 도메인에 유효해야 합니다.
-
인증서는
subjectAltName
확장자를 사용하여*.apps.ocp4.example.com과
같은 와일드카드 도메인을 지정합니다.
IngressController
CR이 있어야 합니다. 기본 설정을 사용할 수 있어야 합니다.$ oc --namespace openshift-ingress-operator get ingresscontrollers
출력 예
NAME AGE default 10m
임시 인증서가 있는 경우 사용자 정의 기본 인증서가 포함 된 보안의 tls.crt
파일에 인증서가 포함되어 있어야 합니다. 인증서를 지정하는 경우에는 순서가 중요합니다. 서버 인증서 다음에 임시 인증서를 나열해야 합니다.
프로세스
아래에서는 사용자 정의 인증서 및 키 쌍이 현재 작업 디렉터리의 tls.crt
및 tls.key
파일에 있다고 가정합니다. 그리고 tls.crt
및 tls.key
의 실제 경로 이름으로 변경합니다. Secret 리소스를 생성하고 IngressController CR에서 참조하는 경우 custom-certs-default
를 다른 이름으로 변경할 수도 있습니다.
이 작업을 수행하면 롤링 배포 전략에 따라 Ingress 컨트롤러가 재배포됩니다.
tls.crt
및tls.key
파일을 사용하여openshift-ingress
네임스페이스에 사용자 정의 인증서를 포함하는 Secret 리소스를 만듭니다.$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
새 인증서 보안 키를 참조하도록 IngressController CR을 업데이트합니다.
$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
업데이트가 적용되었는지 확인합니다.
$ echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
다음과 같습니다.
<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
작은 정보다음 YAML을 적용하여 사용자 지정 기본 인증서를 설정할 수 있습니다.
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: defaultCertificate: name: custom-certs-default
인증서 보안 이름은 CR을 업데이트하는 데 사용된 값과 일치해야 합니다.
IngressController CR이 수정되면 Ingress Operator는 사용자 정의 인증서를 사용하도록 Ingress 컨트롤러의 배포를 업데이트합니다.
6.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'
클러스터가 새 인증서 구성을 조정하는 동안 지연이 발생할 수 있습니다.
검증
원래 클러스터 인증서가 복원되었는지 확인하려면 다음 명령을 입력합니다.
$ echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
다음과 같습니다.
<domain>
- 클러스터의 기본 도메인 이름을 지정합니다.
출력 예
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
6.8.3. Ingress 컨트롤러 확장
처리량 증가 요구 등 라우팅 성능 또는 가용성 요구 사항을 충족하도록 Ingress 컨트롤러를 수동으로 확장할 수 있습니다. IngressController
리소스를 확장하려면 oc
명령을 사용합니다. 다음 절차는 기본 IngressController
를 확장하는 예제입니다.
원하는 수의 복제본을 만드는 데에는 시간이 걸리기 때문에 확장은 즉시 적용되지 않습니다.
프로세스
기본
IngressController
의 현재 사용 가능한 복제본 개수를 살펴봅니다.$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
출력 예
2
oc patch
명령을 사용하여 기본IngressController
의 복제본 수를 원하는 대로 조정합니다. 다음 예제는 기본IngressController
를 3개의 복제본으로 조정합니다.$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
출력 예
ingresscontroller.operator.openshift.io/default patched
기본
IngressController
가 지정한 복제본 수에 맞게 조정되었는지 확인합니다.$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
출력 예
3
작은 정보또는 다음 YAML을 적용하여 Ingress 컨트롤러를 세 개의 복제본으로 확장할 수 있습니다.
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 3 1
- 1
- 다른 양의 복제본이 필요한 경우
replicas
값을 변경합니다.
6.8.4. 수신 액세스 로깅 구성
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
사이드카에 로그를 기록하도록 Ingress 컨트롤러를 구성하면 Operator는 Ingress 컨트롤러 Pod에
logs
라는 컨테이너를 만듭니다.$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
출력 예
2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Syslog 끝점에 대한 Ingress 액세스 로깅을 구성합니다.
수신 액세스 로깅을 구성하려면
spec.logging.access.destination
을 사용하여 대상을 지정해야 합니다. Syslog 끝점 대상에 로깅을 지정하려면spec.logging.access.destination.type
에 대한Syslog
를 지정해야 합니다. 대상 유형이Syslog
인 경우,spec.logging.access.destination.syslog.endpoint
를 사용하여 대상 끝점을 지정해야 하며spec.logging.access.destination.syslog.facility
를 사용하여 장치를 지정할 수 있습니다. 다음 예제는Syslog
대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514
참고syslog
대상 포트는 UDP여야 합니다.
특정 로그 형식으로 Ingress 액세스 로깅을 구성합니다.
spec.logging.access.httpLogFormat
을 지정하여 로그 형식을 사용자 정의할 수 있습니다. 다음 예제는 IP 주소 1.2.3.4 및 포트 10514를 사용하여syslog
끝점에 로그하는 Ingress 컨트롤러 정의입니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514 httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
Ingress 액세스 로깅을 비활성화합니다.
Ingress 액세스 로깅을 비활성화하려면
spec.logging
또는spec.logging.access
를 비워 둡니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: null
6.8.5. Ingress 컨트롤러 스레드 수 설정
클러스터 관리자는 클러스터에서 처리할 수 있는 들어오는 연결의 양을 늘리기 위해 스레드 수를 설정할 수 있습니다. 기존 Ingress 컨트롤러에 패치하여 스레드의 양을 늘릴 수 있습니다.
사전 요구 사항
- 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.
프로세스
스레드 수를 늘리도록 Ingress 컨트롤러를 업데이트합니다.
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
참고많은 리소스를 실행할 수 있는 노드가 있는 경우 원하는 노드의 용량과 일치하는 라벨을 사용하여
spec.nodePlacement.nodeSelector
를 구성하고spec.tuningOptions.threadCount
를 적절하게 높은 값으로 구성할 수 있습니다.
6.8.6. 내부 로드 밸런서를 사용하도록 Ingress 컨트롤러 구성
클라우드 플랫폼에서 Ingress 컨트롤러를 생성할 때 Ingress 컨트롤러는 기본적으로 퍼블릭 클라우드 로드 밸런서에 의해 게시됩니다. 관리자는 내부 클라우드 로드 밸런서를 사용하는 Ingress 컨트롤러를 생성할 수 있습니다.
클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.
IngressController
의 범위를
변경하려면 CR(사용자 정의 리소스)이 생성된 후 .spec.endpointPublishingStrategy.loadBalancer.scope
매개변수를 변경할 수 있습니다.
그림 6.1. LoadBalancer 다이어그램
이전 그래픽에서는 OpenShift Container Platform Ingress LoadBalancerService 끝점 게시 전략에 대한 다음 개념을 보여줍니다.
- OpenShift Ingress 컨트롤러 로드 밸런서를 사용하여 클라우드 공급자 로드 밸런서 또는 내부적으로 로드 밸런싱을 외부적으로 로드할 수 있습니다.
- 그래픽에 표시된 것처럼 로드 밸런서의 단일 IP 주소 및 더 친숙한 포트(예: 8080 및 4200)를 사용할 수 있습니다.
- 외부 로드 밸런서의 트래픽은 Pod에서 지시하며 down 노드의 인스턴스에 표시된 대로 로드 밸런서에서 관리합니다. 구현 세부 사항은 Kubernetes 서비스 설명서를 참조하십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음 예제와 같이
<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
다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.
$ oc create -f <name>-ingress-controller.yaml 1
- 1
<name>
을IngressController
오브젝트의 이름으로 변경합니다.
선택 사항: Ingress 컨트롤러가 생성되었는지 확인하려면 다음 명령을 실행합니다.
$ oc --all-namespaces=true get ingresscontrollers
6.8.7. GCP에서 Ingress 컨트롤러에 대한 글로벌 액세스 구성
내부 로드 밸런서가 있는 GCP에서 생성된 Ingress 컨트롤러는 서비스의 내부 IP 주소를 생성합니다. 클러스터 관리자는 로드 밸런서와 동일한 VPC 네트워크 및 컴퓨팅 리전 내의 모든 리전의 클라이언트가 클러스터에서 실행되는 워크로드에 도달할 수 있도록 하는 글로벌 액세스 옵션을 지정할 수 있습니다.
자세한 내용은 글로벌 액세스에 대한 GCP 설명서를 참조하십시오.
사전 요구 사항
- GCP 인프라에 OpenShift Container Platform 클러스터를 배포했습니다.
- 내부 로드 밸런서를 사용하도록 Ingress 컨트롤러 구성
-
OpenShift CLI(
oc
)를 설치합니다.
프로세스
글로벌 액세스를 허용하도록 Ingress 컨트롤러 리소스를 구성합니다.
참고Ingress 컨트롤러를 생성하고 글로벌 액세스 옵션을 지정할 수도 있습니다.
Ingress 컨트롤러 리소스를 구성합니다.
$ oc -n openshift-ingress-operator edit ingresscontroller/default
YAML 파일을 편집합니다.
Global
에 대한clientAccess
구성 샘플spec: endpointPublishingStrategy: loadBalancer: providerParameters: gcp: clientAccess: Global 1 type: GCP scope: Internal type: LoadBalancerService
- 1
gcp.clientAccess
를Global
로 설정합니다.
- 파일을 저장하여 변경 사항을 적용합니다.
다음 명령을 실행하여 서비스가 글로벌 액세스를 허용하는지 확인합니다.
$ oc -n openshift-ingress edit svc/router-default -o yaml
출력에서 주석
networking.gke.io/internal-load-balancer-allow-global-access
가 있는 GCP에 글로벌 액세스가 활성화되어 있음을 보여줍니다.
6.8.8. Ingress 컨트롤러 상태 점검 간격 설정
클러스터 관리자는 상태 점검 간격을 설정하여 두 번 연속된 상태 점검 간에 라우터가 대기하는 시간을 정의할 수 있습니다. 이 값은 모든 경로에 대한 기본값으로 전역적으로 적용됩니다. 기본값은 5초입니다.
사전 요구 사항
- 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.
프로세스
백엔드 상태 점검 간 간격을 변경하도록 Ingress 컨트롤러를 업데이트합니다.
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
참고단일 경로에 대해
healthCheckInterval
을 재정의하려면 경로 주석router.openshift.io/haproxy.health.check.interval
을 사용하십시오.
6.8.9. 클러스터의 기본 Ingress 컨트롤러를 내부로 구성
클러스터를 삭제하고 다시 생성하여 클러스터의 default
Ingress 컨트롤러를 내부용으로 구성할 수 있습니다.
클라우드 공급자가 Microsoft Azure인 경우 노드를 가리키는 퍼블릭 로드 밸런서가 하나 이상 있어야 합니다. 그렇지 않으면 모든 노드의 인터넷 연결이 끊어집니다.
IngressController
의 범위를
변경하려면 CR(사용자 정의 리소스)이 생성된 후 .spec.endpointPublishingStrategy.loadBalancer.scope
매개변수를 변경할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
클러스터의
기본
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
6.8.10. 경로 허용 정책 구성
관리자 및 애플리케이션 개발자는 도메인 이름이 동일한 여러 네임스페이스에서 애플리케이션을 실행할 수 있습니다. 이는 여러 팀이 동일한 호스트 이름에 노출되는 마이크로 서비스를 개발하는 조직을 위한 것입니다.
네임스페이스 간 클레임은 네임스페이스 간 신뢰가 있는 클러스터에 대해서만 허용해야 합니다. 그렇지 않으면 악의적인 사용자가 호스트 이름을 인수할 수 있습니다. 따라서 기본 승인 정책에서는 네임스페이스 간에 호스트 이름 클레임을 허용하지 않습니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
프로세스
다음 명령을 사용하여
ingresscontroller
리소스 변수의.spec.routeAdmission
필드를 편집합니다.$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
샘플 Ingress 컨트롤러 구성
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
작은 정보다음 YAML을 적용하여 경로 승인 정책을 구성할 수 있습니다.
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed
6.8.11. 와일드카드 경로 사용
HAProxy Ingress 컨트롤러는 와일드카드 경로를 지원합니다. Ingress Operator는 wildcardPolicy
를 사용하여 Ingress 컨트롤러의 ROUTER_ALLOW_WILDCARD_ROUTES
환경 변수를 구성합니다.
Ingress 컨트롤러의 기본 동작은 와일드카드 정책이 None
인 경로를 허용하고, 이는 기존 IngressController
리소스의 이전 버전과 호환됩니다.
프로세스
와일드카드 정책을 구성합니다.
다음 명령을 사용하여
IngressController
리소스를 편집합니다.$ oc edit IngressController
spec
에서wildcardPolicy
필드를WildcardsDisallowed
또는WildcardsAllowed
로 설정합니다.spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
6.8.12. X-Forwarded 헤더 사용
HAProxy Ingress 컨트롤러를 구성하여 Forwarded
및 X-Forwarded-For
를 포함한 HTTP 헤더 처리 방법에 대한 정책을 지정합니다. Ingress Operator는 HTTPHeaders
필드를 사용하여 Ingress 컨트롤러의 ROUTER_SET_FORWARDED_HEADERS
환경 변수를 구성합니다.
프로세스
Ingress 컨트롤러에 대한
HTTPHeaders
필드를 구성합니다.다음 명령을 사용하여
IngressController
리소스를 편집합니다.$ oc edit IngressController
spec
에서HTTPHeaders
정책 필드를Append
,Replace
,IfNone
또는Never
로 설정합니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: forwardedHeaderPolicy: Append
사용 사례 예
클러스터 관리자는 다음을 수행할 수 있습니다.
Ingress 컨트롤러로 전달하기 전에
X-Forwarded-For
헤더를 각 요청에 삽입하는 외부 프록시를 구성합니다.헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면
never
정책을 지정합니다. 그러면 Ingress 컨트롤러에서 헤더를 설정하지 않으며 애플리케이션은 외부 프록시에서 제공하는 헤더만 수신합니다.외부 프록시에서 외부 클러스터 요청에 설정한
X-Forwarded-For
헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성합니다.외부 프록시를 통과하지 않는 내부 클러스터 요청에
X-Forwarded-For
헤더를 설정하도록 Ingress 컨트롤러를 구성하려면if-none
정책을 지정합니다. HTTP 요청에 이미 외부 프록시를 통해 설정된 헤더가 있는 경우 Ingress 컨트롤러에서 해당 헤더를 보존합니다. 요청이 프록시를 통해 제공되지 않아 헤더가 없는 경우에는 Ingress 컨트롤러에서 헤더를 추가합니다.
애플리케이션 개발자는 다음을 수행할 수 있습니다.
X-Forwarded-For
헤더를 삽입하는 애플리케이션별 외부 프록시를 구성합니다.다른 경로에 대한 정책에 영향을 주지 않으면서 애플리케이션 경로에 대한 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 애플리케이션 경로에 주석
haproxy.router.openshift.io/set-forwarded-headers: if-none
또는haproxy.router.openshift.io/set-forwarded-headers: never
를 추가하십시오.참고Ingress 컨트롤러에 전역적으로 설정된 값과 관계없이 경로별로
haproxy.router.openshift.io/set-forwarded-headers
주석을 설정할 수 있습니다.
6.8.13. 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 지원이 필요합니다. WebSockets over HTTP/2는 현재 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
<ingresscontroller_name>
을 주석 처리할 Ingress 컨트롤러의 이름으로 변경합니다.
전체 클러스터에서 HTTP/2를 활성화합니다.
전체 클러스터에 HTTP/2를 사용하려면
oc annotate
명령을 입력합니다.$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
작은 정보다음 YAML을 적용하여 주석을 추가할 수도 있습니다.
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster annotations: ingress.operator.openshift.io/default-enable-http2: "true"
6.8.14. 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 컨트롤러가 생성되어 있습니다.
프로세스
Ingress 컨트롤러 리소스를 편집합니다.
$ oc -n openshift-ingress-operator edit ingresscontroller/default
PROXY 구성을 설정합니다.
Ingress 컨트롤러에서 hostNetwork 엔드포인트 게시 전략 유형을 사용하는 경우
spec.endpointPublishingStrategy.hostNetwork.protocol
하위 필드를PROXY
로 설정합니다.PROXY
에 대한hostNetwork
구성 샘플spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork
Ingress 컨트롤러에서 NodePortService 엔드포인트 게시 전략 유형을 사용하는 경우
spec.endpointPublishingStrategy.nodePort.protocol
하위 필드를PROXY
로 설정합니다.PROXY
에 대한nodePort
구성 샘플spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService
6.8.15. appsDomain 옵션을 사용하여 대체 클러스터 도메인 지정
클러스터 관리자는 appsDomain
필드를 구성하여 사용자가 생성한 경로의 기본 클러스터 도메인에 대한 대안을 지정할 수 있습니다. appsDomain
필드는 domain 필드에 지정된 기본값 대신 사용할 OpenShift Container Platform의 선택적 도메인
입니다. 대체 도메인을 지정하면 새 경로의 기본 호스트를 결정하기 위해 기본 클러스터 도메인을 덮어씁니다.
예를 들어, 회사의 DNS 도메인을 클러스터에서 실행되는 애플리케이션의 경로 및 인그레스의 기본 도메인으로 사용할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터를 배포했습니다.
-
oc
명령줄 인터페이스를 설치했습니다.
프로세스
사용자 생성 경로에 대한 대체 기본 도메인을 지정하여
appsDomain
필드를 구성합니다.Ingress
클러스터
리소스를 편집합니다.$ oc edit ingresses.config/cluster -o yaml
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
경로를 노출하고 경로 도메인 변경을 확인하여 기존 경로에
appsDomain
필드에 지정된 도메인 이름이 포함되어 있는지 확인합니다.참고경로를 노출하기 전에
openshift-apiserver
가 롤링 업데이트를 완료할 때까지 기다립니다.경로를 노출합니다.
$ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed
출력 예:
$ 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
6.8.16. HTTP 헤더 대소문자 변환
HAProxy 2.2는 기본적으로 HTTP 헤더 이름을 소문자로 (예: Host: xyz.com
을 host: xyz.com
으로) 변경합니다. 기존 애플리케이션이 HTTP 헤더 이름의 대문자에 민감한 경우 Ingress Controller spec.httpHeaders.headerNameCaseAdjustments
API 필드를 사용하여 기존 애플리케이션을 수정할 때 까지 지원합니다.
OpenShift Container Platform에는 HAProxy 2.2가 포함되어 있으므로 업그레이드하기 전에 spec.httpHeaders.headerNameCaseAdjustments
를 사용하여 필요한 구성을 추가하십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
클러스터 관리자는 oc patch
명령을 입력하거나 Ingress 컨트롤러 YAML 파일에서 HeaderNameCaseAdjustments
필드를 설정하여 HTTP 헤더 케이스를 변환할 수 있습니다.
oc patch
명령을 입력하여 대문자로 작성할 HTTP 헤더를 지정합니다.oc patch
명령을 입력하여 HTTPhost
헤더를Host
로 변경합니다.$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
애플리케이션 경로에 주석을 추가합니다.
$ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
그런 다음 Ingress 컨트롤러는 지정된 대로
host
요청 헤더를 조정합니다.
Ingress 컨트롤러 YAML 파일을 구성하여
HeaderNameCaseAdjustments
필드를 사용하여 조정합니다.다음 예제 Ingress 컨트롤러 YAML은 적절하게 주석이 달린 경로의 HTTP/1 요청에 대해
host
헤더를Host
로 조정합니다.Ingress 컨트롤러 YAML 예시
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: headerNameCaseAdjustments: - Host
다음 예제 경로에서는
haproxy.router.openshift.io/h1-adjust-case
주석을 사용하여 HTTP 응답 헤더 이름 대소문자 조정을 활성화합니다.경로 YAML의 예
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/h1-adjust-case: true 1 name: my-application namespace: my-application spec: to: kind: Service name: my-application
- 1
haproxy.router.openshift.io/h1-adjust-case
를 true로 설정합니다.
6.8.17. 라우터 압축 사용
특정 MIME 유형에 대해 전역적으로 라우터 압축을 지정하도록 HAProxy Ingress 컨트롤러를 구성합니다. mimeTypes
변수를 사용하여 압축이 적용되는 MIME 유형의 형식을 정의할 수 있습니다. 유형은 애플리케이션, 이미지, 메시지, 다중 파트, 텍스트, 비디오 또는 "X-"로 선행되는 사용자 정의 유형입니다. MIME 유형 및 하위 유형에 대한 전체 표기법을 보려면 RFC1341 을 참조하십시오.
압축을 위해 할당된 메모리는 최대 연결에 영향을 미칠 수 있습니다. 또한 대규모 버퍼 압축으로 인해 regex 또는 긴 regex 목록과 같은 대기 시간이 발생할 수 있습니다.
모든 MIME 유형이 압축의 이점을 제공하는 것은 아니지만, HAProxy는 여전히 리소스를 사용하여 에 지시된 경우 압축하려고 합니다. 일반적으로 html, css 및 js와 같은 텍스트 형식은 압축의 이점을 활용하지만 이미지, 오디오 및 비디오와 같은 형식이 압축되는 시간과 리소스를 교환하는 것은 거의 없습니다.
절차
Ingress 컨트롤러의
httpCompression
필드를 구성합니다.다음 명령을 사용하여
IngressController
리소스를 편집합니다.$ oc edit -n openshift-ingress-operator ingresscontrollers/default
사양에서
httpCompression
정책 필드를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" ...
6.8.18. HAProxy 오류 코드 응답 페이지 사용자 정의
클러스터 관리자는 503, 404 또는 두 오류 페이지에 대한 사용자 지정 오류 코드 응답 페이지를 지정할 수 있습니다. HAProxy 라우터는 애플리케이션 pod가 실행 중이 아닌 경우 503 오류 페이지 또는 요청된 URL이 없는 경우 404 오류 페이지를 제공합니다. 예를 들어 503 오류 코드 응답 페이지를 사용자 지정하면 애플리케이션 pod가 실행되지 않을 때 페이지가 제공되며 HAProxy 라우터에서 잘못된 경로 또는 존재하지 않는 경로에 대해 기본 404 오류 코드 HTTP 응답 페이지가 제공됩니다.
사용자 정의 오류 코드 응답 페이지가 구성 맵에 지정되고 Ingress 컨트롤러에 패치됩니다. 구성 맵 키의 사용 가능한 파일 이름은 error-page-503.http
및 error-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 줄 종료를 사용할 수 있는 편집기가 필요합니다.
절차
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
중요사용자 정의 오류 코드 응답 페이지에 올바른 형식을 지정하지 않으면 라우터 Pod 중단이 발생합니다. 이 중단을 해결하려면 구성 맵을 삭제하거나 수정하고 영향을 받는 라우터 Pod를 삭제하여 올바른 정보로 다시 생성해야 합니다.
이름별로
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
Ingress Operator는
my-custom-error-code-pages
구성 맵을openshift-config
네임스페이스에서openshift-ingress
네임스페이스로 복사합니다. Operator는openshift-ingress
네임스페이스에서<your_ingresscontroller_name>-errorpages
패턴에 따라 구성 맵의 이름을 지정합니다.복사본을 표시합니다.
$ oc get cm default-errorpages -n openshift-ingress
출력 예
NAME DATA AGE default-errorpages 2 25s 1
- 1
default
Ingress 컨트롤러 CR(사용자 정의 리소스)이 패치되었기 때문에 구성 맵 이름은default-errorpages
입니다.
사용자 정의 오류 응답 페이지가 포함된 구성 맵이 라우터 볼륨에 마운트되는지 확인합니다. 여기서 구성 맵 키는 사용자 정의 HTTP 오류 코드 응답이 있는 파일 이름입니다.
503 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
404 사용자 지정 HTTP 사용자 정의 오류 코드 응답의 경우:
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
검증
사용자 정의 오류 코드 HTTP 응답을 확인합니다.
테스트 프로젝트 및 애플리케이션을 생성합니다.
$ oc new-project test-ingress
$ oc new-app django-psql-example
503 사용자 정의 http 오류 코드 응답의 경우:
- 애플리케이션의 모든 pod를 중지합니다.
다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.
$ curl -vk <route_hostname>
404 사용자 정의 http 오류 코드 응답의 경우:
- 존재하지 않는 경로 또는 잘못된 경로를 방문합니다.
다음 curl 명령을 실행하거나 브라우저에서 경로 호스트 이름을 방문합니다.
$ curl -vk <route_hostname>
errorfile
속성이haproxy.config
파일에 제대로 있는지 확인합니다.$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
6.8.19. Ingress 컨트롤러 최대 연결 설정
클러스터 관리자는 OpenShift 라우터 배포에 대한 최대 동시 연결 수를 설정할 수 있습니다. 기존 Ingress 컨트롤러를 패치하여 최대 연결 수를 늘릴 수 있습니다.
사전 요구 사항
- 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.
절차
HAProxy에 대한 최대 연결 수를 변경하려면 Ingress 컨트롤러를 업데이트합니다.
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
주의spec.tuningOptions.maxConnections
값을 현재 운영 체제 제한보다 크게 설정하면 HAProxy 프로세스가 시작되지 않습니다. 이 매개변수에 대한 자세한 내용은 "Ingress Controller 구성 매개변수" 섹션의 표를 참조하십시오.
6.9. 추가 리소스
7장. OpenShift Container Platform의 Ingress 분할
OpenShift Container Platform에서 Ingress 컨트롤러는 모든 경로를 제공하거나 경로 서브 세트를 제공할 수 있습니다. 기본적으로 Ingress 컨트롤러는 클러스터의 모든 네임스페이스에서 생성된 모든 경로를 제공합니다. 선택한 특성을 기반으로 경로의 하위 집합인 shard 를 생성하여 라우팅을 최적화하도록 클러스터에 Ingress 컨트롤러를 추가할 수 있습니다. 경로를 shard의 멤버로 표시하려면 경로 또는 네임스페이스 메타데이터
필드에 라벨을 사용합니다. Ingress 컨트롤러는 선택 표현식 이라고도 하는 선택기 를 사용하여 제공할 전체 경로 풀에서 경로 서브 세트를 선택합니다.
Ingress 분할은 트래픽을 특정 Ingress 컨트롤러로 라우팅하거나 다음 섹션에 설명된 다양한 이유로 트래픽을 분리하려는 경우 여러 Ingress 컨트롤러에서 들어오는 트래픽을 로드 밸런싱하려는 경우에 유용합니다.
기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 그러나 라우터 도메인을 대신 사용하도록 경로를 구성할 수 있습니다. 자세한 내용은 Ingress 컨트롤러 Sharding의 경로 생성 을 참조하십시오.
7.1. Ingress 컨트롤러 분할
라우터 샤딩이라고도 하는 Ingress 샤딩을 사용하여 경로, 네임스페이스 또는 둘 다에 라벨을 추가하여 여러 라우터에 경로 집합을 배포할 수 있습니다. Ingress 컨트롤러는 해당 선택기 세트를 사용하여 지정된 라벨이 있는 경로만 허용합니다. 각 Ingress shard는 지정된 선택 표현식을 사용하여 필터링되는 경로로 구성됩니다.
트래픽이 클러스터로 유입되는 기본 메커니즘으로 Ingress 컨트롤러의 요구 사항이 중요할 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.
- 여러 경로를 통해 Ingress 컨트롤러 또는 라우터를 로드 밸런싱하여 변경에 대한 응답 속도 향상
- 특정 경로가 나머지 경로와 다른 수준의 신뢰성을 가지도록 할당
- 특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
- 특정 경로만 추가 기능을 사용하도록 허용
- 예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출
- 녹색 배포 중에 애플리케이션의 한 버전에서 다른 버전으로 트래픽을 전송합니다.
Ingress 컨트롤러가 분할되면 지정된 경로가 그룹의 0개 이상의 Ingress 컨트롤러에 허용됩니다. 경로 상태는 Ingress 컨트롤러가 승인했는지 여부를 나타냅니다. Ingress 컨트롤러는 해당 shard에 고유한 경우에만 경로를 허용합니다.
Ingress 컨트롤러는 세 가지 분할 방법을 사용할 수 있습니다.
- 네임스페이스 선택기와 일치하는 라벨이 있는 네임스페이스의 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 네임스페이스 선택기만 추가합니다.
- 경로 선택기와 일치하는 레이블이 있는 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 경로 선택기만 추가합니다.
- 네임스페이스 선택기와 경로 선택기를 모두 Ingress 컨트롤러에 추가하여 네임스페이스 선택기와 일치하는 라벨과 일치하는 라벨이 있는 레이블이 있는 경로가 Ingress shard에 있도록 합니다.
샤딩을 사용하면 여러 Ingress 컨트롤러에 경로 서브 세트를 배포할 수 있습니다. 이러한 서브셋은 오버라이프(over-overla)이거나, 기존 샤딩(Sampling)이라고도 하며, 중복되는 분할이라고 할 수 있습니다.
7.1.1. 기존 분할 예
Ingress 컨트롤러 finops-router
는 label selector spec.namespaceSelector.matchLabels.name
을 Thanos 및 ops
로
설정하여 구성됩니다.
finops-router
에 대한 YAML 정의의 예
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: finops-router namespace: openshift-ingress-operator spec: namespaceSelector: matchLabels: name: - finance - ops
두 번째 Ingress 컨트롤러 dev-router
는 라벨 선택기 spec.namespaceSelector.matchLabels.name
을 dev
로 설정하여 구성됩니다.
dev-router
YAML 정의의 예
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: dev-router namespace: openshift-ingress-operator spec: namespaceSelector: matchLabels: name: dev
모든 애플리케이션 경로가 별도의 네임스페이스에 있는 경우 각각 name:finance
,name:ops
, name:dev
로 레이블이 지정된 경우 이 구성은 두 Ingress 컨트롤러 간에 경로를 효과적으로 배포합니다. 콘솔, 인증 및 기타 목적을 위한 OpenShift Container Platform 경로는 처리해서는 안 됩니다.
위의 시나리오에서는 분할이 중복된 하위 집합이 없는 특별한 파티션 케이스가 됩니다. 경로는 라우터 shard 간에 나뉩니다.
namespaceSelector
또는 routeSelector
필드에 제외를 위한 경로가 포함되지 않는 한 기본
Ingress 컨트롤러는 모든 경로를 계속 제공합니다. 기본 Ingress 컨트롤러에서 경로를 제외하는 방법에 대한 자세한 내용은 이 Red Hat Knowledgebase 솔루션 및 "기본 Ingress 컨트롤러 삭제" 섹션을 참조하십시오.
7.1.2. 중복된 분할 예
위의 예에서 finops-router
및 dev-router
외에도, dev
및 ops
로 설정된 라벨 선택기 spec.namespaceSelector.matchLabels.name
으로 구성됩니다.
ECDHE -router에 대한 YAML
정의의 예
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: devops-router namespace: openshift-ingress-operator spec: namespaceSelector: matchLabels: name: - dev - ops
name:dev
및 name:ops
레이블이 지정된 네임스페이스의 경로는 이제 서로 다른 두 개의 Ingress 컨트롤러에서 서비스를 제공합니다. 이 구성을 사용하면 경로가 중복되는 하위 집합이 있습니다.
경로의 중복된 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 생성할 수 있습니다. 예를 들어 전용 finops-router
로 더 높은 우선 순위 트래픽을 전환하면서 더 낮은 우선 순위 트래픽을ECDHE -router
로 전송할 수 있습니다.
7.1.3. 기본 Ingress 컨트롤러 분할
새 Ingress shard를 생성한 후 기본 Ingress 컨트롤러에도 적용되는 새 Ingress shard에 적용되는 경로가 있을 수 있습니다. 이는 기본 Ingress 컨트롤러에 선택기가 없고 기본적으로 모든 경로를 허용하기 때문입니다.
네임스페이스 선택기 또는 경로 선택기를 사용하여 특정 라벨을 사용하여 Ingress 컨트롤러를 서비스 경로에서 제한할 수 있습니다. 다음 절차에서는 기본 Ingress 컨트롤러가 네임스페이스 선택기를 사용하여 새로 분할된 Thanos ,ops
, dev
경로를 서비스하지 못하도록 제한합니다. 이렇게 하면 Ingress shard에 더 많은 격리가 추가되었습니다.
모든 OpenShift Container Platform 관리 경로를 동일한 Ingress 컨트롤러에 보관해야 합니다. 따라서 이러한 필수 경로를 제외하는 기본 Ingress 컨트롤러에 추가 선택기를 추가하지 마십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트 관리자로 로그인되어 있습니다.
절차
다음 명령을 실행하여 기본 Ingress 컨트롤러를 수정합니다.
$ oc edit ingresscontroller -n openshift-ingress-operator default
jaeger ,
ops
,dev
라벨이 있는 경로를 제외하는namespaceSelector
를포함
하도록 Ingress 컨트롤러를 편집합니다.apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: namespaceSelector: matchExpressions: - key: type operator: NotIn values: - finance - ops - dev
기본 Ingress 컨트롤러는 더 이상 name:finance
,name:ops
, name:dev
로 레이블이 지정된 네임스페이스를 제공하지 않습니다.
7.1.4. Ingress 분할 및 DNS
클러스터 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 수행해야 합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.
다음 예제를 고려하십시오.
-
라우터 A는 호스트 192.168.0.5에 존재하며
*.foo.com
이 있는 경로가 있습니다. -
라우터 B는 호스트 192.168.1.9에 있으며
*.example.com
이 있는 경로가 있습니다.
별도의 DNS 항목은 라우터 A 및 *.example.com
을 라우터 B를 호스팅하는 노드에 *.foo.com
으로 확인해야 합니다.
-
*.foo.com A IN 192.168.0.5
-
*.example.com A IN 192.168.1.9
7.1.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성
경로 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 경로 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.
그림 7.1. 경로 라벨을 사용한 Ingress 분할
Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
프로세스
router-internal.yaml
파일을 다음과 같이 편집합니다.# cat router-internal.yaml apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" routeSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress 컨트롤러
router-internal.yaml
파일을 적용합니다.# oc apply -f router-internal.yaml
Ingress 컨트롤러는
type: sharded
라벨이 있는 네임스페이스에서 경로를 선택합니다.
7.1.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성
네임스페이스 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 네임스페이스 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.
그림 7.2. 네임스페이스 라벨을 사용한 Ingress 분할
Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
프로세스
router-internal.yaml
파일을 다음과 같이 편집합니다.# cat router-internal.yaml
출력 예
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" namespaceSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress 컨트롤러
router-internal.yaml
파일을 적용합니다.# oc apply -f router-internal.yaml
Ingress 컨트롤러는 네임스페이스 선택기에서 선택한
type: sharded
라벨이 있는 네임스페이스에서 경로를 선택합니다.
7.2. Ingress 컨트롤러 분할을 위한 경로 생성
경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. 이 경우 호스트 이름이 설정되지 않고 경로는 대신 하위 도메인을 사용합니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress 컨트롤러의 도메인을 자동으로 사용합니다. 여러 Ingress 컨트롤러에서 경로가 노출되는 경우 경로는 여러 URL에서 호스팅됩니다.
다음 절차에서는 hello-openshift
애플리케이션을 예제로 사용하여 Ingress 컨트롤러 분할에 대한 경로를 생성하는 방법을 설명합니다.
Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트 관리자로 로그인되어 있습니다.
- 포트에서 트래픽을 수신 대기하는 포트 및 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
- 분할을 위해 Ingress 컨트롤러가 구성되어 있습니다.
프로세스
다음 명령을 실행하여
hello-openshift
라는 프로젝트를 생성합니다.$ oc new-project hello-openshift
다음 명령을 실행하여 프로젝트에 Pod를 생성합니다.
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
다음 명령을 실행하여
hello-openshift
라는 서비스를 생성합니다.$ oc expose pod/hello-openshift
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
다음 명령을 실행하여
hello-openshift-route.yaml
을 사용하여hello-openshift
애플리케이션에 대한 경로를 생성합니다.$ oc -n hello-openshift create -f hello-openshift-route.yaml
검증
다음 명령을 사용하여 경로의 상태를 가져옵니다.
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
생성된
Route
리소스는 다음과 유사해야 합니다.출력 예
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
추가 리소스
8장. Ingress 컨트롤러 끝점 게시 전략 구성
8.1. Ingress 컨트롤러 끝점 게시 전략
NodePortService
끝점 게시 전략
NodePortService
끝점 게시 전략에서는 Kubernetes NodePort 서비스를 사용하여 Ingress 컨트롤러를 게시합니다.
이 구성에서는 Ingress 컨트롤러를 배포하기 위해 컨테이너 네트워킹을 사용합니다. 배포를 게시하기 위해 NodePortService
가 생성됩니다. 특정 노드 포트는 OpenShift Container Platform에 의해 동적으로 할당됩니다. 그러나 정적 포트 할당을 지원하기 위해 관리형 NodePortService
의 노드 포트 필드에 대한 변경 사항은 유지됩니다.
그림 8.1. Diagram of NodePortService
이전 그래픽에서는 OpenShift Container Platform Ingress NodePort 끝점 게시 전략에 대한 다음 개념을 보여줍니다.
- 클러스터에서 사용 가능한 모든 노드에는 외부에서 액세스할 수 있는 자체 IP 주소가 있습니다. 클러스터에서 실행 중인 서비스는 모든 노드의 고유한 NodePort에 바인딩됩니다.
-
클라이언트가 그래픽에
10.0.128.4
IP 주소를 연결하여 다운된 노드에 클라이언트가 연결되면 노드 포트는 서비스를 실행 중인 사용 가능한 노드에 클라이언트를 직접 연결합니다. 이 시나리오에서는 로드 밸런싱이 필요하지 않습니다. 이미지가 표시된 대로10.0.128.4
주소가 다운되어 다른 IP 주소를 대신 사용해야 합니다.
Ingress Operator는 서비스의 .spec.ports[].nodePort
필드에 대한 업데이트를 무시합니다.
기본적으로 포트는 자동으로 할당되며 통합을 위해 포트 할당에 액세스할 수 있습니다. 그러나 동적 포트에 대한 응답으로 쉽게 재구성할 수 없는 기존 인프라와 통합하기 위해 정적 포트 할당이 필요한 경우가 있습니다. 정적 노드 포트와 통합하기 위해 관리 서비스 리소스를 직접 업데이트할 수 있습니다.
자세한 내용은 NodePort
에 대한 Kubernetes 서비스 설명서를 참조하십시오.
HostNetwork
끝점 게시 전략
HostNetwork
끝점 게시 전략에서는 Ingress 컨트롤러가 배포된 노드 포트에 Ingress 컨트롤러를 게시합니다.
HostNetwork
끝점 게시 전략이 있는 Ingress 컨트롤러는 노드당 하나의 Pod 복제본만 가질 수 있습니다. n개의 복제본이 필요한 경우에는 해당 복제본을 예약할 수 있는 n개 이상의 노드를 사용해야 합니다. 각 pod 복제본은 예약된 노드 호스트에서 포트 80
및 443
을 요청하므로 동일한 노드의 다른 pod가 해당 포트를 사용하는 경우 복제본을 노드에 예약할 수 없습니다.
8.1.1. Ingress 컨트롤러 끝점 게시 범위를 Internal에 구성
클러스터 관리자가 클러스터가 프라이빗으로 지정되도록 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 External
로 설정된 범위를
사용하여 생성됩니다. 클러스터 관리자는 외부
범위 Ingress 컨트롤러를 Internal
로 변경할 수 있습니다.
사전 요구 사항
-
oc
CLI를 설치했습니다.
절차
외부
범위가 지정된 Ingress 컨트롤러를Internal
로 변경하려면 다음 명령을 입력합니다.$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'
Ingress 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
Progressing
상태 조건은 추가 작업을 수행해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.$ oc -n openshift-ingress delete services/router-default
서비스를 삭제하면 Ingress Operator에서 내부로 다시
생성합니다
.
8.1.2. Ingress 컨트롤러 끝점 게시 범위를 외부로 구성
클러스터 관리자가 클러스터가 프라이빗으로 지정되도록 지정하지 않고 새 클러스터를 설치하면 기본 Ingress 컨트롤러가 External
로 설정된 범위를
사용하여 생성됩니다.
설치 중 또는 이후에 Ingress 컨트롤러의 범위를 Internal
로 구성할 수 있으며 클러스터 관리자는 내부
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"}}}}'
Ingress 컨트롤러의 상태를 확인하려면 다음 명령을 입력합니다.
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
Progressing
상태 조건은 추가 작업을 수행해야 하는지 여부를 나타냅니다. 예를 들어 상태 조건은 다음 명령을 입력하여 서비스를 삭제해야 함을 나타낼 수 있습니다.$ oc -n openshift-ingress delete services/router-default
서비스를 삭제하면 Ingress Operator가 외부로 다시
생성합니다
.
8.2. 추가 리소스
- 자세한 내용은 Ingress 컨트롤러 구성 매개변수를 참조하십시오.
9장. 끝점에 대한 연결 확인
CNO(Cluster Network Operator)는 클러스터 내 리소스 간에 연결 상태 검사를 수행하는 연결 확인 컨트롤러인 컨트롤러를 실행합니다. 상태 점검 결과를 검토하여 연결 문제를 진단하거나 현재 조사하고 있는 문제의 원인으로 네트워크 연결을 제거할 수 있습니다.
9.1. 연결 상태 점검 수행
클러스터 리소스에 도달할 수 있는지 확인하기 위해 다음 클러스터 API 서비스 각각에 TCP 연결이 수행됩니다.
- Kubernetes API 서버 서비스
- Kubernetes API 서버 끝점
- OpenShift API 서버 서비스
- OpenShift API 서버 끝점
- 로드 밸런서
클러스터의 모든 노드에서 서비스 및 서비스 끝점에 도달할 수 있는지 확인하기 위해 다음 대상 각각에 TCP 연결이 수행됩니다.
- 상태 점검 대상 서비스
- 상태 점검 대상 끝점
9.2. 연결 상태 점검 구현
연결 검증 컨트롤러는 클러스터의 연결 확인 검사를 오케스트레이션합니다. 연결 테스트의 결과는 openshift-network-diagnostics
의 PodNetworkConnectivity
오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.
CNO(Cluster Network Operator)는 클러스터에 여러 리소스를 배포하여 연결 상태 점검을 전달하고 수신합니다.
- 상태 점검 소스
-
이 프로그램은
Deployment
오브젝트에서 관리하는 단일 포드 복제본 세트에 배포됩니다. 프로그램은PodNetworkConnectivity
오브젝트를 사용하고 각 오브젝트에 지정된spec.targetEndpoint
에 연결됩니다. - 상태 점검 대상
- 클러스터의 모든 노드에서 데몬 세트의 일부로 배포된 포드입니다. 포드는 인바운드 상태 점검을 수신 대기합니다. 모든 노드에 이 포드가 있으면 각 노드로의 연결을 테스트할 수 있습니다.
9.3. PodNetworkConnectivityCheck 오브젝트 필드
PodNetworkConnectivityCheck
오브젝트 필드는 다음 표에 설명되어 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
다음과 같은 형식의 오브젝트 이름:
|
|
|
오브젝트와 연결된 네임스페이스입니다. 이 값은 항상 |
|
|
연결 확인이 시작된 포드의 이름입니다(예: |
|
|
연결 검사의 대상입니다(예: |
|
| 사용할 TLS 인증서 설정입니다. |
|
| 해당하는 경우 사용되는 TLS 인증서의 이름입니다. 기본값은 빈 문자열입니다. |
|
| 연결 테스트의 조건 및 최근 연결 성공 및 실패의 로그를 나타내는 오브젝트입니다. |
|
| 연결 확인의 최신 상태 및 모든 이전 상태입니다. |
|
| 실패한 시도에서의 연결 테스트 로그입니다. |
|
| 중단 기간을 포함하는 테스트 로그를 연결합니다. |
|
| 성공적인 시도에서의 연결 테스트 로그입니다. |
다음 표에서는 status.conditions
배열에서 오브젝트 필드를 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
| 연결 조건이 하나의 상태에서 다른 상태로 전환된 시간입니다. |
|
| 사람이 읽기 쉬운 형식으로 마지막 전환에 대한 세부 정보입니다. |
|
| 머신에서 읽을 수 있는 형식으로 전환의 마지막 상태입니다. |
|
| 조건의 상태: |
|
| 조건의 유형입니다. |
다음 표에서는 status.conditions
배열에서 오브젝트 필드를 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
| 연결 오류가 해결될 때부터의 타임 스탬프입니다. |
|
| 서비스 중단의 성공적인 종료와 관련된 로그 항목을 포함한 연결 로그 항목입니다. |
|
| 사람이 읽을 수 있는 형식의 중단 세부 정보에 대한 요약입니다. |
|
| 연결 오류가 먼저 감지될 때부터의 타임 스탬프입니다. |
|
| 원래 오류를 포함한 연결 로그 항목입니다. |
연결 로그 필드
연결 로그 항목의 필드는 다음 표에 설명되어 있습니다. 오브젝트는 다음 필드에서 사용됩니다.
-
status.failures[]
-
status.successes[]
-
status.outages[].startLogs[]
-
status.outages[].endLogs[]
필드 | 유형 | 설명 |
---|---|---|
|
| 작업 기간을 기록합니다. |
|
| 사람이 읽을 수 있는 형식으로 상태를 제공합니다. |
|
|
머신에서 읽을 수 있는 형식으로 상태의 이유를 제공합니다. 값은 |
|
| 로그 항목이 성공 또는 실패인지를 나타냅니다. |
|
| 연결 확인 시작 시간입니다. |
9.4. 끝점에 대한 네트워크 연결 확인
클러스터 관리자는 API 서버, 로드 밸런서, 서비스 또는 포드와 같은 끝점의 연결을 확인할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
현재
PodNetworkConnectivityCheck
오브젝트를 나열하려면 다음 명령을 입력합니다.$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
출력 예
NAME AGE network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 73m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster 75m
연결 테스트 로그를 확인합니다.
- 이전 명령의 출력에서 연결 로그를 검토할 끝점을 식별합니다.
오브젝트를 확인하려면 다음 명령을 입력합니다:
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
여기서
<name>
은PodNetworkConnectivityCheck
오브젝트의 이름을 지정합니다.출력 예
apiVersion: controlplane.operator.openshift.io/v1alpha1 kind: PodNetworkConnectivityCheck metadata: name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 namespace: openshift-network-diagnostics ... spec: sourcePod: network-check-source-7c88f6d9f-hmg2f targetEndpoint: 10.0.0.4:6443 tlsClientCert: name: "" status: conditions: - lastTransitionTime: "2021-01-13T20:11:34Z" message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnectSuccess status: "True" type: Reachable failures: - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" outages: - end: "2021-01-13T20:11:34Z" endLogs: - latency: 2.032018ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T20:11:34Z" - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" message: Connectivity restored after 2m59.999789186s start: "2021-01-13T20:08:34Z" startLogs: - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" successes: - latency: 2.845865ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:14:34Z" - latency: 2.926345ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:13:34Z" - latency: 2.895796ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:12:34Z" - latency: 2.696844ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:11:34Z" - latency: 1.502064ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:10:34Z" - latency: 1.388857ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:09:34Z" - latency: 1.906383ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:08:34Z" - latency: 2.089073ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:07:34Z" - latency: 2.156994ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:06:34Z" - latency: 1.777043ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:05:34Z"
10장. 클러스터 네트워크의 MTU 변경
클러스터 관리자는 클러스터 설치 후 클러스터 네트워크의 MTU를 변경할 수 있습니다. MTU 변경을 종료하려면 클러스터 노드를 재부팅해야 하므로 이러한 변경이 중단됩니다. OVN-Kubernetes 또는 OpenShift SDN 클러스터 네트워크 공급자를 사용하여 클러스터의 MTU만 변경할 수 있습니다.
10.1. 클러스터 MTU 정보
클러스터 네트워크의 최대 전송 단위(MTU)를 설치하는 동안 클러스터에 있는 노드의 기본 네트워크 인터페이스 MTU를 기반으로 자동으로 탐지됩니다. 일반적으로 감지된 MTU를 재정의할 필요는 없습니다.
다음과 같은 몇 가지 이유로 클러스터 네트워크의 MTU를 변경할 수 있습니다.
- 클러스터 설치 중에 감지된 MTU가 인프라에 적합하지 않음
- 이제 클러스터 인프라에는 최적의 성능을 위해 다른 MTU가 필요한 노드 추가와 같이 다른 MTU가 필요합니다.
OVN-Kubernetes 및 OpenShift SDN 클러스터 네트워크 공급자에 대해서만 클러스터 MTU를 변경할 수 있습니다.
10.1.1. 서비스 중단 고려 사항
클러스터에서 MTU 변경을 시작하면 다음과 같은 결과가 서비스 가용성에 영향을 미칠 수 있습니다.
- 새 MTU로 마이그레이션을 완료하려면 두 개 이상의 롤링 재부팅이 필요합니다. 이 기간 동안 일부 노드를 재시작하기 때문에 사용할 수 없습니다.
- 절대 TCP 시간 초과 간격보다 짧은 시간 제한 간격을 사용하여 클러스터에 배포된 특정 애플리케이션은 MTU를 변경하는 동안 중단될 수 있습니다.
10.1.2. MTU 값 선택
MTU 마이그레이션을 계획할 때 다음과 같은 두 가지 MTU 값이 서로 다릅니다.
- Hardware MTU:이 MTU 값은 네트워크 인프라의 세부 사항에 따라 설정됩니다.
클러스터 네트워크 MTU: 이 MTU 값은 클러스터 네트워크 오버레이 오버헤드를 고려하기 위해 하드웨어 MTU보다 항상 적습니다. 특정 오버헤드는 클러스터 네트워크 공급자에 의해 결정됩니다.
-
OVN-Kubernetes:
100
바이트 -
OpenShift SDN:
50
바이트
-
OVN-Kubernetes:
클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우 클러스터의 모든 노드에서 사용하는 가장 낮은 MTU 값에서 클러스터 네트워크 공급자의 오버헤드 값을 제거해야 합니다. 예를 들어, 클러스터의 일부 노드에 9001
의 MTU가 있고 일부에는 1500
의 MTU가 있는 경우 이 값을 1400
으로 설정해야 합니다.
10.1.3. 마이그레이션 프로세스의 작동 방식
다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.
사용자 시작 단계 | OpenShift Container Platform 활동 |
---|---|
Cluster Network Operator 구성에서 다음 값을 설정합니다.
| CNO(Cluster Network Operator): 각 필드가 유효한 값으로 설정되었는지 확인합니다.
제공된 값이 유효한 경우 CNO는 MCO(Machine Config Operator): 클러스터의 각 노드의 롤링 재부팅을 수행합니다. |
클러스터에 있는 노드의 기본 네트워크 인터페이스의 MTU를 재구성합니다. 다음을 포함하여 다양한 방법을 사용하여 이를 수행할 수 있습니다.
| 해당 없음 |
클러스터 네트워크 공급자의 CNO 구성에서 | MCO(Machine Config Operator): 새 MTU 구성으로 클러스터의 각 노드가 롤링 재부팅을 수행합니다. |
10.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
미만으로 설정되어야 합니다.
-
OVN-Kubernetes: 클러스터 MTU는 클러스터의 가장 낮은 하드웨어 MTU 값보다
절차
클러스터 네트워크의 MTU를 늘리거나 줄이려면 다음 절차를 완료합니다.
클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.
$ oc describe network.config cluster
출력 예
... 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 ...
하드웨어 MTU 설정을 준비합니다.
DHCP를 사용하여 하드웨어 MTU를 지정하는 경우 다음 dnsmasq 구성과 같은 DHCP 구성을 업데이트합니다.
dhcp-option-force=26,<mtu>
다음과 같습니다.
<mtu>
- 알릴 DHCP 서버의 하드웨어 MTU를 지정합니다.
- PXE로 커널 명령줄을 사용하여 하드웨어 MTU를 지정하는 경우 그에 따라 해당 구성을 업데이트합니다.
NetworkManager 연결 구성에 하드웨어 MTU를 지정하는 경우 다음 단계를 완료합니다. 이 방법은 DHCP, 커널 명령줄 또는 기타 방법으로 네트워크 구성을 명시적으로 지정하지 않은 경우 OpenShift Container Platform의 기본값입니다. 다음 절차에서는 클러스터 노드에서 모두 동일한 기본 네트워크 구성을 사용하여 수정되지 않은 상태로 작동해야 합니다.
기본 네트워크 인터페이스를 찾습니다.
OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 다음 명령을 입력합니다.
$ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'
다음과 같습니다.
<node_name>
- 클러스터의 노드 이름을 지정합니다.
OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 다음 명령을 입력합니다.
$ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
다음과 같습니다.
<node_name>
- 클러스터의 노드 이름을 지정합니다.
이전 명령에서 반환된 인터페이스 이름에 대해 NetworkManager가 생성한 연결 프로필을 찾으려면 다음 명령을 입력합니다.
$ oc debug node/<node_name> -- chroot /host nmcli c | grep <interface>
다음과 같습니다.
<interface>
- 기본 네트워크 인터페이스의 이름을 지정합니다.
OpenShift SDN의 출력 예
Wired connection 1 46da4a6a-xxxx-xxxx-xxxx-ac0ca900f213 ethernet ens3
원래 연결 구성이 없는 OVN-Kubernetes의 출력 예
ovs-if-phys0 353774d3-0d3d-4ada-b14e-cd4d8824e2a8 ethernet ens4 ovs-port-phys0 332ef950-b2e5-4991-a0dc-3158977c35ca ovs-port ens4
OVN-Kubernetes 클러스터 네트워크 공급자의 경우 2개 또는 3개의 연결 관리자 프로필이 반환됩니다.
- 이전 명령에서 두 개의 프로필만 반환하는 경우 기본 NetworkManager 연결 구성을 템플릿으로 사용해야 합니다.
-
이전 명령에서 세 개의 프로필을 반환하는 경우 다음 수정 사항에 대한 템플릿으로
ovs-if-phys0
또는ovs-port-phys0
이라는 프로필을 사용합니다.
기본 네트워크 인터페이스에 대한 NetworkManager 연결 구성의 파일 이름을 가져오려면 다음 명령을 입력합니다.
$ oc debug node/<node_name> -- chroot /host nmcli -g UUID,FILENAME c show | grep <uuid> | cut -d: -f2
다음과 같습니다.
<node_name>
- 클러스터의 노드 이름을 지정합니다.
<uuid>
- NetworkManager 연결 프로필의 UUID를 지정합니다.
출력 예
/run/NetworkManager/system-connections/Wired connection 1.nmconnection
노드에서 NetworkManager 연결 구성을 복사하려면 다음 명령을 입력합니다.
$ oc debug node/<node_name> -- chroot /host cat "<profile_path>" > config.nmconnection
다음과 같습니다.
<node_name>
- 클러스터의 노드 이름을 지정합니다.
<profile_path>
- 이전 단계에서 NetworkManager 연결의 파일 시스템 경로를 지정합니다.
NetworkManager 연결 구성 예
[connection] id=Wired connection 1 uuid=3e96a02b-xxxx-xxxx-ad5d-61db28678130 type=ethernet autoconnect-priority=-999 interface-name=enp1s0 permissions= timestamp=1644109633 [ethernet] mac-address-blacklist= [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto [proxy] [.nmmeta] nm-generated=true
이전 단계에서
config.nmconnection
파일에 저장된 NetworkManager 구성 파일을 편집합니다.다음 값을 설정합니다.
-
802-3-Ethernet.mtu
: 시스템의 기본 네트워크 인터페이스에 대한 MTU를 지정합니다. -
connection.interface-name
: 선택 사항: 이 구성이 적용되는 네트워크 인터페이스 이름을 지정합니다. -
connection.autoconnect-priority
: 선택 사항:0
이상의 정수 우선 순위 값을 지정하여 이 프로필이 동일한 인터페이스에 대해 다른 프로필에서 사용되는지 확인하는 것이 좋습니다. OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 이 값은100
보다 작아야 합니다.
-
-
connection.uuid
필드를 제거합니다. 다음 값을 변경합니다.
-
connection.id
: 선택 사항: 다른 NetworkManager 연결 프로필 이름을 지정합니다.
-
NetworkManager 연결 구성 예
[connection] id=Primary network interface type=ethernet autoconnect-priority=10 interface-name=enp1s0 [802-3-ethernet] mtu=8051
컨트롤 플레인 노드 및 클러스터의 작업자 노드에 대해 하나씩 두 개의
MachineConfig
오브젝트를 생성합니다.control-plane-interface.bu
파일에 다음 Butane 구성을 생성합니다.variant: openshift version: 4.11.0 metadata: name: 01-control-plane-interface labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/NetworkManager/system-connections/<connection_name> 1 contents: local: config.nmconnection 2 mode: 0600
worker-interface.bu
파일에 다음 Butane 구성을 생성합니다.variant: openshift version: 4.11.0 metadata: name: 01-worker-interface labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/NetworkManager/system-connections/<connection_name> 1 contents: local: config.nmconnection 2 mode: 0644
다음 명령을 실행하여 Butane 구성에서
MachineConfig
오브젝트를 생성합니다.$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done
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> } } } } }'
다음과 같습니다.
<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} } } } }'
MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
$ oc get mcp
업데이트된 노드의 상태가
UPDATED=true
,UPDATING=false
,DEGRADED=false
입니다.참고기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.
호스트의 새 머신 구성 상태를 확인합니다.
머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.
$ oc describe node | egrep "hostname|machineconfig"
출력 예
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
다음 구문이 올바른지 확인합니다.
-
machineconfiguration.openshift.io/state
필드의 값은Done
입니다. -
machineconfiguration.openshift.io/currentConfig
필드의 값은machineconfiguration.openshift.io/desiredConfig
필드의 값과 동일합니다.
-
머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
여기서
<config_name>
은machineconfiguration.openshift.io/currentConfig
필드에서 머신 구성의 이름입니다.머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.
ExecStart=/usr/local/bin/mtu-migration.sh
기본 네트워크 인터페이스 MTU 값을 업데이트합니다.
NetworkManager 연결 구성으로 새 MTU를 지정하는 경우 다음 명령을 입력합니다. MachineConfig Operator는 클러스터의 노드 롤링 재부팅을 자동으로 수행합니다.
$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done
- DHCP 서버 옵션 또는 커널 명령줄 및 PXE로 새 MTU를 지정하는 경우 인프라에 필요한 변경을 수행합니다.
MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
$ oc get mcp
업데이트된 노드의 상태가
UPDATED=true
,UPDATING=false
,DEGRADED=false
입니다.참고기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.
호스트의 새 머신 구성 상태를 확인합니다.
머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.
$ oc describe node | egrep "hostname|machineconfig"
출력 예
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
다음 구문이 올바른지 확인합니다.
-
machineconfiguration.openshift.io/state
필드의 값은Done
입니다. -
machineconfiguration.openshift.io/currentConfig
필드의 값은machineconfiguration.openshift.io/desiredConfig
필드의 값과 동일합니다.
-
머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.
$ oc get machineconfig <config_name> -o yaml | grep path:
여기서
<config_name>
은machineconfiguration.openshift.io/currentConfig
필드에서 머신 구성의 이름입니다.머신 구성이 성공적으로 배포된 경우 이전 출력에
/etc/NetworkManager/system-connections/<connection_name
> 파일 경로가 포함됩니다.머신 구성에는
ExecStart=/usr/local/bin/mtu-migration.sh
행이 포함되어 있지 않아야 합니다.
MTU 마이그레이션을 완료하려면 다음 명령 중 하나를 입력합니다.
OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 다음을 수행합니다.
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
다음과 같습니다.
<mtu>
-
<
overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다
.
OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우:
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'
다음과 같습니다.
<mtu>
-
<
overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다
.
검증
클러스터의 노드가 이전 프로세스에서 지정한 MTU를 사용하는지 확인할 수 있습니다.
클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.
$ oc describe network.config cluster
노드의 기본 네트워크 인터페이스에 대한 현재 MTU를 가져옵니다.
클러스터의 노드를 나열하려면 다음 명령을 입력합니다.
$ oc get nodes
노드의 기본 네트워크 인터페이스의 현재 MTU 설정을 가져오려면 다음 명령을 입력합니다.
$ oc debug node/<node> -- chroot /host ip address show <interface>
다음과 같습니다.
<node>
- 이전 단계의 출력에서 노드를 지정합니다.
<interface>
- 노드의 기본 네트워크 인터페이스 이름을 지정합니다.
출력 예
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
10.3. 추가 리소스
11장. 노드 포트 서비스 범위 구성
클러스터 관리자는 사용 가능한 노드 포트 범위를 확장할 수 있습니다. 클러스터에서 많은 수의 노드 포트를 사용하는 경우 사용 가능한 포트 수를 늘려야 할 수 있습니다.
기본 포트 범위는 30000~32767
입니다. 기본 범위 이상으로 확장한 경우에도 포트 범위는 축소할 수 없습니다.
11.1. 사전 요구 사항
-
클러스터 인프라는 확장된 범위 내에서 지정한 포트에 대한 액세스를 허용해야 합니다. 예를 들어, 노드 포트 범위를
30000~32900
으로 확장하는 경우 방화벽 또는 패킷 필터링 구성에서32768~32900
의 포함 포트 범위를 허용해야 합니다.
11.2. 노드 포트 범위 확장
클러스터의 노드 포트 범위를 확장할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
노드 포트 범위를 확장하려면 다음 명령을 입력합니다.
<port>
를 새 범위에서 가장 큰 포트 번호로 변경합니다.$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
작은 정보또는 다음 YAML을 적용하여 노드 포트 범위를 업데이트할 수 있습니다.
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
출력 예
network.config.openshift.io/cluster patched
구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 업데이트가 적용되려면 몇 분 정도 걸릴 수 있습니다.
$ oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
출력 예
"service-node-port-range":["30000-33000"]
11.3. 추가 리소스
12장. IP 페일오버 구성
다음에서는 OpenShift Container Platform 클러스터의 Pod 및 서비스에 대한 IP 페일오버 구성에 대해 설명합니다.
IP 페일오버는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 방법은 없으므로 VIP가 없는 노드와 많은 VIP가 많은 다른 노드가 있을 수 있습니다 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.
VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.
IP 페일오버는 각 VIP의 포트를 모니터링하여 노드에서 포트에 연결할 수 있는지 확인합니다. 포트에 연결할 수 없는 경우 VIP가 노드에 할당되지 않습니다. 포트를 0
으로 설정하면 이 검사가 비활성화됩니다. 검사 스크립트는 필요한 테스트를 수행합니다.
IP 페일오버는 Keepalived를 사용하여 호스트 집합에서 외부 액세스가 가능한 VIP 주소 집합을 호스팅합니다. 각 VIP는 한 번에 하나의 호스트에서만 서비스를 제공합니다. keepalived는 VRRP(Virtual Router Redundancy Protocol: 가상 라우터 중복 프로토콜)를 사용하여 호스트 집합에서 VIP를 대상으로 서비스를 결정합니다. 호스트를 사용할 수 없게 되거나 Keepalived 서비스가 응답하지 않는 경우 VIP가 세트의 다른 호스트로 전환됩니다. 즉, 호스트를 사용할 수 있는 한 VIP는 항상 서비스됩니다.
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
를 사용할 수 있습니다.
서비스 정의에서 외부 IP를 사용하는 경우 VIP가 외부 IP로 설정되고 IP 페일오버 모니터링 포트가 서비스 포트로 설정됩니다. 노드 포트를 사용하면 포트는 클러스터의 모든 노드에서 열려 있으며, 서비스는 현재 VIP를 서비스하는 모든 노드에서 트래픽을 로드 밸런싱합니다. 이 경우 서비스 정의에서 IP 페일오버 모니터링 포트가 NodePort
로 설정됩니다.
NodePort
설정은 권한 있는 작업입니다.
VIP 서비스의 가용성이 높더라도 성능은 여전히 영향을 받을 수 있습니다. keepalived는 각 VIP가 구성의 일부 노드에서 서비스되도록 하고, 다른 노드에 아무것도 없는 경우에도 여러 VIP가 동일한 노드에 배치될 수 있도록 합니다. IP 페일오버가 동일한 노드에 여러 VIP를 배치하면 일련의 VIP에 걸쳐 외부적으로 로드 밸런싱을 수행하는 전략이 좌절될 수 있습니다.
ingressIP
를 사용하는 경우 ingressIP
범위와 동일한 VIP 범위를 갖도록 IP 페일오버를 설정할 수 있습니다. 모니터링 포트를 비활성화할 수도 있습니다. 이 경우 모든 VIP가 클러스터의 동일한 노드에 표시됩니다. 모든 사용자는 ingressIP
를 사용하여 서비스를 설정하고 고가용성으로 설정할 수 있습니다.
클러스터에는 최대 254개의 VIP가 있습니다.
12.1. IP 페일오버 환경 변수
다음 표에는 IP 페일오버를 구성하는 데 사용되는 변수가 표시되어 있습니다.
변수 이름 | 기본값 | 설명 |
---|---|---|
|
|
IP 페일오버 pod는 각 가상 IP(VIP)에서 이 포트에 대한 TCP 연결을 엽니다. 연결이 설정되면 서비스가 실행 중인 것으로 간주됩니다. 이 포트가 |
|
IP 페일오버가 VRRP(Virtual Router Redundancy Protocol) 트래픽을 보내는 데 사용하는 인터페이스 이름입니다. 기본값은 | |
|
|
생성할 복제본 수입니다. 이는 IP 페일오버 배포 구성의 |
|
복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예: | |
|
|
가상 라우터 ID를 설정하는 데 사용되는 오프셋 값입니다. 다른 오프셋 값을 사용하면 동일한 클러스터 내에 여러 IP 페일오버 구성이 존재할 수 있습니다. 기본 오프셋은 |
|
VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면 | |
| INPUT |
VRRP 트래픽을 허용하는 iptables 규칙을 자동으로 추가하는 |
| 애플리케이션이 작동하는지 확인하기 위해 정기적으로 실행되는 스크립트의 Pod 파일 시스템에 있는 전체 경로 이름입니다. | |
|
| 확인 스크립트가 실행되는 기간(초)입니다. |
| 상태가 변경될 때마다 실행되는 스크립트의 Pod 파일 시스템의 전체 경로 이름입니다. | |
|
|
더 높은 우선 순위의 호스트를 처리하는 전략입니다. |
12.2. IP 페일오버 구성
클러스터 관리자는 레이블 선택기에 정의된 대로 전체 클러스터 또는 노드의 하위 집합에서 IP 페일오버를 구성할 수 있습니다. 클러스터에서 여러 IP 페일오버 배포 구성을 설정할 수도 있습니다. 이 배포 구성은 서로 독립적입니다.
IP 페일오버 배포 구성을 사용하면 제약 조건 또는 사용된 라벨과 일치하는 각 노드에서 페일오버 pod가 실행됩니다.
이 Pod는 Keepalived를 실행하여 엔드포인트를 모니터링하고 VRRP(Virtual Router Redundancy Protocol)를 사용하여 첫 번째 노드가 서비스 또는 엔드포인트에 연결할 수 없는 경우 한 노드에서 다른 노드로의 가상 IP(VIP)를 페일오버할 수 있습니다.
프로덕션 용도의 경우 두 개 이상의 노드를 선택하는 selector
를 설정하고 선택한 노드 수와 동일한 replicas
를 설정합니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 풀 시크릿을 생성했습니다.
프로세스
IP 페일오버 서비스 계정을 생성합니다.
$ oc create sa ipfailover
hostNetwork
의 SCC(보안 컨텍스트 제약 조건)를 업데이트합니다.$ oc adm policy add-scc-to-user privileged -z ipfailover $ oc adm policy add-scc-to-user hostnetwork -z ipfailover
IP 페일오버를 구성하기 위해 배포 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: quay.io/openshift/origin-keepalived-ipfailover ports: - containerPort: 63000 hostPort: 63000 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: lib-modules mountPath: /lib/modules readOnly: true - name: host-slash mountPath: /host readOnly: true mountPropagation: HostToContainer - name: etc-sysconfig mountPath: /etc/sysconfig readOnly: true - name: config-volume mountPath: /etc/keepalive env: - name: OPENSHIFT_HA_CONFIG_NAME value: "ipfailover" - name: OPENSHIFT_HA_VIRTUAL_IPS 2 value: "1.1.1.1-2" - name: OPENSHIFT_HA_VIP_GROUPS 3 value: "10" - name: OPENSHIFT_HA_NETWORK_INTERFACE 4 value: "ens3" #The host interface to assign the VIPs - name: OPENSHIFT_HA_MONITOR_PORT 5 value: "30060" - name: OPENSHIFT_HA_VRRP_ID_OFFSET 6 value: "0" - name: OPENSHIFT_HA_REPLICA_COUNT 7 value: "2" #Must match the number of replicas in the deployment - name: OPENSHIFT_HA_USE_UNICAST value: "false" #- name: OPENSHIFT_HA_UNICAST_PEERS #value: "10.0.148.40,10.0.160.234,10.0.199.110" - name: OPENSHIFT_HA_IPTABLES_CHAIN 8 value: "INPUT" #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 9 # value: /etc/keepalive/mynotifyscript.sh - name: OPENSHIFT_HA_CHECK_SCRIPT 10 value: "/etc/keepalive/mycheckscript.sh" - name: OPENSHIFT_HA_PREEMPTION 11 value: "preempt_delay 300" - name: OPENSHIFT_HA_CHECK_INTERVAL 12 value: "2" livenessProbe: initialDelaySeconds: 10 exec: command: - pgrep - keepalived volumes: - name: lib-modules hostPath: path: /lib/modules - name: host-slash hostPath: path: / - name: etc-sysconfig hostPath: path: /etc/sysconfig # config-volume contains the check script # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh` - configMap: defaultMode: 0755 name: keepalived-checkscript name: config-volume imagePullSecrets: - name: openshift-pull-secret 13
- 1
- IP 페일오버 배포의 이름입니다.
- 2
- 복제할 IP 주소 범위 목록입니다. 이 정보를 제공해야 합니다. 예:
1.2.3.4-6,1.2.3.9
. - 3
- VRRP에 대해 생성할 그룹 수입니다. 설정하지 않으면
OPENSHIFT_HA_VIP_GROUPS
변수로 지정된 각 가상 IP 범위에 대해 그룹이 생성됩니다. - 4
- IP 페일오버가 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
- 배포를 만들기 전에 풀 시크릿을 생성합니다. 그렇지 않으면 배포를 생성할 때 오류가 발생합니다.
12.3. 가상 IP 주소 정보
keepalived는 가상 IP 주소 집합(VIP)을 관리합니다. 관리자는 다음 주소를 모두 확인해야 합니다.
- 클러스터 외부에서 구성된 호스트에서 액세스할 수 있습니다.
- 클러스터 내의 다른 용도로는 사용되지 않습니다.
각 노드의 keepalive는 필요한 서비스가 실행 중인지 여부를 결정합니다. 이 경우 VIP가 지원되고 Keepalived가 협상에 참여하여 VIP를 제공하는 노드를 결정합니다. 노드가 참여하려면 VIP의 감시 포트에서 서비스를 수신 대기하거나 검사를 비활성화해야 합니다.
세트의 각 VIP는 다른 노드에서 제공할 수 있습니다.
12.4. 검사 구성 및 스크립트 알림
keepalived는 사용자가 제공한 선택적 검사 스크립트를 주기적으로 실행하여 애플리케이션의 상태를 모니터링합니다. 예를 들어 스크립트는 요청을 발행하고 응답을 확인하여 웹 서버를 테스트할 수 있습니다.
검사 스크립트를 제공하지 않으면 TCP 연결을 테스트하는 간단한 기본 스크립트가 실행됩니다. 이 기본 테스트는 모니터 포트가 0
이면 비활성화됩니다.
각 IP 페일오버 pod는 pod가 실행 중인 노드에서 하나 이상의 가상 IP(VIP)를 관리하는 Keepalived 데몬을 관리합니다. Keepalived 데몬은 해당 노드의 각 VIP 상태를 유지합니다. 특정 노드의 특정 VIP는 master
, backup
, fault
상태일 수 있습니다.
master
상태에 있는 노드에서 해당 VIP에 대한 검사 스크립트가 실패하면 해당 노드의 VIP가 fault
상태가 되어 재협상을 트리거합니다. 재협상하는 동안 fault
상태에 있지 않은 노드의 모든 VIP가 VIP를 인수하는 노드를 결정하는 데 참여합니다. 결과적으로 VIP는 일부 노드에서 master
상태로 전환되고 VIP는 다른 노드에서 backup
상태로 유지됩니다.
backup
상태의 VIP 노드가 실패하면 해당 노드의 VIP가 fault
상태가 됩니다. 검사 스크립트가 fault
상태의 노드에서 VIP를 다시 전달하면 해당 노드의 VIP 상태가 fault
상태를 종료하고 master
상태로 전환하도록 협상합니다. 그런 다음 해당 노드의 VIP는 master
또는 backup
상태에 들어갈 수 있습니다.
클러스터 관리자는 상태가 변경될 때마다 호출되는 선택적 알림 스크립트를 제공할 수 있습니다. keepalived는 다음 세 개의 매개변수를 스크립트에 전달합니다.
-
$1
-group
또는instance
-
$2
-group
또는instance
이름 -
$3
- 새 상태:master
,backup
또는fault
검사 및 알림 스크립트가 IP 페일오버 Pod에서 실행되고 호스트 파일 시스템이 아닌 Pod 파일 시스템을 사용합니다. 그러나 IP 페일오버 Pod를 사용하면 /hosts
마운트 경로에서 호스트 파일 시스템을 사용할 수 있습니다. 검사 또는 알림 스크립트를 구성할 때 스크립트의 전체 경로를 제공해야 합니다. 스크립트를 제공하는 데 권장되는 접근 방식은 구성 맵을 사용하는 것입니다.
Keepalived가 시작될 때마다 로드되는 검사 및 알림 스크립트의 전체 경로 이름이 Keepalived 구성 파일인 _/etc/keepalived/keepalived.conf
에 추가됩니다. 스크립트는 다음과 같이 구성 맵을 사용하여 Pod에 추가할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
원하는 스크립트를 생성하고 해당 스크립트를 유지할 구성 맵을 생성합니다. 스크립트에는 입력 인수가 없으며
OK
의 경우0
을fail
의 경우1
을 반환해야 합니다.검사 스크립트,
mycheckscript.sh
:#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0
config map을 생성합니다.
$ oc create configmap mycustomcheck --from-file=mycheckscript.sh
pod에 스크립트를 추가합니다. 마운트된 구성 맵 파일의
defaultMode
는oc
명령을 사용하거나 배포 구성을 편집하여 실행할 수 있어야 합니다.0755
,493
10진수 값이 일반적입니다.$ oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
$ oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
참고oc set env
명령은 공백 문자를 구분합니다.=
기호 양쪽에 공백이 없어야 합니다.작은 정보또는
ipfailover-keepalived
배포 구성을 편집할 수 있습니다.$ oc edit deploy ipfailover-keepalived
spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT 1 value: /etc/keepalive/mycheckscript.sh ... volumeMounts: 2 - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst ... volumes: 3 - configMap: defaultMode: 0755 4 name: customrouter name: config-volume ...
변경 사항을 저장하고 편집기를 종료합니다. 이렇게 하면
ipfailover-keepalived
가 다시 시작됩니다.
12.5. VRRP 선점 구성
노드의 가상 IP(VIP)가 검사 스크립트를 전달하여 fault
상태를 벗어나면 노드의 VIP가 현재 master
상태에 있는 노드의 VIP보다 우선 순위가 낮은 경우 backup
상태가 됩니다. 그러나 fault
상태를 벗어나는 노드의 VIP가 우선 순위가 더 높은 경우 선점 전략이 클러스터에서 해당 역할을 결정합니다.
nopreempt
전략에서는 호스트의 우선 순위가 낮은 VIP에서 호스트의 우선 순위가 높은 VIP로 master
를 이동하지 않습니다. preempt_delay 300
을 사용하면 기본값인 Keepalived가 지정된 300초 동안 기다린 후 fault
를 호스트의 우선 순위 VIP로 이동합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다.
프로세스
선점 기능을 지정하려면
oc edit deploy ipfailover-keepalived
를 입력하여 라우터 배포 구성을 편집합니다.$ oc edit deploy ipfailover-keepalived
... spec: containers: - env: - name: OPENSHIFT_HA_PREEMPTION 1 value: preempt_delay 300 ...
- 1
OPENSHIFT_HA_PREEMPTION
값을 설정합니다.-
preempt_delay 300
: Keepalived는 지정된 300초 동안 기다린 후 호스트의 우선 순위가 높은 VIP로master
를 이동합니다. 이는 기본값입니다. -
nopreempt
: 더 낮은 우선 순위 호스트에서 더 높은 우선 순위 호스트로master
를 이동하지 않습니다.
-
12.6. VRRP ID 오프셋 정보
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-ids
는 1..255
범위의 값이 있을 수 있습니다.
IP 페일오버 배포 구성이 여러 개인 경우 배포 구성의 VIP 수를 늘리고 vrrp-id
범위가 겹치지 않도록 OPENSHIFT_HA_VRRP_ID_OFFSET
을 지정해야 합니다.
12.7. 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" ...
- 1
- 7개의 VIP가 있는 환경에서
OPENSHIFT_HA_VIP_GROUPS
가3
으로 설정된 경우 3개의 그룹을 생성하여 3개의 VIP를 첫 번째 그룹에 할당하고 2개의 VIP를 나머지 2개의 그룹에 할당합니다.
OPENSHIFT_HA_VIP_GROUPS
로 설정된 그룹 수가 페일오버로 설정된 IP 주소 수보다 적으면 그룹에는 두 개 이상의 IP 주소가 포함되어 있으며 모든 주소가 하나의 단위로 이동합니다.
12.8. ingressIP의 고가용성
클라우드 이외의 클러스터에서 서비스에 대한 IP 페일오버 및 ingressIP
를 결합할 수 있습니다. 그 결과 ingressIP
를 사용하여 서비스를 생성하는 사용자를 위한 고가용성 서비스가 생성됩니다.
사용 방법은 ingressIPNetworkCIDR
범위를 지정한 다음 ipfailover 구성을 생성할 때 동일한 범위를 사용하는 것입니다.
IP 페일오버는 전체 클러스터에 대해 최대 255개의 VIP를 지원할 수 있으므로 ingressIPNetworkCIDR
은 /24
이하이어야 합니다.
12.9. IP 페일오버 제거
IP 페일오버가 처음 구성되면 클러스터의 작업자 노드는 Keepalived에 대해 224.0.0.18
의 멀티 캐스트 패킷을 명시적으로 허용하는 iptables
규칙을 사용하여 수정됩니다. 노드를 변경하여 IP 페일오버를 제거하려면 iptables
규칙을 제거하고 Keepalived에서 사용하는 가상 IP 주소를 제거하는 작업을 실행해야 합니다.
절차
선택 사항: 구성 맵으로 저장된 점검 및 알림 스크립트를 식별하고 삭제합니다.
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}"
출력 예
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheck
이전 단계에서 볼륨으로 사용되는 구성 맵의 이름을 제공한 경우 구성 맵을 삭제합니다.
$ oc delete configmap <configmap_name>
IP 페일오버를 위한 기존 배포를 식별합니다.
$ oc get deployment -l ipfailover
출력 예
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105d
배포를 삭제합니다.
$ oc delete deployment <ipfailover_deployment_name>
ipfailover
서비스 계정을 제거합니다.$ oc delete sa ipfailover
IP 페일오버를 처음 구성할 때 추가된 IP 테이블 규칙을 제거하는 작업을 실행합니다.
다음 예와 유사한 콘텐츠를 사용하여
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: quay.io/openshift/origin-keepalived-ipfailover:4.11 command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"] nodeSelector: kubernetes.io/hostname: <host_name> <.> restartPolicy: Never
<.> IP 페일오버용으로 구성된 클러스터의 각 노드에 대해 작업을 실행하고 매번 호스트 이름을 바꿉니다.
작업을 실행합니다.
$ oc create -f remove-ipfailover-job.yaml
출력 예
job.batch/remove-ipfailover-2h8dm created
검증
작업이 IP 페일오버의 초기 구성을 제거했는지 확인합니다.
$ oc logs job/remove-ipfailover-2h8dm
출력 예
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...
13장. 인터페이스 수준 네트워크 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 변경만 지원합니다.
13.1. 튜닝 CNI 구성
다음 절차에서는 인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects
sysctl을 변경하기 위해 튜닝 CNI를 구성합니다. 이 예제에서는 ICMP 리디렉션 패킷을 수락하고 전송할 수 있습니다.
프로세스
다음 콘텐츠를 사용하여
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 } } ] }
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" } } ] }'
다음 명령을 실행하여 yaml을 적용합니다.
$ oc apply -f tuning-example.yaml
출력 예
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
다음과 유사한 네트워크 연결 정의를 사용하여
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
- 1
- 구성된
NetworkAttachmentDefinition
의 이름을 지정합니다. - 2
Run
AsUser는 컨테이너가 실행되는 사용자 ID를 제어합니다.- 3
runAsGroup
은 컨테이너가 실행되는 기본 그룹 ID를 제어합니다.- 4
allowPrivilegeEscalation
은 Pod에서 권한 에스컬레이션을 허용하도록 요청할 수 있는지 여부를 결정합니다. 지정되지 않은 경우 기본값은 true입니다. 이 부울은 컨테이너 프로세스에no_new_privs
플래그가 설정되는지 여부를 직접 제어합니다.- 5
기능을
사용하면 전체 루트 액세스 권한을 부여하지 않고 권한 있는 작업을 수행할 수 있습니다. 이 정책은 모든 기능이 Pod에서 삭제되도록 합니다.- 6
runAsNonRoot: true
를 사용하려면 컨테이너가 0이 아닌 다른 UID와 함께 컨테이너를 실행해야 합니다.- 7
RuntimeDefault
는 Pod 또는 컨테이너 워크로드에 대한 기본 seccomp 프로필을 활성화합니다.
다음 명령을 실행하여 yaml을 적용합니다.
$ oc apply -f examplepod.yaml
다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.
$ oc get pod
출력 예
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
다음 명령을 실행하여 Pod에 로그인합니다.
$ oc rsh tunepod
구성된 sysctl 플래그 값을 확인합니다. 예를 들어 다음 명령을 실행하여
net.ipv4.conf.net1.accept_redirects
값을 찾습니다.sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
예상 출력
net.ipv4.conf.net1.accept_redirects = 1
13.2. 추가 리소스
14장. 베어 메탈 클러스터에서 SCTP(Stream Control Transmission Protocol) 사용
클러스터 관리자는 클러스터에서 SCTP(Stream Control Transmission Protocol)를 사용할 수 있습니다.
14.1. OpenShift Container Platform에서의 SCTP(스트림 제어 전송 프로토콜)
클러스터 관리자는 클러스터의 호스트에서 SCTP를 활성화 할 수 있습니다. RHCOS(Red Hat Enterprise Linux CoreOS)에서 SCTP 모듈은 기본적으로 비활성화되어 있습니다.
SCTP는 IP 네트워크에서 실행되는 안정적인 메시지 기반 프로토콜입니다.
활성화하면 Pod, 서비스, 네트워크 정책에서 SCTP를 프로토콜로 사용할 수 있습니다. type
매개변수를 ClusterIP
또는 NodePort
값으로 설정하여 Service
를 정의해야 합니다.
14.1.1. SCTP 프로토콜을 사용하는 구성의 예
protocol
매개변수를 포드 또는 서비스 오브젝트의 SCTP
값으로 설정하여 SCTP를 사용하도록 포드 또는 서비스를 구성할 수 있습니다.
다음 예에서는 pod가 SCTP를 사용하도록 구성되어 있습니다.
apiVersion: v1 kind: Pod metadata: namespace: project1 name: example-pod spec: containers: - name: example-pod ... ports: - containerPort: 30100 name: sctpserver protocol: SCTP
다음 예에서는 서비스가 SCTP를 사용하도록 구성되어 있습니다.
apiVersion: v1 kind: Service metadata: namespace: project1 name: sctpserver spec: ... ports: - name: sctpserver protocol: SCTP port: 30100 targetPort: 30100 type: ClusterIP
다음 예에서 NetworkPolicy
오브젝트는 특정 레이블이 있는 모든 Pod의 포트 80
에서 SCTP 네트워크 트래픽에 적용되도록 구성되어 있습니다.
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-sctp-on-http spec: podSelector: matchLabels: role: web ingress: - ports: - protocol: SCTP port: 80
14.2. SCTP(스트림 제어 전송 프로토콜) 활성화
클러스터 관리자는 클러스터의 작업자 노드에 블랙리스트 SCTP 커널 모듈을 로드하고 활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 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
MachineConfig
오브젝트를 생성하려면 다음 명령을 입력합니다.$ oc create -f load-sctp-module.yaml
선택 사항: MachineConfig Operator가 구성 변경 사항을 적용하는 동안 노드의 상태를 보려면 다음 명령을 입력합니다. 노드 상태가
Ready
로 전환되면 구성 업데이트가 적용됩니다.$ oc get nodes
14.3. SCTP(Stream Control Transmission Protocol)의 활성화 여부 확인
SCTP 트래픽을 수신하는 애플리케이션으로 pod를 만들고 서비스와 연결한 다음, 노출된 서비스에 연결하여 SCTP가 클러스터에서 작동하는지 확인할 수 있습니다.
사전 요구 사항
-
클러스터에서 인터넷에 액세스하여
nc
패키지를 설치합니다. -
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
SCTP 리스너를 시작하는 포드를 생성합니다.
다음 YAML로 pod를 정의하는
sctp-server.yaml
파일을 생성합니다.apiVersion: v1 kind: Pod metadata: name: sctpserver labels: app: sctpserver spec: containers: - name: sctpserver image: registry.access.redhat.com/ubi8/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"] ports: - containerPort: 30102 name: sctpserver protocol: SCTP
다음 명령을 입력하여 pod를 생성합니다.
$ oc create -f sctp-server.yaml
SCTP 리스너 pod에 대한 서비스를 생성합니다.
다음 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
서비스를 생성하려면 다음 명령을 입력합니다.
$ oc create -f sctp-service.yaml
SCTP 클라이언트에 대한 pod를 생성합니다.
다음 YAML을 사용하여
sctp-client.yaml
파일을 만듭니다.apiVersion: v1 kind: Pod metadata: name: sctpclient labels: app: sctpclient spec: containers: - name: sctpclient image: registry.access.redhat.com/ubi8/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"]
Pod
오브젝트를 생성하려면 다음 명령을 입력합니다.$ oc apply -f sctp-client.yaml
서버에서 SCTP 리스너를 실행합니다.
서버 Pod에 연결하려면 다음 명령을 입력합니다.
$ oc rsh sctpserver
SCTP 리스너를 시작하려면 다음 명령을 입력합니다.
$ nc -l 30102 --sctp
서버의 SCTP 리스너에 연결합니다.
- 터미널 프로그램에서 새 터미널 창 또는 탭을 엽니다.
sctpservice
서비스의 IP 주소를 얻습니다. 다음 명령을 실행합니다.$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
클라이언트 Pod에 연결하려면 다음 명령을 입력합니다.
$ oc rsh sctpclient
SCTP 클라이언트를 시작하려면 다음 명령을 입력합니다.
<cluster_IP>
를sctpservice
서비스의 클러스터 IP 주소로 변경합니다.# nc <cluster_IP> 30102 --sctp
15장. PTP 하드웨어 사용
OpenShift Container Platform 클러스터 노드에서 linuxptp
서비스를 구성하고 PTP 지원 하드웨어를 사용할 수 있습니다.
15.1. PTP 하드웨어 정보
PTP Operator를 배포하여 OpenShift Container Platform 콘솔 또는 OpenShift CLI (oc
)를 사용하여 PTP를 설치할 수 있습니다. PTP Operator는 linuxptp
서비스를 생성 및 관리하고 다음 기능을 제공합니다.
- 클러스터에서 PTP 가능 장치 검색.
-
linuxptp
서비스의 구성 관리. -
PTP Operator
cloud-event-proxy
사이드카를 사용하여 애플리케이션의 성능 및 안정성에 부정적인 영향을 주는 PTP 클록 이벤트 알림
PTP Operator는 베어 메탈 인프라에서만 프로비저닝된 클러스터에서 PTP 가능 장치와 함께 작동합니다.
15.2. PTP 정보
PTP(Precision Time Protocol)는 네트워크에서 클럭을 동기화하는 데 사용됩니다. 하드웨어 지원과 함께 사용할 경우 PTP는 마이크로초 미만의 정확성을 수행할 수 있으며 NTP(Network Time Protocol)보다 더 정확합니다.
linuxptp
패키지에는 클럭 동기화를 위한 ptp4l
및 phc2sys
프로그램이 포함되어 있습니다. ptp4l
은 PTP 경계 클록과 일반 클록을 구현합니다. ptp4l
는 하드웨어 타임스탬프를 사용하여 PTP 하드웨어 클록을 소스 클록에 동기화하고 소프트웨어 타임스탬프를 사용하여 시스템 클록을 소스 클록에 동기화합니다. phc2sys
는 하드웨어 타임스탬프에 NIC(네트워크 인터페이스 컨트롤러)의 PTP 하드웨어 클록에 동기화하는 데 사용됩니다.
15.2.1. PTP 도메인의 요소
PTP는 네트워크에 연결된 여러 노드를 각 노드의 클럭과 동기화하는 데 사용됩니다. PTP에 의해 동기화된 클럭은 소스 대상 계층 구조로 구성됩니다. 계층 구조는 모든 클럭에서 실행되는 최상의 마스터 시계(BMC) 알고리즘에 의해 자동으로 생성 및 업데이트됩니다. 대상 클럭은 소스 클럭에 동기화되며 대상 클럭은 다른 다운스트림 시계의 소스가 될 수 있습니다. 다음 유형의 클럭을 구성에 포함할 수 있습니다.
- GRandmaster 클록
- 마스터 클록은 네트워크의 다른 클록에 표준 시간 정보를 제공하며 정확하고 안정적인 동기화를 보장합니다. 타임스탬프를 작성하고 다른 클럭의 시간 요청에 응답합니다. Grandmaster 시계를 GPS(Global Positioning System) 시간 소스에 동기화할 수 있습니다.
- 일반 클록
- 일반 클록에는 네트워크의 위치에 따라 소스 또는 대상 클록의 역할을 수행할 수 있는 단일 포트가 연결되어 있습니다. 일반 클록은 타임스탬프를 읽고 쓸 수 있습니다.
- 경계 클록
- 경계 클록에는 두 개 이상의 통신 경로에 포트가 있으며, 동시에 소스와 다른 대상 클록의 대상일 수 있습니다. 경계 클록은 대상 클록으로 작동합니다. 대상 클럭이 타이밍 메시지를 수신하고 지연을 조정한 다음 네트워크를 전달하기 위한 새 소스 시간 신호를 생성합니다. 경계 클록은 소스 클록과 정확하게 동기화되는 새로운 타이밍 패킷을 생성하며 소스 클럭에 직접 보고하는 연결된 장치의 수를 줄일 수 있습니다.
15.2.2. NTP를 통한 PTP의 이점
PTP가 NTP를 능가하는 주요 이점 중 하나는 다양한 NIC(네트워크 인터페이스 컨트롤러) 및 네트워크 스위치에 있는 하드웨어 지원입니다. 특수 하드웨어를 사용하면 PTP가 메시지 전송 지연을 고려하여 시간 동기화의 정확성을 향상시킬 수 있습니다. 최대한의 정확성을 달성하려면 PTP 클록 사이의 모든 네트워킹 구성 요소를 PTP 하드웨어를 사용하도록 설정하는 것이 좋습니다.
NIC는 전송 및 수신 즉시 PTP 패킷을 타임스탬프할 수 있으므로 하드웨어 기반 PTP는 최적의 정확성을 제공합니다. 이를 운영 체제에서 PTP 패킷을 추가로 처리해야 하는 소프트웨어 기반 PTP와 비교합니다.
PTP를 활성화하기 전에 필수 노드에 대해 NTP가 비활성화되어 있는지 확인합니다. MachineConfig
사용자 정의 리소스를 사용하여 chrony 타임 서비스 (chronyd
)를 비활성화할 수 있습니다. 자세한 내용은 chrony 타임 서비스 비활성화를 참조하십시오.
15.2.3. 듀얼 NIC 하드웨어에서 PTP 사용
OpenShift Container Platform은 클러스터에서 정밀한 PTP 타이밍을 위해 단일 및 듀얼 NIC 하드웨어를 지원합니다.
대역 중 사양을 제공하는 5G 통신망의 경우 각 가상 분산 장치(vDU)는 6개의 무선 단위(RU)에 연결되어 있어야 합니다. 이러한 연결을 수행하기 위해 각 vDU 호스트에 경계 시계로 구성된 2개의 NIC가 필요합니다.
듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 별도의 ptp4l
인스턴스와 함께 각 NIC를 동일한 업스트림 리더 시계에 연결할 수 있습니다.
15.3. CLI를 사용하여 PTP Operator 설치
클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.
사전 요구 사항
- PTP를 지원하는 하드웨어가 있는 노드로 베어 메탈 하드웨어에 설치된 클러스터
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
절차
PTP Operator의 네임스페이스를 생성합니다.
다음 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"
네임스페이스
CR을 생성합니다.$ oc create -f ptp-namespace.yaml
PTP Operator를 위한 Operator 그룹을 생성합니다.
다음 YAML을
ptp-operatorgroup.yaml
파일에 저장합니다.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ptp-operators namespace: openshift-ptp spec: targetNamespaces: - openshift-ptp
OperatorGroup
CR을 생성합니다.$ oc create -f ptp-operatorgroup.yaml
PTP Operator에 등록합니다.
다음 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
서브스크립션
CR을 생성합니다.$ oc create -f ptp-sub.yaml
Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
출력 예
Name Phase 4.12.0-202301261535 Succeeded
15.4. 웹 콘솔을 사용하여 PTP Operator 설치
클러스터 관리자는 웹 콘솔을 사용하여 PTP Operator를 설치할 수 있습니다.
이전 섹션에서 언급한 것처럼 네임스페이스 및 Operator group을 생성해야 합니다.
프로세스
OpenShift Container Platform 웹 콘솔을 사용하여 PTP Operator를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 PTP Operator를 선택한 다음 설치를 클릭합니다.
- Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-ptp를 선택합니다. 그런 다음, 설치를 클릭합니다.
선택 사항: PTP Operator가 설치되었는지 확인합니다.
- Operator → 설치된 Operator 페이지로 전환합니다.
PTP Operator가 openshift-ptp 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.
참고설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
-
Workloads → Pod 페이지로 이동하여
openshift-ptp
프로젝트에서 Pod 로그를 확인합니다.
15.5. PTP 장치 구성
PTP Operator는 NodePtpDevice.ptp.openshift.io
CRD(custom resource definition)를 OpenShift Container Platform에 추가합니다.
PTP Operator는 각 노드에서 PTP 가능 네트워크 장치를 클러스터에서 검색합니다. 호환 가능한 PTP 가능 네트워크 장치를 제공하는 각 노드에 대해 NodePtpDevice
CR(사용자 정의 리소스) 오브젝트를 생성하고 업데이트합니다.
15.5.1. 클러스터에서 PTP 가능 네트워크 장치 검색
클러스터에서 PTP 가능 네트워크 장치의 전체 목록을 반환하려면 다음 명령을 실행합니다.
$ oc get NodePtpDevice -n openshift-ptp -o yaml
출력 예
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 ...
15.5.2. linuxptp 서비스를 일반 클럭으로 구성
PtpConfig
CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp
서비스(ptp4l
,phc2sys
)를 일반 시계로 구성할 수 있습니다.
다음 예제 PtpConfig
CR을 기반으로 linuxptp
서비스를 특정 하드웨어 및 환경에 대한 일반 클럭으로 구성합니다. 이 예제 CR에서는 ptp4lOpts
,ptp4lConf
및 ptpClockThreshold
에 대한 적절한 값을 설정하여 PTP 빠른 이벤트를 구성합니다. ptpClockThreshold
는 이벤트가 활성화된 경우에만 사용됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - PTP Operator를 설치합니다.
절차
다음
PtpConfig
CR을 생성한 다음 YAML을ordinary-clock-ptp-config.yaml
파일에 저장합니다.apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ordinary-clock-ptp-config 1 namespace: openshift-ptp spec: profile: 2 - name: "<profile_name>" 3 interface: ""<interface_name>" 4 ptp4lOpts: "-2 -s --summary_interval -4" 5 phc2sysOpts: "-a -r -n 24" 6 ptp4lConf: | 7 [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 10 8 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 # # 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 9 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 ptpSchedulingPolicy: SCHED_OTHER 10 ptpSchedulingPriority: 10 11 ptpClockThreshold: 12 holdOverTimeout: 5 maxOffsetThreshold: 100 minOffsetThreshold: -100 recommend: 13 - profile: "profile1" 14 priority: 0 15 match: 16 - nodeLabel: "node-role.kubernetes.io/worker" 17 nodeName: "compute-0.example.com" 18
- 1
PtpConfig
CR의 이름입니다.- 2
- 하나 이상의
profile
오브젝트의 배열을 지정합니다. - 3
- 프로필 오브젝트의 고유 이름을 지정합니다.
- 4
ptp4l
서비스에서 사용할 네트워크 인터페이스를 지정합니다(예:ens787f1
).- 5
ptp4l
서비스에 대한 시스템 구성 옵션을 지정합니다. 예를 들어-2
는 IEEE 802.3 네트워크 전송을 선택합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름-i <interface>
및 서비스 구성 파일-f /etc/ptp4l.conf
를 포함하지 않아야 합니다. 이 인터페이스에서 PTP 빠른 이벤트를 사용하려면--summary_interval -4
를 추가합니다.- 6
phc2sys
서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서phc2sys
서비스를 시작하지 않습니다. Intel Coumbiaville 800 시리즈 NIC의 경우phc2sysOpts
옵션을-a -r -m -n 24 -N 8 -R 16
으로 설정합니다.-m
은stdout
에 메시지를 출력합니다.linuxptp-daemon
DaemonSet
은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.- 7
- 기본
/etc/ptp4l.conf
파일을 대체할 구성이 포함된 문자열을 지정합니다. 기본 구성을 사용하려면 필드를 비워 둡니다. - 8
- Intel Coumbiaville 800 시리즈 NIC의 경우
tx_timestamp_timeout
을50
으로 설정합니다. - 9
- Intel Columbiaville 800 시리즈 NIC의 경우
boundary_clock_jbod
를0
으로 설정합니다. - 10
ptp4l
및phc2sys
프로세스에 대한 스케줄링 정책입니다. 기본값은-4.8_OTHER
입니다. Havana 스케줄링을지원하는 시스템에서 Retain_
VRF를 사용합니다.- 11
ptpSchedulingPolicy
가ECDHE_FIFO로 설정된 경우
우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다.ptp4l
및phc2sys
프로세스의 FIFOptpSchedulingPriority
필드는ptpSchedulingPolicy
가ECDHE_OTHER
로 설정된 경우 사용되지 않습니다.- 12
- 선택 사항:
ptpClockThreshold
가 없으면 기본값이ptpClockThreshold
필드에 사용됩니다. 스탠자는 기본ptpClockThreshold
값을 표시합니다.ptpClockThreshold
값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다.holdOverTimeout
은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가FREERUN
로 변경되기 전 시간(초)입니다.maxOffsetThreshold
및minOffsetThreshold
설정은CLOCK_REALTIME
(phc2sys
) 또는 마스터 오프셋(ptp4l
)의 값과 비교되는 나노초에 오프셋 값을 구성합니다.ptp4l
또는phc2sys
오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가FREERUN
로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가LOCKED
로 설정됩니다. - 13
프로필
을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의recommend
오브젝트 배열을 지정합니다.- 14
profile
섹션에 정의된profile
오브젝트 이름을 지정합니다.- 15
- 일반 시계의 경우
priority
를0
으로 설정합니다. - 16
nodeLabel
또는nodeName
으로일치
규칙을 지정합니다.- 17
oc get nodes --show-labels
명령을 사용하여 노드 오브젝트에서node.Labels
의키로
nodeLabel
을 지정합니다.- 18
oc get nodes
명령을 사용하여 노드 오브젝트에서node.Name
으로nodeName
을 지정합니다.
다음 명령을 실행하여
PtpConfig
CR을 생성합니다.$ oc create -f ordinary-clock-ptp-config.yaml
검증
PtpConfig
프로필이 노드에 적용되었는지 확인합니다.다음 명령을 실행하여
openshift-ptp
네임스페이스에서 Pod 목록을 가져옵니다.$ oc get pods -n openshift-ptp -o wide
출력 예
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
프로필이 올바른지 확인합니다.
PtpConfig
프로필에 지정한 노드에 해당하는linuxptp
데몬의 로그를 검사합니다. 다음 명령을 실행합니다.$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
출력 예
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 --summary_interval -4 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
추가 리소스
- PTP 하드웨어의 FIFO 우선 순위 스케줄링에 대한 자세한 내용은 PTP 하드웨어에 대한 FIFO 우선 순위 스케줄링 구성 을 참조하십시오.
15.5.3. linuxptp 서비스를 경계 시계로 구성
PtpConfig
CR(사용자 정의 리소스) 오브젝트를 생성하여 linuxptp
서비스(ptp4l
,phc2sys
)를 경계 시계로 구성할 수 있습니다.
다음 예제 PtpConfig
CR을 기반으로 linuxptp
서비스를 특정 하드웨어 및 환경에 대한 경계 클럭으로 구성합니다. 이 예제 CR은 또한 ptp4lOpts
,ptp4lConf
, ptpClockThreshold
에 적절한 값을 설정하여 PTP 빠른 이벤트를 구성합니다. ptpClockThreshold
는 이벤트가 활성화된 경우에만 사용됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - PTP Operator를 설치합니다.
절차
다음
PtpConfig
CR을 만든 다음 YAML을boundary-clock-ptp-config.yaml
파일에 저장합니다.apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config 1 namespace: openshift-ptp spec: profile: 2 - name: "<profile_name>" 3 ptp4lOpts: "-2 --summary_interval -4" 4 ptp4lConf: | 5 [ens1f0] 6 masterOnly 0 [ens1f3] 7 masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 #slaveOnly 1 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 # # Runtime 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 10 8 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 # # 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 9 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 phc2sysOpts: "-a -r -n 24" 10 ptpSchedulingPolicy: SCHED_OTHER 11 ptpSchedulingPriority: 10 12 ptpClockThreshold: 13 holdOverTimeout: 5 maxOffsetThreshold: 100 minOffsetThreshold: -100 recommend: 14 - profile: "<profile_name>" 15 priority: 10 16 match: 17 - nodeLabel: "<node_label>" 18 nodeName: "<node_name>" 19
- 1
PtpConfig
CR의 이름입니다.- 2
- 하나 이상의
profile
오브젝트의 배열을 지정합니다. - 3
- 프로파일 오브젝트를 고유하게 식별하는 프로파일 오브젝트의 이름을 지정합니다.
- 4
ptp4l
서비스에 대한 시스템 구성 옵션을 지정합니다. 옵션은 네트워크 인터페이스 이름과 서비스 구성 파일이 자동으로 추가되므로 네트워크 인터페이스 이름-i <interface>
및 서비스 구성 파일-f /etc/ptp4l.conf
를 포함하지 않아야 합니다.- 5
ptp4l
을 경계 클록으로 시작하는 데 필요한 구성을 지정합니다. 예를 들어ens1f0
은 그랜드 마스터 클록에서 동기화되고ens1f3
은 연결된 장치를 동기화합니다.- 6
- 동기화 클럭을 수신하는 인터페이스입니다.
- 7
- 동기화 시계를 전송하는 인터페이스입니다.
- 8
- Intel Coumbiaville 800 시리즈 NIC의 경우
tx_timestamp_timeout
을50
으로 설정합니다. - 9
- Intel Columbiaville 800 시리즈 NIC의 경우
boundary_clock_jbod
가0
으로 설정되어 있는지 확인합니다. Intel Fortville X710 시리즈 NIC의 경우boundary_clock_jbod
가1
로 설정되어 있는지 확인합니다. - 10
phc2sys
서비스에 대한 시스템 구성 옵션을 지정합니다. 이 필드가 비어 있으면 PTP Operator에서phc2sys
서비스를 시작하지 않습니다.- 11
- ptp4l 및 phc2sys 프로세스에 대한 스케줄링 정책입니다. 기본값은-4.8
_OTHER
입니다. Havana 스케줄링을지원하는 시스템에서 Retain_
VRF를 사용합니다. - 12
ptpSchedulingPolicy
가ECDHE_FIFO로 설정된 경우
우선 순위를 설정하는 데 사용되는 1-65의 정수 값입니다.ptp4l
및phc2sys
프로세스의 FIFOptpSchedulingPriority
필드는ptpSchedulingPolicy
가ECDHE_OTHER
로 설정된 경우 사용되지 않습니다.- 13
- 선택 사항:
ptpClockThreshold
스탠자가 없으면ptpClockThreshold
필드에 기본값이 사용됩니다. 스탠자는 기본ptpClockThreshold
값을 표시합니다.ptpClockThreshold
값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다.holdOverTimeout
은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가FREERUN
로 변경되기 전 시간(초)입니다.maxOffsetThreshold
및minOffsetThreshold
설정은CLOCK_REALTIME
(phc2sys
) 또는 마스터 오프셋(ptp4l
)의 값과 비교되는 나노초에 오프셋 값을 구성합니다.ptp4l
또는phc2sys
오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가FREERUN
로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가LOCKED
로 설정됩니다. - 14
프로필
을 노드에 적용하는 방법에 대한 규칙을 정의하는 하나 이상의recommend
오브젝트 배열을 지정합니다.- 15
profile
섹션에 정의된profile
오브젝트 이름을 지정합니다.- 16
0
에서99
사이의 정수 값으로priority
를 지정합니다. 숫자가 클수록 우선순위가 낮으므로 우선순위99
는 우선순위10
보다 낮습니다.match
필드에 정의된 규칙에 따라 여러 프로필과 노드를 일치시킬 수 있는 경우 우선 순위가 높은 프로필이 해당 노드에 적용됩니다.- 17
nodeLabel
또는nodeName
으로일치
규칙을 지정합니다.- 18
oc get nodes --show-labels
명령을 사용하여 노드 오브젝트에서node.Labels
의키로
nodeLabel
을 지정합니다. 예:node-role.kubernetes.io/worker
.- 19
oc get nodes
명령을 사용하여 노드 오브젝트에서node.Name
으로nodeName
을 지정합니다. 예:node-role.kubernetes.io/worker
. 예:compute-0.example.com
.
다음 명령을 실행하여 CR을 생성합니다.
$ oc create -f boundary-clock-ptp-config.yaml
검증
PtpConfig
프로필이 노드에 적용되었는지 확인합니다.다음 명령을 실행하여
openshift-ptp
네임스페이스에서 Pod 목록을 가져옵니다.$ oc get pods -n openshift-ptp -o wide
출력 예
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
프로필이 올바른지 확인합니다.
PtpConfig
프로필에 지정한 노드에 해당하는linuxptp
데몬의 로그를 검사합니다. 다음 명령을 실행합니다.$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
출력 예
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 --summary_interval -4 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
추가 리소스
- PTP 하드웨어의 FIFO 우선 순위 스케줄링에 대한 자세한 내용은 PTP 하드웨어에 대한 FIFO 우선 순위 스케줄링 구성 을 참조하십시오.
15.5.4. 듀얼 NIC 하드웨어의 경계 시계로 linuxptp 서비스 구성
경계 시계로 구성된 이중 NIC가 있는 PTP(Precision Time Protocol) 하드웨어는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
각 NIC에 대한 PtpConfig
CR(사용자 정의 리소스) 오브젝트를 생성하여 이중 NIC 하드웨어의 경계 시계로 linuxptp
서비스(ptp4l
,phc2sys
)를 구성할 수 있습니다.
듀얼 NIC 하드웨어를 사용하면 각 NIC가 다운스트림 클럭을 공급하는 별도의 ptp4l
인스턴스와 함께 각 NIC를 동일한 업스트림 리더 시계에 연결할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - PTP Operator를 설치합니다.
절차
각 NIC에 대해 하나씩 두 개의 개별
PtpConfig
CR을 생성하고 각 CR의 기반으로 "Linuxptp 서비스 구성"의 참조 CR을 사용합니다. 예를 들어 다음과 같습니다.phc2sysOpts
의 값을 지정하여boundary-clock-ptp-config-nic1.yaml
을 생성합니다.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
boundary-clock-ptp-config-nic2.yaml
을 생성하고phc2syss
필드를 완전히 제거하여 두 번째 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 ...
- 1
- 두 번째 NIC에서
ptp4l
을 경계 시계로 시작하는 데 필요한 인터페이스를 지정합니다.
참고두 번째 NIC에서
phc2sysOpts
필드를 두 번째PtpConfig
CR에서 완전히 제거하여phc2sys
서비스를 비활성화해야 합니다.
다음 명령을 실행하여 듀얼 NIC
PtpConfig
CR을 생성합니다.첫 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.
$ oc create -f boundary-clock-ptp-config-nic1.yaml
두 번째 NIC에 대해 PTP를 구성하는 CR을 생성합니다.
$ oc create -f boundary-clock-ptp-config-nic2.yaml
검증
PTP Operator가 두 NIC에
PtpConfig
CR을 적용했는지 확인합니다. 이중 NIC 하드웨어가 설치된 노드에 해당하는linuxptp
데몬의 로그를 검사합니다. 예를 들어 다음 명령을 실행합니다.$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
출력 예
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
15.5.5. Intel coumbiaville E800 시리즈 NIC as PTP 일반 클럭 참조
다음 표에서는 Intel coumbiaville E800 시리즈 NIC를 일반 시계로 사용하기 위해 참조 PTP 설정을 변경해야 하는 변경 사항을 설명합니다. 클러스터에 적용하는 PtpConfig
CR(사용자 정의 리소스)을 변경합니다.
PTP 구성 | 권장 설정 |
---|---|
|
|
|
|
|
|
phc 2sysOpts의
경우-m
은 stdout
에 메시지를 출력합니다. linuxptp-daemon
DaemonSet
은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
추가 리소스
-
PTP 빠른 이벤트가 있는 일반 시계로
linuxptp
서비스를 구성하는 전체 예제 CR은 일반 시계 로 linuxptp 서비스 구성을 참조하십시오.
15.5.6. PTP 하드웨어에 대한 VRF 우선 순위 스케줄링 구성
대기 시간이 짧은 성능을 요구하는 통신 또는 기타 배포 구성에서 PTP 데몬 스레드는 나머지 인프라 구성 요소와 함께 제한된 CPU 풋프린트에서 실행됩니다. 기본적으로 PTP 스레드는 SCHED_OTHER
정책으로 실행됩니다. 높은 로드에서 이러한 스레드는 오류가 없는 작업에 필요한 스케줄링 대기 시간을 얻지 못할 수 있습니다.
잠재적인 스케줄링 대기 시간 오류가 발생하지 않도록 PTP Operator linuxptp
서비스를 구성하여 스레드를 schedule _
VRF 정책으로 실행할 수 있습니다. ppc _
VRF가 PtpConfig
CR에 대해 설정된 경우 ptp4l
및 phc2sys
는 PtpConfig
CR의 ptpSchedulingPriority
필드에 의해 설정된 우선 순위로 chrt
의 상위 컨테이너에서 실행됩니다.
ptpSchedulingPolicy
설정은 선택 사항이며 대기 시간 오류가 발생하는 경우에만 필요합니다.
절차
PtpConfig
CR 프로필을 편집합니다.$ oc edit PtpConfig -n openshift-ptp
ptpSchedulingPolicy
및ptpSchedulingPriority
필드를 변경합니다.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
-
저장 후 종료하여
PtpConfig
CR에 변경 사항을 적용합니다.
검증
linuxptp-daemon
Pod의 이름과PtpConfig
CR이 적용된 해당 노드를 가져옵니다.$ oc get pods -n openshift-ptp -o wide
출력 예
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
업데이트된
chrt
first priority로ptp4l
프로세스가 실행 중인지 확인합니다.$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
출력 예
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
15.6. 일반적인 PTP Operator 문제 해결
다음 단계를 수행하여 PTP Operator의 일반적인 문제를 해결합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - PTP를 지원하는 호스트가 있는 베어 메탈 클러스터에 PTP Operator를 설치합니다.
절차
구성된 노드를 위해 Operator 및 Operand가 클러스터에 성공적으로 배포되었는지 확인합니다.
$ oc get pods -n openshift-ptp -o wide
출력 예
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
참고PTP 빠른 이벤트 버스가 활성화되면 준비된
linuxptp-daemon
Pod 수는3/3
가 됩니다. PTP 빠른 이벤트 버스가 활성화되지 않으면2/2
가 표시됩니다.지원되는 하드웨어가 클러스터에 있는지 확인합니다.
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
출력 예
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
노드에 사용 가능한 PTP 네트워크 인터페이스를 확인합니다.
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
다음과 같습니다.
- <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
해당 노드의
linuxptp-daemon
Pod에 액세스하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.다음 명령을 실행하여
linuxptp-daemon
Pod의 이름과 문제를 해결하려는 해당 노드를 가져옵니다.$ oc get pods -n openshift-ptp -o wide
출력 예
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
필수
linuxptp-daemon
컨테이너로의 원격 쉘:$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
다음과 같습니다.
- <linux_daemon_container>
-
진단할 컨테이너입니다 (예:
linuxptp-daemon-lmvgn
).
linuxptp-daemon
컨테이너에 대한 원격 쉘 연결에서 PTP 관리 클라이언트(pmc
) 툴을 사용하여 네트워크 인터페이스를 진단합니다. 다음pmc
명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다(예:ptp4l
).# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
노드가 기본 클록에 성공적으로 동기화되었을 때의 출력 예
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
15.7. PTP 하드웨어 빠른 이벤트 알림 프레임워크
15.7.1. PTP 및 클럭 동기화 오류 이벤트 정보
가상 RAN과 같은 클라우드 네이티브 애플리케이션에서는 전체 네트워크의 작동에 중요한 하드웨어 타이밍 이벤트에 대한 알림에 액세스해야 합니다. 빠른 이벤트 알림은 임박한 실시간 PTP(Precision Time Protocol) 클럭 동기화 이벤트에 대한 조기 경고 신호입니다. PTP 클럭 동기화 오류는 낮은 대기 시간 애플리케이션의 성능과 안정성에 부정적인 영향을 줄 수 있습니다(예: 분산 장치(DU)에서 실행되는 vRAN 애플리케이션).
PTP 동기화 손실은 RAN 네트워크에 심각한 오류입니다. 노드에서 동기화가 손실된 경우 라디오가 종료될 수 있으며 네트워크 Over the Air (OTA) 트래픽이 무선 네트워크의 다른 노드로 이동될 수 있습니다. 클러스터 노드에서 PTP 클럭 동기화 상태를 DU에서 실행 중인 vRAN 애플리케이션에 통신할 수 있도록 함으로써 이벤트 알림이 워크로드 오류와 비교하여 완화됩니다.
동일한 DU 노드에서 실행되는 RAN 애플리케이션에서 이벤트 알림을 사용할 수 있습니다. 게시/서브스크립션 REST API는 이벤트 알림을 메시징 버스에 전달합니다. 게시/서브스크립션 메시징 또는 pub/sub 메시징은 주제에 게시된 모든 메시지가 해당 주제에 대한 모든 가입자에 의해 즉시 수신되는 서비스 통신 아키텍처에 대한 비동기식 서비스입니다.
빠른 이벤트 알림은 OpenShift Container Platform의 PTP Operator에서 모든 PTP 가능 네트워크 인터페이스에 대해 생성됩니다. 이 이벤트는 AMQP(Advanced Message Queuing Protocol) 메시지 버스를 통해 cloud-event-proxy
사이드카 컨테이너를 사용하여 사용할 수 있습니다. AMQP 메시지 버스는 AMQ Interconnect Operator에서 제공합니다.
PTP 빠른 이벤트 알림은 PTP 일반 클럭 또는 PTP 경계 클럭을 사용하도록 구성된 네트워크 인터페이스에 사용할 수 있습니다.
15.7.2. PTP 빠른 이벤트 알림 프레임워크 정보
DCN(Distributed Unit) 애플리케이션을 PTP(Precision Time Protocol) 빠른 이벤트 알림을 PTP Operator 및 cloud-event-proxy
사이드카 컨테이너를 사용하여 생성한 빠른 이벤트 알림에 등록할 수 있습니다. ptpOperatorConfig
CR(사용자 정의 리소스)에서 enableEventPublisher
필드를 true
로 설정하고 AMQPP(Advanced Messageauthorization Protocol) transportHost
주소를 지정하여 cloud-event-proxy
사이드카 컨테이너를 활성화합니다. PTP 빠른 이벤트는 AMQ Interconnect Operator가 제공하는 AMQP 이벤트 알림 버스를 사용합니다. AMQ Interconnect는 AMQP 지원 엔드포인트 간에 유연한 메시지 라우팅을 제공하는 메시징 라우터인 Red Hat AMQ의 구성 요소입니다. PTP 빠른 이벤트 프레임워크의 개요는 다음과 같습니다.
그림 15.1. PTP 빠른 이벤트 개요
cloud-event-proxy
사이드카 컨테이너는 기본 애플리케이션의 리소스를 사용하지 않고 대기 시간 없이 기본 vRAN 애플리케이션과 동일한 리소스에 액세스할 수 있습니다.
빠른 이벤트 알림 프레임워크는 통신에 REST API를 사용하며 O-RAN REST API 사양을 기반으로 합니다. 프레임워크는 게시자 및 구독자 애플리케이션 간의 통신을 처리하는 게시자, 구독자 및 AMQ 메시징 버스로 구성됩니다. cloud-event-proxy
사이드카는 DU 노드의 기본 DU 애플리케이션 컨테이너에 느슨하게 연결된 Pod에서 실행되는 유틸리티 컨테이너입니다. DU 애플리케이션을 게시된 PTP 이벤트에 등록할 수 있는 이벤트 게시 프레임워크를 제공합니다.
DU 애플리케이션은 사이드카 패턴에서 cloud-event-proxy
컨테이너를 실행하여 PTP 이벤트를 구독합니다. 다음 워크플로는 DU 애플리케이션에서 PTP 빠른 이벤트를 사용하는 방법을 설명합니다.
-
DU 애플리케이션에서 서브스크립션 요청: DU는 API 요청을
cloud-event-proxy
사이드카로 전송하여 PTP 이벤트 서브스크립션을 생성합니다.cloud-event-proxy
사이드카는 서브스크립션 리소스를 생성합니다. -
cloud-event-proxy 사이드카는 서브스크립션을 생성: 이벤트 리소스는
cloud-event-proxy
사이드카에 의해 유지됩니다.cloud-event-proxy
사이드카 컨테이너는 ID 및 URL 위치가 있는 승인을 전송하여 저장된 서브스크립션 리소스에 액세스합니다. 사이드카는 서브스크립션에 지정된 리소스에 대한 AMQ 메시징 리스너 프로토콜을 생성합니다. -
DU 애플리케이션에서 PTP 이벤트 알림 수신:
cloud-event-proxy
사이드카 컨테이너가 리소스 한정자에 지정된 주소를 수신합니다. DU 이벤트 소비자는 메시지를 처리하고 서브스크립션에 지정된 반환 URL로 전달합니다. -
cloud-event-proxy 사이드카는 PTP 이벤트를 검증하고 DU 애플리케이션에 게시:
cloud-event-proxy
사이드카는 이벤트를 수신하고 클라우드 이벤트 오브젝트를 래핑하여 데이터를 검색하고 반환 URL을 가져와 이벤트를 DU 소비자 애플리케이션에 다시 게시합니다. - DU 애플리케이션은 PTP 이벤트 사용: DU 애플리케이션 이벤트 소비자가 PTP 이벤트를 수신하고 처리합니다.
15.7.3. AMQ 메시징 버스 설치
노드에서 게시자와 구독자 간에 PTP 빠른 이벤트 알림을 전달하려면 노드에서 로컬로 실행되도록 AMQ 메시징 버스를 설치하고 구성해야 합니다. 클러스터에서 사용할 AMQ Interconnect Operator를 설치하여 이 작업을 수행합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
절차
-
AMQ Interconnect Operator를 자체
amq-interconnect
네임스페이스에 설치합니다. Add the Red Hat Integration - AMQ Interconnect Operator 를 참조하십시오.
검증
AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.
$ oc get pods -n amq-interconnect
출력 예
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
필수
linuxptp-daemon
PTP 이벤트 생산자 Pod가openshift-ptp
네임스페이스에서 실행되고 있는지 확인합니다.$ oc get pods -n openshift-ptp
출력 예
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 12h linuxptp-daemon-k8n88 3/3 Running 0 12h
15.7.4. PTP 빠른 이벤트 알림 게시자 구성
클러스터에서 네트워크 인터페이스에 PTP 빠른 이벤트 알림을 사용하려면 PTP Operator PtpOperatorConfig
CR(사용자 정의 리소스)에서 빠른 이벤트 게시자를 활성화하고 생성한 PtpConfig
CR에서 ptpClockThreshold
값을 구성해야 합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - PTP Operator 및 AMQ Interconnect Operator를 설치합니다.
절차
PTP 빠른 이벤트를 활성화하도록 기본 PTP Operator 구성을 수정합니다.
다음 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 transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local 2
PtpOperatorConfig
CR을 업데이트합니다.$ oc apply -f ptp-operatorconfig.yaml
PTP 지원 인터페이스에 대한
PtpConfig
CR(사용자 정의 리소스)을 생성하고ptpClockThreshold
및ptp4lOpts
에 필요한 값을 설정합니다. 다음 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
- 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
로 변경되기 전 시간(초)입니다.maxOffsetThreshold
및minOffsetThreshold
설정은CLOCK_REALTIME
(phc2sys
) 또는 마스터 오프셋(ptp4l
)의 값과 비교되는 나노초에 오프셋 값을 구성합니다.ptp4l
또는phc2sys
오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가FREERUN
로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가LOCKED
로 설정됩니다.
추가 리소스
-
PTP 빠른 이벤트가 있는 일반 시계로
linuxptp
서비스를 구성하는 전체 예제 CR은 일반 시계 로 linuxptp 서비스 구성을 참조하십시오.
15.7.5. DU 애플리케이션을 PTP 이벤트 REST API 참조에 구독
PTP 이벤트 알림을 REST API를 사용하여 DU(Distributed Unit) 애플리케이션을 상위 노드에 생성된 PTP 이벤트에 서브스크립션합니다.
리소스 주소 /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/
에서
DU 애플리케이션을 게시한 PTP 이벤트에 등록합니다.
cloud-event-
consumer
/api/ocloudNotifications/v1/subscriptions
-
POST
: 새 서브스크립션을 생성합니다. -
GET
: 서브스크립션 목록 검색합니다.
-
/api/ocloudNotifications/v1/subscriptions/<subscription_id>
-
GET
: 지정된 서브스크립션 ID에 대한 세부 정보를 반환합니다.
-
api/ocloudNotifications/v1/subscriptions/status/<subscription_id>
-
PUT
: 지정된 서브스크립션 ID에 대한 새 상태 ping 요청 생성
-
/api/ocloudNotifications/v1/health
-
GET
:ocloudNotifications
API의 상태를 반환합니다.
-
api/ocloudNotifications/v1/publishers
-
GET
: 클러스터 노드에 대한os-clock-sync-state
,ptp-clock-class-change
,lock-state
메시지 배열을 반환합니다.
-
/api/ocloudnotifications/v1/<resource_address>/CurrentState
-
GET
:os-clock-sync-state
,ptp-clock-class-change
,lock-state
이벤트 등 하나의 현재 상태를 반환합니다.
-
9089
는 애플리케이션 Pod에 배포된 cloud-event-consumer
컨테이너의 기본 포트입니다. 필요에 따라 DU 애플리케이션에 대해 다른 포트를 구성할 수 있습니다.
15.7.5.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" } ]
HTTP 방법
POST api/ocloudNotifications/v1/subscriptions
설명
새 서브스크립션을 생성합니다. 서브스크립션이 성공적으로 생성되었거나 이미 존재하는 경우 201 Created
상태 코드가 반환됩니다.
매개변수 | 유형 |
---|---|
subscription | data |
페이로드 예
{ "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions", "resource": "/cluster/node/compute-1.example.com/ptp" }
15.7.5.2. api/ocloudNotifications/v1/subscriptions/<subscription_id>
HTTP 방법
GET api/ocloudNotifications/v1/subscriptions/<subscription_id>
설명
ID <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" }
15.7.5.3. api/ocloudNotifications/v1/subscriptions/status/<subscription_id>
HTTP 방법
PUT api/ocloudNotifications/v1/subscriptions/status/<subscription_id>
설명
ID <subscription _id>를 사용하여 서브스크립션에 대한 새 상태 ping 요청을 생성합니다
. 서브스크립션이 있는 경우 상태 요청이 성공하고 202 Accepted
상태 코드가 반환됩니다.
매개변수 | 유형 |
---|---|
| string |
API 응답 예
{"status":"ping sent"}
15.7.5.4. api/ocloudNotifications/v1/health/
HTTP 방법
GET api/ocloudNotifications/v1/health/
설명
ocloudNotifications
REST API의 상태를 반환합니다.
API 응답 예
OK
15.7.5.5. api/ocloudNotifications/v1/publishers
HTTP 방법
GET api/ocloudNotifications/v1/publishers
설명
클러스터 노드의 os-clock-sync-state
,ptp-clock-class-change
및 lock-state
세부 정보를 반환합니다. 시스템은 관련 장비 상태 변경이 있을 때 알림을 생성합니다.
-
OS-clock-sync-state
알림은 호스트 운영 체제 클럭 동기화 상태