노드 호스트는 네트워크에 액세스하여 atomic-openshift-*, iptables, CRI-O 또는 Docker 와 같은 RPMs 종속성을 설치합니다. 이러한 종속성을 미리 설치하여 설치하는 동안 호스트당 여러 번이 아니라 필요할 때만 RPM에 액세스하므로 보다 효율적인 설치를 생성합니다.

이는 보안상의 이유로 레지스트리에 액세스할 수 없는 머신에도 유용합니다.

OpenShift Container Platform 설치 방법에서는 Ansible을 사용합니다. Ansible은 병렬 작업을 실행하는 데 유용하며, 이는 빠르고 효율적인 설치를 의미합니다. 그러나 추가 튜닝 옵션을 사용하여 이러한 기능을 개선할 수 있습니다. 사용 가능한 Ansible 구성 옵션 목록은 Ansible 구성 구성 섹션을 참조하십시오.

가장 낮은 대기 시간 제어 노드(LAN 속도)에서 설치 프로그램을 실행합니다. 광범위한 영역 네트워크(octets)를 통해 실행하는 것은 권장되지 않으며, 손실된 네트워크 연결을 통해 설치를 실행하지도 않습니다.

Ansible은 OpenSSH 버전이 ControlPersist 를 지원하는지 확인하는 데 RHEL 6.6 이상을 사용하고 클러스터와 동일한 LAN에서 설치 프로그램을 실행하지만 클러스터의 시스템에서 실행하는 등 성능 및 스케일링에 대한 자체 지침을 제공합니다.

다음은 Ansible에서 설명하는 권장 사항을 통합하는 대규모 클러스터 설치 및 관리에 대한 Ansible 구성의 예입니다.

# cat /etc/ansible/ansible.cfg

# config file for ansible -- http://ansible.com/
# ==============================================
[defaults]
forks = 20 1
host_key_checking = False
remote_user = root
roles_path = roles/
gathering = smart
fact_caching = jsonfile
fact_caching_connection = $HOME/ansible/facts
fact_caching_timeout = 600
log_path = $HOME/ansible.log
nocows = 1
callback_whitelist = profile_tasks

[privilege_escalation]
become = False

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=600s -o ServerAliveInterval=60
control_path = %(directory)s/%%h-%%r
pipelining = True 2
timeout = 10

네트워크 서브넷은 설치 후 변경할 수 있지만 어려움이 있습니다. 크기를 낮추면 클러스터 확장에 문제가 발생할 수 있으므로 설치하기 전에 네트워크 서브넷 크기를 고려하는 것이 훨씬 쉬워집니다.

권장 네트워크 서브넷 지정 방법은 네트워크 최적화 주제를 참조하십시오.

Pod 트래픽 외에도 OpenShift Container Platform 인프라에서 가장 많이 사용되는 데이터 경로도 OpenShift Container Platform 마스터 호스트와 etcd 사이입니다. OpenShift Container Platform API 서버(마스터 바이너리의 일부)는 etcd에서 노드 상태, 네트워크 구성, 시크릿 등을 참조합니다.

다음을 통해 이 트래픽 경로를 최적화합니다.

OpenShift Container Platform 마스터는 CPU 로드를 쉽게하기 위해 적극적으로 리소스의 역직렬화 버전을 캐시합니다. 그러나 Pod가 1,000개 미만인 소규모 클러스터에서 이 캐시는 상당한 CPU 부하 감소를 위해 많은 메모리를 낭비할 수 있습니다. 기본 캐시 크기는 50,000개 항목이며, 리소스 크기에 따라 1~2GB의 메모리를 차지하도록 증가할 수 있습니다. 이 캐시 크기는 /etc/origin/master/master-config.yaml 에서 다음 설정을 사용하여 줄일 수 있습니다.

kubernetesMasterConfig:
  apiServerArguments:
    deserialization-cache-size:
    - "1000"

API 서버로 전송되는 클라이언트 요청 또는 API 호출 수는 QPS(Queries per second) 값에 따라 결정되며 API 서버에서 처리할 수 있는 동시 요청 수는 maxRequestsInFlight 설정에 따라 결정됩니다. 클라이언트가 QPS 수치를 초과할 수 있는 요청 수는 버스트 값에 따라 달라지며, 이는 자연에서 버스트(bursty)되는 애플리케이션에 도움이 되며, 이는 불규칙한 요청 수를 생성할 수 있습니다. 요청에 대한 응답 시간은 특히 대규모 및/또는 밀도가 높은 클러스터의 경우 API 서버에서 많은 동시 요청을 처리하는 경우 대기 시간이 높을 수 있습니다. Prometheus에서 apiserver_request_count 속도 메트릭을 모니터링하고 maxRequestsInFlight 및 QPS 를 적절하게 조정하는 것이 좋습니다.

API 서버의 CPU 및 메모리 사용량을 변경할 때 기본값을 변경할 때는 더 많은 요청을 동시에 처리할 때 etcd IOPS가 증가합니다. 또한 고정 60초 제한 시간이 지나면 API 서버가 취소되고 클라이언트가 재시도를 시작할 때 API 서버에 과부하가 발생할 수도 있습니다.

API 서버 시스템에서 충분한 CPU 및 메모리 리소스를 사용할 수 있는 경우 위에서 언급한 요인을 고려하여 API 서버 요청 과부하 문제를 안전하게 완화할 수 있으며 *_/etc/origin/master/master-config.yaml의 maxRequestsInFlight, API qps 및 burst 값을 사용하여 문제를 해결할 수 있습니다.

masterClients:
  openshiftLoopbackClientConnectionOverrides:
    burst: 600
    qps: 300
servingInfo:
  maxRequestsInFlight: 500

OpenShift Container Platform 노드 구성 파일에는 iptables 동기화 기간, SDN 네트워크의 최대 전송 단위(MTU) 및 프록시 모드와 같은 중요한 옵션이 포함되어 있습니다. 노드를 구성하려면 적절한 노드 구성 맵 을 수정합니다.

노드 구성 파일을 사용하면 kubelet(노드) 프로세스에 인수를 전달할 수 있습니다. kubelet --help 를 실행하여 가능한 옵션 목록을 볼 수 있습니다.

/etc/origin/node/node-config.yaml 파일에서 두 개의 매개변수는 pod- per-core 및 max-pods 에 예약할 수 있는 최대 Pod 수를 제어합니다. 두 옵션이 모두 사용 중인 경우 두 옵션 중 가장 낮은 값이 노드의 Pod 수를 제한합니다. 이 값을 초과하면 다음과 같은 결과가 발생할 수 있습니다.

pods-per-core 는 노드의 프로세서 코어 수에 따라 노드에서 실행할 수 있는 Pod 수를 설정합니다. 예를 들어 프로세서 코어가 4개인 노드에서 pods-per-core 가 10 으로 설정된 경우 노드에 허용되는 최대 Pod 수는 40입니다.

kubeletArguments:
  pods-per-core:
    - "10"

Max-pods 는 노드의 속성에 관계없이 노드가 실행할 수 있는 Pod 수를 고정된 값으로 설정합니다. 클러스터 제한 문서 max-pods 에 대해 지원되는 최대 값.

kubeletArguments:
  max-pods:
    - "250"

위의 예제를 사용하면 pods-per-core 의 기본값은 10 이고 max-pods 의 기본값은 250 입니다. 즉, 노드에 25개 이상의 코어가 없으면 기본적으로 pods-per-core 가 제한 요인이 됩니다.

OpenShift Container Platform 클러스터에 권장되는 제한 사항은 설치 문서의 고려 사항 지정 섹션을 참조하십시오. 컨테이너 상태 업데이트를 위해 OpenShift Container Platform 및 컨테이너 엔진 조정에 권장되는 크기 조정 계정입니다. 이러한 조정은 마스터 및 컨테이너 엔진 프로세스에 CPU 부담을 줄여 많은 로그 데이터 쓰기를 포함할 수 있습니다.

kubelet이 API 서버와 통신하는 속도는 qps 및 버스트 값에 따라 다릅니다. 각 노드에서 실행 중인 Pod가 제한된 경우 기본값은 충분합니다. 노드에 충분한 CPU 및 메모리 리소스가 있으면 /etc/origin/node/node-config.yaml 파일에서 qps 및 버스트 값을 조정할 수 있습니다.

kubeletArguments:
  kube-api-qps:
  - "20"
  kube-api-burst:
  - "40"

etcd는 OpenShift Container Platform에서 구성에 사용하는 분산 키-값 저장소입니다.

etcd 3.x는 모든 크기의 클러스터에 대한 CPU, 메모리, 네트워크 및 디스크 요구 사항을 줄이는 중요한 확장성과 성능 향상을 제공합니다. etcd 3.x는 디스크상의 etcd 데이터베이스의 2단계 마이그레이션을 용이하게 하는 이전 버전과 호환되는 스토리지 API도 구현합니다. 마이그레이션을 위해 OpenShift Container Platform 3.5에서 etcd 3.x에서 사용하는 스토리지 모드는 v2 모드로 유지됩니다. OpenShift Container Platform 3.6부터 새로운 설치는 스토리지 모드 v3를 사용합니다. 이전 버전의 OpenShift Container Platform에서 업그레이드해도 v2에서 v3로 데이터가 자동으로 마이그레이션 되지 않습니다. 제공된 플레이북을 사용하고 문서화된 프로세스에 따라 데이터를 마이그레이션해야 합니다.

etcd 버전 3은 디스크의 etcd 데이터베이스를 2단계로 마이그레이션할 수 있도록 이전 버전과 호환되는 스토리지 API를 구현합니다. 마이그레이션을 위해 OpenShift Container Platform 3.5에서 etcd 3.x에서 사용하는 스토리지 모드는 v2 모드로 유지됩니다. OpenShift Container Platform 3.6부터 새로운 설치는 스토리지 모드 v3를 사용합니다. OpenShift Container Platform 3.7로 업그레이드하는 프로세스의 일부로 etcd 스토리지 API를 필요한 경우 v3로 업그레이드합니다. 버전 3.7 이상에서는 v3 API를 사용해야 합니다.

새 설치의 스토리지 모드를 v3으로 변경하는 것 외에도 OpenShift Container Platform 3.6은 모든 OpenShift Container Platform 유형에 대해 쿼럼 읽기 를 적용하기 시작합니다. 이는 etcd에 대한 쿼리가 오래된 데이터를 반환하지 않도록하기 위해 수행됩니다. 단일 노드 etcd 클러스터에서 오래된 데이터는 중요하지 않습니다. 일반적으로 프로덕션 클러스터에 있는 고가용성 etcd 배포에서 쿼럼은 유효한 쿼리 결과를 확인합니다. 쿼럼 읽기는 데이터베이스 용어에 선형 화됩니다. 모든 클라이언트는 클러스터의 최신 업데이트된 상태를 확인하고 모든 클라이언트는 동일한 읽기 및 쓰기 순서를 확인합니다. 성능 향상에 대한 자세한 내용은 etcd 3.1 공지 를 참조하십시오.

OpenShift Container Platform은 etcd를 사용하여 Kubernetes 자체보다 추가 정보를 저장하는 데 필요합니다. 예를 들어 OpenShift Container Platform은 OpenShift Container Platform이 Kubernetes 위에 추가하는 기능에 필요하므로 etcd의 이미지, 빌드 및 기타 구성 요소에 대한 정보를 저장합니다. 궁극적으로 etcd 호스트의 성능 및 크기 조정에 대한 지침은 적절한 방식으로 Kubernetes 및 기타 권장 사항과 다릅니다. Red Hat은 가장 정확한 권장 사항을 생성하기 위해 OpenShift Container Platform 사용 사례 및 매개변수를 사용하여 etcd 확장성과 성능을 테스트합니다.

cluster-loader 유틸리티를 사용하여 300-노드 OpenShift Container Platform 3.6 클러스터를 사용하여 성능이 저하되었습니다. etcd 3.x (storage mode v2)와 etcd 3.x (storage 모드 v3) 비교하면 아래 차트에서 명확한 개선 사항이 확인됩니다.

로드 중인 스토리지 IOPS가 크게 줄어듭니다.

스토리지 IOPS가 정상적인 상태에서도 크게 줄어듭니다.

동일한 I/O 데이터를 보고 두 모드에서 평균 IOPS를 플롯합니다.

API 서버(마스터) 및 etcd 프로세스의 CPU 사용량이 감소합니다.

API 서버(마스터)와 etcd 프로세스 둘 다의 메모리 사용률도 감소합니다.

etcd 3.1의 3-노드 클러스터에서 수행한 크기 I/O 작업을 확인(스토리지 v3 모드 사용 및 쿼럼 읽기 사용), 읽기 크기는 다음과 같습니다.

및 쓰기:

tuned 는 RHEL(Red Hat Enterprise Linux) 및 기타 Red Hat 제품에서 기본적으로 활성화된 튜닝 프로파일 전달 메커니즘입니다. tuned 는 다양한 워크로드 성능 및 확장성 요구 사항에 맞게 운영 체제를 최적화하도록 sysctl, 전원 관리 및 커널 명령줄 옵션과 같은 Linux 설정을 사용자 지정합니다.

OpenShift Container Platform은 tuned 데몬을 활용하고 openshift,openshift-node 및 openshift-control-plane 라는 Tuned 프로필을 포함합니다. 이러한 프로필은 커널에 일반적으로 발생하는 수직 확장 제한 중 일부를 안전하게 늘리며 설치 중에 시스템에 자동으로 적용됩니다.

Tuned 프로필은 프로필 간의 상속을 지원합니다. 또한 가상 환경에서 프로필이 사용되는지 여부에 따라 상위 프로필을 선택하는 자동적인 기능을 지원합니다. openshift 프로필은 이러한 기능을 모두 사용하며 openshift-node 및 openshift-control-plane 프로필의 상위 버전입니다. OpenShift Container Platform 애플리케이션 노드와 컨트롤 플레인 노드 둘 다와 관련된 튜닝이 포함되어 있습니다. openshift-node 및 openshift-control-plane 프로필은 각각 애플리케이션 및 컨트롤 플레인 노드에 설정됩니다.

openshift 프로필이 있는 프로필 계층 구조를 상위로 사용하면 OpenShift Container Platform 시스템에 전달되는 튜닝이 베어 메탈 호스트 및 RHEL Atomic Host 노드의 경우 virtual-guest 의 throughput-performance (기본값)인 통합입니다.

시스템에서 Tuned 프로필이 활성화되어 있는지 확인하려면 다음을 실행합니다.

# tuned-adm active

Current active profile: openshift-node

Tuned 에 대한 자세한 내용은 Red Hat Enterprise Linux 성능 튜닝 가이드를 참조하십시오.

CPU 및 메모리와 같은 리소스에 필요한 클러스터의 일부에서 더 쉽게 액세스할 수 있도록 오버 커밋 절차를 사용할 수 있습니다.

오버 커밋할 때 다른 애플리케이션이 필요할 때 필요한 리소스에 액세스할 수 없는 위험이 있으므로 성능이 저하됩니다. 그러나, 이는 밀도 증가 및 비용 절감을 위해 허용되는 절충일 수 있습니다. 예를 들어 개발, 품질 보장(QA) 또는 테스트 환경은 오버 커밋될 수 있는 반면, 프로덕션은 그렇지 않을 수 있습니다.

OpenShift Container Platform은 컴퓨팅 리소스 모델 및 할당량 시스템을 통해 리소스 관리를 구현합니다. OpenShift 리소스 모델에 대한 자세한 내용은 설명서를 참조하십시오.

오버 커밋에 대한 자세한 내용과 전략은 클러스터 관리 가이드의 Overcommiting 설명서를 참조하십시오.

Red Hat은 확장 또는 성능 문제를 디버깅하는 데 도움이 되는 rhel-tools 컨테이너 이미지 패키징 툴을 배포합니다. 이 컨테이너 이미지:

다음과 같이 rhel-tools 컨테이너를 사용합니다.

# atomic run rhel7/rhel-tools

자세한 내용은 RHEL Tools 컨테이너 설명서 를 참조하십시오.

OpenShift Container Platform 클러스터를 설치하고 관리하는 데 사용되는 Ansible 기반 툴링 을 통해 추가 진단 상태 점검을 사용할 수 있습니다. 현재 OpenShift Container Platform 설치에 대한 일반적인 배포 문제를 보고할 수 있습니다.

이러한 검사는 ansible-playbook 명령( 클러스터 설치중에 사용되는 것과 동일한 방법)을 사용하거나 컨테이너화된 openshift-ansible 버전으로 실행할 수 있습니다. ansible-playbook 방법의 경우 openshift-ansible RPM 패키지에서 검사를 제공합니다. 컨테이너화된 방법의 경우 openshift3/ose-ansible 컨테이너 이미지는 Red Hat Container Registry 를 통해 배포됩니다.

사용 가능한 상태 점검 및 사용 예시에 대한 정보는 클러스터 관리 가이드의 Ansible 기반 상태 점검을 참조하십시오.

스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.

다음 표에는 OpenShift Container Platform에서 사용 가능한 영구 스토리지 기술이 나열되어 있습니다.

OpenShift Container Platform 레지스트리, 로깅 및 모니터링을 위해 블록, 파일 및 개체 스토리지에 대해 통합 모드 GlusterFS(동일한 호스팅 스토리지 솔루션) 또는 독립 모드 GlusterFS(외부 호스팅 스토리지 솔루션)를 사용할 수 있습니다.

다음 표에는 지정된 OpenShift Container Platform 클러스터 애플리케이션에 권장되는 구성 가능한 스토리지 기술이 요약되어 있습니다.

컨테이너 런타임은 이미지와 컨테이너를 그래프 드라이버(예: DeviceMapper 및 OverlayFS)에 저장합니다. 각각에는 장단점이 있습니다.

지원 가능성 및 사용 경고 등 OverlayFS에 대한 자세한 내용은 해당 버전의 Red Hat Enterprise Linux (RHEL) 7 릴리스 노트 를 참조하십시오.

성능 향상을 위해 Red Hat은 장치 매퍼를 통해 overlayFS 스토리지 드라이버를 사용하는 것이 좋습니다. 그러나 프로덕션 환경에서 이미 Device Mapper를 사용하는 경우 컨테이너 이미지 및 컨테이너 루트 파일 시스템에 씬 프로비저닝을 사용하는 것이 좋습니다. 그러지 않으면 항상 CRI-O에 Docker 엔진 또는 overlayFS에 overlayfs2를 사용합니다.

루프 장치를 사용하면 성능에 영향을 줄 수 있습니다. 계속 사용할 수 있지만 다음 경고 메시지가 기록됩니다.

devmapper: Usage of loopback devices is strongly discouraged for production use.
Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to
dm.thinpooldev section.

간편한 스토리지 설정을 위해 docker-storage-setup 유틸리티를 사용하면 많은 설정 세부 정보를 자동화할 수 있습니다.

Overlay의 경우

Thinpool의 경우

기본적으로 씬 풀은 기본 블록 장치의 40%를 사용하도록 구성됩니다. 스토리지를 사용하면 LVM에서 씬 풀을 100%까지 자동으로 확장합니다. 따라서 Data Space Total 값이 기본 LVM 장치의 전체 크기와 일치하지 않습니다.

개발 시 Red Hat 배포판의 docker는 기본적으로 루프백이 마운트된 스파스 파일로 설정됩니다. 시스템이 루프백 모드를 사용하고 있는지 확인하려면 다음을 수행합니다.

# docker info|grep loop0

 Data file: /dev/loop0

Pod는 임시 파일 저장과 같은 내부 작업에 임시 스토리지를 사용합니다. 이러한 임시 스토리지의 수명은 개별 Pod의 수명 이상으로 연장되지 않으며 이 임시 스토리지는 여러 Pod 사이에서 공유할 수 없습니다.

OpenShift Container Platform 3.10 이전에는 임시 로컬 스토리지가 컨테이너의 쓰기 가능한 계층, 로그 디렉터리, EmptyDir 볼륨을 통해 Pod에 노출되었습니다. 로컬 스토리지 회계 및 격리 부족과 관련한 문제는 다음과 같습니다.

임시 스토리지는 여전히 동일한 방식으로 Pod에 노출되지만 Pod의 임시 스토리지 사용에 대한 요청 및 제한을 구현하는 새로운 방법이 있습니다.

임시 스토리지는 시스템의 모든 Pod에서 공유되며 OpenShift Container Platform은 관리자 및 사용자가 설정한 요청 및 제한 이외의 모든 수준의 서비스를 보장하는 메커니즘을 제공하지 않습니다. 예를 들어, 임시 스토리지는 초당 I/O 작업 또는 스토리지 성능의 기타 측정에 대한 처리량, I/O 작업 보장을 보장하지 않습니다.

노드의 로컬 스토리지는 기본 및 보조 파티션으로 나눌 수 있습니다. 기본 파티션은 임시 로컬 스토리지에 사용할 수 있는 유일한 파티션입니다. 지원되는 두 개의 기본 파티션인 root 및 runtime이 있습니다.

OpenShift SDN 은 OpenvSwitch, VXLAN(가상 확장 가능 LAN) 터널, OpenFlow 규칙 및 iptables를 사용합니다. 이 네트워크는 점보 프레임, NIC(네트워크 인터페이스 카드) 오프로드, 멀티 큐, ethtool 설정을 사용하여 조정할 수 있습니다.

VXLAN은 VLAN에 비해 네트워크 수가 4096개에서 1600만 개 이상으로 증가하고 물리적 네트워크 전반에 걸쳐 계층 2 연결과 같은 이점을 제공합니다. 이를 통해 서비스 뒤에 있는 모든 Pod가 서로 다른 시스템에서 실행되는 경우에도 서로 통신할 수 있습니다.

VXLAN은 사용자 데이터그램 프로토콜(UDP) 패킷의 터널링된 모든 트래픽을 캡슐화합니다. 그러나 이로 인해 CPU 사용량이 증가합니다. 이러한 외부 및 내부 패킷은 전송 중에 데이터가 손상되지 않았음을 보장하기 위해 일반적인 체크섬 규칙을 따릅니다. CPU 성능에 따라 이러한 추가 처리 오버헤드는 처리량이 감소하고 기존 비 오버레이 네트워크에 비해 대기 시간이 증가할 수 있습니다.

클라우드, 가상 머신, 베어 메탈 CPU 성능은 많은 Gbps의 네트워크 처리량을 처리할 수 있습니다. 10 또는 40Gbps와 같은 높은 대역폭 링크를 사용하는 경우 성능이 저하될 수 있습니다. 이 문제는 VXLAN 기반 환경에서 알려진 문제이며 컨테이너 또는 OpenShift Container Platform에만 국한되지 않습니다. VXLAN 터널에 의존하는 네트워크는 VXLAN 구현으로 인해 비슷한 작업을 수행할 수 있습니다.

Gbps을 초과하여 푸시하려는 경우 다음을 수행할 수 있습니다.

VXLAN 오프로드는 대기 시간을 단축시키지 않습니다. 그러나 대기 시간 테스트에서도 CPU 사용량이 감소합니다.

networkConfig:
  mtu: 1450 1
  networkPluginName: "redhat/openshift-ovs-subnet" 2

OpenShift Container Platform은 Pod 및 서비스 모두에 IP 주소 관리를 제공합니다. 기본값을 사용하면 다음을 수행할 수 있습니다.

대부분의 경우 배포 후에는 이러한 네트워크를 변경할 수 없습니다. 따라서 성장을 위해 미리 계획하는 것이 중요합니다.

네트워크 크기 조정에 대한 제한은 SDN 설명서의 문서에 설명되어 있습니다.

더 큰 환경을 계획하려면 Ansible 인벤토리 파일의 [OSE3:vars] 섹션에 추가하는 것이 좋습니다.

[OSE3:vars]
osm_cluster_network_cidr=10.128.0.0/10

이렇게 하면 각각 510개의 사용 가능한 IP 주소가 있는 8192 개의 노드가 허용됩니다.

설치 중인 소프트웨어 버전에 대한 노드/포드 제한에 대한 OpenShift Container Platform 설명서의 지원 가능성을 참조하십시오.

노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.

IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec가 활성화되면 일부 NIC 가속 기능을 사용할 수 없으며 처리량이 감소하고 CPU 사용량이 증가합니다.

OpenShift Container Platform은 EgressIP .com이 수집하여 백엔드에 저장할 수 있는 지표를 노출합니다. https://github.com/kubernetes/heapster OpenShift Container Platform 관리자는 하나의 사용자 인터페이스에서 컨테이너 및 구성 요소 지표를 볼 수 있습니다. 이러한 지표는 스케일링 시기와 방법을 결정하기 위해 수평 Pod 자동 스케일러 에서도 사용됩니다.

이 주제에서는 지표 구성 요소를 확장하는 방법에 대한 정보를 제공합니다.

210 및 990 OpenShift Container Platform 노드에서 수행되는 테스트에서 10500개의 포드와 11000개의 포드가 각각 모니터링되면 아래 표에 표시된 속도가 가장 빠르게 증가했습니다.

위의 계산에서 스토리지 요구 사항이 계산된 값을 초과하지 않도록 예상 크기의 약 20%가 오버헤드로 추가되었습니다.

METRICS_DURATION 및 METRICS_RESOLUTION 값이 기본값인7 일과 15 초 동안 유지되는 경우 위의 값과 같이 주당 FeatureGate 스토리지 크기 요구 사항을 계획하는 것이 안전합니다.

지표 Pod 세트(Cassandra/Hawkular/Heapster)는 최소 25,000개의 Pod를 모니터링할 수 있습니다.

# oc scale -n openshift-infra --replicas=2 rc hawkular-metrics

OpenShift Container Platform에서는 cluster-monitoring-operator 에서 백엔드에 수집하고 저장할 수 있는 지표를 노출합니다. OpenShift Container Platform 관리자는 하나의 대시보드 인터페이스인 Grafana에서 시스템 리소스, 컨테이너 및 구성 요소 지표를 볼 수 있습니다.

이 주제에서는 클러스터 모니터링 Operator 확장에 대한 정보를 제공합니다.

영구 스토리지와 함께 Prometheus를 사용하려면 Ansible 인벤토리 파일의 openshift_cluster_monitoring_operator_prometheus_storage_enabled 변수를 true 로 설정해야 합니다.

다양한 스케일링 크기에 대해 다양한 테스트가 수행되었습니다. 아래 표에 반영된 Prometheus 데이터베이스 증가.

위의 계산에서 스토리지 요구 사항이 계산된 값을 초과하지 않도록 예상 크기의 약 20%가 오버헤드로 추가되었습니다.

위의 계산은 기본 OpenShift Container Platform cluster-monitoring-operator 를 위해 개발되었습니다. 더 높은 규모의 경우 Ansible 인벤토리 파일에서 openshift_cluster_monitoring_operator_prometheus_storage_capacity 변수를 편집합니다. 기본값은 50Gi 입니다.

195 GB (space per 15 days ) * 2 (pods) = 390 GB free

Infrastructure as a Service Provider: OpenStack

환경을 계획하는 동안 노드당 적합한 Pod 수를 결정합니다.

Maximum Pods per Cluster / Expected Pods per Node = Total Number of Nodes

노드에 적합한 Pod 수는 애플리케이션 자체에 따라 다릅니다. 애플리케이션의 메모리, CPU 및 스토리지 요구 사항을 고려하십시오.

2200 / 250 = 8.8

노드 수를 20으로 늘리면 Pod 배포는 노드당 110개 Pod로 변경됩니다.

2200 / 20 = 110

예에 나온 애플리케이션 환경을 고려해 보십시오.

예상 요구사항은 CPU 코어 550개, RAM 450GB 및 스토리지 1.4TB입니다.

노드의 인스턴스 크기는 기본 설정에 따라 높게 또는 낮게 조정될 수 있습니다. 노드에서는 리소스 초과 커밋이 발생하는 경우가 많습니다. 이 배포 시나리오에서는 동일한 양의 리소스를 제공하는 데 더 작은 노드를 추가로 실행하도록 선택할 수도 있고 더 적은 수의 더 큰 노드를 실행하도록 선택할 수도 있습니다. 운영 민첩성 및 인스턴스당 비용과 같은 요인을 고려해야 합니다.

일부 애플리케이션은 초과 커밋된 환경에 적합하지만 일부 애플리케이션은 그렇지 않습니다. 대부분의 Java 애플리케이션과 대규모 페이지를 사용하는 애플리케이션은 초과 커밋에 적합하지 않은 애플리케이션의 예입니다. 해당 메모리는 다른 애플리케이션에 사용할 수 없습니다. 위의 예에 나온 환경에서는 초과 커밋이 약 30%이며, 이는 일반적으로 나타나는 비율입니다.

Cluster Loader는 많은 수의 다양한 오브젝트를 클러스터에 배포하여 사용자 정의 클러스터 오브젝트를 생성하는 툴입니다. Cluster Loader를 빌드하고, 구성하고, 실행하여 다양한 클러스터 상태에서 OpenShift Container Platform 배포의 성능 지표를 측정하십시오.

Cluster Loader는 atomic-openshift-tests 패키지에 포함되어 있습니다. 설치하려면 다음을 실행합니다.

$ yum install atomic-openshift-tests

설치 후 테스트 실행 파일 extended.test 는 /usr/libexec/atomic-openshift/extended.test 에 있습니다.

여러 템플릿 또는 Pod가 포함된 여러 네임스페이스(프로젝트)를 생성합니다.

config/ 하위 디렉터리에서 Cluster Loader의 구성 파일을 찾습니다. 이러한 구성 예제에서 참조하는 포드 파일 및 템플릿 파일은 content/ 하위 디렉터리에 있습니다.

provider: local 1
ClusterLoader:
  cleanup: true
  projects:
    - num: 1
      basename: clusterloader-cakephp-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/cakephp-mysql.json

    - num: 1
      basename: clusterloader-dancer-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/dancer-mysql.json

    - num: 1
      basename: clusterloader-django-postgresql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/django-postgresql.json

    - num: 1
      basename: clusterloader-nodejs-mongodb
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/nodejs-mongodb.json

    - num: 1
      basename: clusterloader-rails-postgresql
      tuning: default
      templates:
        - num: 1
          file: ./examples/quickstarts/rails-postgresql.json

  tuningsets: 2
    - name: default
      pods:
        stepping: 3
          stepsize: 5
          pause: 0 s
        rate_limit: 4
          delay: 0 ms

IDENTIFIER 매개변수가 사용자 템플릿에 정의되어 있지 않으면 템플릿 생성에 실패하고 error: unknown parameter name "IDENTIFIER"가 표시됩니다. 템플릿을 배포하는 경우 다음과 같이 이 매개변수를 템플릿에 추가하여 오류를 방지하십시오.

{
  "name": "IDENTIFIER",
  "description": "Number to append to the name of resources",
  "value": "1"
}

Pod를 배포하는 경우 매개변수를 추가할 필요가 없습니다.

CPU 관리자는 CPU 그룹을 관리하고 워크로드를 특정 CPU로 제한합니다.

CPU 관리자는 다음과 같은 속성 중 일부가 포함된 워크로드에 유용합니다.

CPU 관리자를 설정하려면 다음을 수행합니다.

메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같습니다. 1Gi 메모리는 262,144 페이지 등입니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.

대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처에서 일반적인 대규모 페이지 크기는 2Mi와 1Gi입니다. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.

OpenShift Container Platform에서는 Pod의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다. 이 주제에서는 방법을 설명합니다.

대규모 페이지는 hugepages-<size > 리소스 이름을 사용하여 컨테이너 수준 리소스 요구 사항을 통해 사용할 수 있습니다. 여기서 크기는 특정 노드에서 지원되는 정수 값을 사용하여 가장 컴팩트한 바이너리 표기법입니다. 예를 들어 노드가 2048KiB 페이지 크기를 지원하는 경우 예약 가능한 리소스 hugepages-2Mi 를 노출합니다. CPU 또는 메모리와 달리 대규모 페이지는 과다 할당을 지원하지 않습니다.

kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

일부 플랫폼에서는 여러 대규모 페이지 크기를 지원합니다. 특정 크기의 대규모 페이지를 할당하려면 대규모 페이지 부팅 명령 매개변수 앞에 대규모 페이지 크기 선택 매개변수 hugepagesz=<size>를 지정합니다. <size> 값은 바이트 단위로 지정해야 하며 스케일링 접미사 [kKmMgG]를 선택적으로 사용할 수 있습니다. 기본 대규모 페이지 크기는 default_hugepagesz=<size> 부팅 매개변수로 정의할 수 있습니다. 자세한 내용은 Transparent Huge Pages 구성을 참조하십시오.

대규모 페이지 요청은 제한과 같아야 합니다. 제한은 지정되었으나 요청은 지정되지 않은 경우 제한이 기본값입니다.

대규모 페이지는 Pod 범위에서 격리됩니다. 컨테이너 격리는 향후 반복에서 계획됩니다.

대규모 페이지에서 지원하는 EmptyDir 볼륨은 Pod 요청보다 더 많은 대규모 페이지 메모리를 사용하면 안 됩니다.

SHM_HUGETLB로 shmget()를 통해 대규모 페이지를 사용하는 애플리케이션은 proc/sys/vm/hugetlb_shm_group과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.

애플리케이션에 통합 모드를 사용하는 경우 워크로드 유형에 따라 gluster-block과 GlusterFS 모드 간 정보에 입각하여 이 주제에서 제공되는 지침 및 모범 사례를 따르십시오.

OpenShift Container Platform 3.10에서는 다음 (no)SQL 데이터베이스에서 광범위한 테스트를 수행했습니다.

이러한 데이터베이스의 스토리지는 통합 모드 스토리지 클러스터에서 시작되었습니다.

Postgresql SQL 벤치마킹 pgbench 은 데이터베이스 벤치마킹에 사용되었습니다. MongoDB noSQL 벤치마킹 YCSB Yahoo의 경우 Cloud Serving Benchmark 는 벤치마킹 및 workloada,workloadb,workloadf 를 테스트했습니다.

위에서 언급한 GlusterFS의 성능 번역기는 이미 최신 통합 모드 이미지와 함께 제공되는 데이터베이스 프로필의 일부입니다.

Postgresql SQL 데이터베이스의 경우 GlusterFS 및 gluster-block은 거의 동일한 성능 결과를 보여주었습니다. MongoDB noSQL 데이터베이스의 경우 gluster-block이 더 잘 수행됩니다. 따라서 MongoDB noSQL 데이터베이스에 gluster-block 기반 스토리지를 사용하십시오.