클러스터 구성

OpenShift Container Platform은 소스 코드에서 컨테이너 이미지를 빌드하고 배포하며 라이프사이클을 관리할 수 있습니다. 이를 활성화하기 위해 OpenShift Container Platform은 OpenShift Container Platform 환경에 배포하여 이미지를 로컬로 관리할 수 있는 내부 통합 컨테이너 이미지 레지스트리 를 제공합니다.

전체 OpenShift Container Platform 클러스터를 처음 설치하는 동안 설치 프로세스 중에 레지스트리가 자동으로 배포되었을 수 있습니다. 레지스트리 구성이 없거나 레지스트리 구성을 추가로 사용자 지정하려면 기존 클러스터에 레지스트리 배포를 참조하십시오.

전체 OpenShift Container Platform 클러스터의 통합 일부로 실행하도록 배포할 수는 있지만 OpenShift Container Platform 레지스트리는 독립 실행형 컨테이너 이미지 레지스트리로 별도로 설치할 수 있습니다.

독립 실행형 레지스트리를 설치하려면 독립 실행형 레지스트리 설치를 따르십시오. 이 설치 경로는 레지스트리와 특수 웹 콘솔을 실행하는 올인원 클러스터를 배포합니다.

OpenShift Container Platform 클러스터를 처음 설치하는 동안 통합 레지스트리가 자동으로 배포되지 않았거나 더 이상 성공적으로 실행되지 않고 기존 클러스터에 다시 배포해야 하는 경우 다음 섹션을 참조하십시오.

레지스트리가 내부 및 외부 참조 모두에 대해 로 알려진 호스트 이름과 포트를 구성할 수 있습니다. 이렇게 하면 이미지 스트림은 이미지의 호스트 이름 기반 푸시 및 가져오기 사양을 제공하므로, 이미지 소비자가 레지스트리 서비스 IP의 변경 사항과 이미지 스트림과 참조를 이식할 수 있습니다.

클러스터 내에서 레지스트리를 참조하는 데 사용되는 호스트 이름을 설정하려면 마스터 구성 파일의 imagePolicyConfig 섹션에 internalRegistryHostname 을 설정합니다. 외부 호스트 이름은 동일한 위치에 externalRegistryHostname 값을 설정하여 제어됩니다.

imagePolicyConfig:
  internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
  externalRegistryHostname: docker-registry.mycompany.com

레지스트리 자체는 동일한 내부 호스트 이름 값으로 구성해야 합니다. 이 작업은 레지스트리 배포 구성에서 REGISTRY_OPENSHIFT_SERVER_ADDR 환경 변수를 설정하거나 레지스트리 구성의 OpenShift 섹션에서 값을 설정하여 수행할 수 있습니다.

통합 컨테이너 이미지 레지스트리를 배포하려면 클러스터 관리자 권한이 있는 사용자로 oc adm registry 명령을 사용합니다. 예를 들면 다음과 같습니다.

$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \1
    --service-account=registry \2
    --images='registry.redhat.io/openshift3/ose-${component}:${version}' 3

그러면 docker-registry 라는 서비스와 배포 구성이 생성됩니다. 성공적으로 배포되면 docker-registry-1-cpty9 와 유사한 이름으로 포드가 생성됩니다.

레지스트리 생성 시 지정할 수 있는 전체 옵션 목록을 보려면 다음을 수행합니다.

$ oc adm registry --help

--fs-group 의 값은 레지스트리에서 사용하는 SCC에서 허용해야 합니다(일반적으로 restricted SCC).

oc adm registry 명령을 사용하여 --daemonset 옵션을 사용하여 레지스트리를 DaemonSet 으로 배포합니다.

DaemonSet은 노드가 생성될 때 지정된 Pod 복사본이 포함되어 있는지 확인합니다. 노드를 제거하면 Pod가 가비지 수집됩니다.

DaemonSet에 대한 자세한 내용은 Daemonsets 사용을 참조하십시오.

기본적으로 레지스트리는 컴퓨팅 리소스 요청 또는 제한에 대한 설정 없이 생성됩니다. 프로덕션의 경우 레지스트리의 배포 구성을 업데이트하여 레지스트리의 리소스 요청 및 제한을 설정하는 것이 좋습니다. 그렇지 않으면 레지스트리 포드가 BestEffort 포드 로 간주됩니다.

요청 및 제한 구성에 대한 자세한 내용은 Compute Resources 를 참조하십시오.

레지스트리는 컨테이너 이미지와 메타데이터를 저장합니다. 레지스트리를 사용하여 포드를 배포하면 Pod가 종료되면 삭제된 임시 볼륨을 사용합니다. 누구나 레지스트리로 빌드 또는 푸시한 이미지가 사라집니다.

이 섹션에는 지원되는 레지스트리 스토리지 드라이버가 나열되어 있습니다. 자세한 내용은 컨테이너 이미지 레지스트리 설명서를 참조하십시오.

다음 목록에는 레지스트리의 구성 파일에서 구성해야 하는 스토리지 드라이버가 포함되어 있습니다.

일반 레지스트리 스토리지 구성 옵션이 지원됩니다. 자세한 내용은 컨테이너 이미지 레지스트리 설명서를 참조하십시오.

다음 스토리지 옵션은 파일 시스템 드라이버를 통해 구성해야 합니다.

$ oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
     --claim-name=<pvc_name> --overwrite

storage:
  cache:
    layerinfo: inmemory
  delete:
    enabled: true
  s3:
    accesskey: awsaccesskey 1
    secretkey: awssecretkey 2
    region: us-west-1
    regionendpoint: http://myobjects.local
    bucket: bucketname
    encrypt: true
    keyid: mykeyid
    secure: true
    v4auth: false
    chunksize: 5242880
    rootdirectory: /s3/object/name/prefix

$ oc adm registry --service-account=registry \
    --config=/etc/origin/master/admin.kubeconfig \
    --images='registry.redhat.io/openshift3/ose-${component}:${version}' \ 1
    --mount-host=<path>

$ sudo chown 1001:root <path>

OpenShift Container Platform은 통합 레지스트리에 웹 기반 인터페이스를 제공합니다. 이 레지스트리 콘솔은 이미지 검색 및 관리를 위한 선택적 구성 요소입니다. 포드로 실행되는 상태 비저장 서비스로 배포됩니다.

$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper

컨테이너 이미지 레지스트리의 로그를 보려면 배포 구성과 함께 oc logs 명령을 사용합니다.

$ oc logs dc/docker-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

태그 및 이미지 메타데이터는 OpenShift Container Platform에 저장되지만 레지스트리는 /registry 의 레지스트리 컨테이너에 마운트된 볼륨에 계층 및 서명 데이터를 저장합니다. oc exec 는 권한 있는 컨테이너에서 작동하지 않으므로 레지스트리의 콘텐츠를 보려면 레지스트리 Pod의 컨테이너에 수동으로 SSH를 적용한 다음 컨테이너 자체에서 docker exec 를 실행해야 합니다.

고급 용도의 경우 레지스트리에 직접 액세스하여 docker 명령을 호출할 수 있습니다. 이를 통해 docker push 또는 docker pull과 같은 작업을 사용하여 통합 레지스트리에서 이미지를 직접 푸시 하거나 가져올 수 있습니다. 이렇게 하려면 docker login 명령을 사용하여 레지스트리에 로그인해야 합니다. 수행할 수있는 작업은 다음 섹션에 설명된대로 사용자 권한에 따라 달라집니다.

OpenShift Container 레지스트리는 Prometheus 메트릭에 대한 엔드 포인트를 제공합니다. Prometheus는 독립형 오픈 소스 시스템 모니터링 및 경고 툴킷입니다.

메트릭은 레지스트리 엔드 포인트의 /extensions/v2/metrics 경로에 표시됩니다. 그러나 이 경로를 먼저 활성화해야 합니다. 자세한 내용은 확장 레지스트리 구성을 참조하십시오.

다음은 지표 쿼리의 간단한 예입니다.

$ curl -s -u <user>:<secret> \ 1
    http://172.30.30.30:5000/extensions/v2/metrics | grep openshift | head -n 10

# HELP openshift_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which OpenShift was built.
# TYPE openshift_build_info gauge
openshift_build_info{gitCommit="67275e1",gitVersion="v3.6.0-alpha.1+67275e1-803",major="3",minor="6+"} 1
# HELP openshift_registry_request_duration_seconds Request latency summary in microseconds for each operation
# TYPE openshift_registry_request_duration_seconds summary
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.5"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.9"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.99"} 0
openshift_registry_request_duration_seconds_sum{name="test/origin-pod",operation="blobstore.create"} 0
openshift_registry_request_duration_seconds_count{name="test/origin-pod",operation="blobstore.create"} 5

지표에 액세스하는 또 다른 방법은 클러스터 역할을 사용하는 것입니다. 끝점을 활성화해야 하지만 <secret> 을 지정할 필요가 없습니다. 메트릭을 담당하는 구성 파일의 일부는 다음과 같아야합니다.

openshift:
  version: 1.0
  metrics:
    enabled: true
...

메트릭에 액세스할 클러스터 역할이 아직 없는 경우 클러스터 역할을 생성해야 합니다.

$ cat <<EOF |
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-scraper
rules:
- apiGroups:
  - image.openshift.io
  resources:
  - registry/metrics
  verbs:
  - get
EOF
oc create -f -

이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>

고급 쿼리 및 권장 시각화 프로그램은 업스트림 Prometheus 설명서 를 참조하십시오.

기본적으로 OpenShift Container Platform 레지스트리는 TLS를 통해 트래픽을 제공하도록 클러스터 설치 중에 보호됩니다. 또한 서비스를 외부에 노출하기 위해 기본적으로 패스스루 경로가 생성됩니다.

어떠한 이유로 레지스트리가 보안 또는 노출되지 않은 경우 수동으로 이렇게 하는 방법에 대한 단계는 다음 섹션을 참조하십시오.

TLS를 통해 트래픽을 제공하도록 레지스트리를 수동으로 보호하려면 다음을 수행합니다.

OpenShift Container Platform 클러스터 내에서 OpenShift Container Platform 레지스트리에 로그인하는 대신 먼저 레지스트리를 보안한 다음 경로로 노출하여 외부에서 액세스할 수 있습니다. 이를 통해 라우팅 주소를 사용하여 클러스터 외부에서 레지스트리에 로그인하고 라우팅 호스트를 사용하여 이미지에 태그를 지정하거나 푸시할 수 있습니다.

레지스트리를 공개하기 위해 레지스트리를 보호하는 대신 비 프로덕션 OpenShift Container Platform 환경에 비보안 레지스트리를 노출하면 됩니다. 이를 통해 SSL 인증서를 사용하지 않고 레지스트리에 대한 외부 경로를 보유할 수 있습니다.

비보안 레지스트리를 공개하려면 다음을 수행합니다.

비보안 및 노출된 레지스트리에 로그인할 때 docker login 명령에서 레지스트리를 지정해야 합니다. 예를 들면 다음과 같습니다.

# docker login -e user@company.com \
    -u f83j5h6 \
    -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
    <host>

OpenShift Container Platform은 서비스 IP 주소로 통합 레지스트리를 참조하므로 docker-registry 서비스를 삭제하고 다시 생성하는 경우 새 서비스에서 이전 IP 주소를 다시 사용하도록 정렬하여 완전히 투명한 전환을 보장할 수 있습니다. 새 IP 주소를 방지할 수 없는 경우 마스터만 재부팅하여 클러스터 중단을 최소화할 수 있습니다.

# master-restart api
# master-restart controllers

이렇게 하면 이전 IP 주소를 포함하는 이전 레지스트리 URL이 캐시에서 지워집니다.

/etc/containers/registries.conf 파일을 사용하여 컨테이너 이미지를 검색할 Docker 레지스트리 목록을 생성할 수 있습니다.

/etc/containers/registries.conf 파일은 사용자가 myimage:latest 와 같은 이미지 단축 이름을 사용하여 이미지를 가져올 때 OpenShift Container Platform에서 검색해야 하는 레지스트리 서버 목록입니다. 검색 순서를 사용자 지정하고, 보안 및 비보안 레지스트리를 지정하고, 차단된 레지스트리 목록을 정의할 수 있습니다. OpenShift Container Platform은 차단된 목록의 레지스트리를 검색하거나 가져올 수 없습니다.

예를 들어 사용자가 myimage:latest 이미지를 가져오려는 경우 OpenShift Container Platform은 myimage:latest 를 찾을 때까지 목록에 표시되는 순서대로 레지스트리를 검색합니다.

레지스트리 검색 목록을 사용하면 OpenShift Container Platform 사용자가 다운로드할 수 있는 이미지 및 템플릿 세트를 큐레이션할 수 있습니다. 이러한 이미지를 하나 이상의 Docker 레지스트리에 배치하고 레지스트리를 목록에 추가한 다음 해당 이미지를 클러스터로 가져올 수 있습니다.

레지스트리 검색 목록을 구성하려면 다음을 수행합니다.

레지스트리가 내부 및 외부 참조 모두에 대해 로 알려진 호스트 이름과 포트를 구성할 수 있습니다. 이렇게 하면 이미지 스트림은 이미지의 호스트 이름 기반 푸시 및 가져오기 사양을 제공하므로, 이미지 소비자가 레지스트리 서비스 IP의 변경 사항과 이미지 스트림과 참조를 이식할 수 있습니다.

클러스터 내에서 레지스트리를 참조하는 데 사용되는 호스트 이름을 설정하려면 마스터 구성 파일의 imagePolicyConfig 섹션에 internalRegistryHostname 을 설정합니다. 외부 호스트 이름은 동일한 위치에 externalRegistryHostname 값을 설정하여 제어됩니다.

imagePolicyConfig:
  internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
  externalRegistryHostname: docker-registry.mycompany.com

레지스트리 자체는 동일한 내부 호스트 이름 값으로 구성해야 합니다. 이 작업은 레지스트리 배포 구성에서 REGISTRY_OPENSHIFT_SERVER_ADDR 환경 변수를 설정하거나 레지스트리 구성의 OpenShift 섹션에서 값을 설정하여 수행할 수 있습니다.

실행 중인 레지스트리 컨테이너의 /config.yml 에 기본적으로 있는 통합 레지스트리의 기본 구성을 자체 사용자 지정 구성으로 재정의할 수 있습니다.

레지스트리 구성 파일의 관리를 직접 활성화하고 ConfigMap 을 사용하여 업데이트된 구성을 배포하려면 다음을 수행합니다.

이 작업은 원하는 구성을 수행하기 위해 반복 프로세스로 수행할 수 있습니다. 예를 들어 문제를 해결하는 동안 구성이 일시적으로 업데이트되어 디버그 모드가 될 수 있습니다.

기존 구성을 업데이트하려면 다음을 수행합니다.

업스트림 Docker 배포 라이브러리에는 다양한 구성 옵션을 사용할 수 있습니다. 일부 구성 옵션이 지원되거나 활성화되지는 않습니다. 레지스트리 구성을 재정의할 때 이 섹션을 참조로 사용합니다.

log:
  level: debug
  formatter: text
  fields:
    service: registry
    environment: staging

storage:
  delete:
    enabled: true 1
  redirect:
    disable: false
  cache:
    blobdescriptor: inmemory
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
    readonly:
      enabled: false

auth:
  openshift:
    realm: openshift

middleware:
  registry:
    - name: openshift 1
  repository:
    - name: openshift 2
      options:
        acceptschema2: true 3
        pullthrough: true 4
        mirrorpullthrough: true 5
        enforcequota: false 6
        projectcachettl: 1m 7
        blobrepositorycachettl: 10m 8
  storage:
    - name: openshift 9

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3:
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    bucket: docker.myregistry.com
    region: eu-west-3
    regionendpoint: https://s3.eu-west-3.amazonaws.com
 auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: openshift

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3: 1
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    region: us-east-1
    bucket: docker.myregistry.com
auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: cloudfront 2
      options:
        baseurl: https://jrpbyn0k5k88bi.cloudfront.net/ 3
        privatekey: /etc/docker/cloudfront-ABCEDFGHIJKLMNOPQRST.pem 4
        keypairid: ABCEDFGHIJKLMNOPQRST 5
    - name: openshift

middleware:
  repository:
    - name: openshift
      options:
        acceptschema2: true 1
        pullthrough: true 2
        mirrorpullthrough: true 3
        enforcequota: false 4
        projectcachettl: 1m 5
        blobrepositorycachettl: 10m 6

$ oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
  xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
  http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}

openshift:
  version: 1.0 1
  server:
    addr: docker-registry.default.svc 2
  metrics:
    enabled: false 3
    secret: <secret> 4
  requests:
    read:
      maxrunning: 10 5
      maxinqueue: 10 6
      maxwaitinqueue 2m 7
    write:
      maxrunning: 10 8
      maxinqueue: 10 9
      maxwaitinqueue 2m 10

http:
  addr: :5000
  tls:
    certificate: /etc/secrets/registry.crt
    key: /etc/secrets/registry.key

notifications:
  endpoints:
    - name: registry
      disabled: false
      url: https://url:port/path
      headers:
        Accept:
          - text/plain
      timeout: 500
      threshold: 5
      backoff: 1000

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: "" 1
openshift:
  version: 1.0
  cache:
    disabled: true 2
    blobrepositoryttl: 10m

다음은 통합 레지스트리를 배포하거나 사용할 때 알려진 문제입니다.

로컬 docker-registry 배포에서는 추가 로드를 사용합니다. 기본적으로 registry.redhat.io 의 콘텐츠를 캐시합니다. STI 빌드용 registry.redhat.io 의 이미지가 로컬 레지스트리에 저장됩니다. 로컬 docker-registry 에서 가져오기를 시도합니다. 결과적으로 극도의 동시 빌드로 인해 가져오기에 대한 시간 초과가 발생하고 빌드가 실패할 수 있는 상황이 있습니다. 문제를 완화하려면 docker-registry 배포를 둘 이상의 복제본으로 스케일링합니다. 빌더 Pod의 로그에서 시간 초과를 확인합니다.

공유 NFS 볼륨과 함께 확장된 레지스트리를 사용하는 경우 이미지를 푸시하는 동안 다음 오류 중 하나가 표시될 수 있습니다.

이러한 오류는 Docker에서 이미지를 푸시하려고 할 때 내부 레지스트리 서비스에서 반환됩니다. 이러한 원인은 노드에서 파일 속성의 동기화에서 발생합니다. NFS 클라이언트 측 캐싱, 네트워크 대기 시간 및 계층 크기와 같은 요인은 모두 기본 라운드 로빈 로드 밸런싱 구성을 사용하여 이미지를 푸시할 때 발생할 수 있는 잠재적인 오류에 기여할 수 있습니다.

다음 단계를 수행하여 이러한 실패 가능성을 최소화할 수 있습니다.

이 오류는 가져온 이미지를 가져오는 이미지 스트림과 다른 이미지 스트림으로 푸시할 때 발생합니다. 이는 빌드된 이미지를 임의의 이미지 스트림으로 다시 태그하기 때문에 발생합니다.

$ oc tag srcimagestream:latest anyproject/pullimagestream:latest

internal.registry.url:5000/anyproject/pullimagestream:latest

수동 Docker 가져오기 동안 유사한 오류가 발생합니다.

Error: image anyproject/pullimagestream:latest not found

이 문제를 방지하려면 내부 관리 이미지의 태그 지정을 완전히 방지하거나 빌드된 이미지를 원하는 네임스페이스에 수동으로 다시 푸시합니다.

레지스트리가 S3 스토리지 백엔드에서 실행될 때 보고되는 문제가 있습니다. 컨테이너 이미지 레지스트리로 푸시하는 데 다음 오류가 발생하는 경우가 있습니다.

Received unexpected HTTP status: 500 Internal Server Error

이 문제를 디버깅하려면 레지스트리 로그를 확인해야 합니다. 여기에서 실패한 푸시 시 발생하는 유사한 오류 메시지를 찾습니다.

time="2016-03-30T15:01:21.22287816-04:00" level=error msg="unknown error completing upload: driver.Error{DriverName:\"s3\", Enclosed:(*url.Error)(0xc20901cea0)}" http.request.method=PUT
...
time="2016-03-30T15:01:21.493067808-04:00" level=error msg="response completed with error" err.code=UNKNOWN err.detail="s3: Put https://s3.amazonaws.com/oso-tsi-docker/registry/docker/registry/v2/blobs/sha256/ab/abe5af443833d60cf672e2ac57589410dddec060ed725d3e676f1865af63d2e2/data: EOF" err.message="unknown error" http.request.method=PUT
...
time="2016-04-02T07:01:46.056520049-04:00" level=error msg="error putting into main store: s3: The request signature we calculated does not match the signature you provided. Check your key and signing method." http.request.method=PUT
atest

이러한 오류가 표시되면 Amazon S3 지원에 문의하십시오. 지역이나 특정 버킷에 문제가 있을 수 있습니다.

이미지를 정리할 때 다음 오류가 발생하면 다음을 수행합니다.

BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob

레지스트리 로그에 는 다음 정보가 포함되어 있습니다.

error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported

즉, 사용자 지정 구성 파일에는 storage 섹션에 필수 항목, 즉 storage:delete:enabled 가 true로 설정되어 있지 않습니다. 이미지를 추가하고 레지스트리를 다시 배포한 다음 이미지 정리 작업을 반복합니다.

클러스터로 트래픽을 가져오는 방법은 여러 가지가 있습니다. 가장 일반적인 방법은 OpenShift Container Platform 라우터 를 OpenShift Container Platform 설치의 서비스로 향하는 외부 트래픽의 진입 지점으로 사용하는 것입니다.

OpenShift Container Platform은 다음 라우터 플러그인을 제공하고 지원합니다.

OpenShift Container Platform 클러스터를 배포하기 전에 클러스터 설치 중에 자동으로 생성되는 라우터의 서비스 계정이 있어야 합니다. 이 서비스 계정에는 호스트 포트를 지정할 수 있는 SCC( 보안 컨텍스트 제약 조건)에 대한 권한이 있습니다.

$ oc adm policy add-cluster-role-to-user \
    cluster-reader \
    system:serviceaccount:default:router

oc adm router 명령은 새 설치에서 라우터를 설정하는 작업을 간소화하기 위해 관리자 CLI와 함께 제공됩니다. oc adm router 명령은 서비스 및 배포 구성 오브젝트를 만듭니다. service -account 옵션을 사용하여 라우터가 마스터에 연결하는 데 사용할 서비스 계정을 지정합니다.

라우터 서비스 계정은 사전에 생성하거나 oc adm router --service-account 명령으로 만들 수 있습니다.

OpenShift Container Platform 구성 요소 간 모든 형식의 통신은 TLS에 의해 보호되며 다양한 인증서 및 인증 방법을 사용합니다. default -certificate .pem 형식 파일을 제공하거나 oc adm router 명령으로 파일을 생성할 수 있습니다. 경로가 생성되면 사용자는 라우터가 경로를 처리할 때 사용할 경로 인증서를 제공할 수 있습니다.

라우터는 특정 노드에 배포됩니다. 따라서 클러스터 관리자와 외부 네트워크 관리자가 라우터를 실행할 IP 주소와 라우터에서 처리할 트래픽을 보다 쉽게 조정할 수 있습니다. 라우터는 노드 선택기를 사용하여 특정 노드에 배포됩니다.

$ oc adm router --dry-run --service-account=router 1

라우터가 없는 경우 다음을 실행하여 라우터를 생성합니다.

$ oc adm router <router_name> --replicas=<number> --service-account=router --extended-logging=true

고가용성 구성이 생성되지 않는 한 --replicas 는 일반적으로 1 입니다.

--extended-logging=true 는 HAProxy에서 생성한 로그를 syslog 컨테이너로 전달하도록 라우터를 구성합니다.

라우터의 호스트 IP 주소를 찾으려면 다음을 수행합니다.

$ oc get po <router-pod>  --template={{.status.hostIP}}

라우터 shard를 사용하여 라우터가 특정 네임스페이스 또는 경로로 필터링되었는지 확인하거나 라우터 생성 후 환경 변수를 설정할 수도 있습니다. 이 경우 각 shard에 대한 라우터를 생성합니다.

$ oc adm router --dry-run --service-account=router

$ oc adm router --dry-run -o yaml --service-account=router

$ oc adm router --extended-logging=true

다음 예제는 --extended-logging=true 를 사용하는 라우터의 구성입니다.

$ oc get pod router-1-xhdb9 -o yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - env:

    ....

    - name: ROUTER_SYSLOG_ADDRESS 1
      value: /var/lib/rsyslog/rsyslog.sock

    ....

 - command: 2
   - /sbin/rsyslogd
   - -n
   - -i
   - /tmp/rsyslog.pid
   - -f
   - /etc/rsyslog/rsyslog.conf
   image: registry.redhat.io/openshift3/ose-haproxy-router:v3.11.188
   imagePullPolicy: IfNotPresent
   name: syslog

다음 명령을 사용하여 HAProxy 로그를 확인합니다.

$ oc set env dc/test-router ROUTER_LOG_LEVEL=info 1
$ oc logs -f <pod-name> -c syslog 2

HAProxy 로그는 다음 형식을 취합니다.

2020-04-14T03:05:36.629527+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.627] fe_no_sni~ be_secure:openshift-console:console/pod:console-b475748cb-t6qkq:console:10.128.0.5:8443 0/0/1/1/2 200 393 - - --NI 2/1/0/1/0 0/0 "HEAD / HTTP/1.1"
2020-04-14T03:05:36.633024+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.528] public_ssl be_no_sni/fe_no_sni 95/1/104 2793 -- 1/1/0/0/0 0/0

$ oc adm router <router_name> --replicas=<number> --selector=<label> \
    --service-account=router

예를 들어 router 이라는 라우터를 생성하고 node-role.kubernetes.io/infra=true로 레이블이 지정된 노드에 배치하려면 다음을 수행합니다.

$ oc adm router router --replicas=1 --selector='node-role.kubernetes.io/infra=true' \
  --service-account=router

클러스터 설치 중에 openshift_router_selector 및 openshift_registry_selector Ansible 설정은 기본적으로 node-role.kubernetes.io/infra=true 로 설정됩니다. 기본 라우터 및 레지스트리는 노드가 node-role.kubernetes.io/infra=true 레이블과 일치하는 경우에만 자동으로 배포됩니다.

라벨 업데이트에 대한 자세한 내용은 노드에서 라벨 업데이트를 참조하십시오.

스케줄러 정책에 따라 여러 개의 인스턴스가 여러 호스트에서 생성됩니다.

$ oc adm router <router_name> -o <format> --images=<image> \
    --service-account=router

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

$ oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
    --service-account=router

ROUTE_LABELS 환경 변수를 사용하면 특정 라우터에서만 사용하도록 경로를 필터링할 수 있습니다.

예를 들어 여러 라우터와 100개의 경로가 있는 경우 레이블을 경로에 연결하여 한 라우터에서 이를 처리하도록 하는 반면 나머지는 다른 라우터에서 처리할 수 있습니다.

라우터가 생성되면 --max-connections= 옵션은 원하는 제한을 설정합니다.

$ oc adm router --max-connections=10000   ....

라우터의 배포 구성에서 ROUTER_MAX_CONNECTIONS 환경 변수를 편집하여 값을 변경합니다. 라우터 포드는 새 값으로 다시 시작됩니다. ROUTER_MAX_CONNECTIONS 가 없으면 기본값 20000이 사용됩니다.

HAProxy S tric-sni 는 라우터 배포 구성의 ROUTER_STRICT_SNI 환경 변수를 통해 제어할 수 있습니다. 또한 --strict-sni 명령줄 옵션을 사용하여 라우터를 만들 때 설정할 수 있습니다.

$ oc adm router --strict-sni

라우터를 만들 때 --ciphers 옵션을 사용하여 라우터 암호화 제품군 을 설정합니다.

$ oc adm router --ciphers=modern   ....

값은 modern,intermediate 또는 old 이며 기본값은 intermediate 입니다. 또는 ":"로 구분된 암호 집합을 제공할 수 있습니다. 암호는 다음을 통해 표시되는 세트의 암호여야 합니다.

$ openssl ciphers

또는 기존 라우터에 ROUTER_CIPHERS 환경 변수를 사용합니다.

라우터 및 백엔드 서비스에 대한 클라이언트 액세스는 상호 TLS 인증을 사용하여 제한할 수 있습니다. 라우터는 인증된 세트에 없는 클라이언트의 요청을 거부합니다. 상호 TLS 인증은 클라이언트 인증서에 구현되며 인증서를 발급한 CA(인증 기관), 인증서 폐기 목록 및/또는 모든 인증 대상 필터를 기반으로 제어할 수 있습니다. 라우터를 생성할 때 상호 tls 구성 옵션 -- mutual-tls-auth,--mutual-tls-auth-ca, -- mutual-tls-auth-filter 를 사용합니다.

$ oc adm router --mutual-tls-auth=required  \
                --mutual-tls-auth-ca=/local/path/to/cacerts.pem   ....

mutual -tls-auth 값은 required,optional 또는 none 이며 기본값으로 none 입니다. mutual -tls-auth-ca 값은 하나 이상의 CA 인증서가 포함된 파일을 지정합니다. 이러한 CA 인증서는 라우터에서 클라이언트의 인증서를 확인하는 데 사용됩니다.

mutual -tls-auth-crl 을 사용하면 인증서 취소 목록을 지정하여 인증서(유효한 인증 기관에서 발급)가 취소된 경우를 처리할 수 있습니다.

$ oc adm router --mutual-tls-auth=required  \
     --mutual-tls-auth-ca=/local/path/to/cacerts.pem  \
     --mutual-tls-auth-filter='^/CN=my.org/ST=CA/C=US/O=Security/OU=OSE$'  \
     ....

인증서 제목에 따라 --mutual-tls-auth-filter 값을 사용하여 세분화된 액세스 제어에 사용할 수 있습니다. 값은 인증서 제목과 일치하는 데 사용되는 정규식입니다.

mutual -tls-auth=required 를 사용하면 인증된 클라이언트 만 백엔드 리소스에 액세스할 수 있습니다. 즉, 클라이언트가 인증 정보( 클라이언트 인증서라고 함)를 항상 제공해야 합니다. 상호 TLS 인증을 선택하도록 하려면 --mutual-tls-auth=optional 을 사용합니다(또는 none 을 사용하여 이를 비활성화 - 기본값임). 여기서 선택사항 은 인증 정보를 제공하는 클라이언트가 인증 정보를 제공하지 않아도 되며 클라이언트가 인증 정보를 제공하는 경우 X-SSL* HTTP 헤더의 백엔드로만 전달됩니다.

$ oc adm router --mutual-tls-auth=optional  \
     --mutual-tls-auth-ca=/local/path/to/cacerts.pem  \
     ....

상호 TLS 인증 지원이 활성화된 경우( --mutual-tls-auth 플래그에 필수 또는 선택적 값 사용) 클라이언트 인증 정보는 X-SSL* HTTP 헤더 형식의 백엔드로 전달됩니다.

X-SSL* HTTP 헤더 X-SSL-Client-DN: 인증서 제목의 전체 고유 이름(DN)의 예. X-SSL-Client-NotBefore: YYMMDDhhmmss[Z] 형식의 클라이언트 인증서 시작 날짜입니다. X-SSL-Client-NotAfter: YYMMDDhhmmss[Z] 형식의 클라이언트 인증서 종료일입니다. X-SSL-Client-SHA1: 클라이언트 인증서의 SHA-1 지문입니다. X-SSL-Client-DER: 클라이언트 인증서에 대한 전체 액세스를 제공합니다. base-64 형식으로 인코딩된 DER 형식 클라이언트 인증서를 포함합니다.

IP 페일오버를 사용하여 OpenShift Container Platform 클러스터에 고가용성 라우터를 설정 할 수 있습니다. 이 설정에는 여러 노드에 여러 개의 복제본이 있으므로 현재 노드에 장애가 발생한 경우 장애 조치(failover) 소프트웨어로 전환할 수 있습니다.

환경 변수 ROUTER_SERVICE_HTTP_PORT 및 ROUTER_SERVICE_HTTPS_PORT 를 설정하여 템플릿 라우터가 바인딩하는 서비스 포트를 사용자 지정할 수 있습니다. 이 작업은 템플릿 라우터를 만든 다음 배포 구성을 편집하여 수행할 수 있습니다.

다음 예제에서는 0 개의 복제본을 사용하여 라우터 배포를 생성하고 라우터 서비스 HTTP 및 HTTPS 포트를 사용자 지정한 다음 적절하게 확장합니다(복제본 1 개로).

$ oc adm router --replicas=0 --ports='10080:10080,10443:10443' 1
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080  \
                   ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1

다음은 iptables 를 사용하여 사용자 지정 라우터 서비스 포트를 여는 예입니다.

$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10080 -j ACCEPT
$ iptables -A OS_FIREWALL_ALLOW -p tcp --dport 10443 -j ACCEPT

관리자는 동일한 정의로 여러 라우터를 만들어 동일한 경로 집합을 제공할 수 있습니다. 각 라우터는 다른 노드에 있으며 다른 IP 주소를 가집니다. 네트워크 관리자는 각 노드에 원하는 트래픽을 가져와야 합니다.

클러스터에 라우팅 부하를 분산하고 다른 라우터 또는 shard 에 테넌트를 분리하도록 여러 라우터를 그룹화할 수 있습니다. 그룹의 각 라우터 또는 shard는 라우터의 선택기를 기반으로 경로를 허용합니다. 관리자는 ROUTE_LABELS 를 사용하여 전체 클러스터에 shard를 생성할 수 있습니다. 사용자는 NAMESPACE_LABELS 를 사용하여 네임스페이스(프로젝트)에서 shard를 생성할 수 있습니다.

특정 라우터를 특정 노드에 배포하려면 다음 두 단계가 필요합니다.

라우터 분할 에서는 NAMESPACE_LABELS 및 ROUTE_LABELS 를 사용하여 라우터 네임스페이스와 경로를 필터링합니다. 이를 통해 경로의 하위 집합을 여러 라우터 배포에 배포할 수 있습니다. 오버레이되지 않은 하위 집합을 사용하면 경로 집합을 효과적으로 분할할 수 있습니다. 또는 겹치는 경로 하위 집합으로 구성된 shard를 정의할 수 있습니다.

기본적으로 라우터는 모든 프로젝트(네임스페이스) 에서 모든 경로를 선택합니다. 분할에는 경로 또는 네임스페이스에 레이블을 추가하고 라우터에 라벨 선택기를 추가합니다. 각 라우터 shard는 특정 레이블 선택기 집합에서 선택한 경로로 구성되거나 특정 레이블 선택기 세트에서 선택한 네임스페이스에 속합니다.

라우터 공유 및 DNS

요청을 원하는 shard로 라우팅하려면 외부 DNS 서버가 필요하므로 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 만들어야 합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.

다음 예제를 고려하십시오.

별도의 DNS 항목은 *.foo.com을 라우터 A를 호스팅하는 노드로 확인하고 *.example.com을 라우터 B를 호스팅하는 노드로 확인해야 합니다.

라우터 공유 예

이 섹션에서는 네임스페이스 및 경로 레이블을 사용하여 라우터 분할에 대해 설명합니다.

그림 3.1. 네임 스페이스 레이블 기반 라우터 공유

이 레이블을 추가하면 라우터에서 경로를 사용할 수 있습니다.

sla=high       geo=east     hw=modest     dept=finance
sla=medium     geo=west     hw=strong     dept=dev
sla=low                                   dept=ops

#!/bin/bash
# Usage: mkshard ID SELECTION-EXPRESSION
id=$1
sel="$2"
router=router-shard-$id           1
oc adm router $router --replicas=0  2
dc=dc/router-shard-$id            3
oc set env   $dc ROUTE_LABELS="$sel"  4
oc scale $dc --replicas=3         5

#!/bin/bash
# Usage: modshard ID SELECTION-EXPRESSION...
id=$1
shift
router=router-shard-$id       1
dc=dc/$router                 2
oc scale $dc --replicas=0     3
oc set env   $dc "$@"             4
oc scale $dc --replicas=3     5

$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'

$ modshard 3 ROUTE_LABELS='dept != finance'

$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'

$ modshard 3 NAMESPACE_LABELS='frequency=weekly'

$ modshard 3 \
    NAMESPACE_LABELS='frequency=weekly' \
    ROUTE_LABELS='sla=low'

서비스를 노출할 때 외부 사용자가 애플리케이션에 액세스하는 데 사용하는 DNS 이름과 동일한 경로를 사용할 수 있습니다. 외부 네트워크의 네트워크 관리자는 호스트 이름이 경로를 허용한 라우터의 이름으로 확인되어야 합니다. 사용자는 이 호스트 이름을 가리키는 CNAME으로 DNS를 설정할 수 있습니다. 그러나 사용자는 라우터의 호스트 이름을 알지 못할 수 있습니다. 알 수 없는 경우 클러스터 관리자는 이를 제공할 수 있습니다.

클러스터 관리자는 라우터를 만들 때 라우터의 정식 호스트 이름과 함께 --router-canonical-hostname 옵션을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

# oc adm router myrouter --router-canonical-hostname="rtr.example.com"

이렇게 하면 라우터의 호스트 이름이 포함된 라우터 배포 구성에 ROUTER_CANONICAL_HOSTNAME 환경 변수가 생성됩니다.

이미 존재하는 라우터의 경우 클러스터 관리자는 라우터의 배포 구성을 편집하고 ROUTER_CANONICAL_HOSTNAME 환경 변수를 추가할 수 있습니다.

spec:
  template:
    spec:
      containers:
        - env:
          - name: ROUTER_CANONICAL_HOSTNAME
            value: rtr.example.com

ROUTER_CANONICAL_HOSTNAME 값은 경로를 승인한 모든 라우터의 경로 상태에 표시됩니다. 라우터를 다시 로드할 때마다 경로 상태가 새로 고쳐집니다.

사용자가 경로를 만들면 모든 활성 라우터가 경로를 평가하고 조건이 충족되면 이를 승인합니다. ROUTER_CANONICAL_HOSTNAME 환경 변수를 정의하는 라우터에서 경로를 허용하면 라우터에서 routerCanonicalHostname 필드에 값을 경로 상태에 배치합니다. 사용자는 경로 상태를 검사하여 라우터가 경로를 허용했는지 확인하고, 목록에서 라우터를 선택하고, 네트워크 관리자에게 전달할 라우터의 호스트 이름을 찾을 수 있습니다.

status:
  ingress:
    conditions:
      lastTransitionTime: 2016-12-07T15:20:57Z
      status: "True"
      type: Admitted
      host: hello.in.mycloud.com
      routerCanonicalHostname: rtr.example.com
      routerName: myrouter
      wildcardPolicy: None

oc describe 는 사용 가능한 경우 호스트 이름을 포함합니다.

$ oc describe route/hello-route3
...
Requested Host: hello.in.mycloud.com exposed on router myroute (host rtr.example.com) 12 minutes ago

사용자는 위의 정보를 사용하여 DNS 관리자에게 경로의 호스트 hello.in.mycloud.com에서 라우터의 정식 호스트 이름 rtr.example.com 으로 CNAME을 설정하도록 요청할 수 있습니다. 그러면 hello.in.mycloud.com 에 대한 트래픽이 사용자의 애플리케이션에 도달하게 됩니다.

마스터 구성 파일(기본적으로 /etc/origin/master/master-config.yaml 파일)을 수정하여 해당 환경의 기본 라우팅 하위 도메인으로 사용되는 접미사를 사용자 지정할 수 있습니다. 호스트 이름을 지정하지 않는 경로는 이 기본 라우팅 하위 도메인을 사용하여 생성됩니다.

다음 예제에서는 구성된 접미사를 v3.openshift.test로 설정하는 방법을 보여줍니다.

routingConfig:
  subdomain: v3.openshift.test

위 구성을 실행하는 OpenShift Container Platform 마스터에서 mynamespace 네임스페이스에 호스트 이름을 추가하지 않고 no-route-hostname 이라는 경로의 예를 위해 생성된 호스트 이름은 다음과 같습니다.

no-route-hostname-mynamespace.v3.openshift.test

관리자가 모든 경로를 특정 라우팅 하위 도메인으로 제한하려는 경우 --force-subdomain 옵션을 oc adm router 명령에 전달할 수 있습니다. 이렇게 하면 라우터가 경로에 지정된 호스트 이름을 재정의하고 --force-subdomain 옵션에 제공된 템플릿을 기반으로 합니다.

다음 예제에서는 라우터를 실행하여 사용자 지정 하위 도메인 템플릿 ${name}-${namespace}.apps.example.com 을 사용하여 경로 호스트 이름을 재정의합니다.

$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'

인증서가 포함되지 않은 TLS 지원 경로에서는 라우터의 기본 인증서를 대신 사용합니다. 대부분의 경우 이 인증서는 신뢰할 수 있는 인증 기관에서 제공해야 하지만 편의를 위해 OpenShift Container Platform CA를 사용하여 인증서를 생성할 수 있습니다. 예를 들면 다음과 같습니다.

$ CA=/etc/origin/master
$ oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
      --signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
      --hostnames='*.cloudapps.example.com' \
      --cert=cloudapps.crt --key=cloudapps.key

라우터는 인증서와 키가 단일 파일에서 PEM 형식이어야 합니다.

$ cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem

여기에서 --default-cert 플래그를 사용할 수 있습니다.

$ oc adm router --default-cert=cloudapps.router.pem --service-account=router

라우터 인증서를 수동으로 재배포하려면 다음을 수행합니다.

현재는 암호로 보호되는 키 파일이 지원되지 않습니다. HAProxy는 시작 시 암호를 묻는 메시지를 표시하며 이 프로세스를 자동화할 방법이 없습니다. 키 파일에서 암호를 제거하려면 다음을 실행합니다.

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

다음은 트래픽이 대상에 프록시되기 전에 라우터에서 TLS 종료와 함께 보안 에지 종료 경로를 사용하는 방법에 대한 예입니다. 보안 에지 종료 경로는 TLS 인증서 및 키 정보를 지정합니다. TLS 인증서는 라우터 프런트엔드에서 제공합니다.

먼저 라우터 인스턴스를 시작합니다.

# oc adm router --replicas=1 --service-account=router

다음으로 에지 보안 경로에 사용할 개인 키 csr 및 인증서를 만듭니다. 이 작업을 수행하는 방법에 대한 지침은 인증 기관 및 공급자에 따라 다릅니다. www.example.test 도메인의 간단한 자체 서명 인증서는 아래 표시된 예제를 참조하십시오.

# sudo openssl genrsa -out example-test.key 2048
#
# sudo openssl req -new -key example-test.key -out example-test.csr  \
  -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=www.example.test"
#
# sudo openssl x509 -req -days 366 -in example-test.csr  \
      -signkey example-test.key -out example-test.crt

위의 인증서와 키를 사용하여 경로를 생성합니다.

$ oc create route edge --service=my-service \
    --hostname=www.example.test \
    --key=example-test.key --cert=example-test.crt
route "my-service" created

해당 정의를 살펴보겠습니다.

$ oc get route/my-service -o yaml
apiVersion: v1
kind: Route
metadata:
  name:  my-service
spec:
  host: www.example.test
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
    key: |
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

www.example.test 에 대한 DNS 항목이 라우터 인스턴스를 가리키는지 확인하고 도메인의 경로를 사용할 수 있어야 합니다. 아래 예제에서는 로컬 확인자와 함께 curl을 사용하여 DNS 조회를 시뮬레이션합니다.

# routerip="4.1.1.1"  #  replace with IP address of one of your router instances.
# curl -k --resolve www.example.test:443:$routerip https://www.example.test/

HAProxy 라우터는 와일드카드 경로를 지원하며, 이 경로는 ROUTER_ALLOW_WILDCARD_ROUTES 환경 변수를 true 로 설정하여 활성화됩니다. 라우터 승인 검사를 통과하는 와일드카드 정책이 Subdomain 인 모든 경로는 HAProxy 라우터에서 서비스를 제공합니다. 그런 다음 HAProxy 라우터는 경로의 와일드카드 정책에 따라 연결된 서비스(경로용)를 노출합니다.

$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1

와일드카드 경로에 사용할 웹 콘솔을 구성하는 방법을 알아봅니다.

보안 에지 종료 경로는 TLS 인증서 및 키 정보를 지정합니다. TLS 인증서는 하위 도메인(*.example.org)과 일치하는 모든 호스트의 라우터 프런트엔드에서 제공합니다.

와일드카드 경로(ROUTER_ALLOW_WILDCARD_ROUTES 가 true로 설정됨)를 허용하는 라우터의 경우 와일드카드 경로와 연결된 하위 도메인의 소유권에 대한 몇 가지 주의 사항이 있습니다.

와일드카드 경로 이전에는 다른 클레임에 대해 경로가 가장 오래된 네임스페이스를 사용하는 호스트 이름에 대한 소유권을 기반으로 했습니다. 예를 들어, 1. example.test 에 대한 클레임이 있는 네임스페이스 ns1 의 경로 r 1은 경로 r2 가 경로 r 2보다 오래된 경우 네임스페이스 ns2 의 다른 경로 r 2 에 대해 상이합니다.

또한 다른 네임스페이스의 경로는 오버레이되지 않은 호스트 이름을 요청할 수 있었습니다. 예를 들어 네임스페이스 ns1 의 routerone은 www.example.test 를 클레임하고 네임스페이스 d2 의 다른 경로 rtwo 는 c3po.example.test 를 클레임할 수 있습니다.

동일한 하위 도메인을 클레임하는 와일드카드 경로(위예제에서 example.test )가 없는 경우에도 마찬가지입니다.

그러나 와일드카드 경로는 하위 도메인(\ *.example.test 형식의 호스트 이름) 내의 모든 호스트 이름을 요청해야 합니다. 와일드카드 경로의 클레임은 해당 하위 도메인의 가장 오래된 경로(예.test)가 와일드카드 경로와 동일한 네임스페이스에 있는지 여부에 따라 허용 또는 거부됩니다. 가장 오래된 경로는 일반 경로 또는 와일드카드 경로일 수 있습니다.

예를 들어, owner.example.test 라는 호스트를 요청한 ns1 네임스페이스에 경로 eldest 가 이미 있고 나중에 해당 하위 도메인의 경로(예.test)에 요청하는 새 와일드카드 경로 와일드카드 경로가 추가된 경우 와일드카드 경로의 클레임은소유경로와 동일한 네임스페이스(ns1)인 경우에만 허용됩니다.

다음 예제에서는 와일드카드 경로 클레임이 성공 또는 실패하는 다양한 시나리오를 보여줍니다.

아래 예제에서 와일드카드 경로를 허용하는 라우터는 와일드카드 경로가 하위 도메인을 요청하지 않은 한 하위 도메인 example.test 에 있는 호스트에 대한 비 오버레이 클레임을 허용합니다.

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test
$ oc expose service myservice --hostname=bname.example.test

$ oc project ns2
$ oc expose service anotherservice --hostname=second.example.test
$ oc expose service anotherservice --hostname=cname.example.test

$ oc project otherns
$ oc expose service thirdservice --hostname=emmy.example.test
$ oc expose service thirdservice --hostname=webby.example.test

아래 예제에서 와일드카드 경로를 허용하는 라우터에서는 소유자.example.test 또는 aname.example.example.test 에 대한 클레임을 성공적으로 허용하지 않습니다. 소유 네임스페이스는 ns1 입니다.

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test

$ oc project ns2
$ oc expose service secondservice --hostname=bname.example.test
$ oc expose service secondservice --hostname=cname.example.test

$ # Router will not allow this claim with a different path name `/p1` as
$ # namespace `ns1` has an older route claiming host `aname.example.test`.
$ oc expose service secondservice --hostname=aname.example.test --path="/p1"

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `owner.example.test`.
$ oc expose service secondservice --hostname=owner.example.test

$ oc project otherns

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `aname.example.test`.
$ oc expose service thirdservice --hostname=aname.example.test

아래 예제에서 와일드카드 경로를 허용하는 라우터를 사용하면 소유 네임스페이스가 ns1 이고 와일드카드 경로는 동일한 네임스페이스에 속하므로 '\*.example.test.test 클레임이 성공합니다.

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will allow this claim.

아래 예에서 와일드카드 경로를 허용하는 라우터에서는 소유 네임스페이스가 ns1 이고 와일드카드 경로는 다른 네임 스페이스에 속하므로 '\*.example.test.test에 대한 클레임이 성공하지 못합니다 .

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Switch to a different namespace/project.
$ oc project cyclone

$ # Reusing the route.yaml from a prior example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will deny (_NOT_ allow) this claim.

마찬가지로 와일드카드 경로가 있는 네임스페이스에서 하위 도메인을 요청하면 해당 네임스페이스 내 경로만 동일한 하위 도메인의 호스트를 요청할 수 있습니다.

아래 예제에서 와일드카드 경로가 subdomain example.test 인 네임스페이스 ns1 의 경로가 있으면 네임스페이스 ns1 의 경로만 동일한 하위 도메인의 호스트를 요청할 수 있습니다.

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service otherservice --hostname=other.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `other.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for deux.example.test
$ oc expose service mysecondservice --hostname=deux.example.test

$ # namespace `ns1` is allowed to claim for deux.example.test with path /p1
$ oc expose service mythirdservice --hostname=deux.example.test --path="/p1"

$ oc project otherns

$ # namespace `otherns` is not allowed to claim for deux.example.test
$ # with a different path '/otherpath'
$ oc expose service otherservice --hostname=deux.example.test --path="/otherpath"

$ # namespace `otherns` is not allowed to claim for owner.example.test
$ oc expose service yetanotherservice --hostname=owner.example.test

$ # namespace `otherns` is not allowed to claim for unclaimed.example.test
$ oc expose service yetanotherservice --hostname=unclaimed.example.test

아래 예제에서는 소유자 경로가 삭제되고 소유권이 네임스페이스 내에서 전달되는 다양한 시나리오가 표시되어 있습니다. 네임스페이스 ns1 에 호스트를 클레임하는 경로에는 eldest .example.test 가 있지만 해당 네임스페이스의 와일드카드 경로는 하위 도메인 example.test 를 요청할 수 있습니다. 호스트 eldest .example.test 의 경로가 삭제되면 다음 가장 오래된 경로 senior.example.test 가 가장 오래된 경로가 되며 다른 경로에는 영향을 주지 않습니다. 호스트 senior.example.test 의 경로가 삭제되면 가장 오래된 다음 경로 junior.example.test 가 가장 오래된 경로가 되고 와일드카드 경로 클레임자를 차단합니다.

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=eldest.example.test
$ oc expose service seniorservice --hostname=senior.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service juniorservice --hostname=junior.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `junior.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for dos.example.test
$ oc expose service mysecondservice --hostname=dos.example.test

$ # Delete route for host `eldest.example.test`, the next oldest route is
$ # the one claiming `senior.example.test`, so route claims are unaffacted.
$ oc delete route myservice

$ # Delete route for host `senior.example.test`, the next oldest route is
$ # the one claiming `junior.example.test` in another namespace, so claims
$ # for a wildcard route would be affected. The route for the host
$ # `dos.example.test` would be unaffected as there are no other wildcard
$ # claimants blocking it.
$ oc delete route seniorservice

OpenShift Container Platform 라우터는 컨테이너 내부에서 실행되며 기본 동작은 호스트의 네트워크 스택을 사용하는 것입니다(즉, 라우터 컨테이너가 실행되는 노드). 이 기본 동작은 원격 클라이언트의 네트워크 트래픽이 대상 서비스 및 컨테이너에 도달하기 위해 사용자 공간을 통해 여러 개의 홉을 수행하지 않아도 되므로 성능에 도움이 됩니다.

또한 이 기본 동작을 사용하면 라우터에서 노드의 IP 주소를 가져오는 대신 원격 연결의 실제 소스 IP 주소를 가져올 수 있습니다. 이 기능은 원래 IP를 기반으로 수신 규칙을 정의하고, 고정 세션을 지원하고, 다른 용도에서 트래픽을 모니터링하는 데 유용합니다.

이 호스트 네트워크 동작은 --host-network 라우터 명령줄 옵션으로 제어되며 기본 동작은 --host-network=true 를 사용하는 것과 동일합니다. 컨테이너 네트워크 스택을 사용하여 라우터를 실행하려면 라우터를 만들 때 --host-network=false 옵션을 사용합니다. 예를 들면 다음과 같습니다.

$ oc adm router --service-account=router --host-network=false

내부적으로 라우터 컨테이너는 외부 네트워크가 라우터와 통신할 수 있도록 80 및 443 포트를 게시해야 합니다.

동적 구성 관리자를 지원하도록 HAProxy 라우터를 구성할 수 있습니다.

동적 구성 관리자는 HAProxy를 다시 로드하지 않고도 특정 유형의 경로를 온라인으로 제공합니다. 경로 및 엔드포인트 추가|deletion|업데이트 와 같은 경로 및 엔드포인트 라이프사이클 이벤트를 처리합니다.

ROUTER_HAPROXY_CONFIG_MANAGER 환경 변수를 true 로 설정하여 동적 구성 관리자를 활성화합니다.

$ oc set env dc/<router_name> ROUTER_HAPROXY_CONFIG_MANAGER='true'

동적 구성 관리자가 HAProxy를 동적으로 구성할 수 없는 경우 구성을 다시 작성하고 HAProxy 프로세스를 다시 로드합니다. 예를 들어 새 경로에 사용자 지정 시간 초과와 같은 사용자 지정 주석이 있거나 경로에 사용자 지정 TLS 구성이 필요한 경우입니다.

동적 구성은 사전 할당된 경로 및 백엔드 서버 풀과 함께 HAProxy 소켓 및 구성 API를 사용합니다. 경로 청사진을 사용하여 사전 할당된 경로 풀이 생성됩니다. 기본 청사진 집합은 사용자 지정 TLS 구성 및 통과 경로 없이 비보안 경로, 에지 보안 경로를 지원합니다.

다음 절차에서는 세 개의 경로 오브젝트, 즉 reencrypt-blueprint, annotated- edge-blueprint 및 annotated- unsecured-blueprint 를 생성했다고 가정합니다. 다양한 경로 유형 오브젝트의 예는 경로 유형을 참조하십시오.

HAProxy 라우터 지표 는 기본적으로 외부 지표 수집 및 집계 시스템(예: Prometheus, statsd)에서 사용할 수 있도록 Prometheus 형식에 노출되거나 게시됩니다. 지표는 브라우저 또는 CSV 다운로드에서 볼 수 있도록 자체 HTML 형식으로 HAProxy 라우터 에서 직접 사용할 수도 있습니다. 이러한 지표에는 HAProxy 기본 지표 및 일부 컨트롤러 지표가 포함됩니다.

다음 명령을 사용하여 라우터를 생성할 때 OpenShift Container Platform에서는 기본적으로 1936년까지 통계 포트의 Prometheus 형식으로 지표를 사용할 수 있습니다.

$ oc adm router --service-account=router

다수의 경로가 있는 OpenShift Container Platform 클러스터에서는 기본적으로 65536 인 net.ipv4.neigh.default.gc_thresh3 값보다 큰 경로가 있는 OpenShift Container Platform 클러스터에서 라우터 Pod를 실행하는 클러스터의 각 노드에서 sysctl 변수의 기본값을 늘려 ARP 캐시에 더 많은 항목을 허용해야 합니다.

문제가 발생하면 커널 메시지가 다음과 유사합니다.

[ 1738.811139] net_ratelimit: 1045 callbacks suppressed
[ 1743.823136] net_ratelimit: 293 callbacks suppressed

이 문제가 발생하면 oc 명령이 다음 오류로 인해 실패할 수 있습니다.

Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument

IPv4의 실제 ARP 항목을 확인하려면 다음을 실행합니다.

# ip -4 neigh show nud all | wc -l

숫자가 net.ipv4.neigh.default.gc_thresh3 임계값에 접근하기 시작하면 값을 늘립니다. 다음을 실행하여 현재 값을 가져옵니다.

# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh2 = 512
# sysctl net.ipv4.neigh.default.gc_thresh3
net.ipv4.neigh.default.gc_thresh3 = 1024

다음 sysctl은 변수를 OpenShift Container Platform 현재 기본값으로 설정합니다.

# sysctl net.ipv4.neigh.default.gc_thresh1=8192
# sysctl net.ipv4.neigh.default.gc_thresh2=32768
# sysctl net.ipv4.neigh.default.gc_thresh3=65536

이러한 설정을 영구적으로 설정하려면 이 문서를 참조하십시오.

DHCP http-request 를 기본 HAProxy 라우터 이미지에 추가하여 DDoS(Distributed-of-service) 공격(예: slowloris) 공격으로부터 배포를 보호합니다.

# and the haproxy stats socket is available at /var/run/haproxy.stats
global
  stats socket ./haproxy.stats level admin

defaults
  option http-server-close
  mode http
  timeout http-request 5s
  timeout connect 5s 1
  timeout server 10s
  timeout client 30s

또한 환경 변수 ROUTER_SLOWLORIS_TIMEOUT 이 설정되면 클라이언트가 전체 HTTP 요청을 보내야 하는 시간을 제한합니다. 그렇지 않으면 HAProxy가 연결을 종료합니다.

환경 변수를 설정하면 라우터 배포 구성의 일부로 정보를 캡처할 수 있으며 템플릿을 수동으로 수정할 필요가 없지만 HAProxy 설정을 수동으로 추가하려면 라우터 포드를 다시 빌드하고 라우터 템플릿 파일을 유지 관리해야 합니다.

주석을 사용하면 HAProxy 템플릿 라우터에서 다음을 제한하는 기능을 포함하여 기본 사항이 적용됩니다.

애플리케이션은 트래픽 패턴이 매우 다를 수 있으므로 경로별로 활성화됩니다.

--threads 플래그로 활성화된 스레드입니다. 이 플래그는 HAProxy 라우터에서 사용할 스레드 수를 지정합니다.

기본 HAProxy 라우터는 대부분의 사용자의 요구 사항을 충족하기 위한 것입니다. 그러나 HAProxy의 모든 기능을 노출하지는 않습니다. 따라서 사용자가 자신의 요구에 맞게 라우터를 수정해야 할 수 있습니다.

애플리케이션 백엔드 내에서 새 기능을 구현하거나 현재 작업을 수정해야 할 수 있습니다. 라우터 플러그인은 이 사용자 지정에 필요한 모든 기능을 제공합니다.

라우터 포드는 템플릿 파일을 사용하여 필요한 HAProxy 구성 파일을 생성합니다. 템플릿 파일은 golang 템플릿 입니다. 템플릿을 처리할 때 라우터는 라우터의 배포 구성, 허용된 경로 집합 및 일부 도우미 기능을 포함하여 OpenShift Container Platform 정보에 액세스할 수 있습니다.

라우터 포드가 시작되고 다시 로드될 때마다 HAProxy 구성 파일을 생성한 다음 HAProxy를 시작합니다. HAProxy 구성 설명서 에서는 HAProxy의 모든 기능과 유효한 구성 파일을 구성하는 방법을 설명합니다.

configMap 을 사용하여 라우터 Pod에 새 템플릿을 추가할 수 있습니다. 이 방법을 사용하면 configMap 을 라우터 Pod의 볼륨으로 마운트하도록 라우터 배포 구성이 수정되었습니다. TEMPLATE_FILE 환경 변수는 라우터 포드에서 템플릿 파일의 전체 경로 이름으로 설정됩니다.

또는 사용자 지정 라우터 이미지를 빌드하여 일부 또는 전체 라우터를 배포할 때 사용할 수 있습니다. 모든 라우터에서 동일한 이미지를 실행할 필요가 없습니다. 이렇게 하려면 haproxy-template.config 파일을 수정하고 라우터 이미지를 다시 빌드 합니다. 새 이미지는 클러스터의 Docker 리포지토리로 푸시되고 라우터의 배포 구성 이미지: 필드가 새 이름으로 업데이트됩니다. 클러스터가 업데이트되면 이미지를 다시 빌드하고 푸시해야 합니다.

두 경우 모두 라우터 포드는 템플릿 파일로 시작합니다.

HAProxy 템플릿 파일은 상당히 크고 복잡합니다. 일부 변경의 경우 전체 교체를 작성하지 않고 기존 템플릿을 수정하는 것이 더 쉬울 수 있습니다. 라우터 Pod를 참조하여 master에서 이를 실행하여 실행 중인 라우터에서 haproxy-config.template 파일을 가져올 수 있습니다.

# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc exec router-2-40fc3 cat haproxy-config.template > haproxy-config.template
# oc exec router-2-40fc3 cat haproxy.config > haproxy.config

또는 라우터를 실행 중인 노드에 로그인할 수도 있습니다.

# docker run --rm --interactive=true --tty --entrypoint=cat \
    registry.redhat.io/openshift3/ose-haproxy-router:v{product-version} haproxy-config.template

이미지 이름은 컨테이너 이미지의 입니다.

사용자 지정된 템플릿의 기반으로 사용할 수 있도록 이 콘텐츠를 파일에 저장합니다. 저장된 haproxy.config 는 실제로 실행 중인 항목을 표시합니다.

ConfigMap 을 사용하여 라우터 이미지를 다시 빌드하지 않고 라우터 인스턴스를 사용자 지정할 수 있습니다. haproxy-config.template, reload-haproxy 및 기타 스크립트는 라우터 환경 변수 생성 및 수정뿐만 아니라 수정할 수 있습니다.

다음 예제 사용자 지정은 고가용성 라우팅 설정에서 사용하여 피어 간에 동기화되는 고정 테이블을 사용할 수 있습니다.

피어 섹션 추가

피어 간에 고정 테이블을 동기화하려면 HAProxy 구성에 peers 섹션을 정의해야 합니다. 이 섹션에서는 HAProxy가 피어를 식별하고 연결하는 방법을 결정합니다. 플러그인은 .PeerEndpoints 변수 아래의 템플릿에 데이터를 제공하여 라우터 서비스의 멤버를 쉽게 식별할 수 있도록 합니다. 다음을 추가하여 라우터 이미지 내의 haproxy-config.template 파일에 peer 섹션을 추가할 수 있습니다.

{{ if (len .PeerEndpoints) gt 0 }}
peers openshift_peers
  {{ range $endpointID, $endpoint := .PeerEndpoints }}
    peer {{$endpoint.TargetName}} {{$endpoint.IP}}:1937
  {{ end }}
{{ end }}

다시 로드 스크립트 변경

stick-tables를 사용하는 경우 HAProxy에 peer 섹션의 로컬 호스트 이름을 고려해야 하는 사항을 지시하는 옵션이 있습니다. 엔드포인트를 만들 때 플러그인은 TargetName 을 엔드포인트의 TargetRef.Name 값으로 설정합니다. TargetRef 를 설정하지 않으면 TargetName 을 IP 주소로 설정합니다. TargetRef.Name 은 Kubernetes 호스트 이름에 해당하므로, -L 옵션을 reload-haproxy 스크립트에 추가하여 피어 섹션에서 로컬 호스트를 식별할 수 있습니다.

peer_name=$HOSTNAME 1

if [ -n "$old_pid" ]; then
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name -sf $old_pid
else
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name
fi

백엔드 수정

마지막으로 백엔드 내에서 고정 테이블을 사용하려면 HAProxy 구성을 수정하여 stick-tables 및 peer 세트를 사용할 수 있습니다. 다음은 고정 테이블을 사용하도록 TCP 연결의 기존 백엔드를 변경하는 예입니다.

            {{ if eq $cfg.TLSTermination "passthrough" }}
backend be_tcp_{{$cfgIdx}}
  balance leastconn
  timeout check 5000ms
  stick-table type ip size 1m expire 5m{{ if (len $.PeerEndpoints) gt 0 }} peers openshift_peers {{ end }}
  stick on src
                {{ range $endpointID, $endpoint := $serviceUnit.EndpointTable }}
  server {{$endpointID}} {{$endpoint.IP}}:{{$endpoint.Port}} check inter 5000ms
                {{ end }}
            {{ end }}

이 수정 후 라우터를 다시 빌드할 수 있습니다.

라우터를 다시 빌드하려면 실행 중인 라우터에 있는 여러 파일의 복사본이 필요합니다. 작업 디렉토리를 만들고 라우터에서 파일을 복사합니다.

# mkdir - myrouter/conf
# cd myrouter
# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc exec router-2-40fc3 cat haproxy-config.template > conf/haproxy-config.template
# oc exec router-2-40fc3 cat error-page-503.http > conf/error-page-503.http
# oc exec router-2-40fc3 cat default_pub_keys.pem > conf/default_pub_keys.pem
# oc exec router-2-40fc3 cat ../Dockerfile > Dockerfile
# oc exec router-2-40fc3 cat ../reload-haproxy > reload-haproxy

이러한 파일을 편집하거나 바꿀 수 있습니다. 그러나 conf/haproxy-config.template 및 reload-haproxy 가 수정될 가능성이 가장 높습니다.

파일을 업데이트한 후 다음을 수행합니다.

# docker build -t openshift/origin-haproxy-router-myversion .
# docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion 1
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest 2

새 라우터를 사용하려면 image: 문자열을 변경하거나 oc adm router 명령에 --images=<repo>/<image>:<tag> 플래그를 추가하여 라우터 배포 구성을 편집합니다.

변경 사항을 디버깅할 때 imagePullPolicy를 설정하는 것이 좋습니다. always 배포 구성에서 각 Pod 생성 시 이미지를 강제로 가져옵니다. 디버깅이 완료되면 imagePullPolicy로 다시 변경할 수 있습니다. ifNotPresent 각 Pod에서 풀을 시작하지 않도록 합니다.

기본적으로 HAProxy 라우터에서는 HTTP를 사용하도록 들어오는 연결이 안전하지 않은 에지 및 재암호화 경로에 대해 예상합니다. 그러나 PROXY 프로토콜을 사용하여 들어오는 요청을 예상하도록 라우터를 구성할 수 있습니다. 이 주제에서는 PROXY 프로토콜을 사용하도록 HAProxy 라우터 및 외부 로드 밸런서를 구성하는 방법에 대해 설명합니다.

프록시 서버 또는 로드 밸런서와 같은 중간 서비스에서 HTTP 요청을 전달하는 경우 이 정보를 후속 중간 및 궁극적으로 요청이 전달되는 백엔드 서비스에 제공하기 위해 요청의 "Forwarded" 헤더에 연결의 소스 주소를 추가합니다. 그러나 연결이 암호화되면 중간자는 "Forwarded" 헤더를 수정할 수 없습니다. 이 경우 HTTP 헤더는 요청이 전달될 때 원래 소스 주소를 정확하게 전달하지 않습니다.

이 문제를 해결하기 위해 일부 로드 밸런서는 PROXY 프로토콜을 사용하여 HTTP 요청을 단순히 HTTP 전달을 위한 대안으로 캡슐화합니다. 캡슐화를 사용하면 전달된 요청 자체를 수정하지 않고도 로드 밸런서에서 요청에 정보를 추가할 수 있습니다. 특히, 이는 암호화된 연결을 전달할 때도 로드 밸런서에서 소스 주소를 통신할 수 있음을 의미합니다.

HAProxy 라우터는 PROXY 프로토콜을 수락하고 HTTP 요청을 분리하도록 구성할 수 있습니다. 라우터는 에지 및 재암호화 경로의 암호화를 종료하므로 라우터는 요청에서 "Forwarded" HTTP 헤더(및 관련 HTTP 헤더)를 업데이트하여 PROXY 프로토콜을 사용하여 통신하는 모든 소스 주소를 추가할 수 있습니다.

기본적으로 HAProxy 라우터에서는 PROXY 프로토콜을 사용하지 않습니다. 라우터는 들어오는 연결에 PROXY 프로토콜을 예상하도록 ROUTER_USE_PROXY_PROTOCOL 환경 변수를 사용하여 구성할 수 있습니다.

$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true

PROXY 프로토콜을 비활성화하려면 변수를 true 또는 TRUE 이외의 값으로 설정합니다.

$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=false

라우터에서 PROXY 프로토콜을 활성화하는 경우 PROXY 프로토콜을 사용하도록 라우터 앞에 로드 밸런서를 구성해야 합니다. 다음은 PROXY 프로토콜을 사용하도록 Amazon의 ELB(Elastic Load Balancer) 서비스를 구성하는 예입니다. 이 예에서는 ELB가 포트 80(HTTP), 443(HTTPS) 및 5000(이미지 레지스트리의 경우)을 하나 이상의 EC2 인스턴스에서 실행되는 라우터로 전달한다고 가정합니다.

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
    jq '.LoadBalancerDescriptions| [.[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 1
    },
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 2
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": [] 3
    }
  ]
]

또는 ELB가 이미 구성되어 있지만 PROXY 프로토콜을 사용하도록 구성되지 않은 경우 HTTP 대신 TCP 프로토콜을 사용하도록 기존 리스너를 변경해야 합니다(TCP 포트 443은 이미 TCP 프로토콜을 사용해야 함).

$ aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \
   --load-balancer-ports 80
$ aws elb create-load-balancer-listeners --load-balancer-name "$lb" \
   --listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
   jq '[.LoadBalancerDescriptions[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP", 1
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    }
  ]
]

그런 다음 로드 밸런서 정책을 만들고 위의 5단계에 설명된 대로 ELB에 추가합니다.

OpenShift Container Platform 설치 프로그램에는 OpenShift Container Platform에 Red Hat CloudForms 4.6(CloudForms Management Engine 5.9 또는 CFME)을 배포하기 위한 Ansible 역할 openshift-management 및 플레이북이 포함되어 있습니다.

OpenShift Container Platform에 Red Hat CloudForms를 배포할 때 다음과 같은 두 가지 주요 결정을 내릴 수 있습니다.

첫 번째 결정에서는 Red Hat CloudForms가 사용할 PostgreSQL 데이터베이스의 위치에 따라 두 가지 방법 중 하나로 Red Hat CloudForms를 배포할 수 있습니다.

두 번째 결정을 위해 openshift-management 역할은 많은 기본 배포 매개 변수를 재정의하기 위한 사용자 지정 옵션을 제공합니다. 여기에는 PV를 백업하는 스토리지 클래스 옵션이 포함됩니다.

이 가이드의 주제에는 OpenShift Container Platform에서 Red Hat CloudForms를 실행하기 위한 요구 사항, 사용 가능한 구성 변수에 대한 설명, 초기 OpenShift Container Platform 설치 중 또는 클러스터가 프로비저닝된 후 설치 프로그램 실행에 대한 지침이 포함되어 있습니다.

다음 섹션에서는 설치 프로그램을 실행할 때 Red Hat CloudForms 설치 동작을 제어하는 데 사용되는 Ansible 인벤토리 파일에서 사용할 수 있는 역할 변수에 대해 설명합니다.

openshift_management_template_parameters Ansible 역할 변수를 사용하여 애플리케이션 또는 PV 템플릿에서 재정의하려는 템플릿 매개변수를 지정할 수 있습니다.

예를 들어 PostgreSQL 포드의 메모리 요구 사항을 줄이려는 경우 다음을 설정할 수 있습니다.

openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}

Red Hat CloudForms 템플릿이 처리되면 POSTGRESQL_MEM_REQ 템플릿 매개변수 값에 1Gi 가 사용됩니다.

일부 템플릿 매개 변수가 두 템플릿 변형(컨테이너화된 또는 외부 데이터베이스)에 있는 것은 아닙니다. 예를 들어 podified 데이터베이스 템플릿에는 POSTGRESQL_MEM_REQ 매개 변수가 있지만 포드가 필요한 데이터베이스가 없기 때문에 이러한 매개 변수가 외부 db 템플릿에 존재하지 않습니다.

따라서 템플릿 매개 변수를 재정의하는 경우 주의하십시오. 템플릿에 정의되지 않은 매개 변수를 포함하면 오류가 발생합니다. Unsure the Management App is created 작업 중에 오류가 발생하면 설치 프로그램을 다시 실행하기 전에 제거 스크립트를 먼저 실행합니다.

초기 OpenShift Container Platform 설치 중 또는 클러스터가 프로비저닝된 후 Red Hat CloudForms를 배포할 수 있습니다.

다음 섹션에서는 시작하는 데 도움이 되는 OpenShift Container Platform의 Red Hat CloudForms의 다양한 구성을 보여주는 인벤토리 파일의 예를 보여줍니다.

[OSEv3:vars]
openshift_management_app_template=cfme-template

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_storage_class=nfs_external 1
openshift_management_storage_nfs_external_hostname=nfs.example.com 2

openshift_management_storage_nfs_base_dir=/exports/hosted/prod

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}

[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}

설치 프로그램 실행에 설명된 대로 OpenShift Container Platform에 Red Hat CloudForms를 배포한 후 컨테이너 공급자 통합을 활성화하는 두 가지 방법이 있습니다. OpenShift Container Platform을 컨테이너 공급자로 수동으로 추가하거나 이 역할에 포함된 플레이북을 시도할 수 있습니다.

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    openshift-management/add_container_provider.yml

현재 OpenShift Container Platform 클러스터를 Red Hat CloudForms 배포에 통합하는 플레이북을 제공할 뿐 아니라, 이 역할에는 임의의 Red Hat CloudForms 서버에서 여러 컨테이너 플랫폼을 컨테이너 공급자로 추가할 수 있는 스크립트가 포함되어 있습니다. 컨테이너 플랫폼은 OpenShift Container Platform 또는 OpenShift Origin일 수 있습니다.

여러 프로바이더 스크립트를 사용하려면 플레이북을 실행할 때 CLI에서 EXTRA_VARS 매개 변수를 수동으로 구성하고 설정해야 합니다.

container_providers:
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 1
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname1>"
    name: <display_name1>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 2
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname2>"
    name: <display_name2>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
management_server:
  hostname: "<hostname>"
  user: <user_name>
  password: <password>

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    -e container_providers_config=/tmp/cp.yml \
    playbooks/openshift-management/add_many_container_providers.yml

하나 이상의 컨테이너 공급업체를 추가한 후 Red Hat CloudForms에서 새 공급업체를 새로 고쳐 컨테이너 공급업체 및 관리 중인 컨테이너에 대한 모든 최신 데이터를 가져와야 합니다. 이를 위해서는 Red Hat CloudForms 웹 콘솔의 각 공급업체로 이동한 후 각각 새로 고침 버튼을 클릭해야 합니다.

단계는 다음 Red Hat CloudForms 설명서를 참조하십시오.

OpenShift Container Platform에서 배포된 Red Hat CloudForms 설치를 제거 및 제거하려면 플레이북 디렉터리로 변경하고 uninstall.yml 플레이북을 실행합니다.

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    playbooks/openshift-management/uninstall.yml

이전 PostgreSQL 데이터를 지우지 않으면 캐스케이딩 오류가 발생할 수 있으므로 postgresql Pod가 크래시 루프백 상태가 됩니다. 그러면 cfme 포드가 시작되지 않습니다. 크래시 루프백오프 의 원인은 이전 배포 중에 생성된 데이터베이스 NFS 내보내기에 대한 잘못된 파일 권한 때문입니다.

계속하려면 PostgreSQL 내보내기에서 모든 데이터를 지우고 포드(배포자 포드가 아님)를 삭제합니다. 예를 들어 다음 Pod가 있는 경우 다음을 수행합니다.

$ oc get pods
NAME                 READY     STATUS             RESTARTS   AGE
httpd-1-cx7fk        1/1       Running            1          21h
cfme-0               0/1       Running            1          21h
memcached-1-vkc7p    1/1       Running            1          21h
postgresql-1-deploy  1/1       Running            1          21h
postgresql-1-6w2t4   0/1       CrashLoopBackOff   1          21h

그런 다음 다음을 수행합니다.

PostgreSQL 배포자 포드는 삭제한 포드를 교체하기 위해 새 postgresql 포드를 확장하려고 합니다. postgresql 포드가 실행되면 cfme 포드에서 차단을 중지하고 애플리케이션 초기화를 시작합니다.

모니터링 스택은 추가 리소스 요구 사항을 적용합니다. 자세한 내용은 컴퓨팅 리소스 권장 사항을 참조하십시오.

모니터링 스택은 기본적으로 OpenShift Container Platform과 함께 설치됩니다. 설치되지 않도록 할 수 있습니다. 이를 수행하려면 Ansible 인벤토리 파일에서 이 변수를 false로 설정합니다.

openshift_cluster_monitoring_operator_install

다음을 실행하여 수행할 수 있습니다.

$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-monitoring/config.yml \
   -e openshift_cluster_monitoring_operator_install=False

Ansible 디렉터리의 일반적인 경로는 /usr/share/ansible/openshift-ansible/ 입니다. 이 경우 구성 파일의 경로는 /usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml 입니다.

영구저장장치를 사용하여 클러스터 모니터링을 실행하면 메트릭이 영구 볼륨에 저장되며 Pod가 다시 시작되거나 재생성될 수 있습니다. 데이터 손실에서 메트릭 또는 경고 데이터가 필요한 경우 이상적입니다. 프로덕션 환경의 경우 블록 스토리지 기술을 사용하여 영구 스토리지를 구성하는 것이 좋습니다.

지원되는 OpenShift Container Platform 모니터링 구성 방법은 이 가이드에 설명된 옵션을 사용하여 구성하는 것입니다. 이러한 명시적 구성 옵션 외에도 스택에 추가 구성을 삽입할 수 있습니다. 그러나 구성 패러다임은 Prometheus 릴리스에서 변경될 수 있으며 이러한 경우는 모든 구성 가능성이 제어되는 경우에만 정상적으로 처리할 수 있기 때문에 지원되지 않습니다.

명시적으로 지원되지 않는 경우는 다음과 같습니다.

OpenShift Container Platform 모니터링에는 모니터링 인프라를 사용할 수 있도록 잘못된 버전의 스위치가 포함되어 있습니다.

배달 못 한 사람의 스위치는 항상 트리거되는 간단한 Prometheus 경고 규칙입니다. Alertmanager는 배달된 사람의 스위치에 대한 알림을 지속적으로 이 기능을 지원하는 알림 프로바이더로 보냅니다. 또한 Alertmanager와 알림 프로바이더 간의 통신이 작동하는지 확인합니다.

이 메커니즘은 모니터링 시스템 자체가 중단될 때 알림을 발행하도록 PagerDuty에서 지원합니다. 자세한 내용은 아래 Dead man의 switch PagerDuty 를 참조하십시오.

Alertmanager에 대해 경고가 실행된 후 논리적으로 그룹화하는 방법을 확인하도록 구성해야 합니다.

이 예에서는 프론트엔드 팀의 경고 라우팅을 반영하기 위해 새 경로가 추가됩니다.

PagerDuty 는 Dead Man's Snitch 라는 통합을 통해 이 메커니즘을 지원합니다. PagerDuty 구성을 기본 deadmansswitch 수신자에 추가하면 됩니다. 위에서 설명한 프로세스를 사용하여 이 구성을 추가합니다.

Dead man의 스위치 경고가 15분 동안 자동으로 작동될 경우 운영자를 호출하도록 Dead Man의 Snitch를 구성합니다. 기본 Alertmanager 설정을 사용하면 5분마다 Dead man의 스위치 경고가 반복됩니다. 15분 후에 Dead Man의 Snitch가 트리거되면 알림이 2번 이상 실패했음을 나타냅니다.

PagerDuty를 위한 Dead Man의 Snitch 구성 방법 알아보기.

OpenShift Container Platform 클러스터 모니터링에는 기본적으로 구성된 다음 경고 규칙이 제공됩니다. 현재는 사용자 지정 경고 규칙을 추가할 수 없습니다.

일부 경고 규칙에는 이름이 동일합니다. 이것은 의도적입니다. 임계값이 다르거나 심각도가 다르거나 둘 다 있는 동일한 이벤트에 대해 경고합니다. 억제 규칙을 사용하면 심각도가 더 높은 심각도가 실행되면 더 낮은 심각도가 억제됩니다.

경고 규칙에 대한 자세한 내용은 구성 파일을 참조하십시오.

Red Hat 제품에 대한 권한이 있는 Red Hat 고객인 경우 해당 사용자 자격 증명이 있는 계정이 있습니다. Red Hat 고객 포털에 로그인하는 데 사용하는 사용자 이름과 암호입니다.

계정이 없는 경우 다음 옵션 중 하나에 등록하여 무료로 계정을 얻을 수 있습니다.

조직에서 공유 계정을 관리하는 경우 토큰을 생성해야 합니다. 관리자는 조직과 연결된 모든 토큰을 생성, 보기 및 삭제할 수 있습니다.

Ansible 설치 프로그램을 사용하여 설치 또는 업그레이드 중에 레지스트리 자격 증명을 관리할 수도 있습니다.

이렇게 하면 다음 설정이 설정됩니다.

openshift_examples_registryurl 또는 oreg_url 에 기본값 registry.redhat.io 를 사용하는 경우 Ansible 설치 프로그램에서 자격 증명이 필요합니다.

인증된 추가 레지스트리에 액세스해야 하는 클러스터는 openshift_additional_registry_credentials 를 설정하여 레지스트리 목록을 구성할 수 있습니다. 각 레지스트리에는 host 및 password 값이 필요하며 user를 설정하여 사용자 이름을 지정할 수 있습니다. 기본적으로 지정된 인증 정보는 지정된 레지스트리에서 이미지 openshift3/ose-pod 를 검사하여 유효성을 검사합니다.

대체 이미지를 지정하려면 다음 중 하나를 수행합니다.

레지스트리가 안전하지 않은 경우 tls_verify 를 False로 설정합니다.

이 목록의 모든 자격 증명에는 OpenShift 네임스페이스에서 생성된 imagestreamsecret 과 모든 노드에 배포된 자격 증명이 있습니다.

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

openshift_additional_registry_credentials=[{'host':'registry.example.com','user':'name','password':'pass1','test_login':'False'},{'host':'registry2.example.com','password':'token12345','tls_verify':'False','test_image':'mongodb/mongodb'}]

서비스 계정을 생성하고 Red Hat 레지스트리에 대해 생성된 토큰을 생성한 후에는 추가 작업을 수행할 수 있습니다.

HTPasswd 인증을 사용하도록 OpenShift Container Platform 클러스터를 구성하려면 인벤토리 파일에 포함하려면 해시된 암호가 있는 사용자가 하나 이상 필요합니다.

다음을 수행할 수 있습니다.

사용자 및 해시된 암호를 생성하려면 다음을 수행합니다.

그런 다음 HTPasswd 인증을 구성할 때 해시된 암호를 사용할 수 있습니다. 해시된 암호는 : 뒤에 있는 문자열입니다. 위의 예에서 다음을 입력합니다.

openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}

사용자 이름과 해시된 암호로 플랫 파일을 생성하려면 다음을 수행합니다.

그런 다음 HTPasswd 인증을 구성할 때 암호 파일을 사용할 수 있습니다.