2장. 시스템 및 환경 요구 사항
2.1. 시스템 요구 사항
OpenShift Container Platform 환경의 호스트는 다음 하드웨어 사양 및 시스템 수준 요구 사항을 충족해야 합니다.
2.1.1. Red Hat 서브스크립션
Red Hat 계정에 유효한 OpenShift Container Platform 서브스크립션이 있어야합니다. 서브스크립션이 없는 경우 영업 담당자에게 자세한 내용을 문의하십시오.
2.1.2. 최소 하드웨어 요구 사항
시스템 요구 사항은 호스트 유형에 따라 다릅니다.
| |
| |
| 외부 etcd 노드 |
|
| Ansible 컨트롤러 | Ansible 플레이북을 실행하는 호스트에는 인벤토리의 호스트당 최소 75MiB의 여유 메모리가 있어야 합니다. |
RHEL Atomic Host에서 /var/ 파일 시스템 크기 요구 사항을 충족하려면 기본 구성을 변경해야 합니다. 설치 중 또는 설치 후 이를 구성하는 방법은 Docker 형식의 컨테이너를 사용하여 스토리지 관리를 참조하십시오.
시스템의 임시 디렉토리는 Python의 표준 라이브러리의 tempfile 모듈에 정의된 규칙에 따라 결정됩니다.
컨테이너 데몬을 실행하는 각 시스템에 대한 스토리지를 구성해야 합니다. 컨테이너화된 설치의 경우 마스터에 스토리지가 필요합니다. 또한 기본적으로 웹 콘솔은 마스터의 컨테이너에서 실행되며 마스터는 웹 콘솔을 실행하기 위해 스토리지가 필요합니다. 컨테이너는 노드에서 실행되므로 노드에 항상 스토리지가 필요합니다. 스토리지 크기는 워크로드, 컨테이너 수, 실행 중인 컨테이너의 크기, 컨테이너 스토리지 요구 사항에 따라 달라집니다. 컨테이너화된 etcd를 실행하도록 스토리지를 구성해야 합니다.
NVMe 또는 SSD와 같이 직렬 쓰기(fsync)를 빠르게 처리하는 스토리지와 함께 etcd를 사용하는 것이 좋습니다. Ceph, NFS 및 회전 디스크는 권장되지 않습니다.
2.1.3. 프로덕션 수준 하드웨어 요구 사항
최소 요구사항이 있는 테스트 또는 샘플 환경이 작동합니다. 프로덕션 환경의 경우 다음 권장 사항이 적용됩니다.
- 마스터 호스트
- 외부 etcd가 있는 고가용성 OpenShift Container Platform 클러스터에서 마스터 호스트는 최소 요구사항을 충족해야 하며 1000개의 Pod마다 하나의 CPU 코어 및 1.5GB의 메모리가 있어야 합니다. 따라서 2000개의 포드의 OpenShift Container Platform 클러스터에 있는 마스터 호스트의 권장 크기는 CPU 코어 2개와 16GB의 RAM과 2개의 CPU 코어 및 3GB RAM, 총 4개의 CPU 코어 및 19GB RAM의 최소 요구 사항입니다.
성능 지침은 Recommended Practices for OpenShift Container Platform Master Hosts 에서 참조하십시오.
- 노드 호스트
- 노드 호스트의 크기는 예상되는 워크로드 크기에 따라 다릅니다. OpenShift Container Platform 클러스터 관리자는 예상 워크로드를 계산하고 오버 헤드에 약 10 %를 추가해야 합니다. 프로덕션 환경의 경우 노드 호스트 장애가 최대 용량에 영향을 미치지 않도록 충분한 리소스를 할당해야 합니다.
자세한 내용은 고려 사항 및 클러스터 제한 크기 조정을 참조하십시오.
노드에서 물리적 리소스에 대한 서브스크립션을 초과하면 Pod를 배치하는 동안 Kubernetes 스케줄러가 보장하는 리소스에 영향을 미칩니다. 메모리 교체를 방지하기 위해 수행할 수 있는 조치를 알아보십시오.
2.1.4. 스토리지 관리
| 디렉터리 | 참고 | 크기 조정 | 예상 성장 |
|---|---|---|---|
| /var/lib/openshift | etcd 스토리지에 단일 마스터 모드 및 etcd가 atomic-openshift-master 프로세스에 포함된 경우에만 사용됩니다. | 10GB 미만입니다. | 환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다. |
| /var/lib/etcd | 멀티 마스터 모드에서 또는 etcd를 관리자가 독립형으로 만들 때 etcd 스토리지에 사용됩니다. | 20GB 미만입니다. | 환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다. |
| /var/lib/docker | 실행 시간이 docker이면 마운트 지점입니다. 활성 컨테이너 런타임(포드 포함) 및 로컬 이미지의 스토리지( 레지스트리 스토리지에 사용되지 않음)에 사용되는 스토리지입니다. 마운트 지점은 수동 대신 docker-storage에서 관리해야 합니다. | 16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. | 컨테이너 실행 용량에 따라 증가가 제한됩니다. |
| /var/lib/containers | 런타임이 CRI-O이면 마운트 지점입니다. 활성 컨테이너 런타임(포드 포함) 및 로컬 이미지의 스토리지( 레지스트리 스토리지에 사용되지 않음)에 사용되는 스토리지입니다. | 16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. | 실행 중인 컨테이너의 용량으로 제한됨 |
| /var/lib/origin/openshift.local.volumes | Pod용 임시 볼륨 스토리지입니다. 런타임 시 컨테이너로 마운트된 외부 요소가 모두 포함됩니다. 영구 스토리지 PV에서 지원하지 않는 환경 변수, kube 시크릿 및 데이터 볼륨이 포함됩니다. | 변동 가능 | 스토리지가 필요한 Pod가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다. |
| /var/log | 모든 구성 요소의 로그 파일입니다. | 10~30GB입니다. | 로그 파일이 빠르게 증가할 수 있습니다. 크기는 디스크를 늘리거나 로그 회전을 사용하여 관리할 수 있습니다. |
2.1.5. Red Hat Gluster Storage 하드웨어 요구 사항
통합 모드 또는 독립 모드 클러스터에서 사용되는 모든 노드는 스토리지 노드로 간주됩니다. 스토리지 노드는 별도의 클러스터 그룹으로 그룹화할 수 있지만 단일 노드는 여러 그룹에 있을 수 없습니다. 각 스토리지 노드 그룹에 대해 다음을 수행합니다.
- 스토리지 gluster volumetype 옵션을 기반으로 그룹당 하나 이상의 스토리지 노드가 필요합니다.
각 스토리지 노드에는 최소 8GB의 RAM이 있어야 합니다. 이는 Red Hat Gluster Storage 포드 및 기타 애플리케이션 및 기본 운영 체제를 실행할 수 있도록 하는 것입니다.
- 각 GlusterFS 볼륨은 스토리지 클러스터의 모든 스토리지 노드에서 메모리를 소비하며, 이는 약 30MB입니다. 총 RAM 수는 예상하거나 예상한 동시 볼륨의 수에 따라 결정되어야 합니다.
각 스토리지 노드에는 현재 데이터 또는 메타데이터가 없는 원시 블록 장치가 하나 이상 있어야 합니다. 이러한 블록 장치는 GlusterFS 스토리지에 전체적으로 사용됩니다. 다음이 없는지 확인합니다.
- 파티션 테이블 (GPT 또는 MSDOS)
- 파일 시스템 또는 보조 파일 시스템 서명
- 이전 볼륨 그룹 및 논리 볼륨의 LVM2 서명
- LVM2 물리 볼륨의 메타데이터
의심의 여지가 있는 경우,
dispfs -a <device>는 위의 중 하나를 지워야 합니다.
인프라 애플리케이션 전용 스토리지(예: OpenShift Container Registry) 전용 클러스터와 일반 애플리케이션을 위한 스토리지 전용 두 개의 클러스터를 계획하는 것이 좋습니다. 여기에는 총 6개의 스토리지 노드가 필요합니다. 이 권장 사항은 I/O 및 볼륨 생성의 성능에 잠재적으로 영향을 미치지 않도록 합니다.
2.1.6. 하드웨어 요구 사항 모니터링
모니터링 스택은 추가 시스템 리소스 요구 사항을 적용하고 기본적으로 설치됩니다. 컴퓨팅 리소스 권장 사항 및 클러스터 모니터링 설명서 를 참조하십시오.
2.1.7. SELinux 요구 사항
OpenShift Container Platform을 설치하거나 설치 프로그램이 실패하기 전에 모든 서버에서 SELinux를 사용하도록 설정해야 합니다. 또한 /etc/selinux/config 파일에 SELINUX=enforcing 및 SELINUXTYPE=targeted 를 구성합니다.
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
2.1.8. 선택 사항: 코어 사용량 구성
기본적으로 OpenShift Container Platform 마스터 및 노드는 실행 중인 시스템에서 사용 가능한 모든 코어를 사용합니다. GOMAXPROCS 환경 변수를 설정하여 OpenShift Container Platform에서 사용할 코어 수를 선택할 수 있습니다. GOMAXPROCS 환경 변수가 작동하는 방식을 포함하여 자세한 내용은 Go Language 설명서 를 참조하십시오.
예를 들어 서버를 시작하기 전에 다음을 실행하여 OpenShift Container Platform이 하나의 코어에서만 실행되도록 합니다.
# export GOMAXPROCS=1
2.1.9. 선택 사항: OverlayFS 사용
OverlayFS는 다른 파일 시스템을 오버레이할 수 있는 통합 파일 시스템입니다.
Red Hat Enterprise Linux 7.4부터 OverlayFS를 사용하도록 OpenShift Container Platform 환경을 구성할 수 있는 옵션이 있습니다. overlay2 그래프 드라이버는 이전 오버레이 드라이버 외에 완전히 지원됩니다. 그러나 Red Hat은 속도와 간단한 구현 때문에 오버레이 대신 overlay2 를 사용하는 것이 좋습니다.
Overlay Versus Overlay2 Graph 드라이버를 비교하면 overlay 및 overlay 2 드라이버에 대한 자세한 내용이 있습니다.
Docker 서비스의 overlay2 그래프 드라이버를 활성화하는 방법에 대한 지침은 Atomic Host 문서의 Overlay Graph Driver 섹션을 참조하십시오.
2.1.10. 보안 경고
OpenShift Container Platform은 클러스터의 호스트에서 컨테이너를 실행하며, 빌드 작업 및 레지스트리 서비스와 같은 경우에 따라 권한이 있는 컨테이너를 사용합니다. 또한 이러한 컨테이너는 호스트의 Docker 데몬에 액세스하고 Docker 빌드 및 Docker 내보내기 작업을 수행합니다. 따라서 클러스터 관리자는 효과적으로 root 액세스 권한이 있으므로 임의의 이미지에서 docker 실행 작업을 수행할 수 있는 보안 위험을 알고 있어야 합니다. 이는 특히 Docker 빌드 작업과 관련이 있습니다.
유해한 컨테이너에 대한 노출은 모든 노출이 해당 노드에 제한되도록 특정 빌드를 노드에 할당하여 제한할 수 있습니다. 이렇게 하려면 개발자 가이드의 특정 노드에 빌드 할당 섹션을 참조하십시오. 클러스터 관리자는 글로벌 빌드 기본값 구성 및 덮어쓰기 항목을 참조하십시오.
보안 컨텍스트 제약 조건을 사용하여 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 작업을 제어할 수도 있습니다. Dockerfile에서 USER 로 이미지를 실행하도록 활성화하는 방법에 대한 자세한 내용은 Managing Security Context Constraints ( cluster-admin 권한이 있는 사용자 필요)을 참조하십시오.
자세한 내용은 다음 문서를 참조하십시오.
