검색

클러스터 설치

download PDF
OpenShift Container Platform 3.11

OpenShift Container Platform 3.11 설치 클러스터

초록

이 가이드를 사용하여 OpenShift Container Platform 3.11 클러스터 설치

1장. 설치 계획

일련의 Ansible 플레이북을 실행하여 OpenShift Container Platform을 설치합니다. 클러스터를 설치할 준비가 되면 환경 및 OpenShift Container Platform 클러스터 구성을 나타내는 인벤토리 파일을 생성합니다. Ansible에 대해 잘 알고 있으면 이 프로세스를 더 쉽게 수행할 수 있지만 필수는 아닙니다.

Ansible 및 해당 기본 사용에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다.

1.1. 초기 계획

프로덕션 OpenShift Container Platform 클러스터를 설치하기 전에 다음 질문에 대한 응답이 필요합니다.

  • 온프레미스 서버에서 IBM POWER 또는 x86_64 프로세서를 사용하고 있습니까? 두 유형의 프로세서를 사용하는 서버에 OpenShift Container Platform을 설치할 수 있습니다. POWER 서버를 사용하는 경우 IBM POWER에 설치 제한 및 고려 사항을 검토하십시오.
  • 클러스터에 필요한 Pod 수 Sizing Considerations 섹션에서는 노드 및 Pod에 대한 제한을 제공하므로 환경 규모를 계산할 수 있습니다.
  • 클러스터에 필요한 호스트 수 환경 시나리오 섹션에서는 단일 마스터 및 여러 마스터 구성의 여러 예를 제공합니다.
  • 고가용성 클러스터가 필요하십니까? 고가용성 구성에서는 내결함성을 향상시킵니다. 이 경우 여러 마스터에서 네이티브 HA 예제를 사용하여 환경을 설정할 수 있습니다.
  • 클러스터 모니터링이 필요한 경우 모니터링 스택에는 추가 시스템 리소스가 필요합니다. 모니터링 스택은 기본적으로 설치되어 있습니다. 자세한 내용은 클러스터 모니터링 설명서 를 참조하십시오.
  • RHEL(Red Hat Enterprise Linux) 또는 RHEL Atomic Host를 클러스터 노드의 운영 체제로 사용하시겠습니까? RHEL에 OpenShift Container Platform을 설치하는 경우 RPM 기반 설치를 사용합니다. RHEL Atomic Host에서는 시스템 컨테이너를 사용합니다. 두 설치 유형 모두 작동하는 OpenShift Container Platform 환경을 제공합니다.
  • 인증에 사용할 ID 공급자는 무엇입니까? 지원되는 ID 공급자를 이미 사용하는 경우 설치 중에 해당 ID 공급자를 사용하도록 OpenShift Container Platform을 구성합니다.
  • 다른 기술과 통합할 때 내 설치가 지원됩니까? 테스트된 통합 목록은 OpenShift Container Platform 테스트된 통합을 참조하십시오.

1.1.1. IBM POWER에 설치에 대한 제한 사항 및 고려 사항

버전 3.10.45로 IBM POWER 서버에 OpenShift Container Platform을 설치할 수 있습니다.

  • 클러스터는 Power 노드 및 마스터만 사용해야 합니다. 이미지에 태그가 지정된 방식으로 OpenShift Container Platform은 x86 이미지와 Power 이미지를 구분할 수 없습니다.
  • 이미지 스트림 및 템플릿은 업그레이드 시 기본적으로 설치되거나 업데이트되지 않습니다. 이미지 스트림을 수동으로 설치하고 업데이트할 수 있습니다.
  • 온프레미스 Power 서버에만 설치할 수 있습니다. 클라우드 공급자의 노드에 OpenShift Container Platform을 설치할 수 없습니다.
  • 모든 스토리지 공급자가 지원되는 것은 아닙니다. 다음 스토리지 공급자만 사용할 수 있습니다.

1.2. 크기 조정 고려 사항

OpenShift Container Platform 클러스터에 필요한 노드 및 Pod 수를 결정합니다. 클러스터 확장성은 클러스터 환경의 Pod 수와 관련이 있습니다. 이 숫자는 설정의 다른 숫자에 영향을 미칩니다. OpenShift Container Platform의 오브젝트의 최신 제한 사항은 클러스터 제한을 참조하십시오.

1.3. 환경 시나리오

이러한 환경 시나리오를 사용하여 크기 조정 요구에 따라 OpenShift Container Platform 클러스터를 계획할 수 있습니다.

참고

설치 후 단일 마스터 클러스터에서 여러 마스터로 이동하는 것은 지원되지 않습니다.

모든 환경에서 etcd 호스트가 마스터 호스트와 함께 배치되면 etcd는 호스트에서 정적 포드로 실행됩니다. etcd 호스트가 마스터 호스트와 함께 배치되지 않은 경우 독립형 프로세스로 etcd를 실행합니다.

참고

RHEL Atomic Host를 사용하는 경우 마스터 호스트에서만 etcd를 구성할 수 있습니다.

1.3.1. 하나의 시스템에서 단일 마스터 및 노드

개발 환경의 단일 시스템에 OpenShift Container Platform을 설치할 수 있습니다. 올인원 환경을 프로덕션 환경으로 사용할 수 없습니다.

1.3.2. 단일 마스터 및 여러 노드

다음 표에서는 단일 마스터 (동일한 호스트에 etcd를 설치한 경우)의 예제 환경과 두 개의 노드를 설명합니다.

호스트 이름설치할 인프라 구성 요소

master.example.com

master, etcd 및 노드

node1.example.com

노드

node2.example.com

1.3.3. 네이티브 HA를 사용하는 여러 마스터

다음은 기본 HA 방법을 사용하는 마스터 세 개, HAProxy 로드 밸런서 1개 및 기본 HA 방법을 사용하는 두 개의 노드에 대한 환경 예제를 설명합니다. etcd는 마스터 노드에서 정적 포드로 실행됩니다.

중요

고가용성 및 내결함성 환경을 보유하려면 라우터 및 마스터 노드를 로드 밸런싱해야 합니다. Red Hat은 프로덕션 환경에 엔터프라이즈급 외부 로드 밸런서를 사용하는 것이 좋습니다. 이 로드 밸런싱은 마스터 및 노드에 적용되며 OpenShift Container Platform 라우터를 실행하는 호스트입니다. 로드가 IP 주소에 분산되는 TCP(Transmission Control Protocol) 계층 4 로드 밸런싱이 권장됩니다. 프로덕션 사용 사례에는 권장되지 않는 참조 설계의 경우 External Load Balancer Integrations with OpenShift Enterprise 3 를 참조하십시오.

호스트 이름설치할 인프라 구성 요소

master1.example.com

마스터(기본 HA를 사용한 클러스터) 및 노드 및 클러스터형 etcd

master2.example.com

master3.example.com

lb.example.com

API 마스터 끝점을 로드 밸런싱하는 HAProxy

node1.example.com

노드

node2.example.com

1.3.4. 외부 클러스터 etcd와 함께 네이티브 HA를 사용하는 여러 마스터

다음은 3개의 마스터 환경, HAProxy 로드 밸런서 1개, 외부 클러스터형 etcd 호스트 세 개 및 기본 HA 방법을 사용하는 두 개의 노드에 대한 예제 환경을 설명합니다.

호스트 이름설치할 인프라 구성 요소

master1.example.com

마스터(기본 HA를 사용한 클러스터) 및 노드

master2.example.com

master3.example.com

lb.example.com

API 마스터 끝점을 로드 밸런싱하는 HAProxy

etcd1.example.com

클러스터형 etcd

etcd2.example.com

etcd3.example.com

node1.example.com

노드

node2.example.com

1.3.5. 독립 실행형 레지스트리

OpenShift Container Platform의 통합 레지스트리를 사용하여 독립형 레지스트리 역할을 하도록 OpenShift Container Platform을 설치할 수도 있습니다. 이 시나리오에 대한 자세한 내용은 독립 실행형 레지스트리 설치를 참조하십시오.

1.4. 지원되는 운영 체제의 설치 유형

OpenShift Container Platform 3.10부터 RHEL을 호스트의 기본 OS로 사용하는 경우 RPM 방법을 사용하여 해당 호스트에 OpenShift Container Platform 구성 요소를 설치합니다. RHEL Atomic Host를 사용하는 경우 해당 호스트에서 시스템 컨테이너 방법이 사용됩니다. 두 설치 유형 모두 클러스터에 동일한 기능을 제공하지만 사용하는 운영 체제는 서비스 및 호스트 업데이트를 관리하는 방법이 결정됩니다.

참고

OpenShift Container Platform 3.10부터 포함된 설치 방법은 Red Hat Enterprise Linux 시스템에서 더 이상 지원되지 않습니다.

RPM 설치는 패키지 관리를 통해 모든 서비스를 설치하고, 시스템 컨테이너 설치 시 시스템 컨테이너 이미지를 사용하여 서비스를 설치하고 개별 컨테이너에서 별도의 서비스를 실행하도록 서비스를 구성합니다.

RHEL에서 RPM을 사용하는 경우 모든 서비스가 외부 소스에서 패키지 관리를 통해 설치 및 업데이트됩니다. 이러한 패키지는 동일한 사용자 공간에 있는 호스트의 기존 구성을 수정합니다. RHEL Atomic Host에 시스템 컨테이너를 설치하면 OpenShift Container Platform의 각 구성 요소가 실행할 호스트의 커널을 사용하는 자체 지원 패키지에 컨테이너로 제공됩니다. 업데이트된 최신 컨테이너는 호스트의 기존 컨테이너를 대체합니다.

다음 표와 섹션은 설치 유형 간의 차이점에 대해 간략하게 설명합니다.

표 1.1. 설치 유형 간 차이점
 Red Hat Enterprise LinuxRHEL Atomic Host

설치 유형

RPM 기반

시스템 컨테이너

Mechanism

yum을 사용하는 RPM 패키지

docker를 사용하는 시스템 컨테이너 이미지

서비스 관리

systemd

Dockersystemd 단위

1.4.1. 시스템 컨테이너에 필요한 이미지

시스템 컨테이너 설치 유형은 다음 이미지를 사용합니다.

  • openshift3/ose-node

기본적으로 위의 이미지는 모두 registry.redhat.io 의 Red Hat Registry에서 가져옵니다.

설치 중에 개인 레지스트리를 사용하여 이미지를 가져와야 하는 경우 레지스트리 정보를 미리 지정할 수 있습니다. 필요에 따라 인벤토리 파일에서 다음 Ansible 변수를 설정합니다.

oreg_url='<registry_hostname>/openshift3/ose-${component}:${version}'
openshift_docker_insecure_registries=<registry_hostname>
openshift_docker_blocked_registries=<registry_hostname>
참고

openshift_docker_insecure_registries 변수를 호스트의 IP 주소로 설정할 수도 있습니다. 0.0.0.0/0은 유효한 설정이 아닙니다.

기본 구성 요소는 oreg_url 값에서 이미지 접두사 및 버전을 상속합니다.

추가, 비보안 및 차단된 컨테이너 레지스트리의 구성은 필요한 이미지를 가져오기 전에 설치 프로세스 시작 시 이러한 설정을 적용하도록 합니다.

1.4.2. systemd 서비스 이름

설치 프로세스는 일반 systemctl 명령을 사용하여 서비스를 시작, 중지 및 폴링하는 데 사용할 수 있는 관련 systemd 장치를 생성합니다. 시스템 컨테이너 설치의 경우 이러한 장치 이름은 RPM 설치의 이름과 일치합니다.

1.4.3. 파일 경로 위치

모든 OpenShift Container Platform 구성 파일은 RPM 기반 설치와 함께 컨테이너화된 설치 중에 동일한 위치에 배치되며 os-tree 업그레이드 후에도 유지됩니다.

그러나 기본 이미지 스트림 및 템플릿 파일은 RHEL Atomic Host에서 읽기 전용이므로 표준 /usr/share/openshift/examples/ 이 아닌 Atomic Host 설치의 경우 /etc/origin/examples/ 에 설치됩니다.

1.4.4. 스토리지 요구사항

RHEL Atomic Host 설치에는 일반적으로 매우 작은 루트 파일 시스템이 있습니다. 그러나 etcd, 마스터 및 노드 컨테이너는 /var/lib/ 디렉터리에 데이터를 유지합니다. OpenShift Container Platform을 설치하기 전에 루트 파일 시스템에 충분한 공간이 있는지 확인합니다. 자세한 내용은 시스템 요구 사항 섹션을 참조하십시오.

2장. 시스템 및 환경 요구 사항

2.1. 시스템 요구 사항

OpenShift Container Platform 환경의 호스트는 다음 하드웨어 사양 및 시스템 수준 요구 사항을 충족해야 합니다.

2.1.1. Red Hat 서브스크립션

Red Hat 계정에 유효한 OpenShift Container Platform 서브스크립션이 있어야합니다. 서브스크립션이 없는 경우 영업 담당자에게 자세한 내용을 문의하십시오.

2.1.2. 최소 하드웨어 요구 사항

시스템 요구 사항은 호스트 유형에 따라 다릅니다.

마스터

  • 물리적 또는 가상 시스템 또는 퍼블릭 또는 프라이빗 IaaS에서 실행되는 인스턴스.
  • 기본 OS: RHEL (Red Hat Enterprise Linux) 7.5 이상 설치 옵션 및 Extras 채널의 최신 패키지 또는 RHEL Atomic Host 7.4.5 이상.

    • IBM POWER9: "최신" 설치 옵션 및 Extras 채널의 최신 패키지가 있는 RHEL-ALT 7.5.
    • IBM POWER8: "최신" 설치 옵션을 사용하는 RHEL 7.5 및 Extras 채널의 최신 패키지. RHEL을 사용하는 경우 다음과 같은 최소 커널 버전을 사용해야 합니다.
    • RHEL 7.5: 3.10.0-862.31.1
    • RHEL 7.6: 3.10.0-957.27.2
    • RHEL 7.7: 3.10.0-1062
  • 최소 4 vCPU (추가 권장)
  • 최소 16GB RAM(특히 etcd가 마스터에 공동 배치된 경우 메모리가 강력히 권장됩니다).
  • /var/ 를 포함하는 파일 시스템의 최소 40GB의 하드 디스크 공간 redcircle 1
  • /usr/local/bin/ 을 포함하는 파일 시스템의 최소 1GB의 하드 디스크 공간
  • 시스템의 임시 디렉토리를 포함하는 파일 시스템의 최소 1GB의 하드 디스크 공간 redcircle 2
  • 공동 배치된 etcd를 사용하는 마스터에는 최소 4개의 코어가 필요합니다. 2 코어 시스템은 작동하지 않습니다.

노드

  • 물리적 또는 가상 시스템 또는 퍼블릭 또는 프라이빗 IaaS에서 실행되는 인스턴스.
  • 기본 OS: RHEL 7.5 이상, "최소" 설치 옵션 또는 RHEL Atomic Host 7.4.5 이상.

    • IBM POWER9: "최신" 설치 옵션 및 Extras 채널의 최신 패키지가 있는 RHEL-ALT 7.5.
    • IBM POWER8: "최신" 설치 옵션을 사용하는 RHEL 7.5 및 Extras 채널의 최신 패키지. RHEL을 사용하는 경우 다음과 같은 최소 커널 버전을 사용해야 합니다.
    • RHEL 7.5: 3.10.0-862.31.1
    • RHEL 7.6: 3.10.0-957.27.2
    • RHEL 7.7: 3.10.0-1062
  • NetworkManager 1.0 이상
  • vCPU 1개
  • 최소 8GB RAM
  • /var/ 를 포함하는 파일 시스템의 최소 15GB의 하드 디스크 공간 redcircle 1
  • /usr/local/bin/ 을 포함하는 파일 시스템의 최소 1GB의 하드 디스크 공간
  • 시스템의 임시 디렉토리를 포함하는 파일 시스템의 최소 1GB의 하드 디스크 공간 redcircle 2
  • Docker의 스토리지 백엔드에 대해 컨테이너를 실행하는 시스템당 15GB의 할당되지 않은 공간 최소 15GB의 추가 공간은 Docker 스토리지 구성을 참조하십시오. 노드에서 실행되는 컨테이너의 크기 및 수에 따라 추가 공간이 필요할 수 있습니다.

외부 etcd 노드

Ansible 컨트롤러

Ansible 플레이북을 실행하는 호스트에는 인벤토리의 호스트당 최소 75MiB의 여유 메모리가 있어야 합니다.

redcircle 1 RHEL Atomic Host에서 /var/ 파일 시스템 크기 요구 사항을 충족하려면 기본 구성을 변경해야 합니다. 설치 중 또는 설치 후 이를 구성하는 방법은 Docker 형식의 컨테이너를 사용하여 스토리지 관리를 참조하십시오.

redcircle 2 시스템의 임시 디렉토리는 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. 스토리지 관리

표 2.1. OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리
디렉터리참고크기 조정예상 성장

/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=enforcingSELINUXTYPE=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 권한이 있는 사용자 필요)을 참조하십시오.

자세한 내용은 다음 문서를 참조하십시오.

2.2. 환경 요구 사항

다음 섹션에서는 OpenShift Container Platform 구성이 포함된 환경의 요구 사항을 정의합니다. 여기에는 Git 리포지토리 액세스, 스토리지 및 클라우드 인프라 공급자와 같은 외부 서비스에 대한 네트워킹 고려 사항 및 액세스가 포함됩니다.

2.2.1. DNS 요구 사항

OpenShift Container Platform에는 환경에 완전히 작동하는 DNS 서버가 필요합니다. 이는 DNS 소프트웨어를 실행하는 별도의 호스트이며 플랫폼에서 실행되는 호스트 및 컨테이너에 이름 확인을 제공할 수 있습니다.

중요

각 호스트의 /etc/hosts 파일에 항목을 추가하는 것만으로는 충분하지 않습니다. 이 파일은 플랫폼에서 실행 중인 컨테이너에 복사되지 않습니다.

OpenShift Container Platform의 주요 구성 요소는 컨테이너 내부에서 실행되며 이름 확인을 위해 다음 프로세스를 사용합니다.

  1. 기본적으로 컨테이너는 호스트에서 DNS 구성 파일(/etc/resolv.conf)을 수신합니다.
  2. 그러면 OpenShift Container Platform에서 Pod의 첫 번째 이름 서버를 노드의 IP 주소로 설정합니다.

OpenShift Container Platform 3.2부터 dnsmasq 는 모든 마스터 및 노드에 자동으로 구성됩니다. Pod는 노드를 DNS로 사용하고 노드는 요청을 전달합니다. 기본적으로 dnsmasq 는 포트 53에서 수신 대기하도록 노드에 구성되므로 노드는 다른 유형의 DNS 애플리케이션을 실행할 수 없습니다.

참고

NetworkManagerdnsmasq 를 DNS IP 주소로 채우려면 시스템에서 자동으로 네트워크에 연결할 수 있도록 감지 및 구성을 제공하는 프로그램이 필요합니다.

NM_CONTROLLED 는 기본적으로 yes 로 설정됩니다. NM_CONTROLLEDno 로 설정된 경우 NetworkManager 디스패치 스크립트에서 관련 origin-upstream-dns.conf dnsmasq 파일을 생성하지 않으며 dnsmasq를 수동으로 구성해야 합니다.

마찬가지로, PEERDNS 매개변수가 네트워크 스크립트에서 no 로 설정된 경우(예: /etc/sysconfig/network-scripts/ifcfg-em1 )는 생성되지 않으며 Ansible 설치가 실패합니다. PEERDNS 설정이 yes 로 설정되어 있는지 확인합니다.

다음은 DNS 레코드의 예입니다.

master1    A   10.64.33.100
master2    A   10.64.33.103
node1      A   10.64.33.101
node2      A   10.64.33.102

DNS 환경이 제대로 작동하지 않는 경우 다음과 같이 오류가 발생할 수 있습니다.

  • 참조 Ansible 기반 스크립트를 통한 제품 설치
  • 인프라 컨테이너(registry, 라우터) 배포
  • IP 주소를 통해 액세스할 수 없으므로 OpenShift Container Platform 웹 콘솔에 대한 액세스 권한
2.2.1.1. DNS를 사용하도록 호스트 구성

해당 환경의 각 호스트가 DNS 서버의 호스트 이름을 확인하도록 구성되어 있는지 확인합니다. 호스트의 DNS 확인 구성은 DHCP가 활성화되어 있는지 여부에 따라 다릅니다. DHCP가 있는 경우:

  • 비활성화한 다음 네트워크 인터페이스를 정적으로 구성하고 NetworkManager에 DNS 이름 서버를 추가합니다.
  • 그런 다음 NetworkManager 디스패치 스크립트는 DHCP 구성에 따라 DNS를 자동으로 구성합니다.

DNS 서버에서 호스트를 확인할 수 있는지 확인하려면 다음을 수행하십시오.

  1. /etc/resolv.conf 의 내용을 확인합니다.

    $ cat /etc/resolv.conf
    # Generated by NetworkManager
    search example.com
    nameserver 10.64.33.1
    # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh

    이 예에서 10.64.33.1은 DNS 서버의 주소입니다.

  2. /etc/resolv.conf 에 나열된 DNS 서버가 OpenShift Container Platform 환경에 있는 모든 마스터 및 노드의 IP 주소로 호스트 이름을 확인할 수 있는지 테스트합니다.

    $ dig <node_hostname> @<IP_address> +short

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

    $ dig master.example.com @10.64.33.1 +short
    10.64.33.100
    $ dig node1.example.com @10.64.33.1 +short
    10.64.33.101
2.2.1.2. DNS 와일드 카드 구성

선택적으로 라우터를 사용하도록 와일드카드를 구성하여 새 경로를 추가할 때 DNS 구성을 업데이트할 필요가 없습니다. 라우터에 와일드카드를 구성하는 경우 Ansible 인벤토리 파일을 구성할 때 openshift_master_default_subdomain 매개변수를 이 값으로 설정합니다.

DNS 영역의 와일드카드는 궁극적으로 OpenShift Container Platform 라우터 의 IP 주소로 확인되어야 합니다.

예를 들어 TTL(Time-to-live) 값이 낮은 cloudapps 에 와일드카드 DNS 항목을 만들고 라우터가 배포될 호스트의 공용 IP 주소를 가리킵니다.

*.cloudapps.example.com. 300 IN  A 192.168.133.2
주의

각 노드 호스트의 /etc/resolv.conf 파일에서 와일드카드 항목이 있는 DNS 서버가 네임서버로 나열되지 않거나 와일드카드 도메인이 검색 목록에 나열되어 있지 않은지 확인합니다. 그렇지 않으면 OpenShift Container Platform에서 관리하는 컨테이너가 호스트 이름을 올바르게 확인하지 못할 수 있습니다.

2.2.1.3. 노드 호스트 이름 구성

클라우드 공급자와 통합되지 않은 클러스터를 설정하면 노드의 호스트 이름을 올바르게 설정해야 합니다. 각 노드의 호스트 이름을 확인할 수 있어야 하며 각 노드는 서로 연결할 수 있어야 합니다.

노드가 다른 노드에 도달할 수 있는지 확인하려면 다음을 수행합니다.

  1. 한 노드에서 호스트 이름을 가져옵니다.

    $ hostname
    
    master-1.example.com
  2. 동일한 노드에서 호스트의 정규화된 도메인 이름을 가져옵니다.

    $ hostname -f
    
    master-1.example.com
  3. 다른 노드에서 첫 번째 노드에 연결할 수 있는지 확인합니다.

    $ ping master-1.example.com -c 1
    
    PING master-1.example.com (172.16.122.9) 56(84) bytes of data.
    64 bytes from master-1.example.com (172.16.122.9): icmp_seq=1 ttl=64 time=0.319 ms
    
    --- master-1.example.com ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.319/0.319/0.319/0.000 ms

2.2.2. 네트워크 액세스 요구 사항

공유 네트워크는 마스터 호스트와 노드 호스트 사이에 있어야 합니다. 표준 클러스터 설치 프로세스를 사용하여 고가용성에 대해 여러 마스터를 구성하려면 설치 프로세스 중에 VIP( 가상 IP)로 구성할 IP 도 선택해야 합니다. 선택하는 IP는 모든 노드 간에 라우팅할 수 있어야 하며, FQDN을 사용하여 구성하는 경우 모든 노드에서 확인해야 합니다.

2.2.2.1. NetworkManager

NetworkManagerdnsmasq 를 DNS IP 주소로 채우려면 시스템에서 자동으로 네트워크에 연결할 수 있도록 감지 및 구성을 제공하는 프로그램이 필요합니다.

NM_CONTROLLED 는 기본적으로 yes 로 설정됩니다. NM_CONTROLLEDno 로 설정된 경우 NetworkManager 디스패치 스크립트에서 관련 origin-upstream-dns.conf dnsmasq 파일을 생성하지 않으며 dnsmasq를 수동으로 구성해야 합니다.

2.2.2.2. firewalld를 방화벽으로 구성

iptables가 기본 방화벽이지만 새로 설치하는 데 firewalld가 권장됩니다. Ansible 인벤토리 파일에서 os_firewall_use_firewalld=true 를 설정하여 firewalld를 활성화할 수 있습니다.

[OSEv3:vars]
os_firewall_use_firewalld=True

이 변수를 true 로 설정하면 필수 포트가 열리고 기본 영역에 규칙을 추가하여 firewalld가 올바르게 구성되었는지 확인합니다.

참고

firewalld 기본 구성 사용은 제한된 구성 옵션과 함께 제공되며 재정의할 수 없습니다. 예를 들어 여러 영역에 인터페이스를 사용하여 스토리지 네트워크를 설정할 수 있지만, 노드가 통신하는 인터페이스가 기본 영역에 있어야 합니다.

2.2.2.3. 여러 네트워크 인터페이스가 있는 호스트

호스트에 네트워크 인터페이스가 한 개 이상 있는 경우 OpenShift Container Platform은 설치, 클러스터 네트워크 및 서비스 네트워크에는 하나의 네트워크 인터페이스만 사용합니다. OpenShift Container Platform과 관련이 없는 통신에 추가 네트워크 인터페이스를 사용할 수 있지만, 다른 네트워크 인터페이스를 통해 클러스터 관련 트래픽과 다른 클러스터 관련 트래픽을 라우팅할 수 없습니다.

2.2.2.4. 필수 포트

OpenShift Container Platform 설치는 iptables 를 사용하여 각 호스트에 자동으로 내부 방화벽 규칙 세트를 생성합니다. 그러나 네트워크 구성이 하드웨어 기반 방화벽과 같은 외부 방화벽을 사용하는 경우 특정 프로세스 또는 서비스의 통신 엔드포인트 역할을 하는 특정 포트를 통해 인프라 구성 요소가 서로 통신할 수 있는지 확인해야 합니다.

OpenShift Container Platform에 필요한 다음 포트가 네트워크에서 열려 있고 호스트 간 액세스를 허용하도록 구성되었는지 확인합니다. 일부 포트는 구성 및 사용량에 따라 선택 사항입니다.

표 2.2. Node to Node

4789

UDP

별도의 호스트의 Pod 간 SDN 통신에 필요합니다.

표 2.3. 마스터로 노드

4789

UDP

별도의 호스트의 Pod 간 SDN 통신에 필요합니다.

443 또는 8443

TCP

노드 호스트가 마스터 API와 통신하는 데 필요합니다. 노드 호스트는 백엔드 상태, 작업을 수신하는 등의 작업에 필요합니다.

표 2.4. 노드 마스터

4789

UDP

별도의 호스트의 Pod 간 SDN 통신에 필요합니다.

10250

TCP

oc 명령에 대해 Kubelet을 통해 노드 호스트에 대한 마스터 프록시입니다. 마스터 및 인프라 노드에서 모든 마스터 및 노드로 이 포트를 허용해야 합니다. 메트릭의 경우 소스가 인프라 노드여야 합니다.

10010

TCP

CRI-O를 사용하는 경우 이 포트를 열어 oc execoc rsh 작업을 허용합니다.

표 2.5. 마스터 마스터

2049

TCP/UDP

설치 프로그램의 일부로 NFS 호스트를 프로비저닝할 때 필요합니다.

2379

TCP

독립 실행형 etcd(클러스터)에 사용하여 변경 사항을 승인하는 데 사용됩니다.

2380

TCP

etcd는 독립형 etcd(Cluster)를 사용할 때 리더 선택 및 피어링 연결을 위해 마스터 간에 이 포트를 열어야 합니다.

4789

UDP

별도의 호스트의 Pod 간 SDN 통신에 필요합니다.

표 2.6. 로드 밸런서 외부

9000

TCP

네이티브 HA 방법을 선택하는 경우 선택 옵션으로 HAProxy 통계 페이지에 액세스할 수 있습니다.

표 2.7. 마스터 외부

443 또는 8443

TCP

노드 호스트가 마스터 API와 통신하는 데 필요합니다. 노드 호스트는 상태를 게시하고 작업을 수신하는 등의 작업을 수행합니다.

8444

TCP

컨트롤러 관리자 및 스케줄러 서비스가 수신 대기하는 포트입니다. /metrics/healthz 끝점에 대해 열어야 합니다.

표 2.8. IaaS 배포

22

TCP

설치 프로그램 또는 시스템 관리자가 SSH에 필요합니다.

53 또는 8053

TCP/UDP

클러스터 서비스(SkyDNS)의 DNS 확인에 필요합니다. 3.2 이전의 설치 또는 환경이 3.2로 업그레이드된 경우 포트 53을 사용합니다. 새로운 설치는 기본적으로 8053을 사용하므로 dnsmasq 를 구성할 수 있습니다. 마스터 호스트에서 내부적으로 열려 있어야 합니다.

80 또는 443

TCP

라우터에 HTTP/HTTPS를 사용합니다. 특히 라우터를 실행하는 노드에서 외부로 열어야 합니다.

1936

TCP

(선택 사항) 템플릿 라우터를 실행하여 통계에 액세스할 때 열어야 합니다. 통계를 공개적으로 표현할 수 있는지 여부에 따라 외부적으로 또는 내부적으로 연결에 대해 열 수 있습니다. 열기 위해 추가 구성이 필요할 수 있습니다. 자세한 내용은 아래 참고 섹션을 참조하십시오.

23792380

TCP

독립형 etcd의 경우 다음을 사용합니다. 마스터 호스트에서 내부적으로 열려 있어야 합니다. 2379 는 서버-클라이언트 연결용입니다. 2380 은 서버-서버 연결용이며 etcd를 클러스터링한 경우에만 필요합니다.

4789

UDP

VxLAN 사용(OpenShift SDN). 노드 호스트에서 내부적으로만 필요합니다.

8443

TCP

OpenShift Container Platform 웹 콘솔에서 사용하기 위해 API 서버와 공유됩니다.

10250

TCP

Kubelet에서 사용합니다. 노드에서 외부로 열어야 합니다.

참고

  • 위의 예에서 포트 4789 는 UDP(User Datagram Protocol)에 사용됩니다.
  • 배포가 SDN을 사용하는 경우 레지스트리가 배포된 동일한 노드에서 레지스트리에 액세스하지 않는 한 서비스 프록시를 통해 Pod 네트워크에 액세스합니다.
  • OpenShift Container Platform 내부 DNS는 SDN을 통해 수신할 수 없습니다. 클라우드 배포가 아닌 경우 기본적으로 마스터 호스트의 기본 경로와 연결된 IP 주소로 설정됩니다. 클라우드 배포의 경우 클라우드 메타데이터에 정의된 첫 번째 내부 인터페이스와 연결된 IP 주소로 기본 설정됩니다.
  • 마스터 호스트는 포트 10250 을 사용하여 노드에 도달하고 SDN을 초과하지 않습니다. 배포의 대상 호스트에 따라 달라지며 계산된 openshift_public_hostname 을 사용합니다.
  • 포트 1936 은 iptables 규칙으로 인해 계속 액세스할 수 없습니다. 다음을 사용하여 1936 포트를 열도록 iptables를 구성합니다.

    # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp \
        --dport 1936 -j ACCEPT
표 2.9. 집계된 로깅 및 메트릭

9200

TCP

Elasticsearch API 사용의 경우 Kibana가 디스플레이 로그를 검색할 수 있도록 모든 인프라 노드에서 내부적으로 열어야 합니다. 경로를 통해 Elasticsearch에 직접 액세스하기 위해 외부에서 열 수 있습니다. 경로는 oc expose 를 사용하여 생성할 수 있습니다.

9300

TCP

Elasticsearch 간 사용의 경우. Elasticsearch 클러스터의 멤버가 서로 통신할 수 있도록 모든 인프라 노드에서 내부적으로 열어야 합니다.

9090

TCP

Prometheus API 및 웹 콘솔의 경우 를 사용합니다.

9100

TCP

하드웨어 및 운영 체제 지표를 내보내는 Prometheus Node-Exporter의 경우 Prometheus 서버가 메트릭을 스크랩하려면 각 OpenShift Container Platform 호스트에서 포트 9100을 열어야 합니다.

8443

TCP

노드 호스트가 마스터 API에 통신할 경우 노드 호스트에서 백 상태를 게시하고 작업을 수신하는 등의 작업을 수행합니다. 마스터 및 인프라 노드에서 모든 마스터 및 노드로 이 포트를 허용해야 합니다.

10250

TCP

Kubernetes cAdvisor의 경우 컨테이너 리소스 사용 및 성능 분석 에이전트입니다. 마스터 및 인프라 노드에서 모든 마스터 및 노드로 이 포트를 허용해야 합니다. 메트릭의 경우 소스가 인프라 노드여야 합니다.

8444

TCP

컨트롤러 관리자 및 스케줄러 서비스가 수신 대기하는 포트입니다. 포트 8444는 각 OpenShift Container Platform 호스트에서 열려 있어야 합니다.

1936

TCP

(선택 사항) 템플릿 라우터를 실행하여 통계에 액세스할 때 열어야 합니다. 라우터에서 Prometheus 지표가 활성화된 경우 인프라 노드에서 라우터를 호스팅하는 인프라 노드로 이 포트를 허용해야 합니다. 통계를 공개적으로 표현할 수 있는지 여부에 따라 외부적으로 또는 내부적으로 연결에 대해 열 수 있습니다. 열기 위해 추가 구성이 필요할 수 있습니다. 자세한 내용은 위의 참고 섹션을 참조하십시오.

참고

2.2.3. 영구 스토리지

Kubernetes 영구 볼륨 프레임 워크를 사용하면 사용자 환경에서 사용 가능한 네트워크 스토리지를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. 이 작업은 애플리케이션 요구에 따라 초기 OpenShift Container Platform 설치를 완료한 후 수행할 수 있으며 사용자는 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

클러스터 구성 가이드에서는 클러스터 관리자가 NFS,GlusterFS,Ceph RBD,OpenStack Cinder,AWS Elastic Block Store(EBS ), GCE 영구 디스크 및 iSCSI 를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝하는 방법에 대한 지침을 제공합니다.

2.2.4. 클라우드 공급자 고려 사항

클라우드 공급자에 OpenShift Container Platform을 설치할 때 고려해야 할 몇 가지 사항이 있습니다.

2.2.4.1. 감지된 IP 주소 및 호스트 이름 덮어쓰기

일부 배포에서는 사용자가 호스트의 탐지된 호스트 이름 및 IP 주소를 재정의해야 합니다. 기본값을 보려면 플레이북 디렉터리로 변경하고 openshift_facts 플레이북을 실행합니다.

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook  [-i /path/to/inventory] \
  playbooks/byo/openshift_facts.yml
중요

Amazon Web Services의 경우 Overriding Detected IP Addresses and Host Names 섹션을 참조하십시오.

이제 감지된 공통 설정을 확인합니다. 해당 사용자가 예상하는 내용이 아닌 경우 재정의할 수 있습니다.

Inventory File 구성 주제에서는 사용 가능한 Ansible 변수에 대해 자세히 설명합니다.

변수사용법

hostname

  • 인스턴스 자체에서 내부 IP 주소로 확인됩니다.

ip

  • 인스턴스의 내부 IP 주소입니다.

public_hostname

  • 클라우드 외부의 호스트에서 외부 IP로 확인.
  • 공급자 openshift_public_hostname 덮어쓰기.

public_ip

  • 인스턴스와 연결된 외부 액세스 IP 주소입니다.
  • openshift_public_ip 재정의

use_openshift_sdn

  • GCE를 제외한 모든 클라우드의 경우 true 로 설정합니다.
  • openshift_use_openshift_sdn overrides.
2.2.4.2. 클라우드 공급자에 대한 설치 후 구성

설치 프로세스에 따라 AWS,OpenStack 또는 GCE 용으로 OpenShift Container Platform을 구성할 수 있습니다.

3장. 호스트 준비

OpenShift Container Platform을 설치하기 전에 노드 호스트를 준비해야 합니다. 다음 요구 사항을 충족해야 합니다.

3.1. 운영 체제 요구 사항

마스터 및 노드 호스트에 대한 운영 체제 요구 사항은 서버 아키텍처에 따라 다릅니다.

  • x86_64 아키텍처를 사용하는 서버의 경우 RHEL(Red Hat Enterprise Linux) 7.5 이상의 기본 설치를 Extras 채널 또는 RHEL Atomic Host 7.4.2 이상의 최신 패키지와 함께 사용합니다.
  • 클라우드 기반 설치의 경우 Extras 채널의 최신 패키지와 함께 RHEL 7.5 이상의 기본 설치를 사용하십시오.
  • IBM POWER8 아키텍처를 사용하는 서버의 경우 Extras 채널의 최신 패키지와 함께 RHEL 7.5 이상의 기본 설치를 사용합니다.
  • IBM POWER9 아키텍처를 사용하는 서버의 경우 Extras 채널의 최신 패키지와 함께 RHEL-ALT 7.5 이상의 기본 설치를 사용합니다.

필요한 경우 해당 설치 지침은 다음 문서를 참조하십시오.

3.2. 서버 유형 요구 사항

노드에 IBM POWER 서버를 사용하는 경우 IBM POWER 서버만 사용할 수 있습니다. IBM POWER 서버에서 실행되는 노드를 x86_64 서버를 사용하는 기존 클러스터에 추가하거나 IBM POWER 및 x86_64 서버를 혼합하여 클러스터 노드를 배포할 수 없습니다.

3.3. PATH 설정

각 호스트의 root 사용자의 PATH 에는 다음 디렉터리가 포함되어야 합니다.

  • /bin
  • /sbin
  • /usr/bin
  • /usr/sbin

이러한 디렉터리는 기본적으로 새로운 RHEL 7.x 설치에 설정됩니다.

3.4. 호스트 액세스 확인

OpenShift Container Platform 설치 프로그램에는 모든 호스트에 액세스할 수 있는 사용자가 필요합니다. 설치 프로그램을 루트가 아닌 사용자로 실행하려면 먼저 암호 없는 sudo 권한을 각 호스트에 구성합니다.

  1. 설치 Playbook을 실행하는 호스트에서 SSH 키를 생성합니다.

    # ssh-keygen

    암호를 사용하지 마십시오.

  2. 키를 다른 클러스터 호스트에 배포합니다. bash 루프를 사용할 수 있습니다.

    # for host in master.example.com \ 1
        node1.example.com \  2
        node2.example.com; \ 3
        do ssh-copy-id -i ~/.ssh/id_rsa.pub $host; \
        done
    1 2 3
    각 클러스터 호스트에 대한 호스트 이름을 제공합니다.
  3. SSH를 통해 반복문에 나열된 각 호스트에 액세스할 수 있는지 확인합니다.

3.5. 프록시 덮어쓰기 설정

노드의 /etc/environment 파일에 http_proxy 또는 https_proxy 값이 포함된 경우 OpenShift Container Platform 구성 요소 간 열린 통신을 허용하도록 해당 파일에 no_proxy 값을 설정해야 합니다.

참고

/etc/environment 파일의 no_proxy 매개변수는 인벤토리 파일에 설정한 글로벌 프록시 값과 동일한 값이 아닙니다. 글로벌 프록시 값은 프록시 설정으로 특정 OpenShift Container Platform 서비스를 구성합니다. 자세한 내용은 글로벌 프록시 옵션 구성을 참조하십시오.

/etc/environment 파일에 프록시 값이 포함된 경우 각 노드의 no_proxy 매개변수에 다음 값을 정의합니다.

  • 마스터 및 노드 호스트 이름 또는 해당 도메인 접미사.
  • 기타 내부 호스트 이름 또는 해당 도메인 접미사.
  • etcd IP 주소. etcd 액세스가 IP 주소로 제어되므로 호스트 이름이 아닌 IP 주소를 제공해야 합니다.
  • Kubernetes IP 주소(기본적으로 172.30.0.1 ) 인벤토리 파일의 openshift_portal_net 매개변수에 설정된 값이어야 합니다.
  • Kubernetes 내부 도메인 접미사, cluster.local.
  • Kubernetes 내부 도메인 접미사인 .svc .svc.
참고

no_proxy 가 CIDR을 지원하지 않기 때문에 도메인 접미사를 사용할 수 있습니다.

http_proxy 또는 https_proxy 값을 사용하는 경우 no_proxy 매개변수 값이 다음 예와 유사합니다.

no_proxy=.internal.example.com,10.0.0.1,10.0.0.2,10.0.0.3,.cluster.local,.svc,localhost,127.0.0.1,172.30.0.1

3.6. 호스트 등록

설치 패키지에 액세스하려면 각 호스트를 RHSM(Red Hat Subscription Manager)에 등록하고 활성 OpenShift Container Platform 서브스크립션을 연결해야 합니다.

  1. 각 호스트에서 RHSM으로 동륵합니다.

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

    # subscription-manager refresh
  3. 사용 가능한 서브스크립션을 나열하십시오.

    # subscription-manager list --available --matches '*OpenShift*'
  4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다.

    # subscription-manager attach --pool=<pool_id>
  5. 모든 yum 저장소를 비활성화합니다.

    1. 활성화된 모든 RHSM 저장소를 비활성화합니다.

      # subscription-manager repos --disable="*"
    2. 나머지 yum 저장소를 나열하고 repo id 아래에 해당 이름을 적어 둡니다.

      # yum repolist
    3. yum-config-manager를 사용하여 나머지 yum 리포지토리를 비활성화합니다.

      # yum-config-manager --disable <repo_id>

      또는 모든 리포지토리를 비활성화합니다.

       yum-config-manager --disable \*

      사용 가능한 리포지토리가 많으면 몇 분의 시간이 소요될 수 있습니다.

  6. OpenShift Container Platform 3.11에 필요한 리포지토리를 활성화합니다.

    • x86_64 서버에 클라우드 설치 및 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-server-rpms" \
          --enable="rhel-7-server-extras-rpms" \
          --enable="rhel-7-server-ose-3.11-rpms" \
          --enable="rhel-7-server-ansible-2.9-rpms"
    • IBM POWER8 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-for-power-le-rpms" \
          --enable="rhel-7-for-power-le-extras-rpms" \
          --enable="rhel-7-for-power-le-optional-rpms" \
          --enable="rhel-7-server-ansible-2.9-for-power-le-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.11-rpms"
    • IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-for-power-9-rpms" \
          --enable="rhel-7-for-power-9-extras-rpms" \
          --enable="rhel-7-for-power-9-optional-rpms" \
          --enable="rhel-7-server-ansible-2.9-for-power-9-rpms" \
          --enable="rhel-7-server-for-power-9-rhscl-rpms" \
          --enable="rhel-7-for-power-9-ose-3.11-rpms"
    참고

    이전 버전의 OpenShift Container Platform 3.11은 Ansible 2.6만 지원했습니다. 최신 버전의 플레이북에서는 이제 사용할 기본 버전인 Ansible 2.9를 지원합니다.

3.7. 기본 패키지 설치

중요

호스트에서 RHEL 7.5를 사용하고 OpenShift Container Platform의 기본 Docker 구성( OverlayFS 스토리지 및 모든 기본 로깅 옵션 사용)을 수락하려면 이러한 패키지를 수동으로 설치하지 마십시오. 이러한 패키지는 설치 중에 prerequisites.yml 플레이북을 실행할 때 설치됩니다.

호스트에서 RHEL 7.4를 사용하거나 RHEL 7.5를 사용하고 docker 구성을 사용자 정의하려는 경우 이러한 패키지를 설치하십시오.

RHEL 7 시스템의 경우:

  1. 다음 기본 패키지를 설치합니다.

    # yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
  2. 시스템을 최신 패키지로 업데이트합니다.

    # yum update
    # reboot
  3. 설치 방법에 필요한 패키지를 설치합니다.

    • 컨테이너화된 설치 프로그램을 사용하려면 다음 패키지를 설치합니다.

      # yum install atomic
    • RPM 기반 설치 프로그램을 사용하려면 다음 패키지를 설치합니다.

      # yum install openshift-ansible
      참고

      yum install openshift-ansible 명령을 실행하는 동안 오류가 발생하면 문제 해결 방법을 참조하십시오.

      이 패키지는 설치 프로그램 유틸리티를 제공하고 Ansible, 플레이북, 관련 구성 파일과 같이 클러스터 설치 프로세스에 필요한 다른 패키지를 가져옵니다.

RHEL Atomic Host 7 시스템의 경우:

  1. 사용 가능한 경우 최신 Atomic 트리로 업그레이드하여 호스트를 최신 상태로 유지합니다.

    # atomic host upgrade
  2. 업그레이드가 완료되고 다음 부팅을 준비한 후 호스트를 재부팅합니다.

    # reboot

3.8. Docker 설치

이 시점에서 모든 마스터 및 노드 호스트에 Docker를 설치합니다. 이를 통해 OpenShift Container Platform을 설치하기 전에 Docker 스토리지 옵션을 구성할 수 있습니다.

참고

클러스터 설치 프로세스는 /etc/sysconfig/docker 파일을 자동으로 수정합니다.

RHEL 7 시스템의 경우:

  1. Docker 1.13을 설치합니다.

    # yum install docker-1.13.1
  2. 1.13 버전이 설치되었는지 확인합니다.

    # rpm -V docker-1.13.1
    # docker version

RHEL Atomic Host 7 시스템의 경우:

작업이 필요하지 않습니다. Docker는 기본적으로 설치, 구성 및 실행됩니다.

3.9. Docker Storage 구성

에서 생성된 컨테이너 및 이미지는 Docker의 스토리지 백엔드에 저장됩니다. 이 스토리지는 임시 스토리지이며 애플리케이션의 요구 사항을 충족하기 위해 할당된 영구 스토리지와 별개입니다. 임시 스토리지를 사용하면 컨테이너를 제거할 때 컨테이너 저장 데이터가 손실됩니다. 영구 스토리지를 사용하면 컨테이너가 제거되는 경우에도 컨테이너 저장 데이터가 유지됩니다.

기본적으로 각 시스템에서 컨테이너 데몬을 실행하기 때문에 모든 마스터 및 노드 호스트에 대한 스토리지를 구성해야 합니다. 컨테이너화된 설치의 경우 마스터에 스토리지가 필요합니다. 또한 기본적으로 스토리지가 필요한 웹 콘솔 및 etcd는 마스터의 컨테이너에서 실행됩니다. 컨테이너는 노드에서 실행되므로 항상 스토리지가 필요합니다.

스토리지 크기는 워크로드, 컨테이너 수, 실행되는 컨테이너의 크기 및 컨테이너 스토리지 요구 사항에 따라 다릅니다.

중요

호스트에서 RHEL 7.5를 사용하고 OpenShift Container Platform의 기본 Docker 구성( OverlayFS 스토리지 및 모든 기본 로깅 옵션 사용)을 수락하려면 이러한 패키지를 수동으로 설치하지 마십시오. 이러한 패키지는 설치 중에 prerequisites.yml 플레이북을 실행할 때 설치됩니다.

호스트에서 RHEL 7.4를 사용하거나 RHEL 7.5를 사용하고 docker 구성을 사용자 정의하려는 경우 이러한 패키지를 설치하십시오.

RHEL 7 시스템의 경우:

RHEL 7의 기본 스토리지 백엔드는 루프백 장치의 씬 풀로, 프로덕션 용도에는 지원되지 않으며 개념 증명 환경에만 적합합니다. 프로덕션 환경의 경우 씬 풀 논리 볼륨을 생성하고 해당 볼륨을 사용하도록 Docker를 다시 구성해야 합니다.

Docker는 이미지와 컨테이너를 그래프 드라이버에 저장합니다. 이 드라이버는 DeviceMapper,OverlayFS 및 RuntimeClass와 같은 플러그형 스토리지 기술인 그래프 드라이버에 저장합니다. 각각에는 장단점이 있습니다. 예를 들어 OverlayFS는 컨테이너 시작 및 중지 시 DeviceMapper보다 빠르지만 Unix (POSIX)용 운영 체제 인터페이스는 통합 파일 시스템의 아키텍처 제한으로 인해 호환되지 않습니다. RHEL 버전에서 OverlayFS 사용에 대한 정보는 Red Hat Enterprise Linux 릴리스 노트를 참조하십시오.

DeviceMapper 및 OverlayFS의 이점 및 제한에 대한 자세한 내용은 Graph Driver Choosing을 참조하십시오.

RHEL Atomic Host 7 시스템의 경우:

RHEL Atomic Host의 Docker의 기본 스토리지 백엔드는 프로덕션 환경에서 지원되는 씬 풀 논리 볼륨입니다. 시스템 요구 사항에 설명된 Docker 스토리지 요구 사항에 따라 이 볼륨에 충분한 공간이 할당되어 있는지 확인해야 합니다.

공간이 충분하지 않은 경우 RHEL Atomic Host의 스토리지 관리에 대한 자세한 내용은 docker-storage-setup 및 기본 명령을 사용하는 방법에 대한 자세한 내용은 Docker 포맷 을 사용하여 스토리지 관리를 참조하십시오.

3.9.1. OverlayFS 구성

OverlayFS는 일종의 통합 파일 시스템입니다. OverlayFS를 사용하면 다른 파일 시스템을 위에 오버레이할 수 있습니다. 변경 사항은 상위 파일 시스템에 기록되지만 하위 파일 시스템은 수정되지 않은 상태로 유지됩니다.

Overlay Versus Overlay2 Graph 드라이버를 비교하면 overlay overlay 2 드라이버에 대한 자세한 내용이 있습니다.

overlay2 드라이버를 사용하려면 하위 계층에서 XFS 파일 시스템을 사용해야 합니다. 하위 계층 파일 시스템은 수정되지 않은 파일 시스템입니다.

Docker 서비스의 OverlayFS 스토리지 드라이버 활성화에 대한 자세한 내용은 Red Hat Enterprise Linux Atomic Host 설명서 를 참조하십시오.

3.9.2. 씬 풀 스토리지 구성

Docker에 포함된 docker-storage-setup 스크립트를 사용하여 씬 풀 장치를 생성하고 Docker의 스토리지 드라이버를 구성할 수 있습니다. Docker를 설치한 후 이 작업을 수행할 수 있으며 이미지 또는 컨테이너를 만들기 전에 수행해야 합니다. 이 스크립트는 /etc/sysconfig/docker-storage-setup 파일에서 구성 옵션을 읽고 논리 볼륨 생성을 위한 세 가지 옵션을 지원합니다.

  • 추가 블록 장치를 사용합니다.
  • 지정된 기존 볼륨 그룹을 사용합니다.
  • 루트 파일 시스템이 있는 볼륨 그룹에서 남은 여유 공간을 사용합니다.

추가 블록 장치를 사용하는 것은 가장 강력한 옵션이지만 Docker 스토리지를 구성하기 전에 다른 블록 장치를 호스트에 추가해야 합니다. 다른 옵션 둘 다 호스트를 프로비저닝할 때 사용 가능한 공간을 남겨 두어야합니다. 루트 파일 시스템 볼륨 그룹의 사용 가능한 공간을 사용하는 것은 일부 애플리케이션에 문제가 발생하는 것으로 알려져 있습니다(예: Red Hat Mobile Application Platform (RHMAP).

  1. 다음 세 가지 옵션 중 하나를 사용하여 docker-pool 볼륨을 만듭니다.

    • 추가 블록 장치를 사용하려면 다음을 수행합니다.

      1. /etc/sysconfig/docker-storage-setup 에서1.8.0 S 를 사용할 블록 장치의 경로로 설정합니다. VG 를 볼륨 그룹 이름으로 설정하여 docker-vg 와 같이 만듭니다. 예를 들면 다음과 같습니다.

        # cat <<EOF > /etc/sysconfig/docker-storage-setup
        DEVS=/dev/vdc
        VG=docker-vg
        EOF
      2. docker-storage-setup 을 실행하고 출력을 검토하여 docker-pool 볼륨이 생성되었는지 확인합니다.

        # docker-storage-setup                                                                                                                                                                                                                                [5/1868]
        0
        Checking that no-one is using this disk right now ...
        OK
        
        Disk /dev/vdc: 31207 cylinders, 16 heads, 63 sectors/track
        sfdisk:  /dev/vdc: unrecognized partition table type
        
        Old situation:
        sfdisk: No partitions found
        
        New situation:
        Units: sectors of 512 bytes, counting from 0
        
           Device Boot    Start       End   #sectors  Id  System
        /dev/vdc1          2048  31457279   31455232  8e  Linux LVM
        /dev/vdc2             0         -          0   0  Empty
        /dev/vdc3             0         -          0   0  Empty
        /dev/vdc4             0         -          0   0  Empty
        Warning: partition 1 does not start at a cylinder boundary
        Warning: partition 1 does not end at a cylinder boundary
        Warning: no primary partition is marked bootable (active)
        This does not matter for LILO, but the DOS MBR will not boot this disk.
        Successfully wrote the new partition table
        
        Re-reading the partition table ...
        
        If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
        to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
        (See fdisk(8).)
          Physical volume "/dev/vdc1" successfully created
          Volume group "docker-vg" successfully created
          Rounding up size to full physical extent 16.00 MiB
          Logical volume "docker-poolmeta" created.
          Logical volume "docker-pool" created.
          WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
          THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
          Converted docker-vg/docker-pool to thin pool.
          Logical volume "docker-pool" changed.
    • 기존 지정된 볼륨 그룹을 사용하려면 다음을 수행합니다.

      1. /etc/sysconfig/docker-storage-setup 에서 VG 를 볼륨 그룹으로 설정합니다. 예를 들면 다음과 같습니다.

        # cat <<EOF > /etc/sysconfig/docker-storage-setup
        VG=docker-vg
        EOF
      2. 그런 다음 docker-storage-setup 을 실행하고 출력을 검토하여 docker-pool 볼륨이 생성되었는지 확인합니다.

        # docker-storage-setup
          Rounding up size to full physical extent 16.00 MiB
          Logical volume "docker-poolmeta" created.
          Logical volume "docker-pool" created.
          WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
          THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
          Converted docker-vg/docker-pool to thin pool.
          Logical volume "docker-pool" changed.
    • 루트 파일 시스템이 있는 볼륨 그룹에서 나머지 여유 공간을 사용하려면 다음을 수행합니다.

      1. 루트 파일 시스템이 있는 볼륨 그룹에 필요한 여유 공간이 있는지 확인한 다음 docker-storage-setup 을 실행하고 출력을 검토하여 docker-pool 볼륨이 생성되었는지 확인합니다.

        # docker-storage-setup
          Rounding up size to full physical extent 32.00 MiB
          Logical volume "docker-poolmeta" created.
          Logical volume "docker-pool" created.
          WARNING: Converting logical volume rhel/docker-pool and rhel/docker-poolmeta to pool's data and metadata volumes.
          THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
          Converted rhel/docker-pool to thin pool.
          Logical volume "docker-pool" changed.
  2. 구성을 확인합니다. /etc/sysconfig/docker-storage 파일에 dm.thinpooldevdocker-pool 논리 볼륨 값이 있는지 확인합니다.

    # cat /etc/sysconfig/docker-storage
    DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/rhel-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "
    
    # lvs
      LV          VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      docker-pool rhel twi-a-t---  9.29g             0.00   0.12
    중요

    Docker 또는 OpenShift Container Platform을 사용하기 전에 docker-pool 논리 볼륨이 요구 사항을 충족할 수 있을 만큼 충분히 큰지 확인합니다. 사용 가능한 볼륨 그룹의 docker-pool 볼륨 60%를 만듭니다. LVM 모니터링을 통해 볼륨 그룹을 채우기 위해 증가합니다.

  3. Docker를 시작하거나 다시 시작합니다.

    • 호스트에서 Docker가 실행되지 않은 경우 서비스를 활성화하고 시작한 다음 실행 중인지 확인합니다.

      # systemctl enable docker
      # systemctl start docker
      # systemctl is-active docker
    • Docker가 이미 실행 중인 경우:

      1. Docker를 다시 초기화합니다.

        주의

        그러면 현재 호스트에 있는 모든 컨테이너 또는 이미지가 제거됩니다.

        # systemctl stop docker
        # rm -rf /var/lib/docker/*
        # systemctl restart docker
      2. /var/lib/docker/ 폴더의 콘텐츠를 삭제합니다.

3.9.3. Docker 스토리지 재구성

docker-pool 을 생성한 후 Docker 스토리지를 재구성해야 하는 경우:

  1. docker-pool 논리 볼륨을 제거합니다.
  2. 전용 볼륨 그룹을 사용하는 경우 볼륨 그룹 및 관련 물리 볼륨을 제거하십시오.
  3. docker-storage-setup 을 다시 실행합니다.

LVM 관리에 대한 자세한 내용은 Logical Volume Manager Administration 을 참조하십시오.

3.9.4. 이미지 서명 지원 활성화

OpenShift Container Platform은 이미지가 신뢰할 수 있는 소스에서 암호화 방식으로 확인할 수 있습니다. 컨테이너 보안 가이드에서 는 이미지 서명의 작동 방식에 대한 고급 설명을 제공합니다.

atomic 명령행 인터페이스(CLI), 버전 1.12.5 이상을 사용하여 이미지 서명 확인을 구성할 수 있습니다. atomic CLI는 RHEL Atomic Host 시스템에 사전 설치되어 있습니다.

참고

atomic CLI에 대한 자세한 내용은 Atomic CLI 설명서 를 참조하십시오.

다음 파일 및 디렉터리는 호스트의 신뢰 구성을 구성합니다.

  • /etc/containers/registries.d/*
  • /etc/containers/policy.json

각 노드에서 직접 신뢰 구성을 관리하거나 별도의 호스트의 파일을 Ansible을 사용하여 적절한 노드에 배포할 수 있습니다. 예를 들면 다음과 같습니다. Ansible을 사용하여 파일 배포 자동화 예제는 컨테이너 이미지 서명 통합 가이드 를 참조하십시오.

  1. 호스트 시스템에 설치되지 않은 경우 atomic 패키지를 설치합니다.

    $ yum install atomic
  2. 현재 신뢰 구성을 확인합니다.

    $ atomic trust show
    * (default)                         accept

    기본 구성은 모든 레지스트리를 허용 목록에 추가하는 것입니다. 즉, 서명 확인이 구성되지 않았음을 의미합니다.

  3. 신뢰 구성을 사용자 정의합니다. 다음 예제에서는 하나의 레지스트리 또는 네임스페이스, 신뢰할 수 없는 레지스트리를 블랙리스트(라이프트)하고, 벤더 레지스트리에서 서명 확인이 필요합니다.

    $ atomic trust add --type insecureAcceptAnything 172.30.1.1:5000
    
    $ atomic trust add --sigstoretype atomic \
      --pubkeys pub@example.com \
      172.30.1.1:5000/production
    
    $ atomic trust add --sigstoretype atomic \
      --pubkeys /etc/pki/example.com.pub \
      172.30.1.1:5000/production
    
    $ atomic trust add --sigstoretype web \
      --sigstore https://access.redhat.com/webassets/docker/content/sigstore \
      --pubkeys /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \
      registry.redhat.io
    
    # atomic trust show
    * (default)                         accept
    172.30.1.1:5000                     accept
    172.30.1.1:5000/production          signed security@example.com
    registry.redhat.io                  signed security@redhat.com,security@redhat.com
  4. 글로벌 거부 기본 신뢰를 추가하여 노드를 추가로 강화할 수 있습니다.

    $ atomic trust default reject
    
    $ atomic trust show
    * (default)                         reject
    172.30.1.1:5000                     accept
    172.30.1.1:5000/production          signed security@example.com
    registry.redhat.io                  signed security@redhat.com,security@redhat.com
  5. 필요한 경우 추가 구성 옵션에 대한 atomic -trust 를 검토합니다.

3.9.5. 컨테이너 로그 관리

컨테이너의 로그 파일을 방지하려면 컨테이너가 실행 중인 노드에서 /var/lib/docker/containers/<hash>/<hash>-json.log 파일에서 문제가 있는 크기로 증가하지 못하도록 Docker의 json-file 로깅 드라이버를 구성하여 로그 파일의 크기와 수를 제한할 수 있습니다.

옵션목적

--log-opt max-size

새 로그 파일이 생성되는 크기를 설정합니다.

--log-opt max-file

호스트별로 보관할 최대 로그 파일 수를 설정합니다.

  1. 로그 파일을 구성하려면 /etc/sysconfig/docker 파일을 편집합니다. 예를 들어 최대 파일 크기를 1MB로 설정하고 항상 마지막 세 개의 로그 파일을 유지하려면 max-size=1Mmax-file=3OPTIONS= 행에 추가하여 값이 단일 따옴표 형식을 유지하도록 합니다.

    OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'

    로깅 드라이버 구성 방법에 대한 자세한 내용은 Docker의 설명서를 참조하십시오.

  2. Docker 서비스를 다시 시작하십시오.

    # systemctl restart docker

3.9.6. 사용 가능한 컨테이너 로그 보기

컨테이너가 실행 중인 노드의 /var/lib/docker/containers/<hash>/ 디렉터리에서 컨테이너 로그를 볼 수 있습니다. 예를 들면 다음과 같습니다.

# ls -lh /var/lib/docker/containers/f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8/
total 2.6M
-rw-r--r--. 1 root root 5.6K Nov 24 00:12 config.json
-rw-r--r--. 1 root root 649K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.1
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.2
-rw-r--r--. 1 root root 1.3K Nov 24 00:12 hostconfig.json
drwx------. 2 root root    6 Nov 24 00:12 secrets

3.9.7. 로컬 볼륨 사용량 차단

DockerfileVOLUME 명령을 사용하거나 docker run -v <volumename > 명령을 사용하여 볼륨을 프로비저닝하면 호스트의 스토리지 공간이 사용됩니다. 이 스토리지를 사용하면 예기치 않은 공간 문제가 발생하여 호스트를 중단할 수 있습니다.

OpenShift Container Platform에서 자체 이미지를 실행하려고 하면 노드 호스트의 전체 스토리지 공간이 채워지게 됩니다. 이 문제에 대한 한 가지 해결책은 사용자가 볼륨을 사용하여 이미지를 실행하지 못하도록 하는 것입니다. 이렇게 하면 사용자가 액세스할 수 있는 유일한 스토리지를 제한할 수 있으며 클러스터 관리자가 스토리지 할당량을 할당할 수 있습니다.

docker-novolume-plugin 을 사용하면 정의된 로컬 볼륨에서 컨테이너를 시작하지 못하도록 하여 이 문제를 해결합니다. 특히 플러그인은 다음을 포함하는 docker run 명령을 차단합니다.

  • --volumes-from 옵션
  • VOLUME(s)가 정의된 이미지
  • docker volume 명령을 사용하여 프로비저닝된 기존 볼륨에 대한 참조

플러그인은 바인드 마운트에 대한 참조를 차단하지 않습니다.

docker-novolume-plugin 을 활성화하려면 각 노드 호스트에서 다음 단계를 수행합니다.

  1. docker-novolume-plugin 패키지를 설치합니다.

    $ yum install docker-novolume-plugin
  2. docker-novolume-plugin 서비스를 활성화하고 시작합니다.

    $ systemctl enable docker-novolume-plugin
    $ systemctl start docker-novolume-plugin
  3. /etc/sysconfig/docker 파일을 편집하고 OPTIONS 목록에 다음을 추가합니다.

    --authorization-plugin=docker-novolume-plugin
  4. docker 서비스를 다시 시작하십시오.

    $ systemctl restart docker

이 플러그인을 활성화하면 로컬 볼륨이 정의된 컨테이너가 시작되지 않고 다음 오류 메시지가 표시됩니다.

runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed

3.10. Red Hat Gluster Storage 소프트웨어 요구 사항

GlusterFS 볼륨에 액세스하려면 예약 가능한 모든 노드에서 mount.glusterfs 명령을 사용할 수 있어야 합니다. RPM 기반 시스템의 경우 glusterfs-adapter 패키지를 설치해야 합니다.

# yum install glusterfs-fuse

이 패키지는 모든 RHEL 시스템에 설치됩니다. 그러나 서버에서 x86_64 아키텍처를 사용하는 경우 Red Hat Gluster Storage에서 사용 가능한 최신 버전으로 업데이트하는 것이 좋습니다. 이렇게 하려면 다음 RPM 리포지토리를 활성화해야 합니다.

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

glusterfs-adapter 가 이미 노드에 설치되어 있는 경우 최신 버전이 설치되어 있는지 확인합니다.

# yum update glusterfs-fuse

3.11. 다음 단계

호스트 준비를 마친 후 OpenShift Container Platform을 설치하는 경우 인벤토리 파일을 구성합니다. 독립 실행형 레지스트리를 설치하는 경우 독립 실행형 레지스트리 를 계속 설치합니다.

4장. 인벤토리 파일 구성

4.1. 클러스터의 인벤토리 파일 사용자 정의

Ansible 인벤토리 파일은 클러스터의 호스트에 대한 세부 정보와 OpenShift Container Platform 설치에 대한 클러스터 구성 세부 정보를 설명합니다. OpenShift Container Platform 설치 플레이북은 인벤토리 파일을 읽고 호스트 세트에 OpenShift Container Platform을 설치할 위치와 방법을 확인합니다.

참고

YAML 구문에 대한 기본 세부 정보를 포함하여 인벤토리 파일 형식에 대한 자세한 내용은 Ansible 설명서 를 참조하십시오.

호스트 준비에 설명된 대로 openshift-ansible RPM 패키지를 설치하면 Ansible 종속 항목은 /etc/ansible/hosts 의 기본 위치에 파일을 생성합니다. 그러나 파일은 단순히 기본 Ansible 예이며 OpenShift Container Platform 구성과 관련된 변수가 없습니다. OpenShift Container Platform을 성공적으로 설치하려면 클러스터 topography 및 요구 사항을 기반으로 파일의 기본 콘텐츠를 자체 구성으로 교체해야 합니다.

다음 섹션에서는 클러스터 설치 중에 인벤토리 파일에 설정하기 위해 일반적으로 사용되는 변수를 설명합니다. 설명된 대부분의 Ansible 변수는 선택 사항입니다. 개발 환경의 경우 필수 매개변수의 기본값을 수락할 수 있지만 프로덕션 환경에서 해당 변수의 적절한 값을 선택해야 합니다.

예제 인벤토리 파일에서 클러스터 설치의 시작점으로 사용할 다양한 예제를 검토할 수 있습니다.

참고

업데이트를 유지하기 위해 이미지에 버전 번호 정책이 필요합니다. 자세한 내용은 아키텍처 가이드의 이미지 버전 태그 정책 섹션을 참조하십시오.

4.2. 클러스터 변수 구성

Ansible 설치 중에 글로벌 클러스터 환경 변수를 할당하려면 /etc/ansible/hosts 파일의 [OSEv3:vars] 섹션에 추가합니다. 각 매개변수 값을 별도의 줄에 배치해야 합니다. 예를 들면 다음과 같습니다.

[OSEv3:vars]

openshift_master_identity_providers=[{'name': 'htpasswd_auth',
'login': 'true', 'challenge': 'true',
'kind': 'HTPasswdPasswordIdentityProvider',}]

openshift_master_default_subdomain=apps.test.example.com
중요

Ansible 인벤토리 파일의 매개변수 값에 #, { 또는 } 와 같은 특수 문자가 포함된 경우 값을 두 번 이스케이프해야 합니다(즉, 단일 및 이중 따옴표 모두에서 값 묶기). 예를 들어, mypasswordwith###hashsigns 를 변수 openshift_cloudprovider_openstack_password 의 값으로 사용하려면 Ansible 호스트 인벤토리 파일에서 openshift_cloudprovider_openstack_password='mypasswordwith###hashsigns" 로 선언합니다.

다음 표에서는 Ansible 설치 프로그램에서 사용할 글로벌 클러스터 변수를 설명합니다.

표 4.1. 일반 클러스터 변수
변수목적

ansible_ssh_user

이 변수는 설치 프로그램의 SSH 사용자를 사용하고 기본값은 root 로 설정합니다. 이 사용자는 암호 없이 SSH 기반 인증을 허용해야 합니다. SSH 키 기반 인증을 사용하는 경우 SSH 에이전트에서 키를 관리해야 합니다.

ansible_become

ansible_ssh_userroot 가 아닌 경우 이 변수를 true 로 설정하고 암호 없이 sudo 에 대해 사용자를 구성해야 합니다.

debug_level

이 변수는 systemd-journald.service 에 기록된 INFO 메시지를 설정합니다. 다음 중 하나를 설정합니다.

  • 오류 및 경고만 기록하기 위한 0
  • 2 정상적인 정보를 기록하는 것입니다 (이는 기본 수준입니다.)
  • 디버깅 수준 정보를 기록하기 위한 4
  • 6 API 수준 디버깅 정보(요청/응답)를 기록합니다.
  • 8 에서 본문 수준 API 디버깅 정보를 기록합니다.

디버그 로그 수준에 대한 자세한 내용은 로깅 수준 구성을 참조하십시오.

openshift_clock_enabled

클러스터 노드에서 NTP(Network Time Protocol)를 활성화할지 여부입니다. 기본값은 true입니다.

chrony 패키지가 설치된 경우 NTP 서비스를 제공하도록 구성됩니다. chrony 패키지가 설치되지 않은 경우 설치 플레이북은 NTP 서비스를 제공하도록 ntp 패키지를 설치하고 구성합니다.

중요

클러스터의 마스터와 노드가 동기화되지 않도록 하려면 이 매개변수의 기본값을 변경하지 마십시오.

openshift_master_admission_plugin_config

이 변수는 인벤토리 호스트 파일의 요구 사항에 따라 매개변수 및 임의의 JSON 값을 설정합니다. 예를 들면 다음과 같습니다.

openshift_master_admission_plugin_config={"ClusterResourceOverride":{"configuration":{"apiVersion":"v1","kind":"ClusterResourceOverrideConfig","memoryRequestToLimitPercent":"25","cpuRequestToLimitPercent":"25","limitCPUToMemoryPercent":"200"}}}

이 값 에서 openshift_master_admission_plugin_config={"openshift.io/ImagePolicy":{"configuration":{"apiVersion":"v1","executionRules":[{"matchImageAnnotations":[{"key":"images.openshift.io/deny-execution","value":"true}] "name":"execution-denied","onResources":[{"resource":"pods"},{"resource":"builds"},"reject":true,"skipOnResolutionFailure":true],"kind":"ImagePolicyConfig"}}} 은 기본 매개변수 값입니다.

중요

사용자 정의 설정을 추가해야 하는 경우에도 기본 openshift_master_admission_plugin_config 값을 포함해야 합니다.

openshift_master_audit_config

이 변수는 API 서비스 감사를 활성화합니다. 자세한 내용은 감사 구성을 참조하십시오.

openshift_master_audit_policyfile

감사 정책 파일의 위치를 제공합니다. 자세한 내용은 감사 정책 구성을 참조하십시오.

openshift_master_cluster_hostname

이 변수는 클러스터의 호스트 이름을 덮어씁니다. 기본값은 마스터의 호스트 이름입니다.

openshift_master_cluster_public_hostname

이 변수는 클러스터의 공용 호스트 이름을 덮어씁니다. 기본값은 마스터의 호스트 이름입니다. 외부 로드 밸런서를 사용하는 경우 외부 로드 밸런서의 주소를 지정합니다.

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

openshift_master_cluster_public_hostname=openshift-ansible.public.example.com

openshift_master_cluster_method

선택 사항: 이 변수는 여러 마스터를 배포할 때 HA 메서드를 정의합니다. 네이티브 메서드를 지원합니다. 자세한 내용은 여러 마스터를 참조하십시오.

openshift_rolling_restart_mode

이 변수를 사용하면 업그레이드 플레이북을 직접 실행할 때 HA 마스터(즉, 마스터가 한 번에 하나씩 다운됨)의 롤링 재시작을 활성화합니다. 기본값은 마스터에서 서비스를 롤백할 수 있는 서비스입니다. 대신 마스터 노드를 완전히 다시 시작할 수 있는 롤링을 활성화하는 시스템으로 설정할 수 있습니다.

마스터의 롤링 재시작은 업그레이드 중에 제공된 Ansible 후크 를 사용하여 추가 변경 사항을 적용해야 할 수 있습니다. 수행을 위해 선택한 작업에 따라 호스트를 재부팅하여 서비스를 다시 시작할 수 있습니다.

openshift_master_identity_providers

이 변수는 ID 공급자를 설정합니다. 기본값은 모두 거부 입니다. 지원되는 ID 공급자를 사용하는 경우 이를 사용하도록 OpenShift Container Platform을 구성합니다. 여러 ID 공급자를 구성할 수 있습니다.

openshift_master_named_certificates

이러한 변수는 설치의 일부로 배포되는 사용자 정의 인증서를 구성하는 데 사용됩니다. 자세한 내용은 사용자 정의 인증서 구성을 참조하십시오.

openshift_master_overwrite_named_certificates

openshift_hosted_router_certificate

호스팅된 라우터의 사용자 정의 인증서 위치를 제공합니다.

openshift_master_ca_certificate

OpenShift Container Platform 인증서에 서명하는 단일 인증서 및 키를 제공합니다. 새 또는 사용자 지정 OpenShift Container Platform CA 재배포를 참조하십시오.

openshift_additional_ca

openshift_master_ca_certificate 매개변수의 인증서가 중간 인증서로 서명된 경우 CA에 대한 중간 및 루트 인증서의 전체 체인이 포함된 번들 인증서를 제공합니다. 새 또는 사용자 지정 OpenShift Container Platform CA 재배포를 참조하십시오.

openshift_redeploy_service_signer

매개변수가 false 로 설정되면 openshift-master/redeploy-certificates.yml 플레이북을 실행할 때 서비스 서명자가 재배포되지 않습니다. 기본값은 true입니다.

openshift_hosted_registry_cert_expire_days

자동 생성된 레지스트리 인증서의 유효성입니다. 기본값은 730 (2년)입니다.

openshift_ca_cert_expire_days

자동 생성된 CA 인증서의 유효 기간(일). 기본값은 1825 (5년)입니다.

openshift_master_cert_expire_days

자동 생성된 마스터 인증서의 유효 기간(일). 기본값은 730 (2년)입니다.

etcd_ca_default_days

자동 생성된 외부 etcd 인증서의 유효 기간(일). etcd CA, 피어, 서버 및 클라이언트 인증서에 대한 유효성을 제어합니다. 기본값은 1825 (5년)입니다.

openshift_certificate_expiry_warning_days

이 날짜 또는 더 적은 수에 인증서가 만료되는 클러스터 업그레이드 중단. 기본값은 365 (1년)입니다.

openshift_certificate_expiry_fail_on_warn

자동 생성 인증서가 openshift_certificate_expiry_warning_days 매개변수에 지정된 기간 동안 유효하지 않은 경우 업그레이드가 실패합니다. 기본값은 True입니다.

os_firewall_use_firewalld

기본 iptables 대신 firewalld를 사용하려면 true 로 설정합니다. RHEL Atomic Host에서는 사용할 수 없습니다. 자세한 내용은 방화벽 구성 섹션을 참조하십시오.

openshift_master_session_name

이러한 변수는 OAuth 구성의 세션 옵션에 대한 기본값을 재정의합니다. 자세한 내용은 세션 옵션 구성을 참조하십시오.

openshift_master_session_max_seconds

openshift_master_session_auth_secrets

openshift_master_session_encryption_secrets

openshift_master_image_policy_config

마스터 구성에서 imagePolicyConfig 를 설정합니다. 자세한 내용은 이미지 구성을 참조하십시오.

openshift_router_selector

라우터 Pod를 자동으로 배포하는 기본 노드 선택기입니다. 자세한 내용은 노드 호스트 레이블 구성을 참조하십시오.

openshift_registry_selector

레지스트리 Pod를 자동으로 배포하는 기본 노드 선택기입니다. 자세한 내용은 노드 호스트 레이블 구성을 참조하십시오.

openshift_template_service_broker_namespaces

이 변수는 브로커가 제공할 템플릿을 하나 이상 지정하여 템플릿 서비스 브로커를 활성화합니다.

openshift_master_bootstrap_auto_approve

이 변수를 사용하면 부트 스트랩 자동 승인을 활성화하여 부트스트랩 인증 정보를 제공하면 노드가 클러스터에 자동으로 참여할 수 있습니다. AWS(Amazon Web Services) 클러스터에서 클러스터 자동 스케일링 을 활성화하는 경우 true 로 설정합니다. 기본값은 false입니다.

ansible_service_broker_node_selector

Ansible 서비스 브로커 포드, 기본값 {"node-role.kubernetes.io/infra":"true"} 를 자동으로 배포하는 기본 노드 선택기입니다. 자세한 내용은 노드 호스트 레이블 구성을 참조하십시오.

osm_default_node_selector

이 변수는 마스터 구성 파일의 projectConfig.defaultNodeSelector 필드에 정의된 Pod를 배치할 때 프로젝트가 기본적으로 사용할 노드 선택기를 재정의합니다. 정의되지 않은 경우 기본값은 node-role.kubernetes.io/compute=true 입니다.

openshift_docker_additional_registries

OpenShift Container Platform은 지정된 추가 레지스트리 또는 레지스트리를 docker 구성에 추가합니다. 다음은 검색할 레지스트리입니다. 레지스트리에서 80 이외의 포트에 액세스해야 하는 경우 < address>:<port > 형식으로 필요한 포트 번호를 포함합니다.

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

openshift_docker_additional_registries=example.com:443
참고

대체 레지스트리를 사용하도록 클러스터를 구성해야 하는 경우 openshift_docker_additional_registries 대신 oreg_url 을 설정합니다.

openshift_docker_insecure_registries

OpenShift Container Platform은 지정된 추가 비보안 레지스트리 또는 레지스트리를 docker 구성에 추가합니다. 이러한 레지스트리의 경우 SSL(Secure Sockets Layer)이 확인되지 않습니다. 호스트 이름 또는 호스트의 IP 주소로 설정할 수 있습니다. 0.0.0.0/0 은 IP 주소에 유효한 설정이 아닙니다.

openshift_docker_blocked_registries

OpenShift Container Platform은 지정된 차단된 레지스트리 또는 레지스트리를 docker 구성에 추가합니다. 나열된 레지스트리를 차단합니다. 이 값을 다른 변수에 없는 모든 블록으로 설정합니다.

openshift_docker_ent_reg

openshift_deployment_typeopenshift-enterprise 로 설정된 경우 컨테이너 런타임에서 신뢰하는 추가 레지스트리입니다. 기본값은 registry.redhat.io 입니다. openshift_docker_ent_reg='' 를 설정하면 docker 구성에 registry.redhat.io 가 추가되지 않습니다.

openshift_metrics_hawkular_hostname

이 변수는 클러스터 메트릭의 마스터 구성에서 metricsPublicURL 을 재정의하여 지표 콘솔과 통합할 호스트 이름을 설정합니다. 이 변수를 변경하는 경우 라우터를 통해 호스트 이름에 액세스할 수 있는지 확인합니다.

openshift_clusterid

이 변수는 AWS 가용 영역에 고유한 클러스터 식별자입니다. 이를 통해 여러 영역 또는 여러 클러스터가 있는 AWS(Amazon Web Services)의 잠재적인 문제가 발생하지 않습니다. 자세한 내용은 AWS 라벨 을 참조하십시오.

openshift_encryption_config

이 변수를 사용하여 데이터 저장소 계층 암호화를 구성합니다.

openshift_image_tag

이 변수를 사용하여 설치하거나 구성할 컨테이너 이미지 태그를 지정합니다.

openshift_pkg_version

이 변수를 사용하여 설치 또는 구성할 RPM 버전을 지정합니다.

주의

클러스터가 설정된 후 openshift_image_tag 또는 openshift_pkg_version 변수를 수정하면 업그레이드가 트리거될 수 있으므로 다운 타임이 발생할 수 있습니다.

  • openshift_image_tag 가 설정되면 다른 버전이 설치된 경우에도 시스템 컨테이너 환경의 모든 호스트에 해당 값이 사용됩니다. If
  • openshift_pkg_version 이 설정되고, 다른 버전이 설치된 경우에도 RPM 기반 환경의 모든 호스트에 값이 사용됩니다.
표 4.2. 네트워킹 변수
변수목적

openshift_master_default_subdomain

이 변수는 노출된 경로에 사용할 기본 하위 도메인을 재정의합니다. 이 변수의 값은 소문자 영숫자 또는 대시(-)로 구성되어야 합니다. 알파벳 문자로 시작해야 하며 영숫자로 끝나야 합니다.

os_sdn_network_plugin_name

이 변수는 포드 네트워크에 사용할 OpenShift SDN 플러그인 을 구성합니다. 기본값은 표준 SDN 플러그인의 경우 redhat/openshift-ovs-subnet 입니다. 다중 테넌트 SDN 플러그인을 사용하도록 변수를 redhat/openshift-ovs-multitenant 로 설정합니다.

osm_cluster_network_cidr

이 변수는 SDN 클러스터 네트워크 CIDR 블록을 재정의합니다. 이는 포드 IP가 할당되는 네트워크입니다. 인프라의 기존 네트워크 블록과 충돌하지 않는 개인 블록을 지정하고 해당 Pod, 노드 또는 마스터에 액세스해야 할 수 있습니다. 기본값은 10.128.0.0/14 이며 배포 후에는 임의로 다시 구성할 수 없지만 SDN 마스터 구성에서 특정 변경을 수행할 수 있습니다.

openshift_portal_net

이 변수는 OpenShift Container Platform SDN 에서 서비스를 생성할 서브넷을 구성합니다. Pod, 노드 또는 마스터에 액세스해야 할 수 있는 기존 네트워크 블록과 충돌하지 않는 개인 블록을 지정합니다. 기본값은 172.30.0.0/16 이며 배포 후에는 다시 구성할 수 없습니다. 기본값에서 변경하는 경우 docker0 네트워크 브리지에서 기본적으로 사용하는 172.17.0.0/16 을 방지하거나 docker0 네트워크를 수정합니다.

osm_host_subnet_length

이 변수는 OpenShift Container Platform SDN 에서 포드 IP에 할당된 호스트당 크기별 크기를 지정합니다. 기본값은 9 입니다. 예를 들어 기본 10.128.0.0/14 클러스터 네트워크가 지정되면 10.128.0.0/23, 10.128.4.0/23, 10.128.4.0/23 등이 할당됩니다. 이는 배포 후에는 다시 구성할 수 없습니다.

openshift_node_proxy_mode

이 변수는 사용할 서비스 프록시 모드 (기본, pure- iptables 구현 또는 사용자 공간 프록시의 경우 userspace )를 지정합니다.

openshift_use_flannel

이 변수는 flannel 을 기본 SDN 대신 대체 네트워킹 계층으로 활성화합니다. flannel 을 활성화하는 경우 openshift_use_openshift_sdn 변수를 사용하여 기본 SDN을 비활성화합니다. 자세한 내용은 Flannel 사용을 참조하십시오.

openshift_use_openshift_sdn

OpenShift SDN 플러그인을 비활성화하려면 false 로 설정합니다.

openshift_sdn_vxlan_port

이 변수는 클러스터 네트워크의 6443 포트 번호를 설정합니다. 기본값은 4789 입니다. 자세한 내용은 클러스터 네트워크의 VXLAN PORT 변경을 참조하십시오.

openshift_node_sdn_mtu

이 변수는 OpenShift SDN에 사용할 MTU 크기를 지정합니다. 값은 노드의 기본 네트워크 인터페이스의 MTU보다 50 바이트 작아야 합니다. 예를 들어 기본 네트워크 인터페이스에 1500 의 MTU가 있는 경우 이 값은 1450 입니다. 기본값은 1450 입니다.

4.3. 배포 유형 구성

설치 프로그램에서 사용하는 플레이북 및 역할 전체에서 사용되는 다양한 기본값은 배포 유형 구성(일반적으로 Ansible 인벤토리 파일에 정의되어 있음)을 기반으로 합니다.

인벤토리 파일의 [OSEv3:vars] 섹션의 openshift_deployment_type 매개변수가 openshift-enterprise 로 설정되어 OpenShift Container Platform 변형을 설치합니다.

[OSEv3:vars]
openshift_deployment_type=openshift-enterprise

4.4. 호스트 변수 구성

Ansible 설치 중 호스트에 환경 변수를 할당하려면 [masters] 또는 [nodes] 섹션의 호스트 항목 뒤에 /etc/ansible/hosts 파일에서 환경 변수를 설정합니다. 예를 들면 다음과 같습니다.

[masters]
ec2-52-6-179-239.compute-1.amazonaws.com openshift_public_hostname=ose3-master.public.example.com

다음 표에서는 개별 호스트 항목에 할당할 수 있는 Ansible 설치 프로그램에서 사용할 수 있는 변수를 설명합니다.

표 4.3. 호스트 변수
변수목적

openshift_public_hostname

이 변수는 시스템의 공용 호스트 이름을 재정의합니다. 이 방법은 클라우드 설치 또는 NAT(네트워크 주소 변환)를 사용하는 네트워크의 호스트에 사용합니다.

openshift_public_ip

이 변수는 시스템의 공용 IP 주소를 재정의합니다. 이 방법은 클라우드 설치 또는 NAT(네트워크 주소 변환)를 사용하는 네트워크의 호스트에 사용합니다.

openshift_node_labels

이 변수는 더 이상 사용되지 않습니다. 노드 레이블 설정의 현재 방법에 대한 노드 그룹 정의 및 호스트 매핑 을 참조하십시오.

openshift_docker_options

이 변수는 컨테이너 로그 관리에 사용되는 옵션과 같이 /etc/sysconfig/docker 에서 추가 docker 옵션을 구성합니다. json-file 을 사용하는 것이 좋습니다.

다음 예제에서는 Docker가 3MB 로그 파일 및 서명 확인 간에 순환되는 json-file 로그 드라이버를 사용하도록 Docker의 구성을 보여줍니다. 추가 옵션을 제공할 때 단일 따옴표 형식을 유지 관리해야 합니다.

OPTIONS=' --selinux-enabled --log-opt  max-size=1M --log-opt max-file=3 --insecure-registry 172.30.0.0/16 --log-driver=json-file --signature-verification=false'

openshift_schedulable

이 변수는 호스트가 스케줄링 가능한 노드로 표시되는지 여부를 구성합니다. 즉, 새 Pod 배치에 사용할 수 있습니다. 마스터 의 Schedulability on Masters를 참조하십시오.

openshift_node_problem_detector_install

이 변수는 Node Problem Detector 를 활성화하는 데 사용됩니다. false 로 설정하면 Node Problem Detector가 설치되거나 시작되지 않습니다.

4.5. 노드 그룹 및 호스트 매핑 정의

노드 구성은 마스터에서 부트 스트랩 됩니다. 노드를 부팅하고 서비스를 시작하면 노드는 클러스터에 참여하기 전에 kubeconfig 및 기타 노드 구성 파일이 있는지 확인합니다. 노드가 마스터에서 구성을 가져오지 않으면 클러스터에 참여합니다.

이 프로세스에서는 관리자가 각 노드 호스트에서 고유하게 노드 구성을 수동으로 유지 관리해야 합니다. 대신 마스터에서 가져온 ConfigMaps에서 노드 호스트의 /etc/origin/node/node-config.yaml 파일의 내용을 제공합니다.

4.5.1. 노드 ConfigMaps

노드 구성을 정의하는 Configmaps는 openshift-node 프로젝트에서 사용할 수 있어야 합니다. ConfigMaps는 이제 노드 레이블에 대한 권한 있는 정의이기도 합니다. 이전 openshift_node_labels 값은 효과적으로 무시됩니다.

클러스터 설치 중에 기본적으로 설치 프로그램은 다음과 같은 기본 ConfigMap을 생성합니다.

  • node-config-master
  • node-config-infra
  • node-config-compute

또한 다음 ConfigMap이 생성되어 여러 역할에 노드를 레이블을 지정합니다.

  • node-config-all-in-one
  • node-config-master-infra

다음 ConfigMap은 각 기존 기본 노드 그룹의 CRI-O 변형입니다.

  • node-config-master-crio
  • node-config-infra-crio
  • node-config-compute-crio
  • node-config-all-in-one-crio
  • node-config-master-infra-crio
중요

노드 호스트의 /etc/origin/node/node-config.yaml 파일을 수정할 수 없습니다. 노드가 사용하는 ConfigMap에 정의된 구성으로 변경 사항을 덮어씁니다.

4.5.2. 노드 그룹 정의

최신 openshift-ansible 패키지를 설치한 후 /usr/share/ansible/openshift-ansible/openshift_facts/defaults/main.yml 파일에서 YAML 형식으로 노드 그룹 정의의 기본 세트를 볼 수 있습니다.

openshift_node_groups:
  - name: node-config-master 1
    labels:
      - 'node-role.kubernetes.io/master=true' 2
    edits: [] 3
  - name: node-config-infra
    labels:
      - 'node-role.kubernetes.io/infra=true'
    edits: []
  - name: node-config-compute
    labels:
      - 'node-role.kubernetes.io/compute=true'
    edits: []
  - name: node-config-master-infra
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true'
    edits: []
  - name: node-config-all-in-one
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true,node-role.kubernetes.io/compute=true'
    edits: []
1
노드 그룹 이름.
2
노드 그룹과 연결된 노드 라벨 목록입니다. 자세한 내용은 노드 호스트 레이블 을 참조하십시오.
3
노드 그룹의 구성에 대한 모든 편집

인벤토리 파일의 [OSEv3:vars] 그룹에 openshift_node_groups 변수를 설정하지 않으면 이러한 기본값이 사용됩니다. 그러나 사용자 지정 노드 그룹을 설정하려면 인벤토리 파일에 계획된 모든 노드 그룹을 포함하여 전체 openshift_node_groups 구조를 정의해야 합니다.

openshift_node_groups 값은 기본값과 병합되지 않으며 YAML 정의를 Python 사전으로 변환해야 합니다. 그런 다음 edits 필드를 사용하여 키-값 쌍을 지정하여 노드 구성 변수를 수정할 수 있습니다.

참고

구성 가능한 노드 변수에 대한 참조는 마스터 및 노드 구성 파일을 참조하십시오.

예를 들어 인벤토리 파일의 다음 항목은 node-config-master,node-config-infra, node-config-compute 라는 그룹을 정의합니다.

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}]

인벤토리 파일의 다음 항목은 node-config-master,node-config-infra, node-config-compute 및node-config- compute -storage 를 사용하여 새 노드 그룹 이름을 정의할 수도 있습니다.

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}, {'name': 'node-config-compute-storage', 'labels': ['node-role.kubernetes.io/compute-storage=true']}]

인벤토리 파일에서 항목을 설정하면 노드 그룹의 ConfigMap을 편집할 수도 있습니다.

  • node-config-compute 를 수정하여 kubeletArguments.pods-per-core20 으로 설정하는 것과 같은 목록을 사용할 수 있습니다.
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]
  • 목록을 사용하여 kubelet 에 두 개의 매개변수를 추가하도록 node-config-compute 그룹 수정과 같은 여러 키 값 쌍을 수정할 수 있습니다.
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.experimental-allocatable-ignore-eviction','value': ['true']}, {'key': 'kubeletArguments.eviction-hard', 'value': ['memory.available<1Ki']}]}]
  • node-config-compute 그룹 수정과 같이 사전을 값으로 사용하여 perFSGroup512Mi 로 설정할 수도 있습니다.
openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'volumeConfig.localQuota','value': {'perFSGroup':'512Mi'}}]}]

openshift_node_group.yml 플레이북이 실행될 때마다 edits 필드에 정의된 변경 사항은 관련 ConfigMap(이 예제의node-config-compute )을 업데이트합니다. 그러면 결국 호스트의 구성 파일에 영향을 미칩니다.

참고

openshift_node_group.yaml 플레이북을 실행하면 새 노드만 업데이트됩니다. 클러스터의 기존 노드를 업데이트하려면 실행할 수 없습니다.

4.5.3. 노드 그룹에 호스트 매핑

어떤 노드 호스트에 사용할 ConfigMap을 매핑하려면 인벤토리의 [nodes] 그룹에 정의된 모든 호스트를 openshift_node_group_name 변수를 사용하여 노드 그룹에 할당해야 합니다.

중요

기본 노드 그룹 정의 및 ConfigMaps 사용 여부에 관계없이 호스트당 openshift_node_group_name 을 노드 그룹으로 설정해야 합니다.

openshift_node_group_name 값은 각 노드를 구성하는 ConfigMap을 선택하는 데 사용됩니다. 예를 들면 다음과 같습니다.

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'

다른 사용자 정의 ConfigMap이 openshift_node_groups 에 정의된 경우 사용할 수도 있습니다. Exmaple의 경우:

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
gluster[1:6].example.com openshift_node_group_name='node-config-compute-storage'

4.5.4. 노드 호스트 레이블

클러스터 설치 중에 노드 호스트에 레이블 을 할당할 수 있습니다. 이러한 라벨을 사용하여 스케줄러 를 사용하여 노드에 Pod의 배치를 결정할 수 있습니다.

노드 호스트에 할당되는 기본 라벨을 수정하려면 고유한 사용자 지정 노드 그룹을 생성해야 합니다. 라벨을 변경하기 위해 openshift_node_labels 변수를 더 이상 설정할 수 없습니다. 기본 노드 그룹을 수정하려면 노드 그룹 정의를 참조하십시오.

node-role.kubernetes.io/infra=true 이외의 (이 그룹을 사용하는 호스트도 전용 인프라 노드 구성으로 참조되고 Dedicated Infrastructure 노드 구성에서도 설명됨) 실제 라벨 이름과 값은 임의로 지정되지만 클러스터의 요구 사항에 맞게 할당할 수 있습니다.

4.5.4.1. 마스터에서 Pod 조정 가능

설치 프로세스 중에 마스터로 지정하는 모든 호스트를 노드로 구성합니다. 이렇게 하면 마스터가 OpenShift SDN 의 일부로 구성됩니다. 마스터 호스트의 항목을 [nodes] 섹션에 추가해야 합니다.

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'

설치 후 호스트의 조정 가능성을 변경하려면 노드 표시를 Unschedulable 또는 Schedulable 을 참조하십시오.

4.5.4.2. 노드에서 Pod 조정 가능

마스터는 기본적으로 스케줄링 가능한 노드로 표시되므로 클러스터 설치 중에 기본 노드 선택기가 기본적으로 설정됩니다. 기본 노드 선택기는 마스터 구성 파일의 projectConfig.defaultNodeSelector 필드에 정의되어 Pod를 배치할 때 기본적으로 사용할 노드 프로젝트를 결정합니다. osm_default_node_selector 변수를 사용하여 재정의하지 않는 한 node-role.kubernetes.io/compute=true 로 설정됩니다.

중요

설치 중에 node-role.kubernetes.io/compute=true 의 기본 노드 선택기를 허용하는 경우 전용 인프라 노드가 클러스터에 정의되어 있지 않은지 확인합니다. 이 시나리오에서는 프로젝트에 Pod를 예약할 때 node-role.kubernetes.io/compute=true 라벨이 있는 노드가 없기 때문에 애플리케이션 포드를 배포할 수 없습니다.

필요한 경우 이 설정 후 설치 후 조정하기 위한 단계는 클러스터 전체 기본 노드 선택기 설정을 참조하십시오.

4.5.4.3. Dedicated Infrastructure 노드 구성

레지스트리 및 라우터 Pod가 사용자 애플리케이션에 사용되는 Pod와 별도로 실행할 수 있는 전용 인프라 노드를 유지 관리하는 프로덕션 환경에 사용하는 것이 좋습니다.

openshift_router_selectoropenshift_registry_selector Ansible 설정은 레지스트리 및 라우터 Pod를 배치할 때 사용되는 라벨 선택기를 결정합니다. 기본적으로 node-role.kubernetes.io/infra=true 로 설정됩니다.

# default selectors for router and registry services
# openshift_router_selector='node-role.kubernetes.io/infra=true'
# openshift_registry_selector='node-role.kubernetes.io/infra=true'

레지스트리 및 라우터는 node-role.kubernetes.io/infra=true 라벨이 있는 노드 호스트에서만 실행할 수 있으며 이는 전용 인프라 노드로 간주됩니다. OpenShift Container Platform 환경에서 하나 이상의 노드 호스트에 node-role.kubernetes.io/infra=true 레이블이 있는지 확인합니다. 이 레이블을 설정하는 기본 node-config-infra 를 사용할 수 있습니다.

[nodes]
infra-node1.example.com openshift_node_group_name='node-config-infra'
중요

선택기 설정과 일치하는 노드가 [nodes] 섹션에 없는 경우 기본 라우터 및 레지스트리는 Pending 상태로 실패했습니다.

OpenShift Container Platform을 사용하여 레지스트리 및 라우터를 관리하지 않으려면 다음 Ansible 설정을 구성합니다.

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

기본 registry.redhat.io 이외의 이미지 레지스트리를 사용하는 경우 /etc/ansible/hosts 파일에 레지스트리를 지정해야 합니다.

마스터의 Schedulability 구성에 설명된 대로 마스터 호스트는 기본적으로 예약 가능으로 표시됩니다. master 호스트에 node-role.kubernetes.io/infra=true 로 레이블을 지정하고 다른 전용 인프라 노드가 없는 경우 마스터 호스트도 예약 가능으로 표시되어야 합니다. 그러지 않으면 레지스트리 및 라우터 Pod를 어디에도 배치할 수 없습니다.

기본 node-config-master-infra 노드 그룹을 사용하여 이를 수행할 수 있습니다.

[nodes]
master.example.com openshift_node_group_name='node-config-master-infra'

4.6. 프로젝트 매개변수 구성

기본 프로젝트 설정을 구성하려면 /etc/ansible/hosts 파일에서 다음 변수를 구성합니다.

표 4.4. 프로젝트 매개변수
매개변수설명유형기본값

osm_project_request_message

projectrequest API 끝점을 통해 프로젝트를 요청할 수 없는 경우 사용자에게 제공되는 문자열입니다.

문자열

null

osm_project_request_template

projectrequest 에 대한 응답으로 프로젝트를 생성하는 데 사용할 템플릿입니다. 값을 지정하지 않으면 기본 템플릿이 사용됩니다.

< namespace>/<template>형식이 있는 문자열

null

osm_mcs_allocator_range

네임스페이스에 할당할 MCS 카테고리 범위를 정의합니다. 이 값이 시작된 후 변경되면 새 프로젝트에 이미 다른 프로젝트에 할당된 라벨이 표시될 수 있습니다. 접두사는 사용자, 역할 및 유형을 포함하여 모든 유효한 SELinux 용어 세트일 수 있습니다. 그러나 접두사를 기본값으로 남겨 두면 서버에서 자동으로 설정할 수 있습니다. 예를 들어 s0:/2 는 s0:c0,c0에서 s0:c511,c511에 레이블을 할당하고 s0:/2,512 는 s0:c0,c0,c0,c0의 레이블을 s0:c511,c511,51111로 할당합니다.

< prefix>/<numberOfLabels>[,<maxCategory> 형식으로 된문자열

s0:/2

osm_mcs_labels_per_project

프로젝트당 예약할 레이블 수를 정의합니다.

정수

5

osm_uid_allocator_range

프로젝트에 자동으로 할당된 총 Unix 사용자 ID(UID) 세트와 각 네임스페이스가 가져오는 블록의 크기를 정의합니다. 예를 들어 1000-1999/10 은 네임스페이스당 10개의 UID를 할당하고 공간이 부족하기 전에 최대 100개의 블록을 할당할 수 있습니다. 기본값은 사용자 네임스페이스가 시작될 때 컨테이너 이미지에 대해 예상되는 범위 크기입니다.

< block_range>/<number_of_UIDs형식의 문자열

1000000000-1999999999/10000

4.7. 마스터 API 포트 구성

마스터 API에서 사용하는 기본 포트를 구성하려면 /etc/ansible/hosts 파일에서 다음 변수를 구성합니다.

표 4.5. 마스터 API 포트
변수목적

openshift_master_api_port

이 변수는 OpenShift Container Platform API에 액세스할 포트 번호를 설정합니다.

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

openshift_master_api_port=3443

웹 콘솔 포트 설정(openshift_master_console_port)은 API 서버 포트(openshift_master_api_port)와 일치해야 합니다.

4.8. 클러스터 사전 설치 확인 구성

사전 설치 확인은 openshift_health_checker Ansible 역할의 일부로 실행되는 일련의 진단 작업입니다. OpenShift Container Platform을 설치하기 전에 Ansible을 실행하고, 필요한 인벤토리 값이 설정되어 있는지 확인하고, 성공적인 설치를 방지하거나 방해할 수 있는 호스트의 잠재적인 문제를 식별합니다.

다음 표에서는 OpenShift Container Platform의 모든 Ansible을 설치하기 전에 실행할 사용 가능한 사전 설치 검사를 설명합니다.

표 4.6. 사전 설치 확인
이름 확인목적

memory_availability

이를 통해 호스트에 OpenShift Container Platform의 특정 배포에 권장되는 메모리 양이 있는지 확인합니다. 기본값은 최신 설치 문서에서 가져온 것입니다. 최소 메모리 요구 사항에 대한 사용자 정의 값은 인벤토리 파일에서 openshift_check_min_host_memory_gb 클러스터 변수를 설정하여 설정할 수 있습니다.

disk_availability

이 검사는 etcd, 마스터 및 노드 호스트에서만 실행됩니다. 이를 통해 OpenShift Container Platform 설치의 마운트 경로에 디스크 공간이 충분히 남아 있습니다. 권장 디스크 값은 최신 설치 문서에서 가져옵니다. 최소 디스크 공간 요구 사항에 대한 사용자 정의 값은 인벤토리 파일에서 openshift_check_min_host_disk_gb 클러스터 변수를 설정하여 설정할 수 있습니다.

docker_storage

docker 데몬(노드 및 시스템 컨테이너 설치)에 의존하는 호스트에서만 실행됩니다. docker 의 총 사용량이 사용자 정의 제한을 초과하지 않는지 확인합니다. 사용자 정의 제한이 설정되지 않은 경우 docker 의 최대 사용량 임계값은 사용 가능한 총 크기의 90%입니다. 총 백분율 사용량에 대한 임계값 제한은 인벤토리 파일의 변수로 설정할 수 있습니다. max_thinpool_data_usage_percent=90. 인벤토리 파일에서 max_thinpool_data_usage_percent 클러스터 변수를 설정하여 최대 thinpool 사용량에 대한 사용자 정의 제한을 설정할 수 있습니다.

docker_storage_driver

Docker 데몬이 OpenShift Container Platform에서 지원하는 스토리지 드라이버를 사용하고 있는지 확인합니다. devicemapper 스토리지 드라이버를 사용하는 경우 추가 검사를 통해 루프백 장치가 사용되지 않습니다. 자세한 내용은 Docker의 장치 매퍼 스토리지 드라이버 사용 가이드를 참조하십시오.

docker_image_availability

OpenShift Container Platform 설치에 필요한 이미지를 로컬 또는 호스트 시스템에 구성된 컨테이너 이미지 레지스트리 중 하나 이상에서 사용할 수 있는지 확인하려고 합니다.

package_version

yum기반 시스템에서 필요한 OpenShift Container Platform 패키지의 여러 릴리스를 사용할 수 있는지 결정합니다. OpenShift의 엔터프라이즈 설치 중에 사용할 수 있는 패키지의 여러 릴리스가 있으면 다른 릴리스에 대해 여러 yum 리포지토리가 활성화되어 있어서 설치 문제가 발생할 수 있습니다.

package_availability

OpenShift Container Platform의 RPM 설치 전에 실행됩니다. 현재 설치에 필요한 RPM 패키지를 사용할 수 있는지 확인합니다.

package_update

호스트에서 yum 업데이트 또는 패키지 설치를 실제로 수행하거나 yum 을 실행하지 않고 성공적으로 설치할지 여부를 확인합니다.

특정 사전 설치 검사를 비활성화하려면 인벤토리 파일에서 쉼표로 구분된 확인 이름 목록을 사용하여 openshift_disable_check 변수를 포함합니다. 예를 들면 다음과 같습니다.

openshift_disable_check=memory_availability,disk_availability
참고

기존 클러스터에서 진단을 위해 실행되는 유사한 상태 점검 세트는 Ansible 기반 상태 점검 에서 확인할 수 있습니다. 인증서 만료 확인은 인증서 재배포 에서 확인할 수 있습니다.

4.9. 레지스트리 위치 구성

registry.redhat.io 에서 기본 레지스트리를 사용하는 경우 다음 변수를 설정해야 합니다.

oreg_url=registry.redhat.io/openshift3/ose-${component}:${version}
oreg_auth_user="<user>"
oreg_auth_password="<password>"

레지스트리 액세스 토큰 설정에 대한 자세한 내용은 Red Hat Container Registry Authentication 을 참조하십시오.

registry.redhat.io 에서 기본값 이외의 이미지 레지스트리를 사용하는 경우 /etc/ansible/hosts 파일에 레지스트리를 지정합니다.

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true
표 4.7. 레지스트리 변수
변수목적

oreg_url

대체 이미지 위치로 설정합니다. registry.redhat.io 에서 기본 레지스트리를 사용하지 않는 경우 필수 항목입니다. 기본 구성 요소는 oreg_url 값에서 이미지 접두사 및 버전을 상속합니다. 기본 레지스트리와 인증이 필요한 레지스트리의 경우 oreg_auth_ user 및 oreg_auth _password 를 지정해야 합니다.

openshift_examples_modify_imagestreams

기본값이 아닌 레지스트리를 가리키는 경우 true 로 설정합니다. 이미지 스트림 위치를 oreg_url 값으로 수정합니다.

oreg_auth_user

oreg_url 이 인증이 필요한 레지스트리를 가리키는 경우 oreg_auth_user 변수를 사용하여 사용자 이름을 제공합니다. 또한 oreg_auth_password 매개변수 값으로 암호를 제공해야 합니다. 기본 레지스트리를 사용하는 경우 registry.redhat.io 에 액세스할 수 있는 사용자를 지정합니다.

oreg_auth_password

oreg_url 이 인증이 필요한 레지스트리를 가리키는 경우 oreg_auth_password 변수를 사용하여 암호를 제공합니다. 또한 사용자 이름을 oreg_auth_user 매개변수 값으로 제공해야 합니다. 기본 레지스트리를 사용하는 경우 해당 사용자의 암호 또는 토큰을 지정합니다.

참고

기본 레지스트리에는 인증 토큰이 필요합니다. 자세한 내용은 Red Hat Registry 액세스 및 구성을참조하십시오.

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

oreg_url=example.com/openshift3/ose-${component}:${version}
oreg_auth_user=${user_name}
oreg_auth_password=${password}
openshift_examples_modify_imagestreams=true

4.10. 레지스트리 경로 구성

사용자가 OpenShift Container Platform 클러스터 외부에서 내부 컨테이너 이미지 레지스트리로 이미지를 푸시하고 가져올 수 있도록 하려면 /etc/ansible/hosts 파일에서 레지스트리 경로를 구성합니다. 기본적으로 레지스트리 경로는 docker-registry-default.router.default.svc.cluster.local 입니다.

표 4.8. 레지스트리 경로 변수
변수목적

openshift_hosted_registry_routehost

원하는 레지스트리 경로의 값으로 설정합니다. 경로에는 기본 애플리케이션 하위 도메인 와일드카드 값으로 설정한 통신 또는 하위 도메인을 관리하는 인프라 노드로 확인되는 이름이 포함됩니다. 예를 들어 openshift_master_default_subdomain 매개변수를 apps.example.com 으로 설정하고 .apps.example.com 이 인프라 노드 또는 로드 밸런서로 해석되는 경우 registry.apps.example.com 을 레지스트리 경로로 사용할 수 있습니다.

openshift_hosted_registry_routecertificates

레지스트리 인증서의 경로를 설정합니다. 인증서 위치에 대한 값을 제공하지 않으면 인증서가 생성됩니다. 다음 인증서의 위치를 정의할 수 있습니다.

  • certfile
  • keyfile
  • cafile

openshift_hosted_registry_routetermination

다음 값 중 하나로 설정합니다.

  • 에지 라우터에서 암호화를 종료하고 대상에서 제공하는 새 인증서로 재암호화 하도록 설정합니다.
  • 대상에서 암호화를 종료하려면 passthrough 로 설정합니다. 대상은 트래픽의 암호를 해독합니다.

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

openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"

4.11. 라우터 Sharding 구성

올바른 데이터를 인벤토리에 제공하여 라우터 분할 지원을 사용할 수 있습니다. 변수 openshift_hosted_routers 에는 목록 형식으로 된 데이터가 들어 있습니다. 데이터가 전달되지 않으면 기본 라우터가 생성됩니다. 라우터 샤딩의 다양한 조합이 있습니다. 다음 예제에서는 별도의 노드에서 라우터를 지원합니다.

openshift_hosted_routers=[{'name': 'router1', 'certificate': {'certfile': '/path/to/certificate/abc.crt',
'keyfile': '/path/to/certificate/abc.key', 'cafile':
'/path/to/certificate/ca.crt'}, 'replicas': 1, 'serviceaccount': 'router',
'namespace': 'default', 'stats_port': 1936, 'edits': [], 'images':
'openshift3/ose-${component}:${version}', 'selector': 'type=router1', 'ports':
['80:80', '443:443']},

{'name': 'router2', 'certificate': {'certfile': '/path/to/certificate/xyz.crt',
'keyfile': '/path/to/certificate/xyz.key', 'cafile':
'/path/to/certificate/ca.crt'}, 'replicas': 1, 'serviceaccount': 'router',
'namespace': 'default', 'stats_port': 1936, 'edits': [{'action': 'append',
'key': 'spec.template.spec.containers[0].env', 'value': {'name': 'ROUTE_LABELS',
'value': 'route=external'}}], 'images':
'openshift3/ose-${component}:${version}', 'selector': 'type=router2', 'ports':
['80:80', '443:443']}]

4.12. Red Hat Gluster Storage 영구 스토리지 구성

OpenShift Container Platform에 영구 스토리지 및 동적 프로비저닝을 제공하도록 Red Hat Gluster Storage를 구성할 수 있습니다. 자체 노드(독립모드)에서 컨테이너화된 OpenShift Container Platform(연동모드)과 컨테이너화되지 않은 경우 모두 사용할 수 있습니다.

OpenShift Container Platform 클러스터와 상호 작용하는 변수를 사용하여 Red Hat Gluster Storage 클러스터를 구성합니다. [OSEv3:vars] 그룹에 정의하는 변수는 호스트 변수, 역할 변수, 이미지 이름 및 버전 태그 변수를 포함합니다.

glusterfs_devices 호스트 변수를 사용하여 Red Hat Gluster Storage 클러스터를 관리할 블록 장치 목록을 정의합니다. 구성의 각 호스트에는 하나 이상의 glusterfs_devices 변수가 있어야 하며 모든 구성에는 파티션이나 LVM PV가 없는 베어 장치가 하나 이상 있어야 합니다.

역할 변수는 Red Hat Gluster Storage 클러스터를 새 또는 기존 OpenShift Container Platform 클러스터와의 통합을 제어합니다. 통합 Docker 레지스트리의 스토리지로 사용하도록 별도의 Red Hat Gluster Storage 클러스터를 구성할 수 있도록 각 변수에 해당 변수가 있는 여러 역할 변수를 정의할 수 있습니다.

이미지 이름과 버전 태그 변수를 정의하여 중단 후 OpenShift Container Platform pod가 업그레이드되지 않아 다른 OpenShift Container Platform 버전이 있는 클러스터가 발생할 수 있습니다. 이러한 변수를 정의하여 컨테이너화된 모든 구성 요소에 대한 이미지 이름 및 버전 태그를 지정할 수도 있습니다.

아래 항목을 포함한 추가 정보 및 예제는 Red Hat Gluster Storage를 사용하여 영구 스토리지 에서 확인할 수 있습니다.

4.12.1. 통합 모드 구성

중요

특정 호스트 준비 및 사전 요구 사항은 통합 모드 고려 사항을 참조하십시오.

  1. 인벤토리 파일에서 [OSEv3:vars] 섹션에 다음 변수를 추가하고 구성에 필요한 대로 조정합니다.

    [OSEv3:vars]
    ...
    openshift_storage_glusterfs_namespace=app-storage
    openshift_storage_glusterfs_storageclass=true
    openshift_storage_glusterfs_storageclass_default=false
    openshift_storage_glusterfs_block_deploy=true
    openshift_storage_glusterfs_block_host_vol_size=100
    openshift_storage_glusterfs_block_storageclass=true
    openshift_storage_glusterfs_block_storageclass_default=false
  2. [OSEv3:children] 섹션에 glusterfs 를 추가하여 [glusterfs] 그룹을 활성화합니다.

    [OSEv3:children]
    masters
    nodes
    glusterfs
  3. GlusterFS 스토리지를 호스팅할 각 스토리지 노드에 대해 [glusterfs] 섹션을 추가합니다. 각 노드에 대해 glusterfs_devices 를 GlusterFS 클러스터의 일부로 완전히 관리할 원시 블록 장치 목록으로 설정합니다. 나열된 장치가 하나 이상 있어야 합니다. 파티션이나 LVM PV가 없는 각 장치는 베어여야 합니다. 변수를 지정하면 폼을 사용합니다.

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

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

    [glusterfs]
    node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
  4. [glusterfs] 아래에 나열된 호스트를 [nodes] 그룹에 추가합니다.

    [nodes]
    ...
    node11.example.com openshift_node_group_name="node-config-compute"
    node12.example.com openshift_node_group_name="node-config-compute"
    node13.example.com openshift_node_group_name="node-config-compute"

배포가 성공하려면 유효한 이미지 태그가 필요합니다. & lt;tag >를 인벤토리 파일의 다음 변수에 대한 상호 운용성 매트릭스 에 설명된 대로 OpenShift Container Platform 3.11과 호환되는 Red Hat Gluster Storage 버전으로 바꿉니다.

  • openshift_storage_glusterfs_image=registry.redhat.io/rhgs3/rhgs-server-rhel7:<tag>
  • openshift_storage_glusterfs_block_image=registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:<tag>
  • openshift_storage_glusterfs_s3_image=registry.redhat.io/rhgs3/rhgs-s3-server-rhel7:<tag>
  • openshift_storage_glusterfs_heketi_image=registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:<tag>
  • openshift_storage_glusterfs_registry_image=registry.redhat.io/rhgs3/rhgs-server-rhel7:<tag>
  • openshift_storage_glusterfs_block_registry_image=registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:<tag>
  • openshift_storage_glusterfs_s3_registry_image=registry.redhat.io/rhgs3/rhgs-s3-server-rhel7:<tag>
  • openshift_storage_glusterfs_heketi_registry_image=registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:<tag>

4.12.2. 독립 모드 구성

  1. 인벤토리 파일에서 [OSEv3:vars] 섹션에 다음 변수를 추가하고 구성에 필요한 대로 조정합니다.

    [OSEv3:vars]
    ...
    openshift_storage_glusterfs_namespace=app-storage
    openshift_storage_glusterfs_storageclass=true
    openshift_storage_glusterfs_storageclass_default=false
    openshift_storage_glusterfs_block_deploy=true
    openshift_storage_glusterfs_block_host_vol_size=100
    openshift_storage_glusterfs_block_storageclass=true
    openshift_storage_glusterfs_block_storageclass_default=false
    openshift_storage_glusterfs_is_native=false
    openshift_storage_glusterfs_heketi_is_native=true
    openshift_storage_glusterfs_heketi_executor=ssh
    openshift_storage_glusterfs_heketi_ssh_port=22
    openshift_storage_glusterfs_heketi_ssh_user=root
    openshift_storage_glusterfs_heketi_ssh_sudo=false
    openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"
  2. [OSEv3:children] 섹션에 glusterfs 를 추가하여 [glusterfs] 그룹을 활성화합니다.

    [OSEv3:children]
    masters
    nodes
    glusterfs
  3. GlusterFS 스토리지를 호스팅할 각 스토리지 노드에 대해 [glusterfs] 섹션을 추가합니다. 각 노드에 대해 glusterfs_devices 를 GlusterFS 클러스터의 일부로 완전히 관리할 원시 블록 장치 목록으로 설정합니다. 나열된 장치가 하나 이상 있어야 합니다. 파티션이나 LVM PV가 없는 각 장치는 베어여야 합니다. 또한 glusterfs_ip 를 노드의 IP 주소로 설정합니다. 변수를 지정하면 폼을 사용합니다.

    <hostname_or_ip> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

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

    [glusterfs]
    gluster1.example.com glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    gluster2.example.com glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    gluster3.example.com glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'

4.13. OpenShift Container Registry 구성

통합 OpenShift Container Registry 는 설치 프로그램을 사용하여 배포할 수 있습니다.

4.13.1. 레지스트리 스토리지 구성

레지스트리 스토리지 옵션을 사용하지 않는 경우 기본 OpenShift Container Registry는 임시이며 Pod가 더 이상 존재하지 않으면 모든 데이터가 손실됩니다.

중요

테스트 결과, RHEL NFS 서버를 컨테이너 이미지 레지스트리의 스토리지 백엔드로 사용하는 데 문제가 있는 것으로 표시됩니다. 여기에는 OpenShift Container Registry 및 Quay가 포함됩니다. 따라서 RHEL NFS 서버를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.

마켓플레이스의 다른 NFS 구현에는 이러한 문제가 나타나지 않을 수 있습니다. 이러한 OpenShift 핵심 구성 요소에 대해 완료된 테스트에 대한 자세한 내용은 개별 NFS 구현 공급업체에 문의하십시오.

고급 설치 프로그램을 사용할 때 레지스트리 스토리지를 활성화하기 위한 몇 가지 옵션이 있습니다.

옵션 A: NFS 호스트 그룹

다음 변수가 설정되면 [nfs] 호스트 그룹의 호스트의 < nfs_directory>/<volume_name > 경로를 사용하여 클러스터 설치 중에 NFS 볼륨이 생성됩니다. 예를 들어 이러한 옵션을 사용하는 볼륨 경로는 /exports/registry 입니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)'
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi
옵션 B: 외부 NFS 호스트

외부 NFS 볼륨을 사용하려면 스토리지 호스트에 < nfs_directory>/<volume_name > 경로가 이미 있어야 합니다. 다음 옵션을 사용하는 원격 볼륨 경로는 nfs.example.com:/exports/registry 입니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_host=nfs.example.com
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi
NFS를 사용하여 OpenShift Container Platform 업그레이드 또는 설치
Option C: OpenStack Platform

OpenStack 스토리지 구성이 이미 있어야 합니다.

[OSEv3:vars]

openshift_hosted_registry_storage_kind=openstack
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_openstack_filesystem=ext4
openshift_hosted_registry_storage_openstack_volumeID=3a650b4f-c8c5-4e0a-8ca5-eaee11f16c57
openshift_hosted_registry_storage_volume_size=10Gi
옵션 D: AWS 또는 다른 S3 스토리지 솔루션

단순 스토리지 솔루션(S3) 버킷이 이미 있어야 합니다.

[OSEv3:vars]

#openshift_hosted_registry_storage_kind=object
#openshift_hosted_registry_storage_provider=s3
#openshift_hosted_registry_storage_s3_accesskey=access_key_id
#openshift_hosted_registry_storage_s3_secretkey=secret_access_key
#openshift_hosted_registry_storage_s3_bucket=bucket_name
#openshift_hosted_registry_storage_s3_region=bucket_region
#openshift_hosted_registry_storage_s3_chunksize=26214400
#openshift_hosted_registry_storage_s3_rootdirectory=/registry
#openshift_hosted_registry_pullthrough=true
#openshift_hosted_registry_acceptschema2=true
#openshift_hosted_registry_enforcequota=true

Minio 또는 ExoScale과 같은 다른 S3 서비스를 사용하는 경우 region endpoint 매개변수도 추가합니다.

openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/
옵션 E: 통합 모드

통합 모드를 구성하는 것과 유사하게 Red Hat Gluster Storage는 클러스터를 처음 설치하는 동안 OpenShift Container Registry용 스토리지를 제공하여 레지스트리에 대한 중복되고 안정적인 스토리지를 제공하도록 구성할 수 있습니다.

중요

특정 호스트 준비 및 사전 요구 사항은 통합 모드 고려 사항을 참조하십시오.

  1. 인벤토리 파일에서 [OSEv3:vars] 섹션에서 다음 변수를 설정하고 구성에 필요한 대로 조정합니다.

    [OSEv3:vars]
    ...
    openshift_hosted_registry_storage_kind=glusterfs 1
    openshift_hosted_registry_storage_volume_size=5Gi
    openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'
    1
    인프라 노드에서 통합 OpenShift Container Registry를 실행하는 것이 좋습니다. 인프라 노드는 OpenShift Container Platform 클러스터에 서비스를 제공하기 위해 관리자가 배포한 애플리케이션을 실행하는 전용 노드입니다.
  2. [OSEv3:children] 섹션에 glusterfs_registry 를 추가하여 [glusterfs_registry] 그룹을 활성화합니다.

    [OSEv3:children]
    masters
    nodes
    glusterfs_registry
  3. GlusterFS 스토리지를 호스팅할 각 스토리지 노드에 대한 항목이 [glusterfs_registry] 섹션을 추가합니다. 각 노드에 대해 glusterfs_devices 를 GlusterFS 클러스터의 일부로 완전히 관리할 원시 블록 장치 목록으로 설정합니다. 나열된 장치가 하나 이상 있어야 합니다. 파티션이나 LVM PV가 없는 각 장치는 베어여야 합니다. 변수를 지정하면 폼을 사용합니다.

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

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

    [glusterfs_registry]
    node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
  4. [glusterfs_registry] 아래에 나열된 호스트를 [nodes] 그룹에 추가합니다.

    [nodes]
    ...
    node11.example.com openshift_node_group_name="node-config-infra"
    node12.example.com openshift_node_group_name="node-config-infra"
    node13.example.com openshift_node_group_name="node-config-infra"
옵션 F: Google Compute Engine (GCE)의 GCS(Google Cloud Storage) 버킷

GCS 버킷은 이미 있어야 합니다.

[OSEv3:vars]

openshift_hosted_registry_storage_provider=gcs
openshift_hosted_registry_storage_gcs_bucket=bucket01
openshift_hosted_registry_storage_gcs_keyfile=test.key
openshift_hosted_registry_storage_gcs_rootdirectory=/registry
옵션 G: vSphere Cloud Provider(VCP)를 통한 vSphere 볼륨

vSphere 클라우드 공급자는 OpenShift Container Platform 노드에서 액세스할 수 있는 데이터 저장소를 사용하여 구성해야 합니다.

레지스트리에 vSphere 볼륨을 사용하는 경우 스토리지 액세스 모드를 ReadWriteOnce 로 설정하고 복제본 수를 1 로 설정해야 합니다.

[OSEv3:vars]

openshift_hosted_registry_storage_kind=vsphere
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_annotations=['volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume']
openshift_hosted_registry_replicas=1

4.14. 글로벌 프록시 옵션 구성

호스트에 외부 호스트에 연결하기 위해 HTTP 또는 HTTPS 프록시를 사용해야 하는 경우 마스터, Docker 및 빌드를 포함하여 프록시를 사용하도록 구성해야 하는 많은 구성 요소가 있습니다. 노드 서비스는 외부 액세스가 필요하지 않은 마스터 API에만 연결하므로 프록시를 사용하도록 구성할 필요가 없습니다.

이 구성을 단순화하기 위해 사용자 환경에 균일하게 이러한 설정을 적용하기 위해 클러스터 또는 호스트 수준에서 다음 Ansible 변수를 지정할 수 있습니다.

참고

빌드에 프록시 환경을 정의하는 방법에 대한 자세한 내용은 글로벌 빌드 기본값 및 덮어쓰기 구성을 참조하십시오.

표 4.9. 클러스터 프록시 변수
변수목적

openshift_http_proxy

이 변수는 masters 및 Docker 데몬의 HTTP_PROXY 환경 변수를 지정합니다.

openshift_https_proxy

이 변수는 마스터 및 Docker 데몬의 HTTPS_PROXY 환경 변수를 지정합니다.

openshift_no_proxy

이 변수는 마스터 및 Docker 데몬의 NO_PROXY 환경 변수를 설정하는 데 사용됩니다. 정의된 프록시를 사용하지 않는 쉼표로 구분된 호스트 이름, 도메인 이름 또는 와일드카드 호스트 이름 목록을 제공합니다. 기본적으로 이 목록은 정의된 모든 OpenShift Container Platform 호스트 이름 목록을 사용하여 보강됩니다.

정의된 프록시를 사용하지 않는 호스트 이름은 다음과 같습니다.

  • 마스터 및 노드 호스트 이름입니다. 도메인 접미사를 포함해야 합니다.
  • 기타 내부 호스트 이름. 도메인 접미사를 포함해야 합니다.
  • etcd IP 주소. etcd 액세스가 IP 주소로 관리되므로 IP 주소를 제공해야 합니다.
  • 컨테이너 이미지 레지스트리 IP 주소입니다.
  • Kubernetes IP 주소입니다. 이 값은 기본적으로 172.30.0.1 이고 제공된 경우 openshift_portal_net 매개변수 값입니다.
  • cluster.local Kubernetes 내부 도메인 접미사입니다.
  • svc Kubernetes 내부 도메인 접미사입니다.

openshift_generate_no_proxy_hosts

이 부울 변수는 정의된 모든 OpenShift 호스트의 이름 및 *.cluster.localNO_PROXY 목록에 자동으로 추가되는지 여부를 지정합니다. 기본값은 true 입니다. 이 옵션을 재정의하려면 false 로 설정합니다.

openshift_builddefaults_http_proxy

이 변수는 BuildDefaults 승인 컨트롤러를 사용하여 빌드에 삽입된 HTTP_PROXY 환경 변수를 정의합니다. 이 매개변수를 정의하지 않지만 openshift_http_proxy 매개변수를 정의하면 openshift_http_proxy 값이 사용됩니다. openshift_builddefaults_http_proxy 값을 False 로 설정하여 openshift_http_proxy 값과 관계없이 빌드의 기본 http 프록시를 비활성화합니다.

openshift_builddefaults_https_proxy

이 변수는 BuildDefaults 승인 컨트롤러를 사용하여 빌드에 삽입된 HTTPS_PROXY 환경 변수를 정의합니다. 이 매개변수를 정의하지 않지만 openshift_http_proxy 매개변수를 정의하면 openshift_https_proxy 값이 사용됩니다. openshift_https_proxy 값과 관계없이 빌드의 기본 https 프록시를 비활성화하려면 openshift_builddefaults_https_proxy 값을 False 로 설정합니다.

openshift_builddefaults_no_proxy

이 변수는 BuildDefaults 승인 컨트롤러를 사용하여 빌드에 삽입된 NO_PROXY 환경 변수를 정의합니다. openshift_no_proxy 값과 관계없이 빌드의 기본 프록시 설정을 비활성화하려면 openshift_builddefaults_no_proxy 값을 False 로 설정합니다.

openshift_builddefaults_git_http_proxy

이 변수는 빌드 중 git clone 작업에서 사용하는 HTTP 프록시를 정의하고 BuildDefaults 승인 컨트롤러를 사용하여 정의합니다. openshift_builddefaults_git_http_proxy 값을 False 로 설정하여 openshift_http_proxy 값과 관계없이 빌드 중 git clone 작업에 대한 기본 http 프록시를 비활성화합니다.

openshift_builddefaults_git_https_proxy

이 변수는 빌드 중 git clone 작업에서 사용하는 HTTPS 프록시를 정의하고 BuildDefaults 승인 컨트롤러를 사용하여 정의합니다. openshift_builddefaults_git_https_proxy 값을 False 로 설정하여 openshift_https_proxy 값과 관계없이 빌드 중 Git 복제 작업에 대한 기본 https 프록시를 비활성화합니다.

4.15. 방화벽 구성

중요
  • 기본 방화벽을 변경하는 경우 클러스터의 각 호스트가 동일한 방화벽 유형을 사용하여 불일치를 방지해야 합니다.
  • Atomic Host에 설치된 OpenShift Container Platform과 함께 firewalld를 사용하지 마십시오. Atomic 호스트에서 firewalld는 지원되지 않습니다.
참고

iptables가 기본 방화벽이지만 새로 설치하는 데 firewalld가 권장됩니다.

OpenShift Container Platform에서는 iptables를 기본 방화벽으로 사용하지만 설치 프로세스 중에 firewalld를 사용하도록 클러스터를 구성할 수 있습니다.

iptables는 기본 방화벽이므로 OpenShift Container Platform은 자동으로 구성되도록 설계되었습니다. 그러나 iptables 규칙이 올바르게 구성되지 않은 경우 OpenShift Container Platform을 중단할 수 있습니다. firewalld의 장점은 여러 오브젝트가 방화벽 규칙을 안전하게 공유할 수 있도록 하는 것입니다.

OpenShift Container Platform 설치의 방화벽으로 firewalld를 사용하려면 install의 Ansible 호스트 파일의 구성 변수 목록에 os_firewall_use_firewalld 변수를 추가합니다.

[OSEv3:vars]
os_firewall_use_firewalld=True 1
1
이 변수를 true 로 설정하면 필수 포트가 열리고 기본 영역에 규칙을 추가하여 firewalld가 올바르게 구성되었는지 확인합니다.
참고

firewalld 기본 구성 사용은 제한된 구성 옵션과 함께 제공되며 재정의할 수 없습니다. 예를 들어 여러 영역에 인터페이스를 사용하여 스토리지 네트워크를 설정할 수 있지만, 노드가 통신하는 인터페이스가 기본 영역에 있어야 합니다.

4.16. 세션 옵션 구성

OAuth 구성의 세션 옵션 은 인벤토리 파일에서 구성할 수 있습니다. 기본적으로 Ansible은 생성된 인증 및 암호화 비밀로 sessionSecretsFile 을 채우므로 하나의 마스터에서 생성한 세션을 다른 마스터에서 디코딩할 수 있습니다. 기본 위치는 /etc/origin/master/session-secrets.yaml 이며 이 파일은 모든 마스터에서 삭제된 경우에만 다시 생성됩니다.

openshift_master_session_nameopenshift_master_session_max_seconds 를 사용하여 세션 이름과 최대 초를 설정할 수 있습니다.

openshift_master_session_name=ssn
openshift_master_session_max_seconds=3600

제공되는 경우 openshift_master_session_auth_secretsopenshift_master_encryption_secrets 의 길이가 같아야 합니다.

OPENSHIFT를 사용하여 세션을 인증하는 데 사용되는 openshift_master_session_auth_secrets 의 경우 32바이트 또는 64바이트의 시크릿을 사용하는 것이 좋습니다.

openshift_master_session_auth_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']

세션을 암호화하는 데 사용되는 openshift_master_encryption_secrets 의 경우 시크릿은 AES-128, AES-192 또는 AES-256을 선택하려면 16 24 또는 32자여야 합니다.

openshift_master_session_encryption_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']

4.17. 사용자 정의 인증서 구성

OpenShift Container Platform API 및 웹 콘솔 의 공개 호스트 이름에 대한 사용자 정의 제공 인증서는 클러스터 설치 중에 배포할 수 있으며 인벤토리 파일에서 구성할 수 있습니다.

참고

openshift_master_cluster_public_hostname 매개변수 값으로 설정한 공용MasterURL 과 연결된 호스트 이름에 대한 사용자 정의 인증서를 구성합니다. 인프라 구성 요소가 내부 masterURL 호스트를 사용하여 마스터 API에 연결을 시도하므로 마스터 URL과 연결된 호스트 이름에 사용자 정의 제공 인증서를 사용하면 인프라 구성 요소가 마스터 API에 연결하려고 하므로 TLS 오류가 발생합니다.

인증서 및 키 파일 경로는 openshift_master_named_certificates 클러스터 변수를 사용하여 구성할 수 있습니다.

openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "cafile": "/path/to/custom-ca1.crt"}]

파일 경로는 Ansible이 실행되는 시스템의 로컬이어야 합니다. 인증서는 마스터 호스트에 복사되며 /etc/origin/master/named_certificates/ 디렉터리에 배포됩니다.

Ansible은 인증서의 일반 이름주체 대체 이름을 감지합니다. 감지된 이름은 openshift_master_named_certificates 를 설정할 때 "names" 키를 제공하여 덮어쓸 수 있습니다.

openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]

openshift_master_named_certificates 를 사용하여 구성된 인증서는 마스터에 캐시됩니다. 즉, 각 추가 Ansible이 다른 인증서 세트로 실행하면 이전에 배포한 모든 인증서가 마스터 호스트 및 마스터 구성 파일에 남아 있게 됩니다.

openshift_master_named_certificates 를 제공된 값(또는 값이 없음)으로 덮어쓰려면 openshift_master_overwrite_named_certificates 클러스터 변수를 지정합니다.

openshift_master_overwrite_named_certificates=true

예를 들어 인벤토리 파일에서 다음 클러스터 변수를 고려하십시오.

openshift_master_cluster_method=native
openshift_master_cluster_hostname=lb-internal.openshift.com
openshift_master_cluster_public_hostname=custom.openshift.com

후속 Ansible 실행의 인증서를 덮어쓰려면 다음 매개변수 값을 설정합니다.

openshift_master_named_certificates=[{"certfile": "/root/STAR.openshift.com.crt", "keyfile": "/root/STAR.openshift.com.key", "names": ["custom.openshift.com"], "cafile": "/root/ca-file.crt"}]
openshift_master_overwrite_named_certificates=true
중요

cafile 인증서는 설치 중 또는 인증서를 다시 배포하는 동안 마스터의 ca-bundle.crt 파일로 가져옵니다. ca-bundle.crt 파일은 OpenShift Container Platform에서 실행되는 모든 Pod에 마운트됩니다. 여러 OpenShift Container Platform 구성 요소가 masterPublicURL 엔드포인트에 액세스할 때 기본적으로 명명된 인증서를 자동으로 신뢰합니다. certificates 매개변수에서 cafile 옵션을 생략하면 웹 콘솔의 기능과 다른 여러 구성 요소가 줄어듭니다.

4.18. 인증서 유효성 구성

기본적으로 etcd, 마스터 및 kubelet을 관리하는 데 사용되는 인증서는 2~5년 후에 만료됩니다. 자동 생성 레지스트리, CA, 노드 및 마스터 인증서의 유효 기간(일)은 다음 변수(표시된 기본값)를 사용하여 설치 중에 구성할 수 있습니다.

[OSEv3:vars]

openshift_hosted_registry_cert_expire_days=730
openshift_ca_cert_expire_days=1825
openshift_master_cert_expire_days=730
etcd_ca_default_days=1825

이러한 값은 Ansible 설치 후 Ansible 을 통해 인증서를 재배포 할 때도 사용됩니다.

4.19. 클러스터 모니터링 구성

Prometheus 클러스터 모니터링이 자동으로 배포되도록 설정되어 있습니다. 자동 배포를 방지하려면 다음을 설정합니다.

[OSEv3:vars]

openshift_cluster_monitoring_operator_install=false

Prometheus Cluster Monitoring 및 해당 구성에 대한 자세한 내용은 Prometheus 클러스터 모니터링 설명서 를 참조하십시오.

4.20. 클러스터 지표 구성

클러스터 메트릭은 자동으로 배포되도록 설정되지 않습니다. 클러스터 설치 중에 클러스터 지표를 활성화하려면 다음을 설정합니다.

[OSEv3:vars]

openshift_metrics_install_metrics=true

지표 공용 URL은 openshift_metrics_hawkular_hostname Ansible 변수를 사용하여 클러스터 설치 중에 설정할 수 있습니다. 기본값은 다음과 같습니다.

https://hawkular-metrics.{{openshift_master_default_subdomain}}/hawkular/metrics

이 변수를 변경하는 경우 라우터를 통해 호스트 이름에 액세스할 수 있는지 확인합니다.

openshift_metrics_hawkular_hostname=hawkular-metrics.{{openshift_master_default_subdomain}}

중요

업스트림 Kubernetes 규칙에 따라 지표는 eth0 의 기본 인터페이스에서만 수집할 수 있습니다.

참고

메트릭을 배포하려면 openshift_master_default_subdomain 값을 설정해야 합니다.

4.20.1. 지표 스토리지 구성

메트릭에 영구 스토리지를 사용하려면 openshift_metrics_cassandra_storage_type 변수를 설정해야 합니다. openshift_metrics_cassandra_storage_type 이 설정되지 않은 경우 cluster 지표 데이터는 emptyDir 볼륨에 저장되며 KnativeServing Pod가 종료될 때 삭제됩니다.

중요

테스트 결과, RHEL NFS 서버를 컨테이너 이미지 레지스트리의 스토리지 백엔드로 사용하는 데 문제가 있는 것으로 표시됩니다. 여기에는 지표 스토리지에 대한 sysfs가 포함됩니다. 따라서 RHEL NFS 서버를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.

rhcos는 여러 개의 독립된 인스턴스를 통해 중복성을 제공하도록 설계되었습니다. 이러한 이유로 데이터 디렉토리에 NFS 또는 SAN을 사용하는 것은 반성제이며 권장되지 않습니다.

그러나 마켓플레이스의 NFS/SAN 구현에는 이 구성 요소의 백업 또는 스토리지 제공 문제가 없을 수 있습니다. 이러한 OpenShift 핵심 구성 요소에 대해 완료된 테스트에 대한 자세한 내용은 개별 NFS/SAN 구현 공급업체에 문의하십시오.

클러스터 설치 중에 클러스터 지표 스토리지를 활성화하는 데는 다음 세 가지 옵션이 있습니다.

옵션 A: Dynamic

OpenShift Container Platform 환경에서 클라우드 공급자에 대한 동적 볼륨 프로비저닝 을 지원하는 경우 다음 변수를 사용합니다.

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=dynamic

gluster-storage 및 glusterfs-storage-block과 같이 동적으로 프로비저닝된 여러 볼륨 유형이 있는 경우 변수별로 프로비저닝된 볼륨 유형을 지정할 수 있습니다. 다음 변수를 사용합니다.

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=pv
openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block

DynamicProvisioningEnabled 를 사용하여 동적 프로비저닝을 활성화하거나 비활성화하는 방법에 대한 자세한 내용은 볼륨 구성을 확인합니다.

옵션 B: NFS 호스트 그룹

다음 변수가 설정되면 [nfs] 호스트 그룹의 호스트에서 < nfs_directory>/<volume_name > 경로를 사용하여 클러스터 설치 중에 NFS 볼륨이 생성됩니다. 예를 들어 이러한 옵션을 사용하는 볼륨 경로는 /exports/metrics 입니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_nfs_options='*(rw,root_squash)'
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi
옵션 C: 외부 NFS 호스트

외부 NFS 볼륨을 사용하려면 스토리지 호스트에 < nfs_directory>/<volume_name > 경로가 이미 있어야 합니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_host=nfs.example.com
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

다음 옵션을 사용하는 원격 볼륨 경로는 nfs.example.com:/exports/metrics 입니다.

NFS를 사용하여 OpenShift Container Platform 업그레이드 또는 설치

NFS(및 NFS 프로토콜)는 OpenShift Container Platform 인프라를 구성하는 애플리케이션에 필요한 적절한 일관성을 제공하지 않으므로 핵심 OpenShift Container Platform 구성 요소에 NFS를 사용하는 것은 권장되지 않습니다.

결과적으로 설치 프로그램 및 업데이트 플레이북에 핵심 인프라 구성 요소가 있는 NFS를 사용할 수 있도록 하는 옵션이 필요합니다.

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

클러스터를 업그레이드하거나 설치할 때 다음 메시지가 표시되면 추가 단계가 필요합니다.

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

Ansible 인벤토리 파일에서 다음 매개변수를 지정합니다.

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

4.21. 클러스터 로깅 구성

클러스터 로깅은 기본적으로 자동으로 배포되도록 설정되지 않습니다. 클러스터 설치 중에 클러스터 로깅을 활성화하려면 다음을 설정합니다.

[OSEv3:vars]

openshift_logging_install_logging=true
참고

클러스터 로깅을 설치할 때 Ansible 인벤토리 파일에서 openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"} 와 같은 노드 선택기를 지정해야 합니다.

사용 가능한 클러스터 로깅 변수에 대한 자세한 내용은 로깅 Ansible 변수 지정을 참조하십시오.

4.21.1. 로깅 스토리지 구성

로깅에 영구 스토리지를 사용하려면 openshift_logging_es_pvc_dynamic 변수를 설정해야 합니다. openshift_logging_es_pvc_dynamic 이 설정되지 않은 경우 클러스터 로깅 데이터는 emptyDir 볼륨에 저장되며 Elasticsearch Pod가 종료될 때 삭제됩니다.

중요

테스트 결과, RHEL NFS 서버를 컨테이너 이미지 레지스트리의 스토리지 백엔드로 사용하는 데 문제가 있는 것으로 표시됩니다. 여기에는 로깅 스토리지를 위한 ElasticSearch가 포함됩니다. 따라서 RHEL NFS 서버를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.

ElasticSearch로 인해 사용자 정의 deletionPolicy를 구현하지 않기 때문에 NFS 스토리지를 볼륨 또는 영구 볼륨으로 사용하지 않는 것은 Lucene 및 기본 deletionPolicy는 NFS가 제공하지 않는 파일 시스템 동작에 따라 Elasticsearch 스토리지에서 지원되지 않습니다. 데이터 손상 및 기타 문제가 발생할 수 있습니다.

마켓플레이스의 NFS 구현에는 이러한 문제가 발생하지 않을 수 있습니다. 이러한 OpenShift 핵심 구성 요소에 대해 수행한 테스트에 대한 자세한 내용은 개별 NFS 구현 공급업체에 문의하십시오.

클러스터 설치 중에 클러스터 로깅 스토리지를 활성화하는 방법은 다음 세 가지가 있습니다.

옵션 A: Dynamic

OpenShift Container Platform 환경에 동적 볼륨 프로비저닝이 있는 경우 클라우드 공급자 또는 독립 스토리지 공급자를 통해 구성할 수 있습니다. 예를 들어 클라우드 공급자는 GCE에서 provisioner kubernetes.io/gce-pd 를 사용하는 StorageClass를 가질 수 있으며 GlusterFS와 같은 독립 스토리지 제공에는 provisioner kubernetes.io/glusterfs 가 있는 StorageClass 가 있을 수 있습니다. 두 경우 모두 다음 변수를 사용합니다.

[OSEv3:vars]

openshift_logging_es_pvc_dynamic=true

동적 프로비저닝에 대한 자세한 내용은 동적 프로비저닝 및 스토리지 클래스 생성을 참조하십시오.

gluster-storage 및 glusterfs-storage-block과 같이 동적으로 프로비저닝된 여러 볼륨 유형이 있는 경우 변수별로 프로비저닝된 볼륨 유형을 지정할 수 있습니다. 다음 변수를 사용합니다.

[OSEv3:vars]

openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block

DynamicProvisioningEnabled 를 사용하여 동적 프로비저닝을 활성화하거나 비활성화하는 방법에 대한 자세한 내용은 볼륨 구성을 확인합니다.

옵션 B: NFS 호스트 그룹

다음 변수가 설정되면 [nfs] 호스트 그룹의 호스트에서 < nfs_directory>/<volume_name > 경로를 사용하여 클러스터 설치 중에 NFS 볼륨이 생성됩니다. 예를 들어 이러한 옵션을 사용하는 볼륨 경로는 /exports/logging 입니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_nfs_directory=/exports 1
openshift_logging_storage_nfs_options='*(rw,root_squash)' 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging
1 2
이러한 매개변수는 /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 설치 플레이북에서만 작동합니다. 매개변수는 /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml 플레이북에서 작동하지 않습니다.
3
NFS 볼륨 이름은 로깅 해야 합니다.
옵션 C: 외부 NFS 호스트

외부 NFS 볼륨을 사용하려면 스토리지 호스트에 < nfs_directory>/<volume_name > 경로가 이미 있어야 합니다.

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_host=nfs.example.com 1
openshift_logging_storage_nfs_directory=/exports 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging
1 2
이러한 매개변수는 /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 설치 플레이북에서만 작동합니다. 매개변수는 /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml 플레이북에서 작동하지 않습니다.
3
NFS 볼륨 이름은 로깅 해야 합니다.

다음 옵션을 사용하는 원격 볼륨 경로는 nfs.example.com:/exports/logging 입니다.

NFS를 사용하여 OpenShift Container Platform 업그레이드 또는 설치

NFS(및 NFS 프로토콜)는 OpenShift Container Platform 인프라를 구성하는 애플리케이션에 필요한 적절한 일관성을 제공하지 않으므로 핵심 OpenShift Container Platform 구성 요소에 NFS를 사용하는 것은 권장되지 않습니다.

결과적으로 설치 프로그램 및 업데이트 플레이북에 핵심 인프라 구성 요소가 있는 NFS를 사용할 수 있도록 하는 옵션이 필요합니다.

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

클러스터를 업그레이드하거나 설치할 때 다음 메시지가 표시되면 추가 단계가 필요합니다.

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

Ansible 인벤토리 파일에서 다음 매개변수를 지정합니다.

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

4.22. 서비스 카탈로그 옵션 사용자 정의

서비스 카탈로그 는 설치 중에 기본적으로 활성화됩니다. 서비스 브로커를 활성화하면 카탈로그로 서비스 브로커를 등록할 수 있습니다. 서비스 카탈로그가 활성화되면 OpenShift Ansible 브로커와 템플릿 서비스 브로커가 모두 설치되어 있습니다. 자세한 내용은 OpenShift Ansible Broker 구성 및 Template 서비스 브로커 구성을 참조하십시오. 서비스 카탈로그를 비활성화하면 OpenShift Ansible 브로커 및 템플릿 서비스 브로커가 설치되지 않습니다.

서비스 카탈로그의 자동 배포를 비활성화하려면 인벤토리 파일에서 다음 클러스터 변수를 설정합니다.

openshift_enable_service_catalog=false

자체 레지스트리를 사용하는 경우 다음을 추가해야 합니다.

  • openshift_service_catalog_image_prefix: 서비스 카탈로그 이미지를 가져오는 경우 특정 접두사(예: 레지스트리)를 강제로 사용합니다. 이미지 이름까지 전체 레지스트리 이름을 제공해야 합니다.
  • openshift_service_catalog_image_version: 서비스 카탈로그 이미지를 가져오는 경우 강제로 특정 이미지 버전을 사용합니다.

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

openshift_service_catalog_image="docker-registry.default.example.com/openshift/ose-service-catalog:${version}"
openshift_service_catalog_image_prefix="docker-registry-default.example.com/openshift/ose-"
openshift_service_catalog_image_version="v3.9.30"

4.22.1. OpenShift Ansible 브로커 구성

OpenShift Ansible 브로커 (OAB)는 설치 중에 기본적으로 활성화되어 있습니다.

OAB를 설치하지 않으려면 인벤토리 파일에서 ansible_service_broker_install 매개변수 값을 false 로 설정합니다.

ansible_service_broker_install=false
표 4.10. 서비스 브로커 사용자 정의 변수
변수목적

openshift_service_catalog_image_prefix

서비스 카탈로그 구성 요소 이미지의 접두사를 지정합니다.

4.22.1.1. OpenShift Ansible 브로커의 영구 스토리지 구성

OAB는 나머지 OpenShift Container Platform 클러스터에서 사용하는 etcd와 별도로 자체 etcd 인스턴스를 배포합니다. OAB의 etcd 인스턴스에는 작동할 PV(영구 볼륨)를 사용하는 별도의 스토리지가 필요합니다. PV를 사용할 수 없는 경우 etcd는 PV를 충족할 때까지 대기합니다. OAB 애플리케이션은 etcd 인스턴스를 사용할 수 있을 때까지 CrashLoop 상태를 입력합니다.

일부 Ansible 플레이북 번들(APB)은 배포하기 위해 자체 사용을 위해 PV가 필요합니다. 예를 들어, 각 데이터베이스 APB에는 두 가지 계획이 있습니다. 개발 계획에서는 임시 스토리지를 사용하며 프로덕션 계획에는 PV가 필요하지 않으며 PV가 필요합니다.

APBPV 필요?

postgresql-apb

예, 그러나 프로덕션 계획 전용입니다.

mysql-apb

예, 그러나 프로덕션 계획 전용입니다.

mariadb-apb

예, 그러나 프로덕션 계획 전용입니다.

mediawiki-apb

있음

OAB에 대한 영구 스토리지를 구성하려면 다음을 수행합니다.

참고

다음 예제에서는 NFS 호스트를 사용하여 필요한 PV를 제공하는 방법을 보여줍니다. 그러나 다른 영구저장장치 공급자를 대신 사용할 수 있습니다.

  1. 인벤토리 파일에서 [OSEv3: children] 섹션에 nfs 를 추가하여 [nfs] 그룹을 활성화합니다.

    [OSEv3:children]
    masters
    nodes
    nfs
  2. [nfs] 그룹 섹션을 추가하고 NFS 호스트가 될 시스템의 호스트 이름을 추가합니다.

    [nfs]
    master1.example.com
  3. [OSEv3:vars] 섹션에 다음을 추가합니다.

    # nfs_directory must conform to DNS-1123 subdomain must consist of lower case
    # alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character
    
    openshift_hosted_etcd_storage_kind=nfs
    openshift_hosted_etcd_storage_nfs_options="*(rw,root_squash,sync,no_wdelay)"
    openshift_hosted_etcd_storage_nfs_directory=/opt/osev3-etcd 1
    openshift_hosted_etcd_storage_volume_name=etcd-vol2 2
    openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"]
    openshift_hosted_etcd_storage_volume_size=1G
    openshift_hosted_etcd_storage_labels={'storage': 'etcd'}
    1 2
    [nfs] 그룹의 호스트에서 경로 < nfs_directory>/<volume_name >을 사용하여 NFS 볼륨이 생성됩니다. 예를 들어 이러한 옵션을 사용하는 볼륨 경로는 /opt/osev3-etcd/etcd-vol2 입니다.

    이 설정은 클러스터 설치 중에 OAB의 etcd 인스턴스에 연결된 영구 볼륨을 생성합니다.

4.22.1.2. 로컬 APB 개발을 위한 OpenShift Ansible 브로커 구성

OAB와 함께 OpenShift Container Registry와 함께 APB 개발을 수행하려면 OAB에서 액세스할 수 있는 이미지 화이트리스트를 정의해야 합니다. 화이트리스트가 정의되지 않은 경우 브로커는 APB를 무시하고 사용자는 APB를 볼 수 없습니다.

기본적으로 화이트리스트는 비어 있으므로 사용자가 브로커를 구성하는 클러스터 관리자 없이 브로커에 APB 이미지를 추가할 수 없습니다. -apb 로 끝나는 모든 이미지를 허용 목록에 추가하려면 다음을 수행합니다.

  1. 인벤토리 파일에서 [OSEv3:vars] 섹션에 다음을 추가합니다.

    ansible_service_broker_local_registry_whitelist=['.*-apb$']

4.22.2. 템플릿 서비스 브로커 구성

템플릿 서비스 브로커 (TSB)는 설치 중에 기본적으로 활성화되어 있습니다.

TSB를 설치하지 않으려면 template_service_broker_install 매개변수 값을 false 로 설정합니다.

template_service_broker_install=false

TSB를 구성하려면 템플릿 및 이미지 스트림을 서비스 카탈로그에 로드하기 위해 하나 이상의 프로젝트를 브로커의 소스 네임스페이스로 정의해야 합니다. 인벤토리 파일의 [OSEv3:vars] 섹션에서 다음을 수정하여 소스 프로젝트를 설정합니다.

openshift_template_service_broker_namespaces=['openshift','myproject']
표 4.11. 템플릿 서비스 브로커 사용자 정의 변수
변수목적

template_service_broker_prefix

템플릿 서비스 브로커 구성 요소 이미지의 접두사를 지정합니다.

ansible_service_broker_image_prefix

ansible 서비스 브로커 구성 요소 이미지의 접두사를 지정합니다.

4.23. 웹 콘솔 사용자 지정 구성

다음 Ansible 변수는 웹 콘솔을 사용자 정의할 마스터 구성 옵션을 설정합니다. 이러한 사용자 지정 옵션에 대한 자세한 내용은 웹 콘솔 사용자 지정을 참조하십시오.

표 4.12. 웹 콘솔 사용자 정의 변수
변수목적

openshift_web_console_install

웹 콘솔 설치 여부를 결정합니다. true 또는 false 로 설정할 수 있습니다. 기본값은 true 입니다.

openshift_web_console_prefix

웹 콘솔 이미지의 접두사를 지정합니다.

openshift_master_logout_url

웹 콘솔 구성에서 clusterInfo.logoutPublicURL 을 설정합니다. 자세한 내용은 로그 아웃 URL 변경을 참조하십시오. 예제 값: https://example.com/logout

openshift_web_console_extension_script_urls

웹 콘솔 구성에서 extensions.scriptURLs 를 설정합니다. 자세한 내용은 확장 스크립트 로드 및 스타일시트 를 참조하십시오. 예제 값: ['https://example.com/scripts/menu-customization.js','https://example.com/scripts/nav-customization.js']

openshift_web_console_extension_stylesheet_urls

웹 콘솔 구성에 extensions.styleroomURLs 를 설정합니다. 자세한 내용은 확장 스크립트 로드 및 스타일시트 를 참조하십시오. 예제 값: ['https://example.com/styles/logo.css','https://example.com/styles/custom-styles.css']

openshift_master_oauth_template

마스터 구성에 OAuth 템플릿을 설정합니다. 자세한 내용은 로그인 페이지 사용자 지정을 참조하십시오. 예제 값: ['/path/to/login-template.html']

openshift_master_metrics_public_url

마스터 구성에 metricsPublicURL 을 설정합니다. 자세한 내용은 지표 공용 URL 설정을 참조하십시오. 예제 값: https://hawkular-metrics.example.com/hawkular/metrics

openshift_master_logging_public_url

마스터 구성에 loggingPublicURL 을 설정합니다. 자세한 내용은 Kibana 를 참조하십시오. 예제 값: https://kibana.example.com

openshift_web_console_inactivity_timeout_minutes

일정 시간 비활성 후 자동으로 사용자 아웃을 기록하도록 웹 콘솔을 구성합니다. 기능을 비활성화하려면 5 또는 0보다 크거나 같은 정수여야 합니다. 기본값은 0(비활성화)입니다.

openshift_web_console_cluster_resource_overrides_enabled

오버 커밋을 위해 클러스터가 구성되어 있는지 여부를 나타내는 부울 값입니다. true 인 경우 웹 콘솔은 클러스터 리소스 덮어쓰기 구성을 사용하여 이러한 값을 설정해야 하므로 리소스 제한을 편집할 때 CPU 요청, CPU 제한 및 메모리 요청에 대한 필드를 숨깁니다.

openshift_web_console_enable_context_selector

웹 콘솔과 관리 콘솔 마스트 헤드에서 컨텍스트 선택기를 활성화하여 두 콘솔 간에 빠르게 전환합니다. 두 콘솔이 모두 설치되면 기본값은 true 입니다.

4.24. 클러스터 콘솔 구성

클러스터 콘솔은 웹 콘솔과 같은 추가 웹 인터페이스이지만 관리 작업에 중점을 둡니다. 클러스터 콘솔은 웹 콘솔과 동일한 많은 일반 OpenShift Container Platform 리소스를 지원하지만 클러스터에 대한 메트릭을 보고 노드, 영구 볼륨, 클러스터 역할 및 사용자 정의 리소스 정의와 같은 클러스터 범위 리소스를 관리할 수도 있습니다. 다음 변수를 사용하여 클러스터 콘솔을 사용자 지정할 수 있습니다.

표 4.13. 클러스터 콘솔 사용자 정의 변수
변수목적

openshift_console_install

클러스터 콘솔 설치 여부를 결정합니다. true 또는 false 로 설정할 수 있습니다. 기본값은 true 입니다.

openshift_console_hostname

클러스터 콘솔의 호스트 이름을 설정합니다. 기본값은 console.<openshift_master_default_subdomain>입니다. 이 변수를 변경하는 경우 라우터를 통해 호스트 이름에 액세스할 수 있는지 확인합니다.

openshift_console_cert

클러스터 콘솔 경로에 사용할 선택적 인증서입니다. 사용자 지정 호스트 이름을 사용하는 경우에만 필요합니다.

openshift_console_key

클러스터 콘솔 경로에 사용할 선택적 키입니다. 사용자 지정 호스트 이름을 사용하는 경우에만 필요합니다.

openshift_console_ca

클러스터 콘솔 경로에 사용할 선택적 CA입니다. 사용자 지정 호스트 이름을 사용하는 경우에만 필요합니다.

openshift_base_path

클러스터 콘솔의 기본 경로입니다. 설정하면 /console/ 와 같은 슬래시로 시작하고 끝나야 합니다. 기본값은 / (기본 경로 없음)입니다.

openshift_console_auth_ca_file

OAuth 서버에 연결하는 데 사용할 선택적 CA 파일입니다. 기본값은 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 입니다. 일반적으로 이 값은 변경할 필요가 없습니다. CA 파일이 포함된 ConfigMap을 생성하고 지정한 위치와 동일한 위치에 있는 openshift-console 네임스페이스의 콘솔 배포에 마운트해야 합니다.

4.25. Operator Lifecycle Manager 구성

중요

Operator 프레임워크는 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

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

Technology Preview Operator 프레임워크에 는 OLM(Operator Lifecycle Manager)이 포함됩니다. 인벤토리 파일에서 다음 변수를 설정하여 클러스터 설치 중에 OLM을 선택적으로 설치할 수 있습니다.

참고

또는 클러스터 설치 후 Technology Preview Operator Framework를 설치할 수 있습니다. 별도의 지침은 Ansible을 사용하여 Operator Lifecycle Manager 설치를 참조하십시오.

  1. [OSEv3:vars] 섹션에 openshift_enable_olm 변수를 추가하여 true 로 설정합니다.

    openshift_enable_olm=true
  2. [OSEv3:vars] 섹션에 openshift_additional_registry_credentials 변수를 추가하여 Operator 컨테이너를 가져오는 데 필요한 자격 증명을 설정합니다.

    openshift_additional_registry_credentials=[{'host':'registry.connect.redhat.com','user':'<your_user_name>','password':'<your_password>','test_image':'mongodb/enterprise-operator:0.3.2'}]

    https://access.redhat.com 에서 Red Hat 고객 포털에 로그인하는 데 사용하는 자격 증명으로 사용자암호 를 설정합니다.

    test_image 는 사용자가 제공한 인증 정보를 테스트하는 데 사용할 이미지를 나타냅니다.

클러스터 설치가 완료되면 이 기술 프리뷰 단계에서 OLM을 클러스터 관리자로 사용하는 방법에 대한 추가 단계는 첫 번째 Operator 시작에서 참조하십시오.

5장. 인벤토리 파일 예

5.1. 개요

자체 인벤토리 파일 구성 의 기본 사항을 확인한 후 고가용성을 위해 여러 마스터 사용을 포함하여 다양한 환경 topographies를 설명하는 다음 예제 인벤토리를 검토할 수 있습니다. 요구 사항과 일치하는 예제를 선택하고 자체 환경과 일치하도록 수정하고 설치를 실행할 때 인벤토리 파일로 사용할 수 있습니다.

중요

다음 예제 인벤토리에서는 [nodes] 그룹에서 호스트마다 openshift_node_group_name 을 설정할 때 노드 그룹의 기본 세트를 사용합니다. 자체 사용자 지정 노드 그룹 정의를 정의하고 사용하려면 인벤토리 파일에서 openshift_node_groups 변수를 설정합니다. 자세한 내용은 노드 그룹 및 호스트 매핑 정의를 참조하십시오.

5.2. 단일 마스터 예

단일 마스터 및 여러 노드와 단일 etcd 호스트로 환경을 구성할 수 있습니다.

참고

설치 후 단일 마스터 클러스터에서 여러 마스터로 이동하는 것은 지원되지 않습니다.

5.2.1. 단일 마스터, 단일 etcd 및 여러 노드

다음 표에서는 단일 마스터 (동일한 호스트에서 정적 포드로 실행되는 단일 etcd 인스턴스 포함), 사용자 애플리케이션을 호스팅하는 데 사용되는 두 노드, 전용 인프라 호스팅을 위한 node-role.kubernetes.io/infra=true 라벨이 있는 두 개의 노드에 대해 설명합니다.

호스트 이름설치할 구성 요소/역할

master.example.com

master, etcd 및 노드

node1.example.com

컴퓨팅 노드

node2.example.com

infra-node1.example.com

인프라 노드

infra-node2.example.com

다음 예제 인벤토리 파일의 [masters], [etcd], [nodes] 섹션에 있는 예제 호스트를 볼 수 있습니다.

단일 마스터, 단일 etcd 및 여러 노드 인벤토리 파일

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
master.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

중요

OpenShift Container Platform 3.9부터 기본 노드 선택기 요구 사항 및 노드 레이블 고려 사항을 이해하려면 노드 호스트 레이블 구성을 참조하십시오.

이 예제를 사용하려면 환경 및 사양과 일치하도록 파일을 수정하고 /etc/ansible/hosts 로 저장합니다.

5.2.2. 단일 마스터, 여러 etcd 및 여러 노드

다음 표에서는 단일 마스터, 세 개의 etcd 호스트, 사용자 애플리케이션을 호스팅하는 두 개의 노드전용 인프라 호스팅을 위한 node-role.kubernetes.io/infra=true 라벨이 있는 두 개의 노드에 대해 설명합니다.

호스트 이름설치할 구성 요소/역할

master.example.com

마스터 및 노드

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

컴퓨팅 노드

node2.example.com

infra-node1.example.com

전용 인프라 노드

infra-node2.example.com

다음 예제 인벤토리 파일의 [masters], [nodes], [etcd] 섹션에 있는 예제 호스트를 볼 수 있습니다.

단일 마스터, 여러 etcd 및 여러 노드 인벤토리 파일

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

중요

OpenShift Container Platform 3.9부터 기본 노드 선택기 요구 사항 및 노드 레이블 고려 사항을 이해하려면 노드 호스트 레이블 구성을 참조하십시오.

이 예제를 사용하려면 환경 및 사양과 일치하도록 파일을 수정하고 /etc/ansible/hosts 로 저장합니다.

5.3. 여러 마스터 예

여러 마스터, 여러 etcd 호스트 및 여러 노드로 환경을 구성할 수 있습니다. HA( 고가용성)를 위해 여러 마스터를 구성하면 클러스터에 단일 장애 지점이 없습니다.

참고

설치 후 단일 마스터 클러스터에서 여러 마스터로 이동하는 것은 지원되지 않습니다.

여러 마스터를 구성할 때 클러스터 설치 프로세스에서 네이티브 HA(고가용성) 방법을 지원합니다. 이 방법은 OpenShift Container Platform에 빌드된 기본 HA 마스터 기능을 활용하여 모든 로드 밸런싱 솔루션과 결합할 수 있습니다.

호스트가 인벤토리 파일의 [lb] 섹션에 정의된 경우 Ansible은 자동으로 HAProxy를 마스터의 로드 밸런싱 솔루션으로 설치하고 구성합니다. 호스트가 정의되지 않은 경우 모든 마스터 호스트에서 마스터 API (포트 8443)의 균형을 위해 선택한 외부 로드 밸런싱 솔루션이 미리 구성되어 있다고 가정합니다.

참고

이 HAProxy 로드 밸런서는 API 서버의 HA 모드를 설명하기 위한 것이며 프로덕션 환경에는 사용하지 않는 것이 좋습니다. 클라우드 공급자에 배포하는 경우 클라우드 네이티브 TCP 기반 로드 밸런서를 배포하거나 고가용성 로드 밸런서를 제공하기 위해 다른 단계를 수행하는 것이 좋습니다.

HAProxy 로드 밸런서는 API 서버로 트래픽을 로드 밸런싱하는 데만 사용되며 사용자 애플리케이션 트래픽을 로드 밸런싱하지 않습니다.

외부 로드 밸런싱 솔루션의 경우 다음을 수행해야 합니다.

  • SSL 패스스루용으로 구성된 사전 생성된 로드 밸런서 가상 IP(VIP)입니다.
  • openshift_master_api_port 값(기본적으로 8443)에 의해 지정된 포트에서 수신 대기하는 VIP가 해당 포트의 모든 마스터 호스트로 다시 프록시합니다.
  • DNS에 등록된 VIP의 도메인 이름입니다.

    • 도메인 이름은 OpenShift Container Platform 설치 프로그램에서 openshift_master_cluster_public_hostnameopenshift_master_cluster_hostname 의 값이 됩니다.

자세한 내용은 GitHub의 External Load Balancer 통합 예제 를 참조하십시오. 고가용성 마스터 아키텍처에 대한 자세한 내용은 Kubernetes 인프라를 참조하십시오.

참고

클러스터 설치 프로세스에서는 현재 active-passive 설정에서 여러 HAProxy 로드 밸런서를 지원하지 않습니다. 설치 후 수정 사항은 로드 밸런서 관리 설명서 를 참조하십시오.

여러 마스터를 구성하려면 여러 마스터에서 여러 etcd를참조하십시오.

5.3.1. 외부 클러스터 etcd와 함께 네이티브 HA를 사용하는 여러 마스터

다음은 기본 HA 방법을 사용한 3개의 마스터 환경 예: HAProxy 로드 밸런서 1개, 사용자 애플리케이션을 호스팅하는 데 사용할 두 개의 노드, 전용 인프라 호스팅을 위한 node-role.kubernetes.io/infra=true 라벨이 있는 노드 두 개에 대해 설명합니다. https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#master

호스트 이름설치할 구성 요소/역할

master1.example.com

마스터(기본 HA를 사용한 클러스터) 및 노드

master2.example.com

master3.example.com

lb.example.com

HAProxy에서 API 마스터 끝점만 로드 밸런싱

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

컴퓨팅 노드

node2.example.com

infra-node1.example.com

전용 인프라 노드

infra-node2.example.com

[masters], [etcd], [lb], [nodes] 및 [nodes] 섹션에 있는 다음 예제 호스트가 다음 예제 인벤토리 파일의 섹션을 확인할 수 있습니다.

HAProxy 인벤토리 파일을 사용하여 여러 마스터

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availbility cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# apply updated node defaults
openshift_node_groups=[{'name': 'node-config-all-in-one', 'labels': ['node-role.kubernetes.io/master=true', 'node-role.kubernetes.io/infra=true', 'node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

중요

OpenShift Container Platform 3.9부터 기본 노드 선택기 요구 사항 및 노드 레이블 고려 사항을 이해하려면 노드 호스트 레이블 구성을 참조하십시오.

이 예제를 사용하려면 환경 및 사양과 일치하도록 파일을 수정하고 /etc/ansible/hosts 로 저장합니다.

5.3.2. Co-located Clustered etcd에서 Native HA를 사용하는 여러 마스터

다음에서는 기본 HA 방법(각 호스트에서 정적 Pod로 실행되는 etcd 포함), HAProxy 로드 밸런서 1개, 사용자 애플리케이션을 호스팅하는 데 필요한 노드 2개, 전용 인프라 호스팅을 위한 node-role.kubernetes.io/infra=true 라벨을 사용하는 마스터 3개 환경 예를 설명합니다.

호스트 이름설치할 구성 요소/역할

master1.example.com

마스터( native HA를 사용한 클러스터) 및 etcd가 각 호스트에서 정적 포드로 실행되는 노드

master2.example.com

master3.example.com

lb.example.com

HAProxy에서 API 마스터 끝점만 로드 밸런싱

node1.example.com

컴퓨팅 노드

node2.example.com

infra-node1.example.com

전용 인프라 노드

infra-node2.example.com

[masters], [etcd], [lb], [nodes] 및 [nodes] 섹션에 있는 다음 예제 호스트가 다음 예제 인벤토리 파일의 섹션을 확인할 수 있습니다.

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availability cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
master1.example.com
master2.example.com
master3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
중요

OpenShift Container Platform 3.9부터 기본 노드 선택기 요구 사항 및 노드 레이블 고려 사항을 이해하려면 노드 호스트 레이블 구성을 참조하십시오.

이 예제를 사용하려면 환경 및 사양과 일치하도록 파일을 수정하고 /etc/ansible/hosts 로 저장합니다.

6장. OpenShift Container Platform 설치

OpenShift Container Platform 클러스터를 설치하려면 일련의 Ansible 플레이북을 실행합니다.

중요

--tags 또는 --check 옵션을 사용하여 Ansible Playbook을 실행하는 것은 Red Hat에서 지원되지 않습니다.

참고

OpenShift Container Platform을 독립형 레지스트리로 설치하려면 독립 실행형 레지스트리 설치를 참조하십시오.

6.1. 사전 요구 사항

OpenShift Container Platform을 설치하기 전에 클러스터 호스트를 준비합니다.

  • 시스템 및 환경 요구 사항을 검토합니다.
  • 대규모 클러스터가 있는 경우 설치 시간을 최적화하기 위한 제안 사항은 스케일링 및 성능 가이드 를 확인하십시오.
  • 호스트를 준비합니다. 이 프로세스에는 구성 요소 유형별 시스템 및 환경 요구 사항 확인, docker 서비스 설치 및 구성, Ansible 버전 2.6 이상을 설치하는 작업이 포함됩니다. 설치 플레이북을 실행하려면 Ansible을 설치해야 합니다.
  • 환경 및 OpenShift Container Platform 클러스터 구성을 정의하도록 인벤토리 파일을 구성합니다. 초기 설치 및 향후 클러스터 업그레이드는 이 인벤토리 파일을 기반으로 합니다.
  • Red Hat Enterprise Linux에 OpenShift Container Platform을 설치하는 경우 RPM 또는 시스템 컨테이너 설치 방법을 사용할지 여부를 결정합니다. RHEL Atomic Host 시스템에 시스템 컨테이너 방법이 필요합니다.

6.1.1. RPM 기반 설치 프로그램 실행

RPM 기반 설치 프로그램은 RPM 패키지를 통해 설치된 Ansible을 사용하여 로컬 호스트에서 사용 가능한 플레이북 및 구성 파일을 실행합니다.

중요

nohup 에서 OpenShift Ansible 플레이북을 실행하지 마십시오. 플레이북과 함께 nohup 을 사용하면 파일 설명자를 생성하지만 닫히지 않습니다. 따라서 시스템이 파일을 열어서 실행할 수 있으며 플레이북이 실패합니다.

RPM 기반 설치 프로그램을 실행하려면 다음을 수행합니다.

  1. 플레이북 디렉터리로 변경하고 prerequisites.yml 플레이북을 실행합니다. 이 Playbook은 필요한 소프트웨어 패키지를 설치하고 컨테이너 런타임을 수정합니다. 컨테이너 런타임을 구성할 필요가 없는 경우 클러스터를 처음으로 배포하기 전에 이 플레이북을 한 번만 실행합니다.

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook [-i /path/to/inventory] \ 1
      playbooks/prerequisites.yml
    1
    인벤토리 파일이 /etc/ansible/hosts 디렉터리에 없는 경우 -i 및 인벤토리 파일의 경로를 지정합니다.
  2. 플레이북 디렉터리로 변경하고 deploy_cluster.yml 플레이북을 실행하여 클러스터 설치를 시작합니다.

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook [-i /path/to/inventory] \ 1
        playbooks/deploy_cluster.yml
    1
    인벤토리 파일이 /etc/ansible/hosts 디렉터리에 없는 경우 -i 및 인벤토리 파일의 경로를 지정합니다.

. 설치에 성공하면 설치를 확인합니다. 설치에 실패하면 설치를 다시 시도합니다.

6.1.2. 컨테이너화된 설치 프로그램 실행

openshift3/ose-ansible 이미지는 컨테이너화된 OpenShift Container Platform 설치 프로그램의 버전입니다. 이 설치 프로그램 이미지는 RPM 기반 설치 프로그램과 동일한 기능을 제공하지만 호스트에 직접 설치하는 대신 모든 종속 항목을 제공하는 컨테이너화된 환경에서 실행됩니다. 이를 사용하는 유일한 요구 사항은 컨테이너를 실행하는 기능입니다.

6.1.2.1. 설치 프로그램을 시스템 컨테이너로 실행

설치 프로그램 이미지는 시스템 컨테이너로 사용할 수 있습니다. 시스템 컨테이너는 기존 docker 서비스 외부에서 저장 및 실행됩니다. 이렇게 하면 호스트에서 Docker를 다시 시작하는 데 문제가 없는 대상 호스트 중 하나에서 설치 프로그램 이미지를 실행할 수 있습니다.

Atomic CLI를 사용하여 설치 프로그램을 런타임 시스템 컨테이너로 실행하려면 root 사용자로 다음 단계를 수행합니다.

  1. prerequisites.yml 플레이북을 실행합니다.

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml \
        --set OPTS="-v" \
        registry.redhat.io/openshift3/ose-ansible:v3.11
    1
    인벤토리 파일의 로컬 호스트의 위치를 지정합니다.

    이 명령은 지정된 인벤토리 파일 및 root 사용자의 SSH 구성을 사용하여 사전 요구 사항 작업 세트를 실행합니다.

  2. deploy_cluster.yml 플레이북을 실행합니다.

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml \
        --set OPTS="-v" \
        registry.redhat.io/openshift3/ose-ansible:v3.11
    1
    인벤토리 파일의 로컬 호스트의 위치를 지정합니다.

    이 명령은 지정된 인벤토리 파일과 root 사용자의 SSH 구성을 사용하여 클러스터 설치를 시작합니다. 터미널에 출력을 기록하고 /var/log/ansible.log 파일에 저장합니다. 이 명령을 처음 실행할 때 이미지를 OSTree 스토리지로 가져옵니다(시스템 컨테이너는 docker 데몬 스토리지 대신 이 값을 사용합니다). 후속 실행에서는 저장된 이미지를 재사용합니다.

    설치 프로그램을 다시 실행하기 전에 설치가 실패하는 경우 특정 명령 또는 해결 방법을 확인하기 위해 알려진 문제를 참조하십시오.

6.1.2.2. 다른 플레이북 실행

PLAYBOOK_FILE 환경 변수를 사용하여 컨테이너화된 설치 프로그램을 사용하여 실행할 다른 플레이북을 지정할 수 있습니다. PLAYBOOK_FILE 의 기본값은 /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 이지만 컨테이너 내부의 다른 플레이북의 경로로 설정할 수 있습니다.

예를 들어 설치 전에 사전 설치 검사 플레이북을 실행하려면 다음 명령을 사용합니다.

# atomic install --system \
    --storage=ostree \
    --set INVENTORY_FILE=/path/to/inventory \
    --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml \ 1
    --set OPTS="-v" \ 2
    registry.redhat.io/openshift3/ose-ansible:v3.11
1
PLAYBOOK_FILEplaybooks/ 디렉터리에서 시작하는 플레이북의 전체 경로로 설정합니다. 플레이북은 RPM 기반 설치 프로그램과 동일한 위치에 있습니다.
2
ansible-playbook 에 명령줄 옵션을 추가하려면 RuntimeClass S 를 설정합니다.
6.1.2.3. 설치 프로그램을 컨테이너로 실행

설치 프로그램 이미지는 docker 를 실행할 수 있는 Docker 컨테이너로도 실행할 수 있습니다.

주의

설치 프로그램이 호스트에서 docker 를 재시작하고 설치를 중단할 수 있으므로 이 방법을 사용하여 구성 중인 호스트 중 하나에서 설치 프로그램을 실행할 수 없습니다.

참고

이 방법과 위의 시스템 컨테이너 메서드는 동일한 이미지를 사용하지만 다른 진입점과 컨텍스트로 실행되므로 런타임 매개 변수는 동일하지 않습니다.

적어도 docker 컨테이너로 설치 프로그램을 실행하는 경우 다음을 제공해야 합니다.

  • Ansible이 호스트에 연결할 수 있도록 SSH 키.
  • Ansible 인벤토리 파일.
  • 해당 인벤토리에 대해 실행할 Ansible 플레이북의 위치입니다.

docker 를 통해 설치를 실행하는 방법의 예는 docker 에 대한 액세스 권한이 있는root 가 아닌 사용자가 실행해야 합니다.

  1. 먼저 prerequisites.yml 플레이북을 실행합니다.

    $ docker run -t -u `id -u` \ 1
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \ 2
        -v $HOME/ansible/hosts:/tmp/inventory:Z \ 3
        -e INVENTORY_FILE=/tmp/inventory \ 4
        -e PLAYBOOK_FILE=playbooks/prerequisites.yml \ 5
        -e OPTS="-v" \ 6
        registry.redhat.io/openshift3/ose-ansible:v3.11
    1
    -u 'id -u' 는 현재 사용자와 동일한 UID로 컨테이너를 실행하여 해당 사용자가 컨테이너 내에서 SSH 키를 사용할 수 있도록 합니다. SSH 개인 키는 소유자만 읽을 수 있어야 합니다.
    2
    -v $HOME/.ssh/id_rsa:/opt/app-root/.ssh/id_rsa:Z 는 컨테이너 사용자의 $HOME/.ssh/id_rsa 디렉터리에 SSH 키인 $HOME/.ssh /id_rsa를 마운트합니다. /opt/app-root/src 는 컨테이너에 있는 사용자의 $HOME 입니다. SSH 키를 다른 위치에 마운트하는 경우 -e ANSIBLE_PRIVATE_KEY_FILE=/the/mount/point 또는 ansible_ssh_private_key_file=/the/mount/point 를 인벤토리의 변수로 설정하여 Ansible을 가리키도록 환경 변수를 추가합니다. SSH 키는 :Z 플래그를 사용하여 마운트됩니다. 컨테이너가 제한된 SELinux 컨텍스트에서 SSH 키를 읽을 수 있도록 이 플래그가 필요합니다. 또한 원래 SSH 키 파일의 레이블이 system_u:object_r:container_file_t:s0:c113,c247 과 같은 항목에 다시 지정됩니다. :Z 에 대한 자세한 내용은 docker-run(1) 매뉴얼 페이지를 참조하십시오. 예를 들어 전체 $HOME/.ssh 디렉토리를 마운트(및 다시 레이블을 다시 레이블)하는 경우 호스트의 sshd 가 공개 키에 액세스하지 못하도록 차단되어 이러한 볼륨 마운트 사양을 제공하면 로그인할 수 있습니다. 따라서 원래 파일 레이블이 그대로 유지되도록 SSH 키 또는 디렉터리의 별도의 사본을 사용할 수 있습니다.
    3 4
    -V $HOME/ansible/hosts:/tmp/inventory:Z와 -e INVENTORY_FILE=/tmp/inventory 는 정적 Ansible 인벤토리 파일을 컨테이너에 /tmp/inventory 로 마운트한 후 해당 환경 변수를 해당 환경 변수를 가리키도록 설정합니다. SSH 키와 마찬가지로 기존 라벨에 따라 컨테이너에서 읽을 수 있도록 :Z 플래그를 사용하여 인벤토리 파일 SELinux 레이블을 다시 지정해야 할 수 있습니다. 사용자 $HOME 디렉터리의 파일의 경우 이 작업이 필요할 수 있습니다. 마운트하기 전에 인벤토리를 전용 위치에 복사하려고 할 수 있습니다. INVENTORY_URL 환경 변수를 지정하거나 DYNAMIC_SCRIPT_URL 매개변수를 사용하여 동적 인벤토리를 제공하는 실행 가능 스크립트를 지정하여 웹 서버에서 인벤토리 파일을 다운로드할 수도 있습니다.
    5
    -e PLAYBOOK_FILE=playbooks/prerequisites.ymlopenshift-ansible 콘텐츠의 최상위 디렉터리에서 상대 경로로 실행할 플레이북을 지정합니다. 이 예에서는 사전 요구 사항 플레이북을 지정합니다. RPM에서 전체 경로 또는 컨테이너의 다른 플레이북 파일의 경로를 지정할 수도 있습니다.
    6
    -EoctetsS="-v" 는 컨테이너 내에서 실행되는 ansible-playbook 명령에 임의의 명령행 옵션을 제공합니다. 이 예에서 세부 정보 표시를 늘리려면 -v 를 지정합니다.
  2. 다음으로 deploy_cluster.yml 플레이북을 실행하여 클러스터 설치를 시작합니다.

    $ docker run -t -u `id -u` \
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \
        -v $HOME/ansible/hosts:/tmp/inventory:Z \
        -e INVENTORY_FILE=/tmp/inventory \
        -e PLAYBOOK_FILE=playbooks/deploy_cluster.yml \
        -e OPTS="-v" \
        registry.redhat.io/openshift3/ose-ansible:v3.11
6.1.2.4. OpenStack용 설치 Playbook 실행

기존 OpenStack 설치에 OpenShift Container Platform을 설치하려면 OpenStack 플레이북을 사용합니다. 자세한 사전 요구 사항을 포함하여 플레이북에 대한 자세한 내용은 OpenStack Provisioning readme 파일을 참조하십시오.

Playbook을 실행하려면 다음 명령을 실행합니다.

$ ansible-playbook --user openshift \
  -i openshift-ansible/playbooks/openstack/inventory.py \
  -i inventory \
  openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml

6.1.3. 설치 플레이북 정보

설치 프로그램은 모듈식 플레이북을 사용하므로 관리자가 필요에 따라 특정 구성 요소를 설치할 수 있습니다. 역할 및 플레이북을 분리하면 애드혹 관리 작업을 더 잘 목표로 지정할 수 있습니다. 이로 인해 설치 중에 제어 수준이 높아지고 시간이 단축됩니다.

기본 설치 플레이북 /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 은 특정 순서로 개별 구성 요소 플레이북 세트를 실행하고 설치 프로그램이 어떤 단계를 반복했는지 보고합니다. 설치에 실패하면 Ansible 실행 오류와 함께 어떤 단계가 실패했는지 알 수 있습니다.

중요

RHEL Atomic Host는 OpenShift Container Platform 서비스를 시스템 컨테이너로 실행하는 데 지원되지만 설치 방법은 RHEL Atomic Host에서 사용할 수 없는 Ansible을 사용합니다. 따라서 RPM 기반 설치 프로그램은 RHEL 7 시스템에서 실행해야 합니다. 설치를 시작하는 호스트는 OpenShift Container Platform 클러스터에 포함하기위한 것이 아니라 다음 작업을 수행할 수 있습니다. 또는 컨테이너화된 버전의 설치 프로그램을 RHEL Atomic Host 시스템에서 실행할 수 있는 시스템 컨테이너로 사용할 수 있습니다.

6.2. 설치 재시도

Ansible 설치 프로그램이 실패하는 경우에도 OpenShift Container Platform을 설치할 수 있습니다.

  1. 특정 지침 또는 해결 방법을 확인하려면 Known issues 를 검토하십시오.
  2. 설치에서 오류를 해결합니다.
  3. 설치를 제거하고 다시 설치해야 하는지 확인합니다.

    • SDN 구성을 수정하거나 새 인증서를 생성하지 않은 경우 설치를 다시 시도합니다.
    • SDN 구성을 수정하거나 새 인증서를 생성하거나 설치 프로그램이 다시 실패하면 정리 운영 체제 설치로 처음부터 다시 시작하거나 다시 설치해야 합니다. ???
    • 가상 머신을 사용하는 경우 새 이미지에서 시작하거나 설치 다시 설치합니다.
    • 베어 메탈 머신을 사용하는 경우 를 제거하고 다시 설치합니다.
  4. 설치를 다시 시도합니다.

    • deploy_cluster.yml 플레이북을 다시 실행할 수 있습니다.
    • 나머지 개별 설치 플레이북을 실행할 수 있습니다.

      나머지 플레이북만 실행하려면 실패한 단계에 대해 플레이북을 실행하여 시작한 다음 나머지 플레이북을 순서대로 실행합니다. 다음 명령을 사용하여 각 플레이북을 실행합니다.

      # ansible-playbook [-i /path/to/inventory] <playbook_file_location>

      다음 표에는 플레이북을 실행해야 하는 순서대로 나열되어 있습니다.

      표 6.1. 개별 구성 요소 플레이북 실행 순서
      플레이북 이름파일 위치

      상태 점검

      /usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml

      노드 부트 스트랩

      /usr/share/ansible/openshift-ansible/playbooks/openshift-node/bootstrap.yml

      etcd 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/config.yml

      NFS 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-nfs/config.yml

      로드 밸런서 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-loadbalancer/config.yml

      마스터 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-master/config.yml

      마스터 추가 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-master/additional_config.yml

      노드 공동 작업

      /usr/share/ansible/openshift-ansible/playbooks/openshift-node/join.yml

      glusterfs 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml

      호스트 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/config.yml

      설치 모니터링

      /usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml

      웹 콘솔 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-web-console/config.yml

      관리 콘솔 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-console/config.yml

      지표 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml

      metrics-server

      /usr/share/ansible/openshift-ansible/playbooks/metrics-server/config.yml

      로깅 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

      가용성 모니터링 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-monitor-availability/config.yml

      서비스 카탈로그 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-service-catalog/config.yml

      관리 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.yml

      Descheduler 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-descheduler/config.yml

      Node Problem Detector 설치

      /usr/share/ansible/openshift-ansible/playbooks/openshift-node-problem-detector/config.yml

      OLM(Operator Lifecycle Manager) 설치(기술 프리뷰)

      /usr/share/ansible/openshift-ansible/playbooks/olm/config.yml

6.3. 설치 확인

설치가 완료된 후 다음을 수행합니다.

  1. 마스터가 시작되고 노드가 등록되어 Ready 상태로 보고되었는지 확인합니다. 마스터 호스트에서 root로 다음 명령을 실행합니다.

    # oc get nodes
    NAME                   STATUS    ROLES     AGE       VERSION
    master.example.com     Ready     master    7h        v1.9.1+a0ce1bc657
    node1.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
    node2.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
  2. 웹 콘솔이 올바르게 설치되었는지 확인하려면 마스터 호스트 이름과 웹 콘솔 포트 번호를 사용하여 웹 브라우저로 웹 콘솔에 액세스합니다.

    예를 들어 호스트 이름이 master.openshift.com 이고 기본 포트 8443 을 사용하는 마스터 호스트의 경우 웹 콘솔 URL은 https://master.openshift.com:8443/console 입니다.

여러 etcd 호스트 확인

여러 etcd 호스트를 설치한 경우:

  1. 먼저 etcd ctl 명령을 제공하는 etcd 패키지가 설치되었는지 확인합니다.

    # yum install etcd
  2. 마스터 호스트에서 etcd 클러스터 상태를 확인하고 etcd 호스트의 FQDN을 다음과 같이 대체합니다.

    # etcdctl -C \
        https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \
        --ca-file=/etc/origin/master/master.etcd-ca.crt \
        --cert-file=/etc/origin/master/master.etcd-client.crt \
        --key-file=/etc/origin/master/master.etcd-client.key cluster-health
  3. 또한 멤버 목록이 올바른지 확인합니다.

    # etcdctl -C \
        https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \
        --ca-file=/etc/origin/master/master.etcd-ca.crt \
        --cert-file=/etc/origin/master/master.etcd-client.crt \
        --key-file=/etc/origin/master/master.etcd-client.key member list
HAProxy를 사용하여 여러 마스터 확인

HAProxy를 로드 밸런서로 사용하여 여러 마스터를 설치한 경우 다음 URL을 열고 HAProxy의 상태를 확인합니다.

http://<lb_hostname>:9000 1
1
인벤토리 파일의 [lb] 섹션에 나열된 로드 밸런서 호스트 이름을 제공합니다.

HAProxy 구성 설명서 를 참조하여 설치를 확인할 수 있습니다.

6.4. 선택적으로 빌드 보안

Docker 빌드 실행은 권한 있는 프로세스이므로 일부 다중 테넌트 환경에서 컨테이너에 허용 가능한 것으로 간주될 수 있는 것보다 컨테이너에 더 많은 액세스 권한이 있습니다. 사용자를 신뢰하지 않으면 설치 후 더 안전한 옵션을 구성할 수 있습니다. 클러스터에서 Docker 빌드를 비활성화하고 사용자가 클러스터 외부에서 이미지를 빌드해야 합니다. 이 선택적 프로세스에 대한 자세한 내용은 전략별 빌드 보안을 참조하십시오.

6.5. 확인된 문제

  • 여러 마스터 클러스터의 장애 조치(failover)에서는 컨트롤러 관리자가 이 문제를 해결할 수 있으므로 시스템이 의도한 것보다 더 많은 Pod를 실행할 수 있습니다. 그러나 이는 일시적인 이벤트이며 시간이 지남에 따라 시스템이 자체적으로 올바르게 수행됩니다. 자세한 내용은 https://github.com/kubernetes/kubernetes/issues/10030 을 참조하십시오.
  • 알려진 문제로 인해 설치를 실행한 후 구성 요소에 NFS 볼륨이 프로비저닝되면 구성 요소가 NFS 볼륨에 배포되는지 여부에 관계없이 다음 디렉터리가 생성될 수 있습니다.

    • /exports/logging-es
    • /exports/logging-es-ops/
    • /exports/metrics/
    • /exports/prometheus
    • /exports/prometheus-alertbuffer/
    • /exports/prometheus-alertmanager/

      필요에 따라 설치 후 이러한 디렉터리를 삭제할 수 있습니다.

6.6. 다음 단계는 무엇입니까?

작동하는 OpenShift Container Platform 인스턴스가 있으므로 다음을 수행할 수 있습니다.

7장. 연결이 끊긴 설치

종종 데이터 센터의 일부는 프록시 서버를 통해 인터넷에 액세스하지 못할 수 있습니다. 이러한 환경에 OpenShift Container Platform을 계속 설치할 수 있지만 필수 소프트웨어 및 이미지를 다운로드하여 연결이 끊긴 환경에서 사용할 수 있도록 해야 합니다.

노드 호스트에서 설치 구성 요소를 사용할 수 있게 되면 표준 설치 단계에 따라 OpenShift Container Platform을 설치합니다.

OpenShift Container Platform을 설치한 후 클러스터에서 가져온 S2I 빌더 이미지를 만들어야 합니다.

7.1. 사전 요구 사항

  • OpenShift Container Platform의 전체 아키텍처를 검토하고 환경 토폴로지를 계획합니다.
  • 인터넷에 액세스할 수 있고 최소 110GB의 디스크 공간이 있는 RHEL (Red Hat Enterprise Linux) 7 서버를 받으십시오. 필요한 소프트웨어 리포지토리 및 컨테이너 이미지를 이 컴퓨터에 다운로드합니다.
  • 미러링된 저장소를 제공하기 위해 연결이 끊긴 환경 내에서 웹 서버를 유지 관리할 계획입니다. 네트워크를 통해 또는 연결이 끊긴 배포에서 물리적 미디어를 사용하여 인터넷에 연결된 호스트에서 이 웹 서버로 리포지토리를 복사합니다.
  • 소스 제어 리포지토리를 제공합니다. 설치 후 노드는 Git과 같은 소스 코드 리포지토리의 소스 코드에 액세스해야 합니다.

    OpenShift Container Platform에서 애플리케이션을 빌드할 때 빌드에 Ruby 애플리케이션의 Maven 리포지토리 또는 Gem 파일과 같은 외부 종속성이 포함될 수 있습니다.

  • 연결이 끊긴 환경 내에 레지스트리를 제공합니다. 옵션은 다음과 같습니다.

7.2. 필수 소프트웨어 패키지 및 이미지 가져오기

연결이 끊긴 환경에 OpenShift Container Platform을 설치하기 전에 필요한 이미지 및 구성 요소를 가져와서 리포지토리에 저장합니다.

중요

연결이 끊긴 환경에 있는 클러스터와 동일한 아키텍처가 있는 시스템에서 필요한 이미지 및 소프트웨어 구성 요소를 가져와야 합니다.

7.2.1. OpenShift Container Platform 패키지 가져오기

인터넷 연결이 있는 RHEL 7 서버에서 리포지토리를 동기화합니다.

  1. 리포지토리를 동기화한 후 패키지가 삭제되지 않도록 하려면 GPG 키를 가져옵니다.

    $ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
  2. Red Hat 고객 포털에 서버를 등록합니다. OpenShift Container Platform 서브스크립션에 액세스할 수 있는 계정과 연결된 인증 정보를 사용해야 합니다.

    $ subscription-manager register
  3. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

    $ subscription-manager refresh
  4. OpenShift Container Platform 채널을 제공하는 서브스크립션을 연결합니다.

    1. OpenShift Container Platform 채널을 제공하는 사용 가능한 서브스크립션 풀을 검색합니다.

      $ subscription-manager list --available --matches '*OpenShift*'
    2. OpenShift Container Platform을 제공하는 서브스크립션의 풀 ID를 연결합니다.

      $ subscription-manager attach --pool=<pool_id>
      $ subscription-manager repos --disable="*"
  5. OpenShift Container Platform 3.11에 필요한 리포지토리를 활성화합니다.

    • x86_64 서버에 클라우드 설치 및 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-server-rpms" \
          --enable="rhel-7-server-extras-rpms" \
          --enable="rhel-7-server-ose-3.11-rpms" \
          --enable="rhel-7-server-ansible-2.9-rpms"
    • IBM POWER8 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-for-power-le-rpms" \
          --enable="rhel-7-for-power-le-extras-rpms" \
          --enable="rhel-7-for-power-le-optional-rpms" \
          --enable="rhel-7-server-ansible-2.9-for-power-le-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.11-rpms"
    • IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      # subscription-manager repos \
          --enable="rhel-7-for-power-9-rpms" \
          --enable="rhel-7-for-power-9-extras-rpms" \
          --enable="rhel-7-for-power-9-optional-rpms" \
          --enable="rhel-7-server-ansible-2.9-for-power-9-rpms" \
          --enable="rhel-7-server-for-power-9-rhscl-rpms" \
          --enable="rhel-7-for-power-9-ose-3.11-rpms"
    참고

    이전 버전의 OpenShift Container Platform 3.11은 Ansible 2.6만 지원했습니다. 최신 버전의 플레이북에서는 이제 사용할 기본 버전인 Ansible 2.9를 지원합니다.

  6. 필수 패키지를 설치합니다.

    $ sudo yum -y install yum-utils createrepo docker git

    yum-utils 패키지는 yum 리포지토리를 미러링할 수 있는 reposync 유틸리티를 제공하며, createrepo 패키지를 사용하여 디렉터리에서 사용 가능한 yum 리포지토리를 생성할 수 있습니다.

  7. 소프트웨어를 서버의 스토리지 또는 USB 드라이브 또는 기타 외부 장치에 저장할 디렉토리를 만듭니다.

    $ mkdir -p </path/to/repos>
    중요

    이 서버를 연결 해제된 LAN에 다시 연결하고 리포지토리 서버로 사용할 수 있는 경우 파일을 로컬에 저장합니다. USB 연결 스토리지를 사용할 수 없는 경우 소프트웨어를 연결이 끊긴 LAN의 리포지토리 서버로 전송할 수 있습니다.

  8. 패키지를 동기화하고 각각에 대한 리포지토리를 생성합니다.

    • x86_64 서버의 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ for repo in \
        rhel-7-server-rpms \
        rhel-7-server-extras-rpms \
        rhel-7-server-ansible-2.9-rpms \
        rhel-7-server-ose-3.11-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=</path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      생성한 디렉터리의 경로를 제공합니다.
    • IBM POWER8 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ for repo in \
        rhel-7-for-power-le-rpms \
        rhel-7-for-power-le-extras-rpms \
        rhel-7-for-power-le-optional-rpms \
        rhel-7-server-ansible-2.9-for-power-le-rpms \
        rhel-7-server-for-power-le-rhscl-rpms \
        rhel-7-for-power-le-ose-3.11-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=</path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      생성한 디렉터리의 경로를 제공합니다.
    • IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ for repo in \
        rhel-7-for-power-9-rpms \
        rhel-7-for-power-9-extras-rpms \
        rhel-7-for-power-9-optional-rpms \
        rhel-7-server-ansible-2.9-for-power-9-rpms \
        rhel-7-server-for-power-9-rhscl-rpms \
        rhel-7-for-power-9-ose-3.11-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=/<path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      생성한 디렉터리의 경로를 제공합니다.

7.2.2. 이미지 가져오기

필요한 컨테이너 이미지를 가져옵니다.

  1. Docker 데몬을 시작합니다.

    $ systemctl start docker
  2. 필요한 모든 OpenShift Container Platform 인프라 구성 요소 이미지를 가져옵니다. & lt;tag& gt;를 설치할 버전으로 바꿉니다. 예를 들어 최신 버전에 v3.11.634 를 지정합니다. 다른 마이너 버전을 지정할 수 있습니다. 컨테이너화된 설치 프로그램을 사용하는 경우 다음 필요한 이미지 외에도 registry.redhat.io/openshift3/ose-ansible:v3.11 를 가져옵니다.

    $ docker pull registry.redhat.io/openshift3/apb-base:<tag>
    $ docker pull registry.redhat.io/openshift3/apb-tools:<tag>
    $ docker pull registry.redhat.io/openshift3/automation-broker-apb:<tag>
    $ docker pull registry.redhat.io/openshift3/csi-attacher:<tag>
    $ docker pull registry.redhat.io/openshift3/csi-driver-registrar:<tag>
    $ docker pull registry.redhat.io/openshift3/csi-livenessprobe:<tag>
    $ docker pull registry.redhat.io/openshift3/csi-provisioner:<tag>
    $ docker pull registry.redhat.io/openshift3/grafana:<tag>
    $ docker pull registry.redhat.io/openshift3/kuryr-controller:<tag>
    $ docker pull registry.redhat.io/openshift3/kuryr-cni:<tag>
    $ docker pull registry.redhat.io/openshift3/local-storage-provisioner:<tag>
    $ docker pull registry.redhat.io/openshift3/manila-provisioner:<tag>
    $ docker pull registry.redhat.io/openshift3/mariadb-apb:<tag>
    $ docker pull registry.redhat.io/openshift3/mediawiki:<tag>
    $ docker pull registry.redhat.io/openshift3/mediawiki-apb:<tag>
    $ docker pull registry.redhat.io/openshift3/mysql-apb:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-ansible-service-broker:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-cli:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-cluster-autoscaler:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-cluster-capacity:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-cluster-monitoring-operator:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-console:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-configmap-reloader:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-control-plane:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-deployer:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-descheduler:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-docker-builder:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-docker-registry:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-efs-provisioner:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-egress-dns-proxy:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-egress-http-proxy:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-egress-router:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-haproxy-router:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-hyperkube:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-hypershift:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-keepalived-ipfailover:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-kube-rbac-proxy:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-kube-state-metrics:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-metrics-server:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-node:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-node-problem-detector:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-operator-lifecycle-manager:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-ovn-kubernetes:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-pod:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-prometheus-config-reloader:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-prometheus-operator:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-recycler:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-service-catalog:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-template-service-broker:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-tests:<tag>
    $ docker pull registry.redhat.io/openshift3/ose-web-console:<tag>
    $ docker pull registry.redhat.io/openshift3/postgresql-apb:<tag>
    $ docker pull registry.redhat.io/openshift3/registry-console:<tag>
    $ docker pull registry.redhat.io/openshift3/snapshot-controller:<tag>
    $ docker pull registry.redhat.io/openshift3/snapshot-provisioner:<tag>
    $ docker pull registry.redhat.io/rhel7/etcd:3.2.28
  3. x86_64 서버에 온프레미스 설치의 경우 다음 이미지를 가져옵니다. & lt;tag& gt;를 설치할 버전으로 바꿉니다. 예를 들어 최신 버전에 v3.11.634 를 지정합니다. 다른 마이너 버전을 지정할 수 있습니다.

    $ docker pull registry.redhat.io/openshift3/ose-efs-provisioner:<tag>
  4. 선택적 구성 요소에 필요한 모든 OpenShift Container Platform 구성 요소 이미지를 가져옵니다. & lt;tag& gt;를 설치할 버전으로 바꿉니다. 예를 들어 최신 버전에 v3.11.634 를 지정합니다. 다른 마이너 버전을 지정할 수 있습니다.

    • x86_64 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker pull registry.redhat.io/openshift3/metrics-cassandra:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-hawkular-metrics:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-hawkular-openshift-agent:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-heapster:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-schema-installer:<tag>
      $ docker pull registry.redhat.io/openshift3/oauth-proxy:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-curator5:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-elasticsearch5:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-eventrouter:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-fluentd:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-kibana5:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus-alertmanager:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus-node-exporter:<tag>
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-postgresql
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-memcached
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-app-ui
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-app
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-embedded-ansible
      $ docker pull registry.redhat.io/cloudforms46/cfme-openshift-httpd
      $ docker pull registry.redhat.io/cloudforms46/cfme-httpd-configmap-generator
      $ docker pull registry.redhat.io/rhgs3/rhgs-server-rhel7
      $ docker pull registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
      $ docker pull registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7
      $ docker pull registry.redhat.io/rhgs3/rhgs-s3-server-rhel7
    • IBM POWER8 또는 IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker pull registry.redhat.io/openshift3/metrics-cassandra:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-hawkular-openshift-agent:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-heapster:<tag>
      $ docker pull registry.redhat.io/openshift3/metrics-schema-installer:<tag>
      $ docker pull registry.redhat.io/openshift3/oauth-proxy:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-curator5:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-elasticsearch5:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-eventrouter:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-fluentd:<tag>
      $ docker pull registry.redhat.io/openshift3/ose-logging-kibana5:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus-alert-buffer:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus-alertmanager:<tag>
      $ docker pull registry.redhat.io/openshift3/prometheus-node-exporter:<tag>
    중요

    Red Hat 지원을 받으려면 rhgs3/ 이미지에 통합 모드 서브스크립션이 필요합니다.

  5. OpenShift Container Platform 환경에서 사용하려는 Red Hat 인증 S 2I(Source-to-Image) 빌더 이미지를 가져옵니다.

    버전 번호를 지정하여 올바른 태그를 지정해야 합니다. 이미지 버전 호환성에 대한 자세한 내용은 OpenShift 및 Atomic Platform 테스트 통합 페이지의 S2I 표를 참조하십시오.

    다음 이미지를 가져올 수 있습니다.

    $ docker pull registry.redhat.io/jboss-amq-6/amq63-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-datagrid-7/datagrid71-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-datagrid-7/datagrid71-client-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-datavirt-6/datavirt63-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-datavirt-6/datavirt63-driver-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-decisionserver-6/decisionserver64-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-processserver-6/processserver64-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-eap-6/eap64-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-eap-7/eap71-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-webserver-3/webserver31-tomcat7-openshift:<tag>
    $ docker pull registry.redhat.io/jboss-webserver-3/webserver31-tomcat8-openshift:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-2-rhel7:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-agent-maven-35-rhel7:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-agent-nodejs-8-rhel7:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-slave-base-rhel7:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-slave-maven-rhel7:<tag>
    $ docker pull registry.redhat.io/openshift3/jenkins-slave-nodejs-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/mongodb-32-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/mysql-57-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/perl-524-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/php-56-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/postgresql-95-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/python-35-rhel7:<tag>
    $ docker pull registry.redhat.io/redhat-sso-7/sso70-openshift:<tag>
    $ docker pull registry.redhat.io/rhscl/ruby-24-rhel7:<tag>
    $ docker pull registry.redhat.io/redhat-openjdk-18/openjdk18-openshift:<tag>
    $ docker pull registry.redhat.io/redhat-sso-7/sso71-openshift:<tag>
    $ docker pull registry.redhat.io/rhscl/nodejs-6-rhel7:<tag>
    $ docker pull registry.redhat.io/rhscl/mariadb-101-rhel7:<tag>

7.2.3. 이미지 내보내기

환경에서 내부 네트워크에 액세스할 수 없으며 콘텐츠를 전송하기 위해 물리적 미디어가 필요한 경우 이미지를 압축된 파일로 내보냅니다. 호스트가 인터넷과 내부 네트워크에 모두 연결되어 있는 경우 다음 단계를 건너뛰고 계속 리포지토리 서버 준비 및 채우기.

  1. 압축 이미지를 저장하고 다음으로 변경하는 디렉토리를 만듭니다.

    $ mkdir </path/to/images>
    $ cd </path/to/images>
  2. OpenShift Container Platform 인프라 구성 요소 이미지를 내보냅니다. 컨테이너화된 설치 프로그램을 사용하는 경우 다음 필요한 이미지 외에도 registry.redhat.io/openshift3/ose-ansible:v3.11 를 내보냅니다.

    • x86_64 서버의 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker save -o ose3-images.tar \
          registry.redhat.io/openshift3/apb-base \
          registry.redhat.io/openshift3/apb-tools \
          registry.redhat.io/openshift3/automation-broker-apb \
          registry.redhat.io/openshift3/csi-attacher \
          registry.redhat.io/openshift3/csi-driver-registrar \
          registry.redhat.io/openshift3/csi-livenessprobe \
          registry.redhat.io/openshift3/csi-provisioner \
          registry.redhat.io/openshift3/grafana \
          registry.redhat.io/openshift3/kuryr-controller \
          registry.redhat.io/openshift3/kuryr-cni \
          registry.redhat.io/openshift3/local-storage-provisioner \
          registry.redhat.io/openshift3/manila-provisioner \
          registry.redhat.io/openshift3/mariadb-apb \
          registry.redhat.io/openshift3/mediawiki \
          registry.redhat.io/openshift3/mediawiki-apb \
          registry.redhat.io/openshift3/mysql-apb \
          registry.redhat.io/openshift3/ose-ansible-service-broker \
          registry.redhat.io/openshift3/ose-cli \
          registry.redhat.io/openshift3/ose-cluster-autoscaler \
          registry.redhat.io/openshift3/ose-cluster-capacity \
          registry.redhat.io/openshift3/ose-cluster-monitoring-operator \
          registry.redhat.io/openshift3/ose-console \
          registry.redhat.io/openshift3/ose-configmap-reloader \
          registry.redhat.io/openshift3/ose-control-plane \
          registry.redhat.io/openshift3/ose-deployer \
          registry.redhat.io/openshift3/ose-descheduler \
          registry.redhat.io/openshift3/ose-docker-builder \
          registry.redhat.io/openshift3/ose-docker-registry \
          registry.redhat.io/openshift3/ose-efs-provisioner \
          registry.redhat.io/openshift3/ose-egress-dns-proxy \
          registry.redhat.io/openshift3/ose-egress-http-proxy \
          registry.redhat.io/openshift3/ose-egress-router \
          registry.redhat.io/openshift3/ose-haproxy-router \
          registry.redhat.io/openshift3/ose-hyperkube \
          registry.redhat.io/openshift3/ose-hypershift \
          registry.redhat.io/openshift3/ose-keepalived-ipfailover \
          registry.redhat.io/openshift3/ose-kube-rbac-proxy \
          registry.redhat.io/openshift3/ose-kube-state-metrics \
          registry.redhat.io/openshift3/ose-metrics-server \
          registry.redhat.io/openshift3/ose-node \
          registry.redhat.io/openshift3/ose-node-problem-detector \
          registry.redhat.io/openshift3/ose-operator-lifecycle-manager \
          registry.redhat.io/openshift3/ose-ovn-kubernetes \
          registry.redhat.io/openshift3/ose-pod \
          registry.redhat.io/openshift3/ose-prometheus-config-reloader \
          registry.redhat.io/openshift3/ose-prometheus-operator \
          registry.redhat.io/openshift3/ose-recycler \
          registry.redhat.io/openshift3/ose-service-catalog \
          registry.redhat.io/openshift3/ose-template-service-broker \
          registry.redhat.io/openshift3/ose-tests \
          registry.redhat.io/openshift3/ose-web-console \
          registry.redhat.io/openshift3/postgresql-apb \
          registry.redhat.io/openshift3/registry-console \
          registry.redhat.io/openshift3/snapshot-controller \
          registry.redhat.io/openshift3/snapshot-provisioner \
          registry.redhat.io/rhel7/etcd:3.2.28 \
    • IBM POWER8 또는 IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker save -o ose3-images.tar \
          registry.redhat.io/openshift3/apb-base \
          registry.redhat.io/openshift3/apb-tools \
          registry.redhat.io/openshift3/automation-broker-apb \
          registry.redhat.io/openshift3/csi-attacher \
          registry.redhat.io/openshift3/csi-driver-registrar \
          registry.redhat.io/openshift3/csi-livenessprobe \
          registry.redhat.io/openshift3/csi-provisioner \
          registry.redhat.io/openshift3/grafana \
          registry.redhat.io/openshift3/kuryr-controller \
          registry.redhat.io/openshift3/kuryr-cni \
          registry.redhat.io/openshift3/local-storage-provisioner \
          registry.redhat.io/openshift3/manila-provisioner \
          registry.redhat.io/openshift3/mariadb-apb \
          registry.redhat.io/openshift3/mediawiki \
          registry.redhat.io/openshift3/mediawiki-apb \
          registry.redhat.io/openshift3/mysql-apb \
          registry.redhat.io/openshift3/ose-ansible-service-broker \
          registry.redhat.io/openshift3/ose-cli \
          registry.redhat.io/openshift3/ose-cluster-autoscaler \
          registry.redhat.io/openshift3/ose-cluster-capacity \
          registry.redhat.io/openshift3/ose-cluster-monitoring-operator \
          registry.redhat.io/openshift3/ose-console \
          registry.redhat.io/openshift3/ose-configmap-reloader \
          registry.redhat.io/openshift3/ose-control-plane \
          registry.redhat.io/openshift3/ose-deployer \
          registry.redhat.io/openshift3/ose-descheduler \
          registry.redhat.io/openshift3/ose-docker-builder \
          registry.redhat.io/openshift3/ose-docker-registry \
          registry.redhat.io/openshift3/ose-egress-dns-proxy \
          registry.redhat.io/openshift3/ose-egress-http-proxy \
          registry.redhat.io/openshift3/ose-egress-router \
          registry.redhat.io/openshift3/ose-haproxy-router \
          registry.redhat.io/openshift3/ose-hyperkube \
          registry.redhat.io/openshift3/ose-hypershift \
          registry.redhat.io/openshift3/ose-keepalived-ipfailover \
          registry.redhat.io/openshift3/ose-kube-rbac-proxy \
          registry.redhat.io/openshift3/ose-kube-state-metrics \
          registry.redhat.io/openshift3/ose-metrics-server \
          registry.redhat.io/openshift3/ose-node \
          registry.redhat.io/openshift3/ose-node-problem-detector \
          registry.redhat.io/openshift3/ose-operator-lifecycle-manager \
          registry.redhat.io/openshift3/ose-ovn-kubernetes \
          registry.redhat.io/openshift3/ose-pod \
          registry.redhat.io/openshift3/ose-prometheus-config-reloader \
          registry.redhat.io/openshift3/ose-prometheus-operator \
          registry.redhat.io/openshift3/ose-recycler \
          registry.redhat.io/openshift3/ose-service-catalog \
          registry.redhat.io/openshift3/ose-template-service-broker \
          registry.redhat.io/openshift3/ose-tests \
          registry.redhat.io/openshift3/ose-web-console \
          registry.redhat.io/openshift3/postgresql-apb \
          registry.redhat.io/openshift3/registry-console \
          registry.redhat.io/openshift3/snapshot-controller \
          registry.redhat.io/openshift3/snapshot-provisioner \
          registry.redhat.io/rhel7/etcd:3.2.28 \
  3. 선택적 구성 요소에 대한 이미지를 동기화한 경우 내보냅니다.

    • x86_64 서버의 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker save -o ose3-optional-imags.tar \
          registry.redhat.io/openshift3/metrics-cassandra \
          registry.redhat.io/openshift3/metrics-hawkular-metrics \
          registry.redhat.io/openshift3/metrics-hawkular-openshift-agent \
          registry.redhat.io/openshift3/metrics-heapster \
          registry.redhat.io/openshift3/metrics-schema-installer \
          registry.redhat.io/openshift3/oauth-proxy \
          registry.redhat.io/openshift3/ose-logging-curator5 \
          registry.redhat.io/openshift3/ose-logging-elasticsearch5 \
          registry.redhat.io/openshift3/ose-logging-eventrouter \
          registry.redhat.io/openshift3/ose-logging-fluentd \
          registry.redhat.io/openshift3/ose-logging-kibana5 \
          registry.redhat.io/openshift3/prometheus \
          registry.redhat.io/openshift3/prometheus-alertmanager \
          registry.redhat.io/openshift3/prometheus-node-exporter \
          registry.redhat.io/cloudforms46/cfme-openshift-postgresql \
          registry.redhat.io/cloudforms46/cfme-openshift-memcached \
          registry.redhat.io/cloudforms46/cfme-openshift-app-ui \
          registry.redhat.io/cloudforms46/cfme-openshift-app \
          registry.redhat.io/cloudforms46/cfme-openshift-embedded-ansible \
          registry.redhat.io/cloudforms46/cfme-openshift-httpd \
          registry.redhat.io/cloudforms46/cfme-httpd-configmap-generator \
          registry.redhat.io/rhgs3/rhgs-server-rhel7 \
          registry.redhat.io/rhgs3/rhgs-volmanager-rhel7 \
          registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7 \
          registry.redhat.io/rhgs3/rhgs-s3-server-rhel7 \
    • IBM POWER8 또는 IBM POWER9 서버에 온프레미스 설치의 경우 다음 명령을 실행합니다.

      $ docker save -o ose3-optional-imags.tar \
          registry.redhat.io/openshift3/metrics-cassandra \
          registry.redhat.io/openshift3/metrics-hawkular-openshift-agent \
          registry.redhat.io/openshift3/metrics-heapster \
          registry.redhat.io/openshift3/metrics-schema-installer \
          registry.redhat.io/openshift3/oauth-proxy \
          registry.redhat.io/openshift3/ose-logging-curator5 \
          registry.redhat.io/openshift3/ose-logging-elasticsearch5 \
          registry.redhat.io/openshift3/ose-logging-eventrouter \
          registry.redhat.io/openshift3/ose-logging-fluentd \
          registry.redhat.io/openshift3/ose-logging-kibana5 \
          registry.redhat.io/openshift3/prometheus \
          registry.redhat.io/openshift3/prometheus-alert-buffer \
          registry.redhat.io/openshift3/prometheus-alertmanager \
          registry.redhat.io/openshift3/prometheus-node-exporter \
  4. 가져온 S2I 빌더 이미지를 내보냅니다. 예를 들어 Jenkins 및 Tomcat 이미지만 동기화한 경우 다음을 수행합니다.

    $ docker save -o ose3-builder-images.tar \
        registry.redhat.io/jboss-webserver-3/webserver31-tomcat7-openshift:<tag> \
        registry.redhat.io/jboss-webserver-3/webserver31-tomcat8-openshift:<tag> \
        registry.redhat.io/openshift3/jenkins-2-rhel7:<tag> \
        registry.redhat.io/openshift3/jenkins-agent-maven-35-rhel7:<tag> \
        registry.redhat.io/openshift3/jenkins-agent-nodejs-8-rhel7:<tag> \
        registry.redhat.io/openshift3/jenkins-slave-base-rhel7:<tag> \
        registry.redhat.io/openshift3/jenkins-slave-maven-rhel7:<tag> \
        registry.redhat.io/openshift3/jenkins-slave-nodejs-rhel7:<tag> \
  5. 인터넷에 연결된 호스트의 압축 파일을 내부 호스트로 복사합니다.
  6. 복사한 이미지를 로드합니다.

    $ docker load -i ose3-images.tar
    $ docker load -i ose3-builder-images.tar
    $ docker load -i ose3-optional-images.tar

7.3. 리포지토리 서버 준비 및 채우기

설치 중 및 향후 업데이트 중에 소프트웨어를 호스팅하려면 웹 서버가 필요합니다. RHEL 7은 Apache 웹 서버를 제공할 수 있습니다.

  1. 웹 서버를 준비합니다.

    1. 연결이 끊긴 환경에 새 웹 서버를 설치해야 하는 경우 LAN에 110GB 이상의 공간이 있는 새 RHEL 7 시스템을 설치합니다. RHEL 설치 중에 Basic Web Server 옵션을 선택합니다.
    2. OpenShift Container Platform 소프트웨어 및 필수 이미지를 다운로드한 서버를 다시 사용하는 경우 서버에 Apache를 설치합니다.

      $ sudo yum install httpd
  2. 리포지토리 파일을 Apache의 루트 폴더에 배치합니다.

    • 서버를 다시 사용하는 경우:

      $ mv /path/to/repos /var/www/html/
      $ chmod -R +r /var/www/html/repos
      $ restorecon -vR /var/www/html
    • 새 서버를 설치한 경우 외부 스토리지를 연결한 다음 파일을 복사합니다.

      $ cp -a /path/to/repos /var/www/html/
      $ chmod -R +r /var/www/html/repos
      $ restorecon -vR /var/www/html
  3. 방화벽 규칙을 추가합니다.

    $ sudo firewall-cmd --permanent --add-service=http
    $ sudo firewall-cmd --reload
  4. 변경 사항을 적용하려면 Apache를 활성화하고 시작합니다.

    $ systemctl enable httpd
    $ systemctl start httpd

7.4. 레지스트리 채우기

연결이 끊긴 환경에서 이미지를 태그를 지정하고 내부 레지스트리로 내보냅니다.

중요

다음 단계는 이미지를 레지스트리에 로드하는 일반적인 가이드입니다. 이미지를 로드하려면 더 많은 또는 다른 작업을 수행해야 할 수 있습니다.

  1. 이미지를 레지스트리로 푸시하기 전에 각 이미지를 다시 태그합니다.

    • openshift3 리포지토리의 이미지의 경우 이미지를 주요 버전 번호와 마이너 버전 번호로 태그를 지정합니다. 예를 들어 OpenShift Container Platform 노드 이미지를 태그하려면 다음을 수행합니다.

      $ docker tag registry.redhat.io/openshift3/ose-node:<tag> registry.example.com/openshift3/ose-node:<tag>
      $ docker tag registry.redhat.io/openshift3/ose-node:<tag> registry.example.com/openshift3/ose-node:{major-tag}
    • 다른 이미지의 경우 이미지에 정확한 버전 번호로 태그를 지정합니다. 예를 들어 etcd 이미지에 태그를 지정하려면 다음을 수행합니다.

      $ docker tag registry.redhat.io/rhel7/etcd:3.2.28 registry.example.com/rhel7/etcd:3.2.28
  2. 각 이미지를 레지스트리에 푸시합니다. 예를 들어 OpenShift Container Platform 노드 이미지를 푸시하려면 다음을 수행합니다.

    $ docker push registry.example.com/openshift3/ose-node:<tag>
    $ docker push registry.example.com/openshift3/ose-node:{major-tag}

7.5. 클러스터 호스트 준비

이제 설치 파일이 있으므로 호스트를 준비합니다.

  1. OpenShift Container Platform 클러스터의 호스트를 생성합니다. 최신 버전의 RHEL 7을 사용하고 최소 설치를 수행하는 것이 좋습니다. 호스트가 시스템 요구 사항을 충족하는지 확인합니다.
  2. 각 노드 호스트에서 리포지토리 정의를 생성합니다. /etc/yum.repos.d/ose.repo 파일에 다음 텍스트를 배치합니다.

    [rhel-7-server-rpms]
    name=rhel-7-server-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-rpms 1
    enabled=1
    gpgcheck=0
    [rhel-7-server-extras-rpms]
    name=rhel-7-server-extras-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-extras-rpms 2
    enabled=1
    gpgcheck=0
    [rhel-7-server-ansible-2.9-rpms]
    name=rhel-7-server-ansible-2.9-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-ansible-2.9-rpms 3
    enabled=1
    gpgcheck=0
    [rhel-7-server-ose-3.11-rpms]
    name=rhel-7-server-ose-3.11-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-ose-3.11-rpms 4
    enabled=1
    gpgcheck=0
    1 2 3 4
    & lt;server_IP >를 소프트웨어 리포지토리를 호스팅하는 Apache 서버의 IP 주소 또는 호스트 이름으로 바꿉니다.
  3. 설치를 위해 호스트 준비를 완료합니다. 호스트 준비 단계에 따라 호스트 등록 섹션의 단계를 생략합니다.

7.6. OpenShift Container Platform 설치

소프트웨어, 이미지 및 호스트를 준비한 후 표준 설치 방법을 사용하여 OpenShift Container Platform을 설치합니다.

  1. 내부 레지스트리를 참조하도록 인벤토리 파일을 구성합니다.

    • 내부 레지스트리의 경우:

      oreg_url=registry.example.com/openshift3/ose-<component>:<version> 1
      openshift_examples_modify_imagestreams=true
      1
      ose 구성 요소 이름과 버전 번호를 모두 지정합니다.
    • Satellite 이미지 레지스트리의 경우:

      oreg_url=satellite.example.com/oreg-prod-openshift3_ose-<component>:<version> 1
      osm_etcd_image=satellite.example.com/oreg-prod-rhel7_etcd:3.2.28 2
      openshift_examples_modify_imagestreams=true
      1
      ose 구성 요소 이름과 버전 번호를 모두 지정합니다.
      2
      etcd 이미지의 URL 접두사가 Satellite 서버에서 다른 경우 osm_etcd_image 매개변수에 etcd 이미지의 위치와 이름을 지정해야 합니다.
  2. 설치 플레이북을 실행합니다.

8장. OpenShift 컨테이너 이미지 레지스트리의 독립형 배포 설치

OpenShift Container Platform은 모든 기능을 갖춘 OCR( OpenShift Container Registry )이라는 통합 컨테이너 이미지 레지스트리를 포함합니다. 개발자를 위한 전체 서비스로서의 플랫폼(Platform-as-a-Service) 환경으로 배포하는 대신 OCR을 독립형 컨테이너 이미지 레지스트리로 설치하여 현장 또는 클라우드에서 실행할 수 있습니다.

OCR의 독립형 배포를 설치할 때 일반적인 OpenShift Container Platform 설치와 유사하게 마스터 및 노드 클러스터가 여전히 설치되어 있습니다. 그런 다음 컨테이너 이미지 레지스트리가 클러스터에서 실행되도록 배포됩니다. 이 독립형 배포 옵션은 컨테이너 이미지 레지스트리를 원하는 관리자에게 유용하지만 개발자 중심 웹 콘솔 및 애플리케이션 빌드 및 배포 도구가 포함된 전체 OpenShift Container Platform 환경이 필요하지 않습니다.

OCR은 다음과 같은 기능을 제공합니다.

관리자는 독립 실행형 OCR을 배포하여 여러 OpenShift Container Platform 클러스터를 지원하는 레지스트리를 별도로 관리할 수 있습니다. 또한 관리자는 독립 실행형 OCR을 통해 레지스트리를 분리하여 자체 보안 또는 규정 준수 요구 사항을 충족할 수 있습니다.

8.1. 최소 하드웨어 요구 사항

독립 실행형 OCR을 설치하면 다음과 같은 하드웨어 요구 사항이 있습니다.

  • 물리적 또는 가상 시스템 또는 퍼블릭 또는 프라이빗 IaaS에서 실행되는 인스턴스.
  • 기본 OS: RHEL 7.5 이상, "최신" 설치 옵션 및 RHEL 7 Extras 채널의 최신 패키지 또는 RHEL Atomic Host 7.4.5 이상.
  • NetworkManager 1.0 이상
  • vCPU 2개
  • 최소 16GB RAM
  • /var/ 를 포함하는 파일 시스템의 최소 15GB의 하드 디스크 공간
  • Docker의 스토리지 백엔드에 대해 할당되지 않은 추가 15GB의 추가 공간은 Docker 스토리지 구성을 참조하십시오. 자세한 내용은 Docker 스토리지 구성을 참조하십시오.
중요

OpenShift Container Platform은 x86_64 또는 IBM POWER 아키텍처가 있는 서버를 지원합니다. IBM POWER 서버를 사용하여 클러스터 노드를 호스팅하는 경우 IBM POWER 서버만 사용할 수 있습니다.

참고

RHEL Atomic Host에서 /var/ 파일 시스템 크기 조정 요구 사항을 충족하려면 기본 구성을 수정해야 합니다. 설치 중 또는 설치 후 이 구성 방법에 대한 지침은 Red Hat Enterprise Linux Atomic Host의 스토리지 관리를 참조하십시오.

8.2. 지원되는 시스템 토폴로지

독립 실행형 OCR에서 지원되는 시스템 토폴로지는 다음과 같습니다.

all-in-one

마스터, 노드 및 레지스트리 구성 요소가 포함된 단일 호스트입니다.

다중 마스터(Highly-Available)

각각 네이티브 고가용성을 위해 구성된 마스터가 포함된 모든 구성 요소인 마스터가 있는 3개의 호스트.

8.3. OpenShift Container Registry 설치

  1. 계획 계획 부터 전체 클러스터 설치 프로세스를 검토합니다. OCR을 설치하면 동일한 프로세스가 사용되지만 인벤토리 파일에 몇 가지 특정 설정이 필요합니다. 설치 문서에는 인벤토리 파일에 사용 가능한 Ansible 변수 목록이 포함되어 있습니다.
  2. 호스트 준비 단계를 완료합니다.
  3. /etc/ansible/hosts 디렉터리에 인벤토리 파일을 생성합니다.

    중요

    독립 실행형 OCR을 설치하려면 [OSEv3:vars] 섹션의 인벤토리 파일에 deployment_subtype=registry 를 설정해야 합니다.

    지원되는 다양한 시스템 토폴로지에 대해 다음 예제 인벤토리 파일을 사용합니다.

    올인원 독립형 OpenShift Container Registry 인벤토리 파일

    # Create an OSEv3 group that contains the masters and nodes groups
    [OSEv3:children]
    masters
    nodes
    etcd
    
    # Set variables common for all OSEv3 hosts
    [OSEv3:vars]
    # SSH user, this user should allow ssh based auth without requiring a password
    ansible_ssh_user=root
    
    openshift_master_default_subdomain=apps.test.example.com
    
    # If ansible_ssh_user is not root, ansible_become must be set to true
    #ansible_become=true
    
    openshift_deployment_type=openshift-enterprise
    deployment_subtype=registry 1
    openshift_hosted_infra_selector="" 2
    
    # uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
    #openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
    
    # host group for masters
    [masters]
    registry.example.com
    
    # host group for etcd
    [etcd]
    registry.example.com
    
    # host group for nodes
    [nodes]
    registry.example.com openshift_node_group_name='node-config-all-in-one'

    1
    전체 OpenShift Container Platform 환경이 아닌 독립형 OCR을 설치하도록 deployment_subtype=registry 를 설정합니다.
    2
    단일 호스트에 레지스트리 및 해당 웹 콘솔을 예약할 수 있습니다.

    여러 마스터(고가용성) 독립형 OpenShift Container Registry 인벤토리 파일

    # Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
    # The lb group lets Ansible configure HAProxy as the load balancing solution.
    # Comment lb out if your load balancer is pre-configured.
    [OSEv3:children]
    masters
    nodes
    etcd
    lb
    
    # Set variables common for all OSEv3 hosts
    [OSEv3:vars]
    ansible_ssh_user=root
    openshift_deployment_type=openshift-enterprise
    deployment_subtype=registry 1
    
    openshift_master_default_subdomain=apps.test.example.com
    
    # Uncomment the following to enable htpasswd authentication; defaults to
    # DenyAllPasswordIdentityProvider.
    #openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
    
    # Native high availability cluster method with optional load balancer.
    # If no lb group is defined installer assumes that a load balancer has
    # been preconfigured. For installation the value of
    # openshift_master_cluster_hostname must resolve to the load balancer
    # or to one or all of the masters defined in the inventory if no load
    # balancer is present.
    openshift_master_cluster_method=native
    openshift_master_cluster_hostname=openshift-internal.example.com
    openshift_master_cluster_public_hostname=openshift-cluster.example.com
    
    # apply updated node-config-compute group defaults
    openshift_node_groups=[{'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{'key': 'kubeletArguments.pods-per-core','value': ['20']}, {'key': 'kubeletArguments.max-pods','value': ['250']}, {'key': 'kubeletArguments.image-gc-high-threshold', 'value':['90']}, {'key': 'kubeletArguments.image-gc-low-threshold', 'value': ['80']}]}]
    
    # enable ntp on masters to ensure proper failover
    openshift_clock_enabled=true
    
    # host group for masters
    [masters]
    master1.example.com
    master2.example.com
    master3.example.com
    
    # host group for etcd
    [etcd]
    etcd1.example.com
    etcd2.example.com
    etcd3.example.com
    
    # Specify load balancer host
    [lb]
    lb.example.com
    
    # host group for nodes, includes region info
    [nodes]
    master[1:3].example.com openshift_node_group_name='node-config-master-infra'
    node1.example.com       openshift_node_group_name='node-config-compute'
    node2.example.com       openshift_node_group_name='node-config-compute'

    1
    전체 OpenShift Container Platform 환경이 아닌 독립형 OCR을 설치하도록 deployment_subtype=registry 를 설정합니다.
  4. 독립 실행형 OCR을 설치합니다. 프로세스는 전체 클러스터 설치 프로세스와 유사합니다.

    중요

    Ansible 플레이북을 실행하는 호스트에는 인벤토리 파일에서 호스트당 최소 75MiB의 여유 메모리가 있어야 합니다.

    1. 새 클러스터를 배포하기 전에 클러스터 디렉터리로 변경하고 prerequisites.yml 플레이북을 실행합니다.

      $ cd /usr/share/ansible/openshift-ansible
      $ ansible-playbook  [-i /path/to/inventory] \ 1
          playbooks/prerequisites.yml
      1
      인벤토리 파일이 /etc/ansible/hosts 디렉터리에 없는 경우 -i 및 인벤토리 파일의 경로를 지정합니다.

      이 플레이북은 한 번만 실행해야 합니다.

    2. 설치를 시작하려면 플레이북 디렉터리로 변경하고 deploy_cluster.yml 플레이북을 실행합니다.

      $ cd /usr/share/ansible/openshift-ansible
      $ ansible-playbook  [-i /path/to/inventory] \ 1
          playbooks/deploy_cluster.yml
      1
      인벤토리 파일이 /etc/ansible/hosts 디렉터리에 없는 경우 -i 및 인벤토리 파일의 경로를 지정합니다.

9장. OpenShift Container Platform 설치 제거

uninstall.yml 플레이북을 실행하여 클러스터에서 OpenShift Container Platform 호스트를 설치 제거할 수 있습니다. 이 Playbook은 다음을 포함하여 Ansible에서 설치한 OpenShift Container Platform 콘텐츠를 삭제합니다.

  • 설정
  • 컨테이너
  • 기본 템플릿 및 이미지 스트림
  • 이미지
  • RPM 패키지

플레이북은 플레이북을 실행할 때 지정한 인벤토리 파일에 정의된 모든 호스트의 콘텐츠를 삭제합니다.

중요

클러스터를 제거하기 전에 다음 시나리오 목록을 검토하고 설치 제거를 가장 적합한 옵션인지 확인하십시오.

  • 설치 프로세스가 실패하고 프로세스를 계속 진행하려는 경우 설치를 다시 시도할 수 있습니다. 설치 플레이북은 클러스터를 설치하지 못하는 경우 클러스터를 제거하지 않고도 다시 실행할 수 있도록 설계되었습니다.
  • 처음부터 실패한 설치를 다시 시작하려면 다음 섹션에 설명된 대로 uninstall.yml 플레이북을 실행하여 클러스터에서 OpenShift Container Platform 호스트를 제거할 수 있습니다. 이 Playbook은 설치한 최신 버전의 OpenShift Container Platform 자산만 설치 제거합니다.
  • 호스트 이름 또는 인증서 이름을 변경해야 하는 경우 uninstall.yml 플레이북을 실행하여 설치를 재시도하기 전에 인증서를 다시 생성해야 합니다. 설치 플레이북을 다시 실행하면 인증서가 다시 생성되지 않습니다.
  • 개념 증명 설치와 같이 이전에 OpenShift Container Platform을 설치한 호스트를 용도 변경하거나 OpenShift Container Platform의 다른 마이너 버전 또는 비동기 버전을 설치하려면 프로덕션 클러스터에서 호스트 이미지를 다시 지정해야 합니다. uninstall.yml 플레이북을 실행한 후 일부 호스트 자산은 변경된 상태로 유지될 수 있습니다.

9.1. OpenShift Container Platform 클러스터 설치 제거

클러스터의 모든 호스트에서 OpenShift Container Platform을 설치 제거하려면 플레이북 디렉터리로 변경하고 가장 최근에 사용한 인벤토리 파일을 사용하여 플레이북을 실행합니다.

# ansible-playbook [-i /path/to/file] \ 1
    /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml
1
인벤토리 파일이 /etc/ansible/hosts 디렉터리에 없는 경우 -i 및 인벤토리 파일의 경로를 지정합니다.

9.2. 노드 설치 제거

나머지 호스트 및 클러스터를 그대로 유지하면서 uninstall.yml Playbook을 사용하여 특정 호스트에서 노드 구성 요소를 설치 제거하려면 다음을 수행합니다.

주의

특정 마스터 또는 etcd 호스트가 아닌 특정 노드 호스트를 제거하려는 경우에만 이 방법을 사용하십시오. 마스터 또는 etcd 호스트를 설치 제거하려면 클러스터에 추가 구성 변경이 필요합니다.

  1. 노드 삭제 단계를 수행하여 클러스터에서 노드 오브젝트를 제거합니다.
  2. 해당 호스트만 참조하는 다른 인벤토리 파일을 생성합니다. 예를 들어 하나의 노드에서만 콘텐츠를 삭제하려면 다음을 수행합니다.

    [OSEv3:children]
    nodes 1
    
    [OSEv3:vars]
    ansible_ssh_user=root
    openshift_deployment_type=openshift-enterprise
    
    [nodes]
    node3.example.com openshift_node_group_name='node-config-infra' 2
    1
    제거할 호스트에 적용되는 섹션만 포함합니다.
    2
    제거할 호스트만 포함합니다.
  3. 플레이북 디렉터리로 변경하고 uninstall.yml 플레이북을 실행합니다.

    # ansible-playbook -i /path/to/new/file \ 1
        /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml
    1
    새 인벤토리 파일의 경로를 지정합니다.

플레이북이 완료되면 모든 OpenShift Container Platform 콘텐츠가 지정된 호스트에서 제거됩니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.