Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

DAY 2 운영 가이드

OpenShift Container Platform 3.11

OpenShift Container Platform 3.11 DAY 2 운영 가이드

Red Hat OpenShift Documentation Team

초록

OpenShift Container Platform Cluster 관리 안내서에서는 구성에 중점을 두는 반면, 이 안내서에서는 일상적인 유지 관리 작업에 대한 개요를 설명합니다.

1장. 개요

이 섹션은 새로 설치한 OpenShift Container Platform 관리자용으로 작성되었습니다.

OpenShift Container Platform Cluster 관리 안내서에서는 구성에 중점을 두는 반면, 이 안내서에서는 일상적인 유지 관리 작업에 대한 개요를 설명합니다.

2장. 한 번 실행 작업

OpenShift Container Platform을 설치한 후 호스트가 일관되게 원활히 실행되도록 시스템을 추가로 구성해야 할 수 있습니다.

이러한 작업은 한 번만 실행되는 작업으로 분류되지만 상황이 바뀌면 언제든지 이 작업을 수행할 수 있습니다.

2.1. NTP 동기화

NTP(Network Time Protocol)는 호스트를 세계 시간과 동기화하는 데 사용합니다. 시간 동기화는 로그 유지 및 타임스탬프와 같이 시간에 민감한 작업에 중요하며 OpenShift Container Platform이 구축된 Kubernetes에 사용하도록 적극 추천합니다. OpenShift Container Platform 운영에는 etcd 리더 선택, 포드 상태 점검 및 기타 문제가 포함되며 시간 왜곡 문제를 방지하는 데 도움이 됩니다.

참고

OpenShift Container Platform 설치 플레이북에서는 기본적으로 NTP 서비스를 제공하도록 ntp 패키지를 설치, 활성화 및 구성합니다. 이 동작을 비활성화하려면 인벤토리 파일에서 openshift_clock_enabled = false를 설정하십시오. 호스트에 chrony 패키지가 이미 설치되어 있으면 ntp 패키지를 사용하는 대신 NTP 서비스를 제공하도록 구성되어 있습니다.

인스턴스에 따라 NTP가 기본적으로 활성화되어 있지 않을 수 있습니다. 호스트가 NTP를 사용하도록 구성되어 있는지 확인하려면 다음을 수행하십시오.

$ timedatectl
      Local time: Thu 2017-12-21 14:58:34 UTC
  Universal time: Thu 2017-12-21 14:58:34 UTC
        RTC time: Thu 2017-12-21 14:58:34
       Time zone: Etc/UTC (UTC, +0000)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

NTP 사용NTP 동기화가 모두 이면 NTP 동기화가 활성화됩니다.

아니오이면 ntp 또는 chrony RPM 패키지를 설치하고 활성화하십시오.

ntp 패키지를 설치하려면 다음 명령을 실행하십시오.

# timedatectl set-ntp true

chrony 패키지를 설치하려면 다음 명령을 실행하십시오.

# yum install chrony
# systemctl enable chronyd --now
중요

NTP를 사용하든 다른 방법을 사용하든 클러스터의 모든 호스트에서 시간 동기화를 활성화해야 합니다.

timedatectl 명령, 시간대 및 시계 구성에 대한 자세한 정보는 날짜와 시간 구성UTC, 시간대 및 DST를 참조하십시오.

2.2. 엔트로피

OpenShift Container Platform에서는 엔트로피를 사용하여 ID 또는 SSL 트래픽과 같은 오브젝트의 난수를 생성합니다. 이러한 작업에서는 작업을 완료하는 데 엔트로피가 충분하게 될 때까지 대기합니다. 엔트로피가 충분하지 않으면 커널은 충분히 빠른 속도로 이러한 난수를 생성할 수 없으므로 시간 초과가 발생하고 보안 연결이 거부될 수 있습니다.

사용 가능한 엔트로피를 확인하려면 다음을 수행하십시오.

$ cat /proc/sys/kernel/random/entropy_avail
2683

사용 가능한 엔트로피는 클러스터의 모든 노드 호스트에서 확인해야 합니다. 이 값으로 적합한 값은 1000을 넘어야 합니다.

참고

Red Hat에서는 이 값을 모니터링하고 값이 800 미만인 경우 경고를 발행하도록 권장합니다.

또는 rngtest 명령을 사용하여 사용 가능한 엔트로피뿐 아니라 시스템에서 충분한 엔트로피도 공급할 수 있는지 확인할 수 있습니다.

$ cat /dev/random | rngtest -c 100

rngtest 명령은 rng-tools에서 사용할 수 있습니다.

위의 작업을 완료하는 데 약 30초가 걸리면 사용 가능한 엔트로피가 충분하지 않은 것입니다.

환경에 따라 엔트로피를 여러 가지 방법으로 늘릴 수 있습니다. 자세한 내용은 https://developers.redhat.com/blog/2017/10/05/entropy-rhel-based-cloud-instances/ 블로그 게시물을 참조하십시오.

일반적으로 rng-tools 패키지를 설치하고 rngd 서비스를 활성화하여 엔트로피를 증가시킬 수 있습니다.

# yum install rng-tools
# systemctl enable --now rngd

rngd 서비스가 시작되면 엔트로피가 충분한 수준으로 증가해야 합니다.

2.3. 기본 스토리지 클래스 확인

동적으로 프로비저닝된 영구 스토리지가 올바르게 작동하려면 기본 스토리지 클래스를 정의해야 합니다. 설치 중에 이 기본 스토리지 클래스는 AWS(Amazon Web Services), GCP(Google Cloud Platform) 등과 같은 일반적인 클라우드 제공자에 맞게 정의됩니다.

기본 스토리지 클래스가 정의되었는지 확인하려면 다음을 수행하십시오.

$ oc get storageclass
NAME                 TYPE
ssd                  kubernetes.io/gce-pd
standard (default)   kubernetes.io/gce-pd

위 출력은 GCP에서 실행되는 OpenShift Container Platform 인스턴스에서 가져온 것으로, 표준(HDD) 및 SSD의 두 가지 영구 스토리지를 사용할 수 있습니다. 표준 스토리지 클래스가 기본값으로 구성되어 있습니다. 스토리지 클래스가 정의되어 있지 않거나 기본값으로 설정되지 않은 경우 제안된 대로 스토리지 클래스를 설정하는 방법에 대한 지시 사항은 동적 프로비저닝 및 스토리지 클래스 작성 섹션을 참조하십시오.

3장. 환경 상태 점검

이 주제에는 OpenShift Container Platform 클러스터 및 다양한 구성 요소의 전반적인 상태를 확인하고 의도된 동작을 설명하는 단계가 포함되어 있습니다.

다양한 구성 요소에 대한 검증 프로세스를 아는 것이 문제 해결을 위한 첫 번째 단계입니다. 문제가 발생하면 이 섹션에 제공된 검사를 사용하여 문제를 진단할 수 있습니다.

3.1. 완전한 환경 상태 점검

OpenShift Container Platform 클러스터의 엔드 투 엔드 기능을 확인하려면 예제 애플리케이션을 빌드하고 배포하십시오.

프로시저
  1. cakephp-mysql-example 템플릿에서 예제 애플리케이션뿐만 아니라 validate라는 새 프로젝트를 만듭니다.

    $ oc new-project validate
    $ oc new-app cakephp-mysql-example

    빌드를 따르는지 로그를 확인할 수 있습니다.

    $ oc logs -f bc/cakephp-mysql-example
  2. 빌드가 완료되면 두 포드에서 데이터베이스와 애플리케이션을 실행해야 합니다.

    $ oc get pods
    NAME                            READY     STATUS      RESTARTS   AGE
    cakephp-mysql-example-1-build   0/1       Completed   0          1m
    cakephp-mysql-example-2-247xm   1/1       Running     0          39s
    mysql-1-hbk46                   1/1       Running     0          1m
  3. 애플리케이션 URL을 방문하십시오. Cake PHP 프레임워크 시작 페이지가 표시되어야 합니다. URL은 cakephp-mysql-example-validate.<app_domain> 형식이어야 합니다.
  4. 기능이 확인되면 validate 프로젝트를 삭제할 수 있습니다.

    $ oc delete project validate

    프로젝트의 모든 리소스도 삭제됩니다.

3.2. Prometheus를 사용하여 경고 생성

환경 문제가 발생하기 전에 진단할 수 있도록 OpenShift Container Platform을 Prometheus와 통합하여 시각적 표시와 경고를 생성할 수 있습니다. 이러한 문제에는 노드가 중단된 경우, 포드가 너무 많은 CPU 또는 메모리를 소비하는 경우 등이 포함될 수 있습니다.

자세한 내용은 설치 및 구성 안내서에 있는 OpenShift Container Platform의 Prometheus 섹션을 참조하십시오.

3.3. 호스트 상태

클러스터가 작동 중인지 확인하려면 마스터 인스턴스에 연결하고 다음을 실행하십시오.

$ oc get nodes
NAME                  STATUS                     AGE       VERSION
ocp-infra-node-1clj   Ready                      1h        v1.6.1+5115d708d7
ocp-infra-node-86qr   Ready                      1h        v1.6.1+5115d708d7
ocp-infra-node-g8qw   Ready                      1h        v1.6.1+5115d708d7
ocp-master-94zd       Ready                      1h        v1.6.1+5115d708d7
ocp-master-gjkm       Ready                      1h        v1.6.1+5115d708d7
ocp-master-wc8w       Ready                      1h        v1.6.1+5115d708d7
ocp-node-c5dg         Ready                      1h        v1.6.1+5115d708d7
ocp-node-ghxn         Ready                      1h        v1.6.1+5115d708d7
ocp-node-w135         Ready                      1h        v1.6.1+5115d708d7

위의 클러스터 예는 3개의 마스터 호스트, 3개의 인프라 노드 호스트 및 3개의 노드 호스트로 구성되며, 모두 실행 중입니다 클러스터의 모든 호스트가 이 출력에 표시되어야 합니다.

Ready 상태는 마스터 호스트가 노드 호스트와 통신할 수 있고 노드에서 포드를 실행할 준비가 되었음을 의미합니다(단, 스케줄링이 비활성화된 노드 제외).

etcd 명령을 실행하기 전에 etcd.conf 파일에 소스를 제공하십시오.

# source /etc/etcd/etcd.conf

etcdctl 명령을 사용하여 모든 마스터 인스턴스에서 기본 etcd 상태를 확인할 수 있습니다.

# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
  --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS cluster-health
member 59df5107484b84df is healthy: got healthy result from https://10.156.0.5:2379
member 6df7221a03f65299 is healthy: got healthy result from https://10.156.0.6:2379
member fea6dfedf3eecfa3 is healthy: got healthy result from https://10.156.0.9:2379
cluster is healthy

그러나 연관된 마스터 호스트를 포함하여 etcd 호스트에 대한 자세한 정보를 얻으려면 다음을 수행하십시오.

# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
  --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
295750b7103123e0: name=ocp-master-zh8d peerURLs=https://10.156.0.7:2380 clientURLs=https://10.156.0.7:2379 isLeader=true
b097a72f2610aea5: name=ocp-master-qcg3 peerURLs=https://10.156.0.11:2380 clientURLs=https://10.156.0.11:2379 isLeader=false
fea6dfedf3eecfa3: name=ocp-master-j338 peerURLs=https://10.156.0.9:2380 clientURLs=https://10.156.0.9:2379 isLeader=false

etcd 클러스터가 마스터 서비스와 같은 위치에 있는 경우 모든 etcd 호스트에 마스터 호스트 이름이 포함되어 있어야 합니다. 또는 etcd가 별도로 실행 중이면 모든 etcd 인스턴스가 표시되어야 합니다.

참고

etcdctl2는 v3 데이터 모델의 etcdctl3뿐만 아니라 v2 데이터 모델의 etcd 클러스터를 조회하기 위한 적절한 플래그를 포함하는 etcdctl 도구의 별칭입니다.

3.4. 라우터 및 레지스트리 상태

라우터 서비스가 실행 중인지 확인하려면 다음을 수행하십시오.

$ oc -n default get deploymentconfigs/router
NAME      REVISION   DESIRED   CURRENT   TRIGGERED BY
router    1          3         3         config

DESIREDCURRENT 열의 값은 노드 호스트 수와 일치해야 합니다.

동일한 명령을 사용하여 레지스트리 상태를 확인하십시오.

$ oc -n default get deploymentconfigs/docker-registry
NAME              REVISION   DESIRED   CURRENT   TRIGGERED BY
docker-registry   1          3         3         config
참고

컨테이너 이미지 레지스트리의 다중 실행 인스턴스에는 여러 프로세스의 쓰기를 지원하는 백엔드 스토리지가 필요합니다. 선택한 인프라 공급자에 이 기능이 없으면 컨테이너 이미지 레지스트리의 단일 인스턴스를 실행할 수 있습니다.

모든 포드가 실행 중이고 어떤 호스트에서 실행 중인지 확인하려면 다음을 수행하십시오.

$ oc -n default get pods -o wide
NAME                       READY     STATUS    RESTARTS   AGE       IP            NODE
docker-registry-1-54nhl    1/1       Running   0          2d        172.16.2.3    ocp-infra-node-tl47
docker-registry-1-jsm2t    1/1       Running   0          2d        172.16.8.2    ocp-infra-node-62rc
docker-registry-1-qbt4g    1/1       Running   0          2d        172.16.14.3   ocp-infra-node-xrtz
registry-console-2-gbhcz   1/1       Running   0          2d        172.16.8.4    ocp-infra-node-62rc
router-1-6zhf8             1/1       Running   0          2d        10.156.0.4    ocp-infra-node-62rc
router-1-ffq4g             1/1       Running   0          2d        10.156.0.10   ocp-infra-node-tl47
router-1-zqxbl             1/1       Running   0          2d        10.156.0.8    ocp-infra-node-xrtz
참고

OpenShift Container Platform에서 외부 컨테이너 이미지 레지스트리를 사용하는 경우 내부 레지스트리 서비스를 실행할 필요가 없습니다.

3.5. 네트워크 연결

네트워크 연결에는 노드 상호 작용을 위한 클러스터 네트워크와 포드 상호 작용을 위한 소프트웨어 정의 네트워크(SDN)의 두 가지 주요 네트워킹 계층이 있습니다. OpenShift Container Platform에서는 종종 특정 인프라 공급자에 최적화된 여러 네트워크 구성을 지원합니다.

참고

네트워킹의 복잡성 때문에 이 섹션에서는 일부 확인 시나리오는 다루지 않습니다.

3.5.1. 마스터 호스트에서 연결

etcd 및 마스터 호스트

마스터 서비스는 etcd 키-값 저장소를 사용하여 상태를 동기화된 상태로 유지합니다. 해당 etcd 서비스가 마스터 호스트에 배치되어 있는지 아니면 etcd 서비스 전용으로 지정된 호스트에서 실행되는지에 관계없이 마스터와 etcd 서비스 간의 통신이 중요합니다. 이 통신은 TCP 포트 23792380에서 수행합니다. 이 통신을 확인하는 방법은 호스트 상태 섹션을 참조하십시오.

SkyDNS

SkyDNS에서는 OpenShift Container Platform에서 실행 중인 로컬 서비스의 이름 분석을 제공합니다. 이 서비스에서는 TCPUDP 포트 8053을 사용합니다.

이름 분석을 확인하려면 다음을 수행하십시오.

$ dig +short docker-registry.default.svc.cluster.local
172.30.150.7

응답이 다음 출력과 일치하면 SkyDNS 서비스가 올바르게 작동하는 것입니다.

$ oc get svc/docker-registry -n default
NAME              CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
docker-registry   172.30.150.7   <none>        5000/TCP   3d

API 서비스 및 웹 콘솔

API 서비스와 웹 콘솔은 모두 설정에 따라 동일한 포트, 일반적으로 TCP 8443 또는 443을 공유합니다. 이 포트는 클러스터 내에서 사용 가능해야 하며, 배포된 환경에서 작업해야 하는 모든 사람이 사용할 수 있어야 합니다. 이 포트에 도달할 수 있는 URL은 내부 클러스터 및 외부 클라이언트에 따라 다를 수 있습니다.

다음 예에서 https://internal-master.example.com:443 URL은 내부 클러스터에서 사용하고 https://master.example.com:443 URL은 외부 클라이언트에서 사용합니다. 모든 노드 호스트에서 다음을 수행하십시오.

$ curl -k https://internal-master.example.com:443/version
{
  "major": "1",
  "minor": "6",
  "gitVersion": "v1.6.1+5115d708d7",
  "gitCommit": "fff65cf",
  "gitTreeState": "clean",
  "buildDate": "2017-10-11T22:44:25Z",
  "goVersion": "go1.7.6",
  "compiler": "gc",
  "platform": "linux/amd64"
}

클라이언트의 네트워크에서 액세스할 수 있어야 합니다.

$ curl -k https://master.example.com:443/healthz
ok

3.5.2. 노드 인스턴스의 연결

노드에서 SDN 연결 포드 통신에서는 기본적으로 UDP 포트 4789를 사용합니다.

노드 호스트 기능을 확인하려면 애플리케이션을 생성하십시오. 다음 예제에서는 노드가 인프라 노드에서 실행중인 컨테이너 이미지 레지스트리에 도달하는지 확인합니다.

프로시저
  1. 새 프로젝트를 생성하십시오.

    $ oc new-project sdn-test
  2. 다음과 같이 httpd 애플리케이션을 배포하십시오.

    $ oc new-app centos/httpd-24-centos7~https://github.com/sclorg/httpd-ex

    빌드가 완료될 때까지 기다려 주십시오.

    $ oc get pods
    NAME               READY     STATUS      RESTARTS   AGE
    httpd-ex-1-205hz   1/1       Running     0          34s
    httpd-ex-1-build   0/1       Completed   0          1m
  3. 실행 중인 포드에 연결하십시오.

    $ oc rsh po/<pod-name>

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

    $ oc rsh po/httpd-ex-1-205hz
  4. 내부 레지스트리 서비스의 healthz 경로를 확인하십시오.

    $ curl -kv https://docker-registry.default.svc.cluster.local:5000/healthz
    * About to connect() to docker-registry.default.svc.cluster.locl port 5000 (#0)
    *   Trying 172.30.150.7...
    * Connected to docker-registry.default.svc.cluster.local (172.30.150.7) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    * Server certificate:
    * 	subject: CN=172.30.150.7
    * 	start date: Nov 30 17:21:51 2017 GMT
    * 	expire date: Nov 30 17:21:52 2019 GMT
    * 	common name: 172.30.150.7
    * 	issuer: CN=openshift-signer@1512059618
    > GET /healthz HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: docker-registry.default.svc.cluster.local:5000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Date: Mon, 04 Dec 2017 16:26:49 GMT
    < Content-Length: 0
    < Content-Type: text/plain; charset=utf-8
    <
    * Connection #0 to host docker-registry.default.svc.cluster.local left intact
    
    sh-4.2$ *exit*

    HTTP/1.1 200 OK 응답이 표시되면 노드가 올바르게 연결되어 있는 것입니다.

  5. 다음과 같이 테스트 프로젝트를 정리하십시오.

    $ oc delete project sdn-test
    project "sdn-test" deleted
  6. 노드 호스트가 TCP 포트 10250에서 청취 중입니다. 이 포트는 임의 노드의 모든 마스터 호스트에서 도달할 수 있어야 하며, 모니터링이 클러스터에 배포된 경우 인프라 노드는 모든 인스턴스에서 이 포트에 액세스할 수 있어야 합니다. 다음 명령을 사용하여 이 포트에서 중단된 통신을 탐지할 수 있습니다.

    $ oc get nodes
    NAME                  STATUS                     AGE       VERSION
    ocp-infra-node-1clj   Ready                      4d        v1.6.1+5115d708d7
    ocp-infra-node-86qr   Ready                      4d        v1.6.1+5115d708d7
    ocp-infra-node-g8qw   Ready                      4d        v1.6.1+5115d708d7
    ocp-master-94zd       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-master-gjkm       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-master-wc8w       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-node-c5dg         Ready                      4d        v1.6.1+5115d708d7
    ocp-node-ghxn         Ready                      4d        v1.6.1+5115d708d7
    ocp-node-w135         NotReady                   4d        v1.6.1+5115d708d7

    위 출력에서 ocp-node-w135 노드의 노드 서비스는 마스터 서비스에서 도달할 수 없으며 NotReady 상태로 표시됩니다.

  7. 마지막 서비스는 라우터이며 OpenShift Container Platform 클러스터에서 실행 중인 올바른 서비스로 연결을 라우팅해야 합니다. 라우터에서는 인프라 노드의 TCP 포트 80443에서 들어오는 트래픽을 청취합니다. 라우터가 작동하기 시작하려면 DNS를 구성해야 합니다.

    $ dig *.apps.example.com
    
    ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-8.P3.fc27 <<>> *.apps.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45790
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;*.apps.example.com.	IN	A
    
    ;; ANSWER SECTION:
    *.apps.example.com. 3571	IN	CNAME	apps.example.com.
    apps.example.com.	3561	IN	A	35.xx.xx.92
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue Dec 05 16:03:52 CET 2017
    ;; MSG SIZE  rcvd: 105

    IP 주소(이 경우 35.xx.xx.92)는 모든 인프라 노드에 들어오는 트래픽을 분산시키는 로드 밸런서를 가리켜야 합니다. 라우터의 기능을 확인하려면 이번에는 클러스터 외부에서 레지스트리 서비스를 한 번 더 확인하십시오.

    $ curl -kv https://docker-registry-default.apps.example.com/healthz
    *   Trying 35.xx.xx.92...
    * TCP_NODELAY set
    * Connected to docker-registry-default.apps.example.com (35.xx.xx.92) port 443 (#0)
    ...
    < HTTP/2 200
    < cache-control: no-cache
    < content-type: text/plain; charset=utf-8
    < content-length: 0
    < date: Tue, 05 Dec 2017 15:13:27 GMT
    <
    * Connection #0 to host docker-registry-default.apps.example.com left intact

3.6. 스토리지

마스터 인스턴스에는 /var 디렉터리용으로 40GB 이상의 하드 디스크 공간이 필요합니다. df 명령을 사용하여 마스터 호스트의 디스크 사용량을 확인하십시오.

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      xfs        45G  2.8G   43G   7% /
devtmpfs       devtmpfs  3.6G     0  3.6G   0% /dev
tmpfs          tmpfs     3.6G     0  3.6G   0% /dev/shm
tmpfs          tmpfs     3.6G   63M  3.6G   2% /run
tmpfs          tmpfs     3.6G     0  3.6G   0% /sys/fs/cgroup
tmpfs          tmpfs     732M     0  732M   0% /run/user/1000
tmpfs          tmpfs     732M     0  732M   0% /run/user/0

노드 인스턴스에서는 /var 디렉터리에 15GB 이상의 공간이 필요하고 Docker 스토리지(이 경우 /var/lib/docker)에는 15GB 이상의 공간이 필요합니다. 클러스터의 크기와 포드에 필요한 임시 스토리지의 크기에 따라 노드에서 /var/lib/origin/openshift.local.volumes용으로 별도의 파티션을 생성해야 합니다.

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      xfs        25G  2.4G   23G  10% /
devtmpfs       devtmpfs  3.6G     0  3.6G   0% /dev
tmpfs          tmpfs     3.6G     0  3.6G   0% /dev/shm
tmpfs          tmpfs     3.6G  147M  3.5G   4% /run
tmpfs          tmpfs     3.6G     0  3.6G   0% /sys/fs/cgroup
/dev/sdb       xfs        25G  2.7G   23G  11% /var/lib/docker
/dev/sdc       xfs        50G   33M   50G   1% /var/lib/origin/openshift.local.volumes
tmpfs          tmpfs     732M     0  732M   0% /run/user/1000

포드의 영구 스토리지는 OpenShift Container Platform 클러스터를 실행하는 인스턴스 외부에서 처리해야 합니다. 포드의 영구 볼륨은 인프라 공급자가 프로비저닝하거나 컨테이너 기본 스토리지 또는 컨테이너 준비 스토리지를 사용하여 프로비저닝할 수 있습니다.

3.7. Docker 저장

Docker 스토리지는 두 가지 옵션 중 하나로 백업할 수 있습니다. 첫 번째는 장치 매퍼가 있는 씬 풀 논리 볼륨이며, 두 번째는 Red Hat Enterprise Linux 버전 7.4이므로 overlay2 파일 시스템입니다. 설정이 쉽고 성능이 향상되므로 일반적으로 overlay2 파일 시스템을 사용하는 것이 좋습니다.

Docker 스토리지 디스크는 /var/lib/docker 로 마운트되고 xfs 파일 시스템으로 포맷됩니다. Docker 스토리지는 overlay2 파일 시스템을 사용하도록 구성되었습니다.

$ cat /etc/sysconfig/docker-storage
DOCKER_STORAGE_OPTIONS='--storage-driver overlay2'

Docker에서 이 스토리지 드라이버를 사용하는지 확인하려면 다음을 수행하십시오.

# docker info
Containers: 4
 Running: 4
 Paused: 0
 Stopped: 0
Images: 4
Server Version: 1.12.6
Storage Driver: overlay2
 Backing Filesystem: xfs
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: overlay host bridge null
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: docker-runc runc
Default Runtime: docker-runc
Security Options: seccomp selinux
Kernel Version: 3.10.0-693.11.1.el7.x86_64
Operating System: Employee SKU
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 3
CPUs: 2
Total Memory: 7.147 GiB
Name: ocp-infra-node-1clj
ID: T7T6:IQTG:WTUX:7BRU:5FI4:XUL5:PAAM:4SLW:NWKL:WU2V:NQOW:JPHC
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://registry.redhat.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8
Registries: registry.redhat.io (secure), registry.redhat.io (secure), docker.io (secure)

3.8. API 서비스 상태

OpenShift API 서비스는 모든 마스터 인스턴스에서 실행됩니다. 서비스 상태를 보려면 kube-system 프로젝트에서 master-api 포드를 보십시오.

oc get pod -n kube-system -l openshift.io/component=api

NAME                             READY     STATUS    RESTARTS   AGE
master-api-myserver.com          1/1       Running   0          56d

API 서비스는 API 호스트 이름을 사용하여 외부에서 조회할 수 있는 상태 점검을 노출합니다. API 서비스와 웹 콘솔은 모두 설정에 따라 동일한 포트, 일반적으로 TCP 8443 또는 443을 공유합니다. 이 포트는 클러스터 내에서 사용 가능해야 하며, 배포된 환경에서 작업해야 하는 모든 사람이 사용할 수 있어야 합니다.

oc get pod -n kube-system -o wide
NAME                                               READY     STATUS    RESTARTS   AGE       IP            NODE
master-api-myserver.com                            1/1       Running   0          7h        10.240.0.16   myserver.com

$ curl -k https://myserver.com:443/healthz 1
ok
1
클라이언트의 네트워크에서 액세스할 수 있어야 합니다. 이 예에서 웹 콘솔 포트는 443입니다. OpenShift Container Platform 배포 전에 호스트 인벤토리 파일에서 openshift_master_console_port에 설정된 값을 지정하십시오. 인벤토리 파일에 openshift_master_console_port가 포함되어 있지 않으면 기본적으로 8443 포트가 설정됩니다.

3.9. 컨트롤러 역할 확인

OpenShift Container Platform 컨트롤러 서비스는 모든 마스터 호스트에서 사용할 수 있습니다. 서비스는 활성/수동 모드에서 실행됩니다. 즉, 한 번에 하나의 마스터에서만 실행되어야 합니다.

OpenShift Container Platform 컨트롤러에서는 서비스를 실행할 호스트를 선택하는 프로시저를 실행합니다. 현재 실행 중인 값은 kube-system 프로젝트에 저장된 특수 configMa의 주석에 저장됩니다.

컨트롤러 서비스를 cluster-admin 사용자로 실행하는 마스터 호스트를 확인하십시오.

$ oc get -n kube-system cm openshift-master-controllers -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"master-ose-master-0.example.com-10.19.115.212-dnwrtcl4","leaseDurationSeconds":15,"acquireTime":"2018-02-17T18:16:54Z","renewTime":"2018-02-19T13:50:33Z","leaderTransitions":16}'
  creationTimestamp: 2018-02-02T10:30:04Z
  name: openshift-master-controllers
  namespace: kube-system
  resourceVersion: "17349662"
  selfLink: /api/v1/namespaces/kube-system/configmaps/openshift-master-controllers
  uid: 08636843-0804-11e8-8580-fa163eb934f0

이 명령은 holderIdentity 속성 내에서 control-plane.alpha.kubernetes.io/leader 주석으로 현재 마스터 컨트롤러를 다음과 같이 출력합니다.

master-<hostname>-<ip>-<8_random_characters>

다음을 통해 출력을 필터링하여 마스터 호스트의 호스트 이름을 찾으십시오.

$ oc get -n kube-system cm openshift-master-controllers -o json | jq -r '.metadata.annotations[] | fromjson.holderIdentity | match("^master-(.*)-[0-9.]*-[0-9a-z]{8}$") | .captures[0].string'
ose-master-0.example.com

3.10. 올바른 최대 전송 단위(MTU) 크기 확인

최대 전송 단위(MTU)를 확인하면 SSL 인증서 문제로 가장할 수 있는 잘못된 네트워킹 구성을 방지할 수 있습니다.

패킷이 HTTP를 통해 전송된 MTU 크기보다 큰 경우 물리적 네트워크 라우터에서 패킷을 여러 패킷으로 나누어 데이터를 전송할 수 있습니다. 그러나 패킷이 HTTPS를 통해 전송된 MTU 크기보다 크면 라우터에서 패킷을 삭제해야합니다.

설치하면 다음을 비롯하여 여러 구성 요소에 안전하게 연결할 수 있는 인증서를 생성합니다.

  • 마스터 호스트
  • 노드 호스트
  • 인프라 노드
  • 레지스트리
  • 라우터

이러한 인증서는 마스터 노드의 경우 /etc/origin/master 디렉터리에 있으며, 인프라 및 앱 노드의 경우 /etc/origin/node 디렉터리에 있습니다.

설치 후 네트워크 연결 섹션에 설명된 프로세스를 사용하여 REGISTRY_OPENSHIFT_SERVER_ADDR에 대한 연결을 확인할 수 있습니다.

전제 조건
  1. 마스터 호스트에서 HTTPS 주소를 가져옵니다.

    $ oc -n default get dc docker-registry -o jsonpath='{.spec.template.spec.containers[].env[?(@.name=="REGISTRY_OPENSHIFT_SERVER_ADDR")].value}{"\n"}'
    docker-registry.default.svc:5000

    위의 결과는 docker-registry.default.svc : 5000의 출력을 제공합니다.

  2. /healthz를 위에 제공된 값에 추가하고, 이를 사용하여 모든 호스트(마스터, 인프라, 노드)를 확인하십시오.

    $ curl -v https://docker-registry.default.svc:5000/healthz
    * About to connect() to docker-registry.default.svc port 5000 (#0)
    *   Trying 172.30.11.171...
    * Connected to docker-registry.default.svc (172.30.11.171) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    * Server certificate:
    * 	subject: CN=172.30.11.171
    * 	start date: Oct 18 05:30:10 2017 GMT
    * 	expire date: Oct 18 05:30:11 2019 GMT
    * 	common name: 172.30.11.171
    * 	issuer: CN=openshift-signer@1508303629
    > GET /healthz HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: docker-registry.default.svc:5000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Date: Tue, 24 Oct 2017 19:42:35 GMT
    < Content-Length: 0
    < Content-Type: text/plain; charset=utf-8
    <
    * Connection #0 to host docker-registry.default.svc left intact

    위의 예제 출력에서는 SSL 연결이 올바른지 확인하는 데 사용되는 MTU 크기를 보여줍니다. 연결 시도에 성공한 후 연결이 설정되고 certpath 및 docker-registry에 관한 모든 서버 인증서 정보로 NSS를 초기화하여 완료합니다.

    MTU 크기가 잘못되면 시간 초과가 발생합니다.

    $ curl -v https://docker-registry.default.svc:5000/healthz
    * About to connect() to docker-registry.default.svc port 5000 (#0)
    *   Trying 172.30.11.171...
    * Connected to docker-registry.default.svc (172.30.11.171) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb

    위의 예에서는 연결이 설정되었지만 certpath를 사용하여 NSS 초기화를 완료할 수 없음을 보여줍니다. 이 문제는 적절한 노드 구성 맵에 설정된 부적절한 MTU 크기를 처리합니다.

    이 문제를 해결하려면 노드 구성 맵에서 MTU 크기를 OpenShift SDN 이더넷 장치에서 사용하는 MTU 크기보다 50바이트 작게 조정하십시오.

  3. 원하는 이더넷 장치(예: eth0)의 MTU 크기를 확인하십시오.

    $ ip link show eth0
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
        link/ether fa:16:3e:92:6a:86 brd ff:ff:ff:ff:ff:ff

    위의 MTU는 1500으로 설정되어 있습니다.

  4. MTU 크기를 변경하려면 적절한 노드 구성 맵을 수정하고 ip 명령을 통해 제공되는 출력보다 50바이트 작은 값을 설정하십시오.

    예를 들어, MTU 크기가 1500으로 설정된 경우 노드 구성 맵에서 MTU 크기를 1450으로 조정하십시오.

    networkConfig:
       mtu: 1450
  5. 변경사항을 저장하고 노드를 재부팅하십시오.

    참고

    OpenShift Container Platform SDN의 일부인 모든 마스터 및 노드에서 MTU 크기를 변경해야 합니다. 또한 tun0 인터페이스의 MTU 크기는 클러스터의 일부인 모든 노드에서 같아야 합니다.

  6. 노드가 다시 온라인 상태가 되면 원래 curl 명령을 다시 실행하여 문제가 더 이상 없는지 확인하십시오.

    $ curl -v https://docker-registry.default.svc:5000/healthz

    시간 초과가 지속되면 MTU 크기를 50바이트씩 증분하여 계속 조정하고 프로세스를 반복하십시오.

4장. 환경 전체 백업 생성

환경 전체 백업을 생성하려면 인스턴스가 충돌하거나 데이터가 손상된 경우 복원할 수 있도록 중요한 데이터를 복사해야 합니다. 백업이 생성되면 새로 설치된 버전의 관련 구성 요소로 백업을 복원할 수 있습니다.

OpenShift Container Platform에서 클러스터 수준으로 개별 스토리지에 상태를 저장하여 백업할 수 있습니다. 환경 백업의 전체 상태는 다음과 같습니다.

  • 클러스터 데이터 파일
  • 각 마스터의 etcd 데이터
  • API 오브젝트
  • 레지스트리 스토리지
  • 볼륨 스토리지

데이터 손실을 방지하기 위해 정기적으로 백업을 수행하십시오.

중요

다음 프로세스에서는 애플리케이션 및 OpenShift Container Platform 클러스터를 백업하는 일반적인 방법을 설명합니다. 사용자 정의 요구 사항을 고려할 수 없습니다. 이 단계를 클러스터 전체 백업 및 복원 프로시저의 기초로 사용하십시오. 데이터 손실을 방지하기 위해 필요한 모든 예방 조치를 취해야 합니다.

백업 및 복원은 보장되지 않습니다. 자신의 데이터를 백업할 책임은 각자에게 있습니다.

4.1. 마스터 호스트 백업 생성

시스템 업데이트, 업그레이드 또는 기타 중요한 수정과 같은 OpenShift Container Platform 인프라를 변경하기 전에 이 백업 프로세스를 수행하십시오. 장애가 발생할 경우 최신 데이터를 사용할 수 있도록 데이터를 정기적으로 백업하십시오.

OpenShift Container Platform 파일

마스터 인스턴스는 API, 컨트롤러와 같은 중요한 서비스를 실행합니다. /etc/origin/master 디렉터리에서는 다음과 같은 여러 중요한 파일을 저장합니다.

  • 구성, API, 컨트롤러, 서비스 등
  • 설치를 통해 생성된 인증서
  • 모든 클라우드 공급자 관련 구성
  • htpasswd를 사용하는 경우 키와 기타 인증 파일(예: htpasswd)
  • 기타 등등

로그 레벨 증가 또는 프록시 사용과 같은 OpenShift Container Platform 서비스를 사용자 정의할 수 있습니다. 구성 파일은 /etc/sysconfig 디렉터리에 저장됩니다.

마스터도 노드이므로 전체 /etc/origin 디렉터리를 백업하십시오.

프로시저

중요

각 마스터 노드에서 다음 단계를 수행해야 합니다.

  1. 여기에 있는 포드 정의의 백업을 생성하십시오.
  2. 마스터 호스트 구성 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/ ${MYBACKUPDIR}/etc/sysconfig/
    참고

    마스터 구성 파일은 /etc/origin/master/master-config.yaml입니다.

    주의

    /etc/origin/master/ca.serial.txt 파일은 Ansible 호스트 인벤토리에 나열된 첫 번째 마스터에서만 생성됩니다. 첫 번째 마스터 호스트를 더 이상 사용하지 않는 경우 프로세스 전에 /etc/origin/master/ca.serial.txt 파일을 나머지 마스터 호스트에 복사하십시오.

    중요

    여러 마스터를 실행하는 OpenShift Container Platform 3.11 클러스터에서 마스터 노드 중 하나는 /etc/origin/master, /etc/etcd/ca/etc/etcd/generated_certs에 추가 CA 인증서를 포함합니다. 이러한 인증서는 애플리케이션 노드와 etcd 노드 확장 작업에 필요하며, 원래 마스터를 영구적으로 사용할 수 없게 되는 경우 다른 마스터 노드에 복원해야 합니다. 이러한 디렉터리는 기본적으로 여기에 설명된 백업 프로시저에 포함됩니다.

  3. 백업을 계획할 때 고려해야 할 다른 중요한 파일은 다음과 같습니다.

    파일

    설명

    /etc/cni/*

    컨테이너 네트워크 인터페이스 구성(사용된 경우)

    /etc/sysconfig/iptables

    iptables 규칙이 저장된 위치

    /etc/sysconfig/docker-storage-setup

    container-storage-setup 명령의 입력 파일

    /etc/sysconfig/docker

    docker 구성 파일

    /etc/sysconfig/docker-network

    docker 네트워킹 구성(예: MTU)

    /etc/sysconfig/docker-storage

    docker 스토리지 구성(container-storage-setup을 통해 생성)

    /etc/dnsmasq.conf

    dnsmasq의 기본 구성 파일

    /etc/dnsmasq.d/*

    다른 dnsmasq 구성 파일

    /etc/sysconfig/flanneld

    flannel 구성 파일(사용된 경우)

    /etc/pki/ca-trust/source/anchors/

    시스템에 추가된 인증서(예 : 외부 레지스트리용)

    다음 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  4. 패키지가 실수로 제거되었거나 rpm 패키지에 포함된 파일을 복원해야 하는 경우 시스템에 rhel 패키지 목록이 설치되어 있으면 유용할 수 있습니다.

    참고

    콘텐츠 뷰 또는 사실 저장소와 같은 Red Hat Satellite 기능을 사용하는 경우 누락된 패키지 및 시스템에 설치된 패키지의 히스토리 데이터를 다시 설치하는 적절한 메커니즘을 제공하십시오.

    시스템에 설치된 현재 rhel 패키지 목록을 작성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  5. 이전 단계를 사용한 경우 다음 파일이 백업 디렉터리에 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/master/ca.crt
    etc/origin/master/ca.key
    etc/origin/master/ca.serial.txt
    etc/origin/master/ca-bundle.crt
    etc/origin/master/master.proxy-client.crt
    etc/origin/master/master.proxy-client.key
    etc/origin/master/service-signer.crt
    etc/origin/master/service-signer.key
    etc/origin/master/serviceaccounts.private.key
    etc/origin/master/serviceaccounts.public.key
    etc/origin/master/openshift-master.crt
    etc/origin/master/openshift-master.key
    etc/origin/master/openshift-master.kubeconfig
    etc/origin/master/master.server.crt
    etc/origin/master/master.server.key
    etc/origin/master/master.kubelet-client.crt
    etc/origin/master/master.kubelet-client.key
    etc/origin/master/admin.crt
    etc/origin/master/admin.key
    etc/origin/master/admin.kubeconfig
    etc/origin/master/etcd.server.crt
    etc/origin/master/etcd.server.key
    etc/origin/master/master.etcd-client.key
    etc/origin/master/master.etcd-client.csr
    etc/origin/master/master.etcd-client.crt
    etc/origin/master/master.etcd-ca.crt
    etc/origin/master/policy.json
    etc/origin/master/scheduler.json
    etc/origin/master/htpasswd
    etc/origin/master/session-secrets.yaml
    etc/origin/master/openshift-router.crt
    etc/origin/master/openshift-router.key
    etc/origin/master/registry.crt
    etc/origin/master/registry.key
    etc/origin/master/master-config.yaml
    etc/origin/generated-configs/master-master-1.example.com/master.server.crt
    ...[OUTPUT OMITTED]...
    etc/origin/cloudprovider/openstack.conf
    etc/origin/node/system:node:master-0.example.com.crt
    etc/origin/node/system:node:master-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:master-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    필요한 경우 파일을 압축하여 공간을 절약할 수 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

이러한 파일을 처음부터 새로 생성하기 위해 openshift-ansible-contrib 리포지토리에는 이전 단계를 수행하는 backup_master_node.sh 스크립트가 포함되어 있습니다. 스크립트에서는 스크립트를 실행하는 호스트에 디렉터리를 생성하고 이전에 언급된 모든 파일을 복사합니다.

참고

Openshift-ansible-contrib 스크립트는 Red Hat에서 지원하지 않지만, 참조 아키텍처 팀에서는 코드가 정의된 대로 작동하고 안전하도록 테스트를 수행합니다.

다음을 사용하여 모든 마스터 호스트에서 스크립트를 실행할 수 있습니다.

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

4.2. 노드 호스트 백업 생성

노드 호스트의 백업 생성은 마스터 호스트 백업과 다른 사용 사례입니다. 마스터 호스트에는 많은 중요한 파일이 포함되어 있으므로 백업을 만드는 것이 좋습니다. 그러나 노드의 특성은 장애 조치(failover)의 경우 노드에 특별한 항목이 복제되며. 일반적으로 환경을 실행하는 데 필요한 데이터는 포함하지 않는다는 것입니다. 노드 백업에 환경을 실행하는 데 필요한 것이 있으면 백업을 생성하는 것이 좋습니다.

백업 프로세스는 시스템 업데이트, 업그레이드 또는 기타 중요한 수정과 같이 인프라를 변경하기 전에 수행해야 합니다. 장애가 발생할 경우 최신 데이터를 사용할 수 있도록 정기적으로 백업을 수행해야 합니다.

OpenShift Container Platform 파일

노드 인스턴스는 컨테이너를 기반으로 하는 포드 양식으로 애플리케이션을 실행합니다. /etc/origin//etc/origin/node 디렉터리에 다음과 같은 중요한 파일이 있습니다.

  • 노드 서비스의 구성
  • 설치를 통해 생성된 인증서
  • 클라우드 공급자 관련 구성
  • dnsmasq 구성과 같은 키 및 기타 인증 파일

OpenShift Container Platform 서비스는 로그 레벨을 높이고 프록시를 사용하도록 사용자 정의할 수 있으며 구성 파일은 /etc/sysconfig 디렉터리에 저장됩니다.

프로시저

  1. 노드 구성 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/atomic-openshift-node ${MYBACKUPDIR}/etc/sysconfig/
  2. OpenShift Container Platform에서는 다음을 포함하여 백업 정책을 계획할 때 고려해야 하는 특정 파일을 사용합니다.

    파일

    설명

    /etc/cni/*

    컨테이너 네트워크 인터페이스 구성(사용된 경우)

    /etc/sysconfig/iptables

    iptables 규칙이 저장된 위치

    /etc/sysconfig/docker-storage-setup

    container-storage-setup 명령의 입력 파일

    /etc/sysconfig/docker

    docker 구성 파일

    /etc/sysconfig/docker-network

    docker 네트워킹 구성(예: MTU)

    /etc/sysconfig/docker-storage

    docker 스토리지 구성(container-storage-setup을 통해 생성)

    /etc/dnsmasq.conf

    dnsmasq의 기본 구성 파일

    /etc/dnsmasq.d/*

    다른 dnsmasq 구성 파일

    /etc/sysconfig/flanneld

    flannel 구성 파일(사용된 경우)

    /etc/pki/ca-trust/source/anchors/

    시스템에 추가된 인증서(예 : 외부 레지스트리용)

    해당 파일을 생성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  3. 패키지가 실수로 제거되거나 rpm 패키지에 포함된 파일을 복원해야 하는 경우 시스템에 rhel 패키지 목록이 설치되어 있으면 유용할 수 있습니다.

    참고

    콘텐츠 뷰 또는 사실 저장소와 같은 Red Hat Satellite 기능을 사용하는 경우 누락된 패키지 및 시스템에 설치된 패키지의 히스토리 데이터를 다시 설치하는 적절한 메커니즘을 제공하십시오.

    시스템에 설치된 현재 rhel 패키지 목록을 작성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  4. 이제 다음 파일이 백업 디렉터리에 있어야 합니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/atomic-openshift-node
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/node/system:node:app-node-0.example.com.crt
    etc/origin/node/system:node:app-node-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:app-node-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/origin/cloudprovider/openstack.conf
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    필요한 경우 파일을 압축하여 공간을 절약할 수 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

이러한 파일을 처음부터 새로 생성하기 위해 openshift-ansible-contrib 리포지토리에는 이전 단계를 수행하는 backup_master_node.sh 스크립트가 포함되어 있습니다. 스크립트에서는 스크립트를 실행하는 호스트에 디렉터리를 생성하고 이전에 언급된 모든 파일을 복사합니다.

참고

Openshift-ansible-contrib 스크립트는 Red Hat에서 지원하지 않지만, 참조 아키텍처 팀에서는 코드가 정의된 대로 작동하고 안전하도록 테스트를 수행합니다.

스크립트는 다음을 사용하여 모든 마스터 호스트에서 실행될 수 있습니다.

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

4.3. 레지스트리 인증서 백업

외부 보안 레지스트리를 사용하는 경우 모든 레지스트리 인증서를 저장해야 합니다. 레지스트리는 기본적으로 보호됩니다.

중요

각 클러스터 노드에서 다음 단계를 수행해야 합니다.

프로시저

  1. 레지스트리 인증서를 백업하십시오.

    # cd /etc/docker/certs.d/
    # tar cf /tmp/docker-registry-certs-$(hostname).tar *
  2. 백업을 외부 위치로 이동하십시오.
참고

하나 이상의 외부 보안 레지스트리로 작업할 때 이미지를 가져오거나 푸시하는 모든 호스트에서는 포드를 실행하기 위해 레지스트리 인증서를 신뢰해야 합니다.

4.4. 다른 설치 파일 백업

OpenShift Container Platform을 설치하는 데 사용한 파일을 백업하십시오.

프로시저

  1. 복원 프로시저에는 전체 재설치가 포함되므로 초기 설치에 사용된 모든 파일을 저장하십시오. 이러한 파일에는 다음이 포함될 수 있습니다.

  2. 설치 후 단계에 대한 프로시저를 백업하십시오. 일부 설치에는 설치 프로그램에 포함되지 않은 단계가 포함될 수 있습니다. 이러한 단계에는 OpenShift Container Platform의 제어 범위를 벗어난 서비스 변경 또는 모니터링 에이전트와 같은 추가 서비스 설치가 포함될 수 있습니다. 여러 인증 공급자를 사용하는 등 고급 설치 관리자가 아직 지원하지 않는 추가 구성에도 영향을 줄 수 있습니다.

4.5. 애플리케이션 데이터 백업

대부분의 경우 컨테이너 이미지 내에 rsync가 설치되어 있다고 가정하면 oc rsync 명령을 사용하여 애플리케이션 데이터를 백업할 수 있습니다. Red Hat rhel7 기본 이미지에는 rsync가 포함되어 있습니다. 따라서 rhel7을 기반으로하는 모든 이미지에도 포함됩니다. CLI 작업 문제 해결 및 디버깅 -rsync를 참조하십시오.

주의

이는 애플리케이션 데이터의 일반 백업이며 데이터베이스 시스템의 특수 내보내기 및 가져오기 프로시저와 같은 애플리케이션별 백업 프로시저는 고려하지 않습니다.

Cinder, NFS 또는 Gluster와 같이 사용하는 영구 볼륨의 유형에 따라 다른 백업 수단이 존재할 수 있습니다.

백업 경로도 애플리케이션에 따라 다릅니다. deploymentconfig에 있는 볼륨의 mountPath를 보고 백업할 경로를 결정할 수 있습니다.

참고

애플리케이션 포드가 실행되는 동안에만 이 유형의 애플리케이션 데이터 백업을 수행할 수 있습니다.

프로시저

Jenkins 배치의 애플리케이션 데이터를 백업하는 예

  1. deploymentconfig에서 애플리케이션 데이터 mountpath를 가져오십시오.

    $ oc get dc/jenkins -o jsonpath='{ .spec.template.spec.containers[?(@.name=="jenkins")].volumeMounts[?(@.name=="jenkins-data")].mountPath }'
    /var/lib/jenkins
  2. 현재 실행 중인 포드 이름을 가져오십시오.

    $ oc get pod --selector=deploymentconfig=jenkins -o jsonpath='{ .metadata.name }'
    jenkins-1-37nux
  3. oc rsync 명령을 사용하여 애플리케이션 데이터를 복사하십시오.

    $ oc rsync jenkins-1-37nux:/var/lib/jenkins /tmp/

4.6. etcd 백업

etcd는 영구 마스터 상태 외에도 모든 오브젝트 정의의 키 값 저장소입니다. 다른 구성 요소에서 변경을 기다린 다음 원하는 상태로 이동합니다.

3.5 이전의 OpenShift Container Platform 버전에서는 etcd 버전 2(v2)를 사용하고 3.5 이상에서는 버전 3(v3)을 사용합니다. etcd의 두 버전 간 데이터 모델은 서로 다릅니다. etcd v3에서는 v2 및 v3 데이터 모델을 모두 사용할 수 있는 반면 etcd v2에서는 v2 데이터 모델만 사용할 수 있습니다. etcd v3 서버에서 v2 및 v3 데이터 저장소는 병렬로 존재하며 독립적입니다.

v2 및 v3 작업 모두에서 ETCDCTL_API 환경 변수를 사용하여 올바른 API를 사용할 수 있습니다.

$ etcdctl -v
etcdctl version: 3.2.5
API version: 2
$ ETCDCTL_API=3 etcdctl version
etcdctl version: 3.2.5
API version: 3.2

v3으로 마이그레이션하는 방법에 대한 정보는 OpenShift Container Platform 3.7 설명서의 etcd 데이터 마이그레이션(v2에서 v3으로) 섹션을 참조하십시오.

OpenShift Container Platform 버전 3.10 이상에서는 별도의 호스트에 etcd를 설치하거나 마스터 호스트에서 정적 포드로 실행할 수 있습니다. 별도의 etcd 호스트를 지정하지 않으면 etcd는 마스터 호스트에서 정적 포드로 실행됩니다. 이와 같은 차이 때문에 정적 포드를 사용하면 백업 프로세스가 달라집니다.

etcd 백업 프로세스는 두 가지 서로 다른 프로시저로 구성됩니다.

  • 구성 백업: 필수 etcd 구성 및 인증서를 포함합니다.
  • 데이터 백업: v2 및 v3 데이터 모델을 포함합니다.

etcd 클러스터에 연결되어 있고 적절한 인증서가 제공되며 etcdctl 도구가 설치된 모든 호스트에서 데이터 백업 프로세스를 수행할 수 있습니다.

참고

백업 파일은 외부 시스템, 이상적으로는 OpenShift Container Platform 환경 외부에 복사한 다음 암호화해야 합니다.

etcd 백업에는 여전히 현재 스토리지 볼륨에 대한 모든 참조가 있습니다. etcd를 복원하면 OpenShift Container Platform이 노드에서 이전 포드를 시작하고 동일한 스토리지를 다시 연결하기 시작합니다. 이 프로세스는 클러스터에서 노드를 제거하고 그 자리에 새 노드를 다시 추가하는 프로세스와 다르지 않습니다. 해당 노드에 연결된 모든 항목은 다시 스케줄링된 모든 노드의 포드에 다시 연결됩니다.

4.6.1. etcd 백업

etcd를 백업할 때 etcd 구성 파일과 etcd 데이터를 둘 다 백업해야 합니다.

4.6.1.1. etcd 구성 파일 백업

보존할 etcd 구성 파일은 모두 etcd가 실행 중인 인스턴스의 /etc/etcd 디렉터리에 저장됩니다. 여기에는 etcd 구성 파일(/etc/etcd/etcd.conf)과 클러스터 통신에 필요한 인증서가 포함됩니다. 이러한 모든 파일은 Ansible 설치 프로그램에서 설치 시 생성됩니다.

프로시저

클러스터의 etcd 멤버마다 etcd 구성을 백업하십시오.

$ ssh master-0
# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
참고

각 etcd 클러스터 멤버의 인증서 및 구성 파일은 고유합니다.

4.6.1.2. etcd 데이터 백업

전제 조건
참고

OpenShift Container Platform 설치 프로그램에서는 etcd v2 작업의 etcdctl2 및 etcd v3 작업의 etcdctl3이라는 모든 플래그를 입력하지 않도록 별칭을 생성합니다.

그러나 etcdctl3 별명에서는 etcdctl 명령에 전체 끝점 목록을 제공하지 않으므로, --endpoints 옵션을 지정하고 모든 끝점을 나열해야 합니다.

etcd를 백업하기 전에 다음을 수행하십시오.

  • etcdctl 바이너리가 사용 가능해야 하거나 컨테이너화 된 설치에서 rhel7/etcd 컨테이너가 사용 가능해야 합니다.
  • OpenShift Container Platform API 서비스가 실행 중인지 확인하십시오.
  • etcd 클러스터(2379/tcp 포트)와의 연결을 확인하십시오.
  • etcd 클러스터에 연결하기 위한 적절한 인증서를 확인하십시오.
  • go가 설치되어 있는지 확인하십시오.

    1. etcd 클러스터가 작동하는지 확인하려면 상태를 점검하십시오.

      • 다음 명령을 실행하십시오.

        # ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \
                  --key=/etc/etcd/peer.key \
                  --cacert="/etc/etcd/ca.crt" \
                  --endpoints="https://*master-0.example.com*:2379,\
                    https://*master-1.example.com*:2379,\
                    https://*master-2.example.com*:2379"
                    endpoint health
        https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
        https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
        https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
    2. 멤버 목록을 확인하십시오.

      # etcdctl3 member list
      2a371dd20f21ca8d, started, master-1.example.com, https://192.168.55.12:2380, https://192.168.55.12:2379
      40bef1f6c79b3163, started, master-0.example.com, https://192.168.55.8:2380, https://192.168.55.8:2379
      95dc17ffcce8ee29, started, master-2.example.com, https://192.168.55.13:2380, https://192.168.55.13:2379
프로시저
참고

etcdctl backup 명령은 백업을 수행하는 데 사용되는 반면 etcd v3에는 백업의 개념이 없습니다. 대신 etcdctl snapshot save 명령을 사용하여 활성 멤버에서 스냅샷을 작성하거나 etcd 데이터 디렉터리에서 member/snap/db 파일을 복사합니다.

etcdctl backup 명령을 실행하면 백업에 포함된 일부 메타데이터, 특히 노드 ID 및 클러스터 ID를 다시 작성합니다. 즉, 백업에서 노드의 이전 ID가 손실됩니다. 백업에서 클러스터를 다시 생성하려면 새로운 단일 노드 클러스터를 생성한 후 나머지 노드를 클러스터에 추가하십시오. 새 노드가 기존 클러스터에 참여하지 못하도록 메타데이터가 다시 작성됩니다.

etcd 데이터를 백업하십시오.

중요

이전 버전의 OpenShift Container Platform에서 업그레이드된 클러스터에는 v2 데이터 저장소가 포함될 수 있습니다. 모든 etcd 데이터 저장소를 백업하십시오.

  1. etcd 노드의 스냅샷을 작성하십시오.

    # systemctl show etcd --property=ActiveState,SubState
    # mkdir -p /var/lib/etcd/backup/etcd-$(date +%Y%m%d) 1
    # etcdctl3 snapshot save /var/lib/etcd/backup/etcd-$(date +%Y%m%d)/db
    1
    /var/lib/etcd/의 디렉터리에 스냅샷을 써야 합니다.
    참고

    etcdctl snapshot save 명령을 실행하려면 etcd 서비스가 실행 중이어야 합니다.

  2. etcd 포드 정의를 제거하고 호스트를 재부팅하여 모든 etcd 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  3. etcd 데이터 백업을 생성하고 etcd db 파일을 복사하십시오.

    # etcdctl2 backup \
        --data-dir /var/lib/etcd \
        --backup-dir /backup/etcd-$(date +%Y%m%d)

    /backup/etcd-<date>/ 디렉터리가 생성됩니다. 여기서 <date>는 현재 날짜를 나타내며, 외부 NFS 공유, S3 버킷 또는 외부 스토리지 위치여야 합니다.

    일체형 클러스터의 경우 etcd 데이터 디렉터리는 /var/lib/origin/openshift.local.etcd 디렉터리에 있습니다.

    • etcd가 정적 포드로 실행되는 경우 다음 명령을 실행하십시오.

      중요

      정적 포드를 사용하는 경우 v3 API를 사용하십시오.

  4. 정적 포드 매니페스트에서 etcd 끝점 IP 주소를 얻습니다.

    $ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
    $ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
  5. etcd 포드 이름을 확보하십시오.

    $ oc login -u system:admin
    $ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '\S*etcd\S*')
  6. 포드에서 etcd 데이터의 스냅샷을 작성하여 로컬에 저장하십시오.

    $ oc project kube-system
    $ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \
        --cert /etc/etcd/peer.crt \
        --key /etc/etcd/peer.key \
        --cacert /etc/etcd/ca.crt \
        --endpoints $ETCD_EP \
        snapshot save /var/lib/etcd/snapshot.db"

4.7. 프로젝트 백업

관련된 모든 데이터의 백업을 생성하려면 중요한 정보를 모두 내보낸 다음 새 프로젝트로 복원해야 합니다.

중요

oc get all 명령은 특정 프로젝트 리소스만 반환하므로 다음 단계에 표시된 대로 PVC 및 보안을 비롯한 다른 리소스를 별도로 백업해야 합니다.

프로시저

  1. 백업할 프로젝트 데이터를 나열하십시오.

    $ oc get all
    NAME         TYPE      FROM      LATEST
    bc/ruby-ex   Source    Git       1
    
    NAME               TYPE      FROM          STATUS     STARTED         DURATION
    builds/ruby-ex-1   Source    Git@c457001   Complete   2 minutes ago   35s
    
    NAME                 DOCKER REPO                                     TAGS      UPDATED
    is/guestbook         10.111.255.221:5000/myproject/guestbook         latest    2 minutes ago
    is/hello-openshift   10.111.255.221:5000/myproject/hello-openshift   latest    2 minutes ago
    is/ruby-22-centos7   10.111.255.221:5000/myproject/ruby-22-centos7   latest    2 minutes ago
    is/ruby-ex           10.111.255.221:5000/myproject/ruby-ex           latest    2 minutes ago
    
    NAME                 REVISION   DESIRED   CURRENT   TRIGGERED BY
    dc/guestbook         1          1         1         config,image(guestbook:latest)
    dc/hello-openshift   1          1         1         config,image(hello-openshift:latest)
    dc/ruby-ex           1          1         1         config,image(ruby-ex:latest)
    
    NAME                   DESIRED   CURRENT   READY     AGE
    rc/guestbook-1         1         1         1         2m
    rc/hello-openshift-1   1         1         1         2m
    rc/ruby-ex-1           1         1         1         2m
    
    NAME                  CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
    svc/guestbook         10.111.105.84    <none>        3000/TCP            2m
    svc/hello-openshift   10.111.230.24    <none>        8080/TCP,8888/TCP   2m
    svc/ruby-ex           10.111.232.117   <none>        8080/TCP            2m
    
    NAME                         READY     STATUS      RESTARTS   AGE
    po/guestbook-1-c010g         1/1       Running     0          2m
    po/hello-openshift-1-4zw2q   1/1       Running     0          2m
    po/ruby-ex-1-build           0/1       Completed   0          2m
    po/ruby-ex-1-rxc74           1/1       Running     0          2m
  2. 프로젝트 오브젝트를 .yaml 또는 .json 파일로 내보냅니다.

    • 프로젝트 오브젝트를 project.yaml 파일로 내보내려면 다음을 수행하십시오.

      $ oc get -o yaml --export all > project.yaml
    • 프로젝트 오브젝트를 project.json 파일로 내보내려면 다음을 수행하십시오.

      $ oc get -o json --export all > project.json
  3. 프로젝트의 역할 바인딩, 보안, 서비스 계정영구 볼륨 클레임을 내보냅니다.

    $ for object in rolebindings serviceaccounts secrets imagestreamtags cm egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvc templates cronjobs statefulsets hpa deployments replicasets poddisruptionbudget endpoints
    do
      oc get -o yaml --export $object > $object.yaml
    done
  4. 네임스페이스가 지정된 모든 오브젝트를 나열하려면 다음을 수행하십시오.

    $ oc api-resources --namespaced=true -o name
  5. 내보낸 일부 오브젝트는 특정 메타데이터 또는 프로젝트의 고유 ID에 대한 참조를 사용할 수 있습니다. 이것은 재생성된 개체의 유용성에 대한 제한사항입니다.

    imagestreams를 사용하는 경우 deploymentconfigimage 매개 변수는 복원된 환경에 존재하지 않는 내부 레지스트리에 있는 이미지의 특정 sha 체크섬을 가리킬 수 있습니다. 예를 들어 샘플 "ruby-ex"를 oc new-app centos/ruby-22-centos7~https://github.com/sclorg/ruby-ex.git로 실행하면 이미지를 호스팅하기 위해 내부 레지스트리를 사용하여 imagestream ruby-ex를 생성합니다.

    $ oc get dc ruby-ex -o jsonpath="{.spec.template.spec.containers[].image}"
    10.111.255.221:5000/myproject/ruby-ex@sha256:880c720b23c8d15a53b01db52f7abdcbb2280e03f686a5c8edfef1a2a7b21cee

    deploymentconfig를 가져오는 경우 oc get --export를 통해 내보냈으므로 이미지가 없으면 실패합니다.

4.8. 영구 볼륨 클레임 백업

컨테이너 내부에서 서버로 영구 데이터를 동기화할 수 있습니다.

중요

OpenShift Container Platform 환경을 호스팅하는 공급자에 따라 백업 및 복원 목적으로 타사 스냅샷 서비스를 시작하는 기능도 있습니다. OpenShift Container Platform에는 이러한 서비스를 시작할 수 있는 기능이 없으므로 이 안내서에서는 해당 단계를 설명하지 않습니다.

특정 애플리케이션의 올바른 백업 프로시저는 제품 설명서를 참조하십시오. 예를 들어, mysql 데이터 디렉터리 자체를 복사해도 사용 가능한 백업이 생성되지 않습니다. 대신 관련 애플리케이션의 특정 백업 프로시저를 실행한 다음 모든 데이터를 동기화하십시오. 여기에는 OpenShift Container Platform 호스팅 플랫폼에서 제공하는 스냅샷 솔루션 사용이 포함됩니다.

프로시저

  1. 프로젝트와 포드를 보십시오.

    $ oc get pods
    NAME           READY     STATUS      RESTARTS   AGE
    demo-1-build   0/1       Completed   0          2h
    demo-2-fxx6d   1/1       Running     0          1h
  2. 영구 볼륨에서 현재 사용 중인 볼륨을 찾으려면 원하는 포드를 설명하십시오.

    $ oc describe pod demo-2-fxx6d
    Name:			demo-2-fxx6d
    Namespace:		test
    Security Policy:	restricted
    Node:			ip-10-20-6-20.ec2.internal/10.20.6.20
    Start Time:		Tue, 05 Dec 2017 12:54:34 -0500
    Labels:			app=demo
    			deployment=demo-2
    			deploymentconfig=demo
    Status:			Running
    IP:			172.16.12.5
    Controllers:		ReplicationController/demo-2
    Containers:
      demo:
        Container ID:	docker://201f3e55b373641eb36945d723e1e212ecab847311109b5cee1fd0109424217a
        Image:		docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Image ID:		docker-pullable://docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Port:		8080/TCP
        State:		Running
          Started:		Tue, 05 Dec 2017 12:54:52 -0500
        Ready:		True
        Restart Count:	0
        Volume Mounts:
          */opt/app-root/src/uploaded from persistent-volume (rw)*
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-8mmrk (ro)
        Environment Variables:	<none>
    ...omitted...

    이 출력에서는 영구 데이터가 /opt/app-root/src/uploaded 디렉터리에 있음을 보여줍니다.

  3. 로컬로 데이터를 복사하십시오.

    $ oc rsync demo-2-fxx6d:/opt/app-root/src/uploaded ./demo-app
    receiving incremental file list
    uploaded/
    uploaded/ocp_sop.txt
    uploaded/lost+found/
    
    sent 38 bytes  received 190 bytes  152.00 bytes/sec
    total size is 32  speedup is 0.14

    백업 소프트웨어 또는 또 다른 백업 메커니즘으로 백업하기 위해 ocp_sop.txt 파일을 로컬 시스템으로 다운로드합니다.

    참고

    PVC를 사용할 필요 없이 포드를 시작하는 경우 이전 단계를 사용할 수도 있지만, 나중에 PVC가 필요하다고 결정할 수 있습니다 데이터를 보존한 다음 복원 프로세스를 사용하여 새 스토리지를 채울 수 있습니다.

5장. 호스트 수준 작업

5.1. 클러스터에 호스트 추가

클러스터에 마스터 또는 노드 호스트를 추가하는 데 대한 정보는 설치 및 구성 안내서의 기존 클러스터에 호스트 추가 섹션을 참조하십시오.

5.2. 마스터 호스트 작업

5.2.1. 마스터 호스트 사용 중단

마스터 호스트를 사용 중단하면 OpenShift Container Platform 환경에서 마스터 호스트가 제거됩니다.

마스터 호스트를 사용 중단 또는 축소하는 이유는 기본 인프라의 하드웨어 크기 조정 또는 교체하기 위해서입니다.

고가용성 OpenShift Container Platform 환경에는 최소 3개의 마스터 호스트와 3개의 etcd 노드가 필요합니다. 일반적으로 마스터 호스트는 etcd 서비스와 함께 배치됩니다. 마스터 호스트를 사용 중단하면 해당 호스트에서 etcd 정적 포드도 제거됩니다.

중요

해당 서비스 중에서 수행되는 투표 메커니즘 때문에 마스터 및 etcd 서비스가 항상 홀수로 배포되게 하십시오.

5.2.1.1. 마스터 호스트 백업 생성

시스템 업데이트, 업그레이드 또는 기타 중요한 수정과 같은 OpenShift Container Platform 인프라를 변경하기 전에 이 백업 프로세스를 수행하십시오. 장애가 발생할 경우 최신 데이터를 사용할 수 있도록 데이터를 정기적으로 백업하십시오.

OpenShift Container Platform 파일

마스터 인스턴스는 API, 컨트롤러와 같은 중요한 서비스를 실행합니다. /etc/origin/master 디렉터리에서는 다음과 같은 여러 중요한 파일을 저장합니다.

  • 구성, API, 컨트롤러, 서비스 등
  • 설치를 통해 생성된 인증서
  • 모든 클라우드 공급자 관련 구성
  • htpasswd를 사용하는 경우 키와 기타 인증 파일(예: htpasswd)
  • 기타 등등

로그 레벨 증가 또는 프록시 사용과 같은 OpenShift Container Platform 서비스를 사용자 정의할 수 있습니다. 구성 파일은 /etc/sysconfig 디렉터리에 저장됩니다.

마스터도 노드이므로 전체 /etc/origin 디렉터리를 백업하십시오.

프로시저
중요

각 마스터 노드에서 다음 단계를 수행해야 합니다.

  1. 여기에 있는 포드 정의의 백업을 생성하십시오.
  2. 마스터 호스트 구성 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/ ${MYBACKUPDIR}/etc/sysconfig/
    참고

    마스터 구성 파일은 /etc/origin/master/master-config.yaml입니다.

    주의

    /etc/origin/master/ca.serial.txt 파일은 Ansible 호스트 인벤토리에 나열된 첫 번째 마스터에서만 생성됩니다. 첫 번째 마스터 호스트를 더 이상 사용하지 않는 경우 프로세스 전에 /etc/origin/master/ca.serial.txt 파일을 나머지 마스터 호스트에 복사하십시오.

    중요

    여러 마스터를 실행하는 OpenShift Container Platform 3.11 클러스터에서 마스터 노드 중 하나는 /etc/origin/master, /etc/etcd/ca/etc/etcd/generated_certs에 추가 CA 인증서를 포함합니다. 이러한 인증서는 애플리케이션 노드와 etcd 노드 확장 작업에 필요하며, 원래 마스터를 영구적으로 사용할 수 없게 되는 경우 다른 마스터 노드에 복원해야 합니다. 이러한 디렉터리는 기본적으로 여기에 설명된 백업 프로시저에 포함됩니다.

  3. 백업을 계획할 때 고려해야 할 다른 중요한 파일은 다음과 같습니다.

    파일

    설명

    /etc/cni/*

    컨테이너 네트워크 인터페이스 구성(사용된 경우)

    /etc/sysconfig/iptables

    iptables 규칙이 저장된 위치

    /etc/sysconfig/docker-storage-setup

    container-storage-setup 명령의 입력 파일

    /etc/sysconfig/docker

    docker 구성 파일

    /etc/sysconfig/docker-network

    docker 네트워킹 구성(예: MTU)

    /etc/sysconfig/docker-storage

    docker 스토리지 구성(container-storage-setup을 통해 생성)

    /etc/dnsmasq.conf

    dnsmasq의 기본 구성 파일

    /etc/dnsmasq.d/*

    다른 dnsmasq 구성 파일

    /etc/sysconfig/flanneld

    flannel 구성 파일(사용된 경우)

    /etc/pki/ca-trust/source/anchors/

    시스템에 추가된 인증서(예 : 외부 레지스트리용)

    다음 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  4. 패키지가 실수로 제거되었거나 rpm 패키지에 포함된 파일을 복원해야 하는 경우 시스템에 rhel 패키지 목록이 설치되어 있으면 유용할 수 있습니다.

    참고

    콘텐츠 뷰 또는 사실 저장소와 같은 Red Hat Satellite 기능을 사용하는 경우 누락된 패키지 및 시스템에 설치된 패키지의 히스토리 데이터를 다시 설치하는 적절한 메커니즘을 제공하십시오.

    시스템에 설치된 현재 rhel 패키지 목록을 작성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  5. 이전 단계를 사용한 경우 다음 파일이 백업 디렉터리에 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/master/ca.crt
    etc/origin/master/ca.key
    etc/origin/master/ca.serial.txt
    etc/origin/master/ca-bundle.crt
    etc/origin/master/master.proxy-client.crt
    etc/origin/master/master.proxy-client.key
    etc/origin/master/service-signer.crt
    etc/origin/master/service-signer.key
    etc/origin/master/serviceaccounts.private.key
    etc/origin/master/serviceaccounts.public.key
    etc/origin/master/openshift-master.crt
    etc/origin/master/openshift-master.key
    etc/origin/master/openshift-master.kubeconfig
    etc/origin/master/master.server.crt
    etc/origin/master/master.server.key
    etc/origin/master/master.kubelet-client.crt
    etc/origin/master/master.kubelet-client.key
    etc/origin/master/admin.crt
    etc/origin/master/admin.key
    etc/origin/master/admin.kubeconfig
    etc/origin/master/etcd.server.crt
    etc/origin/master/etcd.server.key
    etc/origin/master/master.etcd-client.key
    etc/origin/master/master.etcd-client.csr
    etc/origin/master/master.etcd-client.crt
    etc/origin/master/master.etcd-ca.crt
    etc/origin/master/policy.json
    etc/origin/master/scheduler.json
    etc/origin/master/htpasswd
    etc/origin/master/session-secrets.yaml
    etc/origin/master/openshift-router.crt
    etc/origin/master/openshift-router.key
    etc/origin/master/registry.crt
    etc/origin/master/registry.key
    etc/origin/master/master-config.yaml
    etc/origin/generated-configs/master-master-1.example.com/master.server.crt
    ...[OUTPUT OMITTED]...
    etc/origin/cloudprovider/openstack.conf
    etc/origin/node/system:node:master-0.example.com.crt
    etc/origin/node/system:node:master-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:master-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    필요한 경우 파일을 압축하여 공간을 절약할 수 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

이러한 파일을 처음부터 새로 생성하기 위해 openshift-ansible-contrib 리포지토리에는 이전 단계를 수행하는 backup_master_node.sh 스크립트가 포함되어 있습니다. 스크립트에서는 스크립트를 실행하는 호스트에 디렉터리를 생성하고 이전에 언급된 모든 파일을 복사합니다.

참고

Openshift-ansible-contrib 스크립트는 Red Hat에서 지원하지 않지만, 참조 아키텍처 팀에서는 코드가 정의된 대로 작동하고 안전하도록 테스트를 수행합니다.

다음을 사용하여 모든 마스터 호스트에서 스크립트를 실행할 수 있습니다.

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

5.2.1.2. etcd 백업

etcd를 백업할 때 etcd 구성 파일과 etcd 데이터를 둘 다 백업해야 합니다.

5.2.1.2.1. etcd 구성 파일 백업

보존할 etcd 구성 파일은 모두 etcd가 실행 중인 인스턴스의 /etc/etcd 디렉터리에 저장됩니다. 여기에는 etcd 구성 파일(/etc/etcd/etcd.conf)과 클러스터 통신에 필요한 인증서가 포함됩니다. 이러한 모든 파일은 Ansible 설치 프로그램에서 설치 시 생성됩니다.

프로시저

클러스터의 etcd 멤버마다 etcd 구성을 백업하십시오.

$ ssh master-0
# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
참고

각 etcd 클러스터 멤버의 인증서 및 구성 파일은 고유합니다.

5.2.1.2.2. etcd 데이터 백업
전제 조건
참고

OpenShift Container Platform 설치 프로그램에서는 etcd v2 작업의 etcdctl2 및 etcd v3 작업의 etcdctl3이라는 모든 플래그를 입력하지 않도록 별칭을 생성합니다.

그러나 etcdctl3 별명에서는 etcdctl 명령에 전체 끝점 목록을 제공하지 않으므로, --endpoints 옵션을 지정하고 모든 끝점을 나열해야 합니다.

etcd를 백업하기 전에 다음을 수행하십시오.

  • etcdctl 바이너리가 사용 가능해야 하거나 컨테이너화 된 설치에서 rhel7/etcd 컨테이너가 사용 가능해야 합니다.
  • OpenShift Container Platform API 서비스가 실행 중인지 확인하십시오.
  • etcd 클러스터(2379/tcp 포트)와의 연결을 확인하십시오.
  • etcd 클러스터에 연결하기 위한 적절한 인증서를 확인하십시오.
  • go가 설치되어 있는지 확인하십시오.
프로시저
참고

etcdctl backup 명령은 백업을 수행하는 데 사용되는 반면 etcd v3에는 백업의 개념이 없습니다. 대신 etcdctl snapshot save 명령을 사용하여 활성 멤버에서 스냅샷을 작성하거나 etcd 데이터 디렉터리에서 member/snap/db 파일을 복사합니다.

etcdctl backup 명령을 실행하면 백업에 포함된 일부 메타데이터, 특히 노드 ID 및 클러스터 ID를 다시 작성합니다. 즉, 백업에서 노드의 이전 ID가 손실됩니다. 백업에서 클러스터를 다시 생성하려면 새로운 단일 노드 클러스터를 생성한 후 나머지 노드를 클러스터에 추가하십시오. 새 노드가 기존 클러스터에 참여하지 못하도록 메타데이터가 다시 작성됩니다.

etcd 데이터를 백업하십시오.

중요

이전 버전의 OpenShift Container Platform에서 업그레이드된 클러스터에는 v2 데이터 저장소가 포함될 수 있습니다. 모든 etcd 데이터 저장소를 백업하십시오.

  1. etcd 노드의 스냅샷을 작성하십시오.

    # systemctl show etcd --property=ActiveState,SubState
    # mkdir -p /var/lib/etcd/backup/etcd-$(date +%Y%m%d) 1
    # etcdctl3 snapshot save /var/lib/etcd/backup/etcd-$(date +%Y%m%d)/db
    1
    /var/lib/etcd/의 디렉터리에 스냅샷을 써야 합니다.
    참고

    etcdctl snapshot save 명령을 실행하려면 etcd 서비스가 실행 중이어야 합니다.

  2. etcd 포드 정의를 제거하고 호스트를 재부팅하여 모든 etcd 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  3. etcd 데이터 백업을 생성하고 etcd db 파일을 복사하십시오.

    # etcdctl2 backup \
        --data-dir /var/lib/etcd \
        --backup-dir /backup/etcd-$(date +%Y%m%d)

    /backup/etcd-<date>/ 디렉터리가 생성됩니다. 여기서 <date>는 현재 날짜를 나타내며, 외부 NFS 공유, S3 버킷 또는 외부 스토리지 위치여야 합니다.

    일체형 클러스터의 경우 etcd 데이터 디렉터리는 /var/lib/origin/openshift.local.etcd 디렉터리에 있습니다.

    • etcd가 정적 포드로 실행되는 경우 다음 명령을 실행하십시오.

      중요

      정적 포드를 사용하는 경우 v3 API를 사용하십시오.

  4. 정적 포드 매니페스트에서 etcd 끝점 IP 주소를 얻습니다.

    $ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
    $ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
  5. etcd 포드 이름을 확보하십시오.

    $ oc login -u system:admin
    $ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '\S*etcd\S*')
  6. 포드에서 etcd 데이터의 스냅샷을 작성하여 로컬에 저장하십시오.

    $ oc project kube-system
    $ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \
        --cert /etc/etcd/peer.crt \
        --key /etc/etcd/peer.key \
        --cacert /etc/etcd/ca.crt \
        --endpoints $ETCD_EP \
        snapshot save /var/lib/etcd/snapshot.db"

5.2.1.3. 마스터 호스트 사용 중단

마스터 호스트에서는 OpenShift Container Platform API 및 컨트롤러 서비스와 같은 중요한 서비스를 실행합니다. 마스터 호스트를 사용 중단하려면 이러한 서비스를 중지해야 합니다.

OpenShift Container Platform API 서비스는 활성/활성 서비스이므로, 요청을 별도의 마스터 서버로 보내는 한 서비스를 중지해도 환경에 영향을 미치지 않습니다. 그러나 OpenShift Container Platform 컨트롤러 서비스는 활성/수동 서비스이며, 이 경우 서비스에서 etcd를 사용하여 활성 마스터를 결정합니다.

다중 마스터 아키텍처에서 마스터 호스트를 사용 중단하려면 새로운 연결에서 해당 마스터를 사용하려고 시도하지 않도록 로드 밸런서 풀에서 마스터를 제거해야 합니다. 이 프로세스는 사용된 로드 밸런서에 따라 크게 달라집니다. 아래 단계에서는 haproxy에서 마스터를 제거하는 세부 사항을 보여줍니다. OpenShift Container Platform이 클라우드 공급자에서 실행 중이거나 F5 어플라이언스를 사용하는 경우 특정 제품 문서를 참조하여 순환에서 마스터를 제거하십시오.

프로시저
  1. /etc/haproxy/haproxy.cfg 구성 파일에서 backend 섹션을 제거하십시오. 예를 들어 haproxy를 사용하여 master-0.example.com이라는 마스터를 더 이상 사용하지 않는 경우 호스트 이름이 다음에서 제거되었는지 확인하십시오.

    backend mgmt8443
        balance source
        mode tcp
        # MASTERS 8443
        server master-1.example.com 192.168.55.12:8443 check
        server master-2.example.com 192.168.55.13:8443 check
  2. 그런 다음 haproxy 서비스를 다시 시작하십시오.

    $ sudo systemctl restart haproxy
  3. 마스터가 로드 밸런서에서 제거되면 정적 포드 디렉터리 /etc/origin/node/pods에서 정의 파일을 이동하여 API와 컨트롤러 서비스를 비활성화하십시오.

    # mkdir -p /etc/origin/node/pods/disabled
    # mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:
    +
  4. 마스터 호스트는 스케줄링 가능한 OpenShift 컨테이너 플랫폼 노드이므로 노드 호스트 사용 중단 섹션의 단계를 따르십시오.
  5. /etc/ansible/hosts Ansible 인벤토리 파일의 [masters][nodes] 그룹에서 마스터 호스트를 제거하여 해당 인벤토리 파일로 Ansible 작업을 실행할 때 문제가 발생하지 않도록 하십시오.

    주의

    Ansible 인벤토리 파일에 나열된 첫 번째 마스터 호스트를 사용 중지하려면 추가 예방 조치가 필요합니다.

    /etc/origin/master/ca.serial.txt 파일은 Ansible 호스트 인벤토리에 나열된 첫 번째 마스터에서만 생성됩니다. 첫 번째 마스터 호스트를 더 이상 사용하지 않는 경우 프로세스 전에 /etc/origin/master/ca.serial.txt 파일을 나머지 마스터 호스트에 복사하십시오.

    중요

    여러 마스터를 실행하는 OpenShift Container Platform 3.11 클러스터에서 마스터 노드 중 하나는 /etc/origin/master, /etc/etcd/ca/etc/etcd/generated_certs에 추가 CA 인증서를 포함합니다. 이 인증서는 애플리케이션 노드 및 etcd 노드 확장 작업에 필요하며, CA 호스트 마스터가 사용 중지되는 경우 또 다른 마스터 노드에서 복원해야 합니다.

  6. kubernetes 서비스에는 마스터 호스트 IP가 끝점으로 포함되어 있습니다. 마스터가 올바르게 사용 중지되었는지 확인하려면 kubernetes 서비스 출력을 검토하고 사용 중지된 마스터가 제거되었는지 확인하십시오.

    $ oc describe svc kubernetes -n default
    Name:			kubernetes
    Namespace:		default
    Labels:			component=apiserver
    			provider=kubernetes
    Annotations:		<none>
    Selector:		<none>
    Type:			ClusterIP
    IP:			10.111.0.1
    Port:			https	443/TCP
    Endpoints:		192.168.55.12:8443,192.168.55.13:8443
    Port:			dns	53/UDP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Port:			dns-tcp	53/TCP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Session Affinity:	ClientIP
    Events:			<none>

    마스터가 사용 중지되면 마스터가 이전에 실행 중이던 호스트를 안전하게 삭제할 수 있습니다.

5.2.1.4. etcd 호스트 제거

etcd 호스트가 복원 이후에 실패하면 클러스터에서 제거하십시오.

모든 마스터 호스트에서 수행할 단계

프로시저
  1. etcd 클러스터에서 서로 다른 etcd 호스트를 제거하십시오. 각 etcd 노드에 대해 다음 명령을 실행하십시오.

    # etcdctl -C https://<surviving host IP address>:2379 \
      --ca-file=/etc/etcd/ca.crt     \
      --cert-file=/etc/etcd/peer.crt     \
      --key-file=/etc/etcd/peer.key member remove <failed member ID>
  2. 모든 마스터에서 마스터 API 서비스를 다시 시작하십시오.

    # master-restart api restart-master controller

현재 etcd 클러스터에서 수행할 단계

프로시저
  1. 클러스터에서 실패한 호스트를 제거하십시오.

    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    failed to check the health of member 8372784203e11288 on https://192.168.55.21:2379: Get https://192.168.55.21:2379/health: dial tcp 192.168.55.21:2379: getsockopt: connection refused
    member 8372784203e11288 is unreachable: [https://192.168.55.21:2379] are all unreachable
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    
    # etcdctl2 member remove 8372784203e11288 1
    Removed member 8372784203e11288 from cluster
    
    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    1
    remove 명령에는 호스트 이름이 아니라 etcd ID가 필요합니다.
  2. etcd 서비스를 다시 시작할 때 etcd 구성이 실패한 호스트를 사용하지 않게 하려면 나머지 모든 etcd 호스트에서 /etc/etcd/etcd.conf 파일을 수정하고 ETCD_INITIAL_CLUSTER 변수의 값에서 실패한 호스트를 제거하십시오.

    # vi /etc/etcd/etcd.conf

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

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380,master-2.example.com=https://192.168.55.13:2380

    이는 다음이 됩니다.

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380
    참고

    실패한 호스트는 etcdctl을 사용하여 제거되므로 etcd 서비스를 다시 시작할 필요가 없습니다.

  3. 클러스터의 현재 상태를 반영하고 플레이북을 다시 실행할 때 문제가 발생하지 않도록 Ansible 인벤토리 파일을 수정하십시오.

    [OSEv3:children]
    masters
    nodes
    etcd
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
  4. Flannel을 사용하는 경우 모든 호스트에서 /etc/sysconfig/flanneld에 있는 flanneld 서비스 구성을 수정하고 etcd 호스트를 제거하십시오.

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379
  5. flanneld 서비스를 다시 시작하십시오.

    # systemctl restart flanneld.service

5.2.2. 마스터 호스트 백업 생성

시스템 업데이트, 업그레이드 또는 기타 중요한 수정과 같은 OpenShift Container Platform 인프라를 변경하기 전에 이 백업 프로세스를 수행하십시오. 장애가 발생할 경우 최신 데이터를 사용할 수 있도록 데이터를 정기적으로 백업하십시오.

OpenShift Container Platform 파일

마스터 인스턴스는 API, 컨트롤러와 같은 중요한 서비스를 실행합니다. /etc/origin/master 디렉터리에서는 다음과 같은 여러 중요한 파일을 저장합니다.

  • 구성, API, 컨트롤러, 서비스 등
  • 설치를 통해 생성된 인증서
  • 모든 클라우드 공급자 관련 구성
  • htpasswd를 사용하는 경우 키와 기타 인증 파일(예: htpasswd)
  • 기타 등등

로그 레벨 증가 또는 프록시 사용과 같은 OpenShift Container Platform 서비스를 사용자 정의할 수 있습니다. 구성 파일은 /etc/sysconfig 디렉터리에 저장됩니다.

마스터도 노드이므로 전체 /etc/origin 디렉터리를 백업하십시오.

프로시저
중요

각 마스터 노드에서 다음 단계를 수행해야 합니다.

  1. 여기에 있는 포드 정의의 백업을 생성하십시오.
  2. 마스터 호스트 구성 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/ ${MYBACKUPDIR}/etc/sysconfig/
    참고

    마스터 구성 파일은 /etc/origin/master/master-config.yaml입니다.

    주의

    /etc/origin/master/ca.serial.txt 파일은 Ansible 호스트 인벤토리에 나열된 첫 번째 마스터에서만 생성됩니다. 첫 번째 마스터 호스트를 더 이상 사용하지 않는 경우 프로세스 전에 /etc/origin/master/ca.serial.txt 파일을 나머지 마스터 호스트에 복사하십시오.

    중요

    여러 마스터를 실행하는 OpenShift Container Platform 3.11 클러스터에서 마스터 노드 중 하나는 /etc/origin/master, /etc/etcd/ca/etc/etcd/generated_certs에 추가 CA 인증서를 포함합니다. 이러한 인증서는 애플리케이션 노드와 etcd 노드 확장 작업에 필요하며, 원래 마스터를 영구적으로 사용할 수 없게 되는 경우 다른 마스터 노드에 복원해야 합니다. 이러한 디렉터리는 기본적으로 여기에 설명된 백업 프로시저에 포함됩니다.

  3. 백업을 계획할 때 고려해야 할 다른 중요한 파일은 다음과 같습니다.

    파일

    설명

    /etc/cni/*

    컨테이너 네트워크 인터페이스 구성(사용된 경우)

    /etc/sysconfig/iptables

    iptables 규칙이 저장된 위치

    /etc/sysconfig/docker-storage-setup

    container-storage-setup 명령의 입력 파일

    /etc/sysconfig/docker

    docker 구성 파일

    /etc/sysconfig/docker-network

    docker 네트워킹 구성(예: MTU)

    /etc/sysconfig/docker-storage

    docker 스토리지 구성(container-storage-setup을 통해 생성)

    /etc/dnsmasq.conf

    dnsmasq의 기본 구성 파일

    /etc/dnsmasq.d/*

    다른 dnsmasq 구성 파일

    /etc/sysconfig/flanneld

    flannel 구성 파일(사용된 경우)

    /etc/pki/ca-trust/source/anchors/

    시스템에 추가된 인증서(예 : 외부 레지스트리용)

    다음 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  4. 패키지가 실수로 제거되었거나 rpm 패키지에 포함된 파일을 복원해야 하는 경우 시스템에 rhel 패키지 목록이 설치되어 있으면 유용할 수 있습니다.

    참고

    콘텐츠 뷰 또는 사실 저장소와 같은 Red Hat Satellite 기능을 사용하는 경우 누락된 패키지 및 시스템에 설치된 패키지의 히스토리 데이터를 다시 설치하는 적절한 메커니즘을 제공하십시오.

    시스템에 설치된 현재 rhel 패키지 목록을 작성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  5. 이전 단계를 사용한 경우 다음 파일이 백업 디렉터리에 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/master/ca.crt
    etc/origin/master/ca.key
    etc/origin/master/ca.serial.txt
    etc/origin/master/ca-bundle.crt
    etc/origin/master/master.proxy-client.crt
    etc/origin/master/master.proxy-client.key
    etc/origin/master/service-signer.crt
    etc/origin/master/service-signer.key
    etc/origin/master/serviceaccounts.private.key
    etc/origin/master/serviceaccounts.public.key
    etc/origin/master/openshift-master.crt
    etc/origin/master/openshift-master.key
    etc/origin/master/openshift-master.kubeconfig
    etc/origin/master/master.server.crt
    etc/origin/master/master.server.key
    etc/origin/master/master.kubelet-client.crt
    etc/origin/master/master.kubelet-client.key
    etc/origin/master/admin.crt
    etc/origin/master/admin.key
    etc/origin/master/admin.kubeconfig
    etc/origin/master/etcd.server.crt
    etc/origin/master/etcd.server.key
    etc/origin/master/master.etcd-client.key
    etc/origin/master/master.etcd-client.csr
    etc/origin/master/master.etcd-client.crt
    etc/origin/master/master.etcd-ca.crt
    etc/origin/master/policy.json
    etc/origin/master/scheduler.json
    etc/origin/master/htpasswd
    etc/origin/master/session-secrets.yaml
    etc/origin/master/openshift-router.crt
    etc/origin/master/openshift-router.key
    etc/origin/master/registry.crt
    etc/origin/master/registry.key
    etc/origin/master/master-config.yaml
    etc/origin/generated-configs/master-master-1.example.com/master.server.crt
    ...[OUTPUT OMITTED]...
    etc/origin/cloudprovider/openstack.conf
    etc/origin/node/system:node:master-0.example.com.crt
    etc/origin/node/system:node:master-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:master-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    필요한 경우 파일을 압축하여 공간을 절약할 수 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

이러한 파일을 처음부터 새로 생성하기 위해 openshift-ansible-contrib 리포지토리에는 이전 단계를 수행하는 backup_master_node.sh 스크립트가 포함되어 있습니다. 스크립트에서는 스크립트를 실행하는 호스트에 디렉터리를 생성하고 이전에 언급된 모든 파일을 복사합니다.

참고

Openshift-ansible-contrib 스크립트는 Red Hat에서 지원하지 않지만, 참조 아키텍처 팀에서는 코드가 정의된 대로 작동하고 안전하도록 테스트를 수행합니다.

다음을 사용하여 모든 마스터 호스트에서 스크립트를 실행할 수 있습니다.

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

5.2.3. 마스터 호스트 백업 복원

중요한 마스터 호스트 파일의 백업을 생성한 후, 파일이 손상되거나 잘못 제거된 경우 파일을 다시 마스터로 복사하고 파일에 올바른 콘텐츠가 포함되어 있는지 확인한 다음 영향을 받는 서비스를 다시 시작하여 파일을 복원할 수 있습니다.

프로시저
  1. /etc/origin/master/master-config.yaml 파일을 복원하십시오.

    # MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*
    # cp /etc/origin/master/master-config.yaml /etc/origin/master/master-config.yaml.old
    # cp /backup/$(hostname)/$(date +%Y%m%d)/origin/master/master-config.yaml /etc/origin/master/master-config.yaml
    # master-restart api
    # master-restart controllers
    주의

    마스터 서비스를 다시 시작하면 가동 중지 시간이 발생할 수 있습니다. 그러나 고가용성 로드 밸런서 풀에서 마스터 호스트를 제거한 다음, 복원 작업을 수행할 수 있습니다. 서비스가 올바르게 복원되면 마스터 호스트를 다시 로드 밸런서 풀에 추가할 수 있습니다.

    참고

    영향을 받는 인스턴스를 완전히 재부팅하여 iptables 구성을 복원하십시오.

  2. 패키지가 누락되었으므로 OpenShift Container Platform을 다시 시작할 수 없는 경우 패키지를 다시 설치하십시오.

    1. 현재 설치된 패키지 목록을 가져오십시오.

      $ rpm -qa | sort > /tmp/current_packages.txt
    2. 패키지 목록의 차이점을 확인하십시오.

      $ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt
      
      > ansible-2.4.0.0-5.el7.noarch
    3. 누락된 패키지를 다시 설치하십시오.

      # yum reinstall -y <packages> 1
      1
      <packages>를 패키지 목록 간에 서로 다른 패키지로 바꾸십시오.
  3. 인증서를 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사하여 시스템 인증서를 복원하고 update-ca-trust를 실행하십시오.

    $ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*
    $ sudo cp ${MYBACKUPDIR}/external_certificates/my_company.crt /etc/pki/ca-trust/source/anchors/
    $ sudo update-ca-trust
    참고

    SELinux 컨텍스트뿐만 아니라 파일을 다시 복사할 때 사용자 ID와 그룹 ID가 복원되는지 항상 확인하십시오.

5.3. 노드 호스트 작업

5.3.1. 노드 호스트 사용 중지

프로시저는 인프라 노드 또는 애플리케이션 노드를 사용 중지하더라도 동일합니다.

전제 조건

제거할 노드 세트에서 기존 포드를 마이그레이션할 수 있는 용량이 충분한지 확인하십시오. 인프라 노드를 제거한 후 두 개 이상의 노드가 온라인 상태를 유지하는 경우에만 인프라 노드를 제거하는 것이 좋습니다.

프로시저
  1. 사용 중지할 노드를 찾으려면 사용 가능한 모든 노드를 나열하십시오.

    $ oc get nodes
    NAME                  STATUS                     AGE       VERSION
    ocp-infra-node-b7pl   Ready                      23h       v1.6.1+5115d708d7
    ocp-infra-node-p5zj   Ready                      23h       v1.6.1+5115d708d7
    ocp-infra-node-rghb   Ready                      23h       v1.6.1+5115d708d7
    ocp-master-dgf8       Ready,SchedulingDisabled   23h       v1.6.1+5115d708d7
    ocp-master-q1v2       Ready,SchedulingDisabled   23h       v1.6.1+5115d708d7
    ocp-master-vq70       Ready,SchedulingDisabled   23h       v1.6.1+5115d708d7
    ocp-node-020m         Ready                      23h       v1.6.1+5115d708d7
    ocp-node-7t5p         Ready                      23h       v1.6.1+5115d708d7
    ocp-node-n0dd         Ready                      23h       v1.6.1+5115d708d7

    예를 들어,이 주제에서는 ocp-infra-node-b7pl 인프라 노드를 사용 중지합니다.

  2. 노드와 현재 실행 중인 서비스를 설명하십시오.

    $ oc describe node ocp-infra-node-b7pl
    Name:			ocp-infra-node-b7pl
    Role:
    Labels:			beta.kubernetes.io/arch=amd64
    			beta.kubernetes.io/instance-type=n1-standard-2
    			beta.kubernetes.io/os=linux
    			failure-domain.beta.kubernetes.io/region=europe-west3
    			failure-domain.beta.kubernetes.io/zone=europe-west3-c
    			kubernetes.io/hostname=ocp-infra-node-b7pl
    			role=infra
    Annotations:		volumes.kubernetes.io/controller-managed-attach-detach=true
    Taints:			<none>
    CreationTimestamp:	Wed, 22 Nov 2017 09:36:36 -0500
    Phase:
    Conditions:
      ...
    Addresses:		10.156.0.11,ocp-infra-node-b7pl
    Capacity:
     cpu:		2
     memory:	7494480Ki
     pods:		20
    Allocatable:
     cpu:		2
     memory:	7392080Ki
     pods:		20
    System Info:
     Machine ID:			bc95ccf67d047f2ae42c67862c202e44
     System UUID:			9762CC3D-E23C-AB13-B8C5-FA16F0BCCE4C
     Boot ID:			ca8bf088-905d-4ec0-beec-8f89f4527ce4
     Kernel Version:		3.10.0-693.5.2.el7.x86_64
     OS Image:			Employee SKU
     Operating System:		linux
     Architecture:			amd64
     Container Runtime Version:	docker://1.12.6
     Kubelet Version:		v1.6.1+5115d708d7
     Kube-Proxy Version:		v1.6.1+5115d708d7
    ExternalID:			437740049672994824
    Non-terminated Pods:		(2 in total)
      Namespace			Name				CPU Requests	CPU Limits	Memory Requests	Memory Limits
      ---------			----				------------	----------	---------------	-------------
      default			docker-registry-1-5szjs		100m (5%)	0 (0%)		256Mi (3%)0 (0%)
      default			router-1-vzlzq			100m (5%)	0 (0%)		256Mi (3%)0 (0%)
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      CPU Requests	CPU Limits	Memory Requests	Memory Limits
      ------------	----------	---------------	-------------
      200m (10%)	0 (0%)		512Mi (7%)	0 (0%)
    Events:		<none>

    위의 출력에서는 노드에서 router-1-vzlzqdocker-registry-1-5szjs의 두 포드가 실행 중임을 보여줍니다. 이 두 포드를 마이그레이션하기 위해 두 개의 추가 인프라 노드를 사용할 수 있습니다.

    참고

    위에서 설명한 클러스터는 고가용성 클러스터이므로 모든 인프라 노드에서 routerdocker-registry 서비스가 모두 실행되고 있습니다.

  3. 노드를 스케줄링할 수 없는 것으로 표시하고 모든 포드를 비웁니다.

    $ oc adm drain ocp-infra-node-b7pl --delete-local-data
    node "ocp-infra-node-b7pl" cordoned
    WARNING: Deleting pods with local storage: docker-registry-1-5szjs
    pod "docker-registry-1-5szjs" evicted
    pod "router-1-vzlzq" evicted
    node "ocp-infra-node-b7pl" drained

    포드가 로컬 스토리지(예: EmptyDir )를 연결한 경우 --delete-local-data 옵션을 제공해야 합니다. 일반적으로 프로덕션 환경에서 실행 중인 포드에서는 임시 또는 캐시 파일용으로만 로컬 스토리지를 사용해야 하며, 중요하거나 영구적인 파일용으로는 사용하지 않아야 합니다. 일반 스토리지의 경우 애플리케이션에서 오브젝트 스토리지 또는 영구 볼륨을 사용해야 합니다. 이 경우 컨테이너 이미지를 저장하는 데 오브젝트 스토리지가 사용되므로 docker-registry 포드의 로컬 스토리지는 비어 있습니다.

    참고

    위 작업을 수행하면 노드에서 실행 중인 기존 포드가 삭제됩니다. 그런 다음 복제 컨트롤러에 따라 새 포드를 생성합니다.

    일반적으로 모든 애플리케이션은 복제 컨트롤러를 사용하여 포드를 생성하는 배포 구성을 통해 배포해야 합니다.

    oc adm drain을 수행해도 베어 포드(미러 포드도 아니고 ReplicationController, ReplicaSet, DaemonSet, StatefulSet 또는 작업에서 관리하지도 않는 포드)가 삭제되지 않습니다. 삭제하려면 --force 옵션이 필요합니다. 베어 포드는 다른 노드에서 재생성되지 않으며 이 작업 중에 데이터가 손실될 수 있습니다.

    아래 예에서는 레지스트리의 복제 컨트롤러 출력을 보여줍니다.

    $ oc describe rc/docker-registry-1
    Name:		docker-registry-1
    Namespace:	default
    Selector:	deployment=docker-registry-1,deploymentconfig=docker-registry,docker-registry=default
    Labels:		docker-registry=default
    		openshift.io/deployment-config.name=docker-registry
    Annotations: ...
    Replicas:	3 current / 3 desired
    Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
    Pod Template:
      Labels:		deployment=docker-registry-1
    			deploymentconfig=docker-registry
    			docker-registry=default
      Annotations:		openshift.io/deployment-config.latest-version=1
    			openshift.io/deployment-config.name=docker-registry
    			openshift.io/deployment.name=docker-registry-1
      Service Account:	registry
      Containers:
       registry:
        Image:	openshift3/ose-docker-registry:v3.6.173.0.49
        Port:	5000/TCP
        Requests:
          cpu:	100m
          memory:	256Mi
        Liveness:	http-get https://:5000/healthz delay=10s timeout=5s period=10s #success=1 #failure=3
        Readiness:	http-get https://:5000/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
        Environment:
          REGISTRY_HTTP_ADDR:					:5000
          REGISTRY_HTTP_NET:					tcp
          REGISTRY_HTTP_SECRET:					tyGEnDZmc8dQfioP3WkNd5z+Xbdfy/JVXf/NLo3s/zE=
          REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA:	false
          REGISTRY_HTTP_TLS_KEY:					/etc/secrets/registry.key
          OPENSHIFT_DEFAULT_REGISTRY:				docker-registry.default.svc:5000
          REGISTRY_CONFIGURATION_PATH:				/etc/registry/config.yml
          REGISTRY_HTTP_TLS_CERTIFICATE:				/etc/secrets/registry.crt
        Mounts:
          /etc/registry from docker-config (rw)
          /etc/secrets from registry-certificates (rw)
          /registry from registry-storage (rw)
      Volumes:
       registry-storage:
        Type:	EmptyDir (a temporary directory that shares a pod's lifetime)
        Medium:
       registry-certificates:
        Type:	Secret (a volume populated by a Secret)
        SecretName:	registry-certificates
        Optional:	false
       docker-config:
        Type:	Secret (a volume populated by a Secret)
        SecretName:	registry-config
        Optional:	false
    Events:
      FirstSeen	LastSeen	Count	From			SubObjectPath	Type		Reason		Message
      ---------	--------	-----	----			-------------	--------	------		-------
      49m		49m		1	replication-controller			Normal		SuccessfulCreate	Created pod: docker-registry-1-dprp5

    출력 하단의 이벤트에는 새 포드 생성에 대한 정보가 표시됩니다. 따라서 모든 포드를 나열할 때 다음을 수행하십시오.

    $ oc get pods
    NAME                       READY     STATUS    RESTARTS   AGE
    docker-registry-1-dprp5    1/1       Running   0          52m
    docker-registry-1-kr8jq    1/1       Running   0          1d
    docker-registry-1-ncpl2    1/1       Running   0          1d
    registry-console-1-g4nqg   1/1       Running   0          1d
    router-1-2gshr             0/1       Pending   0          52m
    router-1-85qm4             1/1       Running   0          1d
    router-1-q5sr8             1/1       Running   0          1d
  4. 현재 사용 중지된 노드에서 실행 중인 docker-registry-1-5szjsrouter-1-vzlzq 포드는 더 이상 사용할 수 없습니다. 대신 docker-registry-1-dprp5router-1-2gshr의 두 가지 새 포드가 생성되었습니다. 위에 표시된 대로 새 라우터 포드는 router-1-2gshr이지만 보류 중 상태에 있습니다. 모든 노드가 하나의 단일 라우터에서만 실행될 수 있고 호스트의 포트 80 및 443에 바인딩되어 있기 때문입니다.
  5. 새로 생성된 레지스트리 포드를 살펴보면 아래 예에서는 포드가 ocp-infra-node-rghb 노드에서 작성되었으며, 이는 사용 중지된 노드와 다릅니다.

    $ oc describe pod docker-registry-1-dprp5
    Name:			docker-registry-1-dprp5
    Namespace:		default
    Security Policy:	hostnetwork
    Node:			ocp-infra-node-rghb/10.156.0.10
    ...

    인프라와 애플리케이션 노드를 사용 중지하는 것의 유일한 차이점은 인프라 노드를 비우고 해당 노드를 교체할 계획이 없는 경우 인프라 노드에서 실행 중인 서비스를 축소할 수 있다는 것입니다.

    $ oc scale dc/router --replicas 2
    deploymentconfig "router" scaled
    
    $ oc scale dc/docker-registry --replicas 2
    deploymentconfig "docker-registry" scaled
  6. 이제 모든 인프라 노드에서는 한 종류의 포드만 각각 실행합니다.

    $ oc get pods
    NAME                       READY     STATUS    RESTARTS   AGE
    docker-registry-1-kr8jq    1/1       Running   0          1d
    docker-registry-1-ncpl2    1/1       Running   0          1d
    registry-console-1-g4nqg   1/1       Running   0          1d
    router-1-85qm4             1/1       Running   0          1d
    router-1-q5sr8             1/1       Running   0          1d
    
    $ oc describe po/docker-registry-1-kr8jq | grep Node:
    Node:			ocp-infra-node-p5zj/10.156.0.9
    
    $ oc describe po/docker-registry-1-ncpl2 | grep Node:
    Node:			ocp-infra-node-rghb/10.156.0.10
    참고

    완전한 고가용성 클러스터를 제공하려면 항상 3개 이상의 인프라 노드를 사용할 수 있어야 합니다.

  7. 노드의 스케줄링이 비활성화되었는지 확인하려면 다음을 수행하십시오.

    $ oc get nodes
    NAME                  STATUS                     AGE       VERSION
    ocp-infra-node-b7pl   Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-infra-node-p5zj   Ready                      1d        v1.6.1+5115d708d7
    ocp-infra-node-rghb   Ready                      1d        v1.6.1+5115d708d7
    ocp-master-dgf8       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-master-q1v2       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-master-vq70       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-node-020m         Ready                      1d        v1.6.1+5115d708d7
    ocp-node-7t5p         Ready                      1d        v1.6.1+5115d708d7
    ocp-node-n0dd         Ready                      1d        v1.6.1+5115d708d7

    또한 노드에 포드가 포함되어 있지 않습니다.

    $ oc describe node ocp-infra-node-b7pl
    Name:			ocp-infra-node-b7pl
    Role:
    Labels:			beta.kubernetes.io/arch=amd64
    			beta.kubernetes.io/instance-type=n1-standard-2
    			beta.kubernetes.io/os=linux
    			failure-domain.beta.kubernetes.io/region=europe-west3
    			failure-domain.beta.kubernetes.io/zone=europe-west3-c
    			kubernetes.io/hostname=ocp-infra-node-b7pl
    			role=infra
    Annotations:		volumes.kubernetes.io/controller-managed-attach-detach=true
    Taints:			<none>
    CreationTimestamp:	Wed, 22 Nov 2017 09:36:36 -0500
    Phase:
    Conditions:
      ...
    Addresses:		10.156.0.11,ocp-infra-node-b7pl
    Capacity:
     cpu:		2
     memory:	7494480Ki
     pods:		20
    Allocatable:
     cpu:		2
     memory:	7392080Ki
     pods:		20
    System Info:
     Machine ID:			bc95ccf67d047f2ae42c67862c202e44
     System UUID:			9762CC3D-E23C-AB13-B8C5-FA16F0BCCE4C
     Boot ID:			ca8bf088-905d-4ec0-beec-8f89f4527ce4
     Kernel Version:		3.10.0-693.5.2.el7.x86_64
     OS Image:			Employee SKU
     Operating System:		linux
     Architecture:			amd64
     Container Runtime Version:	docker://1.12.6
     Kubelet Version:		v1.6.1+5115d708d7
     Kube-Proxy Version:		v1.6.1+5115d708d7
    ExternalID:			437740049672994824
    Non-terminated Pods:		(0 in total)
      Namespace			Name		CPU Requests	CPU Limits	Memory Requests	Memory Limits
      ---------			----		------------	----------	---------------	-------------
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      CPU Requests	CPU Limits	Memory Requests	Memory Limits
      ------------	----------	---------------	-------------
      0 (0%)	0 (0%)		0 (0%)		0 (0%)
    Events:		<none>
  8. /etc/haproxy/haproxy.cfg 구성 파일의 backend 섹션에서 인프라 인스턴스를 제거하십시오.

    backend router80
        balance source
        mode tcp
        server infra-1.example.com 192.168.55.12:80 check
        server infra-2.example.com 192.168.55.13:80 check
    
    backend router443
        balance source
        mode tcp
        server infra-1.example.com 192.168.55.12:443 check
        server infra-2.example.com 192.168.55.13:443 check
  9. 그런 다음 haproxy 서비스를 다시 시작하십시오.

    $ sudo systemctl restart haproxy
  10. 다음 명령을 사용하여 모든 포드를 비운 후 클러스터에서 노드를 제거하십시오.

    $ oc delete node ocp-infra-node-b7pl
    node "ocp-infra-node-b7pl" deleted
    $ oc get nodes
    NAME                  STATUS                     AGE       VERSION
    ocp-infra-node-p5zj   Ready                      1d        v1.6.1+5115d708d7
    ocp-infra-node-rghb   Ready                      1d        v1.6.1+5115d708d7
    ocp-master-dgf8       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-master-q1v2       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-master-vq70       Ready,SchedulingDisabled   1d        v1.6.1+5115d708d7
    ocp-node-020m         Ready                      1d        v1.6.1+5115d708d7
    ocp-node-7t5p         Ready                      1d        v1.6.1+5115d708d7
    ocp-node-n0dd         Ready                      1d        v1.6.1+5115d708d7
참고

포드 또는 노드 비우기 및 유출에 대한 자세한 내용은 노드 유지보수 섹션을 참조하십시오.

5.3.1.1. 노드 호스트 교체

사용 중지된 노드 대신 노드를 추가해야 하는 경우 기존 클러스터에 호스트 추가를 따르십시오.

5.3.2. 노드 호스트 백업 생성

노드 호스트의 백업 생성은 마스터 호스트 백업과 다른 사용 사례입니다. 마스터 호스트에는 많은 중요한 파일이 포함되어 있으므로 백업을 만드는 것이 좋습니다. 그러나 노드의 특성은 장애 조치(failover)의 경우 노드에 특별한 항목이 복제되며. 일반적으로 환경을 실행하는 데 필요한 데이터는 포함하지 않는다는 것입니다. 노드 백업에 환경을 실행하는 데 필요한 것이 있으면 백업을 생성하는 것이 좋습니다.

백업 프로세스는 시스템 업데이트, 업그레이드 또는 기타 중요한 수정과 같이 인프라를 변경하기 전에 수행해야 합니다. 장애가 발생할 경우 최신 데이터를 사용할 수 있도록 정기적으로 백업을 수행해야 합니다.

OpenShift Container Platform 파일

노드 인스턴스는 컨테이너를 기반으로 하는 포드 양식으로 애플리케이션을 실행합니다. /etc/origin//etc/origin/node 디렉터리에 다음과 같은 중요한 파일이 있습니다.

  • 노드 서비스의 구성
  • 설치를 통해 생성된 인증서
  • 클라우드 공급자 관련 구성
  • dnsmasq 구성과 같은 키 및 기타 인증 파일

OpenShift Container Platform 서비스는 로그 레벨을 높이고 프록시를 사용하도록 사용자 정의할 수 있으며 구성 파일은 /etc/sysconfig 디렉터리에 저장됩니다.

프로시저
  1. 노드 구성 파일의 백업을 생성하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/atomic-openshift-node ${MYBACKUPDIR}/etc/sysconfig/
  2. OpenShift Container Platform에서는 다음을 포함하여 백업 정책을 계획할 때 고려해야 하는 특정 파일을 사용합니다.

    파일

    설명

    /etc/cni/*

    컨테이너 네트워크 인터페이스 구성(사용된 경우)

    /etc/sysconfig/iptables

    iptables 규칙이 저장된 위치

    /etc/sysconfig/docker-storage-setup

    container-storage-setup 명령의 입력 파일

    /etc/sysconfig/docker

    docker 구성 파일

    /etc/sysconfig/docker-network

    docker 네트워킹 구성(예: MTU)

    /etc/sysconfig/docker-storage

    docker 스토리지 구성(container-storage-setup을 통해 생성)

    /etc/dnsmasq.conf

    dnsmasq의 기본 구성 파일

    /etc/dnsmasq.d/*

    다른 dnsmasq 구성 파일

    /etc/sysconfig/flanneld

    flannel 구성 파일(사용된 경우)

    /etc/pki/ca-trust/source/anchors/

    시스템에 추가된 인증서(예 : 외부 레지스트리용)

    해당 파일을 생성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  3. 패키지가 실수로 제거되거나 rpm 패키지에 포함된 파일을 복원해야 하는 경우 시스템에 rhel 패키지 목록이 설치되어 있으면 유용할 수 있습니다.

    참고

    콘텐츠 뷰 또는 사실 저장소와 같은 Red Hat Satellite 기능을 사용하는 경우 누락된 패키지 및 시스템에 설치된 패키지의 히스토리 데이터를 다시 설치하는 적절한 메커니즘을 제공하십시오.

    시스템에 설치된 현재 rhel 패키지 목록을 작성하려면 다음을 수행하십시오.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  4. 이제 다음 파일이 백업 디렉터리에 있어야 합니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/atomic-openshift-node
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/node/system:node:app-node-0.example.com.crt
    etc/origin/node/system:node:app-node-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:app-node-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/origin/cloudprovider/openstack.conf
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    필요한 경우 파일을 압축하여 공간을 절약할 수 있습니다.

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

이러한 파일을 처음부터 새로 생성하기 위해 openshift-ansible-contrib 리포지토리에는 이전 단계를 수행하는 backup_master_node.sh 스크립트가 포함되어 있습니다. 스크립트에서는 스크립트를 실행하는 호스트에 디렉터리를 생성하고 이전에 언급된 모든 파일을 복사합니다.

참고

Openshift-ansible-contrib 스크립트는 Red Hat에서 지원하지 않지만, 참조 아키텍처 팀에서는 코드가 정의된 대로 작동하고 안전하도록 테스트를 수행합니다.

스크립트는 다음을 사용하여 모든 마스터 호스트에서 실행될 수 있습니다.

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

5.3.3. 노드 호스트 백업 복원

중요한 노드 호스트 파일의 백업을 생성한 후, 파일이 손상되거나 잘못 제거된 경우 파일을 다시 복사하고 파일에 올바른 콘텐츠가 포함되어 있는지 확인한 다음 영향을 받는 서비스를 다시 시작하여 파일을 복원할 수 있습니다.

프로시저
  1. /etc/origin/node/node-config.yaml 파일을 복원하십시오.

    # MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    # cp /etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml.old
    # cp /backup/$(hostname)/$(date +%Y%m%d)/etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml
    # reboot
주의

서비스를 다시 시작하면 가동 중지 시간이 발생할 수 있습니다. 프로세스를 용이하게 하는 방법에 관한 팁은 노드 유지보수를 참조하십시오.

참고

영향을 받는 인스턴스를 완전히 재부팅하여 iptables 구성을 복원하십시오.

  1. 패키지가 누락되었으므로 OpenShift Container Platform을 다시 시작할 수 없는 경우 패키지를 다시 설치하십시오.

    1. 현재 설치된 패키지 목록을 가져오십시오.

      $ rpm -qa | sort > /tmp/current_packages.txt
    2. 패키지 목록의 차이점을 확인하십시오.

      $ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt
      
      > ansible-2.4.0.0-5.el7.noarch
    3. 누락된 패키지를 다시 설치하십시오.

      # yum reinstall -y <packages> 1
      1
      <packages>를 패키지 목록 간에 서로 다른 패키지로 바꾸십시오.
  2. 인증서를 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사하여 시스템 인증서를 복원하고 update-ca-trust를 실행하십시오.

    $ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*
    $ sudo cp ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/my_company.crt /etc/pki/ca-trust/source/anchors/
    $ sudo update-ca-trust
    참고

    SELinux 컨텍스트뿐만 아니라 파일을 다시 복사할 때 적절한 사용자 ID와 그룹 ID가 복원되는지 항상 확인하십시오.

5.3.4. 노드 유지보수 및 다음 단계

다양한 노드 관리 옵션은 노드 관리 또는 포드 관리 주제를 참조하십시오. 여기에는 다음이 포함됩니다.

노드에서 특정 구성 요소가 사용하도록 리소스의 일부를 예약할 수 있습니다. 여기에는 kubelet, kube-proxy, Docker 또는 sshdNetworkManager와 같은 나머지 시스템 구성 요소가 포함됩니다. 자세한 내용은 클러스터 관리자 안내서의 노드 리소스 할당 섹션을 참조하십시오.

5.4. etcd 작업

5.4.1. etcd 백업

etcd는 영구 마스터 상태 외에도 모든 오브젝트 정의의 키 값 저장소입니다. 다른 구성 요소에서 변경을 기다린 다음 원하는 상태로 이동합니다.

3.5 이전의 OpenShift Container Platform 버전에서는 etcd 버전 2(v2)를 사용하고 3.5 이상에서는 버전 3(v3)을 사용합니다. etcd의 두 버전 간 데이터 모델은 서로 다릅니다. etcd v3에서는 v2 및 v3 데이터 모델을 모두 사용할 수 있는 반면 etcd v2에서는 v2 데이터 모델만 사용할 수 있습니다. etcd v3 서버에서 v2 및 v3 데이터 저장소는 병렬로 존재하며 독립적입니다.

v2 및 v3 작업 모두에서 ETCDCTL_API 환경 변수를 사용하여 올바른 API를 사용할 수 있습니다.

$ etcdctl -v
etcdctl version: 3.2.5
API version: 2
$ ETCDCTL_API=3 etcdctl version
etcdctl version: 3.2.5
API version: 3.2

v3으로 마이그레이션하는 방법에 대한 정보는 OpenShift Container Platform 3.7 설명서의 etcd 데이터 마이그레이션(v2에서 v3으로) 섹션을 참조하십시오.

OpenShift Container Platform 버전 3.10 이상에서는 별도의 호스트에 etcd를 설치하거나 마스터 호스트에서 정적 포드로 실행할 수 있습니다. 별도의 etcd 호스트를 지정하지 않으면 etcd는 마스터 호스트에서 정적 포드로 실행됩니다. 이와 같은 차이 때문에 정적 포드를 사용하면 백업 프로세스가 달라집니다.

etcd 백업 프로세스는 두 가지 서로 다른 프로시저로 구성됩니다.

  • 구성 백업: 필수 etcd 구성 및 인증서를 포함합니다.
  • 데이터 백업: v2 및 v3 데이터 모델을 포함합니다.

etcd 클러스터에 연결되어 있고 적절한 인증서가 제공되며 etcdctl 도구가 설치된 모든 호스트에서 데이터 백업 프로세스를 수행할 수 있습니다.

참고

백업 파일은 외부 시스템, 이상적으로는 OpenShift Container Platform 환경 외부에 복사한 다음 암호화해야 합니다.

etcd 백업에는 여전히 현재 스토리지 볼륨에 대한 모든 참조가 있습니다. etcd를 복원하면 OpenShift Container Platform이 노드에서 이전 포드를 시작하고 동일한 스토리지를 다시 연결하기 시작합니다. 이 프로세스는 클러스터에서 노드를 제거하고 그 자리에 새 노드를 다시 추가하는 프로세스와 다르지 않습니다. 해당 노드에 연결된 모든 항목은 다시 스케줄링된 모든 노드의 포드에 다시 연결됩니다.

5.4.1.1. etcd 백업

etcd를 백업할 때 etcd 구성 파일과 etcd 데이터를 둘 다 백업해야 합니다.

5.4.1.1.1. etcd 구성 파일 백업

보존할 etcd 구성 파일은 모두 etcd가 실행 중인 인스턴스의 /etc/etcd 디렉터리에 저장됩니다. 여기에는 etcd 구성 파일(/etc/etcd/etcd.conf)과 클러스터 통신에 필요한 인증서가 포함됩니다. 이러한 모든 파일은 Ansible 설치 프로그램에서 설치 시 생성됩니다.

프로시저

클러스터의 etcd 멤버마다 etcd 구성을 백업하십시오.

$ ssh master-0
# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
참고

각 etcd 클러스터 멤버의 인증서 및 구성 파일은 고유합니다.

5.4.1.1.2. etcd 데이터 백업
전제 조건
참고

OpenShift Container Platform 설치 프로그램에서는 etcd v2 작업의 etcdctl2 및 etcd v3 작업의 etcdctl3이라는 모든 플래그를 입력하지 않도록 별칭을 생성합니다.

그러나 etcdctl3 별명에서는 etcdctl 명령에 전체 끝점 목록을 제공하지 않으므로, --endpoints 옵션을 지정하고 모든 끝점을 나열해야 합니다.

etcd를 백업하기 전에 다음을 수행하십시오.

  • etcdctl 바이너리가 사용 가능해야 하거나 컨테이너화 된 설치에서 rhel7/etcd 컨테이너가 사용 가능해야 합니다.
  • OpenShift Container Platform API 서비스가 실행 중인지 확인하십시오.
  • etcd 클러스터(2379/tcp 포트)와의 연결을 확인하십시오.
  • etcd 클러스터에 연결하기 위한 적절한 인증서를 확인하십시오.
  • go가 설치되어 있는지 확인하십시오.
프로시저
참고

etcdctl backup 명령은 백업을 수행하는 데 사용되는 반면 etcd v3에는 백업의 개념이 없습니다. 대신 etcdctl snapshot save 명령을 사용하여 활성 멤버에서 스냅샷을 작성하거나 etcd 데이터 디렉터리에서 member/snap/db 파일을 복사합니다.

etcdctl backup 명령을 실행하면 백업에 포함된 일부 메타데이터, 특히 노드 ID 및 클러스터 ID를 다시 작성합니다. 즉, 백업에서 노드의 이전 ID가 손실됩니다. 백업에서 클러스터를 다시 생성하려면 새로운 단일 노드 클러스터를 생성한 후 나머지 노드를 클러스터에 추가하십시오. 새 노드가 기존 클러스터에 참여하지 못하도록 메타데이터가 다시 작성됩니다.

etcd 데이터를 백업하십시오.

중요

이전 버전의 OpenShift Container Platform에서 업그레이드된 클러스터에는 v2 데이터 저장소가 포함될 수 있습니다. 모든 etcd 데이터 저장소를 백업하십시오.

  1. etcd 노드의 스냅샷을 작성하십시오.

    # systemctl show etcd --property=ActiveState,SubState
    # mkdir -p /var/lib/etcd/backup/etcd-$(date +%Y%m%d) 1
    # etcdctl3 snapshot save /var/lib/etcd/backup/etcd-$(date +%Y%m%d)/db
    1
    /var/lib/etcd/의 디렉터리에 스냅샷을 써야 합니다.
    참고

    etcdctl snapshot save 명령을 실행하려면 etcd 서비스가 실행 중이어야 합니다.

  2. etcd 포드 정의를 제거하고 호스트를 재부팅하여 모든 etcd 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  3. etcd 데이터 백업을 생성하고 etcd db 파일을 복사하십시오.

    # etcdctl2 backup \
        --data-dir /var/lib/etcd \
        --backup-dir /backup/etcd-$(date +%Y%m%d)

    /backup/etcd-<date>/ 디렉터리가 생성됩니다. 여기서 <date>는 현재 날짜를 나타내며, 외부 NFS 공유, S3 버킷 또는 외부 스토리지 위치여야 합니다.

    일체형 클러스터의 경우 etcd 데이터 디렉터리는 /var/lib/origin/openshift.local.etcd 디렉터리에 있습니다.

    • etcd가 정적 포드로 실행되는 경우 다음 명령을 실행하십시오.

      중요

      정적 포드를 사용하는 경우 v3 API를 사용하십시오.

  4. 정적 포드 매니페스트에서 etcd 끝점 IP 주소를 얻습니다.

    $ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
    $ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
  5. etcd 포드 이름을 확보하십시오.

    $ oc login -u system:admin
    $ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '\S*etcd\S*')
  6. 포드에서 etcd 데이터의 스냅샷을 작성하여 로컬에 저장하십시오.

    $ oc project kube-system
    $ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \
        --cert /etc/etcd/peer.crt \
        --key /etc/etcd/peer.key \
        --cacert /etc/etcd/ca.crt \
        --endpoints $ETCD_EP \
        snapshot save /var/lib/etcd/snapshot.db"

5.4.2. etcd 복구

etcd 구성 파일의 복원 프로시저에서는 해당 파일을 대체한 다음 서비스 또는 정적 포드를 다시 시작합니다.

etcd 호스트가 손상되고 /etc/etcd/etcd.conf 파일이 손실되면 다음을 사용하여 복원하십시오.

$ ssh master-0
# cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf
# restorecon -RvF /etc/etcd/etcd.conf

이 예에서 백업 파일은 /backup/yesterday/master-0-files/etcd.conf 경로에 저장되며, 외부 NFS 공유, S3 버킷 또는 기타 스토리지 솔루션으로 사용할 수 있습니다.

참고

정적 포드로 etcd를 실행하면 해당 섹션의 단계만 수행하십시오. 마스터 또는 독립형 노드에서 별도의 서비스로 etcd를 실행하는 경우 필요한 대로 단계를 수행하여 데이터를 복원하십시오.

5.4.2.1. etcd 데이터 복원

다음 프로세스를 수행하면 정상적인 데이터 파일을 복원하고 etcd 클러스터를 단일 노드로 시작한 다음 etcd 클러스터가 필요한 경우 나머지 노드를 추가합니다.

프로시저
  1. etcd 포드 정의를 제거하고 호스트를 재부팅하여 모든 etcd 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    # reboot
  2. 적절한 백업이 복원되게 하려면 etcd 디렉터리를 삭제하십시오.

    • 디렉터리를 삭제하기 전에 현재 etcd 데이터를 백업하려면 다음 명령을 실행하십시오.

      # mv /var/lib/etcd /var/lib/etcd.old
      # mkdir /var/lib/etcd
      # restorecon -RvF /var/lib/etcd/
    • 또는 디렉터리 및 etcd 데이터를 삭제하려면 다음 명령을 실행하십시오.

      # rm -Rf /var/lib/etcd/*
      참고

      일체형 클러스터에서 etcd 데이터 디렉터리는 /var/lib/origin/openshift.local.etcd 디렉터리에 있습니다.

  3. 정상적인 백업 데이터 파일을 각 etcd 노드에 복원하십시오. etcd와 함께 배치된 마스터 호스트를 포함하여 모든 etcd 호스트에서 이 단계를 수행하십시오.

    # cp -R /backup/etcd-xxx/* /var/lib/etcd/
    # mv /var/lib/etcd/db /var/lib/etcd/member/snap/db
    # chcon -R --reference /backup/etcd-xxx/* /var/lib/etcd/
  4. etcd 호스트 중 하나에서 etcd 서비스를 실행하여 새 클러스터를 강제 실행하십시오.

    그러면 etcd 서비스의 사용자 정의 파일이 생성되며, --force-new-cluster 옵션을 추가하여 실행 명령을 덮어씁니다.

    # mkdir -p /etc/systemd/system/etcd.service.d/
    # echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf
    # echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf
    # sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \
        /usr/lib/systemd/system/etcd.service \
        >> /etc/systemd/system/etcd.service.d/temp.conf
    
    # systemctl daemon-reload
    # master-restart etcd
  5. 오류 메시지를 확인하십시오.

    # master-logs etcd etcd
  6. 상태를 점검하십시오.

    # etcdctl3 cluster-health
    member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379
    cluster is healthy
  7. 클러스터 모드에서 etcd 서비스를 다시 시작하십시오.

    # rm -f /etc/systemd/system/etcd.service.d/temp.conf
    # systemctl daemon-reload
    # master-restart etcd
  8. 상태 및 멤버 목록을 확인하십시오.

    # etcdctl3 cluster-health
    member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379
    cluster is healthy
    
    # etcdctl3 member list
    5ee217d17301: name=master-0.example.com peerURLs=http://localhost:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
  9. 첫 번째 인스턴스가 실행된 후 나머지 피어를 다시 클러스터에 추가할 수 있습니다.
5.4.2.1.1. peerURLS 매개 변수 수정

데이터를 복원하고 새 클러스터를 생성하고 나면 peerURLs 매개 변수에서 etcd가 피어 통신을 청취하는 IP 대신 localhost를 표시합니다.

# etcdctl3 member list
5ee217d17301: name=master-0.example.com peerURLs=http://*localhost*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
5.4.2.1.1.1. 프로시저
  1. etcdctl member list를 사용하여 멤머 ID를 가져오십시오.

    `etcdctl member list`
  2. etcd가 피어 통신을 청취하는 IP를 가져옵니다.

    $ ss -l4n | grep 2380
  3. 해당 IP로 멤버 정보를 업데이트하십시오.

    # etcdctl3 member update 5ee217d17301 https://192.168.55.8:2380
    Updated member with ID 5ee217d17301 in cluster
  4. 검증하려면 IP가 멤버 목록에 있는지 확인하십시오.

    $ etcdctl3 member list
    5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true

5.4.2.2. etcd 스냅샷 복원

복원 시 스냅샷 무결성을 선택적으로 확인할 수 있습니다. etcdctl snapshot save로 스냅샷을 작성한 경우 etcdctl snapshot restore에서 확인한 무결성 해시가 있습니다. 데이터 디렉터리에서 스냅샷을 복사하면 무결성 해시가 없고 --skip-hash-check를 사용해야만 복원됩니다.

중요

데이터 복원 프로시저는 단일 etcd 호스트에서 수행해야 합니다. 그런 다음 나머지 노드를 클러스터에 추가할 수 있습니다.

프로시저
  1. etcd 포드 정의를 제거하고 호스트를 재부팅하여 모든 etcd 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    # reboot
  2. etcdctl에서 복원 프로시저를 수행할 노드에 데이터를 다시 생성하므로 이전 데이터를 모두 지우십시오.

    # rm -Rf /var/lib/etcd
  3. /etc/etcd/etcd.conf 파일의 값을 대체하여 snapshot restore 명령을 실행하십시오.

    # etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \
      --data-dir /var/lib/etcd \
      --name master-0.example.com \
      --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \
      --initial-cluster-token "etcd-cluster-1" \
      --initial-advertise-peer-urls https://192.168.55.8:2380 \
      --skip-hash-check=true
    
    2017-10-03 08:55:32.440779 I | mvcc: restore compact to 1041269
    2017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c
  4. 복원된 파일에 권한 및 selinux 컨텍스트를 복원하십시오.

    # restorecon -RvF /var/lib/etcd
  5. etcd 서비스를 시작하십시오.

    # systemctl start etcd
  6. 오류 메시지가 있는지 확인하십시오.

    # master-logs etcd etcd

5.4.2.3. 정적 포드에서 etcd 복원

정적 포드에서 etcd를 복원하기 전에 다음을 수행하십시오.

  • etcdctl 바이너리가 사용 가능해야 하거나 컨테이너화 된 설치에서 rhel7/etcd 컨테이너가 사용 가능해야 합니다.

    다음 명령을 실행하여 etcd 패키지로 etcdctl 바이너리를 설치할 수 있습니다.

    # yum install etcd

    이 패키지에서는 systemd 서비스도 설치합니다. etcd가 정적 포드에서 실행될 때 systemd 서비스로 실행되지 않도록 서비스를 비활성화하고 마스킹하십시오. 서비스를 비활성화하고 마스킹하면 실수로 서비스가 시작되지 않고 시스템을 재부팅할 때 서비스가 자동으로 다시 시작되지 않게 할 수 있습니다.

    # systemctl disable etcd.service
    # systemctl mask etcd.service

정적 포드에서 etcd를 복원하려면 다음을 수행하십시오.

  1. 포드가 실행 중이면 포드 매니페스트 YAML 파일을 다른 디렉터리로 이동하여 etcd 포드를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/etcd.yaml /etc/origin/node/pods-stopped
  2. 이전 데이터를 모두 지우십시오.

    # rm -rf /var/lib/etcd

    포드를 복원하는 노드에서 etcdctl을 사용하여 데이터를 다시 생성합니다.

  3. etcd 스냅샷을 etcd 포드의 마운트 경로로 복원하십시오.

    # export ETCDCTL_API=3
    # etcdctl snapshot restore /etc/etcd/backup/etcd/snapshot.db
    	 --data-dir /var/lib/etcd/
    	 --name ip-172-18-3-48.ec2.internal
    	 --initial-cluster "ip-172-18-3-48.ec2.internal=https://172.18.3.48:2380"
    	 --initial-cluster-token "etcd-cluster-1"
    	 --initial-advertise-peer-urls https://172.18.3.48:2380
    	 --skip-hash-check=true

    $/ backup_files/etcd.conf 파일에서 클러스터의 값을 얻으십시오.

  4. 데이터 디렉터리에서 필요한 권한 및 selinux 컨텍스트를 설정하십시오.

    # restorecon -RvF /var/lib/etcd/
  5. 포드 매니페스트 YAML 파일을 필요한 디렉토리로 이동하여 etcd 포드를 다시 시작하십시오.

    # mv /etc/origin/node/pods-stopped/etcd.yaml /etc/origin/node/pods/

5.4.3. etcd 호스트 교체

etcd 호스트를 교체하려면 etcd 클러스터를 확장한 다음 호스트를 제거하십시오. 이 프로세스를 수행하면 교체 프로시저 중에 etcd 호스트가 손실된 경우 쿼럼을 유지할 수 있습니다.

주의

etcd 클러스터는 교체 작업 중에 쿼럼을 유지해야 합니다. 즉, 항상 하나 이상의 호스트가 작동해야 합니다.

etcd 클러스터에서 쿼럼을 유지보수하는 동안 호스트 교체 작업이 발생해도 일반적으로 클러스터 작업은 영향을 받지 않습니다. 많은 양의 etcd 데이터를 복제해야 하는 경우 일부 작업이 느려질 수 있습니다.

참고

etcd 클러스터와 관련된 프로시저를 시작하기 전에 프로시저에 실패한 경우 클러스터를 복원할 수 있도록 etcd 데이터 및 구성 파일의 백업이 있어야 합니다.

5.4.4. etcd 확장

etcd 호스트에 리소스를 추가하여 etcd 클러스터를 수직으로 확장하거나 etcd 호스트를 더 추가하여 수평으로 확장할 수 있습니다.

참고

투표 시스템 etcd 용도 때문에 클러스터에는 항상 홀수의 멤버가 있어야 합니다.

홀수의 etcd 호스트를 포함하는 클러스터가 있으면 내결함성이 있는 것입니다. 홀수의 etcd 호스트가 있으면 쿼럼에 필요한 수는 변경되지 않지만 내결함성이 증가합니다. 예를 들어, 멤버가 3개인 클러스터의 경우 쿼럼은 2이므로 내결함성은 1입니다. 따라서 두 멤버가 정상이면 클러스터가 계속 작동합니다.

3개의 etcd 호스트가 있는 프로덕션 내 클러스터를 사용하는 것이 좋습니다.

새로운 호스트에는 새로운 Red Hat Enterprise Linux 버전 7 전용 호스트가 필요합니다. etcd 스토리지가 최대 성능을 달성하려면 SSD 디스크와 /var/lib/etcd에 마운트된 전용 디스크에 있어야 합니다.

전제 조건
  1. 새 etcd 호스트를 추가하기 전에 etcd 구성 및 데이터를 모두 백업하여 데이터 손실을 방지하십시오.
  2. 비정상 클러스터에 새 호스트를 추가하지 않도록 현재 etcd 클러스터 상태를 확인하십시오. 다음 명령을 실행하십시오.

    # ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \
              --key=/etc/etcd/peer.key \
              --cacert="/etc/etcd/ca.crt" \
              --endpoints="https://*master-0.example.com*:2379,\
                https://*master-1.example.com*:2379,\
                https://*master-2.example.com*:2379"
                endpoint health
    https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
    https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
    https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
  3. scaleup 플레이북을 실행하기 전에 새 호스트가 적절한 Red Hat 소프트웨어 채널에 등록되어 있는지 확인하십시오.

    # subscription-manager register \
        --username=*<username>* --password=*<password>*
    # subscription-manager attach --pool=*<poolid>*
    # subscription-manager repos --disable="*"
    # subscription-manager repos \
        --enable=rhel-7-server-rpms \
        --enable=rhel-7-server-extras-rpms

    etcd는 rhel-7-server-extras-rpms 소프트웨어 채널에서 호스팅됩니다.

  4. 사용되지 않은 모든 etcd 멤버가 etcd 클러스터에서 제거되었는지 확인하십시오. scaleup 플레이북을 실행하기 전에 완료해야 합니다.

    1. etcd 멤버를 나열하십시오.

      # etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \
        --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URLS member list -w table

      해당되는 경우 사용되지 않은 etcd 멤버 ID를 복사하십시오.

    2. 다음 명령에서 ID를 지정하여 사용되지 않은 멤버를 제거하십시오.

      # etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \
        --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URL member remove UNUSED_ETCD_MEMBER_ID
  5. 현재 etcd 노드에서 etcd 및 iptables를 업그레이드하십시오.

    # yum update etcd iptables-services
  6. etcd 호스트의 /etc/etcd 구성을 백업하십시오.
  7. 새 etcd 멤버도 OpenShift Container Platform 노드 이면 원하는 수의 호스트를 클러스터에 추가하십시오.
  8. 이 프로시저의 나머지 부분에서는 하나의 호스트를 추가했다고 가정하지만, 여러 호스트를 추가하는 경우 각 호스트에서 모든 단계를 수행하십시오.

5.4.4.1. Ansible을 사용하여 새 etcd 호스트 추가

프로시저
  1. Ansible 인벤토리 파일에서 [new_etcd]라는 새 그룹을 생성하고 새 호스트를 추가하십시오. 그런 다음 new_etcd 그룹을 [OSEv3] 그룹의 하위 그룹으로 추가하십시오.

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd 1
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
    master-2.example.com
    
    [new_etcd] 2
    etcd0.example.com 3
    1 2 3
    다음 라인을 추가하십시오.
  2. OpenShift Container Platform을 설치했으며 Ansible 인벤토리 파일을 호스팅하는 호스트에서 플레이북 디렉터리로 변경하고 etcd scaleup 플레이북을 실행하십시오.

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook  playbooks/openshift-etcd/scaleup.yml
  3. 플레이북을 실행한 다음 새 etcd 호스트를 [new_etcd] 그룹에서 [etcd] 그룹으로 이동하여 현재 상태를 반영하도록 인벤토리 파일을 수정하십시오.

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
    master-2.example.com
    etcd0.example.com
  4. Flannel을 사용하는 경우 새 etcd 호스트를 포함하도록 /etc/sysconfig/flanneld에 있는 모든 OpenShift Container Platform 호스트에서 flanneld 서비스 구성을 수정하십시오.

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
  5. flanneld 서비스를 다시 시작하십시오.

    # systemctl restart flanneld.service

5.4.4.2. 새 etcd 호스트 수동 추가

마스터 노드에서 etcd를 정적 포드로 실행하지 않으면 다른 etcd 호스트를 추가해야 할 수도 있습니다.

프로시저
현재 etcd 클러스터 수정

etcd 인증서를 생성하려면 openssl 명령을 실행하여 값을 사용자 환경의 값으로 바꾸십시오.

  1. 다음과 같이 일부 환경 변수를 생성하십시오.

    export NEW_ETCD_HOSTNAME="*etcd0.example.com*"
    export NEW_ETCD_IP="192.168.55.21"
    
    export CN=$NEW_ETCD_HOSTNAME
    export SAN="IP:${NEW_ETCD_IP}, DNS:${NEW_ETCD_HOSTNAME}"
    export PREFIX="/etc/etcd/generated_certs/etcd-$CN/"
    export OPENSSLCFG="/etc/etcd/ca/openssl.cnf"
    참고

    etcd_v3_ca_* 로 사용되는 사용자 정의 openssl 확장에는 $SAN 환경 변수가 subjectAltName으로 포함됩니다. 자세한 내용은 /etc/etcd/ca/openssl.cnf를 참조하십시오.

  2. 구성 및 인증서를 저장할 디렉터리를 생성하십시오.

    # mkdir -p ${PREFIX}
  3. 서버 인증서 요청을 생성하고 서명하십시오(server.csrserver.crt).

    # openssl req -new -config ${OPENSSLCFG} \
        -keyout ${PREFIX}server.key  \
        -out ${PREFIX}server.csr \
        -reqexts etcd_v3_req -batch -nodes \
        -subj /CN=$CN
    
    # openssl ca -name etcd_ca -config ${OPENSSLCFG} \
        -out ${PREFIX}server.crt \
        -in ${PREFIX}server.csr \
        -extensions etcd_v3_ca_server -batch
  4. 피어 인증서 요청을 생성하고 서명하십시오(peer.csrpeer.crt).

    # openssl req -new -config ${OPENSSLCFG} \
        -keyout ${PREFIX}peer.key \
        -out ${PREFIX}peer.csr \
        -reqexts etcd_v3_req -batch -nodes \
        -subj /CN=$CN
    
    # openssl ca -name etcd_ca -config ${OPENSSLCFG} \
      -out ${PREFIX}peer.crt \
      -in ${PREFIX}peer.csr \
      -extensions etcd_v3_ca_peer -batch
  5. 나중에 수정하도록 현재 노드에서 현재 etcd 구성 및 ca.crt 파일을 예제로 복사하십시오.

    # cp /etc/etcd/etcd.conf ${PREFIX}
    # cp /etc/etcd/ca.crt ${PREFIX}
  6. 여전히 남아 있는 etcd 호스트에 있는 동안 새 호스트를 클러스터에 추가하십시오. 클러스터에 etcd 멤버를 추가하려면 먼저 첫 번째 멤버의 peerURLs 값에서 기본 localhost 피어를 조정해야 합니다.

    1. member list 명령을 사용하여 첫 번째 멤버의 멤버 ID를 가져오십시오.

      # etcdctl --cert-file=/etc/etcd/peer.crt \
          --key-file=/etc/etcd/peer.key \
          --ca-file=/etc/etcd/ca.crt \
          --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ 1
          member list
      1
      --peers 매개 변수 값에 활성 etcd 멤버의 URL만 지정하십시오.
    2. etcd가 클러스터 피어를 청취하는 IP 주소를 얻으십시오.

      $ ss -l4n | grep 2380
    3. 멤버 ID와 이전 단계에서 얻은 IP 주소를 전달하여 etcdctl member update 명령으로 peerURLs의 값을 업데이트합니다.

      # etcdctl --cert-file=/etc/etcd/peer.crt \
          --key-file=/etc/etcd/peer.key \
          --ca-file=/etc/etcd/ca.crt \
          --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \
          member update 511b7fb6cc0001 https://172.18.1.18:2380
    4. member list 명령을 다시 실행하고 피어 URL에 더 이상 localhost가 포함되지 않도록 하십시오.
  7. 새 호스트를 etcd 클러스터에 추가하십시오. 새 호스트는 아직 구성되지 않았으므로 새 호스트를 구성할 때까지 상태는 unstarted로 남아 있습니다.

    주의

    각 멤버를 추가하고 한 번에 하나씩 온라인 상태로 만들어야 합니다. 각 멤버를 클러스터에 추가할 때 현재 피어의 peerURL 목록을 조정해야 합니다. peerURL 목록은 각 구성원이 추가될 때마다 하나씩 증가합니다. etcdctl member add 명령은 다음 지시사항에 설명된 대로 각 멤버를 추가할 때 etcd.conf 파일에 설정해야 하는 값을 출력합니다.

    # etcdctl -C https://${CURRENT_ETCD_HOST}:2379 \
      --ca-file=/etc/etcd/ca.crt     \
      --cert-file=/etc/etcd/peer.crt     \
      --key-file=/etc/etcd/peer.key member add ${NEW_ETCD_HOSTNAME} https://${NEW_ETCD_IP}:2380 1
    
    Added member named 10.3.9.222 with ID 4e1db163a21d7651 to cluster
    
    ETCD_NAME="<NEW_ETCD_HOSTNAME>"
    ETCD_INITIAL_CLUSTER="<NEW_ETCD_HOSTNAME>=https://<NEW_HOST_IP>:2380,<CLUSTERMEMBER1_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER2_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER3_NAME>=https:/<CLUSTERMEMBER3_IP>:2380"
    ETCD_INITIAL_CLUSTER_STATE="existing"
    1
    이 라인에서 10.3.9.222는 etcd 멤버의 레이블입니다. 호스트 이름, IP 주소 또는 간단한 이름을 지정할 수 있습니다.
  8. 샘플 ${PREFIX}/etcd.conf 파일을 업데이트하십시오.

    1. 다음 값을 이전 단계에서 생성된 값으로 바꾸십시오.

      • ETCD_NAME
      • ETCD_INITIAL_CLUSTER
      • ETCD_INITIAL_CLUSTER_STATE
    2. 이전 단계의 출력에서 새 호스트 IP로 다음 변수를 수정하십시오. ${NEW_ETCD_IP}를 값으로 사용할 수 있습니다.

      ETCD_LISTEN_PEER_URLS
      ETCD_LISTEN_CLIENT_URLS
      ETCD_INITIAL_ADVERTISE_PEER_URLS
      ETCD_ADVERTISE_CLIENT_URLS
    3. 이전에 멤버 시스템을 etcd 노드로 사용한 경우 /etc/etcd/etcd.conf 파일에서 현재 값을 덮어써야 합니다.
    4. 구문 오류 또는 누락된 IP 주소가 있는지 파일을 확인하십시오. 그렇지 않으면 etcd 서비스가 실패할 수 있습니다.

      # vi ${PREFIX}/etcd.conf
  9. 설치 파일을 호스팅하는 노드에서 /etc/ansible/hosts 인벤토리 파일의 [etcd] 호스트 그룹을 업데이트하십시오. 이전 etcd 호스트를 제거하고 새 호스트를 추가하십시오.
  10. 인증서, 샘플 구성 파일 및 ca가 포함된 tgz 파일을 생성하여 새 호스트에 복사하십시오.

    # tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} .
    # scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/
새 etcd 호스트 수정
  1. iptables-services를 설치하여 etcd의 필수 포트를 여는 iptables 유틸리티를 제공하십시오.

    # yum install -y iptables-services
  2. etcd가 통신할 수 있도록 OS_FIREWALL_ALLOW 방화벽 규칙을 생성하십시오.

    • 클라이언트용 2379/tcp 포트
    • 피어 통신용 2380/tcp 포트

      # systemctl enable iptables.service --now
      # iptables -N OS_FIREWALL_ALLOW
      # iptables -t filter -I INPUT -j OS_FIREWALL_ALLOW
      # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2379 -j ACCEPT
      # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2380 -j ACCEPT
      # iptables-save | tee /etc/sysconfig/iptables
      참고

      이 예에서는 새 체인 OS_FIREWALL_ALLOW가 생성되는데, 이는 OpenShift Container Platform 설치 프로그램이 방화벽 규칙에 사용하는 표준 이름입니다.

      주의

      IaaS 환경에서 환경을 호스팅하는 경우 해당 포트로 들어오는 트래픽도 허용하도록 인스턴스의 보안 그룹을 수정하십시오.

  3. etcd를 설치하십시오.

    # yum install -y etcd

    버전 etcd-2.3.7-4.el7.x86_64 이상이 설치되어 있는지 확인하십시오.

  4. etcd 포드 정의를 제거하여 etcd 서비스가 실행 중이지 않은지 확인하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  5. etcd 구성 및 데이터를 제거하십시오.

    # rm -Rf /etc/etcd/*
    # rm -Rf /var/lib/etcd/*
  6. 인증서 및 구성 파일을 추출하십시오.

    # tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
  7. 새 호스트에서 etcd를 시작하십시오.

    # systemctl enable etcd --now
  8. 호스트가 클러스터의 일부이고 현재 클러스터 상태인지 확인하십시오.

    • v2 etcd API를 사용하는 경우 다음 명령을 실행하십시오.

      # etcdctl --cert-file=/etc/etcd/peer.crt \
                --key-file=/etc/etcd/peer.key \
                --ca-file=/etc/etcd/ca.crt \
                --peers="https://*master-0.example.com*:2379,\
                https://*master-1.example.com*:2379,\
                https://*master-2.example.com*:2379,\
                https://*etcd0.example.com*:2379"\
                cluster-health
      member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
      member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
      member 8b8904727bf526a5 is healthy: got healthy result from https://192.168.55.21:2379
      member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
      cluster is healthy
    • v3 etcd API를 사용하는 경우 다음 명령을 실행하십시오.

      # ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \
                --key=/etc/etcd/peer.key \
                --cacert="/etc/etcd/ca.crt" \
                --endpoints="https://*master-0.example.com*:2379,\
                  https://*master-1.example.com*:2379,\
                  https://*master-2.example.com*:2379,\
                  https://*etcd0.example.com*:2379"\
                  endpoint health
      https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
      https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
      https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
      https://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms
각 OpenShift Container Platform 마스터 수정
  1. 모든 마스터에서 /etc/origin/master/master-config.yaml 파일의 etcClientInfo 섹션에서 마스터 구성을 수정하십시오. OpenShift Container Platform에서 데이터를 저장하는 데 사용하는 etcd 서버 목록에 새 etcd 호스트를 추가하고 실패한 etcd 호스트를 제거하십시오.

    etcdClientInfo:
      ca: master.etcd-ca.crt
      certFile: master.etcd-client.crt
      keyFile: master.etcd-client.key
      urls:
        - https://master-0.example.com:2379
        - https://master-1.example.com:2379
        - https://master-2.example.com:2379
        - https://etcd0.example.com:2379
  2. 마스터 API 서비스를 다시 시작하십시오.

    • 모든 마스터에서 다음을 수행하십시오.

      # master-restart api
      # master-restart controllers
      주의

      etcd 노드의 수는 홀수여야하므로 2개 이상의 호스트를 추가해야 합니다.

  3. Flannel을 사용하는 경우 새 etcd 호스트를 포함하도록 모든 OpenShift Container Platform 호스트에서 /etc/sysconfig/flanneld에 있는 flanneld 서비스 구성을 수정하십시오.

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
  4. flanneld 서비스를 다시 시작하십시오.

    # systemctl restart flanneld.service

5.4.5. etcd 호스트 제거

etcd 호스트가 복원 이후에 실패하면 클러스터에서 제거하십시오.

모든 마스터 호스트에서 수행할 단계

프로시저
  1. etcd 클러스터에서 서로 다른 etcd 호스트를 제거하십시오. 각 etcd 노드에 대해 다음 명령을 실행하십시오.

    # etcdctl -C https://<surviving host IP address>:2379 \
      --ca-file=/etc/etcd/ca.crt     \
      --cert-file=/etc/etcd/peer.crt     \
      --key-file=/etc/etcd/peer.key member remove <failed member ID>
  2. 모든 마스터에서 마스터 API 서비스를 다시 시작하십시오.

    # master-restart api restart-master controller

현재 etcd 클러스터에서 수행할 단계

프로시저
  1. 클러스터에서 실패한 호스트를 제거하십시오.

    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    failed to check the health of member 8372784203e11288 on https://192.168.55.21:2379: Get https://192.168.55.21:2379/health: dial tcp 192.168.55.21:2379: getsockopt: connection refused
    member 8372784203e11288 is unreachable: [https://192.168.55.21:2379] are all unreachable
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    
    # etcdctl2 member remove 8372784203e11288 1
    Removed member 8372784203e11288 from cluster
    
    # etcdctl2 cluster-health
    member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
    member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
    member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
    cluster is healthy
    1
    remove 명령에는 호스트 이름이 아니라 etcd ID가 필요합니다.
  2. etcd 서비스를 다시 시작할 때 etcd 구성이 실패한 호스트를 사용하지 않게 하려면 나머지 모든 etcd 호스트에서 /etc/etcd/etcd.conf 파일을 수정하고 ETCD_INITIAL_CLUSTER 변수의 값에서 실패한 호스트를 제거하십시오.

    # vi /etc/etcd/etcd.conf

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

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380,master-2.example.com=https://192.168.55.13:2380

    이는 다음이 됩니다.

    ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380
    참고

    실패한 호스트는 etcdctl을 사용하여 제거되므로 etcd 서비스를 다시 시작할 필요가 없습니다.

  3. 클러스터의 현재 상태를 반영하고 플레이북을 다시 실행할 때 문제가 발생하지 않도록 Ansible 인벤토리 파일을 수정하십시오.

    [OSEv3:children]
    masters
    nodes
    etcd
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
  4. Flannel을 사용하는 경우 모든 호스트에서 /etc/sysconfig/flanneld에 있는 flanneld 서비스 구성을 수정하고 etcd 호스트를 제거하십시오.

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379
  5. flanneld 서비스를 다시 시작하십시오.

    # systemctl restart flanneld.service

6장. 프로젝트 수준 작업

6.1. 프로젝트 백업

관련된 모든 데이터의 백업을 생성하려면 중요한 정보를 모두 내보낸 다음 새 프로젝트로 복원해야 합니다.

중요

oc get all 명령은 특정 프로젝트 리소스만 반환하므로 다음 단계에 표시된 대로 PVC 및 보안을 비롯한 다른 리소스를 별도로 백업해야 합니다.

프로시저

  1. 백업할 프로젝트 데이터를 나열하십시오.

    $ oc get all
    NAME         TYPE      FROM      LATEST
    bc/ruby-ex   Source    Git       1
    
    NAME               TYPE      FROM          STATUS     STARTED         DURATION
    builds/ruby-ex-1   Source    Git@c457001   Complete   2 minutes ago   35s
    
    NAME                 DOCKER REPO                                     TAGS      UPDATED
    is/guestbook         10.111.255.221:5000/myproject/guestbook         latest    2 minutes ago
    is/hello-openshift   10.111.255.221:5000/myproject/hello-openshift   latest    2 minutes ago
    is/ruby-22-centos7   10.111.255.221:5000/myproject/ruby-22-centos7   latest    2 minutes ago
    is/ruby-ex           10.111.255.221:5000/myproject/ruby-ex           latest    2 minutes ago
    
    NAME                 REVISION   DESIRED   CURRENT   TRIGGERED BY
    dc/guestbook         1          1         1         config,image(guestbook:latest)
    dc/hello-openshift   1          1         1         config,image(hello-openshift:latest)
    dc/ruby-ex           1          1         1         config,image(ruby-ex:latest)
    
    NAME                   DESIRED   CURRENT   READY     AGE
    rc/guestbook-1         1         1         1         2m
    rc/hello-openshift-1   1         1         1         2m
    rc/ruby-ex-1           1         1         1         2m
    
    NAME                  CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
    svc/guestbook         10.111.105.84    <none>        3000/TCP            2m
    svc/hello-openshift   10.111.230.24    <none>        8080/TCP,8888/TCP   2m
    svc/ruby-ex           10.111.232.117   <none>        8080/TCP            2m
    
    NAME                         READY     STATUS      RESTARTS   AGE
    po/guestbook-1-c010g         1/1       Running     0          2m
    po/hello-openshift-1-4zw2q   1/1       Running     0          2m
    po/ruby-ex-1-build           0/1       Completed   0          2m
    po/ruby-ex-1-rxc74           1/1       Running     0          2m
  2. 프로젝트 오브젝트를 .yaml 또는 .json 파일로 내보냅니다.

    • 프로젝트 오브젝트를 project.yaml 파일로 내보내려면 다음을 수행하십시오.

      $ oc get -o yaml --export all > project.yaml
    • 프로젝트 오브젝트를 project.json 파일로 내보내려면 다음을 수행하십시오.

      $ oc get -o json --export all > project.json
  3. 프로젝트의 역할 바인딩, 보안, 서비스 계정영구 볼륨 클레임을 내보냅니다.

    $ for object in rolebindings serviceaccounts secrets imagestreamtags cm egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvc templates cronjobs statefulsets hpa deployments replicasets poddisruptionbudget endpoints
    do
      oc get -o yaml --export $object > $object.yaml
    done
  4. 네임스페이스가 지정된 모든 오브젝트를 나열하려면 다음을 수행하십시오.

    $ oc api-resources --namespaced=true -o name
  5. 내보낸 일부 오브젝트는 특정 메타데이터 또는 프로젝트의 고유 ID에 대한 참조를 사용할 수 있습니다. 이것은 재생성된 개체의 유용성에 대한 제한사항입니다.

    imagestreams를 사용하는 경우 deploymentconfigimage 매개 변수는 복원된 환경에 존재하지 않는 내부 레지스트리에 있는 이미지의 특정 sha 체크섬을 가리킬 수 있습니다. 예를 들어 샘플 "ruby-ex"를 oc new-app centos/ruby-22-centos7~https://github.com/sclorg/ruby-ex.git로 실행하면 이미지를 호스팅하기 위해 내부 레지스트리를 사용하여 imagestream ruby-ex를 생성합니다.

    $ oc get dc ruby-ex -o jsonpath="{.spec.template.spec.containers[].image}"
    10.111.255.221:5000/myproject/ruby-ex@sha256:880c720b23c8d15a53b01db52f7abdcbb2280e03f686a5c8edfef1a2a7b21cee

    deploymentconfig를 가져오는 경우 oc get --export를 통해 내보냈으므로 이미지가 없으면 실패합니다.

6.2. 프로젝트 복원

프로젝트를 복원하려면 새 프로젝트를 생성한 다음 oc create -f pods.json을 실행하여 내보낸 파일을 복원하십시오. 그러나 일부 오브젝트에는 다른 오브젝트가 필요하므로 프로젝트를 처음부터 새로 복원하려면 특정 순서가 필요합니다. 예를 들어, pods를 만들기 전에 configmaps를 생성해야 합니다.

프로시저

  1. 프로젝트를 단일 파일로 내보낸 경우 다음 명령을 실행하여 가져오십시오.

    $ oc new-project <projectname>
    $ oc create -f project.yaml
    $ oc create -f secret.yaml
    $ oc create -f serviceaccount.yaml
    $ oc create -f pvc.yaml
    $ oc create -f rolebindings.yaml
    주의

    포드 및 기본 서비스 계정과 같은 일부 리소스를 생성하지 못할 수 있습니다.

6.2.1. 영구 볼륨 클레임 백업

컨테이너 내부에서 서버로 영구 데이터를 동기화할 수 있습니다.

중요

OpenShift Container Platform 환경을 호스팅하는 공급자에 따라 백업 및 복원 목적으로 타사 스냅샷 서비스를 시작하는 기능도 있습니다. OpenShift Container Platform에는 이러한 서비스를 시작할 수 있는 기능이 없으므로 이 안내서에서는 해당 단계를 설명하지 않습니다.

특정 애플리케이션의 올바른 백업 프로시저는 제품 설명서를 참조하십시오. 예를 들어, mysql 데이터 디렉터리 자체를 복사해도 사용 가능한 백업이 생성되지 않습니다. 대신 관련 애플리케이션의 특정 백업 프로시저를 실행한 다음 모든 데이터를 동기화하십시오. 여기에는 OpenShift Container Platform 호스팅 플랫폼에서 제공하는 스냅샷 솔루션 사용이 포함됩니다.

프로시저
  1. 프로젝트와 포드를 보십시오.

    $ oc get pods
    NAME           READY     STATUS      RESTARTS   AGE
    demo-1-build   0/1       Completed   0          2h
    demo-2-fxx6d   1/1       Running     0          1h
  2. 영구 볼륨에서 현재 사용 중인 볼륨을 찾으려면 원하는 포드를 설명하십시오.

    $ oc describe pod demo-2-fxx6d
    Name:			demo-2-fxx6d
    Namespace:		test
    Security Policy:	restricted
    Node:			ip-10-20-6-20.ec2.internal/10.20.6.20
    Start Time:		Tue, 05 Dec 2017 12:54:34 -0500
    Labels:			app=demo
    			deployment=demo-2
    			deploymentconfig=demo
    Status:			Running
    IP:			172.16.12.5
    Controllers:		ReplicationController/demo-2
    Containers:
      demo:
        Container ID:	docker://201f3e55b373641eb36945d723e1e212ecab847311109b5cee1fd0109424217a
        Image:		docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Image ID:		docker-pullable://docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Port:		8080/TCP
        State:		Running
          Started:		Tue, 05 Dec 2017 12:54:52 -0500
        Ready:		True
        Restart Count:	0
        Volume Mounts:
          */opt/app-root/src/uploaded from persistent-volume (rw)*
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-8mmrk (ro)
        Environment Variables:	<none>
    ...omitted...

    이 출력에서는 영구 데이터가 /opt/app-root/src/uploaded 디렉터리에 있음을 보여줍니다.

  3. 로컬로 데이터를 복사하십시오.

    $ oc rsync demo-2-fxx6d:/opt/app-root/src/uploaded ./demo-app
    receiving incremental file list
    uploaded/
    uploaded/ocp_sop.txt
    uploaded/lost+found/
    
    sent 38 bytes  received 190 bytes  152.00 bytes/sec
    total size is 32  speedup is 0.14

    백업 소프트웨어 또는 또 다른 백업 메커니즘으로 백업하기 위해 ocp_sop.txt 파일을 로컬 시스템으로 다운로드합니다.

    참고

    PVC를 사용할 필요 없이 포드를 시작하는 경우 이전 단계를 사용할 수도 있지만, 나중에 PVC가 필요하다고 결정할 수 있습니다 데이터를 보존한 다음 복원 프로세스를 사용하여 새 스토리지를 채울 수 있습니다.

6.2.2. 영구 볼륨 클레임 복원

백업한 영구 볼륨 클레임(PVC) 데이터를 복원할 수 있습니다. 파일을 삭제한 다음 파일을 예상 위치에 다시 배치하거나 영구 볼륨 클레임을 마이그레이션할 수 있습니다. 스토리지를 이동해야 하거나 백엔드 스토리지가 더 이상 없는 재해 시나리오에서 마이그레이션할 수 있습니다.

특정 애플리케이션의 올바른 복원 프로시저는 제품 설명서를 참조하십시오.

6.2.2.1. 기존 PVC로 파일 복원

프로시저
  1. 파일을 삭제하십시오.

    $ oc rsh demo-2-fxx6d
    sh-4.2$ ls */opt/app-root/src/uploaded/*
    lost+found  ocp_sop.txt
    sh-4.2$ *rm -rf /opt/app-root/src/uploaded/ocp_sop.txt*
    sh-4.2$ *ls /opt/app-root/src/uploaded/*
    lost+found
  2. PVC에 있던 파일의 rsync 백업이 포함된 서버에서 파일을 바꾸십시오.

    $ oc rsync uploaded demo-2-fxx6d:/opt/app-root/src/
  3. oc rsh를 사용하여 포드에 연결하고 디렉터리의 콘텐츠를 확인하여 파일이 포드에 다시 있는지 확인하십시오.

    $ oc rsh demo-2-fxx6d
    sh-4.2$ *ls /opt/app-root/src/uploaded/*
    lost+found  ocp_sop.txt

6.2.2.2. 새로운 PVC로 데이터 복원

다음 단계에서는 새 pvc가 작성되었다고 가정합니다.

프로시저
  1. 현재 정의된 claim-name을 덮어 쓰십시오.

    $ oc set volume dc/demo --add --name=persistent-volume \
    		--type=persistentVolumeClaim --claim-name=filestore \ --mount-path=/opt/app-root/src/uploaded --overwrite
  2. 포드에서 새로운 PVC를 사용하고 있는지 확인하십시오.

    $ oc describe dc/demo
    Name:		demo
    Namespace:	test
    Created:	3 hours ago
    Labels:		app=demo
    Annotations:	openshift.io/generated-by=OpenShiftNewApp
    Latest Version:	3
    Selector:	app=demo,deploymentconfig=demo
    Replicas:	1
    Triggers:	Config, Image(demo@latest, auto=true)
    Strategy:	Rolling
    Template:
      Labels:	app=demo
    		deploymentconfig=demo
      Annotations:	openshift.io/container.demo.image.entrypoint=["container-entrypoint","/bin/sh","-c","$STI_SCRIPTS_PATH/usage"]
    		openshift.io/generated-by=OpenShiftNewApp
      Containers:
       demo:
        Image:	docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Port:	8080/TCP
        Volume Mounts:
          /opt/app-root/src/uploaded from persistent-volume (rw)
        Environment Variables:	<none>
      Volumes:
       persistent-volume:
        Type:	PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        *ClaimName:	filestore*
        ReadOnly:	false
    ...omitted...
  3. 배치 구성에서 새 pvc를 사용하므로 oc rsync를 실행하여 파일을 새 pvc에 배치하십시오.

    $ oc rsync uploaded demo-3-2b8gs:/opt/app-root/src/
    sending incremental file list
    uploaded/
    uploaded/ocp_sop.txt
    uploaded/lost+found/
    
    sent 181 bytes  received 39 bytes  146.67 bytes/sec
    total size is 32  speedup is 0.15
  4. oc rsh를 사용하여 포드에 연결하고 디렉터리의 콘텐츠를 확인하여 파일이 포드에 다시 있는지 확인하십시오.

    $ oc rsh demo-3-2b8gs
    sh-4.2$ ls /opt/app-root/src/uploaded/
    lost+found  ocp_sop.txt

6.2.3. 이미지 및 컨테이너 제거

수집된 데이터 및 이전 버전의 오브젝트를 제거하는 방법에 대한 정보는 리소스 제거 주제를 참조하십시오.

7장. Docker 작업

OpenShift Container Platform에서는 컨테이너 엔진(CRI-O 또는 Docker)을 사용하여 여러 컨테이너로 구성된 포드에서 애플리케이션을 실행합니다.

클러스터 관리자가 OpenShift Container Platform 설치 요소를 효율적으로 실행하기 위해 때때로 컨테이너 엔진을 추가로 구성해야 할 수도 있습니다.

7.1. 컨테이너 스토리지 증가

사용 가능한 스토리지 양을 늘리면 중단없이 계속 배포할 수 있습니다. 이렇게 하려면 적절한 양의 여유 용량이 포함된 여유 파티션을 사용할 수 있어야 합니다.

7.1.1. 노드 비우기

프로시저

  1. 마스터 인스턴스에서 또는 클러스터 관리자로 노드에서 포드를 비우고 해당 노드에서 다른 포드의 스케줄링을 비활성화하십시오.

    $ NODE=ose-app-node01.example.com
    $ oc adm manage-node ${NODE} --schedulable=false
    NAME                          STATUS                     AGE       VERSION
    ose-app-node01.example.com   Ready,SchedulingDisabled   20m       v1.6.1+5115d708d7
    
    $ oc adm drain ${NODE} --ignore-daemonsets
    node "ose-app-node01.example.com" already cordoned
    pod "perl-1-build" evicted
    pod "perl-1-3lnsh" evicted
    pod "perl-1-9jzd8" evicted
    node "ose-app-node01.example.com" drained
    참고

    마이그레이션하지 않는 로컬 볼륨에서 실행 중인 컨테이너가 있으면 다음 명령을 실행하십시오. oc adm drain $ {NODE} --ignore-daemonsets --delete-local-data

  2. 노드의 포드를 나열하여 포드가 제거되었는지 확인하십시오.

    $ oc adm manage-node ${NODE} --list-pods
    
    Listing matched pods on node: ose-app-node01.example.com
    
    NAME      READY     STATUS    RESTARTS   AGE
  3. 각 노드에 대해 이전 두 단계를 반복하십시오.

포드 또는 노드 비우기 및 유출에 대한 자세한 내용은 노드 유지보수를 참조하십시오.

7.1.2. 스토리지 증가

Docker 스토리지는 두 가지 방법, 즉 새 디스크 연결 또는 기존 디스크 확장을 통해 늘릴 수 있습니다.

새로운 디스크로 스토리지 증가

전제 조건
  • 스토리지가 더 필요한 기존 인스턴스에 새 디스크를 사용할 수 있어야 합니다. 다음 단계에서 /etc/sysconfig/docker-storage-setup 파일에 표시된 것처럼 원본 디스크에는 /dev/xvdb 레이블이 지정되고 새 디스크에는 /dev/xvdd 레이블이 지정됩니다.

    # vi /etc/sysconfig/docker-storage-setup
    DEVS="/dev/xvdb /dev/xvdd"
    참고

    이 프로세스는 기본 OpenShift Container Platform 인프라에 따라 다를 수 있습니다.

프로시저
  1. docker를 중지하십시오.

    # systemctl stop docker
  2. 포드 정의를 제거하고 호스트를 재부팅하여 노드 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  3. docker-storage-setup 명령을 실행하여 컨테이너 스토리지와 연관된 볼륨 그룹 및 논리 볼륨을 확장하십시오.

    # docker-storage-setup
    1. thin pool 설정의 경우 다음 출력이 표시되고 다음 단계로 진행할 수 있습니다.

      INFO: Volume group backing root filesystem could not be determined
      INFO: Device /dev/xvdb is already partitioned and is part of volume group docker_vol
      INFO: Device node /dev/xvdd1 exists.
        Physical volume "/dev/xvdd1" successfully created.
        Volume group "docker_vol" successfully extended
    2. Overlay2 파일 시스템을 사용하는 XFS 설정의 경우 이전 출력에 표시된 증가가 표시되지 않습니다.

      XFS 스토리지를 확장하려면 다음 단계를 수행해야 합니다.

      1. lvextend 명령을 실행하여 볼륨 그룹에서 사용 가능한 모든 공간을 사용하도록 논리 볼륨을 늘리십시오.

        # lvextend -r -l +100%FREE /dev/mapper/docker_vol-dockerlv
        참고

        더 적은 공간을 사용해야 하는 경우 적절하게 FREE 백분율을 선택하십시오.

      2. 사용 가능한 공간을 사용하도록 파일 시스템을 늘리려면 xfs_growfs 명령을 실행하십시오.

        # xfs_growfs /dev/mapper/docker_vol-dockerlv
        참고

        XFS 파일 시스템은 축소할 수 없습니다.

      3. docker-storage-setup 명령을 다시 실행하십시오.

        # docker-storage-setup

        이제 출력에 확장 볼륨 그룹과 논리 볼륨이 표시됩니다.

        INFO: Device /dev/vdb is already partitioned and is part of volume group docker_vg
        INFO: Found an already configured thin pool /dev/mapper/docker_vg-docker--pool in /etc/sysconfig/docker-storage
        INFO: Device node /dev/mapper/docker_vg-docker--pool exists.
          Logical volume docker_vg/docker-pool changed.
  4. Docker 서비스를 시작하십시오.

    # systemctl start docker
    # vgs
      VG         #PV #LV #SN Attr   VSize  VFree
      docker_vol   2   1   0 wz--n- 64.99g <55.00g
  5. 호스트를 재부팅하여 노드 서비스를 다시 시작하십시오.

    # systemctl restart atomic-openshift-node.service
  6. 새 볼륨 그룹을 생성하고 docker-storage-setup을 다시 실행하는 것과 비교하여 디스크를 추가하면 새 스토리지를 추가한 후에도 시스템에서 사용된 이미지가 여전히 존재한다는 이점이 있습니다.

    # container images
    REPOSITORY                                              TAG                 IMAGE ID            CREATED             SIZE
    docker-registry.default.svc:5000/tet/perl               latest              8b0b0106fb5e        13 minutes ago      627.4 MB
    registry.redhat.io/rhscl/perl-524-rhel7         <none>              912b01ac7570        6 days ago          559.5 MB
    registry.redhat.io/openshift3/ose-deployer      v3.6.173.0.21       89fd398a337d        5 weeks ago         970.2 MB
    registry.redhat.io/openshift3/ose-pod           v3.6.173.0.21       63accd48a0d7        5 weeks ago         208.6 MB
  7. 스토리지 용량이 증가함에 따라 새로 들어오는 포드를 허용하도록 노드를 스케줄링하게 설정하십시오.

    클러스터 관리자로 마스터 인스턴스에서 다음을 실행하십시오.

    $ oc adm manage-node ${NODE} --schedulable=true
    
    ose-master01.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-master02.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-master03.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-infra-node01.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-infra-node02.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-infra-node03.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-app-node01.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-app-node02.example.com   Ready                      24m       v1.6.1+5115d708d7

새로운 디스크로 스토리지 증가

  1. 이전 단계를 따라 노드를 비우십시오.
  2. docker를 중지하십시오.

    # systemctl stop docker
  3. 포드 정의를 제거하여 노드 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  4. 기존 디스크의 크기를 원하는 대로 조정하십시오. 이 크기는 환경에 따라 달라질 수 있습니다.

    • LVM(Logical Volume Manager)을 사용하는 경우 다음을 수행하십시오.

    • 클라우드 공급자를 사용하는 경우 디스크를 삭제한 다음 더 큰 새 디스크를 생성하고 인스턴스에 연결할 수 있습니다.
    • 비클라우드 환경의 경우 디스크 및 파일 시스템의 크기를 조정할 수 있습니다. 자세한 내용은 다음 솔루션을 참조하십시오.

  5. 장치 이름, 크기 등을 점검하여 새 디스크에 맞게 /etc/sysconfig/container-storage-setup 파일이 올바르게 구성되었는지 확인하십시오.
  6. docker-storage-setup을 실행하여 새 디스크를 재구성하십시오.

    # docker-storage-setup
    INFO: Volume group backing root filesystem could not be determined
    INFO: Device /dev/xvdb is already partitioned and is part of volume group docker_vol
    INFO: Device node /dev/xvdd1 exists.
      Physical volume "/dev/xvdd1" successfully created.
      Volume group "docker_vol" successfully extended
  7. Docker 서비스를 시작하십시오.

    # systemctl start docker
    # vgs
      VG         #PV #LV #SN Attr   VSize  VFree
      docker_vol   2   1   0 wz--n- 64.99g <55.00g
  8. 호스트를 재부팅하여 노드 서비스를 다시 시작하십시오.

    # systemctl restart atomic-openshift-node.service

7.1.3. 스토리지 백엔드 변경

서비스 및 파일 시스템이 개선됨에 따라 새로운 기능을 활용하기 위해 스토리지 백엔드의 변경이 필요할 수 있습니다. 다음 단계에서는 장치 매퍼 백엔드를 overlay2 스토리지 백엔드로 변경하는 예를 제공합니다. overlay2는 기존 장치 매퍼보다 속도와 밀도가 향상되었습니다.

7.1.3.1. 노드 비우기

  1. 마스터 인스턴스에서 또는 클러스터 관리자로 노드에서 포드를 비우고 해당 노드에서 다른 포드의 스케줄링을 비활성화하십시오.

    $ NODE=ose-app-node01.example.com
    $ oc adm manage-node ${NODE} --schedulable=false
    NAME                          STATUS                     AGE       VERSION
    ose-app-node01.example.com   Ready,SchedulingDisabled   20m       v1.6.1+5115d708d7
    
    $ oc adm drain ${NODE} --ignore-daemonsets
    node "ose-app-node01.example.com" already cordoned
    pod "perl-1-build" evicted
    pod "perl-1-3lnsh" evicted
    pod "perl-1-9jzd8" evicted
    node "ose-app-node01.example.com" drained
    참고

    마이그레이션하지 않는 로컬 볼륨에서 실행 중인 컨테이너가 있으면 다음 명령을 실행하십시오. oc adm drain $ {NODE} --ignore-daemonsets --delete-local-data

  2. 노드의 포드를 나열하여 포드가 제거되었는지 확인하십시오.

    $ oc adm manage-node ${NODE} --list-pods
    
    Listing matched pods on node: ose-app-node01.example.com
    
    NAME      READY     STATUS    RESTARTS   AGE

    포드 또는 노드 비우기 및 유출에 대한 자세한 내용은 노드 유지보수를 참조하십시오.

  3. 현재 인스턴스에서 실행중인 컨테이너가 없으면 docker 서비스를 중지하십시오.

    # systemctl stop docker
  4. 포드 정의를 제거하여 노드 서비스를 중지하십시오.

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  5. 볼륨 그룹 이름, 논리 볼륨 이름 및 물리 볼륨 이름을 확인하십시오.

    # vgs
      VG         #PV #LV #SN Attr   VSize   VFree
      docker_vol   1   1   0 wz--n- <25.00g 15.00g
    
    # lvs
    LV       VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
     dockerlv docker_vol -wi-ao---- <10.00g
    
    # lvremove /dev/docker_vol/docker-pool  -y
    # vgremove docker_vol -y
    # pvs
      PV         VG         Fmt  Attr PSize   PFree
      /dev/xvdb1 docker_vol lvm2 a--  <25.00g 15.00g
    
    # pvremove /dev/xvdb1 -y
    # rm -Rf /var/lib/docker/*
    # rm -f /etc/sysconfig/docker-storage
  6. docker-storage-setup 파일을 수정하여 STORAGE_DRIVER를 지정하십시오.

    참고

    시스템이 Red Hat Enterprise Linux 버전 7.3에서 7.4로 업그레이드되면, docker 서비스에서 extfs의 STORAGE_DRIVER와 함께 /var을 사용하려고 시도합니다. extor을 STORAGE_DRIVER로 사용하면 오류가 발생합니다. 오류에 대한 자세한 내용은 다음 버그를 참조하십시오.

    DEVS=/dev/xvdb
    VG=docker_vol
    DATA_SIZE=95%VG
    STORAGE_DRIVER=overlay2
    CONTAINER_ROOT_LV_NAME=dockerlv
    CONTAINER_ROOT_LV_MOUNT_PATH=/var/lib/docker
    CONTAINER_ROOT_LV_SIZE=100%FREE
  7. 스토리지를 설정하십시오.

    # docker-storage-setup
  8. docker를 시작하십시오.

    # systemctl start docker
  9. 호스트를 재부팅하여 노드 서비스를 다시 시작하십시오.

    # systemctl restart atomic-openshift-node.service
  10. overlay2를 사용하도록 스토리지를 수정한 상태에서 들어오는 새 포드를 허용하도록 노드를 스케줄링 가능하게 하십시오.

    마스터 인스턴스에서 또는 클러스터 관리자로 다음을 수행하십시오.

    $ oc adm manage-node ${NODE} --schedulable=true
    
    ose-master01.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-master02.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-master03.example.com   Ready,SchedulingDisabled   24m       v1.6.1+5115d708d7
    ose-infra-node01.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-infra-node02.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-infra-node03.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-app-node01.example.com   Ready                      24m       v1.6.1+5115d708d7
    ose-app-node02.example.com   Ready                      24m       v1.6.1+5115d708d7

7.2. 컨테이너 레지스트리 인증서 관리

OpenShift Container Platform 내부 레지스트리는 포드로 생성됩니다. 그러나 원하는 경우 컨테이너를 외부 레지스트리에서 가져올 수 있습니다. 기본적으로 레지스트리는 TCP 포트 5000에서 청취합니다. 레지스트리에서는 TLS를 통해 노출된 이미지를 보호하거나 트래픽을 암호화하지 않고 레지스트리를 실행하는 옵션을 제공합니다.

주의

Docker에서는 .crt 파일을 CA 인증서로 해석하고 .cert 파일을 클라이언트 인증서로 해석합니다. 모든 CA 확장자는 .crt이어야 합니다.

7.2.1. 외부 레지스트리용 인증 기관 인증서 설치

외부 레지스트리와 함께 OpenShift Container Platform을 사용하려면 레지스트리에서 이미지를 가져올 수 있는 모든 노드의 레지스트리 인증 기관(CA) 인증서를 신뢰해야 합니다.

참고

Docker 버전에 따라 컨테이너 이미지 레지스트리를 신뢰하는 프로세스가 다릅니다. Docker 루트 인증 기관의 최신 버전이 시스템 기본값과 병합됩니다. docker 버전 1.13 이전에는 다른 사용자 정의 루트 인증서가 없을 때만 시스템 기본 인증서를 사용합니다.

프로시저
  1. CA 인증서를 /etc/pki/ca-trust/source/anchors/에 복사하십시오.

    $ sudo cp myregistry.example.com.crt /etc/pki/ca-trust/source/anchors/
  2. 신뢰할 수 있는 인증 기관 목록에 CA 인증서를 추출하여 추가하십시오.

    $ sudo update-ca-trust extract
  3. openssl 명령을 사용하여 SSL 인증서를 확인하십시오.

    $ openssl verify myregistry.example.com.crt
    myregistry.example.com.crt: OK
  4. 인증서가 있고 신뢰가 업데이트되면 docker 서비스를 다시 시작하여 새 인증서가 올바르게 설정되었는지 확인하십시오.

    $ sudo systemctl restart docker.service

Docker 버전이 1.13인 경우 기관 인증서를 신뢰하기 위해 다음 추가 단계를 수행하십시오.

  1. 모든 노드에서 /etc/docker/certs.d에 새 디렉터리를 작성하십시오. 여기서 디렉터리 이름은 컨테이너 이미지 레지스트리의 호스트 이름입니다.

    $ sudo mkdir -p /etc/docker/certs.d/myregistry.example.com
    참고

    포트 번호 없이 컨테이너 이미지 레지스트리에 액세스할 수 없으면 포트 번호는 필요하지 않습니다. 원래 Docker 레지스트리에 포트를 지정하는 방법은 다음과 같습니다. myregistry.example.com:port

  2. IP 주소를 통해 컨테이너 이미지 레지스트리에 액세스하려면 디렉터리 이름이 컨테이너 이미지 레지스트리의 IP인 모든 노드에서 /etc/docker/certs.d 내에 새 디렉터리를 생성해야 합니다.

    $ sudo mkdir -p /etc/docker/certs.d/10.10.10.10
  3. 이전 단계에서 새로 생성된 Docker 디렉터리에 CA 인증서를 복사하십시오.

    $ sudo cp myregistry.example.com.crt \
      /etc/docker/certs.d/myregistry.example.com/ca.crt
    
    $ sudo cp myregistry.example.com.crt /etc/docker/certs.d/10.10.10.10/ca.crt
  4. 인증서가 복사되면 docker 서비스를 다시 시작하여 새 인증서가 사용되는지 확인하십시오.

    $ sudo systemctl restart docker.service

7.2.2. Docker 인증서 백업

노드 호스트 백업을 수행할 때 외부 레지스트리의 인증서를 포함시키십시오.

프로시저
  1. /etc/docker/certs.d를 사용하는 경우 디렉터리에 포함된 모든 인증서를 복사하고 파일을 저장하십시오.

    $ sudo tar -czvf docker-registry-certs-$(hostname)-$(date +%Y%m%d).tar.gz /etc/docker/certs.d/
  2. 시스템 신뢰를 사용하는 경우 시스템 신뢰 내에 인증서를 추가하기 전에 인증서를 저장하십시오. 저장이 완료되면 trust 명령을 사용하여 복원할 인증서를 추출하십시오. 시스템 신뢰 CA를 식별하고 pkcs11 ID를 기록하십시오.

    $ trust list
    ...[OUTPUT OMMITED]...
    pkcs11:id=%a5%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert
        type: certificate
        label: MyCA
        trust: anchor
        category: authority
    ...[OUTPUT OMMITED]...
  3. pem 형식으로 인증서를 추출하고 이름을 제공하십시오. 예를 들어, myca.crt입니다.

    $ trust extract --format=pem-bundle \
     --filter="%a5%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert" myca.crt
  4. openssl을 통해 인증서가 올바르게 추출되었는지 확인하십시오.

    $ openssl verify myca.crt
  5. 필요한 모든 인증서에 대해 프로시저를 반복하고 파일을 원격 위치에 저장하십시오.

7.2.3. Docker 인증서 복원

외부 레지스트리의 Docker 인증서가 삭제되거나 손상된 경우 복원 메커니즘에서는 이전에 수행된 백업의 파일을 사용하는 설치 방법과 동일한 단계를 사용합니다.

7.3. 컨테이너 레지스트리 관리

외부 docker 레지스트리를 사용하여 이미지를 가져오도록 OpenShift Container Platform을 구성할 수 있습니다. 그러나 구성 파일을 사용하여 특정 이미지 또는 레지스트리를 허용하거나 거부할 수 있습니다.

네트워크 트래픽의 인증서를 사용하여 외부 레지스트리가 노출되면 보안 레지스트리로 이름을 지정할 수 있습니다. 그렇지 않으면 레지스트리와 호스트 사이의 트래픽은 일반 텍스트이며 암호화되지 않으므로 레지스트리가 안전하지 않습니다.

7.3.1. Docker 검색 외부 레지스트리

기본적으로 docker 데몬에서는 모든 레지스트리에서 이미지를 가져올 수 있지만 docker.io/registry.redhat.io 에 대해 검색 작업이 수행됩니다. docker 데몬과 함께 --add-registry 옵션을 사용하여 다른 레지스트리에서 이미지를 검색하도록 데몬을 구성할 수 있습니다.

참고

Red Hat Registry registry.redhat.io에서 이미지를 검색하는 기능은 기본적으로 Red Hat Enterprise Linux docker 패키지에 있습니다.

프로시저
  1. 사용자가 다른 레지스트리와 함께 docker search를 사용하여 이미지를 검색할 수 있게 하려면 해당 레지스트리를 registries 매개 변수 아래 /etc/containers/registries.conf 파일에 추가하십시오.

    registries:
      - registry.redhat.io
      - my.registry.example.com
  2. my.registry.example.com을 사용하려면 docker 데몬을 다시 시작하십시오.

    $ sudo systemctl restart docker.service

    docker 데몬을 다시 시작하면 docker 컨테이너가 다시 시작됩니다.

  3. Ansible 설치 프로그램을 사용하면 Ansible 호스트 파일의 openshift_docker_additional_registries 변수를 사용하여 구성할 수 있습니다.

    openshift_docker_additional_registries=registry.redhat.io,my.registry.example.com

7.3.2. Docker 외부 레지스트리 허용 목록 및 차단 목록

docker 데몬의 registriesblock_registries 플래그를 구성하여 외부 레지스트리에서 작업을 차단하도록 Docker를 구성할 수 있습니다.

프로시저
  1. registries 플래그를 사용하여 허용되는 레지스트리를 /etc/containers/registries.conf 파일에 추가하십시오.

    registries:
      - registry.redhat.io
      - my.registry.example.com
    참고

    docker.io 레지스트리는 동일한 방법으로 추가할 수 있습니다.

  2. 나머지 레지스트리를 차단하십시오.

    block_registries:
       - all
  3. 이전 버전의 나머지 레지스트리를 차단하십시오.

    BLOCK_REGISTRY='--block-registry=all'
  4. docker 데몬을 다시 시작하십시오.

    $ sudo systemctl restart docker.service

    docker 데몬을 다시 시작하면 docker 컨테이너가 다시 시작됩니다.

  5. 이 예에서는 docker.io 레지스트리가 차단 목록에 추가되었으므로 해당 레지스트리와 관련된 모든 작업이 실패합니다.

    $ sudo docker pull hello-world
    Using default tag: latest
    Trying to pull repository registry.redhat.io/hello-world ...
    Trying to pull repository my.registry.example.com/hello-world ...
    Trying to pull repository registry.redhat.io/hello-world ...
    unknown: Not Found
    $ sudo docker pull docker.io/hello-world
    Using default tag: latest
    Trying to pull repository docker.io/library/hello-world ...
    All endpoints blocked.

    파일을 다시 수정하고 서비스를 다시 시작하여 docker.ioregistries 변수에 다시 추가하십시오.

    registries:
      - registry.redhat.io
      - my.registry.example.com
      - docker.io
    block_registries:
      - all

    또는

    ADD_REGISTRY="--add-registry=registry.redhat.io --add-registry=my.registry.example.com --add-registry=docker.io"
    BLOCK_REGISTRY='--block-registry=all'
  6. Docker 서비스를 다시 시작하십시오.

    $ sudo systemctl restart docker
  7. 이제 이미지를 가져올 수 있는지 확인하려면 다음을 수행하십시오.

    $ sudo docker pull docker.io/hello-world
    Using default tag: latest
    Trying to pull repository docker.io/library/hello-world ...
    latest: Pulling from docker.io/library/hello-world
    
    9a0669468bf7: Pull complete
    Digest: sha256:0e06ef5e1945a718b02a8c319e15bae44f47039005530bc617a5d071190ed3fc
  8. 예를 들어 해당 레지스트리를 사용해야 하는 모든 노드 호스트에서 docker 데몬 구성 파일을 수정하기 위해 외부 레지스트리를 사용해야 하는 경우 악성 컨테이너가 실행되지 않도록 해당 노드에 차단 목록을 생성하십시오.

    Ansible 설치 프로그램을 사용하면 Ansible 호스트 파일의 openshift_docker_additional_registriesopenshift_docker_blocked_registries 변수를 사용하여 구성할 수 있습니다.

    openshift_docker_additional_registries=registry.redhat.io,my.registry.example.com
    openshift_docker_blocked_registries=all

7.3.3. 보안 레지스트리

외부 레지스트리에서 이미지를 가져오려면 레지스트리 인증서를 신뢰해야 합니다. 그렇지 않으면 이미지 가져오기 작업이 실패합니다.

그렇게 하려면 외부 레지스트리용 인증 기관 인증서 설치 섹션을 참조하십시오.

허용 목록을 사용하는 경우, 위에서 설명한 대로 외부 레지스트리를 registries 변수에 추가해야 합니다.

7.3.4. 비보안 레지스트리

신뢰할 수 없는 인증서를 사용하거나 인증서가 전혀 없는 외부 레지스트리는 피해야 합니다.

그러나 docker 데몬이 리포지토리에서 이미지를 가져올 수 있도록 --insecure-registry 옵션을 사용하여 비보안 레지스트리를 추가해야 합니다. --add-registry 옵션과 동일하지만 docker 작업이 확인되지 않았습니다.

검색을 활성화하고 차단 목록이 있는 경우 이미지 가져오기와 같은 다른 작업을 수행하려면 두 옵션을 모두 사용하여 레지스트리를 추가해야 합니다.

테스트용으로 localhost 비보안 레지스트리를 추가하는 방법에 관한 예가 표시됩니다.

프로시저
  1. localhost 비보안 레지스트리를 추가하도록 /etc/containers/registries.conf 구성 파일을 수정하십시오.

    [registries.search]
    registries = ['registry.redhat.io', 'my.registry.example.com', 'docker.io', 'localhost:5000' ]
    
    [registries.insecure]
    registries = ['localhost:5000']
    
    [registries.block]
    registries = ['all']
    참고

    비보안으로 표시되고 허용 목록에 포함되도록 registries.search 섹션과 registries.insecure 섹션 둘 다에 비보안 레지스트리를 추가하십시오. registeries.block 섹션에 추가된 레지스트리는 registries.search 섹션에 추가하여 허용 목록에 추가하지 않으면 차단됩니다.

  2. 레지스트리를 사용하려면 docker 데몬을 다시 시작하십시오.

    $ sudo systemctl restart docker.service

    docker 데몬을 다시 시작하면 docker 컨테이너가 다시 시작됩니다.

  3. localhost에서 컨테이너 이미지 레지스트리 포드를 실행하십시오.

    $ sudo docker run -p 5000:5000 registry:2
  4. 이미지를 가져오십시오.

    $ sudo docker pull openshift/hello-openshift
  5. 이미지에 태그를 지정하십시오.

    $ sudo docker tag docker.io/openshift/hello-openshift:latest localhost:5000/hello-openshift-local:latest
  6. 이미지를 로컬 레지스트리로 푸시하십시오.

    $ sudo docker push localhost:5000/hello-openshift-local:latest
  7. Ansible 설치 프로그램을 사용하면 Ansible 호스트 파일의 openshift_docker_additional_registries, openshift_docker_blocked_registriesopenshift_docker_insecure_registries 변수를 사용하여 구성할 수 있습니다.

    openshift_docker_additional_registries=registry.redhat.io,my.registry.example.com,localhost:5000
    openshift_docker_insecure_registries=localhost:5000
    openshift_docker_blocked_registries=all
    참고

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

7.3.5. 인증된 레지스트리

docker와 함께 인증된 레지스트리를 사용하려면 docker 데몬이 레지스트리에 로그인해야 합니다. OpenShift Container Platform에서는 사용자가 호스트에서 docker login 명령을 실행할 수 없으므로 다른 단계 세트를 수행해야 합니다. 인증된 레지스트리를 사용하여 사용자가 가져올 수 있는 이미지 또는 외부 레지스트리에 액세스할 수 대상을 제한할 수 있습니다.

외부 docker 레지스트리에 인증이 필요하면 해당 레지스트리를 사용하는 프로젝트에서 특수 보안을 생성한 다음, 해당 보안을 사용하여 docker 작업을 수행하십시오.

프로시저
  1. 사용자가 docker 레지스트리에 로그인하려는 프로젝트에서 dockercfg 보안을 생성하십시오.

    $ oc project <my_project>
    $ oc create secret docker-registry <my_registry> --docker-server=<my.registry.example.com> --docker-username=<username> --docker-password=<my_password> --docker-email=<me@example.com>
  2. .dockercfg 파일이 있으면 oc 명령을 사용하여 보안을 생성하십시오.

    $ oc create secret generic <my_registry> --from-file=.dockercfg=<path/to/.dockercfg> --type=kubernetes.io/dockercfg
  3. $HOME/.docker/config.json 파일을 채우십시오.

    $ oc create secret generic <my_registry> --from-file=.dockerconfigjson=<path/to/.dockercfg> --type=kubernetes.io/dockerconfigjson
  4. 가져오기 작업을 수행하는 서비스 계정에 보안을 연결하여 인증된 레지스트리에서 이미지를 가져오려면 dockercfg 보안을 사용하십시오. 이미지를 가져오는 기본 서비스 계정의 이름은 default입니다.

    $ oc secrets link default <my_registry> --for=pull
  5. S2I 기능을 사용하여 이미지를 푸시하려면 dockercfg 보안이 S2I 포드에 마운트되므로, 빌드를 수행하는 적절한 서비스 계정에 연결되어야 합니다. 이미지를 작성하는 데 사용되는 기본 서비스 계정의 이름은 builder입니다.

    $ oc secrets link builder <my_registry>
  6. buildconfig에서 푸시 또는 가져오기 작업에 맞게 보안을 지정해야 합니다.

    "type": "Source",
    "sourceStrategy": {
        "from": {
            "kind": "DockerImage",
            "name": "*my.registry.example.com*/myproject/myimage:stable"
        },
        "pullSecret": {
            "name": "*mydockerregistry*"
        },
    ...[OUTPUT ABBREVIATED]...
    "output": {
        "to": {
            "kind": "DockerImage",
            "name": "*my.registry.example.com*/myproject/myimage:latest"
        },
        "pushSecret": {
            "name": "*mydockerregistry*"
        },
    ...[OUTPUT ABBREVIATED]...
  7. 외부 레지스트리가 외부 서비스에 인증을 위임하는 경우, dockercfg 보안, 즉 레지스트리 URL을 사용하는 레지스트리와 고유 URL을 사용하는 외부 인증 시스템을 둘 다 생성하십시오. 두 보안 모두 서비스 계정에 추가해야 합니다.

    $ oc project <my_project>
    $ oc create secret docker-registry <my_registry> --docker-server=*<my_registry_example.com> --docker-username=<username> --docker-password=<my_password> --docker-email=<me@example.com>
    $ oc create secret docker-registry <my_docker_registry_ext_auth> --docker-server=<my.authsystem.example.com> --docker-username=<username> --docker-password=<my_password> --docker-email=<me@example.com>
    $ oc secrets link default <my_registry> --for=pull
    $ oc secrets link default <my_docker_registry_ext_auth> --for=pull
    $ oc secrets link builder <my_registry>
    $ oc secrets link builder <my_docker_registry_ext_auth>

7.3.6. ImagePolicy 승인 플러그인

승인 제어 플러그인은 API에 대한 요청을 가로채고, 구성된 규칙에 따라 확인을 수행하며, 해당 규칙에 따라 특정 조치를 허용하거나 거부합니다. OpenShift Container Platform에서는 다음을 제어할 수 있는 ImagePolicy 승인 플러그인을 사용하여 환경에서 실행되는 허용된 이미지를 제한할 수 있습니다.

  • 이미지 소스: 이미지를 가져오는 데 사용할 수 있는 레지스트리
  • 이미지 해상도: 태그 변경 때문에 이미지가 변경되지 않도록 포드가 불변 다이제스트와 함께 실행되도록 강제 시행
  • 컨테이너 이미지 레이블 제한사항: 이미지에 특정 레이블이 있거나 없도록 강제 시행
  • 이미지 주석 제한사항: 통합 컨테이너 레지스트리의 이미지에 특정 주석이 있거나 없도로 강제 시행
주의

ImagePolicy 승인 플러그인은 현재 베타로 간주됩니다.

프로시저
  1. ImagePolicy 플러그인이 활성화된 경우 모든 마스터 노드에서 /etc/origin/master/master-config.yaml 파일을 수정하여 외부 레지스트리를 사용할 수 있도록 수정해야 합니다.

    admissionConfig:
      pluginConfig:
        openshift.io/ImagePolicy:
          configuration:
            kind: ImagePolicyConfig
            apiVersion: v1
            executionRules:
            - name: allow-images-from-other-registries
              onResources:
              - resource: pods
              - resource: builds
              matchRegistries:
              - docker.io
              - <my.registry.example.com>
              - registry.redhat.io
    참고

    ImagePolicy를 활성화하려면 애플리케이션을 배포할 때 oc new-app kubernetes/guestbook 대신 oc new-app docker.io/kubernetes/guestbook과 같은 레지스트리를 지정해야 합니다. 그렇지 않으면 실패합니다.

  2. 설치 시 승인 플러그인을 활성화하도록 openshift_master_admission_plugin_config 변수를 모든 pluginConfig 구성을 포함하는 json 형식 문자열과 함께 사용할 수 있습니다.

    openshift_master_admission_plugin_config={"openshift.io/ImagePolicy":{"configuration":{"kind":"ImagePolicyConfig","apiVersion":"v1","executionRules":[{"name":"allow-images-from-other-registries","onResources":[{"resource":"pods"},{"resource":"builds"}],"matchRegistries":["docker.io","*my.registry.example.com*","registry.redhat.io"]}]}}}

7.3.7. 외부 레지스트리에서 이미지 가져오기

애플리케이션 개발자는 oc import-image 명령을 사용하여 imagestreams를 생성하도록 이미지를 가져올 수 있으며, 외부 레지스트리에서 이미지 가져오기를 허용하거나 거부하도록 OpenShift Container Platform을 구성할 수 있습니다.

프로시저
  1. 사용자가 이미지를 가져올 수 있는 허용된 레지스트리를 구성하려면 /etc/origin/master/master-config.yaml 파일에 다음을 추가하십시오.

    imagePolicyConfig:
      allowedRegistriesForImport:
      - domainName: docker.io
      - domainName: '\*.docker.io'
      - domainName: '*.redhat.com'
      - domainName: 'my.registry.example.com'
  2. 인증된 외부 레지스트리에서 이미지를 가져오려면 원하는 프로젝트 내에 보안을 생성하십시오.
  3. 권장되지 않더라도, 인증된 외부 레지스트리가 비보안이거나 인증서를 신뢰할 수 없는 경우 --insecure = true 옵션과 함께 oc import-image 명령을 사용할 수 있습니다.

    인증된 외부 레지스트리가 보안인 경우 다음과 같이 레지스트리 가져오기 컨트롤러를 실행할 때 마스터 호스트에서 레지스트리 인증서를 신뢰해야 합니다.

    /etc/pki/ca-trust/source/anchors/의 인증서를 복사하십시오.

    $ sudo cp <my.registry.example.com.crt> /etc/pki/ca-trust/source/anchors/<my.registry.example.com.crt>
  4. update-ca-trust 명령을 실행하십시오.

    $ sudo update-ca-trust
  5. 모든 마스터 호스트에서 마스터 서비스를 다시 시작하십시오.

    $ sudo master-restart api
    $ sudo master-restart controllers
  6. 외부 레지스트리의 인증서는 OpenShift Container Platform 레지스트리에서 신뢰할 수 있어야 합니다.

    $ for i in pem openssl java; do
      oc create configmap ca-trust-extracted-${i} --from-file /etc/pki/ca-trust/extracted/${i}
      oc set volume dc/docker-registry --add -m /etc/pki/ca-trust/extracted/${i} --configmap-name=ca-trust-extracted-${i} --name ca-trust-extracted-${i}
    done
    주의

    현재 레지스트리 포드에 인증서를 추가하는 공식 프로시저는 없지만, 위의 임시 해결 방법을 사용할 수 있습니다.

    이 임시 해결 방법을 수행하면 해당 명령을 실행하는 시스템의 신뢰할 수 있는 모든 인증서로 configmaps를 생성하므로, 필요한 인증서만 신뢰할 수 있는 안전한 시스템에서 실행하는 것이 좋습니다.

  7. 또는 다음과 같이 Dockerfile을 사용하여 이미지를 다시 작성하는 올바른 인증서를 신뢰하도록 레지스트리 이미지를 수정하십시오.

    FROM registry.redhat.io/openshift3/ose-docker-registry:v3.6
    ADD <my.registry.example.com.crt> /etc/pki/ca-trust/source/anchors/
    USER 0
    RUN update-ca-trust extract
    USER 1001
  8. 이미지를 다시 빌드하고 docker 레지스트리에 푸시한 다음, deploymentconfig 레지스트리에서 해당 이미지를 spec.template.spec.containers["name":"registry"].image로 사용하십시오.

    $ oc patch dc docker-registry -p '{"spec":{"template":{"spec":{"containers":[{"name":"registry","image":"*myregistry.example.com/openshift3/ose-docker-registry:latest*"}]}}}}'
참고

설치 시 imagePolicyConfig 구성을 추가하려면 openshift_master_image_policy_config 변수를 다음과 같이 모든 imagePolicyConfig 구성을 포함하는 json 형식 문자열과 함께 사용할 수 있습니다.

openshift_master_image_policy_config={"imagePolicyConfig":{"allowedRegistriesForImport":[{"domainName":"docker.io"},{"domainName":"\*.docker.io"},{"domainName":"*.redhat.com"},{"domainName":"*my.registry.example.com*"}]}}

ImagePolicy에 대한 자세한 정보는 ImagePolicy 승인 플러그인 섹션을 참조하십시오.

7.3.8. OpenShift Container Platform 레지스트리 통합

OpenShift Container Platform을 독립형 컨테이너 이미지 레지스트리로 설치하여 레지스트리 기능만 제공할 수 있지만 OpenShift Container Platform 플랫폼에서 실행하면 장점이 있습니다.

OpenShift Container Platform 레지스트리에 대한 자세한 정보 OpenShift Container Registry 독립형 배포 설치를 참조하십시오.

OpenShift Container Platform 레지스트리를 통합하려면 이전 섹션이 모두 적용됩니다. OpenShift Container Platform의 관점에서는 외부 레지스트리로 취급되지만, 몇 가지 추가 작업을 수행해야 합니다. 왜냐하면 이 레지스트리는 다중 테넌트 레지스트리이고 OpenShift Container Platform의 권한 부여 모델이 적용되므로 새로운 프로젝트를 생성할 때 레지스트리에서 해당 환경에 이 프로젝트를 독립형으로 생성하지 않기 때문입니다.

7.3.8.1. 레지스트리 프로젝트와 클러스터 연결

레지스트리는 레지스트리 포드 및 웹 인터페이스가 있는 전체 OpenShift Container Platform 환경이므로, 레지스트리에서 새 프로젝트를 생성하는 프로세스는 oc new-project 또는 oc create 명령줄을 사용하거나 웹 인터페이스를 통해 수행됩니다.

프로젝트가 생성되면 프로젝트 관리자에게 권한이 부여될 뿐만 아니라 일반 서비스 계정(builder, defaultdeployer)도 자동으로 생성됩니다. "익명" 사용자뿐만 아니라 다른 사용자도 이미지를 푸시하거나 가져올 수 있습니다.

모든 사용자가 레지스트리 내에서 이 새로운 프로젝트의 이미지를 가져오도록 허용하는 것과 같은 몇 가지 사용 사례가 있을 수 있지만, OpenShift Container Platform과 레지스트리 간에 1:1 프로젝트 관계를 유지하려는 경우 사용자가 해당 특정 프로젝트에서 이미지를 푸시하고 가져올 수 있으므로 몇 가지 단계가 필요합니다.

주의

레지스트리 웹 콘솔에는 가져오기/푸시 작업에 사용할 토큰이 표시되지만, 토큰에서 세션 토큰이 있음을 나타내므로 만료됩니다. 특정 권한이 있는 서비스 계정을 생성하면 관리자가 서비스 계정의 권한을 제한할 수 있으므로, 예를 들어 이미지 푸시 또는 가져오기에 다른 서비스 계정을 사용할 수 있습니다. 그러면 서비스 계정 토큰이 만료되지 않으므로 사용자는 토큰 만료, 보안 재생성 및 기타 작업을 구성할 필요가 없습니다.

프로시저
  1. 새 프로젝트를 생성하십시오.

    $ oc new-project <my_project>
  2. 레지스트리 프로젝트를 생성하십시오.

    $ oc new-project <registry_project>
  3. 레지스트리 프로젝트에서 서비스 계정을 생성하십시오.

    $ oc create serviceaccount <my_serviceaccount> -n <registry_project>
  4. 레지스트리 편집기 역할을 사용하여 이미지를 푸시하고 가져오는 권한을 부여하십시오.

    $ oc adm policy add-role-to-user registry-editor -z <my_serviceaccount> -n <registry_project>

    가져오기 권한만 필요한 경우 registry-viewer 역할을 사용할 수 있습니다.

  5. 서비스 계정 토큰을 얻으십시오.

    $ TOKEN=$(oc sa get-token <my_serviceaccount> -n <registry_project>)
  6. dockercfg 보안을 생성하려면 토큰을 비밀번호로 사용하십시오.

    $ oc create secret docker-registry <my_registry> \
      --docker-server=<myregistry.example.com> --docker-username=<notused> --docker-password=${TOKEN} --docker-email=<me@example.com>
  7. 가져오기 작업을 수행하는 서비스 계정에 보안을 연결하여 레지스트리에서 이미지를 가져오려면 dockercfg 보안을 사용하십시오. 이미지를 가져오는 기본 서비스 계정의 이름은 default입니다.

    $ oc secrets link default <my_registry> --for=pull
  8. S2I 기능을 사용하여 이미지를 푸시하려면 dockercfg 보안이 S2I 포드에 마운트되므로, 빌드를 수행하는 적절한 서비스 계정에 연결되어야 합니다. 이미지를 작성하는 데 사용되는 기본 서비스 계정의 이름은 builder입니다.

    $ oc secrets link builder <my_registry>
  9. buildconfig에서 푸시 또는 가져오기 작업에 맞게 보안을 지정해야 합니다.

    "type": "Source",
    "sourceStrategy": {
        "from": {
            "kind": "DockerImage",
            "name": "<myregistry.example.com/registry_project/my_image:stable>"
        },
        "pullSecret": {
            "name": "<my_registry>"
        },
    ...[OUTPUT ABBREVIATED]...
    "output": {
        "to": {
            "kind": "DockerImage",
            "name": "<myregistry.example.com/registry_project/my_image:latest>"
        },
        "pushSecret": {
            "name": "<my_registry>"
        },
    ...[OUTPUT ABBREVIATED]...

8장. 인증서 관리

OpenShift Container Platform 클러스터의 라이프사이클 동안 인증서는 라이프사이클의 다양한 단계를 거칩니다. 다음 프로시저에서는 해당 라이프사이클의 다양한 부분을 관리하는 방법을 설명합니다.

인증서 말료를 보고 인증서를 다시 배포하는 데 대한 정보는 인증서 재배포를 참조하십시오.

8.1. 애플리케이션의 자체 서명 인증서를 CA 서명 인증서로 변경

일부 애플리케이션 템플릿에서는 자체 서명된 인증서를 생성합니다. 그런 다음 애플리케이션에서 클라이언트에 직접 제공합니다. 예를 들어 기본적으로 OpenShift Container Platform Ansible 설치 프로그램 배포 프로세스의 일부로 메트릭 배포자가 자체 서명된 인증서를 생성합니다.

이러한 자체 서명된 인증서는 브라우저에서 인식되지 않습니다. 이 문제를 완화하려면 공개적으로 서명된 인증서를 사용한 다음 자체 서명된 인증서로 트래픽을 다시 암호화하도록 구성하십시오.

  1. 기존 경로를 삭제하십시오.

    $ oc delete route hawkular-metrics -n openshift-infra

    경로를 삭제한 상태에서, 재암호화 전략을 사용하여 새 경로에 사용될 인증서는 메트릭 배포자가 생성한 기존 와일드카드 및 자체 서명 인증서에서 어셈블해야 합니다. 다음 인증서를 사용할 수 있어야 합니다.

    • 와일드카드 CA 인증서
    • 와일드카드 개인 키
    • 와일드카드 인증서
    • Hawkular CA 인증서

      각 인증서는 파일 시스템에서 새 경로의 파일로 사용 가능해야 합니다.

      다음 명령을 실행하여 Hawkular CA를 검색하고 파일에 저장할 수 있습니다.

      $ oc get secrets hawkular-metrics-certs \
          -n openshift-infra \
          -o jsonpath='{.data.ca\.crt}' | base64 \
          -d > hawkular-internal-ca.crt
  2. 와일드카드 개인 키, 인증서 및 CA 인증서를 찾으십시오. wildcard.key, wildcard.crtwildcard.ca와 같은 개별 파일에 각각을 배치하십시오.
  3. 새로운 재암호화 경로를 생성하십시오.

    $ oc create route reencrypt hawkular-metrics-reencrypt \
        -n openshift-infra \
        --hostname hawkular-metrics.ocp.example.com \
        --key wildcard.key \
        --cert wildcard.crt \
        --ca-cert wildcard.ca \
        --service hawkular-metrics \
        --dest-ca-cert hawkular-internal-ca.crt

법적 공지

저작권 © 2018 Red Hat, Inc.
이 문서의 텍스트와 그림은 Creative Commons Attribution-Share Alike 3.0 Unported 라이센스("CC-BY-SA")에 따라 Red Hat에서 라이센스를 부여합니다. CC-BY-SA에 대한 설명은 다음에 있습니다. http://creativecommons.org/licenses/by-sa/3.0/. CC-BY-SA에 따라 이 문서 또는 해당 문서의 수정본을 배포할 경우 원본 버전의 URL을 제공해야 합니다. 수정된 버전에서는 모든 Red Hat 상표를 제거해야 합니다.
Red Hat은 이 문서의 라이센스 제공자로서 관련 법률이 허용하는 한도 내에서 CC-BY-SA의 섹션 4d를 시행할 권리를 포기하며 이를 주장하지 않을 것에 동의합니다.
수정 부분 https://github.com/kubernetes-incubator/service-catalog/ Red Hat에서 수정했습니다. 다음을 통해 라이센스가 부여됩니다. Apache License 2.0.
Red Hat, Red Hat Enterprise Linux, Shadowman 로고, JBoss, OpenShift, Fedora, Infinity 로고 및 RHCE는 미국 및 기타 국가에 등록된 Red Hat, Inc.의 상표입니다.
Linux는® 미국 및 기타 국가에 등록된 Linus Torvalds의 등록 상표입니다.
Java는® Oracle 및/또는 그 계열사의 등록 상표입니다.
XFS는® 미국 및/또는 기타 국가에 등록된 Silicon Graphics International Corp. 또는 그 자회사의 상표입니다.
MySQL은® 미국, 유럽 연합 및 기타 국가에서 사용되는 MySQL AB의 등록 상표입니다.
Node.js는® Joyent의 공식 상표입니다. Red Hat Software Collections는 공식 Joyent Node.js 오픈 소스 또는 상용 프로젝트에서 공식적으로 보증하거나 관련되어 있지 않습니다.
OpenStack Word Mark® 및 OpenStack 로고는 미국 및 기타 국가에서 사용되는 OpenStack Foundation의 등록 상표/서비스표 또는 상표/서비스표이며 OpenStack Foundation의 허가를 받아 사용됩니다. OpenStack Foundation 또는 OpenStack 커뮤니티와 제휴, 보증 또는 후원하지 않습니다.
다른 모든 상표는 해당 소유자의 자산입니다.