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

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

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

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

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

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

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

기본적으로 위의 이미지는 모두 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>

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

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

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

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

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

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

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

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

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

시스템의 임시 디렉토리는 Python의 표준 라이브러리의 tempfile 모듈에 정의된 규칙에 따라 결정됩니다.

컨테이너 데몬을 실행하는 각 시스템에 대한 스토리지를 구성해야 합니다. 컨테이너화된 설치의 경우 마스터에 스토리지가 필요합니다. 또한 기본적으로 웹 콘솔은 마스터의 컨테이너에서 실행되며 마스터는 웹 콘솔을 실행하기 위해 스토리지가 필요합니다. 컨테이너는 노드에서 실행되므로 노드에 항상 스토리지가 필요합니다. 스토리지 크기는 워크로드, 컨테이너 수, 실행 중인 컨테이너의 크기, 컨테이너 스토리지 요구 사항에 따라 달라집니다. 컨테이너화된 etcd를 실행하도록 스토리지를 구성해야 합니다.

NVMe 또는 SSD와 같이 직렬 쓰기(fsync)를 빠르게 처리하는 스토리지와 함께 etcd를 사용하는 것이 좋습니다. Ceph, NFS 및 회전 디스크는 권장되지 않습니다.

최소 요구사항이 있는 테스트 또는 샘플 환경이 작동합니다. 프로덕션 환경의 경우 다음 권장 사항이 적용됩니다.

성능 지침은 Recommended Practices for OpenShift Container Platform Master Hosts 에서 참조하십시오.

자세한 내용은 고려 사항 및 클러스터 제한 크기 조정을 참조하십시오.

통합 모드 또는 독립 모드 클러스터에서 사용되는 모든 노드는 스토리지 노드로 간주됩니다. 스토리지 노드는 별도의 클러스터 그룹으로 그룹화할 수 있지만 단일 노드는 여러 그룹에 있을 수 없습니다. 각 스토리지 노드 그룹에 대해 다음을 수행합니다.

모니터링 스택은 추가 시스템 리소스 요구 사항을 적용하고 기본적으로 설치됩니다. 컴퓨팅 리소스 권장 사항 및 클러스터 모니터링 설명서 를 참조하십시오.

OpenShift Container Platform을 설치하거나 설치 프로그램이 실패하기 전에 모든 서버에서 SELinux를 사용하도록 설정해야 합니다. 또한 /etc/selinux/config 파일에 SELINUX=enforcing 및 SELINUXTYPE=targeted 를 구성합니다.

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

기본적으로 OpenShift Container Platform 마스터 및 노드는 실행 중인 시스템에서 사용 가능한 모든 코어를 사용합니다. GOMAXPROCS 환경 변수를 설정하여 OpenShift Container Platform에서 사용할 코어 수를 선택할 수 있습니다. GOMAXPROCS 환경 변수가 작동하는 방식을 포함하여 자세한 내용은 Go Language 설명서 를 참조하십시오.

예를 들어 서버를 시작하기 전에 다음을 실행하여 OpenShift Container Platform이 하나의 코어에서만 실행되도록 합니다.

# export GOMAXPROCS=1

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 섹션을 참조하십시오.

OpenShift Container Platform은 클러스터의 호스트에서 컨테이너를 실행하며, 빌드 작업 및 레지스트리 서비스와 같은 경우에 따라 권한이 있는 컨테이너를 사용합니다. 또한 이러한 컨테이너는 호스트의 Docker 데몬에 액세스하고 Docker 빌드 및 Docker 내보내기 작업을 수행합니다. 따라서 클러스터 관리자는 효과적으로 root 액세스 권한이 있으므로 임의의 이미지에서 docker 실행 작업을 수행할 수 있는 보안 위험을 알고 있어야 합니다. 이는 특히 Docker 빌드 작업과 관련이 있습니다.

유해한 컨테이너에 대한 노출은 모든 노출이 해당 노드에 제한되도록 특정 빌드를 노드에 할당하여 제한할 수 있습니다. 이렇게 하려면 개발자 가이드의 특정 노드에 빌드 할당 섹션을 참조하십시오. 클러스터 관리자는 글로벌 빌드 기본값 구성 및 덮어쓰기 항목을 참조하십시오.

보안 컨텍스트 제약 조건을 사용하여 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 작업을 제어할 수도 있습니다. Dockerfile에서 USER 로 이미지를 실행하도록 활성화하는 방법에 대한 자세한 내용은 Managing Security Context Constraints ( cluster-admin 권한이 있는 사용자 필요)을 참조하십시오.

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

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

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

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

다음은 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 환경이 제대로 작동하지 않는 경우 다음과 같이 오류가 발생할 수 있습니다.

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

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

[OSEv3:vars]
os_firewall_use_firewalld=True

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

컨테이너가 실행 중인 노드의 /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

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

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

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

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

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

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

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

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

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

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

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

최신 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: []

인벤토리 파일의 [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을 편집할 수도 있습니다.

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']}]}]

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']}]}]

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 )을 업데이트합니다. 그러면 결국 호스트의 구성 파일에 영향을 미칩니다.

어떤 노드 호스트에 사용할 ConfigMap을 매핑하려면 인벤토리의 [nodes] 그룹에 정의된 모든 호스트를 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'

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

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

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

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

# 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'

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

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

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

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

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

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

옵션 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용 스토리지를 제공하여 레지스트리에 대한 중복되고 안정적인 스토리지를 제공하도록 구성할 수 있습니다.

옵션 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

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

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

옵션 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

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

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

옵션 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

옵션 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

다음 옵션을 사용하는 원격 볼륨 경로는 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

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

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

ansible_service_broker_install=false

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

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

template_service_broker_install=false

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

openshift_template_service_broker_namespaces=['openshift','myproject']

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

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

# 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'

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

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

다음 예제 인벤토리 파일의 [masters], [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]
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'

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

다음은 기본 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

[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 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'

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

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

[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'

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

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

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

. 설치에 성공하면 설치를 확인합니다. 설치에 실패하면 설치를 다시 시도합니다.

openshift3/ose-ansible 이미지는 컨테이너화된 OpenShift Container Platform 설치 프로그램의 버전입니다. 이 설치 프로그램 이미지는 RPM 기반 설치 프로그램과 동일한 기능을 제공하지만 호스트에 직접 설치하는 대신 모든 종속 항목을 제공하는 컨테이너화된 환경에서 실행됩니다. 이를 사용하는 유일한 요구 사항은 컨테이너를 실행하는 기능입니다.

# 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

$ ansible-playbook --user openshift \
  -i openshift-ansible/playbooks/openstack/inventory.py \
  -i inventory \
  openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml

설치 프로그램은 모듈식 플레이북을 사용하므로 관리자가 필요에 따라 특정 구성 요소를 설치할 수 있습니다. 역할 및 플레이북을 분리하면 애드혹 관리 작업을 더 잘 목표로 지정할 수 있습니다. 이로 인해 설치 중에 제어 수준이 높아지고 시간이 단축됩니다.

기본 설치 플레이북 /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml 은 특정 순서로 개별 구성 요소 플레이북 세트를 실행하고 설치 프로그램이 어떤 단계를 반복했는지 보고합니다. 설치에 실패하면 Ansible 실행 오류와 함께 어떤 단계가 실패했는지 알 수 있습니다.

인터넷 연결이 있는 RHEL 7 서버에서 리포지토리를 동기화합니다.

필요한 컨테이너 이미지를 가져옵니다.

환경에서 내부 네트워크에 액세스할 수 없으며 콘텐츠를 전송하기 위해 물리적 미디어가 필요한 경우 이미지를 압축된 파일로 내보냅니다. 호스트가 인터넷과 내부 네트워크에 모두 연결되어 있는 경우 다음 단계를 건너뛰고 계속 리포지토리 서버 준비 및 채우기.